ネットワークサービスを利用する利用者間の関係を提供するためのサーバ
【課題】異なるＷｅｂサービスのサーバ同士がソーシャルグラフを表す情報を直接授受しなくとも、利用者が複数のＷｅｂサービスに分散したソーシャルグラフを統合して利用することができ、このことで利用者にとっての利便性を高め、さらに各Ｗｅｂサービスの利用を促進する。
【解決手段】第一の利用者をネットワークサービスの利用者の中で一意に特定するための情報である認識票を受信する受信手段と、前記ネットワークサービスの第二の利用者および第三の利用者を、一意に特定する第一の検索結果認識票および第二の検索結果認識票をそれぞれ検索する検索手段と、第一のスクランブル認識票および第二のスクランブル認識票を生成する変換手段と、前記第一の検索結果認識票と前記第一のスクランブル認識票とを関連付け、かつ前記第二の検索結果認識票と前記第二のスクランブル認識票とを関連付けて記憶する記憶手段と、を有する。
【解決手段】第一の利用者をネットワークサービスの利用者の中で一意に特定するための情報である認識票を受信する受信手段と、前記ネットワークサービスの第二の利用者および第三の利用者を、一意に特定する第一の検索結果認識票および第二の検索結果認識票をそれぞれ検索する検索手段と、第一のスクランブル認識票および第二のスクランブル認識票を生成する変換手段と、前記第一の検索結果認識票と前記第一のスクランブル認識票とを関連付け、かつ前記第二の検索結果認識票と前記第二のスクランブル認識票とを関連付けて記憶する記憶手段と、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明は、サーバと連携してＷｅｂサービスなどのネットワークサービスを提供する情報処理の技術に関する。
【背景技術】
【０００２】
ソーシャル・ネットワーキング・サイト（ＳＮＳ）と呼ばれる、コミュニティ型の会員制Ｗｅｂサービスの普及が著しい（例えば、特許文献１参照。）。ＳＮＳにより、インターネット上で利用者同士の繋がりを構築および促進することができると考えられる。ＳＮＳとしてたとえば非特許文献１などに開示されるウェブサイトが知られている。さらに、最近ではインターネット上にある、検索、写真や動画の共有、販売、チャットや音声によるメッセージ交換を目的とするＷｅｂサービスにおいても、やはり利用者同士の繋がりを構築および促進する目的で上記のＳＮＳ的な機能が提供されている。
【０００３】
ＳＮＳ、もしくはＳＮＳ的機能を有する各種Ｗｅｂサービスにおいては、該当サイトへ様々な情報の入力や登録を行う。さらに、これらの情報を知人と共有、知人と通信をおこない、さらに参加者の中から知人を検索することで、該当サービス上での新たな人間関係を構築、促進することができる。これを実現するために、ＳＮＳ、またはＳＮＳ的機能を有する各種Ｗｅｂサービスの利用者は、あらかじめ何らかの手続きにより該当Ｗｅｂサイトにログインし、さらに他の利用者から検索されるための利用者自身の情報を入力しておく必要がある。
【０００４】
しかし、このようなＳＮＳ、もしくはＳＮＳ的機能を有する各種Ｗｅｂサービスの数が増大した結果、利用者は数多くのＷｅｂサイトで、ログイン、自分の情報登録、共有する情報の入力や登録、知人との通信、知人の検索等を繰り返し実行する必要が生じている。この結果、ログイン情報や共有する情報、さらに知人に関する情報の管理が困難になっている。
【０００５】
この問題の解決に向けて、様々な試みがなされている。ＳＮＳを含む各種Ｗｅｂサービスでは、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）へのアクセスを外部に許可することで、Ｗｅｂサービス間で利用者が共有する情報の相互融通を実現している。また、ＯｐｅｎＩＤ（例えば、非特許文献２参照。）によって、異なるＳＮＳを含むＷｅｂサービスに唯一のログイン情報でログインすることを可能にする試みもなされている。
【０００６】
ネットワーク上の知人同士の関係は、ソーシャルグラフと呼ばれる。上記のような、異なるＳＮＳを含むＷｅｂサービス間での相互融通の対象となる情報には、ソーシャルグラフが含まれる。最近では、これまで各Ｗｅｂサービス内で独立して保持されていたソーシャルグラフを、Ｗｅｂサービスを超えて融通し合うという試みがなされている。（例えば、非特許文献３参照。）Ｓｏｃｉａｌ Ｇｒａｐｈ ＡＰＩはその試みの１つである。Ｓｏｃｉａｌ Ｇｒａｐｈ ＡＰＩは、ある利用者の特定のＷｅｂサービスにおけるＩＤを与えると、戻り値としてその利用者の他のＷｅｂサービスにおけるＩＤを返す。また、ある利用者の特定のＷｅｂサービスにおけるＩＤを与えると、戻り値としてその利用者と様々なＷｅｂサービスにおいて知人関係にある利用者の、各々のＷｅｂサービスにおけるＩＤを返す。Ｗｅｂサービスを超えた、ソーシャルグラフの融通によって、上記情報管理の困難が解決され、その結果各Ｗｅｂサービスへの利用者の訪問が増えることが期待されている。
【特許文献１】米国特許第７０６９３０８号明細書
【非特許文献１】マイスペース株式会社、“ＭｙＳｐａｃｅ”、［online］、［平成２０年１１月２６日検索］、インターネット〈URL：ｈｔｔｐ：／／ｗｗｗ．ｍｙｓｐａｃｅ．ｃｏｍ／〉
【非特許文献２】オープンアイディーファウンデーション、“ＯｐｅｎＩＤ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ２．０ − Ｆｉｎａｌ”、［online］、平成１９年１２月５日、［平成２０年１１月２６日検索］、インターネット〈URL：ｈｔｔｐ：／／ｏｐｅｎｉｄ．ｎｅｔ／ｓｐｅｃｓ／ｏｐｅｎｉｄ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ−２＿０．ｈｔｍｌ〉
【非特許文献３】Ｂｒａｄ Ｆｉｔｚｐａｔｒｉｃｋ、Ｄａｖｉｄ Ｒｅｃｏｒｄｏｎ著、“Ｔｈｏｕｇｈｔｓ ｏｎ ｔｈｅ Ｓｏｃｉａｌ Ｇｒａｐｈ”、［online］、平成１９年８月１７日［平成２０年１１月２６日検索］、インターネット〈URL：ｈｔｔｐ：／／ｂｒａｄｆｉｔｚ．ｃｏｍ／ｓｏｃｉａｌ−ｇｒａｐｈ−ｐｒｏｂｌｅｍ／〉
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、ＳＮＳ、もしくはＳＮＳ的機能を有するＷｅｂサービスを提供する多くの事業者にとって、そのＷｅｂサービス内のソーシャルグラフは、収益の源泉である。また、Ｗｅｂサービス内に閉じたソーシャルグラフは、利用者が他のＷｅｂサービスに移ることを抑止する効果を持つ。従って、主として事業的観点から、ほとんどのＳＮＳを含むＷｅｂサービス事業者は自分のＷｅｂサービス内のソーシャルグラフに対する、他の事業者からのアクセスを許可していない。このため現実には、上に述べたＷｅｂサービスを超えたソーシャルグラフの融通は、ほとんど行われず、上記利用者によるログイン及び情報管理の困難の解消や、各Ｗｅｂサービスの活性化は実現していない。
【０００８】
図１、図２および図３を参照して、Ｗｅｂサービス間でのソーシャルグラフ融通に関する問題点を説明する。図１は、外部からのソーシャルグラフ取得要求に応答する機能を備えたＷｅｂサービスＸのサーバ１００の概略構成図である。サーバ１００は、記憶手段１１０、検索手段１２０、ＡＰＩ提供手段１３０、送受信手段１７０を有する。さらに送受信手段はソーシャルグラフ取得要求を外部のサーバより受信した上で検索キーを検索手段１２０に送る要求受信手段１７１と、検索手段より得た検索結果を、送信したサーバに送信する結果送信手段１７２を含む。このＡＰＩ提供手段１３０は、ＷｅｂサービスＸの利用者をＷｅｂサービスＸ内で一意に特定するための情報である認識票が入力されると、検索手段１２０に要求して、その認識票を有する利用者となんらかの関係がある他の利用者の認識票を戻り値として返す機能を有する手段である。認識票としては、そのＷｅｂサービスを利用するために用いるログイン名、電子メールアドレスなどの利用者を一意に特定する識別情報を用いることができる。
【０００９】
いまたとえば、ＷｅｂサービスＸのサーバの記憶手段１１０に、図２に示すソーシャルグラフが記憶されているとする。図２において１つの点は1人の利用者を表し、一つの直線は２人の利用者の間に関係があることを示す。点はノード、線はエッジと呼ばれる。エッジはその両端のノードの関係を表している。例えば、図２では、たとえば利用者Ａ２０１と利用者Ｂ２０２との間に関係２１１があることを示している。同様にたとえば利用者Ａ２０１と利用者Ｃ２０３との間に関係２１２が、また利用者Ａ２０１と利用者Ｄ２０４との間に関係２１３が、さらに利用者Ｃ２０３と利用者Ｄ２０４との間に関係２１４が、各々ある。なお、図２ではソーシャルグラフをノードとエッジを用いて図示したが、記憶手段１１０に記憶されるソーシャルグラフは、いかなる形式であってもよい。多くの場合、データベースの表として記憶されている。例えば、なんらかの関係のある２人の利用者の認識票を同じ行に記憶することで記憶される。
【００１０】
ここで、たとえばＷｅｂサービスＹのサーバ１９０が、ＷｅｂサービスＸのサーバ１００に対して、利用者ＡのＷｅｂサービスＸにおける認識票ＩＤｘａを送信する。この認識票ＩＤｘａは利用者Ａの認識票であるとする。このＩＤｘａの送信は、利用者Ａと関係のある利用者の認識票を要求することに対応する。ＷｅｂサービスＸのサーバの要求受信手段１７１がＩＤｘａを受信し、ＡＰＩ提供手段１３０の指示により検索手段１１０がこのＩＤｘａを検索キーとして、記憶手段１１０に記憶された、図２に示すソーシャルグラフを検索する。検索の結果、利用者Ａと関係のある利用者Ｂ、利用者Ｃ、および利用者Ｄの認識票ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄが得られる。ＡＰＩ提供手段１３０がこれらの認識票を、結果送信手段１７２を通じてＷｅｂサービスＹのサーバ１９０に返信する。図３には、ＷｅｂサービスＸのサーバの送受信手段１７０に対する入力と出力の関係の一例を示す。すなわち、ＷｅｂサービスＸのサーバ１００に対して、たとえば利用者Ａ、および利用者Ｂそれぞれの認識票を入力したときの出力される認識票を示している。
【００１１】
なお、本明細書では、認識票の表記はすべてＩＤで始まるとする。また３文字目はＷｅｂサービスを、また４文字目は利用者を表す。たとえば、ＩＤｘａは、ＷｅｂサービスＸにおいて利用者Ａを一意に特定するための認識票である。
【００１２】
図１、図２、および図３に示す一例は、ソーシャルグラフを異なるＷｅｂサービス間で融通する典型的な方法である。以下に、この方法のＷｅｂサービス事業者Ｘにとっての問題を示す。この方法では、ＷｅｂサービスＹのサーバ１９０は、各利用者に入力させるなど何らかの方法でＷｅｂサービスＸの利用者の認識票を入手すれば、各々の利用者と関係のある利用者のＷｅｂサービスＸにおける認識票を、たとえば図３のように入手できる。ＷｅｂサービスＹのサーバ１９０は、このような情報から、図２に示すＷｅｂサービスＸにおけるソーシャルグラフの一部または全部を再現できる。通常、Ｗｅｂサービスで使われる認識票は数字または文字の組み合わせである。このため、ＷｅｂサービスＸのサーバに対して、数字または文字の組み合わせを総当たりで要求すれば、ＷｅｂサービスＹがＷｅｂサービスＸの有するソーシャルグラフを全て入手することができる場合もある。
【００１３】
ＷｅｂサービスＹが、ＷｅｂサービスＸのソーシャルグラフの一部または全部を入手することにより、ＷｅｂサービスＸにとっては、以下の利点と欠点が生ずる。
【００１４】
ＷｅｂサービスＸにとって利点は、２つある。第１の利点は、利用者がＷｅｂサービスＸとＷｅｂサービスＹを組み合わせて使うことで、ＷｅｂサービスＸ利用者の利便性が向上する点である。たとえば、ＷｅｂサービスＸがＳＮＳ、ＷｅｂサービスＹがリアルタイム性のあるチャットサービスだったとする。ＷｅｂサービスＸでリアルタイム性のあるチャットサービスを提供していない場合、ＷｅｂサービスＸの利用者は、ＷｅｂサービスＹと組み合わせることで、ＳＮＳで知人同士が情報交換をしながら、必要に応じてリアルタイムでチャットすることが可能になる。ＷｅｂサービスＸは、自らチャットサービスを提供するコスト無く、ユーザに対してより高い利便性を提供できる。第２の利点は、利用者がＷｅｂサービスＹと組み合わせて使うことで、ＷｅｂサービスＸの利用が促進される点である。この例では、ＷｅｂサービスＸの利用者同士が、チャットで情報交換を始めることで、これまで以上の情報交換をＷｅｂサービスＸで行うようになる。
【００１５】
一方、ＷｅｂサービスＸにとっての欠点もある。ＷｅｂサービスＸとＷｅｂサービスＹとが共にＳＮＳであると仮定する。このとき、ＷｅｂサービスＸと競合関係にあるＷｅｂサービスＹが、前記の方法でＷｅｂサービスＸのソーシャルグラフを何の対価も支払わずに入手できることになる。したがって、ＷｅｂサービスＸの利用者の享受する利便性を、そのままＷｅｂサービスＹも実現し提供できるので、ＷｅｂサービスＹは、ＷｅｂサービスＸの利用者を奪うかもしれない。
【００１６】
本願発明によれば、このような従来のＡＰＩ公開によるソーシャルグラフの融通に係る、前記の利点を維持しながら、かつ前記の欠点を解決することが可能となる。また、本願発明によれば、前記のように異なるＷｅｂサービスのサーバ同士がソーシャルグラフを表す情報を直接授受しなくとも、利用者が複数のＷｅｂサービスに分散したソーシャルグラフを統合して利用することができる。このことで利用者にとっての利便性を高め、さらに各Ｗｅｂサービスの利用を促進するための方法を提供できる。
【課題を解決するための手段】
【００１７】
本発明の第１の側面において、ネットワークサービスを提供するためのサーバであって、そのネットワークサービスの利用者をそのネットワークサービスの中で一意に特定するための情報である認識票を受信する受信手段と、受信された認識票と関連付けて記憶された他の利用者の認識票を検索する検索手段と、スクランブル認識票を生成する変換手段と、検索された認識票と生成されたスクランブル認識票とを関連付けて記憶する記憶手段と、生成されたスクランブル認識票を送信する送信手段と、を有することを特徴とするサーバが提供される。ここに、受信された認識票と関連付けて記憶された他の利用者の認識票が複数存在する場合には、変換手段は、複数のスクランブル認識票を生成し、記憶手段は、第１の認識票と第２の認識票と、複数のスクランブル認識票と複数の認識票とのそれぞれを関連付けて記憶し、送信手段は、複数のスクランブル認識票を送信してもよい。
【００１８】
このようなサーバを提供することによる効果の一つとして、受信された認識票の間の関係を秘密に保つことができ、課題が解決される。
【００１９】
また、本発明の第２の側面おいて、上記第１の側面において提供されるサーバからスクランブル認識票を受信する手段を有する第２のサーバが提供される。
【００２０】
このような第２のサーバを、上記第１の側面において提供されるサーバにより提供されるネットワークサービスとは別のネットワークサービスに用いることによる効果の一つとして、別のネットワークサービスから上記第１の側面において提供されるサーバをアクセスすることが可能となり、課題が解決される。
【００２１】
また、本発明の第３の側面において、第一のサーバによって提供される第一のネットワークサービスの利用者を第一のネットワークサービスの中で一意に特定するための情報である認識票を第一のサーバに送信する送信手段と、送信された認識票と第一のサーバにおいて関連付けて記憶された認識票を第一のサーバより受信する受信手段と、スクランブル認識票を生成する変換手段と、第一のサーバより受信された認識票と生成されたスクランブル認識票とを関連付けて記憶する記憶手段と、を有することを特徴とするサーバが提供される。ここに、一の認識票の送信に対して第一のサーバより受信された認識票が複数存在する場合には、変換手段は、複数のスクランブル認識票を生成し、記憶手段は、第一のサーバより受信された複数の認識票と生成された複数のスクランブル認識票とのそれぞれを関連付けて記憶してもよい。
【００２２】
このようなサーバが提供される効果の一つとして、複数のネットワークサービスを横断してスクランブル認識票を生成して認識票と関連付けることができるので、認識票の間の関係などを秘密に保つことができる、課題が解決される。
【発明の効果】
【００２３】
本願発明の方法およびサーバによれば、複数のＷｅｂサービス間で各々のＷｅｂサービス内にある利用者同士の関係を利用し合うことで、各々のＷｅｂサービスの利用を促進しながらも、ひとつのＷｅｂサービスにおける利用者同士の関係を、他のＷｅｂサービスの提供者が再合成することを防止でき、各Ｗｅｂサービス提供者の資産である利用者同士の関係を保護することができる。
【発明を実施するための最良の形態】
【００２４】
以下に本願発明を実施するための、現在考えられる最善の形態について説明する。本願発明の範囲は、添付特許請求の範囲によって明確に定義されているため、この説明は限定的な意味に解釈すべきではなく、単に発明の一般原理を例示する目的で行う。
【００２５】
（実施形態１）
図４は、本願発明の実施形態の一例である、ＷｅｂサービスＸのサーバ４００の概略構成図である。サーバ４００は、外部のＷｅｂサービスとソーシャルグラフについて連携する機能を備えている。サーバ４００は、記憶手段４１０、検索手段４２０、認識票変換手段４３０、ＡＰＩ提供手段４４０、演算手段４５０、送受信手段４７０を有する。さらに送受信手段は特定の利用者と関係を持つ利用者一覧の要求を外部のサーバより受信した上で検索キーを検索手段４２０に送る要求受信手段４７１と、検索手段４２０より得た検索結果を、特定の利用者と関係を持つ利用者リスト要求の送信元に送信する結果送信手段４７２を含む。特定の利用者と関係を持つ利用者リスト要求は、サーバ、例えば、他のＷｅｂサービスのサーバから送信される。ＡＰＩ提供手段４４０は、ＷｅｂサービスＸの利用者をＷｅｂサービスＸ内で一意に特定するための認識票が入力されると、検索手段４２０に検索を要求する。そして、ＡＰＩ提供手段４４０は、その認識票を有する利用者と関係がある他の利用者の認識票が検索されると、さらにこれをスクランブル認識票に変換した上、戻り値として返す機能を備える。
【００２６】
いまたとえば、ＷｅｂサービスＸのサーバの記憶手段のソーシャルグラフテーブル４１１に、図２に示すソーシャルグラフが記憶されているとする。図２ではソーシャルグラフをノードとエッジを用いて図示したが、ソーシャルグラフテーブル４１１に記憶に記憶されるソーシャルグラフは、いかなる形式であってもよく、ここではデータベースのテーブルの形式として記憶されていると仮定する。また、ソーシャルグラフにより関係が存在するとされる利用者は、知人同士であるとみなされることが想定される。例えば、Ｗｅｂサービスに入会するためには、すでに入会している人の招待が必要になっていてもよい。
【００２７】
ここで、たとえばＷｅｂサービスＹのサーバ４９０が、ＷｅｂサービスＸのサーバ４００に対して、利用者ＡのＷｅｂサービスＸにおける認識票ＩＤｘａを送信することで、利用者Ａと知人である関係にある他の利用者のスクランブル認識票および付加情報を要求する（ステップＳ５０１）。付加情報としては、名前、ニックネーム、写真、コメントなど、各々の利用者がＷｅｂサービスＸに登録している情報なら何でもよい。なお、付加情報の要求は必須ではない。ＷｅｂサービスＸのサーバの要求受信手段４７１がＩＤｘａを受信し、ＡＰＩ提供手段４４０の指示により検索手段４２０がこのＩＤｘａを検索キーとして、記憶手段４１０に記憶されたソーシャルグラフテーブル４１１を検索する（ステップＳ５０２）。検索の結果、利用者Ａと関係のある利用者Ｂ、利用者Ｃ、および利用者Ｄの認識票ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄが得られる。
【００２８】
次にＡＰＩ提供手段４４０は、検索キーであるＩＤｘａ、および検索結果であるＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄを、認識票変換手段４３０へ送る（ステップＳ５０３）。次に、認識票変換手段は、検索結果であるＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄの各々に対応するスクランブル認識票Ｓ０、Ｓ１、およびＳ２を生成する（ステップＳ５０４）。Ｓ０、Ｓ１、およびＳ２の生成方法は後述する。次に認識票変換手段は、ＩＤｘｂとＳ０、ＩＤｘｃとＳ１、およびＩＤｘｄとＳ２を各々関連づけて、記憶手段の変換テーブル４１２に記憶する（ステップＳ５０５）。次に、ＡＰＩ提供手段４４０は、結果送信手段４７２を通じてＳ０、Ｓ１、およびＳ２を各々、利用者Ｂ、Ｃ、およびＤの各々の付加情報に関連づけた上、ＷｅｂサービスＹのサーバ４９０に送信する（ステップＳ５０６）。
【００２９】
図６に、変換テーブル４１２の一例を示す。変換テーブルは検索キーからなる列、および検索結果の認識票からなる行のマトリクスである。この例では、検索キーはステップＳ５０１でＷｅｂサービスＸのサーバ４００が受信した認識票であり、例えばＩＤｘａとなる。このため、変換テーブルにおけるＩＤｘａの列６１０の、ＩＤｘｂの行６１２にＳ０が、ＩＤｘｃの行６１３にＳ１が、ＩＤｘｄの行６１４にＳ２が、各々記憶される。図６は、変換テーブルの一例であり、異なる形態のテーブルであっても、図６と同じ情報が表現されていればよい。
【００３０】
次に、たとえばＷｅｂサービスＹのサーバ４９０が、ＷｅｂサービスＸのサーバ４００に対して、利用者ＢのＷｅｂサービスＸにおける認識票ＩＤｘｂを送信することで、利用者Ｂと関係のある利用者のスクランブル認識票および付加情報を要求する（ステップＳ５０７）。ＷｅｂサービスＸのサーバの要求受信手段４７１がＩＤｘｂを受信し、ＡＰＩ提供手段４４０の指示により検索手段４２０がこのＩＤｘｂを検索キーとして、記憶手段４１０に記憶された図２に示すソーシャルグラフを検索する（ステップＳ５０８）。検索の結果、利用者Ｂと関係のある利用者Ａ、利用者Ｄ、および利用者Ｅの認識票ＩＤｘａ、ＩＤｘｄ、およびＩＤｘｅが得られる。
【００３１】
次にＡＰＩ提供手段４４０は、検索キーであるＩＤｘｂ、および検索結果であるＩＤｘａ、ＩＤｘｄ、およびＩＤｘｅを、認識票変換手段４３０へ送る（ステップＳ５０９）。次に、認識票変換手段は、検索結果であるＩＤｘａ、ＩＤｘｄ、およびＩＤｘｅの各々に対応するスクランブル認識票Ｓ３、Ｓ４、およびＳ５を生成する（ステップＳ５１０）。Ｓ３、Ｓ４、およびＳ５の生成方法は後述する。次に認識票変換手段は、ＩＤｘａとＳ３、ＩＤｘｄとＳ４、およびＩＤｘｅとＳ５を各々関連づけて、記憶手段の変換テーブル４１２に記憶する（ステップＳ５１１）。図６を参照すると、この例で検索キーは、ステップＳ５０７でＷｅｂサービスＸのサーバ４００が受信したＩＤｘｂである。このため、変換テーブルにおけるＩＤｘｂの列６２０の、ＩＤｘａの行６２１にＳ３が、ＩＤｘｄの行６２４にＳ４が、ＩＤｘｅの行６２５にＳ５が、各々記憶される。次に、ＡＰＩ提供手段４４０は、結果送信手段４７２を通じてＳ３、Ｓ４、およびＳ５を、各々利用者Ａ、Ｄ、およびＥの付加情報を関連づけた上、ＷｅｂサービスＹのサーバ４９０に送信する（ステップＳ５１２）。なお、図６には上記ＩＤｘａおよびＩＤｘｂに加えて、参考のためにＩＤｘｃ、ＩＤｘｄ、ＩＤｘｅ、ＩＤｘｆ、ＩＤｘｇの各々について、ＷｅｂサービスＸのサーバが知人の情報提供要求した場合の、スクランブル認識票も記した。前記変換テーブルはＷｅｂサービスＸのサーバの記憶手段４１０に記憶されていてもよく、またはＷｅｂサービスＸのサーバにネットワークを経由して接続された他のサーバの記憶手段または外部記憶手段に記憶されていてもよい。
【００３２】
ここで、ステップＳ５０４およびステップＳ５１０におけるスクランブル認識票の生成方法について説明する。本願発明の一実施形態において、検索結果である認識票をスクランブル認識票に変換するのは、ＷｅｂサービスＹのサーバの要求により上記ステップＳ５０１からＳ５１２までのステップが実行されても、ＷｅｂサービスＹのサーバがＷｅｂサービスＸのソーシャルグラフを再合成できないことが目的である。
【００３３】
図７は、ＷｅｂサービスＸのサーバ４００に対する要求および結果の関係について、従来の方法と本願発明の一実施形態による方法を比較したものである。従来の方法による結果を受信したＷｅｂサービスＹのサーバ４９０は、図８（ａ）に示すように、図２に示したソーシャルグラフの一部を再合成できる。たとえばこの結果、ＷｅｂサービスＹのサーバ４９０では、図８におけるエッジ８０１とエッジ８０２から、認識票ＩＤｘｄを持つ利用者Ｄが認識票ＩＤｘａを持つ利用者Ａと認識票ＩＤｘｂを持つ利用者Ｂとの共通の知人であることを知ることができる。本願発明による方法では、ＷｅｂサービスＹのサーバ４９０が得る情報は図８（ｂ）のとおりである。このＳ０からＳ５を適切に生成することで、ＷｅｂサービスＹのサーバ４９０では、ＷｅｂサービスＸ上のソーシャルグラフを再合成することができない。すなわち、本願発明による方法によれば、利用者Ｄが利用者Ａと利用者Ｂとの共通の知人であることを知ることができない。
【００３４】
ステップＳ５０４およびステップＳ５１０における、認識票からスクランブル認識票への変換は、このようにＷｅｂサービスＹのサーバ４９０でＷｅｂサービスＸのソーシャルグラフを再合成できないようなスクランブル認識票の変換方法であれば、どのような方法でもよい。このような変換方法としてのスクランブル認識票の生成方法の一例としては、演算手段４５０が生成する乱数を、順次Ｓ０、Ｓ１、Ｓ２、Ｓ３、Ｓ４、Ｓ５とする方法がある。この方法では、図８（ｂ）に示すようにＷｅｂサービスＹのサーバ４９０が受け取るＳ０からＳ５は無作為に選択された数値、文字列のいずれか１以上を含んでいてよい。無作為とは、検索結果である認識票とそれに対して生成されるスクランブル認識票との対応関係に法則性が存在しないことをいう。無作為であっても、生成される認識票は全て等しくなく、言い換えると異なるのが好ましい。この場合、たとえば同じＩＤｘｄから変換されたＳ２およびＳ４は異なる値となるため、ＷｅｂサービスＹのサーバ４９０では、利用者Ｄが利用者Ａと利用者Ｂの共通の知人であることを知る手段はない。
【００３５】
またスクランブル認識票を生成する方法の他の一例としては、要求と結果の演算結果をスクランブル認識票とする方法がある。たとえば、ＷｅｂサービスＸのサーバＸの演算手段４５０がステップＳ５０１で受信した認識票ＩＤｘａと、検索結果であるＩＤｘｂ、ＩＤｘｃ、ＩＤｘｄそれぞれとの所定の演算（例えば、積の演算など）の結果を各々Ｓ０、Ｓ１、およびＳ２とする。なお、認識票が文字列であれば、積の演算は文字列の連接などとして定義できる。同様にたとえば、認識票ＩＤｘｂと、検索結果であるＩＤｘａ、ＩＤｘｄ、ＩＤｘｅそれぞれとの積などを各々Ｓ３、Ｓ４、およびＳ５とする。この場合、ＩＤｘｄから変換されたＳ２およびＳ４は異なる値となるため、ＷｅｂサービスＹのサーバ４９０では、利用者Ｄが利用者Ａと利用者Ｂの共通の知人であることを知る手段はない。また、所定の演算の一例としては、Ｗｅｂサービスに固有の数値（もしくは種値）を定数として含む演算であってもよい。すなわち、Ｗｅｂサービスに対して一意に決まる数値（もしくは種値）を変数としてもつ演算であってもよい。もし３つ以上のＷｅｂサービスが本願発明の一実施形態による方法でソーシャルグラフを利用し合う場合には、各Ｗｅｂサービスが数値（もしくは種値）として相互に異なる定数を用いることで、ソーシャルグラフの秘匿性を高めることができる。サービスＸがインターネット上で一意に決まるような値を数値（もしくは種値）として用いてもよい。
【００３６】
次に、スクランブル認識票および付加情報を受信した後の、ＷｅｂサービスＹのサーバ４９０における処理について図９、図１０、および図１１を参照して説明する。図９は、ＷｅｂサービスＹのサーバ４９０の概略構成図である。ＷｅｂサービスＹのサーバは、送受信手段９１１、記憶手段９１２、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）生成手段９１３、リダイレクト手段９１４を有する。ＷｅｂサービスＹのサーバ４９０は、ネットワークを通じてＷｅｂサービスＹの利用者の情報端末９２０に接続されている。図１０は、ＷｅｂサービスＹのサーバ４９０の処理を説明するフロー図である。
【００３７】
ステップＳ５０６でＷｅｂサービスＸのサーバ４００から送信されたスクランブル認識票Ｓ０、Ｓ１、Ｓ２、および各々に関連づけられた付加情報を、ＷｅｂサービスＹのサーバの送受信手段９１１が受信し、記憶手段９１２に記憶する（ステップＳ１００１）。同様に、ステップＳ５１２でＷｅｂサービスＸのサーバ４００から送信されたスクランブル認識票Ｓ３、Ｓ４、Ｓ５、および各々に関連づけられた付加情報を、ＷｅｂサービスＹのサーバの送受信手段９１１が受信し、記憶手段９１２に記憶する（ステップＳ１００２）。
【００３８】
次にＷｅｂサービスＹを利用している利用者Ａの情報端末９２０から、ＷｅｂサービスＹのサーバ４９０に対して、利用者ＡのＷｅｂサービスＸにおける知人の一覧を取得する要求が送られる。ここで、利用者ＡはＷｅｂサービスＹとＷｅｂサービスＸの両方を使っていると仮定する。次に、ＷｅｂサービスＹのサーバ４９０が前記要求を受信する（ステップＳ１００３）。次に、ＷｅｂサービスＹのサーバのＨＴＭＬ生成手段９１３が、前記ステップＳ１００１で受信したスクランブル認識票Ｓ０、Ｓ１、Ｓ２、および各々の付加情報を含むＨＴＭＬコードを生成する。埋め込まれたＨＴＭＬコードの一例は後に図１１を参照しながら説明する。次に送受信手段９１１が、生成されたＨＴＭＬコードをＷｅｂサービスＹ利用者の情報端末９２０に送信する（ステップＳ１００４）。ＷｅｂサービスＹの利用者の情報端末が前記ＨＴＭＬコードを受信すると、ＨＴＭＬ解析手段９２３がこれを解析し、表示手段９２４を使って表示する。
【００３９】
図１１は、表示手段９２４に表示された利用者ＡのＷｅｂサービスＹ画面の一例である。利用者Ａは、ＷｅｂサービスＹ、ＷｅｂサービスＸの両方の利用者である。利用者ＡのＷｅｂサービスＸでの認識票はＩＤｘａである。図１１では、ＷｅｂサービスＹのウィンドウ１１００の中に、ＷｅｂサービスＸにおける利用者Ａの知人の情報１１０１が表示されている。図２に示すとおり、利用者ＡのＷｅｂサービスＸにおける知人は、利用者Ｂ、Ｃ、およびＤである。このため、ＷｅｂサービスＸの知人の情報１１０１には、利用者Ｂの付加情報１１１０、利用者Ｃの付加情報１１２０、および利用者Ｄの付加情報１１３０が表示されている。これらの付加情報は上記ステップＳ１００４で生成されるＨＴＭＬコードに組み込まれたものである。たとえば、図１１の例では、利用者Ｂの付加情報として、ＷｅｂサービスＸ上のニックネーム１１１１、アバター１１１２、およびメッセージ１１１３が表示されている。
【００４０】
図１１の利用者Ｂ、利用者Ｃ、および利用者Ｄを表示するＨＴＭＬコードには、前記スクランブル認識票Ｓ０、Ｓ１、およびＳ２が各々埋め込まれている。いま、たとえばＷｅｂサービスＸのサーバ４００のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＸ．ｃｏｍ／、ＷｅｂサービスＹのサーバ４９０のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＹ．ｃｏｍ／、ＷｅｂサービスＹのサーバの中でサービスＸを表すサービス認識票がｓｅｒｖｉｃｅＩＤＸだったとすると、図１１に示す画面のＨＴＭＬコードにおいて、利用者Ｂの付加情報１１１０は、＜ａ ｈｒｅｆ＝“ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＹ．ｃｏｍ／？ｓｅｒｖｉｃｅＩＤ＝ｓｅｒｖｉｃｅＩＤＸ＆ｉｄ＝Ｓ０”＞と＜／ａ＞との間に記述される。
【００４１】
したがって、利用者Ａが画面１１００上の利用者Ｂの付加情報１１１０を、入出力手段９２２を通じて選択すると、Ｓ０が埋め込まれたＵＲＩが送受信手段９２１を通じてＷｅｂサービスＹのサーバ４９０に送信され、これを送受信手段９１１が受信する（ステップＳ１００５）。ＷｅｂサービスＹのサーバでは、リダイレクト手段９１４が、ＷｅｂサービスＹの利用者の情報端末９２０から受信した前記ＵＲＩからリダイレクト先を計算し、ＷｅｂサービスＸのサーバ４００にリダイレクトする（ステップＳ１００６）。もし、利用者ＢもＷｅｂサービスＹの利用者であり、ＷｅｂサービスＹのサーバ４９０が利用者Ｂの情報端末からＷｅｂサービスＸにおける知人の一覧を表示するという要求を受信した場合にも、前記ステップＳ１００３からステップＳ１００６と同様の処理がおこなわれる。
【００４２】
次にＷｅｂサービスＹのサーバからリダイレクトされたＵＲＩを、ＷｅｂサービスＸのサーバ４００が処理するステップを、図１２を使って説明する。まず前記ステップＳ１００６でＷｅｂサービスＹのサーバ４９０からリダイレクトされたＵＲＩであるｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＸ．ｃｏｍ／？ｉｄ＝Ｓ０を送受信手段４７０が受信する（ステップＳ１２０１）。次にＡＰＩ提供手段４４０がスクランブル認識票Ｓ０を抽出した上、これを検索キーとして変換テーブル４１２を検索し、検索結果として認識票ＩＤｘｂを得る（ステップＳ１２０２）。次に、ＡＰＩ提供手段が、認識票ＩＤｘｂに関連づけられたコンテンツ情報を記憶手段４１０のコンテンツ記憶領域４１３からロードする（ステップＳ１２０３）。次にＡＰＩ提供手段がコンテンツ情報を情報端末のＷｅｂブラウザで表示するためのＨＴＭＬコードを生成する（ステップＳ１２０４）。次に送受信手段４７０が、生成された前記ＨＴＭＬコードを、ネットワークを通じてＷｅｂサービスＹの利用者Ａの情報端末９２０に送信する（ステップＳ１２０５）。
【００４３】
次にＷｅｂサービスＹの利用者の情報端末９２０は、前記ステップＳ１２０５で送信されたＨＴＭＬコードを受信し、ＨＴＭＬ解析手段９２３がこれを解析した上、表示手段９２４が解析結果としてのＷｅｂサービスＸのコンテンツ情報を表示する。たとえば利用者Ａが、図１１に示すＷｅｂサービスＹの画面に表示されたＷｅｂサービスＸ上の知人である利用者Ｂのプロフィール１１１０を、入力手段９２２を使って選択すると、表示画面はＷｅｂサービスＸ上のコンテンツである利用者Ｂの写真や日記に遷移する、というような使い方が可能である。
【００４４】
なお、本実施形態に示す一例ではサービス認識票およびスクランブル認識票をＵＲＩやＵＲＬとしてＨＴＭＬコードに埋め込んだが、ＷｅｂサービスＹのサーバ４９０から送信する情報にスクランブル認識票が含まれており、利用者Ａの情報端末９２０において、ＷｅｂサービスＹの画面上に、ＷｅｂサービスＸにおける利用者Ａの知人の情報を表示することができれば、データの形式は何でもよい。また、本実施形態に示す一例では、図１１の利用者Ｂ、利用者Ｃ、および利用者Ｄを表示するＨＴＭＬコードに含まれるＵＲＬにはサービスＹのサーバのＵＲＬとサービスＹの中でサービスＸを表すサービス認識票とスクランブル認識票を埋め込んだが、サービスＸのＵＲＬとスクランブル認識票を組み合わせたＵＲＬとしてもよい。また、本実施形態に示す一例では、ＷｅｂサービスＸは、利用者の有する何らかのコンテンツ情報を表示するサービスとしたが、本願発明では、ＷｅｂサービスＸはどのようなサービスでもよい。たとえば、ＷｅｂサービスＸやＷｅｂサービスＹはチャットや音声通話などのメッセンジャーサービスであってよい。
【００４５】
また、ＷｅｂサービスＸのサーバとＷｅｂサービスＹのサーバの間の、ネットワークを通じた認識票やスクランブル認識票の送受信が暗号化された状態で実行されてもよい。
【００４６】
以下では、本願発明の効果について説明する。本実施形態に示す一例で、利用者ＡがＷｅｂサービスＸとＷｅｂサービスＹの両方を利用しており、ＷｅｂサービスＸをチャットサービス、ＷｅｂサービスＹをＳＮＳであると仮定する。いま、利用者ＡがＳＮＳサービスＹにチャットサービスＸにおける利用者Ａ自身の認識票を登録しておく。図１１に示したように、利用者ＡはＳＮＳサービスＹの表示画面において、チャットサービスＸにおける友人一覧を表示させることができる。さらに利用者Ａは、ＳＮＳサービスＹの画面に表示された友人一覧の中の1人を選択すると、チャットサービスＸの画面に遷移した上、選択した友人とチャットサービスＸを通じて通信が開始できる。このようにして、ＸおよびＹの２つのＷｅｂサービスを統合して、ソーシャルグラフを使うことができるようになる。この結果、利用者の利便性が増大するとともに、チャットサービスＸ、およびＳＮＳサービスＹの両方の利用が促進される。
【００４７】
これと同等の複数サービスの間でのソーシャルグラフの融通は、ＡＰＩを通じて各サービスの認識票同士の関係を直接サービス間で授受する従来の方法によっても、または本願発明の方法によっても実現可能である。しかし、従来の方法によれば、図７および図８（ｂ）を使って既に説明したように、ＳＮＳサービスＹのサーバ４９０でチャットサービスＸ上のソーシャルグラフを再合成可能であった。もし利用者Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧが、上記利用者Ａと同じようにＳＮＳサービスＹからチャットサービスＸを利用すると、図２に示すチャットサービスＸのソーシャルグラフを、ＷｅｂサービスＹのサーバが再合成することが可能となる。これはほとんどの場合、事業的観点からチャットサービスＸの望むところではない。このために、従来の方法によるソーシャルグラフの相互利用が進まなかった。その結果として利用者の利便性向上やチャットサービスＸやＳＮＳサービスＹの利用促進が実現しなかった。
【００４８】
しかし、本願発明の方法によれば、このような複数サービスの間でのソーシャルグラフの相互利用を実現したとしても、図７および図８（ａ）を使って説明したように、ＳＮＳサービスＹのサーバ４９０が、チャットサービスＸのソーシャルグラフを再合成することは困難あるいは不可能である。このため、Ｗｅｂサービスを超えたソーシャルグラフの相互利用が促進され、利用者の利便性とチャットサービスＸとＳＮＳサービスＹの両方の利用が促進されるという効果がある。
【００４９】
（実施形態２）
図１３に、本願発明の実施形態の他の一例の概略構成図を示す。本実施形態では、ＷｅｂサービスＸのサーバ１３１０とＷｅｂサービスＹのサーバ４９０との間でのソーシャルグラフの相互利用に、ソーシャルグラフ交換サービスＺ（以下サービスＺ）のサーバ１３２０が存在する。またサービスＺのサーバで作成した暗号化変換テーブルを外部記憶手段において保存する場合には、暗号化変換テーブル用サーバ１３５０を使う。なお、暗号化変換テーブルは暗号化変換テーブル用サーバの外部記憶手段１３５１に記憶することは必須ではない。これら４つのサーバ、およびＷｅｂサービスＹの利用者Ａの情報端末９２０は、ネットワークで接続されている。本実施形態では、ＷｅｂサービスＸのサーバ１３１０は、送受信手段１３１１、記憶手段１３１２、検索手段１３１３、およびＨＴＭＬ生成手段１３１６を有する。またサービスＺのサーバ１３２０は、送受信手段１３２１、主記憶手段１３２２、認識票変換手段１３２４、暗号化・復号化手段１３２５、ＡＰＩ提供手段１３２６、および検索手段１３２３を有する。なお、ＷｅｂサービスＸのサーバの記憶手段にあるソーシャルグラフテーブル１３１５には、図２に示すソーシャルグラフがあらかじめ記憶されているとする。図２に示すソーシャルグラフは、いかなる形式で記憶されていてもよく、ここではデータベースのテーブルとして記憶されている。
【００５０】
以下では、本実施形態による、ＷｅｂサービスＸとＷｅｂサービスＹとの間のソーシャルグラフの相互利用の方法を説明する。まず図１４を参照して、ＷｅｂサービスＸのサーバ１３１０が、サービスＺのサーバからの、特定の利用者の知人の認識票要求に対して、結果をＷｅｂサービスＺのサーバに送る各ステップを説明する。はじめに、サービスＺのサーバ１３２０が、ＷｅｂサービスＸのサーバ１３１０に対して、利用者ＡのＷｅｂサービスＸにおける認識票ＩＤｘａを送信することで、利用者Ａと知人である利用者の認識票および付加情報を要求する（ステップＳ１４０１）。付加情報としては、名前、ニックネーム、写真、コメントなど、利用者ＡがＷｅｂサービスＸに登録している情報なら何でもよい。また、付加情報は必須となるものではない。ＷｅｂサービスＸのサーバの送受信手段１３１１がＩＤｘａを受信し、検索手段１３１３がこのＩＤｘａを検索キーとして、記憶手段１３１２に記憶されたソーシャルグラフテーブル１３１５を検索する（ステップＳ１４０２）。検索の結果、利用者Ａと知人関係にある利用者Ｂ、利用者Ｃ、および利用者Ｄの認識票ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄが得られる。送受信手段１３１１はこれらの認識票に付加情報を各々関連づけてサービスＺのサーバ１３２０に送る（ステップＳ１４０３）。同様に、ＷｅｂサービスＸのサーバ１３１０は、サービスＺのサーバ１３２０からのＩＤｘｂの要求に対して、検索結果として利用者Ｂと知人関係にある利用者Ａ、利用者Ｄ、および利用者Ｅの認識票ＩＤｘａ、ＩＤｘｄ、およびＩＤｘｅ、および各々に関連づけられた付加情報を送信する（ステップＳ１４０４からステップＳ１４０６）。
【００５１】
次にサービスＺのサーバは、ＷｅｂサービスＹのサーバがＷｅｂサービスＸの有するソーシャルグラフを再合成できないように、前記ステップＳ１４０３でＷｅｂサービスＸのサーバが送信した情報を以下のように処理する。サービスＺのサーバ１３２０は、利用者Ａと知人関係のある利用者Ｂ、利用者Ｃ、および利用者Ｄの認識票ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄ、および各々に関連づけられた付加情報を受信する（ステップＳ１５０１）。次に、認識票変換手段は、検索結果であるＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄの各々に対応するスクランブル認識票Ｓ０、Ｓ１、およびＳ２を生成する。Ｓ０、Ｓ１、およびＳ２の生成方法は、例えば、実施形態１で図７および図８を用いて説明した方法と同じである。これをもとに図６に示すような変換テーブル１３２７を、サービスＺのサーバの中で他のサービスを一意に表す情報であるサービス認識票などと関連付けて作成する（ステップＳ１５０２）。
【００５２】
前記変換テーブル１３２７は、主記憶手段１３２２に存在するが、ディスク装置などの外部記憶手段には記憶しない。もし、変換テーブルを外部記憶手段で記憶することが必要な場合には、暗号化・復号化手段１３２５が前記変換テーブルを秘密鍵で暗号化し、これを暗号化変換テーブル用サーバ１３５０に送信する。暗号化のための秘密鍵はサービスＺのサーバ１３２０内でのみ保存し、サービスＺのサーバから外部に送信しない。暗号化変換テーブル用サーバ１３５０はその外部記憶手段１３５１に、暗号化変換テーブルを記憶する。サービスＺのサーバは、必要に応じて暗号化変換テーブルを暗号化変換テーブル用サーバ１３５０から呼び出し、主記憶手段において暗号化・復号化手段が秘密鍵を使って復号化した上で、以下に説明する処理をおこなう。なお、ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄと関連づけられた付加情報は、そのままサービスＺのサーバの外部記憶手段などに記憶してもよいし、上記ステップＳ１５０２においてスクランブル認識票Ｓ０、Ｓ１、およびＳ２と各々関連づけた上で、付加情報を含めて暗号化したものを暗号化変換テーブルとしてもよい。また、暗号化の粒度としては、たとえば図６のような暗号化テーブル全体を暗号化してもよく、または検索キーとなる利用者の認識票およびその知人を表すスクランブル認識票群とを単位として暗号化をしてもよい。たとえば、ＩＤｘａ、Ｓ０、Ｓ１、Ｓ２を単位として暗号化し、さらに別途ＩＤｘｂ、Ｓ３、Ｓ４、Ｓ５を単位として暗号化するなどの方法がある。
【００５３】
いま、利用者Ａは、ＷｅｂサービスＹとＷｅｂサービスＸの両方を使っていると仮定する。ＷｅｂサービスＹを利用している利用者Ａの情報端末９２０が、ＷｅｂサービスＹのサーバ４９０に対して、ＷｅｂサービスＸで認識票ＩＤｘａを持つ利用者Ａの、ＷｅｂサービスＸにおける知人の一覧を取得する要求を送る。この要求をＷｅｂサービスＹのサーバ４９０が受信する（ステップＳ１５０３）。次に、ＷｅｂサービスＹのサーバがＩＤｘａとともにこの要求をサービスＺのサーバに送る(ステップＳ１５０４)。これをサービスＺのサーバが受信する。次に、検索手段１３２３がＩＤｘａを検索キーとして主記憶手段にあるサービスＸの変換テーブルを検索し、スクランブル認識票Ｓ０、Ｓ１、およびＳ２および各々に関連づけられた付加情報を得る。送受信手段１３２１がこれらをＷｅｂサービスＹのサーバ４９０に送る（ステップＳ１６０５）。
【００５４】
次に、ＷｅｂサービスＹのサーバのＨＴＭＬ生成手段９１３が、サービスＸを表すサービス認識票、スクランブル認識票Ｓ０、Ｓ１、Ｓ２、および各々の付加情報を含むＨＴＭＬを生成する。次に送受信手段９１１が、生成されたＨＴＭＬコードをＷｅｂサービスＹ利用者の情報端末９２０に送信する（ステップＳ１５０６）。ＷｅｂサービスＹの利用者の情報端末が前記ＨＴＭＬを受信すると、ＨＴＭＬ解析手段９２３がこれを解析し、表示手段を使って表示する。表示手段９２４に表示される利用者ＡのＷｅｂサービスＹの画面については、実施形態１において図１１を用いて説明したとおりである。
【００５５】
図９および図１１を参照して、次に利用者Ａが画面１１００上の利用者Ｂの付加情報１１１０を、入出力手段９２２を通じて選択すると、サービスＸを表すサービス認識票とＳ０を含むＵＲＩが送受信手段９２１を通じてＷｅｂサービスＹのサーバ４９０に送られ、これを送受信手段９１１が受信する（ステップＳ１５０７）。ＷｅｂサービスＹのサーバでは、リダイレクト手段９１４が、ＷｅｂサービスＹの利用者の情報端末９２０からのアクセスをサービスＺのサーバ１３２０にリダイレクトする（ステップＳ１５０８）。もし、利用者ＢもＷｅｂサービスＹの利用者であり、ＷｅｂサービスＹのサーバ４９０が利用者Ｂの情報端末からＷｅｂサービスＸにおける知人の一覧を表示するという要求を受信した場合にも、前記ステップＳ１５０３からステップＳ１５０８と同様の処理がおこなわれる。
【００５６】
次にＷｅｂサービスＹのサーバからリダイレクトされたＵＲＬあるいはＵＲＩを、サービスＺのサーバ１３２０が処理するステップを、図１６を使って説明する。まず前記ステップＳ１５０８でＷｅｂサービスＹのサーバ４９０からのリダイレクトを送受信手段１３２１が受信する（ステップＳ１６０１）。次にＡＰＩ提供手段１３２６がサービス認識票とスクランブル認識票Ｓ０を抽出した上、抽出したサービス認識票と紐付いた変換テーブルにおいてＳＯを検索キーとして検索し、検索結果として利用者Ｂの認識票ＩＤｘｂを得る（ステップＳ１６０２）。次に送受信手段１３２１がＩＤｘｂをＷｅｂサービスＸのサーバ１３１０に送る（ステップＳ１６０３）。これを受信したＷｅｂサービスＸのサーバの検索手段１３１３は、ＩＤｘｂを検索キーとして、コンテンツデータベース１３１４を検索する。次に、ＨＴＭＬ生成手段１３１６が、検索結果として得られた利用者Ｂのコンテンツ情報をＨＴＭＬコードに変換する（ステップＳ１６０４）。次にＷｅｂサービスＸのサーバ１３１０が、生成されたＨＴＭＬコードをＷｅｂサービスＹの利用者である利用者Ａの情報端末９２０に送信する（ステップＳ１６０５）。
【００５７】
次にＷｅｂサービスＹの利用者の情報端末９２０は、前記ステップＳ１６０５で送信されたＨＴＭＬコードを受信し、ＨＴＭＬ解析手段９２３がこれを解析した上、表示手段９２４が解析結果としてのＷｅｂサービスＸのコンテンツ情報を表示する。たとえば利用者Ａが、図１１に示すＷｅｂサービスＹの画面に表示されたＷｅｂサービスＸ上の知人である利用者Ｂのプロフィール１１１０を、入力手段を使って選択すると、表示画面はＷｅｂサービスＸ上のコンテンツである利用者Ｂの写真や日記に遷移する、というような使い方が可能である。
【００５８】
以下では、本実施形態に係る本願発明の効果について説明する。本実施形態は、実施形態１と同様ＷｅｂサービスＸとＷｅｂサービスＹの２つのＷｅｂサービスの間での、ソーシャルグラフの融通を例として本願発明を説明した。しかし現実には、３つ以上の数多くのＷｅｂサービスの間でソーシャルグラフを融通したいという要求がある。このような場合には、実施形態１に示す１対１でのスクランブル認識票の授受に比べて、本実施形態で説明したソーシャルグラフ交換サービスＺが介在する方が、対応するＷｅｂサービス数の増加を実現しやすい。
【図面の簡単な説明】
【００５９】
【図１】従来の方法によるソーシャルグラフを外部に提供するＡＰＩを持つサーバの構成図の一例である。
【図２】Ｗｅｂサービスの保持するソーシャルグラフの一例を表す図である。
【図３】ソーシャルグラフ提供ＡＰＩに対する入出力の一例である。
【図４】本願発明の方法によるソーシャルグラフを外部に提供するＡＰＩを持つＷｅｂサービスＸのサーバの構成図の一例である。
【図５】スクランブル認識票を生成しこれをＷｅｂサービスＹのサーバに送信する処理の一例を説明するフロー図である。
【図６】変換テーブルの一例を表す図である。
【図７】従来の方法と本願発明の方法によるＡＰＩ提供要求に対する入出力を比較した図である。
【図８】従来の方法と本願発明の方法による外部のＷｅｂサービスにおけるソーシャルグラフ再合成を比較した一例を表す図である。
【図９】本願発明の方法によるソーシャルグラフを提供されたＷｅｂサービスＹのサーバの構成図の一例である。
【図１０】ソーシャルグラフを提供されたＷｅｂサービスＹでの処理の一例を説明するフロー図である。
【図１１】ＷｅｂサービスＸとＷｅｂサービスＹの共通の利用者がＷｅｂサービスＹ上でＷｅｂサービスＸの知人一覧を表示させた一例を説明する図である。
【図１２】ＷｅｂサービスＹのサービスを利用中に、ＷｅｂサービスＸでの知人のＷｅｂサービスＸのコンテンツ情報が呼び出された時の処理の一例を説明するフロー図である。
【図１３】本願発明の方法によるソーシャルグラフ交換サービスＺの概略構成図である。
【図１４】ソーシャルグラフを外部に提供するＡＰＩを持つＷｅｂサービスＸのサーバにおける処理の一例を説明したフロー図である。
【図１５】ソーシャルグラフ交換サービスＺのサーバにおける処理の一例を説明するフロー図である。
【図１６】本願発明の方法によるソーシャルグラフを外部に提供するＷｅｂサービスＸのサーバにおける処理の一例を説明するフロー図である。
【符号の説明】
【００６０】
４００ ＷｅｂサービスＸのサーバ
４１０ 記憶手段
４１１ ソーシャルグラフテーブル
４１２ 変換テーブル
４１３ コンテンツ記憶領域
４１４ 種値
４２０ 検索手段
４３０ 認識票変換手段
４４０ 提供手段
４５０ 演算手段
４７０ 送受信手段
４７１ 要求受信手段
４７２ 結果送信手段
４９０ ＷｅｂサービスＹのサーバ
９２０ ＷｅｂサービスＸ及びＷｅｂサービスＹの利用者の情報端末
【技術分野】
【０００１】
本願発明は、サーバと連携してＷｅｂサービスなどのネットワークサービスを提供する情報処理の技術に関する。
【背景技術】
【０００２】
ソーシャル・ネットワーキング・サイト（ＳＮＳ）と呼ばれる、コミュニティ型の会員制Ｗｅｂサービスの普及が著しい（例えば、特許文献１参照。）。ＳＮＳにより、インターネット上で利用者同士の繋がりを構築および促進することができると考えられる。ＳＮＳとしてたとえば非特許文献１などに開示されるウェブサイトが知られている。さらに、最近ではインターネット上にある、検索、写真や動画の共有、販売、チャットや音声によるメッセージ交換を目的とするＷｅｂサービスにおいても、やはり利用者同士の繋がりを構築および促進する目的で上記のＳＮＳ的な機能が提供されている。
【０００３】
ＳＮＳ、もしくはＳＮＳ的機能を有する各種Ｗｅｂサービスにおいては、該当サイトへ様々な情報の入力や登録を行う。さらに、これらの情報を知人と共有、知人と通信をおこない、さらに参加者の中から知人を検索することで、該当サービス上での新たな人間関係を構築、促進することができる。これを実現するために、ＳＮＳ、またはＳＮＳ的機能を有する各種Ｗｅｂサービスの利用者は、あらかじめ何らかの手続きにより該当Ｗｅｂサイトにログインし、さらに他の利用者から検索されるための利用者自身の情報を入力しておく必要がある。
【０００４】
しかし、このようなＳＮＳ、もしくはＳＮＳ的機能を有する各種Ｗｅｂサービスの数が増大した結果、利用者は数多くのＷｅｂサイトで、ログイン、自分の情報登録、共有する情報の入力や登録、知人との通信、知人の検索等を繰り返し実行する必要が生じている。この結果、ログイン情報や共有する情報、さらに知人に関する情報の管理が困難になっている。
【０００５】
この問題の解決に向けて、様々な試みがなされている。ＳＮＳを含む各種Ｗｅｂサービスでは、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）へのアクセスを外部に許可することで、Ｗｅｂサービス間で利用者が共有する情報の相互融通を実現している。また、ＯｐｅｎＩＤ（例えば、非特許文献２参照。）によって、異なるＳＮＳを含むＷｅｂサービスに唯一のログイン情報でログインすることを可能にする試みもなされている。
【０００６】
ネットワーク上の知人同士の関係は、ソーシャルグラフと呼ばれる。上記のような、異なるＳＮＳを含むＷｅｂサービス間での相互融通の対象となる情報には、ソーシャルグラフが含まれる。最近では、これまで各Ｗｅｂサービス内で独立して保持されていたソーシャルグラフを、Ｗｅｂサービスを超えて融通し合うという試みがなされている。（例えば、非特許文献３参照。）Ｓｏｃｉａｌ Ｇｒａｐｈ ＡＰＩはその試みの１つである。Ｓｏｃｉａｌ Ｇｒａｐｈ ＡＰＩは、ある利用者の特定のＷｅｂサービスにおけるＩＤを与えると、戻り値としてその利用者の他のＷｅｂサービスにおけるＩＤを返す。また、ある利用者の特定のＷｅｂサービスにおけるＩＤを与えると、戻り値としてその利用者と様々なＷｅｂサービスにおいて知人関係にある利用者の、各々のＷｅｂサービスにおけるＩＤを返す。Ｗｅｂサービスを超えた、ソーシャルグラフの融通によって、上記情報管理の困難が解決され、その結果各Ｗｅｂサービスへの利用者の訪問が増えることが期待されている。
【特許文献１】米国特許第７０６９３０８号明細書
【非特許文献１】マイスペース株式会社、“ＭｙＳｐａｃｅ”、［online］、［平成２０年１１月２６日検索］、インターネット〈URL：ｈｔｔｐ：／／ｗｗｗ．ｍｙｓｐａｃｅ．ｃｏｍ／〉
【非特許文献２】オープンアイディーファウンデーション、“ＯｐｅｎＩＤ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ２．０ − Ｆｉｎａｌ”、［online］、平成１９年１２月５日、［平成２０年１１月２６日検索］、インターネット〈URL：ｈｔｔｐ：／／ｏｐｅｎｉｄ．ｎｅｔ／ｓｐｅｃｓ／ｏｐｅｎｉｄ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ−２＿０．ｈｔｍｌ〉
【非特許文献３】Ｂｒａｄ Ｆｉｔｚｐａｔｒｉｃｋ、Ｄａｖｉｄ Ｒｅｃｏｒｄｏｎ著、“Ｔｈｏｕｇｈｔｓ ｏｎ ｔｈｅ Ｓｏｃｉａｌ Ｇｒａｐｈ”、［online］、平成１９年８月１７日［平成２０年１１月２６日検索］、インターネット〈URL：ｈｔｔｐ：／／ｂｒａｄｆｉｔｚ．ｃｏｍ／ｓｏｃｉａｌ−ｇｒａｐｈ−ｐｒｏｂｌｅｍ／〉
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、ＳＮＳ、もしくはＳＮＳ的機能を有するＷｅｂサービスを提供する多くの事業者にとって、そのＷｅｂサービス内のソーシャルグラフは、収益の源泉である。また、Ｗｅｂサービス内に閉じたソーシャルグラフは、利用者が他のＷｅｂサービスに移ることを抑止する効果を持つ。従って、主として事業的観点から、ほとんどのＳＮＳを含むＷｅｂサービス事業者は自分のＷｅｂサービス内のソーシャルグラフに対する、他の事業者からのアクセスを許可していない。このため現実には、上に述べたＷｅｂサービスを超えたソーシャルグラフの融通は、ほとんど行われず、上記利用者によるログイン及び情報管理の困難の解消や、各Ｗｅｂサービスの活性化は実現していない。
【０００８】
図１、図２および図３を参照して、Ｗｅｂサービス間でのソーシャルグラフ融通に関する問題点を説明する。図１は、外部からのソーシャルグラフ取得要求に応答する機能を備えたＷｅｂサービスＸのサーバ１００の概略構成図である。サーバ１００は、記憶手段１１０、検索手段１２０、ＡＰＩ提供手段１３０、送受信手段１７０を有する。さらに送受信手段はソーシャルグラフ取得要求を外部のサーバより受信した上で検索キーを検索手段１２０に送る要求受信手段１７１と、検索手段より得た検索結果を、送信したサーバに送信する結果送信手段１７２を含む。このＡＰＩ提供手段１３０は、ＷｅｂサービスＸの利用者をＷｅｂサービスＸ内で一意に特定するための情報である認識票が入力されると、検索手段１２０に要求して、その認識票を有する利用者となんらかの関係がある他の利用者の認識票を戻り値として返す機能を有する手段である。認識票としては、そのＷｅｂサービスを利用するために用いるログイン名、電子メールアドレスなどの利用者を一意に特定する識別情報を用いることができる。
【０００９】
いまたとえば、ＷｅｂサービスＸのサーバの記憶手段１１０に、図２に示すソーシャルグラフが記憶されているとする。図２において１つの点は1人の利用者を表し、一つの直線は２人の利用者の間に関係があることを示す。点はノード、線はエッジと呼ばれる。エッジはその両端のノードの関係を表している。例えば、図２では、たとえば利用者Ａ２０１と利用者Ｂ２０２との間に関係２１１があることを示している。同様にたとえば利用者Ａ２０１と利用者Ｃ２０３との間に関係２１２が、また利用者Ａ２０１と利用者Ｄ２０４との間に関係２１３が、さらに利用者Ｃ２０３と利用者Ｄ２０４との間に関係２１４が、各々ある。なお、図２ではソーシャルグラフをノードとエッジを用いて図示したが、記憶手段１１０に記憶されるソーシャルグラフは、いかなる形式であってもよい。多くの場合、データベースの表として記憶されている。例えば、なんらかの関係のある２人の利用者の認識票を同じ行に記憶することで記憶される。
【００１０】
ここで、たとえばＷｅｂサービスＹのサーバ１９０が、ＷｅｂサービスＸのサーバ１００に対して、利用者ＡのＷｅｂサービスＸにおける認識票ＩＤｘａを送信する。この認識票ＩＤｘａは利用者Ａの認識票であるとする。このＩＤｘａの送信は、利用者Ａと関係のある利用者の認識票を要求することに対応する。ＷｅｂサービスＸのサーバの要求受信手段１７１がＩＤｘａを受信し、ＡＰＩ提供手段１３０の指示により検索手段１１０がこのＩＤｘａを検索キーとして、記憶手段１１０に記憶された、図２に示すソーシャルグラフを検索する。検索の結果、利用者Ａと関係のある利用者Ｂ、利用者Ｃ、および利用者Ｄの認識票ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄが得られる。ＡＰＩ提供手段１３０がこれらの認識票を、結果送信手段１７２を通じてＷｅｂサービスＹのサーバ１９０に返信する。図３には、ＷｅｂサービスＸのサーバの送受信手段１７０に対する入力と出力の関係の一例を示す。すなわち、ＷｅｂサービスＸのサーバ１００に対して、たとえば利用者Ａ、および利用者Ｂそれぞれの認識票を入力したときの出力される認識票を示している。
【００１１】
なお、本明細書では、認識票の表記はすべてＩＤで始まるとする。また３文字目はＷｅｂサービスを、また４文字目は利用者を表す。たとえば、ＩＤｘａは、ＷｅｂサービスＸにおいて利用者Ａを一意に特定するための認識票である。
【００１２】
図１、図２、および図３に示す一例は、ソーシャルグラフを異なるＷｅｂサービス間で融通する典型的な方法である。以下に、この方法のＷｅｂサービス事業者Ｘにとっての問題を示す。この方法では、ＷｅｂサービスＹのサーバ１９０は、各利用者に入力させるなど何らかの方法でＷｅｂサービスＸの利用者の認識票を入手すれば、各々の利用者と関係のある利用者のＷｅｂサービスＸにおける認識票を、たとえば図３のように入手できる。ＷｅｂサービスＹのサーバ１９０は、このような情報から、図２に示すＷｅｂサービスＸにおけるソーシャルグラフの一部または全部を再現できる。通常、Ｗｅｂサービスで使われる認識票は数字または文字の組み合わせである。このため、ＷｅｂサービスＸのサーバに対して、数字または文字の組み合わせを総当たりで要求すれば、ＷｅｂサービスＹがＷｅｂサービスＸの有するソーシャルグラフを全て入手することができる場合もある。
【００１３】
ＷｅｂサービスＹが、ＷｅｂサービスＸのソーシャルグラフの一部または全部を入手することにより、ＷｅｂサービスＸにとっては、以下の利点と欠点が生ずる。
【００１４】
ＷｅｂサービスＸにとって利点は、２つある。第１の利点は、利用者がＷｅｂサービスＸとＷｅｂサービスＹを組み合わせて使うことで、ＷｅｂサービスＸ利用者の利便性が向上する点である。たとえば、ＷｅｂサービスＸがＳＮＳ、ＷｅｂサービスＹがリアルタイム性のあるチャットサービスだったとする。ＷｅｂサービスＸでリアルタイム性のあるチャットサービスを提供していない場合、ＷｅｂサービスＸの利用者は、ＷｅｂサービスＹと組み合わせることで、ＳＮＳで知人同士が情報交換をしながら、必要に応じてリアルタイムでチャットすることが可能になる。ＷｅｂサービスＸは、自らチャットサービスを提供するコスト無く、ユーザに対してより高い利便性を提供できる。第２の利点は、利用者がＷｅｂサービスＹと組み合わせて使うことで、ＷｅｂサービスＸの利用が促進される点である。この例では、ＷｅｂサービスＸの利用者同士が、チャットで情報交換を始めることで、これまで以上の情報交換をＷｅｂサービスＸで行うようになる。
【００１５】
一方、ＷｅｂサービスＸにとっての欠点もある。ＷｅｂサービスＸとＷｅｂサービスＹとが共にＳＮＳであると仮定する。このとき、ＷｅｂサービスＸと競合関係にあるＷｅｂサービスＹが、前記の方法でＷｅｂサービスＸのソーシャルグラフを何の対価も支払わずに入手できることになる。したがって、ＷｅｂサービスＸの利用者の享受する利便性を、そのままＷｅｂサービスＹも実現し提供できるので、ＷｅｂサービスＹは、ＷｅｂサービスＸの利用者を奪うかもしれない。
【００１６】
本願発明によれば、このような従来のＡＰＩ公開によるソーシャルグラフの融通に係る、前記の利点を維持しながら、かつ前記の欠点を解決することが可能となる。また、本願発明によれば、前記のように異なるＷｅｂサービスのサーバ同士がソーシャルグラフを表す情報を直接授受しなくとも、利用者が複数のＷｅｂサービスに分散したソーシャルグラフを統合して利用することができる。このことで利用者にとっての利便性を高め、さらに各Ｗｅｂサービスの利用を促進するための方法を提供できる。
【課題を解決するための手段】
【００１７】
本発明の第１の側面において、ネットワークサービスを提供するためのサーバであって、そのネットワークサービスの利用者をそのネットワークサービスの中で一意に特定するための情報である認識票を受信する受信手段と、受信された認識票と関連付けて記憶された他の利用者の認識票を検索する検索手段と、スクランブル認識票を生成する変換手段と、検索された認識票と生成されたスクランブル認識票とを関連付けて記憶する記憶手段と、生成されたスクランブル認識票を送信する送信手段と、を有することを特徴とするサーバが提供される。ここに、受信された認識票と関連付けて記憶された他の利用者の認識票が複数存在する場合には、変換手段は、複数のスクランブル認識票を生成し、記憶手段は、第１の認識票と第２の認識票と、複数のスクランブル認識票と複数の認識票とのそれぞれを関連付けて記憶し、送信手段は、複数のスクランブル認識票を送信してもよい。
【００１８】
このようなサーバを提供することによる効果の一つとして、受信された認識票の間の関係を秘密に保つことができ、課題が解決される。
【００１９】
また、本発明の第２の側面おいて、上記第１の側面において提供されるサーバからスクランブル認識票を受信する手段を有する第２のサーバが提供される。
【００２０】
このような第２のサーバを、上記第１の側面において提供されるサーバにより提供されるネットワークサービスとは別のネットワークサービスに用いることによる効果の一つとして、別のネットワークサービスから上記第１の側面において提供されるサーバをアクセスすることが可能となり、課題が解決される。
【００２１】
また、本発明の第３の側面において、第一のサーバによって提供される第一のネットワークサービスの利用者を第一のネットワークサービスの中で一意に特定するための情報である認識票を第一のサーバに送信する送信手段と、送信された認識票と第一のサーバにおいて関連付けて記憶された認識票を第一のサーバより受信する受信手段と、スクランブル認識票を生成する変換手段と、第一のサーバより受信された認識票と生成されたスクランブル認識票とを関連付けて記憶する記憶手段と、を有することを特徴とするサーバが提供される。ここに、一の認識票の送信に対して第一のサーバより受信された認識票が複数存在する場合には、変換手段は、複数のスクランブル認識票を生成し、記憶手段は、第一のサーバより受信された複数の認識票と生成された複数のスクランブル認識票とのそれぞれを関連付けて記憶してもよい。
【００２２】
このようなサーバが提供される効果の一つとして、複数のネットワークサービスを横断してスクランブル認識票を生成して認識票と関連付けることができるので、認識票の間の関係などを秘密に保つことができる、課題が解決される。
【発明の効果】
【００２３】
本願発明の方法およびサーバによれば、複数のＷｅｂサービス間で各々のＷｅｂサービス内にある利用者同士の関係を利用し合うことで、各々のＷｅｂサービスの利用を促進しながらも、ひとつのＷｅｂサービスにおける利用者同士の関係を、他のＷｅｂサービスの提供者が再合成することを防止でき、各Ｗｅｂサービス提供者の資産である利用者同士の関係を保護することができる。
【発明を実施するための最良の形態】
【００２４】
以下に本願発明を実施するための、現在考えられる最善の形態について説明する。本願発明の範囲は、添付特許請求の範囲によって明確に定義されているため、この説明は限定的な意味に解釈すべきではなく、単に発明の一般原理を例示する目的で行う。
【００２５】
（実施形態１）
図４は、本願発明の実施形態の一例である、ＷｅｂサービスＸのサーバ４００の概略構成図である。サーバ４００は、外部のＷｅｂサービスとソーシャルグラフについて連携する機能を備えている。サーバ４００は、記憶手段４１０、検索手段４２０、認識票変換手段４３０、ＡＰＩ提供手段４４０、演算手段４５０、送受信手段４７０を有する。さらに送受信手段は特定の利用者と関係を持つ利用者一覧の要求を外部のサーバより受信した上で検索キーを検索手段４２０に送る要求受信手段４７１と、検索手段４２０より得た検索結果を、特定の利用者と関係を持つ利用者リスト要求の送信元に送信する結果送信手段４７２を含む。特定の利用者と関係を持つ利用者リスト要求は、サーバ、例えば、他のＷｅｂサービスのサーバから送信される。ＡＰＩ提供手段４４０は、ＷｅｂサービスＸの利用者をＷｅｂサービスＸ内で一意に特定するための認識票が入力されると、検索手段４２０に検索を要求する。そして、ＡＰＩ提供手段４４０は、その認識票を有する利用者と関係がある他の利用者の認識票が検索されると、さらにこれをスクランブル認識票に変換した上、戻り値として返す機能を備える。
【００２６】
いまたとえば、ＷｅｂサービスＸのサーバの記憶手段のソーシャルグラフテーブル４１１に、図２に示すソーシャルグラフが記憶されているとする。図２ではソーシャルグラフをノードとエッジを用いて図示したが、ソーシャルグラフテーブル４１１に記憶に記憶されるソーシャルグラフは、いかなる形式であってもよく、ここではデータベースのテーブルの形式として記憶されていると仮定する。また、ソーシャルグラフにより関係が存在するとされる利用者は、知人同士であるとみなされることが想定される。例えば、Ｗｅｂサービスに入会するためには、すでに入会している人の招待が必要になっていてもよい。
【００２７】
ここで、たとえばＷｅｂサービスＹのサーバ４９０が、ＷｅｂサービスＸのサーバ４００に対して、利用者ＡのＷｅｂサービスＸにおける認識票ＩＤｘａを送信することで、利用者Ａと知人である関係にある他の利用者のスクランブル認識票および付加情報を要求する（ステップＳ５０１）。付加情報としては、名前、ニックネーム、写真、コメントなど、各々の利用者がＷｅｂサービスＸに登録している情報なら何でもよい。なお、付加情報の要求は必須ではない。ＷｅｂサービスＸのサーバの要求受信手段４７１がＩＤｘａを受信し、ＡＰＩ提供手段４４０の指示により検索手段４２０がこのＩＤｘａを検索キーとして、記憶手段４１０に記憶されたソーシャルグラフテーブル４１１を検索する（ステップＳ５０２）。検索の結果、利用者Ａと関係のある利用者Ｂ、利用者Ｃ、および利用者Ｄの認識票ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄが得られる。
【００２８】
次にＡＰＩ提供手段４４０は、検索キーであるＩＤｘａ、および検索結果であるＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄを、認識票変換手段４３０へ送る（ステップＳ５０３）。次に、認識票変換手段は、検索結果であるＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄの各々に対応するスクランブル認識票Ｓ０、Ｓ１、およびＳ２を生成する（ステップＳ５０４）。Ｓ０、Ｓ１、およびＳ２の生成方法は後述する。次に認識票変換手段は、ＩＤｘｂとＳ０、ＩＤｘｃとＳ１、およびＩＤｘｄとＳ２を各々関連づけて、記憶手段の変換テーブル４１２に記憶する（ステップＳ５０５）。次に、ＡＰＩ提供手段４４０は、結果送信手段４７２を通じてＳ０、Ｓ１、およびＳ２を各々、利用者Ｂ、Ｃ、およびＤの各々の付加情報に関連づけた上、ＷｅｂサービスＹのサーバ４９０に送信する（ステップＳ５０６）。
【００２９】
図６に、変換テーブル４１２の一例を示す。変換テーブルは検索キーからなる列、および検索結果の認識票からなる行のマトリクスである。この例では、検索キーはステップＳ５０１でＷｅｂサービスＸのサーバ４００が受信した認識票であり、例えばＩＤｘａとなる。このため、変換テーブルにおけるＩＤｘａの列６１０の、ＩＤｘｂの行６１２にＳ０が、ＩＤｘｃの行６１３にＳ１が、ＩＤｘｄの行６１４にＳ２が、各々記憶される。図６は、変換テーブルの一例であり、異なる形態のテーブルであっても、図６と同じ情報が表現されていればよい。
【００３０】
次に、たとえばＷｅｂサービスＹのサーバ４９０が、ＷｅｂサービスＸのサーバ４００に対して、利用者ＢのＷｅｂサービスＸにおける認識票ＩＤｘｂを送信することで、利用者Ｂと関係のある利用者のスクランブル認識票および付加情報を要求する（ステップＳ５０７）。ＷｅｂサービスＸのサーバの要求受信手段４７１がＩＤｘｂを受信し、ＡＰＩ提供手段４４０の指示により検索手段４２０がこのＩＤｘｂを検索キーとして、記憶手段４１０に記憶された図２に示すソーシャルグラフを検索する（ステップＳ５０８）。検索の結果、利用者Ｂと関係のある利用者Ａ、利用者Ｄ、および利用者Ｅの認識票ＩＤｘａ、ＩＤｘｄ、およびＩＤｘｅが得られる。
【００３１】
次にＡＰＩ提供手段４４０は、検索キーであるＩＤｘｂ、および検索結果であるＩＤｘａ、ＩＤｘｄ、およびＩＤｘｅを、認識票変換手段４３０へ送る（ステップＳ５０９）。次に、認識票変換手段は、検索結果であるＩＤｘａ、ＩＤｘｄ、およびＩＤｘｅの各々に対応するスクランブル認識票Ｓ３、Ｓ４、およびＳ５を生成する（ステップＳ５１０）。Ｓ３、Ｓ４、およびＳ５の生成方法は後述する。次に認識票変換手段は、ＩＤｘａとＳ３、ＩＤｘｄとＳ４、およびＩＤｘｅとＳ５を各々関連づけて、記憶手段の変換テーブル４１２に記憶する（ステップＳ５１１）。図６を参照すると、この例で検索キーは、ステップＳ５０７でＷｅｂサービスＸのサーバ４００が受信したＩＤｘｂである。このため、変換テーブルにおけるＩＤｘｂの列６２０の、ＩＤｘａの行６２１にＳ３が、ＩＤｘｄの行６２４にＳ４が、ＩＤｘｅの行６２５にＳ５が、各々記憶される。次に、ＡＰＩ提供手段４４０は、結果送信手段４７２を通じてＳ３、Ｓ４、およびＳ５を、各々利用者Ａ、Ｄ、およびＥの付加情報を関連づけた上、ＷｅｂサービスＹのサーバ４９０に送信する（ステップＳ５１２）。なお、図６には上記ＩＤｘａおよびＩＤｘｂに加えて、参考のためにＩＤｘｃ、ＩＤｘｄ、ＩＤｘｅ、ＩＤｘｆ、ＩＤｘｇの各々について、ＷｅｂサービスＸのサーバが知人の情報提供要求した場合の、スクランブル認識票も記した。前記変換テーブルはＷｅｂサービスＸのサーバの記憶手段４１０に記憶されていてもよく、またはＷｅｂサービスＸのサーバにネットワークを経由して接続された他のサーバの記憶手段または外部記憶手段に記憶されていてもよい。
【００３２】
ここで、ステップＳ５０４およびステップＳ５１０におけるスクランブル認識票の生成方法について説明する。本願発明の一実施形態において、検索結果である認識票をスクランブル認識票に変換するのは、ＷｅｂサービスＹのサーバの要求により上記ステップＳ５０１からＳ５１２までのステップが実行されても、ＷｅｂサービスＹのサーバがＷｅｂサービスＸのソーシャルグラフを再合成できないことが目的である。
【００３３】
図７は、ＷｅｂサービスＸのサーバ４００に対する要求および結果の関係について、従来の方法と本願発明の一実施形態による方法を比較したものである。従来の方法による結果を受信したＷｅｂサービスＹのサーバ４９０は、図８（ａ）に示すように、図２に示したソーシャルグラフの一部を再合成できる。たとえばこの結果、ＷｅｂサービスＹのサーバ４９０では、図８におけるエッジ８０１とエッジ８０２から、認識票ＩＤｘｄを持つ利用者Ｄが認識票ＩＤｘａを持つ利用者Ａと認識票ＩＤｘｂを持つ利用者Ｂとの共通の知人であることを知ることができる。本願発明による方法では、ＷｅｂサービスＹのサーバ４９０が得る情報は図８（ｂ）のとおりである。このＳ０からＳ５を適切に生成することで、ＷｅｂサービスＹのサーバ４９０では、ＷｅｂサービスＸ上のソーシャルグラフを再合成することができない。すなわち、本願発明による方法によれば、利用者Ｄが利用者Ａと利用者Ｂとの共通の知人であることを知ることができない。
【００３４】
ステップＳ５０４およびステップＳ５１０における、認識票からスクランブル認識票への変換は、このようにＷｅｂサービスＹのサーバ４９０でＷｅｂサービスＸのソーシャルグラフを再合成できないようなスクランブル認識票の変換方法であれば、どのような方法でもよい。このような変換方法としてのスクランブル認識票の生成方法の一例としては、演算手段４５０が生成する乱数を、順次Ｓ０、Ｓ１、Ｓ２、Ｓ３、Ｓ４、Ｓ５とする方法がある。この方法では、図８（ｂ）に示すようにＷｅｂサービスＹのサーバ４９０が受け取るＳ０からＳ５は無作為に選択された数値、文字列のいずれか１以上を含んでいてよい。無作為とは、検索結果である認識票とそれに対して生成されるスクランブル認識票との対応関係に法則性が存在しないことをいう。無作為であっても、生成される認識票は全て等しくなく、言い換えると異なるのが好ましい。この場合、たとえば同じＩＤｘｄから変換されたＳ２およびＳ４は異なる値となるため、ＷｅｂサービスＹのサーバ４９０では、利用者Ｄが利用者Ａと利用者Ｂの共通の知人であることを知る手段はない。
【００３５】
またスクランブル認識票を生成する方法の他の一例としては、要求と結果の演算結果をスクランブル認識票とする方法がある。たとえば、ＷｅｂサービスＸのサーバＸの演算手段４５０がステップＳ５０１で受信した認識票ＩＤｘａと、検索結果であるＩＤｘｂ、ＩＤｘｃ、ＩＤｘｄそれぞれとの所定の演算（例えば、積の演算など）の結果を各々Ｓ０、Ｓ１、およびＳ２とする。なお、認識票が文字列であれば、積の演算は文字列の連接などとして定義できる。同様にたとえば、認識票ＩＤｘｂと、検索結果であるＩＤｘａ、ＩＤｘｄ、ＩＤｘｅそれぞれとの積などを各々Ｓ３、Ｓ４、およびＳ５とする。この場合、ＩＤｘｄから変換されたＳ２およびＳ４は異なる値となるため、ＷｅｂサービスＹのサーバ４９０では、利用者Ｄが利用者Ａと利用者Ｂの共通の知人であることを知る手段はない。また、所定の演算の一例としては、Ｗｅｂサービスに固有の数値（もしくは種値）を定数として含む演算であってもよい。すなわち、Ｗｅｂサービスに対して一意に決まる数値（もしくは種値）を変数としてもつ演算であってもよい。もし３つ以上のＷｅｂサービスが本願発明の一実施形態による方法でソーシャルグラフを利用し合う場合には、各Ｗｅｂサービスが数値（もしくは種値）として相互に異なる定数を用いることで、ソーシャルグラフの秘匿性を高めることができる。サービスＸがインターネット上で一意に決まるような値を数値（もしくは種値）として用いてもよい。
【００３６】
次に、スクランブル認識票および付加情報を受信した後の、ＷｅｂサービスＹのサーバ４９０における処理について図９、図１０、および図１１を参照して説明する。図９は、ＷｅｂサービスＹのサーバ４９０の概略構成図である。ＷｅｂサービスＹのサーバは、送受信手段９１１、記憶手段９１２、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）生成手段９１３、リダイレクト手段９１４を有する。ＷｅｂサービスＹのサーバ４９０は、ネットワークを通じてＷｅｂサービスＹの利用者の情報端末９２０に接続されている。図１０は、ＷｅｂサービスＹのサーバ４９０の処理を説明するフロー図である。
【００３７】
ステップＳ５０６でＷｅｂサービスＸのサーバ４００から送信されたスクランブル認識票Ｓ０、Ｓ１、Ｓ２、および各々に関連づけられた付加情報を、ＷｅｂサービスＹのサーバの送受信手段９１１が受信し、記憶手段９１２に記憶する（ステップＳ１００１）。同様に、ステップＳ５１２でＷｅｂサービスＸのサーバ４００から送信されたスクランブル認識票Ｓ３、Ｓ４、Ｓ５、および各々に関連づけられた付加情報を、ＷｅｂサービスＹのサーバの送受信手段９１１が受信し、記憶手段９１２に記憶する（ステップＳ１００２）。
【００３８】
次にＷｅｂサービスＹを利用している利用者Ａの情報端末９２０から、ＷｅｂサービスＹのサーバ４９０に対して、利用者ＡのＷｅｂサービスＸにおける知人の一覧を取得する要求が送られる。ここで、利用者ＡはＷｅｂサービスＹとＷｅｂサービスＸの両方を使っていると仮定する。次に、ＷｅｂサービスＹのサーバ４９０が前記要求を受信する（ステップＳ１００３）。次に、ＷｅｂサービスＹのサーバのＨＴＭＬ生成手段９１３が、前記ステップＳ１００１で受信したスクランブル認識票Ｓ０、Ｓ１、Ｓ２、および各々の付加情報を含むＨＴＭＬコードを生成する。埋め込まれたＨＴＭＬコードの一例は後に図１１を参照しながら説明する。次に送受信手段９１１が、生成されたＨＴＭＬコードをＷｅｂサービスＹ利用者の情報端末９２０に送信する（ステップＳ１００４）。ＷｅｂサービスＹの利用者の情報端末が前記ＨＴＭＬコードを受信すると、ＨＴＭＬ解析手段９２３がこれを解析し、表示手段９２４を使って表示する。
【００３９】
図１１は、表示手段９２４に表示された利用者ＡのＷｅｂサービスＹ画面の一例である。利用者Ａは、ＷｅｂサービスＹ、ＷｅｂサービスＸの両方の利用者である。利用者ＡのＷｅｂサービスＸでの認識票はＩＤｘａである。図１１では、ＷｅｂサービスＹのウィンドウ１１００の中に、ＷｅｂサービスＸにおける利用者Ａの知人の情報１１０１が表示されている。図２に示すとおり、利用者ＡのＷｅｂサービスＸにおける知人は、利用者Ｂ、Ｃ、およびＤである。このため、ＷｅｂサービスＸの知人の情報１１０１には、利用者Ｂの付加情報１１１０、利用者Ｃの付加情報１１２０、および利用者Ｄの付加情報１１３０が表示されている。これらの付加情報は上記ステップＳ１００４で生成されるＨＴＭＬコードに組み込まれたものである。たとえば、図１１の例では、利用者Ｂの付加情報として、ＷｅｂサービスＸ上のニックネーム１１１１、アバター１１１２、およびメッセージ１１１３が表示されている。
【００４０】
図１１の利用者Ｂ、利用者Ｃ、および利用者Ｄを表示するＨＴＭＬコードには、前記スクランブル認識票Ｓ０、Ｓ１、およびＳ２が各々埋め込まれている。いま、たとえばＷｅｂサービスＸのサーバ４００のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＸ．ｃｏｍ／、ＷｅｂサービスＹのサーバ４９０のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＹ．ｃｏｍ／、ＷｅｂサービスＹのサーバの中でサービスＸを表すサービス認識票がｓｅｒｖｉｃｅＩＤＸだったとすると、図１１に示す画面のＨＴＭＬコードにおいて、利用者Ｂの付加情報１１１０は、＜ａ ｈｒｅｆ＝“ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＹ．ｃｏｍ／？ｓｅｒｖｉｃｅＩＤ＝ｓｅｒｖｉｃｅＩＤＸ＆ｉｄ＝Ｓ０”＞と＜／ａ＞との間に記述される。
【００４１】
したがって、利用者Ａが画面１１００上の利用者Ｂの付加情報１１１０を、入出力手段９２２を通じて選択すると、Ｓ０が埋め込まれたＵＲＩが送受信手段９２１を通じてＷｅｂサービスＹのサーバ４９０に送信され、これを送受信手段９１１が受信する（ステップＳ１００５）。ＷｅｂサービスＹのサーバでは、リダイレクト手段９１４が、ＷｅｂサービスＹの利用者の情報端末９２０から受信した前記ＵＲＩからリダイレクト先を計算し、ＷｅｂサービスＸのサーバ４００にリダイレクトする（ステップＳ１００６）。もし、利用者ＢもＷｅｂサービスＹの利用者であり、ＷｅｂサービスＹのサーバ４９０が利用者Ｂの情報端末からＷｅｂサービスＸにおける知人の一覧を表示するという要求を受信した場合にも、前記ステップＳ１００３からステップＳ１００６と同様の処理がおこなわれる。
【００４２】
次にＷｅｂサービスＹのサーバからリダイレクトされたＵＲＩを、ＷｅｂサービスＸのサーバ４００が処理するステップを、図１２を使って説明する。まず前記ステップＳ１００６でＷｅｂサービスＹのサーバ４９０からリダイレクトされたＵＲＩであるｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＸ．ｃｏｍ／？ｉｄ＝Ｓ０を送受信手段４７０が受信する（ステップＳ１２０１）。次にＡＰＩ提供手段４４０がスクランブル認識票Ｓ０を抽出した上、これを検索キーとして変換テーブル４１２を検索し、検索結果として認識票ＩＤｘｂを得る（ステップＳ１２０２）。次に、ＡＰＩ提供手段が、認識票ＩＤｘｂに関連づけられたコンテンツ情報を記憶手段４１０のコンテンツ記憶領域４１３からロードする（ステップＳ１２０３）。次にＡＰＩ提供手段がコンテンツ情報を情報端末のＷｅｂブラウザで表示するためのＨＴＭＬコードを生成する（ステップＳ１２０４）。次に送受信手段４７０が、生成された前記ＨＴＭＬコードを、ネットワークを通じてＷｅｂサービスＹの利用者Ａの情報端末９２０に送信する（ステップＳ１２０５）。
【００４３】
次にＷｅｂサービスＹの利用者の情報端末９２０は、前記ステップＳ１２０５で送信されたＨＴＭＬコードを受信し、ＨＴＭＬ解析手段９２３がこれを解析した上、表示手段９２４が解析結果としてのＷｅｂサービスＸのコンテンツ情報を表示する。たとえば利用者Ａが、図１１に示すＷｅｂサービスＹの画面に表示されたＷｅｂサービスＸ上の知人である利用者Ｂのプロフィール１１１０を、入力手段９２２を使って選択すると、表示画面はＷｅｂサービスＸ上のコンテンツである利用者Ｂの写真や日記に遷移する、というような使い方が可能である。
【００４４】
なお、本実施形態に示す一例ではサービス認識票およびスクランブル認識票をＵＲＩやＵＲＬとしてＨＴＭＬコードに埋め込んだが、ＷｅｂサービスＹのサーバ４９０から送信する情報にスクランブル認識票が含まれており、利用者Ａの情報端末９２０において、ＷｅｂサービスＹの画面上に、ＷｅｂサービスＸにおける利用者Ａの知人の情報を表示することができれば、データの形式は何でもよい。また、本実施形態に示す一例では、図１１の利用者Ｂ、利用者Ｃ、および利用者Ｄを表示するＨＴＭＬコードに含まれるＵＲＬにはサービスＹのサーバのＵＲＬとサービスＹの中でサービスＸを表すサービス認識票とスクランブル認識票を埋め込んだが、サービスＸのＵＲＬとスクランブル認識票を組み合わせたＵＲＬとしてもよい。また、本実施形態に示す一例では、ＷｅｂサービスＸは、利用者の有する何らかのコンテンツ情報を表示するサービスとしたが、本願発明では、ＷｅｂサービスＸはどのようなサービスでもよい。たとえば、ＷｅｂサービスＸやＷｅｂサービスＹはチャットや音声通話などのメッセンジャーサービスであってよい。
【００４５】
また、ＷｅｂサービスＸのサーバとＷｅｂサービスＹのサーバの間の、ネットワークを通じた認識票やスクランブル認識票の送受信が暗号化された状態で実行されてもよい。
【００４６】
以下では、本願発明の効果について説明する。本実施形態に示す一例で、利用者ＡがＷｅｂサービスＸとＷｅｂサービスＹの両方を利用しており、ＷｅｂサービスＸをチャットサービス、ＷｅｂサービスＹをＳＮＳであると仮定する。いま、利用者ＡがＳＮＳサービスＹにチャットサービスＸにおける利用者Ａ自身の認識票を登録しておく。図１１に示したように、利用者ＡはＳＮＳサービスＹの表示画面において、チャットサービスＸにおける友人一覧を表示させることができる。さらに利用者Ａは、ＳＮＳサービスＹの画面に表示された友人一覧の中の1人を選択すると、チャットサービスＸの画面に遷移した上、選択した友人とチャットサービスＸを通じて通信が開始できる。このようにして、ＸおよびＹの２つのＷｅｂサービスを統合して、ソーシャルグラフを使うことができるようになる。この結果、利用者の利便性が増大するとともに、チャットサービスＸ、およびＳＮＳサービスＹの両方の利用が促進される。
【００４７】
これと同等の複数サービスの間でのソーシャルグラフの融通は、ＡＰＩを通じて各サービスの認識票同士の関係を直接サービス間で授受する従来の方法によっても、または本願発明の方法によっても実現可能である。しかし、従来の方法によれば、図７および図８（ｂ）を使って既に説明したように、ＳＮＳサービスＹのサーバ４９０でチャットサービスＸ上のソーシャルグラフを再合成可能であった。もし利用者Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧが、上記利用者Ａと同じようにＳＮＳサービスＹからチャットサービスＸを利用すると、図２に示すチャットサービスＸのソーシャルグラフを、ＷｅｂサービスＹのサーバが再合成することが可能となる。これはほとんどの場合、事業的観点からチャットサービスＸの望むところではない。このために、従来の方法によるソーシャルグラフの相互利用が進まなかった。その結果として利用者の利便性向上やチャットサービスＸやＳＮＳサービスＹの利用促進が実現しなかった。
【００４８】
しかし、本願発明の方法によれば、このような複数サービスの間でのソーシャルグラフの相互利用を実現したとしても、図７および図８（ａ）を使って説明したように、ＳＮＳサービスＹのサーバ４９０が、チャットサービスＸのソーシャルグラフを再合成することは困難あるいは不可能である。このため、Ｗｅｂサービスを超えたソーシャルグラフの相互利用が促進され、利用者の利便性とチャットサービスＸとＳＮＳサービスＹの両方の利用が促進されるという効果がある。
【００４９】
（実施形態２）
図１３に、本願発明の実施形態の他の一例の概略構成図を示す。本実施形態では、ＷｅｂサービスＸのサーバ１３１０とＷｅｂサービスＹのサーバ４９０との間でのソーシャルグラフの相互利用に、ソーシャルグラフ交換サービスＺ（以下サービスＺ）のサーバ１３２０が存在する。またサービスＺのサーバで作成した暗号化変換テーブルを外部記憶手段において保存する場合には、暗号化変換テーブル用サーバ１３５０を使う。なお、暗号化変換テーブルは暗号化変換テーブル用サーバの外部記憶手段１３５１に記憶することは必須ではない。これら４つのサーバ、およびＷｅｂサービスＹの利用者Ａの情報端末９２０は、ネットワークで接続されている。本実施形態では、ＷｅｂサービスＸのサーバ１３１０は、送受信手段１３１１、記憶手段１３１２、検索手段１３１３、およびＨＴＭＬ生成手段１３１６を有する。またサービスＺのサーバ１３２０は、送受信手段１３２１、主記憶手段１３２２、認識票変換手段１３２４、暗号化・復号化手段１３２５、ＡＰＩ提供手段１３２６、および検索手段１３２３を有する。なお、ＷｅｂサービスＸのサーバの記憶手段にあるソーシャルグラフテーブル１３１５には、図２に示すソーシャルグラフがあらかじめ記憶されているとする。図２に示すソーシャルグラフは、いかなる形式で記憶されていてもよく、ここではデータベースのテーブルとして記憶されている。
【００５０】
以下では、本実施形態による、ＷｅｂサービスＸとＷｅｂサービスＹとの間のソーシャルグラフの相互利用の方法を説明する。まず図１４を参照して、ＷｅｂサービスＸのサーバ１３１０が、サービスＺのサーバからの、特定の利用者の知人の認識票要求に対して、結果をＷｅｂサービスＺのサーバに送る各ステップを説明する。はじめに、サービスＺのサーバ１３２０が、ＷｅｂサービスＸのサーバ１３１０に対して、利用者ＡのＷｅｂサービスＸにおける認識票ＩＤｘａを送信することで、利用者Ａと知人である利用者の認識票および付加情報を要求する（ステップＳ１４０１）。付加情報としては、名前、ニックネーム、写真、コメントなど、利用者ＡがＷｅｂサービスＸに登録している情報なら何でもよい。また、付加情報は必須となるものではない。ＷｅｂサービスＸのサーバの送受信手段１３１１がＩＤｘａを受信し、検索手段１３１３がこのＩＤｘａを検索キーとして、記憶手段１３１２に記憶されたソーシャルグラフテーブル１３１５を検索する（ステップＳ１４０２）。検索の結果、利用者Ａと知人関係にある利用者Ｂ、利用者Ｃ、および利用者Ｄの認識票ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄが得られる。送受信手段１３１１はこれらの認識票に付加情報を各々関連づけてサービスＺのサーバ１３２０に送る（ステップＳ１４０３）。同様に、ＷｅｂサービスＸのサーバ１３１０は、サービスＺのサーバ１３２０からのＩＤｘｂの要求に対して、検索結果として利用者Ｂと知人関係にある利用者Ａ、利用者Ｄ、および利用者Ｅの認識票ＩＤｘａ、ＩＤｘｄ、およびＩＤｘｅ、および各々に関連づけられた付加情報を送信する（ステップＳ１４０４からステップＳ１４０６）。
【００５１】
次にサービスＺのサーバは、ＷｅｂサービスＹのサーバがＷｅｂサービスＸの有するソーシャルグラフを再合成できないように、前記ステップＳ１４０３でＷｅｂサービスＸのサーバが送信した情報を以下のように処理する。サービスＺのサーバ１３２０は、利用者Ａと知人関係のある利用者Ｂ、利用者Ｃ、および利用者Ｄの認識票ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄ、および各々に関連づけられた付加情報を受信する（ステップＳ１５０１）。次に、認識票変換手段は、検索結果であるＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄの各々に対応するスクランブル認識票Ｓ０、Ｓ１、およびＳ２を生成する。Ｓ０、Ｓ１、およびＳ２の生成方法は、例えば、実施形態１で図７および図８を用いて説明した方法と同じである。これをもとに図６に示すような変換テーブル１３２７を、サービスＺのサーバの中で他のサービスを一意に表す情報であるサービス認識票などと関連付けて作成する（ステップＳ１５０２）。
【００５２】
前記変換テーブル１３２７は、主記憶手段１３２２に存在するが、ディスク装置などの外部記憶手段には記憶しない。もし、変換テーブルを外部記憶手段で記憶することが必要な場合には、暗号化・復号化手段１３２５が前記変換テーブルを秘密鍵で暗号化し、これを暗号化変換テーブル用サーバ１３５０に送信する。暗号化のための秘密鍵はサービスＺのサーバ１３２０内でのみ保存し、サービスＺのサーバから外部に送信しない。暗号化変換テーブル用サーバ１３５０はその外部記憶手段１３５１に、暗号化変換テーブルを記憶する。サービスＺのサーバは、必要に応じて暗号化変換テーブルを暗号化変換テーブル用サーバ１３５０から呼び出し、主記憶手段において暗号化・復号化手段が秘密鍵を使って復号化した上で、以下に説明する処理をおこなう。なお、ＩＤｘｂ、ＩＤｘｃ、およびＩＤｘｄと関連づけられた付加情報は、そのままサービスＺのサーバの外部記憶手段などに記憶してもよいし、上記ステップＳ１５０２においてスクランブル認識票Ｓ０、Ｓ１、およびＳ２と各々関連づけた上で、付加情報を含めて暗号化したものを暗号化変換テーブルとしてもよい。また、暗号化の粒度としては、たとえば図６のような暗号化テーブル全体を暗号化してもよく、または検索キーとなる利用者の認識票およびその知人を表すスクランブル認識票群とを単位として暗号化をしてもよい。たとえば、ＩＤｘａ、Ｓ０、Ｓ１、Ｓ２を単位として暗号化し、さらに別途ＩＤｘｂ、Ｓ３、Ｓ４、Ｓ５を単位として暗号化するなどの方法がある。
【００５３】
いま、利用者Ａは、ＷｅｂサービスＹとＷｅｂサービスＸの両方を使っていると仮定する。ＷｅｂサービスＹを利用している利用者Ａの情報端末９２０が、ＷｅｂサービスＹのサーバ４９０に対して、ＷｅｂサービスＸで認識票ＩＤｘａを持つ利用者Ａの、ＷｅｂサービスＸにおける知人の一覧を取得する要求を送る。この要求をＷｅｂサービスＹのサーバ４９０が受信する（ステップＳ１５０３）。次に、ＷｅｂサービスＹのサーバがＩＤｘａとともにこの要求をサービスＺのサーバに送る(ステップＳ１５０４)。これをサービスＺのサーバが受信する。次に、検索手段１３２３がＩＤｘａを検索キーとして主記憶手段にあるサービスＸの変換テーブルを検索し、スクランブル認識票Ｓ０、Ｓ１、およびＳ２および各々に関連づけられた付加情報を得る。送受信手段１３２１がこれらをＷｅｂサービスＹのサーバ４９０に送る（ステップＳ１６０５）。
【００５４】
次に、ＷｅｂサービスＹのサーバのＨＴＭＬ生成手段９１３が、サービスＸを表すサービス認識票、スクランブル認識票Ｓ０、Ｓ１、Ｓ２、および各々の付加情報を含むＨＴＭＬを生成する。次に送受信手段９１１が、生成されたＨＴＭＬコードをＷｅｂサービスＹ利用者の情報端末９２０に送信する（ステップＳ１５０６）。ＷｅｂサービスＹの利用者の情報端末が前記ＨＴＭＬを受信すると、ＨＴＭＬ解析手段９２３がこれを解析し、表示手段を使って表示する。表示手段９２４に表示される利用者ＡのＷｅｂサービスＹの画面については、実施形態１において図１１を用いて説明したとおりである。
【００５５】
図９および図１１を参照して、次に利用者Ａが画面１１００上の利用者Ｂの付加情報１１１０を、入出力手段９２２を通じて選択すると、サービスＸを表すサービス認識票とＳ０を含むＵＲＩが送受信手段９２１を通じてＷｅｂサービスＹのサーバ４９０に送られ、これを送受信手段９１１が受信する（ステップＳ１５０７）。ＷｅｂサービスＹのサーバでは、リダイレクト手段９１４が、ＷｅｂサービスＹの利用者の情報端末９２０からのアクセスをサービスＺのサーバ１３２０にリダイレクトする（ステップＳ１５０８）。もし、利用者ＢもＷｅｂサービスＹの利用者であり、ＷｅｂサービスＹのサーバ４９０が利用者Ｂの情報端末からＷｅｂサービスＸにおける知人の一覧を表示するという要求を受信した場合にも、前記ステップＳ１５０３からステップＳ１５０８と同様の処理がおこなわれる。
【００５６】
次にＷｅｂサービスＹのサーバからリダイレクトされたＵＲＬあるいはＵＲＩを、サービスＺのサーバ１３２０が処理するステップを、図１６を使って説明する。まず前記ステップＳ１５０８でＷｅｂサービスＹのサーバ４９０からのリダイレクトを送受信手段１３２１が受信する（ステップＳ１６０１）。次にＡＰＩ提供手段１３２６がサービス認識票とスクランブル認識票Ｓ０を抽出した上、抽出したサービス認識票と紐付いた変換テーブルにおいてＳＯを検索キーとして検索し、検索結果として利用者Ｂの認識票ＩＤｘｂを得る（ステップＳ１６０２）。次に送受信手段１３２１がＩＤｘｂをＷｅｂサービスＸのサーバ１３１０に送る（ステップＳ１６０３）。これを受信したＷｅｂサービスＸのサーバの検索手段１３１３は、ＩＤｘｂを検索キーとして、コンテンツデータベース１３１４を検索する。次に、ＨＴＭＬ生成手段１３１６が、検索結果として得られた利用者Ｂのコンテンツ情報をＨＴＭＬコードに変換する（ステップＳ１６０４）。次にＷｅｂサービスＸのサーバ１３１０が、生成されたＨＴＭＬコードをＷｅｂサービスＹの利用者である利用者Ａの情報端末９２０に送信する（ステップＳ１６０５）。
【００５７】
次にＷｅｂサービスＹの利用者の情報端末９２０は、前記ステップＳ１６０５で送信されたＨＴＭＬコードを受信し、ＨＴＭＬ解析手段９２３がこれを解析した上、表示手段９２４が解析結果としてのＷｅｂサービスＸのコンテンツ情報を表示する。たとえば利用者Ａが、図１１に示すＷｅｂサービスＹの画面に表示されたＷｅｂサービスＸ上の知人である利用者Ｂのプロフィール１１１０を、入力手段を使って選択すると、表示画面はＷｅｂサービスＸ上のコンテンツである利用者Ｂの写真や日記に遷移する、というような使い方が可能である。
【００５８】
以下では、本実施形態に係る本願発明の効果について説明する。本実施形態は、実施形態１と同様ＷｅｂサービスＸとＷｅｂサービスＹの２つのＷｅｂサービスの間での、ソーシャルグラフの融通を例として本願発明を説明した。しかし現実には、３つ以上の数多くのＷｅｂサービスの間でソーシャルグラフを融通したいという要求がある。このような場合には、実施形態１に示す１対１でのスクランブル認識票の授受に比べて、本実施形態で説明したソーシャルグラフ交換サービスＺが介在する方が、対応するＷｅｂサービス数の増加を実現しやすい。
【図面の簡単な説明】
【００５９】
【図１】従来の方法によるソーシャルグラフを外部に提供するＡＰＩを持つサーバの構成図の一例である。
【図２】Ｗｅｂサービスの保持するソーシャルグラフの一例を表す図である。
【図３】ソーシャルグラフ提供ＡＰＩに対する入出力の一例である。
【図４】本願発明の方法によるソーシャルグラフを外部に提供するＡＰＩを持つＷｅｂサービスＸのサーバの構成図の一例である。
【図５】スクランブル認識票を生成しこれをＷｅｂサービスＹのサーバに送信する処理の一例を説明するフロー図である。
【図６】変換テーブルの一例を表す図である。
【図７】従来の方法と本願発明の方法によるＡＰＩ提供要求に対する入出力を比較した図である。
【図８】従来の方法と本願発明の方法による外部のＷｅｂサービスにおけるソーシャルグラフ再合成を比較した一例を表す図である。
【図９】本願発明の方法によるソーシャルグラフを提供されたＷｅｂサービスＹのサーバの構成図の一例である。
【図１０】ソーシャルグラフを提供されたＷｅｂサービスＹでの処理の一例を説明するフロー図である。
【図１１】ＷｅｂサービスＸとＷｅｂサービスＹの共通の利用者がＷｅｂサービスＹ上でＷｅｂサービスＸの知人一覧を表示させた一例を説明する図である。
【図１２】ＷｅｂサービスＹのサービスを利用中に、ＷｅｂサービスＸでの知人のＷｅｂサービスＸのコンテンツ情報が呼び出された時の処理の一例を説明するフロー図である。
【図１３】本願発明の方法によるソーシャルグラフ交換サービスＺの概略構成図である。
【図１４】ソーシャルグラフを外部に提供するＡＰＩを持つＷｅｂサービスＸのサーバにおける処理の一例を説明したフロー図である。
【図１５】ソーシャルグラフ交換サービスＺのサーバにおける処理の一例を説明するフロー図である。
【図１６】本願発明の方法によるソーシャルグラフを外部に提供するＷｅｂサービスＸのサーバにおける処理の一例を説明するフロー図である。
【符号の説明】
【００６０】
４００ ＷｅｂサービスＸのサーバ
４１０ 記憶手段
４１１ ソーシャルグラフテーブル
４１２ 変換テーブル
４１３ コンテンツ記憶領域
４１４ 種値
４２０ 検索手段
４３０ 認識票変換手段
４４０ 提供手段
４５０ 演算手段
４７０ 送受信手段
４７１ 要求受信手段
４７２ 結果送信手段
４９０ ＷｅｂサービスＹのサーバ
９２０ ＷｅｂサービスＸ及びＷｅｂサービスＹの利用者の情報端末
【特許請求の範囲】
【請求項１】
ネットワークサービスを提供するためのサーバであって、
前記ネットワークサービスの第一の利用者を前記ネットワークサービスの利用者の中で一意に特定するための情報である認識票を受信する受信手段と、
前記認識票と関連付けられている認識票であって、前記ネットワークサービスの第二の利用者および第三の利用者を、各々前記ネットワークサービス利用者の中で一意に特定する第一の検索結果認識票および第二の検索結果認識票をそれぞれ検索する検索手段と、
第一のスクランブル認識票および第二のスクランブル認識票を生成する変換手段と、
前記第一の検索結果認識票と前記第一のスクランブル認識票とを関連付け、かつ前記第二の検索結果認識票と前記第二のスクランブル認識票とを関連付けて記憶する記憶手段と、
前記第一のスクランブル認識票および前記第二のスクランブル認識票を送信する送信手段と、
を有することを特徴とするサーバ。
【請求項２】
前記第一のスクランブル認識票および前記第二のスクランブル認識票は、前記変換手段が無作為に生成した数値であることを特徴とする請求項１記載のサーバ。
【請求項３】
前記第一のスクランブル認識票および前記第二のスクランブル認識票は、前記変換手段が無作為に生成した文字列であることを特徴とする請求項１記載のサーバ。
【請求項４】
前記第一のスクランブル認識票は、前記認識票と前記第一の検索結果認識票との演算の結果であり、前記第二のスクランブル認識票は、前記認識票と前記第二の検索結果演算票との演算の結果であることを特徴とする請求項１記載のサーバ。
【請求項５】
前記演算は、前記ネットワークサービスで一意に決まる種値を変数として持つことを特徴とする請求項４記載のサーバ。
【請求項６】
前記第一のスクランブル認識票と前記第二のスクランブル認識票が等しくないことを特徴とする請求項１から５のいずれか一に記載のサーバ。
【請求項７】
前記送信手段は、前記記憶手段に前記第一の検索結果認識票と関連づけられて記憶された第一の付加情報と前記第二のスクランブル認識票とを関連づけ、かつ前記サーバの前記記憶手段に前記第二の検索結果認識票と関連づけられて記憶された第二の付加情報と前記第二のスクランブル認識票とを関連づけた状態で送信することを特徴とする請求項１から６のいずれか一に記載のサーバ。
【請求項８】
前記関連は、前記第一の利用者と前記第二の利用者が知人同士であり、かつ前記第一の利用者と前記第三の利用者が知人同士であることを意味することを特徴とする請求項１から７のいずれか一に記載のサーバ。
【請求項９】
第一のサーバによって提供される第一のネットワークサービスの第一の利用者を一意に特定するための情報である認識票を受信する受信手段と、
前記認識票と前記第一のサーバに関連付けて記憶された、前記第一のネットワークサービスの第二の利用者および第三の利用者を、各々一意に特定するための情報である第一の検索結果認識票および第二の検索結果認識票をそれぞれ検索する検索手段と、
第一のスクランブル認識票および第二のスクランブル認識票を生成する変換手段と、
前記第一の検索結果認識票と前記第一のスクランブル認識票とを関連付け、かつ前記第二の検索結果認識票と前記第二のスクランブル認識票とを関連付けて記憶する記憶手段と、
前記第一のスクランブル認識票および前記第二のスクランブル認識票を送信する送信手段と、
を有する前記第一のサーバから前記第一のスクランブル認識票および前記第二のスクランブル認識票を受信する第二受信手段を有することを特徴とする第二のサーバ。
【請求項１０】
前記第一のスクランブル認識票および前記第二のスクランブル認識票が等しくないことを特徴とする請求項９記載の第二のサーバ。
【請求項１１】
前記第一のスクランブル認識票を含むＨＴＭＬを生成する手段を有することを特徴とする請求項９および１０記載の第二のサーバ。
【請求項１２】
第一のサーバによって提供される第一のネットワークサービスの第一の利用者を前記第一のネットワークサービスの利用者の中で一意に特定するための情報である認識票を前記第一のサーバに送信する送信手段と、
前記第一のサーバの記憶手段において前記認識票と関連付けて記憶された第一の検索結果認識票および第二の検索結果認識票を前記第一のサーバより受信する受信手段と、
第一のスクランブル認識票および第二のスクランブル認識票を生成する変換手段と、
前記第一の検索結果認識票と前記第一のスクランブル認識票とを関連付け、かつ前記第二の検索結果認識票と前記第二のスクランブル認識票とを関連付けて記憶する記憶手段と、
を有することを特徴とする第二のサーバ。
【請求項１３】
前記第一のスクランブル認識票および前記第二のスクランブル認識票は、前記変換手段が無作為に生成した数値であることを特徴とする請求項１２記載の第二のサーバ。
【請求項１４】
前記第一のスクランブル認識票および前記第二のスクランブル認識票は、前記変換手段が無作為に生成した文字列であることを特徴とする請求項１２記載の第二のサーバ。
【請求項１５】
前記第一のスクランブル認識票は、前記認識票と前記第一の検索結果認識票との演算の結果であり、前記第二のスクランブル認識票は、前記認識票と前記第二の検索結果認識票との演算の結果であることを特徴とする請求項１２記載の第二のサーバ。
【請求項１６】
前記第一のスクランブル認識票と前記第二のスクランブル認識票とが等しくないことを特徴とする前記請求項１２から１５のいずれか一に記載の第二のサーバ。
【請求項１７】
前記第一のスクランブル認識票を含むＨＴＭＬコードを生成するＨＴＭＬコード生成手段と、
前記ＨＴＭＬコードを送信する送信手段と、
を有することを特徴とする請求項１２から１６のいずれか一に記載の第二のサーバ。
【請求項１８】
前記第一のスクランブル認識票および前記第二のスクランブル認識票を送信する送信手段を有することを特徴とする請求項１２から１６のいずれか一に記載の第二のサーバ。
【請求項１】
ネットワークサービスを提供するためのサーバであって、
前記ネットワークサービスの第一の利用者を前記ネットワークサービスの利用者の中で一意に特定するための情報である認識票を受信する受信手段と、
前記認識票と関連付けられている認識票であって、前記ネットワークサービスの第二の利用者および第三の利用者を、各々前記ネットワークサービス利用者の中で一意に特定する第一の検索結果認識票および第二の検索結果認識票をそれぞれ検索する検索手段と、
第一のスクランブル認識票および第二のスクランブル認識票を生成する変換手段と、
前記第一の検索結果認識票と前記第一のスクランブル認識票とを関連付け、かつ前記第二の検索結果認識票と前記第二のスクランブル認識票とを関連付けて記憶する記憶手段と、
前記第一のスクランブル認識票および前記第二のスクランブル認識票を送信する送信手段と、
を有することを特徴とするサーバ。
【請求項２】
前記第一のスクランブル認識票および前記第二のスクランブル認識票は、前記変換手段が無作為に生成した数値であることを特徴とする請求項１記載のサーバ。
【請求項３】
前記第一のスクランブル認識票および前記第二のスクランブル認識票は、前記変換手段が無作為に生成した文字列であることを特徴とする請求項１記載のサーバ。
【請求項４】
前記第一のスクランブル認識票は、前記認識票と前記第一の検索結果認識票との演算の結果であり、前記第二のスクランブル認識票は、前記認識票と前記第二の検索結果演算票との演算の結果であることを特徴とする請求項１記載のサーバ。
【請求項５】
前記演算は、前記ネットワークサービスで一意に決まる種値を変数として持つことを特徴とする請求項４記載のサーバ。
【請求項６】
前記第一のスクランブル認識票と前記第二のスクランブル認識票が等しくないことを特徴とする請求項１から５のいずれか一に記載のサーバ。
【請求項７】
前記送信手段は、前記記憶手段に前記第一の検索結果認識票と関連づけられて記憶された第一の付加情報と前記第二のスクランブル認識票とを関連づけ、かつ前記サーバの前記記憶手段に前記第二の検索結果認識票と関連づけられて記憶された第二の付加情報と前記第二のスクランブル認識票とを関連づけた状態で送信することを特徴とする請求項１から６のいずれか一に記載のサーバ。
【請求項８】
前記関連は、前記第一の利用者と前記第二の利用者が知人同士であり、かつ前記第一の利用者と前記第三の利用者が知人同士であることを意味することを特徴とする請求項１から７のいずれか一に記載のサーバ。
【請求項９】
第一のサーバによって提供される第一のネットワークサービスの第一の利用者を一意に特定するための情報である認識票を受信する受信手段と、
前記認識票と前記第一のサーバに関連付けて記憶された、前記第一のネットワークサービスの第二の利用者および第三の利用者を、各々一意に特定するための情報である第一の検索結果認識票および第二の検索結果認識票をそれぞれ検索する検索手段と、
第一のスクランブル認識票および第二のスクランブル認識票を生成する変換手段と、
前記第一の検索結果認識票と前記第一のスクランブル認識票とを関連付け、かつ前記第二の検索結果認識票と前記第二のスクランブル認識票とを関連付けて記憶する記憶手段と、
前記第一のスクランブル認識票および前記第二のスクランブル認識票を送信する送信手段と、
を有する前記第一のサーバから前記第一のスクランブル認識票および前記第二のスクランブル認識票を受信する第二受信手段を有することを特徴とする第二のサーバ。
【請求項１０】
前記第一のスクランブル認識票および前記第二のスクランブル認識票が等しくないことを特徴とする請求項９記載の第二のサーバ。
【請求項１１】
前記第一のスクランブル認識票を含むＨＴＭＬを生成する手段を有することを特徴とする請求項９および１０記載の第二のサーバ。
【請求項１２】
第一のサーバによって提供される第一のネットワークサービスの第一の利用者を前記第一のネットワークサービスの利用者の中で一意に特定するための情報である認識票を前記第一のサーバに送信する送信手段と、
前記第一のサーバの記憶手段において前記認識票と関連付けて記憶された第一の検索結果認識票および第二の検索結果認識票を前記第一のサーバより受信する受信手段と、
第一のスクランブル認識票および第二のスクランブル認識票を生成する変換手段と、
前記第一の検索結果認識票と前記第一のスクランブル認識票とを関連付け、かつ前記第二の検索結果認識票と前記第二のスクランブル認識票とを関連付けて記憶する記憶手段と、
を有することを特徴とする第二のサーバ。
【請求項１３】
前記第一のスクランブル認識票および前記第二のスクランブル認識票は、前記変換手段が無作為に生成した数値であることを特徴とする請求項１２記載の第二のサーバ。
【請求項１４】
前記第一のスクランブル認識票および前記第二のスクランブル認識票は、前記変換手段が無作為に生成した文字列であることを特徴とする請求項１２記載の第二のサーバ。
【請求項１５】
前記第一のスクランブル認識票は、前記認識票と前記第一の検索結果認識票との演算の結果であり、前記第二のスクランブル認識票は、前記認識票と前記第二の検索結果認識票との演算の結果であることを特徴とする請求項１２記載の第二のサーバ。
【請求項１６】
前記第一のスクランブル認識票と前記第二のスクランブル認識票とが等しくないことを特徴とする前記請求項１２から１５のいずれか一に記載の第二のサーバ。
【請求項１７】
前記第一のスクランブル認識票を含むＨＴＭＬコードを生成するＨＴＭＬコード生成手段と、
前記ＨＴＭＬコードを送信する送信手段と、
を有することを特徴とする請求項１２から１６のいずれか一に記載の第二のサーバ。
【請求項１８】
前記第一のスクランブル認識票および前記第二のスクランブル認識票を送信する送信手段を有することを特徴とする請求項１２から１６のいずれか一に記載の第二のサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１４】
【図１５】
【図１６】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１４】
【図１５】
【図１６】
【図１３】
【公開番号】特開２０１０−１２８７１３（Ｐ２０１０−１２８７１３Ａ）
【公開日】平成２２年６月１０日（２０１０．６．１０）
【国際特許分類】
【出願番号】特願２００８−３０１５８６（Ｐ２００８−３０１５８６）
【出願日】平成２０年１１月２６日（２００８．１１．２６）
【出願人】（５０６１８３７３１）リプレックス株式会社 (20)
【Ｆターム（参考）】
【公開日】平成２２年６月１０日（２０１０．６．１０）
【国際特許分類】
【出願日】平成２０年１１月２６日（２００８．１１．２６）
【出願人】（５０６１８３７３１）リプレックス株式会社 (20)
【Ｆターム（参考）】
[ Back to top ]