情報料の課金処理方法及び課金代行システム
【課題】 有料情報の提供者に代わって利用者から情報料の課金とその回収を行う課金代行システムを提供する。
【解決手段】 情報サーバ２と公衆通信回線を通じて有料情報を取得する特定の利用者側のクライアント３との間に論理的に介在するシステムであり、課金処理サーバ１０、請求処理サーバ１１、及び回収処理サーバ１２を含んで構成する。課金処理サーバ１０は、クライアント３からの情報要求の受信を契機に情報サーバ２から有料情報と課金額情報とを取得して情報要求元のクライアント３に送出するとともに、課金額情報に基づいて利用者の課金額を決定する。請求処理サーバ１１は、課金処理サーバ１０で決定した課金額を利用者の公衆通信回線使用額に重畳させる。回収処理サーバ１２は、利用者から料金が回収されたときに、回収額から課金額を抽出して有料情報の提供者毎に集計して振り込む処理を行う。
【解決手段】 情報サーバ２と公衆通信回線を通じて有料情報を取得する特定の利用者側のクライアント３との間に論理的に介在するシステムであり、課金処理サーバ１０、請求処理サーバ１１、及び回収処理サーバ１２を含んで構成する。課金処理サーバ１０は、クライアント３からの情報要求の受信を契機に情報サーバ２から有料情報と課金額情報とを取得して情報要求元のクライアント３に送出するとともに、課金額情報に基づいて利用者の課金額を決定する。請求処理サーバ１１は、課金処理サーバ１０で決定した課金額を利用者の公衆通信回線使用額に重畳させる。回収処理サーバ１２は、利用者から料金が回収されたときに、回収額から課金額を抽出して有料情報の提供者毎に集計して振り込む処理を行う。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、例えばインターネットのようなコンピュータ通信網を通じて提供される有料情報についての情報料の課金及びその回収を情報提供者に代わって行う課金代行システムに関する。
【０００２】
【従来の技術】競馬情報、カラオケ・楽曲データ、その他の有料情報をコンピュータ通信網を通じて利用者に提供するサービス提供システムが知られている。このようなサービス提供システムでは、通常、個々の有料情報毎に単位時間当たりの利用料金を設定しておき、利用者が利用した時間に応じて課金を行っている。課金額の回収はクレジット方式が一般的である。すなわち、情報提供者から利用者に対して請求書を発行するとともに、請求書に記載された額の料金をクレジットカードについて登録された預金口座から引き落とすことによって行われている。
【０００３】
【発明が解決しようとする課題】ところで、近年は、有料情報の提供媒体として、ＴＣＰ／ＩＰプロトコルに基づくネットワーク（インターネット）を用いたサービス提供システムが増大している。しかし、インターネットを媒体とし、有料情報の利用料金の回収をクレジットカードで行う形態のサービス提供システムでは以下のような問題があった。
【０００４】（１−１）クレジット方式では、１０円、１００円といった単位での少額の課金をするための手法が確立されていない。少額課金手法それ自体については、プリペイド方式によって実現しているサービス提供システムはあるが、そのためにはプリペイド方式を実現するために専用のソフトウェアを端末にインストールする必要があり、汎用のブラウザをそのまま利用することができない。
【０００５】（１−２）インターネットによる取引後の決済では、クレジット番号を事前に登録したり、決済毎にクレジットカード番号を入れたり、あるいは、別途情報提供者からの請求書によって支払うこと等が行われていた。しかし、いずれの場合も、利用者がクレジットカードを所有していなければ利用することができない。また、オンラインでクレジット番号を流すということについても、利用者の側にセキュリティ上の不安を与える。
【０００６】（１−３）多数の有料情報から利用者が希望する情報を索出して提供する形態のシステムでは、情報提供者が自由に有料情報を入れ替えたり、必要な統計情報などを自由にとることが困難であった。そのため、情報を提供するＷＷＷサーバは、情報提供者自身の都合で運用したいという要望があった。
【０００７】（１−４）インターネットでの有料情報のダウンロードの問題は、きちんとクライアントの端末まで届いたかどうかを保障できない点にある。そのため、従来、情報提供者によっては、同一有料情報について再度アクセスがあった場合に一定時間の再課金を行わないようにしているものがあった。しかし、個々のコンテンツによって再課金のタイミングを制御することが困難であった。例えば、ソフトウェアなどは、必ずしも長いタイミングで再課金をしなくともよいし、逆にオンラインゲームなどは毎回課金したいという要望があり、これらを一元的に管理することが困難であった。
【０００８】（１−５）物資購買や映像提供、案内情報提供等のように、利用者毎に課金額が異なる有料情報を提供するシステムでは、個々の有料情報に対し、ユーザ毎に課金額を変えたり、非課金時間を設定することが難しかった。
【０００９】そこで、本発明の課題は、上記従来の問題点を一挙に解消することができる情報料の課金処理方法を提供することにある。本発明の他の課題は、本発明の方法の実施に適した課金代行システムを提供することにある。
【００１０】
【課題を解決するための手段】上記課題を解決する本発明の課金処理方法は、有料情報を提供する情報提供装置と公衆通信回線を通じて前記有料情報を取得する利用者側の端末装置との間にプロキシサーバを介在させ、前記プロキシサーバにおいて前記端末装置が送出した情報要求に基づき該当する情報提供装置を特定し、利用者が要求した有料情報とその有料情報の当該利用者による利用に対して課金すべき金額情報とを前記特定した情報提供装置より取得するとともに、前記取得した有料情報を前記端末装置に送出する際に前記取得した金額情報に基づいて当該利用者への課金額を決定し、決定した課金額を、請求対象となる前記利用者の公衆通信回線使用額と統合することを特徴とする。この方法では、プロキシ（ｐｒｏｘｙ）サーバが情報提供装置の代わりに機能するので、端末装置からは、あたかも情報提供装置に直接アクセスしたかのようにみえ、その際に、情報料に対する課金が自動的になされるようになる。また、課金額は、公衆通信回線使用額と統合されるので、利用者による料金支払いが１回で済むようになる。
【００１１】本発明の課金処理方法では、また、予め前記プロキシサーバで前記有料情報の格納先アドレスを保持しておき、前記情報要求が前記端末装置から送出されたときに、前記プロキシサーバが前記情報要求に含まれる有料情報の格納先アドレスを特定して当該有料情報を格納した情報提供装置にアクセスするようにする。このようにすれば、端末装置は、有料情報を格納した情報提供装置を特定しなくとも、当該有料情報にアクセスできるようになる。
【００１２】前記課金額は、前記プロキシサーバが取得した有料情報を前記端末装置に最初に送出した時点で決定し、同一利用者に対する指定時間内の同一有料情報の送出については非課金扱いとする。これは、公衆通信回線を介して有料情報を提供する場合の、情報サイズやすべての有料情報が利用者にわたったかを確認することの困難性に鑑みた処理であり、同一利用者が直ちに同一有料情報の要求を発した場合は、前回の有料情報が利用者にわたらなかったと推定される点を考慮したものである。
【００１３】上記他の課題を解決する本発明の課金代行システムは、有料情報を提供する情報提供装置と公衆通信回線、例えばＴＣＰ／ＩＰプロトコルに基づくネットワーク回線を通じて前記有料情報を取得する利用者側の端末装置との間に論理的に介在するもので、前記端末装置が送出した情報要求に基づいて該当する情報提供装置を特定して利用者が要求した有料情報とその有料情報の当該利用者による利用に対して課金すべき金額情報とを前記特定した情報提供装置より取得する代理取得手段、取得した有料情報を前記端末装置に送出するとともに前記取得した金額情報に基づいて当該有料情報に対する利用者の課金額を決定する課金額決定手段、前記決定した課金額を前記利用者の公衆通信回線使用額と統合して請求処理を行う請求処理手段、を有することを特徴とする。
【００１４】上記課金代行システムでは、必要に応じて、前記端末装置から送出された情報要求に含まれる有料情報を識別して当該有料情報の格納先アドレスを特定するアドレス特定手段をさらに備え、生成された格納先アドレスに基づいて前記有料情報を取得するように構成される。
【００１５】なお、前記課金額決定手段は、前記取得した有料情報の最初の送出時点で前記課金額を決定し、同一利用者に対する指定時間内の同一有料情報の送出については非課金処理を行うように構成する。
【００１６】本発明の他の課金代行システムは、暗号化されて放送形式で提供される有料情報を復号させる復号鍵の登録機関と公衆通信回線を通じて前記復号鍵を取得する利用者側の端末装置との間に論理的に介在するもので、前記端末装置より受信した復号鍵要求に基づいて前記登録機関から復号鍵とその復号鍵の当該利用者による利用に対して課金すべき金額情報とを取得する代理取得手段、取得した復号鍵を前記端末装置に送出するとともに前記取得した金額情報に基づいて当該利用者への課金額を決定する課金額決定手段、前記決定した課金額を前記利用者の公衆通信回線使用額と統合して請求処理を行う請求処理手段、を有することを特徴とする。
【００１７】上記他の課金代行システムにおいて、前記課金額決定手段は、前記取得した復号鍵を前記端末装置に送出した時点で前記課金額を決定し、同一利用者に対する指定時間内の同一復号鍵の送出については非課金処理を行うように構成される。
【００１８】上記各課金代行システムにおける好ましい形態として、さらに下記の要素のいずれか、あるいは双方を適宜設ける。
（１）前記統合された額の料金が回収されたときに回収額から前記課金額を抽出して前記有料情報の提供者毎に集計して振り分ける回収処理手段。
（２）前記情報要求の受信を契機に利用者認証を行い、認証結果が正常の場合は当該利用者について登録された情報取得の権限情報を自サーバの権限情報に置換する権限情報置換手段。
【００１９】なお、各課金代行システムが具備する前記代理取得手段は、利用者の識別情報を前記情報提供装置に通知して当該利用者について情報提供者が定めた前記金額情報を取得するように構成される。また、前記代理取得手段、前記課金額決定手段、前記請求処理手段、前記アドレス特定手段、前記回収処理手段、前記権限情報置換手段は、少なくとも一つのプロキシサーバで構成される。
【００２０】
【発明の実施の形態】以下、図面を参照して本発明の実施の形態を詳細に説明する。
（第１実施形態）図１は、本発明の課金代行システムを適用したサービス提供システムの構成図である。このサービス提供システムは、本発明の課金代行システム１と、情報提供装置として機能する不特定多数の情報サーバ２と、有料情報にアクセスする多数の端末装置（以下、クライアント）３とがサービス提供網Ｌ１に接続されている。このサービス提供網Ｌ１はＴＣＰ／ＩＰプロトコルに基づくインターネットＬ２とリンクされており、インターネットＬ２には、情報サーバ２とクライアント３とが接続されている。各クライアント３は、汎用のＨＴＭＬ（HyperText Markup Language）ブラウザを通じてサービス提供網Ｌ１及びインターネットＬ２に接続されたどの情報サーバ２にもアクセスできるようになっている。
【００２１】本実施形態において課金対象となる有料情報は、情報提供者によって予め情報サーバ２に登録され、利用者の要求によりＨＴＴＰ（HyperText Transfer Protcol）を用いて特定のクライアント３に送出する情報である。この有料情報には、ＨＴＭＬデータ、バイナリ，音声，画像等の情報、コンピュータ・グラフィック等があるが、特に限定しない。また、クライアント３から送出される情報要求は、リクエストライン（ＨＴＴＰバージョン／リクエストＵＲＬ（Uniform Resource Locator）／メソッド）、ジェネラルヘッダ、リクエストヘッダ（利用者名、パスワードを含む）、エンティティヘッダ、エンティティボディの構造からなるものとする。
【００２２】本実施形態では、クライアント３からの情報要求に含まれる有料情報に基づく当該有料情報の格納場所を表す格納先アドレスの特定機能を課金代行システム１にもたせることで、各クライアント３からはこのシステム１が一つの巨大な情報サーバ群として見え、一方、個々の情報サーバ２からはクライアント３として見えるようにする。また、利用者による有料情報の利用に対してクレジット方式によらない少額課金を可能にする。さらに、個々の情報サーバ２は、情報提供者自身が独自に管理できるようにする。そのため、複数のプロキシサーバ、例えば課金処理サーバ１０，請求処理サーバ１１、回収処理サーバ１２その他のサーバを内部ネットワークで接続し、いわゆるアプリケーション・ゲートウエイとして機能するように課金代行システム１を構成している。
【００２３】課金処理サーバ１０は、図２に示すように、クライアント３との間の接続インタフェースとなるクライアント接続部１０１と、情報サーバ２との間の接続インタフェースとなる情報サーバ接続部１０２とを有する。クライアント接続部１０１でサポートするプロトコルは、ＨＴＴＰ、ＳＳＬ（Secure Sockets Layer）、ＴＣＰ（Transmission Control Protcol）、ＩＰ（Internet Protcol）である。一方、情報サーバ接続部１０２でサポートするプロトコルは、ＨＴＴＰ、ＳＳＬ、ＴＣＰ、ＩＰである。
【００２４】課金処理サーバ１０は、また、クライアント３より受信した情報要求のリクエストヘッダを解析して利用者認証を行う認証処理部１０３、利用者権限情報（パスワード等）を自サーバについて登録された権限情報に置換する権限情報置換部１０４、情報要求のリクエストラインの内容を識別して該当する有料情報を特定する情報要求受付部１０５、上記アドレス特定機能の一例として、情報要求に含まれる有料情報の指定情報または格納先情報を該当する情報サーバ２に存在する情報のアドレス（サーバ名／情報パス）に変換するアドレス変換機能を実現するサーバ管理部１０６、変換されたアドレスの情報サーバ２に対して自サーバの権限情報でアクセスして利用者が要求した有料情報の代理要求とその有料情報に対する課金情報の要求を行う情報代理要求部１０７を有している。
【００２５】サーバ管理部１０６による上記アドレス変換機能は、以下のようにして実現する。すなわち、予め複数、好ましくはすべての情報サーバ２についての、有料情報の格納先アドレスを保持したアドレステーブルをサーバ管理部１０内に形成するとともに、情報要求に含まれる情報の種別を判定する機能をサーバ管理部１０内に設ける。そして、この情報種別の判定結果とアドレステーブルの保持内容に基づいてその有料情報が存在する情報サーバとその格納先アドレスとを特定し、特定した格納先アドレスから該当する有料情報を取得する。このようにすることで、クライアント３からの情報要求の電文フォーマットがどのようなものであっても、情報種別が判定できれば、課金処理サーバ１０から必要な有料情報にアクセスできるようになる。また、クライアント３は、所望の有料情報の格納先アドレスを正確に知らなくとも当該有料情報を取得できるようになる。
【００２６】課金処理サーバ１０は、また、代理要求に応じて情報サーバ２から送られた有料情報を受け付ける情報応答受付部１０８、受け付けた有料情報を情報要求元のクライアント３へ送信する情報代理応答部１０９、上記有料情報の送出時点でクライアント３を操作する利用者についての課金額を決定する課金額決定部１１０、決定した課金額についての所要処理を行う課金処理部１１１、及び、課金情報を利用者毎に蓄積する課金情報データベース（ＤＢ）１１２を有している。課金情報ＤＢ１１２に蓄積された課金情報は、後述の請求処理サーバ１１において利用される。なお、上記機能ブロック１０１〜１１１及び課金情報ＤＢ１１２は、サーバ本体が所定のプログラムを読み込んで実行することによって形成されるものである。
【００２７】課金処理サーバ１０における処理手順は、図３に示すとおりである。すなわち、クライアント３からの情報要求の受信を契機に、認証処理部１０３において利用者認証を行う（ステップＳ３０１：Yes、Ｓ３０２）。情報要求に誤った利用者ＩＤやパスワードが設定されている場合は、情報代理応答部１０９を通じてクライアント３に個別的に利用者ＩＤまたはパスワード（あるいは両方）の入力を促す。認証が正当であった場合は（ステップＳ３０３：Yes）、情報要求受付部１０５で情報要求を受け付け、これをサーバ管理部１０６に送る。サーバ管理部１０６は、情報要求に含まれる情報種別、または情報の格納先アドレス（クライアント３側で指示されてきた場合）を判定し、上記アドレス変換機能を使用してその有料情報が存在する情報サーバ２を特定する（ステップＳ３０４）。そして、情報代理要求部１０７を通じて、特定した情報サーバに自己の権限情報（利用者の権限情報を置換したもの）でアクセスして利用者の識別情報と有料情報の格納先アドレスとを通知する。情報応答受付部１０８は、その利用者に対して情報提供者が自由に設定した課金情報を取得する（ステップＳ３０５）。また、情報代理要求部１０７を通じて情報サーバ２に有料情報の代理要求を送信し、情報応答受付部１０８を通じてその有料情報を取得するとともに（ステップＳ３０６）、情報代理応答部１０９を通じて、取得した有料情報をクライアント３に送る。つまり、代理応答を行う（ステップＳ３０７）。なお、有料情報の代理要求は、利用者の識別情報や格納先アドレスの通知と同時に情報サーバ２に送信し、課金情報と有料情報とを同時期に取得するようにしてもよい。
【００２８】情報代理応答部１０９が、クライアント３に対する有料情報の送信を開始すると、課金額決定部１１０は、その有料情報について既に課金済であるかどうかを課金情報ＤＢ１１２を参照して判定する。課金済であるが、所定の規定時間、例えば情報サーバ２がその有料情報に対して設定した時間内である場合は、前回の代理応答が正常にクライアント３に届かなかったとみなして、非課金とする（ステップＳ３０８：Yes、Ｓ３０９：Yes）。なお、代理応答は、１情報要求に対して複数ブロック発生する場合があるが、この場合は、最初のブロックが規定時間内であれば、最終ブロックが規定時間を越える場合であっても非課金とする。
【００２９】一方、ステップＳ３０８において課金済みでなかった場合、あるいは課金済みであるが、規定時間を経過している場合、課金額決定部１１０は、代理応答を開始した時点、複数ブロックの場合は最初のブロックをクライアント３に向けて送出した時点で課金額を決定する（ステップＳ３０８：No、Ｓ３１０）。このようにすれば、有料情報がきちんとクライアント３まで届いたかどうかが保障できないという問題を解消することができる。
【００３０】課金額が決定した場合、課金処理部１１１は、その利用者についての課金額を課金情報ＤＢ１１２に蓄積した後、情報サーバ２に対して課金結果通知を行う（ステップＳ３１１，Ｓ３１２）。なお、予め情報サーバ２から課金結果通知が不要とされている場合は、情報サーバ２への課金結果通知が省略される。
【００３１】なお、図示を省略してあるが、課金処理サーバ１０では、課金関連の情報を事後的に解析するため、請求処理サーバ１１及び回収処理サーバ１２から情報料課金ジャーナルと課金結果通知ファイルとを利用者毎に採取する。情報料課金ジャーナルは利用者毎の課金結果を記録するもので、代理応答の先頭ブロック（ｈｔｔｐヘッダ）を正常に送出した時点で採取する。課金結果通知ファイルは、利用者毎に情報サーバ２に対する課金結果通知と課金額不正通知のいずれかを行うための情報を記録するもので、課金額通知は、クライアント３に対して代理応答の先頭ブロック（ｈｔｔｐヘッダ）を送出した時点で採取する。課金額不正通知は、不正な課金額応答を受け取った時点で採取する。
【００３２】次に、請求処理サーバ１１について説明する。請求処理サーバ１１は、課金処理サーバ１０において決定された利用者毎の課金額の累計額を当該利用者の公衆通信回線使用額と統合して請求処理を行う。その具体的な構成例は図４に示すとおりであり、サーバ本体が所定のコンピュータプログラムを読み込んで実行することによって形成される、コマンド解析部２０１、ステータス管理部２０２、ＴＩＤ（Telephone ID）管理部２０３、課金メータ処理部２０４を具備している。なお、ここでは、利用者毎の公衆通信回線使用額、つまり電話料金は、図示しない料金管理機関側の料金管理システムで一括管理し、各利用者に対する実際の請求業務は、当該料金管理システムにおいて行うものとする。
【００３３】コマンド解析部２０１は、入力されたコマンドの内容を解析し、解析結果をステータス管理部２０２と課金メータ処理部２０４に通知する。ステータス管理部２０２は、本実施形態の課金代行システム１全体の状態（ステータス）を監視しており、コマンド解析部２０１による解析の結果、入力されたコマンドが請求処理の実行コマンドである場合は、当該コマンドに課金処理中を表すフラグをたて、当該コマンドの実行終了を契機にそのフラグを解除する。課金処理中のフラグがたっている場合、本システムは、利用者に対してサービス提供は行うが（ジャーナルで記録しておく）、利用者の新たな登録や削除を禁止させるようにする。ＴＩＤ管理部２０３は、利用者名と加入者電話番号（以下、電話番号）とをリンクさせて管理している。なお、ＴＩＤ管理部２０３を別途設けずに、前述の課金情報ＤＢ１１２を用いて利用者の電話番号を特定できるようにしてもよい。課金メータ処理部２０４は、課金情報ＤＢ１１２における利用者毎の課金額を集計して課金メータを作成し、作成した課金メータに対応する加入者電話番号をＴＩＤ管理部２０３から索出するとともに、当該利用者についての課金メータと情報提供者毎の課金内訳を料金管理システムに通知する。通知に際しては、料金管理システム用の電文フォーマットに変換する。この課金メータ及び課金内訳は、利用者に対する請求内容を表すものであり、従前の領収済み通知に対応するものである。
【００３４】この請求処理サーバ１１における処理手順は図５に示すとおりである。すなわち、図示しないデータ入力装置を通じて請求処理を要求するコマンドが入力されると、コマンド解析部２０１がその内容を解析し、請求処理の開始をステータス管理部２０２及び課金メータ処理部２０４に通知する（ステップＳ５０１）。ステータス管理部２０２は、この通知の受領を契機に「課金処理中」を表すフラグをたてる（ステップＳ５０２）。課金メータ処理部２０４は、一の利用者について、前回の課金メータを作成した時点以降今期の基準時点まで（以下、基準期間）の課金額を課金処理サーバ１０（課金情報ＤＢ１１２）から読み出し（ステップＳ５０３）、その利用者の基準期間内の課金メータを作成する（ステップＳ５０４）。その後、ＴＩＤ管理部２０３を検索して利用者の加入者電話番号を特定し、当該利用者の課金メータと情報提供者毎の内訳を料金管理システムに通知する（ステップＳ５０５）。加入者電話番号の特定は、例えば、課金情報ＤＢ１１２で管理されている利用者ログ、あるいは利用者ＩＤから利用者名を特定し、その後、特定した利用者名に対応する加入者電話番号をＴＩＤ管理部２０３から索出することによって行う。前述のようにＴＩＤ管理部２０３を設けずに課金情報ＤＢ１１２のみで利用者の電話番号を管理する場合は、利用者ＩＤに当該利用者の電話番号を履歴として保存しておくことで、直ちに電話番号を特定できるようになる。料金管理システムへの通知後は、その利用者についての課金情報ＤＢ１１２内の課金額をリセットする（ステップＳ５０６）。この処理を他の利用者について繰り返し（ステップＳ５０７）、すべての利用者についての請求処理が終了した場合は、ステータス管理部２０２にその旨を通知して課金処理中のフラグを解除させる（ステップＳ５０８）。このようにして、有料情報についての課金額と電話料金とを一元管理できるようにする。
【００３５】次に、回収処理サーバ１２について説明する。回収処理サーバ１２は、電話料金に課金額が重畳された額の料金が利用者から回収されたときに、回収代行処理を行う。前提として、上記料金管理システムにおいて、回収された額から電話料金が差し引かれた額、つまり先に通知した課金メータに対応する額（以下、回収額）が、通知ないし振り込まれるものとする。
【００３６】この回収処理サーバ１２は、図６に示すように、料金管理システムとの間に接続されたインタフェース部３０１、情報提供者管理部３０２、回収額集計部３０３、図示しない金融機関による振込システムに接続された振込処理部３０４とを具備している。これらの機能ブロック３０１〜３０４は、サーバ本体が所定のプログラムを読み込んで実行することによって形成されるものである。インタフェース部３０１は、料金管理システムから回収通知及び回収額を受領する。情報提供者管理部３０３には、回収代行を希望する情報提供者のＩＤ、振込口座番号、及び振込条件等が登録されている。回収額集計部３０４は、各利用者の回収額を情報提供者毎に集計する。振込処理部３０４は、振込システムにアクセスして情報提供者毎の振込口座番号への自動振込処理を行う。
【００３７】この回収処理サーバ１２における処理手順は図７のとおりである。まず、インタフェース部３０１において料金管理システムから利用者の回収額を取得する（ステップＳ７０１）。回収額集計部３０２は、回収額を情報提供者毎に集計するとともに（ステップＳ７０２）、各情報提供者のＩＤを通じて振込口座番号や振込条件を特定し（ステップＳ７０３）、この特定した振込口座番号や振込条件にしたがって、上記集計した額の料金を振り込むための処理を行う（ステップＳ７０４）。他の情報提供者についてステップＳ７０３及びＳ７０４の処理を繰り返し、すべての情報提供者に対する振込処理が終了した時点で回収処理を終える（ステップＳ７０４）。
【００３８】なお、以上の処理手順は、請求に対してすべての利用者が遅延なく料金を支払い、回収がなされた場合の例である。一部の利用者による回収が遅延した場合は、以下のようにして調整をとる。この場合は、料金管理システムから回収不能であった利用者ＩＤとその利用者の課金メータに対応する額の通知を受ける。この通知に基づいて、回収額集計部３０２は、回収不能であった利用者の課金額及びその内訳を解析し、回収不能額を今期の基準期間の回収額から差し引いて上記情報提供者毎の集計を行う。一方、次の基準期間に上記回収不能が回収された旨の通知を料金管理システムから通知された場合は、回収された額をその基準期間内の本来の回収額に上乗せして上記情報提供者毎の集計を行う。
【００３９】上記実施形態では、利用者に対する領収済み通知を、請求処理サーバ１１における課金内訳で代用した場合の例を示したが、これに代えて、回収処理サーバ１２に領収済み通知処理部を設け、回収額を各情報提供者の振込口座番号に振り込んだ時点で、紙媒体、あるいは通信媒体を通じて領収済み通知を各利用者に対して発行するようにしてもよい。
【００４０】（第２実施形態）図８は、上記課金代行システム１を適用した他のサービス提供システムの実施の形態を示す図である。ここでは、情報提供者が有料情報を暗号化して放送局６から有料放送として提供する場合を想定している。暗号化有料情報を復号させる復号鍵は、情報提供者が予め情報料の金額情報と共に鍵センター７に登録しておく。利用者は、公衆通信回線、例えばインターネットＬ２に接続されたクライアント３の汎用ブラウザを通じて鍵センター７から復号鍵を取得し、この復号鍵を用いて有料放送を復号する。復号鍵は、情報提供者が定めた所定時間のみ有効となるようにし、この復号鍵の配布に対して課金されるようにする。
【００４１】課金代行システム１は、第１実施形態と同様、課金処理サーバ１０、請求処理サーバ１１、回収処理サーバ１２を備えており、有料情報が復号鍵となる以外は、ほぼ同様の処理を行うものである。すなわち、図８に示すように、クライアントからの復号鍵要求（１）の受信を契機に鍵センター７にアクセスして課金額確認を行うとともに（２）、復号鍵を取得する（３）。取得した復号鍵をクライアント３に配布し（４）、同時に課金額の決定を行う。また、料金管理機関７に対して利用者毎の課金累計額の通知を行う（５）。振込システムに連動する料金管理機関７において利用者からの料金回収が確認された場合は（７）、情報提供者毎の情報料を集計し（８）、指定された口座への振り込み処理を行う（９）。
【００４２】なお、第１及び第２実施形態は一例であって、これ以外の同種のサービス提供システム、例えばインターネットによる競馬情報、カラオケ・楽曲データ、その他の有料情報の提供サービスシステムについても本発明の課金代行システム１を利用することができる。
【００４３】このように、本発明の課金代行システム１では、プロキシサーバに課金回収機能を盛り込んだので、従来型システムでは不可能であった汎用のブラウザを用いたクレジットカードによらないインターネット上の少額課金方式が実現できるようになった。
【００４４】また、有料情報に課される料金を利用者の通常の電話回線使用料と統合して一元的に管理できるようにしたので、第三者によるクレジット情報の悪用を防止することが可能になり、利用者の不安を払拭できるようになった。情報提供者にとっても、情報料が自動的に指定口座に振り込まれるので、請求書や領収済通知を利用者毎に発行する作業負担がなくなった。
【００４５】また、クライアント３からは、あたかも一つのＷＷＷサーバに情報を要求しているように見えるシステム構成にしたので、情報提供者が情報サーバ２に自由に有料情報を入れ替えたり、情報利用頻度等の必要な統計情報を自由にとることが容易となり、情報提供者自身による情報サーバ２の運用に柔軟性をもたせることができるようになった。
【００４６】また、有料情報をクライアント３に最初に送出した時点で情報提供者側からの指示に基づく課金額を決定し、同一利用者に対する規定時間（情報提供者が指定）内の同一有料情報の送出については非課金処理を行うようにしたので、例えばインターネットでの有料情報のダウンロードが正常に終了したかどうかをその都度確認する必要がなくなり、また、有料情報毎の再課金のタイミングを緻密に制御する必要がなくなる。これにより、有料情報の種類毎の課金と情報保障の双方を同時に実現できるようになった。
【００４７】さらに、従来型システムでは、同一の有料情報は固定料金であったため、同一サイトに複数種類の有料情報が存在する場合に、個々の有料情報に対して利用者毎に課金額を変えたり、非課金時間を設定することは難しかったが、本発明の課金代行システムでは、情報サーバ２に対して利用者ＩＤを通知し、情報サーバ２からその利用者に対して課金すべき金額情報を応答で返してもらうことで課金額を決定するようにしたので、例えばアクセス頻度の高い利用者や展示会等で利用する者に対しては割引率を高めに設定した課金を行う、というフレキシブルな課金体系を採用することが可能になった。
【００４８】
【発明の効果】以上の説明から明らかなように、本発明の課金代行システムによれば、例えばＴＣＰ／ＩＰプロトコルを採用したネットワーク回線を通じて行われる有料情報の情報料の課金や回収の代行を、利用者及び情報提供者の双方の便宜を図りながら適切に行えるようになり、従来の問題点が一挙に解消される。これにより、この種のサービス提供システムの普及に寄与することができる。
【図面の簡単な説明】
【図１】本発明の課金代行システムを適用したサービス提供システムの実施の一形態を示す構成図。
【図２】この実施形態による課金処理サーバの機能ブロック図。
【図３】課金処理サーバにおける処理手順説明図。
【図４】請求処理サーバの機能ブロック図。
【図５】請求処理サーバにおける処理手順説明図。
【図６】回収処理サーバの機能ブロック図。
【図７】回収処理サーバにおける処理手順説明図。
【図８】本発明の課金代行システムを適用した他のサービス提供システムの実施の一形態を示す説明図。
【符号の説明】
１ 課金代行システム
２ 情報サーバ
３ クライアント
６ 放送局
７ 鍵センター
８ 料金管理機関
１０ 課金処理サーバ
１１ 請求処理サーバ
１２ 回収処理サーバ
１０１ クライアント接続部
１０２ 情報サーバ接続部
１０３ 認証処理部
１０４ 権限情報置換部
１０５ 情報要求受付部
１０６ サーバ管理部
１０７ 情報代理要求部
１０８ 情報応答受付部
１０９ 情報代理応答部
１１０ 課金額決定部
１１１ 課金処理部
１１２ 課金情報データベース（ＤＢ）
２０１ コマンド解析部
２０２ ステータス管理部
２０３ ＴＩＤ管理部
２０４ 課金メータ処理部
３０１ インタフェース部
３０２ 回収額集計部
３０３ 情報提供者管理部
３０４ 振込処理部
【０００１】
【発明の属する技術分野】本発明は、例えばインターネットのようなコンピュータ通信網を通じて提供される有料情報についての情報料の課金及びその回収を情報提供者に代わって行う課金代行システムに関する。
【０００２】
【従来の技術】競馬情報、カラオケ・楽曲データ、その他の有料情報をコンピュータ通信網を通じて利用者に提供するサービス提供システムが知られている。このようなサービス提供システムでは、通常、個々の有料情報毎に単位時間当たりの利用料金を設定しておき、利用者が利用した時間に応じて課金を行っている。課金額の回収はクレジット方式が一般的である。すなわち、情報提供者から利用者に対して請求書を発行するとともに、請求書に記載された額の料金をクレジットカードについて登録された預金口座から引き落とすことによって行われている。
【０００３】
【発明が解決しようとする課題】ところで、近年は、有料情報の提供媒体として、ＴＣＰ／ＩＰプロトコルに基づくネットワーク（インターネット）を用いたサービス提供システムが増大している。しかし、インターネットを媒体とし、有料情報の利用料金の回収をクレジットカードで行う形態のサービス提供システムでは以下のような問題があった。
【０００４】（１−１）クレジット方式では、１０円、１００円といった単位での少額の課金をするための手法が確立されていない。少額課金手法それ自体については、プリペイド方式によって実現しているサービス提供システムはあるが、そのためにはプリペイド方式を実現するために専用のソフトウェアを端末にインストールする必要があり、汎用のブラウザをそのまま利用することができない。
【０００５】（１−２）インターネットによる取引後の決済では、クレジット番号を事前に登録したり、決済毎にクレジットカード番号を入れたり、あるいは、別途情報提供者からの請求書によって支払うこと等が行われていた。しかし、いずれの場合も、利用者がクレジットカードを所有していなければ利用することができない。また、オンラインでクレジット番号を流すということについても、利用者の側にセキュリティ上の不安を与える。
【０００６】（１−３）多数の有料情報から利用者が希望する情報を索出して提供する形態のシステムでは、情報提供者が自由に有料情報を入れ替えたり、必要な統計情報などを自由にとることが困難であった。そのため、情報を提供するＷＷＷサーバは、情報提供者自身の都合で運用したいという要望があった。
【０００７】（１−４）インターネットでの有料情報のダウンロードの問題は、きちんとクライアントの端末まで届いたかどうかを保障できない点にある。そのため、従来、情報提供者によっては、同一有料情報について再度アクセスがあった場合に一定時間の再課金を行わないようにしているものがあった。しかし、個々のコンテンツによって再課金のタイミングを制御することが困難であった。例えば、ソフトウェアなどは、必ずしも長いタイミングで再課金をしなくともよいし、逆にオンラインゲームなどは毎回課金したいという要望があり、これらを一元的に管理することが困難であった。
【０００８】（１−５）物資購買や映像提供、案内情報提供等のように、利用者毎に課金額が異なる有料情報を提供するシステムでは、個々の有料情報に対し、ユーザ毎に課金額を変えたり、非課金時間を設定することが難しかった。
【０００９】そこで、本発明の課題は、上記従来の問題点を一挙に解消することができる情報料の課金処理方法を提供することにある。本発明の他の課題は、本発明の方法の実施に適した課金代行システムを提供することにある。
【００１０】
【課題を解決するための手段】上記課題を解決する本発明の課金処理方法は、有料情報を提供する情報提供装置と公衆通信回線を通じて前記有料情報を取得する利用者側の端末装置との間にプロキシサーバを介在させ、前記プロキシサーバにおいて前記端末装置が送出した情報要求に基づき該当する情報提供装置を特定し、利用者が要求した有料情報とその有料情報の当該利用者による利用に対して課金すべき金額情報とを前記特定した情報提供装置より取得するとともに、前記取得した有料情報を前記端末装置に送出する際に前記取得した金額情報に基づいて当該利用者への課金額を決定し、決定した課金額を、請求対象となる前記利用者の公衆通信回線使用額と統合することを特徴とする。この方法では、プロキシ（ｐｒｏｘｙ）サーバが情報提供装置の代わりに機能するので、端末装置からは、あたかも情報提供装置に直接アクセスしたかのようにみえ、その際に、情報料に対する課金が自動的になされるようになる。また、課金額は、公衆通信回線使用額と統合されるので、利用者による料金支払いが１回で済むようになる。
【００１１】本発明の課金処理方法では、また、予め前記プロキシサーバで前記有料情報の格納先アドレスを保持しておき、前記情報要求が前記端末装置から送出されたときに、前記プロキシサーバが前記情報要求に含まれる有料情報の格納先アドレスを特定して当該有料情報を格納した情報提供装置にアクセスするようにする。このようにすれば、端末装置は、有料情報を格納した情報提供装置を特定しなくとも、当該有料情報にアクセスできるようになる。
【００１２】前記課金額は、前記プロキシサーバが取得した有料情報を前記端末装置に最初に送出した時点で決定し、同一利用者に対する指定時間内の同一有料情報の送出については非課金扱いとする。これは、公衆通信回線を介して有料情報を提供する場合の、情報サイズやすべての有料情報が利用者にわたったかを確認することの困難性に鑑みた処理であり、同一利用者が直ちに同一有料情報の要求を発した場合は、前回の有料情報が利用者にわたらなかったと推定される点を考慮したものである。
【００１３】上記他の課題を解決する本発明の課金代行システムは、有料情報を提供する情報提供装置と公衆通信回線、例えばＴＣＰ／ＩＰプロトコルに基づくネットワーク回線を通じて前記有料情報を取得する利用者側の端末装置との間に論理的に介在するもので、前記端末装置が送出した情報要求に基づいて該当する情報提供装置を特定して利用者が要求した有料情報とその有料情報の当該利用者による利用に対して課金すべき金額情報とを前記特定した情報提供装置より取得する代理取得手段、取得した有料情報を前記端末装置に送出するとともに前記取得した金額情報に基づいて当該有料情報に対する利用者の課金額を決定する課金額決定手段、前記決定した課金額を前記利用者の公衆通信回線使用額と統合して請求処理を行う請求処理手段、を有することを特徴とする。
【００１４】上記課金代行システムでは、必要に応じて、前記端末装置から送出された情報要求に含まれる有料情報を識別して当該有料情報の格納先アドレスを特定するアドレス特定手段をさらに備え、生成された格納先アドレスに基づいて前記有料情報を取得するように構成される。
【００１５】なお、前記課金額決定手段は、前記取得した有料情報の最初の送出時点で前記課金額を決定し、同一利用者に対する指定時間内の同一有料情報の送出については非課金処理を行うように構成する。
【００１６】本発明の他の課金代行システムは、暗号化されて放送形式で提供される有料情報を復号させる復号鍵の登録機関と公衆通信回線を通じて前記復号鍵を取得する利用者側の端末装置との間に論理的に介在するもので、前記端末装置より受信した復号鍵要求に基づいて前記登録機関から復号鍵とその復号鍵の当該利用者による利用に対して課金すべき金額情報とを取得する代理取得手段、取得した復号鍵を前記端末装置に送出するとともに前記取得した金額情報に基づいて当該利用者への課金額を決定する課金額決定手段、前記決定した課金額を前記利用者の公衆通信回線使用額と統合して請求処理を行う請求処理手段、を有することを特徴とする。
【００１７】上記他の課金代行システムにおいて、前記課金額決定手段は、前記取得した復号鍵を前記端末装置に送出した時点で前記課金額を決定し、同一利用者に対する指定時間内の同一復号鍵の送出については非課金処理を行うように構成される。
【００１８】上記各課金代行システムにおける好ましい形態として、さらに下記の要素のいずれか、あるいは双方を適宜設ける。
（１）前記統合された額の料金が回収されたときに回収額から前記課金額を抽出して前記有料情報の提供者毎に集計して振り分ける回収処理手段。
（２）前記情報要求の受信を契機に利用者認証を行い、認証結果が正常の場合は当該利用者について登録された情報取得の権限情報を自サーバの権限情報に置換する権限情報置換手段。
【００１９】なお、各課金代行システムが具備する前記代理取得手段は、利用者の識別情報を前記情報提供装置に通知して当該利用者について情報提供者が定めた前記金額情報を取得するように構成される。また、前記代理取得手段、前記課金額決定手段、前記請求処理手段、前記アドレス特定手段、前記回収処理手段、前記権限情報置換手段は、少なくとも一つのプロキシサーバで構成される。
【００２０】
【発明の実施の形態】以下、図面を参照して本発明の実施の形態を詳細に説明する。
（第１実施形態）図１は、本発明の課金代行システムを適用したサービス提供システムの構成図である。このサービス提供システムは、本発明の課金代行システム１と、情報提供装置として機能する不特定多数の情報サーバ２と、有料情報にアクセスする多数の端末装置（以下、クライアント）３とがサービス提供網Ｌ１に接続されている。このサービス提供網Ｌ１はＴＣＰ／ＩＰプロトコルに基づくインターネットＬ２とリンクされており、インターネットＬ２には、情報サーバ２とクライアント３とが接続されている。各クライアント３は、汎用のＨＴＭＬ（HyperText Markup Language）ブラウザを通じてサービス提供網Ｌ１及びインターネットＬ２に接続されたどの情報サーバ２にもアクセスできるようになっている。
【００２１】本実施形態において課金対象となる有料情報は、情報提供者によって予め情報サーバ２に登録され、利用者の要求によりＨＴＴＰ（HyperText Transfer Protcol）を用いて特定のクライアント３に送出する情報である。この有料情報には、ＨＴＭＬデータ、バイナリ，音声，画像等の情報、コンピュータ・グラフィック等があるが、特に限定しない。また、クライアント３から送出される情報要求は、リクエストライン（ＨＴＴＰバージョン／リクエストＵＲＬ（Uniform Resource Locator）／メソッド）、ジェネラルヘッダ、リクエストヘッダ（利用者名、パスワードを含む）、エンティティヘッダ、エンティティボディの構造からなるものとする。
【００２２】本実施形態では、クライアント３からの情報要求に含まれる有料情報に基づく当該有料情報の格納場所を表す格納先アドレスの特定機能を課金代行システム１にもたせることで、各クライアント３からはこのシステム１が一つの巨大な情報サーバ群として見え、一方、個々の情報サーバ２からはクライアント３として見えるようにする。また、利用者による有料情報の利用に対してクレジット方式によらない少額課金を可能にする。さらに、個々の情報サーバ２は、情報提供者自身が独自に管理できるようにする。そのため、複数のプロキシサーバ、例えば課金処理サーバ１０，請求処理サーバ１１、回収処理サーバ１２その他のサーバを内部ネットワークで接続し、いわゆるアプリケーション・ゲートウエイとして機能するように課金代行システム１を構成している。
【００２３】課金処理サーバ１０は、図２に示すように、クライアント３との間の接続インタフェースとなるクライアント接続部１０１と、情報サーバ２との間の接続インタフェースとなる情報サーバ接続部１０２とを有する。クライアント接続部１０１でサポートするプロトコルは、ＨＴＴＰ、ＳＳＬ（Secure Sockets Layer）、ＴＣＰ（Transmission Control Protcol）、ＩＰ（Internet Protcol）である。一方、情報サーバ接続部１０２でサポートするプロトコルは、ＨＴＴＰ、ＳＳＬ、ＴＣＰ、ＩＰである。
【００２４】課金処理サーバ１０は、また、クライアント３より受信した情報要求のリクエストヘッダを解析して利用者認証を行う認証処理部１０３、利用者権限情報（パスワード等）を自サーバについて登録された権限情報に置換する権限情報置換部１０４、情報要求のリクエストラインの内容を識別して該当する有料情報を特定する情報要求受付部１０５、上記アドレス特定機能の一例として、情報要求に含まれる有料情報の指定情報または格納先情報を該当する情報サーバ２に存在する情報のアドレス（サーバ名／情報パス）に変換するアドレス変換機能を実現するサーバ管理部１０６、変換されたアドレスの情報サーバ２に対して自サーバの権限情報でアクセスして利用者が要求した有料情報の代理要求とその有料情報に対する課金情報の要求を行う情報代理要求部１０７を有している。
【００２５】サーバ管理部１０６による上記アドレス変換機能は、以下のようにして実現する。すなわち、予め複数、好ましくはすべての情報サーバ２についての、有料情報の格納先アドレスを保持したアドレステーブルをサーバ管理部１０内に形成するとともに、情報要求に含まれる情報の種別を判定する機能をサーバ管理部１０内に設ける。そして、この情報種別の判定結果とアドレステーブルの保持内容に基づいてその有料情報が存在する情報サーバとその格納先アドレスとを特定し、特定した格納先アドレスから該当する有料情報を取得する。このようにすることで、クライアント３からの情報要求の電文フォーマットがどのようなものであっても、情報種別が判定できれば、課金処理サーバ１０から必要な有料情報にアクセスできるようになる。また、クライアント３は、所望の有料情報の格納先アドレスを正確に知らなくとも当該有料情報を取得できるようになる。
【００２６】課金処理サーバ１０は、また、代理要求に応じて情報サーバ２から送られた有料情報を受け付ける情報応答受付部１０８、受け付けた有料情報を情報要求元のクライアント３へ送信する情報代理応答部１０９、上記有料情報の送出時点でクライアント３を操作する利用者についての課金額を決定する課金額決定部１１０、決定した課金額についての所要処理を行う課金処理部１１１、及び、課金情報を利用者毎に蓄積する課金情報データベース（ＤＢ）１１２を有している。課金情報ＤＢ１１２に蓄積された課金情報は、後述の請求処理サーバ１１において利用される。なお、上記機能ブロック１０１〜１１１及び課金情報ＤＢ１１２は、サーバ本体が所定のプログラムを読み込んで実行することによって形成されるものである。
【００２７】課金処理サーバ１０における処理手順は、図３に示すとおりである。すなわち、クライアント３からの情報要求の受信を契機に、認証処理部１０３において利用者認証を行う（ステップＳ３０１：Yes、Ｓ３０２）。情報要求に誤った利用者ＩＤやパスワードが設定されている場合は、情報代理応答部１０９を通じてクライアント３に個別的に利用者ＩＤまたはパスワード（あるいは両方）の入力を促す。認証が正当であった場合は（ステップＳ３０３：Yes）、情報要求受付部１０５で情報要求を受け付け、これをサーバ管理部１０６に送る。サーバ管理部１０６は、情報要求に含まれる情報種別、または情報の格納先アドレス（クライアント３側で指示されてきた場合）を判定し、上記アドレス変換機能を使用してその有料情報が存在する情報サーバ２を特定する（ステップＳ３０４）。そして、情報代理要求部１０７を通じて、特定した情報サーバに自己の権限情報（利用者の権限情報を置換したもの）でアクセスして利用者の識別情報と有料情報の格納先アドレスとを通知する。情報応答受付部１０８は、その利用者に対して情報提供者が自由に設定した課金情報を取得する（ステップＳ３０５）。また、情報代理要求部１０７を通じて情報サーバ２に有料情報の代理要求を送信し、情報応答受付部１０８を通じてその有料情報を取得するとともに（ステップＳ３０６）、情報代理応答部１０９を通じて、取得した有料情報をクライアント３に送る。つまり、代理応答を行う（ステップＳ３０７）。なお、有料情報の代理要求は、利用者の識別情報や格納先アドレスの通知と同時に情報サーバ２に送信し、課金情報と有料情報とを同時期に取得するようにしてもよい。
【００２８】情報代理応答部１０９が、クライアント３に対する有料情報の送信を開始すると、課金額決定部１１０は、その有料情報について既に課金済であるかどうかを課金情報ＤＢ１１２を参照して判定する。課金済であるが、所定の規定時間、例えば情報サーバ２がその有料情報に対して設定した時間内である場合は、前回の代理応答が正常にクライアント３に届かなかったとみなして、非課金とする（ステップＳ３０８：Yes、Ｓ３０９：Yes）。なお、代理応答は、１情報要求に対して複数ブロック発生する場合があるが、この場合は、最初のブロックが規定時間内であれば、最終ブロックが規定時間を越える場合であっても非課金とする。
【００２９】一方、ステップＳ３０８において課金済みでなかった場合、あるいは課金済みであるが、規定時間を経過している場合、課金額決定部１１０は、代理応答を開始した時点、複数ブロックの場合は最初のブロックをクライアント３に向けて送出した時点で課金額を決定する（ステップＳ３０８：No、Ｓ３１０）。このようにすれば、有料情報がきちんとクライアント３まで届いたかどうかが保障できないという問題を解消することができる。
【００３０】課金額が決定した場合、課金処理部１１１は、その利用者についての課金額を課金情報ＤＢ１１２に蓄積した後、情報サーバ２に対して課金結果通知を行う（ステップＳ３１１，Ｓ３１２）。なお、予め情報サーバ２から課金結果通知が不要とされている場合は、情報サーバ２への課金結果通知が省略される。
【００３１】なお、図示を省略してあるが、課金処理サーバ１０では、課金関連の情報を事後的に解析するため、請求処理サーバ１１及び回収処理サーバ１２から情報料課金ジャーナルと課金結果通知ファイルとを利用者毎に採取する。情報料課金ジャーナルは利用者毎の課金結果を記録するもので、代理応答の先頭ブロック（ｈｔｔｐヘッダ）を正常に送出した時点で採取する。課金結果通知ファイルは、利用者毎に情報サーバ２に対する課金結果通知と課金額不正通知のいずれかを行うための情報を記録するもので、課金額通知は、クライアント３に対して代理応答の先頭ブロック（ｈｔｔｐヘッダ）を送出した時点で採取する。課金額不正通知は、不正な課金額応答を受け取った時点で採取する。
【００３２】次に、請求処理サーバ１１について説明する。請求処理サーバ１１は、課金処理サーバ１０において決定された利用者毎の課金額の累計額を当該利用者の公衆通信回線使用額と統合して請求処理を行う。その具体的な構成例は図４に示すとおりであり、サーバ本体が所定のコンピュータプログラムを読み込んで実行することによって形成される、コマンド解析部２０１、ステータス管理部２０２、ＴＩＤ（Telephone ID）管理部２０３、課金メータ処理部２０４を具備している。なお、ここでは、利用者毎の公衆通信回線使用額、つまり電話料金は、図示しない料金管理機関側の料金管理システムで一括管理し、各利用者に対する実際の請求業務は、当該料金管理システムにおいて行うものとする。
【００３３】コマンド解析部２０１は、入力されたコマンドの内容を解析し、解析結果をステータス管理部２０２と課金メータ処理部２０４に通知する。ステータス管理部２０２は、本実施形態の課金代行システム１全体の状態（ステータス）を監視しており、コマンド解析部２０１による解析の結果、入力されたコマンドが請求処理の実行コマンドである場合は、当該コマンドに課金処理中を表すフラグをたて、当該コマンドの実行終了を契機にそのフラグを解除する。課金処理中のフラグがたっている場合、本システムは、利用者に対してサービス提供は行うが（ジャーナルで記録しておく）、利用者の新たな登録や削除を禁止させるようにする。ＴＩＤ管理部２０３は、利用者名と加入者電話番号（以下、電話番号）とをリンクさせて管理している。なお、ＴＩＤ管理部２０３を別途設けずに、前述の課金情報ＤＢ１１２を用いて利用者の電話番号を特定できるようにしてもよい。課金メータ処理部２０４は、課金情報ＤＢ１１２における利用者毎の課金額を集計して課金メータを作成し、作成した課金メータに対応する加入者電話番号をＴＩＤ管理部２０３から索出するとともに、当該利用者についての課金メータと情報提供者毎の課金内訳を料金管理システムに通知する。通知に際しては、料金管理システム用の電文フォーマットに変換する。この課金メータ及び課金内訳は、利用者に対する請求内容を表すものであり、従前の領収済み通知に対応するものである。
【００３４】この請求処理サーバ１１における処理手順は図５に示すとおりである。すなわち、図示しないデータ入力装置を通じて請求処理を要求するコマンドが入力されると、コマンド解析部２０１がその内容を解析し、請求処理の開始をステータス管理部２０２及び課金メータ処理部２０４に通知する（ステップＳ５０１）。ステータス管理部２０２は、この通知の受領を契機に「課金処理中」を表すフラグをたてる（ステップＳ５０２）。課金メータ処理部２０４は、一の利用者について、前回の課金メータを作成した時点以降今期の基準時点まで（以下、基準期間）の課金額を課金処理サーバ１０（課金情報ＤＢ１１２）から読み出し（ステップＳ５０３）、その利用者の基準期間内の課金メータを作成する（ステップＳ５０４）。その後、ＴＩＤ管理部２０３を検索して利用者の加入者電話番号を特定し、当該利用者の課金メータと情報提供者毎の内訳を料金管理システムに通知する（ステップＳ５０５）。加入者電話番号の特定は、例えば、課金情報ＤＢ１１２で管理されている利用者ログ、あるいは利用者ＩＤから利用者名を特定し、その後、特定した利用者名に対応する加入者電話番号をＴＩＤ管理部２０３から索出することによって行う。前述のようにＴＩＤ管理部２０３を設けずに課金情報ＤＢ１１２のみで利用者の電話番号を管理する場合は、利用者ＩＤに当該利用者の電話番号を履歴として保存しておくことで、直ちに電話番号を特定できるようになる。料金管理システムへの通知後は、その利用者についての課金情報ＤＢ１１２内の課金額をリセットする（ステップＳ５０６）。この処理を他の利用者について繰り返し（ステップＳ５０７）、すべての利用者についての請求処理が終了した場合は、ステータス管理部２０２にその旨を通知して課金処理中のフラグを解除させる（ステップＳ５０８）。このようにして、有料情報についての課金額と電話料金とを一元管理できるようにする。
【００３５】次に、回収処理サーバ１２について説明する。回収処理サーバ１２は、電話料金に課金額が重畳された額の料金が利用者から回収されたときに、回収代行処理を行う。前提として、上記料金管理システムにおいて、回収された額から電話料金が差し引かれた額、つまり先に通知した課金メータに対応する額（以下、回収額）が、通知ないし振り込まれるものとする。
【００３６】この回収処理サーバ１２は、図６に示すように、料金管理システムとの間に接続されたインタフェース部３０１、情報提供者管理部３０２、回収額集計部３０３、図示しない金融機関による振込システムに接続された振込処理部３０４とを具備している。これらの機能ブロック３０１〜３０４は、サーバ本体が所定のプログラムを読み込んで実行することによって形成されるものである。インタフェース部３０１は、料金管理システムから回収通知及び回収額を受領する。情報提供者管理部３０３には、回収代行を希望する情報提供者のＩＤ、振込口座番号、及び振込条件等が登録されている。回収額集計部３０４は、各利用者の回収額を情報提供者毎に集計する。振込処理部３０４は、振込システムにアクセスして情報提供者毎の振込口座番号への自動振込処理を行う。
【００３７】この回収処理サーバ１２における処理手順は図７のとおりである。まず、インタフェース部３０１において料金管理システムから利用者の回収額を取得する（ステップＳ７０１）。回収額集計部３０２は、回収額を情報提供者毎に集計するとともに（ステップＳ７０２）、各情報提供者のＩＤを通じて振込口座番号や振込条件を特定し（ステップＳ７０３）、この特定した振込口座番号や振込条件にしたがって、上記集計した額の料金を振り込むための処理を行う（ステップＳ７０４）。他の情報提供者についてステップＳ７０３及びＳ７０４の処理を繰り返し、すべての情報提供者に対する振込処理が終了した時点で回収処理を終える（ステップＳ７０４）。
【００３８】なお、以上の処理手順は、請求に対してすべての利用者が遅延なく料金を支払い、回収がなされた場合の例である。一部の利用者による回収が遅延した場合は、以下のようにして調整をとる。この場合は、料金管理システムから回収不能であった利用者ＩＤとその利用者の課金メータに対応する額の通知を受ける。この通知に基づいて、回収額集計部３０２は、回収不能であった利用者の課金額及びその内訳を解析し、回収不能額を今期の基準期間の回収額から差し引いて上記情報提供者毎の集計を行う。一方、次の基準期間に上記回収不能が回収された旨の通知を料金管理システムから通知された場合は、回収された額をその基準期間内の本来の回収額に上乗せして上記情報提供者毎の集計を行う。
【００３９】上記実施形態では、利用者に対する領収済み通知を、請求処理サーバ１１における課金内訳で代用した場合の例を示したが、これに代えて、回収処理サーバ１２に領収済み通知処理部を設け、回収額を各情報提供者の振込口座番号に振り込んだ時点で、紙媒体、あるいは通信媒体を通じて領収済み通知を各利用者に対して発行するようにしてもよい。
【００４０】（第２実施形態）図８は、上記課金代行システム１を適用した他のサービス提供システムの実施の形態を示す図である。ここでは、情報提供者が有料情報を暗号化して放送局６から有料放送として提供する場合を想定している。暗号化有料情報を復号させる復号鍵は、情報提供者が予め情報料の金額情報と共に鍵センター７に登録しておく。利用者は、公衆通信回線、例えばインターネットＬ２に接続されたクライアント３の汎用ブラウザを通じて鍵センター７から復号鍵を取得し、この復号鍵を用いて有料放送を復号する。復号鍵は、情報提供者が定めた所定時間のみ有効となるようにし、この復号鍵の配布に対して課金されるようにする。
【００４１】課金代行システム１は、第１実施形態と同様、課金処理サーバ１０、請求処理サーバ１１、回収処理サーバ１２を備えており、有料情報が復号鍵となる以外は、ほぼ同様の処理を行うものである。すなわち、図８に示すように、クライアントからの復号鍵要求（１）の受信を契機に鍵センター７にアクセスして課金額確認を行うとともに（２）、復号鍵を取得する（３）。取得した復号鍵をクライアント３に配布し（４）、同時に課金額の決定を行う。また、料金管理機関７に対して利用者毎の課金累計額の通知を行う（５）。振込システムに連動する料金管理機関７において利用者からの料金回収が確認された場合は（７）、情報提供者毎の情報料を集計し（８）、指定された口座への振り込み処理を行う（９）。
【００４２】なお、第１及び第２実施形態は一例であって、これ以外の同種のサービス提供システム、例えばインターネットによる競馬情報、カラオケ・楽曲データ、その他の有料情報の提供サービスシステムについても本発明の課金代行システム１を利用することができる。
【００４３】このように、本発明の課金代行システム１では、プロキシサーバに課金回収機能を盛り込んだので、従来型システムでは不可能であった汎用のブラウザを用いたクレジットカードによらないインターネット上の少額課金方式が実現できるようになった。
【００４４】また、有料情報に課される料金を利用者の通常の電話回線使用料と統合して一元的に管理できるようにしたので、第三者によるクレジット情報の悪用を防止することが可能になり、利用者の不安を払拭できるようになった。情報提供者にとっても、情報料が自動的に指定口座に振り込まれるので、請求書や領収済通知を利用者毎に発行する作業負担がなくなった。
【００４５】また、クライアント３からは、あたかも一つのＷＷＷサーバに情報を要求しているように見えるシステム構成にしたので、情報提供者が情報サーバ２に自由に有料情報を入れ替えたり、情報利用頻度等の必要な統計情報を自由にとることが容易となり、情報提供者自身による情報サーバ２の運用に柔軟性をもたせることができるようになった。
【００４６】また、有料情報をクライアント３に最初に送出した時点で情報提供者側からの指示に基づく課金額を決定し、同一利用者に対する規定時間（情報提供者が指定）内の同一有料情報の送出については非課金処理を行うようにしたので、例えばインターネットでの有料情報のダウンロードが正常に終了したかどうかをその都度確認する必要がなくなり、また、有料情報毎の再課金のタイミングを緻密に制御する必要がなくなる。これにより、有料情報の種類毎の課金と情報保障の双方を同時に実現できるようになった。
【００４７】さらに、従来型システムでは、同一の有料情報は固定料金であったため、同一サイトに複数種類の有料情報が存在する場合に、個々の有料情報に対して利用者毎に課金額を変えたり、非課金時間を設定することは難しかったが、本発明の課金代行システムでは、情報サーバ２に対して利用者ＩＤを通知し、情報サーバ２からその利用者に対して課金すべき金額情報を応答で返してもらうことで課金額を決定するようにしたので、例えばアクセス頻度の高い利用者や展示会等で利用する者に対しては割引率を高めに設定した課金を行う、というフレキシブルな課金体系を採用することが可能になった。
【００４８】
【発明の効果】以上の説明から明らかなように、本発明の課金代行システムによれば、例えばＴＣＰ／ＩＰプロトコルを採用したネットワーク回線を通じて行われる有料情報の情報料の課金や回収の代行を、利用者及び情報提供者の双方の便宜を図りながら適切に行えるようになり、従来の問題点が一挙に解消される。これにより、この種のサービス提供システムの普及に寄与することができる。
【図面の簡単な説明】
【図１】本発明の課金代行システムを適用したサービス提供システムの実施の一形態を示す構成図。
【図２】この実施形態による課金処理サーバの機能ブロック図。
【図３】課金処理サーバにおける処理手順説明図。
【図４】請求処理サーバの機能ブロック図。
【図５】請求処理サーバにおける処理手順説明図。
【図６】回収処理サーバの機能ブロック図。
【図７】回収処理サーバにおける処理手順説明図。
【図８】本発明の課金代行システムを適用した他のサービス提供システムの実施の一形態を示す説明図。
【符号の説明】
１ 課金代行システム
２ 情報サーバ
３ クライアント
６ 放送局
７ 鍵センター
８ 料金管理機関
１０ 課金処理サーバ
１１ 請求処理サーバ
１２ 回収処理サーバ
１０１ クライアント接続部
１０２ 情報サーバ接続部
１０３ 認証処理部
１０４ 権限情報置換部
１０５ 情報要求受付部
１０６ サーバ管理部
１０７ 情報代理要求部
１０８ 情報応答受付部
１０９ 情報代理応答部
１１０ 課金額決定部
１１１ 課金処理部
１１２ 課金情報データベース（ＤＢ）
２０１ コマンド解析部
２０２ ステータス管理部
２０３ ＴＩＤ管理部
２０４ 課金メータ処理部
３０１ インタフェース部
３０２ 回収額集計部
３０３ 情報提供者管理部
３０４ 振込処理部
【特許請求の範囲】
【請求項１】 有料情報を提供する情報提供装置と公衆通信回線を通じて前記有料情報を取得する利用者側の端末装置との間にプロキシサーバを介在させ、前記プロキシサーバにおいて前記端末装置が送出した情報要求に基づき該当する情報提供装置を特定し、利用者が要求した有料情報とその有料情報の当該利用者による利用に対して課金すべき金額情報とを前記特定した情報提供装置より取得するとともに、前記取得した有料情報を前記端末装置に送出する際に前記取得した金額情報に基づいて当該利用者への課金額を決定し、決定した課金額を、請求対象となる前記利用者の公衆通信回線使用額と統合することを特徴とする、情報料の課金処理方法。
【請求項２】 予め前記プロキシサーバで前記有料情報の格納先アドレスを保持しておき、前記情報要求が前記端末装置から送出されたときに、前記プロキシサーバが前記情報要求に含まれる有料情報の格納先アドレスを特定して当該有料情報を格納した情報提供装置にアクセスすることを特徴とする請求項１記載の課金処理方法。
【請求項３】 前記課金額は、前記プロキシサーバが取得した有料情報を前記端末装置に最初に送出した時点で決定し、同一利用者に対する指定時間内の同一有料情報の送出については非課金扱いとすることを特徴とする請求項１記載の課金処理方法。
【請求項４】 有料情報を提供する情報提供装置と公衆通信回線を通じて前記有料情報を取得する利用者側の端末装置との間に論理的に介在するシステムであって、前記端末装置が送出した情報要求に基づき該当する情報提供装置を特定して利用者が要求した有料情報とその有料情報の当該利用者による利用に対して課金すべき金額情報とを前記特定した情報提供装置より取得する代理取得手段、取得した有料情報を前記端末装置に送出するとともに前記取得した金額情報に基づいて当該利用者への課金額を決定する課金額決定手段、前記決定した課金額を前記利用者の公衆通信回線使用額と統合して請求処理を行う請求処理手段を有することを特徴とする、情報料の課金代行システム。
【請求項５】 前記端末装置から送出された情報要求に含まれる有料情報を識別して当該有料情報の格納先アドレスを特定するアドレス特定手段をさらに備え、特定された格納先アドレスに基づいて前記有料情報を取得するように構成されたことを特徴とする請求項４記載の課金代行システム。
【請求項６】 前記課金額決定手段は、前記取得した有料情報を前記端末装置に最初に送出した時点で前記課金額を決定し、同一利用者に対する指定時間内の同一有料情報の送出については非課金処理を行うように構成されていることを特徴とする請求項４記載の課金代行システム。
【請求項７】 暗号化されて放送形式で提供される有料情報を復号させる復号鍵の登録機関と公衆通信回線を通じて前記復号鍵を取得する利用者側の端末装置との間に論理的に介在し、前記端末装置より受信した復号鍵要求に基づいて前記登録機関から復号鍵とその復号鍵の当該利用者による利用に対して課金すべき金額情報とを取得する代理取得手段、取得した復号鍵を前記端末装置に送出するとともに前記取得した金額情報に基づいて当該利用者への課金額を決定する課金額決定手段、前記決定した課金額を前記利用者の公衆通信回線使用額と統合して請求処理を行う請求処理手段を有することを特徴とする、情報料の課金代行システム。
【請求項８】 前記課金額決定手段は、前記取得した復号鍵を前記端末装置に送出した時点で前記課金額を決定し、同一利用者に対する指定時間内の同一復号鍵の送出については非課金処理を行うように構成されていることを特徴とする請求項７記載の課金代行システム。
【請求項９】 前記統合された額の料金が回収されたときに回収額から前記課金額を抽出して前記有料情報の提供者毎に集計して振り分ける回収処理手段をさらに備えたことを特徴とする請求項４または７記載の課金代行システム。
【請求項１０】 前記情報要求の受信を契機に利用者認証を行い、認証結果が正常の場合は当該利用者について登録された情報取得の権限情報を自サーバの権限情報に置換する権限情報置換手段をさらに備えたことを特徴とする請求項４または７記載の課金代行システム。
【請求項１１】 前記代理取得手段は、利用者の識別情報を前記情報提供装置に通知して当該利用者について情報提供者が定めた前記金額情報を取得するように構成されていることを特徴とする請求項４または７記載の課金代行システム。
【請求項１２】 前記公衆通信回線がＴＣＰ／ＩＰプロトコルに基づくネットワーク回線であることを特徴とする請求項４または７記載の課金代行システム。
【請求項１３】 前記代理取得手段、前記課金額決定手段、前記請求処理手段、前記アドレス特定手段、前記回収処理手段、前記権限情報置換手段を少なくとも一つのプロキシサーバで構成したことを特徴とする請求項４、５、７、９、１０、１２のいずれかの項記載の課金代行システム。
【請求項１】 有料情報を提供する情報提供装置と公衆通信回線を通じて前記有料情報を取得する利用者側の端末装置との間にプロキシサーバを介在させ、前記プロキシサーバにおいて前記端末装置が送出した情報要求に基づき該当する情報提供装置を特定し、利用者が要求した有料情報とその有料情報の当該利用者による利用に対して課金すべき金額情報とを前記特定した情報提供装置より取得するとともに、前記取得した有料情報を前記端末装置に送出する際に前記取得した金額情報に基づいて当該利用者への課金額を決定し、決定した課金額を、請求対象となる前記利用者の公衆通信回線使用額と統合することを特徴とする、情報料の課金処理方法。
【請求項２】 予め前記プロキシサーバで前記有料情報の格納先アドレスを保持しておき、前記情報要求が前記端末装置から送出されたときに、前記プロキシサーバが前記情報要求に含まれる有料情報の格納先アドレスを特定して当該有料情報を格納した情報提供装置にアクセスすることを特徴とする請求項１記載の課金処理方法。
【請求項３】 前記課金額は、前記プロキシサーバが取得した有料情報を前記端末装置に最初に送出した時点で決定し、同一利用者に対する指定時間内の同一有料情報の送出については非課金扱いとすることを特徴とする請求項１記載の課金処理方法。
【請求項４】 有料情報を提供する情報提供装置と公衆通信回線を通じて前記有料情報を取得する利用者側の端末装置との間に論理的に介在するシステムであって、前記端末装置が送出した情報要求に基づき該当する情報提供装置を特定して利用者が要求した有料情報とその有料情報の当該利用者による利用に対して課金すべき金額情報とを前記特定した情報提供装置より取得する代理取得手段、取得した有料情報を前記端末装置に送出するとともに前記取得した金額情報に基づいて当該利用者への課金額を決定する課金額決定手段、前記決定した課金額を前記利用者の公衆通信回線使用額と統合して請求処理を行う請求処理手段を有することを特徴とする、情報料の課金代行システム。
【請求項５】 前記端末装置から送出された情報要求に含まれる有料情報を識別して当該有料情報の格納先アドレスを特定するアドレス特定手段をさらに備え、特定された格納先アドレスに基づいて前記有料情報を取得するように構成されたことを特徴とする請求項４記載の課金代行システム。
【請求項６】 前記課金額決定手段は、前記取得した有料情報を前記端末装置に最初に送出した時点で前記課金額を決定し、同一利用者に対する指定時間内の同一有料情報の送出については非課金処理を行うように構成されていることを特徴とする請求項４記載の課金代行システム。
【請求項７】 暗号化されて放送形式で提供される有料情報を復号させる復号鍵の登録機関と公衆通信回線を通じて前記復号鍵を取得する利用者側の端末装置との間に論理的に介在し、前記端末装置より受信した復号鍵要求に基づいて前記登録機関から復号鍵とその復号鍵の当該利用者による利用に対して課金すべき金額情報とを取得する代理取得手段、取得した復号鍵を前記端末装置に送出するとともに前記取得した金額情報に基づいて当該利用者への課金額を決定する課金額決定手段、前記決定した課金額を前記利用者の公衆通信回線使用額と統合して請求処理を行う請求処理手段を有することを特徴とする、情報料の課金代行システム。
【請求項８】 前記課金額決定手段は、前記取得した復号鍵を前記端末装置に送出した時点で前記課金額を決定し、同一利用者に対する指定時間内の同一復号鍵の送出については非課金処理を行うように構成されていることを特徴とする請求項７記載の課金代行システム。
【請求項９】 前記統合された額の料金が回収されたときに回収額から前記課金額を抽出して前記有料情報の提供者毎に集計して振り分ける回収処理手段をさらに備えたことを特徴とする請求項４または７記載の課金代行システム。
【請求項１０】 前記情報要求の受信を契機に利用者認証を行い、認証結果が正常の場合は当該利用者について登録された情報取得の権限情報を自サーバの権限情報に置換する権限情報置換手段をさらに備えたことを特徴とする請求項４または７記載の課金代行システム。
【請求項１１】 前記代理取得手段は、利用者の識別情報を前記情報提供装置に通知して当該利用者について情報提供者が定めた前記金額情報を取得するように構成されていることを特徴とする請求項４または７記載の課金代行システム。
【請求項１２】 前記公衆通信回線がＴＣＰ／ＩＰプロトコルに基づくネットワーク回線であることを特徴とする請求項４または７記載の課金代行システム。
【請求項１３】 前記代理取得手段、前記課金額決定手段、前記請求処理手段、前記アドレス特定手段、前記回収処理手段、前記権限情報置換手段を少なくとも一つのプロキシサーバで構成したことを特徴とする請求項４、５、７、９、１０、１２のいずれかの項記載の課金代行システム。
【図１】
【図２】
【図３】
【図７】
【図４】
【図５】
【図６】
【図８】
【図２】
【図３】
【図７】
【図４】
【図５】
【図６】
【図８】
【公開番号】特開平１１−６６１８２
【公開日】平成１１年（１９９９）３月９日
【国際特許分類】
【出願番号】特願平９−２３００９３
【出願日】平成９年（１９９７）８月２６日
【出願人】（０００１０２７２８）株式会社エヌ・ティ・ティ・データ (438)
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【公開日】平成１１年（１９９９）３月９日
【国際特許分類】
【出願日】平成９年（１９９７）８月２６日
【出願人】（０００１０２７２８）株式会社エヌ・ティ・ティ・データ (438)
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
[ Back to top ]