JP2012511747A - デジタル相互作用を管理するシステムおよび方法 - Google Patents

Abstract

デジタル相互作用を管理するシステムは、識別を生成する識別モジュールを含み、この識別は、第１のパーティに関連する固有の識別子と、第２のパーティとの関係に対する複数の提案された条件とを含む。システムは、識別モジュールと通信する関係モジュールも含み、この関係モジュールは、複数の提案された条件を受信、評価し、複数の提案された条件を受理、または拒否する。受理した場合には、この複数の提案された条件に従って、第１のパーティは第２のパーティと通信することが許される。

Description

本発明は、一般に社会的（ｓｏｃｉａｌ）相互作用（ｉｎｔｅｒａｃｔｉｏｎ）の支援に関し、より具体的には、人とエンティティとの間の関係構造を提供するシステムに関する。

ダムターミナル（ｄｕｍｂ ｔｅｒｍｉｎａｌｓ）の時代においては、ユーザはそれぞれにログインＩＤとパスワードを得ていた。これを用いてメインフレームに接続し、中央管理された特定の許可へマップされた。これは非常に優れた仕掛けであり、ユーザがある許可を要求すると、その許可が認められ、その結果、メインフレームのあるリソースにアクセスすることが可能であった。これには副作用はほとんど何もなかった。

クライアント／サーバ方式のアーキテクチャが発展するに連れて、同様な概念のログインＩＤとパスワードは継続したが、今では多くのネットワークがあり、それぞれが独自のログインＩＤとパスワードの発行ポリシーを有している。各ユーザは、それでもある種の許可を求めることを要求され、その許可が認められてアクセスを得る。しかし今やこの処理を多数のシステムに対して繰り返さねばならず、それぞれのシステムに特有の許可を覚えておくことを気にしないとしても、それぞれのシステムに対してユーザＩＤとパスワードを覚えておくことは面倒になってきている。

この時点で、さまざまなＩＤ管理（ＩＤＭ）製品が出始めて、ＩＤとパスワードの生成処理を簡易化し、許可の中央管理をより一層進めようとした。このことは全てよいことのように思われ、ＩＤＭの範囲が一企業の中に留まっている限り、望ましくない副作用も僅かであって、ユーザに対して顕著な利点を及ぼした。殆どの会社は、許可の変更および見直しの手段を提供し、その手続きは比較的煩雑ではあるが、会社環境と言う閉じた状況においては十分であった。

インターネットの出現と共に、ユーザの繋がる世界は飛躍的に拡大した。それぞれのユーザは、今では職場の役割として、銀行の顧客として、親として、学生として、等々の多くの識別（ｉｄｅｎｔｉｔｉｅｓ）を持っている。残念ながら、識別子の管理と許可の管理とは同じようには発展してこなかった。ログインＩＤとパスワードの発行手続きは、インターネット（ＡＯＬ、Ｙａｈｏｏ、ＭＳＮなど）上の個人の領域に単純に広まり、識別の概念は一方向処理となった。つまりユーザは、情報を送り、専ら第３機関が定義する識別を得ている。これが、ユーザが本質的にプライバシーに関する権利を放棄し、第３パーティがユーザの個人情報をユーザの承諾なしに意のままに集められるという現状をもたらした。

必要とされるのは、全てのネットワークで繋がれた相互作用に一貫して作用するように、ユーザが自由に権利とプライバシーを取りきめられるようなシステムである。

本発明は、識別の概念を新しいインターネットの世界に合うように具体化するものである。本発明は、個人に属しかつそれぞれの関係に、固有の相互に合意可能な条件の取り決め（ｎｅｇｏｔｉａｔｉｏｎ）を中心に配置した、リソースへのアクセス処理を有する運転席へ、ユーザを座り直させるものである。古い識別子は、関係する両者が一意的に認識し、その上、任意の第３パーティに対して完全に透明な、取り決められた（ｎｅｇｏｔｉａｔｅ）構成となる。そうして、ユーザは、確立した全ての関係の片側に座り、条件を見直すこと（あるいはその条件の下で共有される情報にアクセスし更新すること）は、電子住所録を開くのと同じ程度に簡単となる。

関係ネクサスエージェント（Ｒｅｌａｔｉｏｎｓｈｉｐ Ｎｅｘｕｓ Ａｇｅｎｔ （ＲＮＡ））は、この枠組みを、関係は情報交換のために存在する、という論理的相補段階へ展開する。情報の交換は、固定的な条件の組合せに基づくことは殆どない。それよりもむしろ、情報の交換は、時間と共に発展し、それに伴って条件が変化する。このことは、全ての情報は、複雑な関係との関連で発生している展開中の対話の条件を定義する動的な処理の実に不可分な一部であることを示している。本発明によるＲＮＡアーキテクチャは、これらの複雑な相互作用を、明示的で、管理可能かつ安全なものにする。

管理されるデジタル相互作用の１つの態様が、相互性（ｍｕｔｕａｌｉｔｙ）である。各関係の条件は、相互に合意され、取り決められることが可能である。プライバシーは、これらの条件の一部として含まれる。

管理されるデジタル相互作用の別の態様は、相互結合性（ｉｎｔｅｒｃｏｎｎｅｃｔｅｄｎｅｓｓ）である。これは、両者相互及びグローバルに作用する交流を提供することにより達成される。これは知識を増大させる傾向にある。それは知識が主として、結合されたデータの結果であるからである。

管理されるデジタル相互作用の別の態様は、会話で伝送される情報は関係の条件によって定義されて固定されるが、会話は時間と共に発展することが許される、ということである。

管理されるデジタル相互作用の別の態様は、主体的な許可（ａｕｔｈｏｒｉｚａｔｉｏｎ）である。許可は主体的なイベントであるが、過去において承認されたことの“スナップ写真”として固定されたままである必要はない。相互作用のルールは、時間と共に変わることが許されるし、コンテキストによって変化することが許される。

本発明による結果を実行するために、従うべき３つの基準的な概念がある。第１は、取り決められた安全な通信チャネルが確立されることである。第２は、動的な協調ネットワークが確立されることである。第３は、協調的な合意は動的に決定されることである。

本発明のこれらおよびその他の特徴および利点は、好適な実施形態の詳細な説明により、当業者にはより明確となるであろう。詳細な説明に付随する図面を以下に説明する。

本発明の例示的実施形態によるオントロジーを示すブロック図である。 ユーザに対する例示的関係を示す模式図である。 ２つのエンティティが契約合意に入ることを示す模式図である。 ユーザが病院の患者である場合についての、医療産業への実施形態の適用を示す模式図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。 コンテキストに敏感な関係の例を示す図である。 コンテキストに敏感な関係の例を示す図である。

以下の説明的な実施形態の議論において、“オントロジー（ｏｎｔｏｌｏｇｙ）”という用語は、人と、デジタル相互作用を制御するマシンとの間の関係を述べるのに使われる。

いかなるビジネス取引においても、アプリケーションシステムや情報システムなどのリソースへのアクセスは制御されなければならない。この制御は、識別を含む一連の属性で記述されているサブジェクトが、要求されたリソースへのアクセスが認可されているかどうかを判定した後に、許可を与えることにより実行される。許可はまた、契約合意項目とコンテキスト（例えば、ある種の文書へのアクセスは特定の安全区域に限定される）によって制御される。

企業がそのインフラストラクチャを開放し、ネットワークおよびアプリケーションが展開されて、顧客、パートナおよびサプライヤを含むようになると、基本的なずれが露わになってくる。つまり、パートナおよび他の外部ユーザに属する識別を“信用”または仲介する標準的な方法は今のところないからである。連合した識別のソリューションが出現しつつあるが、組織が、頻繁にやり取りのある多数に亘る小規模パートナに対してネットワークを展開しようとする場合、実装が困難であり、費用がかさむということが明らかになってきている。

問題の中心は、信用の発行である。即ち、組織に全ての考えられる信用関係を前以って確立することを期待するのは、先ず現実的ではない。要求された量の時間の間だけ、適正な量の信用を構築する方法が必要とされる。関係を設定し、そして破棄することはｅメールメッセージを送付するのと同じように簡単であるに違いないが、それでもなお、隙のない安全性と説明責任（ａｃｃｏｕｎｔａｂｉｌｉｔｙ）とを提供することが必要である。

キー管理には、従来の公開キーインフラストラクチャで利用されているのと同じ手法のあるものを利用する（即ち、本発明の実施形態は、実績のある暗号技術を再発明しようとするものではない）。しかし、本発明のオントロジーでのキー管理処理は、全く異なるものである。

キー管理は、暗号化技術の最も難しい部分である。一般に、短期キーと長期キーとの２つのクラスのキーがある。短期間セッションキー（一時的なキーと称されることがある）は、通常、自動的で目につかない形で生成される。これは１メッセージまたは１セッションにだけ使用されて廃棄される。長期間キーは、ユーザによって明示的に生成される。これは、認証（アクセスコントロール、保全性および否認防止を含む）と機密性（暗号化）に利用される。長期間キーはまた、セッションキーの確立および格納データの保護にも利用される。

本発明の実施形態は、必要とする周辺インフラストラクチャが最小の量で、短期キーと長期キーの両方を完全にトランスペアレントに処理するように設計されている。認証と検証は、一般に初期の提供処理の間でのみ必要とされ、従って、トランザクションに介入しなければならない第３パーティの時間が劇的に削減される。

実施形態のあるものは、殆どの提供および許可機能に関して、Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ （ＳＭＴＰ）とＥｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ （ＸＭＰＰ）の単純プロトコル拡張に依存し、参加者のメッセージサーバが、通常、公開キーのインフラストラクチャとの間にスケーラビィリティの問題を起こすほとんどのトランザクションを処理することを可能とする。

本発明の実施形態は、フレキシブルなキー認証フレームワークを提供する。キーを認証するために、第３者パーティを必要としない方式は沢山ある（例えば、参加者が既に確立されている関係の一部である小ビジネスのシナリオなど）。一実施形態において、本発明は公開キーの概念を実効的に除外する。その代わりに、オントロジーが全ての関係に対して独自のキーペアを埋め込む。これは沢山の利点をもたらす。他の誰かの公開キーを取得することは、関係提案のＥメールを送信するのと同じ程度に簡単である。公開キーは、含まれてなくて、関係提案をすることで、この関係に特有の新規の公開キーが自動的に生成される。

本発明の実施形態は、組み込みの機密性（ｂｕｉｌｔ−ｉｎ ｃｏｎｆｉｄｅｎｔｉａｌｙ）と認証を提供する。機密性（即ち、情報を意図されたパーティとの間でしか共有しないこと）に関しては、オントロジーは、意図された受け手にしか読むことのできない暗号材料を埋め込む。この方式は、発展して行く安全要求への対処にも展開可能である。認証（即ち、意図されたパーティとの間で情報を共有すること）に関しては、オントロジーは、帯域外の認証の秘密を活用することが可能であり、Ｅｑｕｉｆａｘなどの識別検証権限を利用することもできる。

本発明の実施形態は、ｅメールアドレスのように管理可能なオントロジーを設計するのに用いてもよい。それは、住所録、アクティブディレクトリ、または他の任意の好適なリポジトリに格納することができる。公開キーがないので、複雑な取り消し機構の必要はない。あるオントロジーは、それを削除し、場合によっては新規のものを発行することにより、取り消すことが可能である。

本発明の実施形態は、妥協した（ｃｏｍｐｒｏｍｉｓｅｄ）情報の効果に対処するように構成されていてもよい。認証に関しては、署名された文書はタイムスタンプがない限り無効とされる。この状況に対処するために、認証が更新されてもよく（その結果新しいオントロジーができる）、文書は相互の合意により再度キー付けされてもよい。機密性に関しては、信用リスクのあるオントロジーで暗号化されたすべてのデータは、信用リスクがある。しかし、効果は、影響を受ける関係のみに厳しく制限される。そうして、影響を受ける材料の再キー付けをかなり単純化する。

オントロジーは、相互に取り決め／管理された明確な合意によって、関係に基づく識別の生成と管理を定義するフレームワークである。識別は、固有の暗号化識別子を含み、提案された条件の要約とデジタル署名とがついた、ＵＲＩまたはｅメールアドレスの形で表現される。この結果をオントロジーと呼ぶ。オントロジーは普通のｅメールアドレスと全く同じように使用することができる。事実、オントロジーに基づく関係を確立することの標準的な意味は、単に、ｅメールを交換することである。しかし、本発明の実施形態は、この交換の方法に限定されるものではない。オントロジーを確立する処理は、好適な移送機構すべてに亘って発生し得る。

オントロジーは、関係を結ぶ最初の合意を確立するためだけに利用される。関係の実際の条件は、ＮｅｔＲＮＡ（Ｎｅｔｗｏｒｋ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｎｅｔｗｏｒｋ Ａｇｅｎｔｓ）と呼ばれる、ワークフローに基づくエージェントを介して取り決められる。ＮｅｔＲＮＡは、条件の実施形態および施行である。識別は、関係とのコンテキストで定義されない限り、実際的な意味を持たない。
実施例

図１は、例示的なオントロジーを示す。ユーザのアリスとボブは、それぞれの会社に関連する識別（ｉｄｅｎｔｉｔｙ）と役割（ｒｏｌｅ）を有する。ユーザ同士はまた、会社の役割に関連にして、相互に取り決められた関係を有する。図２を参照すると、本発明の実施形態は、アリスの雇用主との関係における人事部のマネージャに関してのデジタル相互作用を生成および管理するために利用されてもよい。アリスが、ＡＢＣ社の人事マネージャであるとすると、ＡＢＣ社との関係における彼女の役割は、従業員の採用、福利厚生計画の管理、及び下請け契約者（例えばボブ）の採用などのような他の会社との何らかの合意を結ぶことなどを含んでもよい。本発明の実施形態は、アリスに割り当てられ、受理される識別（例えば、アリスはＡＢＣ社のＨＲマネージャである、というような）を定義するために利用されてもよい。この識別を利用して、次に、アリスの人事マネージャとしての役割における、ＡＢＣ社とアリスの関係条件を管理、実行してもよい。

本発明の実施形態は、個人的かつ個々の関係に固有である、相互に合意可能な取り決めを中心とするリソースに、アリスがアクセスすることを可能とする。古い識別子は、関係する両者が一意的に認識し、その上任意の第３パーティに対して完全に透明な、取り決められた構成となる。アリスは、いまや構築した全ての関係の片側に座り、条件を見直すこと（あるいはその条件の下で共有される情報にアクセスし更新すること）が、電子住所録を開くのと同じ程度に簡単となる。

関係は、情報交換のために存在する。さらに、情報の交換が条件の固定的な組合せに基づくことは稀であり、むしろ、これらの交換は時間と共に進展し、それに従って、条件も変化する。例えば、本を書くという協調作業は、その過程におけるさまざまなポイントにおいて異なる人を巻き込む、多くのフェーズを持っている。このことは、全ての情報は、実際に、複雑な関係のコンテキストで発生している、展開中の対話の条件を定義する動的な処理の不可分な一部であることを示している。本発明のＲｅｌａｔｉｏｎｓｈｉｐ Ｎｅｘｕｓ Ａｇｅｎｔ （ＲＮＡ）のアーキテクチャは、これらの複雑な相互作用を、明示的で、管理可能で、かつ安全なものにする。

オフィス２００７文書用のオープンＸＭＬ仕様、および最近リリースされたウィンドウズ(登録商標)ワークフローファウンデーション（ＷＷＦ）とウィンドウズ(登録商標)コミュニケーションファウンデーション（ＷＣＦ）は、本発明の実施形態のさらなる強化を与える。オープンＸＭＬフォーマットは、部分と関係とからなる文書の内部アーキテクチャを定義する。一実施形態によれば、オントロジーは、関係の条件を表現する。オープンＸＭＬ文書での関係の定義を拡張して、本明細書で記述するオントロジーを含むようにすると、複数の相互に関連した関係を含む複雑なビジネス合意を表現する文書を生成することが可能となる。このようにして生成された文書は、文書のそれぞれの部分へのアクセスを支配する条件を埋め込むことができ、さまざまな部分が非常に具体的なルールと許可を表現することが可能となる。例えば、コンサルタントを抱えておく契約は、プリンタ、共有のリソース、日程表、等へのアクセスを確立する具体的な許可を埋め込むことが可能である。ＷＷＦとＷＣＦとを組合せると、複数の組織に亘って安全に配布することが可能なリッチ形式のワークフローに基づいて、動的な関係を表現する文書を生成することが可能となる。

図３は、一実施形態により、ＡＢＣコーポレーションが、新しいアプリケーションソフトを開発するために、臨時の職位に関してＸＹＺ社と契約合意に至ることを決定したシナリオを示す模式図である。図３において、アリスとボブは、オントロジーにより定義された最初の関係を既に確立しているものとする。取り決めの過程において、取り決め（機密性、監査可能性、等）の要求項目を扱うための新オントロジーが生成され、合意がなされると、最終条件を表すオントロジーが生成される。典型的なシナリオとしては、業務に関する合意が協議され、ＡＢＣ社環境内の新ユーザが提供されて、ＸＹＺ社の契約者がＡＢＣ社内の必要なリソースにアクセスすることが許される。この職位は、新しい識別の生成を必要とする。契約関係にある組織との間の任意の関係が処理から断絶され、もしこれが長期間に亘って、多くのパートナとの間で繰り返されれば、その結果は、今日殆どの組織において一般的に見られる種類の混乱となるであろう。連合された識別の方法で、企業内、及び企業間でのユーザの全ライフサイクルを管理することが必要である。これは、ユーザおよびアカウントの生成、アカウントのリンク、認証、アクセス制御、アカウント終了、等を意味する。識別の連合が考慮されると、連合で何がなされるか、誰が参画するか、どのように管理するか、連合参加者によるどのようなリスクを想定すべきか、等を評価することが必要となる。

本発明の実施形態は、合意形成の自然なビジネス処理を拡張することによりこの問題を解消して、処理を実現するために必要なリソースと許可を割り当て、取り決めの最終生成物に永続的にリンクさせる。事実、契約に関するリソースと許可の全ライフサイクルが契約に固定され、従って、自己記述的でかつ殆ど自己調整的となる。

図４は、実施形態による、ジェーンが病院の患者である医療産業からのシナリオを示す模式図である。複雑な組み合わせの関係とプライバシールールとが含まれている。本発明の実施形態を利用して、必要とされるレベルのプライバシーと機密性を保持したまま、この種のシナリオを、簡単かつ効率的に取り扱うことが可能である。例えば、ジェーンの担当医はジェーンのテスト結果にアクセスすることができるが、病院の会計部門は請求書作成に必要な詳細のみを見ることができるだけで、実際のテスト結果を見ることはできない。実際に、本発明の実施形態によるオントロジーとオープンＸＭＬファイルフォーマットを利用した患者の記録は、強力なセキュリティ策を講じることが可能で、ジェーンの明確な許可を得て初めてある情報にアクセスまたは情報共有をすることが可能となる。自動追跡機能も、きわめて簡単に実装することが可能である。

本発明のある実施形態の目的は、セキュリティを簡単にすることである。セキュリティ、プライバシーやアクセス制御は、ｅメールを送ったり、文書を読むのと同じ程度に簡単かつ自然であるべきである。識別は、それを定義する関係に係わるパーティに内密のものである、という前提から実施形態は始まる。識別の確立は、内密で安全な取り決めの結果である。取り決めができると、取り決め時に合意された期間の間、本発明のオントロジーがＮｅｔＲＮＡへのアクセスを提供することができる。取り消しの仕組みはなく、その関係に係わるパーティのみが、条件を変更し、相互に認証することができる。本発明の実施形態は、その関係に係わるパーティに対する説明責任との調和のとれた、先例のないレベルのプライバシーの機会も提供する。全ての関係のそれぞれが固有のキーを含み、関係同士の間での相互参照は不可能である。オントロジーをオープンＸＭＬ文書に拡大することで、相互に関係する複雑なルールを有し、複数パーティが関与する状況を含む、もっとも複雑な関係を継ぎ目なしに扱うことが可能となる。

図５〜図１１は、様々なコンテキストにおけるオントロジーの取り決めの様々なステップを示す図である。

図１２、図１３は、コンテキストに敏感な関係の例を示す図である。

オントロジーのフレームワークは、集合的な知識の探索及び表現を容易にする。モジュール型のウィジェット（ｗｉｄｇｅｔ）アーキテクチャとセキュアメッセージングとが含まれる。結局、全ての意味のあるデジタル相互作用は、（役割上の）個人と１つまたは複数のエージェントとの間の目的に沿った授受の動作を含んでいる。これらの授受の動作の結果として、知識が生じる。

図１４を参照すると、処理の概念図が示されている。上記で説明したような特定の相互作用の組を促進するための合意の実装は、Ｒｅｌａｔｉｏｎａｌ Ｎｅｘｕｓ Ａｇｅｎｔ （ＲＮＡ）を介して具現化される。

オントロジーのアーキテクチャは、基本的に分散型ネットワークであって、目的先導型追求の相互連結を介して、多機能な集合的グローバルナレッジメッシュを形成するために、Ｒｅｌａｔｉｏｎａｌ Ｎｅｘｕｓ Ａｇｅｎｔｓ （ＲＮＡ）の例示化と管理を促進することを目指している。

結果として得られる集合知識は、オントロジーの形で形式化することが可能である。オントロジーは、エージェントまたは一群のエージェントのために存在し得る概念と関係を形式化することによって、知識を体系化する。

ＲＮＡが取り決められた目的に基づいて相互連結を生成すると、動的メッシュが出現し、そこでは、集合知識が、従来型のデータ抽出ではなく、目的先導型ベクトルの形式で表現される。このことは図１５に示されており、Ｒｅｌａｔｉｏｎａｌ Ｎｅｘｕｓ Ａｇｅｎｔｓ （ＲＮＡ）のメッシュを通る、取り決められた横断路（矢印）が示されている。オントロジーは知識への目的先導型通路であり、そこでは全ての参加者が積極的協調をしている。

実際には、それは、集団的な知識の開発において通信し、安全に参加することが可能な、ソフトウェアエージェントのグローバルなメッシュのネットワークを意味する。それぞれのエージェントは、役割で演じている１つまたは複数の主体によって、合意された目的のためにアクセスされる。

オントロジーＳＤＫは、オントロジーがグローバルＲＮＡメッシュ全体で取り決めおよび管理されるようにするために、Ｒｅｌａｔｉｏｎ Ｎｅｘｕｓ Ａｇｅｎｔｓのメッシュネットワークと必要な安全な通信インフラストラクチャを展開するための基本構造を提供する。

本明細書の残りでは、ここで説明した概念を可能とする、オントロジーＳＤＫ（セキュアデジタルキー）により提供される特定の機能に的を絞って説明する。

オントロジーＳＤＫは、以下の節で説明する、いくつかの技術的特徴を有している。

リレーショナルキー：オントロジーアーキテクチャにおけるセキュリティモデルの基本構成ブロック。基本的に、これは楕円曲線暗号システム（ＥＣＣ）と十分に実績のある非対称暗号技術とを、合意条件下で意図したパーティ（又は複数のパーティ）によってのみ利用可能なキーを配送するための独自の技術との組み合わせで利用することに集中するものである。リレーショナルキーは、処理状態を把握しない検証を提供し、殆どのシナリオに対して、キー拒否の必要も排除する。リレーショナルキーは、またキー管理を促進するためのいくつかの限定された条件を埋め込む。

動的デジタル合意：安全な通信チャネルが確立されると、合意は時間と共に発展するという現実に照らして、何ができるかという疑問が残る。動的デジタル合意とは、電子的な取り決めと施行のフレームワークであって、ユーザおよびシステムが相互に受理できる条件を取り決めて、それを自動的に施行することを可能とする。このフレームワークは、定義できる合意の種類に非常に高次のフレキシビリティを与えるリレーショナルキーを基礎としており、必要があればこの合意は時間と共に発展させることができる。

ユニバーサルロールアーキテクチャ：オントロジーアーキテクチャは、人がさまざまな役割を引き受けるものであるという現実を認識する。このために、アーキテクチャは、基本構造である、役割を中心に構成される。役割は、あるエンティティによって引き受けられ、別のエンティティによって認められた（ある権利と責任とを受理する）合意として定義される。役割を認めるものと担うものとが同一である場合は、役割の特別な場合であって、これをナチュラル識別と称する。通常の役割は、オントロジーとして実装されるが、ナチュラル識別は固有の設計上の特徴を有し、ＭＩＡと称される。この役割のアーキテクチャは、個人（ＭＩＲＡを介して表現される）は、任意の数の組織に亘って複数の役割を担うことができることを意味する。

セキュアメッセージング：基本的なオントロジーアーキテクチャは、輸送レイヤーのセキュリティ機能（例えば、ソースアドレスと宛先アドレスの難読化）を提供しない。第１の焦点は、メッセージ内容の保護に置かれる。オントロジーＳＤＫは、種々のタイプのメッセージングセキュリティに対する広範なサポートを提供する。キーとなるセキュアメッセージング機能としては、リレーションベースの暗号化、埋め込まれた利用制御、権利管理、アクセスロケーション制御、等が含まれる。非常に高いセキュリティが要求される場合、および場合によってはセキュアルーティングのインフラストラクチャの一部としても、オントロジーのセキュアメッセージング機能を展開するためのオプションもあるが、これらの機能はオントロジーＳＤＫには含まれない。

組織にまたがるワークフロー：アプリケーション性能の適用範囲を、ファイアウォールやパートナ組織を越えてシームレスかつ完全なセキュリティを有して拡張する。オントロジーＳＤＫは、ファイア−ウォールおよびネットワークを越えて機能するワークフロー、即ち、意のままに操作できる究極のワークを、生成および管理する機能を提供する。

レコードおよびインスタンスレベルのデータベースセキュリティ：内部ネットワークと外部ネットワークの両方にある、データソース、システムデータ、ユーザデータを、アプリケーションが含むようにすることができる。アプリケーション中の属性およびオブジェクトレベルに至るまでの高度なセキュリティと暗号化を提供し、これらの許可をネットワークを越えて施行する。

ステートレス（処理状態を把握しない）ライセンシング：高度なユーザライセンシング機能であって、複雑で高価なサーバのインフラストラクチャを必要としないで、任意のビジネス展開シナリオに好適なライセンシング条件を定義する、ほぼ無限の能力が可能である。

この基本コンセプトは、広範なアプリケーションを有し、それは、人対人の安全な通信から、ファイアウォールを超えたビジネス対ビジネスの処理、等に及ぶ。本明細書の次の数節は、いくつかの一般的な統合シナリオについて検討する。

本発明による結果を実行するために、従うべき３つの基準的な概念がある。第１は、取り決めされた安全な通信チャネルが確立されることである。第２は、動的な協調ネットワークが確立されることである。第３は、協調合意は動的に決定されることである。
安全な通信チャネルの確立

安全な通信チャネルの確立処理は、相互の取り決め処理を中心に展開する。典型的な例では、アリスがボブとの間に安全な通信チャネルの確立を希望する。

アリスは、ネクサスエージェントに接続する。これはワークフローのエージェントであり、ローカル装置上にあってもよいし、リモートアクセスしてもよい。ネクサスエージェントとの通信は、常に暗号化され、アリスのみが自分のネクサスエージェントを利用して新しい接続を生成することができる。ネクサスエージェントは、通信チャネル、ポリシー、及びアリスの好みの変化の管理を取り扱う。ネクサスエージェントへのユーザインタフェースは、ウェブページであってよい。ただし、ｅメールのような通常の生産性アプリケーションにシームレスに統合することも可能である。

アリスは、どの認証情報をボブに開示するかを決定する。提供される認証情報には、第３者機関がその有効性を証明するための安全トークンが含まれてもよい。典型的な認証情報は、Ｅメールアドレス、専門会員証や、ボブが検証可能であり、アリスが開示を望む他の任意のエビデンスであってよい。この認証情報のパッケージは、ボブの識別を検証するために、次のステップでアリスが確立しようとする要求をボブが満たして初めて、ボブへのアクセスが可能となる。

次にアリスは、どの認証情報をボブに要求するかを決定する。アリスは使用しようとする、彼女自身の認証情報データを提供する。これはＱ＆Ａのセットとなっており、ボブが正しく回答できないと、アリスから提供された認証情報にアクセスできない。アリスは、最低限、受信者アドレスを提供しなければならない。これは要求を送信するのに使われるアドレスである。

アリスは、通信チャネル用の属性を提案する。基本的な属性は、有効期限、暗号化要求、チャネルの更新が可能かどうか、等を含む。属性は拡張可能であるが、通信チャネルにおいては、絶対値として表現できることが必要であり、チャネルが相互で合意されたら、取り消し不能、変更不能である。

ネクサスエージェントは次に、新規のランダムなキーのペア（ＫｓａｌｉｃｅとＫｒｂｏｂ）を生成し、チャネル要求パッケージに備える。

この処理は、アリスが通信しようとする全てのパーティに対して繰り返される。アリスは、異なる認証情報を用いて、同一の受信者に対して複数のチャネルを持つことが可能である。それは、用いられる認証情報は、各チャネルの識別の不可分の一部であるからである。

ネクサスエージェントは要求を送信しようとする。受信者が既に同じ技術を利用していれば、受信者のアドレスは受信者のネクサスエージェントに対してインスタントメッセンジャのアドレスとなる。受信者がその技術を持っていない場合には、要求は指示を含んだｅメールまたはインスタントメッセージの形で送信され、新規のネクサスエージェントが受信者用に自動的に作成される。受信者が任意の通信チャネルの一部であることを必要とせずに、ネクサスエージェントからメッセージを送信することは可能であるが、ここでは説明するシナリオには含まないことを理解されたい。

ボブのネクサスエージェントが要求を受信する。要求は、アリスのドメインによって署名され、認証機関によって公に検証することができる。

ボブの個人ポリシーが起動され、要求の処理が始まる。以下のステップでは、ボブが要求を手動で処理することが可能であり、または、彼の個人ポリシーが要求の全処理を自動的に行わせるルールを含むことも可能である。

ボブは、アリスからの質問を検討する。この時点で、ボブは、誰かが通信チャネルを要求しているということを知っているだけである。ボブが先に進もうとすると、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎプロトコルを用いてキー交換が行われ、取り決めの間、暗号化キーが交換される。

ボブがアリスからの質問に答えないと決定した場合は、要求を拒否し、任意選択でその理由をアリスに返すことができる。ボブが質問に答えることにすると、回答の全処理がボブのネクサスエージェントでのみ始まる。

ボブはアリスからの質問に答え、アリスから提案された条件を検討する。

ボブの回答のハッシュが生成され、取り決めキーを用いて暗号化される。次にボブは、提案された条件が受理できるかどうかを判定し、任意選択で、違う条件を提案してもよい。ハッシュ（および、もしあれば、条件に対する変更提案も）がアリスに返信される。

アリスは、ハッシュを解読し、要求を生成した時に前以って計算されたハッシュと比較する。それらが一致する場合には、ボブはアリスの開示要求に満足している。一致しない場合は、取り決めは失敗である。

ボブが代替条件を提案した場合には、アリスは、それを受理、拒否、または代案提案をすることができる。代替提案が作成された場合には、ボブに送信されて受理を求められる。そして、条件の取り決めは、両者が合意するか、どちらかのパーティが取り決めを終了するまで続けられる。

取り決めが成功すると、アリスはＫｒｂｏｂをボブへ送信する。

ボブは、Ｋｒｂｏｂを受信し、彼自身の新しいキーのペア（ＫｓｂｏｂとＫｒａｌｉｃｅ）を生成する。そして、Ｋｒａｌｉｃｅをアリスに送信する。

これでアリスとボブは、２対のキーを交換した。この両方が、双方向の安全通信チャネルの基礎として作用する。
安全通信ネットワークの確立

安全通信チャネルのネットワークが一旦できると、次の論理ステップは、これらのチャネルを活用して、動的協調ネットワークを生成することができる。例として以下の協調ネットワークを考察してみよう。

アンジェラは、慢性疾患の専門家である、ブランチャード医師の予約を取りたいと思っている。アンジェラの保険（ヘルスプラス）の規約では、専門医への予約は、かかりつけの医師（ＰＣＰ）であるドクタージョーンズからの紹介で行われなければならない。アンジェラのポリシーはまた、ＰＣＰは保険会社によって承認された専門医へしか紹介できないことが規定されている。

この実施例において、全てのパーティは確立されたネクサスエージェントを有し、通信チャネルは必要に応じて取り決めに成功するものと仮定する。

処理の開始時に以下の接続がなされる。

・アンジェラ−患者−ドクタージョーンズ

・アンジェラ−会員−ヘルスプラス

・ドクタージョーンズ−ネットワークの医師−ヘルスプラス

・ドクターブランチャード−ネットワークの専門医−ヘルスプラス

次に、この動的協調合意がどのようにこの前後関係において展開されるかを示す。（このシナリオにおいては、ネクサスエージェントは、オーナのオンライン上のアバターであり、殆どの場合、人を指す場合には、オーナからの直接動作、あるいはネクサスエージェント中に埋め込まれたスクリプトによる許可に基づいて、アクションをするネクサスエージェントを想定することができる。）

１．アンジェラが、ドクタージョーンズに紹介を依頼する。この処理はＥメールを送信するのと同じ程度に簡単に行われ、アンジェラのネクサスエージェントによって、ドクタージョーンズに自動的に送られる。アンジェラは患者であるので、ドクタージョーンズと通信する際にアンジェラができることを記述した既存のポリシーがきちんとある。この実施例においては、アンジェラがｅメールを送信すると、自動的に発動される適切なポリシーによって、メッセージがアンジェラからのものであることが自動的に認証される。

２．メッセージがドクタージョーンズのネクサスエージェントで受信され、アンジェラの通信する権利が確立されると、メッセージ中の実際の要求が処理される。ここの場合、可能性のある処理としては、ドクタージョーンズのアシスタントであるジェーンがメッセージを閲覧することが含まれるかもしれない。ジェーンは、ドクタージョーンズのネクサスエージェントにアクセスすることが認められており、アンジェラのカルテの限られた部分にもアクセスすることができる。このことによって、ジェーンは、ドクタージョーンズが既にアンジェラを専門医へ紹介することに関するメモを作成していることがわかる。

３．次にジェーンは、ヘルスプラスに関するアンジェラのポリシー条件を満たす、対応可能な専門医を見つける必要がある。この時点で、ドクタージョーンズは、アンジェラのヘルスプラスに関するポリシーにアクセスする許可をアンジェラに要求する。

４．許可が認められると、ドクタージョーンズはヘルスプラスと通信し、アンジェラの医学的必要性とポリシーとに基づいて対応可能な専門医のリストを要求する。

５．ヘルスプラスは要求を受信し、可能性のある専門医のリストを作成する。ドクタージョーンズにリストを返信する前に、ヘルスプラスはそれぞれの専門医に許可を要求する。対応可能であると応答した専門医についてのみ、ドクタージョーンズに返信される。

６．ドクタージョーンズのネクサスエージェントを介して、対応可能でアンジェラを診るつもりのある専門医のリストをジェーンは手に入れる。このやり取りにおいて、可能な予約時間等の追加情報も交換されてもよい。

７．次にジェーンは、特定の専門医を選択するか、またはリストをアンジェラに返信する。

８．アンジェラは紹介状を受信し、ドクターブランチャードを選択する。アンジェラとドクターブランチャードとの間に新しい通信チャネルが取り決めされ、ドクタージョーンズは選択結果を通知される。

９．こうしてアンジェラはドクターブランチャードと通信できるようになり、予約を取る。予約を取る処理において、アンジェラのカルテ（連絡先を含む）がドクターブランチャードに自動的に提供される。

１０．アンジェラのかかりつけの医師はドクタージョーンズであるので、新規の複数パーティ間のポリシーが取り決めされて導入され、アンジェラがドクターブランチャードに診てもらった後にドクタージョーンズが継続診療を行えるようにする。この新規のポリシーは、新規の通信チャネルではない。それはむしろ分散されたワークフロー処理であって、複数の通信チャネルにリンクされているが、それ自身の通底するルールを持っていて、それが利用するチャネルに拡大適用される。

通信チャネルは、協調合意を展開し取り決めすることができるための基本であることに留意されたい。協調合意は、リッチワークフロースクリプトであり、複数のパーティ間で取り決めされ、各参加者のネクサスエージェントのコンテキスト上で動作する。

通信チャネルとは違って、協調合意は時間と共に変化し、発展する。協調合意の目的が発展し、あるいは終了すると、協調合意は時間と共に発展および変化するようになっている。
協調合意の動的解法

通信チャネルは、ある期間に亘り、沢山のコラボレーションの導管として作用する安全なパイプである。通信チャネルは意図して不変となっており、その属性は、チャネルのある限り不変である。

その一方で、協調合意は本質的に動的な性質である。それは目的を表し、時間による変化を扱うことができる。

例えば、アリスは、ボブとの間に職業関係に基づく通信チャネルを有している。チャネルそのものは単にコラボレーションの可能性であり、コラボレーションの潜在ベクトルである。アリスがボブから見積りを取ろうとする場合、要求と全ての関連するデータを含む協調合意をアリスは作成する。通信チャネルを用いて要求が交換されるが、見積り処理の実装は、協調合意の中に含まれる。

しかし、アリスが、ボブとチャーリーとデーブに見積り要求を送信したらどうなるだろうか？多分デーブが最もよい提示をしたことになって、元の要求が、デーブに対する注文書になる間に、ボブとチャーリーへの要求は終了する必要がある。ここに、合意の動的発展の中の基本ステップが含まれる。

１．アリスが見積依頼（ＲＦＱ）をボブとチャーリーとデーブに出す。アリスが原版を持っていて、送付された各コピーは元の合意と定期的に通信することが可能である。

２．３０日後にアリスは、見積りを受信し、アリスは、デーブが最もよい見積りをしたと判断する。

３．アリスは、次に、ＲＦＱを使って合意の一部分である承認処理を動作させ、デーブが落札したことを明記する。これがＲＦＱを始動させて、他のすべてのインスタンスにメッセージを送信する。

４．ボブとチャーリーに対するＲＦＱはメッセージを受信し、その結果ＲＦＱが終了し、このＲＦＱに関するそれ以上の通信は終わる（あるいは、それに代わるフィードバック処理が実行されるかもしれない）。

５．デーブへのＲＦＱは成功通知を受理し、デーブに注文を受けて、注文書を要求するように促す。

６．デーブからの受理通知をアリスが受信すると、注文書を含む新規の合議が準備されデーブへ送信される。

７．デーブは注文書を受信し、条件を検閲し、承認することにより注文書が発効する。元のＲＦＱはこれで閉じられるが、そのデータは、注文書の統合された一部である。

この特定の主題にはもちろん多くの変形がある。上記の実施例は、単純な、相対的に一方向からの発展だけを説明したものである。合意はリッチワークフローとして実装されるので、複数のパーティを含む複雑なルールを実装することも完全に可能である。

前述の発明を関連する法的基準に則して説明した。従って、説明は、本質的に制限的であるというよりも例示的である。開示した実施形態に対する変形や変更は、当業者には明らかとなるであろうし、それらは本発明の範囲内にある。従って、本発明に与えられる法的保護範囲は、以下の特許請求の範囲を検討することによってのみ判定できる。

Claims (8)

1. デジタル相互作用を管理する方法であって、
   関係に関する複数の提案された条件を含むメッセージを受信することであって、前記メッセージは、送信側パーティの識別と受信側パーティの識別とを含み、前記送信側パーティの識別は、秘匿されており、
   前記メッセージを開き、前記複数の提案された条件が受理される場合、前記送信側パーティの識別を明らかにする、
   ことを含む、方法。
2. 前記開くステップにおいて受理された場合、前記複数の提案された条件を格納する、ことを更に含む、請求項１に記載の方法。
3. 前記受信側パーティが前記複数の提案された条件を拒否した場合、前記メッセージを削除する、ことを更に含む、請求項１に記載の方法。
4. 前記メッセージは、認証ヘッダを含み、
   前記方法は、
   前記認証ヘッダを認証し、
   前記メッセージを前記受信側パーティに中継する、
   ことを更に含む、請求項１に記載の方法。
5. 前記送信側パーティの識別は、前記送信側パーティに関係する固有の識別子を含む、請求項１に記載の方法。
6. 前記固有の識別子は、電子署名を含む、請求項５に記載の方法。
7. 前記複数の提案された条件が受理された場合、前記送信側パーティが前記受信側パーティと通信することを可能とする、ことを更に含む、請求項１に記載の方法。
8. 前記複数の提案された条件を受理する判定は、前記複数の提案された条件を関係モジュールによって評価することにより達成される、請求項１に記載の方法。

Images