JP6248422B2

JP6248422B2 - 情報開示システム、情報開示プログラム及び情報開示方法

Info

Publication number: JP6248422B2
Application number: JP2013119286A
Authority: JP
Inventors: 一峰的場
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2013-06-05
Filing date: 2013-06-05
Publication date: 2017-12-20
Anticipated expiration: 2033-06-05
Also published as: US9497195B2; US20140365653A1; JP2014235720A

Description

本発明は、情報開示システム、情報開示プログラム及び情報開示方法に関する。

個人のデータが複数の既存サービスに分散している場合において、それらの複数の既存サービスの個人データを活用して、新たな価値を提供する新サービスを構築できる可能性がある。例えば、自分と同じ嗜好の友人の活動履歴を参照して、自分の普段の活動圏内（位置情報）にあるお勧めのおでかけスポットを見つけることが可能な新サービスなどが考えられる。

このような新サービスを実現するには、既存サービスが有するデータを新サービスに渡す必要がある。しかるに、新サービスと既存サービスは運営組織が異なる場合があり、アカウントの統合などが不可能な状況も想定される。このため、上記のような新サービスを実現するためには、サービス間を連携させた上で、既存サービス内のデータを新サービスに渡し、新サービス配下のユーザに提供するといった方法を採用することが考えられる。

なお、従来、異なるＳＮＳ（Social Networking System）間で利用者の状況情報や共有情報の連携を行う技術や、複数のエンティティの各々が保管する資源を、エンティティの各々が相互に利用し合えるようにする技術が提案されている（例えば、特許文献１，２等参照）。

特開２００９−１９９３６８号公報特開２００３−６７３２６号公報

しかしながら、既存サービスと新サービスの二者間でデータを渡す場合、データの提供側もしくは提供先のどちらかのユーザが両方のサービスにユーザアカウントを作成するなどして、サービス間でデータを渡す必要がある。また、サービス間でデータを受け渡しするためには、どちらかのサービスが相手側のサービスインタフェースに合わせてインタフェース機能を作り直す必要がある。このため、多数のサービス間における連携を柔軟に行うことは難しい。

また、既存の技術として、アカウント間でデータを共有する仲介サービスが知られている。しかるに、この仲介サービスは２つのサービスにおいて同一人物が利用する２つのアカウント間でのデータ渡しを想定しているため、そのままでは他人との情報共有に適用することは難しい。

１つの側面では、本発明は、あるサービスのあるユーザの情報を他のサービスのユーザに対して簡易に開示することが可能な情報開示システム、情報開示プログラム及び情報開示方法を提供することを目的とする。

一つの態様では、情報開示システムは、第１のユーザが利用可能な第１のサービスと、第２のユーザが利用可能な第２のサービスと、前記第１のユーザから、前記第２のユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記第２のユーザに対して認証情報を送付し、前記認証情報を利用したユーザからのアクセスがあった場合に、前記第１のサービスから収集した情報を開示する仲介サーバと、を備え、前記仲介サーバは、前記第１のユーザから、前記第１、第２のサービスとは異なる第３のサービスを利用する第３のユーザに対して前記第１のサービスの情報を開示する指示を受け付け、かつ、前記第２のユーザ及び前記第３のユーザが同一人物である場合には、前記第２のユーザに対して送付した認証情報と同一の認証情報を前記第３のユーザに対して送付する情報開示システムである。

一つの態様では、情報開示プログラムは、第１のサービスを利用している第１のユーザから、第２のサービスを利用している第２のユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記第２のユーザに対して認証情報を送付し、前記認証情報を利用したユーザからのアクセスがあった場合に、前記第１のサービスから収集した情報を開示し、前記第１のユーザから、前記第１、第２のサービスとは異なる第３のサービスを利用する第３のユーザに対して前記第１のサービスの情報を開示する指示を受け付け、かつ、前記第２のユーザ及び前記第３のユーザが同一人物である場合には、前記第２のユーザに対して送付した認証情報と同一の認証情報を前記第３のユーザに対して送付する、処理をコンピュータに実行させる情報開示プログラムである。

一つの態様では、第１のサービスを利用している第１のユーザから、第２のサービスを利用している第２のユーザに対して前記第１のサービスの情報を開示する指示を受け付けた場合に、前記第２のユーザに対して認証情報を送付し、前記認証情報を利用したユーザからのアクセスがあった場合に、前記第１のサービスから収集した情報を開示し、前記第１のユーザから、前記第１、第２のサービスとは異なる第３のサービスを利用する第３のユーザに対して前記第１のサービスの情報を開示する指示を受け付け、かつ、前記第２のユーザ及び前記第３のユーザが同一人物である場合には、前記第２のユーザに対して送付した認証情報と同一の認証情報を前記第３のユーザに対して送付する、処理をコンピュータが実行する情報開示方法である。

あるサービスのあるユーザの情報を他のサービスのユーザに対して簡易に開示することができる。

第１の実施形態に係る情報開示システムの構成を概略的に示す図である。仲介サーバのハードウェア構成図である。第１の実施形態に係る仲介サーバの機能ブロック図である。図４（ａ）は、認可セッション保持部のデータ構造を示す図であり、図４（ｂ）は、データ保持部のデータ構造を示す図であり、図４（ｃ）は、アクセス制御ルール保持部のデータ構造を示す図であり、図４（ｄ）は、チケット保持部のデータ構造を示す図である。データ取得処理を示す図である。データ提供処理を示す図である。図５のステップＳ１、Ｓ２における仲介サーバの処理を示すフローチャートである。図５のステップＳ３における仲介サーバの処理を示すフローチャートである。図６のステップＳ４における仲介サーバの処理を示すフローチャートである。比較例１を示す図である。比較例２を示す図である。第２の実施形態に係る仲介サーバの機能ブロック図である。図１３（ａ）は、第２の実施形態のユーザグループ保持部のデータ構造を示す図であり、図１３（ｂ）は、第２の実施形態のチケット保持部のデータ構造を示す図である。第２の実施形態におけるステップＳ１、Ｓ２の処理を示すフローチャートである。第２の実施形態におけるステップＳ４の処理を示すフローチャートである。第３の実施形態に係る仲介サーバの機能ブロック図である。第３の実施形態におけるステップＳ４の処理を示すフローチャートである。第３の実施形態におけるデータ取得処理を示す図である。図１９（ａ）は、第４の実施形態のチケット保持部のデータ構造を示す図であり、図１９（ｂ）は、第４の実施形態のアクセス制御ルール保持部のデータ構造を示す図である。第４の実施形態におけるステップＳ４の処理を示すフローチャートである。第５の実施形態に係る仲介サーバの機能ブロック図である。第５の実施形態におけるステップＳ４の処理を示すフローチャートである。第６の実施形態に係る仲介サーバの機能ブロック図である。図２４（ａ）は、第６の実施形態にかかる変換ルール保持部のデータ構造を示す図であり、図２４（ｂ）は、変換前のデータを示す図であり、図２４（ｃ）は、変換後のデータを示す図である。第６の実施形態におけるデータ変換部の処理を示すフローチャートである。

《第１の実施形態》
以下、第１の実施形態に係る情報開示システムについて、図１〜図９に基づいて詳細に説明する。

図１には、第１の実施形態の情報開示システム１００の構成が概略的に示されている。図１に示すように、情報開示システム１００は、既存サービスＡ、新サービスＸ、仲介サーバ１０、及びユーザ端末７０を備えている。既存サービスＡ及び新サービスＸは、１又は複数のサーバを含むサーバ群を有する。既存サービスＡ、新サービスＸ、仲介サーバ１０、及びユーザ端末７０は、インターネットなどのネットワーク８０に接続されている。

既存サービスＡは、所定の情報をユーザに対して提供するサービスであり、ユーザ端末７０を利用するユーザ（例えば、ユーザ１）がアカウント（ユーザＩＤ及びパスワード）を有しているものとする。すなわち、ユーザ１は、既存サービスＡの配下のユーザであるものとする。

新サービスＸは、所定の情報をユーザに対して提供するサービスであり、ユーザ端末７０を利用するユーザ（例えば、ユーザ２）がアカウント（ユーザＩＤ及びパスワード）を有しているものとする。すなわち、ユーザ２は、新サービスＸの配下のユーザであるものとする。なお、本実施形態では、ユーザ１は、新サービスＸの配下のユーザではないものとする。また、ユーザ２は、既存サービスＡの配下のユーザではないものとする。

仲介サーバ１０は、既存サービスＡが保持するデータをユーザ１のアカウント情報を用いて取得し、ユーザ１がデータを渡すことを許可したユーザ（例えば、ユーザ２）に対して取得したデータを提供するサーバである。図２には、仲介サーバ１０のハードウェア構成が概略的に示されている。図２に示すように、仲介サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これら仲介サーバ１０の構成各部は、バス９８に接続されている。仲介サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（情報開示プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（情報開示プログラムを含む）をＣＰＵ９０が実行することにより、図３に示すアクセス設定部１２、認可セッション設定部１４、チケット発行部１６、データ収集部１８、チケット検証部２０、及びアクセス制御部２２としての機能が実現される。なお、図３には、仲介サーバ１０のＨＤＤ９６等により実現されている、認可セッション保持部３０、データ保持部３２、アクセス制御ルール保持部３４、及びチケット保持部３６も図示されている。

アクセス設定部１２は、既存サービスＡのユーザ（ユーザ１）からの要求に応じて、新サービスＸ側からユーザＩＤリスト（ユーザ２のＩＤを含む）を取得し、ユーザ（ユーザ１）に提供する。

認可セッション設定部１４は、既存サービスＡのユーザ（ユーザ１）から既存サービスＡのアカウント情報（ユーザＩＤ、パスワード）を取得し、認可セッションの作成を行う。なお、本実施形態では、既存サービスＡに対して仲介サーバ１０がユーザ１としてアクセスできるようにする技術としてOAuthを利用することとしている。しかしながら、これに限らず、他サービスにアクセス権限を移譲することが可能な他の方法（例えばSAML：Security Assertion Markup Language）などを採用することとしてもよい。

認可セッション設定部１４は、認可セッションを作成すると、認可セッション保持部３０に認可セッションの情報を保存する。また、認可セッション設定部１４は、データ提供元のユーザ（ユーザ１）が選択したデータ提供先のユーザ（例えばユーザ２）のＩＤと認可セッションのセッションＩＤをアクセス制御ルール保持部３４に保存する。そして、認可セッション設定部１４は、データ提供先のユーザのＩＤリストをチケット発行部１６に通知する。

ここで、認可セッション保持部３０は、既存サービスのＩＤ、認可セッションのセッションＩＤを保持するテーブルであり、図４（ａ）に示すようなデータ構造を有する。具体的には、図４（ａ）に示すように、認可セッション保持部３０は、既存サービスのＩＤを示す「サービスＩＤ」、「認可Code」及び「アクセストークン」、認可セッションのＩＤを示す「セッションＩＤ」の各フィールドを有している。また、アクセス制御ルール保持部３４は、認可セッションのセッションＩＤとデータ提供先のユーザのＩＤと関係を保持するテーブルであり、図４（ｃ）に示すようなデータ構造を有する。具体的には、図４（ｃ）に示すように、アクセス制御ルール保持部３４は、認可セッションの「セッションＩＤ」、データの提供先のユーザが利用する新サービスを示す「サービスＩＤ」、データが提供されるユーザを示す「ユーザＩＤ」の各フィールドを有している。

チケット発行部１６は、認可セッション設定部１４からの通知を受けると、チケット保持部３６にユーザＩＤのリストを保存する。ここで、チケット保持部３６は、データ提供先のユーザのＩＤと識別情報としてのチケットとの関係を保持するテーブルであり、図４（ｄ）に示すようなデータ構造を有する。具体的には、図４（ｄ）に示すように、チケット保持部３６は、データ提供先のユーザが利用する新サービスを示す「サービスＩＤ」、データ提供先のユーザの「ユーザＩＤ」、及び「チケット」の各フィールドを有している。なお、データ提供先のユーザからチケットの取得要求があるまでは、「チケット」のフィールドには、「未発行」が格納されるものとする。また、チケット発行部１６は、データ提供先のユーザからのチケットの取得要求があると、チケットを新たに生成し、チケット保持部３６に保存するとともに、データ提供先のユーザに対してチケットを渡す。

なお、チケットとしては、ＵＵＩＤ（Universally unique identifier）をランダムに生成して利用するものとする。本実施形態では、一例として、チケットＴ１が543b8d39-24a6-496f-8233-97808e9e625のような予測不可能な文字列であり、Ｔ２が23c4e2f4-8cfb-4f00-9537-70947d998a2eのような予測不可能な文字列であるものとする。なお、チケットは、バイナリデータであってもよい。また、チケット発行部１６は、データ提供先のユーザにチケットを渡す場合、例えば、HTTP ResponseのBodyに文字列をそのまま記載して応答したり、構造化したデータ（ＸＭＬ：Extensible Markup LanguageやＪＳＯＮ：Java（登録商標）script Object Notation）のパラメータとして応答するなどすればよい。

データ収集部１８は、認可セッション保持部３０から読み出したセッションＩＤを利用し、該当するセッション用のデータを既存サービスＡから取得し、データ保持部３２に格納する。なお、データ提供元のユーザ（ユーザ１）は、OAuthにおいて、どのような範囲のデータを取得するかを設定してもよいし、設定しないこととしてもよい。なお、範囲を設定しない場合には、データ収集部１８によって、データ提供元のユーザの全てのデータが取得されることになる。ここで、データ保持部３２は、認可セッションのセッションＩＤごとに、データ群を保持するテーブルであり、図４（ｂ）に示すようなデータ構造を有している。具体的には、データ保持部３２は、データ提供元のサービスの「サービスＩＤ」、認可セッションの「セッションＩＤ」、収集したデータの「データＩＤ」、データそのものが格納される「データ」の各フィールドを有している。

チケット検証部２０は、データ提供先のユーザ（ユーザ２）からユーザＩＤおよびチケットを取得すると、チケット保持部３６をチェックする。そして、チケット検証部２０は、認証ができた場合に、アクセス制御部２２に対してデータ提供先のユーザ（ユーザ２）のユーザＩＤを送信する。

アクセス制御部２２は、チケット検証部２０からデータ提供先のユーザ（ユーザ２）のユーザＩＤを受け取ると、アクセス制御ルール保持部３４を読み出し、ユーザＩＤに対応するセッションＩＤ（データ提供先のユーザがアクセスできるセッションＩＤ）のリストを取得する。そして、アクセス制御部２２は、データ提供先のユーザ（ユーザ２）によってリクエストされたデータの種類（データリストや指定ＩＤのデータ）に基づいて、データ保持部３２から該当するデータ（もしくはデータ群）を読み出して、データ提供先のユーザ（ユーザ２）に提供する。

（処理の概要）
次に、情報開示システム１００における処理の概要について、図５、図６に沿って説明する。なお、本実施形態では、既存サービスＡの配下のユーザ１のデータを新サービスＸの配下のユーザ２に提供するものとする。ユーザ１及びユーザ２は、図１のユーザ端末７０から各サービスや仲介サーバ１０に対してアクセスするものとする。また、情報開示システム１００は、図５に示すデータ取得処理と、図６に示すデータ提供処理を実行する。

（データ取得処理）
データ取得処理においては、図５に示すような処理が実行される。

図５においては、まず、ユーザ１が仲介サーバ１０にアクセスし、データの提供先のサービスおよびデータの提供先のユーザを選択する（図５のステップＳ１参照）。そして、仲介サーバ１０は、OAuthを利用して、既存サービスからユーザ１のデータを取得できるようにアクセス権限の移譲等の手続きを行う（図５のステップＳ２参照）。なお、図５のステップＳ２は、ユーザ１が選択したデータ提供元のサービスの数だけ繰り返し実行する。

次いで、仲介サーバ１０は、既存サービスＡからユーザ１のデータを取得（収集）する（図５のステップＳ３参照）。なお、ユーザ２との間でどのようなデータを共有するのかをユーザ１が指定した場合は、指定されたデータのみを取得する。また、定期的にデータが更新・追加される場合は、仲介サーバ１０も定期的にデータの取得を行うものとする。

（データ提供処理）
データ提供処理においては、図６に示すような処理が実行される。

仲介サーバ１０は、データ提供先のユーザから新サービスＸに対して、既存サービスＡのデータのリクエスト（開示要求）があった場合に、ユーザ２に対して、チケットを発行する。そして、ユーザ２が上記チケットを利用して仲介サーバ１０に対してアクセスすると、仲介サーバ１０がチケットを検証し、アクセス権限をチェックする。この場合、仲介サーバ１０は、チケットが有効であることを確認すると、ユーザ２に対して提供可能なデータを提供する（図６のステップＳ４参照）。

なお、図６のステップＳ５に示すように、ユーザ２は、新サービスＸを介して間接的に仲介サーバ１０にアクセスし、データの提供を受けることもできる。

次に、上記各処理について、図７〜図９のフローチャートに沿って詳細に説明する。

（ステップＳ１、Ｓ２について）
図７には、図５のステップＳ１、Ｓ２における仲介サーバ１０の処理がフローチャートにて示されている。なお、以下においても、データ提供元のサービスが既存サービスＡ、データ提供元のユーザがユーザ１、データ提供先のサービスが新サービスＸ、データ提供先のユーザがユーザ２であるものとする。

図７の処理では、ステップＳ１０において、アクセス設定部１２は、既存サービスＡからユーザ１のメッセージを受信するまで待機する。この場合、アクセス設定部１２は、既存サービスＡ（ユーザ１）からメッセージを受信した段階で、ステップＳ１２に移行する。

ステップＳ１２に移行すると、アクセス設定部１２は、ユーザ（ユーザ１）からの初回リクエストであるか否かを判断する。ここでの判断が肯定された場合（ユーザ１からの初回リクエストである場合）には、ステップＳ１４に移行し、否定された場合には、ステップＳ１８に移行する。

ステップＳ１４に移行すると、アクセス設定部１２は、ユーザ１からの初回リクエストに応じて、データ提供先のサービス（新サービスＸ）からユーザリストを取得する。このユーザリストは、データ提供先のサービスの配下の全ユーザのＩＤが格納された一覧であるものとする。

次いで、ステップＳ１６では、アクセス設定部１２は、ユーザ１に対して、取得したユーザリストを応答する。なお、例えば、ユーザ１が特定のキーワードを特定してリクエストした場合には、アクセス設定部１２は、ユーザリストのうち特定のキーワードを含むユーザの一覧（リスト）を応答することとしてもよい。その後は、図７の全処理を終了する。

一方、ユーザ１からのメッセージが初回リクエストでなく、ステップＳ１２の判断が否定された場合には、ステップＳ１８に移行する。ステップＳ１８では、認可セッション設定部１４は、ユーザ１からのメッセージがユーザＩＤ選択メッセージであるか否かを判断する。なお、ユーザＩＤ選択メッセージとは、ユーザ１がステップＳ１６において取得したユーザリストの中からユーザ（ユーザＩＤ）を選択した結果を示すメッセージである。ここでは、ユーザ１がユーザリストの中からユーザ２を選択したものとする。この場合、ステップＳ１８の判断が肯定され、ステップＳ２０に移行する。なお、ステップＳ１８の判断が否定された場合（既存サービスＡからのメッセージが初回リクエストでなく、かつユーザＩＤ選択メッセージでなかった場合）には、図７の全処理が終了する。

ステップＳ２０に移行すると、認可セッション設定部１４は、認可セッションのセッションＩＤを作成する。そして、これ以降、ステップＳ２２〜Ｓ３０においては、認可セッション設定部１４が、既存サービスＡのユーザ１について、OAuthによるアクセス権限移譲処理を行う。

例えばOAuth2.0の場合、まず、認可セッション設定部１４は、ステップＳ２２において、未認可サービス（ここでは、既存サービスＡ）へのリダイレクトを実行する。具体的には、認可セッション設定部１４が、ユーザ１にリダイレクト指示の応答を返す。この場合、ユーザ１は、既存サービスＡのログイン画面にアクセスし、ユーザＩＤとパスワードを用いてログインする。その後、既存サービスＡが認可セッション設定部１４にデータを提供することを確認する画面を返し、ユーザ１がその承認をする。そして、既存サービスＡからの応答により、仲介サーバ１０のＵＲＬにリダイレクトされることになる。

次いで、ステップＳ２４では、認可セッション設定部１４は、ＵＲＬのパラメータに含まれる文字列から認可Codeを受け取り、この認可Codeを既存サービスＡに渡すことで、既存サービスＡからアクセストークンを取得する。なお、これ以降は、データ収集部１８は、取得されたアクセストークンを利用して、ユーザ１のデータを取得することができるようになっている。

次いで、ステップＳ２６では、認可セッション設定部１４は、アクセストークンの文字列（例えば”ＳＩＤ１”）を認可セッションのセッションＩＤとし、既存サービスＡのＩＤとともに認可セッション保持部３０に格納する（エントリを作成する）。

次いで、ステップＳ２８では、認可セッション設定部１４は、全ての既存サービス（ユーザが複数の既存サービスを選択した場合）の認可が完了したか否かを判断する。ここでの判断が否定された場合には、ステップＳ２２に戻り、ステップＳ２２〜Ｓ２８の処理・判断を繰り返すが、ステップＳ２８の判断が肯定された場合には、ステップＳ３０に移行する。

ステップＳ３０に移行すると、認可セッション設定部１４は、チケット保持部３６及びアクセス制御ルール保持部３４にエントリを追加する。具体的には、認可セッション設定部１４は、データ提供先のユーザ（新サービスＸのユーザ２（User2））をチケット発行部１６に通知する。そして、チケット発行部１６が、チケット保持部３６に新サービスＸのユーザ２が登録されているか否かを確認し、未登録の場合はチケット保持部３６に登録する。また、認可セッション設定部１４は、セッションＩＤおよびデータ提供先のユーザ（新サービスＸのユーザ２（User2））をアクセス制御ルール保持部３４に格納する。なお、ステップＳ３０の処理が行われた後は、図７の全処理を終了する。

なお、アクセストークンには有効期限があり、有効期限が切れた場合には再取得して変更する必要がある。このため、認可CodeをセッションＩＤとして扱うこととしてもよい。

（ステップＳ３について）
図８には、図５のステップＳ３における仲介サーバ１０の処理がフローチャートにて示されている。

図８の処理においては、まず、ステップＳ４０において、データ収集部１８が、認可セッション保持部３０のエントリを読み出す。次いで、ステップＳ４２では、データ収集部１８は、データ未取得セッションが存在するか否かをデータ保持部３２を参照して判断する。ここでの判断が否定された場合には、ステップＳ４０に戻るが、肯定された場合には、ステップＳ４４に移行する。

ステップＳ４４に移行すると、データ収集部１８は、データ未取得セッションに関し、データ提供元からデータを取得する。具体的には、データ収集部１８は、既存サービスＡに対してアクセストークン（又はセッションＩＤ）を付与してリクエストを送信する。この場合、既存サービスＡは、アクセストークンを参照することでユーザ１の権限でアクセスが行われたことがわかるため、ユーザ１のデータを仲介サーバ１０のデータ収集部１８に返答する。これにより、データ収集部１８は既存サービスＡからデータを取得することができる。

次いで、ステップＳ４６では、データ収集部１８は、データ保持部３２にセッションＩＤと、取得したデータと、を書き込む。その後は、ステップＳ４２に戻り、データ収集部１８は、上記処理を繰り返し実行する。以上の処理により、必要なデータがデータ保持部３２に順次収集されるようになっている。

（ステップＳ４（Ｓ５）について）
図９には、図６のステップＳ４における仲介サーバ１０の処理がフローチャートにて示されている。

図９の処理では、まず、ステップＳ５０において、チケット発行部１６が、チケット取得要求を受信したか否かを判断する。ここで、ユーザ２が新サービスＸにアクセスし、新サービスＸのユーザ２（User2）としてログインし、新サービスＸが、ユーザ２（User2）のチケットを取得するために仲介サーバ１０のチケット発行部１６にリクエストを送ったとする。この場合、ステップＳ５０の判断は肯定されて、チケット発行部１６は、ステップＳ５２に移行する。

ステップＳ５２に移行すると、チケット発行部１６は、OAuthによるログインの確認、もしくは新サービスＸと仲介サーバ１０との間でサーバ間の認証（サーバＩＰチェック）を行うことでリクエストの送信元をチェックする。また、この際に合わせて送られる送信元ユーザのＩＤをもとに、データ提供先のユーザ２に関するチケット発行依頼であることを確認する。

次いで、ステップＳ５４では、チケット発行部１６が、チケット保持部３６のエントリを確認し、ユーザ２のチケットが未発行であれば、新たにチケット（図４（ｄ）ではＴ１）を作成し、新サービスＸに応答する（送信する）。なお、新サービスＸにおいては、受け取ったチケット（Ｔ１）をユーザ２の利用するユーザ端末７０に転送する。その後は、図９の全処理を終了する。

一方、ステップＳ５０の判断が否定された場合には、チケット検証部２０は、ステップＳ５６に移行し、データ取得要求を受信したか否かを判断する。ここでの判断が否定された場合には、図８の全処理を終了するが、肯定された場合には、ステップＳ５８に移行する。なお、ステップＳ５６の判断が肯定される場合とは、ユーザ２がチケット（Ｔ１）、新サービスＸのＩＤ（Ｘ）、ユーザ２のＩＤ（User2）を利用してチケット検証部２０に対してデータの取得要求を行った場合である。

ステップＳ５６の判断が肯定され、ステップＳ５８に移行すると、チケット検証部２０は、受け取ったチケットとチケット保持部３６（図４（ｄ））の内容を照合する。また、ステップＳ６０では、チケット検証部２０は、受け取ったチケットとチケット保持部３６の内容とが正しい組み合わせであるか否かをチェックすることで、アクセス権限をチェックする。なお、アクセス権限がある場合には、チケット検証部２０は、アクセス制御部２２に対して新サービスＸのユーザ２のＩＤ（User2）を送信する。

そして、ステップＳ６２では、アクセス制御部２２が、データもしくはデータリストの応答を行う。具体的には、アクセス制御部２２は、アクセス制御ルール保持部３４（図４（ｃ））のエントリを読み出し、新サービスＸのユーザ２がアクセスできるセッションＩＤ（ＳＩＤ１）を取得する。そして、アクセス制御部２２は、上記セッションＩＤ（ＳＩＤ１）のデータのうち、リクエストされたデータをデータ保持部３２（図４（ｂ））から読み出して、ユーザ２に応答する。なお、ユーザは、リクエストにおいて、データＩＤを指定して特定のデータを指示することとしてもよいし、データリストを指示することとしてもよい。

なお、ステップＳ５４において、ユーザ２が新サービスＸを経由して仲介サーバ１０にアクセスすることが保証されている場合は、ユーザ２にチケットを転送する代わりに新サービスＸがチケットＴ１とユーザ２（User2）の関係を保持してもよい。この場合、ユーザ２が新サービスＸを経由して仲介サーバ１０にアクセスすることで、ステップＳ５８以降の処理は、図６のステップＳ５に示すように、新サービスＸ経由で行われることになる。

以上の処理を実行することで、ユーザ１およびユーザ２が仲介サーバ１０にアカウントを作らなくても、ユーザ１のデータをユーザ２に対して提供（開示）することが可能である。

以上、詳細に説明したように、本第１の実施形態によると、情報開示システム１００は、既存サービスＡ配下のユーザ１から、新サービスＸ配下のユーザ２に対してサービスＡのデータを開示するリクエストを受け付けると（Ｓ１８：肯定）、ユーザ２に対してチケットを送付し（Ｓ５４）、ユーザ２からチケットを利用したアクセスがあった場合（Ｓ５６：肯定）に、サービスＡから収集した情報を開示する仲介サーバ１０を備えている。これにより、ユーザ２が仲介サーバ１０やサービスＡにアクセスするためのアカウントを作成しなくても、ユーザ２に対して、ユーザ１のデータを開示することができる。

また、本第１の実施形態では、仲介サーバ１０がユーザ２に対して送信したチケットをユーザ２が用いることで、ユーザ１がユーザ２に対してアクセス設定した範囲（データ保持部３２においてセッションＩＤに紐付けられたデータ）へのアクセスが可能となる。これにより、ユーザごとに適切なアクセスコントロールを行うことができる。

ここで、比較例について説明する。
（比較例１）
図１０には、比較例１の概要が示されている。図１０に示すように、比較例１では、既存サービスＡのデータを新サービスＸの配下のユーザ２に対して開示するため、既存サービスＡのユーザ１のアカウント（ユーザＩＤおよびパスワード）をユーザ２に教える。そして、ユーザ２は新サービスＸのアカウントと既存サービスＡのユーザ１のアカウントの両方を仲介サービス１０’に登録する。このようにすることで、仲介サービス１０’は、既存サービスＡからユーザ１のアカウントで情報を取得し、ユーザ２のアカウントで新サービスＸにその情報を渡すようにすることができる。

しかしながら、比較例１では、ユーザ１からユーザ２に対してアカウントを教える必要があるため、セキュリティ上のリスクを伴うと考えられる。また、既存サービスＡのアカウントをユーザ２が使える状態になるため、ユーザ１がユーザ２と共有したくない情報まで共有してしまうおそれがある。また、ユーザ２がアカウントを利用して、ユーザ１の想定していない操作（データの書き込みなど）を行ってしまうおそれもある。これに対し、上記第１の実施形態の情報開示システム１００では、ユーザ２に対してユーザ１のアカウントを教えなくてもよいため、上記のような事態は発生しない。

（比較例２）
図１１には、比較例２の概要が示されている。図１１の比較例２では、仲介サーバ１０”内にユーザ１とユーザ２の両方がユーザアカウントを作成する。そして、ユーザ１が仲介サーバ１０”内でユーザ２にデータを渡してもよいということを設定する。

しかしながら、比較例２では、データを渡すためだけに、仲介サーバ１０”にユーザアカウントを作らなくてはならないため、手間がかかる。これに対し、上記第１の実施形態の情報開示システム１００では、アカウントの作成は不要である。

《第２の実施形態》
次に、第２の実施形態について図１２〜図１５に基づいて説明する。図１２には、第２の実施形態に係る仲介サーバ２１０の機能ブロック図が示されている。図１２と図３とを比較すると分かるように、仲介サーバ２１０は、ユーザグループ保持部３８を有している点が第１の実施形態の仲介サーバ１０と異なる。

図１３（ａ）には、ユーザグループ保持部３８のデータ構造の一例が示されている。ユーザグループ保持部３８は、図１３（ａ）に示すように、「ユーザグループＩＤ」、「サービスＩＤ」、「ユーザＩＤ」の各フィールドを有している。

図１４には、第２の実施形態のステップＳ１、Ｓ２の処理がフローチャートにて示されている。なお、図１４の処理は、第１の実施形態の図７に対応する処理である。また、図１４において太線にて示す処理（ステップＳ２９Ａ〜Ｓ２９Ｃ）が、第１の実施形態と異なる処理である。例えば、ユーザ１が、「新サービスＸのユーザ２、新サービスＹのユーザ２が同一人物である」旨を認可セッション設定部１４に対して指定すると、認可セッション設定部１４は、その情報をチケット発行部１６に渡す。この場合、図１４のステップＳ２０〜Ｓ２８の後、ステップＳ２９Ａの判断（同一人物指定があったか否かの判断）は肯定されるので、チケット発行部１６は、ステップＳ２９Ｂに移行する。

ステップＳ２９Ｂに移行すると、チケット発行部１６は、新たにユーザグループＩＤ（ＵＧＩＤ１）を作成する。そして、チケット発行部１６は、図１３（ｂ）に示すように、チケット保持部３６にサービスＩＤ＝“Ｇｒｏｕｐ”、ユーザＩＤ＝“ＵＧＩＤ１”のエントリを登録する。さらに、チケット発行部１６は、ステップＳ２９Ｃにおいて、ユーザグループ保持部３８に、図１３（ａ）に示すように、（UGID1, X, User2）、（UGID1, Y, User2）の２エントリを登録（追加）する。

図１５には、第１の実施形態の図９に対応する処理がフローチャートにて示されている。この処理においては、チケット発行部１６は、図１５において太線で示すように、ステップＳ５２とＳ５４との間に、ステップＳ５３の処理を実行する。

図１５の処理では、例えば、ユーザ２がサービスＸのユーザとしてチケット取得要求を出すと、チケット発行部１６は、ステップＳ５３において、サービスＸ、User2のエントリをユーザグループ保持部３８（図１３（ａ））において検索する。これにより、ユーザグループＩＤ（ＵＧＩＤ１）を取得することができる。そして、ステップＳ５４では、チケット発行部１６は、サービスＩＤ＝“Ｇｒｏｕｐ”、ユーザＩＤ＝“ＵＧＩＤ１”でチケット保持部３６を検索しする。この場合、チケットが未発行であれば、チケット発行部１６は、新しくチケットの文字列を生成してユーザ２に対して応答（送信）し、チケット保持部３６のエントリを更新する。なお、チケットが発行済みの場合は、該当チケットをチケット保持部３６から取得してユーザ２に対して応答（送信）する。

以上のように、本第２の実施形態によれば、複数のサービスの配下のユーザが同一人物である場合に、該ユーザに対して、同一の（共通の）チケットを発行することとしている。これにより、ユーザによるチケット管理を簡略化することができる。

≪第３の実施形態≫
次に、第３の実施形態について、図１６〜図１８に基づいて説明する。なお、前述した第１の実施形態では、チケットを発行するタイミングとチケットを利用するタイミングが別である場合について説明したが、本第３の実施形態では、図１６に示すように新サービスＸと仲介サーバ３１０との間でOAuth認可を行うことで、チケットの発行と１回目のデータ提供を同時に行えるようにしている。この場合、第１の実施形態で説明した図９のステップＳ５２、Ｓ５４が不要となり、代わりに、図１７において太線で示す処理が実行される。

図１７のステップＳ１５０では、新サービスＸのユーザ２（User2）から仲介サーバ３１０に対するデータの取得要求（リクエスト）があった場合に、チケット検証部２０は、リクエストにチケットが付与されているか否かを判断する。ここでの判断が否定された場合、すなわち、データ提供を初めて受けるような場合（チケットを保有していない場合）には、ステップＳ１５１に移行する。なお、ステップＳ１５１に移行する場合、チケット検証部２０は、チケット発行部１６に対して新サービスＸのＩＤ（Ｘ）およびユーザＩＤ（User2）を渡す。

ステップＳ１５１、Ｓ１５２では、チケット発行部１６は、新サービスＸのUser2について、OAuthによるアクセス権限移譲を行う。例えばOAuth2.0の場合、まず仲介サーバ３１０がユーザ２にリダイレクト指示の応答を返して、ユーザ２が新サービスＸのログイン画面にアクセスし、ログインする。その後、新サービスＸが仲介サーバ３１０にデータを提供することを確認する画面を返し、ユーザ２がその承認をする。そして新サービスＸからの応答で、仲介サーバ３１０のＵＲＬにリダイレクトされる（Ｓ１５１）。その際にＵＲＬのパラメータに含まれる文字列から仲介サーバ３１０が認可Codeを受け取り、仲介サーバ３１０が認可Codeを新サービスＸに渡すことで、新サービスＸよりアクセストークンを取得する（Ｓ１５２）。

次いで、ステップＳ１５３では、チケット発行部１６は、取得したアクセストークンを利用して、新サービスＸより該当するユーザＩＤ（User2）を取得し、リクエストを受けたユーザＩＤ（User2）と同じであることを確認する。

そして、ステップＳ１５４では、チケット発行部１６は、新たにチケット（Ｔ１）を作成する。また、チケット発行部１６は、チケット保持部３６にサービスＩＤ＝Ｘ, ユーザＩＤ＝ User2, チケット＝Ｔ１のエントリを追加し、チケット検証部２０に対して検証が終わったことおよびチケットＴ１を通知する。この場合、チケット検証部２０は、アクセス制御部２２に対して新サービスＸのユーザUser2とチケットＴ１を伝える。その後は、第１の実施形態と同様、ステップＳ６０、Ｓ６２を実行する。

なお、ステップＳ１５０の判断が肯定された場合、すなわち、データ提供を受けるのが２回目以降の場合には、ユーザはチケットを付与してデータ提供のリクエストを行うので、ステップＳ５８に移行する。そして、ステップＳ５８〜Ｓ６２においては、第１の実施形態と同様の処理が行われることになる。

なお、図１８には、図１７の処理の流れ（データのやり取り等）が示されている。

以上のように、本第３の実施形態では、チケット発行のためだけの処理を削減し、チケットの発行と１回目のデータ提供とを同時に（一連の流れの中で）行うようにしている。これにより、新サービスＸのユーザ２がより簡単にデータを受け取ることができるようになる。

≪第４の実施形態≫
次に、第４の実施形態について、図１９、図２０に基づいて説明する。なお、本第４の実施形態の仲介サーバの構成は、図３と同様となっている。上述した第１の実施形態において、データを提供するユーザ１が、新サービス配下の全員にデータを提供しても良いとする場合、全ユーザに対して異なるチケットを発行し、発行したチケットを管理する必要がある。この場合、チケットの管理数が膨大になるおそれがある。本第４の実施形態では、このような点を考慮し、チケット発行部１６は、サービス全体にデータ提供することを許可した場合に、サービス全体用のチケット（サービスチケット）を発行することとする。

具体的には、ユーザ１が仲介サーバに対して新サービスＸの全ユーザにデータ提供することを指示した場合、認可セッション設定部１４は、セッションＩＤおよびデータ提供先のサービス（サービスＩＤ＝Ｘ、ユーザＩＤ＝ワイルドカード“＊”）をアクセス制御ルール保持部３４に格納する（図１９（ｂ）の最下行参照）。次いで、認可セッション設定部１４は、データ提供先のサービス（種別＝“Service”、サービスＩＤ＝Ｘ、ユーザＩＤ＝ワイルドカード “＊”）をチケット発行部１６に通知する。そして、チケット発行部１６は、チケット保持部３６に新サービスＸが登録されているかを確認し、登録されていない場合にはチケット保持部３６に登録する（図１９（ａ）の最下行参照）。なお、図１９（ａ）のチケット保持部３６には、図４（ｄ）と比較すると分かるように、チケットの種別を示すフィールドが追加されているものとする。

図１９には、第１の実施形態の図９の処理に対応する処理のフローチャートが示されている。図１９の処理では、図９のステップＳ５２とステップＳ５４との間に、ステップＳ５３Ａの判断を行う。すなわち、ステップＳ５２の終了後は、ステップＳ５３Ａにおいて、チケット発行部１６は、ユーザＩＤのエントリがチケット保持部３６にあるか否かを判断する。ここでの判断が肯定された場合には、チケット発行部１６は、ステップＳ５４において、ユーザ専用のチケットを生成し、応答する。

一方、ステップＳ５３Ａの判断が否定された場合には、チケット発行部１６は、サービス用のチケット（サービスチケット）を応答する。

なお、アクセス制御部２２は、ユーザがデータ提供を受ける際、ユーザ専用のチケットがリクエストに付与されていた場合には、アクセス制御ルール保持部３４（図１９（ｂ））のユーザＩＤが指定されたエントリ、およびユーザＩＤがワイルドカード “＊” になっているエントリの両方のエントリをユーザがアクセス可能なデータ範囲（認可セッション群）として扱う。

なお、上記においては、新サービスＸ配下のユーザ全員にデータを提供する場合に、各ユーザにサービス用のチケットを渡す場合について説明した。ただし、これに限らず、例えば、新サービスＸに対してデータの取得を許可する場合にも上記と同様の仕組みを利用することが可能である。

以上のように、本第４の実施形態では、サービス用のチケットを導入することで、データの提供先をサービス又はサービス内の全ユーザとした場合に、管理すべきチケット数を削減することができる。

≪第５の実施形態≫

次に、第５の実施形態について、図２１、図２２に基づいて説明する。図２１には、第５の実施形態に係る仲介サーバ５１０の機能ブロック図が示されている。図２１と、図３（第１の実施形態の仲介サーバ１０）とを比較すると分かるように、仲介サーバ５１０は、図３に示すデータ収集部１８の代わりにデータ取得部２６を有している。また、仲介サーバ５１０は、図３に示すデータ保持部３２の代わりに、データキャッシュ部４０を有している。

データ取得部２６は、認可セッションのセッションＩＤをアクセス制御部２２から取得すると、そのＩＤに対応するアクセストークンを認可セッション保持部３０から読み出し、既存サービスＡからデータを取得する。なお、データ取得部２６は、データ取得前に、データキャッシュ部４０を検索し、取得しようとしているデータがあった場合にはそのデータを取得しないこととする。一方、データキャッシュ部４０に取得しようとしているデータがなかった場合には既存サービスＡからデータを取得して、データキャッシュ部４０に取得したデータを保存するとともに、当該データを返す。そして、データ取得部２６は、データキャッシュ部４０に存在しているデータ又は既存サービスＡから取得してデータキャッシュ部４０に保存したデータを、アクセス制御部２２に渡す。なお、データキャッシュ部４０は、認可セッションのセッションＩＤごとに、データ群を保持するテーブルであるものとする。

図２２には、第１の実施形態における図９の処理に対応する処理が示されている。図２２の処理では、図９のステップＳ６０と、ステップＳ６２との間に、データ取得部２６がステップＳ６１Ａ〜Ｓ６１Ｅの処理・判断を実行する。

ユーザ２が、チケットＴ１、新サービスＸのＩＤ（Ｘ）、ユーザのＩＤ（User2）を付与して、仲介サーバ５１０に対してデータの取得要求（リクエスト）を行うと、チケット検証部２０は、受け取ったチケットとチケット保持部３６の内容を照合する（Ｓ５８）。そして、正しい組み合わせの場合には、チケット検証部２０は、アクセス制御部２２に対して、新サービスＸのユーザ２のＩＤ（User2）を伝える（Ｓ６０）。また、アクセス制御部２２は、アクセス制御ルール保持部３４のエントリを読み出し、新サービスＸのユーザ２がアクセスできる認可セッションのセッションＩＤ（ＳＩＤ１）を取得する。その後、アクセス制御部２２は、上記セッションＩＤ（ＳＩＤ１）をデータ取得部２６に通知する。

データ取得部２６は、図２２のステップＳ６１Ａにおいて、セッションＩＤ（ＳＩＤ１）をキーにデータキャッシュ部４０を検索し、データの有無を確認する。なお、ユーザ２よりデータのＩＤが指定されている場合にはそのＩＤもキーとして検索する。

なお、リクエストが初回の場合にはデータが見つからないため、ステップＳ６１Ａの判断は否定されて、データ取得部２６は、ステップＳ６１Ｂに移行する。ステップＳ６１Ｂでは、データ取得部２６は、セッションＩＤ（ＳＩＤ１）をキーとして認可セッション保持部３０を検索し、アクセストークン（Ｔｏｋｅｎ1）を取得する。

次いで、ステップＳ６１Ｃでは、データ取得部２６はアクセストークン（Ｔｏｋｅｎ１）を使って、既存サービスＡからデータを取得する。次いで、ステップＳ６１Ｄでは、データ取得部２６は、取得したデータをデータキャッシュ部４０に保存する。そして、ステップＳ６２では、データキャッシュ部４０に保存したデータをアクセス制御部２２に渡す。この場合、アクセス制御部２２は、データ取得部２６から渡されたデータをユーザ２に応答する。

なお、ステップＳ６１Ａの判断が肯定された場合には、ステップＳ６１Ｅにおいて、データ取得部２６はデータキャッシュ部４０からデータを読み出し、ステップＳ６２において、そのデータをアクセス制御部２２に渡す。この場合も、アクセス制御部２２は、データ取得部２６から渡されたデータをユーザ２に応答する。

なお、既存サービスＡにおいてデータ更新や追加・削除が行われる場合がある。このような場合には、従来のキャッシュ技術と同様、データに有効期限を設定してキャッシュ保持部よりデータを削除するようにしてもよい。あるいは、キャッシュ容量の上限を超えたら古いデータから消すようにしてもよい。あるいは、一部のデータのキャッシュを禁止するなどしてもよい。

以上のように、本第５の実施形態によると、データ取得部２６は、データを事前収集しないこととしている。これにより、膨大なデータを扱う既存サービスと連携した場合でも、性能をある程度維持したまま、仲介サーバ５１０が保持する必要のあるデータの容量を削減することができる。これにより、コストダウンを図ることができる。

≪第６の実施形態≫
次に、第６の実施形態について、図２３〜図２５に基づいて説明する。図２３には、第６の実施形態に係る仲介サーバ６１０の機能ブロック図が示されている。

仲介サーバ６１０は、第１の実施形態の仲介サーバ１０の構成に加えて、変換後データ保持部４４と、変換ルール保持部４２と、データ変換部２４とを有している。

変換後データ保持部４４は、認可セッションのセッションＩＤごとに、データ群を保持するテーブルであり、データ保持部３２とデータ構造は同様となっている。

変換ルール保持部４２は、既存サービスと新サービスの組み合わせごとに、変換処理のルールを保持するテーブルである。具体的には、図２４（ａ）に示すようなデータ構造を有している。図２４（ａ）においては、既存サービスＡから新サービスＸにデータを渡す際には、ＪＳＯＮ形式をＸＭＬ形式に変換すること、および“Field1”のフィールド名を“Data_ID”に変換すること、が定義されている。

データ変換部２４は、データ保持部３２のデータを読み出し、変換ルール保持部４２のルールに従ってデータの変換を行った後、変換後データ保持部４４に変換後のデータを保存する。例えば、図２４（ｂ）に示すデータを、図２４（ａ）の変換ルールに従って変換すると、図２４（ｃ）に示すデータとなる。

なお、図２５は、データ変換部２４の具体的な処理を示すフローチャートである。データ変換部２４は、図２５のステップＳ２００において、常時、データ保持部３２のデータを確認しており、新しいデータが追加された場合に、ステップＳ２０２に移行する。ステップＳ２０２では、データ変換部２４は、データ保持部３２から新しく追加されたデータを読み出す。次いで、ステップＳ２０４では、データ変換部２４は、読みだしたデータのサービスＩＤ（Ａ）を検索キーに、変換ルール保持部４２からエントリを読み出す。そして、ステップＳ２０４では、データ変換部２４は、読みだしたエントリに基づいてデータを変換し、ステップＳ２０６において、変換後データ保持部４４に変換後のデータを書き出す。その後は、ステップＳ２００に戻り、上記処理を繰り返す。

以上のように、本第６の実施形態によると、データ変換部２４がデータの変換処理を行うことで、複数の既存サービスと連携することができるようになる。

なお、図２４（ａ）では、既存サービスと新サービスとにより変換ルールを定義しているが、これに限らず、複数の既存サービスを共通的なデータフォーマットに変換するのみでもよい。このようにしても、新サービスＸは仲介サーバ６１０の提供するデータフォーマットのみを意識するだけで、複数の既存サービスと連携することができるようになる。

なお、上記第１〜第６の実施形態は適宜組み合わせ可能である。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の第１〜第６の実施形態の説明に関して、更に以下の付記を開示する。
（付記１）第１のユーザが利用可能な第１のサービスと、
第２のユーザが利用可能な第２のサービスと、
前記第１のユーザから、前記第２のユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記第２のユーザに対して認証情報を送付し、前記第２のユーザから前記認証情報を利用したアクセスがあった場合に、前記第１のサービスから収集した情報を開示する仲介サーバと、を備える情報開示システム。
（付記２）前記仲介サーバは、前記第１のユーザから、前記第１、第２のサービスとは異なる第３のサービスを利用する第３のユーザに対して前記第１のサービスの情報を開示する指示を受け付け、かつ、前記第２のユーザ及び前記第３のユーザが同一人物である場合には、前記第２のユーザに対して送付した認証情報と同一の認証情報を前記第３のユーザに対して送付することを特徴とする付記１に記載の情報開示システム。
（付記３）前記仲介サーバは、前記第１のユーザから、前記第２のユーザを含む前記第２のサービスを利用可能な全ユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記全ユーザに対して共通の認証情報を送付することを特徴とする付記１に記載の情報開示システム。
（付記４）前記仲介サーバは、前記第１のサービスから収集した情報を所定の変換ルールに基づいて変換し、開示することを特徴とする付記１〜３のいずれかに記載の情報開示システム。
（付記５）前記仲介サーバは、前記第２のユーザから前記認証情報を利用したアクセスがあったタイミングで、前記第２のユーザに開示する情報を前記第１のサービスから収集することを特徴とする付記１〜４のいずれかに記載の情報開示システム。
（付記６）前記仲介サーバは、前記第１のサービスから収集した情報をキャッシュすることを特徴とする付記５に記載の情報開示システム。
（付記７）第１のサービスを利用している第１のユーザから、第２のサービスを利用している第２のユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記第２のユーザに対して認証情報を送付し、
前記第２のユーザから前記認証情報を利用したアクセスがあった場合に、前記第１のサービスから収集した情報を開示する、処理をコンピュータに実行させることを特徴とする情報開示プログラム。
（付記８）前記第１のユーザから、前記第１、第２のサービスとは異なる第３のサービスを利用する第３のユーザに対して前記第１のサービスの情報を開示する指示を受け付け、かつ、前記第２のユーザ及び前記第３のユーザが同一人物である場合には、前記第２のユーザに対して送付した認証情報と同一の認証情報を前記第３のユーザに対して送付する処理を前記コンピュータに実行させることを特徴とする付記７に記載の情報開示プログラム。
（付記９）前記認証情報を送付する処理では、前記第１のユーザから、前記第２のユーザを含む前記第２のサービスを利用可能な全ユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記全ユーザに対して共通の認証情報を送付することを特徴とする付記７に記載の情報開示プログラム。
（付記１０）前記情報を開示する処理では、前記第１のサービスから収集した情報を所定の変換ルールに基づいて変換し、開示することを特徴とする付記７〜９のいずれかに記載の情報開示プログラム。
（付記１１）前記第２のユーザから前記認証情報を利用したアクセスがあったタイミングで、前記第２のユーザに開示する情報を前記第１のサービスから収集することを特徴とする付記７〜１０のいずれかに記載の情報開示プログラム。
（付記１２）前記第１のサービスから収集した情報をキャッシュすることを特徴とする付記１１に記載の情報開示プログラム。
（付記１３）第１のサービスを利用している第１のユーザから、第２のサービスを利用している第２のユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記第２のユーザに対して認証情報を送付する工程と、
前記第２のユーザから前記認証情報を利用したアクセスがあった場合に、前記第１のサービスから収集した情報を開示する工程と、をコンピュータが実行することを特徴とする情報開示方法。
（付記１４）前記第１のユーザから、前記第１、第２のサービスとは異なる第３のサービスを利用する第３のユーザに対して前記第１のサービスの情報を開示する指示を受け付け、かつ、前記第２のユーザ及び前記第３のユーザが同一人物である場合には、前記第２のユーザに対して送付した認証情報と同一の認証情報を前記第３のユーザに対して送付する工程を前記コンピュータが実行することを特徴とする付記１３に記載の情報開示方法。
（付記１５）前記認証情報を送付する工程では、前記第１のユーザから、前記第２のユーザを含む前記第２のサービスを利用可能な全ユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記全ユーザに対して共通の認証情報を送付することを特徴とする付記１３に記載の情報開示方法。
（付記１６）前記情報を開示する工程では、前記第１のサービスから収集した情報を所定の変換ルールに基づいて変換し、開示することを特徴とする付記１３〜１５のいずれかに記載の情報開示方法。
（付記１７）前記第２のユーザから前記認証情報を利用したアクセスがあったタイミングで、前記第２のユーザに開示する情報を前記第１のサービスから収集することを特徴とする付記１３〜１６のいずれかに記載の情報開示方法。
（付記１８）前記第１のサービスから収集した情報をキャッシュすることを特徴とする付記１７に記載の情報開示方法。

１０仲介サーバ
９０ＣＰＵ（コンピュータ）
１００情報開示システム

Claims

第１のユーザが利用可能な第１のサービスと、
第２のユーザが利用可能な第２のサービスと、
前記第１のユーザから、前記第２のユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記第２のユーザに対して認証情報を送付し、前記認証情報を利用したユーザからのアクセスがあった場合に、前記第１のサービスから収集した情報を開示する仲介サーバと、を備え、
前記仲介サーバは、前記第１のユーザから、前記第１、第２のサービスとは異なる第３のサービスを利用する第３のユーザに対して前記第１のサービスの情報を開示する指示を受け付け、かつ、前記第２のユーザ及び前記第３のユーザが同一人物である場合には、前記第２のユーザに対して送付した認証情報と同一の認証情報を前記第３のユーザに対して送付することを特徴とする情報開示システム。
前記仲介サーバは、前記第１のサービスから収集した情報を所定の変換ルールに基づいて変換し、開示することを特徴とする請求項１に記載の情報開示システム。
第１のサービスを利用している第１のユーザから、第２のサービスを利用している第２のユーザに対して前記第１のサービスの情報を開示する指示を受け付けると、前記第２のユーザに対して認証情報を送付し、
前記認証情報を利用したユーザからのアクセスがあった場合に、前記第１のサービスから収集した情報を開示し、
前記第１のユーザから、前記第１、第２のサービスとは異なる第３のサービスを利用する第３のユーザに対して前記第１のサービスの情報を開示する指示を受け付け、かつ、前記第２のユーザ及び前記第３のユーザが同一人物である場合には、前記第２のユーザに対して送付した認証情報と同一の認証情報を前記第３のユーザに対して送付する、
処理をコンピュータに実行させるための情報開示プログラム。
第１のサービスを利用している第１のユーザから、第２のサービスを利用している第２のユーザに対して前記第１のサービスの情報を開示する指示を受け付けた場合に、前記第２のユーザに対して認証情報を送付し、
前記認証情報を利用したユーザからのアクセスがあった場合に、前記第１のサービスから収集した情報を開示し、
前記第１のユーザから、前記第１、第２のサービスとは異なる第３のサービスを利用する第３のユーザに対して前記第１のサービスの情報を開示する指示を受け付け、かつ、前記第２のユーザ及び前記第３のユーザが同一人物である場合には、前記第２のユーザに対して送付した認証情報と同一の認証情報を前記第３のユーザに対して送付する、
処理をコンピュータが実行することを特徴とする情報開示方法。