信頼性保証サーバおよびサービス連携システム
【課題】サービス事業者がネットワーク上でAPIや情報を公開する場合に、サービス提供ポリシーに応じて、公開を許諾する相手を容易に制御可能とする。また、ユーザの匿名性を保ったまま、異なる複数のサービスプロバイダ間で、ユーザ情報を連携させたサービスの提供を可能とすること。
【解決手段】通信部11は、サービスプロバイダ2からサービスプロバイダ3の信頼性問い合わせを受ける。サービス連携制御部13は、サービスプロバイダ情報DB15とサービス提供ポリシーDB16に格納された情報から、サービスプロバイダ2のサービスをサービスプロバイダ3に利用許可するのが妥当か否か判定し、この判定結果をサービスプロバイダ2に返す。ユーザ連携紐付け部を備えれば、ユーザは、匿名性を保ったまま異なるサービスプロバイダによるサービスを受けることが可能になる。
【解決手段】通信部11は、サービスプロバイダ2からサービスプロバイダ3の信頼性問い合わせを受ける。サービス連携制御部13は、サービスプロバイダ情報DB15とサービス提供ポリシーDB16に格納された情報から、サービスプロバイダ2のサービスをサービスプロバイダ3に利用許可するのが妥当か否か判定し、この判定結果をサービスプロバイダ2に返す。ユーザ連携紐付け部を備えれば、ユーザは、匿名性を保ったまま異なるサービスプロバイダによるサービスを受けることが可能になる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、信頼性保証サーバおよびサービス連携システムに関し、特に、異なる事業者が提供するサービスを安全に相互利用することができるように連携させる信頼性保証サーバおよびサービス連携システムに関する。
【背景技術】
【０００２】
近年、Webサービスとして、一般ユーザに対してAPIを公開し、サービスの機能や情報などを提供することが行われている。しかし、これら一般に公開されているAPIは、特に認証を必要とせず、全てのサービス事業者や一般ユーザでも広く利用可能なものである。したがって、ある事業者が提供する機能や情報を、他の信頼のおけるサービス事業者からのみ利用可能とするような仕組みは実現されていない。
【０００３】
異なったサービス事業者が提供する機能や情報を安全に交換するためには、要求元のサービスプロバイダからのリクエストが正当であることを認証し、該リクエストを要求先のサービスプロバイダへ送信することが必要となる。
【０００４】
この際、サービスプロバイダの間では、(1)要求元のサービスプロバイダが、成りすましされていないサービスプロバイダであること、(2)要求元のサービスプロバイダが、要求先のサービスプロバイダからみて十分に信頼できるサービスプロバイダであること、の２点が守られている必要がある。つまり、今、Bと名乗るサービスプロバイダからサービスプロバイダAに対してサービスの機能利用や情報取得などのリクエストがあったときに、「Bと名乗るサービスプロバイダからのリクエストは、本当にサービスプロバイダBからきた要求である」ことを証明するのが(1)であり、「サービスプロバイダBは、サービスプロバイダAの基準からみて自分のサービスの機能を利用させ、あるいは情報を提供してよい相手である」ことを証明するのが(2)であるといえる。
【０００５】
(1)については、電子証明書などで、要求元のサービスプロバイダが正当であることを証明することができる。一方、(2)については、これまで(1)で正当であると証明されたサービスプロバイダを無条件に信頼する、あるいは、サービスプロバイダ間で個別に契約を締結し、それに基づいてサービスの機能を利用させ、あるいは情報を提供してよいサービスプロバイダであるとするのが一般的であった。
【０００６】
特許文献１には、Webサービスにおいて、中間サービス提供者が、サービスの内容を保証し、利用者が安心して使用できることを実現するWebサービスシステムが記載されている。これでは、与信情報を利用して、サービス内容の信頼性を通知する。
【０００７】
特許文献２には、複数のサービスを同時に利用する際のサービス制御システムが記載されている。これでは、同時に提供される異なる複数のサービスを比較し、統括的に制御することで、ユーザのサービスに対する要求の特性を考慮した各サービスの提供方法を動的に決定する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−９９９６９号公報
【特許文献２】特開２００５−１００３２０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述のようなアプローチは、(A)個々のサービスプロバイダのポリシーに基づいてきめ細かくサービスの機能を利用させ、あるいは情報を提供する制御を行うことができない、(B)要求元のサービスプロバイダが、サービスの機能を利用させ、あるいは情報を提供してよい相手かどうか判断する方法がない、つまり前述の(2)を証明する方法がない、という課題がある。例えば、特許文献１が実現しているのは、与信という一つの項目の情報のみで、その信頼性を通知する仕組みであり、そのプロバイダ間の相互関係に基づいているものではない。また、与信という情報を与えるのみで、その情報を元に、個々のサービスプロバイダのポリシーに基づいたサービス制御を実現する仕組みには至っていない。
【００１０】
特許文献１に記載されたWebサービスシステムおよび特許文献２に記載されたサービス制御システムは、上記(A),(B)の点を解決し、異なったサービス事業者が提供するサービスの機能や情報を安全に交換するものではない。
【００１１】
本発明の目的は、上記課題を解決し、異なる事業者が提供するサービスを安全に相互利用することができるように連携させる信頼性保証サーバおよびサービス連携システムを提供することにある。
【００１２】
また、本発明の他の目的は、ユーザの匿名性を保ったまま、異なるサービスプロバイダにおけるユーザ情報の問い合わせを可能とすることであり、これにより、異なるサービスプロバイダ間を連携させる信頼性保証サーバおよびサービス連携システムを提供することにある。
【課題を解決するための手段】
【００１３】
上記課題を解決するため、本発明の信頼性保証サーバは、複数のサービスプロバイダ間で事業者間の信頼性を保証しつつ、各サービスプロバイダが提供するサービスを連携させる信頼性保証サーバであって、各サービスプロバイダの事業者の信頼性に関する情報および各サービスプロバイダが提供するサービスについての情報を格納するサービスプロバイダ情報DBと、各サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを格納するサービス提供ポリシーDBと、ネットワークを介してサービスプロバイダからリクエストを受ける通信部と、前記通信部が受けたリクエストに対して、前記サービスプロバイダ情報DBおよび前記サービス提供ポリシーDBから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて前記リクエストに応えることが妥当か否かを判定し、該判定結果に応じた応答を送出するサービス連携制御部を備えた点に第１の特徴がある。
【００１４】
また、本発明の信頼性保証サーバは、前記通信部が、サービス提供元サービスプロバイダから信頼性保証対象事業者の信頼性問い合わせをリクエストとして受け、前記サービス連携制御部が、前記通信部が受けた信頼性問い合わせに対して、前記サービスプロバイダ情報DBおよび前記サービス提供ポリシーDBから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて信頼性保証対象事業者の信頼性を判定し、該判定結果を応答としてサービス提供元サービスプロバイダに返す点に第２の特徴がある。
【００１５】
また、本発明の信頼性保証サーバは、さらに、各ユーザに与えられる共通ユーザIDと該共通ユーザIDに対してサービスプロバイダごとに紐付けられたハンドルを格納するユーザ連携DBと、前記共通ユーザIDを用いて各サービスプロバイダに対するユーザのログインを可能とするシングルサインオン部と、サービスプロバイダからの特定ユーザの情報取得要求に対してサービスプロバイダ間で情報取得要求およびそれに対する応答を送受する際に、前記ユーザ連携DBを用いてハンドルを変換するユーザ連携紐付け部を備えた点に第３の特徴がある。
【００１６】
また、本発明の信頼性保証サーバは、前記通信部が、信頼性保証対象事業者のサービスプロバイダからサービス提供元サービスプロバイダの情報提供要求をリクエストとして受け、前記サービス連携制御部は、前記通信部が受けた情報提供要求に対して、前記サービスプロバイダ情報DBおよび前記サービス提供ポリシーDBから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて情報提供要求に応えることが妥当か否かを判定し、該判定結果によりサービス提供元サービスプロバイダから情報を取得し、該情報を応答として信頼性保証対象事業者のサービスプロバイダに返し、前記ユーザ連携紐付け部は、信頼性保証対象事業者のサービスプロバイダ側とサービス提供元サービスプロバイダ側とでハンドルを変換する点に第４の特徴がある。
【００１７】
また、本発明の信頼性保証サーバは、前記サービス提供ポリシーが、サービスの利用許可のためのサービス提供ポリシーを、サービス提供ポリシーDBから取得し、そのポリシーと、前記サービスプロバイダ情報DBに記載されたサービスプロバイダの属性情報から、サービスの利用許可を判定するものである点に第５の特徴がある。
【００１８】
また、本発明の信頼性保証サーバは、前記サービス提供ポリシーが、サービスプロバイダ情報DBに格納されているプロバイダなら全て許可、事前に登録済みの、信頼するプロバイダリストに登録されたプロバイダにのみ許可、特定の業種にのみ許可、過去一定期間以上信頼性保証サーバに登録されているプロバイダに対してのみ許可、信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可、一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可、のいずれか、またはその組み合わせをサービスの利用許可の条件として規定するものである点に第６の特徴がある。
【００１９】
また、本発明の信頼性保証サーバは、前記サービス提供ポリシーとして、信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可または一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可をサービスの利用許可の条件として規定するものを含み、前記サービス連携制御部は、サービス提供ポリシーDB中に含まれる他のサービスプロバイダと、当該サービスプロバイダの関連性に関する情報を取得する点に第７の特徴がある。
【００２０】
また、本発明の信頼性保証サーバは、前記サービス提供ポリシーとして、一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可をサービスの利用許可の条件として規定するものを含み、前記サービス連携制御部は、サービス提供ポリシーDB中に含まれる各サービスプロバイダのサービス提供ポリシーを検索し、当該サービスプロバイダを信頼しているサービスプロバイダの数を取得し、その件数が、前記サービス提供ポリシーに対して十分であるかをサービス利用許可の条件とする点に第８の特徴がある。
【００２１】
また、本発明の信頼性保証サーバは、各々のサービスプロバイダに対して、信頼性保証サーバを運営する事業者として、どのくらい信頼しているかに関する独自の指標を持ち、サービス利用許可の条件は、上記独自の指標をも用いて規定される点に第９の特徴がある。
【００２２】
また、本発明の信頼性保証サーバは、さらに、サービスプロバイダの電子証明書を保存し、サービスプロバイダの認証を行うサービスプロバイダ認証部を備え、前記サービス連携制御部は、前記サービスプロバイダ認証部により認証されたサービスプロバイダ間でのサービス連携を可能とする点に第１０の特徴がある。
【００２３】
また、本発明の信頼性保証サーバは、さらに、サービスプロバイダのURLおよび名称を含むサービス発見情報を保存し、サービスプロバイダからの要求に応じてサービス発見情報を提供するサービス発見機能を備える点に第１１の特徴がある。
【００２４】
また、本発明のサービス連携システムは、上記第２の特徴を有する信頼性保証サーバと、前記信頼性保証サーバにネットワークを介して接続された複数のサービスプロバイダを備え、前記サービス提供元サービスプロバイダは、信頼性保証対象事業者のサービスプロバイダから電子署名と共に自サービスプロバイダが提供するサービスの利用要求を受領した場合、前記信頼性保証サーバに対して電子署名と共に信頼性保証対象事業者の信頼性問い合わせを送出し、該信頼性問い合わせに対して返された判定結果を基に、信頼性保証対象事業者のサービスプロバイダに自サービスプロバイダが提供するサービスを利用させる点に第１の特徴がある。
【００２５】
また、本発明のサービス連携システムは、上記第３または第４の特徴を有する信頼性保証サーバと、前記信頼性保証サーバにネットワークを介して接続された複数のサービスプロバイダを備え、前記サービスプロバイダは、ユーザＩＤと一対一に紐付けられたハンドルを作成し、該ハンドルを含んだ情報提供要求あるいはそれに対する応答を前記信頼性保証サーバに対して送出する点に第２の特徴がある。
【発明の効果】
【００２６】
本発明では、信頼性保証サーバが各サービスプロバイダが提供するサービスを連携させることが妥当か否かを判定し、その判定結果を提供するので、各サービスプロバイダは、他サービスプロバイダから自サービスプロバイダが提供するサービスの機能利用あるいは情報取得が要求された際、要求元サービスプロバイダに対してサービスの機能利用あるいは情報取得を許可するか否かを決定できる。これにより、各サービスプロバイダが提供するサービスを柔軟かつ安全に連携させることができる。
【００２７】
また、過去にビジネス上の繋がりのない事業者のサービスプロバイダ間においても、信頼性保証サーバが要求元サービスプロバイダの信頼性に基づいてサービスを連携させることが妥当か否かを判定し、その判定結果を要求先サービスプロバイダに提供するので、要求先サービスプロバイダは要求元サービスプロバイダの信頼性を推測することが可能となる。これにより、サービスプロバイダ間でのサービス連携の拡大が期待できる。
【００２８】
また、本発明では、信頼性保証サーバが各サービスプロバイダの事業者の信頼性に関する情報と各サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーの両者を保持し、信頼性保証サーバ側で各サービスを連携させることが妥当か否かを判定するので、サービスプロバイダ間に流通する情報を最小限にしつつ高信頼でサービスプロバイダ間でのサービス連携を図ることができる。また、サービス提供ポリシーにより、きめ細かく、例えばサービスごとに、サービス連携を可能とするか否かの制御を行うことができる。
【００２９】
さらに、本発明によれば、ユーザの匿名性を保ったまま、異なるサービスプロバイダ間におけるユーザ情報の問い合わせが可能となるため、異なる複数のサービスプロバイダ間で、ユーザ情報を連携させたサービスを提供することが安全かつ容易に実現可能となる。
【図面の簡単な説明】
【００３０】
【図１】本発明に係るサービス連携システムの第１実施形態を示すブロック構成図である。
【図２】図１のサービス連携システムの動作を示すフローチャートである。
【図３】サービス提供ポリシーDBに登録されるサービス提供ポリシーのフォーマットを示す図である。
【図４】サービス発見機能の動作を具体的に示すフローチャートである。
【図５】サービス発見応答の例を示す図である。
【図６】本発明に係るサービス連携システムの第２実施形態を示すブロック構成図である。
【図７】図６のサービス連携システムの動作を示すフローチャートである。
【図８】信頼性保証サーバ1で行われるハンドル変換を概念的に示す図である。
【発明を実施するための形態】
【００３１】
以下、図面を参照して本発明を説明する。図１は、本発明に係るサービス連携システムの第１実施形態を示すブロック構成図である。なお、以下では、本発明がサービス連携システムとして実現された実施形態を説明するが、信頼性保証サーバ単体としても１つの装置を成すものであるので、本発明は、信頼性保証サーバとして実現されたものも含む。
【００３２】
本発明のサービス連携システムは、基本的に、ネットワークを介して接続された信頼性保証サーバおよび複数のサービスプロバイダにより構築される。図１では、信頼性保証サーバ1およびA社サービスプロバイダ2およびB社サービスプロバイダ3を示している。A社は、例えばメーカであり、B社は、例えば放送事業者である。
【００３３】
信頼性保証サーバ1は、通信部11、プロバイダ認証部12、サービス連携制御部13、サービス発見機能14、サービスプロバイダ情報データベース(DB)15およびサービス提供ポリシーDB16を備える。
【００３４】
通信部11は、ネットワークを介してサービスプロバイダ2,3からのリクエストを受け、それに対する応答を返す。プロバイダ認証部12は、各ユーザの電子証明を登録し、電子証明書の認証局機能を持ち、信頼性保証サーバ1を利用させるための認証処理を行う。
【００３５】
サービス連携制御部13は、各サービスプロバイダの事業者の信頼性に関する情報および各サービスプロバイダが提供するサービスの機能利用あるいは情報取得(以下、サービスの利用と称する。)を許可する際のサービス提供ポリシーに基づいてサービスプロバイダ2,3からのリクエストに応えることが妥当か否かを判定し、その判定結果に応じた応答を送出する。
【００３６】
サービス発見機能14は、サービスプロバイダのURLおよび名称を含むサービス発見情報を保存し、サービスプロバイダからの要求に応じてサービス発見情報を提供する。
【００３７】
サービスプロバイダ情報DB15は、各サービスプロバイダの事業者の信頼性に関する情報および各サービスプロバイダが提供するサービスについての情報などの各サービスプロバイダの属性情報を格納し、サービス提供ポリシーDB16は、各サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを格納する。
【００３８】
サービスプロバイダ2,3は、サービスを相互に連携する上で対等であれば同じ構成であるが、他サービスプロバイダに自サービスプロバイダのサービスの利用を許可するだけ、あるいは他サービスプロバイダのサービスを単に利用するだけ(放送事業者)の構成のサービスプロバイダも想定される。
【００３９】
図１では、サービスプロバイダ2がサービス利用要求先、サービスプロバイダ3がサービス利用要求元である場合、すなわち、サービスプロバイダ2がサービスプロバイダ3で提供されているサービスを利用する場合の動作説明に必要な構成要素のみを図示している。
【００４０】
サービスプロバイダ2は、通信部21、リクエスト受付部22、サービス提供機能23およびアクセス制御部24を有する。
【００４１】
通信部21は、信頼性保証サーバ1および他サービスプロバイダとの通信を行う。リクエスト受付部22は、他サービスプロバイダからのサービス利用要求を受け付け、信頼性保証サーバ1に対してサービス利用要求元事業者の信頼性問い合わせを行う。サービス提供機能23は、他サービスプロバイダに対して自サービスプロバイダのサービスを提供する。アクセス制御部24は、サービス利用可の応答を返す場合、ポリシーを変更(アクセス権設定)し、一定時間、他サービスプロバイダからのサービス利用要求に含まれるドメイン名に対してアクセスを許可する。
【００４２】
サービスプロバイダ3は、通信部31、サービス連携要求部32およびサービス提供部33を有する。
【００４３】
通信部31は、信頼性保証サーバ1および他のサービスプロバイダと通信を行う。サービス連携要求部32は、サービス利用要求先サービスプロバイダに対してサービス利用要求を送出する。サービス提供部33は、ユーザからのサービス要求を受け付け、サービスを提供する。
【００４４】
次に、図１のサービス連携システムの動作を説明する。図２は、その動作を示すフローチャートである。
【００４５】
今、サービスプロバイダ2が、自社(メーカA社)の持つ製品に関する詳細情報、部品の図面を提供するサービスを持ち、そのAPIを提供しているとする。A社がこのサービスの利用を自社と連携関係にある会社または放送事業者のみに限定したいとき、事前設定の手順として、まず、A社(メーカ)は、信頼性保証サーバ1を運営する事業者（以下、プラットフォーム事業者と称する。)とその旨を契約する(S21)。この契約は、書類手続きによって行われる。同様に、B社(放送事業者)も、プラットフォーム事業者と契約する(S22)。
【００４６】
契約に伴い、A社は、プラットフォーム事業者にサービスプロバイダ情報およびサービス提供ポリシーをオンラインあるいはオフラインで提供する。プラットフォーム事業者は、自ら、A社の信頼性・正当性を確認し、サービスプロバイダ情報DB15およびサービス提供ポリシーDB16にそれぞれ、サービスプロバイダ情報およびサービス提供ポリシーを登録する。同時に、A社の電子証明書をプロバイダ認証部12に登録する。
【００４７】
同様に、B社は、プラットフォーム事業者にサービスプロバイダ情報をオンラインあるいはオフラインで提供する。プラットフォーム事業者は、自ら、B社の信頼性・正当性を確認し、サービスプロバイダ情報DB15にサービスプロバイダ情報を登録する。同時に、B社の電子証明書をプロバイダ認証部12に登録する。
【００４８】
サービスプロバイダ情報には、例えば、(1)会社名・業種などの基本情報、(2)信頼性保証サーバ1に登録された期間および参照された回数、(3)該会社を信頼しているサービスプロバイダの情報などが含まれる。(1)の基本情報には、サービスプロバイダの名称、サービスプロバイダが提供するサービスおよびその名称、サービスプロバイダのURL、サービスを公開する対象なども含まれる。
【００４９】
サービス提供ポリシーは、(1)信頼性保証サーバ1に登録されているプロバイダなら全て許可、(2)事前に登録済みの、信頼するプロバイダリストに登録されたプロバイダにのみ許可、(3)特定の業種にのみ許可、(4)過去一定期間以上信頼性保証サーバ1に登録されているプロバイダに対してのみ許可、(5)信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可(信頼関係のチェーン)、(6)一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可(信頼関係の総量)、などといった、サービスを利用許可する際の条件を記載したデータである。
【００５０】
図３は、サービス提供ポリシーDB16に登録されるサービス提供ポリシーのフォーマットを示す図である。ここで、service IDは、サービスを一意に特定するためのIDであり、Public、ProviderIDs、Categories、Periodはそれぞれ上記(1)、(2)、(3)、(4)に対応する。TrustChain、Chaindepth、TrustNnm はそれぞれ図示内容を持ち、これらにより直接の信頼関係にないサービスプロバイダでも利用許可するかどうかの条件を規定することができる。
【００５１】
また、信頼性保証サーバ1では、サービスプロバイダ情報をサービス発見機能14に反映させる。サービス発見機能14は、Webサーバとして提供され、HTTPSプロトコルの要求とそれに対応するXMLメッセージによって実現される。XMLには、個々のサービスに対して、(1)サービスプロバイダの名称、(2)サービスプロバイダが提供するサービスの名称、(3)サービスプロバイダのURL、(4)サービスを公開する対象、などの情報が含まれる。
【００５２】
放送事業者B社は、信頼性保証サーバ1に対してサービス発見要求を送出し(S24)、サービス発見応答を受ける(S25)ことにより、自社サービスプロバイダが提供するサービスに連携して提供することができるサービスの存在を知ることができる。これは、信頼性保証サーバ1のサービス発見機能14を利用することで可能となる。以上までが事前設定の手順である。
【００５３】
図４は、サービス発見機能の動作を具体的に示すフローチャートである。サービスプロバイダ3は、信頼性保証サーバ1に対してサービス発見要求(HTTPSリクエスト)を送出し(S24)、該サービス発見要求に対するサービス発見応答(HTTPSリプライ(XML))を受ける(S25)。
【００５４】
図５は、サービス発見応答の例を示す図である。本例のサービス発見応答は、サービスプロバイダの通し番号(service Provider ID)、サービスプロバイダのURL(service Provider URL)、サービスリスト(Service Lists)としてサービスの通し番号(service ID)と該サービス名(name)と該サービスにアクセスするためのURL(service Provider URL)と該サービスのアクセス方法が取得するためのURL(manual URL)を含み、サービスプロバイダ3にはこれらの情報が一覧として提供される。
【００５５】
放送事業者B社は、信頼性保証サーバ1のサービス発見機能14によって、メーカA社サービスプロバイダ2が提供する図面情報提供サービスの存在を知ることができる。放送事業者B社が、このサービスを自社サービスプロバイダ3が提供するサービスに連携させて提供したいとする場合、以下のサービスプロバイダの信頼性の問い合わせの手順が実行される。
【００５６】
まず、放送事業者B社は、自社サービスプロバイダ3のサービス連携要求部32によって、サービスプロバイダ2に対してサービス利用要求を送出する(S26)。サービス利用要求は、上述のサービス発見によって取得されたURLに対するHTTPSリクエストとして送出される。サービス利用要求には、例えば、(1)送信元のサービスプロバイダ名、(2)送信元を保証するための電子署名、(3)サービスへのアクセス元のドメイン、の情報が含まれる。
【００５７】
サービスプロバイダ2は、サービスプロバイダ3からのサービス利用要求を通信部21で受信し、リクエスト受付部22に送出する。リクエスト受付部22は、サービス利用要求を受け取ると、通信部21を介して信頼性保証サーバ1に対してサービス利用要求に含まれている電子署名を転送し、サービス利用要求元の信頼性問い合わせを行う。すなわち、信頼性保証サーバ1にサービスプロバイダ3の信頼性問い合わせを送出する(S27)。
【００５８】
信頼性保証サーバ1では、サービスプロバイダ2からの信頼性問い合わせに対して以下の処理を行う。まず、サービスプロバイダ2から転送されてきたB社の電子署名をプロバイダ認証部12によって認証する。これにより、サービスプロバイダ2がなりすましされていないかを証明できる。
【００５９】
次に、サービス連携制御部13は、サービス提供ポリシーDB16から、事前に登録されているA社のサービス提供ポリシーを取得し、また、サービスプロバイダ情報DB15に登録されているB社のサービスプロバイダ情報からB社の信頼性に関する情報を取得する。なお、サービス提供ポリシーが、信頼関係のチェーンまたは信頼関係の総量に関するもの(すなわち上記(5)または(6))である場合、サービス連携制御部13は、サービス提供ポリシーDB16に対する検索を横断的に行い、B社を信頼しているプロバイダの数や種類に関する情報を取得する。
【００６０】
以下、具体例を挙げて示す。今、サービスプロバイダ2のポリシーが、TrustChainが1、ChainDepthが2だとする。すなわち、サービスプロバイダ2は、リクエスト要求元が、自身のPoviderIDs に登録されているサービスプロバイダそのものであるか、あるいは、それらサービスプロバイダのが持つそれぞれのサービスポリシーにおいて、1社以上のPoviderIDsに登録されていれば、サービス提供を許容するというポリシーを持ち、また、ここで、ChainDepthが3だとする。この場合、サービスプロバイダ2→サービスプロバイダ2が信頼するサービスプロバイダのリスト(サービスプロバイダ群A)→サービスプロバイダ群Aのうち何れかが信頼するサービスプロバイダのリストのように、再帰的にサービスポリシーの取得を行い、B社の信頼性についての情報を収集する。
【００６１】
以上の通り、TrustChainは、自社が直接・または間接に信頼関係を構築しているサービスプロバイダにのみサービス利用を許可することを可能にする。
【００６２】
一方、TrustNnmは、自身との直接もしくは間接の信頼関係ではなく、世間の「風評」に基づいて、サービスを提供もしくは拒絶することを可能にする。
【００６３】
このTrustNumは、他のサービスプロバイダのうち何社以上から信頼されているかに基づく指標であるが、悪質なサービスプロバイダが、自身の信頼度を上げるために、架空のサービスプロバイダを複数登録させ、サービスプロバイダ間で相互に信頼関係を作ったように見せかけ、この信頼されているサービスプロバイダの数を上昇させるという懸念がある。本信頼性保証サーバは、そのような架空のサービスプロバイダは審査の段階で拒絶するが、例えば、サービスプロバイダとしての最低限の実態のみを構築して審査を追加してしまい、相互に信頼関係を作ったように見せかけるという懸念がある。そこで、本信頼性保証サーバに、サービスプロバイダを信頼している件数というだけでなく、以下に示す「信頼度」を元にして判別する仕組みを導入し、信頼性判別を行ってもよい。以下、この信頼度について記載する。
【００６４】
サービスプロバイダが信頼性保証サーバに登録する際、前述の通り、サービスプロバイダとプラットフォーム事業者の間で書類手続きによる契約が行われる。この際、プラットフォーム事業者は、得られたサービスプロバイダの情報から、各サービスプロバイダに対して、信頼性保証サーバからの信頼度を設定する。この信頼度は、例えば１〜５のような数値であり、サービスプロバイダの社会的な信頼度や実績、上場有無等に基づき、プラットフォーム事業者のポリシーに応じて設定され、信頼性保証サーバ内に保存される。信頼度は非公開の情報であり、サービスプロバイダに開示されることは無い。
【００６５】
今、サービスプロバイダAが、m社のサービスプロバイダのPoviderIDs に登録されているとする。サービスプロバイダAを信頼するサービスプロバイダn自身の、信頼性保証サーバからの信頼度をRnとするとき、サービスプロバイダAの総合的な信頼度R_Allは、以下の式で算出できる。
【００６６】
【数１】
【００６７】
但し、ここでRは、サービスプロバイダA自身が、信頼性保証サーバから付与された信頼度の値、max(A,B)は、AとBの内、大きいほうを返す関数とする。
【００６８】
サービス提供事業者は、直接繋がりの無いサービスプロバイダとの間でも、前述の信頼度R_All を参照することで、当該サービスプロバイダの信頼性を判別することが可能となる。
【００６９】
次に、サービス連携制御部13は、B社のサービスプロバイダ3に対するサービス提供の可否、すなわち、B社の信頼性に関する情報がA社のサービス提供ポリシーの条件に合っているか否かを判定し、この判定結果をサービスプロバイダ3の信頼性問い合わせ(S27)に対する応答としてサービスプロバイダ2に返す(S28)。この例では、A社のサービスプロバイダ2が提供するサービスは、放送事業者に利用許可されることになっているので、B社の信頼性に関する情報は、上記(3)のサービス提供ポリシーに合致する。
【００７０】
サービスプロバイダ2は、信頼性保証サーバ1から信頼性問い合わせ応答を通信部21で受信し、リクエスト受付部22に送出する。リクエスト受付部22は、この信頼性問い合わせ応答に基づいて、サービス利用可否をサービス利用要求(S26)の応答としてサービスプロバイダ3に返す(S29)。ここで、サービス利用可の応答を返す場合、アクセス制御部23によってポリシーを変更(アクセス権設定)し、一定時間、サービスプロバイダ3からのリクエストに含まれるドメイン名に対してアクセスを許可する。アクセス制御部23は、例えば、Webサーバのアクセス制御機能などによって実装される。
【００７１】
B社のサービスプロバイダ3は、自サービスプロバイダが提供するサービスにA社サービスプロバイダ2が提供するサービスを連携させたサービスを、サービス提供部33を通してユーザに提供することができる。以上のように、サービスプロバイダ2,3間で信頼性が確保された場合には、B社サービスプロバイダ3は、A社サービスプロバイダ2のAPIを用いてユーザにサービスを提供することが可能となる。ユーザに対するサービスの提供では、サービスプロバイダ3は、ユーザからの要求に基づいて、サービスプロバイダ2が提供するサービスにアクセスし(S30)、そのサービス応答(S31)を受けてユーザの要求に応えることができる。ここで提供されるサービスには、例えば、B社のホームページ上で、A社の提供する図面を、B社のホームページ上から参照するような、いわゆるマッシュアップと呼ばれるサービスも含まれる。
【００７２】
以上のサービスプロバイダの信頼性の問い合わせの手順(S26〜S29)を通してサービスプロバイダ2,3間で信頼性が確保されなかった場合には、信頼性保証サーバ1は、サービスプロバイダ2に対してサービスプロバイダ3の信頼性問い合わせ(S27)に対する応答(S28)と共に信頼性欠如の理由、例えば、B社を信頼しているサービスプロバイダ(事業者)の数が足りなかった、B社の電子署名が不正であった、B社は、A社が信頼するサービスプロバイダの中に入っていなかった、などの理由を送信する。
【００７３】
サービスプロバイダ2がサービスプロバイダ3に返すサービス利用要求の応答は、任意のものとすることができる。例えば、この応答として、単純に拒絶を返してもよく、サービスプロバイダ3に対して別途問い合わせを送ってもよい。
【００７４】
図６は、本発明に係るサービス連携システムの第２実施形態を示すブロック構成図である。図６において、図１と同一あるいは同等部分には同じ符号を付してある。
【００７５】
第２実施形態は、異なるサービスプロバイダ間において、情報問い合わせ先サービスにおけるユーザIDを知る必要なく、ユーザに関する情報を、信頼できるサービスプロバイダ間で相互利用することを可能としたものである。
【００７６】
これを実現するため、第１実施形態の構成に加えて、信頼性保証サーバ1は、ユーザ連携DB17、シングルサインオン部18およびユーザ連携紐付け部19を備える。
【００７７】
ユーザ連携DB17は、各ユーザに与えられる共通ユーザIDとこの共通ユーザIDに対してサービスプロバイダごとに紐付けられたハンドルを格納する。
【００７８】
シングルサインオン部18は、ユーザ連携DB17に格納されている共通ユーザIDを用いて各サービスプロバイダに対するユーザのログインを可能とする。
【００７９】
ユーザ連携紐付け部19は、サービスプロバイダからの特定ユーザの情報提供要求に対してサービスプロバイダ間で情報提供要求およびそれに対する応答を送受する際に、ユーザ連携DB17を用いてハンドルを変換する
【００８０】
サービスプロバイダ2は、ユーザID DB25を備え、サービスプロバイダ3は、ユーザID DB34を備える。
【００８１】
ユーザID DB25,34は、各サービスプロバイダ2,3におけるユーザIDを格納しており、リクエスト受付部22およびサービス連携要求部32は、ユーザID DB25,34に格納されているユーザIDと一対一に紐付けられたハンドルを作成し、このハンドルを含んだ情報提供要求あるいはそれに対する応答を信頼性保証サーバ1に対して送出する。
【００８２】
次に、図６のサービス連携システムにおける動作を説明する。図７は、その動作を示すフローチャートである。
【００８３】
今、具体例として、A社のサービスプロバイダ2が赤い羽根募金キャンペーンを行っており、B社のサービスプロバイダ3がレストラン予約サービスを提供しているものとする。
【００８４】
また、サービスプロバイダ2は、自サービスプロバイダが提供するサービスを利用するユーザのうち、どのユーザが赤い羽根募金キャンペーンに賛同しているかのユーザ情報を、DBとして持っているものとする。また、ユーザは、この赤い羽根募金キャンペーンに関する情報を他のサービスプロバイダと共有することについて、事前に同意しているものとする。
【００８５】
信頼性保証サーバ1が提供するシングルサインオン機能によって、ユーザは、共通ユーザIDでサービスプロバイダ2,3のいずれに対してもログイン可能である。なお、シングルサインオンにおいては、各サービスプロバイダが提供するサービスにログインするために、ユーザごとに与えられる共通ユーザID、各サービスプロバイダが内部的に保持するユーザIDの他に、その共通IDとユーザIDを紐付けるためのハンドルが存在する。第２実施形態では、信頼性保証サーバ1でハンドルの変換を行う。
【００８６】
事前設定は、第１実施形態と同様であり、A社の赤い羽根キャンペーンが信頼性保証サーバ1のサービス発見機能に登録される。今、B社が、サービス発見機能14によって、この赤い羽根募金キャンペーンを発見し、これと連携したサービスとして、赤い羽根募金キャンペーンに賛同したユーザに対して特別割引を行うサービスの提供を希望したとする。
【００８７】
サービスプロバイダ3のユーザが、B社の提供するレストラン予約サービスを受けるために、シングルサインオンによりサービスプロバイダ3にログインすると、サービスプロバイダ3は、ユーザIDを認証した後、該ユーザが赤い羽根募金キャンペーンに賛同しているかについて、信頼性保証サーバ1に問い合わせる。
【００８８】
この問い合わせのために、サービスプロバイダ3は、自身の電子署名と、赤い羽根募金キャンペーンを行っているA社のサービスプロバイダ2に対する情報取得要求を信頼性保証サーバ1に対して送出する。このとき、サービスプロバイダ3は、ユーザを特定するためのユーザIDをそのまま送出せず、サービスプロバイダ3のユーザID DB34に格納されたユーザIDと一対一に紐付けられたハンドルを作成し、このハンドルを含んだ情報取得要求を送出する(S71)。
【００８９】
信頼性保証サーバ1は、この情報取得要求に対する情報提供の可否の判定を行う。
この判定の動作は、第１実施形態と同様である。すなわち、まず、プロバイダ認証部12が、サービスプロバイダ3から送出されてきた電子署名を認証する。
【００９０】
次に、サービス連携制御部13が、サービス提供ポリシーDB16から、事前に登録されているA社のサービスプロバイダ2が提供するサービスを利用許可する際のサービス提供ポリシーを取得し、また、サービスプロバイダ情報DB15に登録されているB社のサービスプロバイダ情報からB社の信頼性に関する情報を取得する。なお、サービス提供ポリシーが、信頼関係のチェーンまたは信頼関係の総量に関するものである場合、サービス連携制御部13は、サービス提供ポリシーDB16に対する検索を横断的に行い、B社を信頼しているプロバイダの数や種類に関する情報を取得する。
【００９１】
次に、サービス連携制御部13が、B社のサービスプロバイダ3に対する情報提供の可否、すなわち、B社の信頼性に関する情報がA社のサービスプロバイダ2が提供するサービスを利用許可する際のサービス提供ポリシーに合っているか否かを判定する。ここで、B社の信頼性に関する情報がA社のサービスプロバイダ2が提供するサービスを利用許可する際のサービス提供ポリシーに合っていると判定されれば、サービス連携制御部13は、ユーザ連携紐付け部19によってユーザ連携DB17を検索し、要求元ユーザに対するサービスプロバイダ2のハンドルを取得し、このハンドルを含む情報取得要求をサービスプロバイダ2に対して送出する(S72)。この情報取得要求は、要求元サービスプロバイダのID(URL)も含む。情報取得要求は、例えば、HTTPSプロトコルによるGet命令に相当する。
【００９２】
サービスプロバイダ2は、信頼性保証サーバ1からの情報取得要求をリクエスト受付部22で受け付け、取得要求されたユーザ情報、すなわち、ユーザが赤い羽根募金キャンペーンに賛同しているかの情報を検索し、応答として返す(S73)。このとき、情報取得要求に対しては、アクセス制御部23によって、アクセス元IPアドレスを判別し、信頼性保証サーバ1からの要求のみを受け付ける。
【００９３】
信頼性保証サーバ1は、サービスプロバイダ2から返されたユーザ情報を情報取得要求(S71)に対する応答として直接サービスプロバイダ3に返す(S74)。第１実施形態では、サービスプロバイダ3の信頼性問い合わせに対する応答をサービスプロバイダ2に返しているが、第２実施形態の情報取得要求に対する応答は直接要求元サービスプロバイダ3に返す。
【００９４】
図８は、信頼性保証サーバ1で行われるハンドル変換を概念的に示す図である。ここでは、サービスプロバイダ2,3のURLをそれぞれ、http://servicea.com/、http://serviceb.com/とし、共通ユーザID(共通User ID)がUser1である特定ユーザに対して、ユーザID DB25,34が格納するユーザID(User ID)をそれぞれAlice、Bobとし、それに紐付けられたハンドル(User ID紐付け索引)をそれぞれ、Alicezz、123Bobとする。
【００９５】
信頼性保証サーバ1のユーザ連携DB17は、特定ユーザの共通ユーザID(共通User ID)とそれに対応するサービスプロバイダ2,3のURL(サービスプロバイダURL)とハンドル(User ID紐付け索引)を格納する。
【００９６】
サービスプロバイダ3は、特定ユーザについてサービスプロバイダ2のDBが持つ情報を知りたい場合、ハンドルAlicezzを含む情報取得要求(クエリ)を信頼性保証サーバ1に送出する(S81)。
【００９７】
信頼性保証サーバ1は、ユーザ連携DB17に格納された情報からサービスプロバイダ2に対するハンドル123Bobを取得し、ハンドルをAlicezzから123Bobに変換する。そして、ハンドル123Bobを含むクエリをサービスプロバイダ2に送出する(S82)。クエリには、アクセス元IPアドレス(信頼性保証サーバ1のIPアドレス)も含ませる。
【００９８】
サービスプロバイダ2は、リクエスト受付部22が付けたクエリが信頼性保証サーバ1からのものであることをアクセス元IPアドレスから判別し、クエリに対する応答を信頼性保証サーバ1に返す(S83)。この応答は、ハンドル123Bobおよび特定ユーザが赤い羽根募金キャンペーンに賛同しているか否かのユーザ情報(true又はfalse)を含む。
【００９９】
信頼性保証サーバ1は、サービスプロバイダ2から返された応答をクエリ(S81)に対する応答としてサービスプロバイダ3に返す(S84)。この際、ハンドルを123BobからAlicezzに変換する。この応答は、ハンドルAlicezzおよび特定ユーザが赤い羽根募金キャンペーンに賛同しているか否かのユーザ情報(true又はfalse)を含む。
【０１００】
以上の手順(S71〜S74,S81〜S84)によって、サービスプロバイダ3では、ユーザがA社の赤い羽根募金キャンペーンに賛同しているという情報を取得することができるので、サービスプロバイダ3におけるメニュー画面において、羽根募金キャンペーンに基づいた特別割引サービスを提示することが可能となる(図７(S75))。
【０１０１】
また、以上の手順では、サービスプロバイダ2,3間で直接通信を行っておらず、信頼性保証サーバ1を介在させ、かつそれぞれのハンドルを用いているので、サービス間で匿名性を保ったまま、安全にユーザに関する情報を公開することができる。さらに、信頼性保証サーバ1のサービス連携制御部13によって、各サービスプロバイダのサービス提供ポリシーを反映させ、きめ細かく、例えばサービスごとに、サービス連携を可能とするか否かの制御を行うことができる。
【０１０２】
以上、実施形態を説明したが、本発明は、上記実施形態に限定されるものではなく、種々に変形可能である。例えば、サービスプロバイダ情報DB15やサービス提供ポリシーDB16が格納する情報は、上記した情報に限られるものではなく、また、適宜変更して格納することができるものである。
【符号の説明】
【０１０３】
1・・・信頼性保証サーバ、2,3・・・サービスプロバイダ、11・・・通信部、12・・・プロバイダ認証部、13・・・サービス連携制御部、14・・・サービス発見機能、15・・・サービスプロバイダ情報DB、16・・・サービス提供ポリシーDB、17・・・ユーザ連携DB、18・・・シングルサインオン部、19・・・ユーザ連携紐付け部、21,31・・・通信部、22・・・リクエスト受付部、23・・・サービス提供機能、24・・・アクセス制御部、25,34・・・ユーザID DB、32・・・サービス連携要求部、33・・・サービス提供部
【技術分野】
【０００１】
本発明は、信頼性保証サーバおよびサービス連携システムに関し、特に、異なる事業者が提供するサービスを安全に相互利用することができるように連携させる信頼性保証サーバおよびサービス連携システムに関する。
【背景技術】
【０００２】
近年、Webサービスとして、一般ユーザに対してAPIを公開し、サービスの機能や情報などを提供することが行われている。しかし、これら一般に公開されているAPIは、特に認証を必要とせず、全てのサービス事業者や一般ユーザでも広く利用可能なものである。したがって、ある事業者が提供する機能や情報を、他の信頼のおけるサービス事業者からのみ利用可能とするような仕組みは実現されていない。
【０００３】
異なったサービス事業者が提供する機能や情報を安全に交換するためには、要求元のサービスプロバイダからのリクエストが正当であることを認証し、該リクエストを要求先のサービスプロバイダへ送信することが必要となる。
【０００４】
この際、サービスプロバイダの間では、(1)要求元のサービスプロバイダが、成りすましされていないサービスプロバイダであること、(2)要求元のサービスプロバイダが、要求先のサービスプロバイダからみて十分に信頼できるサービスプロバイダであること、の２点が守られている必要がある。つまり、今、Bと名乗るサービスプロバイダからサービスプロバイダAに対してサービスの機能利用や情報取得などのリクエストがあったときに、「Bと名乗るサービスプロバイダからのリクエストは、本当にサービスプロバイダBからきた要求である」ことを証明するのが(1)であり、「サービスプロバイダBは、サービスプロバイダAの基準からみて自分のサービスの機能を利用させ、あるいは情報を提供してよい相手である」ことを証明するのが(2)であるといえる。
【０００５】
(1)については、電子証明書などで、要求元のサービスプロバイダが正当であることを証明することができる。一方、(2)については、これまで(1)で正当であると証明されたサービスプロバイダを無条件に信頼する、あるいは、サービスプロバイダ間で個別に契約を締結し、それに基づいてサービスの機能を利用させ、あるいは情報を提供してよいサービスプロバイダであるとするのが一般的であった。
【０００６】
特許文献１には、Webサービスにおいて、中間サービス提供者が、サービスの内容を保証し、利用者が安心して使用できることを実現するWebサービスシステムが記載されている。これでは、与信情報を利用して、サービス内容の信頼性を通知する。
【０００７】
特許文献２には、複数のサービスを同時に利用する際のサービス制御システムが記載されている。これでは、同時に提供される異なる複数のサービスを比較し、統括的に制御することで、ユーザのサービスに対する要求の特性を考慮した各サービスの提供方法を動的に決定する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−９９９６９号公報
【特許文献２】特開２００５−１００３２０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述のようなアプローチは、(A)個々のサービスプロバイダのポリシーに基づいてきめ細かくサービスの機能を利用させ、あるいは情報を提供する制御を行うことができない、(B)要求元のサービスプロバイダが、サービスの機能を利用させ、あるいは情報を提供してよい相手かどうか判断する方法がない、つまり前述の(2)を証明する方法がない、という課題がある。例えば、特許文献１が実現しているのは、与信という一つの項目の情報のみで、その信頼性を通知する仕組みであり、そのプロバイダ間の相互関係に基づいているものではない。また、与信という情報を与えるのみで、その情報を元に、個々のサービスプロバイダのポリシーに基づいたサービス制御を実現する仕組みには至っていない。
【００１０】
特許文献１に記載されたWebサービスシステムおよび特許文献２に記載されたサービス制御システムは、上記(A),(B)の点を解決し、異なったサービス事業者が提供するサービスの機能や情報を安全に交換するものではない。
【００１１】
本発明の目的は、上記課題を解決し、異なる事業者が提供するサービスを安全に相互利用することができるように連携させる信頼性保証サーバおよびサービス連携システムを提供することにある。
【００１２】
また、本発明の他の目的は、ユーザの匿名性を保ったまま、異なるサービスプロバイダにおけるユーザ情報の問い合わせを可能とすることであり、これにより、異なるサービスプロバイダ間を連携させる信頼性保証サーバおよびサービス連携システムを提供することにある。
【課題を解決するための手段】
【００１３】
上記課題を解決するため、本発明の信頼性保証サーバは、複数のサービスプロバイダ間で事業者間の信頼性を保証しつつ、各サービスプロバイダが提供するサービスを連携させる信頼性保証サーバであって、各サービスプロバイダの事業者の信頼性に関する情報および各サービスプロバイダが提供するサービスについての情報を格納するサービスプロバイダ情報DBと、各サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを格納するサービス提供ポリシーDBと、ネットワークを介してサービスプロバイダからリクエストを受ける通信部と、前記通信部が受けたリクエストに対して、前記サービスプロバイダ情報DBおよび前記サービス提供ポリシーDBから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて前記リクエストに応えることが妥当か否かを判定し、該判定結果に応じた応答を送出するサービス連携制御部を備えた点に第１の特徴がある。
【００１４】
また、本発明の信頼性保証サーバは、前記通信部が、サービス提供元サービスプロバイダから信頼性保証対象事業者の信頼性問い合わせをリクエストとして受け、前記サービス連携制御部が、前記通信部が受けた信頼性問い合わせに対して、前記サービスプロバイダ情報DBおよび前記サービス提供ポリシーDBから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて信頼性保証対象事業者の信頼性を判定し、該判定結果を応答としてサービス提供元サービスプロバイダに返す点に第２の特徴がある。
【００１５】
また、本発明の信頼性保証サーバは、さらに、各ユーザに与えられる共通ユーザIDと該共通ユーザIDに対してサービスプロバイダごとに紐付けられたハンドルを格納するユーザ連携DBと、前記共通ユーザIDを用いて各サービスプロバイダに対するユーザのログインを可能とするシングルサインオン部と、サービスプロバイダからの特定ユーザの情報取得要求に対してサービスプロバイダ間で情報取得要求およびそれに対する応答を送受する際に、前記ユーザ連携DBを用いてハンドルを変換するユーザ連携紐付け部を備えた点に第３の特徴がある。
【００１６】
また、本発明の信頼性保証サーバは、前記通信部が、信頼性保証対象事業者のサービスプロバイダからサービス提供元サービスプロバイダの情報提供要求をリクエストとして受け、前記サービス連携制御部は、前記通信部が受けた情報提供要求に対して、前記サービスプロバイダ情報DBおよび前記サービス提供ポリシーDBから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて情報提供要求に応えることが妥当か否かを判定し、該判定結果によりサービス提供元サービスプロバイダから情報を取得し、該情報を応答として信頼性保証対象事業者のサービスプロバイダに返し、前記ユーザ連携紐付け部は、信頼性保証対象事業者のサービスプロバイダ側とサービス提供元サービスプロバイダ側とでハンドルを変換する点に第４の特徴がある。
【００１７】
また、本発明の信頼性保証サーバは、前記サービス提供ポリシーが、サービスの利用許可のためのサービス提供ポリシーを、サービス提供ポリシーDBから取得し、そのポリシーと、前記サービスプロバイダ情報DBに記載されたサービスプロバイダの属性情報から、サービスの利用許可を判定するものである点に第５の特徴がある。
【００１８】
また、本発明の信頼性保証サーバは、前記サービス提供ポリシーが、サービスプロバイダ情報DBに格納されているプロバイダなら全て許可、事前に登録済みの、信頼するプロバイダリストに登録されたプロバイダにのみ許可、特定の業種にのみ許可、過去一定期間以上信頼性保証サーバに登録されているプロバイダに対してのみ許可、信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可、一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可、のいずれか、またはその組み合わせをサービスの利用許可の条件として規定するものである点に第６の特徴がある。
【００１９】
また、本発明の信頼性保証サーバは、前記サービス提供ポリシーとして、信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可または一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可をサービスの利用許可の条件として規定するものを含み、前記サービス連携制御部は、サービス提供ポリシーDB中に含まれる他のサービスプロバイダと、当該サービスプロバイダの関連性に関する情報を取得する点に第７の特徴がある。
【００２０】
また、本発明の信頼性保証サーバは、前記サービス提供ポリシーとして、一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可をサービスの利用許可の条件として規定するものを含み、前記サービス連携制御部は、サービス提供ポリシーDB中に含まれる各サービスプロバイダのサービス提供ポリシーを検索し、当該サービスプロバイダを信頼しているサービスプロバイダの数を取得し、その件数が、前記サービス提供ポリシーに対して十分であるかをサービス利用許可の条件とする点に第８の特徴がある。
【００２１】
また、本発明の信頼性保証サーバは、各々のサービスプロバイダに対して、信頼性保証サーバを運営する事業者として、どのくらい信頼しているかに関する独自の指標を持ち、サービス利用許可の条件は、上記独自の指標をも用いて規定される点に第９の特徴がある。
【００２２】
また、本発明の信頼性保証サーバは、さらに、サービスプロバイダの電子証明書を保存し、サービスプロバイダの認証を行うサービスプロバイダ認証部を備え、前記サービス連携制御部は、前記サービスプロバイダ認証部により認証されたサービスプロバイダ間でのサービス連携を可能とする点に第１０の特徴がある。
【００２３】
また、本発明の信頼性保証サーバは、さらに、サービスプロバイダのURLおよび名称を含むサービス発見情報を保存し、サービスプロバイダからの要求に応じてサービス発見情報を提供するサービス発見機能を備える点に第１１の特徴がある。
【００２４】
また、本発明のサービス連携システムは、上記第２の特徴を有する信頼性保証サーバと、前記信頼性保証サーバにネットワークを介して接続された複数のサービスプロバイダを備え、前記サービス提供元サービスプロバイダは、信頼性保証対象事業者のサービスプロバイダから電子署名と共に自サービスプロバイダが提供するサービスの利用要求を受領した場合、前記信頼性保証サーバに対して電子署名と共に信頼性保証対象事業者の信頼性問い合わせを送出し、該信頼性問い合わせに対して返された判定結果を基に、信頼性保証対象事業者のサービスプロバイダに自サービスプロバイダが提供するサービスを利用させる点に第１の特徴がある。
【００２５】
また、本発明のサービス連携システムは、上記第３または第４の特徴を有する信頼性保証サーバと、前記信頼性保証サーバにネットワークを介して接続された複数のサービスプロバイダを備え、前記サービスプロバイダは、ユーザＩＤと一対一に紐付けられたハンドルを作成し、該ハンドルを含んだ情報提供要求あるいはそれに対する応答を前記信頼性保証サーバに対して送出する点に第２の特徴がある。
【発明の効果】
【００２６】
本発明では、信頼性保証サーバが各サービスプロバイダが提供するサービスを連携させることが妥当か否かを判定し、その判定結果を提供するので、各サービスプロバイダは、他サービスプロバイダから自サービスプロバイダが提供するサービスの機能利用あるいは情報取得が要求された際、要求元サービスプロバイダに対してサービスの機能利用あるいは情報取得を許可するか否かを決定できる。これにより、各サービスプロバイダが提供するサービスを柔軟かつ安全に連携させることができる。
【００２７】
また、過去にビジネス上の繋がりのない事業者のサービスプロバイダ間においても、信頼性保証サーバが要求元サービスプロバイダの信頼性に基づいてサービスを連携させることが妥当か否かを判定し、その判定結果を要求先サービスプロバイダに提供するので、要求先サービスプロバイダは要求元サービスプロバイダの信頼性を推測することが可能となる。これにより、サービスプロバイダ間でのサービス連携の拡大が期待できる。
【００２８】
また、本発明では、信頼性保証サーバが各サービスプロバイダの事業者の信頼性に関する情報と各サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーの両者を保持し、信頼性保証サーバ側で各サービスを連携させることが妥当か否かを判定するので、サービスプロバイダ間に流通する情報を最小限にしつつ高信頼でサービスプロバイダ間でのサービス連携を図ることができる。また、サービス提供ポリシーにより、きめ細かく、例えばサービスごとに、サービス連携を可能とするか否かの制御を行うことができる。
【００２９】
さらに、本発明によれば、ユーザの匿名性を保ったまま、異なるサービスプロバイダ間におけるユーザ情報の問い合わせが可能となるため、異なる複数のサービスプロバイダ間で、ユーザ情報を連携させたサービスを提供することが安全かつ容易に実現可能となる。
【図面の簡単な説明】
【００３０】
【図１】本発明に係るサービス連携システムの第１実施形態を示すブロック構成図である。
【図２】図１のサービス連携システムの動作を示すフローチャートである。
【図３】サービス提供ポリシーDBに登録されるサービス提供ポリシーのフォーマットを示す図である。
【図４】サービス発見機能の動作を具体的に示すフローチャートである。
【図５】サービス発見応答の例を示す図である。
【図６】本発明に係るサービス連携システムの第２実施形態を示すブロック構成図である。
【図７】図６のサービス連携システムの動作を示すフローチャートである。
【図８】信頼性保証サーバ1で行われるハンドル変換を概念的に示す図である。
【発明を実施するための形態】
【００３１】
以下、図面を参照して本発明を説明する。図１は、本発明に係るサービス連携システムの第１実施形態を示すブロック構成図である。なお、以下では、本発明がサービス連携システムとして実現された実施形態を説明するが、信頼性保証サーバ単体としても１つの装置を成すものであるので、本発明は、信頼性保証サーバとして実現されたものも含む。
【００３２】
本発明のサービス連携システムは、基本的に、ネットワークを介して接続された信頼性保証サーバおよび複数のサービスプロバイダにより構築される。図１では、信頼性保証サーバ1およびA社サービスプロバイダ2およびB社サービスプロバイダ3を示している。A社は、例えばメーカであり、B社は、例えば放送事業者である。
【００３３】
信頼性保証サーバ1は、通信部11、プロバイダ認証部12、サービス連携制御部13、サービス発見機能14、サービスプロバイダ情報データベース(DB)15およびサービス提供ポリシーDB16を備える。
【００３４】
通信部11は、ネットワークを介してサービスプロバイダ2,3からのリクエストを受け、それに対する応答を返す。プロバイダ認証部12は、各ユーザの電子証明を登録し、電子証明書の認証局機能を持ち、信頼性保証サーバ1を利用させるための認証処理を行う。
【００３５】
サービス連携制御部13は、各サービスプロバイダの事業者の信頼性に関する情報および各サービスプロバイダが提供するサービスの機能利用あるいは情報取得(以下、サービスの利用と称する。)を許可する際のサービス提供ポリシーに基づいてサービスプロバイダ2,3からのリクエストに応えることが妥当か否かを判定し、その判定結果に応じた応答を送出する。
【００３６】
サービス発見機能14は、サービスプロバイダのURLおよび名称を含むサービス発見情報を保存し、サービスプロバイダからの要求に応じてサービス発見情報を提供する。
【００３７】
サービスプロバイダ情報DB15は、各サービスプロバイダの事業者の信頼性に関する情報および各サービスプロバイダが提供するサービスについての情報などの各サービスプロバイダの属性情報を格納し、サービス提供ポリシーDB16は、各サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを格納する。
【００３８】
サービスプロバイダ2,3は、サービスを相互に連携する上で対等であれば同じ構成であるが、他サービスプロバイダに自サービスプロバイダのサービスの利用を許可するだけ、あるいは他サービスプロバイダのサービスを単に利用するだけ(放送事業者)の構成のサービスプロバイダも想定される。
【００３９】
図１では、サービスプロバイダ2がサービス利用要求先、サービスプロバイダ3がサービス利用要求元である場合、すなわち、サービスプロバイダ2がサービスプロバイダ3で提供されているサービスを利用する場合の動作説明に必要な構成要素のみを図示している。
【００４０】
サービスプロバイダ2は、通信部21、リクエスト受付部22、サービス提供機能23およびアクセス制御部24を有する。
【００４１】
通信部21は、信頼性保証サーバ1および他サービスプロバイダとの通信を行う。リクエスト受付部22は、他サービスプロバイダからのサービス利用要求を受け付け、信頼性保証サーバ1に対してサービス利用要求元事業者の信頼性問い合わせを行う。サービス提供機能23は、他サービスプロバイダに対して自サービスプロバイダのサービスを提供する。アクセス制御部24は、サービス利用可の応答を返す場合、ポリシーを変更(アクセス権設定)し、一定時間、他サービスプロバイダからのサービス利用要求に含まれるドメイン名に対してアクセスを許可する。
【００４２】
サービスプロバイダ3は、通信部31、サービス連携要求部32およびサービス提供部33を有する。
【００４３】
通信部31は、信頼性保証サーバ1および他のサービスプロバイダと通信を行う。サービス連携要求部32は、サービス利用要求先サービスプロバイダに対してサービス利用要求を送出する。サービス提供部33は、ユーザからのサービス要求を受け付け、サービスを提供する。
【００４４】
次に、図１のサービス連携システムの動作を説明する。図２は、その動作を示すフローチャートである。
【００４５】
今、サービスプロバイダ2が、自社(メーカA社)の持つ製品に関する詳細情報、部品の図面を提供するサービスを持ち、そのAPIを提供しているとする。A社がこのサービスの利用を自社と連携関係にある会社または放送事業者のみに限定したいとき、事前設定の手順として、まず、A社(メーカ)は、信頼性保証サーバ1を運営する事業者（以下、プラットフォーム事業者と称する。)とその旨を契約する(S21)。この契約は、書類手続きによって行われる。同様に、B社(放送事業者)も、プラットフォーム事業者と契約する(S22)。
【００４６】
契約に伴い、A社は、プラットフォーム事業者にサービスプロバイダ情報およびサービス提供ポリシーをオンラインあるいはオフラインで提供する。プラットフォーム事業者は、自ら、A社の信頼性・正当性を確認し、サービスプロバイダ情報DB15およびサービス提供ポリシーDB16にそれぞれ、サービスプロバイダ情報およびサービス提供ポリシーを登録する。同時に、A社の電子証明書をプロバイダ認証部12に登録する。
【００４７】
同様に、B社は、プラットフォーム事業者にサービスプロバイダ情報をオンラインあるいはオフラインで提供する。プラットフォーム事業者は、自ら、B社の信頼性・正当性を確認し、サービスプロバイダ情報DB15にサービスプロバイダ情報を登録する。同時に、B社の電子証明書をプロバイダ認証部12に登録する。
【００４８】
サービスプロバイダ情報には、例えば、(1)会社名・業種などの基本情報、(2)信頼性保証サーバ1に登録された期間および参照された回数、(3)該会社を信頼しているサービスプロバイダの情報などが含まれる。(1)の基本情報には、サービスプロバイダの名称、サービスプロバイダが提供するサービスおよびその名称、サービスプロバイダのURL、サービスを公開する対象なども含まれる。
【００４９】
サービス提供ポリシーは、(1)信頼性保証サーバ1に登録されているプロバイダなら全て許可、(2)事前に登録済みの、信頼するプロバイダリストに登録されたプロバイダにのみ許可、(3)特定の業種にのみ許可、(4)過去一定期間以上信頼性保証サーバ1に登録されているプロバイダに対してのみ許可、(5)信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可(信頼関係のチェーン)、(6)一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可(信頼関係の総量)、などといった、サービスを利用許可する際の条件を記載したデータである。
【００５０】
図３は、サービス提供ポリシーDB16に登録されるサービス提供ポリシーのフォーマットを示す図である。ここで、service IDは、サービスを一意に特定するためのIDであり、Public、ProviderIDs、Categories、Periodはそれぞれ上記(1)、(2)、(3)、(4)に対応する。TrustChain、Chaindepth、TrustNnm はそれぞれ図示内容を持ち、これらにより直接の信頼関係にないサービスプロバイダでも利用許可するかどうかの条件を規定することができる。
【００５１】
また、信頼性保証サーバ1では、サービスプロバイダ情報をサービス発見機能14に反映させる。サービス発見機能14は、Webサーバとして提供され、HTTPSプロトコルの要求とそれに対応するXMLメッセージによって実現される。XMLには、個々のサービスに対して、(1)サービスプロバイダの名称、(2)サービスプロバイダが提供するサービスの名称、(3)サービスプロバイダのURL、(4)サービスを公開する対象、などの情報が含まれる。
【００５２】
放送事業者B社は、信頼性保証サーバ1に対してサービス発見要求を送出し(S24)、サービス発見応答を受ける(S25)ことにより、自社サービスプロバイダが提供するサービスに連携して提供することができるサービスの存在を知ることができる。これは、信頼性保証サーバ1のサービス発見機能14を利用することで可能となる。以上までが事前設定の手順である。
【００５３】
図４は、サービス発見機能の動作を具体的に示すフローチャートである。サービスプロバイダ3は、信頼性保証サーバ1に対してサービス発見要求(HTTPSリクエスト)を送出し(S24)、該サービス発見要求に対するサービス発見応答(HTTPSリプライ(XML))を受ける(S25)。
【００５４】
図５は、サービス発見応答の例を示す図である。本例のサービス発見応答は、サービスプロバイダの通し番号(service Provider ID)、サービスプロバイダのURL(service Provider URL)、サービスリスト(Service Lists)としてサービスの通し番号(service ID)と該サービス名(name)と該サービスにアクセスするためのURL(service Provider URL)と該サービスのアクセス方法が取得するためのURL(manual URL)を含み、サービスプロバイダ3にはこれらの情報が一覧として提供される。
【００５５】
放送事業者B社は、信頼性保証サーバ1のサービス発見機能14によって、メーカA社サービスプロバイダ2が提供する図面情報提供サービスの存在を知ることができる。放送事業者B社が、このサービスを自社サービスプロバイダ3が提供するサービスに連携させて提供したいとする場合、以下のサービスプロバイダの信頼性の問い合わせの手順が実行される。
【００５６】
まず、放送事業者B社は、自社サービスプロバイダ3のサービス連携要求部32によって、サービスプロバイダ2に対してサービス利用要求を送出する(S26)。サービス利用要求は、上述のサービス発見によって取得されたURLに対するHTTPSリクエストとして送出される。サービス利用要求には、例えば、(1)送信元のサービスプロバイダ名、(2)送信元を保証するための電子署名、(3)サービスへのアクセス元のドメイン、の情報が含まれる。
【００５７】
サービスプロバイダ2は、サービスプロバイダ3からのサービス利用要求を通信部21で受信し、リクエスト受付部22に送出する。リクエスト受付部22は、サービス利用要求を受け取ると、通信部21を介して信頼性保証サーバ1に対してサービス利用要求に含まれている電子署名を転送し、サービス利用要求元の信頼性問い合わせを行う。すなわち、信頼性保証サーバ1にサービスプロバイダ3の信頼性問い合わせを送出する(S27)。
【００５８】
信頼性保証サーバ1では、サービスプロバイダ2からの信頼性問い合わせに対して以下の処理を行う。まず、サービスプロバイダ2から転送されてきたB社の電子署名をプロバイダ認証部12によって認証する。これにより、サービスプロバイダ2がなりすましされていないかを証明できる。
【００５９】
次に、サービス連携制御部13は、サービス提供ポリシーDB16から、事前に登録されているA社のサービス提供ポリシーを取得し、また、サービスプロバイダ情報DB15に登録されているB社のサービスプロバイダ情報からB社の信頼性に関する情報を取得する。なお、サービス提供ポリシーが、信頼関係のチェーンまたは信頼関係の総量に関するもの(すなわち上記(5)または(6))である場合、サービス連携制御部13は、サービス提供ポリシーDB16に対する検索を横断的に行い、B社を信頼しているプロバイダの数や種類に関する情報を取得する。
【００６０】
以下、具体例を挙げて示す。今、サービスプロバイダ2のポリシーが、TrustChainが1、ChainDepthが2だとする。すなわち、サービスプロバイダ2は、リクエスト要求元が、自身のPoviderIDs に登録されているサービスプロバイダそのものであるか、あるいは、それらサービスプロバイダのが持つそれぞれのサービスポリシーにおいて、1社以上のPoviderIDsに登録されていれば、サービス提供を許容するというポリシーを持ち、また、ここで、ChainDepthが3だとする。この場合、サービスプロバイダ2→サービスプロバイダ2が信頼するサービスプロバイダのリスト(サービスプロバイダ群A)→サービスプロバイダ群Aのうち何れかが信頼するサービスプロバイダのリストのように、再帰的にサービスポリシーの取得を行い、B社の信頼性についての情報を収集する。
【００６１】
以上の通り、TrustChainは、自社が直接・または間接に信頼関係を構築しているサービスプロバイダにのみサービス利用を許可することを可能にする。
【００６２】
一方、TrustNnmは、自身との直接もしくは間接の信頼関係ではなく、世間の「風評」に基づいて、サービスを提供もしくは拒絶することを可能にする。
【００６３】
このTrustNumは、他のサービスプロバイダのうち何社以上から信頼されているかに基づく指標であるが、悪質なサービスプロバイダが、自身の信頼度を上げるために、架空のサービスプロバイダを複数登録させ、サービスプロバイダ間で相互に信頼関係を作ったように見せかけ、この信頼されているサービスプロバイダの数を上昇させるという懸念がある。本信頼性保証サーバは、そのような架空のサービスプロバイダは審査の段階で拒絶するが、例えば、サービスプロバイダとしての最低限の実態のみを構築して審査を追加してしまい、相互に信頼関係を作ったように見せかけるという懸念がある。そこで、本信頼性保証サーバに、サービスプロバイダを信頼している件数というだけでなく、以下に示す「信頼度」を元にして判別する仕組みを導入し、信頼性判別を行ってもよい。以下、この信頼度について記載する。
【００６４】
サービスプロバイダが信頼性保証サーバに登録する際、前述の通り、サービスプロバイダとプラットフォーム事業者の間で書類手続きによる契約が行われる。この際、プラットフォーム事業者は、得られたサービスプロバイダの情報から、各サービスプロバイダに対して、信頼性保証サーバからの信頼度を設定する。この信頼度は、例えば１〜５のような数値であり、サービスプロバイダの社会的な信頼度や実績、上場有無等に基づき、プラットフォーム事業者のポリシーに応じて設定され、信頼性保証サーバ内に保存される。信頼度は非公開の情報であり、サービスプロバイダに開示されることは無い。
【００６５】
今、サービスプロバイダAが、m社のサービスプロバイダのPoviderIDs に登録されているとする。サービスプロバイダAを信頼するサービスプロバイダn自身の、信頼性保証サーバからの信頼度をRnとするとき、サービスプロバイダAの総合的な信頼度R_Allは、以下の式で算出できる。
【００６６】
【数１】
【００６７】
但し、ここでRは、サービスプロバイダA自身が、信頼性保証サーバから付与された信頼度の値、max(A,B)は、AとBの内、大きいほうを返す関数とする。
【００６８】
サービス提供事業者は、直接繋がりの無いサービスプロバイダとの間でも、前述の信頼度R_All を参照することで、当該サービスプロバイダの信頼性を判別することが可能となる。
【００６９】
次に、サービス連携制御部13は、B社のサービスプロバイダ3に対するサービス提供の可否、すなわち、B社の信頼性に関する情報がA社のサービス提供ポリシーの条件に合っているか否かを判定し、この判定結果をサービスプロバイダ3の信頼性問い合わせ(S27)に対する応答としてサービスプロバイダ2に返す(S28)。この例では、A社のサービスプロバイダ2が提供するサービスは、放送事業者に利用許可されることになっているので、B社の信頼性に関する情報は、上記(3)のサービス提供ポリシーに合致する。
【００７０】
サービスプロバイダ2は、信頼性保証サーバ1から信頼性問い合わせ応答を通信部21で受信し、リクエスト受付部22に送出する。リクエスト受付部22は、この信頼性問い合わせ応答に基づいて、サービス利用可否をサービス利用要求(S26)の応答としてサービスプロバイダ3に返す(S29)。ここで、サービス利用可の応答を返す場合、アクセス制御部23によってポリシーを変更(アクセス権設定)し、一定時間、サービスプロバイダ3からのリクエストに含まれるドメイン名に対してアクセスを許可する。アクセス制御部23は、例えば、Webサーバのアクセス制御機能などによって実装される。
【００７１】
B社のサービスプロバイダ3は、自サービスプロバイダが提供するサービスにA社サービスプロバイダ2が提供するサービスを連携させたサービスを、サービス提供部33を通してユーザに提供することができる。以上のように、サービスプロバイダ2,3間で信頼性が確保された場合には、B社サービスプロバイダ3は、A社サービスプロバイダ2のAPIを用いてユーザにサービスを提供することが可能となる。ユーザに対するサービスの提供では、サービスプロバイダ3は、ユーザからの要求に基づいて、サービスプロバイダ2が提供するサービスにアクセスし(S30)、そのサービス応答(S31)を受けてユーザの要求に応えることができる。ここで提供されるサービスには、例えば、B社のホームページ上で、A社の提供する図面を、B社のホームページ上から参照するような、いわゆるマッシュアップと呼ばれるサービスも含まれる。
【００７２】
以上のサービスプロバイダの信頼性の問い合わせの手順(S26〜S29)を通してサービスプロバイダ2,3間で信頼性が確保されなかった場合には、信頼性保証サーバ1は、サービスプロバイダ2に対してサービスプロバイダ3の信頼性問い合わせ(S27)に対する応答(S28)と共に信頼性欠如の理由、例えば、B社を信頼しているサービスプロバイダ(事業者)の数が足りなかった、B社の電子署名が不正であった、B社は、A社が信頼するサービスプロバイダの中に入っていなかった、などの理由を送信する。
【００７３】
サービスプロバイダ2がサービスプロバイダ3に返すサービス利用要求の応答は、任意のものとすることができる。例えば、この応答として、単純に拒絶を返してもよく、サービスプロバイダ3に対して別途問い合わせを送ってもよい。
【００７４】
図６は、本発明に係るサービス連携システムの第２実施形態を示すブロック構成図である。図６において、図１と同一あるいは同等部分には同じ符号を付してある。
【００７５】
第２実施形態は、異なるサービスプロバイダ間において、情報問い合わせ先サービスにおけるユーザIDを知る必要なく、ユーザに関する情報を、信頼できるサービスプロバイダ間で相互利用することを可能としたものである。
【００７６】
これを実現するため、第１実施形態の構成に加えて、信頼性保証サーバ1は、ユーザ連携DB17、シングルサインオン部18およびユーザ連携紐付け部19を備える。
【００７７】
ユーザ連携DB17は、各ユーザに与えられる共通ユーザIDとこの共通ユーザIDに対してサービスプロバイダごとに紐付けられたハンドルを格納する。
【００７８】
シングルサインオン部18は、ユーザ連携DB17に格納されている共通ユーザIDを用いて各サービスプロバイダに対するユーザのログインを可能とする。
【００７９】
ユーザ連携紐付け部19は、サービスプロバイダからの特定ユーザの情報提供要求に対してサービスプロバイダ間で情報提供要求およびそれに対する応答を送受する際に、ユーザ連携DB17を用いてハンドルを変換する
【００８０】
サービスプロバイダ2は、ユーザID DB25を備え、サービスプロバイダ3は、ユーザID DB34を備える。
【００８１】
ユーザID DB25,34は、各サービスプロバイダ2,3におけるユーザIDを格納しており、リクエスト受付部22およびサービス連携要求部32は、ユーザID DB25,34に格納されているユーザIDと一対一に紐付けられたハンドルを作成し、このハンドルを含んだ情報提供要求あるいはそれに対する応答を信頼性保証サーバ1に対して送出する。
【００８２】
次に、図６のサービス連携システムにおける動作を説明する。図７は、その動作を示すフローチャートである。
【００８３】
今、具体例として、A社のサービスプロバイダ2が赤い羽根募金キャンペーンを行っており、B社のサービスプロバイダ3がレストラン予約サービスを提供しているものとする。
【００８４】
また、サービスプロバイダ2は、自サービスプロバイダが提供するサービスを利用するユーザのうち、どのユーザが赤い羽根募金キャンペーンに賛同しているかのユーザ情報を、DBとして持っているものとする。また、ユーザは、この赤い羽根募金キャンペーンに関する情報を他のサービスプロバイダと共有することについて、事前に同意しているものとする。
【００８５】
信頼性保証サーバ1が提供するシングルサインオン機能によって、ユーザは、共通ユーザIDでサービスプロバイダ2,3のいずれに対してもログイン可能である。なお、シングルサインオンにおいては、各サービスプロバイダが提供するサービスにログインするために、ユーザごとに与えられる共通ユーザID、各サービスプロバイダが内部的に保持するユーザIDの他に、その共通IDとユーザIDを紐付けるためのハンドルが存在する。第２実施形態では、信頼性保証サーバ1でハンドルの変換を行う。
【００８６】
事前設定は、第１実施形態と同様であり、A社の赤い羽根キャンペーンが信頼性保証サーバ1のサービス発見機能に登録される。今、B社が、サービス発見機能14によって、この赤い羽根募金キャンペーンを発見し、これと連携したサービスとして、赤い羽根募金キャンペーンに賛同したユーザに対して特別割引を行うサービスの提供を希望したとする。
【００８７】
サービスプロバイダ3のユーザが、B社の提供するレストラン予約サービスを受けるために、シングルサインオンによりサービスプロバイダ3にログインすると、サービスプロバイダ3は、ユーザIDを認証した後、該ユーザが赤い羽根募金キャンペーンに賛同しているかについて、信頼性保証サーバ1に問い合わせる。
【００８８】
この問い合わせのために、サービスプロバイダ3は、自身の電子署名と、赤い羽根募金キャンペーンを行っているA社のサービスプロバイダ2に対する情報取得要求を信頼性保証サーバ1に対して送出する。このとき、サービスプロバイダ3は、ユーザを特定するためのユーザIDをそのまま送出せず、サービスプロバイダ3のユーザID DB34に格納されたユーザIDと一対一に紐付けられたハンドルを作成し、このハンドルを含んだ情報取得要求を送出する(S71)。
【００８９】
信頼性保証サーバ1は、この情報取得要求に対する情報提供の可否の判定を行う。
この判定の動作は、第１実施形態と同様である。すなわち、まず、プロバイダ認証部12が、サービスプロバイダ3から送出されてきた電子署名を認証する。
【００９０】
次に、サービス連携制御部13が、サービス提供ポリシーDB16から、事前に登録されているA社のサービスプロバイダ2が提供するサービスを利用許可する際のサービス提供ポリシーを取得し、また、サービスプロバイダ情報DB15に登録されているB社のサービスプロバイダ情報からB社の信頼性に関する情報を取得する。なお、サービス提供ポリシーが、信頼関係のチェーンまたは信頼関係の総量に関するものである場合、サービス連携制御部13は、サービス提供ポリシーDB16に対する検索を横断的に行い、B社を信頼しているプロバイダの数や種類に関する情報を取得する。
【００９１】
次に、サービス連携制御部13が、B社のサービスプロバイダ3に対する情報提供の可否、すなわち、B社の信頼性に関する情報がA社のサービスプロバイダ2が提供するサービスを利用許可する際のサービス提供ポリシーに合っているか否かを判定する。ここで、B社の信頼性に関する情報がA社のサービスプロバイダ2が提供するサービスを利用許可する際のサービス提供ポリシーに合っていると判定されれば、サービス連携制御部13は、ユーザ連携紐付け部19によってユーザ連携DB17を検索し、要求元ユーザに対するサービスプロバイダ2のハンドルを取得し、このハンドルを含む情報取得要求をサービスプロバイダ2に対して送出する(S72)。この情報取得要求は、要求元サービスプロバイダのID(URL)も含む。情報取得要求は、例えば、HTTPSプロトコルによるGet命令に相当する。
【００９２】
サービスプロバイダ2は、信頼性保証サーバ1からの情報取得要求をリクエスト受付部22で受け付け、取得要求されたユーザ情報、すなわち、ユーザが赤い羽根募金キャンペーンに賛同しているかの情報を検索し、応答として返す(S73)。このとき、情報取得要求に対しては、アクセス制御部23によって、アクセス元IPアドレスを判別し、信頼性保証サーバ1からの要求のみを受け付ける。
【００９３】
信頼性保証サーバ1は、サービスプロバイダ2から返されたユーザ情報を情報取得要求(S71)に対する応答として直接サービスプロバイダ3に返す(S74)。第１実施形態では、サービスプロバイダ3の信頼性問い合わせに対する応答をサービスプロバイダ2に返しているが、第２実施形態の情報取得要求に対する応答は直接要求元サービスプロバイダ3に返す。
【００９４】
図８は、信頼性保証サーバ1で行われるハンドル変換を概念的に示す図である。ここでは、サービスプロバイダ2,3のURLをそれぞれ、http://servicea.com/、http://serviceb.com/とし、共通ユーザID(共通User ID)がUser1である特定ユーザに対して、ユーザID DB25,34が格納するユーザID(User ID)をそれぞれAlice、Bobとし、それに紐付けられたハンドル(User ID紐付け索引)をそれぞれ、Alicezz、123Bobとする。
【００９５】
信頼性保証サーバ1のユーザ連携DB17は、特定ユーザの共通ユーザID(共通User ID)とそれに対応するサービスプロバイダ2,3のURL(サービスプロバイダURL)とハンドル(User ID紐付け索引)を格納する。
【００９６】
サービスプロバイダ3は、特定ユーザについてサービスプロバイダ2のDBが持つ情報を知りたい場合、ハンドルAlicezzを含む情報取得要求(クエリ)を信頼性保証サーバ1に送出する(S81)。
【００９７】
信頼性保証サーバ1は、ユーザ連携DB17に格納された情報からサービスプロバイダ2に対するハンドル123Bobを取得し、ハンドルをAlicezzから123Bobに変換する。そして、ハンドル123Bobを含むクエリをサービスプロバイダ2に送出する(S82)。クエリには、アクセス元IPアドレス(信頼性保証サーバ1のIPアドレス)も含ませる。
【００９８】
サービスプロバイダ2は、リクエスト受付部22が付けたクエリが信頼性保証サーバ1からのものであることをアクセス元IPアドレスから判別し、クエリに対する応答を信頼性保証サーバ1に返す(S83)。この応答は、ハンドル123Bobおよび特定ユーザが赤い羽根募金キャンペーンに賛同しているか否かのユーザ情報(true又はfalse)を含む。
【００９９】
信頼性保証サーバ1は、サービスプロバイダ2から返された応答をクエリ(S81)に対する応答としてサービスプロバイダ3に返す(S84)。この際、ハンドルを123BobからAlicezzに変換する。この応答は、ハンドルAlicezzおよび特定ユーザが赤い羽根募金キャンペーンに賛同しているか否かのユーザ情報(true又はfalse)を含む。
【０１００】
以上の手順(S71〜S74,S81〜S84)によって、サービスプロバイダ3では、ユーザがA社の赤い羽根募金キャンペーンに賛同しているという情報を取得することができるので、サービスプロバイダ3におけるメニュー画面において、羽根募金キャンペーンに基づいた特別割引サービスを提示することが可能となる(図７(S75))。
【０１０１】
また、以上の手順では、サービスプロバイダ2,3間で直接通信を行っておらず、信頼性保証サーバ1を介在させ、かつそれぞれのハンドルを用いているので、サービス間で匿名性を保ったまま、安全にユーザに関する情報を公開することができる。さらに、信頼性保証サーバ1のサービス連携制御部13によって、各サービスプロバイダのサービス提供ポリシーを反映させ、きめ細かく、例えばサービスごとに、サービス連携を可能とするか否かの制御を行うことができる。
【０１０２】
以上、実施形態を説明したが、本発明は、上記実施形態に限定されるものではなく、種々に変形可能である。例えば、サービスプロバイダ情報DB15やサービス提供ポリシーDB16が格納する情報は、上記した情報に限られるものではなく、また、適宜変更して格納することができるものである。
【符号の説明】
【０１０３】
1・・・信頼性保証サーバ、2,3・・・サービスプロバイダ、11・・・通信部、12・・・プロバイダ認証部、13・・・サービス連携制御部、14・・・サービス発見機能、15・・・サービスプロバイダ情報DB、16・・・サービス提供ポリシーDB、17・・・ユーザ連携DB、18・・・シングルサインオン部、19・・・ユーザ連携紐付け部、21,31・・・通信部、22・・・リクエスト受付部、23・・・サービス提供機能、24・・・アクセス制御部、25,34・・・ユーザID DB、32・・・サービス連携要求部、33・・・サービス提供部
【特許請求の範囲】
【請求項１】
複数のサービスプロバイダ間で事業者間の信頼性を保証しつつ、各サービスプロバイダが提供するサービスを連携させる信頼性保証サーバであって、
各サービスプロバイダの事業者の信頼性に関する情報および各サービスプロバイダが提供するサービスについての情報を格納するサービスプロバイダ情報ＤＢと、
各サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを格納するサービス提供ポリシーＤＢと、
ネットワークを介してサービスプロバイダからリクエストを受ける通信部と、
前記通信部が受けたリクエストに対して、前記サービスプロバイダ情報ＤＢおよび前記サービス提供ポリシーＤＢから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて前記リクエストに応えることが妥当か否かを判定し、該判定結果に応じた応答を送出するサービス連携制御部を備えたことを特徴とする信頼性保証サーバ。
【請求項２】
前記通信部は、サービス提供元サービスプロバイダから信頼性保証対象事業者の信頼性問い合わせをリクエストとして受け、
前記サービス連携制御部は、前記通信部が受けた信頼性問い合わせに対して、前記サービスプロバイダ情報ＤＢおよび前記サービス提供ポリシーＤＢから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて信頼性保証対象事業者の信頼性を判定し、該判定結果を応答としてサービス提供元サービスプロバイダに返すことを特徴とする請求項１に記載の信頼性保証サーバ。
【請求項３】
さらに、各ユーザに与えられる共通ユーザＩＤと該共通ユーザＩＤに対してサービスプロバイダごとに紐付けられたハンドルを格納するユーザ連携ＤＢと、
前記共通ユーザＩＤを用いて各サービスプロバイダに対するユーザのログインを可能とするシングルサインオン部と、
サービスプロバイダからの特定ユーザの情報取得要求に対してサービスプロバイダ間で情報取得要求およびそれに対する応答を送受する際に、前記ユーザ連携ＤＢを用いてハンドルを変換するユーザ連携紐付け部を備えたことを特徴とする請求項１に記載の信頼性保証サーバ。
【請求項４】
前記通信部は、信頼性保証対象事業者のサービスプロバイダからサービス提供元サービスプロバイダの情報提供要求をリクエストとして受け、
前記サービス連携制御部は、前記通信部が受けた情報提供要求に対して、前記サービスプロバイダ情報ＤＢおよび前記サービス提供ポリシーＤＢから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて情報提供要求に応えることが妥当か否かを判定し、該判定結果によりサービス提供元サービスプロバイダから情報を取得し、該情報を応答として信頼性保証対象事業者のサービスプロバイダに返し、
前記ユーザ連携紐付け部は、信頼性保証対象事業者のサービスプロバイダ側とサービス提供元サービスプロバイダ側とでハンドルを変換することを特徴とする請求項３に記載の信頼性保証サーバ。
【請求項５】
前記サービス提供ポリシーは、サービスの利用許可のためのサービス提供ポリシーを、サービス提供ポリシーＤＢから取得し、そのポリシーと、前記サービスプロバイダ情報ＤＢに記載されたサービスプロバイダの属性情報から、サービスの利用許可を判定するものであることを特徴とする請求項１ないし４のいずれかに記載の信頼性保証サーバ。
【請求項６】
前記サービス提供ポリシーは、サービスプロバイダ情報ＤＢに格納されているプロバイダなら全て許可、事前に登録済みの、信頼するプロバイダリストに登録されたプロバイダにのみ許可、特定の業種にのみ許可、過去一定期間以上信頼性保証サーバに登録されているプロバイダに対してのみ許可、信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可、一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可、のいずれか、またはその組み合わせをサービスの利用許可の条件として規定するものであることを特徴とする請求項１ないし４のいずれかに記載の信頼性保証サーバ。
【請求項７】
前記サービス提供ポリシーとして、信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可または一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可をサービスの利用許可の条件として規定するものを含み、前記サービス連携制御部は、サービス提供ポリシーＤＢ中に含まれる、他のサービスプロバイダと、当該サービスプロバイダの関連性に関する情報を取得することを特徴とする請求項６に記載の信頼性保証サーバ。
【請求項８】
前記サービス提供ポリシーとして、一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可をサービスの利用許可の条件として規定するものを含み、前記サービス連携制御部は、サービス提供ポリシーＤＢ中に含まれる各サービスプロバイダのサービス提供ポリシーを検索し、当該サービスプロバイダを信頼しているサービスプロバイダの数を取得し、その件数が、前記サービス提供ポリシーに対して十分であるかをサービス利用許可の条件とすることを特徴とする請求項６に記載の信頼性保証サーバ。
【請求項９】
各々のサービスプロバイダに対して、信頼性保証サーバを運営する事業者として、どのくらい信頼しているかに関する独自の指標を持ち、サービス利用許可の条件は、上記独自の指標をも用いて規定されることを特徴とする、請求項６ないし８のいずれかに記載の信頼性保証サーバ。
【請求項１０】
さらに、サービスプロバイダの電子証明書を保存し、サービスプロバイダの認証を行うサービスプロバイダ認証部を備え、前記サービス連携制御部は、前記サービスプロバイダ認証部により認証されたサービスプロバイダ間でのサービス連携を可能とすることを特徴とする請求項１ないし９のいずれかに記載の信頼性保証サーバ。
【請求項１１】
さらに、サービスプロバイダのＵＲＬおよび名称を含むサービス発見情報を保存し、サービスプロバイダからの要求に応じてサービス発見情報を提供するサービス発見機能を備えることを特徴とする請求項１ないし１０のいずれかに記載の信頼性保証サーバ。
【請求項１２】
請求項２に記載の信頼性保証サーバと、
前記信頼性保証サーバにネットワークを介して接続された複数のサービスプロバイダを備え、
前記サービス提供元サービスプロバイダは、信頼性保証対象事業者のサービスプロバイダから電子署名と共に自サービスプロバイダが提供するサービスの利用要求を受領した場合、前記信頼性保証サーバに対して電子署名と共に信頼性保証対象事業者の信頼性問い合わせを送出し、該信頼性問い合わせに対して返された判定結果を基に、信頼性保証対象事業者のサービスプロバイダに自サービスプロバイダが提供するサービスを利用させることを特徴とするサービス連携システム。
【請求項１３】
請求項３または４に記載の信頼性保証サーバと、
前記信頼性保証サーバにネットワークを介して接続された複数のサービスプロバイダを備え、
前記サービスプロバイダは、ユーザＩＤと一対一に紐付けられたハンドルを作成し、該ハンドルを含んだ情報提供要求あるいはそれに対する応答を前記信頼性保証サーバに対して送出することを特徴とするサービス連携システム。
【請求項１】
複数のサービスプロバイダ間で事業者間の信頼性を保証しつつ、各サービスプロバイダが提供するサービスを連携させる信頼性保証サーバであって、
各サービスプロバイダの事業者の信頼性に関する情報および各サービスプロバイダが提供するサービスについての情報を格納するサービスプロバイダ情報ＤＢと、
各サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを格納するサービス提供ポリシーＤＢと、
ネットワークを介してサービスプロバイダからリクエストを受ける通信部と、
前記通信部が受けたリクエストに対して、前記サービスプロバイダ情報ＤＢおよび前記サービス提供ポリシーＤＢから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて前記リクエストに応えることが妥当か否かを判定し、該判定結果に応じた応答を送出するサービス連携制御部を備えたことを特徴とする信頼性保証サーバ。
【請求項２】
前記通信部は、サービス提供元サービスプロバイダから信頼性保証対象事業者の信頼性問い合わせをリクエストとして受け、
前記サービス連携制御部は、前記通信部が受けた信頼性問い合わせに対して、前記サービスプロバイダ情報ＤＢおよび前記サービス提供ポリシーＤＢから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて信頼性保証対象事業者の信頼性を判定し、該判定結果を応答としてサービス提供元サービスプロバイダに返すことを特徴とする請求項１に記載の信頼性保証サーバ。
【請求項３】
さらに、各ユーザに与えられる共通ユーザＩＤと該共通ユーザＩＤに対してサービスプロバイダごとに紐付けられたハンドルを格納するユーザ連携ＤＢと、
前記共通ユーザＩＤを用いて各サービスプロバイダに対するユーザのログインを可能とするシングルサインオン部と、
サービスプロバイダからの特定ユーザの情報取得要求に対してサービスプロバイダ間で情報取得要求およびそれに対する応答を送受する際に、前記ユーザ連携ＤＢを用いてハンドルを変換するユーザ連携紐付け部を備えたことを特徴とする請求項１に記載の信頼性保証サーバ。
【請求項４】
前記通信部は、信頼性保証対象事業者のサービスプロバイダからサービス提供元サービスプロバイダの情報提供要求をリクエストとして受け、
前記サービス連携制御部は、前記通信部が受けた情報提供要求に対して、前記サービスプロバイダ情報ＤＢおよび前記サービス提供ポリシーＤＢから、信頼性保証対象事業者の信頼性に関する情報およびサービス提供元サービスプロバイダが提供するサービスを利用許可する際のサービス提供ポリシーを取得し、これにより取得された情報およびサービス提供ポリシーに基づいて情報提供要求に応えることが妥当か否かを判定し、該判定結果によりサービス提供元サービスプロバイダから情報を取得し、該情報を応答として信頼性保証対象事業者のサービスプロバイダに返し、
前記ユーザ連携紐付け部は、信頼性保証対象事業者のサービスプロバイダ側とサービス提供元サービスプロバイダ側とでハンドルを変換することを特徴とする請求項３に記載の信頼性保証サーバ。
【請求項５】
前記サービス提供ポリシーは、サービスの利用許可のためのサービス提供ポリシーを、サービス提供ポリシーＤＢから取得し、そのポリシーと、前記サービスプロバイダ情報ＤＢに記載されたサービスプロバイダの属性情報から、サービスの利用許可を判定するものであることを特徴とする請求項１ないし４のいずれかに記載の信頼性保証サーバ。
【請求項６】
前記サービス提供ポリシーは、サービスプロバイダ情報ＤＢに格納されているプロバイダなら全て許可、事前に登録済みの、信頼するプロバイダリストに登録されたプロバイダにのみ許可、特定の業種にのみ許可、過去一定期間以上信頼性保証サーバに登録されているプロバイダに対してのみ許可、信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可、一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可、のいずれか、またはその組み合わせをサービスの利用許可の条件として規定するものであることを特徴とする請求項１ないし４のいずれかに記載の信頼性保証サーバ。
【請求項７】
前記サービス提供ポリシーとして、信頼するプロバイダリスト中のプロバイダから信頼関係のあるプロバイダに対してのみ許可または一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可をサービスの利用許可の条件として規定するものを含み、前記サービス連携制御部は、サービス提供ポリシーＤＢ中に含まれる、他のサービスプロバイダと、当該サービスプロバイダの関連性に関する情報を取得することを特徴とする請求項６に記載の信頼性保証サーバ。
【請求項８】
前記サービス提供ポリシーとして、一定の種類以上のサービスプロバイダから信頼されているプロバイダに対して許可をサービスの利用許可の条件として規定するものを含み、前記サービス連携制御部は、サービス提供ポリシーＤＢ中に含まれる各サービスプロバイダのサービス提供ポリシーを検索し、当該サービスプロバイダを信頼しているサービスプロバイダの数を取得し、その件数が、前記サービス提供ポリシーに対して十分であるかをサービス利用許可の条件とすることを特徴とする請求項６に記載の信頼性保証サーバ。
【請求項９】
各々のサービスプロバイダに対して、信頼性保証サーバを運営する事業者として、どのくらい信頼しているかに関する独自の指標を持ち、サービス利用許可の条件は、上記独自の指標をも用いて規定されることを特徴とする、請求項６ないし８のいずれかに記載の信頼性保証サーバ。
【請求項１０】
さらに、サービスプロバイダの電子証明書を保存し、サービスプロバイダの認証を行うサービスプロバイダ認証部を備え、前記サービス連携制御部は、前記サービスプロバイダ認証部により認証されたサービスプロバイダ間でのサービス連携を可能とすることを特徴とする請求項１ないし９のいずれかに記載の信頼性保証サーバ。
【請求項１１】
さらに、サービスプロバイダのＵＲＬおよび名称を含むサービス発見情報を保存し、サービスプロバイダからの要求に応じてサービス発見情報を提供するサービス発見機能を備えることを特徴とする請求項１ないし１０のいずれかに記載の信頼性保証サーバ。
【請求項１２】
請求項２に記載の信頼性保証サーバと、
前記信頼性保証サーバにネットワークを介して接続された複数のサービスプロバイダを備え、
前記サービス提供元サービスプロバイダは、信頼性保証対象事業者のサービスプロバイダから電子署名と共に自サービスプロバイダが提供するサービスの利用要求を受領した場合、前記信頼性保証サーバに対して電子署名と共に信頼性保証対象事業者の信頼性問い合わせを送出し、該信頼性問い合わせに対して返された判定結果を基に、信頼性保証対象事業者のサービスプロバイダに自サービスプロバイダが提供するサービスを利用させることを特徴とするサービス連携システム。
【請求項１３】
請求項３または４に記載の信頼性保証サーバと、
前記信頼性保証サーバにネットワークを介して接続された複数のサービスプロバイダを備え、
前記サービスプロバイダは、ユーザＩＤと一対一に紐付けられたハンドルを作成し、該ハンドルを含んだ情報提供要求あるいはそれに対する応答を前記信頼性保証サーバに対して送出することを特徴とするサービス連携システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１０−２２５０７４（Ｐ２０１０−２２５０７４Ａ）
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願番号】特願２００９−７４１２４（Ｐ２００９−７４１２４）
【出願日】平成２１年３月２５日（２００９．３．２５）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２０年度、独立行政法人情報通信研究機構「高度通信・放送研究開発委託研究／端末プラットフォーム技術に関する研究開発」、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（５９９１０８２６４）株式会社ＫＤＤＩ研究所 (233)
【Ｆターム（参考）】
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願日】平成２１年３月２５日（２００９．３．２５）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２０年度、独立行政法人情報通信研究機構「高度通信・放送研究開発委託研究／端末プラットフォーム技術に関する研究開発」、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（５９９１０８２６４）株式会社ＫＤＤＩ研究所 (233)
【Ｆターム（参考）】
[ Back to top ]