JP2003223593A - ディジタルコンテンツ販売における課金中止方法及び認証課金サーバ及び購入制御端末及び課金中止プログラム及び課金中止プログラムを格納した記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 販売システム障害が発生した場合でも、ユー
ザが安全に課金を中止することを可能とする。 【解決手段】 本発明は、認証課金サーバが販売サーバ
に対して課金成功の応答を行う一連の課金処理を実行す
る場合に、販売サーバの障害などの理由により、課金要
求がネットワーク上で、遅延、あるいは消失したとき、
購入制御端末が該販売サーバからの応答を待たずに、認
証課金サーバに対して直接、課金中止情報を送出し、認
証課金サーバで手形発行ＩＤを課金中止状態にすること
により、課金情報が遅延して認証課金サーバに到着して
も、確実に課金を中止する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ディジタルコンテ
ンツ販売における課金中止方法及び認証課金サーバ及び
購入制御端末及び課金中止プログラム及び課金中止プロ
グラムを格納した記憶媒体に係り、特に、インターネッ
ト等のネットワーク上のディジタルコンテンツの配送時
等における少額の即時課金システムにおけるディジタル
コンテンツ販売における課金中止方法及び認証課金サー
バ及び購入制御端末及び課金中止プログラム及び課金中
止プログラムを格納した記憶媒体に関する。

【０００２】詳しくは、街頭端末等の公共性の高い場所
でのコンテンツ購入時における安全性を確保した、簡易
で比較的安価な媒体のカードを使用した少額の即時課金
を行うためのディジタルコンテンツ販売における課金中
止方法及び認証課金サーバ及び購入制御端末及び課金中
止プログラム及び課金中止プログラムを格納した記憶媒
体に関する。

【０００３】

【従来の技術】安価な媒体を利用して、プリペイド・ポ
ストペイド等による決済を可能とする方法として、認証
課金サーバと購入者が有する認証媒体が接続される購入
制御端末間で手形署名鍵を決めて手形署名鍵で作成した
取引毎に、購入制御端末で作成される手形情報で、認証
媒体が接続された購入制御端末と販売サーバとの通信を
行う方法が提案されている。

【０００４】

【発明が解決しようとする課題】しかしながら、プリペ
イド方式でなおかつ認証センタと販売システムが分離し
ており、ユーザが販売システムに商品を要求し、販売シ
ステムが認証センタに課金を要求するという手形方式に
おいては、認証センタが健在であっても販売システムが
ダウンした場合、送信した購入情報の課金結果を確認で
きず安全に課金を中止できないために、第三者により購
入情報を不正に利用されたり、ユーザが意図しない課金
が行われたりする危険がある。これは、販売システムに
障害があった場合、ユーザは販売システムからの応答を
待ち続けて、次の状態に遷移できない状態に陥ってしま
うためである。

【０００５】本発明は、上記の点に鑑みなされたもの
で、販売システム障害が発生した場合でも、ユーザが安
全に課金を中止することが可能なディジタルコンテンツ
販売における課金中止方法及び認証課金サーバ及び購入
制御端末及び課金中止プログラム及び課金中止プログラ
ムを格納した記憶媒体を提供することを目的とする。

【０００６】また、本発明の目的は、ネットワーク障害
が発生した場合でも、ユーザが安全に課金を中止するこ
とができるディジタルコンテンツ販売における課金中止
方法及び認証課金サーバ及び購入制御端末及び課金中止
プログラム及び課金中止プログラムを格納した記憶媒体
を提供することである。

【０００７】また、本発明の目的は、既に課金が完了し
てしまった取引については、課金完了をユーザに通知す
ることができるディジタルコンテンツ販売における課金
中止方法及び認証課金サーバ及び購入制御端末及び課金
中止プログラム及び課金中止プログラムを格納した記憶
媒体を提供することである。

【０００８】更なる本発明の目的は、課金中止が確定し
た取引については、課金中止成功を通知することができ
るディジタルコンテンツ販売における課金中止方法及び
認証課金サーバ及び購入制御端末及び課金中止プログラ
ム及び課金中止プログラムを格納した記憶媒体を提供す
ることである。

【０００９】

【課題を解決するための手段】図１は、本発明の原理を
説明するための図である。

【００１０】本発明（請求項１）は、複数の認証媒体、
複数の購入制御端末、複数の販売サーバ及び１つの認証
課金サーバからなり、システムのネットワーク上のコン
テンツ購入を含む取引を決済を行うためのシステムにお
いて、課金を中止するためのディジタルコンテンツ販売
における課金中止方法において、販売サーバからコンテ
ンツを購入する際の支払手段として、認証課金サーバで
残額を保持するＩＤ認証が可能な認証媒体を購入制御端
末に接続し、購入制御端末では、認証媒体の認証を認証
課金サーバに要求し、認証課金サーバにおいて、認証媒
体の認証を行い、認証が成功すると、認証媒体の媒体Ｉ
Ｄに対する課金許可情報を生成するための手形署名鍵を
生成して、購入制御端末に送信し、購入制御端末では、
販売サーバへの支払時に、１回認証中の取引を特定する
ため手形発行ＩＤを生成し、認証課金サーバから送付さ
れた手形署名鍵を使用して、媒体ＩＤ及び手形発行ＩＤ
を含む取引を特定する情報に対して、暗号化や電子署名
を含む処理を行い、手形署名情報を生成し、課金先の認
証媒体の媒体ＩＤ、手形発行ＩＤ、及び手形署名情報を
含む支払のための手形情報を購入要求として販売サーバ
に送信し、販売サーバでは、受信した手形情報と請求額
とを課金情報として、認証課金サーバに送信し、認証課
金サーバで送信された課金情報が正当であるかを確認し
て、正当であれば課金を行い、認証課金サーバが販売サ
ーバに対して課金成功の応答を行う一連の課金処理を実
行する場合に、販売サーバの障害などの理由により、課
金要求がネットワーク上で、遅延、あるいは消失したと
き、購入制御端末が該販売サーバからの応答を待たず
に、認証課金サーバに対して直接、課金中止情報を送出
し（ステップ１）、認証課金サーバで手形発行ＩＤを課
金中止状態にする（ステップ２）ことにより、課金情報
が遅延して認証課金サーバに到着しても、確実に課金を
中止する。本発明（請求項２）は、販売サーバで販売さ
れる商品を購入するために、購入制御端末において、支
払のための課金情報を生成し、該販売サーバを経由して
認証課金サーバに送信した後に、ネットワーク障害や、
該販売サーバの障害を含む理由により、該商品の購入を
中止するために、購入制御端末が、商品購入に対する課
金を中止させるための課金中止情報を生成して、認証課
金サーバに送信し、課金中止情報が、課金情報より先に
認証課金サーバに到着することにより、課金中止とす
る。

【００１１】本発明（請求項３）は、購入制御端末が課
金情報と課金中止情報を認証課金サーバに送信し、認証
課金サーバが、課金中止情報を課金情報より先に受信し
た場合、該課金中止情報を保持し、該課金中止情報に該
当する課金情報を受信したときに、該課金情報が示す課
金を実行せずに中止し、課金を中止したことを購入制御
端末に通知する。

【００１２】本発明（請求項４）は、課金情報が示す課
金を実行せずに、中止したことを購入制御端末が認証課
金サーバからの通知により認識し、購入制御端末が管理
する認証媒体のバリュー情報を確定する。

【００１３】本発明（請求項５）は、購入制御端末が、
支払のための課金情報と商品購入に対する課金を中止さ
せるための課金中止情報を認証課金サーバに送信し、認
証課金サーバが、課金情報を課金中止情報より先に受信
した場合には、課金処理を履行し、課金結果を保持し、
課金情報に該当する課金中止情報を受信した場合には、
該課金情報が示す課金処理が既に実行されてしまったこ
とを購入制御端末に応答し、購入制御端末では、認証課
金サーバから受信した応答により、認証媒体のバリュー
情報を確定する。

【００１４】本発明（請求項６）は、認証課金サーバ
が、課金中止情報を保持しているとき、課金中止情報に
該当する認証媒体の認証状態が破棄されたことを契機
に、課金中止情報、手形発行ＩＤ、手形署名鍵を破棄す
る。

【００１５】図２は、本発明の原理構成図である。

【００１６】本発明（請求項７）は、コンテンツを購入
する際の支払手段として、認証課金サーバで残額を保持
するＩＤ認証が可能な複数の認証媒体と、複数の購入制
御端末と、複数の販売サーバと、１つの認証課金サーバ
からなるシステムにおいて、購入制御端末は、接続され
た認証媒体の認証を認証課金サーバに要求する手段と、
販売サーバへの支払時に、１回認証中の取引を特定する
ための手形発行ＩＤを生成する手段と、認証課金サーバ
から送付された手形署名鍵を使用して、媒体ＩＤ及び手
形発行ＩＤを含む取引を特定する情報に対して、暗号化
や電子署名を含む処理を行い、手形署名情報を生成する
手段と、課金先の認証媒体の媒体ＩＤ、手形発行ＩＤ、
及び手形署名情報を含む支払のための手形情報を購入要
求として販売サーバに送信する手段と、を有し、販売サ
ーバは、購入制御端末から受信した手形情報と請求額と
を課金情報として、認証課金サーバに送信する手段を有
し、認証課金サーバは、認証媒体の認証を行い、該認証
が成功すると、認証媒体の媒体ＩＤに対する課金許可情
報を生成するための手形署名鍵を生成して、購入制御端
末に送信する手段と、販売サーバから送信された課金情
報が正当であるかを確認して、正当であれば課金を行う
手段と、を有する、コンテンツ購入を含む取引を決済を
行うシステムにおいて、販売サーバの障害などの理由に
より、課金を中止する認証課金サーバであって、課金要
求がネットワーク上で、遅延、あるいは消失したとき、
購入制御端末が該販売サーバからの応答を待たずに送出
した課金中止情報を受信する課金中止情報受信手段１０
１と、手形発行ＩＤを課金中止状態にすることにより、
課金情報が遅延して到着しても、確実に課金を中止する
課金中止手段１０２とを有する。

【００１７】本発明（請求項８）は、課金中止情報を課
金情報より先に受信した場合、該課金中止情報を保持す
る課金中止情報保持手段を有し、課金中止手段１０２に
おいて、課金中止情報保持手段に保持されている課金中
止情報に該当する課金情報を受信したときに、該課金情
報が示す課金を実行せずに中止し、該課金を中止したこ
とを購入制御端末に通知する課金中止通知手段を有す
る。

【００１８】本発明（請求項９）は、課金中止情報保持
手段において、課金中止情報を保持しているとき、該課
金中止情報に対応する認証媒体の認証状態が破棄された
のを契機として、該課金中止情報、手形発行ＩＤ、手形
署名鍵を破棄する手段を更に有する。

【００１９】本発明（請求項１０）は、購入制御端末よ
り、課金中止情報より先に課金情報を受信した場合に、
課金処理を履行し、課金結果を保持する課金手段と、
課金処理の履行後に、課金情報に該当する課金中止情報
を受信した場合には、該課金情報が示す課金処理が既に
実行されてしまったことを購入制御端末に通知する課金
処理通知手段とを有する。

【００２０】本発明（請求項１１）は、コンテンツを購
入する際の支払手段として、認証課金サーバで残額を保
持するＩＤ認証が可能な複数の認証媒体と、複数の購入
制御端末と、複数の販売サーバと、１つの認証課金サー
バからなるシステムにおいて、購入制御端末は、接続さ
れた認証媒体の認証を認証課金サーバに要求する手段
と、販売サーバへの支払時に、１回認証中の取引を特定
するための手形発行ＩＤを生成する手段と、認証課金サ
ーバから送付された手形署名鍵を使用して、媒体ＩＤ及
び手形発行ＩＤを含む取引を特定する情報に対して、暗
号化や電子署名を含む処理を行い、手形署名情報を生成
する手段と、課金先の認証媒体の媒体ＩＤ、手形発行Ｉ
Ｄ、及び手形署名情報を含む支払のための手形情報を購
入要求として販売サーバに送信する手段と、を有し、販
売サーバは、購入制御端末から受信した手形情報と請求
額とを課金情報として、認証課金サーバに送信する手段
を有し、認証課金サーバは、認証媒体の認証を行い、該
認証が成功すると、認証媒体の媒体ＩＤに対する課金許
可情報を生成するための手形署名鍵を生成して、購入制
御端末に送信する手段と、販売サーバから送信された課
金情報が正当であるかを確認して、正当であれば課金を
行う手段と、を有する、コンテンツ購入を含む取引を決
済を行うシステムにおいて、販売サーバの障害などの理
由により、課金を中止する際に、課金中止要求を行う購
入制御端末であって、販売サーバの障害などの理由によ
り、課金要求がネットワーク上で、遅延、あるいは消失
したとき、該販売サーバからの応答を待たずに課金中止
情報を認証課金サーバに送信する課金中止要求発行手段
２０１と、認証課金サーバから課金中止情報に対する応
答を受信し、該応答に基づいて、認証媒体のバリュー情
報を確定するバリュー情報確定手段２０２と、を有す
る。本発明（請求項１２）は、バリュー情報確定手段２
０２において、認証課金サーバから課金を実行したこと
を示す応答を受信した場合には、該応答に基づいて、認
証媒体のバリュー情報を確定する手段を含む。

【００２１】本発明（請求項１３）は、コンテンツを購
入する際の支払手段として、認証課金サーバで残額を保
持するＩＤ認証が可能な複数の認証媒体と、複数の購入
制御端末と、複数の販売サーバと、１つの認証課金サー
バからなるシステムのネットワーク上のコンテンツ購入
を含む取引の課金を行う際に、販売サーバの障害などの
理由により、課金要求がネットワーク上で、遅延、ある
いは消失した場合に課金を中止するために、該認証課金
サーバが実行する課金中止プログラムであって、課金要
求がネットワーク上で、遅延、あるいは消失したとき、
購入制御端末が該販売サーバからの応答を待たずに送出
した課金中止情報を受信する課金中止情報受信プロセス
と、手形発行ＩＤを課金中止状態にすることにより、課
金情報が遅延して到着しても、確実に課金を中止する課
金中止プロセスとを有する。

【００２２】本発明（請求項１４）は、課金中止情報を
課金情報より先に受信した場合、該課金中止情報を記憶
手段に格納する課金中止情報格納プロセスを有し、課金
中止プロセスは、記憶手段に保持されている課金中止情
報に該当する課金情報を受信したときに、該課金情報が
示す課金を実行せずに中止し、該課金を中止したことを
購入制御端末に通知する課金中止通知プロセスを有す
る。

【００２３】本発明（請求項１５）は、記憶手段に、課
金中止情報が格納されているとき、該課金中止情報に対
応する認証媒体の認証状態が破棄されたのを契機とし
て、該課金中止情報、手形発行ＩＤ、手形署名鍵を破棄
するプロセスを更に有する。

【００２４】本発明（請求項１６）は、購入制御端末よ
り、課金中止情報より先に課金情報を受信した場合に、
課金処理を履行し、課金結果を保持する課金プロセス
と、課金処理の履行後に、課金情報に該当する課金中止
情報を受信した場合には、該課金情報が示す課金処理が
既に実行されてしまったことを購入制御端末に通知する
課金処理通知プロセスとを有する。

【００２５】本発明（請求項１７）は、コンテンツを購
入する際の支払手段として、認証課金サーバで残額を保
持するＩＤ認証が可能な複数の認証媒体と、複数の購入
制御端末と、複数の販売サーバと、１つの認証課金サー
バからなるシステムのネットワーク上のコンテンツ購入
を含む取引の課金を行う際に、販売サーバの障害などの
理由により、課金要求がネットワーク上で、遅延、ある
いは消失した場合に課金を中止するために、該購入制御
端末が実行する課金中止プログラムであって、販売サー
バの障害などの理由により、課金要求がネットワーク上
で、遅延、あるいは消失したとき、該販売サーバからの
応答を待たずに課金中止情報を認証課金サーバに送信す
る課金中止要求発行プロセスと、認証課金サーバから課
金中止情報に対する応答、または、課金済でああること
を示す応答を受信し、該応答に基づいて、認証媒体のバ
リュー情報を確定するバリュー情報確定プロセスと、を
有する。

【００２６】本発明（請求項１８）は、コンテンツを購
入する際の支払手段として、認証課金サーバで残額を保
持するＩＤ認証が可能な複数の認証媒体と、複数の購入
制御端末と、複数の販売サーバと、１つの認証課金サー
バからなるシステムのネットワーク上のコンテンツ購入
を含む取引の課金を行う際に、販売サーバの障害などの
理由により、課金要求がネットワーク上で、遅延、ある
いは消失した場合に課金を中止するために、該認証課金
サーバが実行する課金中止プログラムを格納した記憶媒
体であって、請求項１３乃至請求項１６のプログラムを
格納する。

【００２７】本発明（請求項１９）は、コンテンツを購
入する際の支払手段として、認証課金サーバで残額を保
持するＩＤ認証が可能な複数の認証媒体と、複数の購入
制御端末と、複数の販売サーバと、１つの認証課金サー
バからなるシステムのネットワーク上のコンテンツ購入
を含む取引の課金を行う際に、販売サーバの障害などの
理由により、課金要求がネットワーク上で、遅延、ある
いは消失した場合に課金を中止するために、該購入制御
端末が実行する課金中止プログラムを格納した記憶媒体
であって、請求項１７記載のプログラムを格納する。

【００２８】上記のように、本発明では、購入者が販売
サーバの商品を購入するために、購入制御端末から販売
サーバに手形情報を送信した後に、購入者が購入しよう
とした販売サーバの商品の購入を中止したい場合、購入
制御端末から認証課金サーバに対して、手形情報を破棄
するための課金中止要求（手形破棄要求）を直接送信す
る。これにより、課金中止要求を受け付けた認証課金サ
ーバは、当該課金中止要求が示す破棄対象手形情報の検
査を行い、当該手形情報が受付済でないかを検査し、受
付済でなければ、当該手形情報を破棄対象手形情報とし
て登録し、購入制御端末に対し、手形破棄情報受付済で
あることを応答すると共に、当該手形情報をもつ手形の
課金要求を受け付けないようにする。手形破棄情報受付
済の応答を受け取った購入制御端末は、当該手形情報を
持つ手形が販売サーバから認証課金サーバに送信されて
も、それが確実に課金実行されないことを確定できる。

【００２９】また、本発明では、購入制御端末から販売
サーバに手形情報を送信した後に、購入者が購入を中止
したい場合、購入制御端末から認証課金サーバに対し
て、課金中止要求（手形破棄要求）を直接送信する。手
形破棄要求を受け付けた認証課金サーバでは、手形破棄
要求が示す破棄対象手形情報の検査を行い、該当手形情
報を受付済でないかを検査し、この時点において、既に
受付済であれば、当該手形情報を購入制御端末に対し、
手形課金済であることを応答すると共に、当該手形情報
を破棄対象手形情報として登録しない。手形情報受付済
の応答を受け取った購入制御端末は、当該手形情報を持
つ手形が確実に課金実行されたことを確定できる。

【００３０】また、本発明では、購入制御端末から認証
課金サーバに対して認証媒体の切断情報が送信される
か、認証媒体の認証成功から一定時間が経過したことを
契機に、対応する媒体ＩＤの手形情報生成・確認のため
の情報と、その媒体ＩＤに対応した破棄対象手形発行Ｉ
Ｄを削除することにより、当該手形情報を持つ手形が販
売サーバから認証課金サーバに送信されても、それが確
実に課金実行されないことを確定できる。

【００３１】

【発明の実施の形態】以下、図面と共に本発明の実施の
形態を説明する。

【００３２】図３は、本発明が適用されるシステム構成
を示す。

【００３３】本発明のシステムは、同図に示すように、
複数の認証媒体１０と、複数の購入制御端末２００と、
複数の販売サーバ３００と、１つの認証課金セン１００
から構成される。

【００３４】このうち、認証媒体１０は、購入制御端末
２００に接続されることによって、使用可能な、個々の
媒体を一意に特定できる識別子（媒体ＩＤ）が割り当て
られたカードなどの媒体であり、認証課金サーバ１００
から認証を受けることによって媒体ＩＤに対する正当な
媒体であることを保証するための機能を包含している。

【００３５】また、購入制御端末２００は、購入者の操
作等に従い販売サーバ３００に対してコンテンツ等の商
品の購入要求を行う端末であり、購入要求を行う際に、
接続された認証媒体１０の認証制御や手形情報の生成を
行うことで、生成した手形情報を販売サーバ３００に送
信するなど、媒体ＩＤに関連付けられたバリューから販
売サーバ３００に対しての支払制御を行う端末である。

【００３６】また、販売サーバ３００は、購入制御端末
２００からの要求に応じてコンテンツ等の商品の販売を
行うサーバであり、購入要求の際に受け取った手形情報
を請求額と共に認証課金サーバ１００に渡して課金要求
を行い、認証課金サーバ１００では、課金成功時にコン
テンツ等の商品の受渡しを行うサーバである。なお、販
売サーバ３００を持つ販売者は、認証課金サーバ１００
からの精算処理により請求額に対応した代金を受け取る
ことになる。

【００３７】また、認証課金サーバ１００は、認証媒体
１００の媒体ＩＤに関連付けられたバリューを管理して
いるサーバであり、購入制御端末２００からの要求によ
り購入制御端末２００に接続された認証媒体１０の認証
を行う。また、認証課金サーバ１００は、販売サーバ３
００からの課金要求に応じて受け取った手形情報に対応
する媒体ＩＤに関連付けられたバリューに対して課金を
行う。また、認証課金サーバ１００では精算により、販
売サーバ３００に対して課金額に対応した代金の支払を
行う。

【００３８】次に、上記の構成における動作を説明す
る。

【００３９】図４は、本発明の前提となるシステムの動
作の概要を示すシーケンスチャートである。

【００４０】ステップ１０４までの媒体認証が完了し、
認証課金サーバ１００で媒体ＩＤと媒体が媒体ＩＤに対
する媒体であることが確認されると、当該媒体ＩＤに対
する手形署名鍵等の手形情報生成に必要なデータを生成
し、媒体ＩＤの媒体が認証中であることを示す認証セッ
ション情報として保存する（ステップ１０５）と共に、
媒体認証結果として、手形署名鍵などの生成したデータ
を購入制御端末２００に送信する（ステップ１０６）。
ここで、手形署名鍵と共に、認証セッションＩＤを生成
・保存・送信する。なお、手形署名鍵は、購入制御端末
２００以外の第三者に見られない形で送付する必要があ
る。

【００４１】購入制御端末２００では、ステップ１０６
において、手形署名鍵（及び認証セッションＩＤ）など
の受信したデータや媒体ＩＤを、媒体に対応する手形情
報生成のためのデータとして保存する（ステップ１０
７）。

【００４２】次に、図４の『支払処理』で示した範囲
で、手形情報の生成・払出しによるコンテンツ等の商品
購入に対する支払処理を行うが、支払処理のタイミング
は、『媒体認証処理』の後で、『認証状態終了処理』の
前であればいつでもよいが、通常は購入者から商品購入
の指示が出されたときに行う。

【００４３】また、『支払処理』で示した範囲の処理
は、１回の『媒体認証処理』に対して複数回行うことが
可能であり、つまり、１回の媒体認証で、複数の販売サ
ーバ３００への複数回の支払（複数の販売サーバ３００
からの複数回の商品購入）が可能となっている。

【００４４】『支払処理』では、まず、１認証内での取
引を特定する情報である手形発行ＩＤの生成やステップ
１０７で保存した媒体ＩＤや、手形署名鍵等を使用した
手形情報の生成を行う（ステップ１０８）。手形情報
は、 ・取引と特定する情報； ・署名情報： からなり、ここで、「取引を特定する情報」は、媒体Ｉ
Ｄまたは、認証セッションＩＤ等の媒体を一意に特定で
きる情報と、媒体認証セッション内での取引を特定する
情報である手形発行ＩＤとからなる。また、「署名情
報」は、認証を行った購入制御端末２００のみ知ること
が可能な手形署名鍵を使って「取引を特定する情報」及
び支払額や支払先ＩＤやコンテンツＩＤ等の取引を限定
するパラメータに対して、暗号化や電子署名やメッセー
ジ認証識別子生成等を行うことによって生成されるメッ
セージ認証情報に対応する。

【００４５】ステップ１０８で手形情報が生成される
と、購入制御端末２００から販売サーバ３００に対して
支払のための情報である手形情報を送信することで、コ
ンテンツ等の商品購入を要求し（ステップ１０９）、販
売サーバ３００では、手形情報を受け取ると、認証課金
サーバ１００に対して手形情報と商品の代金に相当する
請求額と、精算時の支払先を特定する情報としての支払
先ＩＤを送信する（ステップ１１０）。ここで、通常の
場合、支払先ＩＤは販売サーバ３００を持つ事業者を特
定する情報である。

【００４６】認証課金サーバ１００では、ステップ１１
０で手形情報、請求額、支払先ＩＤなどを受け取ると、
まず、手形情報中の取引を特定する情報から媒体ＩＤを
特定し、特定された媒体ＩＤに対応する認証セッション
情報があるかを調べることで媒体ＩＤが認証中であるか
を検査し（ステップ１１１）、認証中であれば、、媒体
ＩＤに対応して生成・保存してある手形署名鍵を使用し
て手形情報内の署名情報が正しいか（言い換えると、取
引を特定する情報及び手形情報内の取引を限定するパラ
メータが正しいか）を検査する（ステップ１１２）。

【００４７】ステップ１１２で署名情報の検査が成功す
ると、次に、破棄対象管理表を検索し、該当する手形の
破棄要求を受信していないかの検査を行う（ステップ１
１３）。破棄対象手形管理表に手形情報が登録されてい
なければ、課金処理を行う。課金処理は、販売サーバ３
００から指定された請求額分を認証課金サーバ１００で
媒体ＩＤに対応して保持しているバリューに対して課金
を行うと共に、精算情報を蓄えるなどの支払先ＩＤに対
する請求額分の精算を行うための処理を行う（ステップ
１１４）。ここで、認証課金サーバ１００では、媒体Ｉ
Ｄに対するプリペイド残額を管理している場合には、バ
リューに対する課金処理として、プリペイド残額から減
算することになり、認証課金サーバ１００がポストペイ
ド方式の場合には、バリューに対する課金処理は、ポス
トペイドの精算額に加算されることになる。

【００４８】課金が成功すると、課金要求の応答として
認証課金サーバ１００から販売サーバ３００に対して課
金が成功したことを通知し（ステップ１１５）、認証課
金サーバ１００では、手形決済管理表に決済済であるこ
とを登録し、販売サーバ３００では、課金成功通知を受
信すると、商品購入許可として、購入制御端末２００に
課金が成功したことを通知し（ステップ１１６）、商品
受け取りの許可を与える。

【００４９】最後に、『認証状態終了処理』で示した範
囲で、認証媒体１０に対する認証状態の破棄を行う。
『認証状態終了処理』が行われると、ステップ１１１の
支払処理の認証中検査が失敗するため、再度、『媒体認
証処理』が行われるまでは認証媒体１０に対する課金が
不可能になる。

【００５０】『認証状態終了処理』では、まず、媒体Ｉ
Ｄや認証セッションＩＤ等の媒体（または、認証セッシ
ョン）を特定する情報を認証課金サーバ１００に送信し
（ステップ１１７）、認証課金サーバ１００では、ステ
ップ１１７の媒体認証終了要求で受信した媒体ＩＤや認
証セッションＩＤ等の媒体（または、認証セッション）
を特定する情報により認証セッションを検索して、検索
された認証セッション情報を削除することで媒体ＩＤに
対する認証状態の解除を行い、認証状態が解除されたこ
とを媒体認証終了結果として購入制御端末２００に通知
する（ステップ１１８）。

【００５１】以上が、本発明の前提となるシステム動作
である。

【００５２】

【実施例】以下、図面と共に本発明の実施例を説明す
る。

【００５３】本実施例のシステムは、認証媒体としてＩ
Ｃカードを使用したプリペイド方式（プリペイドカー
ド）のシステムを前提としており、購入者が商品購入前
に事前にプリペイドカード（ＩＣカード）を購入するこ
とで、プリペイドカードのバリュー分の金額をカード発
行事業者に支払っていることを想定する。また、購入さ
れたプリペイドカードのバリューはカード発行事業者で
持つ（または、カード発行事業者から委託された）認証
課金サーバで管理していることを前提としている。つま
り、購入者がプリペイドカードによる商品対価支払後
に、認証課金サーバの情報に基づき、カード発行事業者
と販売者の間で精算を行うことで、最終的に販売者への
支払が行われるシステムを想定している。

【００５４】図５は、本発明の一実施例の前提となるシ
ステム構成を示す。

【００５５】同図に示すように、本実施例のシステム
は、複数のＩＣカード１０と、複数の購入制御端末２０
０と、複数の販売サーバ３００と、１つの認証課金サー
バ１００から構成される。

【００５６】このうち、ＩＣカード１０は、購入制御端
末２００と通信を行う通信部１１と、認証課金サーバ１
００からの認証メッセージに対する応答を生成すること
でカード認証を実行する認証応答部１２と、個々のカー
ドを一意に特定できる識別子であるカードＩＤやカード
認証のための秘密データをあるカード認証鍵などを保持
するメモリであるカードデータ保持部１３からなり、認
証課金サーバ１００から認証を受けることによって、カ
ードＩＤに対する正当なカードであることを保証するた
めの機能を包含した、バリューを持つプリペイドカード
である。

【００５７】図６は、本発明の一実施例の前提となるＩ
Ｃカードのカードデータ保持部内のデータの例を示す。

【００５８】また、購入制御端末２００は、ＩＣカード
１０が挿入されることで、ＩＣカードとの通信を行うカ
ードリーダライタ２１０、インターネットなどのネット
ワークに接続され、認証課金サーバ１００や販売サーバ
３００との通信を行う通信部２２０と、認証課金サーバ
１００との通信やＩＣカード１０との通信を制御するこ
とによって、ＩＣカード１０の認証の制御を行ったり、
購入制御端末２００からの要請によって手形情報を生成
したりする課金制御部２３０と、キーボタン装置やディ
スプレイ装置などの入出力手段を持ち購入者からの操作
等により課金制御部２３０に対して手形の生成を要請
し、生成された手形情報を通信部２２０の仲介により販
売サーバ３００へ渡すことにより、商品の購入要求及び
支払処理を行う購入制御部２４０からなり、挿入された
ＩＣカード１０のプリペイド残額から販売サーバ３００
への支払制御を行うことで、購入者に対してコンテンツ
等の購入サービスを提供する端末である。

【００５９】また、販売サーバ３００は、インターネッ
トなどのネットワークに接続され、購入制御端末２００
や認証課金サーバ１００との通信を行う通信部３１０
と、購入制御端末２００からの商品の購入要求を受け付
け、購入要求受付時に受け取った手形情報を認証課金サ
ーバ１００に送付することで課金要求を行い、課金要求
の結果から購入制御端末２００に対して商品受け取りの
ための許可情報の送付やコンテンツダウンロードを行う
などの、コンテンツ等の商品販売の課金制御を行うサー
バである。

【００６０】なお、販売サーバ３００を持つ販売者は、
認証課金サーバ１００からの精算処理により販売額に対
応した代金を受け取ることになるが、精算時の確認のた
めの情報を蓄える精算ログＤＢ３３０を持つこともあ
る。

【００６１】また、販売サーバ３００がコンテンツを販
売するサーバであれば、販売するコンテンツを蓄積して
いるコンテンツＤＢ等３４０を持つこともある。

【００６２】また、認証課金サーバ１００は、インター
ネットなどのネットワークに接続され、購入制御端末２
００や販売サーバ３００との通信を行う通信部１１０
と、ＩＣカード１０のプリペイド残額やカード認証のた
めの情報をカードＩＤ毎に管理しているカードバリュー
管理ＤＢ１３０と、購入制御端末２００からのＩＣカー
ド１０の認証要求に従いＩＣカード１０の認証を行った
り、販売サーバ３００からの課金要求に従い、手形情報
の確認を行うことでプリペイド残額に対して課金を行う
認証セッション管理部１２０と、認証セッション管理部
１２０での課金成功時に支払先への精算のための処理を
行う精算部１４０からなる。

【００６３】図７は、本発明の一実施例の前提となる認
証課金サーバのカードバリューＤＢのデータの例を示
す。

【００６４】カードバリュー管理ＤＢ１３０のデータ
は、個々のＩＣカード１０を一意に特定する識別子であ
るカードＩＤと、カードＩＤに対するバリューであるプ
リペイド残額と、カード認証時に認証データの生成に使
用するカード認証鍵からなる。次に、上記の構成におけ
る動作を説明する。

【００６５】図８は、本発明の一実施例の前提となるシ
ステムの動作を示すシーケンスチャートである。

【００６６】以下の実施例の前提となるシステム動作で
ある『ＩＣカード認証処理』から『認証状態終了処理』
について説明する。

【００６７】まず、購入制御端末２００に対してＩＣカ
ード１０が挿入されると、購入制御端末２００では、
『ＩＣカード認証処理』で示した画面で挿入されたＩＣ
カード１０の認証を行う。

【００６８】最初にＩＣカード１０の認証処理について
説明する。

【００６９】『ＩＣカード認証処理』では、まず、購入
制御端末２００からＩＣカード１０に対してカードＩＤ
の読出しコマンドを送信し（ステップ２０２）、ＩＣカ
ード１０でカードデータ保持部１３に保持しているカー
ドＩＤを読み出して購入制御端末２００に送信する（ス
テップ２０３）ことで、挿入されたＩＣカード１０の読
出しを行う。

【００７０】また、購入制御端末２００では、カードＩ
Ｄの読出しが終わると、認証課金サーバ１００に対して
ＩＣカード認証要求を送信することで挿入されたＩＣカ
ード１０に対するカード認証を要求する（ステップ２０
４）。この際に、認証対象のＩＣカード１０のカードＩ
Ｄを送信する。

【００７１】認証課金サーバ１００では、ＩＣカード認
証要求を受け取ると、疑似乱数生成関数等を使用して乱
数を生成し（ステップ２０５）、生成した乱数を計算要
求として購入制御端末２００に送信する（ステップ２０
６）。

【００７２】購入制御端末２００では、認証課金サーバ
１００から受け取った計算要求メッセージをそのままＩ
Ｃカード１０に転送し（ステップ２０７）、ＩＣカード
１０では、計算要求を受け取ると、受け取った乱数に対
する計算を認証応答部１２で行う（ステップ２０８）。

【００７３】ＩＣカード１０では、応答計算の計算結果
が得られると、計算結果を購入制御端末２００に送信し
（ステップ２０９）、購入制御端末２００では、計算要
求応答をそのまま認証課金サーバ１００へ送信する（ス
テップ２１０）。

【００７４】認証課金サーバ１００では乱数に対する計
算結果が得られると、認証セッション管理部１２０によ
り、乱数とカードバリュー管理ＤＢ１３０に保存してあ
るカードＩＤに対応するカード認証鍵を使用したＩＣカ
ードの応答計算と同じ計算を行い、ＩＣカード１０から
受け取った計算結果と、認証セッション管理部１２０で
の計算結果を比較して双方の計算結果が同じであるかを
照合し（ステップ２１１）、同じであればカード認証が
成功したものとし、計算結果が異なればカード認証が失
敗したものとする。

【００７５】カード認証が成功すると、認証課金サーバ
１００では、カードＩＤに対する認証セッションＩＤや
手形署名鍵等の手形情報生成に必要なデータを生成し
（ステップ２１２）、カードＩＤに対して生成した認証
セッションＩＤと手形署名鍵と、カードバリュー管理Ｄ
Ｂ１３０でカードＩＤに対応して管理されているプリペ
イド残額と認証課金サーバで管理している認証有効機関
を購入制御端末２００に送信する（ステップ２１３）と
共に、カードＩＤが認証済であることを示す認証セッシ
ョン情報として認証セッション管理部１２０で保持する
（ステップ２１４）。

【００７６】図９は、本発明の一実施例の前提となる認
証課金サーバの認証セッション情報の例を示す。同図の
例では、認証課金サーバ１００の認証セッション情報
は、カードＩＤと認証セッションＩＤと手形署名鍵と認
証タイムアウト時間からなる。このうち、認証セッショ
ンＩＤは、認証セッション管理部１２０で生成される認
証を一意に特定する識別子であり、他の認証セッション
情報と重ならないように生成されればよく、認証セッシ
ョン管理部１２０で管理するシリアル番号により割り振
るなどの方法で生成できる。

【００７７】また、手形署名鍵は、認証セッションＩＤ
に対して生成される。認証セッション中に手形情報の確
認に使用される鍵であり、購入制御端末２００以外の第
三者から推測されない形で生成されればよく、疑似乱数
生成関数により生成される乱数を使用するなどの方法が
採れる。

【００７８】また、認証タイムアウト時間は、認証セッ
ション情報を生成した時刻（現在時刻）から、認証課金
サーバ１００に任意に設定されている認証有効期間経過
した時点の時刻であり、認証タイムアウト時間に到達し
た時点で、当該認証セッション情報を破棄することにな
る（または、認証セッション情報を無効とする）。

【００７９】購入制御端末２００では、ステップ２１３
において認証セッションＩＤと手形署名鍵とプリペイド
残額と認証有効期間を受信すると、受信したデータを課
金制御部２３０に手形情報生成のためのデータである認
証セッション情報として保存する（ステップ２１５）と
共に、受信したプリペイド残額を購入制御部２４０のデ
ィスプレイ装置などにより表示することでユーザに提示
する（ステップ２１６）。

【００８０】図１０は、本発明の一実施例の前提となる
購入制御端末における認証セッション情報の例を示す。

【００８１】同図の例では、購入制御端末２００の認証
セッション情報は、カードＩＤと手形発行可能額と認証
セッションＩＤと手形署名鍵と認証タイムアウト時間と
次回手形発行ＩＤからなる。なお、例では、１つの認証
セッション情報となっているが、複数のカードを同時に
扱うことのできるカードリーダ・ライタ（非接触型カー
ドなどの場合）では、複数のカードＩＤに対する認証セ
ッション情報を保持してもよい。（ここで、複数のカー
ドを同時に扱えるカードリーダ・ライタを使用し、複数
の認証セッション情報を管理できるシステムの場合に
は、引き抜かれたカードのカードＩＤに対応する認証セ
ッション情報を特定したり、通信対象のカードを特定す
るために、カードリーダ・ライタでは、カード挿入時及
びカード引抜き時にカードリーダ・ライタがカードを特
定する情報を出す必要があり、カードとの通信時には、
カードリーダ・ライタがカードを特定する情報を指定し
て通信を行う必要がある。また、購入制御端末２００内
でカードＩＤに関連して、カードリーダ・ライタがカー
ドを特定する情報を管理しておくことで、カード引抜き
時に引き抜かれたカードのカードＩＤ及び認証セッショ
ン情報を特定することが可能となる。）ここで、手形発
行可能額は、ステップ２１３において、認証課金サーバ
１００から受信したプリペイド残額が初期値として設定
され、手形情報の販売サーバ３００への払い出し毎に支
払額分減算することで、プリペイド残額の把握を行う。
また、認証セッションＩＤと手形署名鍵は、ステップ２
１３で認証課金サーバ１００から受信したデータであ
る。

【００８２】また、認証タイムアウト時間は、認証セッ
ション情報を生成した時刻（現在時刻）から、ステップ
２１３で受信した認証有効期間経過した時点の時刻であ
り、認証タイムアウト時間を越えたときには、認証セッ
ション情報が無効であると判断する。

【００８３】また、次回手形発行ＩＤは、次回に生成す
る手形情報中の手形発行ＩＤを示しており、手形を手形
情報（手形発行ＩＤ）を生成する毎に１づつ加算してい
く。新たに認証セッション情報が保存されたときには、
初期値として０などが設定される。

【００８４】なお、カード認証が失敗した場合には、ス
テップ２１２、ステップ２１４の処理は行わずに、ステ
ップ２１３で認証失敗を通知し、認証失敗を受け取った
購入制御端末２００でもステップ２１５の処理は行わな
い。

【００８５】次に、『購入・支払処理』で示した範囲
で、手形情報の生成・払い出しによるコンテンツ等の商
品購入及び、支払処理を行うが、購入・支払処理のタイ
ミングは、『ＩＣカード認証処理』の後で、『認証状態
終了処理』の前であればいつでも良いが、通常は、購入
者から商品購入の指示が出たときに行う。

【００８６】また、『購入・支払処理』で示した範囲の
処理は、１回の『ＩＣカード認証処理』に対して複数回
行うことが可能であり、つまり、１回のカード認証で複
数の販売サーバ３００への複数回の支払（複数の販売サ
ーバ３００から複数回の商品購入）が可能となってい
る。

【００８７】本実施例の『購入・支払処理』では、手形
情報生成等の支払処理を行う前に、購入対象の商品の情
報（コンテンツＩＤ、価格、支払ＩＤ等）を入手してお
き、購入者からの購入指示があることを前提としてお
り、購入する商品は、ダウンロードコンテンツであるこ
とを前提としている。

【００８８】まず、購入制御端末２００では、販売サー
バ３００からコンテンツ名、コンテンツＩＤ・価格・支
払先ＩＤ等からなるコンテンツ情報のメニューリストを
入手し（ステップ２１７）、入手したメニューリストを
購入制御部２４０のディスプレイ装置などに表示するこ
とで購入者の入力を促し（ステップ２１８）、購入制御
部２４０のキーボタン装置等により購入者から購入コン
テンツの指定がされると（ステップ２１９）、手形情報
の生成処理などの支払処理に移行する。

【００８９】まず、購入制御端末２００は、認証セッシ
ョン情報の認証セッションＩＤと手形署名鍵と次回発行
手形発行ＩＤを読出し、課金制御部２３０で手形署名の
作成を行うことで、手形情報を生成すると共に、認証セ
ッション情報の手形発行可能額から購入コンテンツの価
格である支払額を減算し、次回手形発行ＩＤに１加算す
る（ステップ２２０）。但し、当該認証セッション情報
の認証タイムアウト時間を超えているときには、手形情
報を作成しても手形情報による課金ができないため、手
形情報の生成は行わずに支払処理を中止するか、再度Ｉ
Ｃカード認証処理を行った後に支払処理を行うことにな
る。

【００９０】なお、課金制御部２３０で保持する認証タ
イムアウト時間内の認証セッション情報が複数ある時に
は、適当なカードの認証セッション情報を選び出すこと
になるが、認証セッション情報の選択は、 ・早く挿入されたカードの認証セッション情報を選ぶ。 ・残額の少ないカードから選ぶ。 ・残額の多いカードから選ぶ。 等のルールや、他のルールによっても構わない。

【００９１】図１１は、本発明の一実施例における手形
情報の例である。

【００９２】同図の例では、手形情報は、認証セッショ
ンＩＤと手形発行ＩＤと手形署名からなり、認証セッシ
ョンＩＤには、認証セッション情報から読み出した認証
セッションＩＤが入り、手形発行ＩＤには、認証セッシ
ョン情報から読出した次回手形発行ＩＤが入り、手形署
名には、課金制御部２３０で作成する手形署名が入る。

【００９３】手形署名を作成するためのパラメータとし
て、手形署名鍵・認証セッションＩＤ・手形発行ＩＤ・
支払先ＩＤ・支払額・コンテンツＩＤを使用し、各パラ
メータを結合したデータを一方向性ハッシュ関数に入力
することで入力文に対するメッセージ認証子としての手
形署名を得ている。一方向性ハッシュ関数は計算結果か
ら入力文のカード認証鍵を推測することが困難であり、
逆に認証鍵を知らなければ別の入力文と手形署名のペア
の作成が困難な方式であればなんでも良く、ＭＤ５関
数、ＳＨＡ関数等を使用することが可能である。

【００９４】ここで、手形署名鍵・認証セッションＩＤ
・手形発行ＩＤは、認証セッション情報から読み出した
データであり、支払元（課金積）のカードを証明する情
報となっている。

【００９５】また、支払先ＩＤ・コンテンツＩＣは、販
売サーバ３００から受け取った購入コンテンツの情報で
あり、また、支払額にはコンテンツの購入コンテンツの
価格を入れ、これら支払先ＩＤ・コンテンツＩＤ・支払
額は取引の内容を限定する情報となっている。

【００９６】また、手形署名作成方法は、認証セッショ
ンＩＤ・手形発行ＩＤ・支払先ＩＤ・支払額・コンテン
ツＩＤが改竄されていないことを証明できる情報として
の手形署名が作成できればなんでもよく、例えば、手形
署名鍵を鍵とした非対象（公開鍵）暗号方式を使用した
ディジタル署名等を使用しても構わない。但し、非対象
暗号方式を使用する場合には、購入制御端末２００で保
持する手形署名鍵を認証鍵とし、認証課金サーバ１００
で保持する手形署名鍵を検証鍵として、それぞれペアで
関連付けられてはいるが、異なるデータの鍵を使用する
必要がある。

【００９７】ステップ２２０で手形情報が生成される
と、購入制御端末２００から販売サーバ３００に対し
て、購入コンテンツを指定するコンテンツＩＤと、支払
のための情報である手形情報とを送信することで、コン
テンツ購入を要求し（ステップ２２１）、販売サーバ３
００では、コンテンツＩＤと手形情報を受け取ると、認
証課金サーバ１００に対して手形情報と、精算時の支払
先を特定する情報としての支払先ＩＤと、コンテンツの
価格に相当する請求額と、コンテンツＩＤを送信する
（ステップ２２２）。なお、ここで請求額は、ステップ
２１７で購入制御端末２００に送信したコンテンツの価
格と同額でなければならず、支払先ＩＤも、ステップ２
１７で購入制御端末２００に送信した支払先ＩＤでなけ
ればならない（他の値を入れると課金に失敗する）。な
お、通常の場合、支払先ＩＤは、販売サーバ３００を持
つ事業者を特定する情報である。

【００９８】認証課金サーバ１００では、手形情報、支
払先ＩＤ、請求額、コンテンツＩＤを受け取ると、ま
ず、手形情報中の認証セッションＩＤを認証セッション
管理部１２０で保持している認証セッション情報から検
索し該当する認証セッション情報がある場合には、現在
時刻が認証タイムアウト時間前であるかを調べる。該当
する認証セッション情報があり、認証タイムアウト時間
前であったときには、要求された手形情報に対する認証
が有効であると判断する（ステップ２２３）。

【００９９】逆に、該当する認証セッション情報がなか
ったあり、あったとしても認証タイムアウト時間を過ぎ
ている場合には、、販売サーバ３００に対して課金失敗
を通知し、処理を終了する。

【０１００】次に、手形情報（認証セッションＩＤ＋手
形発行ＩＤ）が、手形決済履歴管理表に登録されていな
かを検査し、もし登録されていれば、既に課金済の手形
情報であると判断し、販売サーバ３００に対して課金失
敗を通知し、処理を終了する。ここで、手形決済管理表
は、認証課金サーバ１００で作成・管理されるものであ
り、認証課金サーバ１００が決済をした取引がすべて記
載される。従って、この表に記載されているということ
は、既にその手形が課金済という証明になるので、上記
のような動作となる。図１２は、本発明の一実施例の手
形決済履歴管理表の例を示す。

【０１０１】手形情報が登録されていない時には、検索
された該当する認証セッション情報の手形署名鍵と、販
売サーバ３００から受信した手形情報、支払先ＩＤ、請
求額、コンテンツＩＤを使用して、手形情報中の手形署
名の検査を行う。

【０１０２】手形署名の検査では、購入制御端末２００
での手形署名作成時と同じ手順で手形署名鍵、手形情報
中の認証セッションＩＤ・手形情報中の手形発行ＩＤ・
支払先ＩＤ・請求額（手形署名作成時の支払額）・コン
テンツＩＤをパラメータとして手形署名を作成し、手形
情報中の手形署名と作成された手形署名が同じであるか
比較する（ステップ２２４）。ここで、手形情報中の手
形署名と作成された手形署名が異なる場合には、手形情
報または、販売サーバ３００から指定された情報が不正
であると判断し、販売サーバ３００に対して課金失敗を
通知し、処理を終了する。

【０１０３】手形情報中の手形署名と作成された手形署
名が同一の場合には、破棄対象手形管理表に当該認証セ
ッションＩＤと手形発行ＩＤが登録されていないのかの
破棄手形検査を行う（ステップ２２５）。図１３は、本
発明の一実施例の破棄対象手形管理表の例を示す。後述
する購入支払中止処理により、当該認証セッションＩＤ
と手形発行ＩＤが破棄対象手形管理表に登録されている
場合には、認証課金サーバ１００が手形破棄情報を巣で
に受け付けていることを意味しており、ユーザがこの手
形の破棄を要求していると認証課金サーバ１００に認知
し、課金実行することなしに販売サーバ３００に対して
課金失敗を通知し、手形の破棄を履行したものとして、
破棄対象手形管理表から当該認証セッションＩＤと手形
発行ＩＤを削除する。

【０１０４】破棄対象手形管理表に当該認証セッション
ＩＤと手形発行ＩＤが登録されていない場合には、課金
処理（ステップ２２６）に移行する（ステップ２２
５）。

【０１０５】課金処理として、手形情報中の手形発行Ｉ
Ｄと、ステップ２２３で検索された認証セッション情報
を手形決済履歴管理表に登録すると共に、ステップ２２
３で検索された認証セッション情報のカードＩＤに対応
して、カードバリュー管理ＤＢ１３０で管理されている
プリペイド残額から、販売サーバ３００から受け取った
請求額分を減算する。ここで、プリペイド残額が請求額
を下回る場合には、請求額分の課金が不可能であると判
断し、販売サーバ３００に対して課金失敗を通知し処理
を終了する。

【０１０６】プリペイド残額の減算ができたら、認証セ
ッション管理部１２０から精算部１４０に対して当該カ
ードＩＤと販売サーバ３００から受信した手形情報・支
払先ＩＤ・請求額・コンテンツＩＤを渡すことで、精算
部１４０では当該精算部内で管理する精算ログＤＢの当
該支払先ＩＤに対応して、取引リストとして手形情報・
請求額・コンテンツＩＤの情報を追加し、精算額に請求
額分を加算する（ステップ２２６）。

【０１０７】課金処理が成功すると、ステップ２２２の
課金要求の応答として、認証課金サーバ１００から販売
サーバ３００に対して課金が成功したことを通知し（ス
テップ２２７）、販売サーバ３００では、課金成功通知
を受信すると、購入制御端末２００に対して要求された
コンテンツの配信を開始する（ステップ２２８）。

【０１０８】また、課金が成功すると認証課金サーバ１
００は、その取引が決済されたものとして、手形決済履
歴管理表に課金が成功した認証セッションＩＤと手形発
行ＩＤを記録する。

【０１０９】次に、『認証状態終了処理』について説明
する。

【０１１０】『認証状態終了処理』で示した範囲で、Ｉ
Ｃカード１０に対する認証状態の破棄を行う。『認証状
態終了処理』が行われると、対象カードの認証セッショ
ン情報が削除されるため、支払処理のステップ２２３の
認証中検査が失敗し、再度、『ＩＣカード認証処理』が
行われるまでは対象カードに対する課金が不可能にな
る。

【０１１１】なお、本実施例の説明では、カード引抜き
を契機に『認証状態終了処理』が行われることを前提と
しているが、カード引抜き以外でも、ユーザからサービ
ス終了等の指示があったとき、等を契機として認証状態
終了処理を行ってもよい。

【０１１２】『認証状態終了処理』では、まず、ＩＣカ
ード認証処理により、認証済のカードが引き抜かれると
（ステップ２２９）、カードリーダ・ライタ２１０によ
りカード引抜きが検知されて、課金制御部２３０で保持
している引き抜かれたカードのカードＩＤに対応する認
証セッション情報を削除する（ステップ２３０）と共
に、購入制御端末２００の課金制御部２３０では認証課
金サーバ１００に対してカードＩＤを送信することでカ
ードＩＤのカードの認証状態の破棄（認証セッション情
報の削除）を要求する（ステップ２３１）。

【０１１３】ここで、送信する情報は、認証セッション
を特定できる情報であればよく、本実施例においても、
カードＩＤではなく、認証セッションＩＤでもよい。

【０１１４】認証課金サーバ１００では、ＩＣカード認
証終了要求を受信すると、受信したカードＩＤにより認
証セッション管理部１２０で保持する認証セッション情
報を検索して、検索された認証セッション情報を削除す
ることでカードＩＤに対する認証状態の破棄を行い（ス
テップ２３２）、認証状態が破棄されたことを購入制御
端末２００に通知する（ステップ２３３）。

【０１１５】また、『認証状態終了処理』において、認
証セッション情報が削除されるため、該当する認証セッ
ションＩＤが示す手形情報を課金することはできなくな
る。従って、もはや、破棄対象手形管理表に当該認証セ
ッションＩＤを記録しておかなくても、この認証セッシ
ョンＩＤが示す手形情報に対して、課金することは不可
能となるため、『認証状態終了処理』では、認証終了要
求が示す認証セッションＩＤが破棄対象手形管理表に存
在するかどうかを確認し、もし存在する場合には、該当
認証セッションＩＤを持つ全てのレコードを、破棄対象
手形管理表から削除する。

【０１１６】以上が、本発明の前提となるシステムの動
作である。本発明のシステムの動作を『購入・支払中止
処理』として以下に説明する。

【０１１７】［第１の実施例］前述の図８における『購
入・支払処理』にて示した範囲であるコンテンツ等の商
品購入および支払処理を中止したい場合には、購入や支
払処理の中止を『購入・支払処理』の範囲内で行う。購
入・支払中止処理のタイミングは、購入・支払処理の後
で、認証状態終了処理の前である必要があり、購入者か
ら直接に商品購入中止の指示により行われたり、販売サ
ーバ３００障害等の異常時に購入制御端末２００から自
動的に行われたりする。

【０１１８】また、購入・支払周知処理で示した範囲の
処理は、１回の購入・支払処理に対して、１回行うこと
が可能である。

【０１１９】本実施例での購入・支払中止処理では、
『購入・支払処理』において利用した手形情報（手形発
行ＩＤ）を利用する。

【０１２０】図８において、購入制御端末２００は、ス
テップ２２０において、手形情報を生成し、ステップ２
２１で販売サーバ３００に対して手形情報が送信される
ときに、その手形情報を記憶しておく。この時点で購入
制御端末２００が管理しているバリュー情報からは、生
成した手形情報に含まれる請求額の分だけ減算される。
手形情報を送信したのちに、ユーザが購入キャンセルボ
タン等を押下したとき、購入制御端末２００は破棄した
い手形情報が含まれた手形破棄情報を作成し、認証課金
サーバ１００に販売サーバ３００を介さずに直接送信す
る。

【０１２１】手形破棄情報を受信した認証課金サーバ１
００は、手形決済履歴管理表を検索し、該当認証セッシ
ョンＩＤと手形発行ＩＤが登録されているかどうかを調
べる。もし、登録されていれば、すでに課金済の手形情
報であると判断し、購入制御端末２００に対して、手形
課金済通知を送信して、認証課金サーバ１００における
この処理は終了する。この処理を図１４に示す。

【０１２２】当該認証セッションＩＤと手形発行ＩＤが
登録されていない場合には、当該手形は課金実行がされ
ていないと判断し、破棄対象手形管理表に当該認証セッ
ションＩＤと手形発行ＩＤを登録し、購入制御端末２０
０に対して、手形破棄情報受付通知を送信する。破棄対
象手形管理表に登録された手形情報が販売サーバ３００
から送信されてきた場合、その内容の正当性に関わら
ず、その手形は換金せず、販売サーバ３００に対して課
金失敗を通知し、破棄対象手形管理表から当該認証セッ
ションと手形発行ＩＤを削除して、認証課金サーバ１０
０におけるこの処理を終了する。この処理を図１５に示
す。

【０１２３】上述の処理により、購入制御端末２００
は、手形課金済通知か、手形破棄情報受付通知のいずれ
かを受信する。

【０１２４】図１４のステップ３１２の手形課金済通知
を受信した購入制御端末２００は、『購入・支払処理』
が既に行われてしまい、『購入・支払中止処理』が実行
されなかったことを確定できる。そのため、購入制御端
末２００自身で管理しているバリュー情報も、既に課金
されてしまったものとして、確定することができるた
め、認証課金サーバ１００が管理するバリュー情報と、
購入制御端末２００が管理するバリュー情報に相違が生
じることを抑止することが可能である。

【０１２５】また、図１５のステップ４０９に示すよう
に、手形破棄情報受付通知を受信した購入制御端末２０
０は、購入・支払中止処理が確実に実行され、購入・支
払処理が実行されないことを確定できる。なぜなら、購
入・支払処理を行っているために、販売サーバ３００か
ら認証課金サーバ１００に手形情報が到着しても、破棄
対象手形管理表に、当該認証セッションと手形発行ＩＤ
が登録されているために、確実にその手形が課金実行さ
れないことが保証されているためである。従って、購入
制御端末２００自身が管理するバリュー情報に、既に送
信してしまったが確実に課金されないことが保証された
手形情報が持つ請求額の分を増加させることにより、認
証課金サーバ１００が管理するバリュー情報と、購入制
御端末２００が管理するバリュー情報に相違が生じるこ
とを抑止することが可能となる。次に、購入制御端末２
００の動作について説明する。

【０１２６】図１６は、本発明の第１の実施例の購入制
御端末の動作のフローチャートである。

【０１２７】まず、購入制御端末２００では、カードリ
ーダ・ライタ２１０にてカード接続が検出されるのを待
ち（ステップ５０１）、カードが検出されたら、接続さ
れたＩＣカード１０内のカードデータ保持部１３に保存
されているカードＩＤの読み出しを行う（ステップ５０
２）。

【０１２８】カードＩＤの読み出しが終わると、認証課
金サーバ１００に対してＩＣカード認証要求を送信する
ことで、挿入されたＩＣカード１０に対するカード認証
を要求するが、この際に、認証対象のＩＣカード１０の
カードＩＤを送信する（ステップ５０３）。

【０１２９】次に、認証課金サーバ１００から送信され
てくるメッセージ“計算要求”を待ち、当該メッセージ
を受信したら、受信内容をそのままＩＣカード１０に送
信して、ＩＣカード１０からのメッセージを待ち、ＩＣ
カード１０から計算要求応答を受信したら、受信内容を
そのまま認証課金サーバ１００に送信するという、認証
課金サーバ１００とＩＣカード１０間で送受信される、
認証データの中継を行う（ステップ５０４）。

【０１３０】認証中継処理が終了すると、認証課金サー
バ１００からＩＣカード認証結果を受信する（ステップ
５０５）。

【０１３１】ここで、ＩＣカード認証結果の受信時に、
認証エラーを示すデータを受信した場合には（ステップ
５０６，Ｙｅｓ）、ステップ５１６に移行して、エラー
メッセージの表示やカード引抜き、交換指示などを行
い、処理を終了する。

【０１３２】認証エラーでないときには（ステップ５０
６，Ｎｏ）、ＩＣカード認証結果で、認証セッションＩ
Ｄと、手形署名鍵とプリペイド残額と、認証有効期間を
受信しているので、認証セッション情報保存で、受信し
たデータを課金制御部２３０に手形情報生成のためのデ
ータである認証セッション情報としてカードＩＤと共に
保持する（ステップ５０７）。

【０１３３】なお、認証有効期間は、認証セッション情
報を生成した時刻（現在時刻）から認証有効期間経過し
た時点の時刻としての認証タイムアウト時間として保存
する。

【０１３４】また、プリペイド残額は、手形発行可能額
として保存する。

【０１３５】また、次回手形発行ＩＤは、“０”に初期
化する。

【０１３６】次に、受信したプリペイド残額を購入制御
部２４０のディスプレイ装置などにより表示することで
ユーザに提示する（ステップ５０８）。

【０１３７】また、販売サーバ３００から購入対象のコ
ンテンツのメニューリストを取得し、取得したメニュー
リストを購入制御部２４０のディスプレイ装置などに表
示する（ステップ５０９）。

【０１３８】なお、取得するメニューリストには、メニ
ュー表示するためのコンテンツ名や説明情報の他に、商
品を購入するための手形情報作成に必要なコンテンツ情
報（コンテンツＩＤ、価格、支払先ＩＤ等）が含まれて
いる。

【０１３９】メニュー取得及び表示の処理が終了する
と、ユーザの指示によるコンテンツ購入の処理に移行す
る。

【０１４０】ここでは、カード挿入中のみ挿入されてい
るカードのバリューでのコンテンツ購入ができるように
構成するため、ステップ５１０で、カードリーダ・ライ
タ２１０よりカード引抜きの検知を行い、カード引抜き
を検知した場合には、ＩＣカード１０に対する認証状態
の破棄を行う。

【０１４１】認証状態の破棄は、まず、課金制御部２３
０で保持している引き抜かれたカード１０のカードＩＤ
に対応する認証セッション情報を削除する（ステップ５
１７）。

【０１４２】また、購入制御端末２００の課金制御部２
３０では、認証課金サーバ１００に対してカードＩＤを
指定してＩＣカード認証終了要求を送信することで、認
証課金サーバ１００内でのカードＩＤのカードの認証状
態の破棄（認証セッション情報の削除）を要求すると共
に、認証課金サーバ１００からＩＣカード認証終了結果
を待ち、当該ＩＣカード認証終了結果を受信したら処理
を終了する（ステップ５１８）。

【０１４３】ステップ５１０で、カード引き抜きの検知
がされなかった場合には（ステップ５１０，Ｎｏ）、購
入者の操作により購入制御部２４０で表示されたメニュ
ーから購入コンテンツの選択が行われるのをチェック
し、選択がされていないときは（ステップ５１１，Ｎ
ｏ）、カード引抜きまたは、メニュー選択がされるま
で、繰り返しチェックを行う。

【０１４４】なお、購入コンテンツの選択は、購入制御
部２４０のキーボタン装置等により行われる。

【０１４５】購入者によりメニュー選択が行われて購入
するコンテンツが決定すると、認証セッション情報に保
存されている認証セッションＩＤと手形署名鍵と手形発
行ＩＤ（次回手形発行ＩＤ）と、指定されたコンテンツ
に対応するコンテンツ情報（メニューリストとして販売
サーバから取得した情報）である支払先ＩＤと支払額と
コンテンツＩＤとをパラメータとして、課金制御部２３
０で手形署名の作成を行い、認証セッションＩＤと手形
発行ＩＤと手形署名を併せて手形情報とする（手形情報
及び手形署名の作成方法については、前述の図１１、及
び前述の説明を参照）。

【０１４６】但し、認証セッション情報の認証タイムア
ウト時間を超えているときには、手形情報を作成しても
手形情報による課金ができないため、手形情報の生成は
行わずに、処理を中止するか、再度ＩＣカード認証処理
（ＩＣカード認証要求送信（ステップ５０３）〜カード
残額表示（ステップ５０８））を行った後に手形情報の
生成を行うことになる。

【０１４７】また、手形情報の生成が終了すると、認証
セッション情報の手形発行可能額から購入コンテンツの
価格である支払額分を減算すると共に、次回手形発行Ｉ
Ｄに１を加算する（ステップ５１３）。

【０１４８】次に、購入制御端末２００から販売サーバ
３００に対して、購入コンテンツを指定うるコンテンツ
ＩＤと、支払のための情報である手形情報とを送信する
ことでコンテンツ購入を要求し（ステップ５１４）、販
売サーバ３００から要求したコンテンツが配信されるの
を待ち、配信されたコンテンツを受信する（ステップ５
１５）。なお、認証課金サーバ１００で手形情報の確認
が失敗すると、販売サーバ３００から課金失敗の通知を
受け、コンテンツが配信されない。

【０１４９】また、購入者のキャンセルボタン押下など
により、コンテンツ購入キャンセルのイベントが発生し
たら、購入制御端末２００から認証課金サーバ１００に
対して、コンテンツ購入中止要求で支払を中止したい手
形情報を含む手形破棄情報を送信することで、認証課金
サーバ１００において、課金中止が成功したかどうかを
示す情報を待ち、認証課金サーバ１００から、手形課金
済通知が送信されてきた場合には、課金中止ができず課
金が既に行われてしまったことを認知し、ユーザインタ
フェース上にそれを表示する。課金は前払い方式であ
り、手形生成時に既に課金したものとして取り扱ってい
るから、購入制御端末２００は、バリューに関しては、
何もせず、そのまま確定する。また、認証課金サーバ１
００から手形破棄情報受付通知が送信されてきた場合に
は、課金中止に成功したことを認知し、ユーザインタフ
ェース上でそれを表示すると共に、すでに課金されたと
考えて前払いしてしまった手形情報が示すバリューを、
自身が管理するバリューに加算する。

【０１５０】コンテンツの受信が完了すると、ステップ
５０１に戻り、カード１０が引き抜かれるまで、ステッ
プ５０１〜ステップ５１５でコンテンツ購入・支払処理
を繰り返す。

【０１５１】次に、認証課金サーバ１００の動作を説明
する。

【０１５２】図１７は、本発明の第１の実施例の認証課
金サーバの概要動作のフローチャートである。

【０１５３】購入制御端末２００から受け取るメッセー
ジ受信や、販売サーバ３００から受け取るメッセージ受
信や、認証セッションの期限切れの監視を行い、それぞ
れが生起したときに対応した処理を行うことを示してい
る。

【０１５４】具体的には、購入制御端末２００からのＩ
Ｃカード認証要求を受信したかを監視し（ステップ６１
０）、受信した時には、ＩＣカード認証処理を行う（ス
テップ６２０）。当該ＩＣカード認証処理の詳細は後述
する。

【０１５５】また、購入制御端末２００からＩＣカード
認証終了要求を受信したかを監視し（ステップ６３
０）、受信したときには、ＩＣカード認証終了処理を行
う（ステップ６４０）。当該ＩＣカード認証終了処理の
詳細は後述する。

【０１５６】また、販売サーバ３００からの課金要求を
受信したかを監視し（ステップ６５０）、受信したとき
には、課金処理を行う（ステップ６６０）。当該課金処
理の詳細は後述する。

【０１５７】また、認証セッション管理部１２０で保存
している認証セッン情報内の認証タイムアウト時間が現
在時刻より古くなっているかを監視し、認証タイムアウ
ト時間が現在時刻より古くなっている認証セッションが
ある場合には（ステップ６８０）、認証タイムアウト処
理を行う（ステップ６９０）。当該認証タイムアウト処
理の詳細は後述する。

【０１５８】次に、上記のステップ６２０のＩＣカード
認証処理について説明する。

【０１５９】図１８は、本発明の第１の実施例の認証課
金サーバにおけるＩＣカード認証処理のフローチャート
である。

【０１６０】ＩＣカード認証処理（ステップ６２０）で
は、購入制御端末２００からＩＣカード認証要求のメッ
セージで受け取ったカードＩＤを、カードバリュー管理
ＤＢ１３０から検索し、登録されていれば（ステップ６
２１、Ｙｅｓ）、ステップ６２２に移行する。登録され
ていなければ（ステップ６２１、Ｎｏ）、購入制御端末
２００に対して、ＩＣカード認証結果としてエラーを示
す情報を送信するなどを行い、処理を終了する（ステッ
プ６２９）。

【０１６１】疑似乱数生成関数等を使用して、乱数を生
成し、生成した乱数を計算要求として購入制御端末２０
０に送信する（ステップ６２２）。

【０１６２】次に、購入制御端末２００から計算要求応
答のメッセージを待ち、当該メッセージを受信する（ス
テップ６２３）。

【０１６３】次に、認証セッション管理部１２０によ
り、送信した乱数と、受信したカードＩＤに対応してカ
ードバリュー管理ＤＢ１３０に保存してあるカード認証
鍵を使用して、ＩＣカード１０と同じ計算を行い、計算
結果を得る（ステップ６２４）。

【０１６４】次に、受け取った計算要求応答である計算
結果と、認証セッション管理部１２０での計算結果を比
較し、双方の計算結果が合致すれば（ステップ６２５，
Ｙｅｓ）、ステップ６２６に移行する。また、双方の計
算結果が異なれば（ステップ６２５、Ｎｏ）、購入制御
端末２００に対して、ＩＣカード認証結果として、エラ
ーを示す情報を送信するなどの処理を行い、処理を終了
する（ステップ６２９）。

【０１６５】認証セッション管理部１２０で管理するシ
リアル番号を割り振るなどの方法により、認証セッショ
ン情報内の他の認証セッションＩＤと重ならない認証セ
ッションＩＤを生成すると共に、疑似乱数生成関数等に
より手形署名鍵を生成する（ステップ６２６）。

【０１６６】また、生成された認証セッションＩＤと、
手形署名鍵と、カードバリュー管理ＤＢ１３０で受信し
たカードＩＤに対応して管理されているプリペイド残額
と、認証課金サーバ１００で管理している認証有効期間
を購入制御端末２００にＩＣカード認証結果として送信
する（ステップ６２７）。

【０１６７】また、受信したカードＩＤが認証済である
ことを示す認証セッション情報として、受信したカード
ＩＤと、生成した認証セッションＩＤと、生成した手形
署名鍵と、現在時刻に認証有効期間を加えた時刻である
認証タイムアウト時間とを、認証セッション情報として
認証セッション管理部１２０で保持する（認証セッショ
ン情報については、前述の図９及び前述の説明を参照）
（ステップ６２８）。なお、受信したカードＩＤが、認
証セッション情報に既に保存されている場合には、カー
ドＩＤ、認証セッションＩＤ、手形署名鍵、認証タイム
アウト時間を上書きする。

【０１６８】次に、ステップ６４０におけるＩＣカード
認証終了処理について説明する。

【０１６９】図１９は、本発明の第１の実施例の認証課
金サーバにおけるＩＣカード認証終了処理のフローチャ
ートである。

【０１７０】購入制御端末２００から受信したＩＣカー
ド認証終了要求のメッセージのカードＩＤが、認証セッ
ション管理部１２０で保持する認証セッション情報に登
録されているかを検索する（ここで、ＩＣカード認証終
了要求として受信する情報は、認証セッションを特定で
きる情報であればよく、本実施例においてもカードＩＤ
ではなく認証セッションＩＤでもよい）（ステップ６４
１）。

【０１７１】カードＩＤが認証セッション情報に登録さ
れていないときは（ステップ６４２、Ｎｏ）、購入制御
端末２００に対するＩＣカード認証終了結果として、エ
ラーを送信するなどの処理を行い、処理を終了する。

【０１７２】カードＩＤが認証セッション情報に登録さ
れているときは（ステップ６４２、Ｙｅｓ）、カードＩ
Ｄに対応して検索された認証セッション情報を削除し
（ステップ６４３）、購入制御端末２００にＩＣカード
認証終了結果として、認証状態が破棄されたことを通知
する（ステップ６４４）。

【０１７３】次に、ステップ６６０の課金処理について
説明する。

【０１７４】図２０は、本発明の第１の実施例の認証課
金サーバにおける課金処理のフローチャートである。

【０１７５】まず、販売サーバ３００から課金要求とし
て受信した手形情報内の認証セッションＩＤが、認証セ
ッション管理部１２０で保持する認証セッション情報に
登録されているかを検索する（ステップ６６１）。

【０１７６】認証セッションＩＤが認証セッション情報
に登録されていないときは（ステップ６６２，Ｎｏ）、
販売サーバ３００に対するメッセージでエラーを送信す
るなどの処理を行い、処理を終了する（ステップ６７
６）。

【０１７７】認証セッションＩＤが認証セッション情報
に登録されているときは（ステップ６６２，Ｙｅｓ）、
検索された認証セッション情報の認証タイムアウト時間
が、現在時刻より古ければ（ステップ６６３、Ｙｅ
ｓ）、販売サーバ３００に対するメッセージでエラーを
送信するなどの処理を行い、処理を終了する（ステップ
６７６）。なお、タイマ監視などによりリアルタイムに
期限切れセッションの検出が行われて、認証タイムアウ
ト処理が行われていれば、当該有効期限切れの判断は必
ずしも必要でない。

【０１７８】検索された認証セッション情報の認証タイ
ムアウト時間が、現在時刻より新しければ（ステップ６
６３、Ｎｏ）、受信した手形情報内の手形情報が、手形
今朝意履歴管理表に登録されていれば（ステップ６６
４，Ｙｅｓ）、販売サーバ３００に対するメッセージで
エラーを送信するなどの処理を行い、処理を終了する。
受信した手形情報内の手形情報が、手形決済履歴管理表
に登録されていれば（ステップ６６４，Ｎｏ）、受信し
た手形情報内の手形発行ＩＤが、検索された認証セッシ
ョン情報と共に、破棄対象手形管理表に登録されている
かどうかを検索し（ステップ６６５）、登録されていれ
ば（ステップ６６６，Ｙｅｓ）、当該手形を破棄対象手
形であると認知し、課金処理を中止し、当該手形情報を
破棄対象手形情報から削除し（ステップ６７４）、認証
課金サーバ１００から販売サーバ３００に対して、課金
失敗通知を送信すると共に、課金処理を中止して終了す
る（ステップ６７５）。

【０１７９】破棄手形リスト検索の結果、登録されてい
なければ（ステップ６６６，Ｎｏ）、購入制御端末２０
０での手形署名作成時と同じ手順で、認証セッション情
報に保存されている手形署名鍵と、受信した手形情報中
の認証セッションＩＤと、受信した手形情報中の手形発
行ＩＤを、受信した支払先ＩＤ・請求額（手形署名作成
時の支払額）・コンテンツＩＤとをパラメータとして作
成し（ステップ６６７）、手形署名が同じであるか比較
する（ステップ６６８）。手形情報中の手形署名と作成
された手形署名が異なる場合には（ステップ６６８，Ｎ
ｏ）、販売サーバ３００に対するメッセージでエラーを
送信するなどの処理を行い、処理を終了する（ステップ
６７６）。

【０１８０】手形情報中の手形署名と作成された手形署
名が同一の場合には８ステップ６６８，Ｙｅｓ）、受信
した請求額と、検索された認証セッション情報内のカー
ドＩＤに対応してカードバリュー管理ＤＢ１３０で保持
しているプリペイド残額とを比較する（ステップ６６
９）。プリペイド残額＜請求額である場合には（ステッ
プ６６９，Ｎｏ）、販売サーバ３００に対するメッセー
ジでエラーを送信するなどの処理を行い、処理を終了す
る（ステップ６７６）。

【０１８１】プリペイド残額≧請求額の場合には（ステ
ップ６６９，Ｙｅｓ）、受信した手形情報中の手形情報
を、手形結成履歴管理表に追加する（ステップ６７
０）。

【０１８２】また、検索された認証セッション情報のカ
ードＩＤに対応してカードバリュー管理ＤＢ１３０で管
理されているプリペイド残額から、販売サーバ３００か
ら受け取った請求額分を減算する（ステップ６７１）。

【０１８３】また、認証セッション管理部１２０から精
算部１４０に対して、カードＩＤと販売サーバ３００か
ら受信した手形情報・支払先ＩＤ、請求額、コンテンツ
ＩＤを渡すことで、精算部１４０では、精算部１４０内
で管理する精算ログＤＢの支払先ＩＤに対応して、取引
リストとして、手形情報・請求額・コンテンツＩＤの情
報を追加し、精算額に請求額分を加算する（精算ログに
ついては、前述の説明を参照）（ステップ６７２）。

【０１８４】最後に課金要求の応答として、販売サーバ
３００に対して課金が成功したことを通知し、処理を終
了する（ステップ６７３）。

【０１８５】次に、ステップ６８０における認証タイム
アウト処理について説明する。

【０１８６】図２１は、本発明の第１の実施例の認証課
金サーバにおける認証タイムアウト処理のフローチャー
トである。

【０１８７】ステップ６８０の期限切れセッションの有
無の判断において、検出された認証タイムアウト時間が
現在時刻より古くなっている認証セッションを削除し
て、処理を終了する（ステップ６９１）。

【０１８８】なお、課金処理（ステップ６６０）におけ
る、ステップ６６３の認証有効切れであるかの判断の処
理が行われていれば、ステップ６８０の期限切れセッシ
ョンの有無の判断処理、及びステップ６９０の認証タイ
ムアウトの処理は必ずしも必要でない。

【０１８９】以下、課金中止処理について説明する。

【０１９０】図２２は、本発明の第１の実施例の認証課
金サーバの課金中止処理のフローチャートである。

【０１９１】課金中止処理では、購入制御端末２００か
ら受信した手形破棄要求のメッセージの手形破棄情報内
の認証セッションＩＤが、認証セッション管理部１２０
で保持する認証セッション情報に登録されているかを検
索する（ステップ７０１）。認証セッションＩＤが認証
セッション情報に登録されていないときには（（スペプ
７０２、Ｎｏ）、購入制御端末２００に対するメッセー
ジでエラーを送信するなどの処理を行い、処理を終了す
る（ステップ７１０）。

【０１９２】認証セッションＩＤが認証セッション情報
に登録されているときには（ステップ７０２，Ｙｅ
ｓ）、検索された認証セッション情報の認証タイムアウ
ト時間が、現在時刻より古ければ（ステップ７０３、Ｙ
ｅｓ）、購入制御端末２００に対するメッセージでエラ
ーを送信するなどの処理を行い、処理を終了する（ステ
ップ７１０）。

【０１９３】検索された認証セッション情報の認証タイ
ムアウト時間が、現在時刻より新しければ（ステップ７
０３，Ｎｏ）、ステップ７０４に移行する。

【０１９４】なお、タイマ監視などにより、リアルタイ
ムに期限切れセッションの検出が行われて、後述する認
証タイムアウト処理が行われていれば、当該認証有効期
限切れの判断処理は必ずしも必要でない。

【０１９５】受信した手形破棄情報内の手形情報が、手
形決済履歴管理表に登録されていれば（ステップ７０
４，Ｙｅｓ）、手形課金済通知を送信し（ステップ７０
９）、処理を終了する。

【０１９６】受信した手形破棄情報内の手形情報が、手
形決済履歴管理表に登録されていなければ（ステップ７
０４，Ｎｏ）、破棄手形リストから、認証セッション情
報と手形破棄情報内の手形発行ＩＤをキーとして検索を
行い（ステップ７０５）、これが、破棄手形リストに登
録されていれば（ステップ７０６，Ｙｅｓ）、購入制御
端末２００に対して手形破棄情報受付通知を送信して
（ステップ７０８）、処理を終了する。

【０１９７】破棄手形リストから、認証セッション情報
と手形破棄情報内の手形発行ＩＤをキーとして検索を行
い、これらが破棄手形リストに登録されていなければ
（ステップ７０６、Ｎｏ）、認証セッション情報と手形
破棄情報内の手形発行ＩＤを、破棄手形リストに登録し
（ステップ７０７）、購入制御端末２００に手形破棄情
報受付通知を送信して（ステップ７０８）、処理を終了
する。

【０１９８】［第２の実施例］上記の第１の実施例で
は、ユーザインタフェースとなるのは、購入制御端末２
００であった。購入制御端末２００は、コンテンツ選択
画面などのユーザインタフェース、カード認証機能、カ
ード減算機能、などのいくつかの機能を持つ街頭端末で
ある。従って、ユーザがこれを使用する場合、購入制御
端末２００が設置されている場所まで移動する必要があ
る。これは、ユーザの利便性を下げる。

【０１９９】そこで、本実施例では、購入制御端末２０
０からカード認証機能、カード減算機能を分離し、課金
制御装置として説明する。

【０２００】図２３は、本発明の第２の実施例のシステ
ム構成を示す。

【０２０１】同図に示すシステムは、ＩＣカード１０、
課金制御装置４００、ＰＣ（パーソナルコンピュータ）
５００から構成される。

【０２０２】課金制御装置４００は、カードリーダ・ラ
イタ４１０を内蔵し、ＲＳ２３２ＣやＵＳＢなどの汎用
的なインタフェースを持ち、これにより、ＰＣ５００と
接続される。

【０２０３】また、課金制御装置４００と接続されるＰ
Ｃ５００には、画面表示などのユーザインタフェース
や、課金制御装置との通信機能、及び販売サーバ３００
や、認証課金サーバ１００との通信機能を持つ端末ソフ
トウェア５１０を搭載する。課金制御装置４００とＰＣ
５００と端末ソフトウェア５１０の３つを併せると、購
入制御端末２００と全く同じ動作をすることになる。

【０２０４】課金制御装置４００とＰＣ５００と端末ソ
フトウェア５１０は、３つを併せると、購入制御端末２
００と全く同じ動作をするため、これらを組み合わせて
１つのハードウェアとすれば、購入制御端末２００とし
て動作させることが可能であるし、分離して課金制御装
置４００と端末ソフトウェア５１０のみをユーザに販売
すれば、ユーザは自宅のＰＣの端末ソフトウェア５１０
をインストールして課金制御装置４００を接続すること
により、自宅に居ながらにしてディジタルコンテンツの
購入をすることが可能となる。

【０２０５】認証媒体１０、販売サーバ３００、認証課
金サーバ１００の動作は、前述の第１の実施例と全く同
じであるので、以下では、第１の実施例との差分であ
る、課金制御装置４００とＰＣ５００（端末ソフトウェ
ア５１０）の動作を中心に説明する。なお、以下の説明
においては、ＰＣ５００（端末ソフトウェア５１０）を
単に端末ソフトウェアと呼ぶ。

【０２０６】ＩＣカード認証処理は、第１の実施例と同
様に進められる。手形情報の生成は、第１の実施例で
は、購入制御端末２００が行っているが、本実施例で
は、課金制御装置４００が生成する。端末ソフトウェア
５１０を操作しているユーザがコンテンツの購入を意図
して購入操作を行うと、手形情報生成要求が課金制御装
置４００に送信される。手形情報生成要求を受信した課
金制御装置４００は、認証媒体１０から読み出して管理
しているバリュー情報である、発行可能残額から、生成
した手形情報分のバリューを減算する。こうして生成さ
れた手形情報を、手形情報生成結果と共に端末ソフトウ
ェア５１０に送信する。

【０２０７】手形情報生成結果と手形情報を受信した端
末ソフトウェア５１０は、手形の生成が成功したことを
認知して、商品購入要求と共に、手形情報を販売サーバ
３００に送信する。販売サーバ３００及び認証課金サー
バ１００の動作は、第１の実施例と同様である。

【０２０８】ユーザが、商品購入要求を送信してしまっ
た後に、課金の中止を意図して端末ソフトウェア上でキ
ャンセル操作を行うと、端末ソフトウェアから課金制御
装置４００に対して、手形破棄情報生成要求が送信され
る。この手形破棄情報生成要求には、破棄したい手形の
手形情報も含まれている。手形破棄情報生成要求を受信
した課金制御装置４００では、破棄したい手形情報を検
査し、それが正当な要求であれば、手形破棄情報生成の
処理において、手形破棄情報を生成する。生成された手
形破棄情報は、手形破棄情報生成結果と共に、端末ソフ
トウェア５１０に送信される。端末ソフトウェア５１０
は、手形破棄情報の生成が成功したことを認知し、課金
中止要求と共に手形破棄情報を販売サーバ３００に送信
する。

【０２０９】この後の、販売サーバ３００及び認証課金
サーバ１００での動作は第１の実施例と同様である。

【０２１０】図２４は、本発明の第２の実施例における
課金中止に成功した場合のシーケンスチャートである。

【０２１１】課金中止に成功した場合、認証課金サーバ
１００から端末ソフトウェア５１０に対して手形破棄情
報受付通知を送信する（ステップ８１３）。これを受信
した端末ソフトウェア５１０は、課金制御装置４００に
対して同じ情報を送信する。課金制御装置４００では、
手形破棄情報受付通知に含まれる手形破棄情報から手形
破棄が成功したことを認知し、手形情報に含まれるバリ
ューの分だけ発行可能残額を復帰し（ステップ８１
４）、課金前の状態に復帰できる。その後、手形情報復
帰通知を端末ソフトウェア５１０に対して送信する（ス
テップ８１５）。

【０２１２】図２５は、本発明の第２の実施例の課金中
止ができなかった場合のシーケンスチャートである。

【０２１３】課金中止ができずに、既に課金済だった場
合、認証課金サーバ１００から端末ソフトウェア５１０
に対して、手形課金済通知が送信される（ステップ９１
８）。手形課金済通知を受信した端末ソフトウェア５１
０は、課金制御装置４００に対してこれを送信する。課
金制御装置４００は、課金が確実に履行されたことを認
知し、手形課金済通知を端末ソフトウェア５１０に送信
し（ステップ９１９）、この処理を終了する。課金制御
装置４００から端末ソフトウェア５１０に対して送信さ
れる手形課金済通知は、あってもなくてもよい。

【０２１４】また、上記の実施の形態及び実施例では、
認証課金サーバ１００、販売サーバ３００、購入制御端
末２００、課金制御装置４００の各構成に基づいて説明
したが、これらの装置における各々の動作をプログラム
として構築し、認証課金サーバ１００、販売サーバ３０
０、購入制御端末２００、課金制御装置４００として利
用されるコンピュータにインストールする、または、ネ
ットワークを介して流通させることも可能である。

【０２１５】また、構築されたプログラムを認証課金サ
ーバ１００、販売サーバ３００、購入制御端末２００、
課金制御装置４００として利用されるコンピュータに接
続されるハードディスク装置や、フレキシブルディス
ク、ＣＤ−ＲＯＭ等の可搬記憶媒体に格納しておき、本
発明を実施する際にインストールすることにより、容易
に本発明を実現できる。

【０２１６】なお、本発明は、上記の実施の形態及び実
施例に限定されることなく、特許請求の範囲内におい
て、種々変更・応用が可能である。

【０２１７】

【発明の効果】上述のように、本発明によれば、ユーザ
が購入しようとした商品に対して、コンテンツ購入中止
の意図を表明することを購入中止のキャンセルボタンの
押下等を契機とし、購入制御端末が手形破棄情報を作成
し、販売サーバを中継することなく、直接、その手形破
棄情報を認証課金サーバに送信し、受信した認証課金サ
ーバでは、課金中止を要求された手形情報がすでに課金
されてしまっているならば、手形課金済の応答を、課金
されていないのであれば、手形破棄情報受付応答を購入
制御端末に対して送信することで、販売サーバの障害等
により手形情報が遅延し消失した場合においても、購入
制御端末では発行した手形情報がどのように処理される
かを即時に確定することができるため、ユーザは即時に
次のコンテンツの購入を行ったり、コンテンツ購入を中
止することができる。

【０２１８】また、販売サーバは各事業者が独自に用意
し、その価格や性能も様々なものがあるため、一般に高
い信頼性が期待できないと考えられる。それに対して認
証課金サーバは、各事業者が集中的に利用し、障害があ
るとディジタルコンテンツ販売ネットワークそのものが
使えなくなってしまうことから、高い信頼性が要求さ
れ、実際の運用においては、信頼性の高い設備が用意さ
れることが期待できる。そのため、本発明では、信頼性
の高い認証課金サーバと購入制御端末との通信のみ確保
できれば、信頼性の低い販売サーバに障害が発生して
も、ユーザの手形情報の履行を安全に中止し、バリュー
を保護し、引続き障害が発生していない他の販売サーバ
で、コンテンツの購入を行うことができる。

【図面の簡単な説明】

【図１】本発明の原理を説明するための図である。

【図２】本発明の原理構成図である。

【図３】本発明が適用されるシステムの構成図である。

【図４】本発明の前提となるシステムの動作の概要を示
すシーケンスチャートである。

【図５】本発明の一実施例の前提となるシステム構成図
である。

【図６】本発明の一実施例の前提となるＩＣカードのカ
ードデータ保持部のデータの例である。

【図７】本発明の一実施例の前提となる認証課金サーバ
のカードバリュー管理ＤＢのデータの例である。

【図８】本発明の一実施例の前提となるシステムの動作
を示すシーケンスチャートである。

【図９】本発明の一実施例の前提となる認証課金サーバ
の認証セッション情報の例である。

【図１０】本発明の一実施例の前提となる購入制御端末
における認証セッション情報の例である。

【図１１】本発明の一実施例の前提となる手形情報の例
である。

【図１２】本発明の一実施例の前提となる手形結成履歴
管理表の例である。

【図１３】本発明の一実施例の前提となる破棄対象手形
管理表の例である。

【図１４】本発明の第１の実施例の課金済となる処理処
理のシーケンスチャートである。

【図１５】本発明の第１の実施例の課金中止成功の場合
のシーケンスチャートである。

【図１６】本発明の第１の実施例の購入制御端末の動作
のフローチャートである。

【図１７】本発明の第１の実施例の認証課金サーバの概
要動作のフローチャートである。

【図１８】本発明の第１の実施例のＩＣカード認証処理
のフローチャートである。

【図１９】本発明の第１の実施例の認証課金サーバにお
けるＩＣカード認証終了処理のフローチャートである。

【図２０】本発明の第１の実施例の認証課金サーバにお
ける課金処理のフローチャートである。

【図２１】本発明の第１の実施例の認証課金サーバにお
ける認証タイムアウト処理のフローチャートである。

【図２２】本発明の第１の実施例における認証課金サー
バの課金中止処理のフローチャートである。

【図２３】本発明の第２の実施例のシステム構成図であ
る。

【図２４】本発明の第２の実施例における課金中止に成
功した場合のシーケンスチャートである。

【図２５】本発明の第２の実施例の課金中止ができなか
った場合のシーケンスチャートである。

【符号の説明】

１０ 認証媒体 １１ 通信部 １２ 認証応答部 １３ カードデータ保持部 １００ 認証課金サーバ １０１ 課金中止情報受信手段 １０２ 課金中止手段 １１０ 通信部 １２０ 認証セッション管理部 １３０ カードバリュー管理ＤＢ １４０ 精算ログ部（精算ログＤＢ） ２００ 購入制御端末 ２０１ 課金中止要求発行手段 ２０２ バリュー情報確定手段 ２１０ カードリーダ・ライタ ２２０ 通信部 ２３０ 課金制御部 ２４０ 購入制御部 ３００ 販売サーバ ３１０ 通信部 ３２０ 制御部 ３３０ 精算ログＤＢ ３４０ コンテンツＤＢ等 ４００ 課金制御装置 ４１０ カードリーダ・ライタ ４２０ 通信部 ４３０ 課金制御部 ５００ ＰＣ（パーソナルコンピュータ） ５１０ 端末ソフトウェア ５１１ 通信部 ５１２ 購入制御部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 15/00 Ｇ０６Ｆ 15/00 ３３０Ｚ Ｇ０６Ｋ 17/00 Ｇ０６Ｋ 17/00 Ｌ (72)発明者 増田 竜太 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 川村 浩正 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 Ｆターム(参考） 5B058 CA01 KA31 KA35 YA06 5B085 AC04 AE11 BA06 BG02 BG03 BG07

Claims (19)

【特許請求の範囲】
1. 【請求項１】 複数の認証媒体、複数の購入制御端末、
   複数の販売サーバ及び１つの認証課金サーバからなり、
   システムのネットワーク上のコンテンツ購入を含む取引
   を決済を行うためのシステムにおいて、課金を中止する
   ためのディジタルコンテンツ販売における課金中止方法
   において、 前記販売サーバからコンテンツを購入する際の支払手段
   として、前記認証課金サーバで残額を保持するＩＤ認証
   が可能な前記認証媒体を前記購入制御端末に接続し、 前記購入制御端末では、前記認証媒体の認証を前記認証
   課金サーバに要求し、 前記認証課金サーバにおいて、前記認証媒体の認証を行
   い、 前記認証が成功すると、前記認証媒体の媒体ＩＤに対す
   る課金許可情報を生成するための手形署名鍵を生成し
   て、前記購入制御端末に送信し、 前記購入制御端末では、前記販売サーバへの支払時に、
   １回認証中の取引を特定するための識別子（以下、手形
   発行ＩＤと記す）を生成し、 前記認証課金サーバから送付された前記手形署名鍵を使
   用して、前記媒体ＩＤ及び前記手形発行ＩＤを含む取引
   を特定する情報に対して、暗号化や電子署名を含む処理
   を行い、手形署名情報を生成し、 課金先の認証媒体の媒体ＩＤ、前記手形発行ＩＤ、及び
   前記手形署名情報を含む支払のための手形情報を購入要
   求として前記販売サーバに送信し、 前記販売サーバでは、受信した前記手形情報と請求額と
   を課金情報として、前記認証課金サーバに送信し、 前記認証課金サーバで送信された前記課金情報が正当で
   あるかを確認して、正当であれば課金を行い、 前記認証課金サーバが前記販売サーバに対して課金成功
   の応答を行う一連の課金処理を実行する場合に、 前記販売サーバの障害などの理由により、前記課金要求
   がネットワーク上で、遅延、あるいは消失したとき、前
   記購入制御端末が該販売サーバからの応答を待たずに、
   前記認証課金サーバに対して直接、課金中止情報を送出
   し、 前記認証課金サーバで前記手形発行ＩＤを課金中止状態
   にすることにより、前記課金情報が遅延して前記認証課
   金サーバに到着しても、確実に課金を中止することを特
   徴とするディジタルコンテンツ販売における課金中止方
   法。
2. 【請求項２】 前記販売サーバで販売される商品を購入
   するために、前記購入制御端末において、支払のための
   課金情報を生成し、該販売サーバを経由して前記認証課
   金サーバに送信した後に、ネットワーク障害や、該販売
   サーバの障害を含む理由により、該商品の購入を中止す
   るために、 前記購入制御端末が、商品購入に対する課金を中止させ
   るための課金中止情報を生成して、前記認証課金サーバ
   に送信し、 前記課金中止情報が、前記課金情報より先に前記認証課
   金サーバに到着することにより、課金中止とする請求項
   １記載にディジタルコンテンツ販売における課金中止方
   法。
3. 【請求項３】 前記購入制御端末が前記課金情報と前記
   課金中止情報を前記認証課金サーバに送信し、 前記認証課金サーバが、前記課金中止情報を前記課金情
   報より先に受信した場合、該課金中止情報を保持し、該
   課金中止情報に該当する前記課金情報を受信したとき
   に、該課金情報が示す課金を実行せずに中止し、 課金を中止したことを前記購入制御端末に通知する請求
   項２記載のディジタルコンテンツ販売における課金中止
   方法。
4. 【請求項４】 前記課金情報が示す課金を実行せずに、
   中止したことを前記購入制御端末が前記認証課金サーバ
   からの通知により認識し、 前記購入制御端末が管理する認証媒体のバリュー情報を
   確定する請求項３記載のディジタルコンテンツ販売にお
   ける課金中止方法。
5. 【請求項５】 前記購入制御端末が、支払のための課金
   情報と商品購入に対する課金を中止させるための課金中
   止情報を前記認証課金サーバに送信し、 前記認証課金サーバが、前記課金情報を前記課金中止情
   報より先に受信した場合には、課金処理を履行し、課金
   結果を保持し、 前記課金情報に該当する課金中止情報を受信した場合に
   は、該課金情報が示す課金処理が既に実行されてしまっ
   たことを前記購入制御端末に応答し、 前記購入制御端末では、前記認証課金サーバから受信し
   た応答により、認証媒体のバリュー情報を確定する請求
   項１記載のディジタルコンテンツ販売における課金中止
   方法。
6. 【請求項６】 前記認証課金サーバが、前記課金中止情
   報を保持しているとき、 前記課金中止情報に該当する認証媒体の認証状態が破棄
   されたことを契機に、前記課金中止情報、前記手形発行
   ＩＤ、前記手形署名鍵を破棄する請求項１乃至３記載の
   ディジタルコンテンツ販売における課金中止方法。
7. 【請求項７】 コンテンツを購入する際の支払手段とし
   て、認証課金サーバで残額を保持するＩＤ認証が可能な
   複数の認証媒体と、複数の購入制御端末と、複数の販売
   サーバと、１つの認証課金サーバからなるシステムにお
   いて、 前記購入制御端末は、 接続された前記認証媒体の認証を前記認証課金サーバに
   要求する手段と、 前記販売サーバへの支払時に、１回認証中の取引を特定
   するための識別子（以下、手形発行ＩＤと記す）を生成
   する手段と、 前記認証課金サーバから送付された前記手形署名鍵を使
   用して、前記媒体ＩＤ及び前記手形発行ＩＤを含む取引
   を特定する情報に対して、暗号化や電子署名を含む処理
   を行い、手形署名情報を生成する手段と、 課金先の認証媒体の媒体ＩＤ、前記手形発行ＩＤ、及び
   前記手形署名情報を含む支払のための手形情報を購入要
   求として前記販売サーバに送信する手段と、を有し、 前記販売サーバは、 前記購入制御端末から受信した前記手形情報と請求額と
   を課金情報として、前記認証課金サーバに送信する手段
   を有し、 前記認証課金サーバは、 前記認証媒体の認証を行い、該認証が成功すると、前記
   認証媒体の媒体ＩＤに対する課金許可情報を生成するた
   めの手形署名鍵を生成して、前記購入制御端末に送信す
   る手段と、 前記販売サーバから送信された前記課金情報が正当であ
   るかを確認して、正当であれば課金を行う手段と、 を有する、コンテンツ購入を含む取引の決済を行うシス
   テムにおいて、前記販売サーバの障害などの理由によ
   り、課金を中止する認証課金サーバであって、 前記課金要求がネットワーク上で、遅延、あるいは消失
   したとき、前記購入制御端末が該販売サーバからの応答
   を待たずに送出した課金中止情報を受信する課金中止情
   報受信手段と、 前記手形発行ＩＤを課金中止状態にすることにより、前
   記課金情報が遅延して到着しても、確実に課金を中止す
   る課金中止手段とを有することを特徴とする認証課金サ
   ーバ。
8. 【請求項８】 前記課金中止情報を前記課金情報より先
   に受信した場合、該課金中止情報を保持する課金中止情
   報保持手段を有し、 前記課金中止手段は、 前記課金中止情報保持手段に保持されている前記課金中
   止情報に該当する前記課金情報を受信したときに、該課
   金情報が示す課金を実行せずに中止し、該課金を中止し
   たことを前記購入制御端末に通知する課金中止通知手段
   を有する請求項７記載の認証課金サーバ。
9. 【請求項９】 前記課金中止情報保持手段において、前
   記課金中止情報を保持しているとき、該課金中止情報に
   対応する認証媒体の認証状態が破棄されたのを契機とし
   て、該課金中止情報、前記手形発行ＩＤ、前記手形署名
   鍵を破棄する手段を更に有する請求項８記載の認証課金
   サーバ。
10. 【請求項１０】 前記購入制御端末より、前記課金中止
    情報より先に前記課金情報を受信した場合に、課金処理
    を履行し、課金結果を保持する課金手段と、 前記課金処理の履行後に、前記課金情報に該当する課金
    中止情報を受信した場合には、該課金情報が示す課金処
    理が既に実行されてしまったことを前記購入制御端末に
    通知する課金処理通知手段とを有する請求項７記載の認
    証課金サーバ。
11. 【請求項１１】 コンテンツを購入する際の支払手段と
    して、認証課金サーバで残額を保持するＩＤ認証が可能
    な複数の認証媒体と、複数の購入制御端末と、複数の販
    売サーバと、１つの認証課金サーバからなるシステムに
    おいて、 前記購入制御端末は、 接続された前記認証媒体の認証を前記認証課金サーバに
    要求する手段と、 前記販売サーバへの支払時に、１回認証中の取引を特定
    するための識別子（以下、手形発行ＩＤと記す）を生成
    する手段と、 前記認証課金サーバから送付された前記手形署名鍵を使
    用して、前記媒体ＩＤ及び前記手形発行ＩＤを含む取引
    を特定する情報に対して、暗号化や電子署名を含む処理
    を行い、手形署名情報を生成する手段と、 課金先の認証媒体の媒体ＩＤ、前記手形発行ＩＤ、及び
    前記手形署名情報を含む支払のための手形情報を購入要
    求として前記販売サーバに送信する手段と、を有し、 前記販売サーバは、 前記購入制御端末から受信した前記手形情報と請求額と
    を課金情報として、前記認証課金サーバに送信する手段
    を有し、 前記認証課金サーバは、 前記認証媒体の認証を行い、該認証が成功すると、前記
    認証媒体の媒体ＩＤに対する課金許可情報を生成するた
    めの手形署名鍵を生成して、前記購入制御端末に送信す
    る手段と、 前記販売サーバから送信された前記課金情報が正当であ
    るかを確認して、正当であれば課金を行う手段と、 を有する、コンテンツ購入を含む取引の決済を行うシス
    テムにおいて、前記販売サーバの障害などの理由によ
    り、課金を中止する際に、課金中止要求を行う購入制御
    端末であって、 前記販売サーバの障害などの理由により、前記課金要求
    がネットワーク上で、遅延、あるいは消失したとき、該
    販売サーバからの応答を待たずに課金中止情報を前記認
    証課金サーバに送信する課金中止要求発行手段と、 前記認証課金サーバから前記課金中止情報に対する応答
    を受信し、該応答に基づいて、前記認証媒体のバリュー
    情報を確定するバリュー情報確定手段と、 を有することを特徴とする購入制御端末。
12. 【請求項１２】 前記バリュー情報確定手段は、 前記認証課金サーバから課金を実行したことを示す応答
    を受信した場合には、該応答に基づいて、前記認証媒体
    のバリュー情報を確定する手段を含む請求項１１記載の
    購入制御端末。
13. 【請求項１３】 コンテンツを購入する際の支払手段と
    して、認証課金サーバで残額を保持するＩＤ認証が可能
    な複数の認証媒体と、複数の購入制御端末と、複数の販
    売サーバと、１つの認証課金サーバからなるシステムの
    ネットワーク上のコンテンツ購入を含む取引の課金を行
    う際に、販売サーバの障害などの理由により、前記課金
    要求がネットワーク上で、遅延、あるいは消失した場合
    に課金を中止するために、該認証課金サーバが実行する
    課金中止プログラムであって、 前記課金要求がネットワーク上で、遅延、あるいは消失
    したとき、前記購入制御端末が該販売サーバからの応答
    を待たずに送出した課金中止情報を受信する課金中止情
    報受信プロセスと、 前記手形発行ＩＤを課金中止状態にすることにより、前
    記課金情報が遅延して到着しても、確実に課金を中止す
    る課金中止プロセスとを有することを特徴とする課金中
    止プログラム。
14. 【請求項１４】 前記課金中止情報を前記課金情報より
    先に受信した場合、該課金中止情報を記憶手段に格納す
    る課金中止情報格納プロセスを有し、 前記課金中止プロセスは、 前記記憶手段に保持されている前記課金中止情報に該当
    する前記課金情報を受信したときに、該課金情報が示す
    課金を実行せずに中止し、該課金を中止したことを前記
    購入制御端末に通知する課金中止通知プロセスを有する
    請求項１３記載の課金中止プログラム。
15. 【請求項１５】 前記記憶手段に、前記課金中止情報が
    格納されているとき、該課金中止情報に対応する認証媒
    体の認証状態が破棄されたのを契機として、該課金中止
    情報、前記手形発行ＩＤ、前記手形署名鍵を破棄するプ
    ロセスを更に有する請求項１４記載の課金中止プログラ
    ム。
16. 【請求項１６】 前記購入制御端末より、前記課金中止
    情報より先に前記課金情報を受信した場合に、課金処理
    を履行し、課金結果を保持する課金プロセスと、 前記課金処理の履行後に、前記課金情報に該当する課金
    中止情報を受信した場合には、該課金情報が示す課金処
    理が既に実行されてしまったことを前記購入制御端末に
    通知する課金処理通知プロセスとを有する請求項１４記
    載の課金中止プログラム。
17. 【請求項１７】 コンテンツを購入する際の支払手段と
    して、認証課金サーバで残額を保持するＩＤ認証が可能
    な複数の認証媒体と、複数の購入制御端末と、複数の販
    売サーバと、１つの認証課金サーバからなるシステムの
    ネットワーク上のコンテンツ購入を含む取引の課金を行
    う際に、販売サーバの障害などの理由により、前記課金
    要求がネットワーク上で、遅延、あるいは消失した場合
    に課金を中止するために、該購入制御端末が実行する課
    金中止プログラムであって、 前記販売サーバの障害などの理由により、前記課金要求
    がネットワーク上で、遅延、あるいは消失したとき、該
    販売サーバからの応答を待たずに課金中止情報を前記認
    証課金サーバに送信する課金中止要求発行プロセスと、 前記認証課金サーバから前記課金中止情報に対する応
    答、または、課金済でああることを示す応答を受信し、
    該応答に基づいて、前記認証媒体のバリュー情報を確定
    するバリュー情報確定プロセスと、 を有することを特徴とする課金中止プログラム。
18. 【請求項１８】 コンテンツを購入する際の支払手段と
    して、認証課金サーバで残額を保持するＩＤ認証が可能
    な複数の認証媒体と、複数の購入制御端末と、複数の販
    売サーバと、１つの認証課金サーバからなるシステムの
    ネットワーク上のコンテンツ購入を含む取引の課金を行
    う際に、販売サーバの障害などの理由により、前記課金
    要求がネットワーク上で、遅延、あるいは消失した場合
    に課金を中止するために、該認証課金サーバが実行する
    課金中止プログラムを格納した記憶媒体であって、 前記請求項１３乃至前記請求項１６のプログラムを格納
    したことを特徴とする課金中止プログラムを格納した記
    憶媒体。
19. 【請求項１９】 コンテンツを購入する際の支払手段と
    して、認証課金サーバで残額を保持するＩＤ認証が可能
    な複数の認証媒体と、複数の購入制御端末と、複数の販
    売サーバと、１つの認証課金サーバからなるシステムの
    ネットワーク上のコンテンツ購入を含む取引の課金を行
    う際に、販売サーバの障害などの理由により、前記課金
    要求がネットワーク上で、遅延、あるいは消失した場合
    に課金を中止するために、該購入制御端末が実行する課
    金中止プログラムを格納した記憶媒体であって、 前記請求項１７記載のプログラムを格納したことを特徴
    とする課金中止プログラムを格納した記憶媒体。