CN1989520A - 交易处理方法、设备以及*** - Google Patents
交易处理方法、设备以及*** Download PDFInfo
- Publication number
- CN1989520A CN1989520A CNA2005800251668A CN200580025166A CN1989520A CN 1989520 A CN1989520 A CN 1989520A CN A2005800251668 A CNA2005800251668 A CN A2005800251668A CN 200580025166 A CN200580025166 A CN 200580025166A CN 1989520 A CN1989520 A CN 1989520A
- Authority
- CN
- China
- Prior art keywords
- payer
- payment
- electronic equipment
- equipment
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本发明提供了一种交易处理方法、设备以及***。本发明涉及用于对支付人(通常是个别支付人)与受付人(通常是商家)之间的支付进行处理的交易处理。支付交易通常涉及例如通过在商家的刷卡设备中刷卡而将用户的帐户详细信息提供给商家设备。然后,商家设备准备包括诸如用户的帐户ID、商家ID和支付信息之类的信息的交易消息,并将该消息转发给可能包括收单行和发卡银行的交易处理***。交易处理***批准支付并将确认返回给商家。在本发明中,与受付人相关联的设备(在优选实施例中是经适当改装的移动电话)涉及了支付交易处理。一方面,交易处理***向支付人电子设备请求应该进行交易的确认,并且支付人键入正确的PIN,以授权交易。另一方面,所有交易处理信息都从支付人电子设备提供到交易处理***,然后,交易处理***或支付人电子设备确认将交易授权给商家设备。这减轻了商家进行交易处理的负担并且由于支付人参与了控制所以还增强了交易的安全性。在另一实施例中,支付人电子设备还可上载产品的列表并选择产品,同时为产品进行支付,所选产品被通知给受付人(商家)。
Description
技术领域
本发明总体上涉及交易处理方法和***,更具体地但不排它地涉及用于方便支付人(其可以是普通公众的成员)与受付人(其通常是商家)之间在销售点或在线支付的交易处理***。
背景技术
对产品或服务的支付通常以电子方式进行。例如,可利用***或签帐卡进行支付,诸如银行的金融机构可以在支付人已授权转帐之后直接或者通过一个或多个中介机构启动向受付人的帐户的支付转帐。转帐授权例如可以包括向受付人提供***或签帐卡并在***上签字。然后,受付人对支付人在***上的签名与卡上的签名进行比较,如果他感到满意,则接受支付的授权。
已提出许多其他方法来让支付人“签署”交易,以对支付进行核实,例如包括使用安全pin码。
然而,仍存在需要考虑的大量安全风险。例如,使用***或签帐卡的支付通常要求把卡短期地交给受付人直到开出***并签署***为止。磁条卡容易在相对廉价的设备上进行复制,并且复制的卡可用来进行欺诈***易。涉及互联网的电子支付***存在安全问题。通常需要一种提供改进的安全性和便利性的支付***。
另外,常规上与处理支付交易相关联的一般范例是在受付人或商家设备与交易处理***(通常是收单行和一个或更多个发卡银行)之间处理交易处理通信(包括支付信息的消息,例如支付人的帐户ID、商家ID、交易额等)。支付人除了提供其帐户详细信息(如上所述,然后这些详细信息被公开,从而被用于欺诈性用途)之外很少理会交易处理。还没有人提出可替代常规商家设备/交易处理***构造的***。
发明内容
根据第一方面,本发明提供了一种进行支付的方法,该方法包括以下步骤:
提供与支付人相关联的信息,以受付人可访问该信息的方式来提供该信息,
通过与支付人相关联的支付人电子设备来接收与支付有关的信息,以及
利用与支付人相关联的所述电子设备来给出进行支付的指令。
如今,公众成员通常持有一个或更多个电子设备。例如,移动电话是普遍存在的。在一个实施例中,所述方法包括利用与支付人相关联的这种普遍存在的电子设备来给出进行支付的指令。电子设备可以是专用的支付人电子设备或者可以是经改装的移动电话。
因此,每个支付人都可以持有与他们相关联的电子设备,他们能够使用该电子设备来提供进行支付的指令。在一个实施例中,进行支付的指令可以仅仅是针对交易处理***的应该继续进行支付的确认。然而,这增加了当前交易所缺乏的额外安全层(要求来自与支付人相关联的电子设备的信息)。
支付可以是出示卡(card-present)的支付,例如所述支付人亲赴销售点(“POS”)。交易可以是非出示卡的支付,例如互联网支付。在支付是在线支付的情况下(例如互联网支付),电子设备不是支付人用来访问商家网站的计算机,而是单独的电子设备。
在一个实施例中,(例如,通过包括适当的软件应用)将支付人电子设备设置为可识别支付信息。在一个实施例中,可以使用以类似于本交易处理软件的方式来实现支付信息识别的软件,使得支付人电子设备可以表达包括支付信息在内的消息,并将这些消息发送到交易***(例如,由收单行和发卡银行来使用)。
在一个实施例中,支付人电子设备可以包括安全措施,以增加处理的安全性。这些安全措施可以包括发送数字签名作为所述确认,在一个实施例中,支付人电子设备可能需要用户在键盘上输入诸如PIN的消息。在一个实施例中,固件可能需要响应于出现在该设备的显示器上的支付信息而输入PIN,以防止黑客在支付人不知情的情况下利用支付应用。
在一个实施例中,与支付有关的信息可以包括产品信息,该产品信息为包括至少一个产品标识符的列表的形式。这种情况下,所述方法还包括支付人电子设备选择至少一个产品标识符的步骤,并且与支付人相关联的信息包括所选择的产品标识符。在一个实施例中,可以为支付人电子设备提供包括多个产品标识符的列表,然后支付人可以从该列表中进行选择。将该选择提供给受付人电子设备,因此,受付人可以将产品提供给支付人。
受付人收到产品“定单”,同时该定单可能已经支付,这是非常有利的。这使得用户可以同时购买和支付。
在一个实施例中,支付人电子设备可以从受付人电子设备获得交易处理所需的所有支付信息,然后可以利用处理***来直接处理所述交易处理。这减少了商家进行交易处理的负担,并且使得个体支付人能够对处理进行充分的控制,而不需要他们例如将他们的***详细信息交付给商家。相反,支付人电子设备向交易处理***提供帐户详细信息。
根据第二方面,本发明提供了一种处理支付交易的方法,该方法包括以下步骤:交易处理***从与支付人相关联的支付人电子设备接收进行支付的指令;交易处理***授权支付;以及交易处理***提供已授权支付转帐的确认。
根据第三方面,本发明提供了一种便于从支付人到受付人进行支付交易的设备(apparatus),所述设备包括与支付人相关联的支付人电子设备,所述支付人电子设备包括:用于接收与支付有关的信息的支付信息接收装置;和用于给出进行支付的指令的支付指令发出装置。
根据第四方面,本发明提供了一种用于处理支付交易的交易处理***,所述***包括:支付指令接收装置,被构造用于从与支付人相关联的支付人电子设备接收从支付人向受付人进行支付的指令;以及支付处理装置,用于授权从支付人帐户到受付人帐户的资金转帐。
根据第五方面,本发明提供了一种便于处理交易的设备,所述设备包括被构造用于与根据第四方面的交易处理***进行通信的受付人电子设备。
根据第六方面,本发明提供了一种数据库,该数据库包括支付人电子设备可得到的多个产品列表,由此,支付人电子设备可以从这些产品列表中选择一个或更多个产品,以发送给受付人来满足其产品需求。
根据第七方面,本发明提供了一种无源设备,该无源设备被构造为可由支付人电子设备读取,以便于支付交易。
根据第八方面,本发明提供了一种无源设备,该无源设备包括用于标识应用的信息,使得电子设备可以使用该信息来处理与所述无源设备相关联的信息。
根据第九方面,本发明提供了一种启动软件应用的方法,所述方法包括以下步骤:利用包括以下信息的无源设备,该信息标识了所述软件应用的位置;将该信息上载到用户设备;以及利用该用户设备从远程位置获得所述应用。
根据第十方面,本发明提供一种了组织队列的方法,所述方法包括以下步骤:向用户移动电话提供信息,该信息表示了用户在所述队列中的位置;以及随着所述用户在所述队列中位置的移动而更新所述信息。
附图说明
参照附图,根据以下仅通过示例方式对本发明实施例的说明,本发明的特点和优点将变得明了,附图中:
图1是根据本发明实施例的一般支付方法和***的示意性框图;
图2是更详细地示出根据本发明实施例的支付***的示意性框图;
图3是示出图2的支付***的一个可能操作的流程图;
图4是示出利用本发明实施例的支付***的框图;
图5是示出利用图4的***的一个操作处理的流程图;
图6是例示根据本发明另一个实施例的***的操作的框图;
图7是例示图6的***的一个可能操作的流程图;
图8是例示根据本发明另一个实施例的支付***的操作的框图;
图9是示出图8的***的一个可能操作的流程图;
图10是示出根据本发明另一个实施例的支付***的操作的框图;
图11是例示图10的***的一个可能操作的流程图;
图12是示出根据本发明另一个实施例的***的操作的框图;
图13是示出图12的***的一个可能操作的流程图;
图14是示出根据本发明另一个实施例的***的操作的框图;
图15是示出图14的***的操作的一个可能处理的流程图;
图16是出现在图14的***中的支付人电子设备上的“菜单”的示例视图;
图17是示出根据本发明另一个实施例的处理的流程图;
图18是示出根据本发明另一个实施例的***的应用的框图;
图19是示出可能包括在根据本发明实施例的交易处理***中的部件的更详细的框图;而
图20是根据本发明实施例的支付人电子设备的框图。
具体实施方式
图1是可用于实现本发明不同实施例的设备的“概要”视图。常规支付交易通常仅需要与受付人相关联的电子设备(“商家设备”)和交易处理***(其通常可以包括收单行/网关和金融机构)来处理支付,与之不同,本发明的实施例还需要在交易处理中包括另一整体(与支付人相关联的电子设备)。
在常规***中,商家设备通常通过刷磁卡(或从智能卡获得信息)来从支付人获得帐户标识数据。然后,商家设备准备包含所有支付信息(例如,商家ID、支付帐户、商家帐户、支付人的帐户ID等)的消息并将该消息发送给交易处理***。然后,交易处理***可以检查支付人的帐户,以确保可得到足够的资金进行交易(取决于是否存在与帐户相关联的免授权交易金额(floor limit)),并且将批准交易或拒绝交易的判定返回到商家设备。如果接收到交易授权(批准),则商家(受付人)可确信交易将继续进行。
该常规处理存在上述所有安全问题,还需要每个受付人都利用与支付处理***相关联的基础设施。
根据本发明的实施例,交易处理***2进行从支付人到受付人的支付交易需要与支付人相关联的支付人电子设备1。在根据图1的实施例中,与支付人相关联的信息3将被提供给受付人电子设备4。如稍后在说明书中将看到的,信息3可以包括不同要素(element)。例如,它可以包括支付人的帐户详细信息或仅包括已授权支付人与受付人之间进行交易的确认。
然而,在不包括支付人电子设备1的情况下,将不授权交易。这增加了额外的安全层,在一些实施例(待描述)中,极大地方便了交易所涉及的支付人和受付人。在一些实施例中,可以消除对支付交易处理中要涉及的受付人的需求。相反,支付人变为启动和处理支付交易的主要渠道。这是对商家负责交易的常规范例的改变(shift)。实施例使支付人能够保留他们的所有帐户详细信息,使得他们无需经过商家并且不损害安全性。
本发明的实施例实现了包括支付人电子设备1的许多层面的混合。在一个层面上,支付人电子设备只提供应该继续进行支付的确认,否则,交易基本上通过受付人电子设备和交易处理***按照常规的方式被处理。
在另一层面上,支付人电子设备启动支付处理,并且处理与交易处理***发送消息的交易。在该实施例中,受付人电子设备可以只接收支付已发生的确认,所有处理都通过支付人电子设备进行。
在混合的另一层面上,可以提供一种装置,其中支付人电子设备可以通过交易处理***来选择产品,并且支付该产品。
在一个实施例中(第一层面),与支付人相关联的信息可以是由装置3提供的帐户信息,装置3用于提供诸如通行卡、***、帐户卡或智能卡的信息。与受付人相关联的受付人电子设备4(例如读卡设备)从卡3读取信息并将与支付有关的信息发送给交易处理***2。稍后将更详细地描述交易处理***2,但其通常包括交易网关或收单行,还可以包括诸如发卡银行的发卡金融机构。这是标准的构造,其中交易网关接收处理信息并且与支付人能够支付的发卡银行进行核对。在该实施例中,交易处理***2随后与支付人电子设备1进行通信,以从支付人电子设备1获得应该继续进行支付的确认。
该实施例中的支付人电子设备1是经改装的移动电话,稍后在说明书中将对其进行更详细的描述。支付人电子设备1向交易处理***2发送确认,然后交易处理***2向受付人电子设备4发送支付授权。
图2示出了不同层面实施例的表示,其包括经改装的移动电话形式的支付人电子设备1、带有刷卡器10的常规读卡器形式的受付人电子设备4、显示器11和键盘12。交易处理***仍由块2来表示。支付人持有卡3(可以是***)。现在将参照图3的流程图来描述根据图2的实施例的交易处理。
在步骤13,在受付人设备刷卡器10中刷支付人卡3。在以下说明中,应该注意,“受付人设备”将被称为“商家设备”或“MD”。
在步骤14,从MD 4向交易处理***“TPS”2发送交易消息。交易消息可以包括进行交易处理常规上所包括的所有信息,例如***详细信息、支付帐户。
在步骤15,TPS 2向支付人设备(“PD”)1发送用于确认应该继续进行支付的请求(“确认请求”)。
在步骤16,支付人利用PD 1的键盘20按下确认键。然后,PD 1向TPS 2发送确认。
在步骤17,TPS 2向MD 4发送交易授权。
在处理中包括支付人电子设备1的优点是为交易提供了另外的安全性。支付人不仅需要他的***,而且需要访问他的经改装的移动电话,才能使交易继续进行。支付人可能需要键入诸如PIN的安全码,交易处理***可将其与存储在数据库中的PIN进行比较。
欺诈者要访问用户的***、其移动电话,还要知道PIN,以使欺诈交易向前进行,这是不大可能的。
可以实施其他安全措施。在一个实施例中,可以在交易处理***与PD 1之间使用数字签名安全构造。
在另一实施例中,为了确保支付交易向前进行,可以在PD 1中使用固件来确保支付人必须激活输入装置(键盘20)。这样就避免了黑客能够远程操作电话从而在PD 1的拥有者不知情的情况下批准支付交易。对于该固件而言,黑客不能改变该固件,并且要求支付人1通过键盘20键入确认。固件1还可被构造为要求支付信息出现在PD 1的显示器21上,因而,例如支付人可以在键入确认之前浏览诸如支付金额的支付信息。
在图3所示处理的变型例中,取而代之或除TPS 2向MD 4发送交易授权(步骤17)之外,在步骤17A,TPS 2向PD 1发送交易授权。然后,例如,支付人向受付人出示授权(授权出现在PD 1的屏幕上)。在一个实施例中,授权详细信息可以按编码形式(该编码形式可由可设置有MD 4的适当读取器识别)提供在PD 1的屏幕21上。图2中未示出读取器,但读取器可设置在MD 4上。例如,编码可以是出现在屏幕21上的要由MD 4上的适当条形码读取器来读取的条形码。
还可以向PD 1发送支付用的收据,PD 1可以具有用于存储交易收据并由此进行记帐的应用。
使用与支付人相关联的电子装置来确认应该继续进行支付交易的能力也可应用于在线交易(以及上述销售点(POS)类型的交易)。
参照图4,典型的在线交易包括支付人经由互联网25并利用诸如PC26的计算机访问由商家服务器28提供的商家网站27。选择产品后,支付人输入其***详细信息。然后,商家服务器28继续处理该支付交易。众所周知,该处理易受欺骗。
根据本发明的实施例,与支付人相关联的PD 1可用于增强安全性。现在将参照图5来描述根据该实施例而执行的交易处理。
在步骤29,支付人从商家网站27选择商品并在商家网站27上输入其帐户详细信息(通常是******)。
在步骤30,从商家服务器28向TPS 2发送常用交易消息。
根据该实施例,TPS 2随后向PD 1发送确认应该继续进行支付的请求。支付人在其PD 1上键入确认(步骤32),PD 1将该确认发送给TPS2。
然后,TPS 2向商家服务器28发送交易授权(步骤33)。
TPS可以具有数据库,该数据库存储有使得能够与支付人电子设备进行通信的信息(例如,移动电话号码)。
上述实施例一般涉及支付人电子设备,其用于通过要求来自支付人电子设备的对应该继续进行支付交易的确认,来提供另外的安全层。支付人电子设备还可用于接收交易授权和收据,但实际上,交易处理是常规的,并且大多数消息的发送出现在受付人电子设备与交易处理***之间。在以下实施例中,支付人电子设备可以承担更多的交易处理,这通常会带来交易处理的操作便利的提高。
参照图2,PD 1设置有一些可实现本地通信的装置35。用于实现本地通信的装置35包括“访问设备”,并且可以包括设置在移动电话内(或许附接于移动电话)的非接触智能卡。受付人电子设备4设置有适当的读取器36。访问设备35在接触到读取器36时或与读取器36非常接近时,被设置为向MD 4提供使MD 4能够随后与PD 1进行通信的信息。例如,标识信息可以是电话号码,从而MD 4可使用移动电话网络与PD 1接触。作为另一种选择,可以使用本地无线网络(例如BluetoothTM)在PD 1与MD 4之间进行通信。因此,MD 4可向PD 1发送与支付有关的信息。这可使PD 1能够在交易过程中扮演更积极的角色。
在一个实施例中,MD 4可以向PD 1发送支付金额。然后,支付人1可改变(出现在屏幕21上的)支付金额并将改变后的支付金额传送回MD 4用于后续的交易处理。例如,这种实施例在“小费”情况下会非常有用。例如,在饭店内,支付人可利用PD 1输入他们的小费,这将防止在现金支付传票上手工输入小费时可能发生的任何欺诈操作。剩余的交易处理可以按照上述实施例中所描述的通过PD 1所要求的确认来进行。
图7是示出可利用图6的实施例来实现的支付处理的流程图。
在步骤38,在MD 4的读卡器10中刷支付人卡3。
在步骤39,从MD 4向TPS 2发送交易消息和交易信息。然后,PD1经由访问设备35和读取器36向MD 4发送无线通信信息,以实现MD4与PD 1之间的无线通信(步骤40)。
在步骤41,MD 4无线地向PD 1发送“支付请求”。支付请求可以包括支付信息,例如支付金额。应该注意的是,如果给予支付人改变支付信息(会改变支付金额)的选择权,则MD 4可以在向TPS发送交易消息之前等待来自PD 1的答复(即,步骤39将沿流程图进一步向下进行)。
在步骤42,响应于来自MD 4的支付请求(并且在输入了任何进一步信息,如支付金额的改变,之后),PD 1向TPS 2发送应该继续进行交易的确认。
在步骤43,TPS 2随后向MD 4发送交易授权,使受付人知道交易可继续进行。作为另一种选择,TPS 2在步骤43A向PD 1发送交易授权,(并且在43B),PD 1向MD 4无线地发送授权。
应该注意的是,可以不需要单独的访问设备(例如智能卡35),相反访问设备例如可并入到适当构造的PD 1和MD 4中,以允许直接的无线通信。
在图6和图7的实施例中,支付人仍在受付人设备中刷卡,并且商家设备仍处理交易处理的绝大部分。图8例示了其中要进行交易,支付人除了支付人设备1之外无需任何卡或设备的实施例。
可以仍然设置访问设备35和读取器36(或者,如上所述,设备1和4可被适当地构造为以某种其他方式对近程通信进行初始化)。在该实施例中,PD 1还包括使其能够表达交易处理中所用的交易消息的应用(可以实现为软件)。
参照图9,为了承担支付交易,PD 1和MD 4彼此建立通信。然后,在步骤45,MD 4无线地向PD 1发送支付信息,该支付信息包括处理支付所需的信息,例如商家ID和支付金额。
在步骤46,从PD 1向TPS 2发送交易消息,从而可以识别支付人帐户,该交易消息包括交易处理所需的常用信息,例如商家ID、支付金额和支付人的身份。同时,交易消息可以包括应该继续进行交易的确认。
在步骤47,TPS 1可以向MD 4发送交易授权。作为另一种选择,在步骤47A,PD 1可以接收从TPS 2传送来的交易授权,在步骤47B,PD 1无线地向MD 4发送授权。
应该理解的是,如果选择了路径47A和47B,则不需要具有与TPS 2进行通信能力的商家设备。因此,可以提供只具有用于和受付人电子设备(例如无线地)进行通信的本地通信设备的受付人电子设备,支付人电子设备随后进行大量的交易处理通信。这种构造的主要优点是,支付人的帐户详细信息(例如***详细信息)可以不需要经过商家设备。此外,从方便和安全的角度来讲,支付人对交易拥有完全的控制。如结合上述实施例所述,支付信息可以出现在屏幕21上,从而支付人可以浏览该信息,通过键盘输入20来改变信息(例如改变小费)等。支付人拥有完全的控制。
应该注意的是,在该实施例的变型例中,所有通信都可经过MD 4。即,可由PD 1准备支付消息,然后将其本地无线地发送至MD 4,以便随后传递到交易处理***。这是欠安全的选择,因为所有支付人信息都将经过商家设备。然而,这在某些情况下可能是方便的(例如,在PD与交易处理***2之间存在通信困难时)。
支付人的帐户ID可以按加密形式与数字签名一起发送。可应用任何保密措施。在一个实施例中,交易处理***2保存有“***”帐号的数据库。即,帐号的一部分由TPS 2数据库保存,该帐号的其他部分由支付人设备1保存。因此,黑客不能通过侵入PD 1而获得所有帐户ID。
在另外的选择中,商家设备4可包括4A和4B两部分(图8)。4A部分可以是移动设备,例如可由操作员(如饭店的侍者)携带。4B部分可以是受付人电子设备。侍者可使设备4A靠近PD 1以获得通信详细信息(例如,初始化通信),从而PD 1能够随后与4B部分进行通信,例如使PD 1能够上载交易详细信息,然后继续交易处理。
设备4A可以向设备4B的其他部分提供接触详细信息。设备4A实际上可以是无源设备,其可由来自PD 1的电力来供电。在饭店情况下,例如,4A部分能够提供诸如饭店中的餐桌号的信息,使得在随后与4B部分(其可以是电子现金抽屉)的通信中,支付人可被识别为坐在饭店中特定桌位上的人,因此,可由4B部分计算并生成支付人的帐单,然后发送到与该支付人相关联的PD 1。
两部分商家设备4可采取任意方便的构造。为了获得支付信息,4A部分仅需要提供使支付人设备1能够接触(通常更复杂的)4B部分的信息。
图10例示了其中PD 1能够应对在线支付的交易处理的***。图10中使用与图4中所用相同的标号来表示类似的部件。
在该实施例中,PD 1包括用于为交易处理准备交易消息的应用。
参照图11,在步骤50,支付人经由PC 26和互联网25从商家网站27上选择产品。
在步骤51,PD 1上载支付信息,该支付信息包括商家ID和支付金额(以及使交易处理向前继续可能需要的任何其他信息)。上载可以通过与PC 26的有线或无线通信来进行。作为另一种选择,当选择了产品27时,支付人可向商家服务器28提供PD 1的接触详细信息,然后,商家服务器28可(例如,通过移动电话通信网络)将支付信息发送到PD 1。在此外的另一种选择中,可省去PC 26,而PD 1(其可以是经改装的可上网移动电话)直接访问网站27,并上载支付信息。
在步骤52,由PD 1准备交易消息并与交易确认和帐户ID一起发送到TPS。
在步骤53,TPS 2向商家服务器发送交易授权。随后,可为PD 1产生收据(并且其可从商家服务器发送到PD 1)。
上述的加密和其他安全措施可应用在该实施例中。该实施例的主要优点是无需将帐户详细信息(例如***详细信息)放置在网络(例如互联网)上。
图12例示了本发明的另一个实施例。在该实施例中,支付人电子设备1包括被构造用于从无源设备56读取支付信息的读取装置55。在所例示的实施例中,读取装置55是相机55(目前移动电话一般都设置有相机)。然而,读取装置可以是任何其他方便的读取装置,如条形码扫描仪。在该实施例中,相机55与应用软件一起使用,使移动电话能够检测到来自相机的无源设备图像和处理由无源设备提供的信息。
此外,无源设备56不必是条形码,而可以是能够读取以提供支付信息(例如RF)的任何无源设备。
在一个实施例中,由无源设备提供的支付信息可以是商家ID,使PD1能够随后与如图8的实施例中的商家设备4进行通信。然后,除了经由无源设备和PD 1中的读取装置55获得来自MD 4的支付信息之外,处理随后可以沿图9的处理线路继续进行。例如,无源设备可以是饭店中的桌上的条形码。
在更复杂的层面上,无源设备可以提供使PD 1能够继续进行并且启动支付交易的支付信息。例如,无源设备56可包括使带有适当的软件应用的PD 1为交易处理***2准备交易信息所需的足够信息。
现在将与图13相关地描述图12的***的操作。
在步骤58,PD 1从无源设备56获得支付信息。在图12的实施例中,支付人利用他的相机55给条形码56拍照,PD 1上的应用识别条形码并获得支付信息。
另外,在图12的实施例中,条形码56设置有帐单57,帐单57例如可以是饭店帐单。条形码56上的信息包括处理支付商家(例如,饭店的所有者)的交易所需的所有信息。即,这些信息将包括商家ID、支付金额和准备交易消息所需的任何其他信息。
在步骤59,由PD 1准备交易消息并与交易确认和支付人的帐户ID一起发送到TPS 2。
在步骤60,TPS 2与MD 70进行通信并向MD 70提供交易授权。作为另一种选择,与上述实施例相同,TPS 60A可通知PD 1交易授权,然后60B处的PD向MD 70发送交易授权。MD 70可产生收据71并且/或者向PD 1发送电子收据。作为另一种选择,交易处理***2可从MD 17接收电子收据并将其发送到PD 1。
应该理解的是,这种构造具有很大的优点。例如,通过邮政接收的帐单(例如,水电费帐单)可包括无源设备,该无源设备包括可由支付人电子设备的读取器读取以使支付人电子设备能够处理帐单支付的支付信息。
在另外的实施例中,无源设备可提供交易ID号,并且要求PD 1与(例如,商家***所运营的)包含该交易信息的远程数据库进行通信。例如,该数据库可与电子收银机相关联。然后,PD 1从数据库中收集所要求的支付信息,并且通过与TPS 2进行通信而执行交易。在该实施例中,支付人甚至可以手工键入交易ID号。
还需注意的是,在其中支付人设备处理交易的上述实施例中,商家设备必须被构造为响应于由PD 1启动的交易处理来识别通过电话或者通过TPS 2发送的交易批准码(或类似的标识符)。
一些其中本实施例将非常有用的示例情形如下:
●由商家收银机产生带有包括支付信息的条形码的帐单。PD 1扫描条形码(拍照),支付人经由TPS 2授权交易。TPS批准交易并且经由PD 1通知支付人。PD 1在其屏幕21上显示在商家商店处由条形码读取器(图12中未示出)读取的授权码。
●上述示例的变型例针对的是来自交易处理***2的要经由互联网或其他电子***直接传送到商家设备70的响应。
●在商家收银机处产生并入有条形码的明细表(docket)。条形码由小餐馆餐桌处的支付人通过PD 1来读取。处理支付并向收银机发送响应,或者甚至发送到为该餐桌提供服务的侍者的电话上。然后,消费者可以离去。
在另外的实施例中,除了向支付人设备提供支付信息外,还可提供产品信息。产品信息可以按照包括至少一个产品标识符的列表形式来提供,并且支付人设备包括使得能够选择产品的装置(其通常会是软件应用)。可以(经由受付人电子设备)将与产品选择有关的信息发送给受付人,使得支付人电子设备除了能够支付受付人以外还能订购产品。这使得支付人电子设备能够变为“个人收银机”。支付人可以使用他们自己的设备同时订购和支付产品。
产品信息可由许多装置来提供,包括通过来自受付人电子设备的无源设备(例如条形码)发送、从互联网上载等。
图14例示了根据该实施例的用于获得和利用产品信息的多种选择。应该理解的是,本发明并不限于图14中例示的选择。
一种选择是经由无源设备(诸如可与产品相关联的条形码71)来提供产品信息。在图14中,以饭店菜单72的形式示出了一个示例,该饭店菜单包括常规物品列表73,以及可由支付人的PD 1拍照以将菜单上载到PD 1的条形码71。
参照图15,示例处理如下。
在步骤80,PD 1上载包括该产品列表的菜单。PD 1上的软件应用使产品列表能够出现在显示器21上,并且支付人可利用输入20从列表中进行选择(步骤81)。
在步骤82,PD 1准备包括商家ID、产品ID、帐户ID或处理交易所需的任何其他信息的交易消息并且还订购产品。交易消息被发送到TPS2。
TPS 2将产品选择发送至MD 70并且还在TPS 2已授权支付之后发送支付授权。
如果产品信息涉及饭店中的菜单,则由MD 70来接收支付人选择,并且支付人选择将包括支付人的ID(例如,餐桌号)和支付人已选择的产品列表(例如,食物)。因此,商家可填写定单并且将食物和饮料提供给支付人,同时确信知道它们已经被支付。
在该实施例中,受付人电子设备可提供用于显示定单的装置,该装置在图14所例示的实施例中是打印机,该打印机打印出定单74,然后商家操作员可以容易地对订单进行处理,以使他们能够填写定单。
交易处理***2并入有定购***,该定购***被构造用于处理定单(产品选择)并将其转发给受付人。
产品信息可以按许多方式来提供,并且可用于许多方面的购物。饭店中的菜单的其他示例包括:
●商店/超市中的产品可设置有标识产品并提供支付信息的条形码71,使得PD 1能够处理针对产品85的支付交易。在这种情况下,PD 1可选择一种以上的产品,合计支付并采取一次交易。然后,TPS 2通知商家设备(在这种情况下,可以是电子收银机)这些产品已被购买。因此,自动促成了收银机的登录,可以不需要任何与商店收银机相关联的操作。可采用适当的***从产品85上移除任何安全措施,这样支付人才能带着产品离开商店。可以为PD 1生成(上文所述的)收据。
●可以从数据库86(其实际上是“购物”数据库)中下载产品列表。该数据库可包括多个商家以及与这些商家相关联的多个产品列表。支付人可经由PD 1(也许通过传送商家ID)来请求特定商家的菜单或者可浏览列表并上载一个或更多个菜单。他们随后可以购物并且远程地获得和支付商品,或订购和支付产品并亲赴商家店面(outlet)来接收商品。可以为PD 1提供适当的收据(例如,出现在屏幕上的条形码),在商家店面内可参照该收据来确保将商品提供给正确的人。
●例如,该数据库可为饭店和小餐馆提供外卖菜单。上载到PD 1的这种菜单的示例在图16中示出。例如,支付人可以在上班途中将小餐馆的菜单上载到他们的PD 1。他们可以输入对于咖啡、汉堡和蛋糕的定单并经由TPS 2将定单发送到小餐馆,同时支付该定单。当他们到达小餐馆时,他们的定单可能已经准备好了。应该注意的是,菜单可以从“通用购物数据库”中提供、从与商家相关联的***(例如,商家网站)来提供,并且可以经由网络(例如互联网)上载到电话,或者从无源设备(例如条形码)来提供。
如上所述,受付人电子设备70可以只包括打印机,该打印机被构造用于从TPS 2接收交易授权并打印出定单(以及打印出收据74)。支付处理的主要负担由TPS 2和PD 1来承担。
可以执行在之前的实施例中所述的安全措施,例如来自PD 1的对支付的数字签名确认。
应该注意的是,在一个实施例中,交易处理***2可以管理数据库86。在这种实施例中,PD 1可以向TPS 2发送商家ID、可选产品代码或产品族代码,TPS 2可访问数据库86并将可得到的物品的菜单(包括价格和描述)发送回PD 1。支付人经由PD 1来选择物品,然后向TPS 2发送物品列表、商店ID(可选的是商店内的位置)。然后,TPS获得支付授权并且将已支付的定单连同顾客标识一起发送给商店。如上所述,顾客标识可以包括需要与PD 1以某种形式(例如,条形码)提供的代码相匹配的代码。
然后,商家将商品(例如,小餐馆的食物、送货到家的食物、送货到家的商品、可在商店的提货点(pick-up)得到的商品)提供给顾客。再如上所述,安全ID标签的停用(deactivation)可使得购物者方便地带着商品离开商店。
如上所述,为了开帐单和订购,支付人的电子设备获得信息有多种方式。例如,可以利用光读取(例如,相机软件)、智能卡读取器/RFID标签读取器等来获得商店的详细信息,在某些情形下是商店内的位置,例如桌号或支付点。可以通过利用RFID读取器/光读取器扫描物品、滚动选择并点击下载到电话上的软件内的产品/服务菜单,或者手工输入产品代码来选择物品。
下面是示范根据本发明实施例的用于在饭店、小餐馆等内进行订购和支付的***应用的五个示例。
示例1-标准的提供充分服务(full service)的饭店
1.产生帐单并且与光/电可读的小餐馆/桌/金额一起传送;
2.顾客选择/拍照帐单/钱夹;
2(a).当金额不在帐单/钱夹上时,向厨房发送对于金额的请求,然后将金额发送至电话;
3.顾客添加任何小费并且按下“OK”键,所有完成。
示例2-提供充分服务的小餐馆
1.顾客选择/拍照桌号(其是小餐馆/桌号);
2.(经由***)向厨房发送对于金额的请求,然后将金额发送回电话;
3.顾客添加任何小费并且按下“OK”键,所有完成。
示例3-在柜台小餐馆处(counter cafe)进行订购和支付
1.顾客从收银处挑选餐桌号或坐在目前还未准备好的餐桌处;
2.顾客选择/拍照小餐馆/餐桌号(该号还表明了进入定购模式的电话);
3.将菜单发送给电话;
4.顾客通过菜单/黑板输入物品号(大多数最大为两位数),然后按下“OK”键。作为另一种选择,顾客滚读物品并在要定购的物品上单击“OK”键;
5.电话以带有金额的文本的形式显示完成的定单。电话发送定单以虚记金额(salt),然后作为文本发送回电话-订购和支付一步完成!!;
4.在厨房中打印定单条;
5.工作人员送交准备好的定单。
示例4-果汁/三明治酒吧/麦当劳等
1.顾客拍照/选择“小餐馆”号;
2.将菜单发送到顾客电话;
3.顾客通过菜单/黑板输入物品号(大多数最大为两位数),然后按下“OK”键。作为另一种选择,顾客滚读物品并在要定购的物品上单击“OK”键;
4.发送顾客名并发送定单,以打印在厨房条上;
5.如果订单准备好时呼叫顾客名而没有回答,则电话能够嗡嗡作响来提示。
示例5-现代化的提供充分服务的饭店餐馆
1.顾客能够在餐桌处选择定购,还有发信号通知需要以菜单做辅助的选择权。工作人员可例行告知详情等,当电子地“递送”菜单后,可显示“等待工作人员告知详情”。
2.即使发送了定单,电话也返回“更多定购模式”,允许进一步定购甜点、咖啡、酒水等。结束进餐选项提示小费-发送支付并且通知餐馆,因而工作人员可以说“再见”等。
3.通过从外卖菜单或所存储的列表利用上述***、发送名称而非餐桌号来提前定购的能力-取走定单,打进电话,支付,并且在准备好后能够通知购买者。
如上所述,可以使用非接触式智能卡来提供或获得与支付有关的信息。同样可以使用良好接触型设备,其中触点被另一触点接触以获得支付信息。这些设备是公知的。
其中支付人配备有能同时启动交易和进行支付的电子设备的交易流程的另一个示例如下:
受付人设置有相对于TPS标识受付人的标识码。为受付人所提供的每个服务点提供唯一的标识码,该标识码包括受付人提供餐桌服务的餐桌号、外卖食物或其他食物服务柜台。还为受付人处的每个支付台(payment station)也分配唯一的标识码。
受付人的标识码设置在:
1.打印或电子形式的受付人名片的表格
2.受付人的打印菜单或小册子上
3.受付人经营场所内的餐桌号标识符处
4.位于任何其他方便的位置处
支付人通过下列方式之一来指定受付人唯一标识码而启动交易:
1.通过电话中的或者存储在该受付人所用的远程服务器上的软件从所存储的“常见受付人”列表中选择受付人标识码;
2.手工输入受付人标识码;
3.自动输入受付人标识码;
3(a).经由相机对标识码进行光学扫描并且对链接在或并入在设备中的软件进行解码;
3(b).经由链接在或并入在设备中的“条形码”扫描仪或类似光读取器;
3(c).经由链接在或并入在设备中的RFID读取器或非接触式智能卡读取器;
3(d).经由用于启动受付人的设备以通过蓝牙(Bluetooth)或其他无线手段将标识码提供给设备的RFID或非接触式智能卡。
如果检测到的或输入到支付人设备中的受付人标识号标识了支付台,则如针对支付所述地继续进行所要求的交易。
如果标识号标识了受付人的任何其他服务点,则假定支付人希望现在标识支付人希望从受付人获得和支付的商品和服务。
然后,受付人的设备可呈现可以从受付人处得到的选项的菜单。
支付人选择物品标识码所要求的各个物品。这些代码可以:
1.利用设备键盘手工输入,例如5<ok>,其中“5”是期望物品的代码;
2.利用小型设备(例如移动电话)上所公知的“滚选”法从该受付人为设备提供的菜单中进行选择;
3(a).经由相机对标识码进行光学扫描并且对链接在或并入在设备中的软件进行解码;
3(b).经由链接在或并入在设备中的“条形码”扫描仪或类似光读取器;
3(c).经由链接在或并入在设备中的RFID读取器或非接触式智能卡读取器;
3(d).经由用于启动受付人的设备以通过蓝牙或其他无线手段将标识码提供给设备的RFID或非接触式智能卡。
在列表完成时,受付人例如,通过按下<ok>键指示列表完成,而不输入任何代码。然后,受付人的设备可显示被选择让受付人浏览的物品的列表和这些物品的价格。
受付人在此处拥有将帐户从默认帐户改变为用于支付的帐户的选择权,以简单地指示继续进行(例如,通过按下<ok>键)或取消。
受付人的设备可请求PIN或其他生物特征以确认交易。
然后,将物品列表直接发送到提供给受付人用于接收该列表的设备,并且在优选实施例中打印该列表,或者经由TPS间接地发送。根据受付人的商业安排,支付可在列表发送给受付人之前已经完成,或者留待稍后(例如当顾客接收到商品或服务时,或者当顾客选择完成与受付人的交易时)发送。在所有情况下,***都通过从一开始就标识支付人来为支付提供安全措施。
支付人的支付人设备可被构造为允许继续定购另外的物品直到支付人指定为止。在这种情况下,支付可在此时开始,并且可以为支付人提供改变要支付的金额或“***帐单”的选择权。
***帐单使得另外的支付人可以在受付人标识码处加入该交易,每个支付人都指示总金额的份额数(例如,1人、2人)。
图17例示了根据本发明实施例的使用预批准处理的交易处理。在该实施例中,通过利用支付人电子设备,支付人可以预批准为他们还未承担的交易进行支付。这对于许多交易类型或状况特别有用,例如在不出示卡的交易中,如通过互联网的支付。根据该实施例,支付人向TPS 2发送包括预批准指令的预批准消息。预批准指令可以包括用于标识随后要发生的交易的详细信息。例如,详细信息可以包括要进行的支付量。然后,支付人例如执行互联网交易,但在进行交易支付之前,TPS 2对预批准详细信息与交易详细信息进行核对。然后,TPS 2可依据详细信息的匹配来确认或拒绝支付。
更详细地说,参照图17,在步骤100,支付人确定他们希望执行的交易。例如,交易可以是互联网交易。支付人可能要求从商家互联网站点购买物品(item)。因此,支付人能够确定交易的详细信息,例如商家提供出售的商品/服务所要求的支付金额。
在步骤101,支付人向TPS发送预批准指令。预批准指令包括TPS为确认或拒绝后续交易所使用的交易详细信息。详细信息可包括实现交易的标识和授权的任何详细信息。例如,它们可以包括交易的支付金额。
在步骤102,TPS将预批准存储在数据库中。该数据库可包括标识支付人的“支付”信息、包括针对预授权的支付金额的详细信息的“金额”信息、“交易号”和“时间”(其可包括交易将发生的时间)。一旦“时间”届满,TPS随后就可能不批准交易。
在步骤103,支付人以通常方式承担交易。例如,当交易是互联网交易时,支付人可在提供用于接收这种详细信息的商家网站的网页上输入***详细信息。详细信息还包括可由支付人输入或由商家自动输入的支付。然后,将这些交易详细信息提供给TPS。它们可以按多种方式来提供。例如,可经由商家***通过通常传输(usual transmission)将他们提供给TPS。
在步骤104,TPS对接收的交易详细信息与数据库中的预批准详细信息进行核对,然后,根据详细信息是否匹配来授权(或不授权)交易。然后,可向支付人和受付人发送确认(步骤105)。例如,对支付人的确认可以通过SMS消息来进行。
如果在批准处理中,TPS要求进一步的确认,则它们可使用如以上结合前几个附图所述的方法。作为另一种选择或另外的是,它们可进行SMS消息交换,或甚至可利用支付人电子设备进行电话呼叫。
如上所述,该实施例对于为不出示卡的交易提供额外的授权步骤特别有用。
该实施例还可用作出示卡的交易的额外安全层。此外,上述本发明的前面几个实施例依赖于在支付人的电子设备与用于发生交易的TPS之间存在开放的通信信道。如果这些通信信道在出示卡的交易时不是开放的(例如,支付人电子设备是处于适当发送器范围之外的移动电话),则交易不会被授权。本发明的该实施例使得可以选择在失败交易后进行预批准。如果失败发生,则支付人找到在它们的支付人设备与TPS之间存在开放的通信信道的位置,并且提供预批准详细信息。然后,他们返回在不存在通信信道的位置处进行交易。随后,交易如上所述继续进行,即使支付人的电子设备落在通信范围以外,为了实现交易,TPS也对预批准详细信息与交易的详细信息进行比较。
在这样的失败交易的情况下,***可能已经从商家获得了与交易有关的信息。即,由于试图进行交易但由于无法联系打电话叫的人(personsphone)而失败,所以某些交易信息已提供给TPS。在该实施例中,TPS可继续尝试并且联系支付人的设备,直到支付人在范围内为止。当支付人在范围内,并且建立了联系时,授权者实体可将交易信息提供给支付人设备,支付人只需确认该交易信息是正确的。然后,支付人接着返回到商家,再次进行交易,此时交易由于支付人通过向授权者实体确认交易的详细信息而输入的所存储的预授权而通过(go through)。
对于不出示卡的交易,通常情况是这样的,商家向金融机构提供交易的详细信息并且要求它们确认支付人有足够资金进行支付,并且在发出向支付人提供商品的定单
之前冻结这些资金。只有在此之后交易才会通过。在一个实施例中,TPS可使用该商家预批准信息来联系与支付人相关联的电子设备,并且要求支付人确认交易被授权。交易可由一些交易的详细信息(例如支付金额)来标识。一旦支付人授权了支付,就可以接着处理该交易。可以将交易的详细信息保存在数据库中直到交易实际发生为止。
类似的预批准***可用于人们彼此之间的在线支付。
该实施例有用的另一种情形是周期支付,即,对于支付人来说每月进行的支付。预批准可连同交易时间(例如,支付应该发生的月的时间)一起存储在数据库中,TPS在每次从受付人接收到支付请求时都会检查预批准详细信息。这为周期性支付提供了额外的安全级。还可防止支付比约定的更加频繁地进行。
在另一实施例中,用于向PD 1提供信息的无源设备可包括与该无源设备所使用的应用有关的信息。例如,当无源设备是条形码时,其可包括与以下应用有关的信息,该应用需要在PD设备1上运行以使得可以处理条形码信息。
参照图18,可提供被配置为在PD 1上运行的许多不同支付处理应用。例如,支付处理应用150可被配置为特定用于停车计时器(parkingmetre)的支付处理。另一种支付处理应用151可被配置为处理帐单的支付,另一种支付处理应用152可被配置为处理饭店的支付。在另一个实施例中,应用可根本不涉及支付处理,而是具有其他功能。例如,一个应用可以是使PD 1能够上载并且处理名片信息的名片应用。
该***的优点是,掌握条形码中与条形码本身有关的信息使得PD 1能够在应用已经在电话上的情况下获得正确的应用或识别应用。当PD 1有必要获得应用时,条形码可提供可从中获得应用的位置信息,例如互联网节点的位置。
无源设备不限于条形码153,虽然利用常规电话技术相机55容易获得,但它也可以是任何其他类型的无源设备。应用可存储在可通过诸如互联网的网络进行访问的数据库中。
图19例示了交易处理***2的可能部件。在一个实施例中,交易处理***可包括网关160,网关160可包括用于与支付人设备和受付人设备进行通信的***,还有用于与“后端”处理器进行通信的***。常规的交易通常会要求商家设备与由收单行161管理的支付网关进行通信,收单行161随后与金融机构162(其可以是发卡银行)进行通信,以确定是否授权支付。然后,收单行161通常会向受付人设备提供授权或拒绝。本发明实施例的TPS可以的确只是具有适当***的收单行161,或可以是运行网关160并从商家设备或支付人设备向收单行提供信息的单独实体。网关还可运行如结合以上实施例所述的使支付人设备能够上载菜单的“通用购物数据库”163,和使支付人能够经由网关下载预批准的交易预批准数据库164。
TPS可包括单独地执行所有这些功能或一起执行所有这些功能或执行这些功能的不同部分的组合的组织(organisation)。
交易处理***可由适当的软件和硬件(通常是服务器计算机)来实施。
图20是根据本发明实施例的可用于实现支付人设备的经改装移动电话的组件的框图。本文之前的部分中所讨论的大多数功能都可通过以应用121的形式载入到移动电话中的软件来实现。这些应用包括使得能够准备适当的消息的支付应用。通过这些应用,移动电话可被构造用于识别支付信息。这通常是不能由标准计算设备来实现的。
考虑万维网进行对比。万维网构成了通用浏览数据库。该网络包括一种***,其中可以使用组合了“站点”的描述和站点内的另外位置信息(被称作URL)的“请求”来检索通用格式的信息,该信息使得被构造为可处理这种格式的计算机能够显示文本、图形和链接并且可以处理这些文本、图形和链接。
目前人们可以通过网络购物,但还没有允许计算机通过网络进行购物的***。网络语言(html)指定了标记符,使得计算机能够识别和显示标题(heading)、识别和显示链接等,但不能够识别物品代码或价格。计算机的用户必须读取屏幕上的信息并确定物品描述或价格是否存在。
应用121可包括使得支付人设备能够识别并处理支付信息的应用。如以下实施例中所述的,所提出的一个实施例包括“通用购物数据库”。对于这种数据库,请求可特别地含有用于识别提供待售产品的商店的代码,并且需要以下两种类型的请求,而非得到显示页:
1.以便于自动处理的格式和以通用格式获得待售物品的描述和价格,使得计算机能够根据各个响应而自动创建价格和描述的表格的请求。该请求被称作“菜单”请求;以及
2.购买物品或从前面的“菜单请求”中收集所获得的物品的通用请求。
利用常规网络语言(html)进行网上购物的示例如下:
Request=www.sampleshop.com/buypage.html
Response=
<!DOCTYPE HTML PUBLIC″-//W3C//DTD HTML 4.01 Transitional//EN″
″http://www.w3.org/TR/htm14/loose.dtd″>
<html>
<head>
<meta http-equiv=″Content-Type″content=″text/html;charset=iso-8859-1″>
<title>Untitled Document</title>
</head>
<body>
<h2>Welcome to the shop!</h2>
<p>Click<a href=″buywidget.html″>here</a>to buy a widget for$50!</p>
<p> ;</p>
</body>
</html>
网站浏览程序使用标记符来处理与网站浏览有关的信息,例如,标记符<h2>和</h2>之间的文本是标题。
“widget”的价格是$50的事实与网站浏览器无关。
作为对照,使用所提出的“世界商店格式”,请求看起来像:
“store=1234,menu=a”
而响应如下:
<itemID>1567<itemDesc>Widget<price>5000
该响应需要由“购物程序”而非“网站浏览程序”来读取。在这种情况下,如何显示信息取决于“购物程序”。然而,该程序知道物品以一定价格出售。如果用户选择购买该物品,则该程序知道该物品正被购买。
这具有以下优点,进行购买所需的安全措施可由程序自动应用,并且可自动保存购买的历史记录。
还可加载使电话能够读取条形码(或其他无源设备)的其他应用121。
此外,为了进一步增加如上所述的(说明书中稍后进一步例示的)安全措施,可以采用固件122。
经改变的(adapted)电话包括发送器/接收器119、处理器118、SIM卡116、时钟123、RAM 117a、闪速ROM 117b、LCD显示器1 33以及驱动器130、键盘112、导航键110、相机124、扬声器115、麦克风116和A-D转换器114。它还包括天线120、无线模块125(例如蓝牙或通用分组无线业务(GEPRS))。
硬件还可包括能够利用键加密方法识别用户的安全模块。安全模块被设置为众所周知的cyrtosis,这是由Rivest、Shamir和Adleman(RSA)定义的***或电曲线加密方法。当设备是移动电话时,其包括SIM,在该实施例的任何变型例中,SIM都被设置为充当安全模块。
支付人设备可不包括用于实现本发明实施例的上述所有部件。例如,对于一些实施例,诸如预批准,不需要具有访问装置或固件。在其他实施例中,为了提供额外的安全层,可只设置固件,而不设置访问装置。访问装置和固件提供了四个安全层。
综上,该***可由与支付人相关联的电子设备(例如移动电话)来实施,基本上为三层面实施:
1.标准的移动电话,具有或不具有使其对用户更友好的JAVA或另一种应用。该***在该层面上的基础是,在没有安全的移动电话的情况下,必须为现有的安全措施添加安全措施。在该层处,例如可通过简单的SMS消息来实施针对交易的预批准的批准。
2.***“保护”的移动电话。利用防病毒攻击的固件来提供签名***,利用软件来处理来自***的输入消息。签名和PIN键盘可由利用移动电话批准所有交易来代替。
3.启动支付的接触和非接触式ID(访问设备)和移动电话的使用是交易的主要通信设备。
应该注意的是,支付人电子设备可不包括经改装的移动电话。它可包括任何其他计算设备(优选地是便携式的),例如PDA。它甚至可包括特别构造作为支付人电子设备的专用设备。
术语“电子设备”不应该认为限于只由或完全由电子装置操作的设备。本发明可使用任何类型的处理设备(例如,可利用光传输而执行的设备)作为支付人设备和/或受付人设备。
可利用本发明的另一个实施例来避免必须对支付人进行提示。支付人设备在被提示时经由***注册一个人(支付人),该***直接或者通过服务器向电话发送信号。作为另一种选择,当电话置于提示时,电话可周期性地推动(pole)提示状态,以将当前的状态通知给用户。这可用在任何提示中,以在定单准备好时通知支付人。或者给以提示码的提示,或者经由联系列表或其他电子装置电子地读取或利用相机(条形码)光学地读取。然后,***提供什么号码位于提示的最前面的连续状态更新,使得电话能显示在你之前被服务的最后几个号码。该***包括提示数据库,和用于通知电话它们处于提示中的位置的装置。因此,支付人设备可提前定购并且在准备收集(pick up)定单时通知支付人。
下面将描述本发明实施例的另外几个示例。
本发明的经改进的支付***利用了以下事实:许多市场中的大多数消费者都把他们自己的计算设备(通常是移动电话)带到销售点。对该设备的低成本改装可以使新的支付***不仅能够处理当前***的安全问题,而且能够带来许多新的另外的新特征。
利用这一新***,商家将有利地拥有接受交易的经改进的新方式。银行能够减少或消除昂贵的费用备份(charge back)并且增加消费者的信心。移动电话公司有了新的“杀手:”用于移动电话的应用。
本发明实施例的***利用了已“升级”到能够在无线覆盖区的任何位置进行操作的移动电话或袖珍计算机形式的经改造的消费者电子计算机。该***提出,所有交易都包括利用该升级的设备从消费者(支付人)处获得核实。这样,所有交易都由消费者来核实。诸如在销售点、通过电话购买或互联网购买的实时交易可在当时进行核实。
诸如帐单支付的任何后台周期性支付将在设定支付时进行整体批准,在该示例中,如果要求覆盖消费者睡眠或在交易时无法联系的状况,则使得以24小时周期地进行任何后续的另外批准。
支付***考虑到要求对移动电话或袖珍计算机进行的改变,使得可以进行安全且简单地使用支付交易的核实。
另外要考虑为实现最佳操作所需的对其余支付***的改变,以及当这种设备是***的一部分时利用所出现的机会。
在该示例中,在大多数情况下,在消费者进行购买时能够无线地接通移动电话或袖珍计算机。
针对可选操作来升级设备要求设备配备有:
●无线数据通信***,例如GPRS或蓝牙
●方便支付核实的软件和/或固件
●能够利用公共密钥加密法“签署”交易的安全模块
●非接触式智能卡。该设备还能够在提供给消费者之前或在现场为支付功能进行编程。
注意:虽然设备被称作PINpad,但是不是必须使用PIN。
根据支付***的原理将非接触式智能卡提供给消费者。非接触式智能卡是众所周知的设备,通常用在运输***中。非接触式智能卡的典型特征是,其由距离0到10厘米的被称为非接触式智能卡读取器的设备供电和“读取”(实际上与之通信)。
在该***的优选实施例中,消费者将他的非接触式智能卡放在他的移动电话的背面,使其不干扰任何相机、电池盖或电话(或袖珍计算机)的其他功能。卡与消费者设备之间的任何电连接都是不必要的。物理上连接卡是为了方便以及将卡与设备结合在一起。
在根据实施例的***中启动支付
升级的支付点
为了在为新***装备的支付点处启动支付,消费者使袖珍PINpad接触该支付点处的特殊标记的读取器,以表示他/她期望利用该***进行支付。
非接触式智能卡(附接在电话或袖珍计算机上)将详细信息传递给支付点,以实现距离较远的两个设备之间的进一步通信。既然支付点已获得如何接触袖珍式PINpad的详细信息,消费者现在就仅需要保持在内置其袖珍PINpad中的无线通信的范围内。
传统支付点
***的可选特点是,即使在还未升级到接受新***的支付点也能够提供新的支付***。
为了在这些现有的支付点提供该***-消费者的银行在后台激活该***。
在这种情况下,可在销售点提供消费者的普通***,并且交易像传统的交易一样继续进行。当支付请求到达消费者银行时,银行会将支付批准请求直接发送到消费者的移动电话。一旦消费者批准交易,就向银行返回批准消息,并且交易自始至终是在回到商家终端时被授权。
改进的支付交易
已经从卡中获得了可使用何种无线***(例如,蓝牙或GPRS)来联系袖珍PINpad有关的详细信息和发送信息到正确的袖珍PINpad所需的任何信息(例如,蓝牙连接的蓝牙ID或GPRS情形下的电话号码)。支付设备将交易金额发送到袖珍PINpad并且存储该详细信息以便进行支付。
一些交易将允许消费者改变金额。在发生金额改变之后,消费者可选地输入他的PIN或简单地表示“ok”,袖珍PINpad电子地“签署”交易,以表示消费者同意交易。
然后,交易被发送到银行。银行对交易进行处理并将交易的记录发送回消费者和商家设备。
在商家设备收到完成交易的记录时,设备向商店销售人员或自动售卖机发出支付已完成的信号。
零售、销售点、基于卡的***
我们中的大多数人都很熟悉***和借记卡。使用广泛的两种卡是:
●基于磁条的卡;和
●带有计算机芯片的“智能卡”。
从操作角度来讲,利用这两种卡的支付是类似的。支付的步骤通常如下:
1.支付步骤-将卡交给商家
●消费者将卡提供给商家。
●商家在支付终端中使用卡。
●商家输入支付详细信息。
●如果要求PIN,则在PIN输入设备上输入。
●通过商家的支付设备向银行发送交易。
●在商家的支付设备上显示银行答复。
●对于无PIN交易,商家获得消费者签名并保留。
在代替消费者将卡交给商家的支付处理的变型例中,消费者将他自己的卡输入到被设计为由消费者操作的读取器中。该变型例试图通过减小商家看管卡由此能够复制消费者的卡的风险,来减少处理中的某些安全问题。
一般而言,处理存在几个问题。
问题1-设备变化
利用安装在支付点的支付设备,商家拥有充分的机会来学习如何操作该设备,并且假设发生了对该设备的任何篡改,则商家拥有充分的机会来检测这种篡改。但是,消费者在各销售点处面对的可能是完全不同的设备。这造成了以下问题:
●由于消费者要使自己熟悉设备,所以自助支付点是缓慢的且操作起来容易产生困惑。
●出于安全原因应该由消费者执行的任何交易步骤都将面临消费者要操作不熟悉的设备这一障碍。这导致商家执行诸如刷卡和帐户选择的步骤,而不是向消费者解释操作。
●替换设备易于被不择手段的商家使用来收集PIN和卡的详细信息。
问题2-交易签署
已提出各种方法来使消费者“签署”交易,以表示自愿参与。
●书写的签名
在交易时可靠地检测书写的签名中的问题,这对商家一方要求了不合理的技能。对这些书写的签名进行归档和存储也对商家造成了不合理的负担。为进行签名核对而出示卡也强制消费者交出了对其卡的控制。
●经银行(或金融机构)核实的电子PIN
输入到商家设备的PIN可容易地被商家的替换设备获得。这可造成对个人资金的严重攻击。
●经智能卡核实的电子PIN
通过利用消费者的卡来核实PIN,可以极大地降低PIN被窃取的风险。不幸的是,该***没有适当地得到足够广泛的应用。
问题3-卡的复制
卡能够被复制是当前的卡支付***中的主要缺点。磁条卡易于在相对廉价的设备上被复制。
尽管智能卡理论上确实几乎消除了卡复制的问题,但智能卡还包含磁性详细信息并且世界范围内的许多商家都可以单独接受磁性详细信息。在出示卡的任何时候,磁性详细信息仍可被复制并用于世界范围内的欺诈***易。
问题4-重复交易和金额欺骗
商家成倍地从卡中收费或收取消费者认同之外的金额的方式有许多种。小数目的金额可能不会引起消费者的注意,但是却令消费者蒙受损失。然而可以检测到大数目的金额。当报告书(statement)到达时,商家可能已经消失了。尽管在目前的***种这些不是最严重的问题,但是封堵其他漏洞而保留这些问题将会看到这些问题的显著严重化。
问题5-付小费
许多交易允许可选的小费部分。利用商家的终端中所使用的卡来支付小费的唯一实际解决方案是,在银行已批准交易之后增加小费。
让消费者把他的小费输入到商家的机器中是不切实际的。
让商家对完成的交易增加小费造成了***的缺点。如果商家要不正确地增加较多的小费,那么消费者拥有怎样的追索权(recourse)?首先,消费者必须检测到该问题。然后查找该交易并强制商家产生原始签署的收据,这是问题所在。对于双方都花费很高且很痛苦。尽管最终会发现商家***性瞒报费用(skimming),但在发现问题之后仍有许多消费者被收取额外的费用(问题员工可能长期存在!)。
互联网支付***
目前有两种基于互联网的支付是实用的。
1.真正安全的互联网支付
真正安全的互联网支付经常被提到,但是很少实施。首先,安全的互联网支付需要智能卡,而消费者并没有智能卡。MasterCard、Visa等的SET是首先很好推广的利用智能卡的***之一。其次,要想真正安全,对PC的配件的要求是不仅能读取智能卡,而且能显示要花费的金额以及接受PIN以签署交易。例如,这样的***是众所周知的(参见FINREAD)。
智能卡用于为交易提供安全的不可再用的数字签名。由于蠕虫和病毒使得主计算机显示器上的信息对于远端方的更改和获取是开放的,因此需要单独的安全控制台来进行支付。使用控制台上的PIN键盘来指示智能卡为安全地显示在控制台上的金额创建数字签名。
如今这样的交易是尽可能地安全。为了创建交易,人们同时需要原始智能卡和PIN。获得复制的卡实际上是不可能的。
问题在于,多数人的PC不具有FINREAD型附件,也不具有使用智能卡的数字证书。仅仅为了保证人们的互联网交易,***目前难以在成本上被证明是合理的。
为了避免这个问题,诸如美国快递(American Express)和Visa的卡协会提供了不同的另选方案。
美国快递的个人支付方案要求美国快递持卡人首先登录美国快递站点,“预分配”支付金额并接收用于该分配的ID。持卡人随后可以使用该ID来购买链接到美国快递个人支付的互联网商家站点上的商品。该方法具有不用使用***就可进行购买交易的优点,但持卡人使用起来相当麻烦,到目前为止在商家中还未普及实施。
在Visa国际的3D-安全方案中,持卡人仍输入他们的***,但是仅在发卡者而非商家要求***时才输入。该方案依赖于完善建立的SSL/TLS技术,来保护交易中涉及的所有方之间的链路。由于涉及的复杂性,该方案仅对较大的商家有吸引力。
2.主流“安全”互联网支付
主流“安全”互联网支付仅意味着支付详细信息通过互联网安全地传输。当中介机构不能截获所使用的***时,互联网商家自身必须被信任对他们接收的***进行保密、收取正确的金额并且只在指定的情况下开帐单。接收到这些支付详细信息的商家不能肯定地确定是谁发送了该支付详细信息。
基本上,消费者必须无条件地(take it on faith)相信商家,并且当商家添加诸如核对商品递送的地方和收到递送时进行签名的保护时,这对于商家是昂贵的。当商品被电子递送时,商家添加任何保护甚至变得更加困难,结果,在这种交易中进行欺诈的成本很高。
上述实施例的***的优点
如果今后会采用针对该实施例的***的新基础设施,则可以降低安全成本和交易成本。新的支付***为消费者、商家和银行带来了好处,证明了新***的首次展示是合理的。
安全
根据本发明该示例的解决方案提供了当今可用的最高级别的欺诈保护。购买得到了与FINREAD型互联网交易相同的保护。这就好像是消费者将互联网终端和智能卡读取器带到了销售点。
尽管通过智能卡的普遍引入确实可以大大减少许多目前的安全问题,但是该示例的作用不止如此,有利地是,其甚至可根除由于转用(moveto)智能卡而仍然遗留的问题。
进一步的保护通过以下方式来提供:
●能够核实购买金额的安全性;
●防止小费和金额的变化;
●防止加倍收费;
●消除甚至是磁卡级复制的风险;
●通过允许消费者在没有配备新***的销售点核实交易来保护甚至是“传统”的交易的能力;
●在除传统之外的所有交易中,为商家提供支付的证据但不提供消费者卡的详细信息。
成本
通过利用消费者已准备进行支付的设备(例如,移动电话),改进的***的基础设施的成本很低。
支付终端可视为“一分为二”-终端的一部分是消费者携带的移动电话,其余的商家组件大大得到简化并且成本得到降低。
这实现了更多的支付点,例如停车计时器、自动售卖机和商场的自助销售点。
速度
通过使消费者能够在熟悉的设备上分摊交易负荷,可在所有情况下提高交易速度。***实现的自助销售点支付还将允许消费者立即支付,而不是在多数情况下的排队等候服务。
不但结帐可以变得更快,而且饭店内的消费者可以省去取走他们的卡的以进行处理的整个额外步骤。
灵活性
新***为电子支付带来了全新级别的可能性。
新的便利性包括:
委托支付
在支付时,消费者可以指定父母或朋友代表他们进行支付,只要被指定的人是不在场的“唯一电话呼叫”即可。这允使得孩子的其他亲人能够访问应急资金(emergency fund)-但确保其他的应急基金提供者的父母要监视对这种资金的使用。
在支付时,消费者可以指定父母或朋友代表他们进行支付,只要被指定的人是不在场的“唯一电话呼叫”即可。这允使得孩子的其他亲人能够访问应急资金(emergency fund)-但确保其他的应急基金提供者的父母要监视对这种资金的使用。
分开支付(split payment)
去过饭店吗?遇到过帐目应该分为两个、三个或甚至更多个的情况吗?采用现金目前似乎是唯一的解决方案。虽然大多数饭店都会将帐目分为两种方式以便用卡进行支付,但是即使这样这还是杂乱的解决方案。每个额外的卡或其他复杂化都会使传递不同持卡人的意愿更加困难。
配备有其自己的个人PIN键盘的每位用餐者能够自己缴款,根本无须与饭店沟通进行解释。
金额变更
呈递给消费者的金额不仅可以由消费者安全地核实-而且它还可以用指定的参数来改变。这对给小费尤其有效。目前用于给小费的***通常仅对***交易有效。无小费的交易由银行批准。在读取了消费者写在收据上的小费金额后,商家随后处理对原始交易的变更。
这对消费者和商家都是存在问题的。对于商家而言,必须检索原始交易(在忙碌的饭店中,任意一个时刻可能有几个收据出现在餐桌上)并且输入新的金额。
对于消费者而言,根本无法对商家输入的实际最后金额进行核实,并且很难检测到由于商家看错而出现的错误、索费过多或任何其他因素。
利用本实施例,消费者可将要支付的金额直接添加到他自己的设备上-首先处理正确的金额。不要求商家重新进入。错误和怀疑之源被完全消除。
帐户选择
可以将多个银行帐户链接到支付人设备,并且作为另一种选择,可以选作默认帐户。这些帐户不需要来自于同一银行。
该实施例的***还有利地提供更多的便利性。
自助服务支付
自助服务支付点可以避免排队,并且可以在其他情况不可能的位置提供商品和服务。历史上,在这些自助服务支付点进行支付可能要通过硬币(有时通过纸币)。在接受***/借记卡的情况下,消费者或服务提供者必须支付昂贵设备的开销和电话开销。
通过该***进行支付有利地减少了这些问题。接受设备成本低并且不需要电话呼叫。最好地是,消费者利用(他自己的电话中的)相同支付设备,而不必学习如何使用每个支付点的新支付设备。阅读指令和困难的卡读取器已经成为往事。
在所有支付点选择帐户
由于后勤方面的原因,目前的***通常会限制帐户类型。例如,输入PIN在饭店里可能存在问题。利用支付人设备***消除了该问题,因为输入PIN请求被传送至餐桌处的消费者。不需要向收银员发出指令,对PIN输入也没有任何限制。
商家询问帐户然后对比参照以免除消费者在不熟悉的设备上选择帐户的情景已经成为往事。
帐单核实
当银行报告书到达时,移动电话能够立即协调经该***核实的所有电子交易的账户余额(account balance)。这消除了“我是否被索费过高”的担忧或为消费者进行协调的烦琐之事。
收据归档
对于电子签署的所有交易,都不需要纸件收据。这简化了昂贵的索赔、税金记录和针对消费者的其他核算(accounting)。
消除了保留纸质签名作为交易证据的必要,这对于商家而言是巨大的益处。
通用应用
可以为所有支付(电话定购、互联网、现有传统的销售点处的支付***以及新的经改进的低成本支付点)使用相同的核实***。
发卡机构和移动运营商需要升级的***。一旦其就绪,参与的每个持卡人就都能看到直接的利益。在***有价值之前,没有必要等待升级的设备到达商家。
设备
消费者设备
对于***来说,要转换为支付人设备的消费者设备需要无线通信的形式(在某些实施例中不需要如此)。目前,三种无线通信***被广泛使用-802.11、蓝牙和GSM+GPRS/CDMA。
在本示例中,每个设备都被视为适于配备无线通信的形式,能够在位于大多数购买点的消费者与网络之间进行通信。当今的示例是GSM和GPRS或CDMA移动电话数据通信。当所使用的普遍的无线协议随时间而变化时,要使用的无线***也要改变。
本文讨论了基于GSM+GPRS移动电话(其另外可选地配备有蓝牙通信)的***。
新的软件和固件
本实施例中的设备上的软件应该包含目前电话中未发现的特定特征。
特别是:
●通过使得能够在设备中进行支付的任何无线***接收支付请求命令并将该请求传递给SIM模块的能力。
●显示来自SIM模块的支付请求消息并把数据输入(entry)传递回SIM模块的能力。
●以不能被载入到电话中的任何应用复制的方式显示PIN输入消息的能力。
●将对于支付批准消息的回答直接呈现给SIM。
●对于支付批准消息的回答不能通过任何应用软件发送到SIM。
应该注意的是,可使用另一个处理模块来代替SIM,但SIM对于移动电话实施例是优选的。
根据这些要求,断定支付批准消息显示和响应应该由固件来实现。防止应用生成对于支付批准消息的回答确保了没有软件蠕虫或病毒可用于使电话(或其他消费者设备)批准消费者还不知道的支付。
假如在完成辅助功能的任何功能时,保证了支付批准屏幕能够显示将在消息中发送到SIM的金额作为消费者批准支付的金额,则可使用可重新载入的软件将该功能实现在支付批准屏幕上。
非接触式智能卡
非接触式智能卡是公知的。该***的优选实施例为每个设备配备了非接触式智能卡,以便在新类型的支付点容易地进行支付。非接触式智能卡还便于实现消费者设备在金融机构的注册。
期望的是,使用尽可能小尺寸的同时仍允许卡内存在任何必要的天线的非接触式智能卡。还期望使用柔性而非刚性材料来制造卡,使得卡能够粘附于消费者设备的壳体轮廓上。
期望的是,卡能够安全且唯一地记录卡在销售点的出现。这要求卡包含用于签署来自非接触式支付读取器的消息的加密密钥。
非接触式智能卡应该还能够传输与和卡相关联的支付人设备进行通信所需的信息。这种信息包括并入在消费者设备中的任何蓝牙模块的蓝牙ID以及电话号码,使得能够与设备的无线模块进行通信。
非接触式卡还能够将匹配消费者设备的能力(例如,蓝牙-非蓝牙、GSM-GPRS或CDMA等)传输给读取器。
非接触式卡还能够将匹配安全模块的公共密钥(参见下文)发送给如金融机构所使用的读取器,在这种情况下为公共“初始化”密钥。
SIM或安全模块
为确定交易已到达正确的设备,期望能够利用金融机构能核实属于持卡人的密钥来加密数据。这种***是公知的,并且已在几乎所有基于智能卡的支付***中提出。在GSM移动电话的情况下,同样已经存在安全模块。所有要求的是电话中的SIM能够满足这里指定的要求或由能够满足这些要求的SIM来替代。
在优选实施例中,GSM电话中的SIM配备有针对用于金融交易的密钥的和用于匹配的加密算法的安全存储器。诸如RSA或椭圆曲线的公知加密标准是适合的。这种***利用一对密钥,一个“私人”密钥(秘密且安全地保存在消费者卡中)和一个公共密钥。利用一个密钥进行了加密的数据可用另一个密钥来解密。简单放置-并且可以通过以私人密钥加密数据来将数据发送到卡,并且相信只有具有匹配私人密钥的卡才可用于解密数据。相反,以公共密钥正确解密出的任何数据都源自具有私人密钥的卡。
为使金融机构能够为它们的持卡人将密钥安装到已发行的SIM卡上,可使用公共/私人“初始化”密钥对,SIM卡中保存的私人密钥和匹配非接触式智能卡中的公共密钥。
银行授权***
发行借记卡或***的每个银行都必须确保***保持每个持卡人的余额和批准的最小余额的记录。升级该***,以在该***被使能时向持卡人的支付人设备发送支付批准消息。
余额核实***格式化该消息并且在识别出支付人设备时通过***发送该消息以及详细信息。
持卡人可能需要一种使能和禁能该***的方法以允许移动到他的支付人设备可通信的区域之外。
移动电话通信网关
新的通信***从发卡机构接收支付请求并且将请求发送到支付人设备。该***可由一个用于所有交易类型的集成网关***或用于一个或两个交易的单独网关***构成,或者可作为新功能添加到现有的网关。网关应该能够用于三种交易类型:
●启动支付授权请求,发送到支付人设备;
●对从支付人设备接收的支付进行响应;
●将已由支付人设备在销售点签署的交易传递给适当的金融机构。
在这些情况的前两种情况下,网关将充当金融***与支付人设备之间的接口。发卡银行仍需批准交易。在第三种情况下,接收到经批准的交易的金融机构通常是收单行。
应当注意的是,在实施优选解决方案时,可评估发卡机构、收单行和卡协会(例如,Visa)的传统角色。
卡
很长时间以来,传统支付点需要现有类型的磁卡来启动交易。针对新类型交易点的较低交易成本将鼓励他们随时间而加入到销售点中,但***仍给予基于当前卡的销售点充分的保护,而不需要任何升级。
可以发行不链接到特定银行帐户的新卡。
支付设备
现有电子支付接受设备可与未改变的***一起工作-但没有利用所提供的新设备。
一些设备已经从银行逐张卡地得到关于是否请求PIN或签名的指令。建议将***链接到现有的签名卡-或为此发行的新支付卡-而不是基于PIN的卡。
甚至对配置或编程进行的很小变换都将改善利用支付人设备进行交易的效率。利用具有重复编程设备的***可获得另外的好处,并且利用具有新一代支付设备的***可获得更进一步的好处。
一个实施例中的支付人设备可具有三种类型的无线通信以便进行灵活操作:
●用于启动交易的极近程(大约最大10cm)无线通信。
●局域无线通信,用于和贯穿交易的支付点(或支付终端)进行通信。
●全球范围的无线通信,使得能够在支付人设备与消费者在其中保存帐户的银行之间进行通信,而不管消费者在全球的什么地方,或至少在尽可能多的位置。
支付***能够在不需要实现所有上述***的版本中运行。该建议将允许目前的移动电话或具有无线电话调制解调器的袖珍计算机容易且低成本地转换为可工作的支付人设备。
仅单一类型的无线通信
一种示例性支付人设备包括仅一种类型的无线通信。使得能够与支付点进行通信的局域通信或使得能够与帐户被保存在的金融机构直接通信的远程通信在技术上是足以实现的。
这种设备可以通过支付点与金融机构有效地进行通信,或通过金融机构与支付点有效地进行通信。
由于没有并入启动交易的便利装置,所以这些设备将有效地适于保护传统交易。
近程+局域无线PIN键盘
具有近程和局域无线通信能力的设备可以在配备有全部三种类型无线通信的支付点既启动交易又执行交易。
近程+远程无线支付人设备
利用专用数据网络或移动电话网络的远程无线设备广泛地使用,并且可容易地添加短程无线通信。
完整***支付人设备
取来任何一部还配备有蓝牙(或具有配备蓝牙的能力)的移动电话,增加必要的固件和包含适当SIM和非接触式智能卡的包(packet),你就可以拥有一台多用途的支付人设备。由于移动电话***运营商拥有请求电话制造商增加固件并访问SIM和非接触式智能卡的能力,所以这些设备的采用仅需雄心勃勃的移动电话***运营商。
集成完整***支付人设备
与对“完整***”支付人设备的升级相同,可以在制造时将近程无线集成到支付人设备中。这将使得支付人设备不仅能近程地发送数据而且能接收数据。这种能力将使得直接的人对人的支付更加灵活。
支付交易类型
利用支付人设备的传统交易
利用支付人设备的传统交易如同正常***交易那样进行下去,直到传统发卡组织的交易批准中心接收到交易为止。这时,将支付批准请求发送至支付人设备。
一旦支付人设备接收到交易,消费者就可以选择在哪里支付他的帐户以及批准或拒绝交易。
通过网关将消费者的响应发送回批准中心-其随后处理交易并且通过传统***发送回结果。还通过网关将交易的结果发送至支付人设备,以便消费者进行归档并且作为电子消费者收据。
近+远程无线支付人设备交易
在支付点特别配备有支付人设备交易的情况下,消费者通过将他的智能卡接触支付点来表示他愿意进行支付,而不是使用传统的***或借记卡。商家应该已将要支付的金额(或者对于可变金额交易,支付的范围)输入到支付点设备中。
由支付点设备收集的交易的批准请求应该直接发送到支付人设备网关。消费者再次使用支付人设备来修改和/或批准交易,然后将结果从支付人设备发送回网关,该网关将来自支付点的信息连同来自支付人设备的应答一起发送到金融交易批准网络。将交易结果发送回支付点和支付人设备二者,以便为两个设备提供电子收据。
用于完整支付人设备的局域无线交易
在可预知的一段时间内,目前接受传统卡支付的支付点将继续如此。当针对支付人设备交易而另外配备时,这些支付点可以在无需销售人员付出很多努力的情况下,较之传统交易为支付人设备交易更快地传送交易。处理传统交易的能力要求支付点配备有到金融交易批准中心的通信链接。
当针对支付人设备配备的支付点检测到具有局域无线能力的设备时,该支付点可通过局域网直接向支付人设备发送支付批准请求。
当支付人设备通过局域网接收到支付批准请求时,其首先允许消费者改变和/或批准该支付批准请求。然后,支付人设备检查请求以确定是将该交易直接发送到支付人设备网关,还是通过到支付点的局域无线连接发送回支付点。在这种情形下,交易被发送回支付点。
然后,支付点通过批准传统交易所使用的同一网络来发送交易。在接收到对交易的响应后,支付点将交易结果传递至支付人设备,以便为消费者提供电子收据。
用于完整支付人设备的远程无线交易
在先前未提供电子交易的场所,或者在即使接受传统交易的某些情况下,可能期望提供其本身不具备远程通信能力(例如,没有调制解调器或电话)的低成本支付接受点。
在这种情形下,可使用支付人设备来发送用于处理的交易并接收结果。
用于完整支付人设备的局域无线交易(除支付人设备负责通过支付人设备网关发送用于批准的交易之外)和支付人设备将电子记录或交易发送给支付点,二者都提供了交易的记录,并使得商家可以识别消费者的支付。
***安全
***的安全性来自何处?SIM模块(或其他指定的***处理器)安全地存储着用于加密数据并且利用公知的技术(例如RSA)来创建数字签名的密钥。因此,保证了从电话发送来的每个支付批准都是利用该SIM模块生成的。
这样,仅剩下了两种欺诈地生成消费者不批准的交易的可能:1)消费者以外的某人使用该电话或SIM,或2)支付人设备被篡改,从而在消费者并不知情的情况下产生了对交易的授权。
PIN和其他生物特征-支付设备防盗
PIN仅是生物特征的一种形式。它存在于用户的存储器中,并且通过检索该存储器,用户识别出自己为拥有该存储器的人。***可使用任何形式的生物特征,例如PIN、指纹、眼睛扫描、面部识别。
在优选实施例中,每次达到预设金额时或者对于任何超过该预设金额的交易,无论在使用哪一种生物特征(PIN、指纹、眼睛扫描等)都将被要求。例如,考虑$100的预设金额。少于$100的交易可以发生,直到全体这些连续交易总计超过$100为止。达到连续非生物特征交易的合计的第一笔交易将要求生物特征认证。
交易金额 | 要求生物特征? | 原因 |
$300 | 是 | 交易大于预设限制 |
$10 | 否 | 自上次生物特征之后仅花费了$10 |
$50 | 否 | 自上次生物特征之后仅花费了$60 |
$60 | 是 | 加上这笔交易,自上次生物特征之后花费了$120 |
$30 | 否 | 自上次生物特征之后仅花费了$30 |
$150 | 是 | 交易大于预设限制 |
$80 | 否 | 自上次生物特征之后(包括该交易)仅花费了$80 |
重要的一点是,生物特征应该只由SIM来使用。SIM在接下来将交易签署为消费者批准的交易之前对生物特征进行内部认证。无论使用何种生物特征都不应该发送到支付人设备之外。倘若使用PIN,则该PIN不应该与目前在ATM等中使用的任何PIN相匹配。无论使用何种生物特征,对于不访问支付人设备的任何人都是没有价值的。
生物特征(PIN或其他)的使用是为了限制在未经授权的情况下得以访问支付人设备的的任何人可花费的金额(尽管可以通过其他方式来应用生物特征的使用)。
固件保护
根据本示例的***的原理是,支付人设备的用户必须确定显示在签名屏幕上的并且被用户接受的数据是可利用支付人设备签署的唯一数据。
这可以通过设备中的固件来实现。固件被设置为使得单个固件具有以下功能:
1.将信息显示给用户,
2.接受“OK”和PIN或其他生物特征,以及
3.将显示给用户的数据发送至安全模块(通常是SIM)。
防止应用软件执行上述步骤3,而没有为用户显示与为加密或数字签署而发送的完全相同的信息。
固件使支付人设备自身免受软件攻击。通过各种无线接口,设备可能对病毒和蠕虫攻击是开放的。设计就是确保为应用软件提供的用来向SIM发送数据的任何接口专门防止“支付批准”消息被发送到SIM。只有支付批准显示例程才能够发送该响应。这确保了消费者看到,并且物理上按下某一最小形式的“OK”按钮,来批准每笔交易。
过滤器阻止应用软件向安全模块或SIM直接发出“生成签名”命令。
设置标准
该***有许多可能的结构。对于任何部署,都需要确定在要部署该***的市场中哪种无线和加密标准是最适用的。由全球多个标准引起的问题是,当消费者移动到例如他们自己的支付人设备由于不同标准而无法通信的区域中时,他们将面对以下选择:1)获得针对他们所移动到的区域的支付人设备,或者2)他们可能需要临时禁能该***。
目前,GSM是首选的全球***,但是,例如在日本iMode***将是合理的选择。
***部署
为了最初部署***,需要至少一个银行(或其他发卡者)和一个移动电话***运营商协同来部署该***。
移动电话私***运营商的角色
●移动电话运营商设置标准并要求至少一个移动电话供应商并入所述固件。
●然后移动电话运营商通过销售电话和移动电话运营商的定制服务的零售商来推广经改装的电话、SIM和匹配非接触式智能卡的包。
●移动电话的SIM的制造商将通过本文提供的说明而具备制造适当的SIM和非接触式卡的所有知识。网络运营商将这些指令传送给
SIM供应商并且定购SIM。
●移动电话运营商必须(直接或通过网关运营商)提供计算机***,以接收支付批准请求并将它们发送给它们的定购者。
发卡机构的角色
●发卡机构向持卡人推广服务。
●发卡机构的零售部门提供服务以利用消费者所持有的卡的详细信息来初始化支付人设备。
电话运营商变为发卡机构的另选模型
移动电话运营商或移动电话运营商所使用的独立网关可变为发卡机构,而不需要提供借记或信用设备。所发行的卡将简单地链接到消费者现有的借记或信用帐户,但将具有链接到来自多个发卡机构的帐户的能力。
所发行的卡将使授权请求路由回到网关,从而为发卡机构节省了新的基础设施。
在许多国家,移动电话运营商还为卡处理中心提供服务和基础设施。
支付人设备软件
以下功能应该添加到标准移动电话或其他袖珍计算机设备中,以得到本发明的一个实施例。为了例示,与实施有关的详细信息限于GSM移动电话的优选实施例。
支付屏幕
支付屏幕应该具有不能由载入到设备中的任何新应用软件模仿的唯一识别特征。例如,“支付线”具有红框(solid red)背景,电话的固件防止任何应用来绘制类似的红框横幅标题(banner)。该措施是为了阻止病毒程序获知卡PIN。
软件组件
支付人设备实施例中需要以下软件组件。
●来自网络的支付请求消息。
●发往SIM的支付请求消息。
●支付请求数据输入屏幕。
●发往SIM的支付请求屏幕数据消息。
●来自SIM的支付请求响应。
●从SIM传递到网络的支付请求响应。
●来自网络的支付收到响应。
●支付屏幕选项菜单。
●支付选项菜单。
支付请求消息
GSM移动电话所用的简单方法是接收支付请求,作为加特别标记的SMS消息。
可简单地将支付请求消息直接传送至SIM模块。
电话启动支付
支付人设备可用于启动对特定人或商行(business)的支付。选择进行支付的人的简单方式是通过电话号码。
这种支付方法易于出错-有可能支付给错误的人。因此,建议(但不必须)所支付的号码是存储在电话的电话簿中的已有条目。
输入金额作为支付画面之一
来自支付屏幕的选项
●选择帐户。
●传递。
来自空闲设备的支付菜单
●默认帐户。
●查看交易。
●启动支付。
支付设备类型和技术
使用“成对”通信的自适应***
为局域无线通信提出了改进的局域无线通信。诸如蓝牙的局域无线通信可发生在彼此已知的设备之间或发生在未被预设为彼此对话的设备之间。优选的是,可将通信限定为在处理中先前已彼此识别为“成对”的设备。每个设备都具有能够成对的唯一网络ID。
由于支付人设备在许多场合的支付点处使用并且经常以自组织(adhoc)为基础,所以最初似乎无法进行成对通信。
利用用于启动交易的近程通信可以克服这个问题。对于每个支付人设备,可以发行具有唯一标识的支付蓝牙设备的“幻象”点。支付人设备可与该支付点成对。然而,网络标识符被简单地保留并记录在非接触式智能卡上,而不是提供实际支付点作为实际成对的设备。当实际的支付点检测到用于支付人设备的智能卡时,支付点的局域无线通信从非接触式卡读取所需的网络标识符并采用该标识。这样,支付点就变为支付人设备的成对设备。
新支付点
饭店钱夹
电子支付点可构造为用于为消费者呈现可支付金额的饭店钱夹的形式,或饭店中通常使用的支付箱(receptacle)的形式。目前,消费者***他们的***或支付所需现金进行支付。在提供卡支付的情况下,饭店工作人员必须履行另外的步骤,并且消费者必须等待。工作人员和消费者都感到不便。通过使用支付人设备并且将电子支付点内置在支付箱中,消费者可自己支付而不用等待,并可以在他们之间分开支付,而无需要求饭店工作人员辅助这样的复杂操作,消费者和饭店工作人员都从中受益。
根据示例性实施例的***的其他细节:
样本画面
---------------
Pay:Meter
$2.20
for 20mins
------------
Pay:Food
$50:70
15%tip
****
------------
pay:
DJs books
$29.95
**** ←------PIN ENTRY
-----------
样本消息
支付请求
该消息将从网络发送至电话。
字段
字段 | 用途 |
Amount | 要支付的金额-或者,对于单位支付-单价 |
Payto text | 要被支付的商行或人的文本表示 |
Payto# | 要被支付的商行或人的电话号码 |
Unit Text | 可达4个字符,指定了用于单位支付的单位 |
Minimum unit | 支付必须匹配多个这样的单位 |
Flag:allow increase | |
Flag:allow decrease |
Amount:请求要支付的金额(或其相关的-单价)。
Payto:要被支付的人或组织的文本表示。
Payto#:要被支付的人或组织的电话号码。
Unit Text:可达3个字符,显示了要购买的物品的单位(如果无关,则为空)。
Minimum unit:如果无关,则为0。
Flag-vary up amount?:是否有相应的小费以及是否可以增加金额。
Flag-vary down amount?:是否可以减少金额。
支付交易流程
现有的磁卡交易
步骤 | 设备 | 注释 |
刷卡 | ||
输入金额 | ||
向银行发送Txn | ||
银行开始确认 | 参见下文的“支付确认步骤” | |
支付确认步骤
步骤 | 设备 | 注释 |
根据示例性实施例的***的特征:
1.利用消费者携带的无线设备进行支付确认。
2.利用消费者携带的安全无线设备进行支付确认。
3.利用消费者携带的安全无线设备对本人的支付进行支付确认。
4.利用可从设备得到的支付选项通过消费者携带的安全无线设备进行支付确认。
非接触式卡启动
●利用消费者携带的无线设备进行支付确认。
●利用消费者携带的安全无线设备进行支付确认。
●利用消费者携带的安全无线设备对本人的支付进行支付确认。
●利用可从设备得到的支付选项通过消费者携带的安全无线设备进行支付确认。
消费者携带的用于交易的安全确认的无线设备由以下卡启动:
●非接触式智能卡。
●磁式信用借记卡。
●智能卡信用借记卡。
●混合的磁/智能卡借记/***。
支付特征
●电话屏幕上的PIN输入模式。
●发往SIM的受保护支付命令。
●带有%和单位选项的支付画面。
网关
●执行移动电话通信网关中所述的三个任务中任何一个的通信网关通信。
●用于蓝牙或其他“成对”通信***的自适应***。
●带有用于支付人设备的接口的支付点。
●输入特定电话号码后发出拨号音(touch tone)的移动电话。
●通过移动电话利用语音通信来识别要被支付的支付点而进行支付。
对本领域技术人员显而易见的是,修改和变型将视为落入本发明的范围内。
Claims (150)
1、一种进行支付的方法,该方法包括以下步骤:
提供与支付人相关联的信息,所述信息以使受付人能够访问所述信息的方式来提供,
通过与所述支付人相关联的支付人电子设备来接收与所述支付有关的信息,以及
使用与所述支付人相关联的所述电子设备来给出进行支付的指令。
2、根据权利要求1所述的方法,其中所述与支付有关的信息包括支付信息,并且所述方法还包括所述支付人电子设备识别与所述支付相关联的支付信息的步骤。
3、根据权利要求2所述的方法,其中给出指令的所述步骤包括所述支付人电子设备生成包括支付信息的消息并将该消息发送至交易处理***的步骤。
4、根据权利要求2或权利要求3所述的方法,其中所述支付信息包括产品的价格。
5、根据权利要求2、3或4所述的方法,其中所述支付信息包括产品的标识。
6、根据权利要求2至5中任意一项所述的方法,其中所述支付信息包括所述受付人的支付标识,从而所述交易处理***能够向所述受付人的帐户进行支付。
7、根据权利要求2至6中任意一项所述的方法,其中所述支付人电子设备包括显示器,并且所述方法还包括将所述支付人电子设备设置为在所述显示器上显示支付信息的步骤。
8、根据以上权利要求中任意一项所述的方法,其中所述与支付有关的信息包括支付金额,并且其中所述方法还包括所述支付人电子设备变更所述支付金额的步骤。
9、根据权利要求8所述的方法,其中所述支付人电子设备包括用户输入装置,并且变更所述支付金额的所述步骤包括用户通过所述输入装置输入变更后的支付金额的步骤。
10、根据以上权利要求中任意一项所述的方法,其中所述与支付有关的信息包括列表形式的产品信息,所述列表包括至少一个产品标识符,并且所述方法包括所述支付人电子设备选择至少一个产品标识符的步骤,所述与支付人相关联的信息包括所选择的产品标识符。
11、根据权利要求10所述的方法,其中所述列表包括多个所述产品标识符,这些产品标识符包括所述受付人提供的产品的菜单,从而所述支付人电子设备可以选择所述产品中的一个或更多个,使得所述受付人能够提供所述产品。
12、根据权利要求10或权利要求11所述的方法,其中支付人可通过网络得到所述列表,以将其上载到所述支付人电子设备。
13、根据权利要求12所述的方法,其中所述网络是诸如互联网的广域网。
14、根据以上权利要求中任意一项所述的方法,其中通过所述支付人电子设备来接收与所述支付有关的信息的所述步骤包括从无源设备接收与所述支付有关的信息的步骤。
15、根据权利要求14所述的方法,其中所述无源设备是可光读取的设备。
16、根据权利要求15所述的方法,其中所述可光读取的设备是条形码。
17、根据权利要求14、15或16所述的方法,其中作为***的一部分来提供所述无源设备。
18、根据权利要求14、15或16所述的方法,其中所述无源设备与出售的产品一起提供。
19、根据权利要求14至18中任意一项所述的方法,其中所述与支付有关的信息包括以下指令,所述指令用于利用应用来控制所述支付人电子设备以提供进行所述支付的指令。
20、根据权利要求19所述的方法,其中所述与支付有关的信息包括位置信息,该位置信息标识了支付人电子设备能获得要上载到所述支付人电子设备的所述应用的位置。
21、根据以上权利要求中任意一项所述的方法,其中接收与所述支付有关的信息的步骤包括从与所述受付人相关联的受付人电子设备接收所述信息。
22、根据权利要求21所述的方法,其中所述与支付人相关联的信息包括使所述受付人电子设备能够与所述支付人电子设备进行通信的支付人电子设备信息。
23、根据权利要求22所述的方法,其中所述支付人电子设备信息由与所述支付人电子设备相关联的访问设备来提供。
24、根据权利要求23所述的方法,其中所述访问设备是智能卡。
25、根据权利要求23或权利要求24所述的方法,其中所述访问设备与所述支付人电子设备一体化。
26、根据权利要求22至25中任意一项所述的方法,其中所述受付人电子设备与所述支付人电子设备之间的通信是通过局域无线网络进行的。
27、根据权利要求22至26中任意一项所述的方法,其中所述支付人电子设备与所述受付人电子设备之间的通信是通过电话网络进行的。
28、根据权利要求27所述的方法,其中所述电话网络包括移动电话网络。
29、根据以上权利要求中任意一项所述的方法,其中给出进行支付的指令的所述步骤包括所述支付人电子设备提供包含支付金额和所述受付人的支付标识的指令,并将所述指令发送至交易处理***。
30、根据权利要求29所述的方法,其中直接将所述指令从所述支付人电子设备发送至所述交易处理***。
31、根据权利要求29所述的方法,其中经由受付人电子设备将所述指令发送至所述交易处理***。
32、根据以上权利要求中任意一项所述的方法,其中用于进行支付的所述指令包括发送至交易处理***的表示应该进行所述支付的确认。
33、根据权利要求32所述的方法,该方法包括由所述支付人电子设备生成所述确认的步骤。
34、根据权利要求33所述的方法,其中所述支付人电子设备包括输入装置,并且生成确认的所述步骤包括要求用户通过所述输入装置进行输入使得能够生成所述确认的步骤。
35、根据权利要求34所述的方法,其中所述要求步骤由所述支付人电子设备所提供的应用来执行。
36、根据权利要求35所述的方法,其中所述应用在所述支付人电子设备中的固件内实现。
37、根据权利要求34、35或36所述的方法,其中所述支付人电子设备包括显示器,并且所述要求步骤要求所述用户通过所述输入装置认可出现在所述显示器上的与所述支付有关的信息。
38、根据权利要求32至37中任意一项所述的方法,其中所述确认包括编码信息。
39、根据权利要求38所述的方法,其中所述编码信息是数字签名。
40、根据以上权利要求中任意一项所述的方法,其中所述与支付人相关联的信息包括所述支付人的帐户的帐户标识符。
41、根据权利要求40所述的方法,其中所述帐户标识符由提供诸如***的卡的所述支付人来提供。
42、根据权利要求40所述的方法,其中所述帐户标识符是帐户10的一部分,并且其中交易处理***存储有帐户10的其他部分。
43、根据权利要求42所述的方法,其中所述部分帐户10是由所述支付人电子设备以加密形式提供的。
44、根据以上权利要求中任意一项所述的方法,其中所述与支付有关的信息包括一个或更多个应用,所述一个或更多个应用包括指令,所述指令用于控制所述支付人电子设备来提供进行所述支付的指令。
45、根据权利要求44所述的方法,所述方法还包括从网络将所述一个或更多个应用上载到所述支付人电子设备的步骤。
46、根据以上权利要求中任意一项所述的方法,其中所述与支付人相关联的信息是对支付已发生的确认。
47、根据以上权利要求中任意一项所述的方法,其中所述与支付人相关联的信息包括所述支付人的标识。
48、根据以上权利要求中任意一项所述的方法,其中给出进行所述支付的指令的所述步骤包括所述支付人电子设备通过向交易处理***提供预批准指令在所述支付交易发生之前对所述支付进行预批准。
49、根据以上权利要求中任意一项所述的方法,其中所述支付人电子设备是便携式设备。
50、根据权利要求49所述的方法,其中所述便携式设备是掌上型计算机。
51、根据权利要求49或50所述的方法,其中所述便携式设备是移动电话。
52、一种处理支付交易的方法,该方法包括以下步骤:交易处理***从与支付人相关联的支付人电子设备接收进行支付的指令;所述交易处理***授权支付;以及所述交易处理***提供支付转帐已被授权的确认。
53、根据权利要求52所述的方法,其中接收指令的所述步骤包括从支付人电子设备接收消息的步骤,所述消息包括支付信息。
54、根据权利要求53所述的方法,其中所述支付信息包括支付金额和所述受付人的支付标识。
55、根据权利要求52、53或54所述的方法,其中提供支付确认的所述步骤包括所述交易处理***将所述支付确认发送至受付人电子设备的步骤。
56、根据权利要求52至55中任意一项所述的方法,其中提供支付确认的所述步骤包括所述交易处理***将所述支付确认发送至支付人电子设备的步骤。
57、根据权利要求56所述的方法,其中所述支付人电子设备包括显示器,并且提供支付确认的所述步骤包括提供所述确认,使之出现在所述支付人电子设备的所述显示器上。
58、根据权利要求57所述的方法,其中出现在所述显示器上的所述支付确认为机器可读形式,并且能够由受付人电子设备读取。
59、根据权利要求58所述的方法,其中所述机器可读形式是条形码。
60、根据权利要求52至59中任意一项所述的方法,该方法还包括从所述支付人电子设备接收产品信息的步骤,所述产品信息标识了要被支付的受付人的至少一个产品。
61、根据权利要求60所述的方法,该方法包括所述交易处理***将所述产品信息发送至受付人电子设备从而所述受付人可以将所述产品提供给所述支付人的步骤。
62、根据权利要求60或权利要求61所述的方法,该方法包括将产品列表上载到所述支付人电子设备的步骤,所述产品列表包括可由所述支付人电子设备选择的受付人的至少一个产品。
63、根据权利要求62所述的方法,该方法包括提供产品列表的数据库以便上载到支付人电子设备的步骤,每个产品列表都包括可由支付人电子设备选择的相应受付人的至少一个产品。
64、根据权利要求52至63中任意一项所述的方法,该方法包括将应用上载到所述支付人电子设备的步骤,所述应用包括指令,所述指令用于控制所述支付人电子设备来提供进行所述支付的指令。
65、根据权利要求64所述的方法,该方法包括提供包括应用的数据库以便上载到所述支付人电子设备的步骤,所述应用具有指令,所述指令用于控制支付人电子设备来提供进行支付的指令。
66、根据权利要求52至65中任意一项所述的方法,其中用于进行支付的所述指令包括来自所述支付人电子设备的表示应该进行所述支付的确认。
67、根据权利要求66所述的方法,其中所述确认是编码消息。
68、根据权利要求67所述的方法,其中所述编码消息是数字签名。
69、根据权利要求66、67或68所述的方法,其中所述支付人电子设备生成所述确认需要用户启动所述支付人电子设备的输入装置。
70、根据权利要求66至69中任意一项所述的方法,该方法包括所述交易处理***向所述支付人电子设备发送进行确认的请求的步骤。
71、根据权利要求52至70中任意一项所述的方法,其中用于进行支付的所述指令包括支付人帐户信息。
72、根据权利要求71所述的方法,其中所述支付人帐户信息包括帐户标识符的一部分,并且其中所述交易处理***存储有该帐户标识符的其余部分,从而当所述交易处理***从所述支付人电子设备接收到所述部分时能识别所述支付人帐户。
73、根据权利要求52至72中任意一项所述的方法,其中用于进行支付的所述指令包括用于对随后要发生的支付进行预批准的预批准指令,并且所述方法包括所述交易处理***存储所述预批准指令的步骤。
74、根据权利要求52至73中任意一项所述的方法,其中用于进行支付的所述指令是从来自支付人电子设备的发送而直接接收到的。
75、根据权利要求52至73中任意一项所述的方法,其中用于进行支付的所述指令是经由受付人电子设备从由所述支付人电子设备到所述受付人电子设备的发送而间接接收到的。
76、根据权利要求52至74中任意一项所述的方法,其中所述支付人电子设备是便携式设备。
77、根据权利要求76所述的方法,其中所述便携式设备是掌上型计算机。
78、根据权利要求76或77所述的方法,其中所述便携式设备是移动电话。
79、一种便于从支付人到受付人进行支付交易的设备,该设备包括与所述支付人相关联的支付人电子设备,所述支付人电子设备包括用于接收与所述支付有关的信息的支付信息接收装置和用于给出进行所述支付的指令的支付指令发出装置。
80、根据权利要求79所述的设备,其中所述支付人电子设备包括用于识别支付信息的支付处理装置。
81、根据权利要求80所述的设备,其中所述支付人电子设备包括用于生成包括支付信息的消息的消息发出装置和用于将所述消息发送至交易处理***的发送装置。
82、根据权利要求81所述的设备,其中所述支付信息包括支付金额。
83、根据权利要求81或权利要求82所述的设备,其中所述支付信息包括产品的标识。
84、根据权利要求81、82或83所述的设备,其中所述支付信息包括所述受付人的支付标识,从而便于所述交易处理***处理对于所述受付人帐户的支付。
85、根据权利要求79至84中任意一项所述的设备,其中所述支付人电子设备包括显示器,并用于显示支付信息。
86、根据权利要求79至85中任意一项所述的设备,其中所述与支付有关的信息包括支付金额,并且其中所述支付人电子设备包括使所述用户能够变更所述支付金额的输入装置。
87、根据权利要求79至86中任意一项所述的设备,其中所述与支付有关的信息包括产品信息,所述产品信息包括至少一个产品标识符,并且所述支付人电子设备包括用于选择至少一个产品标识符以发送至受付人的选择装置。
88、根据权利要求87所述的设备,其中所述产品信息为列表形式,所述列表包括所述支付人电子设备可以从中进行选择的多个产品标识符。
89、根据权利要求87或权利要求88所述的设备,其中所述支付人电子设备用于从能获得所述产品信息的数据库上载所述产品信息。
90、根据权利要求79至89中任意一项所述的设备,其中所述支付人电子设备包括用于从无源设备读取与所述支付有关的信息的读取装置。
91、根据权利要求90所述的设备,其中所述无源设备是可光读取的设备,并且所述读取装置包括光读取器。
92、根据权利要求91所述的设备,其中所述可光读取的设备是条形码。
93、根据权利要求91或权利要求92所述的设备,其中所述读取装置包括相机。
94、根据权利要求91至93中任意一项所述的设备,其中所述读取装置用于识别提供了与所述支付有关的信息的无源设备。
95、根据权利要求79至94中任意一项所述的设备,所述支付人电子设备还包括用于和受付人电子设备进行通信的通信装置。
96、根据权利要求95所述的设备,其中所述通信装置包括使得能够通过局域无线网络进行通信的装置。
97、根据权利要求95或权利要求96所述的设备,所述支付人电子设备包括用于向所述受付人电子设备提供信息以使得能够在所述受付人电子设备和所述支付人电子设备之间进行通信的访问设备。
98、根据权利要求97所述的设备,其中所述访问设备是智能卡。
99、根据权利要求97或权利要求98所述的设备,其中所述访问设备与所述支付人电子设备一体化。
100、根据权利要求95至99中任意一项所述的设备,其中所述支付人电子设备包括用于向交易处理***发送进行所述支付的指令的发送装置,所述发送装置用于经由所述受付人电子设备来发送所述指令。
101、根据权利要求79至100中任意一项所述的设备,所述支付人电子设备包括远程发送装置,该远程发送装置用于将进行所述支付的指令发送至交易处理***。
102、根据权利要求101所述的设备,其中所述远程发送装置是用于经由移动电话网络来发送信号的发送器。
103、根据权利要求79至102中任意一项所述的设备,其中用于进行所述支付的指令包括发送到交易处理***的表示应该进行所述支付的确认,并且所述支付指令发出装置包括用于生成所述确认的确认生成装置。
104、根据权利要求103所述的设备,其中所述支付人电子设备包括输入装置,并且要使所述确认生成装置生成所述确认需要通过所述输入装置的用户输入。
105、根据权利要求104所述的设备,其中所述确认生成装置部分地或全部地由固件来实现。
106、根据权利要求104或权利要求105所述的设备,其中所述支付人电子设备包括显示器,并且所述确认生成装置要求所述用户通过所述输入装置认可出现在所述显示器上的与所述支付有关的信息,以便为其生成确认。
107、根据权利要求104、105或106所述的设备,其中所述确认生成装置用于生成编码信息形式的确认。
108、根据权利要求107所述的设备,其中所述编码信息是数字签名。
109、根据权利要求79至108中任意一项所述的设备,所述支付人电子设备包括用于存储至少一个应用的存储装置,所述应用包括指令,所述指令用于控制所述支付指令发出装置来给出进行所述支付的指令。
110、根据权利要求109所述的设备,所述支付人电子设备用于从数据库上载所述至少一个应用。
111、根据权利要求74至110中任意一项所述的设备,其中用于进行所述支付的指令包括标识了所述支付人的帐户的帐户标识符。
112、根据权利要求111所述的设备,其中所述帐户标识符包括帐号的一部分,并且其中交易处理***存储有该帐号的其他部分。
113、根据权利要求79至112中任意一项所述的设备,其中用于进行所述支付的指令包括预批准,该预批准用于授权对于后续支付交易的支付。
114、一种用于处理支付交易的交易处理***,该***包括:支付指令接收装置,用于从与支付人相关联的支付人电子设备接收用于从所述支付人到受付人进行支付的指令;以及支付处理装置,用于授权从支付人帐户到受付人帐户的资金转帐。
115、根据权利要求114所述的交易处理***,该交易处理***还包括用于确认支付已经发生的支付确认装置。
116、根据权利要求115所述的***,其中所述支付确认装置用于将支付确认发送至与所述受付人相关联的受付人电子设备。
117、根据权利要求115或权利要求116所述的***,其中所述支付确认装置用于将支付确认发送至所述支付人电子设备。
118、根据权利要求117所述的***,其中所述支付人电子设备包括显示器,并且所述支付确认装置提供所述支付确认,使之出现在所述支付人电子设备的所述显示器上。
119、根据权利要求118所述的***,其中出现在所述显示器上的所述支付确认为机器可读形式,并且能够由受付人电子设备读取。
120、根据权利要求119所述的***,其中所述机器可读形式是条形码。
121、根据权利要求114至120中任意一项所述的***,该***还包括用于从所述支付人电子设备接收产品信息的产品信息接收装置,所述产品信息标识了要被支付的受付人的至少一个产品。
122、根据权利要求121所述的***,该***还包括用于将所述产品信息发送至受付人电子设备,从而所述受付人可以将所述产品提供给所述支付人的产品信息发送装置。
123、根据权利要求121或122所述的***,该***还包括产品列表的数据库,并且使得能够将产品列表上载到支付人电子设备,每个产品列表都包括可由支付人电子设备选择的相应受付人的至少一个产品。
124、根据权利要求114至123中任意一项所述的***,该***还包括数据库,所述数据库包括用于上载到所述支付人电子设备的一个或多个应用,所述一个或更多个应用包括指令,所述指令用于控制所述支付人电子设备来提供进行支付的指令。
125、根据权利要求114至124中任意一项所述的***,其中用于进行所述支付的指令包括来自所述支付人电子设备的表示应该进行所述支付的确认。
126、根据权利要求125所述的***,其中所述确认为编码形式,并且所述***包括用于对所述指令进行解码的装置。
127、根据权利要求126所述的***,其中所述编码形式是数字签名。
128、根据权利要求114至127中任意一项所述的***,其中用于进行所述支付的指令包括支付人帐户信息,该支付人帐户信息包括帐户标识符的一部分,并且所述***还包括存储有所述帐户标识符的其余部分的数据库,从而能够识别所述支付人帐户。
129、根据权利要求114至128中任意一项所述的***,该***还包括存储有预批准指令的预批准数据库,所述预批准指令用于对随后发生的支付进行预批准。
130、一种便于处理交易的设备,该设备包括用于和根据权利要求114至129中任意一项所述的交易处理***进行通信的受付人电子设备。
131、根据权利要求130所述的设备,该设备用于接收标识了至少一个产品的产品信息。
132、根据权利要求131所述的设备,该设备包括用于打印所述产品列表的装置。
133、一种***,该***包括:根据权利要求79至99中任意一项所述的设备;根据权利要求115至129中任意一项所述的***;以及根据权利要求130至132中任意一项所述的设备。
134、一种数据库,该数据库包括支付人电子设备可得到的多个产品列表,从而所述支付人电子设备可以从所述产品列表中选择一个或更多个产品,发送给受付人,以满足产品需求。
135、一种无源设备,该无源设备可由支付人电子设备读取,以便于进行支付交易。
136、根据权利要求135所述的设备,其中所述无源设备是条形码。
137、根据权利要求135或权利要求136所述的设备,其中所述无源设备包括使得所述支付人电子设备能够处理支付的支付信息。
138、根据权利要求135至137中任意一项所述的设备,其中所述无源设备包括产品列表,该产品列表列出了供所述支付人电子设备选择的至少一个产品。
139、根据权利要求135或136所述的设备,其中所述无源设备与产品相关联,并且提供以下信息,该信息使得支付人电子设备能够令支付所述产品的交易更加便利。
140、根据权利要求139所述的设备,其中所述无源设备粘贴在所述产品上或产品包装上。
141、根据权利要求135至138中任意一项所述的设备,其中所述无源设备是饭店或餐馆内的菜单的一部分。
142、根据权利要求135至140中任意一项所述的设备,其中所述无源设备包括标识了应用的信息,所述支付人电子设备利用所述应用来使得支付交易更加便利。
143、一种无源设备,该无源设备包括标识了应用的信息,电子设备利用所述应用来处理与所述无源设备相关联的信息。
144、根据权利要求143所述的设备,其中所述无源设备是条形码。
145、一种计算机程序,该计算机程序包括用于控制计算设备以实施根据权利要求1至51中任意一项所述的方法的指令。
146、一种提供了根据权利要求145所述的计算机程序的计算机可读介质。
147、一种计算机程序,该计算机程序包括用于控制计算设备以实施根据权利要求52至78中任意一项所述的方法的指令。
148、一种提供了根据权利要求147所述的计算机程序的计算机可读介质。
149、一种启动软件应用的方法,该方法包括以下步骤:利用包括标识了软件应用的位置的信息的无源设备;将所述信息上载到用户设备;以及利用所述用户设备从远程位置获得所述应用。
150、一种组织队列的方法,该方法包括以下步骤:向用户移动电话提供信息,该信息表示了用户在所述队列内的位置;以及随着所述用户在所述队列中位置的移动而更新所述信息。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU2004903470A AU2004903470A0 (en) | 2004-06-25 | A system and method of making a payment | |
AU2004903470 | 2004-06-25 | ||
AU2004903997 | 2004-07-19 | ||
AU2004904941 | 2004-08-30 | ||
AU2005901230 | 2005-03-14 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1989520A true CN1989520A (zh) | 2007-06-27 |
Family
ID=38185459
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2005800251668A Pending CN1989520A (zh) | 2004-06-25 | 2005-06-24 | 交易处理方法、设备以及*** |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN1989520A (zh) |
ZA (1) | ZA200700671B (zh) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101685512A (zh) * | 2008-09-28 | 2010-03-31 | ***股份有限公司 | 一种用于实现网上支付的计算机、支付***及其方法 |
CN101853342A (zh) * | 2009-03-30 | 2010-10-06 | 宋煜燊 | 保护隐私的反身份窃取和支付网络 |
CN101939963A (zh) * | 2007-12-07 | 2011-01-05 | 法国电信公司 | 用于控制在与移动终端相关联的安全模块上安装的应用的方法、相关联的安全模块、移动终端、和服务器 |
CN101123454B (zh) * | 2007-09-21 | 2011-04-20 | 北京交通大学 | 基于蓝牙的手机银联卡数据传输方法及*** |
CN102298758A (zh) * | 2010-06-22 | 2011-12-28 | 安智金融与工业公司 | 协助检查交易记录的方法及其相关设备和计算机程序 |
CN103679458A (zh) * | 2013-12-04 | 2014-03-26 | 天地融科技股份有限公司 | 处理交易数据的方法和智能卡 |
CN105187448A (zh) * | 2015-09-30 | 2015-12-23 | 宇龙计算机通信科技(深圳)有限公司 | 一种服务处理方法及服务设备 |
CN105678527A (zh) * | 2016-02-05 | 2016-06-15 | 胡金钱 | 一种基于指纹和人脸的银行业务远程身份验证***和方法 |
CN103679458B (zh) * | 2013-12-04 | 2016-11-30 | 天地融科技股份有限公司 | 处理交易数据的方法和智能卡 |
CN107004196A (zh) * | 2014-12-19 | 2017-08-01 | 脸谱公司 | 促成发送和接收个人对企业支付 |
CN108369671A (zh) * | 2015-10-27 | 2018-08-03 | 万事达卡国际公司 | 用于更新存储的持卡人账户数据的***和方法 |
-
2005
- 2005-06-24 ZA ZA200700671A patent/ZA200700671B/xx unknown
- 2005-06-24 CN CNA2005800251668A patent/CN1989520A/zh active Pending
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101123454B (zh) * | 2007-09-21 | 2011-04-20 | 北京交通大学 | 基于蓝牙的手机银联卡数据传输方法及*** |
CN101939963A (zh) * | 2007-12-07 | 2011-01-05 | 法国电信公司 | 用于控制在与移动终端相关联的安全模块上安装的应用的方法、相关联的安全模块、移动终端、和服务器 |
CN101685512A (zh) * | 2008-09-28 | 2010-03-31 | ***股份有限公司 | 一种用于实现网上支付的计算机、支付***及其方法 |
CN101853342A (zh) * | 2009-03-30 | 2010-10-06 | 宋煜燊 | 保护隐私的反身份窃取和支付网络 |
CN102298758A (zh) * | 2010-06-22 | 2011-12-28 | 安智金融与工业公司 | 协助检查交易记录的方法及其相关设备和计算机程序 |
CN103679458B (zh) * | 2013-12-04 | 2016-11-30 | 天地融科技股份有限公司 | 处理交易数据的方法和智能卡 |
CN103679458A (zh) * | 2013-12-04 | 2014-03-26 | 天地融科技股份有限公司 | 处理交易数据的方法和智能卡 |
CN107004196A (zh) * | 2014-12-19 | 2017-08-01 | 脸谱公司 | 促成发送和接收个人对企业支付 |
CN105187448A (zh) * | 2015-09-30 | 2015-12-23 | 宇龙计算机通信科技(深圳)有限公司 | 一种服务处理方法及服务设备 |
WO2017054287A1 (zh) * | 2015-09-30 | 2017-04-06 | 宇龙计算机通信科技(深圳)有限公司 | 一种服务处理方法及服务设备 |
CN108369671A (zh) * | 2015-10-27 | 2018-08-03 | 万事达卡国际公司 | 用于更新存储的持卡人账户数据的***和方法 |
US11687893B2 (en) | 2015-10-27 | 2023-06-27 | Mastercard International Incorporated | Systems and methods for updating stored cardholder account data |
CN108369671B (zh) * | 2015-10-27 | 2024-01-05 | 万事达卡国际公司 | 用于更新存储的持卡人账户数据的***和方法 |
CN105678527A (zh) * | 2016-02-05 | 2016-06-15 | 胡金钱 | 一种基于指纹和人脸的银行业务远程身份验证***和方法 |
Also Published As
Publication number | Publication date |
---|---|
ZA200700671B (en) | 2008-10-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200193440A1 (en) | Transaction processing method, apparatus and system | |
US9805362B2 (en) | Mobile devices for activating instant disposable payment cards | |
US20160104157A1 (en) | Method for producing a transaction signal | |
US9235841B2 (en) | Transaction security apparatus and method | |
US20130097078A1 (en) | Mobile remote payment system | |
US20100153269A1 (en) | System, method, apparatus and computer program product for interfacing a multi-card radio frequency (rf) device with a mobile communications device | |
US9489662B2 (en) | Apparatus and method for storing electronic receipts on a unified card or smartphone | |
CN108027925B (zh) | 一种使用二维码的无卡支付方法及其*** | |
CN1989520A (zh) | 交易处理方法、设备以及*** | |
MX2011003425A (es) | Sistemas, metodos, y medio leible por computadora para la transferencia de tarjeta virtual de pago y no pago entre dispositivos moviles. | |
WO2008103871A1 (en) | Transfer of value between mobile devices in a mobile commerce system | |
WO2008103879A2 (en) | Provisioning of a device for mobile commerce | |
WO2008103882A2 (en) | Enrollment and registration of a device in a mobile commerce system | |
WO2008103883A1 (en) | Marketing messages in mobile commerce | |
WO2008112402A1 (en) | Account information lookup systems and methods in mobile commerce | |
JP2005092338A (ja) | 電子決済システムおよびレジスター装置 | |
JP2004507000A (ja) | Wapにより資金記憶装置から電子的な金額を伝送するための方法及び装置 | |
JP2006331152A (ja) | 決済システム | |
WO2013115703A2 (en) | A mobile delivery method and a system therefore | |
JP2003006549A (ja) | 指紋認証装置を搭載した携帯電話による現金支払システムと方法 | |
AU2013203552A1 (en) | A transaction processing method, apparatus and system | |
AU2011253607B2 (en) | A transaction processing method, apparatus and system | |
AU2017276353A1 (en) | A transaction processing method, apparatus and system | |
AU2015218423A1 (en) | Systems, methods, and computer readable media for payment and non-payment virtual card transfer between mobile devices | |
AU2005256142A1 (en) | A transaction processing method, apparatus and system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20070627 |