专利名称：：支付令牌化装置、方法和系统的制作方法
技术领域：
：本发明通常针对用于购买交易的装置、方法和系统，更具体地说，针对支付令牌化装置、方法和系统(“PT”)。
背景技术：
：基于卡的消费者交易典型地需要消费者输入信用或借记卡的大量细节，或利用例如现金或支票的支付方法。从事卡交易需要将个人信息发送到广泛的第三方商家。附录和/或附图示出根据本发明的各个非限定性示例发明方面图I示出说明在PT的一些实施例中支付令牌化的示例方面的框图；图2A-图2B示出说明在PT的一些实施例中用于控制用于购买交易的令牌化支付的应用界面的示例特征的应用用户界面图；图3A-图3C示出说明在PT的一些实施例中用于使得用户数据安全并且防止欺骗的支付令牌化移动应用的示例特征的应用用户界面图；图4示出说明在PT的一些实施例中在基于令牌的购买支付程序中用于登记的示例过程的数据流程图；图5示出说明在PT的一些实施例(例如基于令牌的购买登记(“TPE”)组件500)中在基于令牌的购买支付程序中的登记的示例方面的逻辑流程图；图6A-图6E示出说明在PT的一些实施例中用于执行基于令牌的购买交易的示例过程的数据流程图；图7A-图7F示出说明在PT的一些实施例(例如基于令牌的购买交易执行(“tPTE”)组件700)中执行基于令牌的购买交易的示例方面的逻辑流程图；以及图8示出说明PT控制器的实施例的框图。附图中的每个标号的前导数字指示其中该标号被引入和/或详述的附图。故此，在图I中将发现和/或引入标号101的详细讨论。在图2中引入标号201，等等。具体实施方式支付令牌化(PT)支付令牌化装置、方法和系统(下文中“PT”)经由PT组件将基于支付令牌的购买订单变换为多个发放方购买支付资金转账。图I示出说明PT的一些实施例中支付令牌化的示例方面的框图。在一些实现方式中，用户可能希望从商家(例如106)购买产品、服务和/或其它供应物(“产品”)。用户可能希望利用卡(例如借记卡、信用卡、预付费等)(例如101a)、现金(或其等同物)(例如102a)、证券(例如103a)、虚拟货币、奖励、点数、英里等(例如104a)和/或其它支付选项。然而，用户可能希望保持匿名性以防止用户的个人信息被商家收集。作为另一示例，用户可能提防用户的卡数据被误用来进行欺骗交易。在一些实现方式中，用户可能能够利用化名或令牌来代替支付信息。例如，用户可能能够将令牌(例如101b、102b、103b、104b)传递到商家，而并非完全卡信息、现金或账户信息。安全令牌仲裁器可以结合商家而操作，以处理交易。例如，在从用户接收到支付令牌时，商家可以将令牌传递到交易仲裁器。安全交易仲裁器可以具有用于解析到来令牌并且确定用于该令牌的用户的身份的能力。交易仲裁器也可以确定用于处理交易的金融支付信息。在一些实现方式中，交易仲裁器也可以仅具有存储为支付信息的另一令牌。在这些实现方式中，令牌的发放方可以仅仅是获知用户的实际个人和/或金融信息实体而不是用户。因此，在一些实现方式中，令牌可以包括其它令牌的组合。例如，交易仲裁器持有的令牌可以指向交易仲裁器和/或发放方持有的其它令牌。因此，在一些实现方式中，可以相应地通过结构化支付令牌来生成个人和金融信息的安全性的多个层。在一些实现方式中，令牌可以指定包括其它支付令牌的混合的组合物。例如，支付令牌105可以指示可以通过将交易代价的百分比(例如55%)分配给(例如最终链接到信用卡信息IOla的)令牌IOlb并且将不同的百分比(例如45%)分配给(例如最终链接到存储的现金账户102a的)不同的令牌102b来处理交易。在一些实现方式中，可以实时地或几乎实时地确定百分比。例如，令牌仲裁器可以结合具有链接到支付令牌的用户账户的发放方而操作，以(例如根据预定算法)确定应对用户账户中的哪个收费，以及应对每个用户账户收费多少。作为另一示例，可以例如通过请求用户在处理购买交易时提供支付选项而仅在处理交易(见例如103b、104b)时确定百分比。在一些实现方式中，可以通过使用认证方法来对附加安全性进行分层。作为示例，可以要求用户提供用户名称和密码以激活支付令牌。作为另一示例，可以在对于购买交易利用支付令牌之前要求用户提供数字证书以验证用户的身份。作为另一示例，可以利用设备指纹识别。例如，用户的客户机设备可以是用户独占地使用的设备(例如智能电话、平板计算机、膝上型计算机等)。在一些实现方式中，定制硬件认证芯片(例如103)可以部署为与客户机通信。在各种实现方式中，芯片可以嵌入到客户机，预先安装在客户机中，附连为客户机的外设等。在一些实现方式中，用户可以执行与客户机以及链接到用户的支付令牌的用户的卡的认证过程。例如，认证芯片可以被配置为当卡在认证芯片的附近时识别用户的支付令牌物理卡。例如，认证芯片和卡可以经由蓝牙、Wi-Fi、RFID标签、蜂窝连接(例如3G、4G)等传递信号。因此，为了通过支付令牌进行购买，在一些实现方式中，在用户可以使用令牌进行订单购买之前，可以要求用户将支付令牌物理卡提交给与客户机通信地部署的认证芯片。因此，系统提供防止可能知道用户的支付令牌的其它人在欺骗交易中利用用户的支付令牌的可靠性护盾。图2A-图2B示出说明在PT的一些实施例中用来控制用于购买交易的令牌化支付的应用界面的示例特征的应用用户界面图。在一些实现方式中，对用户的设备执行的应用可以包括对用户提供各个特征的应用界面。在一些实现方式中，应用可以包括用户(例如201)的位置的指示(例如商家商店的名称、地理位置、关于商家商店内的通道的信息等)。应用可以提供因产品的购买而应得的支付量的指示(例如202)。在一些实现方式中，应用可以对用户提供各种选项以支付用于购买产品的金额。例如，应用可以利用GPS坐标来确定其中出现用户的商家商店，并且将用户导向到商家的网站。在一些实现方式中，PT可以提供用于直接参与商家以促进交易处理的API。在一些实现方式中，可以开发具有PT功能的商家品牌化PT应用，其可以将用户直接连接到商家的交易处理系统。例如，用户可以从来自各个卡提供商的大量卡(例如信用卡、借记卡、预付费卡等)(例如203)进行选取。在一些实现方式中，应用可以向用户提供用于使用用户的银行账户中包括的资金来支付购买金额的选项，例如支票、储金、货币市场、经常账户、等，例如204。在一些实现方式中，用户可以经由应用设置对于其对于购买交易使用卡、银行账户等的默认选项。在一些实现方式中，默认选项的这种设置可以允许用户经由单一点击、拍击、扫刷和/或其它纠正用户输入动作来发起购买交易(例如205)。在一些实现方式中，当用户利用该选项时，应用可以利用用户的默认设置来发起购买交易。在一些实现方式中，应用可以允许用户利用其它账户(例如GoogleCheckout、Paypal账户等)来支付购买交易(例如206)。在一些实现方式中,应用可以允许用户(例如通过捕获与产品标识符相似的打印礼券)利用奖励点数、航空里程数、宾馆点数、电子礼券、打印的礼券等支付购买交易(例如207-208)。在一些实现方式中，应用可以提供选项以在发起购买交易(例如209)之前提供表达授权。在一些实现方式中，在用户已经选择选项以发起购买交易之后，应用可以对交易的进程提供进程指示符提供指示(例如210)。在一些实现方式中，应用可以经由应用向用户提供关于用户的先前购买的历史信息(例如211)。在一些实现方式中，应用可以向用户提供选项以(例如经由电子邮件、SMS、FacebOOk±的墙壁张贴、Twitter上的推文等)与其它用户共享关于购买的信息(例如212)。在一些实现方式中，应用可以向用户提供选项以显示客户机设备捕获的产品识别信息(例如，为了向在商店出口处的客服代表示出产品信息)(例如214)。在一些实现方式中，用户、应用、设备和或PT可能在处理中遇到错误。在这些情况下，用户可能能够与客服代表交谈(例如VerifyChat213)，以解决购买交易过程中的难题。在一些实现方式中，用户可以选择使用一次令牌(例如匿名化信用卡号)来进行交易(见例如205b)。例如，PT可以利用卡细节的令牌化和匿名化集合(见例如“AnonCardl”，“AnonCard2”)。作为另一示例，PT可以例如实时生成卡细节的一次匿名集合以安全地完成购买交易(例如“AnonItIX”。)在这些实现方式中，应用可以自动地设置用户简档设置，从而用户的任何个人识别信息将不被提供给商家和/或其它实体。例如，应用可以自动地仅发送令牌或别名代替支付信息。支付系统可以处理令牌以获得用于处理购买交易的其关联的支付信息。在一些实现方式中，可以要求用户输入用户名称和密码以启用匿名化特征。在一些实现方式中，用户可以能够经由web界面(例如220)控制与用户关联的每个令牌的属性。例如，用户可能能够登录到web界面(例如221)，并且使得与用户关联的支付令牌可视化(例如223)。用户也可以被提供有用户界面元件，以生成新的令牌。例如，用户界面可以提供用于创建新的令牌的元件(例如224)。例如，用户界面可以允许用户选择金融细节225，例如，但不限于从其获得令牌的资金源、针对令牌的账户类型、初始令牌值(例如用于预先资金和/或孔隙认证)、值毁坏选项(例如协助用于用户的时间受控支出控制)、记账地址信息、货运地址信息、联系人设置、安全性协议、令牌管理者、用户匿名性(用于安全性)选项等。在一些实现方式中，web界面可以允许用户选择个人细节226，例如，但不限于令牌持有者、联系频率(例如用于令牌提供者)、令牌提供者偏好、家长控制、激活的设备等。在一些实现方式中，web界面可以允许用户指定用于令牌的激活227和超期228日期。图3A-图3C示出说明在PT的一些实施例中用于使得用户数据安全并且防止欺骗的支付令牌化移动应用的示例特征的应用用户界面图。在一些实现方式中，对用户的设备执行的应用可以(例如通过激活图2中的Π元件213)提供用于欺骗防范的“VerifyChat”特征。例如，PT可以检测异常和/或可疑的交易。PT可以利用VerifyChat特征来与用户通信，并且验证购买交易的发源者的可靠性。在各种实现方式中，PT可以发送电子邮件消息、文本(SMS)消息、Facebook消息、Twitter推文、文本交谈、语音交谈、视频交谈(例如AppleFaceTime)等，以与用户通信。例如，PT可以对用户发起视频挑战(例如301)。例如，用户可能需要经由视频交谈来呈现他/她自身(例如302)。在一些实现方式中，客服代表(例如代理304b)可以使用用户的视频手动地确定用户的可靠性。在一些实现方式中，PT可以利用面孔、生物测定等识别(例如使用模式分类技术)以确定用户的身份(例如304a)。在一些实现方式中，应用可以提供参考标记(例如叉丝、目标框等)(例如303)，从而用户可以处理视频以促进用户的PT自动化识别。在一些实现方式中，用户可能尚未发起交易，例如，交易是欺骗的。在这些实现方式中，用户可以取消(例如305)挑战。PT可以然后取消交易，和/或代表用户发起欺骗调查过程。在一些实现方式中，PT可以利用文本挑战过程来验证用户的可靠性(例如306)。例如，PT可以经由文本交谈、SMS消息、电子邮件、Faeebook消息、Twitter推文等与用户通信。PT可以对用户提出挑战问题(例如308)。应用可以提供用户输入界面元件(例如虚拟键盘309)以回答PT提出的挑战问题。在一些实现方式中，PT可以自动地随机选择挑战问题；在一些实现方式中，客服代表可以手动地与用户通信。在一些实现方式中，用户可能尚未发起交易，例如，交易是欺骗的。在这些实现方式中，用户可以取消(例如307、310)文本挑战。PT可以然后取消交易，和/或代表用户发起欺骗调查过程。在一些实现方式中，应用可以被配置为识别产品标识符(例如条码、QR码等)。例如，为了欺骗防范，应用可以要求用户利用用户的设备来获得被购买的物品的快照，因此确保刷卡的人持有用户的设备以及购买物品。在一些实现方式中，可以要求用户登录应用以启用其特征。一旦启用，相机就可以对用户提供亲身拍摄的购买特征。例如，客户机设备可以具有经由其应用可以获取图像、视频数据、流送直播视频等的相机(例如313)。应用可以被配置为分析到来数据、并且搜索(例如311)产品标识符(例如314)。在一些实现方式中，应用可以上设叉丝、目标框等校准参考标记(例如315)，从而用户可以使用参考标记来对准产品标识符，从而促进产品标识符识别和解释。在一些实现方式中，应用可以包括界面元件以允许用户在产品识别模式与产品提供界面显示屏幕之间前后切换(例如316)，从而用户可以在捕获产品标识符之前精确地研究对于用户可用的交易。在一些实现方式中，应用可以向用户提供用于浏览先前产品标识符捕获的能力(见例如317)，从而用户能够更好地判断用户希望捕获哪个产品标识符。在一些实现方式中，用户可能希望取消产品购买；应用可以向用户提供用户界面元件(例如318)以取消产品标识符识别过程并且返回用户利用的先前界面屏幕。在一些实现方式中，可以通过列表形式(见例如319)向用户提供关于产品、用户设置、商家、供应物等的信息，从而用户可以更好地理解用户的购买选项。可以在应用中提供各种其它特征(见例如320)。在一些实现方式中，用户能够例如通过激活用户界面元件309浏览和/或修改用户简档和/或用户的设置(见图3A)。例如，用户能够浏览/修改用户名称(例如321a-b)、账户号(例如322a-b)、用户安全性访问码(例如323a-b)、用户pin(例如324a_b)、用户地址(例如325a-b)、与用户关联的社会安全性号(例如326a-b)、当前设备GPS位置(例如327a_b)、用户当前在其商店中的商家的用户账户(例如328a-b)、用户的奖励账户在其商店中的商家的用户账户(例如329a-b)等。在一些实现方式中，用户能够选择应发送数据字段及其关联值中的哪些以促进购买交易，因此对用户提供增强的数据安全性。例如，在图3C的示例说明中，用户已经选择了名称312a、账户号322a、安全性码323a、商家账户ID328a和奖励账户ID329a作为待发送的字段，作为通知的部分以处理购买交易。在一些实现方式中，用户可以切换作为通知的部分发送的字段和/或数据值以处理购买交易。在一些实现方式中，应用可以提供对于用户作为购买订单发送的一部分进行选择的存储的数据字段和/或关联值的多个屏幕。在一些实现方式中，应用可以向PT提供用户的GPS位置。基于用户的GPS位置，PT可以确定用户的情况(例如用户是否在商店、医生办公室、医院、邮政服务局等中)。基于该情况，用户应用可以将适当的字段呈现给用户，用户可以从其选择字段和/或字段值以作为购买订单发送的一部分进行发送。例如，用户可以进入医生的办公室并且希望针对医生的预约而支付联合支付(co-pay)。除了基本交易信息(例如账户号和名称)之外，应用还可以向用户提供用于选择转账可以被提供给医疗提供商、保险公司以及交易处理器的医疗记录、健康信息的能力，以协调多方之间的支付。在一些实现方式中，记录可以通过健康保险便携性和责任法案(HealthInsurancePortabilityandAccountabilityAct,HIPAA)一致数据格式而被发送并且加密，并且仅被授权浏览这些记录的接受者可以具有适当的解密密钥来解密并且浏览私人用户信息。图4示出说明在PT的一些实施例中在基于令牌的购买支付程序中用于登记的示例过程的数据流程图。在一些实现方式中，用户(例如401)可能希望从商家购买产品、服务、供应物等(“产品”)。用户可以经由客户机(例如，但不限于个人计算机、移动设备、电视、销售点终端、货摊、ATM等)(例如402)与商家服务器通信。例如，用户可以将指示用户对于购买产品的愿望的用户输入(例如购买输入411)提供给客户机。在各种实现方式中，用户输入可以包括，但不限于键盘输入、卡扫刷、激活启用RFID/NFC的硬件设备(例如具有多个账户的电子卡、智能电话、平板等)、鼠标点击、在操纵杆/游戏控制台上按下按钮、语音命令、在触摸敏感接口上的单个/多个触摸姿态、在触摸敏感显示器上触摸用户接口元件等。例如，用户可以将在客户机设备执行的浏览器应用导向到商家的网站，并且可以通过在经由网站对用户呈现的超链接上的点击而从网站选择产品。作为另一示例，客户机可以从用户的卡(例如信用卡、借记卡、预付费卡、充值卡等)获得跟踪I数据，例如以下提供的示例跟踪I数据％B123456789012345~PUBLIC/J.Q.'99011200000000000000**901*******(其中，“123456789012345”是J.Q.Public’的卡号，并且具有901的CVV号。“990112”是服务码，并且***表示每次使用卡时随机改变的十进制数字。)在一些实现方式中，客户机可以生成购买订单消息(例如412)，并且将生成的购买订单消息提供(例如413)给商家服务器。例如，在客户机上执行的浏览器应用可以代表用户提供根据可扩展标记语言(“XML”)格式化的数据的形式的包括用于商家服务器的产品订单细节的(安全)超文本传输协议(“HTTP(S)”)GET消息。以下是包括用于商家服务器的XML格式化购买订单消息的示例HTTP(S)GET消息GET/'purchase.phpHTTP/1.IIiost:wvn·,1,merchaηt.comContent-Type:Applicdtion-XMLContent-Length:1306<XMLversion=encoding=<purchase_order><order__ID>4nFU4RG94</order___ID><timestainp>20l,1-02-22I543<'timestamp><U5€；r_ID>john,q.pubiic^gma11·com<..user_ID><client__details><client_IP>iS2.I68.23.i2$</*cIient_IP><client_type>smartphone</cIient_type><.client_model>HTCHero^^ciient_model><05>/\ndroid2.KOS><app_instalied_flag>true<',app_installed_fleg></client_details><purchase_details><num_products>i</num_products><product>〈product·__type>bock<"prodi2ct__type><product_params><prcduct_titie>XMLfordummies</product_titie><lSEli>S'38-2-i4-i*$3^l0-0</lSBl]>_<edition>2nded.</edition><cover>ha.rcibonnd<..cover><seller>bestbuybooks</seiler></product_perams><quanti,ty>l<it:y></product></purchase_details><account_params><account_name>JoHnQ.Pmbiic</account_na.me><account_type>credir<account_type><account_nuni>I2345678012345<-'account_nurr,.><billingaddress>123GreenCt.·OK937$5</billirg_dddress><phone>123-456-7803</phore><sign>/jqp‘</sign><confirm_type>email<^confirir；_t.ype><contact_info>john.q.pubiicigmail·com<Icontact_info></account一para.ms><shi_pping_ir.fo><shlpping_adress>sameasbill<5hip__type>expedited<^ship_tTpe><ship_carrier>edE:%<-ship__carrIer><ship_account>i二3—45_5二8<..ship_accour·t><tracking_flag>true<trackxng_flag><8ign_fl,ag>falss<Iag></3hipping_xnfo><Ipurchase_order>在一些实现方式中，商家服务器可以从客户机获得购买订单消息，并且可以解析购买订单消息以从提取来自用户的购买订单的细节。基于解析，商家服务器可以确定购买订单消息未被令牌化(例如414)。在确定购买订单消息未被令牌化时，商家服务器可以确定用户需要被提供用于对支付令牌化服务注册的选项。商家服务器可以尝试识别令牌仲裁器以对用户提供支付令牌化服务。例如，商家服务器可以针对令牌仲裁器的地址询问(例如415)商家数据库(例如404)。例如，商家服务器可以利用包括结构化查询语言(“SQL”)命令的超文本预处理器(“PHP”)脚本来针对令牌仲裁器的地址询问关系数据库。用于针对令牌仲裁器地址询问数据库的示例PHP/SQL列表提供如下<FHPheader(*Content-Type:text/plain1);mysql_connect(tl254.93.X79-112"f^DBserveri$password；;·./accessdatabasesarvermysql_seleet_dbs'ARBITRATORS.SQL'”；//selectdatai>asetabletosearch//createqueryfortokenarfoitrators$query=''SELECTarbitrato^id,arbitators_namearfoitrator_addressarbitrator_TJRLFEOHToken!zationTableWHEREuser—card—numLIKE11*$IiserpajtrTnentcardnumber^;$result=mysql—quer*/;//performthesearchquerymyscjl—closefwARBITRATORGiSQIZi)7//closedatabaseaccess>—响应于此，商家数据库可以提供令牌仲裁器地址(例如416)。商家服务器可以生成代表用户的令牌化邀请请求(例如417)，并且将令牌化邀请请求提供给令牌服务器(例如405)。例如，商家服务器可以提供与如下示例相似的包括令牌化邀请请求的HTTP(S)POST消息POGT/in^iterequest,phpHTTP/I.IHost:www.tokenizer.comContent-Type:Application/XMLContent-Length:579<XMLversion=Hencoding-xxUTT-Bft><invitation__.request><timestamp>2011-02-2215:22;43</timestamp><user_ID>john.q.pnblic0gmail■com</user_ID><client_details><client___IF>l92*168.23,126</cIient___IP><client_type>smartphone</client_type><client_mode1>HTCHero</cIient_modeI><0S>Android2·2</0S><app_installed_flag>true</app_installed_flag></client—details〉<merchant__param5><merchant_id>3FBCR4IITC</merchant_id><merchant_name>Books&Things,Inc.</merchant_name><merchant_a_uth—key>lIIiF484WCP55CHB27365</merchant_auth*key></merchant_params></invitation_request>在一些实现方式中，令牌服务器可以解析邀请请求消息，并且从该消息提取用户和客户机的细节。令牌服务器可以生成(例如419)用于用户的令牌化邀请和应用表格以完成对令牌化服务的注册。令牌服务器可以将令牌化邀请和应用表格提供(例如420)给客户机(直接提供给客户机或经由商家服务器)。例如，令牌服务器可以提供包括代表应用表格的XML数据的HTTP(S)POST消息，例如以下示例HTTP(S)POST消息权利要求1.一种支付令牌仲裁处理器实现的方法，包括从商家获得用于处理来自用户的购买订单的包括独特源中立通用可分解支付令牌信息的令牌仲裁请求；使用所述支付令牌信息针对关于发放方的发放方信息询问令牌数据库；基于对所述令牌数据库的询问获得所述发放方信息；使用所述发放方信息以及从所述令牌仲裁请求提取的数据经由处理器来生成购买授权请求；以及将所生成的购买授权请求提供给所述发放方。2.如权利要求I所述的方法，还包括基于所述发放方信息确定应针对支付选项询问所述用户；生成对所述用户的支付选项请求；以及将所述支付选项请求提供给所述用户的移动设备。3.如权利要求2所述的方法，还包括从所述用户的移动设备获得对所述支付选项请求的响应；从所述响应提取所述支付选项；基于用于处理来自所述用户的购买订单的待联系的发放方的预定的设置和所述支付选项生成对多个发放方的购买授权请求；以及提供所生成的对所述多个发放方的购买授权请求。4.如权利要求3所述的方法，其中，所述发放方信息包括用于处理来自用户的购买订单的用于待联系的发放方的预定的设置。5.如权利要求2所述的方法，还包括将对用户认证的请求提供给所述用户的移动设备；从所述移动设备获得对关于用户认证的请求的响应；基于对关于用户认证的请求的响应，确定所述用户被认证以利用用于所述购买订单的支付令牌信息；以及在确定所述用户被认证以利用用于所述购买订单的支付令牌信息之后，生成所述购买授权请求。6.如权利要求2所述的方法，还包括从所述用户的移动设备获得对所述支付选项请求的响应；从所述响应提取所述支付选项；生成用于处理来自所述用户的购买订单的用于待联系的发放方的更新的预定的设置；以及存储用于处理来自所述用户的购买订单的用于待联系的发放方的更新的预定的设置。7.如权利要求I所述的方法，其中，使用用于处理来自所述用户的购买订单的关于待联系的发放方的发放方信息中包括的预定的设置来生成所述购买授权请求。8.一种支付令牌仲裁装置，包括用于从商家获得用于处理来自用户的购买订单的包括独特源中立通用可分解支付令牌信息的令牌仲裁请求的装置；用于使用所述支付令牌信息针对关于发放方的发放方信息询问令牌数据库的装置；用于基于对所述令牌数据库的询问获得所述发放方信息的装置；用于使用所述发放方信息以及从所述令牌仲裁请求提取的数据来生成购买授权请求的装置；以及用于将所生成的购买授权请求提供给所述发放方的装置。9.如权利要求9所述的装置，还包括用于基于所述发放方信息而确定应针对支付选项询问所述用户的装置；用于生成对所述用户的支付选项请求的装置；以及用于将所述支付选项请求提供给所述用户的移动设备的装置。10.如权利要求9所述的装置，还包括用于从所述用户的移动设备获得对所述支付选项请求的响应的装置；用于从所述响应提取所述支付选项的装置；用于基于用于处理来自所述用户的购买订单的用于待联系的发放方的预定的设置和所述支付选项生成对多个发放方的购买授权请求的装置；以及用于提供所生成的对所述多个发放方的购买授权请求的装置。11.如权利要求3所述的装置，其中，所述发放方信息包括用于处理来自用户的购买订单的用于待联系的发放方的预定的设置。12.如权利要求9所述的装置，还包括用于将对用户认证的请求提供给所述用户的移动设备的装置；用于从所述移动设备获得对于关于用户认证的请求的响应的装置；用于基于对于关于用户认证的请求的响应确定所述用户被认证以利用用于所述购买订单的支付令牌信息的装置；以及用于在确定所述用户被认证以利用用于所述购买订单的支付令牌信息之后生成所述购买授权请求的装置。13.如权利要求9所述的装置，还包括用于从所述用户的移动设备获得对所述支付选项请求的响应的装置；用于从所述响应提取所述支付选项的装置；用于生成用于处理来自所述用户的购买订单的用于待联系的发放方的更新的预定的设置的装置；以及用于存储用于处理来自所述用户的购买订单的用于待联系的发放方的更新的预定的设置的装置。14.如权利要求8所述的装置，其中，使用用于处理来自所述用户的购买订单的关于待联系的发放方的发放方信息中包括的预定的设置来生成所述购买授权请求。15.—种支付令牌仲裁系统,包括处理器；以及存储器，与处理通信地布置，并且存储处理器可执行指令，用于从商家获得用于处理来自用户的购买订单的包括独特源中立通用可分解支付令牌信息的令牌仲裁请求；使用所述支付令牌信息针对关于发放方的发放方信息询问令牌数据库；基于对所述令牌数据库的询问获得所述发放方信息；使用所述发放方信息以及从所述令牌仲裁请求提取的数据生成购买授权请求；以及将所生成的购买授权请求提供给所述发放方。16.如权利要求15所述的系统，所述存储器还存储用于以下操作的指令基于所述发放方信息确定应针对支付选项询问所述用户；生成对所述用户的支付选项请求；以及将所述支付选项请求提供给所述用户的移动设备。17.如权利要求16所述的系统，所述存储器还存储用于以下操作的指令从所述用户的所述移动设备获得对所述支付选项请求的响应；从所述响应提取所述支付选项；基于用于处理来自所述用户的购买订单的用于待联系的发放方的预定的设置和所述支付选项生成对多个发放方的购买授权请求；以及提供所生成的对所述多个发放方的购买授权请求。18.如权利要求17所述的系统，其中，所述发放方信息包括用于处理来自用户的购买订单的用于待联系的发放方的预定的设置。19.如权利要求16所述的系统，所述存储器还存储用于以下操作的指令将对用户认证的请求提供给所述用户的移动设备；从所述移动设备获得对于关于用户认证的请求的响应；基于对于关于用户认证的请求的响应确定所述用户被认证以利用用于所述购买订单的支付令牌信息；以及在确定所述用户被认证以利用用于所述购买订单的支付令牌信息之后，生成所述购买授权请求。20.如权利要求16所述的系统，所述存储器还存储用于以下操作的指令从所述用户的移动设备获得对所述支付选项请求的响应；从所述响应提取所述支付选项；生成用于处理来自所述用户的购买订单的用于待联系的发放方的更新的预定的设置；以及存储用于处理来自所述用户的购买订单的用于待联系的发放方的更新的预定的设置。21.如权利要求15所述的系统，其中，使用用于处理来自所述用户的所述购买订单的关于待联系的发放方的发放方信息中包括的预定的设置来生成所述购买授权请求。22.—种存储用于以下操作的处理器可执行支付令牌仲裁指令的处理器可读有形介质从商家获得用于处理来自用户的购买订单的包括支付令牌信息的令牌仲裁请求；使用所述支付令牌信息针对关于发放方的发放方信息询问令牌数据库；基于对所述令牌数据库的询问而获得所述发放方信息；使用所述发放方信息以及从所述令牌仲裁请求提取的数据生成购买授权请求；以及将所生成的购买授权请求提供给所述发放方。23.如权利要求22所述的介质，还存储用于以下操作的指令基于所述发放方信息确定应针对支付选项询问所述用户；生成对所述用户的支付选项请求；以及将所述支付选项请求提供给所述用户的移动设备。24.如权利要求23所述的介质，还存储用于以下操作的指令从所述用户的移动设备获得对所述支付选项请求的响应；从所述响应提取所述支付选项；基于用于处理来自所述用户的购买订单的用于待联系的发放方的预定的设置和所述支付选项生成对多个发放方的购买授权请求；以及提供所生成的对所述多个发放方的购买授权请求。25.如权利要求24所述的介质，其中，所述发放方信息包括用于处理来自用户的购买订单的用于待联系的发放方的所述预定的设置。26.如权利要求23所述的介质，还存储用于以下操作的指令将对用户认证的请求提供给所述用户的移动设备；从所述移动设备获得对于关于用户认证的请求的响应；基于对于关于用户认证的请求的响应确定所述用户被认证以利用用于所述购买订单的支付令牌信息；以及在确定所述用户被认证以利用用于所述购买订单的支付令牌信息之后，生成所述购买授权请求。27.如权利要求23所述的介质，还存储用于以下操作的指令从所述用户的移动设备获得对所述支付选项请求的响应；从所述响应提取所述支付选项；生成用于处理来自所述用户的购买订单的用于待联系的发放方的更新的预定的设置；以及存储用于处理来自所述用户的所述购买订单的用于待联系的发放方的更新的预定的设置。28.如权利要求22所述的介质，其中，使用用于处理来自所述用户的所述购买订单的关于待联系的发放方的发放方信息中包括的预定的设置来生成所述购买授权请求。全文摘要支付令牌化装置、方法和系统(“PT”)经由PT组件将基于支付令牌的购买订单变换为多个发放方的购买支付资金转移。在一个实施例中，PT从商家获得用于处理购买订单的包括独特源中立通用可分解支付令牌信息的令牌仲裁请求。PT使用所述支付令牌信息针对发放方信息来询问令牌数据库，并且获得所述发放方信息。PT还基于所述发放方信息确定应针对支付选项而询问所述用户，生成支付选项请求，并且将所述支付选项请求提供给用户的移动设备。在从所述移动设备获得对所述支付选项请求的响应时，所述PT基于支付选项以及用于待联系的发放方的预定的设置而生成用于处理所述购买订单的购买授权请求，并且将所生成的购买授权请求提供给所述发放方。文档编号G06Q20/40GK102939613SQ201180015012公开日2013年2月20日申请日期2011年6月3日优先权日2010年6月4日发明者J·弗恩特,M·迪尔,G·特瑞菲勒蒂,P·隋瑞,A·哈麦德申请人:维萨国际服务协会