課金システム、課金方法
【課題】移動通信端末の通信データ量算出処理を効率良く行う。
【解決手段】通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を通信制御部２１で抽出し、この抽出されるデータ量情報を通信データ量ＤＢ２３に蓄積する。通信データ量ＤＢ２３に蓄積されたデータ量情報に基づいてデータ量を算出し、そのデータ量に応じて課金処理を行う。通信データの抽出を行うデータ量抽出手段と、通信データ量の算出を行う算出手段との間に、通信データ量を蓄積する手段を設けているので、通信データの抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができる。また、抽出されたデータ量情報が所定量を超えた場合に限り、通信データ量ＤＢ２３に蓄積するように構成すれば、通信データ量ＤＢ２３に対する入出力処理による処理遅延を低減できる。
【解決手段】通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を通信制御部２１で抽出し、この抽出されるデータ量情報を通信データ量ＤＢ２３に蓄積する。通信データ量ＤＢ２３に蓄積されたデータ量情報に基づいてデータ量を算出し、そのデータ量に応じて課金処理を行う。通信データの抽出を行うデータ量抽出手段と、通信データ量の算出を行う算出手段との間に、通信データ量を蓄積する手段を設けているので、通信データの抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができる。また、抽出されたデータ量情報が所定量を超えた場合に限り、通信データ量ＤＢ２３に蓄積するように構成すれば、通信データ量ＤＢ２３に対する入出力処理による処理遅延を低減できる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は課金システム、課金方法に関し、特に携帯電話端末をはじめとする移動通信端末における課金システム、課金方法に関する。
【背景技術】
【０００２】
移動通信端末の通信における、データ量算出の方法としてＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のパケット情報とＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のパケット情報とを、一連の処理によって収集してデータ量を算出する課金システムが知られている（例えば、特許文献１参照）。
また、メッセージキュー経由によるデータ読み出しと解析処理により移動通信端末とコンテンツ提供サーバとの間の送達及び再送確認に基づいたデータ量算出を行って、移動通信端末の通信におけるパケットデータ量を算出する方式もある（例えば、非特許文献１参照）。
【０００３】
【特許文献１】特開２０００−２０９２００号公報
【非特許文献１】２００３年電子情報通信学会総合大会Ｂ−６−２４０
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、上記従来技術にかかる課金システムは、以下に示すような問題点があった。すなわち、上記従来技術にかかる課金システムはデータ量算出に用いる、ＴＣＰのパケット情報とＨＴＴＰのパケット情報を抽出した後に、通信データ量算出に至る処理を一連の処理として行っている。そのため、移動通信端末の通信量が多くなる場合、上記パケット情報から通信データ量を算出する処理に時間がかかるため、通信データ量算出処理が通信制御処理に影響を及ぼす。
本発明は上述した従来技術の問題点を解決するためになされたものであり、その目的は移動通信端末の通信量に応じて、通信データ量算出処理を効率良く行うことのできる課金システム、課金方法を提供することである。
【課題を解決するための手段】
【０００５】
本発明の請求項１による課金システムは、通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出手段（例えば、図１中の通信制御部２１に対応）と、前記データ量抽出手段により抽出されるデータ量情報を蓄積する蓄積手段（例えば、図１中の通信データ量ＤＢ２３に対応）と、前記蓄積手段に蓄積されたデータ量情報に基づいてデータ量を算出する算出手段（例えば、図１中の通信データ量算出部２４に対応）とを含み、前記算出手段によって算出されるデータ量に応じて課金処理を行うことを特徴とする。通信データの抽出を行うデータ量抽出手段と、通信データ量の算出を行う算出手段との間に、通信データ量を蓄積する手段を設けるという構成により、通信データの抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができる。
【０００６】
本発明の請求項２による課金システムは、請求項１において、前記データ量抽出手段によって抽出されたデータ量情報が所定量を超えた場合に限り、前記データ量情報を前記蓄積手段に蓄積することを特徴とする。このように構成すれば、蓄積手段に対する入出力処理による処理遅延を低減できる。
【０００７】
本発明の請求項３による課金システムは、請求項１又は２において、前記データ量情報の前記蓄積手段への蓄積単位は固定長であり、
前記蓄積手段への書き込み回数及び前記蓄積手段からの読み込み回数を管理するアクセス回数管理手段（例えば、図１中の通信データ管理部２２に対応）を更に含み、前記書き込み回数及び前記読み出し回数に基づいて、前記蓄積手段から読み込むべきデータ量情報を特定するようにしたことを特徴とする。書き込み管理テーブル及び読み出し管理テーブルを用いることで、処理すべきデータの順序性を保つことができる。また、固定長のデータを書き込み、読み出すことにより、それらの回数を管理するだけで次に処理すべきデータを特定できる。
【０００８】
本発明の請求項４による課金方法は、通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出ステップと、前記データ量抽出ステップにおいて抽出されるデータ量情報を蓄積する蓄積ステップと、前記蓄積ステップにおいて蓄積されたデータ量情報に基づいてデータ量を算出する算出ステップと、前記算出ステップにおいて算出されるデータ量に応じて課金処理を行う課金ステップとを含むことを特徴とする。通信データ量を蓄積する処理を行うことにより、通信データの抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができる。
【発明の効果】
【０００９】
以上説明したように本発明は、移動通信端末とコンテンツ提供サーバとの間の通信制御において、通信データから抽出したデータ量情報をデータベース（以下、ＤＢと略称する）に蓄積し、このＤＢからデータを読み出してデータ量の算出を行うという構成により、通信データ量の抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができるという効果がある。
また、データ量情報が所定量を超えた場合に限り、ＤＢに蓄積するようにすれば、ＤＢに対する入出力処理による処理遅延を低減できるという効果がある。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施の形態を、図面を参照して説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
（課金システムの構成）
まず、本実施形態にかかる課金システムの構成について説明する。図１は、本実施形態にかかる課金システムの構成を示すブロック図である。同図に示されているように、本実施形態にかかる課金システムは、携帯電話端末などによって構成される移動通信端末１０と、当該移動通信端末１０とコンテンツ提供サーバ３０との接続を行う課金システム２０とから構成されている。本システムは、移動通信端末１０からコンテンツ提供サーバ３０への接続に対する課金を行う機能を有する。
【００１１】
また、課金システム２０は、コネクションの確立と通信の情報の抽出とを行う通信制御部２１と、通信制御部２１において抽出された通信の情報の蓄積及び読出しの管理を行う通信データ管理部２２と、コネクション毎に通信データを蓄積する通信データ量ＤＢ２３と、通信データ量ＤＢ２３の情報を基にコネクション毎に通信量の算出を行う通信データ量算出部２４とを備えて構成されている。このように、通信データの抽出を行う抽出手段である通信制御部２１と、通信データ量の算出を行う算出手段である通信データ量算出部２４との間に、通信データ量を蓄積するバッファとして機能する通信データ量ＤＢ２３を設けているので、通信データの抽出処理と通信データ量の算出処理とを分離でき、通信データ量算出処理の通信制御処理への影響を抑えることができる。
【００１２】
以下、課金システム２０の各構成要素について詳細に説明する。
（通信制御部）
通信制御部２１は、移動通信端末１０とコンテンツ提供サーバ３０とのコネクションを確立し、コネクションの中で行われるＴＣＰヘッダ情報とＨＴＴＰヘッダ情報の抽出を行い、この抽出情報をデータ１００として通信データ管理部２２に送る。
また、通信制御部２１は、移動通信端末１０とコンテンツ提供サーバ３０とを接続するときのコネクションに対してＩＤで管理し、上記抽出情報にコネクションのＩＤを付加する。
さらに、通信制御部２１においては、ＨＴＴＰのデータ量が一定量を超えることを感知し、通信データ管理部２２へ一定量を超えたＨＴＴＰ通信があることを通知する。例えば、ＨＴＴＰヘッダ内のコンテンツサイズが１Ｍｂｙｔｅを超えることを感知し、それを通信データ管理部２２へ通知する。
【００１３】
図２は、通信制御部２１から通信データ管理部２２へ送信されるデータ１００の構造図である。同図に示されているように、本例のデータ１００は、コネクションＩＤ１０１と、サイズ超過フラグ１０２と、ＴＣＰヘッダ情報１０３と、ＨＴＴＰヘッダ情報１０４とから構成されている。サイズ超過フラグ１０２の設定により、一定量を超えたＨＴＴＰ通信があることを通信データ管理部２２へ通知することができる。
【００１４】
（通信データ管理部）
図１に戻り、通信データ管理部２２は、通信制御部２１より送信されたデータ１００に含まれている、ＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を、通信データ量ＤＢ２３に蓄積する。また、通信データ管理部２２は、通信データ量算出部２４からの要求に対して、通信データ量ＤＢ２３に蓄積されたＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を、古いデータから順に通信データ量算出部２４に送信する。
【００１５】
通信データ管理部２２は、図３に示されているように、通信データ量ＤＢ２３に対する書き込みを行うときに使う書き込み管理テーブル２２１と、通信データ量ＤＢ２３に対する読み出しを行うときに使う読み出し管理テーブル２２２とを有しており、通信データ量ＤＢ２３へ書き込むファイルの管理を行う。
ここで、通信制御部２１から送られるＴＣＰヘッダ情報とＨＴＴＰヘッダ情報とのまとまりを、それぞれ１ファイルとして通信データ量ＤＢ２３へ書き込むとファイルの数が増大する。そこで、ファイルの数を削減するために、例えば１日単位のデータ量情報を１ファイルとする。つまり、１日の間でデータ量情報を追加する場合は、別のファイルとして追加して書き込むのではなく、その日のファイル内に追加して書き込む。日付が異なる場合は、別のファイルとして追加して書き込まれることは勿論である。
【００１６】
１日単位のデータ量情報を１つのファイルとしているため、その１つのファイル内の目的とするデータ量情報をアクセスするには、アクセス対象を特定する必要が生じる。このため、本例ではデータ量情報に関するアクセス回数をテーブルに書き込んで管理する。すなわち、書き込み管理テーブル２２１では、通信データ量ＤＢ２３に書き込んだ回数を管理し、読み出し管理テーブル２２２は通信データ量ＤＢ２３から読み込んだ回数を管理する。具体的には、通信データ量ＤＢ２３に書き込まれている「ファイル名」と通信データ量ＤＢ２３への「書き込み回数」とを対応付けて書き込み管理テーブル２２１に書き込み、「ファイル名」と通信データ量ＤＢ２３からの「読み出し回数」とを対応付けて読み出し管理テーブル２２２に書き込む。
【００１７】
そして、データ量情報を通信データ量ＤＢ２３に書き込む時には、ファイルに対して上記ＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を追加し、かつ、上記書き込み管理テーブル２２１のその「ファイル名」に対応する「書き込み回数」を加算する。一方、データ量情報を通信データ量ＤＢ２３から読み出す時には、書き込み管理テーブル２２１と読み出し管理テーブル２２２とを参照して、通信データ量ＤＢ２３に書き込んだ回数と読み出した回数との差を計算し、読み出す対象ファイルの読み出し対象データを特定する。このようにすれば、読み出し対象データを容易に特定できるので、入出力処理による処理遅延を最小限に抑えることができる。
【００１８】
また、ＴＣＰパケット情報から移動通信端末とコンテンツ提供サーバとの間の実際に行われたデータ量を算出し、該当するＨＴＴＰパケット情報のデータ量として課金処理を行うため、通信データ量算出には、ＴＣＰパケット情報とＨＴＴＰパケット情報とを抽出した順序を保つ必要があるが、上記のようにテーブルを用いて管理しているのでデータの順序性を維持できる。
【００１９】
ところで、通信制御部２１から通信データ管理部２２に送るＴＣＰヘッダ情報とＨＴＴＰヘッダ情報との組（すなわちデータ量情報）は固定長で送信する。通信データ管理部２２は、上記固定長のデータがある固定個数（例えば、４２個）たまった場合、または通信制御部２１からのデータ送信がタイムアウトを起こした場合、それらのデータを通信データ量ＤＢ２３へ書き込む。タイムアウトを起こした場合は上記の個数に達していないので、足りない分はダミーデータとして通信データ量ＤＢ２３へ書き込むことでデータを固定個数に保つ（つまり、上記固定個数のデータ全体が固定長に保たれる）。
【００２０】
通信データ管理部２２は、上記一定量を超えたＨＴＴＰ通信の通知を受けると、該当コネクションＩＤを通信データ量ＤＢ２３に蓄積することを決定する。通信データ管理部２２は、通信制御部２１から一定量を超えたＨＴＴＰ通信の通知を受信していないコネクションのＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報は通信データ量ＤＢ２３に書き込まず、通信制御部２１から送られた上記ヘッダ情報をそのまま通信データ量算出部２４へ送る。
（通信データ量ＤＢ）
通信データ量ＤＢ２３は、通信データ管理部２２からの読み出しと、書き込みに対して対象となるファイルの蓄積を行う。通信データ量ＤＢ２３は、磁気ディスクや光学式ディスクを利用して構成される。
【００２１】
（通信データ量算出部）
通信データ量算出部２４は、通信データ管理部２２から受信したＴＣＰヘッダ情報とＨＴＴＰヘッダ情報を基に、移動通信端末１０とコンテンツ提供サーバ３０との間で行われた通信データ量の算出をコネクション毎に行う。
通信データ量算出部２４は、コネクション毎に、ＴＣＰヘッダ情報とＨＴＴＰヘッダ情報とに基づいて、通信データ量の算出を行う。このとき、ＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報は、古いデータから順に算出処理を行う必要がある。このため、通信データ管理部２２は、通信制御部２１により該当コネクションのＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報が一定量を超えたと通知され、通信データ量ＤＢ２３へ書き込まれた場合は、該当コネクションのその後のＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を通信データ量ＤＢ２３へ送る必要がある。この場合、上述した書き込み管理テーブル及び読み出し管理テーブルの機能により、ＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報の順序性を維持することができる。
【００２２】
（課金システムの動作例）
続いて、本実施形態にかかる課金システムの動作について説明する。
図４は、本実施形態にかかる課金システムの動作を示すフローチャートである。本実施形態にかかる課金システムを動作させるにあたっては、まず、通信制御部２１にて、移動通信端末１０とコンテンツ提供サーバ３０とのコネクションの確立を行い、コネクションＩＤの払い出しを行う（ステップＳ１）。その後、移動通信端末１０と課金システム２０内の通信制御部２１との間、コンテンツ提供サーバ３０と課金システム２０内の通信制御部２１との間でそれぞれＨＴＴＰリクエスト及びＨＴＴＰレスポンスの送受信が行われる。
【００２３】
次に、移動通信端末１０とコンテンツ提供サーバ３０との通信について、課金システム２０により、ＴＣＰヘッダ情報とＨＴＴＰヘッダ情報とを抽出して通信データ量を判断する（ステップＳ２）。課金システム２０内の通信制御部２１は、ＨＴＴＰのデータ量が一定量を超えているか否かを判断する（ステップＳ３）。例えば、ＨＴＴＰヘッダ内のコンテンツサイズが１Ｍｂｙｔｅを超えているかどうか判断する。
そして、通信制御部２１は、ＨＴＴＰのデータ量が一定量を超えたことを感知すると、一定量を超えたＨＴＴＰ通信があることを通信データ管理部２２へ通知する（ステップＳ３でＹＥＳ、ステップＳ３ａ）。この通知は、図２中のサイズ超過フラグを例えば「１」に設定することによって行われる。
【００２４】
通信制御部２１から一定量を超えたことを通知されたコネクションの場合（ステップＳ３ａ）、通信データ管理部２２は、抽出したＴＣＰヘッダ情報と、ＨＴＴＰヘッダ情報の組が一定量（例えば、４２個）を超えたか、又は、データ量情報の抽出処理がタイムアウトになったかを判断する（ステップＳ４）。そして、それらの組が一定量に達した場合、又は、データ量の抽出処理がタイムアウトになった場合、通信データ管理部２２は通信データ量情報を通信データ量ＤＢ２３に書き込む（ステップＳ５）。
【００２５】
通信データ算出部２４は、通信データ管理部２２へ通信データ要求を送信する（ステップＳ６）。この場合、通信データ量ＤＢ２３へのアクセスを軽減するために、通信データ要求を順次送信するのではなく、送信後に一定時間の待ち時間を入れた後で、次の通信データ要求を送信するのが望ましい。この一定時間は、移動通信端末１０とコンテンツ提供サーバ３０との通信の頻度を考慮し、例えば１０ｍｓｅｃ程度に設定する。通信データ管理部２２は、通信データ量算出部２４からの通信データ要求（ステップＳ６）を受信すると、通信データ量情報を読み出し（ステップＳ７）、読み出した通信データ量情報を通信データ量算出部２４へ送信する（ステップＳ８）。
【００２６】
一方、通信制御部２１から一定量を超えたことを通知されていないコネクションの場合（ステップＳ３でＮＯ）、ＨＴＴＰのデータ量が一定量を超えていないことを通信データ管理部２２へ通知する（ステップＳ３ｂ）。この通知は、図２中のサイズ超過フラグを例えば「０」に設定することによって行われる。この通知を受けた場合、通信データ管理部２２は、通信データ量情報をそのまま通信データ量算出部２４へ送信する（ステップＳ８）。この場合、通信データ量ＤＢ２３への書き込みを行われない。
通信データ量算出部２４は、通信データ管理部２２から通信データ量情報を受信すると（ステップＳ８）、通信データ管理部２２から受信したＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を基に、移動通信端末１０とコンテンツ提供サーバ３０との間で行われた通信データ量の算出を行う（ステップＳ９）。
【００２７】
以上のように、本例では、ステップＳ３においてＨＴＴＰのデータ量を判断することでデータ量の大略を把握し、把握したデータ量が一定量を超えていない場合は従来通りそのまま通信データ量の算出処理に移行する。一方、把握したデータ量が一定量を超えている場合は通信データ量ＤＢ２３に一旦蓄積しておき、後に読み出してデータ量を厳密に解析することで、通信データ量の算出処理の負荷を低減している。つまり、抽出したデータ量に応じ、その蓄積を行うかどうか切替える手段を設けているので、抽出されたデータ量情報が所定量を超えた場合に限って通信データ量ＤＢ２３への書き込みが行われ、ＤＢへの入出力処理を抑えることができる。
【００２８】
（変形例）
続いて、本実施形態にかかる課金システムの変形例について説明する。
上記実施形態にかかる課金システムは、通信制御部２１と、通信データ管理部２２、通信データ量ＤＢ２３及び通信データ量算出部２４とが同じシステム内にある構成であるが、通信制御部２１とそれ以外の各部とが別構成であってもよい。このようなシステム構成にすることで、通信制御部２１を複数設け、通信データ管理部２２と通信データ量ＤＢ２３とを通信データ量算出部２４に収容することが可能になる。このようにすれば、通信処理を行う構成部分（通信制御部２１）とデータ量算出の処理を行う構成部分（通信データ管理部２２、通信データ量ＤＢ２３、通信データ量算出部２４）とを明確に分離できるので、システムの故障時にその影響範囲を限定することができる。
【００２９】
（課金方法）
以上説明した課金システムにおいては、以下のような課金方法が実現されている。すなわち、通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出ステップと、前記データ量抽出ステップにおいて抽出されるデータ量情報を蓄積する蓄積ステップと、前記蓄積ステップにおいて蓄積されたデータ量情報に基づいてデータ量を算出する算出ステップと、前記算出ステップにおいて算出されるデータ量に応じて課金処理を行う課金ステップとを含む課金方法が実現されている。通信データ量を蓄積する処理を行うことにより、通信データの抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができる。
【産業上の利用可能性】
【００３０】
本発明は、携帯電話端末をはじめとする移動通信端末における課金処理に利用できる。
【図面の簡単な説明】
【００３１】
【図１】本発明の実施形態にかかる課金システムの構成例を示すブロック図である。
【図２】図１中の通信制御部から通信データ管理部へ送信されるデータ構造の例を示す図である。
【図３】図１中の通信データ管理部の内部構成例を示す図である。
【図４】本発明の実施形態にかかる課金システムの動作例を示すフローチャートである。
【符号の説明】
【００３２】
１０ 移動通信端末
２０ 課金システム
２１ 通信制御部
２２ 通信データ管理部
２３ 通信データ量ＤＢ
２４ 通信データ量算出部
３０ コンテンツ提供サーバ
１００ データ
１０１ コネクションＩＤ
１０２ サイズ超過フラグ
１０３ ＴＣＰヘッダ情報
１０４ ＨＴＴＰヘッダ情報
２２１ 書き込み管理テーブル
２２２ 読み出し管理テーブル
【技術分野】
【０００１】
本発明は課金システム、課金方法に関し、特に携帯電話端末をはじめとする移動通信端末における課金システム、課金方法に関する。
【背景技術】
【０００２】
移動通信端末の通信における、データ量算出の方法としてＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のパケット情報とＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のパケット情報とを、一連の処理によって収集してデータ量を算出する課金システムが知られている（例えば、特許文献１参照）。
また、メッセージキュー経由によるデータ読み出しと解析処理により移動通信端末とコンテンツ提供サーバとの間の送達及び再送確認に基づいたデータ量算出を行って、移動通信端末の通信におけるパケットデータ量を算出する方式もある（例えば、非特許文献１参照）。
【０００３】
【特許文献１】特開２０００−２０９２００号公報
【非特許文献１】２００３年電子情報通信学会総合大会Ｂ−６−２４０
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、上記従来技術にかかる課金システムは、以下に示すような問題点があった。すなわち、上記従来技術にかかる課金システムはデータ量算出に用いる、ＴＣＰのパケット情報とＨＴＴＰのパケット情報を抽出した後に、通信データ量算出に至る処理を一連の処理として行っている。そのため、移動通信端末の通信量が多くなる場合、上記パケット情報から通信データ量を算出する処理に時間がかかるため、通信データ量算出処理が通信制御処理に影響を及ぼす。
本発明は上述した従来技術の問題点を解決するためになされたものであり、その目的は移動通信端末の通信量に応じて、通信データ量算出処理を効率良く行うことのできる課金システム、課金方法を提供することである。
【課題を解決するための手段】
【０００５】
本発明の請求項１による課金システムは、通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出手段（例えば、図１中の通信制御部２１に対応）と、前記データ量抽出手段により抽出されるデータ量情報を蓄積する蓄積手段（例えば、図１中の通信データ量ＤＢ２３に対応）と、前記蓄積手段に蓄積されたデータ量情報に基づいてデータ量を算出する算出手段（例えば、図１中の通信データ量算出部２４に対応）とを含み、前記算出手段によって算出されるデータ量に応じて課金処理を行うことを特徴とする。通信データの抽出を行うデータ量抽出手段と、通信データ量の算出を行う算出手段との間に、通信データ量を蓄積する手段を設けるという構成により、通信データの抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができる。
【０００６】
本発明の請求項２による課金システムは、請求項１において、前記データ量抽出手段によって抽出されたデータ量情報が所定量を超えた場合に限り、前記データ量情報を前記蓄積手段に蓄積することを特徴とする。このように構成すれば、蓄積手段に対する入出力処理による処理遅延を低減できる。
【０００７】
本発明の請求項３による課金システムは、請求項１又は２において、前記データ量情報の前記蓄積手段への蓄積単位は固定長であり、
前記蓄積手段への書き込み回数及び前記蓄積手段からの読み込み回数を管理するアクセス回数管理手段（例えば、図１中の通信データ管理部２２に対応）を更に含み、前記書き込み回数及び前記読み出し回数に基づいて、前記蓄積手段から読み込むべきデータ量情報を特定するようにしたことを特徴とする。書き込み管理テーブル及び読み出し管理テーブルを用いることで、処理すべきデータの順序性を保つことができる。また、固定長のデータを書き込み、読み出すことにより、それらの回数を管理するだけで次に処理すべきデータを特定できる。
【０００８】
本発明の請求項４による課金方法は、通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出ステップと、前記データ量抽出ステップにおいて抽出されるデータ量情報を蓄積する蓄積ステップと、前記蓄積ステップにおいて蓄積されたデータ量情報に基づいてデータ量を算出する算出ステップと、前記算出ステップにおいて算出されるデータ量に応じて課金処理を行う課金ステップとを含むことを特徴とする。通信データ量を蓄積する処理を行うことにより、通信データの抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができる。
【発明の効果】
【０００９】
以上説明したように本発明は、移動通信端末とコンテンツ提供サーバとの間の通信制御において、通信データから抽出したデータ量情報をデータベース（以下、ＤＢと略称する）に蓄積し、このＤＢからデータを読み出してデータ量の算出を行うという構成により、通信データ量の抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができるという効果がある。
また、データ量情報が所定量を超えた場合に限り、ＤＢに蓄積するようにすれば、ＤＢに対する入出力処理による処理遅延を低減できるという効果がある。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施の形態を、図面を参照して説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
（課金システムの構成）
まず、本実施形態にかかる課金システムの構成について説明する。図１は、本実施形態にかかる課金システムの構成を示すブロック図である。同図に示されているように、本実施形態にかかる課金システムは、携帯電話端末などによって構成される移動通信端末１０と、当該移動通信端末１０とコンテンツ提供サーバ３０との接続を行う課金システム２０とから構成されている。本システムは、移動通信端末１０からコンテンツ提供サーバ３０への接続に対する課金を行う機能を有する。
【００１１】
また、課金システム２０は、コネクションの確立と通信の情報の抽出とを行う通信制御部２１と、通信制御部２１において抽出された通信の情報の蓄積及び読出しの管理を行う通信データ管理部２２と、コネクション毎に通信データを蓄積する通信データ量ＤＢ２３と、通信データ量ＤＢ２３の情報を基にコネクション毎に通信量の算出を行う通信データ量算出部２４とを備えて構成されている。このように、通信データの抽出を行う抽出手段である通信制御部２１と、通信データ量の算出を行う算出手段である通信データ量算出部２４との間に、通信データ量を蓄積するバッファとして機能する通信データ量ＤＢ２３を設けているので、通信データの抽出処理と通信データ量の算出処理とを分離でき、通信データ量算出処理の通信制御処理への影響を抑えることができる。
【００１２】
以下、課金システム２０の各構成要素について詳細に説明する。
（通信制御部）
通信制御部２１は、移動通信端末１０とコンテンツ提供サーバ３０とのコネクションを確立し、コネクションの中で行われるＴＣＰヘッダ情報とＨＴＴＰヘッダ情報の抽出を行い、この抽出情報をデータ１００として通信データ管理部２２に送る。
また、通信制御部２１は、移動通信端末１０とコンテンツ提供サーバ３０とを接続するときのコネクションに対してＩＤで管理し、上記抽出情報にコネクションのＩＤを付加する。
さらに、通信制御部２１においては、ＨＴＴＰのデータ量が一定量を超えることを感知し、通信データ管理部２２へ一定量を超えたＨＴＴＰ通信があることを通知する。例えば、ＨＴＴＰヘッダ内のコンテンツサイズが１Ｍｂｙｔｅを超えることを感知し、それを通信データ管理部２２へ通知する。
【００１３】
図２は、通信制御部２１から通信データ管理部２２へ送信されるデータ１００の構造図である。同図に示されているように、本例のデータ１００は、コネクションＩＤ１０１と、サイズ超過フラグ１０２と、ＴＣＰヘッダ情報１０３と、ＨＴＴＰヘッダ情報１０４とから構成されている。サイズ超過フラグ１０２の設定により、一定量を超えたＨＴＴＰ通信があることを通信データ管理部２２へ通知することができる。
【００１４】
（通信データ管理部）
図１に戻り、通信データ管理部２２は、通信制御部２１より送信されたデータ１００に含まれている、ＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を、通信データ量ＤＢ２３に蓄積する。また、通信データ管理部２２は、通信データ量算出部２４からの要求に対して、通信データ量ＤＢ２３に蓄積されたＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を、古いデータから順に通信データ量算出部２４に送信する。
【００１５】
通信データ管理部２２は、図３に示されているように、通信データ量ＤＢ２３に対する書き込みを行うときに使う書き込み管理テーブル２２１と、通信データ量ＤＢ２３に対する読み出しを行うときに使う読み出し管理テーブル２２２とを有しており、通信データ量ＤＢ２３へ書き込むファイルの管理を行う。
ここで、通信制御部２１から送られるＴＣＰヘッダ情報とＨＴＴＰヘッダ情報とのまとまりを、それぞれ１ファイルとして通信データ量ＤＢ２３へ書き込むとファイルの数が増大する。そこで、ファイルの数を削減するために、例えば１日単位のデータ量情報を１ファイルとする。つまり、１日の間でデータ量情報を追加する場合は、別のファイルとして追加して書き込むのではなく、その日のファイル内に追加して書き込む。日付が異なる場合は、別のファイルとして追加して書き込まれることは勿論である。
【００１６】
１日単位のデータ量情報を１つのファイルとしているため、その１つのファイル内の目的とするデータ量情報をアクセスするには、アクセス対象を特定する必要が生じる。このため、本例ではデータ量情報に関するアクセス回数をテーブルに書き込んで管理する。すなわち、書き込み管理テーブル２２１では、通信データ量ＤＢ２３に書き込んだ回数を管理し、読み出し管理テーブル２２２は通信データ量ＤＢ２３から読み込んだ回数を管理する。具体的には、通信データ量ＤＢ２３に書き込まれている「ファイル名」と通信データ量ＤＢ２３への「書き込み回数」とを対応付けて書き込み管理テーブル２２１に書き込み、「ファイル名」と通信データ量ＤＢ２３からの「読み出し回数」とを対応付けて読み出し管理テーブル２２２に書き込む。
【００１７】
そして、データ量情報を通信データ量ＤＢ２３に書き込む時には、ファイルに対して上記ＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を追加し、かつ、上記書き込み管理テーブル２２１のその「ファイル名」に対応する「書き込み回数」を加算する。一方、データ量情報を通信データ量ＤＢ２３から読み出す時には、書き込み管理テーブル２２１と読み出し管理テーブル２２２とを参照して、通信データ量ＤＢ２３に書き込んだ回数と読み出した回数との差を計算し、読み出す対象ファイルの読み出し対象データを特定する。このようにすれば、読み出し対象データを容易に特定できるので、入出力処理による処理遅延を最小限に抑えることができる。
【００１８】
また、ＴＣＰパケット情報から移動通信端末とコンテンツ提供サーバとの間の実際に行われたデータ量を算出し、該当するＨＴＴＰパケット情報のデータ量として課金処理を行うため、通信データ量算出には、ＴＣＰパケット情報とＨＴＴＰパケット情報とを抽出した順序を保つ必要があるが、上記のようにテーブルを用いて管理しているのでデータの順序性を維持できる。
【００１９】
ところで、通信制御部２１から通信データ管理部２２に送るＴＣＰヘッダ情報とＨＴＴＰヘッダ情報との組（すなわちデータ量情報）は固定長で送信する。通信データ管理部２２は、上記固定長のデータがある固定個数（例えば、４２個）たまった場合、または通信制御部２１からのデータ送信がタイムアウトを起こした場合、それらのデータを通信データ量ＤＢ２３へ書き込む。タイムアウトを起こした場合は上記の個数に達していないので、足りない分はダミーデータとして通信データ量ＤＢ２３へ書き込むことでデータを固定個数に保つ（つまり、上記固定個数のデータ全体が固定長に保たれる）。
【００２０】
通信データ管理部２２は、上記一定量を超えたＨＴＴＰ通信の通知を受けると、該当コネクションＩＤを通信データ量ＤＢ２３に蓄積することを決定する。通信データ管理部２２は、通信制御部２１から一定量を超えたＨＴＴＰ通信の通知を受信していないコネクションのＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報は通信データ量ＤＢ２３に書き込まず、通信制御部２１から送られた上記ヘッダ情報をそのまま通信データ量算出部２４へ送る。
（通信データ量ＤＢ）
通信データ量ＤＢ２３は、通信データ管理部２２からの読み出しと、書き込みに対して対象となるファイルの蓄積を行う。通信データ量ＤＢ２３は、磁気ディスクや光学式ディスクを利用して構成される。
【００２１】
（通信データ量算出部）
通信データ量算出部２４は、通信データ管理部２２から受信したＴＣＰヘッダ情報とＨＴＴＰヘッダ情報を基に、移動通信端末１０とコンテンツ提供サーバ３０との間で行われた通信データ量の算出をコネクション毎に行う。
通信データ量算出部２４は、コネクション毎に、ＴＣＰヘッダ情報とＨＴＴＰヘッダ情報とに基づいて、通信データ量の算出を行う。このとき、ＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報は、古いデータから順に算出処理を行う必要がある。このため、通信データ管理部２２は、通信制御部２１により該当コネクションのＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報が一定量を超えたと通知され、通信データ量ＤＢ２３へ書き込まれた場合は、該当コネクションのその後のＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を通信データ量ＤＢ２３へ送る必要がある。この場合、上述した書き込み管理テーブル及び読み出し管理テーブルの機能により、ＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報の順序性を維持することができる。
【００２２】
（課金システムの動作例）
続いて、本実施形態にかかる課金システムの動作について説明する。
図４は、本実施形態にかかる課金システムの動作を示すフローチャートである。本実施形態にかかる課金システムを動作させるにあたっては、まず、通信制御部２１にて、移動通信端末１０とコンテンツ提供サーバ３０とのコネクションの確立を行い、コネクションＩＤの払い出しを行う（ステップＳ１）。その後、移動通信端末１０と課金システム２０内の通信制御部２１との間、コンテンツ提供サーバ３０と課金システム２０内の通信制御部２１との間でそれぞれＨＴＴＰリクエスト及びＨＴＴＰレスポンスの送受信が行われる。
【００２３】
次に、移動通信端末１０とコンテンツ提供サーバ３０との通信について、課金システム２０により、ＴＣＰヘッダ情報とＨＴＴＰヘッダ情報とを抽出して通信データ量を判断する（ステップＳ２）。課金システム２０内の通信制御部２１は、ＨＴＴＰのデータ量が一定量を超えているか否かを判断する（ステップＳ３）。例えば、ＨＴＴＰヘッダ内のコンテンツサイズが１Ｍｂｙｔｅを超えているかどうか判断する。
そして、通信制御部２１は、ＨＴＴＰのデータ量が一定量を超えたことを感知すると、一定量を超えたＨＴＴＰ通信があることを通信データ管理部２２へ通知する（ステップＳ３でＹＥＳ、ステップＳ３ａ）。この通知は、図２中のサイズ超過フラグを例えば「１」に設定することによって行われる。
【００２４】
通信制御部２１から一定量を超えたことを通知されたコネクションの場合（ステップＳ３ａ）、通信データ管理部２２は、抽出したＴＣＰヘッダ情報と、ＨＴＴＰヘッダ情報の組が一定量（例えば、４２個）を超えたか、又は、データ量情報の抽出処理がタイムアウトになったかを判断する（ステップＳ４）。そして、それらの組が一定量に達した場合、又は、データ量の抽出処理がタイムアウトになった場合、通信データ管理部２２は通信データ量情報を通信データ量ＤＢ２３に書き込む（ステップＳ５）。
【００２５】
通信データ算出部２４は、通信データ管理部２２へ通信データ要求を送信する（ステップＳ６）。この場合、通信データ量ＤＢ２３へのアクセスを軽減するために、通信データ要求を順次送信するのではなく、送信後に一定時間の待ち時間を入れた後で、次の通信データ要求を送信するのが望ましい。この一定時間は、移動通信端末１０とコンテンツ提供サーバ３０との通信の頻度を考慮し、例えば１０ｍｓｅｃ程度に設定する。通信データ管理部２２は、通信データ量算出部２４からの通信データ要求（ステップＳ６）を受信すると、通信データ量情報を読み出し（ステップＳ７）、読み出した通信データ量情報を通信データ量算出部２４へ送信する（ステップＳ８）。
【００２６】
一方、通信制御部２１から一定量を超えたことを通知されていないコネクションの場合（ステップＳ３でＮＯ）、ＨＴＴＰのデータ量が一定量を超えていないことを通信データ管理部２２へ通知する（ステップＳ３ｂ）。この通知は、図２中のサイズ超過フラグを例えば「０」に設定することによって行われる。この通知を受けた場合、通信データ管理部２２は、通信データ量情報をそのまま通信データ量算出部２４へ送信する（ステップＳ８）。この場合、通信データ量ＤＢ２３への書き込みを行われない。
通信データ量算出部２４は、通信データ管理部２２から通信データ量情報を受信すると（ステップＳ８）、通信データ管理部２２から受信したＴＣＰヘッダ情報及びＨＴＴＰヘッダ情報を基に、移動通信端末１０とコンテンツ提供サーバ３０との間で行われた通信データ量の算出を行う（ステップＳ９）。
【００２７】
以上のように、本例では、ステップＳ３においてＨＴＴＰのデータ量を判断することでデータ量の大略を把握し、把握したデータ量が一定量を超えていない場合は従来通りそのまま通信データ量の算出処理に移行する。一方、把握したデータ量が一定量を超えている場合は通信データ量ＤＢ２３に一旦蓄積しておき、後に読み出してデータ量を厳密に解析することで、通信データ量の算出処理の負荷を低減している。つまり、抽出したデータ量に応じ、その蓄積を行うかどうか切替える手段を設けているので、抽出されたデータ量情報が所定量を超えた場合に限って通信データ量ＤＢ２３への書き込みが行われ、ＤＢへの入出力処理を抑えることができる。
【００２８】
（変形例）
続いて、本実施形態にかかる課金システムの変形例について説明する。
上記実施形態にかかる課金システムは、通信制御部２１と、通信データ管理部２２、通信データ量ＤＢ２３及び通信データ量算出部２４とが同じシステム内にある構成であるが、通信制御部２１とそれ以外の各部とが別構成であってもよい。このようなシステム構成にすることで、通信制御部２１を複数設け、通信データ管理部２２と通信データ量ＤＢ２３とを通信データ量算出部２４に収容することが可能になる。このようにすれば、通信処理を行う構成部分（通信制御部２１）とデータ量算出の処理を行う構成部分（通信データ管理部２２、通信データ量ＤＢ２３、通信データ量算出部２４）とを明確に分離できるので、システムの故障時にその影響範囲を限定することができる。
【００２９】
（課金方法）
以上説明した課金システムにおいては、以下のような課金方法が実現されている。すなわち、通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出ステップと、前記データ量抽出ステップにおいて抽出されるデータ量情報を蓄積する蓄積ステップと、前記蓄積ステップにおいて蓄積されたデータ量情報に基づいてデータ量を算出する算出ステップと、前記算出ステップにおいて算出されるデータ量に応じて課金処理を行う課金ステップとを含む課金方法が実現されている。通信データ量を蓄積する処理を行うことにより、通信データの抽出処理と通信データ量の算出処理とを分離し、通信データ量算出処理の通信制御処理への影響を抑えることができる。
【産業上の利用可能性】
【００３０】
本発明は、携帯電話端末をはじめとする移動通信端末における課金処理に利用できる。
【図面の簡単な説明】
【００３１】
【図１】本発明の実施形態にかかる課金システムの構成例を示すブロック図である。
【図２】図１中の通信制御部から通信データ管理部へ送信されるデータ構造の例を示す図である。
【図３】図１中の通信データ管理部の内部構成例を示す図である。
【図４】本発明の実施形態にかかる課金システムの動作例を示すフローチャートである。
【符号の説明】
【００３２】
１０ 移動通信端末
２０ 課金システム
２１ 通信制御部
２２ 通信データ管理部
２３ 通信データ量ＤＢ
２４ 通信データ量算出部
３０ コンテンツ提供サーバ
１００ データ
１０１ コネクションＩＤ
１０２ サイズ超過フラグ
１０３ ＴＣＰヘッダ情報
１０４ ＨＴＴＰヘッダ情報
２２１ 書き込み管理テーブル
２２２ 読み出し管理テーブル
【特許請求の範囲】
【請求項１】
通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出手段と、前記データ量抽出手段により抽出されるデータ量情報を蓄積する蓄積手段と、前記蓄積手段に蓄積されたデータ量情報に基づいてデータ量を算出する算出手段とを含み、前記算出手段によって算出されるデータ量に応じて課金処理を行うことを特徴とする課金システム。
【請求項２】
前記データ量抽出手段によって抽出されたデータ量情報が所定量を超えた場合に限り、前記データ量情報を前記蓄積手段に蓄積することを特徴とする請求項１記載の課金システム。
【請求項３】
前記データ量情報の前記蓄積手段への蓄積単位は固定長であり、
前記蓄積手段への書き込み回数及び前記蓄積手段からの読み込み回数を管理するアクセス回数管理手段を更に含み、前記書き込み回数及び前記読み出し回数に基づいて、前記蓄積手段から読み込むべきデータ量情報を特定するようにしたことを特徴とする請求項１又は２記載の課金システム。
【請求項４】
通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出ステップと、前記データ量抽出ステップにおいて抽出されるデータ量情報を蓄積する蓄積ステップと、前記蓄積ステップにおいて蓄積されたデータ量情報に基づいてデータ量を算出する算出ステップと、前記算出ステップにおいて算出されるデータ量に応じて課金処理を行う課金ステップとを含むことを特徴とする課金方法。
【請求項１】
通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出手段と、前記データ量抽出手段により抽出されるデータ量情報を蓄積する蓄積手段と、前記蓄積手段に蓄積されたデータ量情報に基づいてデータ量を算出する算出手段とを含み、前記算出手段によって算出されるデータ量に応じて課金処理を行うことを特徴とする課金システム。
【請求項２】
前記データ量抽出手段によって抽出されたデータ量情報が所定量を超えた場合に限り、前記データ量情報を前記蓄積手段に蓄積することを特徴とする請求項１記載の課金システム。
【請求項３】
前記データ量情報の前記蓄積手段への蓄積単位は固定長であり、
前記蓄積手段への書き込み回数及び前記蓄積手段からの読み込み回数を管理するアクセス回数管理手段を更に含み、前記書き込み回数及び前記読み出し回数に基づいて、前記蓄積手段から読み込むべきデータ量情報を特定するようにしたことを特徴とする請求項１又は２記載の課金システム。
【請求項４】
通信端末とコンテンツ提供サーバとの間で授受される通信データ量に関するデータ量情報を抽出するデータ量抽出ステップと、前記データ量抽出ステップにおいて抽出されるデータ量情報を蓄積する蓄積ステップと、前記蓄積ステップにおいて蓄積されたデータ量情報に基づいてデータ量を算出する算出ステップと、前記算出ステップにおいて算出されるデータ量に応じて課金処理を行う課金ステップとを含むことを特徴とする課金方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００６−２４６２３３（Ｐ２００６−２４６２３３Ａ）
【公開日】平成１８年９月１４日（２００６．９．１４）
【国際特許分類】
【出願番号】特願２００５−６１３１１（Ｐ２００５−６１３１１）
【出願日】平成１７年３月４日（２００５．３．４）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成１８年９月１４日（２００６．９．１４）
【国際特許分類】
【出願日】平成１７年３月４日（２００５．３．４）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]