(57)【要約】【課題】利用者識別情報のセキュリティを向上させ、かつ、低コストに課金決済システムを構築することを課題とする。【解決手段】課金決済業者Ｋは、利用者識別情報Ｋ−ＩＤ（Ｕ）を暗号化した認証値Ｃ１を利用者Ｕに受け渡す。サービス事業者Ｓは、利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化した値Ｄ１および利用者Ｕから受け取った認証値Ｃ１を課金決済業者Ｋに送信する。課金決済業者Ｋは、認証値Ｃ１を復号化して識別情報Ｋ−ＩＤ（Ｕ）を生成し、Ｋ−ＩＤ（Ｕ）と値Ｄ１との排他的論理和値Ｘ１を暗号化してリンク値Ｌ１を生成する。サービス事業者Ｓは、利用者Ｕの利用料金ＳＵＭ１、値Ｄ１およびリンク値Ｌ１を課金決済業者Ｋに送信する。課金決済業者Ｋは、リンク値Ｌ１を復号化して値Ｘ１を生成し、この値Ｘ１と値Ｄ１の排他的論理和から課金対象者である利用者Ｕの識別情報Ｋ−ＩＤ（Ｕ）を取得する。【選択図】        図１
2005309747.tif 000002
【特許請求の範囲】
【請求項１】
サービス事業者が利用者に提供するサービスについて課金決済を行う課金決済業者の課金決済装置であって、
前記課金決済業者が前記利用者を一意に識別するために発行した利用者識別情報Ｋ−ＩＤ（Ｕ）および前記サービス事業者が前記利用者を一意に識別するために発行した利用者識別情報Ｓ−ＩＤ（Ｕ）の関係を示す情報を暗号化してリンク値Ｌを生成するリンク値生成手段と、
前記サービス事業者の端末から前記利用者の課金に係る課金情報とともに前記リンク値生成手段によって生成されたリンク値Ｌを受け付け、当該リンク値Ｌから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を復号化して前記課金情報による決済を行う決済手段と、
を備えたことを特徴とする課金決済装置。
【請求項２】
前記リンク値生成手段は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを受け付け、当該値Ｄと前記利用者識別情報Ｋ−ＩＤ（Ｕ）との排他的論理和Ｘを暗号化してリンク値Ｌを生成し、
前記決済手段は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを前記課金情報およびリンク値Ｌとともに受け付け、当該リンク値Ｌを復号化して前記排他的論理和Ｘを生成し、当該排他的論理和Ｘおよび前記値Ｄから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得することを特徴とする請求項１に記載の課金決済装置。
【請求項３】
前記利用者識別情報Ｋ−ＩＤ（Ｕ）を暗号化して、前記利用者を認証したことを示す認証値Ｃを生成する認証値生成手段をさらに備え、
前記リンク値生成手段は、前記サービス事業者の端末から前記認証値生成手段によって生成された認証値Ｃを前記値Ｄとともに受け付け、当該認証値Ｃを復号化して前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得し、当該利用者識別情報Ｋ−ＩＤ（Ｕ）と前記値Ｄとの排他的論理和Ｘを暗号化して前記リンク値Ｌを生成することを特徴とする請求項１または２に記載の課金決済装置。
【請求項４】
前記リンク値生成手段および決済手段は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記リンク値Ｌの暗号化または復号化を行うことを特徴とする請求項１、２または３に記載の課金決済装置。
【請求項５】
前記認証値生成手段および決済手段は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記認証値Ｃの暗号化または復号化を行うことを特徴とする請求項３に記載の課金決済装置。
【請求項６】
前記決済手段は、前記利用者が支払う課金料金額を含んだ課金情報を前記サービス事業者の端末から受け付け、当該課金情報に含まれる課金料金額を用いて決済を行うことを特徴とする請求項１〜５のいずれか一つに記載の課金決済装置。
【請求項７】
前記課金決済業者による課金決済のサービスについて前記サービス事業者が支払う課金料金額を算出する課金処理手段をさらに備え、
前記決済手段は、前記利用者について決済を行うとともに、前記課金処理手段によって算出された前記サービス事業者が支払う課金料金額、および、前記利用者が支払う課金料金額を用いて当該サービス事業者について決済を行うことを特徴とする請求項１〜６のいずれか一つに記載の課金決済装置。
【請求項８】
前記課金決済業者は、他のサービス事業者が前記サービス事業者に提供するサービスについても課金決済を行うものであって、
前記リンク値生成手段は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）および前記他のサービス事業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｒ−ＩＤ（Ｓ）の関係を示す情報を暗号化してリンク値Ｌを生成し、
前記決済手段は、前記他のサービス事業者の端末から前記サービス事業者の課金に係る課金情報とともに前記リンク値生成手段によって生成されたリンク値Ｌを受け付け、当該リンク値Ｌから前記サービス事業者情報Ｋ−ＩＤ（Ｓ）を復号化して前記課金情報による決済を行うことを特徴とする請求項１〜７のいずれか一つに記載の課金決済装置。
【請求項９】
サービス事業者が利用者に提供するサービスについて課金決済を行う課金決済業者の課金決済装置による課金決済方法であって、
前記課金決済業者が前記利用者を一意に識別するために発行した利用者識別情報Ｋ−ＩＤ（Ｕ）および前記サービス事業者が前記利用者を一意に識別するために発行した利用者識別情報Ｓ−ＩＤ（Ｕ）の関係を示す情報を暗号化してリンク値Ｌを生成するリンク値生成工程と、
前記サービス事業者の端末から前記利用者の課金に係る課金情報とともに前記リンク値生成工程によって生成されたリンク値Ｌを受け付け、当該リンク値Ｌから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を復号化して前記課金情報による決済を行う決済工程と、
を含んだことを特徴とする課金決済方法。
【請求項１０】
前記リンク値生成工程は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを受け付け、当該値Ｄと前記利用者識別情報Ｋ−ＩＤ（Ｕ）との排他的論理和Ｘを暗号化してリンク値Ｌを生成し、
前記決済工程は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを前記課金情報およびリンク値Ｌとともに受け付け、当該リンク値Ｌを復号化して前記排他的論理和Ｘを生成し、当該排他的論理和Ｘおよび前記値Ｄから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得することを特徴とする請求項９に記載の課金決済方法。
【請求項１１】
前記利用者識別情報Ｋ−ＩＤ（Ｕ）を暗号化して、前記利用者を認証したことを示す認証値Ｃを生成する認証値生成工程をさらに含み、
前記リンク値生成工程は、前記サービス事業者の端末から前記認証値生成工程によって生成された認証値Ｃを前記値Ｄとともに受け付け、当該認証値Ｃを復号化して前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得し、当該利用者識別情報Ｋ−ＩＤ（Ｕ）と前記値Ｄとの排他的論理和Ｘを暗号化して前記リンク値Ｌを生成することを特徴とする請求項９または１０に記載の課金決済方法。
【請求項１２】
前記リンク値生成工程および決済工程は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記リンク値Ｌの暗号化または復号化を行うことを特徴とする請求項９、１０または１１に記載の課金決済方法。
【請求項１３】
前記認証値生成工程および決済工程は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記認証値Ｃの暗号化または復号化を行うことを特徴とする請求項１１に記載の課金決済方法。
【請求項１４】
サービス事業者が利用者に提供するサービスについて課金決済を行う課金決済業者による課金決済方法をコンピュータに実行させる課金決済プログラムであって、
前記課金決済業者が前記利用者を一意に識別するために発行した利用者識別情報Ｋ−ＩＤ（Ｕ）および前記サービス事業者が前記利用者を一意に識別するために発行した利用者識別情報Ｓ−ＩＤ（Ｕ）の関係を示す情報を暗号化してリンク値Ｌを生成するリンク値生成手順と、
前記サービス事業者の端末から前記利用者の課金に係る課金情報とともに前記リンク値生成手順によって生成されたリンク値Ｌを受け付け、当該リンク値Ｌから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を復号化して前記課金情報による決済を行う決済手順と、
をコンピュータに実行させることを特徴とする課金決済プログラム。
【請求項１５】
前記リンク値生成手順は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを受け付け、当該値Ｄと前記利用者識別情報Ｋ−ＩＤ（Ｕ）との排他的論理和Ｘを暗号化してリンク値Ｌを生成し、
前記決済手順は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを前記課金情報およびリンク値Ｌとともに受け付け、当該リンク値Ｌを復号化して前記排他的論理和Ｘを生成し、当該排他的論理和Ｘおよび前記値Ｄから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得することを特徴とする請求項１４に記載の課金決済プログラム。
【請求項１６】
前記利用者識別情報Ｋ−ＩＤ（Ｕ）を暗号化して、前記利用者を認証したことを示す認証値Ｃを生成する認証値生成手順をさらにコンピュータに実行させ、
前記リンク値生成手順は、前記サービス事業者の端末から前記認証値生成手順によって生成された認証値Ｃを前記値Ｄとともに受け付け、当該認証値Ｃを復号化して前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得し、当該利用者識別情報Ｋ−ＩＤ（Ｕ）と前記値Ｄとの排他的論理和Ｘを暗号化して前記リンク値Ｌを生成することを特徴とする請求項１４または１５に記載の課金決済プログラム。
【請求項１７】
前記リンク値生成手順および決済手順は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記リンク値Ｌの暗号化または復号化を行うことを特徴とする請求項１４、１５または１６に記載の課金決済プログラム。
【請求項１８】
前記認証値生成手順および決済手順は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記認証値Ｃの暗号化または復号化を行うことを特徴とする請求項１６に記載の課金決済プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、サービス事業者が利用者に提供するサービスについて課金決済を行う課金決済装置、課金決済方法および課金決済プログラムに関する。
【背景技術】
【０００２】
従来より、ネットワーク上で提供される各種サービスの課金決済技術については、非特許文献１に開示されているように、サービスの契約情報（例えば、どの利用者が何のサービスに加入しているか等の情報）や、料金情報（例えば、サービスの料金、定額制、従量制、割引等の情報）の他に、各事業者が契約している利用者の個人情報など、種々の情報を課金決済業者が管理することが一般的であった。
【０００３】
そして、これらの情報は課金決済業務の運営上も重要な情報であり、その維持管理には多大な費用を必要とするので、基幹系規模（加入者数７桁以上）をターゲットとし、利用者数増大による増益によって維持費用をカバーする課金決済システムが主流であった。このような課金決済システムの代表的なものとしては、複数のサービス事業者および複数の決済業者に対応すべく、複数の利用者と、複数のサービス事業者および複数の決済業者との間を仲介して共通的に課金業務を行うシステム（例えば、特許文献１参照）や、同様に複数のサービス事業者に対応するだけでなく、異なるサービス事業者間の契約および手数料についても対応するシステム（例えば、特許文献２参照）があった。
【０００４】
ところで、最近になって、サービスの開始時には中小規模（加入者数５〜６桁程度）で展開するサービスが増えてきており、その対応として低コストで導入・運営できる課金決済システムが求められている。ここで、小規模なサービスにおいては、複雑な課金形態のニーズは余りなく、周期課金（月単位、日単位など、一定の周期において発生する課金）および随時課金（ペイ・パー・ビューなど、イベントごとに発生する課金）の２タイプにほぼ集約されるので、課金形態を単純にすることで管理すべき情報を軽減（サービスの料金情報や契約情報の情報量を削減）して、システムの導入・運営に要するコストを低く抑える手法が考えられる（例えば、特許文献３や特許文献４参照）。
【０００５】
また、システムの導入・運営に要するコストを低く抑えるには、情報管理を別システム（別業者）に委託する手法なども考えられる。つまり、各事業者がそれぞれの利用者に対して独自に識別情報（ＩＤ）を発行する一方で、専門の管理業者が各ＩＤの関連情報をデータベースに管理し、かかる管理業者に問い合わせを行うことで他事業者が発行したＩＤを自己が発行したＩＤに変換するという「名寄せ技術」である（例えば、特許文献５参照）。
【０００６】
【特許文献１】特開２００２−１６３５９０号公報
【特許文献２】特開２００２−３１８９７４号公報
【特許文献３】特開２００３−１６２６７５号公報
【特許文献４】特開２００４−０２１３３５号公報
【特許文献５】特開２００２−２４５３８８号公報
【非特許文献１】三宅武司、他２名、「柔軟なサービス課金を可能にするＩＰ課金プラットフォーム」、ＮＴＴ技術ジャーナル、社団法人電気通信協会、２０００年１０月１日、Ｖｏｌ．１、Ｎｏ．１０、ｐ．１９〜ｐ．２２
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記した従来の技術のうち、課金処理に必要な種々の情報を課金決済業者が全て管理する手法では、その情報を維持管理する費用が課金決済業者の経営を圧迫する主要因になりかねないという問題点がある。このため、課金決済システムを低コストで導入・運営するためには、課金決済システムが管理する情報を極力減らしていく必要があるが、課金形態の単純化や管理業務の委託には、以下に説明する問題点がある。
【０００８】
すなわち、上記した従来技術のうち、課金形態を単純化する手法では、課金形態の単純化は実現されるが、課金決済業者は計算済みの情報を単純に受け取るしかなく、課金計算はサービス事業者任せになっており、却ってサービス事業者に負担を押しつけているという問題点がある。
【０００９】
また、上記した従来技術のうち、管理業務を委託する手法では、情報漏洩の危険性が増大するおそれがあるので、そのセキュリティには十分過ぎるくらいの配慮を行わなければならず、却ってコスト増の要因になりかねないという問題点がある。特に、上記した「名寄せ技術」の場合には、ＩＤのみを流通させているが、大抵のＩＤは他の個人情報を引き出すためのキー情報として用いられるものであり、通信をＳＳＬ（Secure Socket Layer）等の暗号化技術で保護することで第三者への直接の漏洩は回避できたとしても、ＩＤが一時的には通信の相手先に保持されるので、そこからＩＤが漏洩する危険性は依然として残っている。また、「名寄せ技術」の場合には、「問い合わせ」のための通信処理が増大するので、システムに余分な負担がかかるという問題点もある。
【００１０】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、利用者識別情報のセキュリティを向上させ、かつ、低コストに課金決済システムを構築することが可能な課金決済装置、課金決済方法および課金決済プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するため、請求項１に係る発明は、サービス事業者が利用者に提供するサービスについて課金決済を行う課金決済業者の課金決済装置であって、前記課金決済業者が前記利用者を一意に識別するために発行した利用者識別情報Ｋ−ＩＤ（Ｕ）および前記サービス事業者が前記利用者を一意に識別するために発行した利用者識別情報Ｓ−ＩＤ（Ｕ）の関係を示す情報を暗号化してリンク値Ｌを生成するリンク値生成手段と、前記サービス事業者の端末から前記利用者の課金に係る課金情報とともに前記リンク値生成手段によって生成されたリンク値Ｌを受け付け、当該リンク値Ｌから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を復号化して前記課金情報による決済を行う決済手段と、を備えたことを特徴とする。
【００１２】
また、請求項２に係る発明は、上記の発明において、前記リンク値生成手段は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを受け付け、当該値Ｄと前記利用者識別情報Ｋ−ＩＤ（Ｕ）との排他的論理和Ｘを暗号化してリンク値Ｌを生成し、前記決済手段は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを前記課金情報およびリンク値Ｌとともに受け付け、当該リンク値Ｌを復号化して前記排他的論理和Ｘを生成し、当該排他的論理和Ｘおよび前記値Ｄから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得することを特徴とする。
【００１３】
また、請求項３に係る発明は、上記の発明において、前記利用者識別情報Ｋ−ＩＤ（Ｕ）を暗号化して、前記利用者を認証したことを示す認証値Ｃを生成する認証値生成手段をさらに備え、前記リンク値生成手段は、前記サービス事業者の端末から前記認証値生成手段によって生成された認証値Ｃを前記値Ｄとともに受け付け、当該認証値Ｃを復号化して前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得し、当該利用者識別情報Ｋ−ＩＤ（Ｕ）と前記値Ｄとの排他的論理和Ｘを暗号化して前記リンク値Ｌを生成することを特徴とする。
【００１４】
また、請求項４に係る発明は、上記の発明において、前記リンク値生成手段および決済手段は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記リンク値Ｌの暗号化または復号化を行うことを特徴とする。
【００１５】
また、請求項５に係る発明は、上記の発明において、前記認証値生成手段および決済手段は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記認証値Ｃの暗号化または復号化を行うことを特徴とする。
【００１６】
また、請求項６に係る発明は、上記の発明において、前記決済手段は、前記利用者が支払う課金料金額を含んだ課金情報を前記サービス事業者の端末から受け付け、当該課金情報に含まれる課金料金額を用いて決済を行うことを特徴とする。
【００１７】
また、請求項７に係る発明は、上記の発明において、前記課金決済業者による課金決済のサービスについて前記サービス事業者が支払う課金料金額を算出する課金処理手段をさらに備え、前記決済手段は、前記利用者について決済を行うとともに、前記課金処理手段によって算出された前記サービス事業者が支払う課金料金額、および、前記利用者が支払う課金料金額を用いて当該サービス事業者について決済を行うことを特徴とする。
【００１８】
また、請求項８に係る発明は、上記の発明において、前記課金決済業者は、他のサービス事業者が前記サービス事業者に提供するサービスについても課金決済を行うものであって、前記リンク値生成手段は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）および前記他のサービス事業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｒ−ＩＤ（Ｓ）の関係を示す情報を暗号化してリンク値Ｌを生成し、前記決済手段は、前記他のサービス事業者の端末から前記サービス事業者の課金に係る課金情報とともに前記リンク値生成手段によって生成されたリンク値Ｌを受け付け、当該リンク値Ｌから前記サービス事業者情報Ｋ−ＩＤ（Ｓ）を復号化して前記課金情報による決済を行うことを特徴とする。
【００１９】
また、請求項９に係る発明は、サービス事業者が利用者に提供するサービスについて課金決済を行う課金決済業者の課金決済装置による課金決済方法であって、前記課金決済業者が前記利用者を一意に識別するために発行した利用者識別情報Ｋ−ＩＤ（Ｕ）および前記サービス事業者が前記利用者を一意に識別するために発行した利用者識別情報Ｓ−ＩＤ（Ｕ）の関係を示す情報を暗号化してリンク値Ｌを生成するリンク値生成工程と、前記サービス事業者の端末から前記利用者の課金に係る課金情報とともに前記リンク値生成工程によって生成されたリンク値Ｌを受け付け、当該リンク値Ｌから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を復号化して前記課金情報による決済を行う決済工程と、を含んだことを特徴とする。
【００２０】
また、請求項１０に係る発明は、上記の発明において、前記リンク値生成工程は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを受け付け、当該値Ｄと前記利用者識別情報Ｋ−ＩＤ（Ｕ）との排他的論理和Ｘを暗号化してリンク値Ｌを生成し、前記決済工程は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを前記課金情報およびリンク値Ｌとともに受け付け、当該リンク値Ｌを復号化して前記排他的論理和Ｘを生成し、当該排他的論理和Ｘおよび前記値Ｄから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得することを特徴とする。
【００２１】
また、請求項１１に係る発明は、上記の発明において、前記利用者識別情報Ｋ−ＩＤ（Ｕ）を暗号化して、前記利用者を認証したことを示す認証値Ｃを生成する認証値生成工程をさらに含み、前記リンク値生成工程は、前記サービス事業者の端末から前記認証値生成工程によって生成された認証値Ｃを前記値Ｄとともに受け付け、当該認証値Ｃを復号化して前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得し、当該利用者識別情報Ｋ−ＩＤ（Ｕ）と前記値Ｄとの排他的論理和Ｘを暗号化して前記リンク値Ｌを生成することを特徴とする。
【００２２】
また、請求項１２に係る発明は、上記の発明において、前記リンク値生成工程および決済工程は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記リンク値Ｌの暗号化または復号化を行うことを特徴とする。
【００２３】
また、請求項１３に係る発明は、上記の発明において、前記認証値生成工程および決済工程は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記認証値Ｃの暗号化または復号化を行うことを特徴とする。
【００２４】
また、請求項１４に係る発明は、サービス事業者が利用者に提供するサービスについて課金決済を行う課金決済業者による課金決済方法をコンピュータに実行させる課金決済プログラムであって、前記課金決済業者が前記利用者を一意に識別するために発行した利用者識別情報Ｋ−ＩＤ（Ｕ）および前記サービス事業者が前記利用者を一意に識別するために発行した利用者識別情報Ｓ−ＩＤ（Ｕ）の関係を示す情報を暗号化してリンク値Ｌを生成するリンク値生成手順と、前記サービス事業者の端末から前記利用者の課金に係る課金情報とともに前記リンク値生成手順によって生成されたリンク値Ｌを受け付け、当該リンク値Ｌから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を復号化して前記課金情報による決済を行う決済手順と、をコンピュータに実行させることを特徴とする。
【００２５】
また、請求項１５に係る発明は、上記の発明において、前記リンク値生成手順は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを受け付け、当該値Ｄと前記利用者識別情報Ｋ−ＩＤ（Ｕ）との排他的論理和Ｘを暗号化してリンク値Ｌを生成し、前記決済手順は、前記サービス事業者の端末から前記利用者識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを前記課金情報およびリンク値Ｌとともに受け付け、当該リンク値Ｌを復号化して前記排他的論理和Ｘを生成し、当該排他的論理和Ｘおよび前記値Ｄから前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得することを特徴とする。
【００２６】
また、請求項１６に係る発明は、上記の発明において、前記利用者識別情報Ｋ−ＩＤ（Ｕ）を暗号化して、前記利用者を認証したことを示す認証値Ｃを生成する認証値生成手順をさらにコンピュータに実行させ、前記リンク値生成手順は、前記サービス事業者の端末から前記認証値生成手順によって生成された認証値Ｃを前記値Ｄとともに受け付け、当該認証値Ｃを復号化して前記利用者識別情報Ｋ−ＩＤ（Ｕ）を取得し、当該利用者識別情報Ｋ−ＩＤ（Ｕ）と前記値Ｄとの排他的論理和Ｘを暗号化して前記リンク値Ｌを生成することを特徴とする。
【００２７】
また、請求項１７に係る発明は、上記の発明において、前記リンク値生成手順および決済手順は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記リンク値Ｌの暗号化または復号化を行うことを特徴とする。
【００２８】
また、請求項１８に係る発明は、上記の発明において、前記認証値生成手順および決済手順は、前記課金決済業者が前記サービス事業者を一意に識別するために発行したサービス事業者識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として所定の鍵生成アルゴリズムから鍵を生成し、当該鍵を用いて前記認証値Ｃの暗号化または復号化を行うことを特徴とする。
【発明の効果】
【００２９】
請求項１、９または１４の発明によれば、課金決済業者およびサービス事業者がそれぞれ発行する利用者識別情報間の関係を示す情報をサービス事業者に管理させるので、課金決済処理に必要な情報が分散管理され、課金決済業者による情報の維持管理コストが大幅に削減され、課金決済システムを低コストで導入して運用することが可能になる。また、課金決済業者がサービス事業者に対して識別情報Ｋ−ＩＤ（Ｕ）の値をそのまま見せずに、暗号化されたリンク値に埋め込み、課金決済に際しては、この暗号化されたリンク値を受け付けるので、利用者以外への識別情報Ｋ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。さらに、これによって、識別情報の管理面や流通面での安全性が向上し、利用者による信頼性も向上するので、利用者数の増大を図ることも可能になる。
【００３０】
また、請求項２、１０または１５の発明によれば、リンク値の生成に際しては、識別情報Ｓ−ＩＤ（Ｕ）そのものを受け付けるのではなく、識別情報Ｓ−ＩＤ（Ｕ）を暗号化して得られる値Ｄを受け付けるので、利用者Ｕ以外への識別情報Ｓ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。
【００３１】
また、請求項３、１１または１６の発明によれば、課金決済業者がサービス事業者に対して識別情報Ｋ−ＩＤ（Ｕ）の値をそのまま見せずに、暗号化された認証値Ｃに埋め込み、リンク値の生成に際しては、この暗号化された認証値Ｃを受け付けるので、利用者以外への識別情報Ｋ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。
【００３２】
また、請求項４、１２または１７の発明によれば、リンク値Ｌは、識別情報Ｋ−ＩＤ（Ｓ）を元にして生成された鍵によって暗号化することで生成するので、仮にリンク値Ｌが外部に漏れたとしても、識別情報Ｋ−ＩＤ（Ｓ）を知らなければＫ−ＩＤ（Ｕ）を導き出すことはできない。また、リンク値Ｌおよび識別情報Ｋ−ＩＤ（Ｓ）を知っているサービス事業者であっても、Ｋ−ＩＤ（Ｓ）から共通鍵を生成するためのアルゴリズムを知らないので、リンク値からＫ−ＩＤ（Ｕ）を導き出すことはできない。したがって、利用者以外の第三者による識別情報Ｋ−ＩＤ（Ｕ）の取得を防止することが可能になる。
【００３３】
また、請求項５、１３または１８の発明によれば、認証値Ｃは、識別情報Ｋ−ＩＤ（Ｓ）を元にして生成された共通鍵によって暗号化することで生成するので、仮に認証値Ｃが外部に漏れたとしても、識別情報Ｋ−ＩＤ（Ｓ）を知らなければＫ−ＩＤ（Ｕ）を導き出すことはできない。また、認証値Ｃおよび識別情報Ｋ−ＩＤ（Ｓ）を知っているサービス事業者であっても、Ｋ−ＩＤ（Ｓ）から共通鍵を生成するためのアルゴリズムを知らないので、認証値ＣからＫ−ＩＤ（Ｕ）を導き出すことはできない。したがって、利用者以外の第三者による識別情報Ｋ−ＩＤ（Ｕ）の取得を防止することが可能になる。
【００３４】
また、請求項６の発明によれば、課金決済業者が課金料金額を算出するのではなく、サービス事業者が利用者の課金料金額を算出するので、課金決済業者は課金料金額の算出に必要な情報を管理する必要がなく、課金決済業者による情報の維持管理コストをさらに削減させることが可能になる。
【００３５】
また、請求項７の発明によれば、サービス事業者が課金決済業者に課金決済サービスを依頼しているような場合に、サービス事業者が利用者から受け取る課金料金額から支払料金を差し引って決済を行うことで、サービス事業者から課金決済業者に改めて料金を支払う手間を省くことが可能になる。
【００３６】
また、請求項８の発明によれば、他のサービス事業者があるサービス事業者に提供するサービスについて課金決済を行う場合にも、課金決済業者による情報の維持管理コストを大幅に削減することが可能になり、また、サービス事業者の識別情報のセキュリティを向上させることも可能になる。
【発明を実施するための最良の形態】
【００３７】
以下に添付図面を参照して、この発明に係る課金決済装置、課金決済方法および課金決済プログラムの実施例を詳細に説明する。なお、以下では、利用者、利用者のみにサービスを提供するサービス事業者、利用者およびサービス事業者にサービスを提供するプロバイダ、並びに、課金決済業者の４者が登場する課金決済システムを実施例として説明する。ただし、本実施例では、説明の便宜上、利用者は複数存在するが、サービス事業者、プロバイダおよび課金決済業者はそれぞれ１者のみが存在する場合を説明する。
【実施例】
【００３８】
［利用者、サービス事業者、プロバイダ、課金決済業者］
最初に、図１を用いて、以下の実施例に登場する利用者、サービス事業者、プロバイダ、課金決済業者を説明する。図１は、実施例に登場する利用者、サービス事業者、プロバイダ、課金決済業者を説明するための図である。
【００３９】
サービス事業者Ｓは、利用者Ｕに対してサービスを提供し、利用者Ｕは、サービス事業者Ｓが提供するサービスを利用する（同図の（１）および（２）参照）。また、プロバイダＲは、利用者Ｕに対して利用者向けサービスを提供し、利用者Ｕは、プロバイダＲが提供する利用者向けサービスを利用する（同図の（３）および（４）参照）。さらに、プロバイダＲは、サービス事業者Ｓに対してサービス事業者向けサービスを提供し、サービス事業者Ｓは、プロバイダＲが提供するサービス事業者向けサービスを利用する（同図の（５）および（６）参照）。
【００４０】
課金決済業者Ｋは、サービス事業者ＳおよびプロバイダＲに代わって利用者Ｕにサービスの利用料金を請求し、利用者Ｕから徴収した利用料金から課金決済代行の手数料を差し引いた料金をサービス事業者ＳおよびプロバイダＲに分配する（同図の（７）〜（１０）参照）。なお、実際の利用料金のやりとりは決済機関を介して行われる場合もある。
【００４１】
ところで、「利用者Ｕ、サービス事業者Ｓ、課金決済業者Ｋ」の三者間では、利用者Ｕは特許請求の範囲の「利用者」に対応し、サービス事業者Ｓは同じく「サービス事業者」に対応し、課金決済業者Ｋは同じく「課金決済業者」に対応する。また、「利用者Ｕ、プロバイダＲ、課金決済業者Ｋ」の三者間では、利用者Ｕは特許請求の範囲の「利用者」に対応し、プロバイダＲは同じく「サービス事業者」に対応し、課金決済業者Ｋは同じく「課金決済業者」に対応する。さらに、「サービス事業者Ｓ、プロバイダＲ、課金決済業者Ｋ」の三者間では、サービス事業者Ｓは特許請求の範囲の「サービス事業者」に対応し、プロバイダＲは同じく「他のサービス事業者」に対応し、課金決済業者Ｋは同じく「課金決済業者」に対応する。
【００４２】
［識別情報］
続いて、図２および図３を用いて、以下の実施例で用いる識別情報について説明する。図２は、実施例で用いる識別情報（ＩＤ）を説明するための図であり、図３は、実施例で用いる利用者ＩＤ、サービス事業者ＩＤ、プロバイダＩＤの例を示す図である。同図に示すように、本実施例では、以下の６つの識別情報が用いられる。
Ｋ−ＩＤ（Ｕ）：課金決済業者Ｋが利用者Ｕに発行する識別情報（ＩＤ）
Ｋ−ＩＤ（Ｓ）：課金決済業者Ｋがサービス事業者Ｓに発行する識別情報（ＩＤ）
Ｋ−ＩＤ（Ｒ）：課金決済業者ＫがプロバイダＲに発行する識別情報（ＩＤ）
Ｓ−ＩＤ（Ｕ）：サービス事業者Ｓが利用者Ｕに発行する識別情報（ＩＤ）
Ｒ−ＩＤ（Ｕ）：プロバイダＲが利用者Ｕに発行する識別情報（ＩＤ）
Ｒ−ＩＤ（Ｓ）：プロバイダＲがサービス事業者Ｕに発行する識別情報（ＩＤ）
【００４３】
［暗号化アルゴリズム等］
続いて、以下の実施例で用いる暗号化アルゴリズム等を説明する。図４は、実施例で用いる暗号化アルゴリズム等を説明するための図である。同図に示すように、本実施例では、以下の５つの暗号化アルゴリズムまたは鍵生成アルゴリズムが用いられる。
Ｆ１：課金決済業者Ｋが課金決済装置で用いる暗号化アルゴリズム
Ｆ２：課金決済業者Ｋが課金決済装置で用いる鍵生成アルゴリズム
Ｆ３：サービス事業者Ｓがサービス提供装置で用いる暗号化アルゴリズム
Ｆ４：プロバイダＲがプロバイダ装置で用いる暗号化アルゴリズム
Ｆ５：プロバイダＲがプロバイダ装置で用いる暗号化アルゴリズム
【００４４】
そして、本実施例では、上記した暗号化アルゴリズムを用いた暗号化によって生成される情報として以下のものがある。
Ｃ１：Ｋ−ＩＤ（Ｕ）をアルゴリズムＦ１、鍵Ｋｅｙ１で暗号化して生成される認証値
Ｃ２：Ｋ−ＩＤ（Ｕ）をアルゴリズムＦ１、鍵Ｋｅｙ２で暗号化して生成される認証値
Ｃ３：Ｋ−ＩＤ（Ｓ）をアルゴリズムＦ１、鍵Ｋｅｙ２で暗号化して生成される認証値
Ｄ１：Ｓ−ＩＤ（Ｕ）をアルゴリズムＦ３で暗号化して生成される値
Ｄ２：Ｒ−ＩＤ（Ｕ）をアルゴリズムＦ４で暗号化して生成される値
Ｄ３：Ｒ−ＩＤ（Ｓ）をアルゴリズムＦ５で暗号化して生成される値
Ｌ１：Ｘ１をアルゴリズムＦ１、鍵Ｋｅｙ１で暗号化して生成されるリンク値
Ｌ２：Ｘ２をアルゴリズムＦ１、鍵Ｋｅｙ２で暗号化して生成されるリンク値
Ｌ３：Ｘ３をアルゴリズムＦ１、鍵Ｋｅｙ２で暗号化して生成されるリンク値
【００４５】
ただし、上記した鍵Ｋｅｙ１およびＫｅｙ２および値Ｘ１〜Ｘ３は以下のものである。
Ｋｅｙ１：Ｋ−ＩＤ（Ｓ）から鍵生成アルゴリズムＦ２により生成される暗号鍵
Ｋｅｙ２：Ｋ−ＩＤ（Ｒ）から鍵生成アルゴリズムＦ２により生成される暗号鍵
Ｘ１：Ｋ−ＩＤ（Ｕ）とＤ１の排他的論理和
Ｘ２：Ｋ−ＩＤ（Ｕ）とＤ２の排他的論理和
Ｘ３：Ｋ−ＩＤ（Ｓ）とＤ３の排他的論理和
【００４６】
さらに、本実施例では、上記した暗号化アルゴリズムＦ１は共通鍵暗号化方式を想定したものである。したがって、認証値Ｃ１から識別情報Ｋ−ＩＤ（Ｕ）が復号化され、認証値Ｃ２から識別情報Ｋ−ＩＤ（Ｕ）が復号化され、認証値Ｃ３から識別情報Ｋ−ＩＤ（Ｓ）が復号化され、リンク値Ｌ１から値Ｘ１が復号化され、リンク値Ｌ２から値Ｘ２が復号化され、リンク値Ｌ３から値Ｘ３が復号化される。
【００４７】
また、暗号化アルゴリズムＦ１および鍵生成アルゴリズムＦ２は、同一のアルゴリズムであってもよい。さらに、暗号化アルゴリズムＦ３、Ｆ４およびＦ５は、課金決済業者Ｋとは無関係であるので、サービス提供装置やプロバイダ装置の実装時にサービス事業者ＳやプロバイダＲが任意に決定することができ、Ｆ４およびＦ５が同一であってもよい。
【００４８】
ところで、課金決済業者Ｋは、課金に際して、利用者Ｕに係る識別情報Ｋ−ＩＤ（Ｕ）、Ｓ−ＩＤ（Ｕ）およびＲ−ＩＤ（Ｕ）は同一の利用者Ｕを指し示すこと、並びに、サービス事業者Ｓに係る識別情報Ｋ−ＩＤ（Ｓ）およびＲ−ＩＤ（Ｓ）は同一のサービス事業者Ｓを指し示すことを把握する必要がある。
【００４９】
これに関して、本実施例では、｛Ｋ−ＩＤ（Ｕ）およびＳ−ＩＤ（Ｕ）｝の関係を示す情報を暗号化してリンク値Ｌ１を生成し、これをサービス事業者Ｓに管理させる。また、｛Ｋ−ＩＤ（Ｕ）およびＲ−ＩＤ（Ｕ）｝の関係を示す情報を暗号化してリンク値Ｌ２を生成し、これをプロバイダＲに管理させる。さらに、｛Ｋ−ＩＤ（Ｓ）およびＲ−ＩＤ（Ｓ）｝の関係を示す情報を暗号化してリンク値Ｌ３を生成し、これをプロバイダＲに管理させる。
【００５０】
すなわち、本実施例では、上記したような関係情報を課金決済業者Ｋにおいて保持するようなことはせず、これらを暗号化したリンク値Ｌをサービス事業者ＳやプロバイダＲに管理させる。そして、課金決済業者Ｋは、かかるリンク値Ｌをサービス事業者ＳやプロバイダＲから課金情報とともに受け付けて復号化することでＫ−ＩＤ（Ｕ）やＫ−ＩＤ（Ｓ）を取得し、課金対象者である利用者Ｕやサービス事業者Ｓを特定して課金決済を行う。
【００５１】
［課金処理の概要］
続いて、図５〜図７を用いて、以下の実施例で説明する課金処理の概要を説明する。図５は、実施例に係る課金処理の概要、より詳細には、利用者Ｕ、サービス事業者Ｓおよび課金決済業者Ｋの間で行われる課金処理の概要を説明するための図である。
【００５２】
同図に示すように、課金決済業者Ｋは、識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として鍵生成アルゴリズムＦ２から共通鍵Ｋｅｙ１を生成し、この鍵Ｋｅｙ１および暗号化アルゴリズムＦ１によって識別情報Ｋ−ＩＤ（Ｕ）を暗号化して認証値Ｃ１を生成して、この認証値Ｃ１を利用者Ｕに受け渡す。
【００５３】
サービス事業者Ｓは、利用者Ｕから認証値Ｃ１を受け取ると、この利用者Ｕを一意に識別するための利用者識別情報Ｓ−ＩＤ（Ｕ）を発行し、この識別情報Ｓ−ＩＤ（Ｕ）を暗号化アルゴリズムＦ３によって暗号化して値Ｄ１を生成し、この値Ｄ１および上記の認証値Ｃ１とともに、サービス事業者識別情報Ｋ−ＩＤ（Ｓ）を課金決済業者Ｋに送信する。
【００５４】
課金決済業者Ｋは、識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として鍵生成アルゴリズムＦ２から共通鍵Ｋｅｙ１を生成し、この鍵Ｋｅｙ１および暗号化アルゴリズムＦ１によって認証値Ｃ１を復号化して識別情報Ｋ−ＩＤ（Ｕ）を生成する。さらに、復号化した識別情報Ｋ−ＩＤ（Ｕ）の値と値Ｄ１との排他的論理和をとって値Ｘ１を生成し、この値Ｘ１を鍵Ｋｅｙ１および暗号化アルゴリズムＦ１によって暗号化して、Ｋ−ＩＤ（Ｕ）およびＳ−ＩＤ（Ｕ）のリンクを示すリンク値Ｌ１を生成する。
【００５５】
このようにして生成されたリンク値Ｌ１は、サービス事業者Ｓに受け渡され、利用者Ｕに対するサービスの提供（利用者Ｕのよるサービスの利用）の間、サービス事業者Ｓによって管理される。そして、サービス事業者Ｓは、利用者Ｕに対するサービスの提供によって発生した利用者Ｕの利用料金ＳＵＭ１を、利用者Ｕの値Ｄ１、リンク値Ｌ１および識別情報Ｋ−ＩＤ（Ｓ）とともに課金決済業者Ｋに送信する。
【００５６】
課金決済業者Ｋは、識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として鍵生成アルゴリズムＦ２から共通鍵Ｋｅｙ１を生成し、この鍵Ｋｅｙ１および暗号化アルゴリズムＦ１によってリンク値Ｌ１を復号化して値Ｘ１を生成し、この値Ｘ１と値Ｄ１の排他的論理和から課金対象者である利用者Ｕの識別情報Ｋ−ＩＤ（Ｕ）を生成する。
【００５７】
このように、本実施例では、課金決済業者Ｋおよびサービス事業者Ｓがそれぞれ発行する利用者識別情報Ｋ−ＩＤ（Ｕ）とＳ−ＩＤ（Ｕ）の関係を示す情報をサービス事業者Ｓに管理させるので、課金決済処理に必要な情報が分散管理され、課金決済業者Ｋによる情報の維持管理コストが大幅に削減され、課金決済システムを低コストで導入して運用することが可能になる。
【００５８】
また、課金決済業者Ｋがサービス事業者Ｓに対して識別情報Ｋ−ＩＤ（Ｕ）の値をそのまま見せずに、暗号化されたリンク値Ｌ１に埋め込み、課金決済に際しては、この暗号化されたリンク値Ｌ１を受け付けるので、利用者Ｕ以外への識別情報Ｋ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。さらに、これによって、識別情報の管理面や流通面での安全性が向上し、利用者Ｕによる信頼性も向上するので、利用者数の増大を図ることも可能になる。
【００５９】
なお、図６は、利用者Ｕ、プロバイダＲおよび課金決済業者Ｋの間で行われる課金処理の概要を説明するための図であり、図７は、サービス事業者Ｓ、プロバイダＲおよび課金決済業者Ｋの間で行われる課金処理の概要を説明するための図である。各図に示すように、上記で説明したものと同様の認証値Ｃ２またはＣ３、値Ｄ２またはＤ３、値Ｘ２またはＤ３、リンク値Ｌ２またはＬ３が用いられる。
【００６０】
［システムの構成］
続いて、図８を用いて、本実施例に係るシステムの構成を説明する。図８は、実施例に係るシステムの構成を示す構成図である。同図に示すように、本実施例に係るシステムは、利用者端末１０と、サービス提供装置２０と、プロバイダ装置３０と、課金決済装置４０とを、ネットワーク（インターネットやＬＡＮ、公衆電話網など）を介して相互に通信可能に接続して構成される。
【００６１】
このうち、利用者端末１０は、利用者Ｕが有する既知のパーソナルコンピュータやワークステーション、家庭用ゲーム機、インターネットＴＶ、ＰＤＡ、あるいは携帯電話やＰＨＳの如き移動体通信端末などである。
【００６２】
サービス提供装置２０は、サービス事業者Ｓが有するサーバコンピュータである。また、このサービス提供装置２０には、図８に示すように、サービス事業者Ｓのオペレータが操作するサービス事業者オペレータ端末２００がネットワークを介して通信可能に接続され、また、このサービス事業者オペレータ端末２００は、後述のプロバイダ装置３０および課金決済装置４０ともネットワークを介して通信可能に接続される。
【００６３】
プロバイダ装置３０は、プロバイダＲが有するサーバコンピュータである。また、このプロバイダ装置３０には、図８に示すように、プロバイダＲのオペレータが操作するプロバイダオペレータ端末３００がネットワークを介して通信可能に接続され、また、このプロバイダオペレータ端末３００は、後述の課金決済装置４０ともネットワークを介して通信可能に接続される。
【００６４】
課金決済装置４０は、課金決済業者Ｋが有するサーバコンピュータである。また、この課金決済装置４０には、図８に示すように、課金決済業者Ｋのオペレータが操作する課金決済業者オペレータ端末４００と、料金の引き落としや振り込みを実行する決済機関システム５０とがネットワークを介して通信可能に接続される。
【００６５】
［サービス提供装置の構成］
続いて、図９を用いて、サービス提供装置２０の構成を説明する。図９は、サービス提供装置２０の構成を示すブロック図である。同図に示すように、このサービス提供装置２０は、本発明に密接に関連するものとして、利用者情報ＤＢ２０ａと、サービス料金情報ＤＢ２０ｂと、サービス提供部２１と、課金情報送信部２２と、利用者情報管理部２３と、料金情報管理部２４とを備える。
【００６６】
このうち、利用者情報ＤＢ２０ａは、利用者Ｕに関する各種の情報（利用者情報）を記憶する記憶手段（データベース）である。サービス料金情報ＤＢ２０ｂは、サービスの料金に係る情報（サービス料金情報）を記憶するデータベースである。なお、利用者情報については、図２１を用いて後に詳述し、また、サービス料金情報についても、図３３を用いて後に詳述する。
【００６７】
サービス提供部２１は、利用者端末１０に対してサービスを提供する処理部である。課金情報送信部２２は、各利用者Ｕの月々の課金情報を後述する課金決済装置４０に送信する処理部である。なお、課金情報送信部２２による処理（課金情報送信処理）については、図３１や図３２を用いて後に詳述する。
【００６８】
利用者情報管理部２３は、利用者情報ＤＢ２０ａを管理する処理部であり、例えば、利用者端末１０から、サービス契約時に利用者情報の入力を受け付け、サービス事業者オペレータ端末２００から、利用者情報のメンテナンスを受け付けるほか、課金決済装置４０と連携して利用者認証処理を行うなどする。料金情報管理部２４は、サービス料金情報ＤＢ２０ｂを管理する処理部であり、例えば、サービス事業者オペレータ端末２００から、サービス料金情報のメンテナンスを受け付けるなどする。なお、利用者情報管理部２３による処理（契約締結処理）については、図１８を用いて後に詳述する。
【００６９】
［プロバイダ装置の構成］
続いて、図１０を用いて、プロバイダ装置３０の構成を説明する。図１０は、プロバイダ装置３０の構成を示すブロック図である。同図に示すように、このプロバイダ装置３０は、本発明に密接に関連するものとして、利用者情報ＤＢ３０ａと、サービス業者情報ＤＢ３０ｂと、サービス料金情報ＤＢ３０ｃと、サービス提供部３１と、課金情報送信部３２と、ユーザ情報管理部３３と、料金情報管理部３４とを備える。
【００７０】
このうち、利用者情報ＤＢ３０ａは、利用者Ｕに関する各種の情報（利用者情報）を記憶するデータベースである。サービス業者情報ＤＢ３０ｂは、サービス事業者Ｓに関する各種の情報（サービス事業者情報）を記憶するデータベースである。サービス料金情報ＤＢ３０ｂは、サービスの料金に係る情報（サービス料金情報）を記憶するデータベースである。なお、利用者情報については、図２５を用いて後に詳述し、サービス事業者情報についても、図２９を用いて後に詳述し、さらに、サービス料金情報についても、図３７を用いて後に詳述する。
【００７１】
サービス提供部３１は、利用者端末１０およびサービス事業者オペレータ端末２００に対してサービスを提供する処理部である。課金情報送信部３２は、各利用者Ｕやサービス事業者Ｓの月々の課金情報を後述する課金決済装置４０に送信する処理部である。なお、課金情報送信部３２による処理（課金情報送信処理）については、図３５や図３６を用いて後に詳述する。
【００７２】
ユーザ情報管理部３３は、利用者情報ＤＢ３０ａおよびサービス事業者情報ＤＢ３０ｂを管理する処理部であり、例えば、利用者端末１０またはサービス事業者オペレータ端末２００から、サービス契約時に利用者情報またはサービス事業者情報の入力を受け付け、プロバイダオペレータ端末３００から、利用者情報やサービス事業者情報のメンテナンスを受け付けるほか、課金決済装置４０と連携して利用者認証処理を行うなどする。料金情報管理部３４は、サービス料金情報ＤＢ３０ｂを管理する処理部であり、例えば、プロバイダオペレータ端末３００から、サービス料金情報のメンテナンスを受け付けるなどする。なお、ユーザ情報管理部３３による処理（契約締結処理）については、図２２や図２６を用いて後に詳述する。
【００７３】
［課金決済装置の構成］
続いて、図１１を用いて、課金決済装置４０の構成を説明する。図１１は、課金決済装置４０の構成を示すブロック図である。同図に示すように、この課金決済装置４０は、本発明に密接に関連するものとして、課金情報ＤＢ４０ａと、明細情報ＤＢ４０ｂと、決済情報ＤＢ４０ｃと、利用者情報ＤＢ４０ｄと、サービス業者情報ＤＢ４０ｅと、プロバイダ情報ＤＢ４０ｆと、サービス料金情報ＤＢ４０ｇと、課金情報受信部４１と、請求部４２と、決済ＧＷ部４３と、ユーザ情報管理部４４と、料金情報管理部４５とを備える。
【００７４】
なお、課金情報受信部４１は、特許請求の範囲に記載の「課金処理手段」に対応し、決済ＧＷ部４３は、同じく「決済手段」に対応し、ユーザ情報管理部４４は、同じく「リンク値生成手段」および「認証値生成手段」に対応する。
【００７５】
このうち、課金情報ＤＢ４０ａは、利用者Ｕ、サービス事業者ＳおよびプロバイダＲそれぞれの課金に係る情報（課金情報）を記憶するデータベースである。明細情報ＤＢ４０ｂは、利用者Ｕ、サービス事業者ＳおよびプロバイダＲそれぞれに請求する明細に係る情報（明細情報）を記憶するデータベースである。決済情報ＤＢ４０ｃは、利用者Ｕ、サービス事業者ＳおよびプロバイダＲそれぞれの決済に係る情報（決済情報）を記憶するデータベースである。なお、課金情報については、図４１を用いて後に詳述し、明細情報についても、図４６を用いて後に詳述し、さらに、決済情報についても、図４９を用いて後に詳述する。
【００７６】
利用者情報ＤＢ４０ｄは、利用者Ｕに関する各種の情報（利用者情報）を記憶するデータベースである。サービス業者情報ＤＢ４０ｅは、サービス事業者Ｓに関する各種の情報（サービス事業者情報）を記憶するデータベースである。プロバイダ情報ＤＢ４０ｆは、プロバイダＲに関する各種の情報（プロバイダ情報）を記憶するデータベースである。サービス料金情報ＤＢ４０ｇは、サービスの料金に係る情報（サービス料金情報）を記憶するデータベースである。なお、利用者情報については、図１３を用いて後に詳述し、サービス事業者情報についても、図１５を用いて後に詳述し、プロバイダ情報についても、図１７を用いて後に詳述し、さらに、サービス料金情報についても、図４２を用いて後に詳述する。
【００７７】
課金情報受信部４１は、サービス提供装置２０およびプロバイダ装置３０から課金情報を受信するとともに、内部で課金情報を生成し、課金情報を課金情報ＤＢ４０ａに格納する処理部である。請求部４２は、所定期間ごと（例えば毎月一回）自動的に起動し、課金情報ＤＢ４０ａに記憶された利用者Ｕ、サービス事業者ＳおよびプロバイダＲそれぞれの課金情報を集計して明細情報を生成し、明細情報を明細情報ＤＢ４０ｂに格納する処理部である。決済ＧＷ部４３は、請求部４２に起動終了後に自動的に起動し、明細情報ＤＢ４０ｂに記憶された利用者Ｕ、サービス事業者ＳおよびプロバイダＲそれぞれの明細情報に基づいて、決済機関システム５０に料金の引き落とし・振り込み等を依頼するとともに、引き落とし・振り込み等の決済情報を決済情報ＤＢ４０ｃに格納する処理部である。なお、課金情報受信部４１による処理（課金情報受信処理）については、図４０を用いて後に詳述し、また、請求部４２による処理（請求処理）については、図４４を用いて後に詳述し、さらに、決済ＧＷ部４３による処理（決済処理）ついては、図４８を用いて後に詳述する。
【００７８】
ユーザ情報管理部４４は、利用者情報ＤＢ４０ｄ、サービス事業者情報ＤＢ４０ｅおよびプロバイダ情報ＤＢ４０ｆを管理する処理部であり、例えば、利用者端末１０、サービス事業者オペレータ端末２００またはプロバイダオペレータ端末３００から、サービス契約時に利用者情報、サービス事業者情報またはプロバイダ情報の入力を受け付け、課金決済業者オペレータ端末４００から、利用者情報やサービス事業者情報、プロバイダ情報のメンテナンスを受け付けるほか、利用者認証処理を行うなどする。料金情報管理部４５は、サービス料金情報ＤＢ４０ｇを管理する処理部であり、例えば、課金決済業者オペレータ端末４００から、サービス料金情報のメンテナンスを受け付けるなどする。なお、ユーザ情報管理部４４による処理（契約締結処理）については、図１２や図１４、図１６を用いて後に詳述する。
【００７９】
［利用者Ｕおよび課金決済業者Ｋの間における契約締結］
続いて、図１２および図１３を用いて、利用者Ｕおよび課金決済業者Ｋの間における契約締結を説明する。図１２は、利用者Ｕおよび課金決済業者Ｋの間における契約締結処理の流れを示すフローチャートである。
【００８０】
同図に示すように、課金決済装置４０のユーザ情報管理部４４は、利用者端末１０から送信された契約に必要な登録情報を受信すると（ステップＳＴ１２０１）、この利用者Ｕを一意に識別するための利用者識別情報Ｋ−ＩＤ（Ｕ）を発行する（ステップＳＴ１２０２）。
【００８１】
そして、ユーザ情報管理部４４は、発行した識別情報Ｋ−ＩＤ（Ｕ）や利用者端末１０から受信した情報からなる利用者情報を利用者情報ＤＢ４０ｄに登録するとともに（ステップＳＴ１２０３）、発行した識別情報Ｋ−ＩＤ（Ｕ）および契約を締結した旨を示す情報を利用者端末１０に通知する（ステップＳＴ１２０４）。なお、上記した一連の送受信に際しては、第三者への情報漏洩を防止すべく、例えば、ＳＳＬやＶＰＮ（Virtual Private Network）等の暗号化通信技術が用いられる。
【００８２】
ここで、図１３を用いて、上記した処理によって利用者情報ＤＢ４０ｄに登録された利用者情報を説明する。図１３は、課金決済装置４０の利用者情報ＤＢ４０ｄに登録される利用者情報の例を示す図である。同図に示すように、利用者情報としては、発行したＫ−ＩＤ（Ｕ）や、認証に用いるパスワード（暗号化値）の他に、利用者Ｕに関する情報として、利用者Ｕの氏名、住所、固定電話番号、携帯電話番号、ＦＡＸ番号、メールアドレスなどが登録される。なお、パスワードの暗号化は、課金決済業者Ｋだけが知っている任意のアルゴリズムによって行われ、利用者情報ＤＢ４０ｄに登録する際には、例えば、同図に示すように、ＢＡＳＥ６４エンコーディング処理が施される。
【００８３】
さらに、同図に示すように、利用者情報ＤＢ４０ｄには、利用者Ｕの決済方法に関する情報として、指定金融機関、指定支店名、口座種別、口座番号なども登録される。ただし「決済方法に関する情報は、利用者Ｕと課金決済業者Ｋとの間における契約で決める事項であるので、同図に示した具体例以外に、例えば、代金引換払い、請求書払い、クレジット決済など、他の決済方法を採用してもよい。なお、利用者情報ＤＢ４０ｄでは、利用者Ｕとサービス事業者Ｓ、あるいは利用者ＵとプロバイダＲとの間で決められたサービスの契約に関する情報は管理されない。
【００８４】
［サービス事業者Ｓおよび課金決済業者Ｋの間における契約締結］
続いて、図１４および図１５を用いて、サービス事業者Ｓおよび課金決済業者Ｋの間における契約締結を説明する。図１４は、サービス事業者Ｓおよび課金決済業者Ｋの間における契約締結処理の流れを示すフローチャートである。
【００８５】
同図に示すように、課金決済装置４０のユーザ情報管理部４４は、サービス事業者オペレータ端末２００から送信された契約に必要な登録情報を受信すると（ステップＳＴ１４０１）、このサービス事業者Ｓを一意に識別するためのサービス事業者識別情報Ｋ−ＩＤ（Ｓ）を発行する（ステップＳＴ１４０２）。
【００８６】
そして、ユーザ情報管理部４４は、発行した識別情報Ｋ−ＩＤ（Ｓ）やサービス事業者オペレータ端末２００から受信した情報からなるサービス事業者情報をサービス事業者情報ＤＢ４０ｅに登録するとともに（ステップＳＴ１４０３）、発行した識別情報Ｋ−ＩＤ（Ｓ）および契約を締結した旨を示す情報をサービス事業者オペレータ端末２００に通知する（ステップＳＴ１４０４）。なお、上記した一連の送受信に際しては、第三者への情報漏洩を防止すべく、例えば、ＳＳＬやＶＰＮ等の暗号化通信技術が用いられる。
【００８７】
ここで、図１５を用いて、上記した処理によってサービス事業者情報ＤＢ４０ｅに登録されたサービス事業者情報を説明する。図１５は、課金決済装置４０のサービス事業者情報ＤＢ４０ｅに登録されるサービス事業者情報の例を示す図である。同図に示すように、サービス事業者情報としては、発行したＫ−ＩＤ（Ｓ）や、認証に用いるパスワード（暗号化値）の他に、サービス事業者Ｓに関する情報として、サービス事業者Ｓの事業者名、担当者名、担当部署、住所、メールアドレス、電話番号、ＦＡＸ番号などが登録される。なお、パスワードの暗号化は、課金決済業者Ｋだけが知っている任意のアルゴリズムによって行われ、利用者情報ＤＢ４０ｄに登録する際には、例えば、同図に示すように、ＢＡＳＥ６４エンコーディング処理が施される。
【００８８】
さらに、同図に示すように、サービス事業者情報ＤＢ４０ｅには、サービス事業者Ｓの決済方法に関する情報として、指定金融機関、指定支店名、口座種別、口座番号なども登録される。ただし、決済方法に関する情報は、サービス事業者Ｓと課金決済業者Ｋとの間における契約で決める事項であるので、同図に示した具体例以外に、例えば、代金引換払い、請求書払い、クレジット決済など、他の決済方法を採用してもよい。なお、サービス事業者情報ＤＢ４０ｅでは、サービス事業者ＳとプロバイダＲとの間で決められたサービスの契約に関する情報は管理されない。
【００８９】
［プロバイダＲおよび課金決済業者Ｋの間における契約締結］
続いて、図１６および図１７を用いて、プロバイダＲおよび課金決済業者Ｋの間における契約締結を説明する。図１６は、プロバイダＲおよび課金決済業者Ｋの間における契約締結処理の流れを示すフローチャートである。
【００９０】
同図に示すように、課金決済装置４０のユーザ情報管理部４４は、プロバイダオペレータ端末３００から送信された契約に必要な登録情報を受信すると（ステップＳＴ１６０１）、このプロバイダＲを一意に識別するためのプロバイダ識別情報Ｋ−ＩＤ（Ｒ）を発行する（ステップＳＴ１６０２）。
【００９１】
そして、ユーザ情報管理部４４は、発行した識別情報Ｋ−ＩＤ（Ｒ）やプロバイダオペレータ端末３００から受信した情報からなるプロバイダ情報をプロバイダ情報ＤＢ４０ｆに登録するとともに（ステップＳＴ１６０３）、発行した識別情報Ｋ−ＩＤ（Ｒ）および契約を締結した旨を示す情報をプロバイダオペレータ端末３００に通知する（ステップＳＴ１６０４）。なお、上記した一連の送受信に際しては、第三者への情報漏洩を防止すべく、例えば、ＳＳＬやＶＰＮ等の暗号化通信技術が用いられる。
【００９２】
ここで、図１７を用いて、上記した処理によってプロバイダ情報ＤＢ４０ｆに登録されるプロバイダ情報を説明する。図１７は、課金決済装置４０のプロバイダ情報ＤＢ４０ｆに登録されるプロバイダ情報の例を示す図である。同図に示すように、プロバイダ情報としては、発行したＫ−ＩＤ（Ｒ）や、認証に用いるパスワード（暗号化値）の他に、プロバイダＲに関する情報として、プロバイダＲの事業者名、担当者名、担当部署、住所、メールアドレス、電話番号、ＦＡＸ番号などが登録される。なお、パスワードの暗号化は、課金決済業者Ｋだけが知っている任意のアルゴリズムによって行われ、利用者情報ＤＢ４０ｄに登録する際には、例えば、同図に示すように、ＢＡＳＥ６４エンコーディング処理が施される。
【００９３】
さらに、同図に示すように、プロバイダ情報ＤＢ４０ｆには、プロバイダＲの決済方法に関する情報として、指定金融機関、指定支店名、口座種別、口座番号なども登録される。ただし、決済方法に関する情報は、プロバイダＲと課金決済業者Ｋとの間における契約で決める事項であるので、同図に示した具体例以外に、例えば、代金引換払い、請求書払い、クレジット決済など、他の決済方法を採用してもよい。
【００９４】
［利用者Ｕおよびサービス事業者Ｓの間における契約締結処理］
続いて、図１８〜図２１を用いて、利用者Ｕおよびサービス事業者Ｓの間における契約締結を説明する。図１８は、利用者Ｕおよびサービス事業者Ｓの間における契約締結処理の流れを示すフローチャートである。なお、利用者Ｕおよびサービス事業者Ｓの間における契約が締結されるには、利用者Ｕおよび課金決済業者Ｋの間における契約が事前に締結されていること、さらに、サービス事業者Ｓおよび課金決済業者Ｋの間における契約が事前に締結されていることが必要条件である。
【００９５】
同図に示すように、サービス提供装置２０の利用者情報管理部２３は、利用者端末１０からサービス契約の申請を受け付けると（ステップＳＴ１８０１）、利用者情報ＤＢ２０ａの利用者情報に後述する認証値Ｃ１が登録されているか否かを確認する（ステップＳＴ１８０２）。そして、認証値Ｃ１が登録されていない場合には、認証値Ｃ１を取得後に改めて契約申請を行うことを利用者Ｕに促すべく、課金決済装置４０の認証用ＵＲＩ（Uniform Resource Identifiers）を利用者端末１０に通知する（ステップＳＴ１８０３）。
【００９６】
一方、課金決済装置４０のユーザ情報管理部４４は、上記の認証用ＵＲＬによるアクセスを利用者端末１０から受け付けると（ステップＳＴ１８０４）、利用者端末１０に対して認証に必要な情報（識別情報およびパスワード）の入力を要求する（ステップＳＴ１８０５）。そして、課金決済装置４０のユーザ情報管理部４４は、利用者端末１０から利用者識別情報Ｋ−ＩＤ（Ｕ）およびパスワード（ＰＷ）を受け付けると（ステップＳＴ１８０６）、これらに基づいて認証を行い、かかる認証を行った旨を示す認証値Ｃ１を生成して利用者端末１０に返信する（ステップＳＴ１８０７およびＳＴ１８０９）。なお、認証値Ｃ１の生成処理については、図１９を用いて後に詳述する。
【００９７】
そして、サービス提供装置２０の利用者情報管理部２３は、改めて利用者端末１０からサービス契約の申請を受け付けると（ステップＳＴ１８０９）、利用者端末１０に対して契約に必要な情報（認証値Ｃ１など）の入力を要求する（ステップＳＴ１８１０）。その結果、サービス提供装置２０の利用者情報管理部２３は、利用者端末１０から認証値Ｃ１などの情報を受け付けると（ステップＳＴ１８１１）、この利用者Ｕを一意に識別するための利用者識別情報Ｓ−ＩＤ（Ｕ）を発行するとともに（ステップＳＴ１８１２）、発行した識別情報Ｓ−ＩＤ（Ｕ）や利用者端末１０から受信した情報からなる利用者情報を利用者情報ＤＢ２０ａに登録する（ステップＳＴ１８１３）。
【００９８】
さらに、サービス提供装置２０の利用者情報管理部２３は、発行した識別情報Ｓ−ＩＤ（Ｕ）を暗号化して値Ｄ１を生成し（ステップＳＴ１８１４）、この値Ｄ１および上記の認証値Ｃ１とともに、サービス事業者識別情報Ｋ−ＩＤ（Ｓ）を課金決済装置４０に送信してリンク値Ｌ１の生成を申請する（ステップＳＴ１８１５）。なお、識別情報Ｓ−ＩＤ（Ｕ）の暗号化は、サービス事業者Ｓだけが知っている任意の暗号化アルゴリズムＦ３を用いて行われる。これによって、利用者Ｕ以外への識別情報Ｓ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。
【００９９】
かかる申請を受けた課金決済装置４０のユーザ情報管理部４４は、利用者識別情報Ｋ−ＩＤ（Ｕ）および利用者識別情報Ｓ−ＩＤ（Ｕ）の関係を示す情報を暗号化してリンク値Ｌ１を生成し、このリンク値Ｌ１をサービス提供装置２０に返信する（ステップＳＴ１８１６およびＳＴ１８１７）。なお、リンク値Ｌ１の生成処理については、図２０を用いて後に詳述する。
【０１００】
一方、課金決済装置４０からリンク値Ｌ１を受け取ったサービス提供装置２０の利用者情報管理部２３は、このリンク値Ｌ１を上記した利用者情報に対応付けて利用者情報ＤＢ２０ａに追加登録する（ステップＳＴ１８１８）。そして、サービス提供装置２０の利用者情報管理部２３は、発行した識別情報Ｓ−ＩＤ（Ｕ）を利用者端末１０に通知して、契約を締結した旨を利用者Ｕに知らせる（ステップＳＴ１８１９）。なお、上記した一連の送受信に際しては、第三者への情報漏洩を防止すべく、例えば、ＳＳＬやＶＰＮ等の暗号化通信技術が用いられる。
【０１０１】
（１）認証値Ｃ１の生成処理
続いて、図１９を用いて、上記した認証値Ｃ１の生成処理を説明する。図１９は、認証値Ｃ１の生成処理の流れを示すフローチャートである。
【０１０２】
同図に示すように、課金決済装置４０のユーザ情報管理部４４は、利用者端末１０から利用者識別情報Ｋ−ＩＤ（Ｕ）およびパスワード（ＰＷ）を受け取ると、これらに基づいて認証を行う（ステップＳＴ１９０１）。すなわち、受け取った識別情報Ｋ−ＩＤ（Ｕ）およびパスワードが利用者情報ＤＢ４０ｄに対応付けて記憶されているか否かを判定する。
【０１０３】
その結果、認証が失敗した場合（認証ＮＧ）には、認証値Ｃ１を生成することなく処理を終了する。これとは反対に、認証が成功した場合（認証ＯＫ）には、ユーザ情報管理部４４は、識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として鍵生成アルゴリズムＦ２から共通鍵Ｋｅｙ１を生成し（ステップＳＴ１９０２）、この鍵Ｋｅｙ１および暗号化アルゴリズムＦ１によって識別情報Ｋ−ＩＤ（Ｕ）を暗号化して認証値Ｃ１を生成する（ステップＳＴ１９０３）。
【０１０４】
このように、課金決済業者Ｋがサービス事業者Ｓに対して識別情報Ｋ−ＩＤ（Ｕ）の値をそのまま見せずに、暗号化された認証値Ｃ１に埋め込むので、利用者Ｕ以外への識別情報Ｋ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。
【０１０５】
また、認証値Ｃ１は、識別情報Ｋ−ＩＤ（Ｓ）を元にして生成された共通鍵Ｋｅｙ１によって暗号化することで生成するので、仮に認証値Ｃ１が外部に漏れたとしても、識別情報Ｋ−ＩＤ（Ｓ）を知らなければＫ−ＩＤ（Ｕ）を導き出すことはできない。また、認証値Ｃ１および識別情報Ｋ−ＩＤ（Ｓ）を知っているサービス事業者Ｓであっても、Ｋ−ＩＤ（Ｓ）から共通鍵Ｋｅｙ１を生成するためのアルゴリズムＦ２を知らないので、認証値Ｃ１からＫ−ＩＤ（Ｕ）を導き出すことはできない。したがって、利用者Ｕ以外の第三者による識別情報Ｋ−ＩＤ（Ｕ）の取得を防止することが可能になる。
【０１０６】
（２）リンク値Ｌ１の生成処理
続いて、図２０を用いて、上記したリンク値Ｌ１の生成処理を説明する。図２０は、リンク値Ｌ１の生成処理の流れを示すフローチャートである。
【０１０７】
同図に示すように、課金決済装置４０のユーザ情報管理部４４は、サービス提供装置２０から値Ｄ１および認証値Ｃ１とともにサービス事業者識別情報Ｋ−ＩＤ（Ｓ）を受け取ると、識別情報Ｋ−ＩＤ（Ｓ）の値を乱数値として鍵生成アルゴリズムＦ２から共通鍵Ｋｅｙ１を生成し（ステップＳＴ２００１）、この鍵Ｋｅｙ１および暗号化アルゴリズムＦ１によって認証値Ｃ１を復号化して識別情報Ｋ−ＩＤ（Ｕ）を生成する（ステップＳＴ２００２）。
【０１０８】
そして、ユーザ情報管理部４４は、値Ａ（復号化した識別情報Ｋ−ＩＤ（Ｕ）の値）と値Ｄ１（サービス提供装置２０から受け取った値）とのバイト値を比較し（ステップＳＴ２００３）、どちらかが短い場合には（ステップＳＴ２００４否定）、短い方の値の末尾から不足分を“００”でパディングする（ステップＳＴ２００５）。つまり、短い方の識別情報のバイト数を長い方の識別情報と揃えるために、両者の長さ（バイト数）を比較して、短い方の不足するバイト数分を１６進数値「０ｘ００」でパディングする。
【０１０９】
その後、ユーザ情報管理部４４は、値Ａ（復号化した識別情報Ｋ−ＩＤ（Ｕ）の値、若しくはパディング後の値）と値Ｄ１（サービス提供装置２０から受け取った値、若しくはパディング後の値）との排他的論理和をとって値Ｘ１を生成し（ステップＳＴ２００６）、さらに、この値Ｘ１を鍵Ｋｅｙ１および暗号化アルゴリズムＦ１によって暗号化して、Ｋ−ＩＤ（Ｕ）およびＳ−ＩＤ（Ｕ）のリンクを示すリンク値Ｌ１を生成する（ステップＳＴ２００７）。
【０１１０】
このように、課金決済業者Ｋがサービス事業者Ｓに対して識別情報Ｋ−ＩＤ（Ｕ）の値をそのまま見せずに、暗号化されたリンク値Ｌ１に埋め込むので、利用者Ｕ以外への識別情報Ｋ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。
【０１１１】
また、リンク値Ｌ１は、識別情報Ｋ−ＩＤ（Ｓ）を元にして生成された共通鍵Ｋｅｙ１によって暗号化することで生成するので、仮にリンク値Ｌ１が外部に漏れたとしても、識別情報Ｋ−ＩＤ（Ｓ）を知らなければＫ−ＩＤ（Ｕ）を導き出すことはできない。また、リンク値Ｌ１および識別情報Ｋ−ＩＤ（Ｓ）を知っているサービス事業者Ｓであっても、Ｋ−ＩＤ（Ｓ）から共通鍵Ｋｅｙ１を生成するためのアルゴリズムＦ２を知らないので、リンク値Ｌ１からＫ−ＩＤ（Ｕ）を導き出すことはできない。したがって、利用者Ｕ以外の第三者による識別情報Ｋ−ＩＤ（Ｕ）の取得を防止することが可能になる。
【０１１２】
（３）利用者情報
続いて、図２１を用いて、上記した処理によってサービス提供装置２０の利用者情報ＤＢ２０ａに登録される利用者情報を説明する。図２１は、サービス提供装置２０の利用者情報ＤＢ２０ａに登録される利用者情報の例を示す図である。
【０１１３】
同図に示すように、利用者情報としては、サービス提供装置２０が発行したＳ−ＩＤ（Ｕ）や、認証に用いるパスワード（暗号化値）、課金決済装置４０が生成したリンク値Ｌ１の他に、利用者Ｕに関する情報として、利用者Ｕの氏名、住所、固定電話番号、携帯電話番号、ＦＡＸ番号、メールアドレスなどが登録される。なお、パスワードの暗号化は、サービス事業者Ｓだけが知っている任意のアルゴリズムによって行われ、利用者情報ＤＢ２０ａに登録する際には、例えば、同図に示すように、ＢＡＳＥ６４エンコーディング処理が施される。また、リンク値Ｌ１も、利用者情報ＤＢ２０ａに登録する際には、ＢＡＳＥ６４エンコーディング処理が施される。
【０１１４】
さらに、同図に示すように、利用者情報ＤＢ２０ａには、利用者Ｕのサービス契約に関する情報として、サービス事業者Ｓが予め用意しているサービス（例えば、サービスＡ、サービスＢ・・・）ごとにサービスの加入状況（加入済み、若しくは、未加入）を示す情報なども登録される。
【０１１５】
［利用者ＵおよびプロバイダＲの間における契約締結処理］
続いて、図２２〜図２５を用いて、利用者ＵおよびプロバイダＲの間における契約締結を説明する。図２２は、利用者ＵおよびプロバイダＲの間における契約締結処理の流れを示すフローチャートである。なお、利用者ＵおよびプロバイダＲの間における契約が締結されるには、利用者Ｕおよび課金決済業者Ｋの間における契約が事前に締結されていること、さらに、プロバイダＲおよび課金決済業者Ｋの間における契約が事前に締結されていることが必要条件である。
【０１１６】
同図に示すように、プロバイダ装置３０のユーザ情報管理部３３は、利用者端末１０からサービス契約の申請を受け付けると（ステップＳＴ２２０１）、利用者情報ＤＢ３０ａの利用者情報に後述する認証値Ｃ２が登録されているか否かを確認する（ステップＳＴ２２０２）。そして、認証値Ｃ２が登録されていない場合には、認証値Ｃ２を取得後に改めて契約申請を行うことを利用者Ｕに促すべく、課金決済装置４０の認証用ＵＲＩを利用者端末１０に通知する（ステップＳＴ２２０３）。
【０１１７】
一方、課金決済装置４０のユーザ情報管理部４４は、上記の認証用ＵＲＬによるアクセスを利用者端末１０から受け付けると（ステップＳＴ２２０４）、利用者端末１０に対して認証に必要な情報（識別情報およびパスワード）の入力を要求する（ステップＳＴ２２０５）。そして、課金決済装置４０のユーザ情報管理部４４は、利用者端末１０から利用者識別情報Ｋ−ＩＤ（Ｕ）およびパスワード（ＰＷ）を受け付けると（ステップＳＴ２２０６）、これらに基づいて認証を行い、かかる認証を行った旨を示す認証値Ｃ２を生成して利用者端末１０に返信する（ステップＳＴ２２０７およびＳＴ２２０８）。なお、認証値Ｃ２の生成処理については、図２３を用いて後に詳述する。
【０１１８】
そして、プロバイダ装置３０のユーザ情報管理部３３は、改めて利用者端末１０からサービス契約の申請を受け付けると（ステップＳＴ２２０９）、利用者端末１０に対して契約に必要な情報（認証値Ｃ２など）の入力を要求する（ステップＳＴ２２１０）。その結果、プロバイダ装置３０のユーザ情報管理部３３は、利用者端末１０から認証値Ｃ２などの情報を受け付けると（ステップＳＴ２２１１）、この利用者Ｕを一意に識別するための利用者識別情報Ｒ−ＩＤ（Ｕ）を発行するとともに（ステップＳＴ２２１２）、発行した識別情報Ｒ−ＩＤ（Ｕ）や利用者端末１０から受信した情報からなる利用者情報を利用者情報ＤＢ３０ａに登録する（ステップＳＴ２２１３）。
【０１１９】
さらに、プロバイダ装置３０のユーザ情報管理部３３は、発行した識別情報Ｒ−ＩＤ（Ｕ）を暗号化して値Ｄ２を生成し（ステップＳＴ２２１４）、この値Ｄ２および上記の認証値Ｃ２とともに、プロバイダ識別情報Ｋ−ＩＤ（Ｒ）を課金決済装置４０に送信してリンク値Ｌ２の生成を申請する（ステップＳＴ２２１５）。なお、識別情報Ｒ−ＩＤ（Ｕ）の暗号化は、プロバイダＲだけが知っている任意の暗号化アルゴリズムＦ４を用いて行われる。これによって、利用者Ｕ以外への識別情報Ｒ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。
【０１２０】
かかる申請を受けた課金決済装置４０のユーザ情報管理部４４は、利用者識別情報Ｋ−ＩＤ（Ｕ）および利用者識別情報Ｒ−ＩＤ（Ｕ）の関係を示す情報を暗号化してリンク値Ｌ２を生成し、このリンク値Ｌ２をプロバイダ装置３０に返信する（ステップＳＴ２２１６およびＳＴ２２１７）。なお、リンク値Ｌ２の生成処理については、図２４を用いて後に詳述する。
【０１２１】
一方、課金決済装置４０からリンク値Ｌ２を受け取ったプロバイダ装置３０のユーザ情報管理部３３は、このリンク値Ｌ２を上記した利用者情報に対応付けて利用者情報ＤＢ３０ａに追加登録する（ステップＳＴ２２１８）。そして、プロバイダ装置３０のユーザ情報管理部３３は、発行した識別情報Ｒ−ＩＤ（Ｕ）を利用者端末１０に通知して、契約を締結した旨を利用者Ｕに知らせる（ステップＳＴ２２１９）。なお、上記した一連の送受信に際しては、第三者への情報漏洩を防止すべく、例えば、ＳＳＬやＶＰＮ等の暗号化通信技術が用いられる。
【０１２２】
（１）認証値Ｃ２の生成処理
続いて、図２３を用いて、上記した認証値Ｃ２の生成処理を説明する。図２３は、認証値Ｃ２の生成処理の流れを示すフローチャートである。
【０１２３】
同図に示すように、課金決済装置４０のユーザ情報管理部４４は、利用者端末１０から利用者識別情報Ｋ−ＩＤ（Ｕ）およびパスワード（ＰＷ）を受け取ると、これらに基づいて認証を行う（ステップＳＴ２３０１）。すなわち、受け取った識別情報Ｋ−ＩＤ（Ｕ）およびパスワードが利用者情報ＤＢ４０ｄに対応付けて記憶されているか否かを判定する。
【０１２４】
その結果、認証が失敗した場合（認証ＮＧ）には、認証値Ｃ２を生成することなく処理を終了する。これとは反対に、認証が成功した場合（認証ＯＫ）には、ユーザ情報管理部４４は、識別情報Ｋ−ＩＤ（Ｒ）の値を乱数値として鍵生成アルゴリズムＦ２から共通鍵Ｋｅｙ２を生成し（ステップＳＴ２３０２）、この鍵Ｋｅｙ２および暗号化アルゴリズムＦ１によって識別情報Ｋ−ＩＤ（Ｕ）を暗号化して認証値Ｃ２を生成する（ステップＳＴ２３０３）。
【０１２５】
このように、課金決済業者ＫがプロバイダＲに対して識別情報Ｋ−ＩＤ（Ｕ）の値をそのまま見せずに、暗号化された認証値Ｃ２に埋め込むので、利用者Ｕ以外への識別情報Ｋ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。
【０１２６】
また、認証値Ｃ２は、識別情報Ｋ−ＩＤ（Ｒ）を元にして生成された共通鍵Ｋｅｙ２によって暗号化することで生成するので、仮に認証値Ｃ２が外部に漏れたとしても、識別情報Ｋ−ＩＤ（Ｒ）を知らなければＫ−ＩＤ（Ｕ）を導き出すことはできない。また、認証値Ｃ２および識別情報Ｋ−ＩＤ（Ｒ）を知っているプロバイダＲであっても、Ｋ−ＩＤ（Ｒ）から共通鍵Ｋｅｙ２を生成するためのアルゴリズムＦ２を知らないので、認証値Ｃ２からＫ−ＩＤ（Ｕ）を導き出すことはできない。したがって、利用者Ｕ以外の第三者による識別情報Ｋ−ＩＤ（Ｕ）の取得を防止することが可能になる。
【０１２７】
（２）リンク値Ｌ２の生成処理
続いて、図２４を用いて、上記したリンク値Ｌ２の生成処理を説明する。図２４は、リンク値Ｌ２の生成処理の流れを示すフローチャートである。
【０１２８】
同図に示すように、課金決済装置４０のユーザ情報管理部４４は、プロバイダ装置３０から値Ｄ２および認証値Ｃ２とともにプロバイダ事業者識別情報Ｋ−ＩＤ（Ｒ）を受け取ると、識別情報Ｋ−ＩＤ（Ｒ）の値を乱数値として鍵生成アルゴリズムＦ２から共通鍵Ｋｅｙ２を生成し（ステップＳＴ２４０１）、この鍵Ｋｅｙ２および暗号化アルゴリズムＦ１によって認証値Ｃ２を復号化して識別情報Ｋ−ＩＤ（Ｕ）を生成する（ステップＳＴ２４０２）。
【０１２９】
そして、ユーザ情報管理部４４は、値Ａ（復号化した識別情報Ｋ−ＩＤ（Ｕ）の値）と値Ｄ２（プロバイダ装置３０から受け取った値）とのバイト値を比較し（ステップＳＴ２４０３）、どちらかが短い場合には（ステップＳＴ２４０４否定）、短い方の値の末尾から不足分を“００”でパディングする（ステップＳＴ２４０５）。つまり、短い方の識別情報のバイト数を長い方の識別情報と揃えるために、両者の長さ（バイト数）を比較して、短い方の不足するバイト数分を１６進数値「０ｘ００」でパディングする。
【０１３０】
その後、ユーザ情報管理部４４は、値Ａ（復号化した識別情報Ｋ−ＩＤ（Ｕ）の値、若しくはパディング後の値）と値Ｄ２（プロバイダ装置３０から受け取った値、若しくはパディング後の値）との排他的論理和をとって値Ｘ２を生成し（ステップＳＴ２４０６）、さらに、この値Ｘ２を鍵Ｋｅｙ２および暗号化アルゴリズムＦ１によって暗号化して、Ｋ−ＩＤ（Ｕ）およびＲ−ＩＤ（Ｕ）のリンクを示すリンク値Ｌ２を生成する（ステップＳＴ２４０７）。
【０１３１】
このように、課金決済業者ＫがプロバイダＲに対して識別情報Ｋ−ＩＤ（Ｕ）の値をそのまま見せずに、暗号化されたリンク値Ｌ２に埋め込むので、利用者Ｕ以外への識別情報Ｋ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。
【０１３２】
また、リンク値Ｌ２は、識別情報Ｋ−ＩＤ（Ｒ）を元にして生成された共通鍵Ｋｅｙ２によって暗号化することで生成するので、仮にリンク値Ｌ２が外部に漏れたとしても、識別情報Ｋ−ＩＤ（Ｒ）を知らなければＫ−ＩＤ（Ｕ）を導き出すことはできない。また、リンク値Ｌ２および識別情報Ｋ−ＩＤ（Ｒ）を知っているプロバイダＲであっても、Ｋ−ＩＤ（Ｒ）から共通鍵Ｋｅｙ２を生成するためのアルゴリズムＦ２を知らないので、リンク値Ｌ２からＫ−ＩＤ（Ｕ）を導き出すことはできない。したがって、利用者Ｕ以外の第三者による識別情報Ｋ−ＩＤ（Ｕ）の取得を防止することが可能になる。
【０１３３】
（３）利用者情報
続いて、図２５を用いて、上記した処理によってプロバイダ装置３０の利用者情報ＤＢ３０ａに登録される利用者情報を説明する。図２５は、プロバイダ装置３０の利用者情報ＤＢ３０ａに登録される利用者情報の例を示す図である。
【０１３４】
同図に示すように、利用者情報としては、プロバイダ装置３０が発行したＲ−ＩＤ（Ｕ）や、認証に用いるパスワード（暗号化値）、課金決済装置４０が生成したリンク値Ｌ２の他に、利用者Ｕに関する情報として、利用者Ｕの氏名、住所、固定電話番号、携帯電話番号、ＦＡＸ番号、メールアドレスなどが登録される。なお、パスワードの暗号化は、プロバイダＲだけが知っている任意のアルゴリズムによって行われ、利用者情報ＤＢ３０ａに登録する際には、例えば、同図に示すように、ＢＡＳＥ６４エンコーディング処理が施される。また、リンク値Ｌ２も、利用者情報ＤＢ３０ａに登録する際には、ＢＡＳＥ６４エンコーディング処理が施される。
【０１３５】
さらに、同図に示すように、利用者情報ＤＢ３０ａには、利用者Ｕのサービス契約に関する情報として、プロバイダＲが予め用意しているサービス（例えば、サービスＡ、サービスＢ・・・）ごとにサービスの加入状況（加入しているサービスのランク）を示す情報なども登録される。
【０１３６】
［サービス事業者ＳおよびプロバイダＲの間における契約締結処理］
続いて、図２６〜図２９を用いて、サービス事業者ＳおよびプロバイダＲの間における契約締結を説明する。図２６は、サービス事業者ＳおよびプロバイダＲの間における契約締結処理の流れを示すフローチャートである。なお、サービス事業者ＳおよびプロバイダＲの間における契約が締結されるには、サービス事業者Ｓおよび課金決済業者Ｋの間における契約が事前に締結されていること、さらに、プロバイダＲおよび課金決済業者Ｋの間における契約が事前に締結されていることが必要条件である。
【０１３７】
同図に示すように、プロバイダ装置３０のユーザ情報管理部３３は、サービス事業者オペレータ端末２００からサービス契約の申請を受け付けると（ステップＳＴ２６０１）、サービス事業者情報ＤＢ３０ｂのサービス事業者情報に後述する認証値Ｃ３が登録されているか否かを確認する（ステップＳＴ２６０２）。そして、認証値Ｃ３が登録されていない場合には、認証値Ｃ３を取得後に改めて契約申請を行うことをサービス事業者Ｓに促すべく、課金決済装置４０の認証用ＵＲＩをサービス事業者オペレータ端末２００に通知する（ステップＳＴ２６０３）。
【０１３８】
一方、課金決済装置４０のユーザ情報管理部４４は、上記の認証用ＵＲＬによるアクセスをサービス事業者オペレータ端末２００から受け付けると（ステップＳＴ２６０４）、サービス事業者オペレータ端末２００に対して認証に必要な情報（識別情報およびパスワード）の入力を要求する（ステップＳＴ２６０５）。そして、課金決済装置４０のユーザ情報管理部４４は、サービス事業者オペレータ端末２００から利用者識別情報Ｋ−ＩＤ（Ｓ）およびパスワード（ＰＷ）を受け付けると（ステップＳＴ２６０６）、これらに基づいて認証を行い、かかる認証を行った旨を示す認証値Ｃ３を生成してサービス事業者オペレータ端末２００に返信する（ステップＳＴ２６０７およびＳＴ２６０８）。なお、認証値Ｃ３の生成処理については、図２７を用いて後に詳述する。
【０１３９】
そして、プロバイダ装置３０のユーザ情報管理部３３は、改めてサービス事業者オペレータ端末２００からサービス契約の申請を受け付けると（ステップＳＴ２６０９）、サービス事業者オペレータ端末２００に対して契約に必要な情報（認証値Ｃ３など）の入力を要求する（ステップＳＴ２６１０）。その結果、プロバイダ装置３０のユーザ情報管理部３３は、サービス事業者オペレータ端末２００から認証値Ｃ３どの情報を受け付けると（ステップＳＴ２６１１）、このサービス事業者Ｓを一意に識別するためのサービス事業者識別情報Ｒ−ＩＤ（Ｓ）を発行するとともに（ステップＳＴ２６１２）、発行した識別情報Ｒ−ＩＤ（Ｓ）やサービス事業者オペレータ端末２００から受信した情報からなるサービス事業者情報をサービス事業者情報ＤＢ３０ｂに登録する（ステップＳＴ２６１３）。
【０１４０】
さらに、プロバイダ装置３０のユーザ情報管理部３３は、発行した識別情報Ｒ−ＩＤ（Ｓ）を暗号化して値Ｄ３を生成し（ステップＳＴ２６１４）、この値Ｄ３および上記の認証値Ｃ３とともに、プロバイダ識別情報Ｋ−ＩＤ（Ｒ）を課金決済装置４０に送信してリンク値Ｌ３の生成を申請する（ステップＳＴ２６１５）。なお、識別情報Ｒ−ＩＤ（Ｓ）の暗号化は、プロバイダＲだけが知っている任意の暗号化アルゴリズムＦ５を用いて行われる。これによって、サービス事業者Ｓ以外への識別情報Ｒ−ＩＤ（Ｓ）の漏洩を防止することが可能になる。
【０１４１】
かかる申請を受けた課金決済装置４０のユーザ情報管理部４４は、サービス事業者識別情報Ｋ−ＩＤ（Ｓ）およびサービス事業者識別情報Ｒ−ＩＤ（Ｓ）の関係を示す情報を暗号化してリンク値Ｌ３を生成し、このリンク値Ｌ３をプロバイダ装置３０に返信する（ステップＳＴ２６１６およびＳＴ２６１７）。なお、リンク値Ｌ３の生成処理については、図２８を用いて後に詳述する。
【０１４２】
一方、課金決済装置４０からリンク値Ｌ３を受け取ったプロバイダ装置３０のユーザ情報管理部３３は、このリンク値Ｌ３を上記したサービス事業者情報に対応付けてサービス事業者情報ＤＢ３０ｂに追加登録する（ステップＳＴ２６１８）。そして、プロバイダ装置３０のユーザ情報管理部３３は、発行した識別情報Ｒ−ＩＤ（Ｓ）をサービス事業者オペレータ端末２００に通知して、契約を締結した旨をサービス事業者Ｓに知らせる（ステップＳＴ２６１９）。なお、上記した一連の送受信に際しては、第三者への情報漏洩を防止すべく、例えば、ＳＳＬやＶＰＮ等の暗号化通信技術が用いられる。
【０１４３】
（１）認証値Ｃ３の生成処理
続いて、図２７を用いて、上記した認証値Ｃ３の生成処理を説明する。図２７は、認証値Ｃ３の生成処理の流れを示すフローチャートである。
【０１４４】
同図に示すように、課金決済装置４０のユーザ情報管理部４４は、サービス事業者オペレータ端末２００から利用者識別情報Ｋ−ＩＤ（Ｓ）およびパスワード（ＰＷ）を受け取ると、これらに基づいて認証を行う（ステップＳＴ２７０１）。すなわち、受け取った識別情報Ｋ−ＩＤ（Ｓ）およびパスワードがサービス事業者情報ＤＢ４０ｅに対応付けて記憶されているか否かを判定する。
【０１４５】
その結果、認証が失敗した場合（認証ＮＧ）には、認証値Ｃ３を生成することなく処理を終了する。これとは反対に、認証が成功した場合（認証ＯＫ）には、ユーザ情報管理部４４は、識別情報Ｋ−ＩＤ（Ｒ）の値を乱数値として鍵生成アルゴリズムＦ２から共通鍵Ｋｅｙ２を生成し（ステップＳＴ２７０２）、この鍵Ｋｅｙ２および暗号化アルゴリズムＦ１によって識別情報Ｋ−ＩＤ（Ｓ）を暗号化して認証値Ｃ３を生成する（ステップＳＴ２７０３）。
【０１４６】
このように、課金決済業者ＫがプロバイダＲに対して識別情報Ｋ−ＩＤ（Ｓ）の値をそのまま見せずに、暗号化された認証値Ｃ３に埋め込むので、サービス事業者Ｓ以外への識別情報Ｋ−ＩＤ（Ｓ）の漏洩を防止することが可能になる。
【０１４７】
また、認証値Ｃ３は、識別情報Ｋ−ＩＤ（Ｒ）を元にして生成された共通鍵Ｋｅｙ２によって暗号化することで生成するので、仮に認証値Ｃ３が外部に漏れたとしても、識別情報Ｋ−ＩＤ（Ｒ）を知らなければＫ−ＩＤ（Ｓ）を導き出すことはできない。また、認証値Ｃ３および識別情報Ｋ−ＩＤ（Ｒ）を知っているプロバイダＲであっても、Ｋ−ＩＤ（Ｒ）から共通鍵Ｋｅｙ２を生成するためのアルゴリズムＦ２を知らないので、認証値Ｃ３からＫ−ＩＤ（Ｓ）を導き出すことはできない。したがって、サービス事業者Ｓ以外の第三者による識別情報Ｋ−ＩＤ（Ｓ）の取得を防止することが可能になる。
【０１４８】
（２）リンク値Ｌ３の生成処理
続いて、図２８を用いて、上記したリンク値Ｌ３の生成処理を説明する。図２８は、リンク値Ｌ３の生成処理の流れを示すフローチャートである。
【０１４９】
同図に示すように、課金決済装置４０のユーザ情報管理部４４は、プロバイダ装置３０から値Ｄ３および認証値Ｃ３とともにプロバイダ事業者識別情報Ｋ−ＩＤ（Ｒ）を受け取ると、識別情報Ｋ−ＩＤ（Ｒ）の値を乱数値として鍵生成アルゴリズムＦ２から共通鍵Ｋｅｙ２を生成し（ステップＳＴ２８０１）、この鍵Ｋｅｙ２および暗号化アルゴリズムＦ１によって認証値Ｃ３を復号化して識別情報Ｋ−ＩＤ（Ｓ）を生成する（ステップＳＴ２８０２）。
【０１５０】
そして、ユーザ情報管理部４４は、値Ａ（復号化した識別情報Ｋ−ＩＤ（Ｓ）の値）と値Ｄ３（プロバイダ装置３０から受け取った値）とのバイト値を比較し（ステップＳＴ２８０３）、どちらかが短い場合には（ステップＳＴ２８０４否定）、短い方の値の末尾から不足分を“００”でパディングする（ステップＳＴ２８０５）。つまり、短い方の識別情報のバイト数を長い方の識別情報と揃えるために、両者の長さ（バイト数）を比較して、短い方の不足するバイト数分を１６進数値「０ｘ００」でパディングする。
【０１５１】
その後、ユーザ情報管理部４４は、値Ａ（復号化した識別情報Ｋ−ＩＤ（Ｓ）の値、若しくはパディング後の値）と値Ｄ３（プロバイダ装置３０から受け取った値、若しくはパディング後の値）との排他的論理和をとって値Ｘ３を生成し（ステップＳＴ２８０６）、さらに、この値Ｘ３を鍵Ｋｅｙ２および暗号化アルゴリズムＦ１によって暗号化して、Ｋ−ＩＤ（Ｓ）およびＲ−ＩＤ（Ｓ）のリンクを示すリンク値Ｌ３を生成する（ステップＳＴ２８０７）。
【０１５２】
このように、課金決済業者ＫがプロバイダＲに対して識別情報Ｋ−ＩＤ（Ｓ）の値をそのまま見せずに、暗号化されたリンク値Ｌ３に埋め込むので、サービス事業者Ｓ以外への識別情報Ｋ−ＩＤ（Ｓ）の漏洩を防止することが可能になる。
【０１５３】
また、リンク値Ｌ３は、識別情報Ｋ−ＩＤ（Ｒ）を元にして生成された共通鍵Ｋｅｙ２によって暗号化することで生成するので、仮にリンク値Ｌ３が外部に漏れたとしても、識別情報Ｋ−ＩＤ（Ｒ）を知らなければＫ−ＩＤ（Ｓ）を導き出すことはできない。また、リンク値Ｌ３および識別情報Ｋ−ＩＤ（Ｒ）を知っているプロバイダＲであっても、Ｋ−ＩＤ（Ｒ）から共通鍵Ｋｅｙ２を生成するためのアルゴリズムＦ２を知らないので、リンク値Ｌ３からＫ−ＩＤ（Ｓ）を導き出すことはできない。したがって、サービス事業者Ｓ以外の第三者による識別情報Ｋ−ＩＤ（Ｓ）の取得を防止することが可能になる。
【０１５４】
（３）サービス事業者情報
続いて、図２９を用いて、上記した処理によってプロバイダ装置３０のサービス事業者情報ＤＢ３０ｂに登録されるサービス事業者情報を説明する。図２９は、プロバイダ装置３０のサービス事業者情報ＤＢ３０ｂに登録されるサービス事業者情報の例を示す図である。
【０１５５】
同図に示すように、サービス事業者情報としては、プロバイダ装置３０が発行したＲ−ＩＤ（Ｓ）や、認証に用いるパスワード（暗号化値）、課金決済装置４０が生成したリンク値Ｌ３の他に、サービス事業者Ｓに関する情報として、サービス事業者Ｓの事業者名、担当者名、住所、メールアドレス、電話番号、ＦＡＸ番号などが登録される。なお、パスワードの暗号化は、プロバイダＲだけが知っている任意のアルゴリズムによって行われ、サービス事業者情報ＤＢ３０ｂに登録する際には、例えば、同図に示すように、ＢＡＳＥ６４エンコーディング処理が施される。また、リンク値Ｌ３も、サービス事業者情報ＤＢ３０ｂに登録する際には、ＢＡＳＥ６４エンコーディング処理が施される。
【０１５６】
さらに、同図に示すように、サービス事業者情報ＤＢ３０ｂには、サービス事業者Ｓのサービス契約に関する情報として、プロバイダＲが予め用意しているサービス（例えば、プロバイダサービス）ごとにサービスの加入状況（加入済み、若しくは、未加入）を示す情報なども登録される。
【０１５７】
［課金情報の送受信処理］
続いて、図３０を用いて、課金情報の送受信処理を説明する。図３０は、課金情報の送受信処理の流れを示すフローチャートである。なお、以下に説明する課金情報の送受信処理は、所定の期間（例えば、毎月の締め日後など）ごとに実行される。
【０１５８】
同図に示すように、サービス提供装置２０の課金情報送信部２２またはプロバイダ装置３０の課金情報送信部３２は、利用者Ｕやサービス事業者Ｓに係る課金情報の送信開始を示すシグナルを課金決済装置４０に送信する（ステップＳＴ３００１）。一方、課金決済装置４０の課金情報受信部４１は、かかるシグナルを受信すると、送信開始のシグナルを受信した旨をサービス提供装置２０またはプロバイダ装置３０に返信する（ステップＳＴ３００２）。
【０１５９】
その後、サービス提供装置２０の課金情報送信部２２またはプロバイダ装置３０の課金情報送信部３２は、課金情報を課金決済装置４０に送信する（ステップＳＴ３００３）。一方、課金決済装置４０の課金情報受信部４１は、かかる課金情報を受信すると、課金情報を受信した旨をサービス提供装置２０またはプロバイダ装置３０に返信する（ステップＳＴ３００４）。
【０１６０】
そして、全ての課金情報を課金決済装置４０に送信すると、サービス提供装置２０の課金情報送信部２２またはプロバイダ装置３０の課金情報送信部３２は、課金情報の送信終了を示すシグナルを課金決済装置４０に送信する（ステップＳＴ３００５）。一方、課金決済装置４０の課金情報受信部４１は、かかるシグナルを受信すると、送信終了のシグナルを受信した旨をサービス提供装置２０またはプロバイダ装置３０に返信する（ステップＳＴ３００６）。
【０１６１】
このようにして、サービス提供装置２０またはプロバイダ装置３０と課金決済装置４０との間で、利用者Ｕやサービス事業者Ｓに係る課金情報が送受信される。なお、上記した一連の送受信に際しては、第三者への情報漏洩を防止すべく、例えば、ＳＳＬやＶＰＮ等の暗号化通信技術が用いられる。また、図３０では、１往復分の課金情報の送受信のみを示しているが、例えば、利用者Ｕまたはサービス事業者Ｓごとに課金情報を送信する場合には、ステップＳＴ３００３およびＳＴ３００４の処理が、利用者Ｕまたはサービス事業者Ｓごとに繰り返し行われる。
【０１６２】
［サービス提供装置による課金情報送信処理］
続いて、図３１〜図３４を用いて、上記したサービス提供装置２０による課金情報送信処理の詳細を説明する。図３１は、サービス提供装置２０による課金情報送信処理の流れを示すフローチャートである。なお、以下に説明する課金情報の送信処理は、所定の期間（例えば、毎月の締め日後など）ごとに実行される。
【０１６３】
同図に示すように、サービス提供装置２０の課金情報送信部２２は、利用者Ｕについて課金計算を行う（ステップＳＴ３１０１〜ＳＴ３１０４）。具体的には、課金情報送信部２２は、カウンタｉを設定した後（ステップＳＴ３１０１）、利用者Ｕの料金総計ＳＵＭ１の算出（課金計算処理）を行い、カウンタｉをインクリメントする処理（ステップＳＴ３１０２およびＳＴ３１０３）を、カウンタｉがｎ（課金情報の総数、すなわち当該月の課金処理件数）と等しくなるまで繰り返す（ステップＳＴ３１０４）。なお、かかる課金計算処理については、図３２を用いて後に詳述する。
【０１６４】
その後、課金情報送信部２２は、カウンタｉがｎになると（ステップＳＴ３１０４否定）、計算した課金情報の送信開始を示すシグナルを課金決済装置４０に送信する（ステップＳＴ３１０５）。そして、かかる送信開始のシグナルを受信した旨を課金決済装置４０から受信すると（ステップＳＴ３１０６肯定）、課金情報送信部２２は、ｎ個の課金情報を一つずつ課金決済装置４０に送信する（ステップＳＴ３１０７〜ＳＴ３１１２）。
【０１６５】
具体的には、課金情報送信部２２は、カウンタｉを設定した後（ステップＳＴ３１０７）、識別情報Ｓ−ＩＤ（Ｕ）を暗号化アルゴリズムＦ３で暗号化して値Ｄ１を生成し、利用者Ｕの課金情報（利用者Ｕの値Ｄ１、リンク値Ｌ１、後述する料金総計ＳＵＭ１、課金対象となる月を示す情報、識別情報Ｋ−ＩＤ（Ｓ）からなる情報）を課金決済装置４０に送信し、課金決済装置４０から課金情報受信の通知を受けるとカウンタｉをインクリメントする処理（ステップＳＴ３１０８〜ＳＴ３１１１）を、カウンタｉがｎ（課金情報の総数、すなわち当該月の課金処理件数）と等しくなるまで繰り返す（ステップＳＴ３１１２）。
【０１６６】
その後、課金情報送信部２２は、課金情報を全て送信してカウンタｉがｎになると（ステップＳＴ３１１２否定）、課金情報の送信終了を示すシグナルを課金決済装置４０に送信する（ステップＳＴ３１１３）。そして、送信終了のシグナルを受信した旨を課金決済装置４０から受信して処理を終了する（ステップＳＴ３１１４肯定）。
【０１６７】
（１）課金計算処理
続いて、図３２を用いて、上記したサービス提供装置２０による課金計算処理を説明する。図３２は、サービス提供装置２０による課金計算処理の流れを示すフローチャートである。
【０１６８】
同図に示すように、サービス提供装置２０の課金情報送信部２２は、利用者情報ＤＢ２０ａから課金情報の送信対象となる利用者Ｕのサービス加入状況を検索するとともに（ステップＳＴ３２０１）、サービス料金情報ＤＢ２０ｂから各サービスの料金情報を検索する（ステップＳＴ３２０２）。
【０１６９】
そして、課金情報送信部２２は、以下の式を用いて各利用者Ｕの料金総計ＳＵＭ１を算出する（ステップＳＴ３２０３）。
ＳＵＭ１＝Σ（Ｂｉｌｌ（ｋ）×ｆ（ｋ））・・・ｋ＝１〜ｍ
ｍ：提供するサービス総数
Ｂｉｌｌ（ｋ）：ｋ番目のサービスの料金
ｆ（ｋ）＝｛１（ｋ番目のサービス加入済み）、０（ｋ番目のサービス未加入）｝
【０１７０】
（２）サービス料金情報
ここで、図３３を用いて、上記の課金計算処理で用いられるサービス料金情報について説明する。図３３は、サービス提供装置２０のサービス料金情報ＤＢ２０ｂに記憶されたサービス料金情報の例を示す図である。
【０１７１】
同図に示すように、サービス料金情報としては、サービス事業者Ｓが提供するサービスごとに、サービス名（例えば、サービスＡ、サービスＢ・・・）、料金種別（例えば、月額定額）、締日（例えば、当月末日）、料金（例えば、１０００円）などが登録される。そして、上記の課金計算処理では、サービス料金情報のなかの「料金」が用いられる。
【０１７２】
（３）課金計算処理の具体例
また、図３４を用いて、上記した課金計算処理を具体的に説明する。図３４は、サービス提供装置２０による課金計算処理の具体例を説明するための図である。
【０１７３】
同図に示すように、サービス提供装置２０の課金情報送信部２２では、利用者情報ＤＢ２０ａのサービスＡおよびサービスＢに関する加入状況と、サービス料金情報ＤＢ２０ｂのサービスＡおよびサービスＢに関する料金情報とをそれぞれ関連付けて、利用者Ｕの料金総計ＳＵＭ１を算出する。
【０１７４】
すなわち、例を挙げれば、同図に示すように、利用者ＵがサービスＡについては加入済みであるが、サービスＢについては未加入であったとすると、サービスＡおよびサービスＢの料金は、それぞれ「１０００円」であるので、料金総計ＳＵＭ１＝１０００×１＋１０００×０＝１０００円となる。その結果、同図に示すような課金情報Ｔ１３が、サービス提供装置２０から課金決済装置４０に送信される。なお、課金情報Ｔ１３のうち、値Ｄ１およびリンク値Ｌ１は、利用者Ｕに関する情報である。
【０１７５】
［プロバイダ装置による課金情報送信処理］
続いて、図３５〜図３９を用いて、上記したプロバイダ装置３０による課金情報送信処理の詳細を説明する。図３５は、プロバイダ装置３０による課金情報送信処理の流れを示すフローチャートである。なお、以下に説明する課金情報の送信処理は、所定の期間（例えば、毎月の締め日後など）ごとに実行される。
【０１７６】
同図に示すように、プロバイダ装置３０の課金情報送信部３２は、利用者Ｕおよびサービス事業者Ｓについて課金計算を行う（ステップＳＴ３５０１〜ＳＴ３５０４）。具体的には、課金情報送信部３２は、カウンタｉを設定した後（ステップＳＴ３５０１）、課金計算処理（利用者Ｕの料金総計ＳＵＭ２の算出、サービス事業者Ｓの料金総計ＳＵＭ３の算出）を行い、カウンタｉをインクリメントする処理（ステップＳＴ３５０２およびＳＴ３５０３）を、カウンタｉがｎ（課金情報の総数、すなわち当該月の課金処理件数）と等しくなるまで繰り返す（ステップＳＴ３５０４）。なお、かかる課金計算処理については、図３６を用いて後に詳述する。
【０１７７】
その後、課金情報送信部３２は、カウンタｉがｎになると（ステップＳＴ３５０４否定）、計算した課金情報の送信開始を示すシグナルを課金決済装置４０に送信する（ステップＳＴ３５０５）。そして、かかる送信開始のシグナルを受信した旨を課金決済装置４０から受信すると（ステップＳＴ３５０６肯定）、課金情報送信部３２は、ｈ個の課金情報を一つずつ課金決済装置４０に送信する（ステップＳＴ３５０７〜ＳＴ３５１５）。
【０１７８】
具体的には、課金情報送信部３２は、カウンタｉを設定した後（ステップＳＴ３５０７）、利用者Ｕおよびサービス事業者Ｓの課金情報を課金決済装置４０にそれぞれ送信し、課金決済装置４０から課金情報受信の通知を受けるとカウンタｉをインクリメントする処理（ステップＳＴ３５０８〜ＳＴ３５１４）を、カウンタｉがｈ（課金情報の総数、すなわち当該月の課金処理件数）と等しくなるまで繰り返す（ステップＳＴ３５１５）。
【０１７９】
より詳細には、処理対象が利用者Ｕの課金情報であるか、サービス事業者Ｓの課金情報であるかを判定し（ステップＳＴ３５０８）、利用者Ｕの課金情報である場合には、識別情報Ｒ−ＩＤ（Ｕ）を暗号化アルゴリズムＦ４で暗号化して値Ｄ２を生成し、利用者Ｕの課金情報（利用者Ｕの値Ｄ２、リンク値Ｌ２、後述する料金総計ＳＵＭ２、課金対象となる月を示す情報、識別情報Ｋ−ＩＤ（Ｒ）からなる情報）を課金決済装置４０に送信する（ステップＳＴ３５０９およびＳＴ３５１０）。一方、サービス事業者Ｓの課金情報については、識別情報Ｒ−ＩＤ（Ｓ）を暗号化アルゴリズムＦ５で暗号化して値Ｄ３を生成し、サービス事業者Ｓの課金情報（サービス事業者Ｓの値Ｄ３、リンク値Ｌ３、後述する料金総計ＳＵＭ３、課金対象となる月を示す情報、識別情報Ｋ−ＩＤ（Ｒ）からなる情報）を課金決済装置４０に送信する（ステップＳＴ３５１１およびＳＴ３５１２）。
【０１８０】
その後、課金情報送信部３２は、課金情報を全て送信してカウンタｉがｈになると（ステップＳＴ３５１５否定）、課金情報の送信終了を示すシグナルを課金決済装置４０に送信する（ステップＳＴ３５１６）。そして、送信終了のシグナルを受信した旨を課金決済装置４０から受信して処理を終了する（ステップＳＴ３５１７肯定）。
【０１８１】
（１）課金計算処理
続いて、図３６を用いて、上記したプロバイダ装置３０による課金計算処理を説明する。図３６は、プロバイダ装置３０による課金計算処理の流れを示すフローチャートである。
【０１８２】
同図に示すように、プロバイダ装置３０の課金情報送信部３２は、処理対象が利用者Ｕの課金情報であるか、サービス事業者Ｓの課金情報であるかを判定し（ステップＳＴ３６０１）、以下に述べるようにして、それぞれの課金情報を計算する。
【０１８３】
すなわち、利用者Ｕの課金情報の場合には、利用者情報ＤＢ３０ａから課金情報の送信対象となる利用者Ｕのサービスランクを検索するとともに（ステップＳＴ３６０２）、サービス料金情報ＤＢ３０ｃから各サービスの料金情報を検索する（ステップＳＴ３６０３）。
【０１８４】
そして、課金情報送信部３２は、以下の式を用いて各利用者Ｕの料金総計ＳＵＭ２を算出する（ステップＳＴ３６０４）。つまり、例を挙げると、プロバイダＲが利用者Ｕに対して、記録情報の保存容量と保存期間に応じて複数種類の料金パターンを用意している場合には、以下の式が用いられる。
ＳＵＭ２＝Σサービスごとの料金
【０１８５】
一方、サービス事業者Ｓの課金情報の場合には、サービス事業者情報ＤＢ３０ｂから課金情報の送信対象となるサービス事業者Ｓのサービス加入状況を検索するとともに（ステップＳＴ３６０５）、サービス料金情報ＤＢ３０ｃから各サービスの料金情報を検索する（ステップＳＴ３６０６）。
【０１８６】
そして、課金情報送信部３２は、以下の式を用いて各サービス事業者Ｓの料金総計ＳＵＭ３を算出する（ステップＳＴ３６０７）。つまり、例を挙げると、プロバイダＲがサービス事業者Ｓに対して、記録管理サービスを提供しており、このサービスに加入することがサービス事業者Ｓにおいて必須である場合には、以下の式が用いられる。
ＳＵＭ３＝サービス料金×｛１（サービス加入済み）  or  ０（サービス未加入）｝
【０１８７】
（２）サービス料金情報
ここで、図３７を用いて、上記の課金計算処理で用いられるサービス料金情報について説明する。図３７は、プロバイダ装置３０のサービス料金情報ＤＢ３０ｃに記憶されたサービス料金情報の例を示す図である。
【０１８８】
同図に示すように、サービス料金情報は、利用者Ｕ向けサービスのテーブル（同図では、Ｔ０９、Ｔ１０）、サービス事業者Ｓ向けサービスのテーブル（同図では、Ｔ１１）に区分けして登録される。具体的には、利用者Ｕ向けサービスとして、サービスａおよびサービスｂの２種類が用意されており、提供形態によって「１、２、３・・・」とランク分けされているような場合には、同図に示すように、サービスごとに、ランク（例えば、１、２、３・・・）、料金種別（例えば、月額定額）、締日（例えば、当月末日）、料金（例えば、２００円）などが登録される。
【０１８９】
同様に、サービス事業者Ｓ向けサービスのサービス料金情報としては、同図に示すように、サービス名、料金種別（例えば、月額定額）、締日（例えば、当月末日）、料金（例えば、１００００円）などが登録される。そして、上記の課金計算処理では、サービス料金情報のなかの「料金」が用いられる。
【０１９０】
（３）利用者Ｕに関する課金計算処理の具体例
ここで、図３８を用いて、上記した利用者Ｕに関する課金計算処理を具体的に説明する。図３８は、プロバイダ装置３０による課金計算処理の具体例を説明するための図である。
【０１９１】
同図に示すように、プロバイダ装置３０の課金情報送信部３２では、利用者情報ＤＢ３０ａのサービスａおよびサービスｂに関する契約状況と、サービス料金情報ＤＢ３０ｃのサービスａおよびサービスｂに関する料金情報とをそれぞれ関連付けて、利用者Ｕの料金総計ＳＵＭ２を算出する。
【０１９２】
すなわち、例を挙げれば、同図に示すように、利用者Ｕが、サービスａについてはランク１で契約し、サービスｂについてはランク２で契約したとすると、サービスａおよびサービスｂの料金は、それぞれ「２００円」であるので、料金総計ＳＵＭ２＝２００＋２００＝４００円となる。その結果、同図に示すような課金情報Ｔ１４が、プロバイダ装置３０から課金決済装置４０に送信される。なお、課金情報Ｔ１４のうち、値Ｄ２およびリンク値Ｌ２は、利用者Ｕに関する情報である。
【０１９３】
（４）サービス事業者Ｓに関する課金計算処理の具体例
さらに、図３９を用いて、上記したサービス事業者Ｓに関する課金計算処理を具体的に説明する。図３９は、プロバイダ装置３０による課金計算処理の具体例を説明するための図である。
【０１９４】
同図に示すように、プロバイダ装置３０の課金情報送信部３２では、サービス事業者情報ＤＢ３０ｂのサービス加入状況と、サービス料金情報ＤＢ３０ｃの料金情報とを関連付けて、サービス事業者Ｓの料金総計ＳＵＭ３を算出する。
【０１９５】
すなわち、例を挙げれば、同図に示すように、サービス事業者ＳがプロバイダＲのサービスに加入していたとすると、そのサービスの料金は、「１００００円」であるので、料金総計ＳＵＭ３＝１００００×１＝１００００円となる。その結果、同図に示すような課金情報Ｔ１５が、プロバイダ装置３０から課金決済装置４０に送信される。なお、課金情報Ｔ１５のうち、値Ｄ３およびリンク値Ｌ３は、サービス事業者Ｓに関する情報である。
【０１９６】
［課金決済装置による課金情報受信処理］
続いて、図４０〜図４３を用いて、上記した課金決済装置４０による課金情報受信処理の詳細を説明する。図４０は、課金決済装置４０による課金情報受信処理の流れを示すフローチャートである。なお、以下に説明する課金情報の受信処理は、所定の期間（例えば、サービス事業者ＳやプロバイダＲにおける毎月の締め日後など）ごとに実行される。
【０１９７】
同図に示すように、課金決済装置４０の課金情報受信部４１は、サービス提供装置２０またはプロバイダ装置３０から、利用者Ｕやサービス事業者Ｓに係る課金情報の送信開始を示すシグナルを受信すると（ステップＳＴ４００１肯定）、送信開始のシグナルを受信した旨をサービス提供装置２０またはプロバイダ装置３０に返信する（ステップＳＴ４００２）。
【０１９８】
その後、課金情報受信部４１は、サービス提供装置２０またはプロバイダ装置３０から課金情報を受信すると（ステップＳＴ４００４肯定）、受信した課金情報を課金情報ＤＢ４０ａに保存し（ステップＳＴ４００５）、課金情報を受信した旨をサービス提供装置２０またはプロバイダ装置３０に返信する（ステップＳＴ４００６）。
【０１９９】
そして、課金情報受信部４１は、このような保存および返信を課金情報の受信の度に行い、サービス提供装置２０またはプロバイダ装置３０から課金情報の送信終了を示すシグナルを受信すると（ステップＳＴ４００３肯定）、送信終了のシグナルを受信した旨をサービス提供装置２０またはプロバイダ装置３０に返信する（ステップＳＴ４００７）。
【０２００】
その後、課金情報受信部４１は、課金決済業者Ｋに対するサービス事業者ＳまたはプロバイダＲの課金情報（課金決済サービス料金に関する課金情報）を算出して課金情報ＤＢ４０ａに保存する（ステップＳＴ４００８）。なお、かかる課金情報の算出については、図４２および図４３を用いて後に詳述する。
【０２０１】
そして、課金情報受信部４１は、課金決済サービス料金に関する課金情報を課金情報ＤＢ４０ａに保存した後は、後述する請求処理を起動して課金情報受信処理を終了する（ステップＳＴ４００９）。なお、かかる請求処理については、図４４〜図４７を用いて後に詳述する。
【０２０２】
このように、サービス提供装置２０またはプロバイダ装置３０において予め料金計算がなされているので、課金決済装置４０では、サービスの契約や料金に関する情報を管理する必要がなく、課金決済業者Ｋによる情報の維持管理負担を軽減することが可能になる。
【０２０３】
（１）課金情報
続いて、図４１を用いて、上記した処理によって課金決済装置４０の課金情報ＤＢ４０ａに登録される課金情報を説明する。図４１は、課金決済装置４０の課金情報ＤＢ４０ａに登録される課金情報の例を示す図である。
【０２０４】
同図に示すように、課金情報ＤＢ４０ａに登録される課金情報としては、サービス提供装置２０から受信した利用者Ｕに関する課金情報（同図では、Ｔ１３）、プロバイダ装置３０から受信した利用者Ｕに関する課金情報（同図では、Ｔ１４）、プロバイダ装置３０から受信したサービス事業者Ｓに関する課金情報（同図では、Ｔ１５）、課金決済装置４０が算出したサービス事業者Ｓに関する課金情報（同図では、Ｔ１６）、課金決済装置４０が算出したプロバイダＲに関する課金情報（同図では、Ｔ１７）がある。
【０２０５】
このうち、サービス提供装置２０から受信した利用者Ｕに関する課金情報Ｔ１３としては、同図に示すように、利用者Ｕの値Ｄ１（識別情報Ｓ−ＩＤ（Ｕ）の暗号化値）、リンク値Ｌ１、送信元であるサービス事業者識別情報Ｋ−ＩＤ（Ｓ）、課金対象となる月を示す情報、利用料金ＳＵＭ１などが登録される。
【０２０６】
また、プロバイダ装置３０から受信した利用者Ｕに関する課金情報Ｔ１４としては、同図に示すように、利用者Ｕの値Ｄ２（識別情報Ｒ−ＩＤ（Ｕ）の暗号化値）、リンク値Ｌ２、送信元であるプロバイダ識別情報Ｋ−ＩＤ（Ｒ）、課金対象となる月を示す情報、利用料金ＳＵＭ２などが登録される。
【０２０７】
また、プロバイダ装置３０から受信したサービス事業者Ｓに関する課金情報Ｔ１５としては、同図に示すように、サービス事業者Ｓの値Ｄ３（識別情報Ｒ−ＩＤ（Ｓ）の暗号化値）、リンク値Ｌ３、送信元であるプロバイダ識別情報Ｋ−ＩＤ（Ｒ）、課金対象となる月を示す情報、利用料金ＳＵＭ３などが登録される。
【０２０８】
また、課金決済装置４０が算出したサービス事業者Ｓに関する課金情報Ｔ１６としては、サービス事業者識別情報Ｋ−ＩＤ（Ｓ）、課金対象となる月を示す情報、後述する利用料金などが登録される。同様に、課金決済装置４０が算出したプロバイダＲに関する課金情報Ｔ１７としては、プロバイダ識別情報Ｋ−ＩＤ（Ｒ）、課金対象となる月を示す情報、後述する利用料金などが登録される。
【０２０９】
ところで、値Ｄ１〜Ｄ３、リンク値Ｌ１〜Ｌ３は、いずれもＢＡＳＥ６４エンコーディング処理が施されている。また、課金情報Ｔ１３〜Ｔ１５は、統一されたフォーマットになっており、この順序で送られてくることが課金決済業者Ｋとサービス事業者ＳまたはプロバイダＲとの間で予め決められている。
【０２１０】
また、同図では、説明の便宜上、Ｋ−ＩＤ（Ｓ）やＫ−ＩＤ（Ｒ）といった具合に、カラムに記述されている識別情報の種類を明示したが、実際には値だけが送信されてくるので、その種類を判別するには、サービス事業者情報ＤＢ４０ｅやプロバイダ情報ＤＢ４０ｆを検索することになる。なお、課金情報Ｔ１６およびＴ１７については、課金決済装置４０で自動生成される情報であるので、Ｋ−ＩＤ（Ｓ）やＫ−ＩＤ（Ｒ）は暗号化されておらず、また、リンク値に相当する情報も存在しない。
【０２１１】
（２）サービス料金情報
ここで、図４２を用いて、上記の課金計算処理で用いられるサービス料金情報について説明する。図４２は、課金決済装置４０のサービス料金情報ＤＢ４０ｇに記憶されたサービス料金情報の例を示す図である。
【０２１２】
同図に示すように、課金決済業者Ｋはサービス事業者ＳやプロバイダＲに対してサービス料金を代行して回収する課金決済サービスを提供するものであり、サービス料金情報としては、サービス名、サービス内容、料金種別（例えば、月額定額）、締日（例えば、当月末日）、料金（例えば、５０００円）などが登録される。そして、上記の課金計算処理では、サービス料金情報のなかの「料金」が用いられる。
【０２１３】
（３）課金計算処理の具体例
また、図４３を用いて、上記した課金計算処理を具体的に説明する。図４３は、課金決済装置４０による課金計算処理の具体例を説明するための図である。
【０２１４】
同図に示すように、課金決済装置４０の課金情報受信部４１では、サービス事業者情報ＤＢ４０ｅからサービス事業者Ｓの識別情報Ｋ−ＩＤ（Ｓ）を検索した後に、サービス料金情報ＤＢ４０ｇのサービス料金「５０００円」を用いて利用料金「５０００円」を算出する。そして、識別情報Ｋ−ＩＤ（Ｓ）、課金対象となる月を示す情報、および利用料金「５０００円」からなる課金情報を生成して、課金情報ＤＢ４０ａに保存する。
【０２１５】
同様に、課金決済装置４０の課金情報受信部４１は、同図に示すように、プロバイダ情報ＤＢ４０ｆからプロバイダＲの識別情報Ｋ−ＩＤ（Ｒ）を検索した後に、サービス料金情報ＤＢ４０ｇのサービス料金「５０００円」を用いて利用料金「５０００円」を算出する。そして、識別情報Ｋ−ＩＤ（Ｒ）、課金対象となる月を示す情報、および利用料金「５０００円」からなる課金情報を生成して、課金情報ＤＢ４０ａに保存する。
【０２１６】
［課金決済装置による請求処理］
続いて、図４４〜図４７を用いて、課金決済装置４０による請求処理の詳細を説明する。図４４は、課金決済装置４０による請求処理の流れを示すフローチャートである。なお、以下に説明する請求処理は、上記した課金情報の受信処理（図４０参照）に続いて、所定の期間（例えば、サービス事業者ＳやプロバイダＲにおける毎月の締め日後など）ごとに実行される。
【０２１７】
同図に示すように、課金決済装置４０の請求部４２は、利用者Ｕ、サービス事業者ＳおよびプロバイダＲについてそれぞれ明細情報を生成する（ステップＳＴ４４０１〜ＳＴ４４０５）。具体的には、請求部４２は、カウンタｉを設定した後（ステップＳＴ４４０１）、課金情報ＤＢ４０ａから一つのレコード（課金情報）を取得し、取得した課金情報から明細情報を生成し、カウンタｉをインクリメントする処理（ステップＳＴ４４０２〜ＳＴ４４０４）を、カウンタｉがｐ（課金情報の総数、すなわち当該月の課金処理件数）と等しくなるまで繰り返す（ステップＳＴ４４０５）。なお、かかる明細情報の生成処理については、図４５を用いて後に詳述する。
【０２１８】
その後、課金情報送信部３２は、カウンタｉがｐになると（ステップＳＴ４４０５否定）、後述する決済ＧＷ処理を起動して請求処理を終了する（ステップＳＴ４４０６）。なお、かかる決済処理については、図４８および図４９を用いて後に詳述する。
【０２１９】
（１）明細情報の生成処理
続いて、図４５を用いて、上記した明細情報の生成処理を説明する。図４５は、課金決済装置４０による明細情報の生成処理の流れを示すフローチャートである。
【０２２０】
同図に示すように、課金決済装置４０の請求部４２は、課金情報ＤＢ４０ａから取得した１レコード（課金情報）から料金情報（以下、料金情報Ｂと表記する。）を抽出し（ステップＳＴ４５０１）、課金情報の送信元である識別番号Ｖ（識別情報Ｋ−ＩＤ（Ｓ）または識別番号Ｋ−ＩＤ（Ｒ）のいずれか）がレコード内に存在するかを判定する（ステップＳＴ４５０２）。
【０２２１】
そして、識別番号Ｖが存在する場合には、請求部４２は、課金情報から識別番号Ｖ、値Ｄ（この時点ではＤ１、Ｄ２、Ｄ３のいずれであるか判別されていない値Ｄ）およびリンク値Ｌ（この時点ではＬ１、Ｌ２、Ｌ３のいずれであるか判別されていないリンク値Ｌ）を抽出する（ステップＳＴ４５０３）。
【０２２２】
さらに、請求部４２は、識別番号Ｖの値を乱数値として鍵生成アルゴリズムＦ２から共通鍵を生成する（ステップＳＴ４５０４）。なお、この場合も、識別番号ＶがＫ−ＩＤ（Ｓ）かＫ−ＩＤ（Ｒ）のいずれであるか判別できないため、鍵がＫｅｙ１であるかＫｅｙ２であるかも判別できないが、「Ｋ、Ｄ、Ｌ」の組合せは保持されているので、問題なく以降の処理に進むことができる。
【０２２３】
請求部４２は、上記で生成した鍵および暗号化アルゴリズムＦ１によってリンク値Ｌを復号化して値Ｘを生成し（ステップＳＴ４５０５）、この値Ｘと値Ｄの排他的論理和から課金対象者の識別情報Ｅ（Ｋ−ＩＤ（Ｕ）またはＫ−ＩＤ（Ｓ）のいずれか）を生成する（ステップＳＴ４５０６）。さらに、請求部４２は、利用者情報ＤＢ４０ｄ、サービス事業者情報ＤＢ４０ｅおよびプロバイダ情報ＤＢ４０ｆを検索して、送信元の識別番号Ｖおよび課金対象者の識別情報Ｅを特定する（ステップＳＴ４５０７）。
アルゴリズムＦ２
【０２２４】
この後、請求部４２は、課金情報の送信元がサービス事業者ＳであるかプロバイダＲであるかを判別し（ステップＳＴ４５０８）、送信元がサービス事業者Ｓである場合には、課金対象者は利用者Ｕになるので、利用者Ｕの明細情報内の請求金額情報に、料金情報Ｂの金額を加算するとともに（ステップＳＴ４５０９）、サービス事業者Ｓの明細情報内の収入金額情報に、料金情報Ｂを加算する（ステップＳＴ４５１０）。なお、当該月の料金情報Ｂが複数ある場合には、料金情報Ｂを合算する。
【０２２５】
一方、課金情報の送信元がプロバイダＲである場合には、請求部４２は、課金対象者が利用者Ｕであるかサービス事業者Ｓであるかをさらに判別し（ステップＳＴ４５１１）、課金対象者が利用者Ｕである場合には、利用者Ｕの明細情報内の請求金額情報に、料金情報Ｂの金額を加算するとともに（ステップＳＴ４５１２）、プロバイダＲの明細書情報内の収入金額情報に、料金情報Ｂを加算する（ステップＳＴ４５１３）。なお、当該月の料金情報Ｂが複数ある場合には、料金情報Ｂを合算する。
【０２２６】
さらに、課金対象者がサービス事業者Ｓである場合には、請求部４２は、サービス事業者Ｓの明細情報内の請求金額情報に、料金情報Ｂの金額を加算するとともに（ステップＳＴ４５１４）、プロバイダＲの明細書情報内の収入金額情報に、料金情報Ｂを加算する（ステップＳＴ４５１５）。なお、当該月の料金情報Ｂが複数ある場合には、料金情報Ｂを合算する。
【０２２７】
また、上記のステップＳＴ４５０２の判定において、課金情報の送信元である識別番号Ｖがレコード内に存在しない場合には、課金決済装置４０の内部で生成された課金情報であるので、請求部４２は、課金情報ＤＢ４０ａから取得した１レコード（課金情報）から課金対象者の識別情報Ｇ（Ｋ−ＩＤ（Ｓ）またはＫ−ＩＤ（Ｒ）のいずれか）を抽出する（ステップＳＴ４５１６）。
【０２２８】
そして、請求部４２は、課金対象者がサービス事業者ＳであるかプロバイダＲであるかをさらに判別し（ステップＳＴ４５１７）、課金対象者がサービス事業者Ｓである場合には、サービス事業者Ｓの明細情報内の請求金額情報に、料金情報Ｂの金額を加算する（ステップＳＴ４５１８）。その一方、課金対象者がプロバイダＲである場合には、請求部４２は、プロバイダＲの明細情報内の請求金額情報に、料金情報Ｂの金額を加算する（ステップＳＴ４５１９）。なお、当該月の料金情報Ｂが複数ある場合には、料金情報Ｂを合算する。
【０２２９】
（２）明細情報
続いて、図４６を用いて、上記した処理によって課金決済装置４０の明細情報ＤＢ４０ｂに登録される明細情報を説明する。図４６は、課金決済装置４０の明細情報ＤＢ４０ｂに登録される明細情報の例を示す図である。
【０２３０】
同図に示すように、明細情報ＤＢ４０ｂに登録される明細情報としては、利用者Ｕの明細情報（同図では、Ｔ１８）、サービス事業者Ｓの明細情報（同図では、Ｔ１９）、プロバイダＲの明細情報（同図では、Ｔ２０）があり、支払金額を示す数値には黒三角を付している。
【０２３１】
このうち、利用者Ｕの明細情報Ｔ１８としては、同図に示すように、利用者Ｕの識別情報Ｋ−ＩＤ（Ｕ）、明細処理月、サービス事業者Ｓのサービスに対する利用料金、プロバイダＳのサービスに対する利用料金、収支合計額（支払合計額）などが登録される。例えば、当該明細処理月（２００４年６月）について、サービス事業者Ｓのサービスを１０００円分利用し、プロバイダＲのサービスを４００円分利用したとすると、合計で１４００円の料金を支払うことになり、同図に示すように、支払合計額として「１４００円」が登録される。
【０２３２】
また、サービス事業者Ｓの明細情報Ｔ１９としては、同図に示すように、サービス事業者Ｓの識別情報Ｋ−ＩＤ（Ｓ）、明細処理月、利用者Ｕの代金総計、プロバイダＲのサービスに対する利用料金、課金決済業者Ｋのサービスに対する利用料金、収支合計額（支払合計額または収入合計額）などが登録される。例えば、当該明細処理月（２００４年６月）について、利用者Ｕから合計で１０００００円の代金が入る一方で、プロバイダＲのサービスを１００００円分利用し、課金決済業者Ｋのサービスを５０００円分利用したとすると、合計で８５０００円の料金が支払われることになり、同図に示すように、収入合計額として「８５０００円」が登録される。
【０２３３】
また、プロバイダＲの明細情報Ｔ２０としては、同図に示すように、プロバイダＲの識別情報Ｋ−ＩＤ（Ｒ）、明細処理月、利用者Ｕの代金総計、サービス事業者Ｓの代金総計、課金決済業者Ｋのサービスに対する利用料金、収支合計額（支払合計額または収入合計額）などが登録される。例えば、当該明細処理月（２００４年６月）について、利用者Ｕから合計で５００００円の代金が入り、サービス事業者Ｓから１００００円の代金が入る一方で、課金決済業者Ｋのサービスを５０００円分利用したとすると、合計で５５０００円の料金が支払われることになり、同図に示すように、収入合計額として「５５０００円」が登録される。
【０２３４】
（３）課金情報と明細情報との関係例
続いて、図４７を用いて、課金決済装置４０の課金情報ＤＢ４０ａに登録される課金情報と明細情報ＤＢ４０ｂに登録される明細情報との関係例を説明する。図４７は、課金決済装置４０の課金情報ＤＢ４０ａに登録される課金情報と明細情報ＤＢ４０ｂに登録される明細情報との関係例を示す図である。
【０２３５】
同図に示すように、利用者Ｕの課金情報Ｔ１３の利用料金は、利用者Ｕの明細情報Ｔ１８におけるサービス事業者Ｓのサービスに対する利用料金に対応するとともに、サービス事業者Ｓの明細情報Ｔ１９における利用者Ｕの代金総計に対応する。なお、ここでは、複数の利用者Ｕが存在する場合を例に挙げている。
【０２３６】
また、利用者Ｕの課金情報Ｔ１４の利用料金は、利用者Ｕの明細情報Ｔ１８におけるプロバイダＲのサービスに対する利用料金に対応するとともに、プロバイダＲの明細情報Ｔ２０における利用者Ｕの代金総計に対応する。なお、ここでは、複数の利用者Ｕが存在する場合を例に挙げている。
【０２３７】
また、サービス事業者Ｓの課金情報Ｔ１５の利用料金は、サービス事業者Ｓの明細情報Ｔ１９におけるプロバイダＲのサービスに対する利用料金に対応するとともに、プロバイダＲの明細情報Ｔ２０におけるサービス事業者Ｓの代金総計に対応する。なお、ここでは、サービス事業者Ｓが一つである場合を例に挙げている。
【０２３８】
また、サービス事業者Ｓの課金情報Ｔ１６の利用料金は、サービス事業者Ｓの明細情報Ｔ１９における課金決済業者Ｋのサービスに対する利用料金に対応する。同様に、プロバイダＲの課金情報Ｔ１７の利用料金は、プロバイダＲの明細情報Ｔ２０における課金決済業者Ｋのサービスに対する利用料金に対応する。
【０２３９】
［課金決済装置による請求処理］
続いて、図４８および図４９を用いて、課金決済装置４０による決済処理の詳細を説明する。図４８は、課金決済装置４０による決済処理の流れを示すフローチャートである。なお、以下に説明する決済処理は、上記した請求処理（図４４参照）に続いて、所定の期間（例えば、サービス事業者ＳやプロバイダＲにおける毎月の締め日後など）ごとに実行される。
【０２４０】
同図に示すように、課金決済装置４０の決済ＧＷ部４３は、カウンタｉを設定した後（ステップＳＴ４８０１）、明細情報ＤＢ４０ｂから１レコードを抽出し（ステップＳＴ４８０２）、この１レコードから収支合計額Ｗを抽出する（ステップＳＴ４８０３）。そして、決済ＧＷ部４３は、収支合計額Ｗがマイナスである場合には（ステップＳＴ４８０４肯定）、収支合計額Ｗを引き落とし処理するものと判断し（ステップＳＴ４８０５）、一方、収支合計額Ｗがマイナスでない場合には（ステップＳＴ４８０４否定）、収支合計額Ｗを振り込み処理するものと判断する（ステップＳＴ４８０６）。
【０２４１】
その上で、決済ＧＷ部４３は、１レコードから識別情報を抽出し（ステップＳＴ４８０７）、抽出した識別情報が利用者Ｕ、サービス事業者ＳまたはプロバイダＲのいずれであるかを判定する（ステップＳＴ４８０８）。そして、決済ＧＷ部４３は、抽出した識別情報がＫ−ＩＤ（Ｕ）である場合には、利用者情報ＤＢ４０ｄから当該利用者Ｕの決済方法に関する情報を抽出する（ステップＳＴ４８０９）。
【０２４２】
一方、抽出した識別情報がＫ−ＩＤ（Ｓ）である場合には、決済ＧＷ部４３は、サービス事業者情報ＤＢ４０ｅから当該サービス事業者Ｓの決済方法に関する情報を抽出し（ステップＳＴ４８１０）、また、抽出した識別情報がＫ−ＩＤ（Ｒ）である場合には、プロバイダ情報ＤＢ４０ｆから当該プロバイダＲの決済方法に関する情報を抽出する（ステップＳＴ４８１１）。
【０２４３】
その後、決済ＧＷ部４３は、決済機関システム５０に対して、上記のステップＳＴ４８０９〜ＳＴ４８１１で抽出した決済方法に従って、収支合計額Ｗの引き落とし処理若しくは振り込み処理を依頼し（ステップＳＴ４８１２）、決済情報を決済情報ＤＢ４０ｃに記録する（ステップＳＴ４８１３）。なお、かかる決済情報については、図４９を用いて後に詳述する。
【０２４４】
決済情報ＤＢ４０ｃに決済情報を記録した後、決済ＧＷ部４３は、カウンタｉをインクリメントし（ステップＳＴ４８１４）、上記したステップＳＴ４８０２〜ＳＴ４８１４の処理を、カウンタｉがｔ（当該月の明細情報の総数）と等しくなるまで繰り返し（ステップＳＴ４８１５）、カウンタｉがｔになると（ステップＳＴ４８１５否定）、決済処理を終了する。
【０２４５】
ここで、図４９を用いて、上記した処理によって課金決済装置４０の決済情報ＤＢ４０ｃに登録される決済情報を説明する。図４９は、課金決済装置４０の決済情報ＤＢ４０ｃに登録される決済情報の例を示す図である。
【０２４６】
同図に示すように、決済情報ＤＢ４０ｃに登録される決済情報としては、利用者Ｕの決済情報（同図では、Ｔ２１）、サービス事業者Ｓの決済情報（同図では、Ｔ２２）、プロバイダＲの決済情報（同図では、Ｔ２３）がある。なお、これらの決済情報は、決済機関システム５０に対して、決済依頼（振り込み若しくは引き落としの依頼）を行ったことを示す情報として記録されるものである。
【０２４７】
このうち、利用者Ｕの決済情報Ｔ２１としては、同図に示すように、利用者Ｕの識別情報Ｋ−ＩＤ（Ｕ）、明細処理月、引き落とし額の他に、引き落としの金融機関、支店名、口座番号、引き落としの依頼日時などが記録される。
【０２４８】
また、サービス事業者Ｓの決済情報Ｔ２２としては、同図に示すように、サービス事業者Ｓの識別情報Ｋ−ＩＤ（Ｓ）、明細処理月、振り込み額の他に、振り込みの金融機関、支店名、口座番号、振り込みの依頼日時などが記録される。
【０２４９】
また、プロバイダＲの決済情報Ｔ２３としては、同図に示すように、プロバイダＲの識別情報Ｋ−ＩＤ（Ｒ）、明細処理月、振り込み額の他に、振り込みの金融機関、支店名、口座番号、振り込みの依頼日時などが記録される。
【０２５０】
［本実施例の効果］
上記した実施例によれば、課金決済業者Ｋおよびサービス事業者Ｓがそれぞれ発行する利用者識別情報Ｋ−ＩＤ（Ｕ）とＳ−ＩＤ（Ｕ）の関係を示す情報をサービス事業者Ｓに管理させるので、課金決済処理に必要な情報が分散管理され、課金決済業者Ｋによる情報の維持管理コストが大幅に削減され、課金決済システムを低コストで導入して運用することが可能になる。
【０２５１】
また、上記した実施例によれば、課金決済業者Ｋがサービス事業者Ｓに対して識別情報Ｋ−ＩＤ（Ｕ）の値をそのまま見せずに、暗号化されたリンク値Ｌ１に埋め込み、課金決済に際しては、この暗号化されたリンク値Ｌ１を受け付けるので、利用者Ｕ以外への識別情報Ｋ−ＩＤ（Ｕ）の漏洩を防止することが可能になる。さらに、これによって、識別情報の管理面や流通面での安全性が向上し、利用者Ｕによる信頼性も向上するので、利用者数の増大を図ることも可能になる。
【０２５２】
また、上記した実施例によれば、課金決済業者Ｋが利用者Ｕやサービス事業者Ｓの課金料金額を算出するのではなく、サービス事業者Ｓが利用者Ｕの課金料金額を算出し、プロバイダＲがサービス事業者Ｓの課金料金を算出するので、課金決済業者Ｋは課金料金額の算出に必要な情報を管理する必要がなく、課金決済業者Ｋによる情報の維持管理コストをさらに削減させることが可能になる。
【０２５３】
また、上記した実施例によれば、サービス事業者ＳやプロバイダＲが利用者Ｕから受け取る課金料金額から課金決済サービスの支払料金を差し引って決済を行い、また、プロバイダＲがサービス事業者Ｓから受け取る課金料金額から課金決済サービスの支払料金を差し引って決済を行うことで、サービス事業者ＳやプロバイダＲから課金決済業者Ｋに改めて料金を支払う手間を省くことが可能になる。
【０２５４】
また、上記した実施例によれば、サービス事業者Ｓが他のサービス事業者であるプロバイダＲのサービスを利用し、かかるサービスについて課金決済を行う場合にも、課金決済業者Ｋによる情報の維持管理コストを大幅に削減することが可能になり、また、サービス事業者Ｓの識別情報のセキュリティを向上させることも可能になる。
【０２５５】
［他の実施例］
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
【０２５６】
また、上記の実施例で説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報（例えば、各種のＤＢに登録された情報等）については、特記する場合を除いて任意に変更することができる。
【０２５７】
また、上記の実施例で図示した各装置（例えば、図８〜図１１に例示したサービス提供装置、プロバイダ装置、課金決済装置など）の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０２５８】
なお、上記の実施例では、本発明を実現する各装置（例えば、サービス提供装置、プロバイダ装置、課金決済装置など）を機能面から説明したが、各装置の各機能はパーソナルコンピュータやワークステーションなどのコンピュータにプログラムを実行させることによって実現することもできる。すなわち、本実施例で説明した各種の処理手順は、あらかじめ用意されたプログラムをコンピュータに実行することによって実現することができる。そして、これらのプログラムは、インターネットなどのネットワークを介して配布することができる。さらに、これらのプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。つまり、例を挙げれば、実施例に示したようなサービス提供装置用プログラム、プロバイダ装置用プログラム、課金決済装置用プログラムを格納したＣＤ−ＲＯＭ（装置ごとに別個のＣＤ−ＲＯＭであってもよい）を配布し、このＣＤ−ＲＯＭに格納されたプログラムを各コンピュータが読み出して実行するようにしてもよい。
【産業上の利用可能性】
【０２５９】
以上のように、本発明に係る課金決済装置、課金決済方法および課金決済プログラムは、サービス事業者が利用者に提供するサービスについて課金決済を行う場合に有用であり、特に、利用者識別情報のセキュリティを向上させ、かつ、低コストに課金決済システムを構築することに適する。
【図面の簡単な説明】
【０２６０】
【図１】実施例に登場する利用者、サービス事業者、プロバイダ、課金決済業者を説明するための図である。
【図２】実施例で用いる識別情報（ＩＤ）を説明するための図である。
【図３】実施例で用いる利用者ＩＤ、サービス事業者ＩＤ、プロバイダＩＤの例を示す図である。
【図４】実施例で用いる暗号化アルゴリズム等を説明するための図である。
【図５】実施例に係る課金処理の概要を説明するための図である。
【図６】実施例に係る課金処理の概要を説明するための図である。
【図７】実施例に係る課金処理の概要を説明するための図である。
【図８】実施例に係るシステムの構成を示す構成図である。
【図９】サービス提供装置の構成を示すブロック図である。
【図１０】プロバイダ装置の構成を示すブロック図である。
【図１１】課金決済装置の構成を示すブロック図である。
【図１２】利用者および課金決済業者の間における契約締結処理の流れを示すフローチャートである。
【図１３】課金決済装置の利用者情報ＤＢに登録される利用者情報の例を示す図である。
【図１４】サービス事業者および課金決済業者の間における契約締結処理の流れを示すフローチャートである。
【図１５】課金決済装置のサービス事業者情報ＤＢに登録されるサービス事業者情報の例を示す図である。
【図１６】プロバイダおよび課金決済業者の間における契約締結処理の流れを示すフローチャートである。
【図１７】課金決済装置のプロバイダ情報ＤＢに登録されるプロバイダ情報の例を示す図である。
【図１８】利用者およびサービス事業者の間における契約締結処理の流れを示すフローチャートである。
【図１９】認証値Ｃ１の生成処理の流れを示すフローチャートである。
【図２０】リンク値Ｌ１の生成処理の流れを示すフローチャートである。
【図２１】サービス提供装置の利用者情報ＤＢに登録される利用者情報の例を示す図である。
【図２２】利用者およびプロバイダの間における契約締結処理の流れを示すフローチャートである。
【図２３】認証値Ｃ２の生成処理の流れを示すフローチャートである。
【図２４】リンク値Ｌ２の生成処理の流れを示すフローチャートである。
【図２５】プロバイダ装置の利用者情報ＤＢに登録される利用者情報の例を示す図である。
【図２６】サービス事業者およびプロバイダの間における契約締結処理の流れを示すフローチャートである。
【図２７】認証値Ｃ３の生成処理の流れを示すフローチャートである。
【図２８】リンク値Ｌ３の生成処理の流れを示すフローチャートである。
【図２９】プロバイダ装置のサービス事業者情報ＤＢに登録されるサービス事業者情報の例を示す図である。
【図３０】課金情報の送受信処理の流れを示すフローチャートである。
【図３１】サービス提供装置による課金情報送信処理の流れを示すフローチャートである。
【図３２】サービス提供装置による課金計算処理の流れを示すフローチャートである。
【図３３】サービス提供装置のサービス料金情報ＤＢに記憶されたサービス料金情報の例を示す図である。
【図３４】サービス提供装置による課金計算処理の具体例を説明するための図である。
【図３５】プロバイダ装置による課金情報送信処理の流れを示すフローチャートである。
【図３６】プロバイダ装置による課金計算処理の流れを示すフローチャートである。
【図３７】プロバイダ装置のサービス料金情報ＤＢに記憶されたサービス料金情報の例を示す図である。
【図３８】プロバイダ装置による課金計算処理の具体例を説明するための図である。
【図３９】プロバイダ装置による課金計算処理の具体例を説明するための図である。
【図４０】課金決済装置による課金情報受信処理の流れを示すフローチャートである。
【図４１】課金決済装置の課金情報ＤＢに登録される課金情報の例を示す図である。
【図４２】課金決済装置のサービス料金情報ＤＢに記憶されたサービス料金情報の例を示す図である。
【図４３】課金決済装置による課金計算処理の具体例を説明するための図である。
【図４４】課金決済装置による請求処理の流れを示すフローチャートである。
【図４５】課金決済装置による明細情報の生成処理の流れを示すフローチャートである。
【図４６】課金決済装置の明細情報ＤＢに登録される明細情報の例を示す図である。
【図４７】課金決済装置の課金情報ＤＢに登録される課金情報と明細情報ＤＢに登録される明細情報との関係例を示す図である。
【図４８】課金決済装置による決済処理の流れを示すフローチャートである。
【図４９】課金決済装置の決済情報ＤＢに登録される決済情報の例を示す図である。
【符号の説明】
【０２６１】
１０  利用者端末
２０  サービス提供装置
２００  サービス事業者オペレータ端末
２０ａ  利用者情報ＤＢ（データベース）
２０ｂ  サービス料金情報ＤＢ
２１  サービス提供部
２２  課金情報送信部
２３  利用者情報管理部
２４  料金情報管理部
３０  プロバイダ装置
３００  プロバイダオペレータ端末
３０ａ  利用者情報ＤＢ
３０ｂ  サービス事業者情報ＤＢ
３０ｃ  サービス料金情報ＤＢ
３１  サービス提供部
３２  課金情報送信部
３３  ユーザ情報管理部
３４  料金情報管理部
４０  課金決済装置
４００  課金決済業者オペレータ端末
４０ａ  課金情報ＤＢ
４０ｂ  明細情報ＤＢ
４０ｃ  決済情報ＤＢ
４０ｄ  利用者情報ＤＢ
４０ｅ  サービス事業者情報ＤＢ
４０ｆ  プロバイダ情報ＤＢ
４０ｇ  サービス料金情報ＤＢ
４１  課金情報受信部
４２  請求部
４３  決済ＧＷ（ゲートウェイ）部
４４  ユーザ情報管理部
４５  料金情報管理部
５０  決済機関システム
【図１】
2005309747.tif 000003
【図２】
2005309747.tif 000004
【図３】
2005309747.tif 000005
【図４】
2005309747.tif 000006
【図５】
2005309747.tif 000007
【図６】
2005309747.tif 000008
【図７】
2005309747.tif 000009
【図８】
2005309747.tif 000010
【図９】
2005309747.tif 000011
【図１０】
2005309747.tif 000012
【図１１】
2005309747.tif 000013
【図１２】
2005309747.tif 000014
【図１３】
2005309747.tif 000015
【図１４】
2005309747.tif 000016
【図１５】
2005309747.tif 000017
【図１６】
2005309747.tif 000018
【図１７】
2005309747.tif 000019
【図１８】
2005309747.tif 000020
【図１９】
2005309747.tif 000021
【図２０】
2005309747.tif 000022
【図２１】
2005309747.tif 000023
【図２２】
2005309747.tif 000024
【図２３】
2005309747.tif 000025
【図２４】
2005309747.tif 000026
【図２５】
2005309747.tif 000027
【図２６】
2005309747.tif 000028
【図２７】
2005309747.tif 000029
【図２８】
2005309747.tif 000030
【図２９】
2005309747.tif 000031
【図３０】
2005309747.tif 000032
【図３１】
2005309747.tif 000033
【図３２】
2005309747.tif 000034
【図３３】
2005309747.tif 000035
【図３４】
2005309747.tif 000036
【図３５】
2005309747.tif 000037
【図３６】
2005309747.tif 000038
【図３７】
2005309747.tif 000039
【図３８】
2005309747.tif 000040
【図３９】
2005309747.tif 000041
【図４０】
2005309747.tif 000042
【図４１】
2005309747.tif 000043
【図４２】
2005309747.tif 000044
【図４３】
2005309747.tif 000045
【図４４】
2005309747.tif 000046
【図４５】
2005309747.tif 000047
【図４６】
2005309747.tif 000048
【図４７】
2005309747.tif 000049
【図４８】
2005309747.tif 000050
【図４９】
2005309747.tif 000051