(57)【要約】【課題】正確な課金データの生成が可能であるトランザクション認識方法及び課金処理装置を提供する。【解決手段】課金処理装置は、パケットコピー機から複製HTTP要請が受信されれば、接続住所情報を抽出して第１ハッシュ値を生成する。以後、パケットコピー機から複製HTTP回答が受信されれば、複製HTTP回答に含まれた第２ハッシュ値を抽出して第１ハッシュ値と一致するか否かを判断する。第１ハッシュ値と第２ハッシュ値とが一致すれば、当該HTTP要請と当該変換HTTP回答とをトランザクションとして設定して課金データを生成する。【選択図】図６
2008099333.tif 000002
【特許請求の範囲】
【請求項１】
課金処理装置のトランザクション認識方法において、
パケットコピー機から複製HTTP要請(Request）を受信する段階−ここで、上記複製HTTP要請は、使用者端末機から上記パケットコピー機を経由してプロキシサーバーに伝送されるHTTP要請の複製パケットデータであって、上記パケットコピー機によって複製される−；
上記複製HTTP要請に含まれた接続住所情報を抽出する段階；
上記接続住所情報とあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する段階；
上記パケットコピー機から複製HTTP回答(Response)を受信する段階−ここで、上記複製HTTP回答は、上記接続住所情報に相応するコンテンツ提供サーバーから上記パケットコピー機を経由して上記使用者端末機に伝送される変換HTTP回答の複製パケットデータであって、上記パケットコピー機によって複製される−；
上記複製HTTP回答に含まれた第２ハッシュ値を抽出する段階；
上記第１ハッシュ値と上記第２ハッシュ値を比べる段階；及び
上記第１ハッシュ値と上記第２ハッシュ値が一致する場合、上記HTTP要請と上記変換HTTP回答をトランザクション(transaction）として設定する段階−ここで、上記トランザクションは、上記HTTP要請と上記変換HTTP回答の対(Pair)である−を含むことを特徴とするトランザクション認識方法。
【請求項２】
請求項１において、
上記プロキシサーバーが、上記第２ハッシュ値を含む上記変換HTTP回答を生成するために、
上記HTTP要請を受信する段階；
上記HTTP要請に含まれた上記接続住所情報及び上記ハッシュアルゴリズムを利用して上記第２ハッシュ値を生成する段階；
上記HTTP要請を、上記接続住所情報に相応する上記コンテンツ提供サーバーに伝送する段階；
上記コンテンツ提供サーバーから上記HTTP要請に相応する元のHTTP回答(Response)を受信する段階；及び
上記元のHTTP回答のヘッダーに上記第２ハッシュ値を挿入して上記変換HTTP回答を生成する段階を行うことを特徴とするトランザクション認識方法。
【請求項３】
請求項１において、
上記接続住所情報は、URL(Uniform Resource Locator）であることを特徴とするトランザクション認識方法。
【請求項４】
請求項１において、
上記変換HTTP回答は、データサービス装置を経由して上記使用者端末機に伝送されるが、
上記データサービス装置は、網連動装置(IWF：InterWorking Function)、パケットデータサービングノード（PDSN：Packet Data Serving Node）、サービングGPRSサポーティングノード（SGSN：Serving GPRS Supporting Node）、ゲートウェーGPRSサポーティングノード（GPRS：Gateway GPRS Supporting Node）の中の少なくともひとつであることを特徴とするトランザクション認識方法。
【請求項５】
課金処理装置のトランザクション認識方法において、
データサービス装置からHTTP要請(Request）を受信する段階；
上記HTTP要請に含まれた接続住所情報を抽出する段階；
上記接続住所情報とあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する段階；
上記HTTP要請をプロキシサーバーに伝送する段階；
プロキシサーバーから変換HTTP回答(Response)を受信する段階−ここで、上記変換HTTP回答は、第２ハッシュ値及び上記HTTP要請に相応する元のHTTP回答を含む−；
上記変換HTTP回答に含まれた第２ハッシュ値を抽出する段階；
上記第１ハッシュ値と上記第２ハッシュ値を比べる段階；
上記第１ハッシュ値と上記第２ハッシュ値が一致する場合、上記HTTP要請と上記変換HTTP回答をトランザクション(transaction）として設定する段階−ここで、上記トランザクションは、上記HTTP要請と上記変換HTTP回答の対(Pair)である−；及び
上記変換HTTP回答を上記データサービス装置に伝送する段階を含むことを特徴とするトランザクション認識方法。
【請求項６】
請求項５において、
上記プロキシサーバーが、上記変換HTTP回答を生成するために、
上記HTTP要請を受信する段階；
上記HTTP要請に含まれた上記接続住所情報及び上記ハッシュアルゴリズムを利用して上記第２ハッシュ値を生成する段階；
上記HTTP要請を上記接続住所情報に相応するコンテンツ提供サーバーに伝送する段階；  上記コンテンツ提供サーバーから上記HTTP要請に相応する元のHTTP回答(Response)を受信する段階；及び
上記元のHTTP回答のヘッダーに上記第２ハッシュ値を挿入して上記変換HTTP回答を生成する段階を行うことを特徴とするトランザクション認識方法。
【請求項７】
使用者端末機とコンテンツ提供サーバー間に送受信されるパケットデータの対(Pair)を認識する課金処理装置において、
パケットコピー機から複製HTTP要請(Request) 及び複製HTTP回答(Response)を受信する手段−ここで、上記複製HTTP要請は、上記使用者端末機から上記パケットコピー機を経由してプロキシサーバーに伝送されるHTTP要請の複製パケットデータであって、上記複製HTTP回答は、上記接続住所情報に相応するコンテンツ提供サーバーから上記パケットコピー機を経由して上記使用者端末機に伝送される変換HTTP回答の複製パケットデータであり、上記複製HTTP要請及び上記複製HTTP回答は、上記パケットコピー機によって複製される−；
上記複製HTTP要請に含まれた接続住所情報を抽出する手段；
上記接続住所情報とあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する手段;
上記複製HTTP回答に含まれた第２ハッシュ値を抽出する手段；
上記第１ハッシュ値と上記第２ハッシュ値を比べる手段; 及び
上記第１ハッシュ値と上記第２ハッシュ値が一致する場合、上記HTTP要請と上記変換HTTP回答をトランザクション(transaction）として設定する手段−ここで、上記トランザクションは、上記HTTP要請と上記変換HTTP回答の対(Pair)である−を含むが、
上記プロキシサーバーは、上記第２ハッシュ値を含む上記変換HTTP回答を生成するために、
上記HTTP要請を受信する段階；
上記HTTP要請に含まれた上記接続住所情報及び上記ハッシュアルゴリズムを利用して上記第２ハッシュ値を生成する段階；
上記HTTP要請を上記接続住所情報に相応する上記コンテンツ提供サーバーに伝送する段階；
上記コンテンツ提供サーバーから上記HTTP要請に相応する元のHTTP回答(Response)を受信する段階；及び
上記元のHTTP回答のヘッダーに上記第２ハッシュ値を挿入して上記変換HTTP回答を生成する段階を行うことを特徴とする課金処理装置。
【請求項８】
使用者端末機とコンテンツ提供サーバー間に送受信されるパケットデータの対(Pair)を認識する課金処理装置において、
データサービス装置からHTTP要請(Request）を受信し、プロキシサーバーから変換HTTP回答(Response)を受信する手段；
上記HTTP要請に含まれた接続住所情報を抽出する手段；
上記接続住所情報とあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する手段；
上記変換HTTP回答に含まれた第２ハッシュ値を抽出する手段；
上記第１ハッシュ値と上記第２ハッシュ値を比べる手段；
上記第１ハッシュ値と上記第２ハッシュ値が一致する場合、上記HTTP要請と上記変換HTTP回答をトランザクション(transaction）として設定する手段−ここで、上記トランザクションは、上記HTTP要請と上記変換HTTP回答の対(Pair)である−；及び
上記HTTP要請を上記プロキシサーバーに伝送し、上記変換HTTP回答を上記データサービス装置に伝送する手段を含むが、
上記プロキシサーバーは上記変換HTTP回答を生成するために、
上記HTTP要請を受信する段階；
上記HTTP要請に含まれた上記接続住所情報及び上記ハッシュアルゴリズムを利用して上記第２ハッシュ値を生成する段階；
上記HTTP要請を上記接続住所情報に相応する上記コンテンツ提供サーバーに伝送する段階；
上記コンテンツ提供サーバーから上記HTTP要請に相応する元のHTTP回答(Response)を受信する段階；及び
上記元のHTTP回答のヘッダーに上記第２ハッシュ値を挿入して上記変換HTTP回答を生成する段階を行うことを特徴とする課金処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットデータ課金細分化方法及びそのシステムに関するものであり、特に課金処理装置でのトランザクションの認識に関するものである。
【背景技術】
【０００２】
最近、符号分割多重接続（CDMA：Code Division Multiple Access)技術によって、移動通信端末機を用いる音声信号及び高速データの送受信が可能になっている。
使用者は、パケット通信網を通じてデータを受信することになり、移動通信サービス事業者は、当該使用者のパケット通信網利用（無線データサービス利用）による料金請求のため、課金データを時点ごとに生成して管理する。生成された課金データはあらかじめ指定された時点（例えば、毎月）ごとで合算されて当該使用者の音声通信料金に付け加えて請求される。
【０００３】
したがって、移動通信サービス事業者は、パケット通信網使用者たちに合理的な料金請求のため、料金の透明性を保障できる方案を提示しなければならないのである。
無線データサービス利用に対する従来の課金データ生成方法は次のとおりである。
先ず、使用者は、任意のコンテンツ提供サーバーから提供されるコンテンツを提供してもらうために移動通信端末機を用いて接続されたパケットデータサービングノード（PDSN：Packet Data Serving Node）にデータ提供要請を伝送する。
【０００４】
パケットデータサービングノード(PDSN)は、受信したデータ提供要請を、当該移動通信端末機に設置されたサービスプラットホーム（例えば、BREW(Binary Runtime Environment for Wireless), ME(Mobile Explorer), KUN(KTF Unified Navigator)、WIPI(Wireless Internet Platform for Interoperability）、VOD など）に対応するプロキシサーバーに伝送する。パケットデータサービングノード(PDSN)がデータ提供要請をプロキシサーバーに伝送する過程で課金処理装置はデータ提供要請に相応する通信網利用料を算出する。
【０００５】
プロキシサーバーは、受信されたデータ提供要請を、それに相応するコンテンツ提供サーバーに伝送して、コンテンツ提供サーバーからコンテンツデータを受信してパケットデータサービングノード(PDSN)に伝送する。また、この過程で、課金処理装置がコンテンツデータ伝送に相応するコンテンツ利用料及び通信網利用料を算出することになる。
【０００６】
パケットデータサービングノード(PDSN)は、受信されたコンテンツデータを使用者の移動通信端末機に伝送するし、課金処理装置は、算出された通信網利用料及び／またはコンテンツ利用料を集計して統合課金データを生成するか課金処理を遂行する。
【０００７】
上述のように、従来の課金データ生成方法は、パケットデータサービングノード(PDSN)とプロキシサーバー間に、パケットデータ（例えば、データ提供要請、コンテンツデータ）の送受信される時点ごとで課金処理装置が課金データを生成する方法であった。
【０００８】
すなわち、使用者がコンテンツ提供サーバーに、有無線インターネット及び／またはその他のネットワークを経由してHTTPプロトコルを用いるコンテンツ伝送を要請すれば、使用者端末機がそれに相応するコンテンツデータを正常に受信したのか否かの確認の前、当該コンテンツ伝送に対する課金（すなわち、通信網利用料、コンテンツ利用料）が成り立つ。
【０００９】
このような従来の課金データ生成方法は、ネットワーク及びコンテンツ提供サーバーが非常に安定的な状態で動作することを仮定した場合である。したがって、ネットワークの不安定、コンテンツ提供サーバーの誤動作は課金の間違いの原因になってしまうこともある。
【００１０】
すなわち、従来の課金データ生成方法は、ただ TCP／IPプロトコル分析のみによって課金データを生成するので使用者の無線データサービス利用内訳に符合する課金データが生成されないという問題点があった。また、HTTPプロトコル分析を遂行しても、HTTP要請(HTTP Request)とHTTP回答(HTTP Response）の対（Pair、すなわちトランザクション(transaction))が必ず存在するという仮定の下で課金データを生成する構造であるから正確な課金データが生成されることができない問題点もあった。
【００１１】
また、従来の課金データ生成方法は、使用者が要請したデータを実質的に提供してもらわなかった場合（例えば、通信の間違い、データの不在など）にもただHTTP要請(HTTP Request)があったという理由で課金データが生成される問題点もあった。
【００１２】
また、従来の課金データ生成方法は、移動通信端末機とプロキシサーバー間に別のネットワーク分析装置を具備して、ネットワークパケットを基礎にトランザクション（すなわち、HTTP要請及びこれに相応するHTTP回答の対）を認識するのが容易でない問題点もあった。
【００１３】
また、従来の課金データ生成方法は、課金データであるインターネット課金情報（IPDR：Internet Protocol Detail Record −以下、IPDRと称する）や通話詳細資料(CDR：Call Detail Record−以下、CDR と称する）を生成するにおいて、データセッションの全体に対する使用時間情報と使用パケット量を基準にしてIPDRを生成するという問題点もあった。すなわち、データセッション内で使用者が使ったサービス別に差等課金を適用するためのIPDR生成は試みされていなかった。
【００１４】
また、従来のIPDR生成方法は、トランザクション(Transaction）の重畳現象、トランザクションの未了現象またはセッションの未了現象などの発生時、正確なIPDR生成が成り立つことができない問題点もあった。
【特許文献１】米国特許出願公開第２００３／２３３３２９号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１５】
したがって、上述した従来の問題点を解決するため、本発明の目的は、移動通信サービスシステムでハッシュアルゴリズム(Hash Function）を共有してトランザクション(Transaction）を容易に認識できるようにするトランザクション認識方法及び課金処理装置を提供することである。
【００１６】
本発明のまた別の目的は、トランザクション認識により細分化されて厳格なインターネットサービス課金またはコンテンツ課金が可能なトランザクション認識方法及び課金処理装置を提供することである。
【００１７】
本発明のまた別の目的は、使用者端末機とプロキシサーバーが持続性連結(Persistent Connection）を利用して単一のTCP 連結上に複数のHTTP要請メッセージ及びHTTP回答メッセージを交換するにおいて、ネットワークパケットまたはHTTPメッセージを基準にしてトランザクションの認識が可能なトランザクション認識方法及び課金処理装置を提供することである。
【課題を解決するための手段】
【００１８】
前記のような目的を果たすために、本発明の一側面によれば、課金処理装置のトランザクション認識方法において、パケットコピー機から複製HTTP要請(Request）を受信する段階ーここで、上記複製HTTP要請は、使用者端末機から上記パケットコピー機を経由してプロキシサーバーに伝送されるHTTP要請の複製パケットデータであって、上記パケットコピー機によって複製される−；上記複製HTTP要請に含まれた接続住所情報を抽出する段階；上記接続住所情報とあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する段階；上記パケットコピー機から複製HTTP回答(Response)を受信する段階−ここで、上記複製HTTP回答は、上記接続住所情報に相応するコンテンツ提供サーバーから上記パケットコピー機を経由して上記使用者端末機に伝送される変換HTTP回答の複製パケットデータであって、上記パケットコピー機によって複製される−；上記複製HTTP回答に含まれた第２ハッシュ値を抽出する段階；上記第１ハッシュ値と上記第２ハッシュ値を比べる段階；及び上記第１ハッシュ値と上記第２ハッシュ値が一致する場合、上記HTTP要請と上記変換HTTP回答をトランザクション(transaction）として設定する段階−ここで、上記トランザクションは、上記HTTP要請と上記変換HTTP回答の対(Pair)である−を含むことを特徴とするトランザクション認識方法が提供される。
【００１９】
上記プロキシサーバーは、上記第２ハッシュ値を含む上記変換HTTP回答を生成するために、上記HTTP要請を受信する段階；上記HTTP要請に含まれた上記接続住所情報及び上記ハッシュアルゴリズムを利用して上記第２ハッシュ値を生成する段階；上記HTTP要請を上記接続住所情報に相応する上記コンテンツ提供サーバーに伝送する段階；上記コンテンツ提供サーバーから上記HTTP要請に相応する元のHTTP回答(Response)を受信する段階；及び上記元のHTTP回答のヘッダーに上記第２ハッシュ値を挿入して上記変換HTTP回答を生成する段階を行うことができる。
【００２０】
上記接続住所情報はURL(Uniform Resource Locator）であることができる。上記変換HTTP回答は、データサービス装置を経由して上記使用者端末機に伝送されるが、上記データサービス装置とは、網連動装置(IWF：InterWorking Function)、パケットデータサービングノード（PDSN：Packet Data Serving Node）、サービングGPRSサポーティングノード（SGSN：Serving GPRS Supporting Node）、ゲートウェーGPRSサポーティングノード（GPRS：Gateway GPRS Supporting Node) の中の少なくとも一つであることができる。
【００２１】
本発明のまた別の側面によれば、課金処理装置のトランザクション認識方法において、データサービス装置からHTTP要請(Request）を受信する段階；上記HTTP要請に含まれた接続住所情報を抽出する段階; 上記接続住所情報とあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する段階；上記HTTP要請をプロキシサーバーに伝送する段階; プロキシサーバーから変換HTTP回答(Response)を受信する段階−ここで、上記変換HTTP回答は、第２ハッシュ値及び上記HTTP要請に相応する元のHTTP回答を含む−；上記変換HTTP回答に含まれた第２ハッシュ値を抽出する段階；上記第１ハッシュ値と上記第２ハッシュ値を比べる段階；上記第１ハッシュ値と上記第２ハッシュ値が一致する場合、上記HTTP要請と上記変換HTTP回答をトランザクション(transaction）として設定する段階−ここで、上記トランザクションは上記HTTP要請と上記変換HTTP回答の対(Pair)である−；及び上記変換HTTP回答を上記データサービス装置に伝送する段階を含むことを特徴とするトランザクション認識方法が提供される。
【００２２】
上記プロキシサーバーは、上記変換HTTP回答を生成するために、上記HTTP要請を受信する段階; 上記HTTP要請に含まれた上記接続住所情報及び上記ハッシュアルゴリズムを利用して上記第２ハッシュ値を生成する段階；上記HTTP要請を上記接続住所情報に相応するコンテンツ提供サーバーに伝送する段階；上記コンテンツ提供サーバーから上記HTTP要請に相応する元のHTTP回答(Response)を受信する段階; 及び上記元のHTTP回答のヘッダーに上記第２ハッシュ値を挿入して上記変換HTTP回答を生成する段階を行うことができる。
【００２３】
本発明のまた別の側面によれば、使用者端末機とコンテンツ提供サーバー間に送受信されるパケットデータの対(Pair)を認識する課金処理装置において、パケットコピー機から複製HTTP要請(Request) 及び複製HTTP回答(Response)を受信する手段−ここで、上記複製HTTP要請は、上記使用者端末機から上記パケットコピー機を経由してプロキシサーバーに伝送されるHTTP要請の複製パケットデータであって、上記複製HTTP回答は、上記接続住所情報に相応するコンテンツ提供サーバーから上記パケットコピー機を経由して上記使用者端末機に伝送される変換HTTP回答の複製パケットデータであり、上記複製HTTP要請及び上記複製HTTP回答は上記パケットコピー機によって複製される−；上記複製HTTP要請に含まれた接続住所情報を抽出する手段; 上記接続住所情報とあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する手段；上記複製HTTP回答に含まれた第２ハッシュ値を抽出する手段; 上記第１ハッシュ値と上記第２ハッシュ値を比べる手段；及び上記第１ハッシュ値と上記第２ハッシュ値が一致する場合、上記HTTP要請と上記変換HTTP回答をトランザクション(transaction）として設定する手段−ここで、上記トランザクションは、上記HTTP要請と上記変換HTTP回答の対(Pair)である−を含む課金処理装置が提供される。ここで、上記プロキシサーバーは、上記第２ハッシュ値を含む上記変換HTTP回答を生成するために、上記HTTP要請を受信する段階；上記HTTP要請に含まれた上記接続住所情報及び上記ハッシュアルゴリズムを利用して上記第２ハッシュ値を生成する段階；上記HTTP要請を上記接続住所情報に相応する上記コンテンツ提供サーバーに伝送する段階；上記コンテンツ提供サーバーから上記HTTP要請に相応する元のHTTP回答(Response)を受信する段階；及び上記元のHTTP回答のヘッダーに上記第２ハッシュ値を挿入して上記変換HTTP回答を生成する段階を行うことができる。
【００２４】
本発明のまた別の側面によれば、使用者端末機とコンテンツ提供サーバー間に送受信されるパケットデータの対(Pair)を認識する課金処理装置において、データサービス装置からHTTP要請(Request）を受信し、プロキシサーバーから変換HTTP回答(Response)を受信する手段; 上記HTTP要請に含まれた接続住所情報を抽出する手段；上記接続住所情報とあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する手段；上記変換HTTP回答に含まれた第２ハッシュ値を抽出する手段; 上記第１ハッシュ値と上記第２ハッシュ値を比べる手段；上記第１ハッシュ値と上記第２ハッシュ値が一致する場合、上記HTTP要請と上記変換HTTP回答をトランザクション(transaction）として設定する手段−ここで、上記トランザクションは上記HTTP要請と上記変換HTTP回答の対(Pair)である−；及び上記HTTP要請を上記プロキシサーバーに伝送し、上記変換HTTP回答を上記データサービス装置に伝送する手段を含む課金処理装置が提供される。ここで、上記プロキシサーバーは、上記変換HTTP回答を生成するために、上記HTTP要請を受信する段階；上記HTTP要請に含まれた上記接続住所情報及び上記ハッシュアルゴリズムを利用して上記第２ハッシュ値を生成する段階；上記HTTP要請を上記接続住所情報に相応する上記コンテンツ提供サーバーに伝送する段階；上記コンテンツ提供サーバーから上記HTTP要請に相応する元のHTTP回答(Response)を受信する段階；及び上記元のHTTP回答のヘッダーに上記第２ハッシュ値を挿入して上記変換HTTP回答を生成する段階を行うことができる。
【発明の効果】
【００２５】
本発明は、移動通信サービスシステムでハッシュアルゴリズム(Hash Function）を共有して、トランザクション(Transaction）を容易に認識できるようにする。
また、本発明は、トランザクション認識によって細分化され、厳格なインターネットサービス課金またはコンテンツ課金が可能である。
また、本発明は、使用者端末機とプロキシサーバーの持続性連結(Persistent Connection）を利用して、単一の TCP連結上に複数のHTTP要請メッセージ及びHTTP回答メッセージを交換するにおいてネットワークパケットまたはHTTPメッセージを基準にしてトランザクションの認識が可能である。
【発明を実施するための最良の形態】
【００２６】
本発明と本発明の動作上の利点及び本発明の実施によって果たすことができる目的を充分に理解するためには、本発明の望ましい実施例を例示する添付図面及び添付図面に記載した内容を参照しなければならない。
【００２７】
以下、本発明の望ましい実施例を、添付した図面を参照して詳しく説明する事にする。本発明の説明において、全体的な理解を容易くするために図面番号に構わずに等しい手段に対しては等しい参照番号を使う事とする。
【００２８】
図１は、本発明の望ましい一実施例による移動通信サービスシステムの構成を概略的に示した図面である。
図１を参照すれば、移動通信サービスシステム(120）は、基地局(BTS：Base Transceiver Station, 125)、データサービス装置(130）、パケットコピー機(135）、課金処理装置(140）及びプロキシサーバー(145）を含む。図１には図示されていないが、移動通信サービスシステム(120）は、基地局制御機(BSC：Base Station Controller)、交換機(MSC：Mobile Switching Center)、ホーム位置レジスター(HLR：Home Location Register）、訪問者位置レジスター(VLR：Visitor Location Register)などをともに含むことができる。
【００２９】
基地局(125）は、無線通信網を通じて使用者端末機(110）と移動通信サービスシステム(120）間の無線通信ができるようにし、伝送経路上のデータサービス装置(130）と信号を送受信する。使用者端末機(110）は通信網を通じて移動通信サービスシステム(120）に接続して、移動通信サービスシステム(120）と通信網を通じて結合されている複数のコンテンツ提供サーバー(150a, 150b, ... , 150n : 以下 150と称する）からコンテンツデータ（例えば、ベル音、背景画面、動映像など）を提供してもらう。使用者端末機(110）は、例えば、移動通信端末機、個人携帯端末機(PDA：Personal Digital Assistant）、ノートパソコン(Notebook Computer）などであることができる。
【００３０】
データサービス装置(130）は、無線インターネットサービスの提供及び利用ができるようにする装置であって、網連動装置(IWF：InterWorking Function)、パケットデータサービングノード（(PDSN ：Packet Data Serving Node）、サービングGPRSサポーティングノード（SGSN：Serving GPRS Supporting Node）、ゲートウェーGPRSサポーティングノード(PRS：Gateway GPRS Supporting Node）の中の少なくとも一つを含むことができる。網連動装置(IWF）は、２Ｇ網での無線データサービス装置を意味するし、パケットデータサービングノード(PDSN)は、動機３Ｇ網での無線データサービス装置を意味し、ゲートウェーGPRSサポーティングノード(GPRS)は非動機３Ｇ網での無線データサービス装置を意味する。もちろん、以外にも類似の機能を遂行する装置であれば上述した装置と等しく適用できるということは当然のことである。
【００３１】
パケットコピー機(135）は、データサービス装置(130）とプロキシサーバー(145）間に送受信されるすべての種類のパケットデータをコピーして課金処理装置(140）に伝達する機能を遂行する。
【００３２】
課金処理装置(140）は、パケットコピー機(135）から受信されるパケットデータを利用して、使用者の要請によるコンテンツデータの伝送が正常に完了したのか否か（例えば、HTTP要請に相応するHTTP回答を使用者端末機(110）に伝送したのかの可否）を判断して、正常に完了した場合、使用者の無線データサービス利用に対する課金データを生成して、課金を遂行する。
【００３３】
課金処理装置(140）は、コンテンツデータの伝送が正常に完了したのか判断する分析部と、課金データ生成及び課金遂行のための課金遂行部に仕分けすることができる。
課金処理装置(140）は、コンテンツデータの正常的伝送可否を判断するためにトランザクション(Transaction、HTTP要請(Request）／回答(Response)の対) 認識を遂行する。トランザクション認識のためにハッシュアルゴリズム(Hash Function）が利用されることができる。課金処理装置(140）がハッシュアルゴリズムを利用してトランザクションを認識する方法に対しては以後に関連図面を参照して詳しく説明することとする。
【００３４】
また、課金処理装置(140）は、パケットコピー機(135）から受信されるパケットデータを利用してトランザクション(Transaction）単位で基礎IPDR(Internet Protocol Detail Record）を生成して、基礎IPDRをあらかじめ指定された基準（例えば、サービス別）にしたがって併合(Aggregation）して統合IPDRを生成する。課金処理装置(140）は基礎IPDR及び／または統合IPDRを利用して課金を遂行することができる。
【００３５】
プロキシサーバー(145）は、使用者端末機(110）に具備されているサービスプラットホーム（例えば、BREW(Binary Runtime Environment for Wireless), ME(Mobile Explorer), KUN(KTF Unified Navigator), WIPI(Wireless Internet Platform for Interoperability), VODなど）に相応するように一つ以上で構成されて、当該サービスプラットホームに相応するコンテンツ提供サーバー(150）に接続してコンテンツデータを受信する。すなわち、プロキシサーバー(145）はコンテンツデータの仲介、プロトコル変換、暗号化処理などの機能を遂行することができる。
【００３６】
プロキシサーバー(145）は、使用者端末機(110）から無線データサービス要請が受信されれば、当該使用者端末機(110）に具備されているサービスプラットホームに相応してあらかじめ指定されたコンテンツ提供サーバー(150）から提供されるサービス項目に相応するメニュー情報を上記使用者端末機(110）に伝送する。また、使用者端末機(110）からHTTP要請が受信されれば、当該コンテンツデータを提供するコンテンツ提供サーバー(150）からコンテンツデータを受信してデータサービス装置(130）を通じて使用者端末機(110）に伝送する。HTTP要請はコンテンツデータ提供要請、コンテンツデータアップロード要請などであることができるが、以下ではコンテンツデータ提供要請の場合を仮定して説明する事にする。
【００３７】
また、プロキシサーバー(145）は、使用者端末機(110）から受信されたHTTP要請のURL を利用してハッシュ値を生成し、生成されたハッシュ値をコンテンツ提供サーバー(150）から受信されたHTTP回答（コンテンツデータが含まれることができる）のヘッダーに挿入した後使用者端末機(110）に伝送する機能をともに遂行することができる。
【００３８】
コンテンツ提供サーバー(150）は、移動通信サービスシステム(120）と通信網を通じて接続され、使用者が要請したコンテンツデータを提供する装置であって、ベル音提供サーバー、背景画面イメージ提供サーバー、株式情報提供サーバーなどであることができる。      
【００３９】
図１に示したように、GPRS(General Packet Radio Service)、CDMA-2000(Code Division Multiple Access - 2000）、WCDMA(Wideband CDMA)などの移動通信サービスは、使用者端末機(110）とプロキシサーバー(145）間に一つのTCP セッションが形成される。したがって、使用者が複数のコンテンツ提供サーバー(150）にHTTP要請(HTTP Request)を伝送してもすべてのHTTP要請はプロキシサーバー(145）を経由して相応するコンテンツ提供サーバー(150）に伝送される。また、コンテンツ提供サーバー(150）から受信されるHTTP回答(HTTP Response）もプロキシサーバー(145）を経由して使用者端末機(110）に伝送される。
【００４０】
すなわち、移動通信サービス環境は、使用者端末機(110）が複数のコンテンツ提供サーバー(150）からコンテンツデータを提供してもらう場合、各コンテンツ提供サーバー(150) またはサービス別に分離された複数のTCP セッションを生成し、各セッションごとにサービス形態が変わる。このように、移動通信サービス環境は従来の有線インターネット環境とは異なる構成を有する。
【００４１】
したがって、使用者端末機(110）とプロキシサーバー(145）間にパケット抽出方式で設置された課金処理装置(140）は、コンテンツ提供サーバー(150）の種類やサービス類型によって仕分けされた複数のTCP セッションではなく、一つのTCP セッション上に複数のウェブサービス使用データを検出する。
【００４２】
図２は、本発明の望ましい別の実施例による移動通信サービスシステムの構成を概略的に示した図面である。
図２に示したように、本発明による移動通信サービスシステムは、データサービス装置(130）とプロキシサーバー(145) 間に課金処理装置(140）が具備されるようにすることができる。したがって、パケットコピー機(135）が省略されられる。
課金処理装置(140）は、データサービス装置(130）とプロキシサーバー(145）間に送受信されるパケットデータを利用して、使用者の要請によるコンテンツデータの伝送が正常に完了したのかを判断して、正常に完了した場合、使用者の無線データサービス利用に対する課金データを生成することができる。
【００４３】
勿論、以外にもデータサービス装置(130）とプロキシサーバー(145）間に送受信されるパケットデータを利用してコンテンツデータの伝送完了可否及び課金データを生成することができる構成であれば、何らの制限なしに等しく適用することができるということは当然のことである。
【００４４】
図３は、本発明の望ましい一実施例による課金処理装置の課金データ生成時点決定のためのデータフローチャートであり、図４は一般的なTCP セグメント形式を示した図面である。
【００４５】
図３は、使用者端末機(110）とコンテンツ提供サーバー(150）間にTCP 連結設定(Handshaking）によるTCP セッションが設定された状態で、課金処理装置(140）がHTTP基盤コンテンツ伝送完了可否の判断のため、使われることができる課金データ生成時点決定方法を示したフローチャートである。
【００４６】
図３を参照すれば、段階 310で、使用者端末機(110）は、HTTP GETメソッド(method)を利用して、伝送してもらおうとするコンテンツをURL 形式で指定してコンテンツ提供サーバーに伝送する。HTTP GETメソッドは情報をURL の後に添付する。当該HTTP要請(HTTP Request)は、データサービス装置(130）、プロキシサーバー(145) などを経由してコンテンツ提供サーバー(150）に伝送されることは自明であるが、ここではこれに対する説明は略することにする。
【００４７】
段階 310で、課金処理装置(140）は、データサービス装置(130）、プロキシサーバー(145）間に送受信されるHTTP要請に相応するTCP パケットを伝達してもらってHTTP GETメソッドとURL を獲得する。また、課金処理装置(140）は、当該TCP パケットに指定されたシーケンス番号(Sequence Number）を任意のパラメーター値（以下、 "Ｊ値”と称する）として獲得するし、アック(ACK) 番号(Acknowledgement Number)を任意のパラメーター値（以下、 "Ｋ値”と称する）として獲得する。この時、J 値は HTTP 要請(HTTP Request)の一番目のオクテット(Octet）を示す一連番号であり、Ｋ値は HTTP 回答(HTTP Response）の一番目のオクテットを示す一連番号である。
【００４８】
以下、図４を参照してTCP セグメント形式を手短に説明する。
TCP セグメント(Segment）は、TCP(Transmission Control Protocol)によって伝送される基本単位を意味する。TCP セグメントは、TCP ヘッダーとデータに仕分けられるし、TCP ヘッダーは20バイトの固定ヘッダー部分とオプションフィールド(Optional Field)で構成される。
【００４９】
根源地ポート(Source Port）と目的地ポート(Destination Field）はTCP 連結の両縦断にある応用プログラムを示すポート番号である。
シーケンス番号(Sequence Number）は、セグメントに入っているデータが応用プログラムのバイトストリーム(byte stream）のどの位置に存在するのか表示する。
アック番号(Acknowledge Number)は、受信側が送信側から受けたセグメントに対する回答であって、次に受けるのを待つセグメントのバイト番号を意味する。
【００５０】
ヘッダー長さは、32ビットの整数倍に計算されたセグメントヘッダー長さを示す整数値である。
ウィンドウの大きさ(window size）は、受信側(receiver)の立場での自分の利用可能なバッファ(available buffer)の大きさを知らせてくれるフィールドであって、これを利用して両縦断間の流れ制御(flow control)が遂行される。
【００５１】
チェックサム(Checksum)は、TCP の全体大きさとIP階層のヘッダーのうち後半部１２バイト（byte）に対する間違いの検出のためのコードである。
緊急ポインター(Urgent Pointer)は、緊急データが入っている位置を表示する。
【００５２】
また図３を参照すれば、段階 315で、コンテンツ提供サーバー(150）は、使用者端末機(110）に TCP ACKメッセージを伝送する。 TCP ACKメッセージはコンテンツ提供サーバー(150）が、使用者端末機(110）から伝送されたHTTP要請を正常に受信したことを示す。段階 315は省略されることができる。
【００５３】
使用者端末機(110）から受信されたHTTP要請に相応するプロセスを遂行した後、コンテンツ提供サーバー(150）は、段階 320で、HTTP回答(HTTP Response) メッセージを生成して使用者端末機(110）に伝送する。この時、HTTP回答の一番目パケットのTCP シーケンス番号はＫ値を有する。そして、コンテンツ提供サーバー(150）が使用者端末機(110）に伝送したパケットのうちTCP シーケンス番号がＫ値であるTCP パケットの内容の中にはHTTP回答ヘッダー(HTTP Response Header)のフィールド(Field) 値としてコンテンツの長さ(Contents-Length）が存在する。HTTP規格上コンテンツ長さフィールドは、HTTP回答メッセージ領域(Message Body)の大きさを正確に表示しなければならない。したがって、段階 320で、課金処理装置(140）はコンテンツ長さフィールド値を任意のパラメーター値（以下、 "Ｌ値”と称する）として獲得することができる。また、課金処理装置(140）はHTTP回答の一番目パケットのTCP ペイロード(Payload）のスタートから一番目空のライン(Blank Line,一ラインにCRLFだけ存在）までのオクテット大きさ(octet size)を計算して任意のパラメーター値（以下、 "Ｍ値”と称する）として獲得する。
【００５４】
コンテンツ提供サーバー(150）は、使用者端末機(110）に、一つ以上のIPパケットで構成されるHTTP回答を伝送することができる。当該HTTP回答が使用者端末機(110）に伝送されれば、使用者端末機(110）は、HTTP回答の完了前でもアックメッセージ(ACK message）をコンテンツ提供サーバー(150）に伝送することができる（段階 325、段階 330）。
【００５５】
段階 330で、課金処理装置(140）は、使用者端末機(110）からコンテンツ提供サーバー(150）に伝送されるアックメッセージを持続的に検査してアック(ACK) 番号(Acknowledgement Number)を任意のパラメーター値（以下、 "Ｙ値”と称する）として獲得する。
【００５６】
段階 335で、課金処理装置(140）はＫ値、Ｌ値及びＭ値を合わせた値がＹ値以下なのか否かを判断する。すなわち、課金処理装置(140）はＹ値がＫ値、Ｌ値及びＭ値を合わせた値より大きいかまたは同じの場合、コンテンツ提供サーバー(150）が意図したHTTP回答が使用者端末機(110）に正常に伝送されたと判断して、課金データ生成を開始する。しかし、Ｙ値がＫ値、Ｌ値及びＭ値を合わせた値より小さな場合には段階 330にまた進行してＹ値の獲得を遂行する。
【００５７】
このように、課金処理装置(140）は、段階 310で、HTTP要請(Request）に含まれたアック番号(ACK number)であるＫ値を獲得するし、段階 320でHTTP回答(Response)に含まれたコンテンツの長さ(Content-Length)であるＬ値と、HTTPヘッダー長さ(Header length）であるＭ値を獲得する。そして、段階 330で、TCP アックメッセージのアック番号であるＹ値を獲得する。以後、課金処理装置(140）は、Ｙ値がＫ値、Ｌ値、Ｍ値の合計（すなわち、Ｋ値＋Ｍ値＋Ｌ値）より大きいか同じであればコンテンツの正常伝送が完了されたと判断して課金を遂行する。
【００５８】
しかし、Ｙ値がＫ値、Ｌ値、Ｍ値の合計より小さな場合、課金処理装置(140）は、当該コンテンツの正常伝送がまだ完了されていないと判断して課金を留保することができる。また、Ｙ値がＫ値、Ｌ値、Ｍ値の合計より小さな状態でTCP セッションが終わった場合、課金処理装置(140）は、当該コンテンツの正常伝送が失敗したと認識して、これに相応する課金を遂行することができる。または、課金データを生成しないこともある。また、課金処理装置(140）は、ヘッド（HEAD）メソッドを含むHTTP要請に対するHTTP回答や、1xx 、204 、304 などのHTTP回答コード(Response Code）を有するHTTP回答の場合には、メッセージ領域(Message Body)が存在しないので非課金対象であると認識することができる。この場合には、コンテンツが伝送されないからである。参考に、HEADメソッド(method)は、HTTP回答のメッセージ領域にどんなデータも含ませてはいけないというメソッドである。Informational 1xx は、臨時的な回答を意味する。204 は、コンテンツ提供サーバー(150）がHTTP要請を処理したが、使用者端末機(110）に伝送する情報が存在しない場合(No Content)に使われる。
【００５９】
また、課金処理装置(140）は、HTTP回答内にコンテンツ長さ(Content-Length)フィールドがなく、アイデンティティ(identity)フィールドではないトランスファーコーディング(Transfer-coding）フィールドが存在する場合、トランスファー長さ(Transfer-length) 値をコンテンツ長さ(Content-Length)値に取り替えてプロセスを遂行することができる。      
【００６０】
図５は、本発明の望ましい別の実施例による課金処理装置の課金データ生成時点決定のための具体的なデータフローチャートである。
図５は、使用者が移動通信サービスシステム(120）を通じて任意のコンテンツ提供サーバー(150、すなわち groups.google.com）に接続してサービスを提供してもらう場合に対する、使用者端末機(110）とコンテンツ提供サーバー(150）間の実在的なパケットデータ送受信過程を示したフローチャートである。ただし、使用者端末機(110）とコンテンツ提供サーバー(150）間に送受信されるTCP 水準のパケットデータのうち、本発明と関連があるパケットデータだけが図示される。
【００６１】
図５を参照すれば、使用者端末機(110）とコンテンツ提供サーバー(150）は、段階 510ないし段階 520のTCP パケットの送受信を通じてTCP セッションを形成する。
段階 525で、使用者端末機(110）は、コンテンツ提供サーバー(150）にHTTP要請(HTTP Request)を伝送する。HTTP要請内には http://groups.google.com/index.htmlに相応するURL 情報が含まれている。そして、課金処理装置(140）は、当該HTTP要請内に含まれているシーケンス番号(Sequence Number）である１をＪ値として、アック番号(Acknowledge Number)である１をＫ値として獲得する。
【００６２】
段階 530で、コンテンツ提供サーバー(150）は、使用者端末機(110）からのHTTP要請を正常に受信したという意味で、アック番号をＪ値にするアックメッセージを使用者端末機(110）に伝送することができる。
段階 535で、コンテンツ提供サーバー(150）は、HTTP回答(HTTP Response）を使用者端末機(110）に送り始める。課金処理装置(140）は、コンテンツ提供サーバー(150）から使用者端末機(110）に伝送されるHTTP回答を伝達してもらって、HTTP回答のヘッダーに明示されたコンテンツ長さ(Content-Length)である2709をＬ値として獲得する。また、ヘッダー長さ(Header-Length）を計算して、計算されたヘッダー長さである168 をＭ値として獲得する。
【００６３】
以後TCP セグメント(Segments)がずっとコンテンツ提供サーバー(150）から使用者端末機(110）に伝送されることができる（段階 540）。使用者端末機(110）からコンテンツ提供サーバー(150）にTCP アックメッセージが伝送されれば、課金処理装置(140）は、パケットコピー機(135) などから伝達してもらった当該TCP アックメッセージのアック番号である2878をＹ値として獲得する（段階 545）。
【００６４】
段階 550で、課金処理装置(140）はＫ値、Ｌ値及びＭ値の合計とＹ値の大きさを比べることで、コンテンツ提供サーバー(150）から伝送されたコンテンツが正常に使用者端末機(110）に受信されたのか否かを判断する。そして、正常に伝送が完了したと判断されれば課金を遂行する。すなわち、Ｙ値がＫ値、Ｌ値及びＭ値の合計以上の場合、コンテンツの伝送が正常に完了したと判断する。図５に示したデータフローチャートではＹ値が2878で、Ｋ値（すなわち、1)、Ｌ値（すなわち、2709) 及びＭ値（すなわち、168)の合計が2878であり、両方の値が等しいので課金処理装置(140）はコンテンツの伝送が正常に完了したと判断する。そして、HTTP回答に含まれたコンテンツの大きさ情報及び通信網利用時間などの課金基礎データを利用して課金を遂行する。勿論、課金処理装置(140）が実質的に課金データを生成する方法は、従来の課金データ生成方法や開発可能なすべての課金データ生成方法が制限なしに適用されられることは自明である。
【００６５】
そして、上述したＫ値、Ｌ値及びＭ値の合計とＹ値の大きさを比べる方法をコンテンツ提供サーバー(150）に適用すれば、コンテンツ提供サーバー(150）は、使用者端末機(110）に伝送したコンテンツの正常伝送可否を容易に確認することができる。したがって、正常伝送が成り立たなかったと判断されれば、コンテンツ提供サーバー(150）は、当該コンテンツの再伝送を遂行することもできる。
【００６６】
図６は、本発明のまた別の望ましい実施例による無線データサービスでのトランザクション認識方法を示したフローチャートである。
図６を参照すれば、段階 610で、使用者端末機(110）は、使用者によって選択された任意のコンテンツに対するHTTP要請(Request）を、通信網を通じてプロキシサーバー(145）に伝送する。当該 HTTP 要請は、基地局(125）、データサービス装置(130）、パケットコピー機(135) などを経由してプロキシサーバー(145）に伝達される。
【００６７】
段階 615で、課金処理装置(140）は、パケットコピー機(135）から複製された複製HTTP要請(Request）を受信して、受信された複製HTTP要請からURL を抽出する。次に、課金処理装置(140）は、抽出されたURL 及びあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する。第１ハッシュ値生成のために使われるハッシュアルゴリズムは、プロキシサーバー(145）で第２ハッシュ値を生成するために使われるハッシュアルゴリズムと同じであればどんなハッシュアルゴリズムでも適用可能である。例えば、本発明に適用されることができるハッシュアルゴリズムとしては MD5、SHA-1 、HAS-160 などがある。任意の変数とハッシュアルゴリズムを利用してハッシュ値を生成する方法は主旨の事項なのでこれに対する説明は略する。
【００６８】
段階 620で、プロキシサーバー(145）は、使用者端末機(110）からHTTP要請(Request）を受信して、受信されたHTTP要請からURL を抽出する。次に、プロキシサーバー(145）は、抽出されたURL 及びあらかじめ指定されたハッシュアルゴリズムを利用して第２ハッシュ値を生成する。プロキシサーバー(145）が第２ハッシュ値を生成するために使うハッシュアルゴリズムは、課金処理装置(140）が第１ハッシュ値を生成するために使ったハッシュアルゴリズムと等しくなければならない。
【００６９】
段階 625で、プロキシサーバー(145）は、使用者端末機(110）から受信された HTTP 要請(Request）を、それに相応するコンテンツ提供サーバー(150）に伝送する。
以後、プロキシサーバー(145）は、段階 630で、当該コンテンツ提供サーバー(150）から当該HTTP要請（例えば、株式情報提供要請）に相応するコンテンツデータを含む元のHTTP回答(Response)を受信する。
【００７０】
プロキシサーバー(145）は、段階 630を通じて、受信された元のHTTP回答がどんなHTTP要請に相応することなのかを認識することができるので、段階 635で、元のHTTP回答のヘッダー(Header)に、新しいフィールド値として段階 620を通じて生成した第２ハッシュ値を挿入して変換HTTP回答を生成する。プロキシサーバー(145）は、第２ハッシュ値を元のHTTP回答のヘッダーに挿入の際、使用可能なフィールド名前は、使用者端末機(110）とプロキシサーバー(145）または使用者端末機(110）とコンテンツ提供サーバー(150）間にあらかじめ定義されたフィールドの名前と一致しない場合には制限なしに使われることができる。
【００７１】
そして、プロキシサーバー(145）は、段階 640で、変換HTTP回答(Response)を、通信網を通じて使用者端末機(110）に伝送する。この時、当該変換HTTP回答は、パケットコピー機(135）、データサービス装置(130）、基地局(125) などを経由して使用者端末機(110）に伝送されることができる。
【００７２】
段階 645で、課金処理装置(140）は、パケットコピー機(135）によって複製され伝送される複製変換HTTP回答を受信し、受信された複製変換HTTP回答のヘッダーフィールドに挿入された第２ハッシュ値を抽出する。課金処理装置(140）の第２ハッシュ値抽出のため、第２ハッシュ値を含んでいるフィールド名前はプロキシサーバー(145）と課金処理装置(140）間に共有されなければならない。
【００７３】
段階 650で、課金処理装置(140）は、段階 615で生成した第１ハッシュ値と段階 645で抽出した第２ハッシュ値が一致するのか否かを判断する。一致すれば段階 655に進行して、当該変換HTTP回答を、段階 610を通じて伝送されたHTTP要請に対する回答として認識する。すなわち、当該HTTP要請と当該変換HTTP回答が対(Pair)に認識される。しかし、第１ハッシュ値と第２ハッシュ値が不一致する場合には、HTTP要請と変換HTTP回答を別個の物だと認識して段階を終了する。勿論、当該HTTP要請に相応する変換HTTP回答が受信されるまで段階 645ないし段階 655は繰り返して遂行されることができる。
【００７４】
例えば、使用者端末機(110）から第１HTTP要請及び第２HTTP要請がプロキシサーバー(145）に伝送された場合、課金処理装置(140）は、パケットコピー機(135）から受信した第１複製HTTP要請に対する第１ハッシュ値を生成し、第２複製HTTP要請に対する第２ハッシュ値を生成する。
【００７５】
そして、プロキシサーバー(145）は、受信された第１HTTP要請及び第２HTTP要請をそれぞれ相応するコンテンツ提供サーバー(150）に伝送する。そして、この過程で、第１HTTP要請及び第２HTTP要請に対してそれぞれ相応する第３ハッシュ値及び第４ハッシュ値を生成して保存する。
【００７６】
プロキシサーバー(145）は、任意のコンテンツ提供サーバー(150）から元のHTTP回答が受信されれば、当該元のHTTP回答が第１HTTP要請、第２HTTP要請のうちどれに相応するのかを判断する。次いで、プロキシサーバー(145）は、相応するハッシュ値を元のHTTP回答のヘッダーに挿入して変換HTTP回答を生成する。そして、生成された変換HTTP回答を使用者端末機(110）に伝送する。
【００７７】
課金処理装置(140）は、パケットコピー機(135）から複製変換HTTP回答を受信して、受信された複製変換HTTP回答のヘッダーに含まれたハッシュ値を抽出する。抽出されたハッシュ値が第１ハッシュ値、第２ハッシュ値のうちどれに一致するのかを判断して、一致するハッシュ値に相応するHTTP要請との対(Pair)として認識する。
【００７８】
若しも、同一のURL を要請する連続の二つのHTTP要請（すなわち、第１HTTP要請及び第２HTTP要請）が使用者端末機(110）からプロキシサーバー(145）に伝送される場合、課金処理装置(140) 及びプロキシサーバー(145）が生成する複数のハッシュ値は、全部同じであることが有り得る。この場合、各HTTP要請の時間的手順をハッシュ値のみを利用して区分することはできない。しかし、URL が同じである場合、二つのHTTP要請に対する二つのHTTP回答（すなわち、第１変換HTTP回答及び第２変換HTTP回答）がHTTPメッセージ水準で事実上同じであるので、課金処理装置(140）は、HTTP要請及びHTTP回答の到着手順にかかわらずHTTP対認識(HTTP Pair Matching)を遂行することができる。
【００７９】
また、同一のURL を要請する複数のHTTP要請に相応して、コンテンツ提供サーバー(150）から受信されるHTTP回答がそれぞれ異なる場合も発生することがあるが、これは使用者端末機(110）とコンテンツ提供サーバー(150）間のネットワークが非常に不安定な場合にだけ発生されることに過ぎない。
【００８０】
図７は、本発明のまた別の望ましい実施例による無線データサービスでのトランザクション認識方法を示したフローチャートである。
図７に示したフローチャートは、図２に示したシステム構成のように課金処理装置(140）がデータサービス装置(130）とプロキシサーバー(145) の間に具備されている場合のトランザクション認識方法を示している。すなわち、使用者端末機(110）とコンテンツ提供サーバー(150）間に送受信されるパケットデータが常に課金処理装置(140）を経由して送受信される場合のHTTP要請／回答対の認識方法に関することである。
【００８１】
図７を参照すれば、段階 710で、課金処理装置(140）は、使用者端末機(110）から任意のコンテンツに対するHTTP要請(Request）を受信する。課金処理装置(140）は段階 715で、受信されたHTTP要請をプロキシサーバー(145）に伝送する。次に、段階 720で、課金処理装置(140）は、当該HTTP要請に含まれたURL 及びあらかじめ指定されたハッシュアルゴリズム(Hash Function）を利用して第１ハッシュ値を生成する。勿論、段階 715及び段階 720の順序は変更されることができる。
【００８２】
課金処理装置(140）は、段階 725で、変換HTTP回答をプロキシサーバー(145）から受信して、受信された変換HTTP回答を使用者端末機(110）に伝送する。プロキシサーバー(145）での変換HTTP回答を生成する方法は、前記の図６を参照して説明したところと同じであるのでこれに対する説明は略する。
【００８３】
段階 730で、課金処理装置(140）は、段階 725を通じて受信された変換HTTP回答のヘッダーに含まれた第２ハッシュ値を抽出する。段階 735で、課金処理装置(140）は、段階 720を通じて生成した第１ハッシュ値と段階 730を通じて抽出した第２ハッシュ値が一致するのかを判断する。一致する場合には段階 740に進行して、当該変換HTTP回答が段階 715を通じて伝送されたHTTP要請に対する回答であると認識する。すなわち、当該HTTP要請と当該変換HTTP回答が対(Pair)であると認識される。しかし、第１ハッシュ値と第２ハッシュ値が不一致する場合にはHTTP要請と変換HTTP回答が別個の物だと認識して段階を終了する。勿論、当該HTTP要請に相応する変換HTTP回答が受信されるまで段階 725ないし段階 740は繰り返して遂行されることができる。また、段階 725での受信された変換HTTP回答を使用者端末機(110）に伝送する過程は、受信された変換HTTP回答を利用して段階 730ないし段階 740を完了した後に遂行されることもできる。
【００８４】
図８は、本発明のまた別の望ましい実施例によるサービス別統合課金情報生成方法を示したフローチャートであり、図９は、本発明のまた別の望ましい実施例による無線データサービス使用フローを例示した図面であって、図１０は、本発明のまた別の望ましい実施例による統合IPDR生成時の間違い発生をとり除ける方法を示したフローチャートである。      
【００８５】
図８を参照すれば、課金処理装置(140）は、段階 810で、パケットコピー機(135）から複製パケットデータを受信して、段階 815に進行して、トランザクション(Transaction) 単位で基礎IPDR(Internet Protocol Detail Record、インターネット課金情報）を生成する。パケットコピー機(135）が省略されられるのは前記で説明したとおりである。本発明においてトランザクション(Transaction）と言うのは、一つのTCP セッション内で、使用者端末機(110）とプロキシサーバー(145）間に取り交わすそれぞれのHTTP要請(Request）と相応するHTTP回答(Response)の対を意味する。基礎IPDR内には、トランザクションのスタート時刻及び終了時刻（例えば、HTTP要請のスタート時刻及び終了時刻、HTTP回答のスタート時刻及び終了時刻）、トランザクションを構成するパケットデータの大きさ、コンテンツ提供サーバー(150）の接続住所（例えば、各トランザクションに使われたURL のすべてのリスト）、使用者情報、インターネット使用の終了事由（例えば、正常終了、非正常終了) などが含まれることができる。
【００８６】
課金処理装置(140）がトランザクション(Transaction）を認識する方法には何らの制限はない。ただし、ここでは理解の便宜をはかるため、課金処理装置(140）がトランザクションを認識する二つの方法のみを例示する。
【００８７】
先ず、課金処理装置(140）とプロキシサーバー(145）で、同じハッシュアルゴリズム(Hash Function）を利用してそれぞれハッシュ値を生成した後、課金処理装置(140）で、当該ハッシュ値が一致するのか否かでトランザクションを認識する方法が適用されられる。勿論、ハッシュ値の一致可否でトランザクションを認識する過程は別の情報分析装置（図示してない）で遂行されることができるし、課金処理装置(140）は情報分析装置のトランザクション認識結果を利用して課金処理装置(140）がトランザクション単位で基礎IPDRを生成することもできる。
【００８８】
ハッシュ値の一致可否でトランザクションを認識する方法に対して手短に説明すれば次のとおりである。
使用者端末機(110）から任意のコンテンツに対するHTTP要請(Request）が伝送されれば、当該HTTP要請はデータサービス装置(130）、パケットコピー機(135) などを経由してプロキシサーバー(145）に伝送される。課金処理装置(140、または情報分析装置である、以下同一）は、パケットコピー機(135）から複製された複製HTTP要請を受信して、受信された複製HTTP要請からURL を抽出する。次いで、課金処理装置(140）は、抽出されたURL 及びあらかじめ指定されたハッシュアルゴリズム(Hash Function、例えば MD5, SHA-1, HAS-160等）を利用して第１ハッシュ値を生成する。プロキシサーバー(145）は、受信されたHTTP要請からURL を抽出した後、抽出されたURL 及びあらかじめ指定されたハッシュアルゴリズムを利用して第２ハッシュ値を生成する。プロキシサーバー(145）は、受信されたHTTP要請(Request）をこれに相応するコンテンツ提供サーバー(150）に伝送して、当該コンテンツ提供サーバー(150）から当該HTTP要請（例えば、株式情報提供要請）に相応するコンテンツデータを含む元のHTTP回答(Response)を受信する。プロキシサーバー(145）は、受信された元のHTTP回答がどんなHTTP要請に相応することなのかを認識することができるので、元のHTTP回答のヘッダー(Header)に新しいフィールド値として、相応するHTTP要請に対して生成された第２ハッシュ値を挿入して変換HTTP回答を生成する。
【００８９】
そして、プロキシサーバー(145）は、変換HTTP回答(Response)を、通信網を通じて使用者端末機(110）に伝送するし、この過程でパケットコピー機(135）は、変換HTTP回答の複製である複製変換HTTP回答を課金処理装置(140）に伝送する。課金処理装置(140）は、受信された複製変換HTTP回答のヘッダーフィールドに挿入された第２ハッシュ値を抽出して、第１ハッシュ値と第２ハッシュ値が一致するのか否かを判断する。一致する場合、当該変換HTTP回答が第１ハッシュ値に相応するHTTP要請と対(Pair)であると認識する。パケットコピー機(135）が省略されることもできるのは前記で説明したとおりである。
【００９０】
次に、プロキシサーバー(145）が、HTTP要請(Request）に相応するHTTP回答(Response)が受信されればHTTP要請及びHTTP回答に対する課金情報をHTTP回答内に挿入して、データサービス装置(130）に伝送する方法である。この方法を適用すれば、課金処理装置(140）は、パケットコピー機(135）から課金情報が含まれたHTTP回答の複製パケットデータを受信して、受信された複製パケットデータを利用してトランザクション認識及び当該パケットデータに対する課金を遂行することができる。
【００９１】
プロキシサーバー(145）のHTTP回答のヘッダー情報修正を通じるトランザクション認識及び課金データ生成方法を手短に説明すれば、次のとおりである。
使用者端末機(110）から任意のコンテンツに対するHTTP要請(Request）が伝送されれば、当該HTTP要請は、データサービス装置(130）、パケットコピー機(135) などを経由してプロキシサーバー(145）に伝送される。プロキシサーバー(145）は、受信されたHTTP要請(Request）をこれに相応するコンテンツ提供サーバー(150）に伝送して、当該コンテンツ提供サーバー(150）から当該HTTP要請（例えば、株式情報提供要請）に相応するコンテンツデータを含む元のHTTP回答(Response)を受信する。プロキシサーバー(145）は、元のHTTP回答からHTTPヘッダー情報を抽出して、抽出されたHTTPヘッダー情報内に課金基礎データを挿入して変換HTTP回答を生成する。課金基礎データは、例えば、HTTP要請(Request）のバイト数、HTTP回答(Response)のバイト数、当該コンテンツ提供サーバー(150）の接続住所、加入者情報などであることができる。プロキシサーバー(145）は、使用者端末機(110）からどんなデータに関する要請(HTTP Request)を受信したのか、当該要請をどんなコンテンツ提供サーバー(150）に伝送したのか等に関するセッション関連情報をもう分かっているし、HTTP情報を管理するので、当該課金基礎データをHTTPヘッダー内に容易に挿入することができる。
【００９２】
以後、プロキシサーバー(145）は、変換HTTP回答をパケットコピー機(135）、データサービス装置(130) などを経由して使用者端末機(110）に伝送する。パケットコピー機(135）は、受信された変換HTTP回答を複製して複製変換HTTP回答を課金処理装置(140）に伝送する。課金処理装置(140）は、複製変換HTTP回答のヘッダー内に挿入された課金基礎データを利用してトランザクションに対する課金を遂行する。当該課金基礎データがHTTP要請のバイト数、HTTP回答のバイト数、コンテンツ提供サーバー(150）の接続住所などを含んでいるので、課金処理装置(140）は、HTTP要請及びHTTP回答に対する課金を別に遂行する必要がない。また、プロキシサーバー(145）がトランザクションの構成作業を遂行するので正常のHTTP回答が存在する場合だけ課金が成り立つことができる。
【００９３】
勿論、以外にも課金処理装置(140）がトランザクション（任意のHTTP要請とこれに相応するHTTP回答の対）を認識する多様な方法が存在することができる。そして、以下では、課金処理装置(140）が、任意のHTTP要請と任意のHTTP回答が対に認識されて、トランザクションを構成したことを前提にして説明する。
【００９４】
段階 820で、課金処理装置(140）は、段階 815を通じて生成された基礎IPDRをサービス群別に分類する。図９に、任意の使用者の無線データサービス使用フローが例示されている。移動通信サービス事業者は、サービス政策(service plan)によって、多様なサービスを複数のサービス群に分類（例えば、URL を基準にしたサービス群の分類）することができる。以下では、接続住所（例えば、URL)の中、ドメイン名称が同じである場合、同じサービス群に分類される場合を仮定して説明する。そして、図９に示された無線データ利用フローは、使用者が、サービス群Ａ、サービス群Ｂ及びサービス群Ｃのような複数のサービス群の無線データサービスを利用した場合と仮定する。
【００９５】
課金処理装置(140）は、段階 825で、任意のサービス群に分類された基礎IPDRを併合(Aggregation）して統合IPDRを生成し、段階 830に進行してTCP セッションの時間情報及びIPDRを利用した課金を遂行する。
【００９６】
以下、図９及び図１０を参照して、統合IPDRを生成して課金を遂行する過程を詳しく説明する事にする。上述したように図９には、使用者が、使用者端末機(110）とプロキシサーバー(145）間に繋がれた一つのTCP セッションで複数のサービス（すなわち、サービス群Ａ、サービス群Ｂ及びサービス群Ｃ）を利用する場合を仮定した無線データ利用フローが例示されている。図９に例示された無線データ利用フロー及び図１０のフローチャートを利用して、ネットワークが不安定な状態または使用者端末機(110）が非正常的に動作する場合にも正常に統合IPDRを生成する方法を説明する。
【００９７】
図１０を参照すれば、段階 1010 で、課金処理装置(140）は、PPP 接続の終了時刻であるｔend が認知されるのか否かを判断する。ｔend が認知されれば段階 1015 に進行してｔend をｔFIN として設定する。しかし、ｔend が認知されなければ段階 1020 に進行してTCP セッションの終了前の最後のトランザクションの終了時刻であるｔend をｔC2として設定する。一般的に、移動通信サービスシステム(120）ではPPP のスタート時刻（ｔstart ) と終了時刻（ｔend ) を高い精密度で把握することができる。また、課金処理装置(140）は、TCP セッションのスタート時刻（ｔsyn ) も把握することができる。しかし、ネットワークの不安定性及び使用者端末機(110）の動作の間違いなどによって、ｔFIN の認知のパケットが発生しなくて、ｔFIN が存在しない場合（例えば、無限大に大きくなる場合）が発生させられるからである。
【００９８】
段階 1025 で、課金処理装置(140）は、TCP セッション連結中に発生されたトランザクションのうち、終了に対する間違い発生のトランザクションが存在するのか否かを判断する。課金処理装置(140）は、例えば、任意のトランザクションの終了が認知されない場合または、任意のトランザクションの終了が次のトランザクションのスタート時刻以後に発生した場合などをトランザクションの終了に対する間違いとして判断することができる。終了の間違いがないと判断されれば、段階 1035 に進行する。一般的にTCP セッション中に存在する複数のトランザクションに間違いが存在しないためには、図９に示した無線データ利用フローは下の表１のような関係を満足しなければならない。
【００９９】
【表１】
2008099333.tif 000003
【０１００】
以外に、TCP セッションの使用時間が、各トランザクションの総使用時間の合計と違うという "ｔFIN −ｔsyn −サービス群Ａ使用時間（すなわち、（ｔa2−ｔa1）＋（ｔa4−ｔa3）＋（ｔa6−ｔa5））＋サービス群Ｂ使用時間（すなわち、（ｔb2−ｔb1）＋（ｔb4−ｔb3）＋サービス群Ｃ使用時間（すなわち、（ｔc2−ｔc1））" を満足しなければならない。これは、一般的に各トランザクション間に遊休時間(idle time）が存在するのを意味することである。
しかし、終了の間違いがあると判断されれば、段階 1030 に進行してトランザクションの終了時刻を再定義する。先ず、TCP セッションのうち任意のトランザクションの終了が認識されない場合には、次のトランザクションの終了時刻が次のトランザクションのスタート時刻と同じであると定義することができる。例えば、第３トランザクション(930）の終了が認識されない場合には、第３トランザクション(930）の終了時刻（すなわち、ｔa4）は第４トランザクション(940）のスタート時刻（すなわち、ｔb3）と同じである（ｔa4＝ｔb3）と定義することができる。
【０１０１】
次に、任意のトランザクションの終了が次のトランザクションのスタート時刻以後に発生した場合、課金政策によって、トランザクションの終了時刻を次のトランザクションのスタート時刻と同一であると再定義することができる。例えば、第１トランザクション(910）の終了が第２トランザクション(920）のスタート時刻（すなわち、ｔb1）以後に発生した場合、第１トランザクション(910）の終了時刻（すなわち、ｔa2）は第２トランザクション(920）のスタート時刻（すなわち、ｔb1）と同じである（ｔa2＝ｔb1）と再定義することができる。
【０１０２】
以後、段階1035で、課金処理装置(140）は、サービス別利用時間を合算する。すなわち、課金処理装置は、上述したように、各トランザクションに含まれた接続住所を利用して各トランザクションに相応するサービス群を分類することができるし、分類されたサービス群別にトランザクションの利用時間を合算する。
【０１０３】
また、段階1040で、課金処理装置(140）は、遊休時間(Idle Time）を算出する。遊休時間とは、上述したように、TCP セッションが繋がれたが、トランザクションによって占有されなかった時間（すなわち、ｔIDLE＝（ｔFIN −ｔsyn ）−（サービス群Ａ使用時間＋サービス群Ｂ使用時間＋サービス群Ｃ使用時間))を意味する。
【０１０４】
段階 1045 で、課金処理装置(140）は、サービス利用に対する課金（すなわち、データサービス使用時間及びコンテンツ利用料) 及び算出された遊休時間に対する課金を遂行する。本発明による課金処理装置(140）は、サービス利用時間及び遊休時間に対する正確な時間算出が可能なので使用者の無線データサービス利用に相応する最適の課金が可能である。すなわち、本発明は、従来の TCPセッション中であれば使用者がコンテンツデータを要請するとか提供してない遊休時間に対しても高価の課金が成り立つ問題点を解決することができる。
【０１０５】
以上のように、本発明による無線データサービス利用に対するサービス別統合課金情報生成方法を説明するにおいて、TCP セッション中に発生された複数のトランザクションを、接続住所を基準にしてサービス群別に分類した後、特定サービス群別に含まれた複数のトランザクションの使用時間を合算して課金を遂行する方法を中心に説明した。すなわち、サービス群別に、使用時間当り使用料金（すなわち、通信網使用料）やコンテンツ使用料金（すなわち、コンテンツ使用料）が等しく適用される場合を仮定したのである。
【０１０６】
しかし、場合によっては、同一サービス群に含まれるトランザクションであっても特定トランザクションは、通信網使用料だけが賦課（例えば、コンテンツデータ検索サービス）になるし、特定トランザクションは、通信網使用料とコンテンツ利用料が賦課（例えば、コンテンツデータダウンロードサービス）になる場合があり得る。
【０１０７】
また、一つのTCP セッション中に発生された複数のトランザクションであっても特定トランザクションは、使用時間による課金が成り立つし、他のトランザクションは、パケット使用量による課金が成り立つ場合もあり得る。
【０１０８】
しかし、こういう場合に対しても、上述したサービス群別トランザクションの合算方法が類似に適用されることができるのは自明である。この場合、例えば、接続住所別に策定されたサービス群に属する詳細サービス群（例えば、時間当り課金サービス、パケット課金サービス、コンテンツ使用料賦課サービスなど）を具備すれば充分であるからこれに対する説明は略する。勿論、以外にも多様な料金商品による使用者の無線データサービス利用に対応する料金賦課のため多様なサービス群策定方法が適用されられることは自明である。
【０１０９】
また、今まで、本発明によるサービス別統合課金情報生成システムの構成において、パケットコピー機(135）を含む場合のみを中心に説明した。そして、この場合、課金処理装置(140）が、パケットコピー機(135）から受信される複製パケットデータを利用して基礎IPDR及び統合IPDRを生成した（図１参照）。
【０１１０】
しかし、図２に示したように、パケットコピー機(135）は省略されることができるし、この場合にも課金処理装置(140）は類似の方法で基礎IPDR及び統合IPDRを生成することができる。すなわち、課金処理装置(140）を経由して送受信される当該パケットデータを利用して基礎IPDR及び統合IPDRを生成するのである。パケットコピー機(135）を含まない場合、課金処理装置(140）が、当該パケットデータを利用してIPDRを生成する方法は当業者が容易く具現することができるはずなのでこれに対する説明は略する。
【０１１１】
図面と発明の詳細な説明は、ただ本発明の例示的なことであり、これはただ本発明の説明のため使われたことであって、意味限定や特許請求範囲に記載した本発明の範囲を制限するために使われたことではない。よって本技術分野の通常の知識を持った者であれば、今後多様な変形及び均等な別の実施例が可能であるということを理解するであろう。したがって本発明の真正な技術的保護範囲は添付された特許請求範囲の技術的思想によって決まらなければならない。
【図面の簡単な説明】
【０１１２】
【図１】本発明の望ましい一実施例による移動通信サービスシステムの構成を概略的に示した図面である。
【図２】本発明の望ましい別の実施例による移動通信サービスシステムの構成を概略的に示した図面である。
【図３】本発明の望ましい一実施例による課金処理装置の課金データ生成時点決定のためのデータフローチャートである。
【図４】一般的なTCP セグメント形式を示した図面である。
【図５】本発明の望ましい別の実施例による課金処理装置の課金データ生成時点決定のための具体的なデータフローチャートである。
【図６】本発明の望ましいまた別の実施例による無線データサービスでのトランザクション認識方法を示したフローチャートである。
【図７】本発明の望ましいまた別の実施例による無線データサービスでのトランザクション認識方法を示したフローチャートである。
【図８】本発明の望ましいまた別の実施例によるサービス別統合課金情報生成方法を示したフローチャートである。
【図９】本発明の望ましいまた別の実施例による無線データサービス利用のフローを例示した図面である。
【図１０】本発明の望ましいまた別の実施例による統合 IPDR 生成時の間違い発生をとり除く方法を示したフローチャートである。
【符号の説明】
【０１１３】
120 : 移動通信サービスシステム
125 : 基地局(BTS：Base Transceiver Station) 
130 : データサービス装置
135 : パケットコピー機
140 : 課金処理装置
145 : プロキシサーバー
【図１】
2008099333.tif 000004
【図２】
2008099333.tif 000005
【図３】
2008099333.tif 000006
【図４】
2008099333.tif 000007
【図５】
2008099333.tif 000008
【図６】
2008099333.tif 000009
【図７】
2008099333.tif 000010
【図８】
2008099333.tif 000011
【図９】
2008099333.tif 000012
【図１０】
2008099333.tif 000013