JP2000124900A

JP2000124900A - 課金徴収方法とその装置及び通信システム

Info

Publication number: JP2000124900A
Application number: JP29587698A
Authority: JP
Inventors: Toshiyuki Yubihara; 利之指原
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 1998-10-16
Filing date: 1998-10-16
Publication date: 2000-04-28
Anticipated expiration: 2018-10-16
Also published as: JP3516595B2

Abstract

(57)【要約】【課題】サーバとクライアント間でのデータ通信にお
いて、データパケットを送信したサーバが正確に課金で
きることを課題とする。【解決手段】サーバから暗号化した課金対象のデータ
をクライアントへ送信する課金徴収方法において、前記
課金対象のデータを受信した前記クライアントから確認
応答信号を前記サーバが受信し、前記サーバは前記課金
対象のデータに基いて課金演算して後その課金を課金蓄
積手段に蓄積し、前記クライアントへ前記課金対象のデ
ータを復号化する復号化キーを送信することを特徴とす
る。また、上記課金徴収方法において、前記クライアン
トは、前記サーバから前記課金対象のデータを未復号デ
ータ記憶手段に格納して後、前記確認応答信号を前記サ
ーバに送出し、前記復号化キーを受信して未復号データ
記憶手段に格納された前記課金対象のデータを復号化す
ることを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアントへデ
ータを配送するサーバにおける課金の徴収方法及び課金
徴収装置と通信システムに関する。

【０００２】

【従来の技術】パケット交換網において、サーバからク
ライアントへ有料データの転送を行う場合、届かなかっ
たパケットを課金することなく、データの転送量に応じ
た課金の手法として、クライアントからの確認応答に基
づく課金の方法がある。

【０００３】このような確認応答に基づく課金方式の従
来手法の一例が、特開平２−１４２２４５号公報に記載
されている。該公報では、図１５に示すように、この従
来のパケット交換網における課金方式は、端末１と、端
末２、パケット交換局３、パケット交換局４、課金カウ
ンタ５、再送待ちキュー６とから構成されている。この
ような構成を有するパケット交換網における課金方式
は、次のように動作する。

【０００４】すなわち、端末１から出力されたデータパ
ケット８を、パケット交換局３を介してパケット交換局
４で受信したとき、パケット交換局４は、確認応答パケ
ット９をパケット交換局３に送信する。パケット交換局
３はこの確認応答パケット９を受信すると、再送待ちキ
ュー６から保留していたデータパケット８を削除し、課
金カウンター５へデータパケット８の情報量に相当する
課金を加算する。こうして、確認応答のパケット９を受
信したときに課金計算を行うパケット交換局３は課金計
算を実行し、送信したデータパケットに応じた課金を端
末２から徴収することになる。

【０００５】

【発明が解決しようとする課題】しかしながら、上述の
従来技術には、次のような問題点があった。その問題点
とは、端末２がデータパケット８を受信して、パケット
交換局４が確認応答パケット９を送出しなかった場合、
端末２はデータを受信しつつパケット交換局３において
課金カウンタが加算されないということが生じうること
である。その理由は、パケット交換局４による確認応答
パケット９の送信の課金カウンタ加算の前に、すでに端
末２にデータが届いてしまっているからである。

【０００６】すなわち、単純にデータ受信端末である端
末２であるクライアントからの確認応答をもとに課金を
行った場合、クライアントが確認送達を送信しないこと
により、クライアントはデータを受け取りつつ課金され
ないということが可能になり、課金する側が適正に料金
を取れないという問題があった。

【０００７】本発明は、上記問題点を解決するために、
サーバとクライアント間で、データパケットを送信した
サーバが正確に課金できることを課題とする。

【０００８】

【課題を解決するための手段】本発明は、サーバから暗
号化した課金対象のデータをクライアントへ送信する課
金徴収方法において、前記課金対象のデータを受信した
前記クライアントから確認応答信号を前記サーバが受信
し、前記サーバは前記課金対象のデータに基づいて課金
演算後課金蓄積手段に蓄積し、前記クライアントへ前記
課金対象のデータを復号化する復号化キーを送信するこ
とを特徴とする。

【０００９】また、上記課金徴収方法において、前記ク
ライアントは、前記サーバから前記課金対象のデータを
未復号データ記憶手段に格納して後、前記確認応答信号
を前記サーバに送出し、前記復号化キーを受信して未復
号データ記憶手段に格納された前記課金対象のデータを
復号化することを特徴とする。

【００１０】また、上記課金徴収方法において、前記サ
ーバは、前記クライアントへの前記課金対象のデータを
暗号化キーによって暗号化して前記クライアントへ送信
し、前記確認応答信号を受信して前記課金対象のデータ
に基づいて課金演算し、前記蓄積手段に格納し、復号化
キーを前記クライアントへ送信することを特徴とする。

【００１１】また、本発明は、サーバから暗号化した課
金対象データをクライアントへ送信する課金徴収装置に
おいて、前記課金対象データを受信した前記クライアン
トでＯＳＩ参照モデルの第１レイヤを通して前記サーバ
へ確認応答信号を送出する応答信号送出手段と、前記確
認応答信号を受信した前記サーバで前記課金対象データ
に基づいて課金演算処理する課金演算処理部と、前記確
認応答信号を受信した前記サーバで前記クライアントへ
前記課金対象データを復号化する復号化キーを送信する
復号化キー送信手段とを備えたことを特徴とする。

【００１２】また、本発明は、サーバから暗号化した課
金対象データをクライアントへ送信する通信システムに
おいて、前記サーバは、暗号化した課金対象データを前
記クライアントへ送信するデータ送信手段と、前記クラ
イアントからの確認応答信号を受信して前記課金対象デ
ータに基づいて課金演算処理する課金演算処理部と、前
記確認応答信号を受信して前記クライアントへ前記課金
対象データを復号化する復号化キーを送信する復号化キ
ー送信手段とを備え、前記クライアントは、前記課金対
象データを受信して未復号データとして格納する記憶手
段と、前記記憶手段に格納すると共に前記サーバへ確認
応答信号を送出する応答信号送出手段と、前記復号化キ
ーを受信して前記課金対象データを復号化する復号化手
段とを備えたことを特徴とする。

【００１３】また、本発明は、有料のデータをサーバ側
からクライアント側に転送する場合に、クライアント側
がサーバ側の課金処理を行う前にアプリケーションにデ
ータを引き渡すことを防止するため、暗号化してデータ
を送信し、クライアント側から送られた確認応答に基づ
く課金処理が終わった後、復号化するためのキーを通知
することで、適正な課金処理を実現するトランスポート
プロトコル方式による課金徴収方法や、課金徴収装置、
通信システムである。

【００１４】また、本発明は、図１を参照しつつ具体的
に説明する。図１において、１はデータの送信側、２は
データの受信側である。また、データの送信側１におい
て、１０はデータを送信するためのサーバ側のアプリケ
ーションプログラムである。また、１１はサーバ側のト
ランスポートプロトコルである。１２はサーバ側の物理
層で、無線やEthertnet等のＬＵＮや公衆電話網であっ
てもよい。また、１３は課金情報を蓄積するための手段
である。

【００１５】また、データの受信側２において、２０は
データを受信するためのクライアント側アプリケーショ
ンプログラムである。２１はクライアント側のトランス
ポートプロトコルである。２２はクライアント側の物理
層である。

【００１６】このような構成のもと、サーバ側１からク
ライアント側２にデータを送信する場合のシーケンスを
図２に示す。図２において、サーバ側トランスポートプ
ロトコル１１からクライアント側トランスポートプロト
コル２１にデータを送信するとき、図２のＡ，Ｂ，Ｃに
示すように、ある暗号化キーを用いてデータを暗号化
（encoded Data）し、その暗号化したデータをクライア
ント側トランスポートプロトコル２１に送信する。

【００１７】そして、サーバ側トランスポートプロトコ
ル１１はクライアント側トランスポートプロトコル２１
から確認応答（Ack(1,2,3)，図２のＤ）を受信すると、
サーバ側トランスポートプロトコル１１は、課金情報蓄
積手段１３に対し、送信したパケットＡ，Ｂ，Ｃのデー
タに対する課金情報（Bill(1,2,3)，図２のＦ）を書き
こむ。そして、サーバ側トランスポートプロトコル１１
は、先ほど暗号化して送信したパケットＡ，Ｂ，Ｃのデ
ータを復号するためのキー（Key，図２のＥ）をクライ
アント側トランスポートプロトコル２１に送信する。キ
ーを受け取ったクライアント側トランスポートプロトコ
ル２１は、そのキーをもとにパケットＡ，Ｂ，Ｃのデー
タを復号化（Data(1,2,3)）し、復号化したデータをク
ライアント側アプリケーションプログラム２０に渡す
（図２のＧ）。

【００１８】以上により、サーバ側トランスポートプロ
トコル１１は、クライアント側トランスポートプロトコ
ル２１から送られてきた確認応答をもとに、課金処理を
行うため、再送などで同じデータが送信されても、二重
に課金されるようなことはない。

【００１９】また、クライアント側トランスポートプロ
トコル２１はサーバ側トランスポートプロトコル１１に
おいて課金処理が行われない限り、データをクライアン
ト側アプリケーション２０に渡すことができないので、
サーバ側が課金処理を行う前にクライアント側アプリケ
ーションプログラム２０が受信したデータを入手するこ
とが可能という事態を回避することが可能になる。

【００２０】

【発明の実施の形態】本発明による実施形態について、
図面を参照しつつ詳細に説明する。

【００２１】［第１の実施形態］（本実施形態の構成）図１を参照すると、本実施形態
は、データを送信するサーバ側１とデータを受信するク
ライアント側２、そしてサーバ１〜クライアント２間で
データを転送するための通信媒体３から構成されてい
る。このサーバ側１及びクライアント側２は通信プロト
コルの標準として用いられている７レイヤからなるＯＳ
Ｉ（Open Systems Interconnection）参照モデルに準拠
したＴＣＰ／ＩＰ（Transmission Control Protocol /
Internet Protocol）により効率のよいプロトコルであ
っても、他のプロトコルであってもよく、これらに限定
されるものではない。ＯＳＩ参照モデルとしては、第１
レイヤの物理層、第２レイヤのデータリンク層、第３レ
イヤのネットワーク層、第４レイヤのトランスポート
層、……第７レイヤのアプリケーション層等からなり、
パケット交換局としては第１レイヤから第３レイヤによ
って構成される。

【００２２】また、通信媒体３としても、Ｅthernetに
よる１０ＢＡＳＥ−Ｔや１００ＢＡＳＥ−ＴＸであって
も、Token-ringを用いたＬＡＮや、無線通信であって
も、光ファイバ通信であってもよく、公衆回線を介して
もよく、これらに限定されない。

【００２３】つぎに、サーバ側１は、サーバ側アプリケ
ーションプログラム１０、サーバ側トランスポートプロ
トコル１１、サーバ側物理層１２、課金情報蓄積手段１
３から構成される。また、クライアント側２は、クライ
アント側アプリケーションプログラム２０、クライアン
ト側トランスポートプロトコル２１、クライアント側物
理層２２から構成される。

【００２４】サーバ側物理層１２、およびクライアント
側物理層２２は、通信媒体３を用いて相互に通信するた
めのハードウェア・ソフトウェアであり、Ethernetや無
線通信等がこれに該当する。次に、サーバ側トランスポ
ートプロトコル１１、およびクライアント側トランスポ
ートプロトコル２１は、それぞれの物理層１２，２２を
用いてデータ通信する場合において、相互に確実なデー
タを可能にすることを保証するものである。サーバ側ア
プリケーションプログラム１０は、サーバ側トランスポ
ートプロトコル１１を用いて、クライアント側アプリケ
ーションプログラム２０に何らかのデータを送信するア
プリケーションであり、また、クライアント側アプリケ
ーションプログラム２０は、サーバ側アプリケーション
プログラム１０から送られてくるデータを、クライアン
ト側トランスポートプロトコル２１を用いて受信するア
プリケーションである。

【００２５】次に、サーバ側トランスポートプロトコル
１１を詳細に示したものが図３である。サーバ側トラン
スポートプロトコル１１は、送信データ記憶手段１１
０、暗号化キー生成手段１１１、暗号化手段１１２、復
号化キー記憶手段１１３、サーバ側パケット生成手段１
１４、サーバ側受信パケット解釈手段１１５から構成さ
れる。

【００２６】ここで、送信データ記憶手段１１０は、サ
ーバ側アプリケーションプログラム１０からクライアン
ト側アプリケーション２０へ送信するように依頼を受け
たデータを一時的に格納するものである。暗号化キー生
成手段１１１は、データを暗号化するためのキーと復号
化するためのキーを生成する手段である。暗号化手段１
１２は、送信データ記憶手段１１０のある部分のデータ
を、暗号化キー生成手段１１１から受け取ったキーをも
とに暗号化するものである。ここでの暗号化の方法は、
キーを受信しない限り容易に復号化できない方法であれ
ば、どのような暗号化のアルゴリズムでもよい。例え
ば、公開鍵暗号方式と秘密鍵暗号方式があり、秘密鍵暗
号方式の一つとしてのＤＥＳ（Data Encryption Stabda
rd）方式や、米国ＲＳＡ方式、ＦＥＡＬ方式等が用いら
れ得る。

【００２７】復号化キー記憶手段１１３は、暗号化され
た個々のデータを識別するための識別子（たとえば、Ｔ
ＣＰのシーケンス番号に相当）と、それを復号化するの
に必要なキーの対を、一時的に記憶するものである。サ
ーバ側パケット生成手段１１４は、サーバ側アプリケー
ションプログラム１０、およびサーバ側受信パケット解
釈手段１１５からの要求に基づき、クライアント側トラ
ンスポートプロトコル２１に送信するパケットを生成
し、それをサーバ側物理層１２に引き渡す。サーバ側受
信パケット解釈手段１１５は、クライアント側トランス
ポートプロトコル２１からのパケットをサーバ側物理層
１２を通して受けとり、そのパケットが何のパケットで
あるかを解釈し、次に何のパケットを送出すべきかを判
断し、送出すべきパケットがあれば、サーバ側パケット
生成手段１１４にパケットの送出を依頼するものであ
る。

【００２８】また、サーバ側受信パケット解釈手段１１
５で解釈した結果、課金情報が生じた場合、その情報を
課金情報蓄積手段１３にその情報を蓄積する。

【００２９】次に、クライアント側トランスポートプロ
トコル２１を詳細に示したものが図４である。クライア
ント側トランスポートプロトコル２１は、クライアント
側受信パケット解釈手段２１０、未復号データ記憶手段
２１１、復号化手段２１２、クライアント側パケット生
成手段２１３、受信データ記憶手段２１４から構成され
る。

【００３０】ここで、クライアント側受信パケット解釈
手段２１０は、サーバ側トランスポートプロトコル１１
からクライアント側物理層２２を通して受信したパケッ
トを解釈し、次にサーバ側トランスポートプロトコル１
１に対して送出すべきパケットが何であるかを判断し、
送出すべきパケットがあれば、クライアント側パケット
送出手段２１３に対してパケットの送出を依頼するもの
である。もし暗号化されたデータを受信したならば、そ
の暗号化されたデータを未復号データ記憶手段２１１に
送る。また、サーバ側トランスポートプロトコル１１か
ら暗号化キーを受信した場合は、そのキーを復号化手段
２１２に送る。未復号データ記憶手段２１１は、クライ
アント側受信パケット解釈手段２１０から依頼を受け
た、復号化されていないデータを一時的に記憶するもの
である。

【００３１】また、復号化手段２１２は、クライアント
側受信パケット解釈手段２１０より復号化キーを受け取
ると、それで復号化できるデータを未復号データ記憶手
段２１１より取りだし、そのデータを復号化し、受信デ
ータ記憶手段２１４に送る。受信データ記憶手段２１４
は、復号化されたデータを一時的に記憶し、クライアン
ト側アプリケーションプログラム２０からの読み出され
るまで蓄えておく。クライアント側アプリケーションプ
ログラム２０は、受信データ記憶手段２１４からの復号
化されたデータを用いてアプリケーションプログラムを
実行し、所定の業務を遂行する。

【００３２】（本実施形態の動作の説明）次に、シーケ
ンス図５、および図３および図４を参照して本実施形態
の全体の動作について詳細に説明する。

【００３３】まず、図５のＡ(Data)に示すように、サー
バ側アプリケーションプログラム１０がサーバ側トラン
スポートプロトコル１１にデータの送信を依頼したとす
る。すると、それらのデータは図３の送信データ記憶手
段１１０に一時的に蓄えられる。そして、サーバ側パケ
ット生成手段１１４が要求されたデータをパケットとし
て送信するとき、送信するパケットサイズ分を暗号化手
段１１２が送信データ記憶手段１１０から読みこみ、そ
れを暗号化キー生成手段１１１によって生成された暗号
化キーを用いて暗号化する。そして、暗号化手段１１２
は、この暗号化されたデータを表す識別子と、このデー
タを復号化するのに必要なキーとを対として、復号化キ
ー記憶手段１１３に記憶させる。これらの動作は図５の
Ｂの間に行う。そして、データ部分のみ暗号化されたパ
ケットを図５のＣ(encoded Data(1))に示すように送信
する。

【００３４】そして、以降残りのデータ（図５の例では
Ｅ(encoded Data(2))，Ｇ(encodedData(3))に相当）に
ついても同様に暗号化して送信する。この際、パケット
毎に別々のキーを用いて暗号化する必要はなく、ある適
切なデータサイズ（たとえば、ＴＣＰのウィンドウサイ
ズや課金単位のデータサイズなど）分については、同じ
暗号化キーを用いて暗号化しても良い（本例では、パケ
ットＣ，Ｅ，Ｇのデータは、同じ暗号化キーで暗号化さ
れたものとする）。

【００３５】次に、クライアント側について説明する。
クライアント側はデータＣ(encodedData(1))を受信した
とき、図５のＤの間に、まずクライアント側受信パケッ
ト解釈手段２１０により、それがサーバ側から送信され
てきた暗号化されたデータであることを認識し、その暗
号化されたデータとその識別子を未復号データ記憶手段
２１１に蓄える。以降、Ｅ(encoded Data(2))，Ｇ(enco
ded Data(3))についても同様に暗号化されたデータを、
それぞれ図５のＦ，Ｈの間に未復号データ記憶手段２１
１に蓄える。

【００３６】そして、クライアント側はある時点でデー
タの信頼性を保証するために確認応答をサーバ側に対し
送信するが、本例ではクライアント側がデータパケット
Ｇ(encoded Data(3))を受信した後の時点Ｈで確認応答
を返すものとする。この時点では、クライアント側トラ
ンスポートプロトコル２１は、これまで受信したデータ
を復号するためのキーを持っていないため、この時点で
データをクライアント側アプリケーションに渡すことは
できない。

【００３７】確認応答をサーバ側物理層１２を通して受
信したサーバ側受信パケット解釈手段１１５は、クライ
アント側トランスポートプロトコル２１がデータのパケ
ットＣ，Ｅ，Ｇを受信したことを、この確認応答により
知ることができる。そこで、サーバ側受信パケット解釈
手段１１５は、図５のＫ(Bill(1,2,3))に示すように課
金情報蓄積手段１３に対し、パケットＣ，Ｅ，Ｇで送出
されたデータに対する課金情報を書きこむ。

【００３８】そして、サーバ側受信パケット解釈手段１
１５はサーバ側パケット生成手段１１４に対し、パケッ
トＣ，Ｅ，Ｇで送出されたデータを復号化するためのキ
ー(key)をクライアント側トランスポートプロトコル２
１に対し送信するよう要求する。要求を受けたサーバ側
パケット生成手段１１４は、復号化キー記憶手段１１３
から該当する復号化キーを読み出し、そのキー情報を図
５のＬ(key)に示すように、キーとそのキーで復号化で
きるデータの識別子の対をクライアント側トランスポー
トプロトコル２１に対し送信する。このとき、もし次に
送信すべきデータが存在すれば、そのデータの暗号化さ
れたパケットにキーを相乗りさせても構わない。以上の
動作を図５のＪの間に行う。

【００３９】次に、図５のＬ(key)に示すキーが含まれ
たパケットは、クライアント側物理層２２を通し、クラ
イアント側受信パケット解釈手段２１０に送られる。ク
ライアント側受信パケット解釈手段２１０は、受信した
パケットに含まれるキーを復号化手段２１２に送る。復
号化手段２１２は、そのキーの有効なデータの識別子を
参照して、未復号データ記憶手段２１１からデータを読
み出し、そして復号化し、復号化したデータを受信デー
タ記憶手段２１４に書きこむ。受信データ記憶手段２１
４にデータが書きこまれることによって、図５のＮ(Dat
a(1,2,3))に示すように、クライアント側アプリケーシ
ョンプログラム２０は受信したデータを読み込むことが
可能になる。以上の動作をＭの間に行う。

【００４０】以上でデータ送信の１サイクルを示した
が、このサイクルを繰り返すことでデータの送信を行
う。

【００４１】なお、上記実施形態では、通信プロトコル
によるネットワーキングの通信経路の接続については説
明していないが、サーバ側アプリケーションからデータ
Ａが送信される前に通信経路が確立されているものとし
て説明している。

【００４２】また、未復号データ記憶手段２１１や送信
データ記憶手段１１０、復号化キー記憶手段１１３、受
信データ記憶手段２１４、課金情報蓄積手段等の記憶手
段の記憶容量は充分備えられているものとして説明した
が、例えば未復号データ記憶手段２１１の記憶容量が不
足した場合には、事前に適当容量のパケットが送信され
た時点で課金計算できるように、確認応答Ｉと暗号キー
Ｌの送信受信を行うものである。

【００４３】また、本実施形態において、暗号化キーと
復号化キーとは、サーバと特定のクライアント間と統一
的に定めておけば課金処理が簡単であるが、その分秘密
性や確実性、安全性等のサービス性に欠けるので、デー
タ送受信毎に暗号化キーと復号化キーを変更することが
好ましい。その場合、対称暗号方式のＤＥＳ（data enc
ryption standard）方式ののＥＣＢ（electro codeboo
k）モード，ＣＢＣ（ciper block chaining）モード，
ＣＦＢ（cipher feedback）モード，ＯＦＢ（output fe
edback）モードのいずれでも、ＦＥＡＬ（fast encrypt
ion algorithm）方式等、また非対称暗号方式のＲＡＳ
（Rivest,Shamir,Adleman）方式、エルガマル（ElGama
l）方式、ラビン（Rabin）方式、ナップザック暗号方式
等のいずれを用いてもよく、秘密性と安全性とサービス
性等から定めればよい。そうして、サーバ１から送信デ
ータを暗号化した暗号化キーに対応して、クライアント
側２では受信した復号化キーを用いて復号化手段２１２
内の復号化プログラムに従って予め蓄積した未復号デー
タを復号し、受信データ記憶手段に２１４に蓄積して、
アプリケーションプログラムに従って動作する。

【００４４】［第２の実施形態］本実施形態は、図６に
示すように、あるデータを暗号化してデータを送出しよ
うとする時点で、まだ確認応答取れていない以前のデー
タのパケットが存在した場合、そのデータに関しても復
号化を可能にするような復号化キーに対応した暗号化キ
ーで暗号化することである。

【００４５】たとえば、図６のＡのデータがサーバ側ト
ランスポートプロトコル１１に送信され、パケットＢ(D
ata(1) encoded by key(x))，Ｃ(Data(2) encoded by k
ey(x))がクライアント側トランスポートプロトコル２１
に送信されたとする。図６のＤの時点では、パケットＢ
(Data(1) encoded by key(x))，Ｃ(Data(2) encodedby
key(x))のデータに対する確認応答は受信していないの
で、そこで次に送信するパケットＥ(Data(3) encoded b
y key(x'))，Ｆ(Data(4) encoded by key(x'))のデータ
は、パケットＢ，Ｃのデータを暗号化したキーｘと異な
るキーｘ’で暗号化するが、それを復号化するときは同
じ一つの復号化キーｙ’でパケットＢ，Ｃ，Ｅ，Ｆのデ
ータを復号化できるような暗号化キーｘ’を用いて暗号
化する。

【００４６】すると、図７のシーケンス図のように、サ
ーバ側はクライアント側に対し、複数のキーを送信する
必要が生じて、１パケットですべてのキーが送信不可能
になった場合、本実施形態の方法を用いると、一つの復
号化キーｙ’で対処でき、複数のパケットでキーを送信
することを避けることが可能になる。

【００４７】このような暗号化キーｘ，ｘ’及び復号化
キーｙ’を達成する暗号化キーの存在は、公にされてい
ないが、暗号化技術により、例えば復号化キーｙ’に対
応するビット数の上位ビットを暗号化キーｘとし、その
ビット数の下位ビットを暗号化キーｘ’とすることで、
当該実施形態の目的を実行できる。

【００４８】［第３の実施形態］本発明による第３の実
施形態について説明する。図８を参照すると、サーバ側
トランスポートプロトコル１５の上位にサーバ側課金手
段１４が、そしてクライアント側トランスポート側プロ
トコル２４の上位層にクライアント側課金手段２３が新
たに追加されている。なお、図１と同一部分については
同一符号を付し、重複する説明を省略している。

【００４９】この場合のサーバ側トランスポートプロト
コル１５、クライアント側トランスポートプロトコル２
４のプロトコルは、データ通信の信頼性を保証するもの
であれば、ＴＣＰ等のどのようなトランスポートプロト
コルでも良い。

【００５０】このとき、図９にサーバ側課金手段１４の
詳細図、図１０にクライアント側課金手段２３の詳細図
を示す。図９を参照すると、サーバ側課金手段１４は、
送信データ記憶手段１４０、暗号化キー生成手段１４
１、暗号化手段１４２、復号化キー記憶手段１４３、サ
ーバ側パケット生成手段１４４、サーバ側受信パケット
手段１４５から構成される。

【００５１】また、クライアント側課金手段２３は、ク
ライアント側受信パケット解釈手段２３０、未復号デー
タ記憶手段２３１、復号化手段２３２、クライアント側
パケット生成手段２３３、および受信データ記憶手段２
３４から構成される。

【００５２】次に、図１１のシーケンス図、および図
９、図１０を参照して本実施形態の全体の動作について
詳細に説明する。

【００５３】まず、図１１のＡ(Data)に示すように、サ
ーバ側アプリケーションプログラム１０がサーバ側課金
手段１４へデータの送信の依頼をしたとする。すると、
それらのデータは図９の送信データ記憶手段１４０に一
時的に蓄えられる。そして、サーバ側パケット生成手段
１４４が要求されたデータをパケットとして送信すると
き、送信するデータサイズ分を暗号化手段１４２が送信
データ記憶手段１４０から読みこみ、それを暗号化キー
生成手段１４１によって生成された暗号化キーを用いて
暗号化する。そして、暗号化手段１４２は、この暗号化
されたデータを表す識別子とこのデータを復号化するの
に必要なキーを対として復号化キー記憶手段１４３に記
憶させる。これらの動作は図１１のＢの間に行う。

【００５４】そして、データ部分のみ暗号化されたパケ
ットを、図１１のＣ(encoded Data(1))に示すように送
信する。そして、以降残りのデータ（図１１の例ではＥ
(encoded Data(2))，Ｇ(encoded Data(3))に相当）につ
いても同様に暗号化して送信する。この際、パケット毎
に別々のキーを用いて暗号化する必要はなく、ある適切
なデータサイズ（たとえば、ＴＣＰのウィンドウサイズ
や課金単位のデータサイズなど）分については、同じ暗
号化キーを用いて暗号化しても良い。本例では、図１１
のパケットＣ(encoded Data(1))，Ｅ(encoded Data
(2))，Ｇ(encoded Data(3))のデータは同じ暗号化キー
で暗号化されたものとする。

【００５５】次に、クライアント側について説明する。
クライアント側はパケットＣ(encoded Data(1))を受信
したとき、図１１のＤの間に、まずクライアント側受信
パケット解釈手段２３０により、それがサーバ側から送
信されてきた暗号化されたデータであることを解釈・認
識し、その暗号化されたデータＣとその識別子を未復号
データ記憶手段２３１に蓄える。以降、Ｅ，Ｇについて
も同様に暗号化されたデータとその識別子を、それぞれ
図１１のＦ，Ｈの間に未復号データ記憶手段２３１に蓄
える。そして、クライアント側受信パケット解釈手段２
３０は、ある時点においてこれまで受信したデータを復
号化するための復号化キーを要求する。本例では、図１
１のＨの時点から、Ｉ(Key Request(1,2,3)によってサ
ーバ側トランスポート層プロトコル１５にキー要求を送
信する。

【００５６】このキー要求を、サーバ側トランスポート
プロトコル１５を通して受信したサーバ側受信パケット
解釈手段１４５は、クライアント側課金手段２３がデー
タのパケットＣ，Ｅ，Ｇを受信したことを、このキー要
求により知ることができる。そこで、サーバ側受信パケ
ット解釈手段１４５は、図１１のＫ(Bill(1,2,3))に示
すように課金情報蓄積手段１６に対し、パケットＣ，
Ｅ，Ｇで送出されたデータに対する課金情報を書きこ
む。そして、サーバ側受信パケット解釈手段１４５はサ
ーバ側パケット生成手段１４４に対し、パケットＣ，
Ｅ，Ｇで送出されたデータを復号化するためのキーをク
ライアント側課金手段２４に対し送信するよう要求す
る。要求を受けたサーバ側パケット生成手段１４４は、
復号化キー記憶手段１４３から該当する復号化キーを読
み出し、そのキー情報を図１１のＬに示すように、キー
とそのキーで復号化できるデータの識別子の対をクライ
アント側課金手段２３に対し送信する。

【００５７】このとき、もし次に送信すべきデータが存
在すれば、そのデータの暗号化されたパケットにキーを
相乗りさせても構わない。以上の動作を図１１のＪの間
に行う。

【００５８】次に、図１１のＬ(key)に示すキーの含ま
れているパケットは、クライアント側トランスポートプ
ロトコル２４を通し、クライアント側受信パケット解釈
手段２３０に送られる。クライアント側受信パケット解
釈手段２３０は、受信したパケットに含まれるキーを復
号化手段２３２に送る。復号化手段２３２は、そのキー
の有効なデータの識別子を参照して、未復号データ記憶
手段２３１からデータを読み出し、そして復号化し、復
号化したデータを受信データ記憶手段２３４に書きこ
む。受信データ記憶手段２３４にデータが書きこまれる
ことによって、図１１のＮ(Data(1,2,3))に示すよう
に、クライアント側アプリケーションプログラム２０は
受信したデータを読み込むことが可能になる。以上の動
作をＭの間に行う。

【００５９】以上で、データ送信の１サイクルを示した
が、このサイクルを繰り返すことでデータの送信を行
う。

【００６０】本実施形態では、ＴＣＰ等既存のトランス
ポートプロトコルを用いて、データ量に応じて確実に課
金できる仕組みを提供できる。また、データ通信の信頼
性がサーバ側課金手段、クライアント側課金手段の下位
に位置するサーバ側トランスポートプロトコル、クライ
アント側トランスポートプロトコルで保証されているた
め、キー送信パケットの喪失によるキーの再送等を考慮
する必要がなくなり、課金のためのプロトコルがシンプ
ルになる。

【００６１】［第４の実施形態］本発明による第４の実
施形態について説明する。図１２を参照すると、本図の
構成は図３と同様であるが、サーバ側パケット生成手段
１１４が送信データ１１０から直接データを受け取る手
段を新たに追加されている。また、図１３を参照する
と、本図の構成も図４と同様であるが、クライアント側
受信パケット解釈手段２１０が受信データ記憶手段２１
４へ直接書きこむ手段が新たに追加されている。なお、
図３及び図４と同一部分には同一符号を付し、重複する
説明を省略している。

【００６２】次に、シーケンス図１４を用いて本実施形
態を詳細に説明する。図１４において、Ａ〜Ｍの動作に
ついて、Ｃ，Ｅ，Ｇのパケットにデータが暗号化されて
いることを示す識別子が含まれており、その点以外は上
述の第１の実施形態の（実施形態の動作の説明）と同様
であるので説明を省略する。

【００６３】次に、図１４のＯ(Data)に示すように、サ
ーバ側アプリケーションプログラム１０からサーバ側ト
ランスポートプロトコル１１へデータの送信の依頼があ
ったとする。このときのデータは無料とする。このよう
な無料のデータの場合、送信データ記憶手段１１０に
は、無料であることを示す識別子とともに格納される。
そして、無料データの送信の依頼を受けたサーバ側パケ
ット生成手段１１４は、暗号化手段１１２を経由せず、
直接送信データ記憶手段１１０からデータを読み出す。
そして、そのデータを無料データが入っていることを示
す識別子とともにパケットとしてサーバ側物理層１２へ
送り、図１４のＰ(Data(4))に示すようにクライアント
側トランスポートプロトコル２１へ送信する。以降同様
に繰り返し、図１４のＱ(Data(5))，Ｒ(Data(6))に示す
ように残りのデータを送信する。

【００６４】データの含まれたパケットを受信したクラ
イアント側トランスポートプロトコル内の、クライアン
ト側受信パケット解釈手段２１０は、受信したパケット
内に無料データである識別子により、パケット内のデー
タが無料であることを知る。そこで、クライアント側受
信パケット解釈手段２１０は、受信したデータを未復号
データ記憶手段２１１には送らずに、直接受信データ記
憶手段２１４に送る。受信データ記憶手段２１４に蓄え
られたデータは、サーバ側トランスポートプロトコル１
１から制約を受けることなしに、クライアント側アプリ
ケーションプログラムから読みこまれることが可能であ
る（図１４のＴ(Data(5,6,7))）。

【００６５】以上のようにすることで、有料データと無
料データの混在したデータを送信することが可能にな
る。なお、第３の実施形態においても、本実施形態を適
用することで、第３の実施形態の構成でも有料データと
無料データの混在したデータを送信することが可能であ
る。

【００６６】尚、上記実施形態では、一方をサーバと
し、他方をクライアントとして説明したが、一方にサー
バの機能とクライアントの機能とを合わせ持つ設備を有
した通信システムのノードやルータ等であってもよい。

【００６７】また、上記実施形態で、通信媒体は特に限
定していないが、Ｅthernetによる１０ＢＡＳＥ−Ｔや
１００ＢＡＳＥ−ＴＸであっても、Token-ringを用いた
ＬＡＮや、無線通信であっても、光ファイバ通信であっ
てもよく、公衆回線を介してもよく、これらに限定され
ない。また、図１５に示した複数のパケット交換局３，
４を介して、端局１としてのサーバと、端局２としての
クライアントとで上記各実施形態で示した本発明を実行
してもよい。

【００６８】また、通信システム的に、課金情報蓄積手
段は双方に保管していても、又通信相手に移管していて
もよく、１日または月毎に課金に関して清算することに
しておけば、相互に課金情報を蓄積するミスがなくなれ
ば、サービスへの不信感も生じない。

【００６９】また、上記実施形態で、データはパケット
形式として送受信した例を示したが、パケット形式には
特に限定されず、アナログ形式の公衆電話回線を用いる
場合にはデータ量やデータ送信時間等を対象に課金可能
であり、他方、Ethernet方式による可変長データビット
の形式でも、ＡＴＭの固定長ビット形式のデータ伝送で
あってもよい。

【００７０】

【発明の効果】本発明によれば、第１に、サーバ側の課
金の方法が、クライアント側から送られてきた確認応答
に基づくので、クライアント側が受信したデータ量に応
じた課金が可能となる。

【００７１】また、第２に、サーバ側から暗号化された
データを送信し、サーバ側が課金処理を行った後に、初
めてクライアント側が受信したデータを復号化できるの
で、クライアント側が不正にデータを取得することを不
可能にすることができる。従って、課金徴収に正当な保
護が与えられ、データの送受信を行うサーバ側とクライ
アント側との信頼関係が確立すると共に、当該通信シス
テムに加入しているサーバやクライアントのトータル的
なサービスの信頼性が向上する。

【図面の簡単な説明】

【図１】本発明による実施形態の通信システムの構成図
である。

【図２】本発明による実施形態の通信シーケンス図であ
る。

【図３】本発明による実施形態のサーバ側の構成ブロッ
ク図である。

【図４】本発明による実施形態のクライアント側の構成
ブロック図である。

【図５】本発明による実施形態の通信シーケンス図であ
る。

【図６】本発明による実施形態の通信シーケンス図であ
る。

【図７】本発明による実施形態の通信シーケンス図であ
る。

【図８】本発明による実施形態の通信システムの構成図
である。

【図９】本発明による実施形態のサーバ側の構成ブロッ
ク図である。

【図１０】本発明による実施形態のクライアント側の構
成ブロック図である。

【図１１】本発明による実施形態の通信シーケンス図で
ある。

【図１２】本発明による実施形態のサーバ側の構成ブロ
ック図である。

【図１３】本発明による実施形態のクライアント側の構
成ブロック図である。

【図１４】本発明による実施形態の通信シーケンス図で
ある。

【図１５】従来例によるパケット通信構成図とシーケン
ス図である。

【符号の説明】

１データ送信側（サーバ）２データ受信側（クライアント）３通信媒体１０サーバ側アプリケーションプログラム１１サーバ側トランスポートプロトコル１２サーバ側物理層１３サーバ側課金蓄積手段１４サーバ側課金手段１５サーバ側トランスポートプロトコル１６課金情報蓄積手段２０クライアント側アプリケーションプログラム２１クライアント側トランスポートプロトコル２２クライアント側物理層２３クライアント側課金手段２４クライアント側トランスポートプロトコル１１０，１４０送信データ記憶手段１１１，１４１暗号化キー生成手段１１２，１４２暗号化手段１１３，１４３暗号化キー記憶手段１１４，１４４サーバ側パケット生成手段１１５，１４５サーバ側受信パケット解釈手段２１０，２３０クライアント側受信パケット解釈手段２１１，２３１未復号データ記憶手段２１２，２３２復号化手段２１３，２３３クライアント側パケット生成手段２１４，２３４受信データ記憶手段

Claims

【特許請求の範囲】

【請求項１】サーバから暗号化した課金対象のデータ
をクライアントへ送信する課金徴収方法において、前記サーバは前記クライアントへ送信した後、前記課金
対象のデータを受信した前記クライアントから確認応答
信号を受信し、前記サーバは前記課金対象のデータに基
づいて課金演算して後、前記課金を課金蓄積手段に蓄積
し、前記クライアントへ前記課金対象のデータを復号化
する復号化キーを送信することを特徴とする課金徴収方
法。
【請求項２】前記クライアントは、前記サーバから前
記課金対象のデータを未復号データ記憶手段に格納した
後、前記確認応答信号を前記サーバに送出し、前記復号
化キーを受信して前記未復号データ記憶手段に格納され
た前記課金対象のデータを復号化することを特徴とする
請求項１に記載の課金徴収方法。
【請求項３】前記サーバは、前記クライアントへの前
記課金対象のデータを暗号化キーによって暗号化して前
記クライアントへ送信し、前記確認応答信号を受信して
前記課金対象のデータに基づいて課金演算し、前記課金
蓄積手段に格納し、前記復号化キーを前記クライアント
へ送信することを特徴とする請求項１又は２に記載の課
金徴収方法。
【請求項４】請求項１又は２，３に記載の課金徴収方
法において、前記課金対象のデータは前記サーバから前
記クライアントへパケット形式により送出されることを
特徴とする課金徴収方法。
【請求項５】サーバから暗号化した課金対象データを
クライアントへ送信する課金徴収装置において、前記クライアントは前記課金対象データを受信したとき
ＯＳＩ（Open SystemsInterconnection）参照モデルの
第１レイヤを通して前記サーバへ確認応答信号を送出す
る応答信号送出手段を有し、前記サーバは、前記確認応答信号を受信したとき前記課
金対象データに基づいて課金演算処理する課金演算処理
部と、前記確認応答信号を受信したとき前記クライアン
トへ前記課金対象データを復号化する復号化キーを送信
する復号化キー送信手段とを備えたことを特徴とする課
金徴収装置。
【請求項６】前記クライアントは前記サーバから前記
課金対象のデータを格納する未復号データ記憶手段と、
前記確認応答信号を前記サーバに送出する前記応答信号
送出手段と、前記復号化キーを受信して前記未復号デー
タ記憶手段に格納された前記課金対象データを復号化す
る復号化手段とを有することを特徴とする請求項５に記
載の課金徴収装置。
【請求項７】前記サーバは、前記クライアントへの前
記課金対象データを暗号化キーによって暗号化する暗号
化手段と、前記クライアントへ前記暗号化手段で暗号化
された前記課金対象データを送信する送信手段と、前記
確認応答信号を受信して前記課金対象データに基づいて
課金演算する前記課金演算処理部と、前記復号化キーを
前記クライアントへ送信する復号化キー送信手段とを備
えたことを特徴とする請求項５又は６に記載の課金徴収
装置。
【請求項８】サーバから暗号化した課金対象データを
クライアントへ送信する通信システムにおいて、前記サーバは、暗号化した課金対象データを前記クライ
アントへ送信するデータ送信手段と、前記クライアント
からの確認応答信号を受信して前記課金対象データに基
づいて課金演算処理する課金演算処理部と、前記確認応
答信号を受信して前記クライアントへ前記課金対象デー
タを復号化する復号化キーを送信する復号化キー送信手
段とを備え、前記クライアントは、前記課金対象データを受信して未
復号データとして格納する記憶手段と、前記記憶手段に
格納すると共に前記サーバへ確認応答信号を送出する応
答信号送出手段と、前記復号化キーを受信して前記前記
課金対象データを復号化する復号化手段とを備えたこと
を特徴とする通信システム。
【請求項９】請求項８に記載の通信システムにおい
て、前記サーバの前記データ送信手段は無料データをも
送信するデータ送信手段であり、前記クライアントの前
記応答信号送出手段は前記無料データを受信したとき前
記確認応答信号を送出し又は送出しない応答信号送出手
段であることを特徴とする通信システム。