專利名稱：多方受益的在線認證服務的制作方法
技術領域：
本發(fā)明通常涉及在在線交易期間認證帳戶持有者的身份，具體涉及與增值方一起共享和使用與認證過程有關的信息的技術。
背景技術：
在使用支付卡(如信用卡、借記卡或儲值卡)的支付交易期間，查證持卡者的帳戶所有權以避免各種問題(如未授權使用)是重要的。支付者認證是查證持卡者的帳戶所有權的過程。認證持卡者的帳戶所有權的最常用的方法日常發(fā)生在被稱之為“提交卡”交易期間的銷售點處。提交卡交易包括商家代理收取持卡者的卡，將卡刷過支付卡終端以查證帳戶狀態(tài)和信用額度的有效性，而后核對檢查卡背面的簽名與購物者的簽名相匹配。如果商家遵循這類交易的特定準則，則商家將被保證授權的較小折扣和費用支付量。服務提供商，如Visa國際服務協(xié)會(或服務組織)，可提供這些特定準則。
另一方面，“不提交卡”交易(如那些在線發(fā)生的、通過郵寄的、或通過電話的交易)包括未向商家保證的支付。提供未保證主要是因為在這種非面對面交易中未對支付者進行認證，從而使“不提交卡”交易伴隨有許多的風險。這樣的風險包括的問題比如對在線商家的支付交易的扣款、對商家和持卡者的欺詐行為、增加的銀行例外項目處理開支、以及增加的在線購買貨物和服務是不安全可靠的感覺，而這樣的感覺使某些消費者避開在線購買。風險的具體實例包括未授權使用盜竊的帳戶信息在線購買貨物和服務、偽造卡帳號進行欺詐的在線購物、以及從網(wǎng)絡流量中提取明文帳戶信息。
考慮到持續(xù)的預計的電子商務的高增長的條件下，提供認證支付者的方法是很重要的。考慮到在線交易類型的廣度，提供認證當事人身份的方法也是很重要的，不管交易是否存在有商業(yè)特點。這將使從持卡者、商家、金融機構(gòu)到政府機構(gòu)的所有交易參與者受益。在在線交易期間認證客戶將減低欺詐、爭議、補款和扣款的程度，這隨后將降低與這些事件的每一個相關聯(lián)的成本。認證客戶還解決了安全問題并且因此將導致增加的在線活動。現(xiàn)有的用來在在線交易期間認證當事人的系統(tǒng)已經(jīng)不再被廣泛采用，因為這些系統(tǒng)難于使用、具有復雜的設計、要求系統(tǒng)參與者提前投入相當大的投資并且缺少互用性。某些現(xiàn)有系統(tǒng)另外要求商家、持卡者、發(fā)行機構(gòu)和讓受方的證書的創(chuàng)建、分發(fā)和使用。這種證書的使用已知是非常繁重的。
考慮到上述的觀點，要繼續(xù)努力提供用于認證在線交易中的客戶身份的改進的系統(tǒng)。此外，還要繼續(xù)努力便利地利用對包括在這樣的認證過程中的當事人有用的信息。

發(fā)明內(nèi)容
本發(fā)明的目的在于認證在線交易期間提交者身份的帳戶認證服務。認證服務使信用方為了申請方(“申請者”)的利益能夠利用各種認證方法(如口令或令牌)來查證帳戶持有者的身份。在在線交易期間，認證帳戶持有者的身份包括請求帳戶持有者輸入口令、查證口令、以及告知申請者是否帳戶持有者的真實性已經(jīng)得到查證。帳戶認證服務的可選用實施例包括增值部分，其中關于客戶的信息是與增值方共享的?？蛻粜畔㈥P于客戶的細節(jié)是充足的，因為它是由帳戶認證過程中的各方收集的。增值方接著可以各種方式利用這個信息。所涉及的所有當事人可受益于共享客戶信息，并且各方可在他們?nèi)绾文軌驇椭舜嗽鲋颠@點上達成一致。通過使用識別客戶和商家之間特定交易以及客戶信息的交易標識符，各方還可審計交易和與客戶信息有關的任何協(xié)議。
作為一種方法，本發(fā)明的一個實施例包括至少接收來自提交者的身份認證口令并且將身份認證口令與以前為提交者的帳戶指定的口令比較。該方法還包括在收自提交者的身份認證口令與以前為該帳戶指定的口令匹配時，告知申請者該提交者是真實的帳戶所有者。這樣，信用方為了申請者的利益認證該提交者是真實的帳戶所有者。該方法還包括向增值方發(fā)送提交者的信息。在某些實施例中，該方法還包括對照一組標準評價提交者的信息，并且如果提交者的信息滿足該組標準則向增值方發(fā)送提交者的信息。這使增值方能夠接收想要的客戶信息。同樣地，在將提交者的信息發(fā)送至增值方之前，申請者和增值方中的各方可能同意將一組權利和義務作為條件。另外，交易標識符可用來追蹤個別的在線交易以及有關的客戶信息。
在本發(fā)明的一個實施例中，申請者是商家并且增值方為可使用客戶信息來運載從商家購買的產(chǎn)品的運送公司?？蛻粜畔椭\送公司確定是否以及如何將產(chǎn)品運至客戶。
在本發(fā)明的另外一個實施例中，申請者是商家并且增值方為可使用客戶信息向客戶銷售其貨物或服務的后繼商家?？蛻粜畔椭罄^商家確定是否以及如何與客戶通信。
在本發(fā)明的又一個實施例中，增值方是可使用客戶信息來評價安全問題的安全組織?？蛻粜畔椭踩M織確定是否以及如何解決可能的安全問題。
將在下面的本發(fā)明的說明以及附圖中更詳細地呈現(xiàn)本發(fā)明的這些和其它特征以及優(yōu)點，本發(fā)明的說明以及附圖通過舉例的方式說明了本發(fā)明的原則。


通過參考下面的描述并結(jié)合所采用的附圖，可以更好地理解本發(fā)明連同其中其他的優(yōu)點，其中圖1說明了實現(xiàn)用于各類帳戶認證應用的本發(fā)明帳戶認證服務的系統(tǒng)體系結(jié)構(gòu)的一個實施例。
圖2示意性地說明了支持支付交易中本發(fā)明認證服務的系統(tǒng)體系結(jié)構(gòu)的一個實施例。
圖3說明了帳戶持有者向按照本發(fā)明一個實施例的帳戶認證系統(tǒng)注冊的過程。
圖4說明了其中在帳戶認證系統(tǒng)登記過程期間帳戶持有者可輸入信息的互聯(lián)網(wǎng)網(wǎng)頁的一個實施例。
圖5描述了帳戶認證系統(tǒng)上的已認證的支付交易，其中帳戶持有者使用了聯(lián)入互聯(lián)網(wǎng)的計算機。
圖6說明了提示帳戶持有者其口令的示范窗口。
圖7說明了在支付交易期間被發(fā)送的示范的消息，所述的消息被添加到帳戶認證系統(tǒng)上，其中帳戶持有者使用了聯(lián)入互聯(lián)網(wǎng)的計算機。
圖8說明了涉及包括有增值方面的在線帳戶認證的一組消息流和示范的系統(tǒng)體系結(jié)構(gòu)。
圖9說明了適合于實現(xiàn)本發(fā)明實施例的遠程通信網(wǎng)絡。
圖10說明了安放于交換中心以此提供在線和離線交易處理的系統(tǒng)。
圖11說明的是遠程通信網(wǎng)絡組成部分的另一個視圖。
圖12A和12B說明了適合于實現(xiàn)本發(fā)明實施例的計算機系統(tǒng)。
具體實施例方式
現(xiàn)在將參考如在附圖中所說明的若干優(yōu)選實施例對本發(fā)明進行詳細地描述。在下面的描述中，提出了許多特定細節(jié)以便于提供對本發(fā)明的徹底的理解。然而，對本領域的技術人員來說顯而易見的是，不具有這些特定細節(jié)的某些或全部，仍可實現(xiàn)本發(fā)明。在其它的示例中，為了不對本發(fā)明造成不必要的混淆，未曾詳細描述公知的操作。
在圖1中，該描述將首先給出按照本發(fā)明的通用的帳戶認證系統(tǒng)和協(xié)議的綜述。帳戶認證系統(tǒng)是作為一種服務為參與的發(fā)行者、帳戶持有者和商家設置的。接著，在圖2-7中，描述了與在線支付交易有關的賬戶認證系統(tǒng)的實施例。在線支付交易的描述包含支付交易本身、系統(tǒng)設置、客戶注冊、以及特定消息流。在線支付交易的描述類似于非支付交易的描述。支付和非支付交易都包括帳戶持有者身份的認證。
接著，在圖8中，該說明描述了包括增值部分的帳戶認證過程的實施例。通過首先與增值方共享關于客戶的信息而使價值增加?？蛻粜畔㈥P于客戶的細節(jié)是充足的，因為它是由賬戶認證過程中的各方收集的。接著，增值方可以各種方式利用該信息。例如，接著增值方可向客戶提供集中的信息或者將貨物運至客戶。所涉及的所有當事人可受益于共享客戶信息，并且各方可在關于他們?nèi)绾文軌驇椭舜嗽鲋颠@點上達成一致。通過使用識別客戶和商家之間特定交易以及客戶信息的交易標識符，各方還可審計交易和與客戶信息有關的任何協(xié)議。這個應用描述了這種信息共享如何能夠便利地用于有利于各式各樣的當事人的大范圍的應用中。
帳戶認證系統(tǒng)帳戶認證系統(tǒng)被設計成可在交易期間認證帳戶持有者的帳戶所有權，其中一方不能物理查證聲稱是特定帳戶所有者的另一方的身份。例如，在信用方為了申請者的利益認證提交者的身份時，賬戶認證系統(tǒng)可用于各種交易。提交者是作為具有特定身份而提交自身的任何個人或?qū)嶓w。申請者是請求信用方認證提交者身份的任何個人或?qū)嶓w。信用方是能夠認證提交者身份的并且是受提交者和申請者托付來實施認證過程的實體。信用方可同意在提交者身份有錯誤或有欺詐行為的情形下，保護申請者的利益。帳戶認證系統(tǒng)的重要應用是在在線或便攜式電子裝置上發(fā)生的支付交易領域。
然而，除了支付交易之外，系統(tǒng)可能在許多應用中都是有用的。本發(fā)明的系統(tǒng)可用于其中客戶的身份需要認證的各種非支付的情形。例如，非支付交易包括比如對訪問互聯(lián)網(wǎng)站點以此完成在線表單(如注冊過程)的客戶進行認證這樣的交易。非支付交易還包括小額銀行業(yè)務、大金額銀行業(yè)務、醫(yī)療業(yè)務、保險業(yè)務、以及經(jīng)紀人業(yè)務的許多方面，這里僅舉出了幾個例子。小額銀行業(yè)務包括與卡(如借記卡、購物卡和儲值卡)一起使用的帳號。非支付交易還包括針對比如身份證和執(zhí)照這樣的事情填寫在線表單。例如，美國汽車協(xié)會(AAA)可使用該系統(tǒng)認證它的其中一個客戶的身份或者電話卡公司可使用該系統(tǒng)認證特定卡的用戶的身份。
圖1說明了實現(xiàn)用于各類帳戶認證應用的帳戶認證系統(tǒng)的系統(tǒng)體系結(jié)構(gòu)100的一個實施例。系統(tǒng)體系結(jié)構(gòu)100包括三個域信用方域103、互操作性域104、以及申請者域105。信用方和申請者域分別定義了功能領域，在所述的功能領域內(nèi)是全部或至少部分由信用方或申請者控制的部分?；ゲ僮餍杂蚨x了功能領域，在所述的功能領域內(nèi)是信用方、申請者、以及其他當事人(如服務組織)可利用的部分。
信用方域103包括主要由信用方控制的部分。信用方的實例是向客戶發(fā)行支付卡的金融機構(gòu)，稱之為發(fā)卡銀行。具體地，發(fā)行機構(gòu)或發(fā)卡機構(gòu)使得接收自卡的供應者的新卡個人化，而后將這些卡發(fā)給它的客戶。個人化還可由卡的供應者或由私有化機構(gòu)(personalization bureau)來實施。除了是金融機構(gòu)外，發(fā)行機構(gòu)還可以是任何適合的發(fā)行實體，如遠程通信網(wǎng)絡經(jīng)營者、服務協(xié)會、商家或其他組織、乃至發(fā)行機構(gòu)的代理商。申請者域105包括主要由申請者控制的部分。申請者可以是請求對帳戶持有者身份進行認證的任何當事人。例如，申請者可以是期望認證聲稱是信用卡帳戶所有者的某人身份的商家。收單方可以是登記支付方案中的申請者并管理申請者賬戶的金融機構(gòu)。收單方還將信息從在線商家路由至遠程通信網(wǎng)絡。在其他實施例中，商家可直接將信息路由至遠程通信網(wǎng)絡。
互操作性域104可由互聯(lián)網(wǎng)來支持，并且包括由信用方和申請者使用的部分。
信用方域103包括發(fā)行機構(gòu)帳戶持有者系統(tǒng)110、登記服務器112、訪問控制服務器(ACS)114以及帳戶持有者文件118。取決于系統(tǒng)將應用的特定領域，可將附加的部分包括在信用方域103內(nèi)。例如，在下面的支付交易中，出于認證關于支付交易的帳戶持有者身份的目的，在每個域中提供了附加的部分。
登記服務器112是借助于網(wǎng)絡接口，通過提交將要由帳戶持有者回答的并由信用方查證的一系列問題，來管理帳戶持有者向賬戶認證系統(tǒng)進行登記的計算機。正如圖1所示，信用方操作登記服務器112。然而，服務組織(如Visa)可以信用方的名義來操作登記服務器112。在登記過程中，信用方可使用由外部實體提供的激活網(wǎng)絡的、交互式的“身份認證服務”以此幫助確認帳戶持有者的身份。
ACS 114是具有注冊了由賬戶認證系統(tǒng)提供的賬戶認證服務的帳戶持有者的數(shù)據(jù)庫的計算機。ACS 114包含每個帳戶持有者的帳戶和口令信息。在賬戶認證交易期間，ACS 114向認證申請者提供數(shù)字化簽名收據(jù)、控制對賬戶認證系統(tǒng)的訪問、并確認帳戶持有者參與服務。發(fā)卡機構(gòu)或服務組織(如Visa)可以為信用方操作ACS114。雖然賬戶認證服務不要求使用任何附加的帳戶持有者軟件，但是可使用可選的帳戶持有者軟件和硬件。附加的帳戶持有者軟件可支持附加的認證技術，如數(shù)字證書、集成電路卡(芯片卡)和芯片卡讀卡器。值得注意的是，在本發(fā)明中，需要證書的唯一系統(tǒng)參與者是發(fā)行的金融機構(gòu)。
帳戶持有者文件118是用于存儲與成功向賬戶認證系統(tǒng)登記的帳戶持有者有關的信息的信用方管理的數(shù)據(jù)庫。發(fā)行機構(gòu)帳戶持有者系統(tǒng)110(或信用方帳戶持有者系統(tǒng))由信用方控制，并包含關于帳戶持有者的信息。這樣的信息涉及賬戶信息、由帳戶持有者使用的服務等。發(fā)行機構(gòu)帳戶持有者系統(tǒng)110中的某些信息可用于使帳戶持有者登記進入賬戶認證服務。
申請者域105的申請者180通常期望對帳戶持有者進行認證。當事人180管理有利于認證協(xié)議的請求插入式軟件182。請求插入式軟件模塊182是被結(jié)合進第三方或申請者的網(wǎng)站的軟件模塊。插入式軟件模塊182提供了賬戶認證系統(tǒng)和申請者的處理軟件(如商家的支付處理軟件)之間的接口。
互操作性域104包含目錄服務器128，由互聯(lián)網(wǎng)支持，并且包括由信用方和申請者使用的部分。目錄服務器128將認證請求從申請者路由至特定的ACS(如ACS114)。目錄服務器128由卡方案管理者或服務組織(如Visa)來操作?；ゲ僮餍杂?04還可由互聯(lián)網(wǎng)之外的網(wǎng)絡來支持。
用于支付交易的賬戶認證系統(tǒng)現(xiàn)在將提供用于認證支付交易領域內(nèi)的帳戶持有者的系統(tǒng)體系結(jié)構(gòu)的描述。值得注意的是，在這一部分中描述的許多通用的概念適用于各種應用領域，因為用于支付應用的認證過程類似于非支付應用。
支付交易中的認證系統(tǒng)和協(xié)議的示范用法描述如下。認證系統(tǒng)在帳戶持有者在線購物、向“購物車”中添加項目、進入到在線商家的結(jié)賬頁并完成在線商家結(jié)賬表單時的方案中是有用的。在客戶決定購買其想要的產(chǎn)品或服務之后，例如在客戶點擊“購買”按鈕之后，認證過程可發(fā)生。認證過程還可在客戶支付交易中的其他不同時間開始。通過利用已經(jīng)被結(jié)合進支付網(wǎng)絡的若干點處的軟件，認證過程主要以對客戶來說透明的方式來進行。系統(tǒng)確認帳戶持有者和帳戶持有者所屬的金融機構(gòu)參與的認證服務。接著，創(chuàng)建窗口，在該窗口中客戶通過請求來自帳戶持有者以前所注冊的口令可確認其身份。如果客戶的身份被確認，支付信息和客戶認證通知被發(fā)送回商家。接著，在便利實施時，支付交易由商家進行處理。例如，商家可將訂單確認消息發(fā)送至帳戶持有者的瀏覽器。
圖2示意性地說明了支持支付交易中的認證服務的系統(tǒng)體系結(jié)構(gòu)200的一個實施例。如同圖1的通用系統(tǒng)體系結(jié)構(gòu)100一樣，體系結(jié)構(gòu)200被分成三個域發(fā)行機構(gòu)域102、互操作性域104和收單方域106。圖2的發(fā)行機構(gòu)域102和收單方域106分別類似于圖1的信用方域103和申請者域105。
發(fā)行機構(gòu)域102包括登記站點108、發(fā)行機構(gòu)帳戶持有者系統(tǒng)110、帳戶持有者客戶裝置122、登記服務器112、訪問控制服務器(ACS)114、發(fā)行機構(gòu)或申請者身份認證部分116和帳戶持有者文件118?？蛇x地，發(fā)行機構(gòu)域102可包括核準帳戶持有者120的發(fā)行機構(gòu)文件。帳戶持有者是提交者的另一個稱謂，因為帳戶持有者本身將作為一種特定身份來提供。登記服務器112是借助于網(wǎng)絡接口通過提交將要由帳戶持有者回答的并由發(fā)行機構(gòu)查證的一系列問題來管理帳戶持有者向賬戶認證系統(tǒng)登記的計算機。登記服務器112借助于互聯(lián)網(wǎng)被連接到互聯(lián)網(wǎng)支付網(wǎng)關服務124，其又被連接到遠程通信網(wǎng)絡126(如VisaNet)。互聯(lián)網(wǎng)支付網(wǎng)關服務124使登記服務器112能夠與遠程通信網(wǎng)絡126進行通信。借助于支付網(wǎng)關服務124的連接使登記服務器112能夠詢問發(fā)行機構(gòu)的認證系統(tǒng)127，以此確定是否登記的帳戶持有者具有有效的卡帳戶。登記站點108是其中帳戶持有者可注冊參加由賬戶認證系統(tǒng)提供的賬戶認證服務的互聯(lián)網(wǎng)站點。
帳戶持有者客戶裝置122由帳戶持有者用來加入帳戶認證系統(tǒng)。具體地，帳戶持有者客戶裝置122可以是能夠訪問互聯(lián)網(wǎng)的任何裝置，如個人電腦、移動電話、個人數(shù)字助理或交互式電纜電視。在某些實施例中，帳戶持有者客戶裝置122不能連接到互聯(lián)網(wǎng)上，然而這樣的裝置仍可被帳戶持有者使用，因為客戶裝置122的輸入和輸出消息被路由過能夠處理基于非互聯(lián)網(wǎng)的消息的特定節(jié)點。例如，傳輸和接收以語音和/或文本消息為基礎的消息的移動電話未連接到互聯(lián)網(wǎng)，然而它們?nèi)钥赏ㄟ^以不同方式路由消息而與賬戶認證系統(tǒng)一起使用。短消息服務(SMS)是常用的通訊系統(tǒng)的實例。交互語音響應(IVR)單元可用于音頻通道上的自動交換。這個消息路由布置將在下面的非互聯(lián)網(wǎng)功能裝置的部分中詳細描述。
發(fā)行機構(gòu)帳戶持有者系統(tǒng)110是發(fā)行機構(gòu)控制的系統(tǒng)，其包含了帳戶持有者的信息。該系統(tǒng)信息包含了關于賬戶信息的信息、由帳戶持有者利用的服務等信息。發(fā)行機構(gòu)帳戶持有者系統(tǒng)內(nèi)的某些信息可用于帳戶持有者向賬戶認證系統(tǒng)登記的過程。
發(fā)行機構(gòu)或申請者身份認證數(shù)據(jù)庫116包含發(fā)行機構(gòu)或申請者已經(jīng)具有存檔相關帳戶持有者的信息。數(shù)據(jù)庫116被發(fā)行機構(gòu)用于登記帳戶持有者的過程以查證帳戶持有者的身份。例如，在帳戶持有者注冊過程期間，由帳戶持有者輸入的信息應當與已經(jīng)在認證數(shù)據(jù)庫116中存檔的信息匹配，以便于帳戶持有者成功注冊由賬戶認證系統(tǒng)提供的服務。第三方可以是比如Equifax這樣的公司。
互操作性域104包括目錄服務器128、認證歷史服務器130和收據(jù)管理器131。目錄服務器128將認證請求從商家路由至特定的ACS。目錄服務器128由服務組織(如Visa)操作。認證歷史服務器130和收據(jù)管理器131存儲每項認證的支付交易的簽名收據(jù)(如下面所描述的支付請求響應消息的副本)。認證歷史服務器130包含了查證哪項交易被認證的信息，并在爭議解決過程期間提供附加的信息。認證歷史服務器130和收據(jù)管理器131由服務組織操作。發(fā)行機構(gòu)、收單方、或商家還可保留數(shù)字化簽名收據(jù)的副本。
收單方域106包括商家132和確認服務器136。MPI 134位于商家132的位置處。MPI 134是被結(jié)合進商家電子商務網(wǎng)站的軟件模塊。MPI 134提供了賬戶認證系統(tǒng)和商家支付處理軟件之間的接口。
值得注意的是，MPI 134是與圖1的請求插入式軟件模塊182相同的軟件模塊。“商家”的描述符用于MPI 134來表示正在使用插入式軟件模塊的申請方的類型。然而，應當理解，不管用來描述插入式軟件模塊134的形容詞是怎樣的，在整個說明中所描述的插入式軟件模塊基本上以相同的方式起作用。為了簡化整個說明中術語的用法，“商家”的形容詞將用來描述插入式軟件模塊。然而，這不應當被理解為將插入式軟件模塊134限制為唯一適用于為商家的申請方。此外，MPI將用作商家插入式軟件模塊的只取首字母的縮寫詞。
確認服務器136查證在支付交易期間用于簽署由賬戶認證系統(tǒng)返回到商家的收據(jù)的卡發(fā)行機構(gòu)的數(shù)字簽名。在可選用的實施例中，確認服務器136的功能性可包括在MPI 134中，從而消除了對獨立的確認服務器136的需要。確認服務器136由商家、收單方或服務組織操作。
在某些實施例中，帳戶認證系統(tǒng)可同其他帳戶持有者應用(如電子錢包)交互操作，并且服務可同電子商務標記語言(ECML軟件)一起兼容操作。賬戶認證系統(tǒng)還提供了實現(xiàn)爭議解決步驟的能力。例如，商家可保留充足的信息以此為了爭議解決和扣款而提供帳戶持有者認證的證據(jù)。
設置和注冊說明本描述現(xiàn)在將進一步提供用于設置支付和非支付交易的賬戶認證系統(tǒng)的細節(jié)。首先，將解釋設置各個系統(tǒng)參與者以使他們可使用賬戶認證系統(tǒng)所需要的步驟。接著，解釋帳戶持有者向賬戶認證系統(tǒng)注冊的過程。在描述過這些階段之后，將提供有關實際的支付交易授權的解釋。
設置賬戶認證系統(tǒng)包括針系統(tǒng)內(nèi)所有參與者的設置步驟。對于支付和非支付交易的授權來說，設置步驟通常是相同的。這些參與者包括了比如商家或其他認證申請者、金融機構(gòu)或其他信用方、以及帳戶持有者這樣的實體。
與賬戶認證系統(tǒng)簽約的申請者(如在線商家)接受插入式軟件模塊，如圖1的插入式軟件模塊128和圖2的模塊134。插入式軟件模塊對于由申請者使用的服務器軟件和計算平臺來說是特定的。參與賬戶認證系統(tǒng)的申請者(如金融機構(gòu))將提供他們的服務標識以及營銷方案，以結(jié)合進他們的定制登記站點模板中。作為收單銀行的第三方還應當向商家提供服務組織證明權限(CA)根憑證、客戶認證的服務組織證明權限SSL證書和綜合支持。
在設置信用方以使用賬戶認證系統(tǒng)之前，他們應當獲得并安裝在信用方域內(nèi)指定的所有帳戶認證系統(tǒng)硬件和軟件的副本。信用方(如發(fā)行金融機構(gòu))還將向賬戶認證系統(tǒng)提供身份認證政策以及參與銀行識別號(BIN)信息，用于賬戶持有者身份查證過程?？蛇x地，發(fā)行機構(gòu)可向賬戶認證系統(tǒng)提供賬戶持有者認證信息用于預載入賬戶持有者文件118。預載入促進了對賬戶持有者的大容量支持。例如，當信用方期望激活其所有或大部分的賬戶持有者的帳戶認證服務時，信用方可向其所有的帳戶持有者發(fā)送個人識別號碼(PIN碼)。PIN碼接著可被每個帳戶持有者使用以此訪問他或她的預載入口令。如此，登記過程被加快，因為每個賬戶持有者不必經(jīng)歷正式的登記過程。在賬戶持有者首次使用其預載入口令之后，賬戶持有者具有指定新的和更易于記憶的口令的選擇權。
賬戶持有者認證信息包括比如業(yè)務標識、國家代碼、卡帳號、卡有效期、賬戶持有者名字、在“參與BIN”數(shù)據(jù)中指定的發(fā)行機構(gòu)特定認證數(shù)據(jù)(如婚前姓)這樣的信息，以及比如帳單地址、發(fā)貨地址、社會保險號、電話號碼、帳戶余額、交易歷史和司機駕照號碼這樣的其他信息。信用方還應當向目錄服務器提供其卡帳戶業(yè)務量的帳號范圍以及ACS IP地址(URL)。至于賬戶認證系統(tǒng)的支付應用，可通過供帳戶持有者注冊用的、帶有銀行標記的網(wǎng)站提供服務。
圖3說明了賬戶持有者向根據(jù)一個實施例的帳戶認證系統(tǒng)注冊的過程。如圖所示，在步驟1中，賬戶持有者訪問由信用方(如發(fā)行金融機構(gòu))維持的登記服務器互聯(lián)網(wǎng)網(wǎng)站。賬戶持有者通過注冊其帳號向帳戶認證系統(tǒng)注冊。例如，在支付交易的情況下，賬戶持有者可注冊其信用卡、支票、或借記卡帳號。至于非支付交易，賬戶持有者可注冊保險公司或經(jīng)紀人公司同意的帳號。賬戶持有者可注冊一個或多個卡。
在步驟2處，賬戶持有者輸入比如主帳號(PAN)、名字和卡有效期這樣的信息。在該點處，賬戶持有者還可輸入附加信息。例如，還可輸入地址、e-mail地址、購物者標識、賬戶確認值、賬戶持有者特定口令以及發(fā)行機構(gòu)特定認證信息?？稍谌鐖D4所示的頁面300這樣的登記網(wǎng)站頁面上輸入這個信息。
賬戶持有者在登記站點108上輸入請求信息之后，賬戶認證系統(tǒng)查證賬戶持有者的PAN屬于由信用方在互操作性域104的目錄服務器128中注冊的卡范圍。可利用各種方法查證賬戶持有者身份。首先，正如剛剛提到的，可通過申請者認證數(shù)據(jù)庫或通過信用方自己的認證數(shù)據(jù)庫來查證賬戶持有者身份。另外，可通過使用由信用方提供的核準賬戶持有者120的文件、通過將狀態(tài)檢查授權傳輸?shù)叫庞梅揭约巴ㄟ^比較對由金融機構(gòu)提供的預載入信息的響應來實施確認。
如果PAN不在已登記卡范圍內(nèi)，則登記被拒絕并且登記過程終止。在支付交易中，如果PAN在已登記卡范圍內(nèi)，一美元(或其他任何標稱量)的授權將通過服務組織支付網(wǎng)絡(如VisaNet)被提交到發(fā)行金融機構(gòu)。一美元交易的授權使發(fā)行機構(gòu)能夠查證卡帳戶狀態(tài)、使用地址確認服務的地址以及賬戶持有者確認值2(CVV2)。CVV2是打印在支付卡背面的簽名條上的三位數(shù)字號碼。在非支付交易中，如果PAN在已登記卡號范圍內(nèi)，則不需要一美元交易。
在步驟3處，賬戶持有者被提示附加的認證信息以此在交互的、實時的在線對話中查證賬戶持有者身份。在某些實施例中，在認證交易期間，還可要求賬戶持有者輸入口令和用來認證賬戶持有者的“提示問題和回答”對。
如在步驟4中所示，當查證賬戶持有者的身份并且返回適當?shù)捻憫獣r，授權消息被發(fā)送至發(fā)行金融機構(gòu)。接著在步驟5處，登記服務器112將賬戶持有者信息傳遞至ACS 114以此建立賬戶持有者文件118中的記錄。賬戶持有者文件118可存儲比如金融機構(gòu)BIN碼、帳號、有效期、姓名、司機駕照號碼、帳單地址、社會保險號、賬戶持有者口令、賬戶持有者口令問題、賬戶持有者口令答案、賬戶持有者email地址、申請者身份評分這樣的信息以及其他信息。
在某些實施例中，在注冊過程期間，可要求賬戶持有者輸入可識別賬戶持有者的、被稱之為個人安全消息(PAM)的短語。稍后，在認證過程期間，由信用方將PAM提交給賬戶持有者。因為只有信用方知道由賬戶持有者指定的PAM，所以可向賬戶持有者保證與賬戶認證系統(tǒng)一起使用的對話窗口是從信用方輸送來的。PAM的實例是“天空是藍色的”。
應當注意的是，賬戶持有者不需要新的客戶軟件或裝置就可使用認證系統(tǒng)。在優(yōu)選實施例中，賬戶持有者注冊過程利用安全協(xié)議(如SSL通道加密)來保護在互聯(lián)網(wǎng)上于賬戶持有者和登記服務器之間傳輸?shù)臄?shù)據(jù)。
同樣地，在注冊或登記過程期間，每個信用方可顯示其自己的“使用條款”和/或“數(shù)據(jù)保密政策”。每個信用方能夠要求注冊賬戶持有者接受或拒絕條款或政策以便于完成注冊過程。每個賬戶持有者接受的“使用條款”和/或“數(shù)據(jù)保密政策”的版本號應當由信用方保存。
支付交易描述在設置了所有參與者并且注冊了賬戶持有者之后，實施賬戶認證。圖5描述了利用核心賬戶認證系統(tǒng)的已認證的支付交易，其中賬戶持有者使用了被連接到互聯(lián)網(wǎng)的計算機。在圖5的步驟1中，賬戶持有者訪問互聯(lián)網(wǎng)上商家的電子商務站點。賬戶持有者還可被稱為持卡者，因為在支付交易中，賬戶持有者所持有的最常見類型的帳戶將是某類信用卡、借記卡或支票保證卡賬戶。在賬戶持有者選擇了他或她期望購買的產(chǎn)品或服務之后，賬戶持有者開始結(jié)帳過程，完成結(jié)帳表單，而后點擊“購買”按鈕。
在如圖5所示的步驟2中選擇“購買”按鈕之后，MPI被激活并且接著實施確認過程來確定賬戶持有者的特定帳戶是否向賬戶認證系統(tǒng)注冊。存在有各種方法，據(jù)此MPI可確定賬戶持有者是否向賬戶認證系統(tǒng)注冊。例如，可使用其中檢查與帳戶持有者相關聯(lián)的目錄服務器而后ACS的兩步過程、其中只檢查ACS的過程以及其中商家可檢查包含有與目錄服務器中存有的相同信息的高速緩沖存儲器的方法。
現(xiàn)在將提供對兩步過程的描述。在該描述過程期間將參考圖2進行。在第一步驟中，MPI識別卡帳號并詢問目錄服務器128以查證帳號是在與作為賬戶認證系統(tǒng)的參與者的發(fā)卡銀行相關聯(lián)的帳號范圍內(nèi)。如果帳號不屬于目錄服務器128上所定義的帳號范圍，則發(fā)行機構(gòu)以及因此其賬戶持有者未注冊。既然是這樣，告知商家該賬號未注冊并且MPI 134將交易控制返回到商家店面軟件。在該點處，商家店面軟件可處理該交易，正常的做法是拒絕對賬戶持有者進一步的服務或者用可選用的支付方法處理。
另一方面，如果帳號被確定是在目錄服務器128提交的帳號范圍內(nèi)，則確認過程的第二步驟開始。在目錄服務器128將帳號發(fā)送至ACS以確定帳號是否已登記時，確認的第二步驟開始。如果該卡未登記過，則登記過程終止。如果ACS表示該卡已登記，則ACS借助于目錄服務器將其URL互聯(lián)網(wǎng)地址返回到MPI。MPI接著借助于帳戶持有者客戶裝置和其駐留的瀏覽器來調(diào)用ACS。再次應當注意的是，在賬戶認證系統(tǒng)中可能存在有多個ACS。
檢查賬戶持有者是否向賬戶認證系統(tǒng)注冊的第二種方法是在沒有首先詢問目錄服務器128的情形下MPI 134直接詢問ACS 114。如上所述，第三種方法是用于具有包含了與目錄服務器128中存有的相同信息的高速緩沖存儲器的商家的。如此，商家可至少進行初步檢查。
應當注意的是，在賬戶認證系統(tǒng)中可能存在有不止一個物理的目錄服務器。然而，優(yōu)選地，只有一個邏輯的目錄服務器。換句話說，所有目錄服務器應當是一致的，因為它們包含了相同的信息。
如果賬戶持有者是賬戶認證系統(tǒng)的參與者，則ACS 114向賬戶持有者顯示帶有銀行標記的窗口。帶有銀行標記的窗口包含了基本的支付交易信息并向賬戶持有者提示其認證口令或令牌。參見圖6的示范窗口500，其向賬戶持有者提示了他或她的認證口令。賬戶持有者輸入其認證口令并且ACS 114查證認證口令。窗口500的大小和布局根據(jù)賬戶持有者使用的裝置的參數(shù)來變化。正如今天所常見的，可以給予賬戶持有者一定次數(shù)的正確輸入認證口令的機會。如果賬戶持有者不能正確輸入認證口令的話，則可用賬戶持有者注冊過程期間建立的提示問題來提示賬戶持有者。優(yōu)選地，作為對提示問題的響應，給予賬戶持有者一次輸入正確答案的機會。
如果直接輸入了正確的認證口令或令牌或者賬戶持有者提供了提示問題的正確答案，則支付認證繼續(xù)。接著，ACS進入到利用發(fā)行機構(gòu)的簽名密鑰或服務提供商的密鑰數(shù)字化簽署收據(jù)。這個收據(jù)將包含商家名稱、卡帳號、支付量以及支付日期。在某些實施例中，收據(jù)是支付認證響應(PARes)消息的副本或者具有至少某些從PARes消息中復制的消息字段的消息。認證歷史服務器130存儲下列交易數(shù)據(jù)商家名稱、商家URL、卡帳號、有效期、支付量、支付日期、發(fā)行機構(gòu)支付簽名以及賬戶持有者認證確認值。接著ACS通過賬戶持有者瀏覽器重新引導賬戶持有者返回到MPI。在該點處，ACS還將數(shù)字化簽名的收據(jù)以及關于賬戶持有者是否已經(jīng)過認證的確定傳遞至商家。在收單方域106中，確認服務器136由MPI 134用來查證用于簽署支付收據(jù)的數(shù)字簽名。在查證數(shù)字簽名之后，賬戶持有者被認為“已認證”。在某些實施例中，在交易完成之后，賬戶持有者還將能夠重新注冊其卡帳戶并創(chuàng)建新的口令用于將來的在線購物。
賬戶持有者在步驟3中被認證之后，步驟4啟動授權特定賬戶持有者的賬戶的過程。授權指查證賬戶持有者具有足夠的信用并且對于特定購物信譽良好的過程。相反地，認證指查證賬戶持有者身份的過程。在步驟4中，商家使用MPI將授權消息發(fā)送至支付網(wǎng)絡(如VisaNet)。支付網(wǎng)絡又將授權消息和電子商務指示符(ECI)發(fā)送至發(fā)行金融機構(gòu)。授權消息是本領域公知的消息。授權消息被發(fā)送至發(fā)行機構(gòu)，以使發(fā)行金融機構(gòu)可向商家查證對于請求的支付交易的購物量來說特定帳號是信譽良好的并具有足夠的信用額度。ECI表示交易在互聯(lián)網(wǎng)上完成并表示消息安全等級(即在明文中，通道加密(SSL))和所用的認證。
在可選用實施例中，商家能夠提供附加的消息連同授權消息。例如，還可發(fā)送下列信息表示賬戶持有者是否已成功認證的標記、賬戶信息、數(shù)字簽名、賬戶持有者確認值2、交易標識符、由芯片卡Europay、Mastercard和Visa(EMV)密碼所認證的離線PIN、以及為商家提供保證支付的必要字段。在發(fā)行金融機構(gòu)的授權交易處理完成后，接著借助于支付網(wǎng)絡將支付交易的控制返回到商家店面軟件。而后，發(fā)行機構(gòu)借助于支付網(wǎng)絡將授權響應返回到商家。在圖5的步驟5中，發(fā)行金融機構(gòu)將授權或拒絕交易。在某些實施例中，授權消息被分成批并在稍后的時間以組發(fā)送。認證信息也包括在批授權消息中。
交易標識符由認證賬戶持有者的ACS創(chuàng)建，并且對于給定的支付卡以及來自該卡的特定支付交易來說是唯一的值。發(fā)行機構(gòu)出于各種目的(如在后來的爭議發(fā)生時)使用交易標識符來唯一地識別已認證的支付交易。值得注意的是，交易標識符可表現(xiàn)為適合于唯一識別記錄(如與特定在線交易有關的那些記錄)的多種數(shù)據(jù)形式。在一些實際應用中(如支付交易)，交易標識符是卡認證確認值(CAVV)。在下面的描述中，交易標識符可被稱為CAVV，然而，應該記住，還可使用各種類型的交易標識符。
訪問控制服務器(ACS)114具有各種其它的功能。例如，ACS可使數(shù)據(jù)庫中的已注冊賬戶失效?？赏ㄟ^賬戶持有者或通過發(fā)行機構(gòu)人工使賬戶失效。當賬戶持有者接收到替換卡時，ACS 114還可提供簡化的更新注冊過程。ACS 114可支持具有唯一訪問控制信息的相同注冊賬戶的多個用戶。在為了支付交易或賬戶更新而向用戶提供到ACS 114的連接時，ACS 114可通過一個或多個下面的機制確認用戶為注冊賬戶的授權賬戶持有者口令短語、數(shù)字簽名、在線PIN碼、或/和芯片卡EMV密碼的離線PIN認證。
商家132可與其中商家具有存檔的賬戶持有者帳戶信息的現(xiàn)有系統(tǒng)交互操作、可與現(xiàn)有商家授權和清算系統(tǒng)交互操作、支持向多個商家提供服務的第三方、支持商家和收單方之間的多種支付接口、以及在設置電子商務指示符(ECI)的值時將來自收單方的支付網(wǎng)絡授權消息的強制性影響減至最小。
將交易從商家路由至ACS的一種方法是具有基于賬戶持有者帳號提供服務器地址的目錄。在這樣的方法中，路由信息的請求只能接受已認證商家的。在商家的活動超出正?；顒訒r，則賬戶認證系統(tǒng)可否定對其收單方表示這樣的訪問不再有效的商家的訪問。這可能是商家欺詐被認為是有可能的情形?？刹渴饘~戶認證系統(tǒng)的商家認證，但是這個部署不是必需的。商家認證可有助于將商家欺詐行為降至最少。
圖7說明了在支付交易期間使用根據(jù)一個實施例的核心賬戶認證系統(tǒng)所發(fā)送的特定消息，其中客戶使用了被連接到互聯(lián)網(wǎng)的計算機。圖7的消息被疊加到圖2所示的支付系統(tǒng)結(jié)構(gòu)體系上。應當理解的是，即使消息以及每條消息內(nèi)的數(shù)據(jù)字段給定了特定名稱，這些名稱不會影響認證協(xié)議的執(zhí)行。因此，可將不同的名稱賦給下面討論的消息和數(shù)據(jù)字段。還要注意的是，在本發(fā)明的可選用實施例中，可改變或省略圖7中所描述的特定消息和/或在不影響認證過程總目的的情況下可添加附加的消息。出于各種目的(如添加功能性和使通信順暢)，各種消息均可被改變、添加或省略。還要注意的是，在該說明所描述的過程中消息流在可選用實施例中由于比如剛剛描述過的那些原因是可改變的。
如上所述，在賬戶持有者借助于瀏覽器訪問商家的網(wǎng)站并選擇了購買項目時，支付交易開始。商家的支付系統(tǒng)將要求賬戶持有者輸入其支付信息。一般地，支付信息的輸入應當在安全環(huán)境下發(fā)生，例如，通過使用SSL加密協(xié)議。在賬戶持有者表示他或她準備完成交易時，商家的支付系統(tǒng)調(diào)用MPI 134。接著，如線1a所示，MPI 134檢查目錄服務器128的可包含賬戶持有者PAN的ACS的特定URL以此確認賬戶持有者在服務中已登記?；蛘?，MPI 134檢查其自有的、包含該信息的高速緩沖存儲器。MPI 134還可檢查ACS 114以此查證賬戶持有者的PAN被以賬戶認證系統(tǒng)登記。在MPI 134可檢查其自有的高速緩沖存儲器的情形下，MPI 134應當能夠?qū)⒛夸?28的內(nèi)容復制進它的本地高速緩沖存儲器中。如果這種能力被使用，則商家可立即從它的高速緩沖存儲器中確定賬戶是否是注冊范圍的部分。如果商家實現(xiàn)了這種能力，則高速緩沖存儲器的內(nèi)容應當?shù)狡诓⑶抑辽倜?4小時被更新。在載入MPI 134時并且在此后規(guī)則的時間間隔內(nèi)載入時，應當請求高速緩沖存儲器。
MPI 134通過使用賬戶持有者PAN格式化確認登記請求(VEReq)消息來搜尋PAN。如果還未建立，MPI 134將建立與目錄服務器128或ACS 114的安全連接并向目錄服務器128或ACS 114認證自身。MPI 134將搜尋對應于各種位置處的賬戶持有者PAN的卡范圍輸入。
在MPI 134進行搜尋之后，VEReq消息或如線1b所示直接被傳輸至ACS 114或如線1a所示首先經(jīng)過目錄服務器128之后被傳輸至ACS 114。在VEReq消息借助于目錄服務器128被傳輸至ACS114時，目錄服務器128搜尋與包含在VEReq消息內(nèi)的賬戶持有者PAN對應的記錄。在不成功匹配時，目錄服務器128將格式化不具有URL值的確認登記響應(VERes)消息并且設置PAN登記的狀態(tài)值或設置VERes-狀態(tài)為“N”。接著將VERes消息返回到MPI。另一方面，在匹配成功時，如果還未建立的話，目錄服務器128將建立與ACS URL的安全連接并認證自身到ACS URL。然后，VEReq消息被轉(zhuǎn)發(fā)至ACS URL。如果該URL無效，則MPI應當進入到下一個ACS URL值(如果有效的話)并考慮將要搜尋最大到五個ACSURL。當然，所嘗試的URL的數(shù)目是可變的。如果所有的嘗試均未成功，則將VERes消息返回到MPI同時將VERes-狀態(tài)設置為“N”，以此向商家表示利用賬戶認證系統(tǒng)未能使支付交易進行下去。
在ACS 114接收VEReq消息之后，ACS接受來自VEReq消息的賬戶持有者PAN并對照賬戶持有者文件118來確認它。而后，ACS 114格式化VERes消息。在成功匹配發(fā)生的情形下，ACS將PAN登記的狀態(tài)設置為“Y”、創(chuàng)建ACS 114將與PAN內(nèi)在關聯(lián)的單用途代理PAN、并且將URL字段加入VEReq消息。在未成功匹配的情形下，ACS將PAN登記的狀態(tài)設置為“N”。然后，如線2a所示，ACS使VERes消息經(jīng)過目錄服務器128返回到MPI。對于VEReq消息被直接傳輸?shù)紸CS的情形，如線2b所示，VERes消息被直接傳回到MPI。
通過利用CRReq和CRRes消息對，可便于在MPI 134內(nèi)高速緩存目錄服務器128的數(shù)據(jù)。CRReq消息從MPI被發(fā)送至目錄服務器并且請求參與的卡范圍列表，以便于MPI更新其高速緩沖存儲器。CRRes消息是包含參與范圍的響應。
在某些實施例中，賬戶認證系統(tǒng)檢查賬戶持有者客戶裝置是否通過使用QueryAccount holderReq和QueryAccount holderRes消息對已經(jīng)分配了認證能力。MPI將格式化并發(fā)送詢問、QueryAccountholderReq消息至賬戶持有者客戶裝置122，以此確定分配的賬戶認證賬戶持有者模塊是否是駐留的。QueryAccount holderReq消息的發(fā)送在圖7中由線3示出。如果在QueryAccount holderRes消息內(nèi)任何分配的認證選項被返回，則MPI將直接與賬戶持有者客戶軟件進行通信以此實施認證的步驟。QueryAccount holderRes消息的發(fā)送在圖7中由線4示出。另外，通過使用QueryAccount holderReq和QueryAccount holderRes消息，下面所描述的VEReq和VERes消息將被消除?？衫们度胲浖?nèi)的發(fā)行機構(gòu)的ACS URL來部署賬戶持有者客戶軟件。MPI將首先完成QueryAccount holderReq和QueryAccount holderRes消息。如果探測到賬戶持有者客戶軟件，則在不必引導VEReq和VERes消息的情形下可將PAReq消息發(fā)送至ACS或賬戶持有者客戶軟件。
如果VERes-狀態(tài)具有不等于“Y”的值，則告知商家利用賬戶認證系統(tǒng)使支付交易不能進行下去。然而，如果VERes-狀態(tài)具有等于“Y”的值，則MPI 134將格式化支付者認證請求消息(PAReq)。如線5所示，MPI 134將借助于賬戶持有者客戶裝置瀏覽器將PAReq消息發(fā)送至發(fā)行機構(gòu)的ACS服務器。
在MPI將PAReq消息傳遞至發(fā)行機構(gòu)的ACS之后，ACS向賬戶持有者顯示窗口。該窗口顯示了包含在支付者認證響應(PARes)消息內(nèi)的支付細節(jié)，除了其他項目之外還有比如發(fā)行機構(gòu)的標識、服務組織的標志或商標標識、商家的名稱、商家的位置(URL)、總的購買量和貨幣、購買日期、卡號、分期支付/重復支付項目、訂單描述或與描述的鏈接、特定項目以及銷售狀況或與該信息的鏈接、個人安全消息(PAM)、和賬戶持有者口令的提示或任何其他類型的認證令牌。
ACS接著將提示賬戶持有者輸入適當?shù)目诹?。ACS接受賬戶持有者的輸入并對照賬戶持有者文件118來確認該輸入。賬戶認證系統(tǒng)將允許比如若干次未成功的輸入正確口令的嘗試(如三次嘗試)。當然，所允許的嘗試次數(shù)是可改變的。在最后的不成功嘗試之后，賬戶認證系統(tǒng)可顯示提示問題。賬戶持有者將需要輸入正確的提示問題的答案。接著，顯示與賬戶持有者相關聯(lián)的提示問題。向賬戶持有者提供至少一次輸入正確答案的嘗試機會。如果賬戶持有者提供了錯誤的答案，則可告知商家利用賬戶認證系統(tǒng)未能完成交易。如果賬戶持有者提供了正確的答案，則交易應當作為好像口令是匹配的情況來處理。值得注意的是，如果存在不止一個帳號輸入，則不同賬戶持有者的名字將顯示在下拉窗口中。賬戶持有者接著可選擇其名字。
在口令匹配時，ACS生成并數(shù)字化地簽署PARes消息。如線7所示，ACS還生成并發(fā)送SaveReceipt消息至認證歷史服務器130和收據(jù)管理器131。如線7a所示，還可將SaveReceipt消息從認證歷史服務器130傳送至發(fā)行機構(gòu)授權和結(jié)算系統(tǒng)138，以此允許發(fā)行機構(gòu)能夠?qū)崟r地使支付授權請求與支付者已認證的交易相匹配。發(fā)送SaveReceipt消息至發(fā)行機構(gòu)授權和結(jié)算系統(tǒng)138使發(fā)行機構(gòu)能夠同時確定授權請求是否是針對已認證購買的。如線6所示，ACS接著將重新引導已簽名的PARes消息返回到MPI。
在已簽名的PARes消息被傳回到MPI 134之后，MPI 134被再次激活。如果認證狀態(tài)為“Y”，則MPI 134將PARes消息發(fā)送至確認服務器136。在確認服務器功能是由MPI 134提供的情形下，MPI 134確認PARes消息簽名并返回簽名確認的結(jié)果。如果簽名未被確認，則MPI 134將告知商家利用賬戶認證系統(tǒng)未能使交易進行下去。如果認證狀態(tài)為“N”，則商家應當向賬戶持有者發(fā)送提示以請求附加的信息、請求賬戶持有者使用不同的支付卡或支付形式、或者按非認證支付交易來處理該支付交易。
在收單方域106包含確認服務器的情形下，確認服務器136確認PARes消息的簽名。確認服務器136接著將簽名確認的結(jié)果返回到MPI 134。如果簽名未被確認，則MPI告知商家利用賬戶認證系統(tǒng)未能使交易進行下去。另一方面，如果簽名被確認，則商家繼續(xù)進行已認證的支付交易。如線6a所示，還可將PARes消息從商家傳遞至它的收單方支付處理器140。接著，可將PARes消息從收單方經(jīng)過遠程通信網(wǎng)絡142傳遞至發(fā)行機構(gòu)。因此，支付者認證結(jié)果作為標準支付授權過程的部分對發(fā)行機構(gòu)來說是有用的。
現(xiàn)在將討論與各種傳輸通道有關的安全問題。作為底線，所有傳輸通道優(yōu)選地利用128-位SSL進行加密。賬戶持有者和商家之間的通道包括兩個通道。商家應當保護在賬戶持有者通過使用從服務組織核準的認證中心獲得的SSL證書輸入支付信息時所使用的連接。商家還應當保護用來通過使用從服務組織核準的認證中心獲得的SSL證書將PARes消息從賬戶持有者傳輸?shù)組PI時所使用的連接。
賬戶持有者和ACS之間的通道應當通過使用從服務組織核準的認證中心獲得的SSL證書由ACS來加密。該通道用于兩個目的。首先將PAReq消息從MPI發(fā)送至ACS，其次將已簽名的PARes消息從ACS發(fā)送至賬戶持有者。
賬戶持有者和登記服務器之間的通道應當通過使用從服務組織核準的認證中心獲得的SSL證書由登記服務器來加密。該通道用來接受賬戶持有者登記信息。
商家和目錄服務器之間的通道以及目錄服務器和ACS服務器之間的通道應當通過服務組織發(fā)行的SSL加密證書來保護，以便于保護包含在VEReq和VERes消息內(nèi)的PAN數(shù)據(jù)以及包含在VERes消息內(nèi)的ACS URL地址。
ACS和賬戶持有者之間的通道應當被加密以此保護賬戶持有者口令的提示以及賬戶持有者輸入的口令。該通道應當利用從服務組織核準的認證中心獲得的SSL證書來保護。
對于大多數(shù)交易來說，支付認證請求和響應消息包括但不限于下列字段消息的版本號、商家的標識符、商家的國家代碼、訂單號、購買日期、購買量、交易狀態(tài)、以及購買項目和條件。同樣地，QueryAccount holderRes消息通常包括但不限于比如下面的字段消息的版本號、商家的名稱、訂單號、購買日期、購買量、卡的有效期和交易污點。這些消息可以是XML(可擴展標記語言)格式的。
在非購買認證交易中，支付認證請求、支付認證響應和QueryAccount holderRes消息可包括消息擴展字段。正如在本領域公知的，消息擴展字段為相對于擴展所附屬的消息來定義附加要素的數(shù)據(jù)字段。這些附加的要素可用來進一步方便特定的交易，包括非支付交易。
具有增值部分的賬戶認證過程圖8說明了涉及包括了增值方面的在線賬戶認證的示范系統(tǒng)體系結(jié)構(gòu)和一組消息流。增值方面涉及在具有增值方的賬戶認證過程中收集的共享信息。這樣的信息涉及提交者，并且可由發(fā)行機構(gòu)或信用方以及申請者來收集。提交者信息因為其高度完整性而具有價值，因為其充當了提交者122認證的基礎。可用交易標識符來標記提交者信息，該交易標識符識別特定的在線交易并規(guī)定該信息源于本發(fā)明的認證過程。增值信息可由增值方196用于與運送、后繼銷售、安全檢查以及工作流程管理有關的各種用途，這里僅列舉了幾個例子。所涉及的所有當事人可受益于共享提交者信息，并且各方可在關于他們?nèi)绾文軌驇椭舜嗽鲋颠@點上達成一致。例如，申請者和增值方可基于提交者信息的共享而在附加的合同條款上達成一致。
現(xiàn)在將參考圖8來描述包括將提交者信息發(fā)送至增值方196的認證過程。圖8將作為基于支付交易而被描述。在這樣的描述之后，圖8還將作為基于非支付交易而被描述。圖8以簡化的形式表示了圖7的消息。
圖8中賬戶認證系統(tǒng)體系結(jié)構(gòu)包括發(fā)行機構(gòu)域102、互操作性域104、收單方域106和增值域107。發(fā)行機構(gòu)域102包括提交者122、ACS 114和發(fā)行機構(gòu)190。提交者122代表了人類提交者和提交者客戶裝置(如計算機終端或移動計算裝置)。發(fā)行機構(gòu)190代表了能夠向提交者122發(fā)行支付卡的發(fā)卡銀行。互操作性域104包括Visa目錄128，在這個實施例中，Visa目錄128是由Visa、認證歷史服務器130和VisaNet 194控制的目錄。收單方域106包括申請者132、MPI 134和收單銀行192。申請者132可以是各種類型的當事人，然而，因為申請者132通常是商家，術語商家可用來替代申請者。增值域107包括增值方196和增值控制服務器198。
圖8的支付交易通過編號為1-14的方向箭頭來描述。支付交易在步驟1處開始，此時提交者瀏覽商家的網(wǎng)站、將他或她期望購買的項目添加到購物車中而后結(jié)束購買。在該點處，商家132擁有包括PAN、到期日以及地址信息的必要數(shù)據(jù)，以此繼續(xù)進行支付交易。
在步驟2處，MPI 134將提交者的主賬號(和用戶裝置信息，如果適用的話)發(fā)送至Visa目錄服務器128，以此檢查提交者PAN是否向賬戶認證系統(tǒng)登記。這個過程發(fā)生在商家結(jié)賬過程期間來自提交者的最終“購買”點擊確認之后。在點擊“購買”之后，商家的軟件調(diào)用MPI 134來格式化查證登記請求(VEReq)消息。MPI 134確定其當前是否具有與Visa目錄服務器128的安全連接。如果安全連接還未建立，則MPI 134建立與Visa目錄服務器134的SSL連接。如果Visa目錄服務器配置表示已經(jīng)向商家132發(fā)行了SSL客戶證書，則在SSL會話建立期間，Visa目錄服務器128將請求商家132提交SSL客戶證書。在安全連接已經(jīng)建立之后，MPI 134將VEReq消息投遞至Visa目錄服務器128。值得注意的是，在各種實施利中，利用各種購買訂單確認過程可完成“購買”點擊確認。
VEReq消息連同認證期間發(fā)送的任何其他消息可包括表示在線認證過程還將涉及與增值方共享提交者信息的指示符。
在步驟3處，如果Visa目錄服務器128確定PAN在參與的卡范圍內(nèi)，則Visa目錄服務器128詢問適當?shù)腁CS(如ACS 114)來確定認證(或認證嘗試的證據(jù))是否適用于PAN。這個過程在Visa目錄服務器128接收來自MPI 134的VEReq消息之后發(fā)生。
為了使Visa目錄服務器128查證PAN是在參與的卡范圍內(nèi)，Visa目錄服務器128確認VEReq消息的句法，并且如果確認失敗的話將錯誤返回。Visa目錄服務器128確認VEReq消息數(shù)據(jù)以確保某些要求被滿足。首先，收單方BIN應當代表參與的收單方。其次，商家ID應當代表由收單方BIN識別的收單方的參與商家。第三，如果收單方的Visa區(qū)域要求賬戶認證服務的商家口令，則口令值應當已經(jīng)接收并且口令應當對收單方BIN和商家ID的組合是有效的。如果任何這些要求未被滿足，則Visa目錄服務器128格式化包括有設置為“N”的PAN認證可用和無效請求消息的查證登記響應(VERes)。值得注意的是，這個VERes不包含賬戶標識符、ACS URL和支付協(xié)議的數(shù)據(jù)字段。在Visa目錄服務器128將VERes消息返回到MPI 134之后，支付交易可以多種方式進行下去。例如，支付交易可到達結(jié)束的終點，支付交易可作為非支付交易繼續(xù)進行，或者提交者可嘗試使用不同的賬號。
Visa目錄服務器128搜尋指定包括有在VERes消息中被接收的提交者PAN的卡范圍的記錄。如果未找到提交者PAN，則Visa目錄服務器128格式化包括有設置為“N”的PAN認證可用但不包括賬戶標識符、ACS URL、支付協(xié)議和無效請求的數(shù)據(jù)字段的VERes消息。接著，Visa目錄服務器128將VERes消息返回到MPI 134，并且賬戶認證再次達到如下所述的、可能的停止點。
假定在Visa目錄服務器128中找到了提交者PAN，Visa目錄服務器128確定其當前是否具有與適當?shù)腁CS的安全連接。如果安全連接還未建立，則Visa目錄服務器128建立與ACS的SSL連接。在SSL會話建立期間，Visa目錄服務器128的SSL客戶證書和ACS的服務器證書應當被提交并被確認。如果第一URL嘗試無效，則將嘗試每個連續(xù)的URL值(如果提供的話)。Visa目錄服務器128可嘗試連接到可選地為每個ACS配置的多達四個預備的URL。如果在每次嘗試時，Visa目錄服務器128不能與URL連接，則Visa目錄服務器128格式化包括有設置為“N”的PAN認證可用但不包括賬戶標識符、ACS URL、支付協(xié)議和無效請求的數(shù)據(jù)字段的VERes消息。接著，Visa目錄服務器128將VERes消息返回到MPI 134并且將賬戶認證過程帶到可能的停止點。
在成功地與URL建立連接之后，Visa目錄服務器128將口令字段從VERes消息中移去并將該消息轉(zhuǎn)發(fā)至ACS URL。
在步驟4處，ACS 114確定PAN認證是否有用，而后向Visa目錄服務器128指示該確定。這個過程在ACS借助于Visa目錄服務器128接收VEReq消息之后發(fā)生。ACS 114確認VEReq的句法并且如果確認失敗的話將錯誤返回。值得注意的是，在不可能認證支付交易時，作為替代，有時能夠提供認證嘗試的證據(jù)。ACS 114使用來自VEReq消息的提交者PAN并詢問位于ACS 114內(nèi)的提交者數(shù)據(jù)庫來確定提交者是否登記。如果未找到PAN，則ACS 114格式化包括有設置為“N”的PAN認證可用但不包括賬戶標識符、ACS URL、支付協(xié)議和無效請求的數(shù)據(jù)字段的VERes消息。ACS 114接著將VERes消息發(fā)送至Visa目錄服務器128。
在步驟5處，Visa目錄服務器128將ACS 114的決定轉(zhuǎn)發(fā)至MPI 134。從Visa目錄服務器128的觀點看，該過程在Visa目錄服務器128將VEReq消息轉(zhuǎn)發(fā)至ACS URL之后發(fā)生。從ACS 114的觀點看，該過程在ACS 114將VERes消息發(fā)送至Visa目錄服務器128之后發(fā)生。
Visa目錄服務器128讀取VERes消息，該消息包含相應的VERes或錯誤值。Visa目錄服務器128確認VERes消息的句法并且如果確認失敗的話將錯誤返回到ACS 114。如果從ACS接收的消息在語句構(gòu)成上是正確的，則Visa目錄服務器128將VERes或錯誤轉(zhuǎn)發(fā)至MPI 134。如果從ACS接收的消息在語句構(gòu)成上是不正確的，則Visa目錄服務器128格式化包括有設置為“N”的PAN認證可用但不包括賬戶標識符、ACS URL、支付協(xié)議和無效請求的VERes消息。Visa目錄服務器128將VERes消息返回到MPI 132并且可能停止賬戶認證過程。從MPI 134的觀點看，該過程在MPI 134將VEReq消息投遞至Visa目錄服務器128之后立刻發(fā)生。從Visa目錄服務器128的觀點看，該過程在Visa目錄服務器128將VERes消息轉(zhuǎn)發(fā)至MPI之后立刻發(fā)生。MPI 134讀取響應，該響應包含相應的VERes或錯誤。如果錯誤消息被接收，則賬戶認證過程可能停止。
在因為各種上述的原因使賬戶認證可能結(jié)束的點處，商家可利用來自結(jié)帳過程的有用信息繼續(xù)進行正常的支付授權。在這種情形下，商家支付系統(tǒng)應當作為超出本文件范圍的未認證的電子商務交易來處理該交易。值得注意的是，電子商務指示符應當被設置成與認證結(jié)果和結(jié)帳過程的特征相應的值。如果在結(jié)帳過程期間商家不能使用由提交者選擇的帳戶來處理未認證的交易，則商家可放棄交易或者給予客戶選擇可替換帳戶的選擇權。如果選擇了可替換帳戶，則可重復認證過程。
在可選用的實施例中，對于每項支付交易，通過將Visa目錄服務器的內(nèi)容復制進商家132的本地高速緩沖存儲裝置，可避免需要詢問Visa目錄服務器以查證提交者在賬戶認證系統(tǒng)中的參與(步驟2-5)。如果這種能力被利用，商家132可立刻從高速緩沖存儲器中確定賬戶是否是登記范圍的部分。在商家132處使用本地高速緩沖存儲器的這個可選用的技術從MPI 134格式化卡范圍請求(CRReq)消息并將其發(fā)送至Visa目錄服務器128開始。如果這是第一次高速緩沖存儲器被加載(或者如果高速緩沖存儲器已經(jīng)被刷新并且需要重新加載)，則序列號要素不包括在CRReq中，其將導致Visa目錄服務器128返回參與的卡范圍的整個列表。另外，MPI134應當包括來自最近處理的CRRes的序列號，其將導致Visa目錄服務器僅返回自以前的CRRes以來的變化。序列號是定義Visa目錄服務器128的卡范圍數(shù)據(jù)庫的當前狀態(tài)的值。Visa目錄服務器128向MPI 134提供序列號。特定值僅僅對返回該值的特定Visa目錄服務器有意義。
Visa目錄服務器128確認CRReq的句法并且如果確認失敗的話將錯誤返回。Visa目錄服務器128格式化包含有參與范圍的卡范圍響應(CRRes)并將其發(fā)送至MPI 134。Visa目錄服務器128包括該響應中的序列號。MPI 134應當保留具有第二天的CRReq消息的要被包括的該值。MPI 134確認CRRes的句法并且如果確認失敗的話應當將錯誤發(fā)送至Visa目錄服務器128。MPI 134更新其本地高速緩沖存儲器。應當以返回的順序來處理具有如由動作要素表示的添加或刪除的范圍的列表。值得注意的是，如果CRRes表示關于序列號的錯誤條件，MPI應當清除其高速緩沖存儲器并提交不帶序列號的CRReq。
在認證對提交者的PAN有效時，MPI 134借助于122處的提交者客戶裝置將支付者認證請求(PAReq)消息發(fā)送至ACS 114。步驟6表示PAReq消息被發(fā)送至提交者客戶裝置122。這個過程在MPI134接收來自Visa目錄服務器128的VERes消息之后立即發(fā)生。MPI134確認VERes消息的句法并且如果確認失敗的話應當將錯誤發(fā)送到Visa目錄服務器。MPI 134格式化包括有在VERes中接收的賬戶標識符的PAReq消息。
認證過程的這個實施例包含了商家132和發(fā)行機構(gòu)190之間的提交者相關的信息的共享。發(fā)行機構(gòu)190和商家132的每一方可收集單項或多項交易中的大范圍的關于提交者的信息。這樣的信息可包括關于某一提交者的購物習慣的信息。這樣的信息對各方(如商家132、發(fā)行機構(gòu)190和增值方296)可能是有用的。在認證過程期間，通過在PAReq和PARes消息內(nèi)包含這樣信息，這樣的客戶信息可在商家132和發(fā)行機構(gòu)190之間共享。因此，在步驟6處，商家132可包括在涉及提交者122的PAReq消息信息內(nèi)。
MPI 134構(gòu)建了包含下列字段的表單PAReq、TermUrl(其為商家的URL，最后的答復應當被投遞于此)以及MD(“商家數(shù)據(jù)”)字段。MD字段包含應當被返回商家的商家狀態(tài)數(shù)據(jù)。這個字段用來提供不同方式商家系統(tǒng)操作對話狀態(tài)。如果商家系統(tǒng)在無任何另外的協(xié)助的情形下，可使最后的投遞與最初的購物對話相關聯(lián)，則MD字段可以是空的。如果商家系統(tǒng)未維持給定的購物對話狀態(tài)，則MD可攜帶商家需要繼續(xù)對話的無論什么數(shù)據(jù)。因為該字段的內(nèi)容根據(jù)商家的實際應用而改變，所以ACS應當使之保持不變并且沒有關于該內(nèi)容的假設。
通過使提交者瀏覽器將表單投遞到ACS，MPI 134通過提交者的瀏覽器將PAReq傳遞至在VERes內(nèi)接收的ACS URL。所有連接均為HTTPS以此適應提交者瀏覽器。
步驟7表示PAReq消息從提交者客戶裝置122被發(fā)送至ACS114。這個過程在ACS 114接收包括來自MPI 134的PAReq的郵件之后發(fā)生。下面的描述適用于其中利用口令實施提交者認證的情形?？墒褂闷渌姆椒?如依賴于芯片卡上的應用的那些方法)。ACS114確認PAReq消息并且如果確認失敗的話將錯誤返回。如果確認失敗，則ACS 114格式化具有設置為“N”的交易狀態(tài)和無效請求的PARes消息。
在步驟8中，ACS利用適用于PAN的過程來認證提交者。這些過程包括比如但不限于請求以前在發(fā)行機構(gòu)190和提交者之間建立的口令或PAN，以及向提交者提交數(shù)據(jù)挑戰(zhàn)這樣的技術。例如，數(shù)據(jù)挑戰(zhàn)可包含ACS 114請求提交者客戶裝置122提供將認證提交者或提交者客戶裝置122的身分的特定數(shù)據(jù)響應。在一種方案中，ACS 114可請求客戶提交者裝置創(chuàng)建將認證提交者122的特定密碼?；蛘?，ACS 114可產(chǎn)生認證嘗試的證據(jù)。ACS 144接著格式化具有適當值的PARes消息，而后將數(shù)字簽名施加于響應消息。ACS114對照位于ACS內(nèi)的提交者數(shù)據(jù)庫來確認口令、數(shù)據(jù)響應或密碼。ACS 114還為每項在線交易生成交易標識符(如CAVV)。連同與特定在線交易相關聯(lián)，交易標識符還與在商家132和發(fā)行機構(gòu)190之間共享的客戶信息相關聯(lián)。
在步驟9處，ACS 114將PARes消息返回到提交者客戶裝置122。涉及提交者122的發(fā)行機構(gòu)190維持的信息和交易標識符可被包含在PARes消息內(nèi)發(fā)送至商家。
ACS 114構(gòu)建包含有PARes和MD字段的表單。通過使提交者瀏覽器將表單投遞至MPI，ACS 114將簽名的PARes傳過提交者瀏覽器送至商家的URL(來自MPI的郵件中的TermUrl)。在該過程中，彈出被關閉并且控制返回到商家瀏覽器窗口。
在這個時間點處，ACS 114還可將選擇的數(shù)據(jù)發(fā)送至認證歷史服務器130。例如，ACS 114格式化被發(fā)送至認證歷史服務器130的支付者認證交易(PATransReq)消息。
在認證過程期間所持有的和/或所傳輸?shù)奶峤徽咝畔⒖捎缮碳?32和發(fā)行機構(gòu)190的每一方來存儲。各方可存儲部分或其擁有的全部客戶信息的集合?；蛘?，可將部分或全部客戶信息存儲在認證服務器130中。
在步驟10處，提交者客戶裝置將PARes消息路由至MPI 134。
在步驟11處，MPI 134通過ACS 114確認放置在PARes消息上的數(shù)字簽名。通過ACS 114本身或通過將PARes消息傳送至獨立的確認服務器，可實施數(shù)字化簽名的確認。確認過程利用Visa根憑證來確認PARes簽名。如果利用獨立的確認服務器實現(xiàn)這一點，則MPI 134將PARes發(fā)送至確認過程，確認過程利用Visa根憑證來確認PARes上的簽名，并且認證過程將簽名確認的結(jié)果返回到MPI。
在步驟12處，商家132繼續(xù)進行與收單方192之間的授權交換。
在步驟13處，商家132使用某一組標準來評價所擁有的客戶信息。如果客戶信息集合滿足該標準，則客戶信息和交易標識符被發(fā)送至增值方196。該標準可以圍繞確定增值方196是否期望接收客戶信息的各種問題來考慮。這樣的標準將通過有關認證過程如何操作的更詳細的實例來進行詳細描述。
在步驟14處，增值方196將客戶信息和交易標識符存進數(shù)據(jù)庫，如增值控制服務器198。
步驟15表示可能因為各種目的而發(fā)生的增值控制服務器198和認證歷史服務器130之間的往返通信。這樣的目的包括比如推斷商家132和增值方196之間的交易、爭議解決和數(shù)據(jù)挖掘。
下面描述的部分將描述本發(fā)明各種增值實施例的另外的細節(jié)。
作為增值方的運送公司現(xiàn)在將根據(jù)實施例描述圖8所示的認證系統(tǒng)和過程，在該實施例中，增值方196是被稱為托運方200a的運送公司(“托運方”)。在這個實施例中，提交者122從商家132手中購買需要運送到提交者居住地或其他郵寄地址的產(chǎn)品。被發(fā)送至托運方196的提交者或客戶信息使托運方196能夠?qū)⒇浳镞\至提交者122。如上所述?？蛻粜畔⒕哂懈叨鹊耐暾院拓S富度，因為它來源于認證過程。因此，信息值成為商家132和增值方196的基礎以此進入彼此交易。這些交易類型的范圍可以大大改變。在一個示例中，托運方196依靠客戶信息的完整性和豐富度到達如此的程度，即托運方196原意以更小的成本將產(chǎn)品運至商家132和提交者122。這可能是因為客戶信息聲明，提交者122從不要求將包裹送回至商家的情形。另外，商家132還可依靠這樣的客戶信息到達如此的程度，即托運方196舒適的是從涉及提交者122的回運請求的責任或代價中解脫出來。
認證和增值過程從圖8所示的編號的步驟所描述的認證過程開始。在步驟6和7中，商家132可包括維持在被發(fā)送至發(fā)行機構(gòu)190的PAReq消息中的客戶信息。在步驟9和10中，發(fā)行機構(gòu)190可包括發(fā)行機構(gòu)190維持在被發(fā)送至商家132的PARes消息中的客戶信息。發(fā)行機構(gòu)190還產(chǎn)生交易標識符，其與特定的在線交易和客戶信息相關聯(lián)。
客戶信息可以是比如1)客戶聯(lián)系信息，如名字、郵寄地址、e-mail地址、電話號碼和傳真號碼；2)客戶支付歷史，如全部付清的數(shù)量和拖欠支付的數(shù)量；以及3)運送歷史，如優(yōu)選的運送方法、在沒有返回服務請求的情形下的裝運次數(shù)和準時裝運的次數(shù)?？蛻粜畔⒖砂ㄓ砂l(fā)行機構(gòu)190和商家132收集的任何類型的信息。
還是在步驟9處，客戶信息由商家132和發(fā)行機構(gòu)190的一方或雙方來存儲。或者，客戶信息被存儲在數(shù)據(jù)庫中，如認證歷史服務器130。
在步驟13處，商家132對照某個標準評價客戶信息以確定這樣的信息是否應當被發(fā)送至托運方196。標準可用公式表示，以使如果客戶信息表示比如托運方196可以沒有困難地完成其任務，則將客戶信息發(fā)送至托運方196。通過檢查關于客戶的有效歷史信息，該標準有助于分析運至某一客戶的風險。示范的標準包括1)客戶已經(jīng)同商家進行了大于一定數(shù)量的購物交易了嗎？2)裝運地址是在某國家(比如美國)內(nèi)嗎？3)客戶以前曾經(jīng)未能支付購買嗎？4)客戶以前曾經(jīng)請求過返回裝運嗎？5)客戶是新客戶嗎？6)交易至少是某一貨幣量的嗎？7)運送地址經(jīng)過查證嗎？以及8)運送的國家是低或高風險國家嗎？商家132、托運方196或雙方均可設置標準。
如果客戶信息滿足商家的標準，則客戶信息和交易標識符被發(fā)送至托運方196。因為發(fā)行機構(gòu)190生成了交易標識符，所以托運方196被保證信息的真實性。依賴于客戶信息，在某種程度的裝運無困難并且因此無額外費用的擔保下，托運方196將產(chǎn)品運至客戶122。由于客戶信息所提供的對托運方196的無麻煩交易的擔保，商家132和托運方196可相互提供額外需要考慮的事項。例如，托運方196可能原意以更小的成本將產(chǎn)品運至商家132和客戶122。同樣地，商家132可代表托運方196假設進行裝運的某些風險或者商家132可同意部分補償托運方196的運送成本。
在步驟14處，托運方196將客戶信息連同交易標識符存進增值控制服務器198中。托運方196可利用打印在運送標簽上的交易標識符將產(chǎn)品運至客戶122。
步驟15包含因為各種目的取回交易標識符連同相關的客戶信息。這樣的目的包括但不限于推斷商家132和增值方196之間的交易、爭議解決和/或數(shù)據(jù)挖掘。交易標識符對應于特定的交易并且因此對于追蹤每項交易的歷史是有用的，以使發(fā)行機構(gòu)190、商家132和增值方196可查證關于每項交易的信息。本發(fā)明還可使商家能夠更好地保護自己免遭其中客戶會辯解他或她未進行某次購買的購買欺詐行為。本發(fā)明還可使運送公司能夠更好地保護自己免遭其中客戶也許會虛偽地聲明未接收到發(fā)送的貨物的運送欺詐行為。
在“推”或“拉”的情形下，可從認證歷史服務器(AHS)130中取回客戶信息?！巴啤鼻樾问瞧渲惺录谕l(fā)生并且因此客戶信息被推給接受者(即增值方196)的情形?！袄鼻樾问瞧渲袃H僅根據(jù)不規(guī)則發(fā)生的事件由接受者拉出客戶信息的情形。例如，僅在需要對照存儲在AHS 130內(nèi)的客戶信息和交易標識符進行確認的爭議出現(xiàn)時，可拉出客戶信息。
可從AHS 130中取回客戶信息和交易標識符以此推斷交易。這些交易是以共享客戶信息為基礎的，并且包括各方同意的附加項目。這些交易被稱為增值交易，因為客戶信息成為各方受益的附加交易的基礎。例如，增值交易的一方可接受額外的業(yè)務機會、接受更有競爭力的貨物或服務價錢、和/或接受更有利的合同條款。某些交易包括托運方196根據(jù)某些條款為商家132運載產(chǎn)品的協(xié)議。這樣的條款可包括支付給商家132的更低的運送價錢和/或商家132承擔的責任和風險。通過檢查客戶信息和交易標識符，商家132和托運方196可查證托運方196進行了某些裝運。接著，比如，商家132向托運方196支付折扣的運送費用。在取回這樣的信息是用于推斷這樣的交易的正規(guī)過程時，取回推斷交易的客戶信息和交易標識符為推交易。
客戶信息和交易標識符還對爭議解決情形是有用的。爭議可出現(xiàn)在任何商家132、客戶122和托運方196之間。通過利用來自AHS130的信息證明關于交易的事實可解決爭議。在爭議出現(xiàn)時，客戶信息和交易標識符從存儲這種信息的位置處被“拉出”。商家和托運方之間的爭議可能涉及各方之間增值交易的履行。例如，運送服務支付上出現(xiàn)分歧時，商家132可使用這種信息來證明裝運是托運方196在同意的和折扣的運送費用的基礎上進行的?；蛘咴诳蛻舯г贡热邕\貨未收到或者商品在運送期間被損壞時，托運方196可證明這種交易的責任由商家132來承擔。在某些實例中，責任可由發(fā)行機構(gòu)190來承擔。
客戶信息和交易標識符還可由商家132、發(fā)行機構(gòu)190和托運方196中的每一個用于數(shù)據(jù)挖掘的目的。這些當事人的每一方通過他們的交易可獲得關于特定客戶的信息，對其進行分析以此確定這些客戶的特點和癖好。這樣的特點和癖好對各商家132、托運方196和發(fā)行機構(gòu)190的銷售目的是有用的。商家132可使用關于客戶特點和癖好的信息來確定針對客戶的未來的銷售和市場策略。托運方196還可將這樣的信息用于比如風險分析，以此確定在未遭遇困難的情形下將產(chǎn)品運至客戶的可能性。發(fā)行機構(gòu)190可使用這樣的信息來確定向客戶發(fā)行未來帳戶的風險等級或者確定信用等級是否應當增加。
另外，信息可由任何一方用來確定關于任何另外當事人的特征。例如，托運方可確定加入與某一商家的協(xié)議是否將是明智的業(yè)務決策。為了實施這種分析，可分析客戶信息以此確定商家的欺詐歷史、扣款歷史、其客戶的裝運的共同國家等。當這種信息表明與特定商家的交易通常是易于裝運的，則商家可決定與這樣的商家進行更多的業(yè)務。商家可分析這樣的數(shù)據(jù)以此確定他們是否期望特定托運方滿足其運送需求。例如，客戶數(shù)據(jù)可表明哪些商家具有較高的交貨成功率和按時交貨評分。
在商家132和發(fā)行機構(gòu)190的一方或雙方持有客戶信息的實施例中，可從各自實體取回客戶信息和交易標識符。
在本發(fā)明的運送實際應用的可選用實施例中，商家132可將特定交易的客戶數(shù)據(jù)和交易標識符的副本發(fā)送至多個托運方。因為客戶數(shù)據(jù)來源于認證過程而具有高度的完整性，每個托運方196可能對實施交易運送感興趣。每個托運方196可能感興趣，因為客戶信息的完整性確保了與交易相關的信息的真實性，如運送地址。更重要的是，因為客戶信息在通過商家的標準之后被發(fā)送至每個托運方196，所以確保每個托運方196遭遇運送交易問題的低的可能性。在可選用實施例中，托運方196將至少了解到涉及特定交易的風險等級。而且，托運方196可能對運送用于交易的產(chǎn)品感興趣，因為商家132或發(fā)行機構(gòu)190可能已經(jīng)同意承擔與交易有關的風險成本。已經(jīng)了解交易和客戶之后，每個托運方196可接著向商家132報出其運送成本的出價。商家132可因此選擇其中一個托運方196來運送產(chǎn)品。
作為增值方的后繼商家在圖8所示的認證和信息共享過程的可選用實施例中，增值方196是后繼商家196。在這個實施例中，本發(fā)明可增加后繼商家196的收入機會，并且在某些情形下，可增加商家132和發(fā)行機構(gòu)190的收入機會。后繼商家196接收來自商家132的客戶信息和交易標識符，并使用這樣的信息將其自己的貨物和/或服務銷售給客戶122。后繼商家196可提供任何類型的貨物或服務，但是它們可能多少與商家132銷售的貨物或服務有關。來自商家132的客戶信息是有價值的，因為客戶122很可能購買與商家132的交易主題有關的某些東西。商家132和后繼商家196可互相基于客戶信息加入各種協(xié)議。
這個過程還可從圖8所示的編號的步驟所描述的認證過程開始。在步驟6、7、9和10中，商家132和后繼商家196通過在如前所述的PAReq和PARes消息中包括這樣的信息來共享關于客戶122的信息。同樣地，發(fā)行機構(gòu)190產(chǎn)生交易標識符，其與特定的在線交易和客戶信息相關聯(lián)?？蛻粜畔⒑徒灰讟俗R符還由發(fā)行機構(gòu)190、商家132的各方來存儲或者存儲在單個數(shù)據(jù)庫中，如認證歷史服務器130。
在步驟13處，商家132評價客戶信息以確定該信息和交易標識符是否應當被發(fā)送至后繼商家196。這樣的客戶信息可能涉及比如客戶花費的平均錢數(shù)、客戶花費的最大數(shù)、客戶什么時間進行購物、客戶從誰那兒購買、客戶把錢花在什么上、客戶的性別以及客戶的人口統(tǒng)計信息。應當理解，關于客戶特征的分析范圍是非常大的。如果客戶信息通過了標準，則在步驟13中將該信息發(fā)送至后繼商家196。
在步驟14處，在接收到客戶信息和交易標識符時，后繼商家196將客戶數(shù)據(jù)和交易標識符存進其數(shù)據(jù)庫中，如增值控制服務器198。此時，后繼商家196可利用客戶信息著手針對特定客戶的銷售策略。客戶信息可告知后繼商家196關于如何針對各種客戶編制其銷售策略。例如，關于客戶花費在特定交易上的量的信息將告知后繼商家196有關客戶122可能感興趣的貨物或服務的價格水平。同樣地，關于商家132銷售的貨物或服務的信息告知后繼商家196有關客戶122可能想購買的有關貨物或服務的類型。例如，如果客戶從商家132購買了CD播放器，則后繼商家196可向客戶122銷售某種CD。這樣的交易可被稱為“互補商品”交易。其他互補商品包括比如無繩鉆和可再充電電池、剃刀和剃刀刀片、以及割草機和化肥。
可根據(jù)來自后繼商家196的協(xié)議支配客戶信息的接收，以此向商家132和/或發(fā)行機構(gòu)190提供由客戶信息產(chǎn)生的后繼商家196的任何銷售百分比。這樣的銷售以及類似性質(zhì)的銷售被稱為比如“提升銷售”和“交叉銷售”。正如可以想象的，可根據(jù)商家132和后繼商家196之間的各種協(xié)議支配客戶信息的接收。如上所述，客戶信息是唯一對后繼商家196有價值的，因為其在細節(jié)上是充足的并且具有高度完整性?？蛻粜畔⒃诩毠?jié)上是充足的，因為商家132和發(fā)行機構(gòu)190的一方或雙方已經(jīng)對其進行收集。商家132和發(fā)行機構(gòu)190的各方均處于獨特的位置，以此收集某類關于客戶的信息。最后，客戶信息具有高度完整性，因為其通過了步驟1-12所描述的認證過程。
步驟15再次包含了為了各種目的而取回交易標識符連同相關聯(lián)的客戶信息，例如為了推斷商家132和后繼商家196之間的交易、爭議解決、和/或數(shù)據(jù)挖掘的目的。步驟15可能要求推斷商家132和后繼商家196之間的協(xié)議，其中關于后繼商家196銷售的信息在向商家132發(fā)送后繼銷售的百分比之前被查證。例如，客戶信息和交易識別符可由商家132或后繼商家196取回以此查證后續(xù)銷售是客戶信息的結(jié)果。接著，根據(jù)這樣的查證，貨幣量被發(fā)送至商家132。在這種情形下，客戶信息可作為用于始終貫徹該協(xié)議的規(guī)則的業(yè)務過程被推給一個或兩個商家，或者可以只在需要解決矛盾時拉出客戶信息。
在爭議解決方面，在任何的商家132、后繼商家196或客戶122之間存在爭議的情形下，取回客戶信息和交易識別符。由于商家132和后繼商家196之間協(xié)議可能已經(jīng)被違犯，可發(fā)生爭議。再次，在商家132同意向后繼商家196發(fā)送客戶信息時，后繼商家196可能被要求分享是從客戶信息中得出的任何銷售。接著，在關于后繼商家196給商家132的支付發(fā)生爭議時，可拉出客戶信息。各方可匹配客戶信息和交易標識符，以此查證后繼商家196的某些銷售是否是基于客戶信息而完成的。
關于客戶信息的某些協(xié)議可涉及發(fā)行機構(gòu)190，其中發(fā)行機構(gòu)190還可預期后繼商家196所進行的任何銷售的一部分。
客戶信息還可用于數(shù)據(jù)挖掘目的，其中發(fā)行機構(gòu)190、商家132和后繼商家196的各方可獲得對彼此和客戶的了解。他們對客戶信息的分析可告知各方將來彼此的交易是否將是有利的。
作為增值方的各種當事人在賬戶認證和增值系統(tǒng)的可選用實施例中，各種類型的當事人可表現(xiàn)為客戶122、商家132和增值方196的角色?？蛻?22和商家132的角色可以是彼此在線互相作用的任何當事人，其中商家132要求客戶身份的認證?？梢韵胂笃渲猩碳?32向客戶122出售某類貨物或服務的許多商業(yè)情形。然而，還可想象許多非商業(yè)情形。某些情形包含針對若干事情(如司機駕照、釣魚許可證、建筑許可證、社會保險支付和學校班級注冊)的在線注冊。應當理解，其中當事人(如商家132)將要求另一當事人(如客戶122)身份認證的情況。
由身份認證當事人(如商家132)評價的標準可能涉及各種類型的增值方196。標準通常將涉及增值方196是否將期望接收關于其身份已經(jīng)由本發(fā)明認證的當事人(如客戶122)的信息。在步驟13中被發(fā)送的客戶信息可能涉及每個不同的增值方196。客戶122申請司機駕照時，客戶信息可涉及比如客戶的駕駛紀錄、所駕駛的汽車、駕駛程序和共同目的地。增值方196可以是期望向與駕駛有關的客戶122銷售貨物或服務的任何當事人。例如，增值方196可以是煙霧檢查公司、維修車間或汽車保險公司。在另外的實施例中，增值方196可以不銷售與駕駛有關的任何東西。然而，增值方196仍然可能正在銷售客戶122可能感興趣的貨物或服務。例如，客戶信息可揭示客戶122駕駛某類汽車，并且因此客戶122可能對某一類貨物或服務感興趣。可從客戶信息中提取出各類關系，并且因此對增值方196是有用的。
在客戶122獲得釣魚許可證時，增值方196可以是比如釣魚用具商店、旅行社或服裝店。此外，增值方196不必是直接與釣魚有關的公司。發(fā)送至增值方196的客戶信息可涉及客戶關于釣魚的喜好。由商家122評價的標準可確定客戶122喜歡哪一類釣魚用具、最喜歡哪種釣魚方式、客戶122喜歡去哪里釣魚、以及客戶122使用的服裝種類。
同樣出于工作流程的目的，可將客戶信息發(fā)送至增值方。例如，在客戶122向商家122申請建筑許可證或執(zhí)照之后，有必要將客戶信息發(fā)送至另一個政府機構(gòu)獲得下一步批準。例如，消防代表可能需要接收客戶信息以便于在房屋建造期間安排消防安全檢查。
商家122和增值方196的各方還可相互基于客戶信息和交易標識符的共享而加入增值關系。
在某些實施例中，商家122可以向多個增值方發(fā)送客戶信息和交易標識符。商家122可評價針對每類增值方196的不同的或相同的標準集合。每個增值方196接著將繼續(xù)或并行或依次一個接一個地實施其任務。增值方196可實時地執(zhí)行其相應的任務，以使客戶122接收來自各增值方196的即刻通知或者可離線執(zhí)行該任務。
如上所述，步驟15可用于推斷任何商家132、增值方196和發(fā)行機構(gòu)190之間的協(xié)議的各種目的。
作為增值方的安全組織本發(fā)明的某些實施例可用于安全目的，如國家安全。在這樣的實施例中，增值方196可以是負責檢查有關安全事務的情報(數(shù)據(jù))的政府機構(gòu)或任何組織。商家132可以是與客戶122進行在線交易的任何商業(yè)的、非商業(yè)的、政府的、或非政府機構(gòu)。例如，商家可以是航空預定公司、硬件商店、化學品供應商、或飛行訓練學校。值得注意的是，某些或全部客戶信息的傳輸可由涉及私權或民事權利的法律來管制。
商家132對照與安全有關的標準來評價客戶信息，并且在某一標準滿足時向增值方196發(fā)送該信息連同交易標識符。例如，該標準可評價客戶的購買項目、許可注冊、旅行目的地、旅行的頻率、以及其他與安全有關的事物。一旦接收客戶信息和交易標識符，增值方196可實施其監(jiān)視任務。
交易標識符對于證明客戶信息是有用的，以使如果必要的話可精確追蹤安全性能審計。這在比如政府制定的安全協(xié)議調(diào)查的情況中可能是必要的。尤其是，可能要求商家132證明他們正確地遵守了安全協(xié)議。在某些情形下，商家132要對法院指令的傳票作出反應。在步驟15中，客戶信息和交易標識符可從認證歷史服務器130推或拉出。步驟15還可用于推斷商家132、報告方和增值方196之間的協(xié)議。例如，商家132可接收用于報告有用信息的識別或信用。在利用交易標識符證明來源、日期和其他有關客戶信息的細節(jié)之后，可接受這個信用。步驟15還可由各方用來從認證歷史服務器130中拉出數(shù)據(jù)用于安全有關的事務的數(shù)據(jù)挖掘。因為客戶信息由發(fā)行機構(gòu)190和商家132收集，所以客戶信息很可能在對于監(jiān)視目的很有用的信息方面是充足的。
在某些實施例中，增值方196和商家132彼此實時地通信，以使增值方196在接收到客戶信息之后可向商家132立即發(fā)送消息。如此，可采取即刻行動以解決或避免不想要的情形。
優(yōu)選系統(tǒng)網(wǎng)絡圖9說明了適合于實現(xiàn)本發(fā)明實施例的遠程通信網(wǎng)絡800。本發(fā)明可利用任何適當?shù)倪h程通信網(wǎng)絡并可包含接著在下面討論的不同的硬件、不同的軟件和/或不同的協(xié)議。下述的網(wǎng)絡是圖2的遠程通信網(wǎng)絡126的優(yōu)選實施例。網(wǎng)絡800是支持使用任何銀行卡、旅行和娛樂卡以及其他私人標簽和私人擁有的卡的購物和現(xiàn)金交易的全球遠程通信網(wǎng)絡。該網(wǎng)絡還支持其他網(wǎng)絡的ATM交易、使用紙質(zhì)支票的交易、使用智能卡的交易以及使用其他金融工具的交易。
這些交易通過網(wǎng)絡授權、清算和結(jié)算服務進行處理。授權在購物結(jié)束或付出現(xiàn)金之前發(fā)行機構(gòu)批準或拒絕銷售交易時發(fā)生。清算在交易從收單方傳遞至發(fā)行機構(gòu)用于投遞到客戶帳戶時發(fā)生。結(jié)算是計算和確定所有已被清算的交易的每個成員的凈財務狀況的過程。資金的實際交流是獨立的過程。
交易可作為雙消息或單消息交易被授權、清算和結(jié)算。雙消息交易被發(fā)送兩次一第一次發(fā)送的只是授權決策所需要的信息，稍后一次發(fā)送的是用于清算和結(jié)算的附加信息。單消息交易只為了授權而被發(fā)送一次并且同樣包含清算和結(jié)算信息。一般地，授權、清算和結(jié)算都是在線發(fā)生的。
遠程通信網(wǎng)絡800的主要組成部分是交換中心802、訪問點804、806和處理中心808、810。其他實體(如票據(jù)支付銀行和申請者授權代理)也可通過訪問點連接到網(wǎng)絡。交換中心是可以位于世界任何地方的數(shù)據(jù)處理中心。在一個實施例中，有兩個在美國，一個在英國，一個在日本。每個交換中心安放有實施網(wǎng)絡交易處理的計算機系統(tǒng)。交換中心成為網(wǎng)絡的遠程通信設施的控制點，其包含了基于IBM SNA協(xié)議的衛(wèi)星連接或高速租用線路。優(yōu)選地，將交換中心連接到遠程實體的線路820和822使用基于IBM SNA-LU0通信協(xié)議的衛(wèi)星連接或?qū)Ｓ玫母邘掚娫掚娐贰＠萌魏芜m合的ISO8583標準的裝備，在這些線路上發(fā)送消息。
訪問點804或806通常是位于處理中心的小型計算機系統(tǒng)，處理中心在中心主機和交換中心之間進行接口。訪問點便于消息和文件在主機和支持交易的授權、清算、結(jié)算的交換中心之間的傳輸。鏈接826和828通常是中心內(nèi)的本地鏈接并使用中心所推薦的專用消息格式。
數(shù)據(jù)處理中心(如位于收單方、發(fā)行機構(gòu)和其他實體內(nèi))安放有支持商家和業(yè)務點的處理系統(tǒng)，并且維持客戶數(shù)據(jù)和開單系統(tǒng)。優(yōu)選地，每個處理中心被鏈接到一個或兩個交換中心。處理器被連接到最近的交換，并且如果網(wǎng)絡遇到中斷，則網(wǎng)絡自動將交易路由至次級交換中心。每個交換中心還被鏈接至所有其他的交換中心。這個鏈接使處理中心能夠通過一個或多個交換中心彼此通信。同樣地，處理中心可通過交換中心訪問其他程序的網(wǎng)絡。另外，網(wǎng)絡確保了所有鏈接具有多個備份。從網(wǎng)絡的一點到另一點的連接通常不是固定鏈接；相反，在任何給定的傳輸時間，交換中心選擇最可能的路徑。在任何錯誤鏈接周圍，重新路由自動發(fā)生。
圖10說明了安放于交換中心的、提供在線和離線交易處理的系統(tǒng)840。對于雙消息交易，授權系統(tǒng)842提供授權。系統(tǒng)842支持在線和離線功能，并且其文件包括內(nèi)部系統(tǒng)表格、客戶數(shù)據(jù)庫和商家中心文件。系統(tǒng)842的在線功能支持雙消息授權處理。這個處理包含路由、提交者和卡查證、替代處理和其他功能(如文件維護)。離線功能包括報告、開帳單、以及生成恢復公告。報告包括授權報告、例外文件和通知文件報告、POS報告和開帳單報告。從系統(tǒng)842到系統(tǒng)846的網(wǎng)橋使得使用系統(tǒng)842的成員與使用系統(tǒng)846的成員通信，并訪問SMS網(wǎng)關到外部網(wǎng)絡成為可能。
清算和結(jié)算系統(tǒng)844清算和結(jié)算以前授權的雙消息交易。在全球基礎上，一周工作六天，系統(tǒng)844收集財務或非財務信息并在成員之間分發(fā)報告。它還計算稅、費用和結(jié)算總額并且產(chǎn)生報告以此幫助對帳。網(wǎng)橋構(gòu)成了系統(tǒng)844處理中心和系統(tǒng)846處理中心之間的交換。
單消息系統(tǒng)846處理全部財務交易。系統(tǒng)846還可處理雙消息授權和清算交易，并且利用網(wǎng)橋與系統(tǒng)842通信以及根據(jù)需要訪問外部網(wǎng)絡。系統(tǒng)846處理Visa、Plus Interlink和其他卡交易。SMS文件包含內(nèi)部系統(tǒng)表格和提交者數(shù)據(jù)庫，所述內(nèi)部系統(tǒng)表格控制系統(tǒng)訪問和處理，提交者數(shù)據(jù)庫包含了用于PIN查證和替代處理授權的提交者數(shù)據(jù)的文件。系統(tǒng)846在線功能實施用于授權以及全部財務交易的實時提交者交易處理和例外處理。系統(tǒng)846還積累對帳和結(jié)算總額。系統(tǒng)846離線功能處理結(jié)算和資金轉(zhuǎn)移請求并提供結(jié)算和活動報告。結(jié)算服務848將系統(tǒng)844和846的結(jié)算功能(包括Interlink)合并成針對所有產(chǎn)品和服務的單項服務。清算繼續(xù)由系統(tǒng)844和系統(tǒng)846單獨實施。
圖11說明了遠程通信網(wǎng)絡800的組成部分的另一個視圖。集成支付系統(tǒng)850是用于處理所有在線授權和財務請求交易的主要系統(tǒng)。系統(tǒng)850報告雙消息和單消息處理。在兩種情形下，結(jié)算獨立發(fā)生。三個主要的軟件部分是公用接口功能852、授權系統(tǒng)842和單消息系統(tǒng)846。
公用接口功能852確定在交換中心接收的每個消息所需要的處理。它基于消息來源(系統(tǒng)842、844或846)選擇適當?shù)穆酚?、處理請求的類型以及處理網(wǎng)絡。這個組成部分實施最初的消息編輯，并且在必要時解析消息以及確保內(nèi)容符合基本消息構(gòu)造規(guī)則。功能852將消息路由至它們的系統(tǒng)842或系統(tǒng)846目的地。
計算機系統(tǒng)實施例圖12A和12B說明了適合于實現(xiàn)本發(fā)明實施例的計算機系統(tǒng)900。圖12A示出的是計算機系統(tǒng)的一個可能的物理形式。當然，計算機系統(tǒng)可具有許多物理形式，其范圍從集成電路、電路印刷板和小巧的手握裝置直到大型超級計算機。計算機系統(tǒng)900包括監(jiān)視器902、顯示器904、外殼906、盤驅(qū)動器908、鍵盤910以及鼠標912。盤914是計算機可讀介質(zhì)，用來向計算機系統(tǒng)900或從計算機系統(tǒng)900傳輸數(shù)據(jù)。
圖12B是計算機系統(tǒng)900的框圖的實例。附加到系統(tǒng)總線920的是大量的子系統(tǒng)。處理器922(還稱為中央處理單元或CPU)耦合至包括存儲器924的存儲裝置。存儲器924包括隨機存取存儲器(RAM)和只讀存儲器(ROM)。正如本領域公知的，ROM表現(xiàn)為將數(shù)據(jù)和指令單方向地轉(zhuǎn)移至CPU以及RAM通常用來在兩個方向上轉(zhuǎn)移數(shù)據(jù)和指令。這些類型的存儲器都包括下述的任何適合的計算機可讀介質(zhì)。固定盤926還在兩個方向上耦合至CPU 922；它提供了額外的數(shù)據(jù)存儲容量并且還可包括下述的任何計算機可讀介質(zhì)。固定盤926可用來存儲程序、數(shù)據(jù)和類似物，并且通常是比主要存儲器更慢的次級存儲介質(zhì)(如硬盤)。將會意識到，在任何適當?shù)那樾蜗?，保留在固定盤926內(nèi)的信息可以標準方式作為虛擬內(nèi)存被結(jié)合進存儲器924。可移動盤914可采用下述的任何計算機可讀介質(zhì)的形式。
CPU922還耦合至多種輸入/輸出裝置，如顯示器904、鍵盤910、鼠標912和揚聲器930。通常，輸入/輸出裝置可以是下列任何裝置視頻顯示器、跟蹤球、鼠標、鍵盤、麥克風、觸敏顯示器、傳感器讀卡器、磁帶或紙帶閱讀器、輸入板、輸入筆、語音或手寫體識別器、生物統(tǒng)計學閱讀器、或其他計算機。利用網(wǎng)絡接口940，CPU 922可選地耦合至另一臺計算機或遠程通信網(wǎng)絡。利用這樣的網(wǎng)絡接口，預計在實施上述的方法步驟的過程中CPU可接收來自網(wǎng)絡的信息或者可向網(wǎng)絡輸出信息。而且，本發(fā)明的方法實施例可單獨在CPU 922上執(zhí)行或者可在網(wǎng)絡(如互聯(lián)網(wǎng))上和遠程的、共享處理部分的CPU一起執(zhí)行。
另外，本發(fā)明的實施例還涉及具有計算機可讀介質(zhì)的計算存儲產(chǎn)品，所述計算機可讀介質(zhì)其上具有用于實施各種計算機實現(xiàn)的操作的計算機代碼。介質(zhì)和計算機代碼可以是為了本發(fā)明的目的特別設計和構(gòu)造的，或者它們可以是公知的類型并且對計算機軟件領域的技術人員來說是可得到的。計算機可讀介質(zhì)的實例包括但不限于磁介質(zhì)(如硬盤、軟盤和磁帶)、光學介質(zhì)(如CD-ROM和全息照相裝置)、磁光介質(zhì)(如光磁軟盤)以及特別被配置成可存儲和執(zhí)行程序代碼的硬件裝置(如特定用途集成電路(ASIC)、可編程邏輯裝置(PLD)和ROM、RAM裝置)。計算機代碼的實例包括比如由編譯器產(chǎn)生的機器代碼和包含由計算機利用解譯器執(zhí)行的高級代碼的文件。
雖然已經(jīng)通過優(yōu)選實施例對本發(fā)明進行了描述，但是存在有屬于本發(fā)明范圍的變更、置換和等同物。應當注意的是，存在有許多實現(xiàn)本發(fā)明的方法和設備的可選用的方式。因此，根據(jù)申請者的意愿，后面所附的權利要求將被認為是包括了屬于本發(fā)明真實精神和范圍的所有這樣的變更、置換和等同物。
權利要求
1.一種用于增值方與在線認證系統(tǒng)進行相互作用的方法，其中提交者的身份在在線交易期間由信用方來認證，所述方法包含接收來自所述提交者的身份認證口令；將所述身份認證口令與以前為所述提交者的帳戶指定的口令進行比較；在接收自所述提交者的所述身份認證口令與以前為所述賬戶指定的口令匹配時，告知申請者所述提交者是所述帳戶的真實所有者，據(jù)此所述信用方為了所述申請者的利益認證所述提交者是所述帳戶的真實所有者；以及將提交者信息發(fā)送至所述增值方。
2.如權利要求1所述的方法，還包含對照一組標準來評價所述提交者信息，并且如果所述提交者信息滿足所述組的標準，則將所述提交者信息發(fā)送至所述增值方。
3.如權利要求1-2中的一個所述的方法，還包含將支付認證請求消息從所述申請者發(fā)送至所述信用方，以此請求所述信用方認證所述提交者的所述身份。
4.如權利要求3所述的方法，其中所述支付認證請求消息包括由所述申請者維持的提交者信息。
5.如權利要求4所述的方法，還包含將支付認證響應消息從所述信用方發(fā)送至所述申請者。
6.如權利要求5所述的方法，其中所述支付認證響應消息包括由所述信用方維持的提交者信息。
7.如權利要求6所述的方法，還包含由所述信用方生成交易標識符，其中所述交易標識符與所述在線交易相關聯(lián)并且與被發(fā)送至所述增值方的所述提交者信息相關聯(lián)。
8.如權利要求2所述的方法，其中所述提交者信息包括描述所述在線交易主題的信息。
9.如權利要求8所述的方法，其中所述提交者信息還包括關于所述提交者的購買行為信息。
10.如權利要求2所述的方法，還包含在將提交者信息發(fā)送至增值方的操作之前，由所述申請者和所述增值方的各方同意一組權利和義務。
11.如權利要求10所述的方法，還包含在交換所述提交者信息中，將貨幣值從所述增值方轉(zhuǎn)移至所述申請者。
12.如權利要求9所述的方法，還包含由所述增值方將與所述提交者信息有關的信息發(fā)送至所述提交者。
13.如權利要求7所述的方法，還包含將所述支付認證響應消息和所述交易標識符的副本發(fā)送至歷史服務器以供存儲。
14.如權利要求13所述的方法，還包含從所述歷史服務器取回所述支付認證響應消息和所述交易標識符的副本；以及查證所述交易標識符以此審計所述申請者和所述增值方之間的增值交易。
15.如權利要求14所述的方法，其中為了爭議解決目的所述支付認證響應消息和所述交易標識符的副本由所述增值方取回，還包含將支付認證響應消息和交易標識符的所述副本發(fā)送至所述申請者以便于解決爭議。
16.如權利要求13所述的方法，還包含從所述歷史服務器取回所述支付認證響應消息和所述交易標識符的副本；以及分析所述提交者信息用于數(shù)據(jù)挖掘目的。
17.如權利要求1、2或4-16中的一個所述的方法，其中所述信用方是金融機構(gòu)。
18.如權利要求1、2或4-16中的一個所述的方法，其中所述信用方維持所述客戶的所述賬戶。
19.一種用于托運方與在線認證系統(tǒng)進行相互作用的方法，其中客戶的身份在在線交易期間由信用方來認證，所述方法包含接收來自所述客戶的身份認證口令；將所述身份認證口令與以前為所述客戶的帳戶指定的口令進行比較；在接收自所述客戶的所述身份認證口令與以前為所述賬戶指定的口令匹配時，告知申請者所述客戶是所述帳戶的真實所有者，據(jù)此所述信用方為了所述申請者的利益認證所述客戶是所述帳戶的真實所有者；將客戶信息發(fā)送至所述托運方；以及將購買的產(chǎn)品運至所述客戶。
20.如權利要求19所述的方法，還包含對照一組標準來評價所述客戶信息，并且如果所述客戶信息滿足所述組的標準，則將所述客戶信息發(fā)送至所述托運方。
21.如權利要求20所述的方法，其中所述客戶信息包括郵寄地址。
22.如權利要求19所述的方法，還包含從所述申請者和所述信用方收集所述客戶信息。
23.如權利要求19-22中的一個所述的方法，還包含將支付認證請求消息從所述申請者發(fā)送至所述信用方，以此請求所述信用方認證所述客戶的所述身份。
24.如權利要求23所述的方法，其中所述支付認證請求消息包括由所述申請者維持的客戶信息。
25.如權利要求23所述的方法，還包含將支付認證響應消息從所述信用方發(fā)送至所述申請者。
26.如權利要求25所述的方法，其中所述支付認證響應消息包括由所述信用方維持的客戶信息。
27.如權利要求25所述的方法，還包含由所述信用方生成交易標識符，其中所述交易標識符與所述在線交易相關聯(lián)，并且與被發(fā)送至所述托運方的所述客戶信息相關聯(lián)。
28.如權利要求27所述的方法，其中如果所述托運方接收到所述交易標識符，則所述運送操作僅由所述托運方實施。
29.如權利要求28所述的方法，還包含在將提交者信息發(fā)送至所述托運方的操作之前，由所述申請者和托運方的各方同意一組權利和義務。
30.如權利要求28所述的方法，還包含在所述托運方接收所述客戶信息和所述交易標識符時，以折扣價格生成運送發(fā)票。
31.如權利要求27所述的方法，還包含將所述支付認證響應消息和所述交易標識符的副本發(fā)送至歷史服務器以供存儲。
32.如權利要求31所述的方法，還包含從所述歷史服務器取回所述支付認證響應消息和所述交易標識符的副本；以及查證所述交易標識符以此審計所述申請者和所述托運方之間的交易。
33.如權利要求19-22或24-32中的一個所述的方法，其中所述信用方是金融機構(gòu)。
34.如權利要求19-22或24-32中的一個所述的方法，其中所述信用方維持所述客戶的所述賬戶。
35.如權利要求19-22或24-32中的一個所述的方法，還包含由所述信用方生成交易標識符，其中所述交易標識符與所述在線交易相關聯(lián)并且與所述客戶信息相關聯(lián)；將所述客戶信息和所述交易標識符發(fā)送至多個托運方；接收來自至少某些所述托運方的運送價格報價；以及基于所述價格報價選擇托運方來運送所述購買的產(chǎn)品。
36.一種用于安全組織與在線認證系統(tǒng)進行相互作用的方法，其中提交者的身份在在線交易期間由信用方來認證，所述方法包含接收來自所述提交者的身份認證口令；將所述身份認證口令與以前為所述提交者的帳戶指定的口令進行比較；在接收自所述提交者的所述身份認證口令與以前為所述賬戶指定的口令匹配時，告知申請者所述提交者是所述帳戶的真實所有者，據(jù)此所述信用方為了所述申請者的利益認證所述提交者是所述帳戶的真實所有者；以及將提交者信息發(fā)送至所述安全組織；
37.如權利要求36所述的方法，還包含對照一組標準來評價所述提交者信息，并且如果所述提交者信息滿足所述組的標準，則將所述提交者信息發(fā)送至所述安全組織，其中所述組的標準確定什么時候存在安全事務。
38.如權利要求36所述的方法，還包含將來自所述申請者的支付認證請求消息發(fā)送至所述信用方，以此請求所述信用方認證所述提交者的所述身份。
39.如權利要求38所述的方法，其中所述支付認證請求消息包括由所述申請者維持的提交者信息。
40.如權利要求39所述的方法，還包含將支付認證響應消息從所述信用方發(fā)送至所述申請者。
41.如權利要求40所述的方法，其中所述支付認證響應消息包括由所述信用方維持的提交者信息。
42.如權利要求41所述的方法，還包含由所述信用方生成交易標識符，其中所述交易標識符與所述在線交易相關聯(lián)，并且與被發(fā)送至所述安全組織的所述提交者信息相關聯(lián)。
43.如權利要求37所述的方法，其中所述提交者信息包括至少描述所述在線交易主題的信息。
44.如權利要求43所述的方法，其中所述提交者信息還包括關于所述提交者的購買行為信息。
45.如權利要求43所述的方法，還包含響應接收所述提交者信息，由所述安全組織對所述提交者實施安全檢查。
46.如權利要求41所述的方法，還包含將所述支付認證響應消息和所述交易標識符的副本發(fā)送至歷史服務器以供存儲。
47.如權利要求41所述的方法，還包含從所述歷史服務器取回所述支付認證響應消息和所述交易標識符的副本；以及為安全事務的證據(jù)，分析所述提交者信息。
48.如權利要求37所述的方法，還包含在將提交者信息發(fā)送至所述安全組織的操作之前，由所述申請者和安全組織各方同意一組權利和義務。
49.如權利要求47所述的方法，其中為了爭議解決目的所述支付認證響應消息和所述交易標識符的副本由所述安全組織取回，還包含將支付認證響應消息和交易標識符的所述副本發(fā)送至所述申請者或所述安全組織，以便于解決爭議。
50.如權利要求36-49中的一個所述的方法，其中所述信用方是金融機構(gòu)。
51.如權利要求36-49中的一個所述的方法，其中所述信用方維持所述客戶的所述賬戶。
全文摘要
公開了一種賬戶認證服務，其中在在線交易期間信用方為了申請者的利益查證帳戶持有者的身份。賬戶認證包含請求帳戶持有者的口令、查證該口令以及告知申請者該帳戶持有者的認證是否已經(jīng)得到查證。賬戶認證服務的可選用實施例包括增值部分，其中關于客戶的信息是與增值方共享的。客戶信息關于客戶的細節(jié)是充足的，因為它是由賬戶認證過程中的各方收集的。增值方接著可以各種方式利用該信息。所涉及的所有當事人可受益于共享客戶信息。增值方可能是比如商家、托運方、安全組織或政府組織。交易標識符識別客戶、商家之間的特定交易以及客戶信息。
文檔編號G07F19/00GK1930591SQ200480039179
公開日2007年3月14日 申請日期2004年5月11日 優(yōu)先權日2004年5月3日
發(fā)明者G·E·格爾伯, T·M·－C·李 申請人:國際簽證服務協(xié)會