管理サーバ装置
【課題】各ネットワークサービスの独立性を維持しつつ、かつ各々のサービスの有する知人関係を融通し合う。
【解決手段】複数のサービスサーバそれぞれは、利用者の認識票に他の利用者の認識票である他人認識票を関係付けて記憶し、また、認識票に複数のサービスサーバで利用者を一意に識別する識別情報にその識別情報毎に生成された暗号鍵を関連付けて記憶し、管理サーバは、利用者が利用するサービスサーバの識別子を暗号鍵による暗号化情報を格納するテーブルを有する。暗号化認識票サーバは、第１の認識票に関係付けて第１のサービスサーバに記憶されている他人認識票を受信し、他人認識票に関連する識別情報に関連付けて管理サーバ装置に記憶されている暗号化情報を復号化して、他人認識票の利用者が利用可能なサービスサーバを得て、第１の認識票に他人認識票を関連付けるべきかどうかが判断される。
【解決手段】複数のサービスサーバそれぞれは、利用者の認識票に他の利用者の認識票である他人認識票を関係付けて記憶し、また、認識票に複数のサービスサーバで利用者を一意に識別する識別情報にその識別情報毎に生成された暗号鍵を関連付けて記憶し、管理サーバは、利用者が利用するサービスサーバの識別子を暗号鍵による暗号化情報を格納するテーブルを有する。暗号化認識票サーバは、第１の認識票に関係付けて第１のサービスサーバに記憶されている他人認識票を受信し、他人認識票に関連する識別情報に関連付けて管理サーバ装置に記憶されている暗号化情報を復号化して、他人認識票の利用者が利用可能なサービスサーバを得て、第１の認識票に他人認識票を関連付けるべきかどうかが判断される。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明は、サーバが連携してオンラインサービスを提供する情報処理に関する。
【背景技術】
【０００２】
様々なインターネットサービスが、数多くの事業者によって提供されている。最もよく使われるインターネットサービスは電子メールである。電子メールは、インターネット上で利用者を一意に特定する認識票として電子メールアドレスを用い、知人同士のコミュニケーション手段を提供するサービスである。一方近年、各Ｗｅｂサービス内で利用者を一意に特定する認識票を利用して、Ｗｅｂサービスの利用者間でのコミュニケーション手段を提供するサービスが数多く出現している。ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）、チャット、ブログなどがその例として挙げられる（特許文献１）。
【０００３】
このような、コミュニケーション手段を提供するサービスでは、各利用者が該当サービス上での知人を管理するための、知人一覧の機能が提供されている。たとえば、電子メールクライアントソフトウェア、Ｗｅｂ上の電子メール、ＳＮＳ、チャット、ブログなどには、知人一覧を管理する機能がある。各利用者はこれを、知人一覧を用いて、知人を管理し、新たな他の利用者を追加することで、コミュニケーションの範囲を拡げる。
【０００４】
一方、インターネットサービスを提供する事業者にとっては、自らの提供するサービス内で利用者が増加するほど、また知人関係が密になるほど、サービスの利用が促進され、事業的観点から見たサービスの価値が高まる。このため、サービス事業者は、利用者間の知人関係の拡張を目指す動機がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許第7,069,308号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
このような背景のもとで、インターネット上の各種サービスの利用者、およびこれらのサービスを提供する事業者の双方に、次のような課題が顕在化している。
【０００７】
利用者にとっての問題は、利用するサービスが増え、また各サービスでの知人が増えることによって、知人の管理が面倒になるという問題である。たとえば、ある利用者が電子メール、ＳＮＳ、チャット、ブログの４つのサービスを使っており、かつ各々のサービスに２０人の知人がいたとする。これらの知人は各々のサービスに付随した知人リストによって別々に管理されている。しかも、知人の中にはこれら４つのサービスの中の複数を使っている人がおり、サービスごとに異なる認識票を有し、あるいは異なる名前を名乗っている場合が多い。このような状況で、この利用者が知人を統一的に管理することは難しい。
【０００８】
一方、インターネットサービスを提供する各事業者は、自らの提供するサービス内で知人関係を増やし、さらに他サービスの利用者を自らの提供するサービスの利用者になるように誘導したいという意図を持っている。このためには、各インターネットサービス事業者の有する利用者の認識票、属性情報、知人関係などを、他のインターネットサービス事業者と融通または共有しあうことで、利用者を増やし、知人関係を拡張することができるようになる。したがって、このような認識票、属性情報、知人関係などの融通を、容易に実現する方法が必要とされている。
【０００９】
このような課題の解決に向けて、様々な試みがなされている。ＳＮＳを含む各種Ｗｅｂサービスでは、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）へのアクセスを外部に許可することで、Ｗｅｂサービス間で認識票、属性情報、知人関係などの相互融通を目指している。また、ＯｐｅｎＩＤとして知られている技術により、異なるＳＮＳを含むＷｅｂサービスに１つのログイン情報のみでログインすることを可能にする試みもなされている。
【００１０】
ネットワーク上の知人同士関係は、一般にソーシャルグラフと呼ばれる。上記のような、異なるＳＮＳを含むＷｅｂサービス間での相互融通の対象となる情報には、ソーシャルグラフが含まれる。最近では、これまで各Ｗｅｂサービス内で独立して保持されていたソーシャルグラフを、Ｗｅｂサービスを超えて融通し合うという試みがなされている。例えば、Ｓｏｃｉａｌ Ｇｒａｐｈ ＡＰＩなどとして知られている。Ｓｏｃｉａｌ Ｇｒａｐｈ ＡＰＩは、ある利用者の特定のＷｅｂサービスにおける認識票を与えると、戻り値としてその利用者の他のＷｅｂサービスにおける認識票を返す。また、ある利用者の特定のＷｅｂサービスにおける認識票を与えると、戻り値としてその利用者と様々なＷｅｂサービスにおいて知人関係にある利用者の、各々のＷｅｂサービスにおける認識票を返す。Ｗｅｂサービスを超えた、ソーシャルグラフの融通を促進する願いがある。
【００１１】
しかし、このような試みはいずれも広く普及しているとは言い難く、上記課題は未解決である。その理由は、ネットワークサービスを提供する事業者の事情にある。既に述べたように各事業者は、他のネットワークサービスの認識票、属性情報、知人関係などを利用したいという要求を持っている一方で、自らのネットワークサービスの認識票、属性情報、知人関係などを他のネットワークサービスの事業者に提供したくないという意図を持っている。一般に、利用者の情報やその知人関係は、ネットワークサービス事業者にとっての収益源であるとともに、利用者を他サービスではなく自らのサービスに引き込むための、最も重要な資産と考えられているからである。すなわち、各ネットワークサービス事業者は他のネットワークサービスとの連携を望む一方で、自らのネットワークサービスの独立性を維持したいという要求を持っている。このため、上記のようなＡＰＩで自らの利用者の情報を外部に公開するＡＰＩを提供するネットワークサービス事業者は少なく、またＯｐｅｎＩＤやＳｏｃｉａｌ Ｇｒａｐｈ ＡＰＩなどの標準規格は提案されるものの、これらに対応するネットワークサービスも増えないという状況にある。
【００１２】
このような状況に鑑み、本願発明によるサーバ、システム、情報端末、ネットワークでは、各ネットワークサービスの独立性を維持しつつ、かつ各々のサービスの有する知人関係を融通し合う。このことにより、利用者による知人関係の拡張を容易にするとともに、知人管理の利便性を高める。また、各ネットワークサービスは独立性を維持したまま、その価値の源泉たる知人関係の拡張が実現する。
【課題を解決するための手段】
【００１３】
本発明の一実施形態として、複数のサービスサーバと、管理サーバ装置と、前記複数のサービスサーバと前記管理サーバ装置と通信可能なゲートウェイサーバ装置とを備えるサービスシステムであって、複数のサービスサーバのいずれも、そのサービスサーバ内で利用者を識別する認識票に、そのサービスサーバの他の利用者の認識票である他人認識票を関係付けて記憶可能であり、さらに、前記認識票に、複数のサービスサーバ間で利用者を一意に識別可能な識別情報と、その識別情報ごとに生成された暗号鍵と、を関連付けて記憶可能であり、前記管理サーバ装置は、第１の列に、前記識別情報を格納し、第２の列に、前記複数のサービスサーバのうち、利用者が利用可能なサービスサーバである一又は複数の利用サービスサーバの識別子を、前記利用者の識別情報に関連付けられて前記複数のサービスサーバの一に記憶されている暗号鍵により暗号化した暗号化情報を格納するテーブルを記憶する記憶装置を有し、前記ゲートウェイサーバ装置は、第１の認識票に関係付けて第１のサービスサーバに記憶されている第１の他人認識票を前記第１のサービスサーバとの通信により受信する第１受信部と、前記第１受信部が受信した第１の他人認識票を、前記第１のサービスサーバの識別子に関連付けて一時テーブルに記憶する第１記憶部と、前記複数のサービスサーバの別の一つである第２のサービスサーバより、前記第１の認識票で識別される利用者を前記第２のサービスサーバ内にて識別する第２の認識票に関係付けて記憶されている第２の他人認識票を前記第２のサービスサーバとの通信により受信する第２受信部と、前記第２受信部が受信した第２の他人認識票を、前記第２のサービスサーバの識別子に関連付けて前記一時テーブルに記憶する第２記憶部と、前記通信において、前記第１の他人認識票が、前記第１のサービスサーバにおいて第１の認識票と第１の暗号鍵とに関連付けて記憶されている、と判断されると、前記第１の識別情報を前記管理サーバ装置へ送信する識別情報送信部と、前記第１の暗号鍵により前記第１のサービスサーバの識別子を含む情報を暗号化した暗号化情報を、前記識別情報送信部による前記第１の識別情報の送信に応じて、前記管理サーバ装置より受信する暗号化情報受信部と、前記受信された暗号化情報を前記第１の暗号鍵にて復号した結果に、前記第２のサービスサーバの識別子が含まれていなければ、前記第１の他人認識票により識別される利用者に対して、第１のメッセージを送信することを前記第１のサービスサーバに命令する第１命令部とを有することを特徴とするサービスシステムが開示される。
【００１４】
本発明の一実施形態として、複数のサービスサーバのいずれもそのサービスサーバにて利用者を認識する認識票に関連付けて、前記複数のサービスサーバにおいて前記利用者を一意に識別する識別情報と、前記識別情報ごとに生成された暗号鍵と、を記憶可能な前記複数のサービスサーバと通信が可能な管理サーバ装置であって、第１の列に、前記識別情報を格納し、第２の列に、前記複数のサービスサーバのうち、利用者が利用可能なサービスサーバである一又は複数の利用サービスサーバの識別子を、前記利用者の識別情報に関連付けられて前記複数のサービスサーバの一に記憶されている暗号鍵により暗号化した暗号化情報を格納するテーブルを記憶する記憶装置を備えることを特徴とする管理サーバ装置が開示される。
【００１５】
本発明の一実施形態として、複数のサービスサーバのいずれもそのサービスサーバ内で利用者を識別する認識票に、そのサービスサーバの他の利用者の認識票である他人認識票を関係付けて記憶可能であり、さらに、複数のサービスサーバ間で利用者を一意に識別可能な識別情報を関連付け、前記識別情報毎に生成された暗号鍵を記憶可能であるサービスサーバの一つである第１のサービスサーバより、第１の認識票に関連付けて記憶されている第１の他人認識票を前記第１のサービスサーバとの通信により受信する第１受信部と、前記第１受信部が受信した第１の他人認識票を、前記第１のサービスサーバの識別子に関連付けて一時テーブルに記憶する第１記憶部と、前記複数のサービスサーバの別の一つである第２のサービスサーバより、前記第１の認識票で識別される利用者を前記第２のサービスサーバ内にて識別する第２の認識票に関連づけて記憶されている第２の他人認識票を前記第２のサービスサーバとの通信により受信する第２受信部と、前記第２受信部が受信した第２の他人認識票を、前記第２のサービスサーバの識別子に関連付けて前記一時テーブルに記憶する第２記憶部と、前記通信において、前記第１受信部が受信した第１の他人認識票が、前記第１のサービスサーバにて第１の識別情報及び第１の暗号鍵に関連付けて記憶されている、と判断されると、前記第１の他人認識票に関連づけて記憶されている前記識別情報を送信する識別情報送信部と、前記第１の暗号鍵により前記第１のサービスサーバの識別子を含む情報を暗号化した暗号化情報を、前記識別情報送信部による前記第１の識別情報の送信に応じて、受信する暗号化情報受信部とを有することを特徴とするゲートウェイサーバ装置が開示される。
【発明の効果】
【００１６】
本願発明によれば、複数のインターネットサービスの知人関係の相互利用が可能となるにもかかわらず、これら各インターネットサービスのサーバに記憶された利用者の認識票、付加情報および知人関係などを、他のインターネットサービスのサーバに提供する必要がない。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態における制御システムの概略構成図である。
【図２】本発明の一実施形態における情報端末の概略構成図である。
【図３】本発明の一実施形態におけるサービスサーバの概略構成図である。
【図４】本発明の一実施形態におけるゲートウェイＷＥＢサーバ（ゲートウェイサーバ装置）の概略構成図である。
【図５】本発明の一実施形態における暗号化認識票サーバ（管理サーバ装置）の概略構成図である。
【図６】本発明の一実施形態においてサービスサーバが記憶するテーブル構成の一例図である。
【図７】本発明の一実施形態において認識票と、識別情報と、暗号鍵を関連付けて記憶するテーブルの一例図である。
【図８】本発明の一実施形態において一の認識票に他の認識票を関係づけて記憶するテーブルの一例図である。
【図９】本発明の一実施形態においてサービスサーバが記憶するテーブル構成の一例図である。
【図１０】本発明の一実施形態において認識票と、識別情報と、暗号鍵を関連付けて記憶するテーブルの一例図である。
【図１１】本発明の一実施形態において一の認識票に他の認識票を関係づけて記憶するテーブルの一例図である。
【図１２】本発明の一実施形態において利用者Ａが、そのＷｅｂサービスサーバＸにおける認識票に、他の利用者の認識票を関係付けるための処理を説明するフローチャートである。
【図１３】本発明の一実施形態におけるゲートウェイサーバ装置が一時テーブルを記憶している状態を示す図である。
【図１４】本発明の一実施形態において画面情報により、情報端末に表示される画面の一例図である。
【図１５】本発明の一実施形態において画面情報により、情報端末に表示される画面の一例図である。
【図１６】本発明の一実施形態におけるゲートウェイサーバ装置が記憶する一時テーブルの一例図である。
【図１７】本発明の一実施形態において管理サーバ装置が暗号化情報を記憶するための処理を説明するフローチャートである。
【図１８】本発明の一実施形態において管理サーバ装置の記憶装置が記憶する、第１と第２の列を有するテーブルの一例図である。
【図１９】本発明の一実施形態において利用者Ａが、そのＷｅｂサービスサーバＸにおける認識票に、他の利用者の認識票を関係付けるための処理を説明するフローチャートである。
【図２０】本発明の一実施形態における画面情報により、情報端末に表示される画面の一例図である。
【図２１】本発明の一実施形態における画面情報により、情報端末に表示される画面の一例図である。
【図２２】本発明の一実施形態において他の利用者に、その認識票を利用者Ａの認識票に関係づけることの可否を尋ねる処理を説明するフローチャートである。
【図２３】本発明の一実施形態において他の利用者の認識票を利用者Ａの認識票に関係づけることの可否を尋ねる画面の一例図である。
【図２４】本発明の一実施形態において利用者Ａの認識票に関係付けられた認識票を表示する画面の一例図である。
【図２５】本発明の一実施形態において利用者Ａが、そのＷｅｂサービスサーバＸにおける認識票に、他の利用者の認識票を関係付けるための処理を説明するフローチャートである。
【図２６】本発明の一実施形態において利用者Ａの認識票に関係付けられた認識票を表示する画面の一例図である。
【図２７】本発明の一実施形態において利用者Ａが、そのＷｅｂサービスサーバＸにおける認識票に、他の利用者の認識票を関係付けるための処理を説明するフローチャートである。
【図２８】本発明の一実施形態において他の利用者の認識票を利用者Ａの認識票に関係づけることの可否を尋ねる画面の一例図である。
【発明を実施するための形態】
【００１８】
以下に本発明を実施するための、現在考えられる最善の形態について説明する。本願発明の範囲は、添付の特許請求の範囲によって明確に定義されているため、この説明は限定的な意味に解釈すべきではなく、単に発明の一般原理を例示する目的で行う。
（実施形態１）
【００１９】
図１は、本発明の実施形態の一例である、情報の表示および制御システムの概略構成図である。ゲートウェイＷｅｂサーバ１００が、ＷｅｂサービスＸのサーバ１５０およびＷｅｂサービスＹのサーバ１６０、および暗号化認識票サーバ１７０と、ネットワーク１９２を通じて接続されている。また、ゲートウェイサーバ１００はネットワーク１９１を通じて利用者Ａの情報端末１１０、利用者Ｂの情報端末１２０、および利用者Ｄの情報端末１３０と接続されている。ネットワーク１９１と１９２は、異なるネットワークでも同じネットワークでもよい。
【００２０】
図２に、利用者Ａの情報端末、利用者Ｂの情報端末および利用者Ｄの情報端末の概略構成図を示す。利用者Ａの情報端末１１０は、送受信手段１１１、ＨＴＭＬＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）解析手段１１２、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）表示手段１１３、および入力手段１１４を有する。利用者Ｂの情報端末１２０は、送受信手段１２１、ＨＴＭＬ解析手段１２２、ＧＵＩ表示手段１２３、および入力手段１２４を有する。利用者Ｄの情報端末１３０は、送受信手段１３１、ＨＴＭＬ解析手段１３２、ＧＵＩ表示手段１３３、および入力手段１３４を有する。
【００２１】
図３に、ＷｅｂサービスＸのサーバおよびＷｅｂサービスＹのサーバの概略構成図を示す。ＷｅｂサービスＸのサーバ１５０（以下サーバＸと呼ぶ）は、送受信手段１５１、サービスＸのデータベース１５２（以下データベースＸと呼ぶ）、認証手段１５３、検索手段１５４、ＨＴＭＬ生成手段１５５、メッセージ生成手段１５６、および記憶手段１５７を有する。ＷｅｂサービスＹのサーバ１６０（以下サーバＸと呼ぶ）は、送受信手段１６１、サービスＹのデータベース１６２（以下データベースＹと呼ぶ）、認証手段１６３、検索手段１６４、ＨＴＭＬ生成手段１６５、メッセージ生成手段１６６、および記憶手段１６７を有する。
【００２２】
図４に、ゲートウェイＷｅｂサーバの概略構成図を示す。ゲートウェイＷｅｂサーバ１００は、送受信手段１０１、ＨＴＭＬ生成手段１０２、一時記憶手段１０３、ＵＩＤ生成手段１０４、暗号化手段１０５、復号化手段１０６、検索手段１０７、および暗号鍵生成手段１０８を有する。
【００２３】
図５に、暗号化認識票サーバの概略構成図を示す。暗号化認識票サーバ１７０は、送受信手段５０１、暗号化認識票テーブル５０２、ＵＩＤ生成手段５０３、および検索手段５０４を有する。
【００２４】
図６にデータベースＸ１５２の有するテーブルを示す。データベースＸ１５２は、認識票テーブル６０１およびソーシャルグラフテーブル６０２、および認証テーブル６０３を有する。認識票テーブル６０１には、ＷｅｂサービスＸの個々の利用者を一意に特定するための認識票が、各々の利用者の属性情報、利用者ユニーク認識票（以下ＵＩＤ）、および暗号鍵と関連づけて記憶されている。また、ソーシャルグラフテーブル６０２には、ＷｅｂサービスＸにおける知人関係が記憶されている。
【００２５】
図７に、本実施形態における認識票テーブル６０１の一例を示す。認識票テーブル６０１は、ＷｅｂサービスＸにおいて各利用者を一意に特定する認識票７１０、属性１として各利用者の名前７２０、および属性２として各利用者の誕生月７３０、ＵＩＤ７４０、暗号鍵７５０の各列を有する。属性の数はいくつででも、また無くてもよい。属性情報は、各利用者に関連づけられた情報ならどのような情報であってもよい。また、図８にソーシャルグラフテーブル６０２の一例を示す。ソーシャルグラフテーブル６０２は、ＷｅｂサービスＸにおいて各利用者を一意に特定する認識票と８１０と、各利用者の知人関係にある利用者の認識票８２０、の２列を有する。さらに、認証テーブル６０３は、各利用者の認識票に関連づけて、パスワードなどの認証用情報が記憶されている。
【００２６】
図９にデータベースＹ１６２の有するテーブルを示す。データベースＹ１６２は、認識票テーブル９０１、ソーシャルグラフテーブル９０２、および認証テーブル９０３を有する。認識票テーブル９０１には、ＷｅｂサービスＹの各利用者を一意に特定するための認識票が、各々の利用者の属性情報、ＵＩＤおよび暗号鍵と関連づけて記憶されている。また、ソーシャルグラフテーブル９０２には、ＷｅｂサービスＹ内の知人関係が記憶されている。
【００２７】
図１０に認識票テーブル９０１の一例を示す。認識票テーブル９０１は、ＷｅｂサービスＹにおいて各利用者を一意に特定する認識票と１０１０、属性１として各利用者のニックネーム１０２０、属性２として各利用者の年齢１０３０、ＵＩＤ１０４０、および暗号鍵１０５０の各列を有する。属性の数はいくつででも、また無くてもよい。属性情報は、各利用者に関連づけられた情報ならどのような情報であってもよい。また、図１１にソーシャルグラフテーブル９０２の一例を示す。ＷｅｂサービスＸにおいて各利用者を一意に特定する認識票と１１１０と、各利用者の知人関係にある利用者の認識票１１２０、の２列を有する。さらに、認証テーブル９０３は、各利用者の認識票に関連づけて、パスワードなどの認証用情報が記憶されている。
【００２８】
なお、本明細書において、認識票はすべてＩＤｍｎという形式で表示する。ここでｍはこの認識票によって利用者を一意に特定するＷｅｂサービスの名前、ｎは利用者を表す。たとえば、ＩＤｘａはＷｅｂサービスＸにおける利用者Ａの認識票を表す。同様にＩＤｙａはＷｅｂサービスＹにおける利用者Ａの認識票を表す。この場合、利用者ＡはＷｅｂサービスＸおよびＷｅｂサービスＹの両方の利用者である。現実には、ＷｅｂサービスＸとＷｅｂサービスＹの認識票は各々独立しており、利用者ＡがＷｅｂサービスＸとＷｅｂサービスＹの両方を使っているという事実を、ＷｅｂサービスＸのサーバやＷｅｂサービスＹのサーバが検出する方法はないが、本願発明の内容を明確化するために、本明細書ではこのような表記方法を採用する。
【００２９】
次に、図１２のフロー図を用いて、本願発明によるサーバ、情報端末およびシステムによって、利用者ＡがＷｅｂサービスＸにおける知人を増やす処理について説明する。
【００３０】
いま、利用者Ａがその情報端末１１０を通じてＷｅｂサービスＸを利用している。このとき、ＷｅｂサービスＸのサーバのＨＴＭＬ生成手段１５５によって生成され、送受信手段１５１およびネットワーク１９２およびネットワーク１９１を通じて利用者Ａの情報端末に送られたＨＴＭＬコードが、ＨＴＭＬ解析手段１１２によって解析された結果が、ＧＵＩ表示手段１１３に表示される。これに先立ち、利用者Ａは、その情報端末１１０からＷｅｂサービスにおける認識票ＩＤｘａおよびパスワードをＷｅｂサービスＸのサーバに送り、認証手段１５３が、利用者Ａの情報端末１１０からのアクセスであることを認証している。
【００３１】
次に、利用者ＡはＷｅｂサービスＸに含まれる、本願発明による知人関係拡張サービスを選択する（ステップＳ１２０１）。これは、利用者ＡがＷｅｂサービスＸの画面に表示された知人関係拡張サービスボタンを選択することなどによって実行される。ここで、以下で述べる知人関係拡張サービスのセッションｎが開始される。上記のようにＷｅｂサービスＸはＷｅｂサービスＸのサーバ１５０によって提供されるが、ＷｅｂサービスＸの一部である知人関係拡張サービスは、ゲートウェイＷｅｂサーバ１００によって提供される。すなわち、利用者Ａがその情報端末の入出力手段によって知人関係拡張サービスを選択すると、その要求がネットワーク１９１および１９２を通じてＷｅｂサービスＸのサーバ１５０に送られると、送受信手段１５１がこれをゲートウェイＷｅｂサーバにリダイレクトする（ステップＳ１２０２）。次に、ＷｅｂサービスＸの検索手段１５４が、利用者Ａの認識票ＩＤｘａ７１１を検索キーとして、データベースＸ１５２のソーシャルグラフテーブル６０２を検索し、ＩＤｘｃ８２１、ＩＤｘｅ８２２およびＩＤｘｆ８２３を得る。これは、ＷｅｂサービスＸにおいて、利用者Ａは利用者Ｃ、Ｅ、およびＦと知人関係にあることを示している。さらに検索手段１５４はこのＩＤｘｃ、ＩＤｘｅおよびＩＤｘｆで、データベースＸ１５２の認識票テーブル６０１を検索し、利用者Ｃ、Ｅ、およびＦの名前を得る。各々の名前はＤｉｃｋ Ｃｈｉｎｇ７２３、Ｌａｕｒａ Ｓｍｉｔｈ７２４、Ｓｔｅｖｅ Ｂｕｓｈ７２５である。次に、ＷｅｂサービスＸのサーバの送受信手段１５１は、利用者Ａの認識票ＩＤｘａ、および知人関係にある利用者Ｃ、Ｄ、およびＥの各々の認識票および名前を、ゲートウェイＷｅｂサーバ１００に送る。また、利用者Ａの利用者ユニーク認識票（以下ＵＩＤと呼ぶ）が存在する場合には、これもＩＤｘａと関連づけてゲートウェイＷｅｂサーバに送る（ステップＳ１２０３）。存在しない場合は送らない。図７を参照すると、ＩＤｘａ７１１に対応するＵＩＤは、ＵＩＤの列７４０に存在しない７４１ので、送らない。さらに、知人関係にある利用者Ｃ、Ｅ、およびＦの中でＵＩＤおよび暗号鍵が存在する利用者については、ＵＩＤおよび暗号鍵を各々の認識票に関連づけて、ゲートウェイＷｅｂサーバに送る。存在しない場合は送らない。図７を参照すると、上記検索で得られたＩＤｘｃ、ＩＤｘｅ、およびＩＤｘｆのうちで、ＩＤｘｃおよびＩＤｘｆに各々ＵＩＤと暗号鍵が存在するので、これらＵＩＤｃ７４３、Ｋｃ７５３、ＵＩＤｆ７４５、Ｋｆ７５５もゲートウェイＷｅｂサーバに送る。ここでＵＩＤとは、複数のＷｅｂサービスを跨いで、各利用者を一意に特定するための認識票である。ＵＩＤについては、後に詳しく説明する。本明細書では、ＵＩＤｍという表記は、利用者ＭのＵＩＤであることを表す。
【００３２】
次に、これらの情報をゲートウェイＷｅｂサーバの送受信手段１０１が受信し、一時記憶手段１０３に記憶する（ステップＳ１２０４）。一時記憶手段１０３は、知人関係拡張サービスのセッションごとに、一時的に情報を記憶するための手段であり、各セッションが終了すると消去される。一般的にはＤＲＡＭ（Ｄｉｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）によりなるコンピュータの主記憶手段などが一時記憶手段として使われることが多いが、各セッションが終了する度にその内容が消去されれば、一時記憶手段がどのような装置で実現されていてもよい。図１３に、一時記憶手段の構成の一例を示す。
【００３３】
一時記憶手段１０３には、セッションごとにテーブルが作成される。ゲートウェイサーバは、複数のセッションを並行することができる。このため図１３に示すように、任意の瞬間において、一時記憶手段１０３には、零を含む任意の数のテーブルが存在する。各々のテーブルはセッションが実行されている間は一時記憶手段１０３に記憶されるが、セッションが終了すると消去される。上記ステップＳ１２０４でＷｅｂサービスＸのサーバより受信した情報は、図１３におけるセッションｎのテーブル１３０１に記憶される。
【００３４】
次に、ゲートウェイＷｅｂサーバのＨＴＭＬ生成手段１０２は、上記ステップＳ１２０４で一時記憶手段１０３に記憶した、利用者ＡとＷｅｂサービスＸで知人関係にある利用者Ｃ、利用者Ｅ、および利用者Ｆの名前を含むＨＴＭＬコードを生成し、送受信手段１０１がネットワーク１９１を通じて利用者Ａの情報端末１１０に送る。利用者Ａの情報端末では、送受信手段１１１がこれを受信し、ＨＴＭＬ解析手段１１２がこれを解析した後、ＧＵＩ表示手段１１３に図１４に示す画像を表示する（ステップＳ１２０５）。図１４では、ＧＵＩ表示装置１１３上に、Ｗｅｂブラウザウィンドウ１４００が表示される。このＷｅｂブラウザウィンドウ１４００内には、ＷｅｂサービスＸ内の、知人関係拡張サービスが表示される。知人関係拡張サービスは、ＷｅｂサービスＸの一部である。Ｗｅｂブラウザ１４００内に表示された画像は、ＷｅｂサービスＸの知人一覧１４１０および外部サービス一覧１４２０の２つのウィンドウを有する。
【００３５】
まず、ＷｅｂサービスＸの知人一覧１４１０について説明する。ＷｅｂサービスＸの知人一覧１４１０には、利用者ＡがＷｅｂサービスＸで知人関係にある利用者Ｃ、Ｅ、およびＦの各々の名前の一覧が表示されている。図１４に示した、Ｄｉｃｋ Ｃｈｉｎｇ１４１１、Ｌａｕｒａ Ｓｍｉｔｈ１４１２、およびＳｔｅｖｅ Ｂｕｓｈ１４１３は、各々利用者Ｃ、Ｅ、およびＦの、ＷｅｂさービスＸにおける名前である。また、名前の左に表示されたマーク１４１９は、これらの名前がＷｅｂサービスＸにおける知人であることを表している。
【００３６】
再び図１４を参照して、Ｗｅｂブラウザ１４００内に表示された、外部サービス一覧ウィンドウ１４２０について説明する。外部サービスとは、利用者Ａが使うＷｅｂサービスＸ以外のＷｅｂサービスである。図１４に示す一例では、外部サービス一覧ウィンドウ１４２０は、利用者ＡがＷｅｂサービスＹの知人関係をＷｅｂサービスＸに持ち込むためのボタン１４２１、同様にＷｅｂサービスＷの知人関係をＷｅｂサービスＸに持ち込むためのボタン１４２２、およびＷｅｂサービスＺの知人関係をＷｅｂサービスＸに持ち込むためのボタン１４２３、の３つのボタンを有する。図７および図１０からわかるように、利用者ＡはＷｅｂサービスＸの利用者であると同時にＷｅｂサービスＹの利用者でもある。
【００３７】
利用者Ａは、その情報端末の入出力手段１１４を通じて、ＧＵＩ表示手段１１３に表示されたカーソル１４３０を移動させ、ＷｅｂサービスＹと連携させるためのボタン１４２１に合わせた上、入力手段１１４の有するボタンを下押しするなどしてＷｅｂサービスＹを選択する（ステップＳ１２０６）。すると、利用者Ａの情報端末の送受信手段１１１は、ＷｅｂサービスＹにおける利用者Ａの認証要求を、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送る。更にゲートウェイサーバの送受信手段１０１はこの認証要求を受信した後これを転送し、ネットワーク１９２を通じて、ＷｅｂサービスＹのサーバ１６０に送る。ここで、利用者Ａの情報端末のウェブブラウザ１４００の画面は、ゲートウェイＷｅｂサーバ１００からＷｅｂサービスＹのサーバ１６０にリダイレクトされる（ステップＳ１２０７）。ＷｅｂサービスＹの送受信手段１６１が上記認証要求を受信すると、ＨＴＭＬ生成手段１６５は、利用者Ａの情報端末１１０が認識票ＩＤｙａを持つ利用者Ａのものであることを認証するための入力画面のＨＴＭＬコードを生成する。送受信手段１６１が、ＨＴＭＬコードをネットワーク１９２およびネットワーク１９１を通じて
利用者Ａの情報端末１１０に送る。このＨＴＭＬコードは、利用者Ａの送受信手段１１１を通じてＨＴＭＬ解析手段１１２に送られ、解析された後、ＧＵＩ表示手段１１３によって表示される（ステップＳ１２０８）。
【００３８】
図１５は、このとき利用者Ａの情報端末のＧＵＩ表示手段１１３に表示された画面の一例である。Ｗｅｂブラウザ１４００に表示されたＷｅｂサービスＹの認証画面は、認識票の入力欄１５０１、およびパスワードの入力欄１５０２、および入力完了ボタン１５０３を有する。利用者Ａが入出力手段１１４によってＷｅｂサービスＹにおける利用者Ａの認識票ＩＤｙａをＩＤ入力欄１５０１に、またパスワードをパスワード入力欄１５０２に入力した後、カーソル１４３０を入力完了ボタン１５０３の位置まで移動させた上、入力手段１１４のボタンを下押しするなどして選択する。
【００３９】
ここで入力された利用者Ａの認識票およびパスワードは、認証要求とともに、送受信手段１１１、ネットワーク１９１およびネットワーク１９２を通じてＷｅｂサービスＹのサーバ１６０に送られる（ステップＳ１２０９）。送受信手段１６１がこれらを受信すると、これを認証手段１６３に送る。認証手段１６３は、入力された受信した認識票ＩＤｙａを検索キーとして、データベースＹ１６２にある認証テーブル９０３を検索し、ＩＤｙａに関連づけられたパスワード情報を得た上、ステップＳ１２０９で受信したパスワードとの一致を検出する。ここに示す一例では、認識票とパスワードによる認証を用いて説明したが、ステップＳ１２０９による認証要求が、利用者Ａ自身によるものである、または利用者Ａの情報端末１１０からのものであることが確認できる認証方法であれば、どのような認証方法でもよい。
【００４０】
上記パスワードの一致が検出されると、次に認証された利用者Ａの認識票ＩＤｙａを検索キーとして、データベースＹ１６２のソーシャルグラフテーブル９０２を検索する。図１１を参照すると、ＩＤｙａ１１１１が検索される。次に、このＩＤｙａ１１１１に関連づけられた認識票ＩＤｙｂ１１２１およびＩＤｙｄ１１２２を検索キーとして、認識票テーブル９０１を検索する。図１０を参照すると、認識票ＩＤｙｂ１０１２およびＩＤｙｄ１０１３が検出される。次に、送受信手段１６１が、認識票ＩＤｙａをネットワーク１９２を通じてゲートウェイＷｅｂサーバ１００に送る。また、同時に認識票テーブル９０１で上記認識票ＩＤｙｂおよびＩＤｙｄに各々関連づけられたニックネームｎｉｋｋｉ１０２２およびｎａａｍ１０２３を各々の認識票と関連づけた状態で、ゲートウェイＷｅｂサーバ１００に送る。ステップＳ１２０３と同様に、認識票テーブル９０１において、もしＩＤｙａに関連づけられたＵＩＤが存在すれば、そのＵＩＤもＩＤｙａと関連づけてゲートウェイＷｅｂサーバ１００に送る（ステップＳ１２１０）。図１０に示すように、ここに示す一例では、ＩＤｙａに対応するＵＩＤ１００１は存在しないので、送らない。また、図１０を参照して、上記の検索結果のうちで、認識票ＩＤｙｂ１０１２に関連づけられたＵＩＤであるＵＩＤ１０４２および暗号鍵Ｋｂ１０５２、および認識票ＩＤｙｄに関連づけられたＵＩＤ１０４３およびＫｄ１０５３も、ゲートウェイＷｅｂサーバ１００に送る。
【００４１】
次に、これらの情報をゲートウェイＷｅｂサーバの送受信手段１０１が受信し、一時記憶手段１０３のセッションｎのテーブルに記憶する（ステップＳ１２１１）。既に述べたように、一時記憶手段１０３は、知人関係拡張サービスのセッションごとに、一時的に記憶するための手段であり、各セッションが終了すると消去される。
【００４２】
前記ステップＳ１２１１が完了した段階で、ゲートウェイＷｅｂサーバの一時記憶手段１０３にあるこのセッションnのテーブル１３０１を図１６に示す。ただし、本実施形態に
示す一例では、上記ステップＳ１２０４およびＳ１２１１で、利用者ＡのＵＩＤは、セッションｎのテーブル１３０１には記憶されていないので、図１６に示すＵＩＤａ１６００
はこの時点では空白であり、図１６の状態になるのは、下記ステップＳ１７０３においてである。ここでＩＤｘａ１６０１に関連付けられて記憶されている知人の認識票ＩＤｘｃ１６１１、ＩＤｘｅ１６１２、ＩＤｘｆ１６１３、およびさらにこれら各認識票に関連づけられた名前、ＵＩＤおよび暗号鍵は、上記ステップＳ１２０４において、ＷｅｂサービスＸのサーバより受信した情報である。また、ＩＤｙａ１６０２に関連付けられて記憶されている知人の認識票ＩＤｙｂ１６１４、ＩＤｙｄ１６１５、およびさらにこれら各認識票に関連づけられたニックネーム、ＵＩＤおよび暗号鍵は、上記ステップＳ１２１１において、ＷｅｂサービスＸのサーバより受信した情報である。
【００４３】
次に図１７に示すフロー図を用いて、ＷｅｂサービスＸにおける認識票ＩＤｘａとＷｅｂサービスＹにおける認識票ＩＤｙａが同じ利用者Ａの有するものであることを、本願発明の方法によって暗号化認識票サーバ１７０に記憶する処理について説明する。上記のように、ステップＳ１２０４およびＳ１２１１で利用者ＡのＵＩＤを受信していないので、まず利用者Ａ、すなわち認識票ＩＤｘａ１６０１およびＩＤｙａ１６０２に対応するＵＩＤの発行要求を、暗号化認識票サーバ１７０に、ネットワーク１９２を通じて送る（ステップＳ１７０１）。暗号化認識票サーバの送受信手段５０１がこれを受信すると、ＵＩＤ生成手段５０３が、暗号化認識票テーブル５０２を検索し、まだ存在しない新しいＵＩＤを生成する。次に送受信手段６０１がこの新しいＵＩＤを利用者ＡのＵＩＤとして、ネットワーク１９２を通じてゲートウェイＷｅｂサーバ１００に送る。（ステップＳ１７０２）。図１８に暗号化認識票テーブル５０２の一例を示す。暗号化認識票テーブル５０２は、ＵＩＤの列１８１０と暗号化認識票群１８２０の２つの列を有する。この一例では、ＵＩＤ生成手段５０３は、新たなＵＩＤとしてＵＩＤａを生成する。上記ステップＳ１７０２では、ＵＩＤ生成手段５０３がＵＩＤの列１８１０にないＵＩＤを生成する。暗号化認識票群の列１８２０については後で説明する。
【００４４】
ゲートウェイＷｅｂサーバの送受信手段１０１が新たなＵＩＤａを受信し、一時記憶手段１０３のセッションｎのテーブル１３０１で、空白であったＵＩＤ欄１６００にＵＩＤａを記憶する（ステップＳ１７０３）。次に、ゲートウェイＷｅｂサーバの暗号鍵生成手段１０８が、ＵＩＤａ用の暗号鍵、すなわち利用者Ａの暗号鍵Ｋａを生成する（ステップＳ１７０４）。次に送受信手段１０１がＵＩＤａおよびＫａを、ネットワーク１９２を通じてＷｅｂサービスＸのサーバ１５０およびＷｅｂサービスＹのサーバ１６０に送る（ステップＳ１７０５）。ＷｅｂサービスＸのサーバでは、送受信手段１５１がこれを受信し、データベースＸにある認識票テーブルに記憶する（ステップＳ１７０６）。図７を参照して、記憶する場所は、ＵＩＤａが欄７４１、またＫａが欄７５１である。同様に、ＷｅｂサービスＹのサーバでは、送受信手段１６１がこれを受信し、データベースＸにある認識票テーブル９０１に記憶する。図１０を参照して、記憶する場所は、ＵＩＤａが欄１０４１、またＫａが欄１０５１である。
【００４５】
次に暗号化手段１０５が、一時記憶手段のセッションｎのテーブル１３０１に記憶されているＩＤｘａ１６０１とそれがＷｅｂサービスＸの認識票であることを表すＸ、さらにＩＤｙａ１６０２とそれがＷｅｂサービスＹの認識票であることを表すＹとを関連づけた状態で、上記ステップＳ１７０４で生成した暗号鍵Ｋａで暗号化する（ステップＳ１７０７）。ここで暗号化したものをＥｋａ（ＩＤｘａ−Ｘ、ＩＤｙａ−Ｙ）と表記する。次に送受信手段１０１がＵＩＤａとＥｋａ（ＩＤｘａ−Ｘ、ＩＤｙａ−Ｙ）をネットワーク１９２を通じて暗号化認識票サーバ１７０に送る。暗号化認識票サーバの送受信手段５０１がこれを受信し、暗号化認識票テーブル５０２の新たな行に追加し、ＵＩＤａ１８１１とＥｋａ（ＩＤｘａ−Ｘ、ＩＤｙａ−Ｙ）１８１２を関連づけて保存する（ステップＳ１７０８）。
【００４６】
本実施形態で示す一例では、利用者ＢのＵＩＤｂと暗号鍵Ｋｂが、ＷｅｂサービスＸのサーバの認識票テーブル６０１、およびＷｅｂサービスＹのサーバの認識票テーブル９０１に、セッションｎが開始される以前から記憶されていた。これは、利用者Ｂがセッションｎの開始以前、利用するＷｅｂサービスＸまたはＷｅｂサービスＹにおいて、知人関係拡張サービスを利用して、ステップＳ１７０６までと同様の処理を実行し、図１７に相当する処理を実行した結果である。ここで説明した図１７の処理は、セッションｎにおいてではなく、セッションｎ以降のセッションにおいて、利用者Ａまたは他の利用者がゲートウェイＷｅｂサービスを利用した知人関係拡張サービスを利用する際に使う。
【００４７】
続いて、図１９のフロー図を用いて、利用者ＡがゲートウェイＷｅｂサーバ１００を使ったＷｅｂサービスＸの知人関係拡張サービスの処理について説明を続ける。利用者Ａの情報端末のウェブブラウザ１４００の画面は、ＷｅｂサービスＹのサーバ１６０からゲートウェイＷｅｂサービスのサーバ１００にリダイレクトされる（ステップＳ１９０１）。次に、ＨＴＭＬ生成手段１０２が図１６に示す状態のセッションｎのテーブル１３０１をから図２０の画面を生成するＨＴＭＬコードを生成し、これを送受信手段１０１が利用者Ａの情報端末１１０にネットワーク１９２を通じて送る。利用者Ａの情報端末では、これを送受信手段１１１が受信し、ＨＴＭＬ解析手段１１２によって解析された後、ＧＵＩ表示手段１１３のＷｅｂブラウザ１４００内に表示される（ステップＳ１９０２）。
【００４８】
図２０に、利用者Ａの情報端末のＧＵＩ表示手段１１３に表示された画像を示す。Ｗｅｂブラウザ１４００内には、既に図１４で説明したサービスＸの知人一覧ウィンドウ１４１０とともに、ＷｅｂサービスＹの知人一覧ウィンドウ２０２０が表示されている。ＷｅｂサービスＹの知人一覧ウィンドウには、ｎｉｋｋｉ２０２１およびｎａａｍ２０２２が表示されている。これらは、ゲートウェイＷｅｂサーバ１００の一時記憶手段にあるセッションｎのテーブル上の情報がＨＴＭＬコードとして受信したものを表示している。図２０において、マーク２０２９は、表示された利用者がＷｅｂサービスＹの利用者であることを表している。図１６からわかるように、ｎｉｋｋｉ２０２１は、ＷｅｂサービスＹの認識票ＩＤｙｂを有する利用者Ｂのニックネームであり、またｎａａｍ２０２２は、ＷｅｂサービスＹの認識票ＩＤｙｄを有する利用者Ｄのニックネームである。
【００４９】
次に、利用者Ａが入力手段１１４を操作して、ＧＵＩ表示手段１１３に表示されたカーソル１４３０を移動させ、Ａｄｄボタン２０２５に合わせた上、入力手段１１４の有するボタンを下押しするなどして、Ａｄｄボタン２０２５を選択することで、以下に説明する２つの処理が実行される。このとき、Ａｄｄボタン２０２５を下押しするかわりに、Ｗｅｂブラウザ１４００内で、表示されたｎｉｋｋｉというオブジェクト２０２１にカーソル１４３０を合わせた上、入力手段の有するボタンを下押しするなどして選択したまま、カーソル１４３０をＷｅｂサービスＸの知人一覧ウィンドウ１４１０内に移動させた上、選択を解除する、所謂ドラッグ・アンド・ドロップを実行しても、やはり以下に説明する２つの処理が実行される（ステップＳ１９０３）。この操作は、利用者ＡがこれまでＷｅｂサービスＹにおいてのみ知人関係にあった利用者Ｂと、ＷｅｂサービスＸにおいても知人関係になることを要求する操作である。本実施形態１においては、利用者Ｂは、ＷｅｂサービスＸの利用者であり、認識票ＩＤｘｂを既に有している。ただし、利用者Ａはこれを知らない。
【００５０】
以上の操作によって、以下の２つの処理が実行される。第１の処理は利用者Ａの情報端末のＧＵＩ表示手段１１３への表示変更のための処理である。第２の処理は、利用者Ｂに対して、ＷｅｂサービスＸにおいても利用者Ａと知人関係になることについての同意を求めるための処理である。
【００５１】
まず、上記第1の処理について説明する。上記のようなＡｄｄボタン２０２５の下押し、乃至はドラッグ・アンド・ドロップが実行されたという情報は送受信手段１１１によって、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送られる。送受信手段１０１はこの情報を受け取ると、ＨＴＭＬ生成手段１０２は、図２１に示すような画面を表示するための新たなＨＴＭＬコードを生成する。この新たなＨＴＭＬコードは送受信手段１０１およびネットワーク１９１を通じて利用者Ａの情報端末に送られる。送受信手段１１１がこれを受信すると、ＨＴＭＬ解析手段１１２がこれを解析した上、図２１に示す画像をＧＵＩ表示手段１１３のＷｅｂブラウザ１４００に表示する。
【００５２】
図２１に示す画面では、ＷｅｂサービスＸの知人一覧ウィンドウ１４１０中に、利用者ＡとＷｅｂサービスＹで知人関係にある、ＷｅｂサービスＹにおけるニックネームｎｉｋｋｉを有する利用者Ｂを表すオブジェクト２１１１が新たに追加された（ステップＳ１９０３）。利用者Ｂを表すオブジェクト２１１１には、確認中という文字列２１１２が表示される。これは確認中という文字列でなくとも、利用者ＢがＷｅｂサービスＸでも利用者Ａと知人関係になることを承諾する以前の状態であること意味する表示なら何でも良い。なお、図２１に示す一例では、ステップＳ１９０３の操作の結果、利用者Ｂを表すオブジェクト２１１１がサービスＸの知人一覧ウィンドウ１４１０に追加された。しかし、ウェブブラウザ１４００内に表示される、たとえば「サービスＸの知人に加えようとしている人」のような別のウィンドウに追加されてもよい。また、図２１に示す一例では、ステップＳ１９０３の操作の結果、図２０に示す利用者Ｂを表すオブジェクト２０２１が、図２１ではＷｅｂサービスＹの知人一覧ウィンドウ２０２０から消えているが、これは消えなくてもよい。
【００５３】
次に、上記第２の処理について説明する。上記ステップＳ１９０３におけるＡｄｄボタンの下押し、乃至はドラッグ・アンド・ドロップが実行されたという情報は送受信手段１１１によって、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送られる。ゲートウェイＷｅｂサーバの送受信手段１０１がこれを受信すると、図１６を参照して、検索手段１０７が一時記憶手段のセッションｎのテーブル１３０１から上記ステップＳ１９０３で選択された認識票ＩＤｙｂ１６１４を有する利用者ＢのＵＩＤおよび暗号鍵を検索し、その結果ＵＩＤｂ１６３４およびＫｂ１６４４を得る（ステップＳ１９０４）。次に、送受信手段１０１はＵＩＤｂに関連づけられた暗号化認識票群の要求を、ネットワーク１９２を通じて暗号化認識票サーバ１７０に送る（ステップＳ１９０５）。
【００５４】
暗号化認識票サーバでは、送受信手段５０１がこれを受信し、検索手段５０４が受信したＵＩＤｂを検索キーとして暗号化認識票テーブルを検索する。図１８を参照すると、ＵＩＤｂ１８１１が検出される。すると送受信手段５０１がＵＩＤｂ１８１１に関連づけられた暗号化認識票群Ｅｋｂ（ＩＤｘｂ−Ｘ、ＩＤｙｂ−Ｙ）を、ネットワーク１９２を通じて、ゲートウェイＷｅｂサーバに送る（ステップＳ１９０６）。ゲートウェイＷｅｂサーバの送受信手段１０１がこれを受信すると、復号化手段１０６が前記ステップＳ１９０４で得られた暗号鍵Ｋｂを用いて、受信したＥｋｂ（ＩＤｘｂ−Ｘ、ＩＤｙｂ−Ｙ）を復号化する。その結果、利用者Ｂの有する２つの認識票ＩＤｘｂおよびＩＤｙｂを得る（ステップＳ１９０７）。以上の処理で、ＷｅｂサービスＹでＩＤｙｂを有する利用者Ｂが、ＷｅｂサービスＸにおいては認識票ＩＤｘｂを有することを、ゲートウェイＷｅｂサーバ１００が得たことになる。
【００５５】
次に、送受信手段１０１は、ゲートウェイＷｅｂサーバ１００が前記ステップＳ１９０７で得たＩＤｘｂと、セッションｎのテーブル１３０１にあるＩＤｘａ１６０１を含むメッセージ送信要求を、ネットワーク１９２を通じてＷｅｂサービスＸのサーバに送る（ステップＳ１９０８）。ここで要求するメッセージは、利用者Ａが利用者Ｂに対して、ＷｅｂサービスＸ上でも知人関係になることを要求するためのメッセージである。次に、ＷｅｂサービスＸのサーバの送受信手段１５１がこのメッセージ送信要求を受信し、記憶手段１５７に記憶する（ステップＳ１９０９）。
【００５６】
ここで、利用者Ａが、ＷｅｂサービスＸの知人関係拡張サービスを終了すれば（ステップＳ１９１０）、利用者ＡのＷｅｂブラウザからのアクセスは、ＷｅｂサービスＸのサーバ１５０にリダイレクトされ（ステップＳ１９１１）、さらにゲートウェイＷｅｂサーバの一時記憶手段１０３にある、セッションｎのテーブル１３０１は消去され（ステップＳ１９１２）、セッションｎは終了する。
【００５７】
次に、利用者Ａから利用者Ｂに対するメッセージ送信要求を受信した後の、ＷｅｂサービスＸのサーバの処理について、図２２に示すフロー図を用いて説明する。
【００５８】
利用者ＢがＷｅｂサービスＸにログインする（ステップＳ２２０１）。次に、ＷｅｂサービスＸのサーバのメッセージ生成手段１５６が、送信者を有する利用者Ａ、受信者を利用者Ｂとして、ＷｅｂサービスＸ上でも知人関係になることを要求するためのメッセージを生成する。この時生成される送信者および受信者は、前期ステップＳ１９０９で記憶されたた認識票ＩＤｘａおよびＩＤｘｂを用いる。ここで生成されたメッセージは、ＨＴＭＬ生成手段１５５によってＨＴＭＬコードに変換される。送受信手段１５１が、このＨＴＭＬコードを、ネットワーク１９２および１９１を通じて利用者Ｂの情報端末１２０に送る（ステップＳ２２０２）。
【００５９】
次に、利用者Ｂの情報端末の送受信手段１２１がこのＨＴＭＬコードを受信すると、ＨＴＭＬ解析手段１２２がこれを解析の上、ＧＵＩ表示手段１２３に図２３に示す画像を表示する。ＧＵＩ表示手段１２３には、Ｗｅｂブラウザウィンドウ２３００が表示される。Ｗｅｂブラウザウィンドウ２３００内には、利用者ＢとＷｅｂサービスＹで知人関係にある利用者Ａが、ＷｅｂサービスＸでも知人になりたいという意志を表明した旨の文章２３０１が表示される（ステップＳ２２０３）。また、この画面は非承諾ボタン２３１１および承諾ボタン２３１２が表示されている。ここで、利用者Ｂが入力手段１２４を用いて表示手段１２３に表示されたカーソル２３３０を移動させた上、承諾ボタン２３１２にあわせた上、入力手段のボタンを下押しするなどしてこれを選択する。この操作が実行されたという情報は、送受信手段１２１によってネットワーク１９１、ネットワーク１９２を通じて、ＷｅｂサービスＸのサーバ１５０に送られる（ステップＳ２２０４）。
【００６０】
これをＷｅｂサービスＸのサーバの送受信手段１５１が受信すると、承諾通知が記憶手段１５７に記憶される。この時点で、もし利用者ＡがＷｅｂサービスＸにログインしていれば、次のステップＳ２２０６に進む。もし利用者ＡがＷｅｂサービスＸにログインしていなければ、ログインした時に次ぎのステップＳ２２０６に進む。
【００６１】
ＷｅｂサービスＸのサーバのＨＴＭＬ生成手段１５５が図２４に示す画像のＨＴＭＬコードを生成する。次に送受信手段１５１がネットワーク１９１を通じてこのＨＴＭＬコードを利用者Ａの情報端末１１０に送る（ステップＳ２２０６）。利用者Ａの情報端末では、送受信手段１１１がこのＨＴＭＬコードを受信し、ＨＴＭＬ解析手段１１２がこれを解析した後、ＧＵＩ表示手段１１３に、図２４に示す画像が表示される（ステップＳ２２０７）
【００６２】
図２４に示すように、表示手段１１３にはＷｅｂブラウザウィンドウ１４００が表示される。Ｗｅｂブラウザウィンドウ１４００内には、上記ＨＴＭＬコードの解析結果が表示される。図７および図１０からわかるように、利用者ＢはＷｅｂサービスＸにおいてＢｅｔｔｙ Ｔｈｏｍａｓ７２２の名前を使い、かつＷｅｂサービスＹにおいてニックネームｎｉｋｋｉ１０２２を使っている。これまで説明したステップＳ１２０１からステップＳ２２０４の処理の結果、図２４では、利用者ＢのＷｅｂサービスＸにおける名前Ｂｅｔｔｙ Ｔｈｏｍａｓ２４１１、およびこれがＷｅｂサービスＸにおける名前であることを表すアイコン２４１２と共に表示されている。利用者Ａが、利用者ＢをＷｅｂサービスＸ上の知人にするための操作であるステップＳ１９０３を実行した直後は、利用者Ａの情報端末のＧＵＩ表示手段１１３には、図２１に示す画像が表示されていた。図２１と図２４を比較すると、図２１では、利用者ＢのＷｅｂサービスＹにおけるニックネームｎｉｋｋｉ２１１１が、確認中の表示２１１２とともに表示されているのに対して、図２４では、利用者ＢのＷｅｂサービスＸにおける名前Ｂｅｔｔｙ Ｔｈｏｍａｓ２４１１が、ＷｅｂサービスＸの知人一覧として表示されている。この時点で、利用者Ａと利用者Ｂの間では、知人一覧１４１０に表示された他の知人と同様に、ＷｅｂサービスＸの機能を使うことができる。
【００６３】
なお、本実施形態における暗号化は、利用者ごとに１つの対称鍵秘密鍵を用いて説明したが、非対称鍵を用いてもよい。また、本実施形態では利用者ごとに異なるが、各Ｗｅｂサービスに共通の暗号鍵を利用したが、利用者ごと、かつＷｅｂサービスごとに異なる暗号鍵を用いてもよい。また、本実施形態では、ゲートウェイＷｅｂサーバが、利用者ＡのＵＩＤを利用者ＡがＷｅｂサービスＹのサーバより認証を受けた後、すなわちステップＳ１７０２において生成した。しかし、利用者ＡのＵＩＤの生成は、利用者ＡがＷｅｂサービスＸのサーバから認識票、知人の認識票と付加情報を得るステップＳ１２０３の後、ＵＩＤが存在しないことがわかった時点で生成してもよい。また、本実施形態では、ＷｅｂサービスＸおよびＷｅｂサービスＹに共通のゲートウェイＷｅｂサーバを用いたが、各々のサービスに別のゲートウェイＷｅｂサーバを用いてもよい。
（実施形態２）
【００６４】
これまで説明した実施形態１では、利用者Ｂは、セッションｎが開始される以前から、ＷｅｂサービスＹの利用者であると共に、ＷｅｂサービスＸの利用者でもあった。すなわち、セッションｎが開始される以前から、図７で示すＷｅｂサービスＸのサーバの認識票テーブル６０１および図１０で示すＷｅｂサービスＹのサーバの認識票テーブル９０１に、各々ＩＤｘｂおよびＩＤｙｂが存在した。本実施形態２では、セッションｎが開始される時点では、利用者Ａと利用者ＢはＷｅｂサービスＹ上で知人関係にあり、利用者ＡはＷｅｂサービスＸの利用者であったが、利用者ＤがＷｅｂサービスＸの利用者ではない場合の説明である。この場合、前記実施形態１のステップＳ１９０８で実行したように、ＷｅｂサービスＸ上で利用者Ａから利用者Ｄへのメッセージを送信することはできない。本実施形態２は、このような場合についても、利用者ＡがＷｅｂサービスＸにおいて利用者Ｄと知人になることができるための処理について説明する。
【００６５】
本実施形態２は、前記ステップＳ１９１０を出発点とし、図２５に示すフロー図を用いて説明する。本実施形態２は上記セッションｎの一部であり、ステップＳ１２０１からステップＳ１９０９までの処理を既に経ているところから始まる。ステップＳ１９０９が完了した時点で、利用者Ａの情報端末のＧＵＩ表示手段１１３には、図２１に示す画像が表示されている。このとき利用者Ａは、引き続きＷｅｂサービスＸにおける知人関係拡張サービスを利用する（ステップＳ１９１０）。
【００６６】
再び図２１を参照して、利用者Ａが入力手段１１４を操作して、ＧＵＩ表示手段１１３に表示されたカーソル１４３０を移動させ、Ａｄｄボタン２１２１に合わせた上、入力手段１１４の有するボタンを下押しするなどして、Ａｄｄボタン２１２１を選択することで、以下に説明する２つの処理が実行される。このとき、Ａｄｄボタン２１２１を下押しするかわりに、Ｗｅｂブラウザ１４００内で、表示されたｎａａｍというオブジェクト２１２２にカーソル１４３０を合わせた上、入力手段の有するボタンを下押しするなどして選択したまま、カーソル１４３０をＷｅｂサービスＸの知人一覧ウィンドウ１４１０内に移動させた上、選択を解除する、所謂ドラッグ・アンド・ドロップを実行しても、やはり以下に説明する２つの処理が実行される。この操作は、利用者ＡがこれまでＷｅｂサービスＹにおいてのみ知人関係にあった利用者Ｄと、ＷｅｂサービスＸにおいても知人関係になることを要求する操作である。この時利用者Ｄは、ＷｅｂサービスＸの利用者はなく、ＷｅｂサービスＸにおける認識票を有していない点が、上記実施形態１と異なる点である。
【００６７】
以上の操作によって、以下の２つの処理が実行される。第１の処理は利用者Ａの情報端末のＧＵＩ表示手段１１３への表示変更のための処理である。第２の処理は、利用者Ｄに対して、ＷｅｂサービスＸにおいても利用者Ａと知人関係になることについての同意を求めるための処理である。
【００６８】
まず、上記第1の処理について説明する。上記のようなＡｄｄボタン２１２１の下押し、
乃至はドラッグ・アンド・ドロップが実行されたという情報は送受信手段１１１によって、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送られる。送受信手段１０１はこの情報を受け取ると、ＨＴＭＬ生成手段１０２は、図２６に示すような画面を表示するための新たなＨＴＭＬコードを生成する。この新たなＨＴＭＬコードは送受信手段１０１およびネットワーク１９１を通じて利用者Ａの情報端末に送られる。送受信手段１１１がこれを受信すると、ＨＴＭＬ解析手段１１２がこれを解析した上、図２６に示す画像をＧＵＩ表示手段１１３のＷｅｂブラウザ１４００に表示する。
【００６９】
図２６に示す画面では、ＷｅｂサービスＸの知人一覧ウィンドウ１４１０中に、利用者ＡとＷｅｂサービスＹで知人関係にある、ＷｅｂサービスＹにおけるニックネームｎａａｍを有する利用者Ｄを表すオブジェクト２６１１が新たに追加された（ステップＳ２５０１）。利用者Ｄを表すオブジェクト２６１１には、確認中という文字列２６１２が表示される。これは確認中という文字列でなくとも、利用者ＤがＷｅｂサービスＸでも利用者Ａと知人関係になることを承諾する以前の状態であること意味する表示なら何でも良い。なお、図２６に示す一例では、ステップＳ２５０１の操作の結果、利用者Ｄを表すオブジェクト２６１１がサービスＸの知人一覧ウィンドウ１４１０に追加された。しかし、ウェブブラウザ１４００内に表示される、たとえば「サービスＸの知人に加えようとしている人」のような別のウィンドウに追加されてもよい。また、図２６に示す一例では、ステップＳ２５０１の操作の結果、図２１に示す利用者Ｄを表すオブジェクト２１２２が、図２６ではＷｅｂサービスＹの知人一覧ウィンドウ２０２０から消えているが、これは消えなくてもよい。
【００７０】
次に、上記第２の処理について説明する。上記ステップＳ２５０１におけるＡｄｄボタンの下押し、乃至はドラッグ・アンド・ドロップが実行されたという情報は、送受信手段１１１によって、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送られる。ゲートウェイＷｅｂサーバの送受信手段１０１がこれを受信すると、図１６を参照して、検索手段１０７が一時記憶手段のセッションｎのテーブル１３０１から上記ステップＳ２５０１で選択された認識票ＩＤｙｄ１６１５を有する利用者ＤのＵＩＤおよび暗号鍵を検索する。もしＵＩＤが存在しなければ、後述のステップＳ２５０８に進む。図１６に示す一例では、上記検索の結果ＵＩＤｄ１６３５およびＫｄ１６４５を得る（ステップＳ２５０３）。次に、送受信手段１０１はＵＩＤｄに関連づけられた暗号化認識票群の要求を、ネットワーク１９２を通じて暗号化認識票サーバ１７０に送る（ステップＳ２５０４）。
【００７１】
暗号化認識票サーバ１７０では、送受信手段５０１がこれを受信し、検索手段５０４が受信したＵＩＤｄを検索キーとして暗号化認識票テーブルを検索する。図１８を参照すると、ＵＩＤｄ１８３１が検出される。すると送受信手段５０１がＵＩＤｄ１８３１に関連づけられた暗号化認識票群Ｅｋｄ（ＩＤｙｄ−Ｙ、ＩＤｚｄ−Ｚ）１８３２を、ネットワーク１９２を通じて、ゲートウェイＷｅｂサーバに送る（ステップＳ２５０５）。ゲートウェイＷｅｂサーバの送受信手段１０１がこれを受信すると、復号化手段１０６が前記ステップＳ２５０３で得られた暗号鍵Ｋｄを用いて、受信したＥｋｄ（ＩＤｙｄ−Ｙ、ＩＤｚｄ−Ｚ）を復号化する。その結果、利用者Ｂの有する２つの認識票ＩＤｙｄおよびＩＤｚｄ、そしてこれらは各々ＷｅｂサービスＹおよびＷｅｂサービスＺの認識票であることを得る（ステップＳ２５０６）。以上の処理で、ＷｅｂサービスＹでＩＤｙｄを有する利用者Ｂが、ＷｅｂサービスＸの利用者でないことが判明する（ステップＳ２５０７）。
【００７２】
本実施形態２の場合、利用者ＤがＷｅｂサービスＸの利用者ないため、利用者ＡとＷｅｂサービスＸで知人関係になることを要求するメッセージを、ＷｅｂサービスＸを通じて利用者Ｄに送ることができない。そのため、このメッセージはＷｅｂサービスＹを通じて利用者Ｄに送る。次に、再び図１６を参照して、セッションｎのテーブル上のＩＤｙａ１６０２を発信者の認識票、ＩＤｙｂ１６１５を受信者の認識票としてメッセージ送信要求を、ネットワーク１９２を通じてＷｅｂサービスＹのサーバに送る（ステップＳ２５０８）。ここで要求するメッセージは、利用者Ａが利用者Ｄに対して、ＷｅｂサービスＸ上でも知人関係になることを要求するためのメッセージである。次に、ＷｅｂサービスＹのサーバの送受信手段１６１がこのメッセージ送信要求を受信し、記憶手段１６７に記憶する（ステップＳ２５０９）。
【００７３】
ここで示す例では、利用者ＡはここでＷｅｂサービスＸの知人関係拡張サービスを終了する。このため、利用者ＡのＷｅｂブラウザからのアクセスは、ＷｅｂサービスＸのサーバ１５０にリダイレクトされ（ステップＳ２５１０）、さらにゲートウェイＷｅｂサーバの一時記憶手段１０３にある、セッションｎのテーブル１３０１は消去され（ステップＳ２５１１）、セッションｎは終了する。
【００７４】
その後、利用者ＢがＷｅｂサービスＹにログインする（図２７、ステップＳ２７０１）。次に、ＷｅｂサービスＹのサーバのメッセージ生成手段１６６が、送信者を有する利用者Ａ、受信者を利用者Ｄとして、ＷｅｂサービスＸ上で知人関係になることを要求するためのメッセージを生成する。この時生成される送信者および受信者は、前期ステップＳ２５０９で記憶されたた認識票ＩＤｙａおよびＩＤｙｄを用いる。ここで生成されたメッセージは、ＨＴＭＬ生成手段１６５によってＨＴＭＬコードに変換される。送受信手段１６１が、このＨＴＭＬコードを、ネットワーク１９２および１９１を通じて利用者Ｄの情報端末１３０に送る（ステップＳ２７０２）。
【００７５】
次に、利用者Ｄの情報端末の送受信手段１３１がこのＨＴＭＬコードを受信すると、ＨＴＭＬ解析手段１３２がこれを解析の上、ＧＵＩ表示手段１３３に図２８に示す画像を表示する。ＧＵＩ表示手段１３３には、Ｗｅｂブラウザウィンドウ２８００が表示される（ステップＳ２７０３）。図２８に示す、Ｗｅｂブラウザウィンドウ２８００内には、利用者ＤとＷｅｂサービスＹで知人関係にある利用者Ａが、ＷｅｂサービスＸでも知人になりたいという意志を表明した旨の文章２８０１が表示される（ステップＳ２７０３）。また、この画面は非承諾ボタン２８１１および承諾ボタン２８１２が表示されている。前記ステップＳ２７０２でＷｅｂサービスＹのサーバのＨＴＭＬ作成手段１６５で作成されたＨＴＭＬコードにおいて、前記承諾ボタン２８１２には、ＷｅｂサービスＸのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）および利用者ＡのＷｅｂサービスＸにおける認識票ＩＤｘａが関連づけられている。ここで、利用者Ｄが入力手段１３４を用いて表示手段１３３に表示されたカーソル２８３０を移動させた上、承諾ボタン２８１２にあわせた上、入力手段のボタンを下押しするなどしてこれを選択する。次に、このＵＲＬをもとに、利用者Ｄの情報端末のＷｅｂブラウザ２８００は、ＷｅｂサービスＸのサーバ１５０にリダイレクトされ、さらに上記承認ボタン２８１２に関連づけられたＩＤｘａがＷｅｂサービスＸのサーバ１５０に受け渡される（ステップＳ２７０４）。
【００７６】
この時、利用者Ｄが既にＷｅｂサービスＸの利用者であれば、ＷｅｂサービスＸのサーバ１５０は、利用者Ｄに新規アカウントの作成のための画面を生成するＨＴＬＭコードを生成し、利用者Ｄの情報端末１３０に送る（ステップＳ２７０５）。利用者Ｄが新たにＷｅｂサービスＸの利用者になった場合には、ＷｅｂサービスＸのサーバの認識票データベース１５２の認識票テーブル６０１とソーシャルグラフテーブル６０２の両方に利用者Ｄの新たな行が追加される。利用者ＤがＷｅｂサービスＸにログインすると、この時点で、ＷｅｂサービスＸのサーバの認識票データベース１５２の、ソーシャルグラフテーブル６０２の、サービスＸの認識票ＩＤｘａ７１１の行のサービスＸで知人関係にある人の認識票の列８２０に、利用者Ｄの認識票ＩＤｘｄを追加する。また、ソーシャルグラフテーブル６０２のＩＤｘｄの行の、サービスＸで知人関係にある人の認識票の列８２０に利用者Ａの認識票ＩＤｘａを追加する。これらの処理によって、利用者Ａと利用者Ｄが新たにＷｅｂサービスＸで知人同士になった（ステップ２７０７）。
【００７７】
なお、上記実施形態１および実施形態２の両方で、ＷｅｂサービスＹは、電子メールサービスでもよい。この場合は、ＷｅｂサービスＹの各利用者の認識票は、各利用者の電子メールアドレスとなる。また、ＷｅｂサービスＹのサーバはメールサーバであり、またサーバより各利用者の情報端末に送られるのは、ＨＴＭＬコードではなく、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）やＩＭＡＰ（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）などの電子メール用のプロトコルに準拠したコードとなる。
【００７８】
次に、本願発明による作用効果について説明する。本願発明による方法、システム、サーバ装置、および情報端末によれば、以下に示すような利点がある。
【００７９】
始めに、Ｗｅｂサービス利用者にとっての利点について説明する。Ｗｅｂサービスの利用者は様々なＷｅｂサービスで知人関係を拡げることができる。たとえば、ＷｅｂサービスＸをチャットサービス、ＷｅｂサービスＹをＳＮＳサービスだとする。たとえば、利用者ＡはＳＮＳサービスで知人である利用者Ｂとチャットをしたいという潜在的な要求を持っているとする。各Ｗｅｂサービスが完全に独立している従来のシステムでは、この潜在的要求が顕在化することは希であった。しかし、本願発明の方法、システム、サーバ装置、および情報端末によれば、たとえば図２０に示すようなユーザインタフェイスによって、利用者Ａの上記要求を顕在化させ、ＷｅｂサービスＸ上での知人関係が拡大する可能性を大きくすることができる。このように、本願発明は、性質の異なる複数のＷｅｂサービス間で、利用者同士の知人関係を拡張することで、利用者に大きな利便性を提供できる。
【００８０】
次に、Ｗｅｂサービスを提供する事業者にとっての利点について説明する。Ｗｅｂサービス事業者にとっての、本願発明の利点はさらに２種類に分類できる。Ｗｅｂサービス提供事業者にとっての第１の利点は、既存の利用者によるＷｅｂサービス利用が促進されるという点である。これは、主として上記実施形態１に係る利点である。本願発明よる方法、システム、サーバ装置、および情報端末によれば、たとえば利用者ＡのＷｅｂサービスＸにおける知人は、従来のシステムによるＷｅｂサービスＸと比較して増える。ＷｅｂサービスＸにおける知人が増えれば、利用者Ａがより頻繁にＷｅｂサービスＸを利用する可能性が高くなる。一般にＷｅｂサービス事業者の収益は、利用者の利用頻度の増加に伴い増える傾向にある。従って、本願発明による方法、システム、サーバ装置、および情報端末を使うことで、Ｗｅｂサービス事業者はその収益を増大させることができる。
【００８１】
Ｗｅｂサービス提供事業者にとっての第２の利点は、新規の利用者を増やすことができるという点である。これは、主として上記実施形態２に係る利点である。上記実施形態２では、利用者ＤはＷｅｂサービスＸの利用者ではなかった。しかし、利用者Ｄは、図２８に示すような、ＷｅｂサービスＸに対する招待のメッセージを受け取ることで、新たにＷｅｂサービスＸの利用者になる可能性が高まる。一般にＷｅｂサービス事業者の収益は、利用者数の増大に伴い増える傾向にある。従って、本願発明による方法、システム、サーバ装置、および情報端末を使うことで、Ｗｅｂサービス事業者はその収益を増大させることができる。
【００８２】
従来の方法やシステムを使った場合、もし、ＷｅｂサービスＸの認識票テーブル６０１およびソーシャルグラフテーブル６０２、ＷｅｂサービスＹの認識票テーブル９０１およびソーシャルグラフテーブル９０２の情報を、各々のサーバで交換すれば、上記利用者にとっての利点および上記Ｗｅｂサービス提供事業者にとっての利点を実現することは可能であった。またＷｅｂサービスＸの提供業者でもＷｅｂサービスＹの提供事業者でもない第三者が運営する第三のサーバに、上記各テーブルの情報を集約することによっても、やはり上記利用者にとっての利点および上記Ｗｅｂサービス提供事業者にとっての利点を実現することは可能であった。しかし、上記各テーブルに格納された、利用者に関する情報や、利用者同士の知人関係の情報は、Ｗｅｂサービス提供事業者にとっての価値の源泉である場合が多く、これを他Ｗｅｂサービス提供事業者に渡すことや、第三者に渡すことは許されない場合が多い。
【００８３】
本願発明による方法、システム、サーバ装置、および情報端末では、各Ｗｅｂサービス提供事業者の利用者や利用者同士の知人関係についての情報を、他のＷｅｂサービス提供事業者や第三者のサーバに送り、そこで記憶することなしに、上記利用者やＷｅｂサービス提供事業者にとっての利点を実現することができる。以下について、このことについて詳しく説明する。
【００８４】
上記実施形態１や実施形態２が、上記記利用者やＷｅｂサービス提供事業者にとっての利点を実現していることは、すでに説明したとおりである。これを実現するために、ＷｅｂサービスＸのサーバＸが記憶する利用者に関する情報は、図７に示す認識票テーブル６０１および図８に示すソーシャルグラフテーブル６０２である。また、ＷｅｂサービスＹのサーバが記憶する利用者に関すおる情報は、図１０に示す認識票テーブル９０１および図１１に示すソーシャルグラフテーブル９０２である。これらの図からわかるように、ＷｅｂサービスＸのサーバには、ＷｅｂサービスＹの利用者の情報や知人関係は一切記憶されていない。また逆に、ＷｅｂサービスＹのサーバには、ＷｅｂサービスＸの利用者の情報や知人関係は一切記憶されていない。
【００８５】
本願発明による方法、システム、サーバ装置、および情報端末では、複数のＷｅｂサービスの認識票の関連づけを記憶するのは、暗号化認識票サーバ１７０である。いま、たとえばこの暗号化認識票サーバ１７０は、ＷｅｂサービスＸの提供事業者でも、ＷｅｂサービスＹの提供事業者でもない、第三の事業者によって管理されているものとする。図１８を参照すると、暗号化認識票サーバに記憶されているのは、ＵＩＤに関連づけられた暗号化された様々なＷｅｂサービスにおける認識票群１８２０である。ここで、図５を参照すると、暗号化された認識票群を復号化するための鍵は、暗号化認識票サーバには存在せず、復号化に必要な鍵は、ＷｅｂサービスＸまたはＷｅｂサービスＹのサーバに存在する。この第三の事業者が、ＷｅｂサービスＸやＷｅｂサービスＹの認識票を含む利用者のいかなる情報や知人関係も入手する方法はない。
【００８６】
ゲートウェイＷｅｂサーバ１００には、図１６に示す各Ｗｅｂサービスの利用者の認識票や知人関係が、一時記憶手段上に展開される。しかし、これらの情報が不揮発記憶手段に記憶されることはなく、セッション修了後には、一時記憶手段から削除される。このゲートウェイＷｅｂサーバ１００が、各Ｗｅｂサービスのサーバや、暗号化認識票サーバから独立した中立的サーバとして機能する。ゲートウェイＷｅｂサーバの運営者もまた、ＷｅｂサービスＸおよびＷｅｂサービスＹの利用者の認識票、付加情報、知人関係などを記憶したデータベースを保有する必要がない。
【００８７】
以上のように、本願発明によれば、複数のＷｅｂサービスの知人関係の相互利用が可能となるにも係わらず、これら各Ｗｅｂサービスのサーバに記憶された利用者の認識票、付加情報および知人関係などを、他のサービスのサーバに提供する必要がない。
【符号の説明】
【００８８】
１００ ゲートウェイＷｅｂサーバ
１１０ 利用者Ａの情報端末
１２０ 利用者Ｂの情報端末
１３０ 利用者Ｄの情報端末
１５０ ＷｅｂサービスＸのサーバ
１６０ ＷｅｂサービスＹのサーバ
１７０ 暗号化認識票サーバ
１９１ ネットワーク
１９２ ネットワーク
【技術分野】
【０００１】
本願発明は、サーバが連携してオンラインサービスを提供する情報処理に関する。
【背景技術】
【０００２】
様々なインターネットサービスが、数多くの事業者によって提供されている。最もよく使われるインターネットサービスは電子メールである。電子メールは、インターネット上で利用者を一意に特定する認識票として電子メールアドレスを用い、知人同士のコミュニケーション手段を提供するサービスである。一方近年、各Ｗｅｂサービス内で利用者を一意に特定する認識票を利用して、Ｗｅｂサービスの利用者間でのコミュニケーション手段を提供するサービスが数多く出現している。ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）、チャット、ブログなどがその例として挙げられる（特許文献１）。
【０００３】
このような、コミュニケーション手段を提供するサービスでは、各利用者が該当サービス上での知人を管理するための、知人一覧の機能が提供されている。たとえば、電子メールクライアントソフトウェア、Ｗｅｂ上の電子メール、ＳＮＳ、チャット、ブログなどには、知人一覧を管理する機能がある。各利用者はこれを、知人一覧を用いて、知人を管理し、新たな他の利用者を追加することで、コミュニケーションの範囲を拡げる。
【０００４】
一方、インターネットサービスを提供する事業者にとっては、自らの提供するサービス内で利用者が増加するほど、また知人関係が密になるほど、サービスの利用が促進され、事業的観点から見たサービスの価値が高まる。このため、サービス事業者は、利用者間の知人関係の拡張を目指す動機がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許第7,069,308号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
このような背景のもとで、インターネット上の各種サービスの利用者、およびこれらのサービスを提供する事業者の双方に、次のような課題が顕在化している。
【０００７】
利用者にとっての問題は、利用するサービスが増え、また各サービスでの知人が増えることによって、知人の管理が面倒になるという問題である。たとえば、ある利用者が電子メール、ＳＮＳ、チャット、ブログの４つのサービスを使っており、かつ各々のサービスに２０人の知人がいたとする。これらの知人は各々のサービスに付随した知人リストによって別々に管理されている。しかも、知人の中にはこれら４つのサービスの中の複数を使っている人がおり、サービスごとに異なる認識票を有し、あるいは異なる名前を名乗っている場合が多い。このような状況で、この利用者が知人を統一的に管理することは難しい。
【０００８】
一方、インターネットサービスを提供する各事業者は、自らの提供するサービス内で知人関係を増やし、さらに他サービスの利用者を自らの提供するサービスの利用者になるように誘導したいという意図を持っている。このためには、各インターネットサービス事業者の有する利用者の認識票、属性情報、知人関係などを、他のインターネットサービス事業者と融通または共有しあうことで、利用者を増やし、知人関係を拡張することができるようになる。したがって、このような認識票、属性情報、知人関係などの融通を、容易に実現する方法が必要とされている。
【０００９】
このような課題の解決に向けて、様々な試みがなされている。ＳＮＳを含む各種Ｗｅｂサービスでは、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）へのアクセスを外部に許可することで、Ｗｅｂサービス間で認識票、属性情報、知人関係などの相互融通を目指している。また、ＯｐｅｎＩＤとして知られている技術により、異なるＳＮＳを含むＷｅｂサービスに１つのログイン情報のみでログインすることを可能にする試みもなされている。
【００１０】
ネットワーク上の知人同士関係は、一般にソーシャルグラフと呼ばれる。上記のような、異なるＳＮＳを含むＷｅｂサービス間での相互融通の対象となる情報には、ソーシャルグラフが含まれる。最近では、これまで各Ｗｅｂサービス内で独立して保持されていたソーシャルグラフを、Ｗｅｂサービスを超えて融通し合うという試みがなされている。例えば、Ｓｏｃｉａｌ Ｇｒａｐｈ ＡＰＩなどとして知られている。Ｓｏｃｉａｌ Ｇｒａｐｈ ＡＰＩは、ある利用者の特定のＷｅｂサービスにおける認識票を与えると、戻り値としてその利用者の他のＷｅｂサービスにおける認識票を返す。また、ある利用者の特定のＷｅｂサービスにおける認識票を与えると、戻り値としてその利用者と様々なＷｅｂサービスにおいて知人関係にある利用者の、各々のＷｅｂサービスにおける認識票を返す。Ｗｅｂサービスを超えた、ソーシャルグラフの融通を促進する願いがある。
【００１１】
しかし、このような試みはいずれも広く普及しているとは言い難く、上記課題は未解決である。その理由は、ネットワークサービスを提供する事業者の事情にある。既に述べたように各事業者は、他のネットワークサービスの認識票、属性情報、知人関係などを利用したいという要求を持っている一方で、自らのネットワークサービスの認識票、属性情報、知人関係などを他のネットワークサービスの事業者に提供したくないという意図を持っている。一般に、利用者の情報やその知人関係は、ネットワークサービス事業者にとっての収益源であるとともに、利用者を他サービスではなく自らのサービスに引き込むための、最も重要な資産と考えられているからである。すなわち、各ネットワークサービス事業者は他のネットワークサービスとの連携を望む一方で、自らのネットワークサービスの独立性を維持したいという要求を持っている。このため、上記のようなＡＰＩで自らの利用者の情報を外部に公開するＡＰＩを提供するネットワークサービス事業者は少なく、またＯｐｅｎＩＤやＳｏｃｉａｌ Ｇｒａｐｈ ＡＰＩなどの標準規格は提案されるものの、これらに対応するネットワークサービスも増えないという状況にある。
【００１２】
このような状況に鑑み、本願発明によるサーバ、システム、情報端末、ネットワークでは、各ネットワークサービスの独立性を維持しつつ、かつ各々のサービスの有する知人関係を融通し合う。このことにより、利用者による知人関係の拡張を容易にするとともに、知人管理の利便性を高める。また、各ネットワークサービスは独立性を維持したまま、その価値の源泉たる知人関係の拡張が実現する。
【課題を解決するための手段】
【００１３】
本発明の一実施形態として、複数のサービスサーバと、管理サーバ装置と、前記複数のサービスサーバと前記管理サーバ装置と通信可能なゲートウェイサーバ装置とを備えるサービスシステムであって、複数のサービスサーバのいずれも、そのサービスサーバ内で利用者を識別する認識票に、そのサービスサーバの他の利用者の認識票である他人認識票を関係付けて記憶可能であり、さらに、前記認識票に、複数のサービスサーバ間で利用者を一意に識別可能な識別情報と、その識別情報ごとに生成された暗号鍵と、を関連付けて記憶可能であり、前記管理サーバ装置は、第１の列に、前記識別情報を格納し、第２の列に、前記複数のサービスサーバのうち、利用者が利用可能なサービスサーバである一又は複数の利用サービスサーバの識別子を、前記利用者の識別情報に関連付けられて前記複数のサービスサーバの一に記憶されている暗号鍵により暗号化した暗号化情報を格納するテーブルを記憶する記憶装置を有し、前記ゲートウェイサーバ装置は、第１の認識票に関係付けて第１のサービスサーバに記憶されている第１の他人認識票を前記第１のサービスサーバとの通信により受信する第１受信部と、前記第１受信部が受信した第１の他人認識票を、前記第１のサービスサーバの識別子に関連付けて一時テーブルに記憶する第１記憶部と、前記複数のサービスサーバの別の一つである第２のサービスサーバより、前記第１の認識票で識別される利用者を前記第２のサービスサーバ内にて識別する第２の認識票に関係付けて記憶されている第２の他人認識票を前記第２のサービスサーバとの通信により受信する第２受信部と、前記第２受信部が受信した第２の他人認識票を、前記第２のサービスサーバの識別子に関連付けて前記一時テーブルに記憶する第２記憶部と、前記通信において、前記第１の他人認識票が、前記第１のサービスサーバにおいて第１の認識票と第１の暗号鍵とに関連付けて記憶されている、と判断されると、前記第１の識別情報を前記管理サーバ装置へ送信する識別情報送信部と、前記第１の暗号鍵により前記第１のサービスサーバの識別子を含む情報を暗号化した暗号化情報を、前記識別情報送信部による前記第１の識別情報の送信に応じて、前記管理サーバ装置より受信する暗号化情報受信部と、前記受信された暗号化情報を前記第１の暗号鍵にて復号した結果に、前記第２のサービスサーバの識別子が含まれていなければ、前記第１の他人認識票により識別される利用者に対して、第１のメッセージを送信することを前記第１のサービスサーバに命令する第１命令部とを有することを特徴とするサービスシステムが開示される。
【００１４】
本発明の一実施形態として、複数のサービスサーバのいずれもそのサービスサーバにて利用者を認識する認識票に関連付けて、前記複数のサービスサーバにおいて前記利用者を一意に識別する識別情報と、前記識別情報ごとに生成された暗号鍵と、を記憶可能な前記複数のサービスサーバと通信が可能な管理サーバ装置であって、第１の列に、前記識別情報を格納し、第２の列に、前記複数のサービスサーバのうち、利用者が利用可能なサービスサーバである一又は複数の利用サービスサーバの識別子を、前記利用者の識別情報に関連付けられて前記複数のサービスサーバの一に記憶されている暗号鍵により暗号化した暗号化情報を格納するテーブルを記憶する記憶装置を備えることを特徴とする管理サーバ装置が開示される。
【００１５】
本発明の一実施形態として、複数のサービスサーバのいずれもそのサービスサーバ内で利用者を識別する認識票に、そのサービスサーバの他の利用者の認識票である他人認識票を関係付けて記憶可能であり、さらに、複数のサービスサーバ間で利用者を一意に識別可能な識別情報を関連付け、前記識別情報毎に生成された暗号鍵を記憶可能であるサービスサーバの一つである第１のサービスサーバより、第１の認識票に関連付けて記憶されている第１の他人認識票を前記第１のサービスサーバとの通信により受信する第１受信部と、前記第１受信部が受信した第１の他人認識票を、前記第１のサービスサーバの識別子に関連付けて一時テーブルに記憶する第１記憶部と、前記複数のサービスサーバの別の一つである第２のサービスサーバより、前記第１の認識票で識別される利用者を前記第２のサービスサーバ内にて識別する第２の認識票に関連づけて記憶されている第２の他人認識票を前記第２のサービスサーバとの通信により受信する第２受信部と、前記第２受信部が受信した第２の他人認識票を、前記第２のサービスサーバの識別子に関連付けて前記一時テーブルに記憶する第２記憶部と、前記通信において、前記第１受信部が受信した第１の他人認識票が、前記第１のサービスサーバにて第１の識別情報及び第１の暗号鍵に関連付けて記憶されている、と判断されると、前記第１の他人認識票に関連づけて記憶されている前記識別情報を送信する識別情報送信部と、前記第１の暗号鍵により前記第１のサービスサーバの識別子を含む情報を暗号化した暗号化情報を、前記識別情報送信部による前記第１の識別情報の送信に応じて、受信する暗号化情報受信部とを有することを特徴とするゲートウェイサーバ装置が開示される。
【発明の効果】
【００１６】
本願発明によれば、複数のインターネットサービスの知人関係の相互利用が可能となるにもかかわらず、これら各インターネットサービスのサーバに記憶された利用者の認識票、付加情報および知人関係などを、他のインターネットサービスのサーバに提供する必要がない。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態における制御システムの概略構成図である。
【図２】本発明の一実施形態における情報端末の概略構成図である。
【図３】本発明の一実施形態におけるサービスサーバの概略構成図である。
【図４】本発明の一実施形態におけるゲートウェイＷＥＢサーバ（ゲートウェイサーバ装置）の概略構成図である。
【図５】本発明の一実施形態における暗号化認識票サーバ（管理サーバ装置）の概略構成図である。
【図６】本発明の一実施形態においてサービスサーバが記憶するテーブル構成の一例図である。
【図７】本発明の一実施形態において認識票と、識別情報と、暗号鍵を関連付けて記憶するテーブルの一例図である。
【図８】本発明の一実施形態において一の認識票に他の認識票を関係づけて記憶するテーブルの一例図である。
【図９】本発明の一実施形態においてサービスサーバが記憶するテーブル構成の一例図である。
【図１０】本発明の一実施形態において認識票と、識別情報と、暗号鍵を関連付けて記憶するテーブルの一例図である。
【図１１】本発明の一実施形態において一の認識票に他の認識票を関係づけて記憶するテーブルの一例図である。
【図１２】本発明の一実施形態において利用者Ａが、そのＷｅｂサービスサーバＸにおける認識票に、他の利用者の認識票を関係付けるための処理を説明するフローチャートである。
【図１３】本発明の一実施形態におけるゲートウェイサーバ装置が一時テーブルを記憶している状態を示す図である。
【図１４】本発明の一実施形態において画面情報により、情報端末に表示される画面の一例図である。
【図１５】本発明の一実施形態において画面情報により、情報端末に表示される画面の一例図である。
【図１６】本発明の一実施形態におけるゲートウェイサーバ装置が記憶する一時テーブルの一例図である。
【図１７】本発明の一実施形態において管理サーバ装置が暗号化情報を記憶するための処理を説明するフローチャートである。
【図１８】本発明の一実施形態において管理サーバ装置の記憶装置が記憶する、第１と第２の列を有するテーブルの一例図である。
【図１９】本発明の一実施形態において利用者Ａが、そのＷｅｂサービスサーバＸにおける認識票に、他の利用者の認識票を関係付けるための処理を説明するフローチャートである。
【図２０】本発明の一実施形態における画面情報により、情報端末に表示される画面の一例図である。
【図２１】本発明の一実施形態における画面情報により、情報端末に表示される画面の一例図である。
【図２２】本発明の一実施形態において他の利用者に、その認識票を利用者Ａの認識票に関係づけることの可否を尋ねる処理を説明するフローチャートである。
【図２３】本発明の一実施形態において他の利用者の認識票を利用者Ａの認識票に関係づけることの可否を尋ねる画面の一例図である。
【図２４】本発明の一実施形態において利用者Ａの認識票に関係付けられた認識票を表示する画面の一例図である。
【図２５】本発明の一実施形態において利用者Ａが、そのＷｅｂサービスサーバＸにおける認識票に、他の利用者の認識票を関係付けるための処理を説明するフローチャートである。
【図２６】本発明の一実施形態において利用者Ａの認識票に関係付けられた認識票を表示する画面の一例図である。
【図２７】本発明の一実施形態において利用者Ａが、そのＷｅｂサービスサーバＸにおける認識票に、他の利用者の認識票を関係付けるための処理を説明するフローチャートである。
【図２８】本発明の一実施形態において他の利用者の認識票を利用者Ａの認識票に関係づけることの可否を尋ねる画面の一例図である。
【発明を実施するための形態】
【００１８】
以下に本発明を実施するための、現在考えられる最善の形態について説明する。本願発明の範囲は、添付の特許請求の範囲によって明確に定義されているため、この説明は限定的な意味に解釈すべきではなく、単に発明の一般原理を例示する目的で行う。
（実施形態１）
【００１９】
図１は、本発明の実施形態の一例である、情報の表示および制御システムの概略構成図である。ゲートウェイＷｅｂサーバ１００が、ＷｅｂサービスＸのサーバ１５０およびＷｅｂサービスＹのサーバ１６０、および暗号化認識票サーバ１７０と、ネットワーク１９２を通じて接続されている。また、ゲートウェイサーバ１００はネットワーク１９１を通じて利用者Ａの情報端末１１０、利用者Ｂの情報端末１２０、および利用者Ｄの情報端末１３０と接続されている。ネットワーク１９１と１９２は、異なるネットワークでも同じネットワークでもよい。
【００２０】
図２に、利用者Ａの情報端末、利用者Ｂの情報端末および利用者Ｄの情報端末の概略構成図を示す。利用者Ａの情報端末１１０は、送受信手段１１１、ＨＴＭＬＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）解析手段１１２、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）表示手段１１３、および入力手段１１４を有する。利用者Ｂの情報端末１２０は、送受信手段１２１、ＨＴＭＬ解析手段１２２、ＧＵＩ表示手段１２３、および入力手段１２４を有する。利用者Ｄの情報端末１３０は、送受信手段１３１、ＨＴＭＬ解析手段１３２、ＧＵＩ表示手段１３３、および入力手段１３４を有する。
【００２１】
図３に、ＷｅｂサービスＸのサーバおよびＷｅｂサービスＹのサーバの概略構成図を示す。ＷｅｂサービスＸのサーバ１５０（以下サーバＸと呼ぶ）は、送受信手段１５１、サービスＸのデータベース１５２（以下データベースＸと呼ぶ）、認証手段１５３、検索手段１５４、ＨＴＭＬ生成手段１５５、メッセージ生成手段１５６、および記憶手段１５７を有する。ＷｅｂサービスＹのサーバ１６０（以下サーバＸと呼ぶ）は、送受信手段１６１、サービスＹのデータベース１６２（以下データベースＹと呼ぶ）、認証手段１６３、検索手段１６４、ＨＴＭＬ生成手段１６５、メッセージ生成手段１６６、および記憶手段１６７を有する。
【００２２】
図４に、ゲートウェイＷｅｂサーバの概略構成図を示す。ゲートウェイＷｅｂサーバ１００は、送受信手段１０１、ＨＴＭＬ生成手段１０２、一時記憶手段１０３、ＵＩＤ生成手段１０４、暗号化手段１０５、復号化手段１０６、検索手段１０７、および暗号鍵生成手段１０８を有する。
【００２３】
図５に、暗号化認識票サーバの概略構成図を示す。暗号化認識票サーバ１７０は、送受信手段５０１、暗号化認識票テーブル５０２、ＵＩＤ生成手段５０３、および検索手段５０４を有する。
【００２４】
図６にデータベースＸ１５２の有するテーブルを示す。データベースＸ１５２は、認識票テーブル６０１およびソーシャルグラフテーブル６０２、および認証テーブル６０３を有する。認識票テーブル６０１には、ＷｅｂサービスＸの個々の利用者を一意に特定するための認識票が、各々の利用者の属性情報、利用者ユニーク認識票（以下ＵＩＤ）、および暗号鍵と関連づけて記憶されている。また、ソーシャルグラフテーブル６０２には、ＷｅｂサービスＸにおける知人関係が記憶されている。
【００２５】
図７に、本実施形態における認識票テーブル６０１の一例を示す。認識票テーブル６０１は、ＷｅｂサービスＸにおいて各利用者を一意に特定する認識票７１０、属性１として各利用者の名前７２０、および属性２として各利用者の誕生月７３０、ＵＩＤ７４０、暗号鍵７５０の各列を有する。属性の数はいくつででも、また無くてもよい。属性情報は、各利用者に関連づけられた情報ならどのような情報であってもよい。また、図８にソーシャルグラフテーブル６０２の一例を示す。ソーシャルグラフテーブル６０２は、ＷｅｂサービスＸにおいて各利用者を一意に特定する認識票と８１０と、各利用者の知人関係にある利用者の認識票８２０、の２列を有する。さらに、認証テーブル６０３は、各利用者の認識票に関連づけて、パスワードなどの認証用情報が記憶されている。
【００２６】
図９にデータベースＹ１６２の有するテーブルを示す。データベースＹ１６２は、認識票テーブル９０１、ソーシャルグラフテーブル９０２、および認証テーブル９０３を有する。認識票テーブル９０１には、ＷｅｂサービスＹの各利用者を一意に特定するための認識票が、各々の利用者の属性情報、ＵＩＤおよび暗号鍵と関連づけて記憶されている。また、ソーシャルグラフテーブル９０２には、ＷｅｂサービスＹ内の知人関係が記憶されている。
【００２７】
図１０に認識票テーブル９０１の一例を示す。認識票テーブル９０１は、ＷｅｂサービスＹにおいて各利用者を一意に特定する認識票と１０１０、属性１として各利用者のニックネーム１０２０、属性２として各利用者の年齢１０３０、ＵＩＤ１０４０、および暗号鍵１０５０の各列を有する。属性の数はいくつででも、また無くてもよい。属性情報は、各利用者に関連づけられた情報ならどのような情報であってもよい。また、図１１にソーシャルグラフテーブル９０２の一例を示す。ＷｅｂサービスＸにおいて各利用者を一意に特定する認識票と１１１０と、各利用者の知人関係にある利用者の認識票１１２０、の２列を有する。さらに、認証テーブル９０３は、各利用者の認識票に関連づけて、パスワードなどの認証用情報が記憶されている。
【００２８】
なお、本明細書において、認識票はすべてＩＤｍｎという形式で表示する。ここでｍはこの認識票によって利用者を一意に特定するＷｅｂサービスの名前、ｎは利用者を表す。たとえば、ＩＤｘａはＷｅｂサービスＸにおける利用者Ａの認識票を表す。同様にＩＤｙａはＷｅｂサービスＹにおける利用者Ａの認識票を表す。この場合、利用者ＡはＷｅｂサービスＸおよびＷｅｂサービスＹの両方の利用者である。現実には、ＷｅｂサービスＸとＷｅｂサービスＹの認識票は各々独立しており、利用者ＡがＷｅｂサービスＸとＷｅｂサービスＹの両方を使っているという事実を、ＷｅｂサービスＸのサーバやＷｅｂサービスＹのサーバが検出する方法はないが、本願発明の内容を明確化するために、本明細書ではこのような表記方法を採用する。
【００２９】
次に、図１２のフロー図を用いて、本願発明によるサーバ、情報端末およびシステムによって、利用者ＡがＷｅｂサービスＸにおける知人を増やす処理について説明する。
【００３０】
いま、利用者Ａがその情報端末１１０を通じてＷｅｂサービスＸを利用している。このとき、ＷｅｂサービスＸのサーバのＨＴＭＬ生成手段１５５によって生成され、送受信手段１５１およびネットワーク１９２およびネットワーク１９１を通じて利用者Ａの情報端末に送られたＨＴＭＬコードが、ＨＴＭＬ解析手段１１２によって解析された結果が、ＧＵＩ表示手段１１３に表示される。これに先立ち、利用者Ａは、その情報端末１１０からＷｅｂサービスにおける認識票ＩＤｘａおよびパスワードをＷｅｂサービスＸのサーバに送り、認証手段１５３が、利用者Ａの情報端末１１０からのアクセスであることを認証している。
【００３１】
次に、利用者ＡはＷｅｂサービスＸに含まれる、本願発明による知人関係拡張サービスを選択する（ステップＳ１２０１）。これは、利用者ＡがＷｅｂサービスＸの画面に表示された知人関係拡張サービスボタンを選択することなどによって実行される。ここで、以下で述べる知人関係拡張サービスのセッションｎが開始される。上記のようにＷｅｂサービスＸはＷｅｂサービスＸのサーバ１５０によって提供されるが、ＷｅｂサービスＸの一部である知人関係拡張サービスは、ゲートウェイＷｅｂサーバ１００によって提供される。すなわち、利用者Ａがその情報端末の入出力手段によって知人関係拡張サービスを選択すると、その要求がネットワーク１９１および１９２を通じてＷｅｂサービスＸのサーバ１５０に送られると、送受信手段１５１がこれをゲートウェイＷｅｂサーバにリダイレクトする（ステップＳ１２０２）。次に、ＷｅｂサービスＸの検索手段１５４が、利用者Ａの認識票ＩＤｘａ７１１を検索キーとして、データベースＸ１５２のソーシャルグラフテーブル６０２を検索し、ＩＤｘｃ８２１、ＩＤｘｅ８２２およびＩＤｘｆ８２３を得る。これは、ＷｅｂサービスＸにおいて、利用者Ａは利用者Ｃ、Ｅ、およびＦと知人関係にあることを示している。さらに検索手段１５４はこのＩＤｘｃ、ＩＤｘｅおよびＩＤｘｆで、データベースＸ１５２の認識票テーブル６０１を検索し、利用者Ｃ、Ｅ、およびＦの名前を得る。各々の名前はＤｉｃｋ Ｃｈｉｎｇ７２３、Ｌａｕｒａ Ｓｍｉｔｈ７２４、Ｓｔｅｖｅ Ｂｕｓｈ７２５である。次に、ＷｅｂサービスＸのサーバの送受信手段１５１は、利用者Ａの認識票ＩＤｘａ、および知人関係にある利用者Ｃ、Ｄ、およびＥの各々の認識票および名前を、ゲートウェイＷｅｂサーバ１００に送る。また、利用者Ａの利用者ユニーク認識票（以下ＵＩＤと呼ぶ）が存在する場合には、これもＩＤｘａと関連づけてゲートウェイＷｅｂサーバに送る（ステップＳ１２０３）。存在しない場合は送らない。図７を参照すると、ＩＤｘａ７１１に対応するＵＩＤは、ＵＩＤの列７４０に存在しない７４１ので、送らない。さらに、知人関係にある利用者Ｃ、Ｅ、およびＦの中でＵＩＤおよび暗号鍵が存在する利用者については、ＵＩＤおよび暗号鍵を各々の認識票に関連づけて、ゲートウェイＷｅｂサーバに送る。存在しない場合は送らない。図７を参照すると、上記検索で得られたＩＤｘｃ、ＩＤｘｅ、およびＩＤｘｆのうちで、ＩＤｘｃおよびＩＤｘｆに各々ＵＩＤと暗号鍵が存在するので、これらＵＩＤｃ７４３、Ｋｃ７５３、ＵＩＤｆ７４５、Ｋｆ７５５もゲートウェイＷｅｂサーバに送る。ここでＵＩＤとは、複数のＷｅｂサービスを跨いで、各利用者を一意に特定するための認識票である。ＵＩＤについては、後に詳しく説明する。本明細書では、ＵＩＤｍという表記は、利用者ＭのＵＩＤであることを表す。
【００３２】
次に、これらの情報をゲートウェイＷｅｂサーバの送受信手段１０１が受信し、一時記憶手段１０３に記憶する（ステップＳ１２０４）。一時記憶手段１０３は、知人関係拡張サービスのセッションごとに、一時的に情報を記憶するための手段であり、各セッションが終了すると消去される。一般的にはＤＲＡＭ（Ｄｉｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）によりなるコンピュータの主記憶手段などが一時記憶手段として使われることが多いが、各セッションが終了する度にその内容が消去されれば、一時記憶手段がどのような装置で実現されていてもよい。図１３に、一時記憶手段の構成の一例を示す。
【００３３】
一時記憶手段１０３には、セッションごとにテーブルが作成される。ゲートウェイサーバは、複数のセッションを並行することができる。このため図１３に示すように、任意の瞬間において、一時記憶手段１０３には、零を含む任意の数のテーブルが存在する。各々のテーブルはセッションが実行されている間は一時記憶手段１０３に記憶されるが、セッションが終了すると消去される。上記ステップＳ１２０４でＷｅｂサービスＸのサーバより受信した情報は、図１３におけるセッションｎのテーブル１３０１に記憶される。
【００３４】
次に、ゲートウェイＷｅｂサーバのＨＴＭＬ生成手段１０２は、上記ステップＳ１２０４で一時記憶手段１０３に記憶した、利用者ＡとＷｅｂサービスＸで知人関係にある利用者Ｃ、利用者Ｅ、および利用者Ｆの名前を含むＨＴＭＬコードを生成し、送受信手段１０１がネットワーク１９１を通じて利用者Ａの情報端末１１０に送る。利用者Ａの情報端末では、送受信手段１１１がこれを受信し、ＨＴＭＬ解析手段１１２がこれを解析した後、ＧＵＩ表示手段１１３に図１４に示す画像を表示する（ステップＳ１２０５）。図１４では、ＧＵＩ表示装置１１３上に、Ｗｅｂブラウザウィンドウ１４００が表示される。このＷｅｂブラウザウィンドウ１４００内には、ＷｅｂサービスＸ内の、知人関係拡張サービスが表示される。知人関係拡張サービスは、ＷｅｂサービスＸの一部である。Ｗｅｂブラウザ１４００内に表示された画像は、ＷｅｂサービスＸの知人一覧１４１０および外部サービス一覧１４２０の２つのウィンドウを有する。
【００３５】
まず、ＷｅｂサービスＸの知人一覧１４１０について説明する。ＷｅｂサービスＸの知人一覧１４１０には、利用者ＡがＷｅｂサービスＸで知人関係にある利用者Ｃ、Ｅ、およびＦの各々の名前の一覧が表示されている。図１４に示した、Ｄｉｃｋ Ｃｈｉｎｇ１４１１、Ｌａｕｒａ Ｓｍｉｔｈ１４１２、およびＳｔｅｖｅ Ｂｕｓｈ１４１３は、各々利用者Ｃ、Ｅ、およびＦの、ＷｅｂさービスＸにおける名前である。また、名前の左に表示されたマーク１４１９は、これらの名前がＷｅｂサービスＸにおける知人であることを表している。
【００３６】
再び図１４を参照して、Ｗｅｂブラウザ１４００内に表示された、外部サービス一覧ウィンドウ１４２０について説明する。外部サービスとは、利用者Ａが使うＷｅｂサービスＸ以外のＷｅｂサービスである。図１４に示す一例では、外部サービス一覧ウィンドウ１４２０は、利用者ＡがＷｅｂサービスＹの知人関係をＷｅｂサービスＸに持ち込むためのボタン１４２１、同様にＷｅｂサービスＷの知人関係をＷｅｂサービスＸに持ち込むためのボタン１４２２、およびＷｅｂサービスＺの知人関係をＷｅｂサービスＸに持ち込むためのボタン１４２３、の３つのボタンを有する。図７および図１０からわかるように、利用者ＡはＷｅｂサービスＸの利用者であると同時にＷｅｂサービスＹの利用者でもある。
【００３７】
利用者Ａは、その情報端末の入出力手段１１４を通じて、ＧＵＩ表示手段１１３に表示されたカーソル１４３０を移動させ、ＷｅｂサービスＹと連携させるためのボタン１４２１に合わせた上、入力手段１１４の有するボタンを下押しするなどしてＷｅｂサービスＹを選択する（ステップＳ１２０６）。すると、利用者Ａの情報端末の送受信手段１１１は、ＷｅｂサービスＹにおける利用者Ａの認証要求を、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送る。更にゲートウェイサーバの送受信手段１０１はこの認証要求を受信した後これを転送し、ネットワーク１９２を通じて、ＷｅｂサービスＹのサーバ１６０に送る。ここで、利用者Ａの情報端末のウェブブラウザ１４００の画面は、ゲートウェイＷｅｂサーバ１００からＷｅｂサービスＹのサーバ１６０にリダイレクトされる（ステップＳ１２０７）。ＷｅｂサービスＹの送受信手段１６１が上記認証要求を受信すると、ＨＴＭＬ生成手段１６５は、利用者Ａの情報端末１１０が認識票ＩＤｙａを持つ利用者Ａのものであることを認証するための入力画面のＨＴＭＬコードを生成する。送受信手段１６１が、ＨＴＭＬコードをネットワーク１９２およびネットワーク１９１を通じて
利用者Ａの情報端末１１０に送る。このＨＴＭＬコードは、利用者Ａの送受信手段１１１を通じてＨＴＭＬ解析手段１１２に送られ、解析された後、ＧＵＩ表示手段１１３によって表示される（ステップＳ１２０８）。
【００３８】
図１５は、このとき利用者Ａの情報端末のＧＵＩ表示手段１１３に表示された画面の一例である。Ｗｅｂブラウザ１４００に表示されたＷｅｂサービスＹの認証画面は、認識票の入力欄１５０１、およびパスワードの入力欄１５０２、および入力完了ボタン１５０３を有する。利用者Ａが入出力手段１１４によってＷｅｂサービスＹにおける利用者Ａの認識票ＩＤｙａをＩＤ入力欄１５０１に、またパスワードをパスワード入力欄１５０２に入力した後、カーソル１４３０を入力完了ボタン１５０３の位置まで移動させた上、入力手段１１４のボタンを下押しするなどして選択する。
【００３９】
ここで入力された利用者Ａの認識票およびパスワードは、認証要求とともに、送受信手段１１１、ネットワーク１９１およびネットワーク１９２を通じてＷｅｂサービスＹのサーバ１６０に送られる（ステップＳ１２０９）。送受信手段１６１がこれらを受信すると、これを認証手段１６３に送る。認証手段１６３は、入力された受信した認識票ＩＤｙａを検索キーとして、データベースＹ１６２にある認証テーブル９０３を検索し、ＩＤｙａに関連づけられたパスワード情報を得た上、ステップＳ１２０９で受信したパスワードとの一致を検出する。ここに示す一例では、認識票とパスワードによる認証を用いて説明したが、ステップＳ１２０９による認証要求が、利用者Ａ自身によるものである、または利用者Ａの情報端末１１０からのものであることが確認できる認証方法であれば、どのような認証方法でもよい。
【００４０】
上記パスワードの一致が検出されると、次に認証された利用者Ａの認識票ＩＤｙａを検索キーとして、データベースＹ１６２のソーシャルグラフテーブル９０２を検索する。図１１を参照すると、ＩＤｙａ１１１１が検索される。次に、このＩＤｙａ１１１１に関連づけられた認識票ＩＤｙｂ１１２１およびＩＤｙｄ１１２２を検索キーとして、認識票テーブル９０１を検索する。図１０を参照すると、認識票ＩＤｙｂ１０１２およびＩＤｙｄ１０１３が検出される。次に、送受信手段１６１が、認識票ＩＤｙａをネットワーク１９２を通じてゲートウェイＷｅｂサーバ１００に送る。また、同時に認識票テーブル９０１で上記認識票ＩＤｙｂおよびＩＤｙｄに各々関連づけられたニックネームｎｉｋｋｉ１０２２およびｎａａｍ１０２３を各々の認識票と関連づけた状態で、ゲートウェイＷｅｂサーバ１００に送る。ステップＳ１２０３と同様に、認識票テーブル９０１において、もしＩＤｙａに関連づけられたＵＩＤが存在すれば、そのＵＩＤもＩＤｙａと関連づけてゲートウェイＷｅｂサーバ１００に送る（ステップＳ１２１０）。図１０に示すように、ここに示す一例では、ＩＤｙａに対応するＵＩＤ１００１は存在しないので、送らない。また、図１０を参照して、上記の検索結果のうちで、認識票ＩＤｙｂ１０１２に関連づけられたＵＩＤであるＵＩＤ１０４２および暗号鍵Ｋｂ１０５２、および認識票ＩＤｙｄに関連づけられたＵＩＤ１０４３およびＫｄ１０５３も、ゲートウェイＷｅｂサーバ１００に送る。
【００４１】
次に、これらの情報をゲートウェイＷｅｂサーバの送受信手段１０１が受信し、一時記憶手段１０３のセッションｎのテーブルに記憶する（ステップＳ１２１１）。既に述べたように、一時記憶手段１０３は、知人関係拡張サービスのセッションごとに、一時的に記憶するための手段であり、各セッションが終了すると消去される。
【００４２】
前記ステップＳ１２１１が完了した段階で、ゲートウェイＷｅｂサーバの一時記憶手段１０３にあるこのセッションnのテーブル１３０１を図１６に示す。ただし、本実施形態に
示す一例では、上記ステップＳ１２０４およびＳ１２１１で、利用者ＡのＵＩＤは、セッションｎのテーブル１３０１には記憶されていないので、図１６に示すＵＩＤａ１６００
はこの時点では空白であり、図１６の状態になるのは、下記ステップＳ１７０３においてである。ここでＩＤｘａ１６０１に関連付けられて記憶されている知人の認識票ＩＤｘｃ１６１１、ＩＤｘｅ１６１２、ＩＤｘｆ１６１３、およびさらにこれら各認識票に関連づけられた名前、ＵＩＤおよび暗号鍵は、上記ステップＳ１２０４において、ＷｅｂサービスＸのサーバより受信した情報である。また、ＩＤｙａ１６０２に関連付けられて記憶されている知人の認識票ＩＤｙｂ１６１４、ＩＤｙｄ１６１５、およびさらにこれら各認識票に関連づけられたニックネーム、ＵＩＤおよび暗号鍵は、上記ステップＳ１２１１において、ＷｅｂサービスＸのサーバより受信した情報である。
【００４３】
次に図１７に示すフロー図を用いて、ＷｅｂサービスＸにおける認識票ＩＤｘａとＷｅｂサービスＹにおける認識票ＩＤｙａが同じ利用者Ａの有するものであることを、本願発明の方法によって暗号化認識票サーバ１７０に記憶する処理について説明する。上記のように、ステップＳ１２０４およびＳ１２１１で利用者ＡのＵＩＤを受信していないので、まず利用者Ａ、すなわち認識票ＩＤｘａ１６０１およびＩＤｙａ１６０２に対応するＵＩＤの発行要求を、暗号化認識票サーバ１７０に、ネットワーク１９２を通じて送る（ステップＳ１７０１）。暗号化認識票サーバの送受信手段５０１がこれを受信すると、ＵＩＤ生成手段５０３が、暗号化認識票テーブル５０２を検索し、まだ存在しない新しいＵＩＤを生成する。次に送受信手段６０１がこの新しいＵＩＤを利用者ＡのＵＩＤとして、ネットワーク１９２を通じてゲートウェイＷｅｂサーバ１００に送る。（ステップＳ１７０２）。図１８に暗号化認識票テーブル５０２の一例を示す。暗号化認識票テーブル５０２は、ＵＩＤの列１８１０と暗号化認識票群１８２０の２つの列を有する。この一例では、ＵＩＤ生成手段５０３は、新たなＵＩＤとしてＵＩＤａを生成する。上記ステップＳ１７０２では、ＵＩＤ生成手段５０３がＵＩＤの列１８１０にないＵＩＤを生成する。暗号化認識票群の列１８２０については後で説明する。
【００４４】
ゲートウェイＷｅｂサーバの送受信手段１０１が新たなＵＩＤａを受信し、一時記憶手段１０３のセッションｎのテーブル１３０１で、空白であったＵＩＤ欄１６００にＵＩＤａを記憶する（ステップＳ１７０３）。次に、ゲートウェイＷｅｂサーバの暗号鍵生成手段１０８が、ＵＩＤａ用の暗号鍵、すなわち利用者Ａの暗号鍵Ｋａを生成する（ステップＳ１７０４）。次に送受信手段１０１がＵＩＤａおよびＫａを、ネットワーク１９２を通じてＷｅｂサービスＸのサーバ１５０およびＷｅｂサービスＹのサーバ１６０に送る（ステップＳ１７０５）。ＷｅｂサービスＸのサーバでは、送受信手段１５１がこれを受信し、データベースＸにある認識票テーブルに記憶する（ステップＳ１７０６）。図７を参照して、記憶する場所は、ＵＩＤａが欄７４１、またＫａが欄７５１である。同様に、ＷｅｂサービスＹのサーバでは、送受信手段１６１がこれを受信し、データベースＸにある認識票テーブル９０１に記憶する。図１０を参照して、記憶する場所は、ＵＩＤａが欄１０４１、またＫａが欄１０５１である。
【００４５】
次に暗号化手段１０５が、一時記憶手段のセッションｎのテーブル１３０１に記憶されているＩＤｘａ１６０１とそれがＷｅｂサービスＸの認識票であることを表すＸ、さらにＩＤｙａ１６０２とそれがＷｅｂサービスＹの認識票であることを表すＹとを関連づけた状態で、上記ステップＳ１７０４で生成した暗号鍵Ｋａで暗号化する（ステップＳ１７０７）。ここで暗号化したものをＥｋａ（ＩＤｘａ−Ｘ、ＩＤｙａ−Ｙ）と表記する。次に送受信手段１０１がＵＩＤａとＥｋａ（ＩＤｘａ−Ｘ、ＩＤｙａ−Ｙ）をネットワーク１９２を通じて暗号化認識票サーバ１７０に送る。暗号化認識票サーバの送受信手段５０１がこれを受信し、暗号化認識票テーブル５０２の新たな行に追加し、ＵＩＤａ１８１１とＥｋａ（ＩＤｘａ−Ｘ、ＩＤｙａ−Ｙ）１８１２を関連づけて保存する（ステップＳ１７０８）。
【００４６】
本実施形態で示す一例では、利用者ＢのＵＩＤｂと暗号鍵Ｋｂが、ＷｅｂサービスＸのサーバの認識票テーブル６０１、およびＷｅｂサービスＹのサーバの認識票テーブル９０１に、セッションｎが開始される以前から記憶されていた。これは、利用者Ｂがセッションｎの開始以前、利用するＷｅｂサービスＸまたはＷｅｂサービスＹにおいて、知人関係拡張サービスを利用して、ステップＳ１７０６までと同様の処理を実行し、図１７に相当する処理を実行した結果である。ここで説明した図１７の処理は、セッションｎにおいてではなく、セッションｎ以降のセッションにおいて、利用者Ａまたは他の利用者がゲートウェイＷｅｂサービスを利用した知人関係拡張サービスを利用する際に使う。
【００４７】
続いて、図１９のフロー図を用いて、利用者ＡがゲートウェイＷｅｂサーバ１００を使ったＷｅｂサービスＸの知人関係拡張サービスの処理について説明を続ける。利用者Ａの情報端末のウェブブラウザ１４００の画面は、ＷｅｂサービスＹのサーバ１６０からゲートウェイＷｅｂサービスのサーバ１００にリダイレクトされる（ステップＳ１９０１）。次に、ＨＴＭＬ生成手段１０２が図１６に示す状態のセッションｎのテーブル１３０１をから図２０の画面を生成するＨＴＭＬコードを生成し、これを送受信手段１０１が利用者Ａの情報端末１１０にネットワーク１９２を通じて送る。利用者Ａの情報端末では、これを送受信手段１１１が受信し、ＨＴＭＬ解析手段１１２によって解析された後、ＧＵＩ表示手段１１３のＷｅｂブラウザ１４００内に表示される（ステップＳ１９０２）。
【００４８】
図２０に、利用者Ａの情報端末のＧＵＩ表示手段１１３に表示された画像を示す。Ｗｅｂブラウザ１４００内には、既に図１４で説明したサービスＸの知人一覧ウィンドウ１４１０とともに、ＷｅｂサービスＹの知人一覧ウィンドウ２０２０が表示されている。ＷｅｂサービスＹの知人一覧ウィンドウには、ｎｉｋｋｉ２０２１およびｎａａｍ２０２２が表示されている。これらは、ゲートウェイＷｅｂサーバ１００の一時記憶手段にあるセッションｎのテーブル上の情報がＨＴＭＬコードとして受信したものを表示している。図２０において、マーク２０２９は、表示された利用者がＷｅｂサービスＹの利用者であることを表している。図１６からわかるように、ｎｉｋｋｉ２０２１は、ＷｅｂサービスＹの認識票ＩＤｙｂを有する利用者Ｂのニックネームであり、またｎａａｍ２０２２は、ＷｅｂサービスＹの認識票ＩＤｙｄを有する利用者Ｄのニックネームである。
【００４９】
次に、利用者Ａが入力手段１１４を操作して、ＧＵＩ表示手段１１３に表示されたカーソル１４３０を移動させ、Ａｄｄボタン２０２５に合わせた上、入力手段１１４の有するボタンを下押しするなどして、Ａｄｄボタン２０２５を選択することで、以下に説明する２つの処理が実行される。このとき、Ａｄｄボタン２０２５を下押しするかわりに、Ｗｅｂブラウザ１４００内で、表示されたｎｉｋｋｉというオブジェクト２０２１にカーソル１４３０を合わせた上、入力手段の有するボタンを下押しするなどして選択したまま、カーソル１４３０をＷｅｂサービスＸの知人一覧ウィンドウ１４１０内に移動させた上、選択を解除する、所謂ドラッグ・アンド・ドロップを実行しても、やはり以下に説明する２つの処理が実行される（ステップＳ１９０３）。この操作は、利用者ＡがこれまでＷｅｂサービスＹにおいてのみ知人関係にあった利用者Ｂと、ＷｅｂサービスＸにおいても知人関係になることを要求する操作である。本実施形態１においては、利用者Ｂは、ＷｅｂサービスＸの利用者であり、認識票ＩＤｘｂを既に有している。ただし、利用者Ａはこれを知らない。
【００５０】
以上の操作によって、以下の２つの処理が実行される。第１の処理は利用者Ａの情報端末のＧＵＩ表示手段１１３への表示変更のための処理である。第２の処理は、利用者Ｂに対して、ＷｅｂサービスＸにおいても利用者Ａと知人関係になることについての同意を求めるための処理である。
【００５１】
まず、上記第1の処理について説明する。上記のようなＡｄｄボタン２０２５の下押し、乃至はドラッグ・アンド・ドロップが実行されたという情報は送受信手段１１１によって、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送られる。送受信手段１０１はこの情報を受け取ると、ＨＴＭＬ生成手段１０２は、図２１に示すような画面を表示するための新たなＨＴＭＬコードを生成する。この新たなＨＴＭＬコードは送受信手段１０１およびネットワーク１９１を通じて利用者Ａの情報端末に送られる。送受信手段１１１がこれを受信すると、ＨＴＭＬ解析手段１１２がこれを解析した上、図２１に示す画像をＧＵＩ表示手段１１３のＷｅｂブラウザ１４００に表示する。
【００５２】
図２１に示す画面では、ＷｅｂサービスＸの知人一覧ウィンドウ１４１０中に、利用者ＡとＷｅｂサービスＹで知人関係にある、ＷｅｂサービスＹにおけるニックネームｎｉｋｋｉを有する利用者Ｂを表すオブジェクト２１１１が新たに追加された（ステップＳ１９０３）。利用者Ｂを表すオブジェクト２１１１には、確認中という文字列２１１２が表示される。これは確認中という文字列でなくとも、利用者ＢがＷｅｂサービスＸでも利用者Ａと知人関係になることを承諾する以前の状態であること意味する表示なら何でも良い。なお、図２１に示す一例では、ステップＳ１９０３の操作の結果、利用者Ｂを表すオブジェクト２１１１がサービスＸの知人一覧ウィンドウ１４１０に追加された。しかし、ウェブブラウザ１４００内に表示される、たとえば「サービスＸの知人に加えようとしている人」のような別のウィンドウに追加されてもよい。また、図２１に示す一例では、ステップＳ１９０３の操作の結果、図２０に示す利用者Ｂを表すオブジェクト２０２１が、図２１ではＷｅｂサービスＹの知人一覧ウィンドウ２０２０から消えているが、これは消えなくてもよい。
【００５３】
次に、上記第２の処理について説明する。上記ステップＳ１９０３におけるＡｄｄボタンの下押し、乃至はドラッグ・アンド・ドロップが実行されたという情報は送受信手段１１１によって、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送られる。ゲートウェイＷｅｂサーバの送受信手段１０１がこれを受信すると、図１６を参照して、検索手段１０７が一時記憶手段のセッションｎのテーブル１３０１から上記ステップＳ１９０３で選択された認識票ＩＤｙｂ１６１４を有する利用者ＢのＵＩＤおよび暗号鍵を検索し、その結果ＵＩＤｂ１６３４およびＫｂ１６４４を得る（ステップＳ１９０４）。次に、送受信手段１０１はＵＩＤｂに関連づけられた暗号化認識票群の要求を、ネットワーク１９２を通じて暗号化認識票サーバ１７０に送る（ステップＳ１９０５）。
【００５４】
暗号化認識票サーバでは、送受信手段５０１がこれを受信し、検索手段５０４が受信したＵＩＤｂを検索キーとして暗号化認識票テーブルを検索する。図１８を参照すると、ＵＩＤｂ１８１１が検出される。すると送受信手段５０１がＵＩＤｂ１８１１に関連づけられた暗号化認識票群Ｅｋｂ（ＩＤｘｂ−Ｘ、ＩＤｙｂ−Ｙ）を、ネットワーク１９２を通じて、ゲートウェイＷｅｂサーバに送る（ステップＳ１９０６）。ゲートウェイＷｅｂサーバの送受信手段１０１がこれを受信すると、復号化手段１０６が前記ステップＳ１９０４で得られた暗号鍵Ｋｂを用いて、受信したＥｋｂ（ＩＤｘｂ−Ｘ、ＩＤｙｂ−Ｙ）を復号化する。その結果、利用者Ｂの有する２つの認識票ＩＤｘｂおよびＩＤｙｂを得る（ステップＳ１９０７）。以上の処理で、ＷｅｂサービスＹでＩＤｙｂを有する利用者Ｂが、ＷｅｂサービスＸにおいては認識票ＩＤｘｂを有することを、ゲートウェイＷｅｂサーバ１００が得たことになる。
【００５５】
次に、送受信手段１０１は、ゲートウェイＷｅｂサーバ１００が前記ステップＳ１９０７で得たＩＤｘｂと、セッションｎのテーブル１３０１にあるＩＤｘａ１６０１を含むメッセージ送信要求を、ネットワーク１９２を通じてＷｅｂサービスＸのサーバに送る（ステップＳ１９０８）。ここで要求するメッセージは、利用者Ａが利用者Ｂに対して、ＷｅｂサービスＸ上でも知人関係になることを要求するためのメッセージである。次に、ＷｅｂサービスＸのサーバの送受信手段１５１がこのメッセージ送信要求を受信し、記憶手段１５７に記憶する（ステップＳ１９０９）。
【００５６】
ここで、利用者Ａが、ＷｅｂサービスＸの知人関係拡張サービスを終了すれば（ステップＳ１９１０）、利用者ＡのＷｅｂブラウザからのアクセスは、ＷｅｂサービスＸのサーバ１５０にリダイレクトされ（ステップＳ１９１１）、さらにゲートウェイＷｅｂサーバの一時記憶手段１０３にある、セッションｎのテーブル１３０１は消去され（ステップＳ１９１２）、セッションｎは終了する。
【００５７】
次に、利用者Ａから利用者Ｂに対するメッセージ送信要求を受信した後の、ＷｅｂサービスＸのサーバの処理について、図２２に示すフロー図を用いて説明する。
【００５８】
利用者ＢがＷｅｂサービスＸにログインする（ステップＳ２２０１）。次に、ＷｅｂサービスＸのサーバのメッセージ生成手段１５６が、送信者を有する利用者Ａ、受信者を利用者Ｂとして、ＷｅｂサービスＸ上でも知人関係になることを要求するためのメッセージを生成する。この時生成される送信者および受信者は、前期ステップＳ１９０９で記憶されたた認識票ＩＤｘａおよびＩＤｘｂを用いる。ここで生成されたメッセージは、ＨＴＭＬ生成手段１５５によってＨＴＭＬコードに変換される。送受信手段１５１が、このＨＴＭＬコードを、ネットワーク１９２および１９１を通じて利用者Ｂの情報端末１２０に送る（ステップＳ２２０２）。
【００５９】
次に、利用者Ｂの情報端末の送受信手段１２１がこのＨＴＭＬコードを受信すると、ＨＴＭＬ解析手段１２２がこれを解析の上、ＧＵＩ表示手段１２３に図２３に示す画像を表示する。ＧＵＩ表示手段１２３には、Ｗｅｂブラウザウィンドウ２３００が表示される。Ｗｅｂブラウザウィンドウ２３００内には、利用者ＢとＷｅｂサービスＹで知人関係にある利用者Ａが、ＷｅｂサービスＸでも知人になりたいという意志を表明した旨の文章２３０１が表示される（ステップＳ２２０３）。また、この画面は非承諾ボタン２３１１および承諾ボタン２３１２が表示されている。ここで、利用者Ｂが入力手段１２４を用いて表示手段１２３に表示されたカーソル２３３０を移動させた上、承諾ボタン２３１２にあわせた上、入力手段のボタンを下押しするなどしてこれを選択する。この操作が実行されたという情報は、送受信手段１２１によってネットワーク１９１、ネットワーク１９２を通じて、ＷｅｂサービスＸのサーバ１５０に送られる（ステップＳ２２０４）。
【００６０】
これをＷｅｂサービスＸのサーバの送受信手段１５１が受信すると、承諾通知が記憶手段１５７に記憶される。この時点で、もし利用者ＡがＷｅｂサービスＸにログインしていれば、次のステップＳ２２０６に進む。もし利用者ＡがＷｅｂサービスＸにログインしていなければ、ログインした時に次ぎのステップＳ２２０６に進む。
【００６１】
ＷｅｂサービスＸのサーバのＨＴＭＬ生成手段１５５が図２４に示す画像のＨＴＭＬコードを生成する。次に送受信手段１５１がネットワーク１９１を通じてこのＨＴＭＬコードを利用者Ａの情報端末１１０に送る（ステップＳ２２０６）。利用者Ａの情報端末では、送受信手段１１１がこのＨＴＭＬコードを受信し、ＨＴＭＬ解析手段１１２がこれを解析した後、ＧＵＩ表示手段１１３に、図２４に示す画像が表示される（ステップＳ２２０７）
【００６２】
図２４に示すように、表示手段１１３にはＷｅｂブラウザウィンドウ１４００が表示される。Ｗｅｂブラウザウィンドウ１４００内には、上記ＨＴＭＬコードの解析結果が表示される。図７および図１０からわかるように、利用者ＢはＷｅｂサービスＸにおいてＢｅｔｔｙ Ｔｈｏｍａｓ７２２の名前を使い、かつＷｅｂサービスＹにおいてニックネームｎｉｋｋｉ１０２２を使っている。これまで説明したステップＳ１２０１からステップＳ２２０４の処理の結果、図２４では、利用者ＢのＷｅｂサービスＸにおける名前Ｂｅｔｔｙ Ｔｈｏｍａｓ２４１１、およびこれがＷｅｂサービスＸにおける名前であることを表すアイコン２４１２と共に表示されている。利用者Ａが、利用者ＢをＷｅｂサービスＸ上の知人にするための操作であるステップＳ１９０３を実行した直後は、利用者Ａの情報端末のＧＵＩ表示手段１１３には、図２１に示す画像が表示されていた。図２１と図２４を比較すると、図２１では、利用者ＢのＷｅｂサービスＹにおけるニックネームｎｉｋｋｉ２１１１が、確認中の表示２１１２とともに表示されているのに対して、図２４では、利用者ＢのＷｅｂサービスＸにおける名前Ｂｅｔｔｙ Ｔｈｏｍａｓ２４１１が、ＷｅｂサービスＸの知人一覧として表示されている。この時点で、利用者Ａと利用者Ｂの間では、知人一覧１４１０に表示された他の知人と同様に、ＷｅｂサービスＸの機能を使うことができる。
【００６３】
なお、本実施形態における暗号化は、利用者ごとに１つの対称鍵秘密鍵を用いて説明したが、非対称鍵を用いてもよい。また、本実施形態では利用者ごとに異なるが、各Ｗｅｂサービスに共通の暗号鍵を利用したが、利用者ごと、かつＷｅｂサービスごとに異なる暗号鍵を用いてもよい。また、本実施形態では、ゲートウェイＷｅｂサーバが、利用者ＡのＵＩＤを利用者ＡがＷｅｂサービスＹのサーバより認証を受けた後、すなわちステップＳ１７０２において生成した。しかし、利用者ＡのＵＩＤの生成は、利用者ＡがＷｅｂサービスＸのサーバから認識票、知人の認識票と付加情報を得るステップＳ１２０３の後、ＵＩＤが存在しないことがわかった時点で生成してもよい。また、本実施形態では、ＷｅｂサービスＸおよびＷｅｂサービスＹに共通のゲートウェイＷｅｂサーバを用いたが、各々のサービスに別のゲートウェイＷｅｂサーバを用いてもよい。
（実施形態２）
【００６４】
これまで説明した実施形態１では、利用者Ｂは、セッションｎが開始される以前から、ＷｅｂサービスＹの利用者であると共に、ＷｅｂサービスＸの利用者でもあった。すなわち、セッションｎが開始される以前から、図７で示すＷｅｂサービスＸのサーバの認識票テーブル６０１および図１０で示すＷｅｂサービスＹのサーバの認識票テーブル９０１に、各々ＩＤｘｂおよびＩＤｙｂが存在した。本実施形態２では、セッションｎが開始される時点では、利用者Ａと利用者ＢはＷｅｂサービスＹ上で知人関係にあり、利用者ＡはＷｅｂサービスＸの利用者であったが、利用者ＤがＷｅｂサービスＸの利用者ではない場合の説明である。この場合、前記実施形態１のステップＳ１９０８で実行したように、ＷｅｂサービスＸ上で利用者Ａから利用者Ｄへのメッセージを送信することはできない。本実施形態２は、このような場合についても、利用者ＡがＷｅｂサービスＸにおいて利用者Ｄと知人になることができるための処理について説明する。
【００６５】
本実施形態２は、前記ステップＳ１９１０を出発点とし、図２５に示すフロー図を用いて説明する。本実施形態２は上記セッションｎの一部であり、ステップＳ１２０１からステップＳ１９０９までの処理を既に経ているところから始まる。ステップＳ１９０９が完了した時点で、利用者Ａの情報端末のＧＵＩ表示手段１１３には、図２１に示す画像が表示されている。このとき利用者Ａは、引き続きＷｅｂサービスＸにおける知人関係拡張サービスを利用する（ステップＳ１９１０）。
【００６６】
再び図２１を参照して、利用者Ａが入力手段１１４を操作して、ＧＵＩ表示手段１１３に表示されたカーソル１４３０を移動させ、Ａｄｄボタン２１２１に合わせた上、入力手段１１４の有するボタンを下押しするなどして、Ａｄｄボタン２１２１を選択することで、以下に説明する２つの処理が実行される。このとき、Ａｄｄボタン２１２１を下押しするかわりに、Ｗｅｂブラウザ１４００内で、表示されたｎａａｍというオブジェクト２１２２にカーソル１４３０を合わせた上、入力手段の有するボタンを下押しするなどして選択したまま、カーソル１４３０をＷｅｂサービスＸの知人一覧ウィンドウ１４１０内に移動させた上、選択を解除する、所謂ドラッグ・アンド・ドロップを実行しても、やはり以下に説明する２つの処理が実行される。この操作は、利用者ＡがこれまでＷｅｂサービスＹにおいてのみ知人関係にあった利用者Ｄと、ＷｅｂサービスＸにおいても知人関係になることを要求する操作である。この時利用者Ｄは、ＷｅｂサービスＸの利用者はなく、ＷｅｂサービスＸにおける認識票を有していない点が、上記実施形態１と異なる点である。
【００６７】
以上の操作によって、以下の２つの処理が実行される。第１の処理は利用者Ａの情報端末のＧＵＩ表示手段１１３への表示変更のための処理である。第２の処理は、利用者Ｄに対して、ＷｅｂサービスＸにおいても利用者Ａと知人関係になることについての同意を求めるための処理である。
【００６８】
まず、上記第1の処理について説明する。上記のようなＡｄｄボタン２１２１の下押し、
乃至はドラッグ・アンド・ドロップが実行されたという情報は送受信手段１１１によって、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送られる。送受信手段１０１はこの情報を受け取ると、ＨＴＭＬ生成手段１０２は、図２６に示すような画面を表示するための新たなＨＴＭＬコードを生成する。この新たなＨＴＭＬコードは送受信手段１０１およびネットワーク１９１を通じて利用者Ａの情報端末に送られる。送受信手段１１１がこれを受信すると、ＨＴＭＬ解析手段１１２がこれを解析した上、図２６に示す画像をＧＵＩ表示手段１１３のＷｅｂブラウザ１４００に表示する。
【００６９】
図２６に示す画面では、ＷｅｂサービスＸの知人一覧ウィンドウ１４１０中に、利用者ＡとＷｅｂサービスＹで知人関係にある、ＷｅｂサービスＹにおけるニックネームｎａａｍを有する利用者Ｄを表すオブジェクト２６１１が新たに追加された（ステップＳ２５０１）。利用者Ｄを表すオブジェクト２６１１には、確認中という文字列２６１２が表示される。これは確認中という文字列でなくとも、利用者ＤがＷｅｂサービスＸでも利用者Ａと知人関係になることを承諾する以前の状態であること意味する表示なら何でも良い。なお、図２６に示す一例では、ステップＳ２５０１の操作の結果、利用者Ｄを表すオブジェクト２６１１がサービスＸの知人一覧ウィンドウ１４１０に追加された。しかし、ウェブブラウザ１４００内に表示される、たとえば「サービスＸの知人に加えようとしている人」のような別のウィンドウに追加されてもよい。また、図２６に示す一例では、ステップＳ２５０１の操作の結果、図２１に示す利用者Ｄを表すオブジェクト２１２２が、図２６ではＷｅｂサービスＹの知人一覧ウィンドウ２０２０から消えているが、これは消えなくてもよい。
【００７０】
次に、上記第２の処理について説明する。上記ステップＳ２５０１におけるＡｄｄボタンの下押し、乃至はドラッグ・アンド・ドロップが実行されたという情報は、送受信手段１１１によって、ネットワーク１９１を通じてゲートウェイＷｅｂサーバ１００に送られる。ゲートウェイＷｅｂサーバの送受信手段１０１がこれを受信すると、図１６を参照して、検索手段１０７が一時記憶手段のセッションｎのテーブル１３０１から上記ステップＳ２５０１で選択された認識票ＩＤｙｄ１６１５を有する利用者ＤのＵＩＤおよび暗号鍵を検索する。もしＵＩＤが存在しなければ、後述のステップＳ２５０８に進む。図１６に示す一例では、上記検索の結果ＵＩＤｄ１６３５およびＫｄ１６４５を得る（ステップＳ２５０３）。次に、送受信手段１０１はＵＩＤｄに関連づけられた暗号化認識票群の要求を、ネットワーク１９２を通じて暗号化認識票サーバ１７０に送る（ステップＳ２５０４）。
【００７１】
暗号化認識票サーバ１７０では、送受信手段５０１がこれを受信し、検索手段５０４が受信したＵＩＤｄを検索キーとして暗号化認識票テーブルを検索する。図１８を参照すると、ＵＩＤｄ１８３１が検出される。すると送受信手段５０１がＵＩＤｄ１８３１に関連づけられた暗号化認識票群Ｅｋｄ（ＩＤｙｄ−Ｙ、ＩＤｚｄ−Ｚ）１８３２を、ネットワーク１９２を通じて、ゲートウェイＷｅｂサーバに送る（ステップＳ２５０５）。ゲートウェイＷｅｂサーバの送受信手段１０１がこれを受信すると、復号化手段１０６が前記ステップＳ２５０３で得られた暗号鍵Ｋｄを用いて、受信したＥｋｄ（ＩＤｙｄ−Ｙ、ＩＤｚｄ−Ｚ）を復号化する。その結果、利用者Ｂの有する２つの認識票ＩＤｙｄおよびＩＤｚｄ、そしてこれらは各々ＷｅｂサービスＹおよびＷｅｂサービスＺの認識票であることを得る（ステップＳ２５０６）。以上の処理で、ＷｅｂサービスＹでＩＤｙｄを有する利用者Ｂが、ＷｅｂサービスＸの利用者でないことが判明する（ステップＳ２５０７）。
【００７２】
本実施形態２の場合、利用者ＤがＷｅｂサービスＸの利用者ないため、利用者ＡとＷｅｂサービスＸで知人関係になることを要求するメッセージを、ＷｅｂサービスＸを通じて利用者Ｄに送ることができない。そのため、このメッセージはＷｅｂサービスＹを通じて利用者Ｄに送る。次に、再び図１６を参照して、セッションｎのテーブル上のＩＤｙａ１６０２を発信者の認識票、ＩＤｙｂ１６１５を受信者の認識票としてメッセージ送信要求を、ネットワーク１９２を通じてＷｅｂサービスＹのサーバに送る（ステップＳ２５０８）。ここで要求するメッセージは、利用者Ａが利用者Ｄに対して、ＷｅｂサービスＸ上でも知人関係になることを要求するためのメッセージである。次に、ＷｅｂサービスＹのサーバの送受信手段１６１がこのメッセージ送信要求を受信し、記憶手段１６７に記憶する（ステップＳ２５０９）。
【００７３】
ここで示す例では、利用者ＡはここでＷｅｂサービスＸの知人関係拡張サービスを終了する。このため、利用者ＡのＷｅｂブラウザからのアクセスは、ＷｅｂサービスＸのサーバ１５０にリダイレクトされ（ステップＳ２５１０）、さらにゲートウェイＷｅｂサーバの一時記憶手段１０３にある、セッションｎのテーブル１３０１は消去され（ステップＳ２５１１）、セッションｎは終了する。
【００７４】
その後、利用者ＢがＷｅｂサービスＹにログインする（図２７、ステップＳ２７０１）。次に、ＷｅｂサービスＹのサーバのメッセージ生成手段１６６が、送信者を有する利用者Ａ、受信者を利用者Ｄとして、ＷｅｂサービスＸ上で知人関係になることを要求するためのメッセージを生成する。この時生成される送信者および受信者は、前期ステップＳ２５０９で記憶されたた認識票ＩＤｙａおよびＩＤｙｄを用いる。ここで生成されたメッセージは、ＨＴＭＬ生成手段１６５によってＨＴＭＬコードに変換される。送受信手段１６１が、このＨＴＭＬコードを、ネットワーク１９２および１９１を通じて利用者Ｄの情報端末１３０に送る（ステップＳ２７０２）。
【００７５】
次に、利用者Ｄの情報端末の送受信手段１３１がこのＨＴＭＬコードを受信すると、ＨＴＭＬ解析手段１３２がこれを解析の上、ＧＵＩ表示手段１３３に図２８に示す画像を表示する。ＧＵＩ表示手段１３３には、Ｗｅｂブラウザウィンドウ２８００が表示される（ステップＳ２７０３）。図２８に示す、Ｗｅｂブラウザウィンドウ２８００内には、利用者ＤとＷｅｂサービスＹで知人関係にある利用者Ａが、ＷｅｂサービスＸでも知人になりたいという意志を表明した旨の文章２８０１が表示される（ステップＳ２７０３）。また、この画面は非承諾ボタン２８１１および承諾ボタン２８１２が表示されている。前記ステップＳ２７０２でＷｅｂサービスＹのサーバのＨＴＭＬ作成手段１６５で作成されたＨＴＭＬコードにおいて、前記承諾ボタン２８１２には、ＷｅｂサービスＸのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）および利用者ＡのＷｅｂサービスＸにおける認識票ＩＤｘａが関連づけられている。ここで、利用者Ｄが入力手段１３４を用いて表示手段１３３に表示されたカーソル２８３０を移動させた上、承諾ボタン２８１２にあわせた上、入力手段のボタンを下押しするなどしてこれを選択する。次に、このＵＲＬをもとに、利用者Ｄの情報端末のＷｅｂブラウザ２８００は、ＷｅｂサービスＸのサーバ１５０にリダイレクトされ、さらに上記承認ボタン２８１２に関連づけられたＩＤｘａがＷｅｂサービスＸのサーバ１５０に受け渡される（ステップＳ２７０４）。
【００７６】
この時、利用者Ｄが既にＷｅｂサービスＸの利用者であれば、ＷｅｂサービスＸのサーバ１５０は、利用者Ｄに新規アカウントの作成のための画面を生成するＨＴＬＭコードを生成し、利用者Ｄの情報端末１３０に送る（ステップＳ２７０５）。利用者Ｄが新たにＷｅｂサービスＸの利用者になった場合には、ＷｅｂサービスＸのサーバの認識票データベース１５２の認識票テーブル６０１とソーシャルグラフテーブル６０２の両方に利用者Ｄの新たな行が追加される。利用者ＤがＷｅｂサービスＸにログインすると、この時点で、ＷｅｂサービスＸのサーバの認識票データベース１５２の、ソーシャルグラフテーブル６０２の、サービスＸの認識票ＩＤｘａ７１１の行のサービスＸで知人関係にある人の認識票の列８２０に、利用者Ｄの認識票ＩＤｘｄを追加する。また、ソーシャルグラフテーブル６０２のＩＤｘｄの行の、サービスＸで知人関係にある人の認識票の列８２０に利用者Ａの認識票ＩＤｘａを追加する。これらの処理によって、利用者Ａと利用者Ｄが新たにＷｅｂサービスＸで知人同士になった（ステップ２７０７）。
【００７７】
なお、上記実施形態１および実施形態２の両方で、ＷｅｂサービスＹは、電子メールサービスでもよい。この場合は、ＷｅｂサービスＹの各利用者の認識票は、各利用者の電子メールアドレスとなる。また、ＷｅｂサービスＹのサーバはメールサーバであり、またサーバより各利用者の情報端末に送られるのは、ＨＴＭＬコードではなく、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）やＩＭＡＰ（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）などの電子メール用のプロトコルに準拠したコードとなる。
【００７８】
次に、本願発明による作用効果について説明する。本願発明による方法、システム、サーバ装置、および情報端末によれば、以下に示すような利点がある。
【００７９】
始めに、Ｗｅｂサービス利用者にとっての利点について説明する。Ｗｅｂサービスの利用者は様々なＷｅｂサービスで知人関係を拡げることができる。たとえば、ＷｅｂサービスＸをチャットサービス、ＷｅｂサービスＹをＳＮＳサービスだとする。たとえば、利用者ＡはＳＮＳサービスで知人である利用者Ｂとチャットをしたいという潜在的な要求を持っているとする。各Ｗｅｂサービスが完全に独立している従来のシステムでは、この潜在的要求が顕在化することは希であった。しかし、本願発明の方法、システム、サーバ装置、および情報端末によれば、たとえば図２０に示すようなユーザインタフェイスによって、利用者Ａの上記要求を顕在化させ、ＷｅｂサービスＸ上での知人関係が拡大する可能性を大きくすることができる。このように、本願発明は、性質の異なる複数のＷｅｂサービス間で、利用者同士の知人関係を拡張することで、利用者に大きな利便性を提供できる。
【００８０】
次に、Ｗｅｂサービスを提供する事業者にとっての利点について説明する。Ｗｅｂサービス事業者にとっての、本願発明の利点はさらに２種類に分類できる。Ｗｅｂサービス提供事業者にとっての第１の利点は、既存の利用者によるＷｅｂサービス利用が促進されるという点である。これは、主として上記実施形態１に係る利点である。本願発明よる方法、システム、サーバ装置、および情報端末によれば、たとえば利用者ＡのＷｅｂサービスＸにおける知人は、従来のシステムによるＷｅｂサービスＸと比較して増える。ＷｅｂサービスＸにおける知人が増えれば、利用者Ａがより頻繁にＷｅｂサービスＸを利用する可能性が高くなる。一般にＷｅｂサービス事業者の収益は、利用者の利用頻度の増加に伴い増える傾向にある。従って、本願発明による方法、システム、サーバ装置、および情報端末を使うことで、Ｗｅｂサービス事業者はその収益を増大させることができる。
【００８１】
Ｗｅｂサービス提供事業者にとっての第２の利点は、新規の利用者を増やすことができるという点である。これは、主として上記実施形態２に係る利点である。上記実施形態２では、利用者ＤはＷｅｂサービスＸの利用者ではなかった。しかし、利用者Ｄは、図２８に示すような、ＷｅｂサービスＸに対する招待のメッセージを受け取ることで、新たにＷｅｂサービスＸの利用者になる可能性が高まる。一般にＷｅｂサービス事業者の収益は、利用者数の増大に伴い増える傾向にある。従って、本願発明による方法、システム、サーバ装置、および情報端末を使うことで、Ｗｅｂサービス事業者はその収益を増大させることができる。
【００８２】
従来の方法やシステムを使った場合、もし、ＷｅｂサービスＸの認識票テーブル６０１およびソーシャルグラフテーブル６０２、ＷｅｂサービスＹの認識票テーブル９０１およびソーシャルグラフテーブル９０２の情報を、各々のサーバで交換すれば、上記利用者にとっての利点および上記Ｗｅｂサービス提供事業者にとっての利点を実現することは可能であった。またＷｅｂサービスＸの提供業者でもＷｅｂサービスＹの提供事業者でもない第三者が運営する第三のサーバに、上記各テーブルの情報を集約することによっても、やはり上記利用者にとっての利点および上記Ｗｅｂサービス提供事業者にとっての利点を実現することは可能であった。しかし、上記各テーブルに格納された、利用者に関する情報や、利用者同士の知人関係の情報は、Ｗｅｂサービス提供事業者にとっての価値の源泉である場合が多く、これを他Ｗｅｂサービス提供事業者に渡すことや、第三者に渡すことは許されない場合が多い。
【００８３】
本願発明による方法、システム、サーバ装置、および情報端末では、各Ｗｅｂサービス提供事業者の利用者や利用者同士の知人関係についての情報を、他のＷｅｂサービス提供事業者や第三者のサーバに送り、そこで記憶することなしに、上記利用者やＷｅｂサービス提供事業者にとっての利点を実現することができる。以下について、このことについて詳しく説明する。
【００８４】
上記実施形態１や実施形態２が、上記記利用者やＷｅｂサービス提供事業者にとっての利点を実現していることは、すでに説明したとおりである。これを実現するために、ＷｅｂサービスＸのサーバＸが記憶する利用者に関する情報は、図７に示す認識票テーブル６０１および図８に示すソーシャルグラフテーブル６０２である。また、ＷｅｂサービスＹのサーバが記憶する利用者に関すおる情報は、図１０に示す認識票テーブル９０１および図１１に示すソーシャルグラフテーブル９０２である。これらの図からわかるように、ＷｅｂサービスＸのサーバには、ＷｅｂサービスＹの利用者の情報や知人関係は一切記憶されていない。また逆に、ＷｅｂサービスＹのサーバには、ＷｅｂサービスＸの利用者の情報や知人関係は一切記憶されていない。
【００８５】
本願発明による方法、システム、サーバ装置、および情報端末では、複数のＷｅｂサービスの認識票の関連づけを記憶するのは、暗号化認識票サーバ１７０である。いま、たとえばこの暗号化認識票サーバ１７０は、ＷｅｂサービスＸの提供事業者でも、ＷｅｂサービスＹの提供事業者でもない、第三の事業者によって管理されているものとする。図１８を参照すると、暗号化認識票サーバに記憶されているのは、ＵＩＤに関連づけられた暗号化された様々なＷｅｂサービスにおける認識票群１８２０である。ここで、図５を参照すると、暗号化された認識票群を復号化するための鍵は、暗号化認識票サーバには存在せず、復号化に必要な鍵は、ＷｅｂサービスＸまたはＷｅｂサービスＹのサーバに存在する。この第三の事業者が、ＷｅｂサービスＸやＷｅｂサービスＹの認識票を含む利用者のいかなる情報や知人関係も入手する方法はない。
【００８６】
ゲートウェイＷｅｂサーバ１００には、図１６に示す各Ｗｅｂサービスの利用者の認識票や知人関係が、一時記憶手段上に展開される。しかし、これらの情報が不揮発記憶手段に記憶されることはなく、セッション修了後には、一時記憶手段から削除される。このゲートウェイＷｅｂサーバ１００が、各Ｗｅｂサービスのサーバや、暗号化認識票サーバから独立した中立的サーバとして機能する。ゲートウェイＷｅｂサーバの運営者もまた、ＷｅｂサービスＸおよびＷｅｂサービスＹの利用者の認識票、付加情報、知人関係などを記憶したデータベースを保有する必要がない。
【００８７】
以上のように、本願発明によれば、複数のＷｅｂサービスの知人関係の相互利用が可能となるにも係わらず、これら各Ｗｅｂサービスのサーバに記憶された利用者の認識票、付加情報および知人関係などを、他のサービスのサーバに提供する必要がない。
【符号の説明】
【００８８】
１００ ゲートウェイＷｅｂサーバ
１１０ 利用者Ａの情報端末
１２０ 利用者Ｂの情報端末
１３０ 利用者Ｄの情報端末
１５０ ＷｅｂサービスＸのサーバ
１６０ ＷｅｂサービスＹのサーバ
１７０ 暗号化認識票サーバ
１９１ ネットワーク
１９２ ネットワーク
【特許請求の範囲】
【請求項１】
複数のサービスサーバのいずれもそのサービスサーバにて利用者を認識する認識票に関連付けて、前記複数のサービスサーバにおいて前記利用者を一意に識別する識別情報と、前記識別情報ごとに生成された暗号鍵と、を記憶可能な前記複数のサービスサーバと通信が可能な管理サーバ装置であって、
第１の列に、前記識別情報を格納し、
第２の列に、前記複数のサービスサーバのうち、利用者が利用可能なサービスサーバである一又は複数の利用サービスサーバの識別子を、前記利用者の識別情報に関連付けられて前記複数のサービスサーバの一に記憶されている暗号鍵により暗号化した暗号化情報を格納するテーブルを記憶する記憶装置を備えることを特徴とする管理サーバ装置。
【請求項２】
前記暗号鍵を記憶しないことを特徴とする請求項１に記載の管理サーバ装置。
【請求項３】
前記第２の列に格納される暗号化情報は、前記利用サービスサーバの識別子とともに前記利用サービスサーバ内で前記利用者を識別する認識票を暗号化した情報であることを特徴とする請求項１に記載の管理サーバ装置。
【請求項４】
識別情報を受信する識別情報受信部と、
受信された識別情報と適合する識別情報が前記第１の列に格納されている位置を検索する検索部と
を備える請求項１に記載の管理サーバ装置。
【請求項５】
前記第１の列の前記位置に相当する前記第２列の位置に格納されている暗号化情報を読み出して送信する暗号化情報送信部を備える請求項４に記載の管理サーバ装置。
【請求項６】
識別情報と暗号化情報とを受信する受信部と、
前記第１の列の前記位置に相当する前記第２列の位置に格納されている暗号化情報を、受信された暗号化情報に更新する更新部と、
を備える請求項４に記載の管理サーバ装置。
【請求項７】
前記複数のサービスサーバのいずれも、一の認識票に、他の認識票を関係付けて記憶することが可能であることを特徴とする請求項１に記載の管理サーバ装置。
【請求項８】
さらに、
識別情報を生成するべき命令を受信する識別情報生成命令受信部と、
前記命令に応じて識別情報を生成する識別情報生成部と、
生成された識別情報を返信する識別情報返信部と、
前記返信に応じて受信される暗号化情報と前記生成された識別情報とをそれぞれ第１の列内と第２の列内とにおいて同じ位置に挿入する挿入部と
を備えることを特徴とする請求項１に記載の管理サーバ装置。
【請求項１】
複数のサービスサーバのいずれもそのサービスサーバにて利用者を認識する認識票に関連付けて、前記複数のサービスサーバにおいて前記利用者を一意に識別する識別情報と、前記識別情報ごとに生成された暗号鍵と、を記憶可能な前記複数のサービスサーバと通信が可能な管理サーバ装置であって、
第１の列に、前記識別情報を格納し、
第２の列に、前記複数のサービスサーバのうち、利用者が利用可能なサービスサーバである一又は複数の利用サービスサーバの識別子を、前記利用者の識別情報に関連付けられて前記複数のサービスサーバの一に記憶されている暗号鍵により暗号化した暗号化情報を格納するテーブルを記憶する記憶装置を備えることを特徴とする管理サーバ装置。
【請求項２】
前記暗号鍵を記憶しないことを特徴とする請求項１に記載の管理サーバ装置。
【請求項３】
前記第２の列に格納される暗号化情報は、前記利用サービスサーバの識別子とともに前記利用サービスサーバ内で前記利用者を識別する認識票を暗号化した情報であることを特徴とする請求項１に記載の管理サーバ装置。
【請求項４】
識別情報を受信する識別情報受信部と、
受信された識別情報と適合する識別情報が前記第１の列に格納されている位置を検索する検索部と
を備える請求項１に記載の管理サーバ装置。
【請求項５】
前記第１の列の前記位置に相当する前記第２列の位置に格納されている暗号化情報を読み出して送信する暗号化情報送信部を備える請求項４に記載の管理サーバ装置。
【請求項６】
識別情報と暗号化情報とを受信する受信部と、
前記第１の列の前記位置に相当する前記第２列の位置に格納されている暗号化情報を、受信された暗号化情報に更新する更新部と、
を備える請求項４に記載の管理サーバ装置。
【請求項７】
前記複数のサービスサーバのいずれも、一の認識票に、他の認識票を関係付けて記憶することが可能であることを特徴とする請求項１に記載の管理サーバ装置。
【請求項８】
さらに、
識別情報を生成するべき命令を受信する識別情報生成命令受信部と、
前記命令に応じて識別情報を生成する識別情報生成部と、
生成された識別情報を返信する識別情報返信部と、
前記返信に応じて受信される暗号化情報と前記生成された識別情報とをそれぞれ第１の列内と第２の列内とにおいて同じ位置に挿入する挿入部と
を備えることを特徴とする請求項１に記載の管理サーバ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【公開番号】特開２０１０−２５０７９７（Ｐ２０１０−２５０７９７Ａ）
【公開日】平成２２年１１月４日（２０１０．１１．４）
【国際特許分類】
【出願番号】特願２００９−２２１２１６（Ｐ２００９−２２１２１６）
【出願日】平成２１年９月２５日（２００９．９．２５）
【分割の表示】特願２００９−５３０６８７（Ｐ２００９−５３０６８７）の分割
【原出願日】平成２１年４月１６日（２００９．４．１６）
【出願人】（５０６１８３７３１）リプレックス株式会社 (20)
【Ｆターム（参考）】
【公開日】平成２２年１１月４日（２０１０．１１．４）
【国際特許分類】
【出願日】平成２１年９月２５日（２００９．９．２５）
【分割の表示】特願２００９−５３０６８７（Ｐ２００９−５３０６８７）の分割
【原出願日】平成２１年４月１６日（２００９．４．１６）
【出願人】（５０６１８３７３１）リプレックス株式会社 (20)
【Ｆターム（参考）】
[ Back to top ]