專利名稱：用于管理數(shù)字式互動的系統(tǒng)和方法
技術領域：
本發(fā)明一般涉及方便社會交際，更具體地，涉及提供關于人和實體之間關系的結構的系統(tǒng)。背景信息在啞終端時代，每個用戶得到登錄ID和密碼。其用于連接到主機并被映射到被集中管理的特定權限。這是一種非常好的安排，因為要求某種權限的用戶取得被授予的權限， 并最終能夠訪問某些主機資源。這實際上沒有副作用。隨著客戶端/服務器架構的發(fā)展，相同的、登錄ID和密碼的概念得以延續(xù)，但現(xiàn)在有許多網(wǎng)絡，每個網(wǎng)絡都有他們自己的配給登錄ID和密碼的策略。仍然要求每個用戶請求某種權限，獲得被授予的權限，并且取得訪問權。但是現(xiàn)在必須對許多系統(tǒng)重復該過程，并且記住每個系統(tǒng)的用戶ID和密碼變得麻煩，不過不用擔心記住用戶在每個系統(tǒng)上具有的具體權限。在這方面，各種身份管理(IDM)產(chǎn)品開始出現(xiàn)，以使創(chuàng)建ID和密碼的過程更加簡單，并提供更為集中的權限管理。所有這些看起來是一件好事，且只要將IDM的范圍保持在單個企業(yè)內(nèi)，這將對用戶提供顯著的優(yōu)勢，即幾乎沒有不需要的副作用。大部分企業(yè)提供了改變和復查權限的方法，盡管該過程較為不方便，但其在封閉式企業(yè)環(huán)境的背景下是足夠的。隨著因特網(wǎng)的出現(xiàn)，用戶的連接世界突飛猛進地擴大。現(xiàn)在每個用戶都擁有許多身份他們在工作中的角色，作為銀行顧客、作為父母、作為學生，等等。但遺憾的是，對標識符和權限的管理并沒有以相同的方式發(fā)展。配給登錄ID和密碼的過程簡單地轉(zhuǎn)移到互連網(wǎng)上的個別的域(AOL、Yahoo、MSN，等等)中，身份的概念變?yōu)橐粋€單向的過程——用戶提交信息并取回完全由第三方定義的身份。這導致事務的當前狀態(tài)為用戶實質(zhì)上已放棄了她的隱私權，第三方能夠不經(jīng)用戶同意隨意搜集該用戶的個人信息。需要一種通過其用戶能夠自由協(xié)商權力和隱私的系統(tǒng)，其以對所有的聯(lián)網(wǎng)互動都將一致奏效的方式進行協(xié)商。發(fā)明概述本發(fā)明體現(xiàn)匹配新的互聯(lián)網(wǎng)世界的身份的概念。本發(fā)明把用戶重新置于控制地位，其使用的訪問資源的過程圍繞著對雙方同意的條款的協(xié)商，該協(xié)商對于每個關系都是非公開的且唯一的。舊的標識符成為一種關系雙方一致認可的協(xié)商架構，但對于任何第三方則完全不透明。用戶現(xiàn)在位于她建立的每一關系的一端，而且復查條款(或訪問和更新根據(jù)那些條款共享的信息)變得像打開她的電子地址薄一樣簡單。關系聯(lián)絡代理商(RNA)將該示范擴展到在邏輯上補充的階段關系的存在是出于交換信息的目的。信息交換很少基于條款和條件的靜態(tài)集合。而是這些交換隨時間不斷變化，并且條款隨著交換改變。這意味著所有信息實際上是動態(tài)過程的完整的一部分，其定義在復雜關系的背景下發(fā)生的不斷變化的對話的條款。根據(jù)本發(fā)明的RNA架構使這些復雜的互動明確、可管理和安全。
受管理的數(shù)字式互動的一個方面是相互性。每個關系的條款是雙方同意的并且能夠協(xié)商的。隱私作為這些條款的一部分被包括進來。受管理的數(shù)字式互動的另一個方面是互連性。這通過提供相互地和全球工作的互動來實現(xiàn)。由于知識很大程度上是連接數(shù)據(jù)的結果，所以這趨于增加知識。受管理的數(shù)字式互動的另一個方面是允許對話隨時間不斷變化，而在對話中傳達的信息仍然由關系的條款定義。受管理的數(shù)字式互動的另一個方面是主動認證。認證是主動事件，但不需要保持為過去認證的“快照”不變?；拥脑瓌t允許隨時間改變和基于背景改變。根據(jù)本發(fā)明，為了使結果有效，有三個需要遵循的檢驗標準的概念。首先，建立協(xié)商安全通信渠道。其次，建立動態(tài)的合作網(wǎng)絡。再次，動態(tài)決定合作協(xié)議。從優(yōu)選的實施方式的詳細描述，本發(fā)明的這些和其他的特征和優(yōu)點對本領域技術人員來講將變得更加明顯。以下將描述隨附詳細描述的附圖。附圖簡述

圖1是示出根據(jù)本發(fā)明的示例性實施方式的實體的框圖。圖2是示出用戶的示例性關系的示意圖。圖3是示出兩個實體達成合約協(xié)議的示意圖。圖4是示出將一個實施方式應用到衛(wèi)生保健業(yè)的示意圖，其中用戶為醫(yī)院的病人。圖5-11公開了在各種背景下協(xié)商實體的各種步驟。圖12和13公開了對背景敏感的關系的例子。詳述在以下示例性實施方式的討論中，術語“實體”用于指示控制數(shù)字式互動的、人和機器之間的關系。在任何商業(yè)交易中，必須控制對資源，諸如應用和信息系統(tǒng)的訪問。該控制通過確定由包括身份的一組屬性描述的主體是否被授權訪問所要求的資源，然后授予他們權限來執(zhí)行。也通過合約協(xié)議和背景(例如，對某些文件的訪可能被限制在特定的安全區(qū)域)來控制權限。由于商業(yè)機構開放他們的基礎設施，并將他們的網(wǎng)絡和應用擴展到包括客戶、合作伙伴和供應商，這使其面臨一種基本的斷開(disconnect)原則當前沒有一種標準化的方式來“信任”或以中間人的身份安排屬于合作伙伴和其他外部用戶的身份。于是出現(xiàn)了聯(lián)合的身份解決方案，但當機構希望將他們的網(wǎng)絡擴展到大量的經(jīng)常來往的小型合作伙伴時，這些聯(lián)合的身份解決方案被證明實施起來較為困難且成本較高。問題的核心在于信任問題期望機構提前建立所有可能的信任關系簡直是不現(xiàn)實的。需要僅為所需量的時間僅建立適當量的信任，而不是過多量的信任的方式。建立和破壞這些關系必定和發(fā)送電子郵件消息一樣容易，但它也應當提供完備(bullet-proof)的安全性和責任性。密鑰管理使用與在傳統(tǒng)的公共密鑰基礎設施中使用的相同技術(即，本發(fā)明的實施方式不試圖改進已被證明了的加密技術)中的一些。然而，使用本發(fā)明的實體管理密鑰的過程是非常不同的。
密鑰管理是密碼學最難的部分。通常有兩類密鑰，即短期密鑰和長期密鑰。短期會話密鑰(有時稱為短暫密鑰)通常被自動地且不可視地生成。它們用于一則消息或會話并被丟棄。長期密鑰由用戶明確地生成。它們用于認證(包括訪問控制、誠實和不可拒絕) 和保密(加密)。長期密鑰也用于建立會話密鑰和保護存儲的數(shù)據(jù)。本發(fā)明的實施方式被設計為使用所需要的最少量的外圍基礎設施完全透明地處理短期密鑰和長期密鑰。通常僅在最初的提供過程要求進行認證和驗證，因此大大地減少了第三方參與交易的次數(shù)。對于大部分的提供和認證功能，一些實施方式依賴于對到簡單郵件傳輸協(xié)議 (SMTP)和可擴展的通信和表示協(xié)議(XMPP)的簡單協(xié)議擴展，允許參與者通信的服務器處理大部分的交易，而所述交易使用公共密鑰基礎設施通常導致可擴展性問題。本發(fā)明的實施方式提供了靈活的密鑰鑒定框架。有許多為了證實密鑰不需要第三方的情況(例如小型商業(yè)的情況，參與者是建立的關系的一部分的)。在一個實施方式中， 本發(fā)明有效去除了公共密鑰的觀念。取而代之的是，實體嵌入了關于每個關系的唯一的密鑰對，這具有許多好處。獲得其他人的公共密鑰像發(fā)送郵件以便提議關系一樣簡單。沒有涉及公共密鑰——自動提議關系創(chuàng)建專門關于該關系的新公共密鑰。本發(fā)明的實施方式提供了內(nèi)置的保密性和認證。對于保密(即，只與預期方共享信息)，實體嵌入只能被預期的接收者讀取的加密材料。該機制可被擴展，以便應對不斷變化的安全要求。關于認證(即，與預期方共享信息)，實體能夠利用帶外認證機密，它們也能夠使用身份驗證權威，如Equifax。本發(fā)明的實施方式可被用于設計能夠像電子郵件地址一樣被管理的實體。它們能夠存儲在地址簿、活動目錄、或其他適合的庫中。由于沒有公共密鑰，也不需要復雜的廢棄機制。實體可被廢棄，這通過將其刪除并可能地配給一個新的實體。本發(fā)明的實施方式可被配置為應對泄露(compromise)信息導致的影響。關于認證，除非加有時間戳，否則將使已簽字的文件無效。為了應對這種情況，可以重新認證(產(chǎn)生新的實體)且文件可以通過雙方同意被重定密鑰。關于保密性，使用被泄露的實體加密的所有數(shù)據(jù)都被泄露。然而，該作用被嚴格限制到受影響的關系，使得對受影響的材料重定密鑰相當?shù)睾唵巍嶓w是一個按照明確的相互協(xié)商/管理的協(xié)議定義對基于關系的身份進行創(chuàng)建和管理的框架。身份最初以URI或電子郵件地址的形式來表示，其中電子郵件地址包含帶有被提議條款的概要和數(shù)字簽名的唯一加密身份——其結果稱為實體。一個實體能夠正好像規(guī)則的郵件地址一樣使用。實際上，建立基于實體的關系的默認方法是簡單交換電子郵件。然而，本發(fā)明的實施方式不限于這種交換方法。建立實體的過程可以在任何適合的傳輸機制中發(fā)生。實體僅用于建立最初的協(xié)議以進入一個關系。關系的實際條款通過基于工作流的代理商，被稱為NetRNA (網(wǎng)絡關系網(wǎng)絡代理商)來進行協(xié)商。NetRNA是條款的體現(xiàn)和實施。 除非身份是在關系的背景下定義的，否則其沒有實際意義。例子圖1示出了示例性的實體。用戶Alice和Bob均具有一個身份以及與他們各自的公司相關的角色。在他們的企業(yè)的背景中，這些用戶也具有彼此之間的協(xié)商關系。參考圖2，本發(fā)明的實施方式可用于在她與其雇主的關系的背景下創(chuàng)建和管理關于人力資源經(jīng)理的數(shù)字式互動。如果Alice是ABC公司的人力資源經(jīng)理，那么在她與ABC公司的關系的背景下，她的作用可包括雇用雇員、管理福利計劃、并與其他公司達成某些協(xié)議諸如雇用一個分包商(例如，Bob)。本發(fā)明的實施方式可用于定義可分配給Alice和被Alice接受的身份(例如，Alice-ABC公司的HR經(jīng)理)。然后在其作為人力資源經(jīng)理時，該身份可被用于管理和實施Alice與ABC公司的關系的條款。其使用的訪問資源的過程圍繞著對雙方同意的條款的協(xié)商，該協(xié)商對于每個關系都是非公開的且唯一的。本發(fā)明的實施方式允許Alice訪問的資源圍繞對雙方同意的條款的協(xié)商，該協(xié)商對于每個關系都是非公開的且唯一的。舊的標識符成為一種關系雙方一致認可的協(xié)商架構，但對任何第三方則完全不透明。Alice現(xiàn)在位于她建立的每一關系的一端，而且復查條款(或訪問和更新根據(jù)那些條款共享的信息)變得像打開她的電子地址簿一樣簡單。關系的存在是出于交換信息的目的。此外，信息交換很少基于條款和條件的靜態(tài)集合-而是這些交換隨時間不斷變化，并且這些條款隨著交換改變。例如，合作寫一本書具有許多階段，其涉及在該過程的各個點上的不同的人。這意味著所有信息實際上是動態(tài)過程的完整的一部分，其定義在復雜關系的背景下發(fā)生的不斷變化的對話的條款。根據(jù)本發(fā)明的關系聯(lián)絡代理商(RNA)架構使這些復雜的互動明確、可管理和安全。用于Office 2007文檔的開放式XML規(guī)范，和Windows工作流基礎(WffF)和 Windows通信基礎(WCF)的近期發(fā)布為本發(fā)明的實施方式提供了進一步的加強。開放式XML 格式限定了由部分和關系構成的文檔的內(nèi)部框架。根據(jù)一個實施方式，實體表示了關系的條款。通過將開放式XML文檔中的關系的定義進行擴展，以包括一個實體，如這里所述，可創(chuàng)建表示包含多個相關關系的復雜商業(yè)協(xié)議的文檔。以這種方式創(chuàng)建的文檔能夠?qū)⒐芾韺ξ臋n中的每一部分的訪問的條款嵌入，且各種部分可表示非常具體的原則和權限。例如，保留顧問的合約能夠嵌入具體的權限，該權限將建立到打印機、共享資源、日歷視圖，等等的訪問。當與WffF和WCF組合時，可基于能夠安全地跨機構分布的豐富的工作流來創(chuàng)建表示動態(tài)關系的文檔。圖3是示出了根據(jù)一個實施方式的情況的示意圖，其中ABC公司決定與XYZ公司達成關于開發(fā)新的軟件應用程序的臨時職位的合約協(xié)議。在圖3中，我們假設Alice和Bob 已經(jīng)建立了由實體所定義的最初關系。在處理協(xié)商要求(保密性、可查證性，等等)的協(xié)商過程期間創(chuàng)建了新的實體，一旦協(xié)議達成將創(chuàng)建實體來表示最終的條款。一個典型的情況將涉及協(xié)商服務的協(xié)議，然后在ABC公司環(huán)境中提供一個新用戶以允許XYZ公司的訂約人訪問ABC公司內(nèi)的所需資源。該職位將要求創(chuàng)建新的實體。與該締約機構的任何關系從該過程斷開，并且如果這在長時間周期內(nèi)對許多合作伙伴重復該過程，則其結果是在今天的大多數(shù)機構中發(fā)現(xiàn)的那種混亂無序。聯(lián)合的身份解決方案必須在企業(yè)內(nèi)部和跨企業(yè)地管理完整的用戶生存周期。這意指用戶和賬戶創(chuàng)建、賬戶連接、認證、訪問控制和賬戶終止。一旦考慮到身份聯(lián)合，則需要評估與聯(lián)合有關的事項，即誰將參與、它將怎樣管理、以及聯(lián)合的參與者必定承擔什么類型的風險。本發(fā)明的實施方式通過擴展定義了協(xié)議的自然商業(yè)過程來消除這個問題，使得滿足該過程所需要的資源和權限被分配并永久地與協(xié)商的最終產(chǎn)物相關聯(lián)。實際上，與合約相關的資源和權限的整個生命周期都依賴于它，并因此是自描述的而且在很大程度上是自管理的。圖4是示出了根據(jù)一個實施方式的來自衛(wèi)生保健行業(yè)的情況的示意圖，其中Jane 是醫(yī)院的病人。其涉及了關系和隱私原則的復雜集合。使用本發(fā)明的實施方式，可以簡單且有效地處理這種情況，而同時完全保持所要求的隱私和保密性的級別。例如，Jane的醫(yī)生可以訪問Jane的診斷結果，但醫(yī)院的計費部門只能看到產(chǎn)生賬單的所需細節(jié)——而不是實際的診斷結果。實際上，使用了根據(jù)本發(fā)明的實施方式的實體以及開放式XML文件格式的患者記錄能夠?qū)嵤娪辛Φ陌踩胧?，諸如在能夠訪問或共享某些信息之前要求Jane 的明確許可。也能夠非常容易地實現(xiàn)自動跟蹤特性。本發(fā)明的某些實施方式的目的是使安全簡單化。安全、隱私和訪問控制應該像發(fā)送電子郵件、復查文檔，等等一樣簡單和自然。實施方式開始的前提是，對于在定義了身份的關系中所涉及的各方而言，該身份是非公開的。身份的建立是非公開的、安全的協(xié)商的結果。一旦經(jīng)過了協(xié)商，本發(fā)明的實體能夠在協(xié)商階段中同意的期間內(nèi)提供到NetRNA的訪問——沒有廢棄機制且只有關系所涉及的各方能夠改變條款和彼此認證。本發(fā)明的實施方式還提供了一種機會，即將空前的保密級別與關系所涉及的各方的責任進行平衡。每一關系包含唯一的密鑰；在關系之間不可能有交叉引用。通過將實體擴展到開放式XML文檔，有可能無縫地處理最復雜的關系，該關系包括涉及具有復雜的相關原則的多個方的情況。圖5-11公開了在各種背景下協(xié)商實體的各種步驟。圖12和13公開了對背景敏感的關系的例子。實體框架方便了集合性的知識的研究和表示。它包括模塊化的部件結構和安全通信。最后，所有富有意義的數(shù)字式互動涉及在個人(作為一角色)和一個或多個代理商之間的、圍繞某一目的的給-和-收行為。知識作為這些給-和-收行為的結果而出現(xiàn)。參考圖14，示出了該過程的概念圖。如上所示，方便特定互動集合的協(xié)議的實現(xiàn)通過關系聯(lián)絡代理商(RNA)體現(xiàn)。實體結構基本上是分布式網(wǎng)絡，其被設計以方便關系聯(lián)絡代理商(RNA)的例證和管理以通過目的驅(qū)動的追蹤(pursuit)的互連來組合豐富的、全球的、集合性知識網(wǎng)。最終產(chǎn)生的集合性知識能夠以實體形式被形式化。通過將能夠為一個代理商或一群代理商而存在的概念和關系形式化，實體對知識進行編纂。當RNA基于談判的目的創(chuàng)建互連時形成動態(tài)網(wǎng)，其中集合性的知識以目的驅(qū)動向量而非傳統(tǒng)的數(shù)據(jù)提取的形式來表達。這在圖15中示出，其示出了通過關系聯(lián)絡代理商 (RNA)網(wǎng)絡的協(xié)商遍歷路徑(箭頭)。實體是到知識的目的驅(qū)動路徑，其中所有的參與者都積極地合作。在實踐中，其意味著軟件代理商的全球網(wǎng)狀網(wǎng)絡能夠在知識的集合性發(fā)展中安全地進行通信和參與。由角色的一個或多個對象出于同意的目的訪問每個代理商。實體SDK提供了用于配置關系聯(lián)絡代理商的網(wǎng)狀網(wǎng)絡和必要的安全通信基礎設施的基本構造，以便允許通過全球RNA網(wǎng)來協(xié)商和管理實體。本文檔的其余部分重點關注由實體SDK(安全數(shù)字密鑰)提供的、使本文所描述的概念可行的特殊能力。實體SDK具有在以下段落中描述的技術特征。相關密鑰在實體結構中的安全模型的基本構建塊。在本質(zhì)上，其集中在使用橢圓曲線密碼術(ECC)，和經(jīng)過很好的證明的、與所有人的技術組合的、非對稱加密技術，以便根據(jù)同意條款來遞送僅由預期一方(或多方)使用的密鑰。相關密鑰提供了無狀態(tài)的驗證， 并且對于大多數(shù)情況而言，它們也消除了對密鑰拒絕的需要。相關密鑰也嵌入了一些受限的條款以方便密鑰管理。動態(tài)數(shù)字協(xié)議一旦建立安全的通信渠道仍然存在著問題，即要如何應對關于其與協(xié)議趨于隨時間不斷變化的現(xiàn)實。動態(tài)數(shù)字協(xié)議是一個電子協(xié)商和實施的框架，其允許用戶和系統(tǒng)相互協(xié)商可接受的條款，并隨后自動地實施它們。該框架構建在相關密鑰的基礎上，以便提供在能夠定義的協(xié)議類型上的、非常高級別的靈活性，且如果需要協(xié)議能夠隨時間不斷變化。通用角色結構實體結構認可人們傾向于承擔各種角色這一事實。為此，該結構圍繞基本的構造角色來進行組織。角色被定義為由一個實體承擔并由另一個實體擁有的協(xié)議(以接受某些權力和責任)。當角色的擁有者和承擔者相同時，我們具有角色被稱為自然身份的角色的特殊情況。普通角色被實現(xiàn)為實體，但自然身份具有唯一的設計特征且被稱為MI As。該角色結構意味著個人(通過MIRA表示)能夠承擔跨任何數(shù)目的機構的多個角色。安全通信基本的實體結構不提供傳輸層安全特征(例如，源和目的地址的混亂)。主要焦點在于保護信息的內(nèi)容。實體SDK提供了用于各種類型的通信安全的擴展性支持。密鑰安全通信特征包括基于關系的加密、嵌入式的使用控制、權利管理、訪問位置控制，等等。在有非常高的安全要求的背景下，和甚至作為安全路由基礎設施的一部分也具有對配置實體安全通信特征的選擇，但這些特征不包括在實體SDK中。跨組織的工作流無縫地越過防火墻和合作機構擴展實現(xiàn)應用的能力，并且完全安全。實體SDK提供了創(chuàng)建和管理完全跨防火墻和網(wǎng)絡運行的工作流的能力——最終的工作得到控制。記錄和實例水平數(shù)據(jù)庫安全使應用能夠包括存在于內(nèi)部和外部網(wǎng)絡中的數(shù)據(jù)源、系統(tǒng)和用戶數(shù)據(jù)。提供高水平的安全和加密一直到屬性和應用存儲器的目標水平，并跨網(wǎng)絡執(zhí)行那些權限。無國籍許可復雜的用戶的許可能力，其不需要復雜和昂貴的服務器基礎設施，同時允許幾乎無限的、定義適合任何商業(yè)配置情況的許可證條款的能力。該基本概念具有非常廣的應用范圍，其范圍從個人-到-個人的安全通信，到越過防火墻的商業(yè)-到-商業(yè)過程，等等。本文檔的接下來的幾部分探究幾種通常的綜合情況。根據(jù)本發(fā)明，為了使結果有效，有三個需要遵循的檢驗標準的概念。首先，建立協(xié)商安全通信渠道。其次，建立動態(tài)的合作網(wǎng)絡。再次，動態(tài)決定合作協(xié)議。建立安全通信渠道建立安全通信渠道的過程圍繞相互協(xié)商的過程。在一個典型的例子中，Alice希望與Bob建立安全的通信渠道。Alice連接到她的聯(lián)絡代理商。這是一個能夠依靠本地機或遠程訪問的工作流代理商。與聯(lián)絡代理商的通信一直被加密，并且只有Alice能夠使用她自己的聯(lián)絡代理商創(chuàng)建新的連接。聯(lián)絡代理商處理對通信渠道、政策和Alice的變化的偏愛的管理。聯(lián)絡代理商的用戶界面能夠為網(wǎng)頁，但其也可以與普通生產(chǎn)率應用，諸如電子郵件無縫地結合。
Alice決定她愿意向Bob公開哪些憑證。被提供的憑證可包括由第三方提供的、用于證明他們的有效性的安全標志。典型的憑證能夠是電子郵件地址、專業(yè)的會員、或Bob能夠驗證且Alice愿意公開的任何其他證明。在Bob滿足了 Alice在驗證Bob身份的下一步驟將建立的要求后，該憑證包將只有Bob可以訪問。Alice現(xiàn)在決定她將從Bob要求哪些憑證。Alice提供了她自己對于將被使用的憑證的評價。這是一套Bob在訪問由Alice提供的憑證前將必須能夠正確回答的問題和答案。Alice至少必須提供接收者的地址——這是將用于發(fā)送請求的地址。Alice提出通信渠道的屬性?；緦傩园ń刂谷掌?、加密要求、渠道是否能夠被更新，等等。屬性可以擴展，但在通信渠道中它們必須可表示為絕對值，且一旦渠道相互同意，它們將是不可取消和不可變的。聯(lián)絡代理商現(xiàn)在創(chuàng)建新的隨機密鑰對(Ksalice和Krbob)并準備渠道請求包。對Alice愿意與之通信的每一方重復該過程。由于使用的憑證是每個渠道中的身份的組成部分，對Alice而言可能有和使用不同憑證的相同接收者的多個渠道。聯(lián)絡代理商試圖發(fā)送請求。如果接收者已經(jīng)使用相同的技術，則接收者地址是接收者的聯(lián)絡代理商的即時通信地址。在接收者不具有該技術的情況下，請求以含有指令的電子郵件或即時消息的形式發(fā)出，并且將自動為接收者將新的聯(lián)絡代理商實例化 (instantiated)。此處要注意的是，對于要從聯(lián)絡代理商發(fā)送出的信息而言有可能不要求接收者成為任何通信渠道的一部分，但這不是這里描述的情況。Bob的聯(lián)絡代理商接收該請求。該請求由Alice的域所標記，并能夠通過證書權威進行公開地驗證。Bob的個人策略(Policy)被激活并開始處理該請求。在隨后的步驟中，對Bob而言有可能手動處理該請求，或他的個人策略能夠含有將允許該請求的整個處理自動進行的原則。Bob檢查由Alice提出的問題。這時Bob只知道有人請求通信渠道。如果Bob愿意繼續(xù)向前進行，則使用Diffie-Hellman協(xié)議進行密鑰交換且在協(xié)商的持續(xù)期間交換加密密鑰。如果Bob決定他不愿意回答Alice提出的問題，他能夠拒絕該請求，并可選地提供一個理由給Alice。如果Bob決定回答問題，則回答的整個處理僅在Bob的聯(lián)絡代理商處發(fā)生。Bob回答來自Alice的問題，并且他檢查由Alice提議的條款。創(chuàng)建Bob的答案的散列(hash)并使用協(xié)商的密鑰進行加密。Bob現(xiàn)在還決定所提議的條款是否是可接受的且可選地可提議其他條款。散列(和任何所提議的對條款的改變)將發(fā)回Alice。Alice解密散列并將其與在創(chuàng)建請求時預先計算的散列進行比較。如果它們匹配， 則Bob對Alice公開的要求感到滿意。如果它們不匹配則協(xié)商失敗。如果Bob提議了可供選擇的條款，Alice能夠接受它們、拒絕它們和做出可供選擇的提議。如果做出了可供選擇的提議，該提議將被發(fā)回Bob用于進行接受，并且條款協(xié)商繼續(xù)進行直到雙方同意或任何一方終止協(xié)商。如果協(xié)商成功，Alice發(fā)送Krbob給Bob。
Bob接收Krbob，并且他創(chuàng)建他自己的新密鑰對(Ksbob、Kralice)。然后他發(fā)送 Kralice 給 Alice。Alice和Bob現(xiàn)在交換了一起作為雙向安全通信渠道的基礎的兩對密鑰。建立安全通信網(wǎng)絡一旦存在安全通信渠道的網(wǎng)絡，接下來的邏輯步驟是能夠利用這些渠道創(chuàng)建動態(tài)合作網(wǎng)絡。例如，讓我們看一下下面的合作性網(wǎng)絡Angela想與慢性病專家Blanchard醫(yī)生預定一個約會。Angela的保險范圍 (Health Plus)規(guī)定與專家的約會必須通過她的初級護理醫(yī)師(PCP) Jones轉(zhuǎn)診。Angela 的策略也規(guī)定PCP僅能轉(zhuǎn)診到由保險提供方認可的專家。在這個例子中，我們假設所有的各方都建立了聯(lián)絡代理商，且根據(jù)需要通信渠道已成功協(xié)商。在過程開始時以下連接已建立Angela-Jones 醫(yī)生-的病人Angela-Health Plus-的成員Jones醫(yī)生-Health Plus-的網(wǎng)絡的醫(yī)師Blanchard 醫(yī)生-Health Plus—的網(wǎng)絡的專家此處是在該背景下動態(tài)合作協(xié)議是如何展開的(在該情況中，聯(lián)絡代理商是其擁有者的在線化身，在提到個人的大多數(shù)情況中，能夠假設這是聯(lián)絡代理商基于來自擁有者的直接行動或嵌入在聯(lián)絡代理商中的已編輯為腳本的權限來采取行動)1. Angela請求Jones醫(yī)生轉(zhuǎn)診。該過程像發(fā)送由Angela的聯(lián)絡代理商自動路由給Jones醫(yī)生的電子郵件一樣簡單地發(fā)生。由于Angela是病人，存在已有策略，在其中適當?shù)奈恢妹枋隽水斉cJones醫(yī)生通信時Angela能夠做什么。在該例子中，當Angela發(fā)送她的電子郵件時，該消息被自動認證為來自于Angela，而Angela則在適當?shù)牟呗灾斜蛔詣釉?. 一旦消息被Jones醫(yī)生的聯(lián)絡代理商接收到，Angela的通信權力已建立，則消息中的實際請求被處理。在這種情況下，可能的過程或許會涉及Jane，即查看該消息的、 Jones醫(yī)生的助手。Jane已被授權訪問Jones醫(yī)生的聯(lián)絡代理商，且她可訪問Angela的醫(yī)療記錄中的有限的一部分。這允許Jane看到Jones醫(yī)生已經(jīng)做出了關于將Angela轉(zhuǎn)診給專家的記錄。3. Jane現(xiàn)在需要找到一位可與之聯(lián)系的專家并滿足Angela與HealthPlus的策略的條款。這時Jones醫(yī)生從Angela請求獲得權限以訪問她與Health Plus的策略。4. 一旦被授予權限，Jones醫(yī)生與Health Plus聯(lián)系，以便基于Angela的醫(yī)療需要和她的策略請求可與之聯(lián)系的專家的列表。5. Health Plus接收請求并創(chuàng)建可能的專家的列表。在將列表返回Jones醫(yī)生前， Health Plus請求來自每位專家的許可。只有回應為可與之聯(lián)系的專家將被返回給Jones 醫(yī)生。6.通過Jones醫(yī)生的聯(lián)絡代理商，Jane現(xiàn)在有了可與之聯(lián)系的并且愿意見Angela 的專家的列表。在這次交換期間，也可以交換額外的信息，諸如可能的約會次數(shù)。7. Jane現(xiàn)在能夠選擇具體的專家或返回列表給Angela。
8. Angela接受轉(zhuǎn)診并選擇Blanchard醫(yī)生。一條新的通信渠道在Angela和 Blanchard醫(yī)生之間協(xié)商，并將該選擇通知Jones醫(yī)生。9. Angela現(xiàn)在能夠與Blanchard醫(yī)生通信并安排約會。在安排約會的過程中， Angela的醫(yī)療記錄(包括聯(lián)系信息)被自動提供給Blanchard醫(yī)生。10.由于Angela的PCP是Jones醫(yī)生，將協(xié)商一個新的多方策略并且推出該策略， 這樣在Angela看Blanchard醫(yī)生后，Jones醫(yī)生能夠為她提供后續(xù)的治療。該新的策略不是新的通信渠道。恰恰相反，它是連接到多通信渠道的分布式工作流過程，但該策略具有其自己的、擴展其利用的渠道的潛規(guī)則。注意通信渠道是配置和協(xié)商合作協(xié)議的能力基礎。合作協(xié)議是豐富的工作流腳本，其在各方之間協(xié)商并在各參與者的聯(lián)絡代理商的背景中運行。不同于通信渠道，合作協(xié)議確實改變并且隨時間不斷變化。隨著它們服務的目的不斷變化和有可能終止，合作協(xié)議也旨在隨時間不管變化和改變。動態(tài)決定合作協(xié)議通信渠道是用作在一段時間周期內(nèi)的多個合作的管路的安全管道。通信渠道有目的地不可變的，并且它們的屬性不關于渠道的壽命發(fā)生改變。另一方面，在本質(zhì)上，合作性的協(xié)議固有地是動態(tài)的。它們表示目的且必須能夠應對隨時間發(fā)生的變化。例如，Alice具有與Bob之間的、基于職業(yè)關系的通信渠道。該渠道本身僅僅是合作的可能性-它是合作的潛在關系。當Alice想要從Bob請求一報價時，她創(chuàng)建包含請求和所有相關的數(shù)據(jù)的合作協(xié)議。該通信渠道用于交換請求，但報價過程的實現(xiàn)包含在合作協(xié)議中。但在Alice將關于報價的請求發(fā)送給Bob、Charlie和Dave后將發(fā)生什么事？可能結果Dave做出最好的報價，且最初對Bob和Charlie的請求需要結束，它變?yōu)榕cDave的購買訂單。以下是涉及協(xié)議的動態(tài)的不斷變化中的基本步驟1. Alice發(fā)布報價請求(RFQ)給Bob、Charlie和Dave。Alice具有最初的版本， 且所發(fā)布的每個副本具有與最初的協(xié)議周期性通信的能力。2. 30天后，Alice收到了報價且她確定Dave給出了最好的報價。3. Alice現(xiàn)在使用她的RFQ并激活作為協(xié)議的一部分的批準過程，指定Dave為贏家。這觸發(fā)RFQ發(fā)送消息給所有其他的請求。4. Bob和Charlie的RFQ收到消息，因此RFQ終止，且該RFQ上的進一步通信結束 (或可能有可選的生效的反饋過程)。5. Dave的RFQ收到該成功通知并觸發(fā)Dave接受訂單并請求購買訂單。6. 一旦Alice收到來自Dave的接受，將制訂一個含有購買訂單的協(xié)議并發(fā)送到 Dave07. Dave收到購買訂單，檢測條款，在批準該購買訂單生效。最初的RFQ現(xiàn)在關閉， 但其數(shù)據(jù)是購買訂單的組成部分。當然，關于該特定主題的存在許多變化。上述實例僅解釋了相對簡單單邊變化。由于協(xié)議被實現(xiàn)為豐富的工作流，實現(xiàn)涉及多方的復雜規(guī)則是完全有可能的。根據(jù)相關的法律標準描述了前述的發(fā)明，因此本描述是示例性的而不是在本質(zhì)上限定該發(fā)明的。本公開的實施方式的變化和修改對本領域技術人員來說是明顯的，且在本發(fā)明的范圍內(nèi)進行。因此，本發(fā)明提供的合法保護的范圍僅通過研究以下權利要求才能確定。
權利要求
1.一種用于管理數(shù)字式互動的方法，包括接收消息，所述消息包括關于關系的多個被提議的條款，其中所述消息包括發(fā)送方的身份和接收方的身份，其中所述發(fā)送方的身份被隱藏；以及如果所述多個被提議的條款被接受，則打開所述消息并且揭示所述發(fā)送方的身份。
2.根據(jù)權利要求1所述的方法，還包括如果所述多個被提議的條款在所述打開步驟中被接受，則存儲所述多個被提議的條款。
3.根據(jù)權利要求1所述的方法，還包括如果所述接收方拒絕所述多個被提議的條款， 則刪除所述消息。
4.根據(jù)權利要求1所述的方法，其中所述消息包括認證頭，所述方法還包括認證所述認證頭；以及緊接著將所述消息中轉(zhuǎn)給所述接收方。
5.根據(jù)權利要求1所述的方法，其中所述發(fā)送方的身份包括與所述發(fā)送方相關聯(lián)的唯一的標識符。
6.根據(jù)權利要求5所述的方法，其中所述唯一的標識符包括數(shù)字簽名。
7.根據(jù)權利要求1所述的方法，還包括如果所述多個被提議的條款被接受，則允許所述發(fā)送方與所述接收方通信。
8.根據(jù)權利要求1所述的方法，其中通過關系模塊評估所述多個被提議的條款來實現(xiàn)對接受所述多個被提議的條款的決定。
全文摘要
一種用于管理數(shù)字式互動的系統(tǒng)，其包括用于創(chuàng)建身份的身份模塊，其中身份包括與第一方相關聯(lián)的唯一的標識符，用于與第二方的關系的多個被提議的條款；及關系模塊，其與身份模塊通信，用于接收和評估所述多個被提議的條款，包括接受或拒絕所述多個被提議的條款，如果接受，則根據(jù)所述多個被提議的條款允許所述第一方與所述第二方通信。
文檔編號G06Q10/00GK102365648SQ200980139134
公開日2012年2月29日 申請日期2009年8月6日 優(yōu)先權日2008年8月8日
發(fā)明者菲利浦·理查德 申請人:Mica科技公司