專利名稱：用于控制一個電子合同的生命周期的方法和裝置的制作方法
這個專利文獻公開的一部分包含遵從版權保護的資料。當它出現在專利商標局專利文件或者記錄中時，版權所有者不反對任何人復制該專利文獻或者專利公開，然而在別的方面卻無論如何都保留對該版權的所有權利。
背景技術：
1.領域本發(fā)明通常涉及在計算機系統(tǒng)和網絡中的商務處理的安全性，更具體地說，涉及使用用來支持商務處理的電子合同。
2.描述諸如因特網和萬維網(WWW)的大規(guī)模計算機網絡已經使得公司自動化先前不可能或者那么做成本效果低進行的它們業(yè)務的某些方面成為可能。最近開發(fā)的與因特網有關的技術已經用于代替早期用于經營商業(yè)的通信形式(例如，電話、傳真、郵件、和個人會議)。這些經營商業(yè)的傳統(tǒng)方法在歷史上已經得到被商業(yè)和法定團體理解得很好的行為和法律的規(guī)范所支持。然而，當商業(yè)實體同意在因特網上經營業(yè)務時，一些用于標識和實施商務關系的傳統(tǒng)機制由電子、自動化的機制所代替。通常，自動化能夠除去幫助限制暴露于欺詐下的物理屏障。當一方親自引導和另一方的業(yè)務時，某些社會規(guī)范，以及法律構造，可以用來幫助保證一個事務是被授權和可實施的。當一個業(yè)務是在因特網上在兩個當事方(它們可能相互不認識，或者彼此非常理解)之間進行時，欺詐的可能性就會增加了。至少，就該電子交易而論，這些當事方可能不確定它們的權利和義務。
電子商務實踐有時被稱為商務處理。商務處理可以指實現諸如一個公司的商業(yè)實體的目標的、人工和自動化動作的任何組合。不涉及外部實體的過程被稱作內部處理過程。那些關注外部、涉及與其它實體的至少某些交互的處理過程被稱作共享的處理過程。當在兩個實體之間經由一個諸如因特網的計算機網絡實現共享的處理過程時，就存在諸如欺詐、拒付、和未授權訪問的危險可能性。
諸如隔火墻、加密套接字協(xié)議層(SSL)、和虛擬專用網絡(VPN)的技術可以用來幫助保護這樣的共享處理過程。然而，因為它們缺乏用安全性強制機制來約束在這些實體之間的商務關系表示(如可以由一個合法合同的條款所定義的那樣)的機制，所以它們是有缺陷的。此外，面向連接的機制(例如，防火墻、SSL、VPN)不能夠以一個其中可以顯著地減少欺詐風險的粒度級別控制商務交互。許多被使用用于電子商務的安全性機制依賴于保持不在一個商務交易任一方的控制之下的私有密鑰的認證中心(CA)。使用外部CA導致一個商務協(xié)議的條款和用于強制這些條款的安全性機制的分離。這個分離導致欺詐發(fā)生的機會。
此外，在網絡中的較低層應用安全增加了一個用戶在用于電子商務實踐的計算系統(tǒng)中必須具有的信任程度。需要一種更好的方法，借此一個共享處理過程的當事方能夠更好地把明確或者隱含地包含在一個商業(yè)合同中的限制鏈接到該計算系統(tǒng)。此外，需要用于管理電子合同的生命周期的方法。
附圖簡要說明通過以下本發(fā)明的詳細說明，本發(fā)明的特征和優(yōu)點將變得明顯，其中
圖1是依據本發(fā)明實施例的共享商務處理的框圖；圖2是一個框圖，說明了依據本發(fā)明實施例的電子合同；圖3是依據本發(fā)明的實施例、使用電子合同的標識和授權處理的流程圖；圖4是依據本發(fā)明的實施例、在使用電子合同的參與者之間的交互的框圖；圖5是一個流程圖，說明了依據本發(fā)明實施例的電子合同生命周期的處理；圖6是一個流程圖，說明了依據本發(fā)明的實施例、用于電子合同的簽訂和驗證過程；以及圖7是一個框圖，說明了依據本發(fā)明的實施例、用于實現和使用電子合同的示例系統(tǒng)。
詳細說明本發(fā)明的實施例包含使用一個稱作電子合同的數據結構的方法。該電子合同可以用來允許使商業(yè)對商業(yè)(B2B)電子商務(ecommerce)自動化而不犧牲端到端的安全性。電子合同可以被廣闊地應用于任何基于公用密鑰密碼系統(tǒng)的電子關系，其中密鑰的使用幫助標識與一個商務關系有關的動作以及其中實體世界的關系也受合同法的控制。本發(fā)明的實施例提供了這樣一個機制，它用于把合法實體(例如，公民、公司、等等)的公共密鑰和商務處理的共享子過程進行綁定在一起，由此把處理過程判定綁定到公共密鑰，該公共密鑰反過來被綁定(非電子地)到商業(yè)合同。因此，本發(fā)明的實施例支持共享的處理過程而不使用信任的第三當事方(類似于認證中心)，以及幫助阻止在這樣處理過程中欺詐的可能性。
本發(fā)明的實施例還描述一種用于管理電子合同的生命周期的方法和裝置。本發(fā)明定義了用于創(chuàng)建和修改共享商務處理的處理過程。它把當事方標識為參與者，其中每個當事方都是共享的貢獻者或者代理，而不具有在這些當事方當中占優(yōu)勢的授權者或者分級結構。本發(fā)明創(chuàng)建了一個其中每個當事方可以在該共享處理過程的操作期間互相交叉檢查的環(huán)境。該電子合同把處理過程單元和角色相關聯(lián)，由此把在電子合同內的一個模板中的條目映射為用于執(zhí)行該共享處理過程的操作的當事方的實際資源。當前的電子合同生命周期管理方法使用事件驅動的機制來引起在該生命周期中的狀態(tài)改變。這個方法阻止了對于檢測是否需要生命周期變化的狀態(tài)變量的不必要的輪詢。這樣就節(jié)省了通信帶寬和處理資源。本發(fā)明的實施例以一種對稱、分布式方式進行操作，同時保持在實體世界合同中所獲取的信任語義，而不用涉及被信任的第三方。
在實體世界中，合同關系開始、進展、和結束。類似地，在實體世界關系的電子表示中，需要一種用于創(chuàng)建、更新和轉讓電子合同的過程。可以為該電子合同定義一個生命周期和相關的系統(tǒng)。該生命周期定義了在創(chuàng)建、管理和廢除一個電子合同中涉及的步驟。在一個實施例中，一個發(fā)表和訂購裝置可以用來實現該生命周期的方法。一個發(fā)表和訂購模型的使用便于電子合同文件的移動以及驅動生命周期本身的執(zhí)行。
在本說明書中對本發(fā)明的“一個實施例”或者“一實施例”的參考意指結合該實施例描述的一個特定特征、結構或者特點被包括在本發(fā)明的至少一個實施例中。因此，遍及本說明書在不同位置出現的短語“在一個實施例中”的出現指的未必都是同一個實施例。
當貿易實體希望共享商務處理時，它們一般地依賴于某種形式的密碼系統(tǒng)來向商務消息交換提供安全性。如果發(fā)送者在一個合同的條款下面能夠被接收者驗證為一種具有權力來交換消息的實體，則該交換是有意義的。條款的機器可讀表示對應于數據結構(諸如處理過程定義、角色名稱、加密密鑰、等)。需要共享處理過程單元的一種通用表示以避免句法上的不一致?？赡苓€存在語義不一致。在確定語義方面商業(yè)合同是所能求助的最終點。能夠在當事方之間采取中間步驟來電子地規(guī)定語法和語義以及查找一種適合于兩個/所有當事方的映射。本發(fā)明的實施例經由電子合同提供了這樣一種以電子形式的通用表示。本發(fā)明把該當事方的公共密鑰和商務處理通信交換綁定在一起。
當前一種用于在兩個或更多當事方之間協(xié)商一個商務關系的方法包含使用一個貿易伙伴協(xié)議。貿易伙伴協(xié)議方法通常不把一個公用密鑰和該商業(yè)活動相關聯(lián)，其中用于那個密鑰的授權機構還用于保護在當事方之間的信息交換。該貿易伙伴協(xié)議方法可以使用一個信任的第三方(例如，CA)來要求與貿易伙伴相關的公共密鑰，該第三方不共享該共享處理過程的責任，或者不把貿易伙伴密鑰的使用和商業(yè)合同相關聯(lián)。與此相反，本發(fā)明代之以在貿易伙伴(2個或多個)之間使用一個電子合同某些部分的交叉簽訂，由此提供了共享商務處理的貿易伙伴的聯(lián)合意向的電子證據。通過該電子合同的數字簽名允許做出至少幾個聲明。在該電子合同中包含的公共密鑰表示一起合作的一組商業(yè)(或者合法)實體或者當事方。該當事方依據由該電子合同描述的處理過程、手續(xù)、以及約定來合作通過交易。在該電子合同中標識的每個當事方(合法實體)同意該合同而且將由該合同約束。每個當事方將承擔由該合同所定義的法律責任和義務。
在先前的方法下，如果兩個當事方都不能找到信任的、一個諸如CA的第三方，則這兩個當事方必須依賴于較不安全或者較不自動化的裝置來參與商務。如果找到一個信任的第三方，經常會有這樣的情況，即這第三方否認對在交易期間發(fā)生的、不合需要的事件的責任。因此，就有一個原有的當事方獨立地作出它們義務的細節(jié)的需要。本發(fā)明提供了一種用于允許當事方定義可能在一個共享處理過程期間發(fā)生的、預期的通信交換的方法以及用于自動地驗證該商務關系的條款的機制。
圖1是依據本發(fā)明一個實施例的共享商務處理的一個框圖。當事方A 10和B 12期望一起進行電子商務。雖然在這個示例中的僅僅顯示了兩個當事方，但是應當理解任意數量的當事方都可以使用在本發(fā)明中定義的單個電子合同進行通信。當事方A具有一組它希望和當事方B共享的一個或多個電子商務處理14。類似地，當事方B具有一組它希望和當事方A共享的一個或多個電子商務處理16。本發(fā)明使用一個電子合同18來設置在A與B之間的一個關系以便A信任B和B處理過程的結果，以及B信任A和A處理過程的結果。簽訂的電子合同18包含一個獨立的文檔(在一個實施例中以XML的形式)，該獨立文檔包含一個商業(yè)合同的人類可讀和機器可讀的表示，以及能夠用來驗證在貿易伙伴(A和B)之間或者它們的代表者之間的信息交換的加密密鑰。
例如，B可以具有一個處理過程來為B或者B的下屬產生某些結果。因為電子合同18的存在，A和A的下屬能夠信任B處理過程的結果。以一個相應的方式，A可以具有一個處理過程來為A或者A的下屬產生某些結果。B和B的下屬則能夠信任A處理過程的結果。以這種方式，A和B可以以一種可信賴的方式共享處理過程，這是因為該電子合同作為一個定義了A和B的權利、職責、和通信要求的互操作性協(xié)議而起作用。在本發(fā)明的實施例中，該電子合同包含用于A和B中的每一個的、一個非對稱加密密鑰對的公用密鑰。因為分別由貿易伙伴控制的密鑰是描述貿易伙伴操作語義的電子合同的一部分，所以可以斷定該信任關系。由在該電子合同中包含的條款限制的、由A執(zhí)行的操作能夠由B進行解釋，并且期望B的解釋能匹配A的解釋。
本發(fā)明的實施例提供了至少以下的特征。本發(fā)明創(chuàng)建了一個電子文檔(例如，電子合同18)，它包含允許特定合法實體(例如，當事方A 10和當事方B 12)在一個合法合同的保護下參與一個具體共享處理過程的自動化交換所必需的信息。它把加密密鑰和合法實體相關聯(lián)。它還把該加密密鑰和表示該共享處理過程的子過程的標識符相關聯(lián)，其中該共享處理過程可以由一種描述語言所表示。在一個實施例中，該描述語言是XML，但是還可以使用其它的語言而且本發(fā)明在范圍上不限于這一方面。用于該共享處理過程的處理過程定義具有這樣的屬性，即當事方的商務關系的合同義務的語義被整合到該處理過程定義中。本發(fā)明因此把一個人類可讀的合同和一個機器可讀的、電子合同(處理過程定義)相關聯(lián)，因此爭論的解決能夠通過人的干預得以調停。該電子合同明確地聲明由該當事方達成一致的且用于該共享處理過程的服務，諸如檔案的審計、加時間戳、和保存。該電子合同還明確地聲明可以用來使涉及影響該共享處理過程的和判定的安全性的語義合格的信息，諸如命名空間的定義和角色映射。另外，本發(fā)明使用多個數字簽名來綁定相關的信息。該簽名的語義是這樣的，即通過簽訂該電子合同，當事方對該電子合同的條款達成一致。
電子合同通?？梢詰糜谄渲杏幸粋€電子表示以及其中體力勞動關系受合同法控制的任何關系。一個用于本發(fā)明電子合同的數學基礎起源于1999年9月，由Carl M.Ellison、Bill Frantz、ButlerLampson、Ron Rivest、Brian M.Thomas、和Tatu Ylonen所著，因特網RFC 2693的“SPKI Certificate Theory”，和1999年，JonHowell和David Kotz在Dartmouth College的Department ofComputer Science Technical Report PCS-TR99-361中的“AnAccess - Control Calculus for Spanning AdministrativeDomains”中公開的研究內容。
圖2是一個框圖，說明了依據本發(fā)明一個實施例的一個電子合同。一個電子合同的其它版本和格式也可以在電子合同生命周期管理的本發(fā)明中使用，而且本發(fā)明在范圍上不受使用的電子合同的特定版本的限制。在一個示例中，電子合同18，也稱作一個互操作性協(xié)議，定義了一個把貿易伙伴和密鑰、合同和商務處理單元(子過程)相關聯(lián)的方案，安全機制可以根據該方案進行存取控制判定。該電子合同包含至少以下的部分。在一個實施例中，通用信息部分30提供了一個指定協(xié)議名稱和標識符的信息，以及當前修訂版等級和歷史數據。命名空間授權部分32描述了表示一個對應于在該電子合同中使用的加密密鑰的域的命名空間的第三當事方。在某些情況中，該共享處理過程的部分或者全部可以由標準或者在該貿易伙伴關系以外的其它組定義。命名空間允許一個公用密鑰與一個對該定義實體的引用相關聯(lián)。在操作上，該過程定義的復雜細節(jié)將不會被包含在該電子合同中，但是被外部引用。命名空間定義了由貿易伙伴接受的外部引用的集合。合同信息部分34提供了有關是該電子合同主題的底層商務協(xié)議的數據。它把在該合同下可能是有責任的當事方和公共密鑰相關聯(lián)。這個部分可以包含諸如合同標識符、有效期、創(chuàng)建日期、仲裁者、有責任的當事方、簽訂的公共密鑰、以及用于這些當事方的聯(lián)系信息(例如，名稱、地址、電話和傳真號、等等)的數據。
處理過程信息部分36提供了一個用于該共享商務處理過程的子過程的角色名稱的映射，以及角色名稱的語法和語義的說明。為了共享處理過程，當事方需要具有用于商務處理過程的子過程的通用定義。例如，當事方A可以支持購買訂單處理，但是使用諸如“P.O.agent”的術語用于執(zhí)行這個功能的A的下屬。然而，當事方B可以使用術語“purchaser”用于在B處由B的下屬執(zhí)行的相同功能。因此，當事方可以具有不同的名稱用于相同的功能。這個部分使用于該商務處理子過程的全異角色名稱一致。為了進一步說明該示例，當執(zhí)行訪問控制估計時，如果一個與購買有關的A的處理過程正被請求的話，則將指定一個“P.O.agent”，但是如果該處理過程在A與B之間共享而且B使用術語“purchaser”，要不是在電子合同中有在B中的“purchaser”到在A中的“P.O.agent”的映射，則這將使一次授權檢查失敗。
支持服務部分38描述了可以在支持該共享處理過程中使用的輔助服務。這樣的服務可以包含保存檔案、執(zhí)行審計、和給該協(xié)議加時間戳。雖然在此描述了三個服務，但是還可以指定其它的支持服務。對于檔案，這部分描述了檔案文件存儲的位置，以及用于保證該存檔數據安全的加密密鑰。對于審查，這部分描述了該審計數據存儲的位置，以及用于保證該審計數據安全的加密密鑰。對于時間戳，這部分描述了該時間戳標明數據存儲的位置，以及用于保證該時間戳數據安全的加密密鑰。在各個實施例中，第三當事方可以被使用來提供該檔案文件、審計、和時間戳的支持服務。如果該服務被外包到第三方，則該部分應當指定該第三方的公用密鑰以便當事方A和B對于該選定的第三方來提供該服務達成一致。這樣就把第三方的公用密鑰和所提供的服務相關聯(lián)。
數字簽名部分40允許貿易伙伴數字地簽訂該電子合同。每個當事方都簽訂該合同，以允許多邊和獨立的驗證。這一部分可以包含當事方的數字簽名以及一個或多個證人(例如，第三當事方)的數字簽名。該數字簽名可以在該電子合同之前或者附加在后面。
表I顯示了采用XML形式的電子合同的一個示例，但是可以使用其它的描述性語言。
表1<！--***************************************************************-->
<！ELEMENT SignedlA(IAData，IASignature)>
<！ELEMENT IAData data ％ IA；>
<！ELEMENT IASignature ％dsigSignature；>
<！--***************************************************************-->
<！--***************************************************************-->
<！--INTEL eContract DTD-->
<！--File nameIA.DTD-->
<！--(C)Copyright INTEL Corporation 2000-->
<！--***************************************************************-->
<！DOCTYPE eContract<！ELEMENT eContract(ECInfo，NameSpace*，Contractlnfo，Processlnfo，Servicelnfo，Comment*)>
<！ATTLIST IA xmlns CDATA #IMPLIED>
<！--***************************************************************-->
<--General information-->
<！--***************************************************************-->
<！ELEMENT ECInfo(AgeementId，AgreementName，Revision？)>
<！ELEMENT AgreementId(#PCDATA)>
<！ELEMENT AgreementName(#PCDATA)>
<！ELEMENT Revision(History*)>
<！ATTLIST Revision rev CDATA #IMPLIED>
<！ELEMENT History EMPTY>
<！ATTLIST History AgreementId CDATA #REQUIRED>
<！--***************************************************************-->
<！--Namespace Authorities-->
<！--***************************************************************-->
<！ELEMENT NameSpace(Id，Location，PublicKey？)>
<！ELEMENT Id(#PCDATA)>
<！ELEMENT PublicKey(#PCDATA)>
<！--***************************************************************-->
<1--Contract Info-->
<！--***************************************************************-->
<！ELEMENT Contractinfo(ContractId，Contract，ValidityPeriod，CreationDate，Arbitor*，LiableParty+)>
<！ELEMENT ContractId(#PCDATA)>
<！ELEMENT Contract(#PCDATA)>
<！ELEMENT ValidityPeriod EMPTY>
<！ATTLIST ValidityPeriod from CDATA #IMPLIED to CDATA #IMPLIED>
<！ELEMENT CreationDate(#PCDATA)>
<！ELEMENT Arbitor(ContactName，SigningPublicKey)>
<！ELEMENT LiableParty(ContactName，SigningPublicKey)>
<！ELEMENT SigningPublicKey(#PCDATA)>
<！ATTLIST SigningPublicKey KeyId CDATA#REQUIRED><！--fingerprint-->
<！ELEMENT ContactName (#PCDATA)>
<！--***************************************************************-->
<！--Process Information-->
<！--***************************************************************-->
<！ELEMENT Processlnfo(ProcessDef，PerformerRoleMapping*)>
<！ELEMENT ProcessDef (#PCDATA)>
<！ATTLIST ProcessDef Type NMTOKEN #IMPLIED Ref IDREF #IMPLIED>
<！ELEMENT PerformerRoleMapping(FromRole，ToRole)>
<！ELEMENT FromRole EMPTY>
<！ATTLIST FromRole domainid CDATA #REQUIRED role NMTOKEN #REQUIRED>
<！--domainId is the′Keyid′fingerprint for liable party-->
<！ELEMENT ToRole EMPTY>
<！ATTLIST ToRole domainId CDATA #REQUIRED role NMTOKEN #REQUIRED>
<！--***************************************************************-->
<！--Support Services-->
<！--***************************************************************-->
<！ELEMENT ServiceInfo(Archive*，Audit*，Timestamp*)>
<！ELEMENT Archive(Location，SignaturePublicKey，PrivacyPublicKey)>
<！ELEMENT SignaturePUblicKey(#PCDATA)>
<！ELEMENT PrivacyPublicKey(#PCDATA)>
<！ELEMENT Audit(Location，SignaturePublicKey，PrivacyPublicKey)>
<！ELEMENT Timestamp(Location，SignaturePublicKey，PrivacyPublicKey)>
<！ELEMENT Location EMPTY>
<！ATTLIST Location Ref CDATA #REQUIRED>
<！--***************************************************************-->
<！--Comment-->
<！--***************************************************************-->
<！ELEMENT Comment (#PCDATA)>
]><！--end of DOCTYPE InteropAgreement-->
表II說明了遵循以上文檔類型描述的一個示例XML文檔。
表II<InteropAgreement>
<IAInfo>
<AgeementId>777777</AgreementId>
<AgreementName>Smith JonesJohnson</AgreementName>
<Revisionrev＝″1.0″> </Revision>
</IAlnfo>
<NameSpace>
<Id>333333</Id>
<Location ref＝″www.intel.com/3″></Location>
<PublicKey>GIE389fjlk8FESfslk32o98743</PublicKey>
</NameSpace>
<NameSpace>
<Id>333334</Id>
<Location ref＝″www.intel.com/4″></Location>
<PublicKey>GIE389fjlk8FESfslk32o98743</PublicKey>
</NameSpace>
<ContractInfo>
<ContractId>777777-1111</ContractId>
<Contract>This is the contract…</Contract>
<ValidityPeriod from＝″Jan 1，1000″to＝″Jan 1，3000″>
<NalidityPeriod>
<CreationDate>Jan 1，999</CreationDate>
<LaibleParty>
<ContactName>John Hancock</ContactName>
<SigningPublicKey keyid＝″289839283>
tioAFSOf389ffa7f873yf</SigningPublicKey>
</LiableParty>
</Contractinfo>
<Processlnfo>
<ProcessDef type＝″purchase order″rer＝″www.standard.org/l″>
<PerformerRoleMapping>
<FromRole domainId＝′12345′ role＝″Purchaser″></FromRole>
<ToRole domainId＝′54321′role＝″Purchase Agent″></ToRole>
</PerformerRoleMapping>
</ProcessDef>
</ProcessInfo>
<Servicelnfo>
</Servicelnfo>
<Comment>
″This is a comment.″</Comment>
</InteropAgreement>
通常，該電子合同允許當事方執(zhí)行在與該共享處理過程有關的當事方之間的通信的標識、身份驗證、和授權的驗證任務。當在兩個貿易伙伴之間的通信期間進行兩個類型的安全判定時，可以查閱本發(fā)明的電子合同。第一個判定涉及根據發(fā)送者的公司從屬關系和在發(fā)送者公司和接收者公司之間共享的商務處理或者多個過程來確定消息(由該發(fā)送者簽名的)是否應當由接收者接受。在這種情況下，該電子合同標識該公司和它們的合同關系。該消息的發(fā)送者然后可以作為在該商務關系中的當事人的之一(例如，當事方A或B)的下屬而被驗證身份。
第二個判定確定該發(fā)送者是否被授權執(zhí)行所請求的動作。該電子合同(如表I中的示例所示)包含允許在任何一個貿易伙伴域中的處理器解決在請求動作中的多義性的信息。多義性能夠至少以以下的形式存在-(語法A＝語法B)，但是(語義A！＝語義B)。
-(語法A?。秸Z法B)，但是(語義A＝語義B)。
授權的估計可以由一個自動化工具執(zhí)行，這是因為該電子合同包含執(zhí)行該映射所必需的信息。對于密鑰，K(A)授權由A執(zhí)行的動作。K(B)授權由B執(zhí)行的動作。在A中定義的角色名稱映射到在B中定義的角色名稱。對兩個都是公共的定義也可以處于該電子合同中。
圖3是依據本發(fā)明的一個實施例、一個使用電子合同的標識和授權處理過程的流程圖。在塊50處，來自一個發(fā)送者的一條消息的接收者標識該發(fā)送者。從該發(fā)送者到該接收者的消息可以請求一個作為在當事方(例如，發(fā)送者當事方和接收者當事方)之間共享的處理過程的一部分且要被執(zhí)行的動作。在本發(fā)明中的標識可以僅僅意指確定該發(fā)送者的標識符。在某些實施例中，它可以或者可以不包含確定該發(fā)送者的具體標識信息，諸如名稱、地址、電話號碼、電子郵件地址、納稅人標識號碼、等等。在塊52處，該接收者確定發(fā)送者的機構(例如，該發(fā)送者是該電子合同的一個當事方嗎？)。在塊5 4處，該接收者通過檢查包含在該消息中的電子合同通過和由先前協(xié)議所定義的該接收者的機構把該發(fā)送者的機構與商務關系相關聯(lián)。這個關聯(lián)可以被執(zhí)行，而不依賴于一個信任的第三方(諸如一個認證書機構)來提供一個用于實現在雙方之間通信的安全性的公共根密鑰分級結構。
如果A和B依賴于一個第三方C，則在A中的驗證處理器將知道A和C的公共密鑰，而不是B的。在B中的請求者將僅僅知道有關B和C的。當一個請求從B發(fā)給A時，需要一個來自C的證書(指示C知道B)。然而，A不會知道A同意的合同是否意指和B同意的合同相同。該協(xié)議的條款被包含在C可能還沒有準確地向B或者A表示的電子合同中。相反，利用本發(fā)明，如果在A與B之間創(chuàng)建了一個電子合同，兩個當事方都具有使用一個它們早已知道的密鑰分別為A或B的公用密鑰，來驗證另一方的簽名的能力。
該接收者在塊56處標識對應于一個或多個共享處理過程的協(xié)議的條款。在塊58處，該接收者驗證-在該消息中由發(fā)送者請求的動作對應于該協(xié)議條款；-該動作被該處理過程允許(即，它被定義了)；以及-該動作允許用于該發(fā)送者。
這個驗證可以通過使用角色來執(zhí)行(例如，發(fā)送者S能夠依據電子合同請求動作X嗎？)。在一個用于遍歷這兩個當事方的下屬機構的技術中可以使用數字證書。如果在公司A中的一個處理系統(tǒng)由A授權，則A將發(fā)布一個證明該處理系統(tǒng)的證書。類似地，在B中的一個處理系統(tǒng)可以具有與B相同的關系。如果A的處理系統(tǒng)請求B的處理系統(tǒng)，則B的處理系統(tǒng)必須確定相對于在A & B之間的合同，A的處理系統(tǒng)是否和A一樣值得信賴。如果在由A & B簽訂的合同中定義了分配給A的處理系統(tǒng)的角色或者其它授權，則B的處理系統(tǒng)安全地斷定A的處理系統(tǒng)被授權做出該請求。該證書允許處理系統(tǒng)代表A和B起作用。
因此，可以提供在一個電子合同中公共密鑰的創(chuàng)造性使用，以便可以根據用于在兩個當事方之間的共享商務處理的密鑰，來強制執(zhí)行通信的安全性。另外，可以在該電子合同中指定第三方支持服務，該第三方支持服務可以由除了該合同的委托當事方以外的實體以這樣的方式提供以便每一個委托當事方可以信任該支持服務提供者。雖然先前的討論集中于在兩個當事方之間的雙邊方案，但是本發(fā)明的實施例還可以用于在多個當事方之間的用于共享處理過程的多邊方案。
圖4是依據本發(fā)明的一個實施例的在共享處理過程101中的參與者以及它們的交互的框圖。當事方A 10的實體顯示在圖4的左側，諸如公司辦事員A 100、處理過程所有者A 102、以及一個或多個A的參與者104。當事方B 12的實體顯示在圖4的右側，諸如公司辦事員B106、處理過程所有者B 108、以及一個或多個B的參與者110。最初，每個希望成為貿易伙伴的當事方使用一個可靠的帶外機制和其它當事方交換非對稱密鑰對的一個或多個公共密鑰112。每個當事方可以向對方發(fā)送一個或多個公共密鑰。該交換可以由該當事方的公司辦事員(例如，公司辦事員A 100和公司辦事員B 106)執(zhí)行。帶外機制的可靠性是這樣的，即，任何呈現給一個當事方的公用密鑰被替換為另一個密鑰而不知道該呈現的當事方(例如，經受了“中間的人”的攻擊)的風險是非常低的。在另一個實施例中，該公用密鑰的加密散列，也稱作密鑰指紋114，可能代替該公用密鑰被交換。在某些情況中，該密鑰指紋的交換可能比該密鑰本身的交換更可取，不過本發(fā)明在范圍上不限制于這一方面。交換密鑰和/或密鑰指紋的公司辦事員或者其它合法代表人具有合法地負責他們的機構以及和其它實體建立商務關系的授權。在缺乏授權的不可否認的證據的地方，可以根據該情形確定當事方的代表的虛假授權。
可能不清楚虛假的授權是否能夠僅僅根據電子交互被推斷或者顯示出來。因此，可能更可取的是潛在的貿易伙伴在共享任何自動化的商務處理之前參與到實體世界中。因此，可以在公司辦事員之間親自交換公共密鑰和密鑰指紋。至少有幾種方法來完成該交換。例如，該公司辦事員可以物理上交換具有該當事方的一個或多個公共密鑰和/或密鑰指紋的名片、公司信頭、公司文獻、或者其它文檔。
在該當事方談妥了一個控制他們關系的合同之后，該公司辦事員使用該密鑰對中的私有密鑰數字地簽訂電子合約116(它定義了共享處理過程101)。公司辦事員可以把該電子合同的簽訂職責授權給另一個密鑰，但是如果他或者她這樣做了的話，則他或者她必須在該合同下使用一個角色證書明確地限制授權。角色證書可以是包含公用密鑰以及區(qū)分諸如與該共享處理過程有關的角色的信息的電子文檔。角色證書可以由參與者呈現給對方，來依據在該電子合同中定義的信任規(guī)則，驗證該呈現的當事方是否被授權來執(zhí)行該共享處理過程的至少一部分。角色證書把資源(諸如參與者)和共享處理過程單元相關聯(lián)。該角色證書可以被簽名，由此把該密鑰和包含在其中的信息綁定在一起。任何用于執(zhí)行該角色證書的數字簽名的密鑰必須是來自該電子合同的用于該共享處理過程的密鑰或者那個密鑰的一個代表(例如，在同一個密鑰分級結構中)。該當事方必須同意作為該電子合同的創(chuàng)建的一部分的委托機制。該委托機制可以包含定義用于使用密鑰和管理該共享處理過程的規(guī)則的角色證書的發(fā)布。
該電子合同可以由檔案代理118存儲。該檔案代理可以把該電子合同分發(fā)給處理過程所有者102、104，以及購買/訂購代理120、購買/訂購代理120按序可以把該電子合同分發(fā)給參與者104、110。在一個實施例中，該檔案代理可以是和該購買/訂購代理相同的實體(即，他們的功能可以被一起處理)。
公司辦事員A 100然后向處理過程所有者A 102發(fā)布一個或多個授權證書122。類似地，公司辦事員B 106向處理過程所有者B 108發(fā)布一個或多個授權證書122。處理過程所有者使該共享處理過程自動化。授權證書向處理過程所有者通知用于處理共享處理過程的單元授權。角色證書和授權證書執(zhí)行一個類似的功能-描述在密鑰持有人的權利/義務上的限制。授權證書明確地說明該權限，而角色證書標識該密鑰持有人所屬的組。角色證書期望看門者(例如，檢驗器)知道什么權限適于該角色。授權證書也包含該權限。如果給出了一個授權證書，則該看門者依據該授權證書和該角色證書這二者在本地檢查權限以查看所請求的訪問是否是允許的。處理過程管理包含用于執(zhí)行與該整體共享商務處理有關的特定操作的授權的委托。這包含劃分由該共享商務處理定義并且包含在該電子合同中的角色，以及經由角色證書124把角色委派給參與者。一個處理過程所有者可以是一個個人或者任何用于執(zhí)行該處理過程所有者功能的處理系統(tǒng)。一個處理過程所有者可以通過把任何變化128傳送給一個公司辦事員來更新該處理過程，從而就使該變化可以被并入到一個更新的電子合同中。
參與者可以是由一個當事方使用來執(zhí)行該共享處理過程101的一個或多個單元或者部分的個人或者處理系統(tǒng)(例如，資源)。參與者還可以在該處理過程中的任何地方出現的戰(zhàn)略要點處，執(zhí)行強制該共享處理過程的完整性的角色。參與者可以與購買/訂購代理120登記126在一起以便作為該處理過程的一部分，與由角色證書定義的他們的指定角色一致。參與者可以在該共享處理過程期間使用他們的私有密鑰來保密至被綁定到該電子合同的另一個當事方的消息。
因此，本發(fā)明的實施例提供了一個合同、角色、委托、和驗證的系統(tǒng)，通過該系統(tǒng)可以在貿易伙伴之間共享處理過程。此外，自動化策略可以被并入到該系統(tǒng)中而不用折衷安全性要求。
圖5是一個流程圖，說明了依據本發(fā)明一個實施例的電子合同生命周期的處理。在塊200處，該當事方確定用于共享處理過程的需要。當公司的辦事員或者其它代表決定一個共享的自動化商務處理將被需要或者需要時，這可以正式地或者非正式地出現。依據本發(fā)明的實施例，任一方可以啟動該電子合同的生命周期。如果該當事方同意需要一個共享的處理過程，則該當事方可以在塊202處交換密鑰指紋和/或在塊204處交換公共密鑰。雖然在此顯示的示例詳細地說明了一個在兩個當事方之間共享的處理過程，但是具有任意數量的當事方在一個共享處理過程中合作被認為是在本發(fā)明的范圍之內。因此，所有的當事方都可以交換密鑰和/或密鑰指紋。每個公司辦事員或者代表可以記錄哪個密鑰和/或密鑰指紋屬于哪個對方。這個處理過程在某些時刻，可以簡單到交換包含該密鑰和/或密鑰指紋的商業(yè)名片。如果一個當事方的公用密鑰長到不容易被交換，則當事方可以交換密鑰指紋而不是密鑰。在塊206處，當事方協(xié)商控制該共享處理過程的電子合同條款，以及定義用于處理過程單元的允許角色。在某些情況中，該電子合同可以完全地代替紙件合同。
在塊208處，當事方簽訂/驗證該電子合同。圖6是一個流程圖，說明了依據本發(fā)明的一個實施例簽訂和驗證電子合同的處理過程。該簽訂處理過程涉及使用包含在該電子合同內的公共密鑰之一傳播和簽定該電子合同的步驟。公司辦事員或者他或者她代表之一(例如，處理過程所有者或者參與者)替他或者她的機構數字地簽訂電子合同。在塊300處，該未簽訂的電子合同被呈現給當事方之一的公司辦事員，諸如公司辦事員A 100。該電子合同至少包含與其共享處理過程的貿易伙伴的公用密鑰(多個)。在塊302處，公司辦事員A 100使用他或者她的密鑰指紋來驗證在該電子合同中的B的公用密鑰表示在A與B之間的一個合法關系。如果該驗證通過了，則在塊304處，公司辦事員A用對應于一個早已包含在該電子合同中的公用密鑰的A的私有密鑰簽訂該電子合同。
在塊306處，公司辦事員A然后發(fā)送該電子合同(由A簽訂的)到公司辦事員B 106。在塊308處，公司辦事員B驗證該電子合同的內容，確認該合同和該商務關系以及在合同談判期間交換的密鑰指紋一致。在塊310處，公司辦事員B使用包含在該電子合同中的A的公用密鑰驗證A的簽名。如果該驗證通過了，則在塊312處，公司辦事員用對應于一個早已包含在該電子合同中的公用密鑰的B的私有密鑰簽訂該電子合同。在一個實施例中，公司辦事員B僅僅簽訂原有的電子合同區(qū)域并且不簽下可能已經附加于該合同的簽名。獲取其中簽名作為該合同的一部分而加以應用的次序可能不是重要的。該電子合同還允許證人證明合同的簽訂。在這個情況下，該證人可以數字地簽下公司辦事員的簽名。在塊314處，公司辦事員B 106將該電子合同送回給公司辦事員A 100。在塊316處，公司辦事員A可以使用交換的密鑰來驗證在該電子合同上的簽名。因此，公司辦事員A使用包含在該合同中的公司辦事員B的公用密鑰來驗證公司辦事員B的簽名。
當超過兩個當事方正在共享一個處理過程時，每個當事方必須參與在圖6中顯示的動作中以確保每個當事方都被授權為是該共享處理過程的一部分。因此，該電子合同包含所有當事方的代表的簽名，指示所有的當事方都同意該合同。
再次參考圖5，一旦該當事方已經簽訂和驗證了該電子合同，則它就可以被分發(fā)給當事方。在一個實施例中，該電子合同可以由一個檔案代理118在塊210處存儲。該檔案代理可以提供一個服務來確保該電子合同對于所有感興趣的當事方、處理過程所有者、和參與者來說是可得到的。該檔案代理可以由第三方或者由該電子合同的當事方聯(lián)合地操作。在本發(fā)明中，該電子合同本身確保文檔的完整性，因此該檔案代理不需要提供完整性保證。該檔案代理可以把該電子合同提供給處理過程所有者A 102和B 108。接下來，每個處理過程所有者使用該電子合同標識合適的參與者。例如，用于參與者的處理過程和角色名稱可以對應于在該電子合同中的處理過程和角色名稱。該處理過程所有者在塊212處向一個參與者發(fā)布一個角色證書，由此允許該參與者安全地參與由該電子合同控制的共享處理過程。
一旦已經創(chuàng)建了一個電子合同，則它必須對于參與者來說是可得到的。每個參與者與購買/訂購代理120登記在一起，以便在處理過程變化的事件下得到授權變化(例如，密鑰上的變化)、或者安全性受損害的通知。該參與者還在塊214處登記以便接收該原有的電子合同。該電子合同可以在塊216處由購買/訂購代理分發(fā)給登記的參與者。在塊218處，參與者實現該共享的處理過程。
參與者基于和電子合同存在期間的處理過程有關的參與者憑證，進行存取控制判定。對于給定的一個電子合同，參與者還可以進行性能增強。參與者可以保持它支持和登記的電子合同的一個高速緩存，以便在一個電子合同被更新的情況下得到通知。參與者可以獨立地操作直到外部事件要求重置該高速緩存為止。另外，參與者可以預先計算作為該共享處理過程的一部分所涉及的電子合同和證書的有效性。該結果可以由參與者基于該參與者可用的計算資源而加以緩存。在一個資源受限的環(huán)境中，該參與者可以依賴于一個執(zhí)行驗證操作并且返回結果的遠程代理。
在塊220處，可以更新該共享處理過程。如果該商務處理變化了，則可以要求重新簽署電子合同。該處理過程所有者通知公司辦事員，并且公司辦事員確定該處理過程的變化是否使合同無效并且恰當地進行答復。公司辦事員可以1)重新談判該商務協(xié)議，應用處理過程的變化并且重新簽署該電子合同；2)應用處理過程的變化然后重新簽署該電子合同；或者3)拒絕應用該處理過程的變化。其它事件可以觸發(fā)對處理過程變化的需要。如果實體世界合同、處理過程有效期或者證書有效期到期了，則可能需要通知檔案代理和/或購買/訂購代理。如果密鑰被損害了或者發(fā)現了影響該處理過程的安全漏洞，則可以人工地觸發(fā)解決步驟，但是自動地傳送給所有的參與者。電子合同的終止可以以類似于更新該共享處理過程的方式進行處理，公司辦事員引發(fā)一個停止該共享處理過程授權的、更新的電子合同的傳送。
在此描述的合同生命周期就當事方而論是對稱的。任何當事方都可以啟動和對電子合同生命周期事件作出響應。本發(fā)明通過從該系統(tǒng)模型中除去了一個信任的第三方、諸如一個認證書中心，來減少在現有技術系統(tǒng)上的安全風險。利用本發(fā)明，驗證被隱含在由當事方依據電子合同設置的關系中。因為當事方是相互聯(lián)系的委托人，所以當事方的密鑰具有管理該共享的處理過程的等效的授權。
在前面的描述中，已經描述了本發(fā)明的各個方面。為了說明起見，闡述了具體的數字、系統(tǒng)和配置以便提供對本發(fā)明的一個徹底理解。然而，對于具有這個公開優(yōu)點的本領域的技術人員來說，可以實踐本發(fā)明而不用具體的細節(jié)是顯而易見的。在其它實例中，眾所周知的特征被省略或者簡化以便不致弄模糊本發(fā)明。
本發(fā)明的實施例可以以硬件或者軟件、或者兩者的組合來實現。然而，本發(fā)明的實施例可以被實現為在包含至少一個處理器、一個數據存儲系統(tǒng)(包含易失性和非易失性存儲器和/或存儲單元)、至少一個輸入設備、和至少一個輸出設備的可編程系統(tǒng)上執(zhí)行的計算機程序。程序代碼可以應用于輸入數據以執(zhí)行在此描述的功能以及產生輸出信息。該輸出信息可以以已知的方式應用于一個或多個輸出設備。為了這個應用，一個使用該電子合同的處理系統(tǒng)包括任何具有一個處理器的系統(tǒng)，該處理器，例如像，數字信號處理器(DSP)、微控制器、專用集成電路(ASIC)、或者微處理器。
該程序可以以一個高級過程或者面向對象編程語言來實現以便和一個處理系統(tǒng)進行通信。如果期望的話，該程序也可以以匯編或者機器語言加以實現。實際上，本發(fā)明在范圍上不受任何特定編程語言的限制。在任何情況下，該語言可以是一種編譯或者解釋語言。
該程序可以被存儲在可由通用或者專用可編程處理系統(tǒng)讀取的可拆卸存儲介質或者設備(例如，軟盤驅動器、只讀存儲器(ROM)、CD-ROM設備、閃速存儲器設備、數字通用盤(DVD)、或者其它存儲設備)上，以便當該存儲介質或設備由該處理系統(tǒng)讀取時，配置和操作該處理系統(tǒng)以執(zhí)行在此描述的過程。本發(fā)明的實施例也可以考慮作為被配置為和一個處理系統(tǒng)一起使用的機器可讀的存儲介質而加以實現，其中被這樣配置的該存儲介質導致該處理系統(tǒng)以一個具體和預定義的方式進行操作以執(zhí)行在此描述的功能。
在圖7中顯示了一個這種類型處理系統(tǒng)的一個示例，然而，也可以使用其它的系統(tǒng)而且所有顯示的系統(tǒng)部件并非都是本發(fā)明所要求的。例如可以使用示例系統(tǒng)400來依據本發(fā)明，諸如在此描述的實施例，執(zhí)行用于使用該電子合同的方法的實施例的處理。示例系統(tǒng)400表示基于可以從Intel公司買到的PENTIUMII、PENTIUMIII、和CELERONTM微處理器的處理系統(tǒng)，不過還可以使用其它的系統(tǒng)(包括具有其它微處理器的個人計算機(PC)、工程工作站、其他的機頂盒、等等)和體系結構。
圖7是本發(fā)明的一個實施例中的系統(tǒng)400的一個框圖。系統(tǒng)400包括一個處理數據信號的處理器402。處理器402可以與一條處理器總線404相連，該處理器總線404在處理器402和在系統(tǒng)400中的其它部件之間發(fā)送數據信號。
系統(tǒng)400包含一個存儲器406。存儲器406可以存儲由數據信號表示的指令和/或數據，該數據信號可以由處理器402執(zhí)行。該指令和/或數據可以包含用于執(zhí)行本發(fā)明的任何和/或全部技術的代碼。存儲器406還可以包含附加的軟件和/或數據(未示出)。高速緩存器408可以駐留在處理器402的內部，該高速緩存器存儲在存儲器406中所存儲的數據信號。
橋接器/存儲器控制器410可以與處理器總線404和存儲器406相連。橋接器/存儲器控制器410引導在處理器402、存儲器406、及在系統(tǒng)400中的其它部件之間的數據信號，并且橋接在處理器總線404、存儲器406、和第一輸入/輸出(I/O)總線412之間的數據信號。在這個實施例中，圖形控制器413和顯示設備(未示出)接口，該顯示設備用于向用戶顯示由圖形控制器413所繪制或者進行了其它方面的處理的圖像。
第一I/O總線412可以包括單條總線或者多條總線的組合。第一I/O總線412提供了在系統(tǒng)400中的部件之間的通信鏈路。網絡控制器414可以與第一I/O總線412相連。在某些實施例中，顯示設備控制器416可以與第一I/O總線412相連。該顯示設備控制器416允許把顯示設備連接到系統(tǒng)400并且充當在顯示設備(未示出)和該系統(tǒng)之間的接口。該顯示設備通過顯示設備控制器416從處理器402中接收數據信號并且向系統(tǒng)400的用戶顯示在該數據信號中所包含的信息。
第二I/O總線420可以包舍單條總線或者多條總線的組合。第二I/O總線420提供了在系統(tǒng)400中的部件之間的通信鏈路。數據存儲設備422可以與第二I/O總線420相連。鍵盤接口424可以與第二I/O總線420相連。用戶輸入接口425可以與第二I/O總線420相連。該用戶輸入接口可以和用戶輸入設備，諸如遙控裝置、鼠標、操縱桿、或者跟蹤球相連，以便例如向該計算機系統(tǒng)提供輸入數據。音頻控制器427可以與第二I/O總線相連以便通過一個或多個揚聲器(未示出)處理音頻信號?？偩€橋接器428把第一I/O橋接器412和第二I/O橋接器420相連。
本發(fā)明的實施例與使用系統(tǒng)400來處理電子合同有關。依據一個實施例，這樣的處理可以由系統(tǒng)400響應于執(zhí)行在存儲器404中的指令序列的處理器402執(zhí)行。這樣的指令可以從另一個計算機可讀介質，諸如數據存儲設備422中，或者例如經由網絡控制器414從其它源中讀入到存儲器404中。該指令序列的執(zhí)行導致處理器402依據本發(fā)明的實施例執(zhí)行電子合同處理。在一個替換實施例中，硬件電路可以用來代替軟件指令或者與軟件指令相結合來實現本發(fā)明的實施例。因此，本發(fā)明不局限于硬件電路和軟件的任何具體組合。
系統(tǒng)400中的單元以在本領域眾所周知的方式執(zhí)行它們的常規(guī)功能。特別地，數據存儲設備422可以用來提供可執(zhí)行指令和數據結構的長期儲存，其中這些可執(zhí)行指令和數據結構用于依據本發(fā)明處理電子合同，而存儲器406用來以較短期限為基礎存儲該可執(zhí)行指令，該可執(zhí)行指令用來在由處理器402執(zhí)行期間依據本發(fā)明處理電子合同。
雖然已經參考說明性的實施例對本發(fā)明進行了描述，但是這個描述不是用來以一種限制的意思進行解釋。對于本發(fā)明所屬領域的技術人員來說顯而易見的是說明性實施例的各種修改，以及本發(fā)明的其它實施例被認為在本發(fā)明的精神和范圍之內。
權利要求
1.一種管理表示在共享商務處理的至少兩個當事方之間的關系的電子合同的生命周期的方法，包含交換用于每一個當事方的公共密鑰；協(xié)商該電子合同；數字地簽訂和驗證該電子合同；向該共享商務處理的參與者發(fā)布角色證書，該角色證書定義了參與者執(zhí)行該共享商務處理的至少一部分的授權以及使用該公共密鑰的授權；由該參與者進行登記以接收該電子合同；把該電子合同分發(fā)給該參與者；以及由該參與者執(zhí)行該共享商務處理。
2.如權利要求1所述的方法，進一步包括通過修改該電子合同并且把該電子合同重新分發(fā)給該參與者來更新該共享的商務處理。
3.如權利要求1所述的方法，進一步包括在當事方之間交換密鑰指紋以及在驗證該電子合同中使用該密鑰指紋。
4.如權利要求1所述的方法，其特征在于協(xié)商該電子合同包括確定該電子合同的條款以及定義用于參與者和處理單元的允許角色。
5.如權利要求1所述的方法，進一步包括在分發(fā)該電子合同之前由檔案文件代理存儲該電子合同，以及其中登記以接收該電子合同包括由該參與者向購買/訂購代理登記以便接收該電子合同。
6.如權利要求1所述的方法，其特征在于該電子合同依據一個發(fā)表和訂購模型被分發(fā)給該參與者。
7.如權利要求1所述的方法，進一步包括通過修改該電子合同來停止該共享商務處理的授權來終止該電子合同。
8.如權利要求1所述的方法，其特征在于數字地簽訂和驗證該電子合同包括由當事方交叉檢查彼此在該電子合同上的數字簽名，而不涉及信任的第三方。
9.一種物品，包含具有多個機器可讀指令的存儲介質，其中當該指令由處理器執(zhí)行時，該指令通過以下的步驟來為管理提供表示在共享商務處理的至少兩個當事方之間的關系的電子合同的生命周期交換用于每一個當事方的公共密鑰；協(xié)商該電子合同；數字地簽訂和驗證該電子合同；向該共享商務處理的參與者發(fā)布角色證書，該角色證書定義了參與者執(zhí)行該共享商務處理的至少一部分的授權以及使用該公共密鑰的授權；由該參與者進行登記以接收該電子合同，把該電子合同分發(fā)給該參與者，以及由該參與者執(zhí)行該共享商務處理。
10.如權利要求9所述的物品，進一步包括用于通過修改該電子合同并且把該電子合同重新分發(fā)給該參與者來更新該共享的商務處理的指令。
11.如權利要求9所述的物品，進一步包括在當事方之間交換密鑰指紋以及在驗證該電子合同中使用該密鑰指紋。
12.如權利要求9所述的物品，其特征在于協(xié)商該電子合同包括確定該電子合同的條款以及定義用于參與者和處理單元的允許角色。
13.如權利要求9所述的物品，進一步包括用于在分發(fā)該電子合同之前由檔案文件代理存儲該電子合同的指令，以及其中用于登記以接收該電子合同的指令包括用于由該參與者向購買/訂購代理登記以便接收該電子合同的指令。
14.如權利要求9所述的物品，其特征在于該電子合同依據一個發(fā)表和訂購模型被分發(fā)給該參與者。
15.如權利要求9所述的物品，進一步包括用于通過修改該電子合同來停止該共享商務處理的授權來終止該電子合同的指令。
16.如權利要求9所述的物品，其特征在于用于數字地簽訂和驗證該電子合同的指令包括用于由當事方交叉檢查彼此在該電子合同上的數字簽名，而不涉及信任的第三方的指令。
17.一種用于管理電子合同的生命周期的系統(tǒng)，包含共享由該電子合同表示的商務處理的至少兩個當事方，每個當事方包括用于執(zhí)行該共享商務處理中的單元的至少一個參與者，每一個當事方交換與該電子合同相關聯(lián)的公共密鑰，協(xié)商該電子合同，以及數字地簽訂和驗證該電子合同；與該當事方相連用于存儲該簽訂和驗證的電子合同的檔案文件代理；以及與該檔案文件代理和當事方相連用于該從參與者接收注冊以及用于分發(fā)該簽訂和驗證的電子合同到該參與者的購買/訂購代理。
18.如權利要求17所述的系統(tǒng)，其特征在于在該系統(tǒng)中不存在占優(yōu)勢的授權和當事方的分級結構。
19.如權利要求17所述的系統(tǒng)，其特征在于該至少兩個當事方強制參與者執(zhí)行該共享商務處理中的單元的授權而不用使用信任的第三方。
20.如權利要求17所述的系統(tǒng)，進一步包括用于由第一當事方的第一參與者呈現給第二當事方的第二參與者以便依據在該電子合同中定義的信任規(guī)則，來驗證第一參與者被授權來執(zhí)行該共享商務處理的至少一部分的角色證書。
21.如權利要求17所述的系統(tǒng)，其特征在于該當事方交叉檢查彼此在該電子合同上的數字簽名。
22.如權利要求17所述的系統(tǒng)，其特征在于該當事方在當事方之間交換密鑰指紋。
23.如權利要求17所述的系統(tǒng)，其特征在于該當事方確定該電子合同的條款以及定義用于參與者和處理單元的可允許的角色。
全文摘要
管理表示在共享以個商務處理的至少兩個當事方之間的關系的電子合同的生命周期包括交換用于每一個當事方的公共密鑰，協(xié)商該電子合同，數字地簽訂和驗證該電子合同，向該共享商務過程的參與者發(fā)布角色證書，該角色證書定義了參與者執(zhí)行該共享商務處理的至少一部分的授權以及使用該公共密鑰的授權，由該參與者進行登記以接收該電子合同，把該電子合同分發(fā)給該參與者，以及由該參與者執(zhí)行該共享商務處理。可以通過修改該電子合同并且把該電子合同重新分發(fā)給該參與者來實現更新該共享的商務處理。可以通過修改該電子合同以停止該共享商務處理的授權而且把該電子合同重新分發(fā)給該當事方來實現該電子合同的終止。
文檔編號G06Q10/00GK1636217SQ02805055
公開日2005年7月6日 申請日期2002年1月31日 優(yōu)先權日2001年2月15日
發(fā)明者N·M·史密斯, E·迪特爾特 申請人:英特爾公司