JP4881615B2 - 電子機器の認証についての識別管理システム - Google Patents

Description

本発明は、電子機器の認証についての識別管理システムに関する。

電子機器から要求されるサービスを提供し、提供したサービスに対する決済の手続を行うサービス提供システムが存在する（例えば、特許文献１参照。）。このようなサービス提供システムでは、通常、垂直統合と呼ばれる運営管理の形態が用いられていることが多い。すなわち、サービス提供システムの運営者は、電子機器を認証するための判定サーバを管理し、また、電子機器にサービスを提供するサービス提供事業者は、サービス提供システムの運営者と契約を結び、判定サーバにより正当性などを判定された電子機器にのみサービスを提供する。このような運営管理の形態により、サービス提供システムの運営者の管理する判定サーバにて認証などの処理を経て正当性を判定された電子機器にのみサービスを提供することができるので、サービス提供システムの運営者にとっては、電子機器の所持者からサービス提供の対価の徴収を確実に行うことができ、また、サービス提供者にとっては、サービス提供システムの運営者にサービス提供の対価の徴収を代行してもらうことができるというメリットがある。

そして、このような垂直統合型のサービス内においては、例えば、子供の所有する電子機器に対するサービスの対価の支払いを、親の所有する電子機器に対して要求することも可能となっている。つまり、子供の所有する電子機器と親の所有する電子機器とは、同一のサービス提供システム内に存在しているために、契約などにて同意した場合には、判定サーバにてその課金を要求可能に設定することで、子供が所有する電子機器が利用したサービスについての対価の支払いを、親の所有する電子機器の支払いと併せて決済することが可能となっている。
特開２００４−２２７０５５号公報

しかしながら、従来の垂直統合型のシステムにおいては、サービス提供の対価の徴収のための決済の認証が、同一のサービス提供システム内の機器ごとにしか行なわれないため、例えば、他の利用者の所有する他のサービス提供システム内の電子機器にて契約しているクレジットカード会社や銀行口座を介して支払を行いたい場合に対応できず、電子機器の利用者にとって不都合が生じていた。

そこで、本発明は、かかる課題に鑑みてなされたものであり、異なる利用者が利用する複数のサービス体系を横断的に利用可能とする識別管理システムを提供することを目的とする。

そこで、本発明は、かかる課題を解決するために、第一利用者が利用する第一電子機器からの第二判定サーバの利用要求に基づいて第一判定サーバから出力される保証要求を受けた識別管理サーバにて、第一利用者と第二利用者が主従関係を有するかの検索を行い、第一利用者は第二利用者のサービスを利用することが可能であることを示す保証を出力するシステムを提供する。第一判定サーバは、この保証に基づいて保証付サービス依頼を第二判定サーバに対して出力することができる。

また、第一利用者が利用する第一電子機器からの第二判定サーバの利用要求に基づいて第一判定サーバから保証要求付サービス依頼を受けた識別管理サーバにて、第一利用者と第二利用者が主従関係を有するかの検索を行い、その検索に基づいて、保証付サービス依頼を識別管理サーバ自身が第二判定サーバに対して出力してもよい。

また、第一利用者が利用する第一電子機器からの第二判定サーバの利用要求に基づいて、第一判定サーバからサービス依頼を受けた第二判定サーバが保証要求を識別管理サーバに対して出力するとしてもよい。これを受けて、識別管理サーバにて、第一利用者と第二利用者とが主従関係を有するかの検索を行い、その検索結果に基づいて第二判定サーバに対して保証を出力するとしてもよい。

また第一判定サーバは、識別管理サーバからその第一利用者の主従関係に関する情報を保証に含めて受信し、どの第二利用者のサービス依頼をするかを第一利用者に選択させた後に、第二判定サーバに対して第一判定サーバから保証付サービス依頼を出力してもよい。

以上のような構成により、複数のサービス体系に跨る別々の利用者についての主従関係を、それぞれの利用者の唯一性とともに識別可能とした。これにより、第一の利用者が利用する第一の電子機器が第一のサービス体系に縛られていた現状を打破し、サービス体系の垣根を取り払うことが可能となる。つまり、一の電子機器が垣根を越えて他の利用者が利用する複数のサービス体系を横断的に利用可能となる。

以下、本発明を実施するための最良の形態について、実施形態として説明する。なお、本発明はこれら実施形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において種々なる態様で実施し得る。

なお、特許請求の範囲に挙げられた請求項と以下に説明する実施形態との関係は次の通りとなる。実施形態１は、主に請求項１、２に関する。実施形態２は、主に請求項３、４に関する。実施形態３は、主に請求項５、６に関する。実施形態４は、主に請求項７に関する。

<<実施形態１>>
<実施形態１：概要>
実施形態１は、サービスサーバ群と、電子機器と、判定サーバと、識別管理サーバと、からなるシステムである。垂直統合の運営管理の形態ごとに第一利用者が利用する第一電子機器、第一サービスサーバ群、第一判定サーバとからなる第一のサービス提供システムと、第二利用者が利用する第二電子機器、第二サービスサーバ群、第二判定サーバとからなる第二のサービス提供システムとがある。図１は、従来におけるシステムの一例を示す。図１の従来におけるシステムにおいては、利用者Aが利用者Bの享受しているサービスを利用しようとして第一判定サーバを介して第二判定サーバに対して利用要求を行った場合には、各サービス体系における識別方法が異なっているため、第二判定サーバにおいては、利用者B（ｕｓｅｒＩＤ：ｍｏｍｏ）には確かにサービスを提供しているが、利用者Ａ（ｕｓｅｒＩＤ：ｓａｋｕｒａ）が利用者Ｂの利用権限を有しているかについては、第二判定サーバでは判断することはできず、結果として、利用者Ａは、利用者Ｂの利用しているサービスの提供を受けることができないという問題が生じていた。一方、図２は、かかる問題を解決する本発明の概念を示す図である。図２で示す例においては、図１で示した構成に加えて、第一のサービス提供システムからアクセスが可能な識別管理サーバを有している。図２の識別管理サーバには、主従関係情報が管理されている。本発明はこの主従関係情報を利用することによって、垂直統合型のシステムの垣根を取り払い、他の利用者が利用する垂直統合型のシステムにおける他のサービスを横断的に利用することを実現したものである。

「主従関係情報」とは、第一利用者と第二利用者との相対的関係を示す情報のことであり、一方の「従」の利用者（例えば第一の利用者）は他方の「主」の利用者（例えば第二の利用者）のサービス等を利用することが可能な関係を示す情報のことである。具体的には家族における親と子の関係や、会社における経営者と従業員の関係などが挙げられる。なお、これらの主従関係情報は、必ずしも経済的・社会的な関係に基づいていなくてもよい。例えば、友人同士を主従関係を有するものとすることももちろん可能である。なお、主従関係は、必ずしも自然人同士の関係でなくてもよい。例えば会社（法人）と従業員（自然人）との関係についても、主従関係を有しているものとして扱ってもよい。

図３は、主従関係情報にて示される主従関係についての一例を示した図である。図３（ａ）では、父（Ａ）の利用するサービスを母（Ｂ）及び子（Ｃ）が利用可能な状態を示している。図３（ｂ）では、父（Ａ）及び母（Ｂ）の利用するサービスを子（Ｃ）が利用可能な状態を示している。なお、主従関係とはこれら家族間の関係の他にも例が挙げられる。例えば、図３（ｃ）から（ｅ）に示すように、友人同士や、あるいは教師と生徒との関係も主従関係の一例に含まれるし、また、経営者や従業員の関係なども主従関係の一例に含まれる。なお、図３の例は、各図の右に示した人（従）が、左に示した人（主）のサービスを利用可能な状態であるとして説明を行ったが、逆に、左に示した人（主）が右に示した人（従）のサービスを利用可能な状態であるとしてもよい。例えば、父（Ａ）が子（Ｃ）の利用している他社の携帯電話の通話記録などを照会することも、本発明を利用することによって可能となる。

また、図３（ｅ）の具体的な例としては、従業員（従）が経営者（主）の有する決裁権の委譲依頼を行う場合が挙げられる。なお、ここでいう決裁権とは、電子署名のようなものを想定しており、この決裁権を付することにより、その社内システムでの決裁が可能になるというものである。ここで、例えば経営者が急な出張などで決裁権を委譲せずに長期的に不在等となってしまった場合を例に説明する。この場合には、従業員としては社内システムにおいて決裁が不可能となってしまうために業務が著しく滞ってしまうが、本発明を利用することで、かかる不備を解消できる。即ち、従業員の属する社内システムＡから、例えば決裁権を暫定的に発行可能なサービスサーバが属する他のシステムＢに対して決裁権の委譲依頼を行うと、本発明においては、社内システムＡからの依頼を、当該他のシステムＢでは正当なものと判断して、当該他のシステムＢに属する経営者の端末に対して委譲確認を行う。そして、経営者からの許可が出た場合には、暫定的に決裁権を発行するサービスサーバから従業員の属する社内システムＡに属する端末に対して決裁権が送られることになる。このように、不測の事態が発生した場合であっても本発明を利用することで、その損失を最小限に止めることも可能となる。

図４は、実施形態１の概要を示した図である。図４における大まかな処理の流れは下記の通りである。なお、各用語の示す意味などについては後の部分にて説明を行う。（１）利用者Aが利用する第一電子機器から第一判定サーバに対して利用者Bの共通識別情報を含む第二判定サーバの利用要求を行う。なお、この利用要求は、第一判定サーバに対して要求してもよいし、第一サービスサーバ群を経由して要求してもよい。（２）利用要求を受けた第一判定サーバは、識別管理サーバに対して、第一保証要求を行う。（３）第一保証要求を受けた識別管理サーバにおいては、その第一保証要求に含まれている利用者Aと利用者Bの共通識別情報に基づく主従関係情報に基づいて第一保証を出力する。（４）第一保証を受信した第一判定サーバは、保証付サービス依頼を第二判定サーバに対して出力する。このようにして保証付サービス依頼を受信した第二判定サーバは、そのサービス依頼が正当なものであるとして、その依頼に応じたサービスの提供を第一電子機器に対して行ったりすることができる。

このように、本実施形態は、第一電子機器からの第二判定サーバの利用要求に基づいて、第一判定サーバが第一保証要求を出力し、それを受けた識別管理サーバは、識別管理部の検索を行い、その検索結果に基づいて保証を出力する点に特徴がある。

<実施形態１：構成>
図５は、実施形態１に係るシステムの機能ブロック図を例示する。実施形態１は、第一判定に基づいて第一サービスを第一電子機器（５０１）に行う「第一サービスサーバ群」（５０２）と、第二判定に基づいて第二サービスを第二電子機器（５０３）に行う「第二サービスサーバ群」（５０４）と、第一利用者が利用し、第一サービスサーバ群（５０２）から第一サービスを受ける「第一電子機器」（５０１）と、第二利用者が利用し、第二サービスサーバ群（５０４）から第二サービスを受ける「第二電子機器」（５０３）と、第一サービスサーバ群（５０２）から前記第一サービスを受けるために、第一電子機器（５０１）を第一電子機器識別情報に基づいて第一判定する「第一判定サーバ」（５１０）と、第二サービスサーバ群（５０４）から前記第二サービスを受けるために、第二電子機器（５０３）を第二電子機器識別情報に基づいて第二判定する「第二判定サーバ」（５２０）と、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を識別管理部（５３１）にて管理する「識別管理サーバ」（５３０）とからなるシステム（５００）である。

なお、「第一判定」、「第二判定」とは、それぞれ、第一判定サーバ（５１０）、第二判定サーバ（５２０）が、第一電子機器（５０１）、第二電子機器（５０３）の提供する電子機器識別情報が第一サービスや第二サービスを受けるのに正当なものなどであるかどうかについて行う判定をいう。「電子機器識別情報」とは、電子機器を一意に識別するための情報である。例えば、電子機器の製造番号である。製造番号は、電子機器を識別したメーカーを識別する部分とそのメーカーでの製造の番号を示す部分からなっていてもよい。また、電子機器が携帯電話である場合には、その電話番号や、携帯電話網での携帯電話を一意に識別する番号などが電子機器識別情報となる。また、電子機器識別情報には、利用者を識別する情報が含まれていてもよい。電子機器識別情報は、通常、電子機器に固有に付与される情報であり、改ざんが困難な情報である。このため、電子機器識別情報を利用する場合には、高い信頼性を有しているため、各サービス体系内においてはこの電子機器識別情報を用いて各種のサービスを利用することができるようになっている。なお、電子機器識別情報は電子機器の耐タンパ領域に保持されていてもよい。「第一サービス」、「第二サービス」は、それぞれ、第一サービスサーバ群（５０２）、第二サービスサーバ群（５０４）が、電子機器に提供するサービスをいう。例えば、インターネットのウェブページなどのコンテンツの閲覧や、第一サービスサーバ群（５０２）や第二サービスサーバ群（５０４）などが管理するコンテンツの閲覧や、コンテンツのダウンロード、メールの送受信などの通信を利用させることなどをいう。また、サービスは単一のものである必要はなく、複数の項目などからなる場合もあってよい。「第一サービスサーバ群」、「第二サービスサーバ群」と「群」の文字があるが、これは、サービスの項目などに応じて、サーバが複数になることが想定されているからである。また、単一のサーバ装置により、第一サービスサーバ群、第二サービスサーバ群が構成されていてもよい。なお、第一電子機器識別情報、第二電子機器識別情報とは、それぞれ、第一電子機器（５０１）、第二電子機器（５０３）の電子機器識別情報である。また、「第一利用者」、「第二利用者」とは、それぞれ、第一電子機器（５０１）、第二電子機器（５０３）を利用する者であり、同一の利用者を示すものではない。

なお、本明細書を通じて、同じ意味の言葉には、基本的に同じ標記の言葉を用いることにする。ただし、図面を参照する際の符号は異なる場合がある。

図６は、識別管理サーバ（５３０）の有する識別管理部（５３１）が記憶管理などする情報の一例を示す。図６では、そのような情報はテーブルに格納された形式で表現されている。識別管理部（５３１）は、上述のように、共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理する。共通識別情報とは、システム内で利用者を一意に識別する情報のことである。この共通識別情報は、本発明の目的とする複数のサービスの横断的利用をする際に必要となる概念である。つまり、複数のサービスにおいては、垂直統合型のサービス体系がそれぞれ構成されているが、各サービス体系にて使用する識別情報はそれぞれのサービス体系によって異なっているものであるからである。例えば、一のサービス体系においては、そのサービス体系に属する電子機器の電子機器識別情報を識別情報として利用しているが、他のサービス体系においては、当該他のサービス体系に見合う別異の電子機器識別情報を識別情報として利用しているものである。このため、複数のサービスの横断的使用をする場合には、システム内にて一意にその利用者を識別できる情報が必要になる。このため、共通識別情報が識別管理部にて管理されており、そして、このような共通識別情報に基づいて主従関係情報が識別管理部にて管理されている。

図６では、共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理するために、共通識別情報ごとにテーブルの行を用意して、同じ行に「主」となる利用者の共通識別情報と「従」となる利用者の共通識別情報を格納することにより、その「従」となる共通識別情報で識別される利用者が、その「主」となる共通識別情報で識別される利用者の属するサービスを利用可能であることを示している。例えば、図６において、ｓａｋｕｒａで識別される利用者は、ｍｏｍｏで識別される利用者の利用する電子機器が受けるサービスを利用することができることを示している。

なお、「従」となる利用者が「主」となる利用者となることももちろん可能である。図６では、ｈａｎａｋｏで識別される利用者は、ｍｏｍｏで識別される利用者との関係においては「従」となるが、一方で、ｔａｒｏで示される利用者との関係においては「主」となる。このように、主従関係とは、利用者同士の相対的な関係に応じて定まる関係である。主従関係情報を識別管理サーバに登録する方法としては、例えば、各判定サーバを通じて主従関係情報を登録することが挙げられる。また、主従関係情報を登録する場合には、「主」となる共通識別情報を登録する要求を行った判定サーバに対して、識別管理サーバから確認要求などをその判定サーバに対して行い、その正当性を確認した場合にのみ、主従関係情報として、その「主」となる共通識別情報を取り扱うとしてもよい。なお、図面を含む本明細書においては、共通識別情報の一例として、例えば「ｕｓｅｒＩＤ：ｍｏｍｏ」と表記している箇所や、単に「ｍｏｍｏ」と表記している部分が混在しているが、特に差異はなく、両者は同一の共通識別情報を示しているものとする。

（実施形態１：第一判定サーバの構成）
第一判定サーバは、第一電子機器が第一サービスサーバ群から第一サービスの提供を受けるために第一電子機器識別情報に基づいて第一判定する。「第一電子機器識別情報」とは、既に説明したように、第一電子機器を、少なくとも第一サービスサーバ群と第一判定サーバとの範囲内にて一意に識別するための情報である。ただし、第一電子機器そのものではなく、第一電子機器を介して第一サービスの提供を受ける限りの意味における利用者を識別するためのユーザ識別情報であってもよい。つまり、第一電子機器識別情報は、第一電子機器がサービスの提供を受けるのに適切な電子機器であるか否かを第一判定サーバが判断するために通常利用する識別情報であり、一般的には第一サービスの提供をうけるために固有に築かれたシステム用の識別情報である。例えば、課金処理サーバと、これを利用して課金処理を行なう複数のサービス提供のためのサービスサーバ群からなる固有のシステム（以下、これを「システムＸ」という。）内で利用する識別情報が該当する。第一判定サーバは、固有の垂直統合型のサービス体系を実現するためには原則として第一電子機器識別情報に基づいて、第一電子機器が第一サービスサーバ群から第一サービスを受けることができるかどうかの第一判定を行う。この判定処理は、第一電子機器が自身の第一電子機器識別情報を第一判定サーバに対して送信することにより、第一サービスの提供を要求する場合に行われる。既に説明したように、第一電子機器識別情報は、各電子機器に対して固有に付与される情報であり、通常、改ざんすることができない状態で保存されている情報である。このような第一電子機器識別情報に基づくことで、システムＸ内では、信頼性の高いシステム内固有の第一電子機器に対して第一サービスが提供されていることになる。ところが、これらの処理は、第一サービス関連システム内にとどまった処理であり、第一サービスシステム体系内の固有処理である（だからこそ第一電子機器の信頼性が高まっている）。本件発明は、このような、固有システム内の垂直的サービスを越えた固有システム間の横断的利用を提供するためのものである。

図５で示すように、第一判定サーバ（５１０）は、第一関連保持部（５１１）と、第一保証要求出力部（５１２）と、第一保証受信部（５１３）と、保証付サービス依頼出力部（５１４）とを有する。

「第一関連保持部」（５１１）は、第一利用者の共通識別情報と、第一電子機器識別情報とを関連付けて保持する。例えば、第一利用者の共通識別情報の値を格納する列と第一電子機器識別情報の値を格納する列とからなるテーブルを記憶手段に保持する。そのテーブルの同じ行に、共通識別情報の値と第一電子機器識別情報の値とを格納することにより、その共通識別情報で識別される利用者が、その第一電子機器識別情報で識別される電子機器を使用することが表現される。「共通識別情報」とは、利用者を本システム内にて一意に識別するための情報である。本来、前記例でいうところのシステムＸが構築された時点では共通識別情報なるものを利用する必要はないのであるが、本件発明の目指す異なるサービス体系の横断的利用のために、例えば後発的に固有システム内に共通する概念情報を導入する必要がある。つまり、固有システム（例えば第一サービス体系）を構築後、他の固有システム（例えば、第二サービス体系）との間で横断的に異なる利用者間におけるサービスの利用（例えば、第一判定サーバと、他人が利用する第二判定サーバとを一の電子機器により利用すること）を促進すべく第一に導入される概念情報が共通識別情報である。この共通識別情報は、一般的には、電子機器を所有する利用者の発意に応じて判定サーバに対して付与されることが想定される。共通識別情報が判定サーバに対して与えられるための流通経路は各種考えられ、一に限定されるものではない。もちろん、この説明は一例であって、固有のサービス体系を実現するシステムを構築する際に予め固有の識別情報体系である機器識別情報とともに共通識別情報を利用するように設計することも可能である。

共通識別情報について、さらに説明を行う。まず、利用者が第一のサービスと、第二のサービスを受ける際の識別情報としては、第一電子機器識別情報と、第二電子機器識別情報という異なる識別情報を利用する。これらは異なるサービス体系における固有の識別情報であるため、通常、利用者が同一人であるか別人であるかを問わず、別異の識別情報となる。従って、例えば、第二判定サーバでは、第一利用者が利用する第一電子機器の第一電子機器識別情報に基づいて、第一利用者と異なる利用者である第二利用者が利用する第二電子機器が享受している第二サービスを、その第一電子機器に対して提供してもよい、と判定することはできない。しかし、本システムの恩恵（即ち異なるサービス体系間の横断的利用）を受けるために利用される共通識別情報で識別すれば、第一利用者、第二利用者の本システムにおける唯一性が保証されるため、各利用者を一意に識別することが可能となる。そして、後述するように識別管理サーバにてその共通識別情報に基づく主従関係の正当性を調べて、その結果を保証として付した要求を第二判定サーバに対して出力することで、例えば第一利用者が第二利用者の第二電子機器にて利用する第二サービスを受けることが可能となる。

図７は、第一関連保持部（５１１）が保持するテーブルを例示する。ｓａｋｕｒａで識別される第一利用者が、ｄｅｖｉｃｅ−ＡＢＣで識別される第一電子機器を使用すること等が例として表現されている。

「第一保証要求出力部」（５１２）は、第一電子機器からの第二利用者の共通識別情報を含む第二判定サーバの利用要求に基づいて、第一利用者及び第二利用者の共通識別情報を含む第一保証要求を出力する。第一保証要求の出力先は、識別管理サーバである。第一保証要求出力部による第一保証要求の出力の処理は、本件発明の目指す異なるサービスシステム間の横断的利用のために第一判定サーバから外部に対して最初に行なわれる処理である。第二判定サーバの利用要求としては、第二判定サーバを介して第一サービスの利用料を支払うことを要求するために、第一電子機器が送信する場合がある。本来第一利用者の利用する第一電子機器は第一サービスシステム内でのみサービスの提供を受けることが出来たのであるが、その壁を破って他のサービスシステムにおいても所定のサービスを受けようとするためのものである。本件発明の場合には特に第二判定サーバの利用を目的としている。さらに具体的には、第一利用者と異なる利用者である第二利用者が利用する第二電子機器にてダウンロードした暗号化コンテンツ等を第一利用者が利用する第一電子機器においても利用可能とするために第二判定サーバを介して復号鍵を取得することの要求や、第二電子機器にてダウンロードした個人情報等（スケジュール、カルテなど）を第一電子機器においても閲覧可能とするために第二判定サーバを介してパスワードを取得することの要求などが該当する。また、第二電子機器において行われている課金サービスを利用して、第一電子機器の決済を行うことの要求が該当する。繰り返せば、これらの処理は本来第一電子機器が享受することが不可能であった処理である。なぜなら第一電子機器は第一サービスシステム体系内にてサービスを受けられるのに対して、これらの処理は、第二サービスシステム体系内で第二電子機器のみしか享受することが出来ない処理だったからである。また、第一利用者が、自身と異なる利用者である第二利用者の受けているサービスを横断的に利用することは、セキュリティ等の観点から、実現させることは困難であったからである。

図８は、利用要求の一例を示す。第一利用者が、その所有あるいは占有、管理する電子機器であって、ｄｅｖｉｃｅ−ＡＢＣで識別される電子機器を介して、第二判定サーバの利用を要求することが表わされている。そして、第二判定サーバの利用として、第二利用者の利用する電子機器（第一利用者は必ずしもその電子機器（第二電子機器）を特定してなくてもよい）が享受している第二サービス（図８の例では、課金サービス）を利用すべく、第二利用者の共通識別情報ｍｏｍｏが第二判定サーバの利用要求に含まれている。この第二利用者の共通識別情報は、第一利用者が第一電子機器を通じて入力することで第一電子機器からの利用要求に含まれる情報となる。なお、第二利用者の共通識別情報は、第一利用者が手入力などで第一電子機器に入力することも可能であるし、あるいは第二利用者の共通識別情報を記憶したメモリカード等を第一電子機器に対して挿入することで、第一電子機器に入力することも可能であるし、通信などを介して第一電子機器が取得することも可能である。また、第二利用者の共通識別情報は、一の利用者の共通識別情報に限られることはない。例えば、複数の利用者の共通識別情報を利用要求に含めることも可能である。なお、図８には示されていないが、利用要求には、その他第二判定サーバの利用の種類、第二判定サーバの指定、第二サービスサーバ群のサーバの指定、第二サービスサーバ群により提供されるサービスの指定、サービスの提供の対価の課金方法などの付加的な情報が含まれていてもよい。また、これらの付加的な情報は、第一保証要求と関連づけられて第一保証要求出力部（５１２）に出力されるようになっていてもよい。

図９は、図８で示した第二判定サーバの利用要求に基づいて、第一判定サーバの第一保証要求出力部から出力される第一保証要求の一例を示す。図９においては、第一利用者の共通識別情報ｓａｋｕｒａが含まれている。これは、第一関連保持部（５１１）にて第一電子機器識別情報と、第一利用者の共通識別情報を関連付けて保持しているため、例えば、利用要求を要求した第一電子機器の電子機器識別情報をキーとして第一関連保持部を検索するなどして、その第一電子機器の利用者（つまり、第一利用者）の共通識別情報を取得することができるからである。なお、利用要求に第一電子機器識別情報が含まれていない場合であっても、同一セッション中ではセッション開始時の第一電子機器識別情報を用いることができ、その他、サーバから発行されるクッキーから第一電子機器識別情報を抽出するとしてもよい。検索後、共通識別情報が保持されている場合にはこれを取得し、第一保証要求に含めて、識別管理サーバに対して出力する。

なお、図９で示すように、第二利用者の共通識別情報については、利用要求にて含まれていた共通識別情報であることに起因して、主従関係を有しているかを確認すべき対象である旨が第一保証要求に含まれてもよい。また、第一保証要求は、第一利用者及び第二利用者の共通識別情報（図で示した例では、ｓａｋｕｒａ、ｍｏｍｏ）を含むが、上述したようにその他、第二判定サーバを識別するための情報などの付加的な情報を含んでいてもよい。

第一保証要求は、識別管理サーバから共通識別情報で識別される第一利用者及び第二利用者が唯一存在することの保証と、これらの利用者の主従関係を示す情報に基づく保証を得るために出力されるものである。つまり、本システムにおいては、第一利用者が、異なるサービス体系に属する第二利用者の享受している第二サービスを受けることを可能にすることを目的としているものであるが、第二判定サーバにとってみると、真に第二サービスを受けてもよい第一利用者であるかを判断することは、非常に困難である。しかしながら、本発明で利用する共通識別情報を利用することで、利用者の唯一性が保証される。そして、その唯一性が保証されている第一の利用者が、同じく唯一性を保証されている第二の利用者と主従関係を有していることが識別管理サーバにて識別されることで、その第一利用者と第二利用者とが真に主従関係を有していることの証明を行うことが可能となる。そして、識別管理サーバにてその第一利用者と第二利用者との主従関係が確認された場合（一例としては、第一利用者は、第二利用者との関係において「従」の関係であるため、第一利用者は第二利用者のサービス等を享受できる場合）には、その保証を受信した第二判定サーバは、第二サービスを第一利用者が受けることが可能であることを判断することができる。

なお、第一判定サーバは、第一関連保持部にて、第一利用者の共通識別情報と第一電子器機器識別情報とを関連付けて保持しているため、例えば、第一電子機器からの利用要求に対しては、自身が保持している情報を検索等した結果抽出された第一利用者の共通識別情報を識別管理サーバへの第一保証要求に含めることができる。しかしながら、第一判定サーバにおいては、第二利用者の共通識別情報については保持していないため、その真偽を確認することができない。つまり、第一利用者の共通識別情報と異なり、第二利用者の共通識別情報については、いわば第一利用者からの任意的な入力等によって第一電子機器から送られる情報であるため、その第二利用者の共通識別情報が誤情報である可能性も考えられる。しかしながら、第一判定サーバでは、自身の属する固有にシステム内における第一電子機器からの情報である、という点を信頼して、第二利用者の共通識別情報を第一保証要求に含めて、その真偽については識別管理サーバからの応答によって対応するとしたことで、見ず知らずの共通識別情報をも第一保証要求に含めている。

「第一保証受信部」（５１３）は、第一保証要求出力部（５１２）から出力される第一保証要求に応じて識別管理サーバから返信される前記主従関係情報に基づく第一保証を受信する。識別管理サーバ内の処理については後述する。第一保証には、第一保証要求に含まれる第一利用者の共通識別情報と第二利用者の共通識別情報とに基づいた主従関係の存在を保証する情報が含まれる。つまり、第一利用者の共通識別情報で識別される利用者は、第二利用者の共通識別情報で識別される利用者との相対関係においては、「従」である関係、即ち、第二利用者が利用するサービスの提供を受けることができる関係にあることを保証する情報が含まれる。「保証する情報」と記述したが、この保証する情報とは、例えば、識別管理サーバの有する秘密鍵を用いた署名（例えば、保証されるべき情報のハッシュ値などを署名をする実体の保有する秘密鍵により暗号化した情報）である。また、第一保証受信部が受信する第一保証には、第一利用者の共通識別情報や、第二利用者の共通識別情報が、識別管理サーバで管理されていることを保証する情報も含まれていてもよい。また、第一保証要求を行う際に、複数の第二利用者の共通識別情報を含めて要求を行っていた場合には、例えばその中のいずれか一の利用者が主従関係情報を有しているとの保証を第一保証として受信してもよい。なお、例えば、第一利用者や第二利用者の共通識別情報が識別管理サーバにて管理されていない場合には、第一保証の代わりに、エラー情報を受信してもよいし、また、所定のタイマーを設定して、一定時間識別管理サーバから返信がない場合には、第一保証の受信がエラーになったと判断してもよい。また、第一保証の受信がエラーになった場合には、その後、第一電子機器に対してエラー情報を送信してもよい。なお、第一利用者及び第二利用者の共通識別情報自体は、識別管理サーバにて管理されてはいるものの、これらが主従関係情報として管理されていない場合、即ち、第一利用者と第二利用者とが主従関係にない場合には、上記エラー情報とは別の種別のエラー情報を第一保証の代わりに受信してもよい。

「保証付サービス依頼出力部」（５１４）は、第一保証受信部（５１３）にて受信する第一保証に基づいて、第二利用者の共通識別情報を含む保証付サービス依頼を出力する。サービス依頼に、識別管理サーバによる保証を付加して第一判定サーバから出力することで、異なるサービス体系である第一判定サーバと第二判定サーバ間においても、そのサービス依頼の内容が正しいものとして信頼することができる。つまり、一の利用者が、他の利用者が利用するサービスを双方の同意の上で依頼したものである、ということを認識することができる。そして、サービスを依頼する利用者と、サービスを依頼される利用者は、共通識別情報によってシステム内にてそれぞれ唯一存在性を識別できるため、目的外の利用者が享受しているサービスを誤って依頼するといった処理を防ぐことが可能となる。なお、保証付サービス依頼に含まれる第二利用者の共通識別情報は、利用要求にて含まれている情報を利用して保証付サービス依頼に含めてもよいし、あるいは、識別管理サーバからの第一保証に第二利用者の共通識別情報が含まれている場合には、その情報を利用して保証付サービス依頼に含めてもよい。

図１０は、保証付サービス依頼の一例を示したものである。図１０（ａ）では、ｓａｋｕｒａで識別される第一利用者が、ｍｏｍｏで識別される第二利用者が利用する第二判定サーバの利用（課金サービス）を欲している旨を示している。また、図１０（ａ）では、ｍｏｍｏという共通識別情報が存在し、識別管理サーバで管理され、その共通識別情報ｍｏｍｏにて識別される第二利用者が第一利用者と主従関係を有しているとの保証についての情報が、「<保証データ>」と「<／保証データ>」で囲まれる部分に配置されている。この部分は、第一保証受信部（６０３）が受信した第一保証に相当する。なお、第一保証には、第二判定サーバの利用の種類、第二判定サーバの指定、第二サービスサーバ群のサーバの指定、第二サービスサーバ群により提供されるサービスの指定、サービスの提供の対価の課金方法などの項目も含まれていてもよいし、関連づけられていてもよい。また、これらの項目に応じて、「<保証データ>」と「<／保証データ>」で囲まれる部分に配置されている情報は、その項目が識別管理サーバで管理されていることを保証する情報に相当するようになっていてもよい。また、そのサービスの提供を受ける第一電子機器や第一判定サーバなどの識別情報が含まれてもよい。図１０（ｂ）は、図１０（ａ）の中の「<利用内容>」に該当する項目が含まれてないパターンである。図１０（ｂ）のようなパターンは、例えば第二利用者が指定されれば、そのサービスが一意に特定できる場合の例である。

なお、図１０では第二利用者の共通識別情報とともに第一利用者の共通識別情報についても保証付サービス依頼に含まれることを示したが、第一利用者の共通識別情報については、必ずしも保証付サービス依頼に含まれなくてもよい。例えば、第一判定サーバと第二判定サーバとがＴＣＰ／ＩＰにて通信を行う場合には、第一判定サーバにおいて、その通信にて利用したポート番号などと、第一利用者の第一電子機器識別情報とを一時的に関連付けて記憶しておくことで、その保証付サービス依頼がどの利用者の電子機器からの要求に応じて出力したものであるかを識別してもよい。また、例えば、第二判定サーバにおける課金処理の実行要求のように、第二判定サーバを通じて第二サービスが行われることのみによって、そのサービス依頼が完結するような場合等においては、第一利用者を特定しなくてもよいため、サービス依頼に第一利用者の共通識別情報が含まれなくてよい。

（実施形態１：第一判定サーバの処理）
図１１は、第一判定サーバの処理の流れを説明するフローチャートの一例を示した図である。第一判定サーバは、第一電子機器から第二判定サーバの利用要求を取得可能になるたびに、このフローチャートの処理を実行する。ステップＳ１１０１において、第一電子機器から、第二利用者の共通識別情報を含む第二判定サーバの利用要求を得る。例えば、ソケットを用いた通信におけるｒｅａｄシステムコールを第一保証要求出力部（５１２）において実行する。ステップＳ１１０２において、第一電子機器識別情報から第一利用者の共通識別情報を得る。例えば、ステップＳ１１０１での利用要求を送信した第一電子機器の第一電子機器識別情報を取得し、その取得された第一電子機器識別情報で第一関連保持部（５１１）などを検索することにより、第一利用者の共通識別情報が得られる。

ステップＳ１１０３では、ステップＳ１１０１、Ｓ１１０２で得られた情報を参照して、第一利用者の共通識別情報及び第二利用者の共通識別情報を含む第一保証要求を生成する。例えば、図９に例示された第一保証要求を生成し、メモリに記憶する。ステップＳ１１０４では、第一保証要求を出力する。例えば、識別管理サーバと通信コネクションを確立し、得られるソケットを用いてｗｒｉｔｅシステムコールを第一保証要求出力部（５１２）において実行する。

ステップＳ１１０５では、主従関係情報に基づく第一保証を受信する。例えば、ステップＳ１１０４で確立した通信コネクションのソケットを用いたｒｅａｄシステムコールを第一保証受信部（５１３）において実行する。ステップＳ１１０６では、受信した第一保証に基づいて、第二利用者の共通識別情報を含む保証付サービス依頼を生成する。例えば、図１０に例示された情報を生成して、メモリに記憶する。ステップＳ１１０７では、保証付サービス依頼を出力する。例えば、第二判定サーバに対する通信コネクションを確立し、得られるソケットを用いてｗｒｉｔｅシステムコールを保証付サービス依頼出力部（５１４）において実行する。

その後、第二判定サーバや第二サービスサーバ群からサービスの提供があれば、第一判定サーバは、第一利用者の利用する第一電子機器へサービスの提供を転送する。また、保証付サービス依頼に、第一電子機器識別情報が含まれている場合には、第二判定サーバや第二サービスサーバ群から直接第一電子機器へサービスの提供が行なわれる場合もある。

（実施形態１：第二判定サーバの構成）
第二判定サーバは、第二電子機器が第二サービスサーバ群から第二サービスを受けるために第二電子機器識別情報に基づいて第二判定する。第二電子機器は、第一利用者と異なる利用者である第二利用者が利用する電子機器である。「第二電子機器識別情報」とは、第二電子機器を、少なくとも第二サービスサーバ群と第二判定サーバとの範囲内で一意に識別するための情報である。ただし、第二電子機器そのものでなく、第二電子機器を介して第二サービスの提供を受ける限りの意味における利用者を識別するためのユーザ識別情報であってもよい。つまり、第二電子機器識別情報は、第二電子機器がサービスの提供を受けるのに適切な電子機器であるか否かを第二判定サーバが判断するために通常利用する識別情報であり、一般的には第二サービスの提供を受けるために固有に築かれたシステム用の識別情報である。

図５に示すように、第二判定サーバ（５２０）は、第二関連保持部（５２１）と、保証付サービス依頼受信部（５２２）とを有している。

「第二関連保持部」（５２１）は、第二利用者の共通識別情報と、第二電子機器識別情報とを関連付けて保持する。この共通識別情報は、一般的には、電子機器を所有する利用者の発意に応じて判定サーバに対して付与されることが想定される。共通識別情報が判定サーバに対して与えられるための流通経路は各種考えられ、一に限定されるものではない。もちろん、この説明は一例であって、固有のサービス体系を実現するシステムを構築する際に予め固有の識別情報体系である機器識別情報とともに共通識別情報を利用するように設計することも可能である。

第二判定サーバは、第二電子機器識別情報に基づいて、第二電子機器が第二サービスサーバ群から第二サービスを受けることができるかどうかの第二判定を行う。この判定処理は、第二電子機器が自身の第二電子機器識別情報を第二判定サーバに対して送信することにより、第二サービスの提供を要求する場合に行われる。これらの処理は、第二サービス関連システム内にとどまった処理であり、第二サービスシステム体系内の固有処理である。本件発明は、このような、固有システム内の垂直的サービスではなく、固有システム間の横断的利用を提供するためのものである。

図１２は、第二関連保持部（５２１）が保持するテーブルを例示する。ｍｏｍｏで識別される第二利用者が、ｄｅｖｉｃｅ−ＤＥＦで識別される電子機器を使用すること等が例として表現されている。

「保証付サービス依頼受信部」（５２２）は、前記保証付サービス依頼を受信する。保証付サービス依頼は、第一保証に基づいて生成されているため、信頼性が高いといえる。したがって、第二判定サーバは受信したサービス依頼に応じたサービスの提供を行うとしてもよい。これは、第二判定サーバが、識別管理サーバといわば信頼関係を有していることにより、その識別管理サーバの保証が付されていることでそのサービス依頼が正当なものであると第二判定サーバにて判断できるからである。また、識別管理サーバから出力される第一保証が識別管理サーバの秘密鍵で署名や暗号化がされている場合があり、このとき、保証付サービス依頼には暗号化された保証が含まれていることになるが、第二判定サーバでは識別管理サーバの公開鍵で復号化を行い、保証内容の真正性（主従関係を有する証明に対して付される署名などの真正性）を確認できるとしてもよい。なお、第二判定サーバではサービス依頼に基づいて、第二利用者の共通識別情報をキーとして検索を行うとしてもよい。

図１３は、サービス依頼に基づいて、第二利用者の共通識別情報をキーとして検索を行う場合の第二判定サーバの機能ブロック図を例示する。図５と図１３とを比較すると、図１３の第二判定サーバ（１３２０）には、第二検索部（１３２３）が追加されている。

「第二検索部」（１３２３）は、保証付サービス依頼受信部（１３２２）にて受信した保証付サービス依頼に基づいて第二関連保持部（１３２１）を、第二利用者の共通識別情報をキーとして検索する。第二利用者の共通識別情報をキーとする検索とは、保証付サービス依頼に含まれる第二利用者の共通識別情報を抽出し、これと合致する共通識別情報が第二関連保持部にて保持されているかどうかの検索を行うことをいう。合致する共通識別情報が得られた場合には、保証付サービス依頼に応じたサービスの提供（第一サービスの利用料の支払い、暗号化コンテンツ等の復号鍵送信、パスワード送信など）を行うとしてもよい。また、検索結果は、第一判定サーバや、第二電子機器（第二サービスサーバ群を経由してもよい）に送信するとしてもよい。

本実施形態では、共通識別情報で識別される第二利用者が唯一存在し、かつ、その第二利用者が利用する第二サービスを、その第二利用者と主従関係を有する第一利用者が享受可能であることが識別管理サーバにて証明されることによって、第二判定サーバはサービス依頼の内容が真正であり、信頼できるものであると判断することができる。この理由は以下のとおりである。つまり第二判定サーバは、常日頃からサービスを提供可能な電子機器を識別するために第二電子機器識別情報を利用している。つまり第二判定に第二電子機器識別情報を利用しているのである。したがって、第二判定サーバは第二電子機器識別情報を有する相手は信頼できるが、原則としてそれ以外の手段で相手の信頼性、相手の提供する情報の信頼性を確認することができない。ただし、例外として本件発明においては第二判定サーバにおいて共通識別情報と第二電子機器識別情報とが関連付けられているのでこれを利用する場合がある。この共通識別情報との関連付けの意味は、例えば第二電子機器識別情報（例えば、「ｄｅｖｉｃｅ−ＤＥＦ」）で識別される電子機器を利用する利用者と、共通識別情報（例えば、「ｍｏｍｏ」）で識別される相手とは同一の第二利用者であるという意味である。ここで第二判定サーバに対して共通識別情報で識別される第二利用者について、第二判定サーバの利用の要求があった場合には第二判定サーバは、この要求は第二電子機器識別情報で識別される第二利用者についての要求であると判断できる。ただし、ｍｏｍｏという識別情報がこのシステム内で重複して付与されている場合にはこの限りでない。つまり、第二利用者と同一の共通識別情報であるｍｏｍｏで識別される第三の利用者が第二サービス体系に属している場合には、真の利用者が不明となってしまう可能性も出てくる。この問題を解決するためにはｍｏｍｏという識別情報が重複してシステム内で付与されていないことが確立できればよいこととなる。つまりｍｏｍｏの唯一存在性が立証でき、さらに、その唯一性が立証されている利用者同士の主従関係が証明されていれば、第二判定サーバは見ず知らずの判定サーバからの要求に含まれるｍｏｍｏであっても、そのｍｏｍｏが利用を許可したと認識し、ｄｅｖｉｃｅ−ＤＥＦの利用者としてのサービス提供などの許可を行うことができる。

なお、第一判定サーバと、第二判定サーバとは、便宜的に区別を行ったが、双方が同様の機能を有することを妨げるものではない。また、他の実施形態でも第一判定サーバ、第二判定サーバとが便宜的に区別されるが、双方が同様の機能を有していてもよい。

（実施形態１：第二判定サーバの処理）
図１４は、本実施形態に係るシステムの第二判定サーバの処理の流れを説明するフローチャートを例示する。第二判定サーバは、保証付サービス依頼の受信が可能になるたびに、図１４のフローチャートの処理を実行する。ステップＳ１４０１において、保証付サービス依頼を受信する。例えば、保証付サービス依頼の受信が可能になることを検出した後に、第一判定サーバとの通信コネクションを確立し、得られるソケットを用いて、ｒｅａｄシステムコールを保証付サービス依頼受信部（５２２）で実行する。ステップＳ１４０２において、ステップＳ１４０１で受信した保証付サービス依頼から第二利用者の共通識別情報を得る。ステップＳ１４０３において、ステップＳ１４０１で受信した保証付サービス依頼の真正性を確認する。例えば、識別管理サーバの公開鍵を用いて、署名などの検証を行う。また、ステップＳ１４０２にて得た共通識別情報で識別される第二利用者が、第一利用者と主従関係を有していることの証明を得る。

ステップＳ１４０４において、ステップＳ１４０２で得られた第二利用者の共通識別情報が第二関連保持部に保持されていることを確認する。この確認により、保証付サービス依頼に含まれる第二利用者が、第二判定サーバでの判定によりサービスの提供が行なわれる第二電子機器の利用者であることが確認できる。これにより、第二判定サーバ側で、サービスの提供の対価などの課金の処理を行うことができる。

ステップＳ１４０５では、ステップＳ１４０４での確認に基づいて、第一電子機器へのサービスの提供を許可する。例えば、第二サービスサーバ群のサーバに対して、第一電子機器へ向けてサービスを提供するように命令を行う。なお、第二サービスサーバ群のサーバに対してこのような命令を行う場合には、その命令にステップＳ１４０１で得られた保証付サービス依頼に含まれ得る第一利用者の共通識別情報を含めてもよい。これにより、第二サービスサーバ群のサーバは、サービスを提供する第一利用者を判別することができ、例えば、既に同種あるいは同一のサービスを提供したことがあるかどうかを判断することができる。この判断に基づいて、すでに同種あるいは同一のサービスを提供したことがある第一利用者には、割引された対価にて、あるいは無料にてサービスを提供するようになっていてもよい。

（実施形態１：識別管理サーバの構成）
識別管理サーバは、共通識別情報に基づく主従関係情報を保持し、各サーバを管理する。識別管理サーバと第一判定サーバ間、及び、識別管理サーバと第二判定サーバ間においては、各々信頼関係を有する。

図５で示すように、識別管理サーバ（５３０）は、識別管理部（５３１）と、識別管理部検索部（５３２）と、第一保証出力部（５３３）と、を有する。

識別管理部（５３１）については既に説明した。識別管理部（５３１）により、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理する。共通識別情報は、利用者などによって予め登録が行われることによって発行され、第一判定サーバ、及び、第二判定サーバに対して付与することが想定される。ただし、共通識別情報が判定サーバに対して与えられるための流通経路は各種考えられ、一に限定されるものではない。この共通識別情報により、本システム内における識別情報が、唯一であることが保証される。また、同様に、共通識別情報に基づく主従関係情報は、利用者などによって予め識別管理サーバに対して登録が行われることが想定される。そして、その共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理することで、例えば、第一利用者が、第二利用者との相対関係において、「従」の関係を有していることを保証することができる。

「識別管理部検索部」（５３２）は、第一判定サーバが出力する第一保証要求に含まれる第一利用者及び第二利用者の共通識別情報をキーとして識別管理部の前記主従関係情報を検索する。まず、第一保証要求に含まれる第一利用者の共通識別情報と、第二利用者の共通識別情報を抽出し、これと合致する主従関係情報のレコードが識別管理部にて管理されているかどうか検索を行う。かかる検索では、第一利用者、第二利用者の共通識別情報により、各利用者の本システム内における唯一性を保証することができる。そして、さらに第一利用者と第二利用者とが主従関係を有しているかについても保証することができる。

「第一保証出力部」（５３３）は、識別管理部検索部での検索結果に基づいて前記第一保証を出力する。第一保証の出力先は、第一判定サーバである。識別管理部検索部における検索にて、第一利用者の共通識別情報と、第二利用者の共通識別情報とが合致する主従関係情報が得られた場合には、第一利用者と第二利用者とが主従関係を有していることを保証として出力することができる。なお、第一利用者と第二利用者の共通識別情報が、同一のレコードとして主従関係情報に含まれてはいるものの、その主従関係が逆転した要求である場合には、主従関係を保証しないために、第一保証を出力しなくてもよい。また、例えば利用者の共通識別情報が得られなかった場合や、一方の利用者の共通識別情報はレコード中に含まれているが、他方の利用者の共通識別情報が含まれていない場合などには、別途その旨をエラー情報として出力するとしてもよい。なお、第一判定サーバに対して出力する第一保証を識別管理サーバの秘密鍵で暗号化するとしてもよい。このとき、保証付サービス依頼を受信する第二判定サーバでは識別管理サーバの公開鍵で復号化を行い、保証を確認できれば、改ざんやなりすましを予防でき有益である。

（実施形態１：識別管理サーバの処理）
図１５は、識別管理サーバの処理の流れを説明するフローチャートを例示する。識別管理サーバは、第一保証要求の受信が可能になるごとに、図１５に例示されたフローチャートの処理を行う。ステップＳ１５０１において、第一保証要求を受信する。例えば、第一判定サーバからの通信コネクションの確立の要求に応じて生成されるソケットを用いて、識別管理部検索部（５３２）などにおいてｒｅａｄシステムコールを実行する。ステップＳ１５０２において、第一保証要求に含まれる第一利用者の共通識別情報と第二利用者の共通識別情報を得る。ステップＳ１５０３において、ステップＳ１５０２で得られた第一利用者の共通識別情報と第二利用者の共通識別情報に基づいて、主従関係情報が識別管理部（５３１）で管理されているかどうかを、識別管理部を検索することにより確認する。ステップＳ１５０４において、ステップＳ１５０３での確認に基づいて第一保証を生成して、メモリなどの記憶手段にすくなくとも一時的に記憶する。ステップＳ１５０５において、ステップＳ１５０４で生成して記憶された第一保証を出力する。例えば、ステップＳ１５０１で確立した通信コネクションによるソケットを用いたｗｒｉｔｅシステムコールを第一保証出力部（５３３）において実行する。

<実施形態１：システム全体の処理の流れ>
図１６から図１８は、実施形態１のシステム全体の処理の流れの具体的な一例を示したものである。また、図１９は、図１６から図１８に示した処理の流れの全体像を示した図である。本例においては利用要求の一例として、第二判定サーバを介して第一サービスの利用料を支払うことの要求を例示した。そして、そのサービスの利用料の支払いを、第二利用者に要求する例を示している。本システムにおける利用者識別管理方法においては、まず、Ｓ１６０１にて、第一電子機器から第一サービスサーバ群の一部である第一サービスサーバに対してコンテンツの購入要求を出力する。購入要求を受け付けた第一サービスサーバにおいては、購入費用３００円の支払い先を入力するように第一電子機器に対して要求を出力する。第一電子機器においては、支払い先として第二利用者の共通識別情報である「ｍｏｍｏ」を入力する。続いて、Ｓ１６０２として、第一電子機器から第一サービスサーバに対して「ｍｏｍｏ」への課金要求（利用要求）を出力する。この場合に、第一電子機器識別情報として「ｄｅｖｉｃｅ−ＡＢＣ」も併せて出力される。そして、第一サービスサーバにおいては、第一電子機器からの課金要求を受け付けて、その課金要求を第一判定サーバに対して出力する。なお、ステップＳ１６０２については、第一サービスサーバを経由することなく、第一電子機器から第一判定サーバに対して課金要求が直接出力されるとしてもよい。

次に、課金要求（利用要求）を受け付けた第一判定サーバにて、第一電子機器識別情報（ｄｅｖｉｃｅ−ＡＢＣ）と関連付けられた第一利用者の共通識別情報（ｓａｋｕｒａ）を抽出する（Ｓ１６０３）。そして、受け付けた課金要求に基づいて、第一利用者と第二利用者の共通識別情報（ｓａｋｕｒａ、ｍｏｍｏ）を含む第一保証要求（主従関係保証要求）を識別管理サーバに対して出力する（Ｓ１６０４）。

識別管理サーバは、第一判定サーバが出力する第一保証要求に基づいて、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理する識別管理部を検索する。具体的には第一利用者と第二利用者の共通識別情報（ｓａｋｕｒａ，ｍｏｍｏ）の唯一性の保証と、また、第一利用者の共通識別情報で識別される利用者（ここでは便宜的に「ｓａｋｕｒａ」とする）が、第二利用者の共通識別情報で識別される利用者（ここでは便宜的に「ｍｏｍｏ」とする）の「従」の関係にあること、即ち、第一利用者（ｓａｋｕｒａ）が第二利用者（ｍｏｍｏ）の利用するサービスを利用可能であることが、保証データとして生成される（Ｓ１６０５）。このとき、検索結果に基づいて第一保証を出力すべきかどうかについての判定処理が行われてもよい。そして、識別管理サーバから第一判定サーバに対して検索結果に基づいて要求に対する保証（第一保証）を出力する（Ｓ１６０６）。

次に、第一判定サーバは、識別管理サーバから返信される第一保証を受信する。そして受信した第一保証に基づいて第二利用者の共通識別情報（ｍｏｍｏ）を含む保証付サービス依頼を出力する（Ｓ１６０７）。Ｓ１６０７では、具体的には、第一利用者（ｓａｋｕｒａ）が第二利用者（ｍｏｍｏ）の「従」の関係にあるという保証を含めた第二利用者（ｍｏｍｏ）への課金要求が出力される。なお、Ｓ１６０７にて出力される保証付サービス依頼には、そのサービス依頼元の利用者の情報として、第一利用者の共通識別情報（ｓａｋｕｒａ）が含まれていてもよい。

第二判定サーバは、保証付サービス依頼（保証付課金要求）を受信する。なお、第二判定サーバは、さらに受信した保証付サービス依頼に基づいて、第二利用者（ｍｏｍｏ）が自身に登録されているかについて、第二関連保持部を、第二利用者の共通識別情報（ｍｏｍｏ）をキーとして検索する場合もある（Ｓ１６０８）。

Ｓ１６０８以降の処理については、一例として、図１７又は図１８に示す処理が行われる。図１７と図１８との処理の違いは、課金の実行をする際に、第二利用者（ｍｏｍｏ）に対して許可を得るか否かによるものである。

図１７の例で引き続き説明をする。第二判定サーバにおいては、第二関連保持部を検索した結果、第二利用者の共通識別情報（ｍｏｍｏ）を検出したため、その共通識別情報と関連付けられている第二電子機器識別情報にて識別される第二電子機器に対して課金を実行する。具体的には、第二サービスサーバ群の一部である課金サーバに対して課金命令を出力することなどによって課金の実行がなわれる（Ｓ１６０９Ａ、Ｓ１６１０Ａ）。その後、第二判定サーバを通じて、第一判定サーバや第一電子機器に対して課金の完了通知がなされる（Ｓ１６１１Ａ）。

一方、図１８の例においては、第二判定サーバにおいては、第二関連保持部を検索した結果、第二利用者の共通識別情報（ｍｏｍｏ）を検出したため、その共通識別情報と関連付けられている第二電子機器識別情報にて識別される第二電子機器に対して課金を実行してもよいかの許可確認処理を行う（Ｓ１６０９Ｂ）。そして、この結果、第二電子機器から課金の許可通知が出された場合（Ｓ１６０９Ｂ）には、第二判定サーバは、第二電子機器に対する課金を実行する（Ｓ１６１０Ｂ）。その後、識別管理サーバと、第一判定サーバや第一電子機器に対して課金の完了通知がなされる（Ｓ１６１１Ｂ）。

なお、Ｓ１６１１Ｂにおいては、図１７で示すＳ１６１１Ａと異なり、識別管理サーバに対して課金の完了通知がなされている。以下、この例について詳細に説明を行う。例えば、第二利用者に対して課金の実行を行う場合には、その第二利用者に対して課金の実行の許可を得る場合（図１８の例）と、許可を得ない場合（図１７の例）とが考えられる。ここで、後者の課金の許可を得る場合のシステムについて、グレードという概念を導入することが考えられる。このグレードという概念は一種のランクのようなものであり、例えば同一人が同じ課金サービスを継続して要求する場合には、その都度許可を得ることが第二利用者及び第二判定サーバにおいて煩わしくなる場合がある。そこで、このグレードという概念を導入することで、その煩雑さを解消することが可能となる。具体的には、識別管理サーバにて、課金完了通知に基づいた実績ログを保持しておく。このログには、例えば第一利用者と第二利用者の共通識別情報や、あるいは、また、課金の実行履歴などが格納されている。そして、例えば、再度第一利用者（ｓａｋｕｒａ）から第二利用者（ｍｏｍｏ）の主従関係の保証要求が第一判定サーバから出力された場合には、その保証として、自身が保持している実績ログに基づくグレードを含ませて出力するとしてもよい。すると、第一判定サーバからのサービス依頼（課金実行）が第二判定サーバに対して出力された場合において、第二判定サーバ側では、その保証に含まれているグレードによって、第二電子機器に対して課金実行の許可を行わずに、そのまま課金を実行することができる。なお、グレードという概念を導入する場合には、例えば主従関係が親と子の場合と、友人同士の場合とでは、そのグレードに差異を設けるなど、柔軟なシステム構成をとることが可能となる。もっとも、このグレードという概念については、必須のものではなく、例えば図１７のように、識別管理サーバにて主従関係を有している利用者については、そのことのみに起因して、第二電子機器に対する許可を求めることなく課金の実行などを行うとしてもよい。

<実施形態１：実現形態>
図２０は、実施形態１の実現形態の一例を示す。図２０では、第一判定サーバ（２０３０）を例に挙げて説明する。第一判定サーバ（２０３０）の物理的な構成としては、図２１に示すように、ＣＰＵ、メモリ、ハードディスク、入出力装置、ネットワークインターフェース（Ｉ／Ｏ）などからなるハードウェア（２０３１）として実現される。論理的には、ハードウェア（２０３１）の機能を抽象化したり、ハードウェア（２０３１）の動作を管理などするための基本ソフトウェアであるオペレーティングシステム（２０３２）が動作し、その上に、第一関連保持モジュール（２０３３）、第一保証要求出力モジュール（２０３４）、第一保証受信モジュール（２０３５）、保証付サービス依頼出力モジュール（２０３６）として、それぞれ、第一関連保持部（５１１）、第一保証要求出力部（５１２）、第一保証受信部（５１３）、保証付サービス依頼出力部（５１４）を実現するモジュールを含んで構成されるプログラムが動作する。このプログラムは、例えば、図１１に例示した処理を実行する。

なお、第二判定サーバ（２０４０）や識別管理サーバ（２０５０）についても、ハードウェアの上にオペレーティングシステムを動作させ、その上で各部を実現するモジュールを有するプログラムを動作させることにより実現できることは同様である。

また、第一電子機器（２０１０）や、第二電子機器（２０２０）についても各サーバと同様に、ハードウェアの上にオペレーティングシステムを動作させ、その上で各部を実現するモジュールを有するプログラムを動作させることにより実現することができる。なお、電子機器では、ハードウェア（２０１１、２０２１）に関連付けて電子機器識別情報が格納されているものである。

<実施形態１：主な効果>
以上開示されたシステムの構成では、一の電子機器が一のサービス体系に縛られず、サービス体系の垣根を取り払うことができる。例えば、第一の利用者が利用する第一電子機器に対して、第二の利用者が他のサービス体系で利用する第二電子機器が享受しているサービスを受けさせることができ、利便性の向上が期待できる。

<<実施形態２>>
<実施形態２：概要>
実施形態２について以下に説明する。実施形態２は、実施形態１と同じく、サービスサーバ群と、電子機器と、判定サーバと、識別管理サーバと、からなるシステムであるが、第一電子機器からの第二判定サーバの利用要求に基づいて、第一判定サーバから出力する保証要求付サービス依頼を受けた識別管理サーバにて、識別管理部の検索を行い、この識別管理サーバから保証付サービス依頼が第二判定サーバに出力される点が異なる。図２２は、本実施形態の概念の一例を示す図である。図２２における大まかな処理の流れは下記の通りである。なお、各用語の示す意味などについては後の部分にて説明を行う。（１）利用者Aが利用する第一電子機器から第一判定サーバに対して利用者Bの共通識別情報を含む第二判定サーバの利用要求を行う。なお、この利用要求は、第一判定サーバに対して要求してもよいし、第一サービスサーバ群を経由して要求してもよい。（２）利用要求を受けた第二判定サーバは、識別管理サーバに対して、保証要求付サービス依頼を行う。（３）保証要求付サービス依頼を受けた識別管理サーバにおいては、その保証要求付サービス依頼に含まれている第二判定サーバ識別情報によって識別される第二判定サーバに対して、その保証要求付サービス依頼に含まれる利用者Aと利用者Bの共通識別情報に基づく主従関係情報に基づいて保証付サービス依頼を出力する。

このように、本実施形態は、第一電子機器からの第二判定サーバの利用要求に基づいて、第一判定サーバが保証要求付サービス依頼を出力し、それを受けた識別管理サーバは、識別管理部の検索を行い、その検索結果に基づいて第一判定サーバを経由せずに、第二判定サーバに対して保証付サービス依頼を出力する点に特徴がある。

<実施形態２：構成>
図２３は、実施形態２に係るシステムの機能ブロック図を例示する。実施形態２は、実施形態１と同様に、第一判定に基づいて第一サービスを第一電子機器（２３０３）に行う第一サービスサーバ群（２３０１）と、第二判定に基づいて第二サービスを第二電子機器（２３０４）に行う第二サービスサーバ群（２３０２）と、第一利用者が利用し、第一サービスサーバ群（２３０１）から第一サービスを受ける第一電子機器（２３０３）と、第二利用者が利用し、第二サービスサーバ群（２３０２）から第二サービスを受ける第二電子機器（２３０４）と、第一サービスサーバ群（２３０１）から前記第一サービスを受けるために、第一電子機器（２３０３）を第一電子機器識別情報に基づいて第一判定する第一判定サーバ（２３１０）と、第二サービスサーバ群（２３０２）から前記第二サービスを受けるために、第二電子機器（２３０４）を第二電子機器識別情報に基づいて第二判定する第二判定サーバ（２３２０）と、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を識別管理部（２３３１）に管理する識別管理サーバ（２３３０）とからなるシステム（２３００）である。

実施形態１では、第一判定サーバ（５１０）と識別管理サーバ（５３０）との通信が行なわれ、その後、第一判定サーバ（５１０）と第二判定サーバ（５２０）との通信が行なわれるのに対して、実施形態２では、第一判定サーバ（２３１０）と識別管理サーバ（２３３０）との通信が行なわれ、その後、識別管理サーバ（２３３０）と第二判定サーバ（２３２０）との通信が行なわれる。

（実施形態２：第一判定サーバの構成）
図２３に示すように、第一判定サーバ（２３１０）は、第一関連保持部（２３１１）と、保証要求付サービス依頼出力部（２３１２）とを有する。

「第一関連保持部」（２３１１）は、第一利用者の共通識別情報と第一電子機器識別情報とを関連付けて保持する。すなわち、第一関連保持部（２３１１）の定義は、実施形態１における第一関連保持部（５１１）と同じである。

「保証要求付サービス依頼出力部」（２３１２）は、第一電子機器からの第二利用者の共通識別情報を含む第二判定サーバの利用要求に基づいて、第二判定サーバ識別情報及び第一利用者並びに第二利用者の共通識別情報を含む保証要求付サービス依頼を出力する。「第二判定サーバ識別情報」とは、第二判定サーバを識別する情報である。例えば、第二判定サーバに割り当てられたＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）や、第二判定サーバに割り当てられたＩＰアドレスなどである。後述する本実施形態における識別管理サーバにおいては、この第二判定サーバ識別情報を利用して第二判定サーバに対してサービス依頼を行うことになる。なお、第二判定サーバ識別情報は、第一判定サーバ内にて保持されている情報であってもよいし、あるいは、第一電子機器からの利用要求に含まれる情報であってもよい。保証要求付サービス依頼に第二判定サーバを識別する情報が含まれる理由としては、実施形態２は、実施形態１と異なり、識別管理サーバを経由して第二判定サーバに対してサービス依頼を行うため、識別管理サーバにとっては、そのサービス依頼先である第二判定サーバの識別情報が必要となるからである。

保証要求付サービス依頼出力部（２３１２）は、本件発明の目指す異なるサービスシステム間の横断的利用のために第一判定サーバから外部に対して最初に行なわれる処理を行う。この保証要求付サービス依頼は、識別管理サーバに対して出力される。第二判定サーバの利用要求としては、第二判定サーバを介して第一サービスの利用料を支払うことを要求するために、第一電子機器が送信する場合がある。本来第一電子機器は第一サービスシステム内でのみサービスの提供を受けることが出来たのであるが、その壁を破って他のサービスシステムにおいても所定のサービスを受けようとするためのものである。本件発明の場合には特に第二判定サーバの利用を目的とし、さらに第一利用者と異なる利用者である第二利用者の受けている他のサービス体系におけるサービスを、第一利用者が受けることを目的とするものである。具体的には、第二利用者が利用する第二電子機器にてダウンロードした暗号化コンテンツ等を、第一利用者が利用する第一電子機器においても利用可能とするために第二判定サーバを介して復号鍵を取得することの要求や、第二電子機器にてダウンロードした個人情報等（スケジュール、カルテなど）を第一電子機器においても閲覧可能とするために第二判定サーバを介してパスワードを取得することの要求などが該当する。繰り返せば、これらの処理は本来第一電子機器が享受することが不可能であった処理である。なぜなら第一電子機器は第一サービスシステム体系内にてサービスを受けられるのに対して、これらの処理は、第二サービスシステム体系内で第二電子機器のみしか享受することが出来ない処理だったからである。

第一利用者が利用する第一電子機器からの利用要求時には、例えばその第一電子機器の第一電子機器識別情報が第一判定サーバに併せて出力されるため、保証要求付サービス依頼出力部では、その第一電子機器識別情報に基づいて第一利用者の共通識別情報を取得する。また、第一電子機器からの利用要求に含まれる第二利用者の共通識別情報を取得し、さらに、利用要求の対象となっている第二判定サーバに関する情報である第二判定サーバ識別情報（例えば、ＩＰアドレスなど）を取得する。

図２４は、保証要求付サービス依頼の一例を示す。図２４（ａ）と図２４（ｂ）との差異は、利用内容が明示されているか否かによるものである。図２４の例では、第二判定サーバは、１２３．４５．６７．８７というＩＰアドレスにより識別され、第一利用者の共通識別情報は、ｓａｋｕｒａで表現され、第二利用者の共通識別情報は、ｍｏｍｏで表現される。なお、保証要求付サービス依頼には、その他第二サービスサーバ群のサーバの指定、第二サービスサーバ群により提供されるサービスの指定、サービスの提供の対価の課金方法なども含まれていてもよい。

（実施形態２：第一判定サーバの処理）
図２５は、実施形態２に係るシステムの第一判定サーバの処理の流れを説明するフローチャートを例示する。第一判定サーバは、第一電子機器から第二判定サーバの利用要求が取得可能になるたびに、このフローチャートに表わされている処理を実行する。ステップＳ２５０１において、第一電子機器から、第二利用者の共通識別情報を含む第二判定サーバの利用要求を得る。例えば、ソケットを用いた通信におけるｒｅａｄシステムコールを保証要求付サービス依頼出力部（２３１２）において実行する。ステップＳ２５０２において、第一電子機器識別情報から、第一利用者の共通識別情報を得る。例えば、ステップＳ２５０１での利用要求を送信した電子機器の識別情報を、通信コネクションを示す情報などより取得し、その取得された識別情報で第一関連保持部（２３１１）を検索することにより、第一利用者の共通識別情報が得られる。

ステップＳ２５０３においては、ステップＳ２５０１、Ｓ２５０２で得られた情報を参照して第二判定サーバ識別情報、第一利用者の共通識別情報、第二利用者の共通識別情報を含む保証要求付サービス依頼を生成する。例えば、図２４に例示された保証要求付サービス依頼を生成する。生成された保証要求付サービス依頼はメモリに一時的に記憶されてもよい。ステップＳ２５０４では、保証要求付サービス依頼を出力する。例えば、識別管理サーバと通信コネクションを確立し、メモリなどに記憶された保証要求付サービス依頼を読み出して、通信コネクションの確立により得られるソケットを用いてｗｒｉｔｅシステムコールを保証要求付サービス依頼出力部（２３１２）において実行する。

（実施形態２：第二判定サーバの構成）
図２３に示すように、第二判定サーバ（２３２０）は、第二関連保持部（２３２１）と、第二保証付サービス依頼受信部（２３２２）とを有する。

「第二関連保持部」（２３２１）は、第二利用者の共通識別情報と第二電子機器識別情報とを関連付けて保持する。

「第二保証付サービス依頼受信部」（２３２２）は、前記主従関係情報に基づいて識別管理サーバから出力される第二利用者の共通識別情報を含む第二保証付サービス依頼を受信する。第二保証付サービス依頼は、前記第一判定サーバが出力する保証要求付サービス依頼に基づいて、本実施形態に係るシステムの識別管理サーバから返信されるものである。本実施形態に係るシステムの識別管理サーバ内の処理については後述する。

図２６は、第二保証付サービス依頼の一例を示す。図２６（ａ）と図２６（ｂ）との差異は、サービスの利用内容が明示されているか否かである。図２６に例示された第二保証付サービス依頼には、第二利用者の共通識別情報としてｍｏｍｏが含まれている。これにより、ｍｏｍｏで識別される第二利用者の利用している電子機器が受けているサービスに関する依頼を行ったことが示されている。また、「<保証データ>」と「<／保証データ>」の間には、共通識別情報や、主従関係情報などの真正性を保証するための識別管理サーバによる署名などのデータが配置されている。また、第二保証付サービス依頼には、その他第二サービスサーバ群により提供されるサービスの指定、サービスの提供の対価の課金方法なども含まれていてもよく、これらの情報の真正性を保証するための情報が、「<保証データ>」と「<／保証データ>」の間などに配置されていてもよい。

また、実施形態１で説明したものと同様に、第二判定サーバでは第二保証付サービス依頼に基づいて、第二利用者の共通識別情報をキーとして検索を行うとしてもよい。

図２７は、第二保証付サービス依頼に基づいて第二利用者の共通識別情報をキーとして検索を行う場合の第二判定サーバの機能ブロック図を例示する。図２３と図２７とを比較すると、図２７の第二判定サーバ（２７２０）には、第二検索部（２７２３）が追加されている。

「第二検索部」（２７２３）は、識別管理サーバから受信する第二保証付サービス依頼に基づいて、第二関連保持部（２７２１）を第二利用者の共通識別情報をキーとして検索する。第二利用者の共通識別情報をキーとする検索とは、保証付サービス依頼に含まれる第二利用者の共通識別情報を抽出し、これと合致する共通識別情報が第二関連保持部にて保持されているかどうかの検索を行うことをいう。合致する共通識別情報が得られた場合には、保証付サービス依頼に応じたサービスの提供（第一サービスの利用料の支払い、暗号化コンテンツ等の復号鍵送信、パスワード送信など）を行うとしてもよい。また、検索結果は、第一判定サーバや、第二電子機器（第二サービスサーバ群を経由してもよい）に送信するとしてもよい。

（実施形態２：第二判定サーバの処理）
図２８は、本実施形態に係るシステムの第二判定サーバの処理の流れを説明するフローチャートを例示する。第二判定サーバは、第二保証付サービス依頼の受信が可能になるたびに図２８のフローチャートを実行する。ステップＳ２８０１において、第二利用者の共通識別情報を含む第二保証付サービス依頼を受信する。例えば、第二保証付サービス依頼の受信が可能になることを検出した後に、識別管理サーバとの通信コネクションを確立し、得られるソケットを用いて、ｒｅａｄシステムコールを第二保証付サービス依頼受信部（２３２２）において実行する。ステップＳ２８０２において、ステップＳ２８０１で受信した第二保証付サービス依頼から第二利用者の共通識別情報を得る。ステップＳ２８０３において、ステップＳ２８０１で受信した第二保証付サービス依頼の真正性を確認する。例えば、識別管理サーバの公開鍵を用いて、署名などの検証を行う。ステップＳ２８０４において、ステップＳ２８０２で得られた第二利用者の共通識別情報が第二関連保持部に保持されていることを確認する。この確認により、第二保証付サービス依頼に含まれる第二利用者が、第二判定サーバでの判定によりサービスの提供が行なわれる第二電子機器の利用者であることが確認できる。これにより、第二判定サーバ側で、サービスの提供の対価などの課金の処理を行うことができる。

（実施形態２：識別管理サーバの構成）
図２３に示すように、識別管理サーバ（２３３０）は、識別管理部（２３３１）と、保証要求付サービス依頼受信部（２３３２）と、識別管理部検索部（２３３３）と、第二保証付サービス依頼出力部（２３３４）とを有する。

「識別管理部」（２３３１）は、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理する。共通識別情報は、利用者などによって予め登録が行われることによって発行され、第一判定サーバ、及び、第二判定サーバに対して付与することが想定される。ただし、共通識別情報が判定サーバに対して与えられるための流通経路は各種考えられ、一に限定されるものではない。この共通識別情報により、本システム内における識別情報が、唯一であることが保証される。また、同様に、共通識別情報に基づく主従関係情報は、利用者などによって予め識別管理サーバに対して登録が行われることが想定される。そして、その共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理することで、例えば、第一利用者が、第二利用者との相対関係において、「従」の関係を有していることを保証することができる。

「保証要求付サービス依頼受信部」（２３３２）は、第一判定サーバが出力する保証要求付サービス依頼を受信する。なお、保証要求付サービス依頼は、保証要求と、サービスの依頼を別個に受信するとしてもよい。このとき例えば、第一判定サーバから先に保証要求が出力され、これに基づいて識別管理サーバで識別管理部を検索するとしてもよい。検索結果である保証を第一判定サーバに返し、これを受信した第一判定サーバがサービス依頼を出力するとしてもよい。

「識別管理部検索部」（２３３３）は、保証要求付サービス依頼受信部にて受信された保証要求付サービス依頼に含まれる第一利用者及び第二利用者の共通識別情報をキーとして識別管理部の前記主従関係情報を検索する。即ち、第一保証要求に含まれる第一利用者の共通識別情報と、第二利用者の共通識別情報を抽出し、これと合致する主従関係情報のレコードが識別管理部にて管理されているかどうか検索を行う。かかる検索では、第一利用者、第二利用者の共通識別情報により、各利用者の本システム内における唯一性を保証することができる。そして、さらに第一利用者と第二利用者とが主従関係を有しているかについても保証することができる。

「第二保証付サービス依頼出力部」（２３３４）は、識別管理部検索部での検索結果に基づいて前記第二保証付サービス依頼を出力する。第二保証付サービス依頼の出力先は、第二判定サーバである。識別管理部検索部における検索にて、第一利用者の共通識別情報と、第二利用者の共通識別情報とが合致する主従関係情報が得られた場合には、第一利用者と第二利用者とが主従関係を有していることを保証として付したサービス依頼を出力することができる。なお、第一利用者と第二利用者の共通識別情報が、同一のレコードとして主従関係情報に含まれてはいるものの、その主従関係が逆転した要求である場合には、主従関係を保証しないために、第二保証付サービス依頼を出力しなくてもよい。また、例えば利用者の共通識別情報が得られなかった場合や、一方の利用者の共通識別情報はレコード中に含まれているが、他方の利用者の共通識別情報が含まれていない場合などには、別途その旨をエラー情報としてサービス依頼元である第一判定サーバに対して出力するとしてもよい。なお、第二判定サーバに対して出力する第二保証付サービス依頼を識別管理サーバの秘密鍵で暗号化するとしてもよい。このとき、第二保証付サービス依頼を受信する第二判定サーバでは識別管理サーバの公開鍵で復号化を行い、保証を確認できれば、改ざんやなりすましを予防でき有益である。

なお、識別管理サーバにおいて、第二判定サーバ識別情報を保持してもよく、この場合には、保証要求付サービス依頼に含まれる第二判定サーバ識別情報と比較し、その第二判定サーバの唯一性や正当性等を判断するとしてもよい。

（実施形態２：識別管理サーバの処理）
図２９は、本実施形態に係るシステムの識別管理サーバの処理の流れを説明するフローチャートを例示する。識別管理サーバは、保証要求付サービス依頼が受信可能となるたびに、このフローチャートで表わされる処理を実行する。ステップＳ２９０１において、保証要求付サービス依頼を受信する。このステップでは、例えば、第一判定サーバからの要求などにより確立された通信コネクションのソケットを参照したｒｅａｄシステムコールなどを保証要求付サービス依頼受信部（２３３２）において実行する。ステップＳ２９０２において、受信された保証要求付サービス依頼に含まれる第一利用者及び第二利用者の共通識別情報を得る。得られた結果は、例えばメモリなどに一時的に記憶される。また、このステップで、保証要求付サービス依頼に含まれるサービス依頼も得ることが行なわれ、メモリなどに一時的に記憶されてもよい。ステップＳ２９０３において、第一利用者の共通識別情報と第二利用者の共通識別情報に基づいて、主従関係情報が識別管理部（２３３１）に管理されていることを確認する。このステップは、例えば、識別管理部検索部（２３３３）が識別管理部（２３３１）により記憶管理などされているデータに対して検索を行うことにより実行される。ステップＳ２９０４において、ステップＳ２９０３の結果に基づいて第二保証付サービス依頼を生成する。生成された第二保証付サービス依頼は、例えば、メモリなどに一時的に記憶される。ステップＳ２９０５において、ステップＳ２９０１で受信された保証要求付サービス依頼に含まれる第二判定サーバ識別情報を得る。得られた第二判定サーバ識別情報は、例えば、メモリなどに一時的に記憶される。ステップＳ２９０６において、ステップＳ２９０４で生成された第二保証付サービス依頼を第二判定サーバへ出力する。このステップのために、例えば、ステップＳ２９０５で得られた第二判定サーバ識別情報を用いて第二判定サーバと通信コネクションを確立し、この確立によって得られたソケットを用いて、第二保証付サービス依頼出力部（２３３４）において、ｗｒｉｔｅシステムコールを実行する。

<実施形態２：システム全体の処理の流れ>
図３０及び図３１は、実施形態２のシステム全体の処理の流れの具体的な一例を示したものである。また、図３２は、図３０及び図３１に示した処理の流れの全体像を示した図である。本例においては、利用要求の一例として、第二利用者が第二電子機器にてダウンロードした暗号化コンテンツ等を第一利用者の利用する第一電子機器においても利用可能とするために第二判定サーバを介して第二利用者の復号鍵を取得することの要求を例示した。まず、Ｓ３００１にて、第一電子機器にて、復号鍵の取得要求が生成され、取得要求先として第二利用者の共通識別情報（ｍｏｍｏ）が入力される。続いて、Ｓ１６０２として、第一電子機器から第一判定サーバに対して「ｍｏｍｏ」の復号鍵取得要求（利用要求）を出力する。この場合に、第一電子機器識別情報として「ｄｅｖｉｃｅ−ＡＢＣ」も併せて出力される。なお、Ｓ３００２は、第一サービスサーバ群を経由してもよい。

次に、復号鍵取得要求（利用要求）受け付けた第一判定サーバにて、第一電子機器識別情報（ｄｅｖｉｃｅ−ＡＢＣ）と関連付けられた第一利用者の共通識別情報（ｓａｋｕｒａ）を抽出する（Ｓ３００３）。そして、受け付けた復号鍵取得要求に基づいて、第二判定サーバ識別情報（ＩＰ１２３．４５．６７．８９）及び第一利用者並びに第二利用者の共通識別情報（ｓａｋｕｒａ，ｍｏｍｏ）を含む保証要求付サービス依頼（保証要求付復号鍵取得要求）を識別管理サーバに対して出力する（Ｓ３００４）。

識別管理サーバは、第一判定サーバが出力するこの保証要求付サービス依頼を受信し、その受信した保証要求付サービス依頼に基づいて、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理する識別管理部を、第一利用者及び第二利用者の共通識別情報をキーとして検索する。具体的には第一利用者と第二利用者の共通識別情報（ｓａｋｕｒａ，ｍｏｍｏ）の唯一性の保証と、また、第一利用者の共通識別情報で識別される利用者（ここでは便宜的に「ｓａｋｕｒａ」とする）が、第二利用者の共通識別情報で識別される利用者（ここでは便宜的に「ｍｏｍｏ」とする）の「従」の関係にあること、即ち、第一利用者（ｓａｋｕｒａ）が第二利用者（ｍｏｍｏ）の利用するサービスを利用可能であることが、保証データとして生成される。このとき、検索結果に基づいて第一保証を出力すべきかどうかについての判定処理が行われてもよい。そして、その保証データを付した保証付復号鍵要求データ（第二保証付サービス依頼）を生成する（Ｓ３００５）。そして、第二利用者の共通識別情報（ｍｏｍｏ）を含む第二保証付サービス依頼を復号鍵取得要求に含まれるＩＰアドレスで識別される第二判定サーバに対して出力する（Ｓ３００６）。Ｓ３００６では、具体的には第一利用者（ｓａｋｕｒａ）が第二利用者（ｍｏｍｏ）の「従」の関係にあるという保証を含めた第二利用者（ｍｏｍｏ）への復号鍵要求が出力される。なお、Ｓ３００６にて出力される第二保証付サービス依頼には、そのサービス依頼元の利用者の情報として、第一利用者の共通識別情報（ｓａｋｕｒａ）が含まれていてもよい。

次に、第二判定サーバは、識別管理サーバから出力される保証付復号鍵要求（第二保証付サービス依頼）を受信する。なお、第二判定サーバは、さらに、受信した第二保証付サービス依頼に基づいて、第二利用者（ｍｏｍｏ）が自身に登録されているかについて、第二関連保持部を、第二利用者の共通識別情報（ｍｏｍｏ）をキーとして検索する場合もある（３００７）。

次に図３１に移り、Ｓ３００８にて、第二判定サーバから第二サービスサーバ群の一部である第二サービスサーバに対して復号鍵の取得要求を行う（Ｓ３００８）。そして、第二サービスサーバからは例えばＳ３００７の検索結果にて抽出される第二電子機器識別情報にて識別される第二電子機器に対して復号鍵の提供通知を行う（Ｓ３００９）。その後、第二サービスサーバから、第二判定サーバを経由して、第一判定サーバや第一電子機器に対して復号鍵が送付される（Ｓ３０１０）。なお、実施形態１で説明したようなグレードという概念を実施形態２にも導入することももちろん可能である。

<実施形態２：実現形態>
図３３は、実施形態２の実現形態の一例を示す。図３３では、識別管理サーバ（３３５０）を例に挙げて説明する。識別判定サーバ（３３５０）の物理的な構成としては、ＣＰＵ、メモリ、ハードディスク、入出力装置、ネットワークインターフェースなどからなるハードウェア（３３５０）として実現される。論理的には、ハードウェア（３３５１）の機能を抽象化したり、ハードウェア（３３５１）の動作を管理などするための基本ソフトウェアであるオペレーティングシステム（３３５２）が動作し、その上に、識別管理モジュール（３３５３）、保証要求付サービス依頼受信モジュール（３３５４）、識別管理部検索モジュール（３３５５）、第二保証付サービス依頼出力モジュール（３３５６）として、それぞれ、識別管理部（２３３１）、保証要求付サービス依頼受信部（２３３２）、識別管理部検索部（２３３３）、第二保証付サービス依頼出力部（２３３４）を実現するモジュールを含んで構成されるプログラムが動作する。このプログラムは、例えば、図２９に例示した処理を実行する。

なお、第一判定サーバ（３３３０）や、第二判定サーバ（３３４０）についても、ハードウェアの上にオペレーティングシステムを動作させ、その上で各部を実現するモジュールを有するプログラムを動作させることにより実現できることは同様である。また、第一電子機器（３３１０）や、第二電子機器（３３２０）についても各サーバと同様に、ハードウェアの上にオペレーティングシステムを動作させ、その上で各部を実現するモジュールを有するプログラムを動作させることにより実現することができる。なお、電子機器では、ハードウェア（３３１１、３３２１）に関連付けて電子機器識別情報が格納されているものである。

<実施形態２：主な効果>
実施形態は、サービスサーバ群と、電子機器と、判定サーバと、識別管理サーバと、からなるシステムである点は実施形態１と同じであるが、実施形態１と異なる点は、第一電子機器からの第二判定サーバの利用要求に基づいて、第一判定サーバから出力する保証要求付サービス依頼を受けた識別管理サーバにて、識別管理部の検索を行い、その検索結果に基づいて保証付サービス依頼を出力することである。この構成により、第一電子機器、第一サービスサーバ、第一判定サーバにおける垂直統合型のシステム運営管理の形態による利用者の識別管理を、他の垂直統合型のシステム運営管理形態と連携させて、より柔軟なサービスが提供できる。このとき、識別管理サーバから保証付サービス依頼が付与されることによって、判定サーバ間に連携がない場合でもサービス提供が可能となるだけの信頼関係を生じさせることができる。

<<実施形態３>>
<実施形態３：概要>
実施形態３について以下に説明する。本実施形態は、実施形態１と同様にサービスサーバ群と、電子機器と、判定サーバと、識別管理サーバと、からなるシステムである。実施形態１と異なり、第一電子機器からの第二判定サーバの利用要求に基づいて、第一判定サーバから第一サービス依頼を受けた第二判定サーバは、第二保証要求を識別管理サーバに対して出力し、これを受けた識別管理サーバにて、識別管理部の検索を行い、その検索結果に基づいて保証を第二判定サーバに出力することに特徴を有する。図３４は、本実施形態の概念の一例を示す図である。図３４における大まかな処理の流れは下記の通りである。なお、各用語の示す意味などについては後の部分にて説明を行う。（１）利用者Aが利用する第一電子機器から第一判定サーバに対して利用者Bの共通識別情報を含む第二判定サーバの利用要求を行う。なお、この利用要求は、第一判定サーバに対して要求してもよいし、第一サービスサーバ群を経由して要求してもよい。（２）利用要求を受けた第一判定サーバは、第二判定サーバに対して第一サービス依頼を行う。（３）第一サービス依頼を受けた第二判定サーバにおいては、識別管理サーバに対して第二保証要求を出力する。（４）第二保証要求を受けた識別管理サーバにおいては、その第二保証要求に含まれている利用者Ａと利用者Ｂの共通識別情報に基づく主従関係情報に基づいて第二保証を出力する。このようにして第二保証を得た第二判定サーバでは、第一判定サーバからのサービス依頼が正当なものであるとして、その依頼に応じたサービスの提供を第一電子機器に対して行うことができる。

<実施形態３：構成>
図３５は、実施形態２に係るシステムの全体の機能ブロック図を例示する。実施形態３は、実施形態１と同様に、第一判定に基づいて第一サービスを第一電子機器（３５０３）に行う第一サービスサーバ群（３５０１）と、第二判定に基づいて第二サービスを第二電子機器（３５０４）に行う第二サービスサーバ群（３５０２）と、第一利用者が利用し、第一サービスサーバ群（３５０１）から第一サービスを受ける第一電子機器（３５０３）と、第二利用者が利用し、第二サービスサーバ群（３５０２）から第二サービスを受ける第二電子機器（３５０４）と、第一サービスサーバ群（３５０１）から前記第一サービスを受けるために、第一電子機器（３５０３）を第一電子機器識別情報に基づいて第一判定する第一判定サーバ（３５１０）と、第二サービスサーバ群（３５０２）から前記第二サービスを受けるために、第二電子機器（３５０４）を第二電子機器識別情報に基づいて第二判定する第二判定サーバ（３５２０）と、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を識別管理部（３５３１）に管理する識別管理サーバ（３５３０）とからなるシステム（３５００）である。

実施形態１では、最初に第一判定サーバ（５１０）と識別管理サーバ（５３０）との通信が行なわれ、その後、第一判定サーバ（５１０）と第二判定サーバ（５２０）との通信が行なわれるのに対して、実施形態３では、最初に第一判定サーバ（３５１０）と第二判定サーバ（３５２０）との通信が行なわれ、その後、第二判定サーバ（３５２０）と識別管理サーバ（３５３０）との通信が行なわれる点で異なっている。

（実施形態３：第一判定サーバの構成）
図３５に示すように、第一判定サーバ（３５１０）は、第一関連保持部（３５１１）と、第一サービス依頼出力部（３５１２）とを有する。

「第一関連保持部」（３５１１）は、第一利用者の共通識別情報と第一電子機器識別情報とを関連付けて保持する。すなわち、第一関連保持部（３５１１）の定義は、実施形態１における第一関連保持部（５１１）と同じである。

「第一サービス依頼出力部」（３５１２）は、第一電子機器からの第二利用者の共通識別情報を含む第二判定サーバの利用要求に基づいて、第一利用者及び第二利用者の共通識別情報を含む第一サービス依頼を出力する。第一サービス依頼の出力先は、第二判定サーバである。第一サービス依頼出力部（３５１２）は、本件発明の目指す異なるサービスシステム間の横断的利用のために第一判定サーバから外部に対して最初に行なわれる処理を行う。第二判定サーバの利用要求としては、第二判定サーバを介して第一サービスの利用料を支払うことを要求するために、第一電子機器が送信する場合がある。本来第一電子機器は第一サービスシステム内でのみサービスの提供を受けることが出来たのであるが、その壁を破って他のサービスシステムにおいても所定のサービスを受けようとするためのものである。本件発明の場合には特に第二判定サーバの利用を目的とし、さらに第一利用者と異なる利用者である第二利用者の受けている他のサービス体系におけるサービスを、第一利用者が受けることを目的するものである。具体的には、第二利用者が利用する第二電子機器にてダウンロードした暗号化コンテンツ等を、第一利用者が利用する第一電子機器においても利用可能とするために第二判定サーバを介して復号鍵を取得することの要求や、第二電子機器にてダウンロードした個人情報等（スケジュール、カルテなど）を第一電子機器においても閲覧可能とするために第二判定サーバを介してパスワードを取得することの要求などが該当する。繰り返せば、これらの処理は本来第一電子機器が享受することが不可能であった処理である。なぜなら第一電子機器は第一サービスシステム体系内にてサービスを受けられるのに対して、これらの処理は、第二サービスシステム体系内で第二電子機器のみしか享受することが出来ない処理だったからである。

図３６に、第一サービス依頼の一例を示す。図３６（ａ）と図３６（ｂ）との差異は、サービスの利用内容が明示されているか否かである。図３６では、主従関係確認対象を識別する情報として第二利用者の共通識別情報（ｍｏｍｏ）を含ませ、また、サービス要求利用者を識別する情報として第一利用者の共通識別情報（ｓａｋｕｒａ）を含ませている。なお、図３６には示されていないが、第一サービス依頼には、第二サービスサーバ群のサーバの指定、第二サービスサーバ群により提供されるサービスの指定、サービスの提供の対価の課金方法なども含まれていてもよい。また、第一サービス依頼には、第二判定サーバに対して識別管理サーバへ第一利用者と第二利用者の主従関係を確認させるための依頼要求が含まれていてもよい。

（実施形態３：第一判定サーバの処理）
図３７は、実施形態３に係るシステムの第一判定サーバの処理の流れを説明するフローチャートを例示する。第一判定サーバは、第一電子機器から第二判定サーバの利用要求が取得可能になるたびに、このフローチャートに表わされている処理を実行する。ステップＳ３７０１において、第一電子機器から、第二利用者の共通識別情報を含む第二判定サーバの利用要求を得る。例えば、ソケットを用いた通信におけるｒｅａｄシステムコールを第一サービス依頼出力部（３５１２）において実行する。ステップＳ３７０２において、第一電子機器識別情報から第一利用者の共通識別情報を得る。例えば、ステップＳ３７０１での利用要求を送信した第一電子機器の第一電子機器識別情報を通信コネクションを示す情報などに基づいて取得し、その取得された第一電子機器識別情報で第一関連保持部（３５１１）を検索することにより、第一利用者の共通識別情報が得られる。

ステップＳ３７０３においては、ステップＳ３７０１、Ｓ３７０２で得られた情報を参照して第一利用者及び第二利用者の共通識別情報を含む第一サービス依頼を生成する。生成された第一サービス依頼はメモリなどに一時的に記憶されてもよい。ステップＳ３７０４では、第一サービス依頼を出力する。例えば、第二判定サーバと通信コネクションを確立し、メモリなどに記憶された第一サービス依頼を読み出して、通信コネクションの確立により得られるソケットを用いてｗｒｉｔｅシステムコールを第一サービス依頼出力部（３５１２）において実行する。

（実施形態３：第二判定サーバの構成）
図３５に示すように、第二判定サーバ（３５２０）は、第二関連保持部（３５２１）と、サービス依頼受信部（３５２２）と、第二保証要求出力部（３５２３）と、第二保証受信部（３５２４）とを有する。

「第二関連保持部」（３５２１）は、第二利用者の共通識別情報と、第二電子機器識別情報とを関連付けて保持する。

「サービス依頼受信部」（３５２２）は、本実施形態に係るシステムの第一判定サーバが出力する第一サービス依頼を受信する。受信した第一サービス依頼には、第一利用者の共通識別情報と、第二利用者の共通識別情報により識別される利用者間が主従関係を有することを確認するための保証が付加されていないため、第一サービス依頼を受信した段階では、直ちにサービスの提供を実行することはできない。

「第二保証要求出力部」（３５２３）は、サービス依頼受信部（３５２２）にて受信した第一サービス依頼に基づいて第一利用者及び第二利用者の共通識別情報を含む第二保証要求を出力する。第二保証要求の出力先は、識別管理サーバである。第二保証要求は、識別管理サーバから、第一利用者及び第二利用者の共通識別情報により識別される各利用者が唯一存在し、かつ、その利用者間に主従関係が存在しているとの保証を得るために出力されるものである。第二保証要求は、第一利用者及び第二利用者の共通識別情報を含むが、その他、第一判定サーバを識別するための情報などを含んでいてもよい。なお、第二保証要求出力部は、第一サービス依頼受信部にて受信した第一サービス依頼に含まれる第二利用者の共通識別情報をキーとして、例えば第一関連保持部を検索して、その第二利用者の共通識別情報が保持されていない場合には、第二サービスを享受している者が存在しないため、第二保証要求を出力しなくてもよい。

なお、第二保証要求の例としては、図９の第一保証要求の例において、二箇所に現れる「第一保証要求」を「第二保証要求」に置換して得られる例を挙げることができる。

「第二保証受信部」（３５２４）は、第二保証要求出力部（３５２３）から出力される第二保証要求に基づいて識別管理サーバが出力する前記主従関係情報に基づく第二保証を受信する。識別管理サーバ内の処理については後述する。第二保証には、第二保証要求に含まれる第一利用者の共通識別情報と第二利用者の共通識別情報とに基づいた主従関係の存在を保証する情報が含まれる。つまり、第一利用者の共通識別情報で識別される利用者は、第二利用者の共通識別情報で識別される利用者との相対関係においては、「従」である関係、即ち、第二利用者が利用するサービスの提供を受けることができる関係にあることを保証する情報が含まれる。また、識別管理サーバから出力される第二保証が識別管理サーバの秘密鍵で暗号化されている場合があるが、このとき、第二判定サーバでは識別管理サーバの公開鍵で復号化を行い、保証内容を確認できるとしてもよい。

図３８は、第二保証に基づいて第二利用者の共通識別情報をキーとして検索を行う場合の第二判定サーバの機能ブロック図を例示する。図３５と図３８とを比較すると、図３８の第二判定サーバ（３８２０）には、第二検索部（３８２５）が追加されている。

「第二検索部」（３８２５）は、サービス依頼受信部にて受信した第一サービス依頼及び第二保証受信部にて受信した第二保証に基づいて第二関連保持部（３８２１）を、第二利用者の共通識別情報をキーとして検索する。例えば第二保証にて、第一サービス依頼に含まれる第一利用者と第二利用者の共通識別情報にて識別される利用者の主従関係が保証された場合には、第一サービス依頼に含まれている第二利用者の共通識別情報を抽出し、これと合致する共通識別情報が第二関連保持部にて保持されているかどうかの検索を行うことが挙げられる。合致する第二利用者の共通識別情報が得られた場合には、第一サービス依頼に応じたサービスの提供（第一サービスの利用料の支払い、暗号化コンテンツ等の復号鍵送信、パスワード送信など）を行うとしてもよい。また、検索結果は、第一判定サーバや、第二電子機器（第二サービスサーバ群を経由してもよい）に送信するとしてもよい。

（実施形態３：第二判定サーバの処理）
図３９は、本実施形態に係るシステムの第二判定サーバの処理の流れを説明するフローチャートを例示する。第二判定サーバは、第一サービス依頼の受信が可能になるたびに図３９のフローチャートを実行する。ステップＳ３９０１において、第一サービス依頼を受信する。例えば、第一サービス依頼の受信が可能になることを検出した後に第一判定サーバとの通信コネクションを確立し、得られるソケットを用いてｒｅａｄシステムコールをサービス依頼受信部（３５２２）において実行する。ステップＳ３９０２において、第一利用者及び第二利用者の共通識別情報を含む第二保証要求を生成する。この生成は、ステップＳ３９０１で受信された第一サービス依頼の内容に基づいて行なわれる。生成された第二保証要求は、例えば、メモリなどに一時的に記憶される。ステップＳ３９０３において、第二保証要求を送信する。この送信は、識別管理サーバとの通信コネクションを確立し、この確立で得られるソケットを用いたｗｒｉｔｅシステムコールを第二保証要求出力部（３５２３）において実行することで行なわれる。ステップＳ３９０４において、主従関係情報に基づく第二保証を受信する。この受信は、前記ソケットを用いたｒｅａｄシステムコールを第二保証受信部（３５２４）において実行することで行なわれる。ステップＳ３９０５において、ステップＳ３９０１にて受信した第一サービス依頼と、ステップＳ３９０４にて受信した第二保証に基づいて第一電子機器へサービス提供を許可する。

（実施形態３：識別管理サーバの構成）
図３５に示すように、識別管理サーバ（３５３０）は、識別管理部（３５３１）と、識別管理部検索部（３５３２）と、第二保証出力部（３５３３）とを有する。

「識別管理部」（３５３１）は、実施形態１で説明したものと同様である。

「識別管理部検索部」（３５３２）は、第二判定サーバが出力する第二保証要求に含まれる第一利用者及び第二利用者の共通識別情報をキーとして識別管理部（３５３１）を検索する。即ち、第一保証要求に含まれる第一利用者の共通識別情報と、第二利用者の共通識別情報を抽出し、これと合致する主従関係情報のレコードが識別管理部にて管理されているかどうか検索を行う。かかる検索では、第一利用者、第二利用者の共通識別情報により、各利用者の本システム内における唯一性を保証することができる。そして、さらに第一利用者と第二利用者とが主従関係を有しているかについても保証することができる。

「第二保証出力部」（３５３３）は、識別管理部での検索結果に基づいて前記第二保証を出力する。第二保証の出力先は、第二判定サーバである。識別管理部検索部における検索にて、第一利用者の共通識別情報と、第二利用者の共通識別情報とが合致する主従関係情報が得られた場合には、第一利用者と第二利用者とが主従関係を有していることを保証として出力することができる。なお、第一利用者と第二利用者の共通識別情報が、同一のレコードとして主従関係情報に含まれてはいるものの、その主従関係が逆転した要求である場合には、主従関係を保証しないために、第二保証を出力しなくてもよい。また、例えば利用者の共通識別情報が得られなかった場合や、一方の利用者の共通識別情報はレコード中に含まれているが、他方の利用者の共通識別情報が含まれていない場合などには、別途その旨をエラー情報として出力するとしてもよい。なお、第二判定サーバに対して出力する第二保証を識別管理サーバの秘密鍵で暗号化するとしてもよい。このとき、第二保証を受信した第二判定サーバでは識別管理サーバの公開鍵で復号化を行い、保証を確認できれば、改ざんやなりすましを予防でき有益である。

（実施形態３：識別管理サーバの処理）
図４０は、本実施形態に係るシステムの識別管理サーバの処理の流れを説明するフローチャートを例示する。識別管理サーバは、第二保証要求が受信可能となるたびに、このフローチャートで表わされる処理を実行する。ステップＳ４００１において、第二保証要求を受信する。このステップでは、例えば、第二判定サーバからの要求などにより確立された通信コネクションのソケットを参照したｒｅａｄシステムコールを識別管理部検索部（３５３２）において実行する。ステップＳ４００２において、受信された第二保証要求に含まれる第一利用者及び第二利用者の共通識別情報を得る。得られた結果は、例えば、メモリなどに一時的に記憶される。ステップＳ４００３において、第一利用者の共通識別情報と第二利用者の共通識別情報に基づいて、主従関係情報が管理されていることを確認する。このステップは、例えば、識別管理部検索部（３５３２）が識別管理部（３５３１）により記憶管理などされているデータに対して検索を行うことにより実行される。ステップＳ４００４において、ステップＳ４００３の結果に基づいて第二保証を生成する。生成された第二保証は、例えばメモリなどに一時的に記憶される。ステップＳ４００５において、ステップＳ４００４で生成された第二保証を第二判定サーバへ出力する。このステップでは、例えば、ステップＳ４００１で確立した通信コネクションを用いて、第二保証出力部（３５３３）において、ｗｒｉｔｅシステムコールを実行する。

<実施形態３：システム全体の処理の流れ>
図４１及び図４２は、実施形態３のシステムの処理の流れの具体的な一例を示したものである。また、図４３は、図４１及び図４２に示した処理の流れの全体像を示した図である。本例においては利用要求の一例として、第二利用者が第二電子機器にてダウンロードした個人情報を第一利用者の利用する第一電子機器においても利用可能とするために第二判定サーバを介して第二利用者のパスワードを取得することの要求を例示した。まず、Ｓ４１０１にて、第一電子機器にて、パスワードの取得要求が生成され、取得要求先として第二利用者の共通識別情報（ｍｏｍｏ）が入力される。続いて、Ｓ４１０２として、第一電子機器から第一判定サーバに対して「ｍｏｍｏ」のパスワード取得要求（利用要求）を出力する。この場合に、第一電子機器識別情報として「ｄｅｖｉｃｅ−ＡＢＣ」も併せて出力される。なお、Ｓ４１０２は、第一サービスサーバ群を経由してもよい。

次に、パスワード取得要求（利用要求）受け付けた第一判定サーバにて、第一電子機器識別情報（ｄｅｖｉｃｅ−ＡＢＣ）と関連付けられた第一利用者の共通識別情報（ｓａｋｕｒａ）を抽出する（Ｓ４１０３）。そして、第一判定サーバが、このパスワード要求（利用要求）に基づいて、第一利用者及び第二利用者の共通識別情報（ｓａｋｕｒａ、ｍｏｍｏ）を含む第一サービス依頼（パスワード要求）を第二判定サーバに対して出力する（Ｓ４１０４）。これを受け付けた第二判定サーバは、その受信した第一サービス依頼に基づいて第一利用者及び第二利用者の共通識別情報（ｓａｋｕｒａ、ｍｏｍｏ）を含む第二保証要求（主従関係保証要求）を識別管理サーバに対して出力する（Ｓ４１０５）。

識別管理サーバは、第二判定サーバが出力する第二保証要求（主従関係保証要求）に基づいて、システム内で利用者を一意に識別する共通識別情報に基づく主従関係情報を管理する識別管理部を検索する。具体的には第一利用者と第二利用者の共通識別情報（ｓａｋｕｒａ，ｍｏｍｏ）の唯一性の保証と、また、第一利用者の共通識別情報で識別される利用者（ここでは便宜的に「ｓａｋｕｒａ」とする）が、第二利用者の共通識別情報で識別される利用者（ここでは便宜的に「ｍｏｍｏ」とする）の「従」の関係にあること、即ち、第一利用者（ｓａｋｕｒａ）が第二利用者（ｍｏｍｏ）の利用するサービスを利用可能であることが、保証データとして生成される。このとき、検索結果に基づいて第一保証を出力すべきかどうかについての判定処理が行われてもよい。そして、その保証データを付した第二保証を生成する（Ｓ４１０６）。そして、識別管理サーバから第二判定サーバに対して第一利用者（ｓａｋｕｒａ）が第二利用者（ｍｏｍｏ）の「従」の関係にあるという保証（第二保証）を出力する（Ｓ４１０７）。

次に、第二判定サーバは、識別管理サーバから出力される第二保証（保証データ）を受信する。なお、第二判定サーバは、さらに、受信したパスワード取得要求（第一サービス依頼）と第二保証に基づいて、第二利用者（ｍｏｍｏ）が自身に登録されているかについて、第二関連保持部を、第二利用者の共通識別情報（ｍｏｍｏ）をキーとして検索する場合もある（Ｓ４１０８）。

次に図４２に移り、Ｓ４１０９にて、第二判定サーバにてパスワードの取得を行う。そして、第二判定サーバからは例えばＳ４１０８の検索結果にて抽出される第二電子機器識別情報にて識別される第二電子機器に対してパスワードの提供通知を行う（Ｓ４１１０）。その後、第二判定サーバから、第一判定サーバや第一電子機器に対してパスワードが送付される（Ｓ４１１１）。なお、実施形態１で説明したようなグレードという概念を実施形態３にも導入することももちろん可能である。

<実施形態３：実現形態>
図４４は、実施形態３の実現形態の一例を示す。第二判定サーバ（４４４０）を例に挙げて説明する。第二判定サーバ（４４４０）の物理的な構成としては、ＣＰＵ、メモリ、ハードディスク、入出力装置、ネットワークインターフェースなどからなるハードウェア（４４４０）として実現される。論理的には、ハードウェア（４４４１）の機能を抽象化したり、ハードウェア（４４４１）の動作を管理などするための基本ソフトウェアであるオペレーティングシステム（４４４２）が動作し、その上に、第二関連保持モジュール（４４４３）、サービス依頼受信モジュール（４４４４）、第二保証要求出力モジュール（４４４５）、第二保証受信モジュール（４４４６）、第二検索モジュール（４４４７）として、それぞれ、第二関連保持部（３５２１）、サービス依頼受信部（３５２２）、第二保証要求出力部（３５２３）、第二保証受信部（３５２４）、第二検索部（３８２５）を実現するモジュールを含んで構成されるプログラムが動作する。このプログラムは、例えば、図３９に例示した処理を実行する。なお、第二検索モジュール（３８２５）については、必須の実現形態ではない。

なお、第一判定サーバ（４４３０）や、識別管理サーバ（４４５０）についても、ハードウェアの上にオペレーティングシステムを動作させ、その上で各部を実現するモジュールを有するプログラムを動作させることにより実現できることは同様である。また、第一電子機器（４４１０）や、第二電子機器（４４２０）についても各サーバと同様に、ハードウェアの上にオペレーティングシステムを動作させ、その上で各部を実現するモジュールを有するプログラムを動作させることにより実現することができる。なお、電子機器では、ハードウェア（４４１１、４４２１）に関連付けて電子機器識別情報が格納されているものである。

<実施形態３：主な効果>
本実施形態は、サービスサーバ群と、電子機器と、判定サーバと、識別管理サーバと、からなるシステムである点は実施形態１と同じであるが、第一電子機器からの第二判定サーバの利用要求に基づいて、第一判定サーバから第一サービス依頼を受けた第二判定サーバは第二保証要求を識別管理サーバに対して出力し、これを受けて識別管理サーバにて、識別管理部の検索を行い、その検索結果に基づいて保証を出力する点が実施形態１と異なる。第一電子機器、第一サービスサーバ、第一判定サーバにおける垂直統合型のシステムの運営管理形態による利用者の識別管理を、他の垂直統合型のシステムの運営管理形態と連携させて、より柔軟なサービスが提供できる。このとき、信頼関係のないサーバからサービス依頼を受けた場合でも、識別管理サーバから付与される保証によって、システム内の信頼性が高まり、安全なサービス提供の環境が確保できる。

<<実施形態４>>
<実施形態４：概要>
実施形態４について以下に説明する。本実施形態は、実施形態１と同様に、サービスサーバ群と、電子機器と、判定サーバと、識別管理サーバと、からなるシステムである。実施形態１と異なり、第一電子機器からの第二判定サーバの利用要求に基づき第一判定サーバから出力される第三保証要求を受けた識別管理サーバが、主従関係情報そのものを含む第三保証を第一判定サーバに出力することに特徴を有する。図４５は、本実施形態の概念の一例を示す図である。図４５における大まかな処理の流れは下記の通りである。なお、各用語の示す意味などについては後の部分にて説明を行う。（１）利用者Aが利用する第一電子機器から第一判定サーバに対して第二判定サーバの利用要求を行う。なお、この利用要求は、第一判定サーバに対して要求してもよいし、第一サービスサーバ群を経由して要求してもよい。（２）利用要求を受けた第一判定サーバは、識別管理サーバに対して第三保証要求を行う。（３）第三保証要求を受けた識別管理サーバにおいては、主従関係情報を含む第三保証を第一判定サーバに対して出力する。（４）第三保証を受信した第一判定サーバは、その第三保証に含まれる主従関係情報を第一電子機器に転送する。（５）第一電子機器は、転送された主従関係情報の中から第二利用者を選択して、選択結果を第一判定サーバに通知する。（６）選択通知を受けた第一判定サーバは、その第二利用者のサービスを利用するため、第三保証付サービス依頼を第二判定サーバに対して出力する。なお、主従関係情報の転送や、選択結果の通知については第一サービスサーバ群を経由して行ってもよい。

実施形態４においては、識別管理サーバから、第一利用者の共通識別情報に基づく主従関係情報が、保証を示す情報とともに第一判定サーバに出力される。そして、第一判定サーバから、例えば第一電子機器に対して、主従関係情報に含まれる主従関係を有する第二利用者のうち、どの利用者のサービスを受けるかを問い合わせるなどして、その結果得られた第二利用者の共通識別情報を用いてサービス依頼を行うという点が特徴である。つまり、実施形態１から３で説明したシステムにおいては、第一電子機器から第二利用者の共通識別情報が利用要求に含まれていたが、実施形態４では、まず識別管理サーバから主従関係情報を受け取って、その中から任意の利用者を選択するなどして、第二利用者の共通識別情報をサービス依頼に含める点が特徴である。図４５の例で説明すると、実施形態１から３の場合には、第一利用者Ａは、まず最初に第二利用者Ｂ又は第二利用者Ｃを特定する必要があったが、実施形態４では、第一利用者Ａと主従関係がある利用者をサービス依頼を行う前に把握することができる。

<実施形態４：構成>
図４６は、実施形態４に係るシステムの全体のブロック図を例示する。実施形態４は、実施形態１と同様に、第一判定に基づいて第一サービスを第一電子機器（４６０３）に行う「第一サービスサーバ群」（４６０１）と、第二判定に基づいて第二サービスを第二電子機器（４６０４）に行う「第二サービスサーバ群」（４６０２）と、第一利用者が利用し、第一サービスサーバ群（４６０１）から第一サービスを受ける「第一電子機器」（４６０３）と、第二利用者が利用し、第二サービスサーバ群（４６０２）から第二サービスを受ける「第二電子機器」（４６０４）と、第一サービスサーバ群（４６０１）から前記第一サービスを受けるために、第一電子機器（４６０３）を第一電子機器識別情報に基づいて第一判定する「第一判定サーバ」（４６１０）と、第二サービスサーバ群（４６０２）から前記第二サービスを受けるために、第二電子機器（４６０４）を第二電子機器識別情報に基づいて第二判定する「第二判定サーバ」（４６２０）と、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を識別管理部（４６３１）にて管理する「識別管理サーバ」（４６３０）とからなるシステム（４６００）である。

図４７は、実施形態４の理解を促進するための主従関係を示す図である。図４７においては、子（共通識別情報：ｓａｋｕｒａ）は、父（共通識別情報：ｍｏｍｏ）及び母（共通識別情報：ｈａｎａｋｏ）との関係では、「従」の関係を有しており父と母のいずれのサービスも利用可能であることを示している。実施形態４は、図４７のように、第一利用者が子である場合を想定するとよい。つまり、第一利用者と主従関係（ここでは第一利用者に対して「主」となる関係）を有する、第二利用者となり得る利用者が複数いる場合において本実施形態の構成は効果的な構成となる。

（実施形態４：第一判定サーバの構成）
図４６に示すように、本実施形態に係るシステムの第一判定サーバ（４６１０）は、第一関連保持部（４６１１）と、第三保証要求出力部（４６１２）と、第三保証受信部（４６１３）と、主従関係情報転送部（４６１４）と、選択結果通知取得部（４６１５）と、第三保証付サービス依頼出力部（４６１６）とを有する。

「第一関連保持部」（４６１１）は、実施形態１で説明したものと同様である。

「第三保証要求出力部」（４６１２）は、第一電子機器からの第二判定サーバの利用要求に基づいて、第一利用者の共通識別情報を含む第三保証要求を出力する。第三保証要求の出力先は、識別管理サーバである。第三保証要求出力部による第三保証要求の出力の処理は、本件発明の目指す異なるサービスシステム間の横断的利用のために第一判定サーバから外部に対して最初に行なわれる処理である。第一利用者の共通識別情報は、既に説明したように、利用要求を行った第一電子機器の第一電子機器識別情報をキーとして、第一関連保持部を検索等することで取得することができるものである。図４８は、第三保証要求の一例を示す図である。第三保証要求は、その要求に含まれる第一利用者の唯一存在性の保証とともに、その第一利用者と、主従関係情報に含まれる共通識別情報で識別される利用者（第二利用者）とが、確かに主従関係を有することの保証を要求するものである。

「第三保証受信部」（４６１３）は、第三保証要求出力部（４６１２）から出力される第三保証要求に応じて識別管理サーバから返信される前記主従関係情報を含む第三保証を受信する。識別管理サーバ内の処理については後述する。第三保証には、第三保証要求に含まれる第一利用者の共通識別情報に基づいた主従関係情報が含まれる。即ち、第一利用者を「従」とした場合における「主」となる関係を有する利用者に関する情報を第三保証として受信する。図４９は、第三保証の一例を示す図である。図４９の例では、主従関係情報として、第一利用者の共通識別情報が含まれ、また、この第一利用者と主従関係を有する第二利用者の共通識別情報が、保証データとともに含まれている様子を示している。なお、第一利用者の共通識別情報を省略した形で主従関係情報を受信してもよい。

「主従関係情報転送部」（４６１４）は、前記第三保証受信部（４６１３）にて受信した第三保証に含まれる前記主従関係情報を第一電子機器に転送する。転送先の第一電子機器は、利用要求をした第一電子機器である。第一電子機器に転送する場合には、第一サービスサーバ群を経由して転送させてもよい。本実施形態の特徴としては、このように主従関係情報を第一電子機器に送り、どの第二利用者をサービス依頼先の利用者とするかの問い合わせを第一利用者に行うことが挙げられる。この結果、後述する第三保証付サービス依頼に含ませる第二利用者の共通識別情報を決定することができる。なお、主従関係情報を転送する場合には、主従関係情報を第一電子機器に適した所定の形式に変換してから転送してもよい。主従関係情報の転送を受けた第一電子機器においては、例えば第一利用者からのサービス利用対象となる第二利用者の入力を待って、その入力結果を後述する選択結果として第一判定サーバに通知する。

「選択結果通知取得部」（４６１５）は、主従関係情報転送部（４６１４）から転送された主従関係情報に示される第二利用者識別情報の中から第一電子機器にて選択された第二利用者の共通識別情報を含む選択結果通知を取得する。この選択結果通知によって、どの第二利用者をサービス依頼対象者とするかを第一判定サーバにて決定することができる。

「第三保証付サービス依頼出力部」（４６１６）は、選択結果取得部にて取得した選択結果通知に含まれる第二利用者の共通識別情報を含む第三保証付サービス依頼を出力する。第三保証付サービス依頼の出力先は、第二判定サーバである。具体的には、選択結果通知に含まれる第二利用者の共通識別情報と、第三保証とを併せてサービス依頼を出力する。既に説明したように、実施形態４の特徴としては、この保証付サービス依頼に含まれる第二利用者の共通識別情報が、第一電子機器から最初に入力された情報ではなく、識別管理サーバから主従関係情報として出力された中に含まれる情報であることが特徴である。このような処理を行うことで、第一利用者にとっては、確実に主従関係を有している利用者を特定してサービスを依頼することができるため、サービスの依頼がより迅速かつ確実に行われることが期待できる。第三保証付サービス依頼の一例としては、例えば、図１０の「保証付サービス依頼」を「第三保証付サービス依頼」に置換したものが挙げられる。

（実施形態４：第一判定サーバの処理）
図５０は、第一判定サーバの処理の流れを説明するフローチャートの一例を示した図である。第一判定サーバは、第一電子機器から第二判定サーバの利用要求を取得可能になるたびに、このフローチャートの処理を実行する。ステップＳ５００１において、第一電子機器から、第二判定サーバの利用要求を得る。例えば、ソケットを用いた通信におけるｒｅａｄシステムコールを第三保証要求出力部（４６１２）において実行する。ステップＳ５００２において、第一電子機器識別情報から第一利用者の共通識別情報を得る。例えば、ステップＳ５００１での利用要求を送信した第一電子機器の第一電子機器識別情報を取得し、その取得された第一電子機器識別情報で第一関連保持部（４６１１）などを検索することにより、第一利用者の共通識別情報が得られる。

ステップＳ５００３では、ステップＳ５００１、Ｓ５００２で得られた情報を参照して、第一利用者の共通識別情報を含む第三保証要求を生成する。例えば、図４８に例示された第三保証要求を生成し、メモリに記憶する。ステップＳ５００４では、第三保証要求を出力する。例えば、識別管理サーバと通信コネクションを確立し、得られるソケットを用いてｗｒｉｔｅシステムコールを第三保証要求出力部（４６１２）において実行する。

ステップＳ５００５では、主従関係情報を含む第三保証を受信する。例えば、ステップＳ５００４で確立した通信コネクションのソケットを用いたｒｅａｄシステムコールを第三保証受信部（４６１３）において実行する。ステップＳ５００６では、ステップＳ５００５にて受信した第三保証に含まれる主従関係情報を、第一電子機器に転送する。例えば、ステップＳ５００１で確立した通信コネクションのソケットを用いてｗｒｉｔｅシステムコールを主従関係情報転送部（４６１４）において実行する。ステップＳ５００７では、第一電子機器にて選択された第二利用者の共通識別情報を含む選択結果通知を取得する。例えばステップＳ５００１にて確立した通信コネクションのソケットを用いてｒｅａｄシステムコールを選択結果通知取得部（４６１５）において実行する。ステップＳ５００７では、ステップＳ５００６にて取得した選択結果通知からサービス依頼先の第二利用者を決定する。ステップＳ５００８では、受信した第三保証に基づいて、ステップＳ５００８にて決定した第二利用者の共通識別情報を含む第三保証付サービス依頼を生成する。ステップＳ５００９では、第三保証付サービス依頼を出力する。例えば、第二判定サーバに対する通信コネクションを確立し、得られるソケットを用いてｗｒｉｔｅシステムコールを第三保証付サービス依頼出力部（４６１６）において実行する。

（実施形態４：第二判定サーバの構成）
図４６に示すように、第二判定サーバ（４６２０）は、第二関連保持部（４６２１）と、第三保証付サービス依頼受信部（４６２２）とを有している。

「第二関連保持部」（４６２１）は、第二利用者の共通識別情報と、第二電子機器識別情報とを関連付けて保持する。第二関連保持部は実施形態１で説明したものと同様である。

なお、第二判定サーバ（４６２０）は、「第二検索部」を有していてもよい。「第二検索部」（図示しない）は、第三保証付サービス依頼受信部（４６２２）にて受信した第三保証付サービス依頼に基づいて第二関連保持部（４６２１）を、第二利用者の共通識別情報をキーとして検索する。第二利用者の共通識別情報をキーとする検索とは、第三保証付サービス依頼に含まれる第二利用者の共通識別情報を抽出し、これと合致する共通識別情報が第二関連保持部にて保持されているかどうかの検索を行うことをいう。合致する共通識別情報が得られた場合には、保証付サービス依頼に応じたサービスの提供（第一サービスの利用料の支払い、暗号化コンテンツ等の復号鍵送信、パスワード送信など）を行うとしてもよい。また、検索結果は、第一判定サーバや、第二電子機器（第二サービスサーバ群を経由してもよい）に送信するとしてもよい。

（実施形態４：第二判定サーバの処理）
図５１は、本実施形態に係るシステムの第二判定サーバの処理の流れを説明するフローチャートを例示する。第二判定サーバは、第三保証付サービス依頼の受信が可能になるたびに、図５１のフローチャートの処理を実行する。ステップＳ５１０１において、第三保証付サービス依頼を受信する。例えば、第三保証付サービス依頼の受信が可能になることを検出した後に、第一判定サーバとの通信コネクションを確立し、得られるソケットを用いて、ｒｅａｄシステムコールを第三保証付サービス依頼受信部（４６２２）で実行する。ステップＳ５１０２において、ステップＳ５１０１で受信した第三保証付サービス依頼から第二利用者の共通識別情報を得る。ステップＳ５１０３において、ステップＳ５１０１で受信した第三保証付サービス依頼の真正性を確認する。例えば、識別管理サーバの公開鍵を用いて、署名などの検証を行う。また、ステップＳ５１０２にて得た共通識別情報で識別される第二利用者が、第一利用者と主従関係を有していることの証明を得る。

ステップＳ５１０４において、ステップＳ５１０２で得られた第二利用者の共通識別情報が第二関連保持部に保持されていることを確認する。この確認により、第三保証付サービス依頼に含まれる第二利用者が、第二判定サーバでの判定によりサービスの提供が行なわれる第二電子機器の利用者であることが確認できる。これにより、第二判定サーバ側で、サービスの提供の対価などの課金の処理を行うことができる。ステップＳ５１０５では、ステップＳ５１０４での確認に基づいて、第一電子機器へのサービスの提供を許可する。例えば、第二サービスサーバ群のサーバに対して、第一電子機器へ向けてサービスを提供するように命令を行う。

（実施形態４：識別管理サーバの構成）
図４６に示すように、識別管理サーバ（４６３０）は、識別管理部（４６３１）と、識別管理部検索部（４６３２）と、第三保証出力部（４６３３）と、を有する。

識別管理部（４６３１）については既に説明した。識別管理部（４６３１）により、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理する。共通識別情報は、利用者などによって予め登録が行われることによって発行され、第一判定サーバ、及び、第二判定サーバに対して付与することが想定される。ただし、共通識別情報が判定サーバに対して与えられるための流通経路は各種考えられ、一に限定されるものではない。この共通識別情報により、本システム内における識別情報が、唯一であることが保証される。また、同様に、共通識別情報に基づく主従関係情報は、利用者などによって予め識別管理サーバに対して登録が行われることが想定される。そして、その共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理することで、例えば、第一利用者が、第二利用者との相対関係において、「従」の関係を有していることを保証することができる。

「識別管理部検索部」（４６３２）は、第一判定サーバが出力する第三保証要求に含まれる第一利用者の共通識別情報をキーとして識別管理部の前記主従関係情報を検索する。まず、第一保証要求に含まれる第一利用者の共通識別情報を抽出し、これと合致する主従関係情報のレコードが識別管理部にて管理されているかどうか検索を行う。

「第三保証出力部」（４６３３）は、識別管理部検索部での検索結果に基づいて前記第三保証を出力する。第三保証の出力先は、第一判定サーバである。識別管理部検索部における検索にて、第一利用者の共通識別情報を含む主従関係情報が得られた場合には、その主従関係情報に含まれる第二利用者は、第一利用者との間で確かに主従関係を有しているということを保証として出力することができる。なお、例えば利用者の共通識別情報が得られなかった場合や、第一利用者が主従関係を有していない場合などには、別途その旨をエラー情報として出力するとしてもよい。なお、第一判定サーバに対して出力する第三保証に含まれる保証データを識別管理サーバの秘密鍵で暗号化するとしてもよい。このとき、第三保証付サービス依頼を受信する第二判定サーバでは識別管理サーバの公開鍵で復号化を行い、保証を確認できれば、改ざんやなりすましを予防でき有益である。

（実施形態４：識別管理サーバの処理）
図５２は、識別管理サーバの処理の流れを説明するフローチャートを例示する。識別管理サーバは、第三保証要求の受信が可能になるごとに、図５２に例示されたフローチャートの処理を行う。ステップＳ５２０１において、第三保証要求を受信する。例えば、第一判定サーバからの通信コネクションの確立の要求に応じて生成されるソケットを用いて、識別管理部検索部（４６３２）などにおいてｒｅａｄシステムコールを実行する。ステップＳ５２０２において、第三保証要求に含まれる第一利用者の共通識別情報を得る。ステップＳ５２０３において、ステップＳ５２０２で得られた第一利用者の共通識別情報に基づいて、主従関係情報が識別管理部（４６３１）で管理されているかどうかを、識別管理部を検索することにより確認する。ステップＳ５２０４において、ステップＳ５２０３での確認に基づいて第三保証を生成して、メモリなどの記憶手段にすくなくとも一時的に記憶する。ステップＳ５２０５において、ステップＳ５２０４で生成して記憶された第一保証を出力する。例えば、ステップＳ５２０１で確立した通信コネクションによるソケットを用いたｗｒｉｔｅシステムコールを第三保証出力部（４６３３）において実行する。

<実施形態４：システム全体の処理の流れ>
図５３及び図５４は、実施形態４のシステムの処理の流れの具体的な一例を示したものである。また、図５５は、図５３及び図５４に示した処理の流れの全体像を示した図である。本例においては利用要求の一例として、第二判定サーバを介して第一サービスの利用料を支払うことの要求を例示した。まず、Ｓ５３０１にて、第一電子機器から第一サービスサーバ群の一部である第一サービスサーバに対してコンテンツの購入要求を出力する。購入要求を受け付けた第一サービスサーバにおいては、購入費用３００円の支払い先を入力するように第一電子機器に対して要求を出力する。第一電子機器においては、第三者（第二利用者）に支払いを要求する。続いて、Ｓ５３０２として、第一電子機器から第一サービスサーバに対して第三者（第二利用者）への課金要求（利用要求）を出力する。この場合に、第一電子機器識別情報として「ｄｅｖｉｃｅ−ＡＢＣ」も併せて出力される。そして、第一サービスサーバにおいては、第一電子機器からの課金要求を受け付けて、その課金要求を第一判定サーバに対して出力する。なお、ステップＳ５３０２については、第一サービスサーバを経由することなく、第一電子機器から第一判定サーバに対して課金要求が直接出力されるとしてもよい。

次に、課金要求（利用要求）を受け付けた第一判定サーバにて、第一電子機器識別情報（ｄｅｖｉｃｅ−ＡＢＣ）と関連付けられた第一利用者の共通識別情報（ｓａｋｕｒａ）を抽出する（Ｓ５３０３）。そして、受け付けた課金要求（利用要求）に基づいて、第一利用者の共通識別情報（ｓａｋｕｒａ）を含む第三保証要求（主従関係保証要求）を出力する（Ｓ５３０４）。

識別管理サーバは、第一判定サーバが出力する第三保証要求に基づいて、システム内で利用者を一意に識別する共通識別情報に基づいて第一利用者と第二利用者との主従関係情報を管理する識別管理部を検索する。具体的には第一利用者の共通識別情報で識別される利用者（ここでは便宜的に「ｓａｋｕｒａ」とする）が、第二利用者の共通識別情報で識別される複数の利用者（ここでは便宜的に「ｍｏｍｏ」「ｈａｎａｋｏ」とする）の「従」の関係にあること、即ち、第一利用者（ｓａｋｕｒａ）が第二利用者（ｍｏｍｏ，ｈａｎａｋｏ）の利用するサービスを利用可能であることと、第一利用者と第二利用者の共通識別情報（ｓａｋｕｒａ，ｍｏｍｏ，ｈａｎａｋｏ）の唯一性の保証とが、保証データとして生成される（Ｓ５３０５）。このとき、検索結果に基づいて第三保証を出力すべきかどうかについての判定処理が行われてもよい。そして、識別管理サーバから第一判定サーバに対して検索結果に基づいて主従関係情報（ｓａｋｕｒａ，ｍｏｍｏ，ｈａｎａｋｏ）をそのまま含む保証（第三保証）を出力する（Ｓ５３０６）。

次に、第一判定サーバは、識別管理サーバから返信される保証（第三保証）を受信し、受信した第三保証に含まれる主従関係情報（ｍｏｍｏ、ｈａｎａｋｏ）を第一電子機器に転送する（Ｓ５３０７）。なお、転送する場合には、第一判定サーバ内にて保持されている第一利用者の共通識別情報（ｓａｋｕｒａ）に関しては転送しなくてもよい。

転送を受信した第一電子機器は、転送された主従関係情報の中からサービス依頼対象の第二利用者の共通識別情報（ｍｏｍｏ）を選択し、その選択結果を第一判定サーバに対して通知する（Ｓ５３０８）。

選択結果通知を受けた第一判定サーバは、選択された第二利用者の共通識別情報（ｍｏｍｏ）を含めて第三保証付サービス依頼を出力する（Ｓ５３０９）。Ｓ５３０９では、具体的には、第一利用者（ｓａｋｕｒａ）が第二利用者（ｍｏｍｏ）の「従」の関係にあるという保証を含めた第二利用者（ｍｏｍｏ）への課金要求が出力される。なお、Ｓ５３０９にて出力される第三保証付サービス依頼には、そのサービス依頼元の利用者の情報として、第一利用者の共通識別情報（ｓａｋｕｒａ）が含まれていてもよい。

第二判定サーバは、第三保証付サービス依頼（保証付課金要求）を受信する。なお、第二判定サーバは、さらに受信した第三保証付サービス依頼に基づいて、第二利用者（ｍｏｍｏ）が自身に登録されているかについて、第二関連保持部を、第二利用者の共通識別情報（ｍｏｍｏ）をキーとして検索する場合もある（Ｓ５３１０）。

次に、図５４に移り、第二判定サーバにおいては、第二関連保持部を検索した結果、第二利用者の共通識別情報（ｍｏｍｏ）を検出したため、その共通識別情報と関連付けられている第二電子機器識別情報にて識別される第二電子機器に対して課金を実行する。具体的には、第二サービスサーバ群の一部である課金サーバに対して課金命令を出力することなどによって課金の実行がなされる（Ｓ５３１１）。その後、第二判定サーバを通じて、第一判定サーバや第一電子機器に対して課金の完了通知がなされる（Ｓ５３１２）。なお、実施形態１で説明したようなグレードという概念を実施形態４にも導入することももちろん可能である。

<実施形態４：実現形態>
図５６は、実施形態４の実現形態の一例を示す。第一判定サーバ（５６３０）を例に挙げて説明する。第一判定サーバ（５６３０）は、物理的な構成としては、ＣＰＵ、メモリ、ハードディスク、入出力装置、ネットワークインターフェースなどからなるハードウェア（５６３１）として実現される。論理的には、ハードウェア（５６３１）の機能を抽象化したり、ハードウェア（５６３１）の動作を管理などするための基本ソフトウェアであるオペレーティングシステム（５６３２）が動作し、その上に、第一関連保持モジュール（５６３３）、第三保証要求出力モジュール（５６３４）、第三保証受信モジュール（５６３５）、主従関係情報転送モジュール（５６３６）、選択結果通知取得モジュール（５６３７）、第三保証付サービス依頼出力モジュール（５６３８）として、それぞれ、第一関連保持部（４６１１）、第三保証要求出力部（４６１２）、第三保証受信部（４６１３）、主従関係情報転送部（４６１４）、選択結果通知取得部（４６１５）、第三保証付サービス依頼出力部（４６１６）を実現するモジュールを含んで構成されるプログラムが動作する。このプログラムは、例えば、図４６に例示した処理を実行する。

なお、第二判定サーバ（５６４０）や、識別管理サーバ（５６５０）についても、ハードウェアの上にオペレーティングシステムを動作させ、その上で各部を実現するモジュールを有するプログラムを動作させることにより実現できることは同様である。また、第一電子機器（５６１０）や、第二電子機器（図示しない）についても各サーバと同様に、ハードウェアの上にオペレーティングシステムを動作させ、その上で各部を実現するモジュールを有するプログラムを動作させることにより実現することができる。なお、電子機器では、ハードウェア（５６１１）に関連付けて電子機器識別情報が格納されているものである。

<実施形態４：主な効果>
以上開示されたシステムの構成では、一の電子機器が一のサービス体系に縛られず、サービス体系の垣根を取り払うことができる。また、第一利用者は、主従関係を有していると保証されている利用者を第二利用者としてサービスを依頼することが可能となるため、より確実にサービスの提供を受けることが可能となる。

従来のシステムにおける問題点を示す図 本件発明の概要を説明するための図 主従関係情報を説明するための図 実施形態１を説明するための概念図 実施形態１の機能ブロック図 実施形態１の識別管理サーバの識別管理部が記憶管理などする情報の一例を示す図 実施形態１の第一関連保持部が保持するテーブルの一例を示す図 利用要求の一例を示す図 第一保証要求の一例を示す図 保証付サービス依頼の一例を示す図 実施形態１の第一判定サーバの処理の流れを説明する図 実施形態１の第二関連保持部が保持するテーブルの一例を示す図 実施形態１の第二の機能ブロック図 実施形態１の第二判定サーバの処理の流れを説明する図 実施形態１の識別管理サーバの処理の流れを説明する図 実施形態１のシステム全体の処理の流れを説明するシーケンス第一図 実施形態１のシステム全体の処理の流れを説明するシーケンス第二図 実施形態１のシステム全体の処理の流れを説明するシーケンス第三図 実施形態１のシステム全体の処理の流れの全体像を説明するための図 実施形態１の実現形態の一例を示す図 実施形態１のハードウェア構成の一例を示す図 実施形態２を説明するための概念図 実施形態２の機能ブロック図 実施形態２の保証要求付サービス依頼の一例を示す図 実施形態２の第一判定サーバの処理の流れを説明する図 実施形態２の第二保証付サービス依頼の一例を示す図 実施形態２の第二の機能ブロック図 実施形態２の第二判定サーバの処理の流れを説明する図 実施形態２の識別管理サーバの処理の流れを説明する図 実施形態２のシステム全体の処理の流れを説明するシーケンス第一図 実施形態２のシステム全体の処理の流れを説明するシーケンス第二図 実施形態２のシステム全体の処理の流れの全体像を説明するための図 実施形態２の実現形態の一例を示す図 実施形態３を説明するための概念図 実施形態３の機能ブロック図 実施形態３の第一サービス依頼の一例を示す図 実施形態３の第一判定サーバの処理の流れの一例を示す図 実施形態３の第二の機能ブロック図 実施形態３の第二判定サーバの処理の流れの一例を示す図 実施形態３の識別管理サーバの処理の流れの一例を示す図 実施形態３のシステム全体の処理の流れを説明するシーケンス第一図 実施形態３のシステム全体の処理の流れを説明するシーケンス第二図 実施形態３のシステム全体の処理の流れの全体像を説明するための図 実施形態３の実現形態の一例を示す図 実施形態４を説明するための概念図 実施形態４の機能ブロック図 実施形態４を説明するための主従関係を示す図 実施形態４の第三保証要求の一例を示す図 実施形態４の第三保証の一例を示す図 実施形態４の第一判定サーバの処理の流れを説明する図 実施形態４の第二判定サーバの処理の流れを説明する図 実施形態４の識別管理サーバの処理の流れを説明する図 実施形態４のシステム全体の処理の流れを説明するシーケンス第一図 実施形態４のシステム全体の処理の流れを説明するシーケンス第二図 実施形態４のシステム全体の処理の流れの全体像を説明するための図 実施形態４の実現形態の一例を示す図

符号の説明

５０１ 第一電子機器
５０２ 第一サービスサーバ群
５０３ 第二電子機器
５０４ 第二サービスサーバ群
５１０ 第一判定サーバ
５１１ 第一関連保持部
５１２ 第一保証要求出力部
５１３ 第一保証受信部
５１４ 保証付サービス依頼出力部
５２０ 第二判定サーバ
５２１ 第二関連保持部
５２２ 保証付サービス依頼受信部
５３０ 識別管理サーバ
５３１ 識別管理部
５３２ 識別管理部検索部
５３３ 第一保証出力部

Claims (8)

1. 第一利用者が利用する第一電子機器に対して第一サービスを提供する第一サービスサーバから前記第一電子機器が前記第一サービスを受ける際に、前記第一電子機器に対して固有に付与されるとともに改ざんすることができない状態で前記第一電子機器に保存されている第一電子機器識別情報を前記第一電子機器から受信し、前記第一電子機器識別情報に基づいて前記第一サービスの提供の可否を判定する第一判定を行う第一判定サーバであって、
   前記第一利用者を一意に識別する第一利用者共通識別情報と前記第一電子機器識別情報とを関連付けて保持する第一関連保持部を有するとともに、
   前記第一電子機器から前記第一電子機器識別情報および前記第一利用者とは異なる第二利用者を一意に識別する第二利用者共通識別情報を含む前記第一判定サーバとは異なる第二判定サーバの利用要求を受信した際には、前記第一関連保持部で保持された前記第一電子機器識別情報に対応する前記第一利用者共通識別情報を得るとともに、前記第一利用者共通識別情報及び前記第二利用者共通識別情報を含めて前記第一利用者と前記第二利用者との相対関係を証明する第一保証の発行の要求である第一保証要求を識別管理サーバに対して出力する第一保証要求出力部と、
   前記識別管理サーバから返信される前記第一保証を受信する第一保証受信部と、
   前記第一保証および前記第二利用者共通識別情報を含めて前記第一利用者に対する第二サービスの利用要求である保証付サービス依頼を前記第二判定サーバに対して出力する保証付サービス依頼出力部と、
   を有する第一判定サーバ。
2. 第一利用者を一意に識別する第一利用者共通識別情報および前記第一利用者とは異なる第二利用者を一意に識別する第二利用者共通識別情報を用いて、前記第一利用者と前記第二利用者との相対的関係を主従関係情報として管理する識別管理部と、
   第一判定サーバから入力された前記第一利用者共通識別情報及び前記第二利用者共通識別情報に基づいて、前記識別管理部で管理されている前記主従関係情報を検索する識別管理部検索部と、
   前記識別管理部検索部での検索結果に基づいて、前記第一利用者と前記第二利用者との相対的関係を証明する第一保証を発行し、前記第一判定サーバに出力する第一保証出力部と、
   を有する識別管理サーバであり、
   前記第一判定サーバから入力された前記第一利用者共通識別情報は、前記第一利用者が利用する第一電子機器に対して固有に付与されるとともに改ざんすることができない状態で前記第一電子機器に保存されている第一電子機器識別情報を前記第一電子機器から前記第一判定サーバが受信し、前記第一判定サーバに設けられた前記第一利用者共通識別情報と前記第一電子機器識別情報とを関連付けて保持した第一関連保持部で、受信した前記第一電子機器識別情報が前記第一利用者共通識別情報に変換されたものであり、
   前記第一判定サーバから入力された前記第二利用者共通識別情報は、前記第一電子機器に入力されたものが前記第一判定サーバを介して入力されたものであることを特徴とする、識別管理サーバ。
3. 第一利用者が利用する第一電子機器に対して第一サービスを提供する第一サービスサーバから前記第一電子機器が前記第一サービスを受ける際に、前記第一電子機器に対して固有に付与されるとともに改ざんすることができない状態で前記第一電子機器に保存されている第一電子機器識別情報を前記第一電子機器から受信し、前記第一電子機器識別情報に基づいて前記第一サービスの提供の可否を判定する第一判定を行う第一判定サーバであって、
   前記第一利用者を一意に識別する第一利用者共通識別情報と前記第一電子機器識別情報とを関連付けて保持する第一関連保持部を有するとともに、
   前記第一電子機器から前記第一電子機器識別情報および前記第一利用者とは異なる第二利用者を一意に識別する第二利用者共通識別情報を含む前記第一判定サーバとは異なる第二判定サーバの利用要求を受信した際には、前記第一関連保持部で保持された前記第一電子機器識別情報に対応する前記第一利用者共通識別情報を得るとともに、前記第二判定サーバを識別するための第二判定サーバ識別情報、前記第一利用者共通識別情報、及び前記第二利用者共通識別情報を含めて前記第一利用者と前記第二利用者との相対関係を証明する第二保証の発行および第二判定サーバに対するサービス依頼の要求である保証要求付サービス依頼を識別管理サーバに対して出力する保証要求付サービス依頼出力部と、
   を有する第一判定サーバ。
4. 第一利用者を一意に識別する第一利用者共通識別情報および前記第一利用者とは異なる第二利用者を一意に識別する第二利用者共通識別情報を用いて、前記第一利用者と前記第二利用者との相対的関係を主従関係情報として管理する識別管理部と、
   第一判定サーバから入力された前記第一利用者共通識別情報及び前記第二利用者共通識別情報に基づいて、前記識別管理部で管理されている前記主従関係情報を検索する識別管理部検索部と、
   前記識別管理部検索部での検索結果に基づいて、前記第一利用者と前記第二利用者との相対的関係を証明する第二保証を発行するとともに、前記第一利用者に対する第二サービスサーバが提供する第二サービスの利用要求である保証付サービス依頼を、第二判定サーバに対して出力する第二保証付サービス依頼出力部と、
   を有する識別管理サーバであり、
   前記第一判定サーバから入力された前記第一利用者共通識別情報は、前記第一利用者が利用する第一電子機器に対して固有に付与されるとともに改ざんすることができない状態で前記第一電子機器に保存されている第一電子機器識別情報を前記第一電子機器から前記第一判定サーバが受信し、前記第一判定サーバに設けられた前記第一利用者共通識別情報と前記第一電子機器識別情報とを関連付けて保持した第一関連保持部で、受信した前記第一電子機器識別情報が前記第一利用者共通識別情報に変換されたものであり、
   前記第一判定サーバから入力された前記第二利用者共通識別情報は、前記第一電子機器に入力されたものが前記第一判定サーバを介して入力されたものであることを特徴とする、識別管理サーバ。
5. 第一利用者が利用する第一電子機器に対して第一サービスを提供する第一サービスサーバから前記第一電子機器が前記第一サービスを受ける際に、前記第一電子機器に対して固有に付与されるとともに改ざんすることができない状態で前記第一電子機器に保存されている第一電子機器識別情報を前記第一電子機器から受信し、前記第一電子機器識別情報に基づいて前記第一サービスの提供の可否を判定する第一判定を行う第一判定サーバであって、
   前記第一利用者を一意に識別する第一利用者共通識別情報と前記第一電子機器識別情報とを関連付けて保持する第一関連保持部を有するとともに、
   前記第一電子機器から前記第一電子機器識別情報および前記第一利用者とは異なる第二利用者を一意に識別する第二利用者共通識別情報を含む前記第一判定サーバとは異なる第二判定サーバの利用要求を受信した際には、前記第一関連保持部で保持された前記第一電子機器識別情報に対応する前記第一利用者共通識別情報を得るとともに、前記第一利用者共通識別情報及び前記第二利用者共通識別情報を含めて前記第二判定サーバに対するサービス依頼の要求であるサービス依頼を前記第二判定サーバに対して出力するサービス依頼出力部と、
   を有する第一判定サーバ。
6. 第一利用者を一意に識別する第一利用者共通識別情報および前記第一利用者とは異なる第二利用者を一意に識別する第二利用者共通識別情報を用いて、前記第一利用者と前記第二利用者との相対的関係を主従関係情報として管理する識別管理部と、
   第二判定サーバから入力された前記第一利用者共通識別情報及び前記第二利用者共通識別情報に基づいて、前記識別管理部で管理されている前記主従関係情報を検索する識別管理部検索部と、
   前記識別管理部検索部での検索結果に基づいて、前記第一利用者と前記第二利用者との相対的関係を証明する第二保証を発行し、前記第二判定サーバに出力する第二保証出力部と、
   を有する識別管理サーバであり、
   前記第二判定サーバから入力された前記第一利用者共通識別情報は、前記第一利用者が利用する第一電子機器に対して固有に付与されるとともに改ざんすることができない状態で前記第一電子機器に保存されている第一電子機器識別情報を前記第一電子機器から第一判定サーバが受信し、前記第一判定サーバに設けられた前記第一利用者共通識別情報と前記第一電子機器識別情報とを関連付けて保持した第一関連保持部で、受信した前記第一電子機器識別情報が前記第一利用者共通識別情報に変換され第二判定サーバに出力されたものであり、
   前記第二判定サーバから入力された前記第二利用者共通識別情報は、前記第一電子機器に入力されたものが前記第一判定サーバおよび前記第二判定サーバを介して入力されたものであることを特徴とする、識別管理サーバ。
7. 第一利用者が利用する第一電子機器に対して第一サービスを提供する第一サービスサーバから前記第一電子機器が前記第一サービスを受ける際に、前記第一電子機器に対して固有に付与されるとともに改ざんすることができない状態で前記第一電子機器に保存されている第一電子機器識別情報を前記第一電子機器から受信し、前記第一電子機器識別情報に基づいて前記第一サービスの提供の可否を判定する第一判定を行う第一判定サーバであって、
   前記第一利用者を一意に識別する第一利用者共通識別情報と前記第一電子機器識別情報とを関連付けて保持する第一関連保持部を有するとともに、
   前記第一電子機器から前記第一電子機器識別情報および前記第一利用者とは異なる第二利用者を一意に識別する第二利用者共通識別情報を含む前記第一判定サーバとは異なる第二判定サーバの利用要求を受信した際には、前記第一関連保持部で保持された前記第一電子機器識別情報に対応する前記第一利用者共通識別情報を得るとともに、前記第一利用者共通識別情報及び前記第二利用者共通識別情報を含めて前記第一利用者と前記第二利用者との相対関係を証明する第三保証の発行の要求である第三保証要求を識別管理サーバに対して出力する第三保証要求出力部と、
   前記識別管理サーバから返信される前記第三保証を受信する第三保証受信部と、
   前記第三保証受信部にて受信した前記第三保証に含まれる、前記第一利用者と前記第二利用者の主従関係を示す主従関係情報を前記第一電子機器に転送する主従関係情報転送部と、
   前記主従関係情報転送部から転送された前記主従関係情報に示される前記第二利用者共通識別情報の中から前記第一電子機器にて選択された前記第二利用者の前記第二利用者共通識別情報を含む選択結果通知を前記第一電子機器から取得する選択結果通知取得部と、
   前記第三保証および選択された前記第二利用者共通識別情報を含めて前記第一利用者に対する第二サービスの利用要求である保証付サービス依頼を前記第二判定サーバに対して出力する保証付サービス依頼出力部と、
   を有する第一判定サーバ。
8. 請求項１、３、５または７記載の第一判定サーバと、
   前記第一サービスを、前記第一利用者が利用する前記第一電子機器に対して提供する前記第一サービスサーバと、
   を有する第一サービス提供システム。

Images