JP2005327234A - ピアツーピアコラボレーションシステムにおいて連絡先認証を管理、表示するための方法及び装置 - Google Patents

ピアツーピアコラボレーションシステムにおいて連絡先認証を管理、表示するための方法及び装置 Download PDF

Info

Publication number
JP2005327234A
JP2005327234A JP2004221235A JP2004221235A JP2005327234A JP 2005327234 A JP2005327234 A JP 2005327234A JP 2004221235 A JP2004221235 A JP 2004221235A JP 2004221235 A JP2004221235 A JP 2004221235A JP 2005327234 A JP2005327234 A JP 2005327234A
Authority
JP
Japan
Prior art keywords
user
contact
name
authentication
display
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2004221235A
Other languages
English (en)
Other versions
JP2005327234A5 (ja
JP4976646B2 (ja
Inventor
Raymond E Ozzie
レイモンド・イー・オジー
George P Moromisato
ジョージ・ピー・モロミサト
Nimisha Asthagiri
ニミシャ・アスタギリ
Wei Dai
ウェイ・ダイ
Alexei Evdokimov
アレクセイ・エヴドキモフ
Mark Cote
マーク・コート
Adam Weiss
アダム・ワイス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Groove Networks Inc
Original Assignee
Groove Networks Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Groove Networks Inc filed Critical Groove Networks Inc
Publication of JP2005327234A publication Critical patent/JP2005327234A/ja
Publication of JP2005327234A5 publication Critical patent/JP2005327234A5/ja
Application granted granted Critical
Publication of JP4976646B2 publication Critical patent/JP4976646B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks

Abstract

【課題】
ピアツーピアコラボレーションシステムにおいて、認証関係を管理し、これらの関係を協働者に自動的に表示するための方法及び装置を提供する。
【解決手段】
適切なユーザ対データ関連付けは、ユーザが共用された空間の他のメンバーを容易に認証できるようにする簡略化された最小のユーザインタフェースによってピアツーピアコラボレーティブシステムで作成される共用空間で維持される。特に、ユーザが他のユーザを認証するのに時間をかけない場合にも認証された関係を自動的に構築するためにサポートが提供される。ユーザが共用空間に入りその空間で連絡すると、その連絡先のその認証ステータスを識別する独特のアイコンが各連絡先の表示名に付随する。混乱及び連絡先「スプーフィング」を予防するために同じ表示名の連絡先間の一致を解決するための機構が提供される。認証に対する一貫した手法を実現するためにセキュリティ方針を確立することができる。これらの方針は、ユーザによって設定できる、あるいは代わりに方針は管理者によって設定できる。
【選択図】図１

Description

本発明は、ピアツーピアコラボレーションシステムに関し、認証関係を管理し、これらの関係を協働者に自動的に表示するための方法及び装置に関する。
政府及び他の機関は、ネットワーク化されたコンピューティングシステムのユーザとして、許可されていない開示からデータを保護する上でのセキュリティの価値を理解している。特に政府機関は、データ交換の参加者が自分の通信の相手のアイデンティティについて保証されるように、プライバシーのためにデータを暗号化し、ユーザを強力に認証するために大変な苦労を重ねてきた。更に多くの組織は、ファイアウォールの内側にあるデータに外部ユーザがアクセスするのを妨げるハードウェア障壁またはソフトウェア障壁のどちらかであるファイアウォール付きのきわめて細分化されたプライベートネットワークを実施してきた。
この「アイランド」ネットワークセキュリティ手法の欠点は、それにより他の組織の正規のユーザとのデータの共用が複雑化するという点である。現在の組織モデル及びビジネスモデルは、ファイアウォールを越えた対話機能及びコンサルタント、作業者、及び他の提携組織の人に対する相互依存性を要求する。これらの人のすべては出現する機会及び脅威に迅速に対応するために毎日の業務の中で協調し、協働もしなければならない。今日組織の境界を越えるニーズは従来にも増して大きい。一方では強力なデータ保護と他方ではデータを共用（ｓｈａｒｅ）するニーズの間の――この緊張の結果が協働に対する障害を生じさせる場合がある。多くの組織は、例えば多くの場合安全ではないｅメールとしてデータを送信するなど、まったくセキュリティ対策を回避している。他は単に処置を講じていない場合がある。
多くの組織は、データアクセス許容度の問題を解決するための、誠実ではあるが場当たり的な手法を講じている。選択されたプロトコルを使用する外部者によるアクセスを可能にするために、ファイアウォール内にポートを開くネットワーク管理者もいる。遠隔地に居る既知の作業者がファイアウォールの内側の特定のシステムに入る（ｔｕｎｎｅｌ ｉｎｔｏ）ことができるようにする仮想プライベートネットワーク（ＶＰＮ）を設ける他の管理者もいる。
なお、他の組織はＤＭＺ（「非武装地帯」）として知られるネットワーク領域内に1つまたは複数のシステムを確立する。ＤＭＺは組織のメインファイアウォールの外側にあり、組織の内部及び外部の人々がアクセスできる。例えば、ウェブサーバは多くの場合ＤＭＺ内にある。
これらの解決策の1つの問題は、それらがネットワーク管理者による顕著な関与を必要とするという点である。更にいったんこれらのシステムが実現されると、管理者にはそれらを維持するという重荷が残される。これらのような解決策は管理要員に高度の責任及び信任も負わせる。このような解決策は管理上の妥協の可能性を無視し、多くの場合きわめてカスタマイズされ、十分に解説されていない。いくつかのカスタマイズされた解決策を確立する人物が組織を離れてしまうと、他の人がシステムがどのように構成されているのか分からない可能性がある。これは、さもなければ安全なネットワークのセキュリティホールにつながる可能性がある。
これらの解決策の別の一式の問題が故障及び集中攻撃に対するそれらの脆弱性である。データのロバスト性、データ可用性、及び仲間の協働者を安全に認証する方法は安全なシステムの前提条件である。暗号保護の強度に関わりなく、情報はオンデマンドで入手可能でなければならない。
優れたセキュリティを維持しつつもＩＴ管理者に大きく依存することを回避するために、安全なピアツーピアコラボレーションシステムが開発されている。これらの１つが、ｈｔｔｐ：／／ｗｗｗ．ｇｒｏｏｖｅ．ｎｅｔに詳しく説明されている、マサチューセッツ州０１９０１５、ビバリー、カミングスセンター スィート５３５Ｑ、１００（１００ Ｃｕｍｍｉｎｇｓ Ｃｅｎｔｅｒ Ｓｕｉｔｅ ５３５Ｑ，Ｂｅｖｅｒｌｙ，ＭＡ０１９０１５）のグルーブネットワークス社（Ｇｒｏｏｖｅ Ｎｅｔｗｏｒｋｓ，Ｉｎｃ．）により開発、販売されているグルーブ（Ｇｒｏｏｖｅ）コラボレーションシステムである。特許文献１も参照すること。このシステムでは、協働者は「アイデンティティ」を含むアカウントを作成できる。アイデンティティはそれぞれに秘密鍵と公開鍵が付いた２つの暗号「鍵の組」である「暗号ペルソナ（ｃｒｙｐｔｏｇｒａｐｈｉｃ ｐｅｒｓｏｎａ）」から構成されている。これらの鍵は他のアイデンティティとの安全な通信を実現するために使用される。協働者は、アイデンティティを使用すると、「共用空間（ｓｈａｒｅｄ ｓｐａｃｅ）」と呼ばれる臨時の協働場所を作成できる。共用空間は実質的には、共用される領域、つまり他の協働者がアクセスできるユーザのコンピュータメモリ内の安全なパーティションである。このような共用空間は、グルーブコラボレーションシステムの一部であるユーザインタフェースを使用して作成できる。共用空間は、ファイルフォルダ、または別の種類のファイル共用仕組みを作成することによってなど他の方法でも作成できるであろう。本明細書で使用される「共用空間」は、それがどのように作成されるのかには関係なくこのような共用される領域を意味する。共用空間を作成する協働者は、次に、他のメンバーに該共用空間に加わり、データ及びツールを該空間へ導入するように招待することができる。グルーブコラボレーションシステム（以下、グルーブシステム）は、それがネットワーク管理者にファイアウォール内に特別なポートを開くように要求しなくてもファイアウォールを通して通信できるように標準的なウェブ・プロトコルを使用する。更に、組織は集中管理、中継機能、統合、及びグルーブシステムの使用に対する制御のためにグルーブシステム用サーバを配備することができる。
セキュリティを提供するために、グルーブシステムは１９２ビットの暗号を端末で使用してすべてのユーザアカウント、共用空間及びそのコンテンツを自動的に暗号化する。更に、ネットワークを介して送信される共用空間内のすべてのコンテンツと活動も暗号化され、共用空間の他のメンバーによってのみ解読できる。しかしながら、たとえすべての通信が暗号化され、完全性が保護されていても、ユーザが、彼らが通信している現実世界の人が、ユーザが自分が通信していると考えている実際の人である、及び人のままであることを容易に検証できる場合にだけ、データの起源の完全性は保証できる。
これを行うために、グルーブシステムは認証と呼ばれるプロセスを使用する。このプロセスは、連絡先の「デジタル指紋」を比較することを含む。特に、グルーブシステムは各アイデンティティに関連付けられた一意の明白なデジタル指紋を自動的に生成する。デジタル指紋は連絡先の公開鍵から導き出され、（読みやすさのために句読点と共に）文字と数の長いランダムに見える列としてユーザに提示される。二人の人は、自分達が互いに報告している指紋に対して、彼らが互いについて見ている指紋を比較することによって互いのアイデンティティを手動で認証できる。
例えば、第１のユーザが第２のユーザに共用空間に加わるように誘うと仮定する。該第１のユーザは自分の指紋を該第２のユーザに報告し、第２のユーザは、第２のユーザがメンバーパネルの第１のユーザの連絡先情報を開く時に表示される指紋に照らして報告された指紋をチェックする。それから、第１のユーザと第２のユーザはこの動作を繰り返し、今回は第１のユーザが第２のユーザの指紋を手動で認証する。後述されるように管理されたドメインの中で管理者により「証明」を実行することも可能である。
米国特許第６，４４６，１１３号明細書 Ｗｉｌｌｉａｍ Ｄ．Ｔｉｅｒｎｅｙ及びＫｅｎｎｅｔｈ Ｇ．Ｍｏｏｒｅによって２００１年１０月２４日に提出され、「ピアツーピアコラボレーションシステムを管理するための方法及び装置（ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＭＡＮＡＧＩＮＧ Ａ ＰＥＥＲ−ＴＯ−ＰＥＥＲ ＣＯＬＬＡＢＯＲＡＴＩＯＮ ＳＹＳＴＥＭ）」と題される同時係属中の米国特許出願第１０／０３６，２７５号明細書 ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ／ｅｎｃｒｙｐｔｉｏｎ／ａｅｓ／ ＦＩＰＳ １４０−２ １９８５年のコンピュータサイエンス（Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ １９６）、１０−１８ページのＴ．ＥｌＧａｍａｌ、暗号作成術の進歩―ＣＲＹＰＴＯ’８４の会報、スプリンガーベルラグレクチャーノート（Ｓｐｒｉｎｇｅｒ Ｖｅｒｌａｇ ＬｅｃｔｕｒｅＮｏｔｅｓ）の「公開鍵暗号システム及び離散値対数に基づいたシグナチャ方式（Ａ ｐｕｂｌｉｃ ｋｅｙ ｃｒｙｐｔｏｓｙｓｔｅｍ ａｎｄ ａ ｓｉｇｎａｔｕｒｅ ｓｃｈｅｍｅ ｂａｓｅｄ ｏｎ ｄｉｓｃｒｅｔｅ ｌｏｇａｒｉｔｈｍｓ）」と題される記事
しかしながら、認証手順を用いたとしても、依然として認証されていない通信が発生することはありうる。この信頼性の欠如は、ユーザが認証プロセスを実行する時間をかけず、それによりシステムをなりすまし（ｓｐｏｏｆｉｎｇ）及び他の攻撃に開けてしまうために発生する。
本発明の原理に従って、適切なユーザ対データの関連付けが、ユーザが共用空間の他のメンバーを容易に認証し、情報を暗号化することができるようにする簡略化された最小のユーザインタフェースによって（コンピュータ、ＰＤＡ、ゲームコンソール、セットトップボックス、または他の電子装置などの）複数のデバイスにおいて維持される。特に、ユーザが他のユーザを認証するために時間をかけない場合にも認証された関係を自動的に構築するためのサポートが提供される。いったんこれらの関係が確立されると、それらは共用空間と関連付けられたデータに記憶される。ユーザがその共用空間に入り、その空間内の連絡先を見ると、それぞれの連絡先に独特なアイコンが付随している。これらのアイコンは瞬時にその連絡先のその認証ステータスを識別する。
ある実施態様では、ユーザは「暗示的に」認証されてよい。例えば、第１のユーザが初めて第２のユーザと通信する時、第１のユーザが第２のユーザを手動で認証しなくても、セキュリティシステムは依然として第１のユーザのアカウントの中の第２のユーザの連絡先情報を覚えている。その連絡先が第１のユーザのアカウントに残る限り、第１のユーザは、第２のユーザとのすべての将来の通信が同じ第２のユーザと実施されることを保証される。この暗黙の認証をサポートするためにセキュリティシステムは「名前一致解決」と呼ばれる技法を使用する。ユーザインタフェースは、類似した名称の連絡先が提示されたときにユーザに警告する機能を含んでいる。したがって、第１のユーザは、もし別のユーザが第２のユーザと同じ名前を使用することにより第２のユーザを装っているときには十分に警告される。
別の実施態様では、名前の一致（ｃｏｎｆｌｉｃｔ）は「エイリアシング（ａｌｉａｓｉｎｇ）」と呼ばれる技法で解決される。
更に別の実施態様では、認証に対する一貫した手法を提供するためにセキュリティ方針を確立できる。これらの方針はユーザによって設定できる、あるいは代わりに方針は管理者によって設定できる。方針は、好ましい認証方法、あるいは必要とされる認証方法に対処する。選択された方針に基づき、コラボレーティブシステムは、ユーザが、管理者によって証明されていない人、あるいは手動で認証されていない人と通信しそうになるとユーザに警告することができる。
更に別の実施態様では、選択された方針に基づき、コラボレーティブシステムは、連絡先のアイデンティティが管理者によって証明されていないか、あるいは手動で認証されていない限り、個人との通信を禁止できる。
図１Ａは、前述したグルーブコラボレーションシステムなどのコラボレーティブシステム１００のブロック略図である。図１Ａはコンピュータ、ＰＤＡ、ラップトップコンピュータ、セットトップボックス、ウェブ・イネーブル携帯電話、または他の通信装置である場合がある２台の協働するデバイス１０２と１０４を示している。２台の協働装置だけが図示されているが、追加のデバイスも存在してよい。グルーブソフトウェアがこのようなデバイスにロードされると、それはそれぞれデバイス１０２と１０４内にデータベース１１２と１１６を作成する。これらのデータベースはそれぞれ協働者によって処理されているデータのローカルコピーを保持する。後述されるように、データベース１１２と１１６も協働するデバイス１０２と１０４のそれぞれの動作に関する情報を保持する。
コラボレーティブソフトウェアは、それぞれデバイス１０２と１０４の中にトランシーバ１１０と１１４などのトランシーバも作成する。各トランシーバは、矢印１０６によって概略的に示されるように協働者間の「デルタ」と呼ばれるデータ変更要求の作成及び送信を担当する。通常、これらのデータ変更要求は図１Ａに図示されるようにインターネット１０８上で送信されるが、それらはＬＡＮネットワークなどの別のネットワーク上で送信することもできるであろう。データ変更要求はシステムに協働者を追加する、及びシステムから協働者を削除する、ならびにデータコピーを同期させておくためにそれぞれの協働するデバイス内でローカルデータコピーを更新するなどの多くの目的のために使用される。
図１Ａは、管理ドメイン及び管理されるアイデンティティを確立するために管理要員が使用できる管理サーバ１１８も示している。また、通常、管理サーバ１１８は、矢印１２０と１２２により概略的に示されるように、インターネット１０８などのネットワークを介して協働するデバイスと通信する。管理サーバの動作及びドメインを作成し、管理する上でのその使用は、参照により出願が全体として本明細書に取り込まれている特許文献２に更に詳細に説明されている。
前述したコラボレーティブソフトウェアを使用するために、ユーザはアカウントを確立する。このようなアカウントは、ログイン名とパスワードなどのユーザについての情報を含み、ｅ−メールアドレス及びユーザに連絡する他の方法などの追加の情報を含む場合がある。一般的には、アカウントは、アイデンティティファイル等の他のシステムに共通して見られるユーザ情報ファイルに対応する。アカウントは、コラボレーティブシステムによって維持されるデータベース１１２または１１６などのデータベースに記憶される情報を含む。このようなデータベース１２４は図１Ｂに更に詳細に図解されている。該システムデータベース１２４は、同様にアカウントについての特定のユーザプライベートメタデータを記憶するアカウントデータベース１２６を含む。ユーザが、オフィスで使用するための職業上のアイデンティティと写真や休暇の計画を共用するような目的のために家族と友人と使用するための個人用アイデンティティなどの複数のアイデンティティを持つ可能性がある。メタデータは、アカウントによって保持される１つまたは複数のアイデンティティ１３０及び該アイデンティティと関連付けられる秘密鍵１３２を含む。各アイデンティティは「アイデンティティ鍵組」と呼ばれる２つの鍵の組に関連付けられる。メタデータは更にアカウントに関連付けられた共用空間ごとに識別子１３４を含む。
アカウントデータベース１２６は、アイデンティティごとの連絡先情報を記憶する連絡先記憶部１３６も含む。連絡先ごとの情報は個人のアイデンティティ表示名、電話番号、ｅメールアドレスと、職業上のアイデンティティ表示名、電話番号、ｅメールアドレス等を含む。連絡先情報はコラボレーティブシステムの外部のアイデンティティ間のメッセージを検証し、暗号化するために使用される公開／秘密鍵の組１４０の公開鍵などの何らかの公開情報も含む。連絡先情報は、連絡先の認証ステータスを示すステータスフラグを備えるメタデータ１４２も含む。このメタデータは連絡先の「証明書チェーン」の中の全証明書の最低有効期限も含む（連絡先は更に別の連絡先等により同様に証明される別の連絡先によって証明されてよい）。性能の理由から、コラボレーティブシステムは、一度証明書を確証してから、最低有効期限を記憶するだけである。後に、連絡先がユーザインタフェースに表示される前に、最低有効期限が確認されるが、証明書チェーンは確証し直される必要はない。この手順によりコラボレーティブシステムは証明書の満了という点で最新となることができる。
ステータスフラグは、連絡先が未認証であるかどうか、手動で承認されたかどうか、あるいは管理者によって証明されたのかどうかを示す。後述されるように、各連絡先の認証ステータスが直ちに明らかになるように、これらのフラグにより、ユーザインタフェース上に選択されたアイコンが表示される。本発明の原理に従って、及び後述されるように、メタデータは名前及びユーザが同じ表示名を有するアイデンティティを認識し、対処できるようにする名前一致情報も含む。
コラボレーティブシステムは、ユーザが、ユーザが協働できる個人用領域である共用空間を作成し、共用空間に加わることができるようにする。ユーザは、通常、それぞれの空間が（「メンバー」と呼ばれる）参加者の別の集合を有する複数の空間にアクセスできる。更に、各ユーザは仕事でのワークステーション、家庭でのデスクトップコンピュータ、及びモバイル使用のためのラップトップなどの複数のデバイスでいくつかの共用空間を維持できる。共用空間は、共用空間のメンバーによって寄与されるデータとツールを含み、動的である。即ち、ユーザは加わり、離れる。データは増大し、縮小する。ツールは去来する。共用空間の有効期間は束の間である（数分に過ぎない）か、あるいは共用空間は連続的に永久に持続できる。
このようなコラボレーティブシステムにおいてセキュリティを維持するために、ユーザアイデンティティは認証及び暗号化の技法によりアイデンティティを使用して、現実世界の人と密接に関連付けられ、それによりデータの守秘性と完全性を、それがシステムを通って伝搬するにつれて保証する。認証は、２つの別個のステップでコラボレーティブシステムにより実行される。第１のステップでは、システムは、電子アイデンティティを、それらが表す人間のユーザと正しく関連付けることによってシステム内のユーザを認証する。いったんこれが行われると、コラボレーティブシステムは（ファイル、チャットメッセージ、キーストロークに対する修正などの）システム内の動作を電子アイデンティティに正しく関連付けることにより第２の認証を実行する。
ユーザの自分のコンピュータアイデンティティとの初期の関連付けは、コラボレーティブソフトウェアが最初にデバイス上で構成される時に始まる。第１の構成ステップは、そのユーザを定義する属性を含むアカウント記憶部（データベース１２６などの暗号化されたＸＭＬオブジェクト記憶部）を作成することである。いくつかのアカウント属性が概略ＸＭＬ形式で以下に一覧表示されている。
account
{identities}
identity_1
{spaces}
private signing key (for Identity 1)
private encryption key (for Identity 1)
storage master key
contact information (for Identity 1)
id-url
public key algorithms
public signing key
public encryption key
devices
relay server
status word
idebtity_2
{known contacts}
このサンプルＸＭＬファイルでは、それぞれの字下げが階層を示し、アカウントは、私的なアイデンティティと職業上のアイデンティティなどの複数のアイデンティティを含んでよい。各アイデンティティは、鍵及び連絡先情報のセットを含む独自の一意のパラメータを有している。この鍵は文書に署名するために使用される公開／秘密鍵組の一部である秘密署名鍵を含む。各連絡先は、ＵＲＬ、公開鍵アルゴリズム、公開署名鍵、公開暗号鍵、デバイス、連絡先によって使用される中継サーバ、及び前述されたステータスワードなどの連絡先識別情報を含む追加の情報を含む。
アカウント記憶部を作成する構成プロセスは、ユーザに、大文字と小文字、句読点、及び数字を含み、それを推測するのを困難にする「パスフレーズ」を作成するように依頼する。このパスフレーズは、次に、同様にアカウント記憶部内の情報を暗号化するために使用される（「記憶部マスタ鍵」と総称される）個々の共用空間のための鍵を復号するために使用されるマスタ鍵を保護するために使用される。
より具体的には、システムは、ＵＲＬ ｈｔｔｐ：／／ｒｆｃ−２８９８．ｒｆｃｉｎｄｅｘ．ｃｏｍ／ｒｆｃ−２８９８−２７．ｈｔｍのＲＦＣ ２８９８、及びＲＳＡラボラトリーズ社（ＲＳＡ Ｌａｂｏｒａｔｏｒｉｅｓ，Ｉｎｃ．）によって維持され、ｈｔｔｐ：／／ｗｗｗ．ｒｓａｓｅｃｕｒｉｔｙ．ｃｏｍ／ｒｓａｌａｂｓ／ｐｋｃｓ／ｐｋｃｓ−５に説明されている規格ＰＫＣＳ＃５ 第２版に説明されるパスワードをベースにした鍵導出機能＃２（ＰＢＫＤＦ２）などのパスワードベースの鍵導出機能に対する入力としてランダムな「ソルト」（ｓａｌｔ）値と共にパスフレーズを使用する。この機能は記憶部マスタ鍵を暗号化するアルゴリズムと共に使用するための対称鍵を作成する。この対称鍵はメモリに一時的に存在するに過ぎず、使用後はゼロにされ、絶対に電線で送信されない。別のデバイスで使用される同じパスフレーズは、ＰＢＫＤＦ２機能に追加されたランダムなソルト値のために別の対称鍵を作成するであろう。ソルト値はパスワードが変化するたびに変化するため、パスフレーズに対するディクショナリ攻撃もＰＢＫＤＦ２入力にソフト値を追加することで抑止される。更に、１秒の１０分の１の遅延をプロセスの中に作りこむ。この遅延は正規のログインの間にはほとんど目立たないが、それはディクショナリ攻撃の間に大きな量になり、それらを実行不可能にする。
例示として、記憶部マスタ鍵を暗号化するために使用されるアルゴリズムは、高度暗号化規格アルゴリズム（ＡＥＳ）などのアルゴリズムとなるであろう。ＡＥＳは、対称暗号化アルゴリズムのための米国で承認された規格であり、ＤＥＳアルゴリズムに代わる。ＡＥＳアルゴリズムは最初はラインダール（Ｒｉｊｎｄａｅｌ）と呼ばれ、二人のベルギーの暗号作成者によって作成された。それは非特許文献１及び２に詳しく説明されている。記憶部マスタ鍵は他の鍵を保護するために使用される。２つの主要なマスタ鍵があり、両方ともＡＥＳアルゴリズムを用いた暗号化に使用される２５６ビットの対称鍵である。一方のマスタ鍵はユーザセキュリティメタデータ鍵（ユーザの私的な署名及び復号鍵）を保護し、他方のマスタ鍵はユーザの暗号鍵（共用空間データを保護する鍵）を保護する。各共用空間に記憶されるデータは、独特の（データベース単位の）１９２ビットの対称ＡＥＳ鍵により暗号化される。対応する（データベース単位の）導出された１９２ビットのＨＭＡＣ鍵はデータベースの完全性保護を提供する。
秘密鍵もアカウントにより保持されるアイデンティティと関連付けられる（アカウントは複数のアイデンティティを保持できる）。各アイデンティティは（「アイデンティティ鍵組」と呼ばれている）２つの鍵の組と関連付けられる。（１）共用空間のコンテキストの外でメッセージ（インスタントメッセージ及び共用空間招待／受諾）に署名するために使用される２０４８ビットの非対称ＲＳＡ鍵組（ＲＳＡはＲｉｖｅｓｔ、Ｓｈａｍｉｒ、及びＡｄｌｅｍａｎの略語である――初めての実際的な公開鍵暗号システムを発明した三人の暗号作成者にちなんで。ＲＳＡ公開鍵アルゴリズムは今日最も一般的に使用されている公開鍵アルゴリズムである。それはｈｔｔｐ：／／ｗｗｗ．ｒｓａｓｅｃｕｒｉｔｙ．ｃｏｍ／に十分に説明されている）。
この鍵の組は（１）ＥＳＩＧＮアルゴリズムを使用する空間単位の署名鍵、及び（２）（共用空間のコンテキストの外でメッセージを保護するために使用される対称鍵の）暗号化のために使用される２０４８ビットの非対称ＥｌＧａｍａｌ鍵組を使用する空間単位の署名鍵にも署名する。ＥＳＩＧＮは日本で開発された特許権使用料が無料の公開鍵署名アルゴリズムである。それは現在ＩＥＥＥによって標準化され、ｈｔｔｐ：／／ｉｎｆｏ．ｉｓｌ．ｎｔｔ．ｃｏ．ｊｐ／ｅｓｉｇｎ／に説明されている。ＥｌＧａｍａｌアルゴリズムは、ＲＳＡ公開鍵アルゴリズムの代替策を提供する公開鍵暗号化アルゴリズムである。それは非特許文献３に詳細に説明されている。
ユーザが共用空間を作成すると、コラボレーティブシステムが該空間についての情報を空間に特殊なデータベース鍵で保護されている（図１Ｂのデータベース１４４、１４６、及び１４８などの）別個の共用空間データベースに追加してから、その空間のための多様な鍵を作成する。これらの後者の鍵も共用空間セキュリティメタベースデータベースに追加される。後に、ユーザが共用空間を開くと、記憶部マスタ鍵が該共用空間データベースセキュリティメタデータ内に含まれる鍵を解読するために使用される。これらの後者の鍵は、記憶されている共用空間データを暗号化する１９２ビットの空間単位の対称鍵である記憶部データベース暗号鍵を含む。この鍵は、記憶されている空間データの完全性を保護する１９２ビットの空間単位の対称鍵も導出する。空間は、空間のためのグループ暗号鍵を動的に導出する共用されている１９２ビットの対称鍵、及び「デルタ」と呼ばれる送信装置を介して電話で送信される共用空間データの完全性を保証するグループメッセージ認証（ＭＡＣ）鍵である、空間のためのグループ鍵を備えている。空間グループ鍵は、後述される招待プロトコルの間に新しいメンバーに配布される。空間グループ鍵は、メンバーが空間から招かれなくなると、鍵を付け替えられる（変更される）。
共用空間データベースはメンバーシグナチャ秘密鍵も含み、それはデルタと共用空間のコンテキストの中で送信されるデルタとメッセージに署名するためにこの空間のこのメンバーによって使用される１５３６ビットの非対称ＥＳＩＧＮ鍵である。この鍵の組の公開の半分は後述される「メンバー追加」デルタプロトコルの中で送信される。全メンバーの公開鍵も共用空間データ−ベースで維持される。共用空間データベースは、更に、共用空間内のメンバーの各組の間での組単位の鍵の確立のためにこの空間のこのメンバーにより使用される２０４８ビットの非対称鍵である共用空間メンバーＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ秘密鍵を含む。該Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎアルゴリズムは、ＵＲＬ ｈｔｔｐ：／／ｗｗｗ．ｒｓａｓｅｃｕｒｉｔｙ．ｃｏｍ／ｒｓａｌａｂｓ／ｐｋｃｓ／に位置するウェブサイトのＲＳＡラボラトリーズで入手可能なＰＫＣＳ ＃３に詳細に説明されている。この鍵組の公開半分はユーザのアイデンティティシグナチャ秘密鍵によって署名され、後述される招待プロトコルのグループ全体に配布される。全メンバーのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵の公開部分もこのデータベースに維持される。
共用空間データベースは組単位の鍵も含む。特に、各ユーザは、２つの他の一時的な組単位の鍵を導出するために共用空間の各メンバーと独特の１９２ビット対称鍵を共用する。導出された鍵は、空間の中の単一のユーザをターゲットとした（デルタフェッチ要求などの）メッセージを（１９２ビットのＡＥＳアルゴリズムを使用して）暗号化し、（１９２ビットのＨＭＡＣ ＳＨＡ−１ハッシュアルゴリズムを使用する。このアルゴリズムの詳細はｈｔｔｐ：／／ｗｗｗ．ｉｔｌ．ｎｉｓｔ．ｇｏｖ／ｆｉｐｓｐｕｂｓ／ｆｉｐ１８０−１．ｈｔｍに位置するウェブサイトのＦＩＰＳ １８０−１に説明されている。）完全性保護するために使用される。空間メンバー組単位の鍵は（空間メンバーＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を使用して）空間内のメンバーの各組の間でのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵の一致から由来する。
この時点で、ユーザは電子アイデンティティを作成したことになる。しかしながら、他のユーザは、認証と呼ばれるプロセスにより、作成されたばかりの電子アイデンティティが真にユーザに属していることを依然として検証しなければならない。そうでなければユーザになりすました誰かが「マンインザミドル」攻撃をしかけ、ユーザと他のユーザの両方になりすますことによりユーザと別のユーザの間のすべての通信を傍受することができるであろう。
他のユーザを認証できる複数の方法がある。例えば、ユーザは他のユーザを手動で認証できる。別のユーザを手動で認証するためには、ユーザは他のユーザの公開鍵の「デジタル指紋」を目視で調べる。デジタル指紋はユーザの公開鍵をハッシュするために暗号的に強力なハッシュアルゴリズムを動的に使用して作成される１６進文字列である。本発明と共に使用するのに適しているあるハッシュアルゴリズムが前述したＳＨＡ−１アルゴリズムである。公開鍵の代わりにデジタル指紋が使用される理由とは、それらが、人にとって公開鍵より読み易いが同時に安全であるためである。コラボレーティブシステムがデジタル指紋を作成し、メッセージ上のシグナチャを検証するために使用するユーザの公開鍵は、同様に中央ディレクトリサーバに、あるいはローカルディレクトリサーバに記憶されているユーザの連絡先情報の中に記憶されており、該情報は他のユーザが容易に入手できる。連絡先情報は、他者に送信され、彼らを共用空間に加わるように招待する「招待状」にも含まれている。招待状は更に詳しく後述される。このようにして公開鍵情報はデジタル指紋を作成するために容易に入手できる。
手動認証は、彼らの指紋値を得るために電話呼などの帯域外手段を使用して人に連絡することを含む。特に、コラボレーションシステムは各ユーザのデジタル指紋を自動的に計算する。この指紋はそのユーザに表示できる。更に、新しい連絡先がアカウント情報に追加されると、コラボレーティブシステムはその連絡先のデジタル指紋を計算するためにこの連絡先の公開鍵情報を使用する。この後者のデジタル指紋は図２に画面場面が描かれている認証画面に表示される。ユーザは、次に、帯域外手段を使用してその連絡先に連絡し、その連絡先のデジタル指紋を要求する。それから、ユーザは要求されたデジタル指紋を認証画面に表示されたデジタル指紋と比較し、指紋が一致した場合には、「Ａｕｔｈｅｎｔｉｃａｔｅｄ ａｓ（として認証済み）」ボックスにチェックマークをつけることで、この連絡先が認証された旨を示す。連絡先が特定の名前で認証されることに注意する。認証のプロセスは、認証されたユーザ（Ｍ）による以下の攻撃を妨げる。つまりユーザＡはユーザＭを認証する。今ユーザＡはＭを認証アイコン付きで認証済みとして見る。認証済みのユーザＭは今別のユーザＢの表示名に一致するために自分の表示名を変更する。ユーザＡは今Ｍの連絡先の隣であるがＢの表示名が付いた認証アイコンを見る。このようにして、ユーザＡは、事実上ユーザＭと通信している時に、自分が認証済みのユーザＢと通信していると考えるように「スプーフィング」される。
ユーザの中には「管理された」環境に属しているユーザが居る。これらの環境では、管理者は管理サーバを用いていくつかの方針態様を設定する。例えば、管理者は「ドメイン」レベルまたはグループレベルで方針を設定してよい。ドメイン単位及びグループ単位の方針管理はより大きな環境でセキュリティ制御及び操作パラメータを設定する上で柔軟性を与える。方針制御はパスフレーズ強度、特定のツールまたはソフトウェアバージョンへの制限、及び共用空間数または共用空間を作成する能力に対する制限を含む。
管理された環境では、管理者は管理サーバを使用し、管理されたエンティティへ方針データを分散することによりデバイス及びアイデンティティを管理する。例えば、機密保護方針は組織内の（ドメインの指名された下位区分である）管理ドメインまたはグループごとに個別に設定できる。方針は、パラフレーズの構成及び期限切れのような事柄を制御する管理されたデバイスの動作、及びメンバーが複数のアカウントを作成できるか、それとも管理されていないアイデンティティを作成できるのかを設定する。ユーザを、特定のツールまたはソフトウェアバージョンのダウンロードに制限することができ、彼らを特定の出版者からの署名された構成要素だけをダウンロードするように制約することができる。したがって、管理された環境は組織全体に亘って有意義な方針を構造化する上で大きな柔軟性を提供する。
ユーザが管理されたアイデンティティを有する管理された環境では、コラボレーティブシステムは、「証明機関」によって提供される証明書（署名された連絡先情報）に依存することによって自動的な認証をサポートする。例えば、グルーブエンタープライズマネージメントサーバ（Ｇｒｏｏｖｅ Ｅｎｔｅｒｐｒｉｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ）は証明機関として機能し、コラボレーティブソフトウェアは（ローカルに作成された公開鍵を含む）ユーザ連絡先情報を管理サーバに、それらが管理サーバによって証明できるように提示する。企業内の各管理サーバ管理ドメインは証明機関としての役割を果たす（管理サーバは複数の管理ドメイン、したがって複数の証明機関を有する）。証明機関の公開鍵はそれらの証明書と共にユーザに安全に送信される。これは、ユーザに、エンタープライズマネージメントサーバの証明機関を自分達の共通の証明機関として使用することにより彼らのドメイン内で互いを認証するための帯域内手段を与える。相互ドメイン認証は、無関係の管理サーバドメインの公開鍵を含む相互ドメイン証明書を使用して可能にされる。管理サーバ管理者は、この機能が必要とされる場合これらの証明書を管理する。
コラボレーティブシステムがどこに連絡先名を表示しようとも、「証明／認証アイコン」と呼ばれている認証インジケータがその認証ステータスを示す名前に先行してよい。認証インジケータは連絡先と共に、該連絡先が手動で認証されたかどうか、あるいはユーザが管理されたアイデンティティを有しており、連絡先がユーザドメインまたは相互証明されたドメインのメンバーであるかどうかを表示する。連絡先アイデンティティは、それが手動で認証されない場合、あるいは管理者によって証明されない場合は「未認証」と見なされる。付随する認証アイコン付きの連絡先アイデンティティの説明図は図３に図示されている。図３は、「Ｋｒｉｓ Ｊｏｎｅｓ／マーケティング／カンパニーワン（Ｃｏｍｐａｎｙ Ｏｎｅ）」３０２と名前が指定されたアイデンティティと共に、連絡先の連絡先情報の画面表示３００を描いている。この画面の場面は連絡先名に先行して表示される認証アイコン３０４を描いている。連絡先の認証ステータスを識別する３つのさまざまな認証アイコンがある。これらのアイコンの例示的な例は図４に示されている。
手動認証インジケータ４００は、連絡先が手動で認証された旨を示している。ユーザが手動で認証した連絡先に加えて、このインジケータはユーザ自身のアクティブなアイデンティティ、削除されたアイデンティティ、または無効にされたアイデンティティの隣に表示されている。企業内連絡先の例示的な証明認証インジケータ４０２も図４に示されている。このアイコンが連絡先名の前に表示されるとき、それは連絡先が管理され、連絡先が該アイコンを見ているユーザと同じドメインに属している、あるいはユーザのドメインと相互証明されたユーザの組織内の別のドメインに属していることを示している。連絡先が証明され、手動でも認証された場合は、証明インジケータではなく、手動認証インジケータだけが表示されるであろう。第３の認証インジケータ４０４は、企業内連絡先のための証明インジケータである。このアイコンは、連絡先が管理され、ユーザのドメインと相互証明されるユーザの組織の外部のドメインに属していることを示している。ある実施態様では、このアイコン４０４は企業内認証インジケータ４０２からそれを明確に区別するためにカラーコード化される。
本発明の原理に従って、コラボレーティブシステムは、「暗示認証」と呼ばれるプロセスによって認証済みの関係を自動的に構築するためのサポートを提供する。このプロセスに従って、第１のユーザがシステム内で初めて第２のユーザと通信する時、たとえ第１のユーザが第２のユーザを手動で認証しなくても、及び第２のユーザが証明されなくても、コラボレーティブシステムは第１のユーザのアカウントデータベースの中に、第２のユーザの公開鍵を含む第２のユーザの連絡先情報を依然として記憶する。その時から、システムは、第１のユーザが、第２のユーザの連絡先情報を使用するすべての将来の通信が同じ第２のユーザと行われることを保証されるように、各連絡先の公開鍵情報をチェックする。しかしながら、第２のユーザは手動で認証されていない、あるいは管理者によって証明されていないために連絡先情報の表示の第２のユーザ名の表示に認証アイコンは先行しない。
前述された暗示的な認証方式で生じる１つの問題とは、アイデンティティがユーザが選択した名前と関連付けられるという点である。特に、あらゆるアイデンティティが一意であるが、ユーザが自分のアイデンティティをユーザインタフェースディスプレイで表すために選択する名称は一意である必要はない。例えば、二人がアカウントを起動し、自分達の表示名に「Ｊａｎｅｔ」を入力すると仮定する。これは期せずして同じ表示名を使用する２つの一意のアイデンティティを生じさせるであろう。次に別のユーザが公開アドレスブックで「Ｊａｎｅｔ」を探し、図５Ａに図示されているようにそれが２度表示されていることに気付く可能性がある。図５Ａに図示されているように、両方の連絡先とも同一の表示名５００と５０２で表示されるであろう。
したがって、同じまたは類似した名前の２つの連絡先が混同される、あるいは詐欺師が別のユーザとの通信を開始するために正規の連絡先の名前を使用することが考えられる。この混同が発生しないことを保証するために、コラボレーティブシステムは「名前一致解決」と呼ばれるプロセスを実行する。このプロセスは、類似した名前の連絡先が提示された時にユーザに警告をするために特殊なユーザインタフェース表示アイコンを提供する。このようにして暗示的な認証が使用されると、ユーザは、あるユーザが同じ表示名を使用することにより別のユーザになりすましている場合、及びなりすましている時に警告されるだろう。
特に、２つまたは３つ以上の連絡先が同一（ｅｑｕｉｖａｌｅｎｔ）の表示名を有する時、コラボレーティブシステムは、前述された認証アイコンの代わりに、図５Ｂに図示されるような一致する名前５０４、５０６を有する２つのアイデンティティの表示名のそれぞれの隣に、疑問符アイコン４０６（図４）などの警告を表示する。コラボレーティブシステムは、２つ（または３つ以上の）「クリーンネーム（ｃｌｅａｎ ｎａｍｅ）」が正確に一致する場合表示名を同一と見なす。クリーンネームは（１）先行するスペースと後続のスペースを削除する、（２）複数の埋め込まれたスペースを圧縮する、（３）句読点を削除する、及び（４）すべてのテキストを小文字のＵＮＩＣＯＤＥ文字に変換することにより連絡先表示名から作成される。
表示名を比較するプロセスは図６に示されている。特に、前述されたように、各コラボレーティブシステムアカウントは、表示名を含む連絡先とそのメタデータを維持する「連絡先記憶部」を有している。該記憶部は、ユーザの私的な連絡先リスト、共用空間のメンバーリストから得られる連絡先、及びインスタントメッセージの「Ｔｏ（宛て先）」フィールドと「Ｆｒｏｍ（送信者）」フィールドからの連絡先を含むがそれらに限られないソースから得られる連絡先を含む。
新しい連絡先が記憶部に追加されるたびに、このプロセスはステップ６００で開始し、ステップ６０２に進み、ここで新しい連絡先表示名が、前述されたクリーンネームを作成することによって事前に処理される。このクリーンネームはステップ６０４で新しい連絡先と共に記憶されるメタデータの一部として含まれる。
次にクリーンネームは新しい連絡先を含む連絡先記憶部内の全連絡先についてクリーンネームと比較される。このプロセスを促進するために、クリーンネームは連絡先記憶部内の連絡先ごとにメタデータに記憶される。これらの記憶されているクリーンネームは次に新しい連絡先と比較され、名前が同一であるかどうかを判断し、名前一致リストを作成する。特にステップ６０６では、比較される追加のクリーンネームが連絡先記憶部に留まるかどうかを判断するために確認が行われる。追加名が留まらない場合には、名前連絡先リストは完全なものとなり、プロセスはオフページコネクタ６１６と６１８を介して、処理が後述されるように続行するステップ６２０に進む。
代わりに、追加名がステップ６０６で判断されたようにまだ処理されていない場合には、プロセスはステップ６０８に進み、ここで次の連絡先が連絡先記憶部から取り出され、ステップ６１０でその連絡先のクリーンネームが新しい連絡先クリーンネームと比較される。
ステップ６１２で判断されたように一致がある場合には、その連絡先はステップ６１４で規定されるように名前一致リストに追加される。それからプロセスはステップ６０６に戻り、連絡先記憶部の追加の名前がまだ確認されていないかどうかを判断する。代わりに、ステップ６１２で一致が検出されなかった場合には、プロセスはステップ６０６に戻り、連絡先記憶部の追加の名前がまだ確認されてないかどうかを判断する。
すべての連絡先名が確認されると、処理は前述されたようにステップ６２０へ続行する。ステップ６２０から６４２で、新しい連絡先クリーンネームと一致するクリーンネームの付いた連絡先のメタデータ内の名前一致ビットが設定されるかどうかが判断される。連絡先の名前一致ビットが設定されると、連絡先表示名がコラボレーティブシステムのユーザインタフェース内のどこに、及びいつ表示されようとも、名前一致アイコンが表示される。
名前一致ビットが設定されるかどうかの判断は、連絡先の認証／証明レベルの比較に基づく。前述されたように、各連絡先には以下の４つの証明レベルの１つが割り当てられる。つまり（１）手動で認証済み、（２）企業内で証明済み、（３）企業間で証明済み、及び（４）未認証。手動で認証済みが最高のレベルである。ステップ６０６から６１４で作成された名前一致リスト上の連絡先の場合、これらのレベルはステップ６２０から６２８で比較される。ステップ６２０では、名前一致リストが、リスト上のあらゆる連絡先が処理されていないかどうかを判断するためにチェックされる。連絡先がまだ処理されていない場合は、プロセスはリスト上の次の連絡先が処理のために選択されるステップ６２２に進む。ステップ６１４では、選択された連絡先の認証／証明レベルが、処理された連絡先の最高認証／証明レベルを保持する最高証明レベル変数と比較される。選択された連絡先の認証／証明レベルが該変数の値より高い場合には、ステップ６２６で、変数の値は選択された連絡先の認証／証明レベルに設定され、プロセスはステップ６２０に戻り、リスト上の追加の名前が処理を必要とするかどうかを判断する。
ステップ６２４で、選択された連絡先の認証／証明レベルが最高の証明レベル変数の値より高くないと判断されると、プロセスは、選択された連絡先の認証／証明レベルが最高の証明レベル変数と比較されるステップ６２８に進み、選択された連絡先の認証／証明レベルが最高の証明レベル変数に等しい場合には、別の変数の値、つまり最高の一致証明レベル変数が、選択された連絡先の認証／証明レベルに設定される。プロセスは次にステップ６２０に戻り、一致リストの更に多くの連絡先がまだ処理されていないかどうかを判断する。代わりに、ステップ６２８で、選択された連絡先の認証／証明レベルが最高の証明レベル変数の値に等しくないと判断される場合、プロセスはステップ６２０に直接戻るだけである。
最後に、一致する表示名を有する選択された連絡先と関連付けられるメタデータの名前一致ビットを設定するために、一致リスト上の一致が再び調べられる。このプロセスはステップ６３６から６４４で実行される。特に、ステップ６２０では、まだ処理されていない追加の名前がないと判断されると、プロセスは、オフページコネクタ６３２と６３４を介して、名前一致リストが、リスト上のあらゆる連絡先がまだ処理されていないかどうかを判断するためにチェックされるステップ６３６に進む。
更に多くの連絡先がまだ処理されていない場合には、プロセスは、リストの次の連絡先が選択されるステップ６４０に進む。次に、ステップ６４２で、選択された連絡先の認証／承認レベルがステップ６２０から６３０で求められた最高の証明レベル変数の値と最高の一致証明変数の値と比較される。選択された連絡先の認証／証明レベルが最高の証明レベル変数の値未満である、あるいは最高の一致証明レベル変数の値に等しい場合には、プロセスは、選択された連絡先のメタデータの名前一致ビットが設定されるステップ６４４に進み、プロセスは追加の連絡先を処理するためにステップ６３６に戻る。そうでなければ、ステップ６４２でプロセスは追加の連絡先を処理するために直接ステップ６３６に戻る。すべての連絡先がステップ６３６で決定されたように処理されると、ステップ６３８でプロセスは終了する。
前述した認証／証明レベルの比較は、「名前スプーフィング」攻撃者からのサービス攻撃の拒否を緩和するために実行される。例えば、悪意のあるユーザ（Ｍ）が、表示名が本物のユーザＱの表示名に一致する仮のアイデンティティＱ’を作成することにより、認証済みの（あるいは相互証明された）ユーザＰとＱとの間の通信で混乱を生じさせようとすると仮定する。次にユーザＭは、ユーザＱを装ってインスタントメッセージをユーザＰに送信する。連絡先ＱとＱ’の表示名が一致するため、認証／証明レベルの比較を行わないと、ユーザＰは、名前一致アイコンが連絡先ＱとＱ’の表示名と共に表示されるのを見るであろう。ユーザＰは、次に、後述されるように名前一致を解決することが必要とされるであろう。このプロセスは、Ｍが、すべてが本物の連絡先Ｑと同じ表示名を使用するアイデンティティＱ’’、Ｑ’’’、Ｑ’’’’からメッセージを送信し続ける場合には再三再四繰り返されなければならないであろう。しかしながら、前述された追加の認証／証明レベルのチェックを行うことにより、コレボレーティブシステムは連絡先Ｑ‘より連絡先Ｑを好み、連絡先Ｑの表示名と関連付けられた名前一致アイコンを表示しないだろう。したがって、表示はユーザＰが危険な連絡先を容易に識別できるようにする。
連絡先が連絡先記憶部から削除されると必ず、ステップ６００から６４４が、もはや存在しない名前一致を削除し、追加の認証／証明レベルチェックをもう一度行うためにその連絡先について実行される。
一致アイコンにより示される名前一致を解決するために、ユーザはそれに関連付けられた一致インジケータを有する表示名を右クリックして、名前一致解決ダイアログボックスを開くことができる。この動作によりドロップダウンリストが開き、ユーザは次に該リストから「Ｒｅｓｏｌｖｅ Ｎａｍｅ Ｃｏｎｆｌｉｃｔ（名前一致を解決する）」を選択できる。
Ｒｅｓｏｌｖｅ Ｎａｍｅ Ｃｏｎｆｌｉｃｔのオプションを選択すると、コラボレーティブシステムは、選択された名前と同じ「クリーンネーム」の付いたユーザの連絡先記憶部内のすべての連絡先の位置を突き止め、表示する。これらの後者の連絡先は図７に図示されるようにＲｅｓｏｌｖｅ Ｎａｍｅ Ｃｏｎｆｌｉｃｔダイアログボックス７００のリスト７０２に表示される。例えば、リスト７０２は一致する表示名「Ｊａｎｅｔ」が付いた２つの前述した連絡先７１０と７１２を表示する。このリストは連絡先のステータス７０４（オンラインなのか、オフラインなのか）、及び連絡先のユーザに対する関係７０６も示す。チェックボックス７０８は一致する連絡先が発見されたすべての共用空間の名前を更に表示するために設けられる。リスト７０２内の名前の１つ（例えば、名前７１２）を選択すると、名前は連絡先の「ｖＣａｒｄ」に記憶された情報と共に編集ボックス７１４に表示される。
ユーザは次に、一致する表示名を置換する「エイリアス」表示名を連絡先に割り当てるか、または（同様に、プロセスがエイリアス表示名が連絡先に割り当てられることを必要とする）連絡先を手動で認証するかのどちらかによって名前一致を解決できる。エイリアスは、ユーザがその連絡先を他の類似した名前が指定される連絡先から区別するのに役立つように連絡先に割り当てられる別の表示名に過ぎない。特に、ユーザはその上でクリックしてから、「Ａｌｉａｓ（エイリアス）」オプションまたは「Ａｕｔｈｅｎｔｉｃａｔｅ（認証）」オプションのどちらかを選択することによってＲｅｓｏｌｖｅ（解決）ドロップダウンリスト７１６を起動できる。
Ａｌｉａｓオプションを選択すると、図８に図示されるＡｌｉａｓ（エイリアス）ダイアログボックス８００が表示される。このダイアログボックスには連絡先のフルネーム８０２が表示され、ユーザが連絡先の一意の表示名を入力してから、「ＯＫ」コマンドボタン８０６または「Ｃａｎｃｅｌ（取り消し）」コマンドボタン８０８のどちらかを選択することによって名前を確認できるテキストボックス８０４を有する。代わりに、ドロップダウンリスト７１６からａｕｔｈｅｎｔｉｃａｔｅ（認証）オプションを選択すると、図２に描かれているａｕｔｈｅｎｔｉｃａｔｅ（認証）ダイアログボックスが表示される。
２つの連絡先が両方とも表示名「Ｊａｎｅｔ」で存在する前述した例では、ユーザは親戚のためのエイリアス「Ｊａｎｅｔ（私の姉妹）」及びビジネス上の連絡先のための別のエイリアス「Ｊａｎｅｔ（私のマネージャ）」を作成することを希望する可能性がある。ユーザは、別名の付けられた（ａｌｉａｓｅｄ）連絡先が絶対に表示名一致にならないようにそれぞれの連絡先に一意のエイリアス表示名を割り当てなければならない。後にエイリアス表示名と同じ表示名の付いた連絡先が連絡先記憶部に追加されると、新しい連絡先表示名が一致アイコンと関連付けられるが、別名が付けられ、認証された連絡先表示名は、前述した認証済み／証明済みの連絡先の優先的な処理のために、それと関連付けられた一致アイコンを有さないであろう。エイリアスがＲｅｓｏｌｖｅ Ｎａｍｅ Ｃｏｎｆｌｉｃｔダイアログボックス７００内の連絡先のために選択されているときに、「済み」コマンドボタン７１８を選択するとコラボレーティブシステムは連絡先表示名を該エイリアスで置換する。エイリアス９０２は、次に図９に描かれているように元の表示名の代わりに連絡先リスト９００に表示される。エイリアスは、エイリアス５１６と５１８を図示する図５Ｃに示されるように他のすべての連絡先リストにも表示される。ある実施態様では、エイリアスはユーザのアカウント内の他のすべてのデバイスで同じになるであろう。また、エイリアスは通常他のメンバーには見えないであろう。
前述された手順を用いても、セキュリティシステムのロバスト性は確立された認証及び証明手順にユーザが準拠しているかどうかに大きく依存している。システムのセキュリティを高めるためには、本発明の原理に従って、ユーザによって、あるいは管理されたアイデンティティのケースではシステム管理者によってセキュリティ方針を実現することができる。アイデンティティのためのセキュリティ方針は、コラボレーティブシステムのアイデンティティが他のアイデンティティと通信することをどのように許すのかを制御する。特に、コラボレーティブシステムは、ユーザが、彼らが管理されたアイデンティティを有しておらず、証明されたドメインの一部ではないことを意味する、管理者により証明されていない人と、あるいは手動で認証されていない人と通信しようとする時にユーザに警告することができる。
実例としては、ユーザに警告する、あるいは個人との通信を、彼らの連絡先アイデンティティが管理者により証明されていない、または手動で認証されていない限り禁止するために、複数のオプションが提供されている。これらは、表１に述べられているオプションのようなオプションが含まれてよい。
Figure 2005327234
セキュリティ方針は通信活動中のコラボレーティブシステムの動作に影響を及ぼす。例えば、前述した「未認証の場合警告」方針は表２に示されるように活動に影響を及ぼす。表２が包括的ではないことに注意する。新しい連絡先との他の操作もシステムにＡｕｔｈｅｎｔｉｃａｔｅダイアログを表示させることができるであろう。
Figure 2005327234
「未証明の場合拒絶」方針は表３に示されるように通信活動に影響を及ぼす（表２の場合と同様に、表３も包括的ではない）。
Figure 2005327234
「未証明の場合拒絶」のセキュリティ方針が管理されているアイデンティティに適用さても、管理されているアイデンティティの付いたユーザは依然として他の連絡先アイデンティティを手動で認証できる。しかし、そのユーザは、手動で認証されたアイデンティティが更に管理者によって証明されていない場合には、手動で認証されたアイデンティティと通信できない。ユーザが、手動で認証されたに過ぎないアイデンティティと通信しようとする場合、ユーザは、「未許可の場合拒絶」方針が適用されていないアイデンティティを使用しなければならない。
同じアカウント内の複数のアイデンティティは、各アイデンティティに割り当てられたさまざまなセキュリティ方針を有する場合がある。例えば、ユーザは「未証明の場合拒絶」のセキュリティ方針が適用された自分のオフィスに管理されたアイデンティティを有し、アイデンティティセキュリティ方針が適用されていない状態で家庭で使用するための同じアカウント内の管理されていないアイデンティティも有する可能性がある。更に、指定されたアイデンティティに関してそれぞれが別のレベルの認証を持つ複数のアイデンティティのアカウントを有することも可能である。これが発生する場合、コラボレーティブシステムはアカウントが指定されたアイデンティティとの最高の認証／証明関係を表示する。
例えば、それぞれがさまざまな管理ドメインからの複数の管理されたアイデンティティの付いたアカウントがある場合に、さまざまなレベルの認証が発生することがある。このケースでは、それぞれの管理ドメインは指定されたドメインで異なる相互証明設定値を有する可能性がある。
アイデンティティが管理されている場合、セキュリティ方針は管理サーバを使用して管理者により設定される。セキュリティ方針を特定するためには、管理者はドメインまたはグループのアイデンティティを定義してから、これらのアイデンティティを従来の様式で管理させなければならない。次に管理者はサーバでユーザインタフェースを使用し、方針を設定する。ドメインまたはグループにアイデンティティ方針を設定するために、管理者はドメイン／グループウィンドウを開き、管理ドメインまたはグループを選択してから、「方針」タブ及び「ｅｄｉｔ ｉｄｓｅｎｔｉｔｙ ｐｏｌｉｃｉｅｓ（アイデンティティ方針を編集する）」リンクまたは他の類似する選択機構を選択する。
次に図１０に図示されるアイデンティティ方針ページ１０００が表示される。方針がドメインに対し設定されている場合にはｅｎａｂｌｅ ｐｏｌｉｃｙ（方針を有効にする）チェックボックス１００２が表示される。ボックスにチェックマークを付けると、現在のアイデンティティ方針設定がドメインに適用されることが指定される。ボックスのチェックを解除すると、デフォルトのアイデンティティ設定値がドメインに適用されることが指定される。
「ｉｄｅｎｔｉｔｙ ｍａｙ ｏｎｌｙ ｂｅ ｕｓｅｄ ｏｎ ａ ｍａｎａｇｅｄ ｄｅｖｉｃｅ（アイデンティティは管理されているデバイスだけで使用されてよい）」チェックボックス１００４は、選択されているドメインまたはグループ内の管理されているアイデンティティだけが管理されているデバイスで使用できることを指定する。このチェックボックスのチェックを解除すると、管理されているアイデンティティを、管理されているか、あるいはされていないかに関係なく任意のデバイスで使用できるようにする。
「ａｕｔｏｍａｔｉｃａｌｌｙ ｐｕｂｌｉｓｈ ｖＣａｒｄ ｔｏ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ ｄｉｒｅｃｔｏｒｙ（管理サーバディレクトリにｖＣａｒｄを自動的に発行する）」チェックボックス１００６は、管理サーバがドメイン／グループメンバーの管理されているアイデンティティ及びｖＣａｒｄ情報をドメインメンバーの管理サーバのローカルディレクトリに自動的に発行する必要があることを指定する。
「ｐｒｅｖｅｎｔ ｐｕｂｌｉｓｈｉｎｇ ｖＣａｒｄ ｔｏ ｇｒｏｏｖｅ．ｎｅｔ ｄｉｒｅｃｔｏｒｙ（ｇｒｏｏｖｅ．ｎｅｔディレクトリにｖＣａｒｄを発行するのを妨げる）」チェクボックス１００８は、管理サーバがドメイン／グループメンバーの管理されているアイデンティティ及びｖＣａｒｄ情報をｇｒｏｏｖｅ．ｎｅｔウェブサイト上のｇｒｏｏｖｅ．ｎｅｔパブリックディレクトリに発行してはならないことを指定している。
「ｂａｃｋｕｐ ａｃｏｕｎｔ ｅｖｅｒｙ（１）ｄａｙ（ｓ）（ｍａｘｉｍｕｍ７）（毎（１）日（複数の場合がある）（最大７）アカウントをバックアップする）」チェックボックス１０１０は、ドメインで管理されているアイデンティティについて管理サーバがどのくらい頻繁にユーザアカウントを自動的にバックアプするのかを指定する。１から７の数をテキストボックスに入力し、バックアップ間の日数を指定できる。テキストボックスを空にしておくと、この方針は無効になり、アカウントはバックアップされないであろう。
表示１０００の次のセクションは、ピア（ｐｅｅｒ）認証方針を指定する。この方針は、管理サーバが未認証連絡先とのクライアントによる通信をどのように処理するのかを決定する。「Ｄｏ ｎｏｔ ｗａｒｎ ｏｒ ｒｅｓｔｒｉｃｔ ｍｅｍｂｅｒｓ ａｂｏｕｔ ｃｏｍｍｕｎｉｃａｔｉｎｇ ｗｉｔｈ ａｎｙ ａｉｄｅｎｔｉｔｉｅｓ（あらゆるアイデンティティと通信することについてメンバーに警告またはメンバーを制限しない）」ラジオボタン１０１４を選択すると、表１に説明された「開放」方針が設定され、メンバーは、管理サーバが警告情報を生成しなくても未認証の連絡先と自由に通信できる。
「Ｗａｒｎ ｍｅｍｂｅｒｓ ｂｅｆｏｒｅ ｃｏｍｍｕｎｉｃａｔｉｎｇ ｗｉｔｈ ｃｏｎｔａｃｔｓ ｔｈａｔ ｈａｖｅ ｂｅｅｎ ｎｅｉｔｈｅｒ ａｄｍｉｎｉｓｔｏｒ−ｃｅｒｔｉｆｉｅｄ ｎｏｒ ｍａｎｕａｌｌｙ ａｕｔｈｅｎｔｉｃａｔｅｄ ｂｙ ｔｈｅ ｍｅｍｂｅｒ（管理者に証明されていないし、メンバーによって手動で認証されてもいない連絡先と通信する前にメンバーに警告する）」ラジオボタン１０１６を選択すると、表１の「未認証の場合警告」方針が設定され、メンバーが未認証のユーザと通信できるが、管理サーバはこのような通信が試みられる前に前述されたように警告を発行する。
「Ｏｎｌｙ ａｌｌｏｗ ｍｅｍｂｅｒｓ ｔｏ ｃｏｍｍｕｎｉｃａｔｅ ｗｉｔｈ ａｄｍｉｎｉｓｔｒａｔｏｒ−ｃｅｒｔｉｆｉｅｄ ｃｏｎｔａｃｔｓ（メンバーが管理者により証明された連絡先とだけ通信できるようにする）」ラジオボタン１０１８を選択すると、表１の「未証明の場合拒絶」方針が設定され、メンバーが未証明のアイデンティティと通信するのを妨げる。
全ての選択がなされると、「Ｓｕｂｍｉｔ（提出）」コマンドボタン１０２０を選択できる。次に選択されたアイデンティティ方針が後述される管理されているオブジェクトを使用してドメイン内のデバイスに自動的に広められる。ユーザがオフラインである場合は、その方針は、彼らが次回オンラインになったときに管理オブジェクトによって更新されるだろう。
更に、管理ドメインの一部ではないユーザは、図１１に図示される表示画面のようなユーザインタフェース表示画面１１０によって独自のセキュリティ方針を設定してよい。セキュリティ方針は適切なラジオボタン１１０２、１１０４または１１０６を選択することによりユーザが設定（あるいは、アイデンティティが管理されているアイデンティティである場合にはレビュー）できる。アイデンティティが管理されている場合、ボタン１１０２、１１０４及び１１０６は、管理されているアイデンティティのセキュリティ方針が管理者によって制御されるので無効にされるだろう。アイデンティティが管理されていない場合には、ボタン１１０４と１１０６が有効化されるが、ボタン１１０８は、この選択が常に管理者によって制御されるため（図１１に図示されるように）無効にされるだろう。
ドメインセキュリティ方針は管理サーバからユーザアカウントに送信される「管理オブジェクト」によって実現される。特にセキュリティ方針は「アイデンティティ方針」オブジェクトに含まれる。このようなオブジェクトは管理サーバで作成され、作成時には対象となるユーザ（特定のアイデンティティ）を有するあるいは有さない場合がある。管理サーバが管理オブジェクトを生成した後（ａ）サーバがアカウントの中にオブジェクトを「投入する」または（ｂ）アカウントに関連付けられたエンドユーザが、オブジェクトをアカウントの中に手動で注入するためにオブジェクトの表記をクリックできるかのどちらかである。アカウントの中に注入される管理オブジェクトはアカウントの内部の管理オブジェクト記憶部（１５０、図１Ｂ）に記憶される。
いずれにせよ、管理オブジェクトの注入後、アカウントの何らかのアイデンティティが（報告の目的で）オブジェクトの実際のユーザとして記されるであろう。コラボレーティブシステムが対象となるユーザをアカウントの中のアイデンティティの１つと一致させることができる場合、そのアイデンティティは管理オブジェクトと関連付けられるであろう。そうではない場合は、アカウントの所有者は、アカウントに複数のアイデンティティがある場合に1つのアイデンティティを選択できる。
誰かが管理オブジェクトを注入するたびに、コラボレーティブシステムは（管理者要員が誰がオブジェクトを注入したのか、及び誰がオブジェクトを注入しなかったのかを突き止めることができるように）オブジェクトの実際のユーザのアイデンティティと共に管理サーバにこの事実を報告する。サーバには管理オブジェクトを取り消す能力もある。特にユーザが管理オブジェクトを要求するたびに、この事実は（管理要員が、誰が実際に管理オブジェクトを使用しているのかを突き止め、必要な場合に特定のユーザについてオブジェクトを取り消すことができるように）オブジェクトの実際のユーザと共に管理サーバに報告される。
管理オブジェクトを生成するために、選択された情報が管理サーバに提供される。サーバは次にＸＭＬ文書の形式でオブジェクトを生成する。何らかの情報がオブジェクトのヘッダに含まれている。この情報は管理オブジェクトを識別する名前（大局的に一意）を含む。例えば、例示的な名前は「ｇｒｏｏｖｅＬｉｃｅｎｓｅ：／／Ｃｏｒｅ／ＧｒｏｏｖｅＰｒｏｆｅｓｓｉｏｎａｌ」または「ｇｒｏｏｖｅＡｃｃｏｕｎｔＰｏｌｉｃｙ：／／ＤａｔａＲｅｃｏｖｅｒｙ」またはｇｒｏｏｖｅＩｄｅｎｔｉｔｙＰｏｌｉｃｙ：／／．」を含む。
管理オブジェクト情報は、オブジェクト発行者を識別する情報も含む。これは大局的に一意のＵＲＮ（例えば、「ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ：」）の形を取る企業識別を含む可能性がある。管理サーバＵＲＬ及び（指定されたサーバにとって一意である）管理ドメイン名を含む管理ドメインも提供される。この情報は更にオブジェクトに署名するために使用される管理ドメインの秘密鍵及び証明書、及びオプションで管理オブジェクトの対象となるユーザも含む。オプションで管理オブジェクトの本体も提供されてよい。
一般化された管理オブジェクトを具現するＸＭＬ文書のスキーマが後述される。
<!--
- optional attributes are enclosed in []
- optional attribute default values are after //=
- optional elements are noted as such
-->
<g:ManagedObject
Version="0,0,0,0"
>
<g:Header
GUID="<GUID>"
NAME="<name>"
DisplayName="<display_name>"
Description="<description>"
IssuedTime="<issued_time>"
[DeviceSpecific="1|0"] //="0"
[ReplacementPolicy="$Never|$Always|$IssuedTime"]//="$Never"
[IntendedIdentityURL=<intended_identity_URL>"] //=""
>
<!-- expiration is optional, default is none -->
<g:Expiration>
<g:TimePeriod
Value="<value>"
[Baseline="$IssuedTime|$InjectionTime"
//="$InjectionTime"
[Limit="<limit>"] //=none
/>
</g:Expiration>
<g:Issuer
Name="<name>"
DisplayName="<display_name>"
/>
<g:ManagementDomain
Name="<name>"
DisplayName="<display_name>"
ServerURL="<server_URL>"
/>
</g:Header>

<!-- body is optional -->
<g:Body
ComponentResourceURL="<component_resource_URL>"
>
<!-- whatever data is needed by a particular type of a managed object should be in the body element below -->
<g:body_element>
</g:body_element>
</g:Body>

<g:Signatures>
<g:Signature Value="<value>"Fingerprint="<fingerprint>"/>
</g:Signatures>
</g:ManagedObject>
ヘッダ部分では、ＧＵＩＤ属性は管理オブジェクトの大局的に一意の識別子であり、それぞれの新規に生成される管理オブジェクトと共に生成される。名前属性は管理オブジェクトを識別し、前述された表示名ではない。管理オブジェクト名はＵＲＬであり、ＵＲＬのスキーマ部分は管理オブジェクト型であり、残りはその特定の管理オブジェクト型に特有である。例えば、ｇｒｏｏｖｅＬｉｃｅｎｓｅ：／／ｇｒｏｏｖｅ．ｎｅｔ／；Ｄｉｖｉｓｉｏｎ＝Ｃｏｒｅ，Ｐｒｏｄｕｃｔ＝Ｇｒｏｏｖｅはライセンス管理オブジェクトの名称であり、「ｇｒｏｏｖｅＬｉｃｅｎｓｅ」部分はラインセンスの管理オブジェクト型である。任意の時点で管理オブジェクト記憶部は指定された名前が付いた多くても１つの管理オブジェクトを記憶できる。
ＤｉｓｐｌａｙＮａｍｅ／Ｄｅｓｃｒｉｐｔｉｏｎ属性は、人間が読み取り可能な管理オブジェクトの表示名／記述である。ＩｓｓｕｅｄＴｉｍｅ属性は管理オブジェクト発行時間を指定する。ＤｅｖｉｃｅＳｐｅｃｉｆｉｃ属性は、管理オブジェクトがデバイス全体に適用できるかどうかを判断する。この属性が「１」である場合には、管理オブジェクトはデバイスに特有であり、構成要素ダウンロード方針などのデバイス全体に適用される。
ＲｅｐｌａｃｅｍｅｎｔＰｏｌｉｃｙ属性は、既存の管理オブジェクトを同じ名前が付いた別の管理オブジェクトでいつ置換できるのかを示している。コラボレーティブシステムは、置換対象の管理オブジェクトにおける置換方針よりむしろ置換管理オブジェクト内で指定される置換方針を尊重する。この属性に考えられる値は＄Ｎｅｖｅｒ―管理オブジェクトは絶対に置換できない、＄Ａｌｗａｙｓ―管理オブジェクトはつ常に置換されるべきである、及び＄ＩｓｓｕｅｄＴｉｍｅ―管理オブジェクトは発行時刻がより最近の別の管理オブジェクトによって置換できるである。この属性のデフォルトは＄Ｎｅｖｅｒである。
ＩｎｔｅｎｄｅｄＩｄｅｎｔｉｔｙＵＲＬ属性は、管理オブジェクトについて（実際のとは対照的に）対象となるアイデンティティＵＲＬを指定する。Ｅｘｐｉｒａｔｉｏｎ属性は、管理オブジェクトがいつ期限切れになり、使用できなくなるのかを定義する。期間属性は例えば３０日などの有効期間について指定できる。この値は、Ｂａｓｅｌｉｎｅ属性によって指定されるベースラインに関係する。有効期間のＢａｓｅｌｉｎｅ属性は有効期間の開始がいつ発生するのかを指定し、以下の２つの考えられる値を有する。つまり、ベースラインが管理オブジェクト発行時刻であることを指定する＄ＩｓｓｕｅｄＴｉｍｅと、ベースラインが管理オブジェクト注入時刻であることを指定する＄ＩｎｊｅｃｔｉｏｎＴｉｍｅである。指定されない場合には値＄ＩｎｊｅｃｔｉｏｎＴｉｍｅがデフォルトである。有効期間は、他の条件には関係なく、管理オブジェクトが期限切れになると、総合的な期限を課すことを可能にするＬｉｍｉｔ属性も有する場合がある。これは、ベースラインに関連しない絶対値である。
発行者属性は管理オブジェクト発行者を特定する。発行者名及び表示名は指定される必要があり、名前は大局的に一意でなければならない。管理ドメイン属性は管理オブジェクトの管理ドメインを識別する。管理ドメインの名前、表示名、及びサーバＵＲＬは指定されなければならないが、この場合サーバＵＲＬが管理サーバを指し、名前がそのサーバの範囲内で一意でなくてはならない。
スキーマの本体部分は、どの構成要素がこのオブジェクトの本体、及び特定のオブジェクト型によって決定される不透明なデータを含む本体要素を処理しているのかを指定する構成要素リソースＵＲＬを含む。
前述したように、アイデンティティのセキュリティ方針はアイデンティティ方針管理オブジェクトに含まれる。このようなオブジェクトの例示的な名称は、ｇｒｏｏｖｅＩｄｅｎｔｉｔｙＰｏｌｉｃｙ：／／＜ＧＵＩＤ＞である。例示的なＣｏｍｐｏｎｅｎｔＲｅｓｏｕｒｃｅＵＲＬ属性は、ｈｔｔｐ：／／ｃｏｍｐｏｎｅｎｔｓ．ｇｒｏｏｖｅ．ｎｅｔ／Ｇｒｏｏｖｅ／Ｃｏｍｐｏｎｅｎｔｓ／Ｒｏｏｔ．ｏｓｄ？Ｐａｃｋａｇｅ＝ｎｅｔ．ｇｒｏｏｖｅ．Ｇｒｏｏｖｅ．ＳｙｓｔｅｍＣｏｍｐｏｎｅｎｔｓ．ＧｒｏｏｖｅＡｃｃｏｕｎｔＭｇｒ ＤＬＬ＆ａｍｐ；Ｖｅｒｓｉｏｎ＝０＆ａｍｐ；Ｆａｃｔｏｒｙ＝ＩｄｅｎｔｉｔｙＰｏｌｉｃｙである。
アイデンティティ方針管理オブジェクトの本体要素の例示的なスキーマは以下に示される。このスキーマでは、＜ｇ：Ｐｏｌｉｃｙ＞要素を除くすべての要素がオプションである。
<g:Policy[Flags="<flags>"][PeerAuthenticationLevel="<level>"]>
<g:Contact>
<g:VCard[ChangeFlags="<vCard_change_flags>"/]>
<g:Policies>
<g:DirectoryListings>
<!-- may have 0+ elements like the one below -->
<g:DirectoryListing
Name="<directry_name>"
Value="<directory_listing_value>"/>
</g:DirectoryListings>
</g:Policies>
</g:Contact>
<g:Backup Interval="<interval_in_days>"/>
[<g:Telespaces DefaultTemplateComponentResourceURL="<>"/>]
<g:AttachmentRestriction
AllowOnly="<true|false>"
Size="<size_in_kb>"
FileType="<list_file_ext>"
/>
</g:Policy>
Ｆｌａｇｓ属性の例示的な値は、このアイデンティティがアイデンティティと関連付けられた管理ドメインからのデバイス上だけで使用できることを示す「０ｘ１」である。ＰｅｅｒＡｕｔｈｅｎｔｉｃａｔｉｏｎＬｅｖｅｌ属性は、いかなる連絡先との通信時にも警告または制限が発行されないことを示す「０」を含む３つの考えられる値を有することがある。これが、例示としてデフォルトの動作となるであろう。値「１」は、システムが未認証の連絡先についてユーザに警告する必要があることを示し、値「２」は、システムが未証明の連絡先と通信するのを制限する必要があることを示している。
例示としてｖＣａｒｄ＿ｃｈａｎｇｅ＿ｆｌａｇｓの値は、ユーザが業種フィールドを変更できないことを示す「０ｘ２」である。ｄｉｒｅｃｔｏｒｙ＿ｎａｍｅ属性は、ディレクトリがＧｒｏｏｖｅ．ｎｅｔ連絡先ディレクトリでなければならないことを指定する＄ＧｒｏｏｖｅＮｅｔ及びディレクトリがアイデンティティと関連付けられた管理ドメインのための連絡先ディレクトリでなければならないことを指定する＄ＭａｎａｇｅｍｅｎｔＤｏｍａｉｎなどの複数の値を有することがある。
ｄｉｒｅｃｔｏｒｙ＿ｌｉｓｔｉｎｇ＿ｖａｌｕｅ属性の値は、連絡先リスティングが発行されるかどうかをユーザが決定することを示す「０」となる場合がある。代替値は連絡先リスティングが常に発行される必要があることを指定する「１」、及び連絡先リスティングを決して発行してはならないことを指定する「２」を含む。
ＤｅｆａｕｌｔＴｅｍｐｌａｔｅＣｏｍｐｏｎｅｎｔＲｅｓｏｕｒｃｅＵＲＬ属性の値は、共用空間テンプレートの構成要素リソースＵＲＬである。ＡｔｔａｃｈｍｅｎｔＲｅｓｔｒｉｃｔｉｏｎ要素は、複数の値を有することがある属性ＡｌｌｏｗＯｎｌｙを有する。これらの値は、添付リストが排除リストであり、リスト上のファイル型が許可されていないことを示す値「０」つまり「偽」を含む。代わりに、属性は、添付リストが包含リストであり、リスト上の型だけが許可されていることを示す値「１」または「真」を有することがある。ｓｉｚｅ＿ｉｎ＿ｋｂ属性の値はキロバイト単位でファイルの最大数値サイズを指定する。ｌｉｓｔ＿ｆｉｌｅ＿ｅｘｔ属性の値は、例えば、「ｅｘｅ」、「ｖｂ」、または「ｄｌｌ」などの許可されているファイル拡張子の区切られたリストである。
クライアントが方針オブジェクト（あるいは、通常は管理オブジェクト）を受け取ると、クライアントは最初に方針オブジェクトがその管理ドメインによって署名されていることを検証する。（構成要素ダウンロードなどの）デバイス全体での方針は、デバイスの管理ドメインの公開鍵を使用して検証される。アイデンティティ全体の方針は、アイデンティティの管理ドメインの公開鍵を使用して検証される。管理オブジェクトに署名するために使用される鍵の組はユーザ証明書及び相互ドメイン証明書に署名するために使用される鍵の組とは別個である。管理ドメインは、以下の全部で４つの鍵の組を有する。つまり、（１）管理オブジェクトに署名するための鍵の組、（２）「有線での（ｏｖｅｒ−ｔｈｅ−ｗｉｒｅ）」クライアント／サーバ通信を保護する際に使用される鍵トランスポートの鍵の組、（３）証明書に署名するための鍵の組、及び（４）データ回復及びパスフレーズリセットのための鍵符号化のための鍵の組である。
第1の管理ドメイン公開鍵はアイデンティティと管理ドメインの間の「起動プロトコル」の間にクライアントに安全に配布される。第２の公開鍵も「起動プロトコル」中に送信されるが、第1の鍵で署名された証明書の中にカプセル化されている。第３の公開鍵と第４の公開鍵は、その後、それぞれ「証明／認証」方針及び「データ回復」方針の中で送信される。これらの後者の２つの鍵は、それらが方針にパッケージ化されているため、第１の（方針署名）公開鍵と共に署名される。したがって、第１の公開鍵にアクセスできる管理者が実質的には最高の権威者である。
アイデンティティが、セキュリティ方針が実施されている別の連絡先との通信を試みる時に実行されるプロセスは、図１２Ａから図１２Ｃが共に置かれる時に形成されるフローチャートに図示されている。このプロセスはステップ１２００で開始し、アイデンティティが、アイデンティティが通信を試みるすべての連絡先のリスト（「ＣＬｉｓｔ」と呼ばれる）を作成するステップ１２０２に進む。方針が「未認証の場合警告」または「未証明の場合制限」に設定されているかどうかの決定がステップ１２０４で行われる。ステップ１２０４では、方針が「未認証の場合警告」または「未証明の場合制限」に設定されていると判断された場合、クライアントはＣＬｉｓｔの中の連絡先の（「ＵｎＡｕｔｈＬｉｓｔ」と呼ばれる）すべての未認証連絡先と未証明連絡先のリストを作成する。代わりにステップ１２０４では、方針が警告または制限なしに通信を可能とするために設定されていると判断された場合、プロセスは進み、ステップ１２０８で終了する。
ＵｎＡｕｔｈＬｉｓｔを作成するために、クライアントはＣＬｉｓｔ内の連絡先のすべてを列挙し、処理する。特にプロセスは、全連絡先が処理されたかどうかが判断されるステップ１２０６に進む。すべての連絡先が処理された場合、プロセスはステップ１２０８で終了し、結果として生じるＵｎＡｕｔｈＬｉｓｔは、前述されたように実施される方針に従って通信を制御するために使用される。
代わりに、すべての連絡先が処理されている訳ではないとステップ１２０６で判断されると、次にステップ１２１０でＣＬｉｓｔの中の次の連絡先が選択される。ステップ１２１２では、「警告」を行うために方針が設定され、連絡先がユーザのアカウントの別のアイデンティティであるかどうかが決定される。そうである場合には、連絡先はアカウントのアイデンティティの１つであり、プロセスはすべての連絡先が処理されたかどうかを判断するためにステップ１２０６に戻ることによりＣｌｉｓｔ連絡先の残りで続行される。代わりに、ステップ１２１２において、連絡先がアカウントのアイデンティティの１つではないと判断された場合には、プロセスは、方針が「警告する」ために設定され、連絡先が手動で認証されたかどうかの判断が下されるステップ１２２６に、オフページコネクタ１２１６と１２２２を介して進む。連絡先の手動認証ビットを調べることによって、連絡先が手動で認証されたかどうかの判断を下すことができる。連絡先がすでに認証されている場合にはプロセスはオフページコネクタ１２２０と１２１４を介してステップ１２０６に戻り、ＣＬｉｓｔ上の追加の連絡先がまだ処理されていないかどうかを判断する。
ステップ１２２６で連絡先がすでに認証されていなかったと判断された場合には、プロセスはＩｓＣｅｒｔｉｆｉｅｄＣｏｎｔａｃｔ変数の値がＦＡＬＳＥ（偽）に設定されるステップ１２２８に進む。プロセスはアイデンティティに関連付けられているすべての相互ドメイン証明方針を通して列挙する。特にステップ１２３０では、追加の相互ドメイン方針がまだ調べられていないかどうかが判断される。追加の方針がまだ調べられていない場合には、ステップ１２３２では、次の方針が検査のために選択される。
ステップ１２３４では、連絡先の管理ドメインが方針で証明されたドメインに一致するかどうかが判断される。一致しない場合、プロセスはステップ１２３０に戻り、更に多くの方針がまだ調べられていないのかどうかを判断する。ステップ１２３４で連絡先の管理ドメインが方針で証明されたドメインに一致すると判断されると、プロセスはオフページコネクタ１２３８と１２４６を介して、連絡先の証明書上の署名が相互証明されたドメインの公開鍵で検証され、最小証明書チェーンの有効期限が計算されるステップ１２５２に進む。
次にステップ１２５４では、シグナチャが最小有効期限を検証しないのか、あるいは現在の日付が最小有効期限を越えているのかの判断が下される。そうである場合には、プロセスはオフページコネクタ１２４４と１２３６を介して、プロセスが相互ドメイン方針の残りで続行されるステップ１２３０に戻る。
そうではない場合には、プロセスは、変数ＩｓＣｅｒｔｉｆｉｅｄＣｏｎｔａｃｔが、連絡先が証明されていることを示すＴＲＵＥに設定されるステップ１２５６に進む。次に、プロセスはＩｓＣｅｒｔｉｆｉｅｄＣｏｎｔａｃｔの値が、連絡先が証明されていいないことを示すＦＡＬＳＥかどうかが判断されるステップ１２５８に進む。プロセスは、ステップ１２３０で判断されたようにすべての方針が調べられた後に、オフページコネクタ１２４０と１２４８を介してステップ１２５８にも到達する。
連絡先がステップ１２５８で判断されたように証明されていない場合には、連絡先はステップ１２６０で未認証及び未証明連絡先リスト（ＵｎＡｕｔｈＬｉｓｔ）に追加され、プロセスはオフページコネクタ１２５０と１２４２、及びコネクタ１２２４と１２１８を介してステップ１２０６に戻り、すべての連絡先が処理されたかどうかを判断する。代わりに、ステップ１２５８で連絡先が証明されていると判断されると、プロセスはステップ１２６０を省略し、直接ステップ１２０６に進み、追加の連絡先がまだ処理されていないかどうかを判断する。
すべての連絡先がステップ１２０６で判断されたように処理された後には、未認証連絡先リスト（ＵｎＡｕｔｈＬｉｓｔ）が選択されたセキュリティと共に使用され、未認証且つ未証明のユーザとの通信が試される場合にユーザに警告する、あるいは必要に応じて通信を制限するかのどちらかを行う。
前述された実施態様のソフトウェアインプリメンテーションは、例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭメモリまたは固定ディスクなどのコンピュータ読み取り可能媒体などの有形媒体に固定される、またはモデムや他のインタフェースデバイスを介して媒体上をコンピュータシステムに送信可能な一連のコンピュータ命令を備えてよい。媒体は、光通信回線またはアナログ通信回線を含むがそれらに制限されない有形の媒体である場合があるか、あるいはマイクロ波技法、赤外線技法、または他の伝送技法を含むがそれらに制限されない無線技法で実現されてよい。それはインターネットであってもよい。一連のコンピュータ命令は、本発明に関してここに前述された機能性のすべてまたは一部分を具現する。当業者は、このようなコンピュータ命令が多くのコンピュータアーキテクチャまたはオペレーティングシステムと使用するために多くのプログラミング言語で作成できることを理解するだろう。更に、このような命令は、半導体素子、磁気デバイス、光学素子または他のメモリ装置を含むがそれらに制限されない現在または将来の任意のメモリ技術を使用して記憶されてよいか、あるいは光伝送技術、赤外線伝送技術、マイクロ波伝送技術または他の伝送技術を含むがそれらに制限されない現在または将来の任意の通信技術を使用して伝送されてよい。このようなコンピュータプログラム製品が、例えばシステムＲＯＭまたは固定ディスク上などコンピュータシステムにプレインストールされた収縮包装されたソフトウェアなどの添付の印刷文書または電子文書と共にリムーバブル媒体として配布されるか、あるいはインターネットやワールドワイドウェブなどのネットワーク上のサーバまたは電子掲示板から配布されてよいと考えられる。
本発明の例示的な実施態様が開示されてきたが、本発明の精神及び範囲を逸脱することなく本発明の利点のいくつかを達成する多様な変更及び変形を加えることができることは当業者にとって明らかとなるであろう。例えば、他のインプリメンテーションにおいて、示されているものとは異なるプロトコル及び変換が実行されてよいことが適度に技術にたけた人にとって明らかになるだろう。本発明の概念に対する他の変形だけではなく特定のプロセスフロー、及び描かれているステップの順序などの他の態様も添付の請求項によってカバーされることが意図されている。
図１Ａは、各コラボレーティブコンピュータがトランシーバ及びデータベースを含む例示的なコラボレーティブシステムのブロック概略図である。図１Ｂは、共用空間記憶部、アカウントメタデータ記憶部、及び連絡先記憶部を含むコラボレーションシステムデータベースのブロック概略図である。 図２は、連絡先を手動で認証するために使用される表示画面の画面の場面である。 図３は、詳細な連絡先情報及び認証インジケータを描く連絡先ディスプレイの画面の場面である。 図４は、連絡先認証ステータス及び表示名一致を示すために表示できる一式の例示的なアイコンを示す。 図５Ａは、表示名一致を描く連絡先名前表示の画面の場面である。図５Ｂは、表示名の一致を強調表示するために名前一致アイコンの使用を描く連絡先名の表示の画面場面の一部である。図５Ｃは、表示名一致を解決するためのエイリアスの使用を描く連絡先名表示の画面の場面の一部である。 図６Ａは、図６Ｂと図６Ｃと共に置かれた時に、連絡先表示名と共にいつ名前一致アイコンが表示されなければならないのかを決定するための例示的なプロセスのステップを示すフローチャートを形成する。図６Ｂは、図６Ａと図６Ｃと共に置かれた時に、連絡先表示名と共にいつ名前一致アイコンが表示されなければならないのかを決定するための例示的なプロセスのステップを示すフローチャートを形成する。図６Ｃは、図６Ａと図６Ｂと共に置かれた時に、連絡先表示名と共にいつ名前一致アイコンが表示されなければならないのかを決定するための例示的なプロセスのステップを示すフローチャートを形成する。 図７は、表示名の一致を解決するために使用される画面表示の画面の場面である。 図８は、エイリアスを表示名に割り当てるために使用されるダイアログボックスの画面の場面である。 図９は、表示されたエイリアス及び連絡先認証インジケータを示す連絡先名リスティングの画面の場面である。 図１０は、管理者が１つまたは複数のアイデンティティのためにセキュリティ方針を設定できるようにする表示画面の画面の場面である。 図１１は、ユーザがそのユーザに適用するセキュリティ方針を設定及び検討できるようにする表示画面の画面の場面である。 図１２Ａは、図１２Ｂと図１２Ｃと共に置かれた時に、認証されていなく及び証明されていない連絡先のリストをコンパイルするための例示的なプロセスのステップを示すフローチャートを形成する。図１２Ｂは、図１２Ａと図１２Ｃと共に置かれた時に、認証されていなく及び証明されていない連絡先のリストをコンパイルするための例示的なプロセスのステップを示すフローチャートを形成する。図１２Ｃは、図１２Ａと図１２Ｂと共に置かれた時に、認証されていなく及び証明されていない連絡先のリストをコンパイルするための例示的なプロセスのステップを示すフローチャートを形成する。

Claims (42)

  1. ユーザがそれぞれが関連付けられた表示名を備えた複数のアイデンティティを有することがあるピアツーピアコラボレーションシステムにおいて連絡先認証を管理、表示するための方法であって、
    （ａ）グラフィックユーザインタフェース上に、異なるアイデンティティと関連付けられ、同一（ｅｑｕｉｖａｌｅｎｔ）である第1の表示名と第２の表示名の隣に名前一致インジケータを表示することと、
    （ｂ）名前一致インジケータがその隣に表示された表示名の選択に応えて、該選択された表示名と同一であるすべての表示名を表示することと、
    （ｃ）２つの一致する表示名の間の名前の一致を解決するための機構を提供すること、
    を備えることを特徴とする方法。
  2. ステップ（ａ）が、各表示名からクリーンネーム（ｃｌｅａｎ ｎａｍｅ）を計算することと、２つの表示名のクリーンネームを比較し、該２つの表示名が同一であるかどうかを判断することを備えることを特徴とする請求項１の方法。
  3. 各連絡先アイデンティティがそれと関連付けられた認証レベルを有し、ステップ（ａ）が、
    （ａ１）同一であるすべての表示名の認証レベルを調べることと、
    （ａ２）ステップ（ａ１）での調査に基づき選択された表示名の隣に名前一致インジケータを表示すること、
    を備えることを特徴とする請求項１の方法。
  4. ステップ（ａ２）が、その認証レベルが（１）同一の表示名が付いたすべての連絡先アイデンティティの最高の認証／証明レベル未満であるか、あるいは（２）同一の表示名が付いた少なくとも２つの連絡先アイデンティティが等しい認証レベルを有する最高の認証／証明ベルに等しい連絡先アイデンティティと関連付けられた各表示名の隣に名前一致インジケータを表示することを備えることを特徴とする請求項３の方法。
  5. （ｄ）ある連絡先との通信に関して、その連絡先の認証レベルに基づいてコラボレーションシステムの動作を決定するセキュリティ方針を提供することを更に備えることを特徴とする請求項３の方法。
  6. ステップ（ｄ）が、コラボレーションシステムのユーザがセキュリティ方針を決定できるようにすることを備えることを特徴とする請求項５の方法。
  7. ステップ（ｄ）が、システム管理者がセキュリティ方針を決定できるようにすることを備えることを特徴とする請求項５の方法。
  8. （ｅ）ユーザに、そのユーザが所定の認証レベルを有する連絡先と通信しようと試みる時にセキュリティ方針に基づいて警告すること、
    を更に備えることを特徴とする請求項５の方法。
  9. （ｅ）他のユーザが所定の認証レベルを有しているときにセキュリティ方針に基づいてユーザが別のユーザと通信するのを妨げること、
    を更に備えることを特徴とする請求項５の方法。
  10. ステップ（ｂ）が、そこに表示されている選択された表示名と同一であるすべての表示名を有するダイアログボックスを表示することを備えることを特徴とする請求項１の方法。
  11. ステップ（ｃ）が、第1の表示名と第２の表示名の１つにエイリアスを割り当てることを備え、そのエイリアスが第1の表示名と第２の表示名のどちらにも同一ではなく、そのエイリアスが１つの表示名を置換することを特徴とする請求項１の方法。
  12. （ｄ）別の表示名と同一ではない表示名の隣に認証インジケータを表示し、その認証インジケータが、関連付けられた連絡先の認証レベルを示すこと、
    を更に備えることを特徴とする請求項１の方法。
  13. 各連絡先が所定数の認証レベルの１つを有し、表示される認証インジケータが認証レベルの１つに対して一意であることを特徴とする請求項１２の方法。
  14. ユーザが未認証及び未証明のレベルを含む複数の認証及び証明レベルを有することがあるピアツーピアコラボレーションシステムで連絡先認証を管理、表示するための方法であって、
    （ａ）認証及び証明レベルに基づいてコラボレーションシステムの動作を制御するセキュリティ方針を設定することと、
    （ｂ）ユーザによる１つまたは複数の連絡先と通信しようとする試みに応えて、ユーザが通信を試みている未認証及び未証明の連絡先のリストをコンパイルすることと、
    （ｃ）セキュリティ方針に基づいて、ユーザに警告し、ユーザが未認証及び未証明のレベルの連絡先と通信するのを制限すること、
    を備えることを特徴とする方法。
  15. ステップ（ａ）が、ユーザがそのユーザに適用されるセキュリティ方針を設定することを備えることを特徴とする請求項１４の方法。
  16. ステップ（ａ）が、システム管理者がユーザに適用されるセキュリティ方針を設定することを備えることを特徴とする請求項１４の方法。
  17. ステップ（ｃ）が、セキュリティ方針が警告するように設定され、ユーザが未認証及び未証明の連絡先との通信を試みる時にユーザに警告することを備えることを特徴とする請求項１４の方法。
  18. ステップ（ｃ）が、セキュリティ方針が制限するように設定され、ユーザが未証明の連絡先との通信を試みる時に、ユーザが未証明の連絡先と通信するのを妨げることを備えることを特徴とする請求項１４の方法。
  19. ステップ（ｃ）が、セキュリティ方針が警告せずに許可するように設定され、ユーザが未認証及び未証明の連絡先との通信を試みる時に、ユーザが未認証及び未証明の連絡先と通信できるようにすることを備えることを特徴とする請求項１４の方法。
  20. ステップ（ｂ）が、
    （ｂ１）ユーザが通信を試みる連絡先の連絡先リストをコンパイルすることと、
    （ｂ２）認証されていない連絡先を決定するために連絡先リストをチェックすることと、
    （ｂ３）証明方針が任意の認証されていない連絡先に適用できるかどうかを判断するために未認証の連絡先をチェックすることと、
    （ｂ４）証明方針がその連絡先に適用できないときに、未認証及び未証明の連絡先のリストに未認証の連絡先を載せること、
    を備えることを特徴とする請求項１４の方法。
  21. ユーザがそれぞれに関連付けられた表示名が付いた複数のアイデンティティを有することがあるピアツーピアコラボレーションシステムで連絡先認証を管理、表示するための装置であって、
    グラフィックユーザインタフェース上に、異なる連絡先アイデンティティと関連付けられ、同一である第1の表示名と第２の表示名の隣に名前一致インジケータを表示するための手段と、
    その隣に名前一致インジケータが表示された表示名の選択に応えて、該選択された表示名と同一であるすべての表示名を表示するための手段と、
    ２つの一致する表示名の間で名前一致を解決する機構と、
    を備えることを特徴とする装置。
  22. 名前一致インジケータを表示するための手段が、各表示名からクリーンネームを計算する機構と、該２つの表示名が同一であるかどうかを判断するために、２つの表示名のクリーンネームを比較するコンパレータとを備えることを特徴とする請求項２１の装置。
  23. 各連絡先アイデンティティがそれと関連付けられた認証レベルを有し、名前一致インジケータを表示するための手段が、
    同一であるすべての表示名の認証レベルを調べるための手段と、
    認証レベルを調べるための手段によって同一であると判断された表示名に基づいて選択された表示名の隣に名前一致インジケータを表示するための手段と、
    を備えることを特徴とする請求項２１の装置。
  24. 選択された表示名の隣に名前一致インジケータを表示するための手段が、その認証レベルが（１）同一の表示名が付いたすべての連絡先アイデンティティの最高の認証／証明レベル未満であるか、あるいは（２）同一の表示名が付いた少なくとも１つの連絡先アイデンティティが等しい認証レベルを有する最高の認証／証明レベルに等しい連絡先アイデンティティと関連付けられた各表示名の隣に名前一致インジケータを表示するための手段を備えることを特徴とする請求項２３の装置。
  25. ある連絡先との通信に関してその連絡先の認証レベルに基づいてコラボレーションシステムの動作を決定するセキュリティ方針を提供する機構を更に備えることを特徴とする請求項２３の装置。
  26. セキュリティ方針を提供する機構が、コラボレーションシステムのユーザがセキュリティ方針を決定できるようにする機構を備えることを特徴とする請求項２５の装置。
  27. セキュリティ方針を提供する機構が、システム管理者がセキュリティ方針を決定できるようにする機構を備えることを特徴とする請求項２５の装置。
  28. ユーザに、そのユーザが所定の認証レベルを有する連絡先との通信を試みる時にセキュリティ方針に基づいて警告する機構と、
    を更に備えることを特徴とする請求項２５の装置。
  29. 他のユーザが所定の認証レベルを有するときに、ユーザが他のユーザと連絡するのをセキュリティ方針に基づいて妨げる機構を更に備えることを特徴とする請求項２５の装置。
  30. 選択された表示名と同一であるすべての表示名を表示するための手段が、そこに表示されている選択された表示名と同一であるすべての表示名を有するダイアログボックスを表示するための手段を備えることを特徴とする請求項２１の装置。
  31. 名前一致を解決する機構が、第1の表示名と第２の表示名の１つにエイリアスを割り当てるための機構を備え、そのエイリアスが第1の表示名と第２の表示名のどちらにも同一ではなく、そのエイリアスが１つの表示名を置換することを特徴とする請求項２１の装置。
  32. 別の表示名と同一ではない表示名の隣に、関連付けられた連絡先の認証レベルを表示する認証インジケータを表示する機構を更に備えることを特徴とする請求項２１の装置。
  33. 各連絡先が所定数の認証レベルの１つを有することができ、表示された認証インジケータが認証レベルの１つに対して一意であることを特徴とする請求項３２の装置。
  34. ユーザが未認証及び未証明レベルを含む複数の認証及び証明レベルを有することがあるピアツーピアコラボレーションシステムにおいて連絡先認証を管理、表示するための装置であって、
    認証及び証明レベルに基づいてコラボレーションシステムの動作を制御するセキュリティ方針を設定する機構と、
    １つまたは複数の連絡先と通信しようとするユーザによる試みに応えて、ユーザが通信を試みている未認証及び未証明連絡先のリストをコンパイルする手段と、
    セキュリティ方針に基づいて、ユーザに警告し、ユーザが未認証及び未証明レベルの連絡先と通信することを制限する機構と、
    を備えることを特徴とする装置。
  35. セキュリティ方針を設定する機構が、ユーザがそのユーザに適用されるセキュリティ方針を設定できるようにする機構を備えることを特徴とする請求項３４の装置。
  36. セキュリティ方針を設定する機構が、システム管理者がユーザに適用されるセキュリティ方針を設定できるようにする機構を備えることを特徴とする請求項３４の装置。
  37. ユーザに警告し、ユーザを制限する機構が、セキュリティ方針が警告するように設定され、ユーザが未認証及び未証明の連絡先との通信を試みる時にユーザに警告する機構を備えることを特徴とする請求項３４の装置。
  38. ユーザに警告し、ユーザを制限する機構が、セキュリティ方針が制限するように設定され、ユーザが未証明の連絡先との通信を試みる時にユーザが未証明の連絡先と通信するのを妨げる機構を備えることを特徴とする請求項３４の装置。
  39. ユーザに警告し、ユーザを制限する機構が、セキュリティ方針が、警告せずに許すように設定され、ユーザが未認証及び未証明の連絡先との通信を試みる時にユーザが未認証及び未証明の連絡先と通信できるようにする機構を備えることを特徴とする請求項３４の装置。
  40. 未認証及び未証明の連絡先のリストをコンパイルするための手段が、
    ユーザが通信を試みる連絡先の連絡先リストをコンパイルするための手段と、
    認証されていない連絡先を決定するために連絡先リストをチェックするための手段と、
    証明方針が未認証の連絡先に適用できるかどうかを判断するために未認証の連絡先をチェックするための手段と、
    証明方針がその連絡先に適用できないときに未認証及び未証明の連絡先のリストに未認証の連絡先を載せるための手段と、
    を備えることを特徴とする請求項３４の装置。
  41. ユーザがそれぞれに関連付けられた表示名が付いた複数のアイデンティティを有することがあるピアツーピアコラボレーションシステムで連絡先認証を管理、表示するためのコンピュータプログラム製品であって、コンピュータによる読み取りが可能なプログラムコードをその上に有するコンピュータで使用可能な媒体を備えることを特徴とし、
    異なる連絡先アイデンティティと関連付けられ、同一である第1の表示名と第２の表示名の隣に名前一致インジケータをグラフィックユーザインタフェースに表示するためのプログラムコードと、
    名前一致インジケータがそれの隣に表示された表示名の選択に応えて、選択された表示名と同一であるすべての表示名を表示できるように動作可能なプログラムコードと、
    ２つの一致する表示名間の名前の一致を解決するための機構を提供するプログラムコードと、
    を含むことを特徴とするコンピュータプログラム製品。
  42. ユーザが未認証及び未証明のレベルを含む複数の認証及び証明レベルを有することがあるピアツーピアコラボレーションシステム内で連絡先認証を管理、表示するためのコンピュータプログラム製品であって、コンピュータによる読み取りが可能なプログラムコードをその上に有するコンピュータで使用可能な媒体を備えることを特徴とし、
    認証及び証明レベルに基づいてコラボレーションシステムの動作を制御するセキュリティ方針を設定するためのプログラムコードと、
    １つまたは複数の連絡先と通信しようとするユーザによる試みに応えて、ユーザが通信を試みている未認証及び未証明の連絡先のリストをコンパイルできるように動作可能なプログラムコードと、
    セキュリティ方針に基づいて、ユーザに警告し、ユーザが未認証及び未証明のレベルの連絡先と通信するのを制限するためのプログラムコードと、
    を含むことを特徴とするコンピュータプログラム製品。
JP2004221235A 2003-07-31 2004-07-29 ピアツーピアコラボレーションシステムにおいて連絡先認証を管理、表示するための方法及び装置 Expired - Fee Related JP4976646B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/631,206 US7624421B2 (en) 2003-07-31 2003-07-31 Method and apparatus for managing and displaying contact authentication in a peer-to-peer collaboration system
US10/631206 2003-07-31

Publications (3)

Publication Number Publication Date
JP2005327234A true JP2005327234A (ja) 2005-11-24
JP2005327234A5 JP2005327234A5 (ja) 2007-08-30
JP4976646B2 JP4976646B2 (ja) 2012-07-18

Family

ID=34135540

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004221235A Expired - Fee Related JP4976646B2 (ja) 2003-07-31 2004-07-29 ピアツーピアコラボレーションシステムにおいて連絡先認証を管理、表示するための方法及び装置

Country Status (4)

Country Link
US (1) US7624421B2 (ja)
EP (1) EP1513314A3 (ja)
JP (1) JP4976646B2 (ja)
CA (1) CA2473062A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008282388A (ja) * 2007-04-10 2008-11-20 Symantec Corp 単一インターフェースを通してデジタルアイデンティティを管理する方法及び装置
KR20170021643A (ko) * 2015-08-18 2017-02-28 삼성전자주식회사 전자 장치의 연락처 관리 방법 및 그 전자 장치
JP2021509746A (ja) * 2018-02-12 2021-04-01 スラック テクノロジーズ， インコーポレイテッド グループベース通信システムにおけるグループベースオブジェクトに選択的に許可を付与する方法、装置、及びコンピュータプログラム製品

Families Citing this family (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7770204B2 (en) * 2003-09-30 2010-08-03 Novell, Inc. Techniques for securing electronic identities
US20050091595A1 (en) * 2003-10-24 2005-04-28 Microsoft Corporation Group shared spaces
US7734708B1 (en) * 2003-12-22 2010-06-08 Aol Inc. Enabling identification of online identities between different messaging services
EP1686766B1 (en) * 2005-01-28 2007-06-06 Research In Motion Limited Automated integration of content from multiple information stores using a mobile communication device
US20060200374A1 (en) * 2005-03-01 2006-09-07 Yoram Nelken Automatic scheduling method and apparatus
US7908325B1 (en) * 2005-06-20 2011-03-15 Oracle America, Inc. System and method for event-based collaboration
US8832466B1 (en) * 2006-01-27 2014-09-09 Trustwave Holdings, Inc. Methods for augmentation and interpretation of data objects
US7783018B1 (en) * 2006-06-24 2010-08-24 Goldberg Mark S Directory display and configurable entry system
US20080005558A1 (en) * 2006-06-29 2008-01-03 Battelle Memorial Institute Methods and apparatuses for authentication and validation of computer-processable communications
US8976008B2 (en) 2006-08-24 2015-03-10 Privacydatasystems, Llc Cross-domain collaborative systems and methods
US8266443B2 (en) * 2006-08-24 2012-09-11 Privacydatasystems, Llc Systems and methods for secure and authentic electronic collaboration
US8850209B2 (en) * 2006-09-12 2014-09-30 Microsoft Corporation Schema signing
US8095531B2 (en) 2006-10-03 2012-01-10 Salesforce.Com, Inc. Methods and systems for controlling access to custom objects in a database
EP1921817A1 (en) * 2006-11-09 2008-05-14 Thomson Licensing Methods and a device for associating a first device with a second device
US20080148368A1 (en) * 2006-12-14 2008-06-19 Mary Ellen Zurko Secure extranet access to collaborative activities in a collaborative computing environment
EP1993267B1 (en) * 2007-05-16 2013-01-02 Telnic Limited Contact information retrieval system and communication system using the same
CA2590989C (en) * 2007-06-05 2014-02-11 Diversinet Corp. Protocol and method for client-server mutual authentication using event-based otp
US20080313278A1 (en) * 2007-06-17 2008-12-18 Linqee Ltd Method and apparatus for sharing videos
US8782527B2 (en) 2007-06-27 2014-07-15 Microsoft Corp. Collaborative phone-based file exchange
US8150820B1 (en) 2007-10-04 2012-04-03 Adobe Systems Incorporated Mechanism for visible users and groups
US9177313B1 (en) * 2007-10-18 2015-11-03 Jpmorgan Chase Bank, N.A. System and method for issuing, circulating and trading financial instruments with smart features
US9398046B2 (en) * 2008-03-06 2016-07-19 Qualcomm Incorporated Image-based man-in-the-middle protection in numeric comparison association models
US8200819B2 (en) * 2008-03-14 2012-06-12 Industrial Technology Research Institute Method and apparatuses for network society associating
US8850544B1 (en) * 2008-04-23 2014-09-30 Ravi Ganesan User centered privacy built on MashSSL
US8434010B2 (en) 2009-02-12 2013-04-30 International Business Machines Corporation Standardized visual indicators in electronic media
WO2011021277A1 (ja) * 2009-08-18 2011-02-24 富士通株式会社 情報管理装置、情報管理方法および情報管理プログラム
KR20110089650A (ko) * 2010-02-01 2011-08-09 삼성전자주식회사 호스트 장치, 화상형성장치 및 보안설정 관리방법
US8380160B2 (en) * 2010-03-29 2013-02-19 Motorola Solutions, Inc. Method and apparatus for enhanced safety in a public safety communication system
US9674635B2 (en) * 2010-03-29 2017-06-06 Motorola Solutions, Inc. Method and apparatus for distribution of applications to a plurality of communication devices for an expanded operating mode
US8504090B2 (en) * 2010-03-29 2013-08-06 Motorola Solutions, Inc. Enhanced public safety communication system
US8874526B2 (en) 2010-03-31 2014-10-28 Cloudera, Inc. Dynamically processing an event using an extensible data model
US9081888B2 (en) 2010-03-31 2015-07-14 Cloudera, Inc. Collecting and aggregating log data with fault tolerance
US9082127B2 (en) 2010-03-31 2015-07-14 Cloudera, Inc. Collecting and aggregating datasets for analysis
US9356916B2 (en) 2010-04-30 2016-05-31 T-Central, Inc. System and method to use a cloud-based platform supported by an API to authenticate remote users and to provide PKI- and PMI-based distributed locking of content and distributed unlocking of protected content
US20120016999A1 (en) * 2010-07-14 2012-01-19 Sap Ag Context for Sharing Data Objects
US9799004B2 (en) 2010-07-30 2017-10-24 Avaya Inc. System and method for multi-model, context-aware visualization, notification, aggregation and formation
US9240965B2 (en) 2010-08-31 2016-01-19 Sap Se Methods and systems for business interaction monitoring for networked business process
US9235586B2 (en) * 2010-09-13 2016-01-12 Microsoft Technology Licensing, Llc Reputation checking obtained files
EP2625820B1 (en) * 2010-10-08 2021-06-02 Brian Lee Moffat Private data sharing system
US20120246187A1 (en) 2011-03-22 2012-09-27 International Business Machines Corporation Automatic correction of contact list errors in a collaboration system
MY155584A (en) * 2011-09-26 2015-11-03 Mimos Berhad A system and method for performing ad-hoc screen switching & sharing
US9858399B2 (en) * 2011-09-27 2018-01-02 Rakuten, Inc. Group definition management system
US9515999B2 (en) * 2011-12-21 2016-12-06 Ssh Communications Security Oyj Automated access, key, certificate, and credential management
JP5197843B1 (ja) * 2011-12-27 2013-05-15 株式会社東芝 認証連携システムおよびｉｄプロバイダ装置
US9338008B1 (en) * 2012-04-02 2016-05-10 Cloudera, Inc. System and method for secure release of secret information over a network
US9342557B2 (en) 2013-03-13 2016-05-17 Cloudera, Inc. Low latency query engine for Apache Hadoop
US9230077B2 (en) * 2013-03-15 2016-01-05 International Business Machines Corporation Alias-based social media identity verification
US9934382B2 (en) 2013-10-28 2018-04-03 Cloudera, Inc. Virtual machine image encryption
US9231977B2 (en) 2013-12-23 2016-01-05 Nokia Technologies Oy Method and apparatus for providing collaborative privacy policies for a shared device
WO2015163736A1 (en) * 2014-04-25 2015-10-29 Samsung Electronics Co., Ltd. Methods of providing social network service and server performing the same
US9998477B2 (en) * 2015-03-31 2018-06-12 Comcast Cable Communications, Llc Digital content access control
US10097557B2 (en) * 2015-10-01 2018-10-09 Lam Research Corporation Virtual collaboration systems and methods
US10853326B2 (en) * 2017-10-17 2020-12-01 Dropbox, Inc. Sharing collections with external teams
US10250383B1 (en) * 2018-03-20 2019-04-02 Mocana Corporation Dynamic domain key exchange for authenticated device to device communications
US10728361B2 (en) * 2018-05-29 2020-07-28 Cisco Technology, Inc. System for association of customer information across subscribers
US11627132B2 (en) * 2018-06-13 2023-04-11 International Business Machines Corporation Key-based cross domain registration and authorization
US11595217B2 (en) 2018-12-06 2023-02-28 Digicert, Inc. System and method for zero touch provisioning of IoT devices
US11165786B2 (en) * 2018-12-18 2021-11-02 International Business Machines Corporation Remote assistance controller that provides control over what a remote assistor can access
US11804970B2 (en) * 2021-10-15 2023-10-31 Lenovo Global Technology (United States) Inc. Baseboard management controller group administration
US20230205914A1 (en) * 2021-12-27 2023-06-29 Mordecai Barkan Hands free access management and credential protection

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870744A (en) * 1997-06-30 1999-02-09 Intel Corporation Virtual people networking
US6092201A (en) * 1997-10-24 2000-07-18 Entrust Technologies Method and apparatus for extending secure communication operations via a shared list
US7089298B2 (en) * 2001-08-20 2006-08-08 Nokia Corporation Naming distribution method for ad hoc networks
US7068789B2 (en) * 2001-09-19 2006-06-27 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) group security infrastructure and method
US7493363B2 (en) * 2001-09-19 2009-02-17 Microsoft Corporation Peer-to-peer group management and method for maintaining peer-to-peer graphs
US7430747B2 (en) * 2002-12-04 2008-09-30 Microsoft Corporation Peer-to peer graphing interfaces and methods
US7596625B2 (en) * 2003-01-27 2009-09-29 Microsoft Corporation Peer-to-peer grouping interfaces and methods
US7496648B2 (en) * 2003-10-23 2009-02-24 Microsoft Corporation Managed peer name resolution protocol (PNRP) interfaces for peer to peer networking
EP1633079A1 (en) * 2004-09-01 2006-03-08 Deutsche Thomson-Brandt Gmbh Method for managing elements of a peer-group
US7571313B2 (en) * 2004-12-28 2009-08-04 Motorola, Inc. Authentication for Ad Hoc network setup

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CSNB200200512001, 吉田究, Ｇｒｏｏｖｅスターターガイド 第１版, 20011130, 第１版第１刷, ｐ．１５８−１６４, JP, 株式会社オーム社 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008282388A (ja) * 2007-04-10 2008-11-20 Symantec Corp 単一インターフェースを通してデジタルアイデンティティを管理する方法及び装置
KR20170021643A (ko) * 2015-08-18 2017-02-28 삼성전자주식회사 전자 장치의 연락처 관리 방법 및 그 전자 장치
KR102354729B1 (ko) * 2015-08-18 2022-01-25 삼성전자주식회사 전자 장치의 연락처 관리 방법 및 그 전자 장치
JP2021509746A (ja) * 2018-02-12 2021-04-01 スラック テクノロジーズ， インコーポレイテッド グループベース通信システムにおけるグループベースオブジェクトに選択的に許可を付与する方法、装置、及びコンピュータプログラム製品
JP2021082330A (ja) * 2018-02-12 2021-05-27 スラック テクノロジーズ， インコーポレイテッド グループベース通信システムにおけるグループベースオブジェクトに選択的に許可を付与する方法、装置、及びコンピュータプログラム製品
JP7160972B2 (ja) 2018-02-12 2022-10-25 スラック テクノロジーズ， エルエルシー グループベース通信システムにおけるグループベースオブジェクトに選択的に許可を付与する方法、装置、及びコンピュータプログラム製品

Also Published As

Publication number Publication date
US7624421B2 (en) 2009-11-24
US20090150968A1 (en) 2009-06-11
JP4976646B2 (ja) 2012-07-18
EP1513314A3 (en) 2012-05-16
EP1513314A2 (en) 2005-03-09
CA2473062A1 (en) 2005-01-31

Similar Documents

Publication Publication Date Title
JP4976646B2 (ja) ピアツーピアコラボレーションシステムにおいて連絡先認証を管理、表示するための方法及び装置
US7904720B2 (en) System and method for providing secure resource management
US8059818B2 (en) Accessing protected data on network storage from multiple devices
US7624269B2 (en) Secure messaging system with derived keys
US6092201A (en) Method and apparatus for extending secure communication operations via a shared list
US8788811B2 (en) Server-side key generation for non-token clients
JP2009514072A (ja) コンピュータ資源への安全なアクセスを提供する方法
US20070101400A1 (en) Method of providing secure access to computer resources
KR20200027921A (ko) 멀티-홉 변환 암호화를 통한 그룹들에 대한 직교 액세스 제어
JP2009044763A (ja) 識別ベースの暗号化システム
US7827407B2 (en) Scoped federations
JP2006514478A (ja) オンライン／オフライン復号システム
JP2018092446A (ja) 認証認可システム及び情報処理装置と認証認可方法とプログラム
AU2018340671A1 (en) Access to secured information
EP3785409B1 (en) Data message sharing
Spies Public key infrastructure
Pulls Privacy-Friendly cloud storage for the data track: an educational transparency tool
AlQallaf Blockchain-based digital identity management scheme for field connected IoT devices
Andersen Decentralized authorization with private delegation
EP3482546B1 (en) System for secure electronic message transmission
WO2002021793A2 (en) System and method for encrypted message interchange
Alrodhan Privacy and practicality of identity management systems
CN117319067A (zh) 一种基于数字证书的身份认证方法、系统及可读存储介质
Narasimman Arcana: Private tweets on a public microblog platform
Strauch Privacy in Social Networks

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070711

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070711

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20100218

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20100219

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101119

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110221

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110812

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111114

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111202

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120301

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120406

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120413

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150420

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees