JP6050526B2 - 通信費算出方法、管理装置、及びネットワークシステム - Google Patents

Description

参照による取り込み

本出願は、2014年1月22日に出願された日本特許出願第2014-009099号の優先権を主張し、その内容を参照することにより、本出願に取り込む。

開示される主題は、ネットワークシステムにおいて、ネットワークを介してデータ等を購入する際の課金方法に関する。

昨今、大容量コンテンツの普及により、モバイルトラフィックが急増している。モバイルネットワークシステムを運営するモバイル通信事業者は、その対策に多大な投資を強いられている現状がある。また、ARPU(Average Revenue Per User)の低下もあり、モバイル通信事業者として企業収益の減少が危惧されている。このような背景の下、モバイル通信事業者の収益を支える基盤技術の確立が急がれている。

特開平11-55252号公報

一般に、モバイル通信事業者は、モバイル通信を利用するユーザと契約を結び、その対価として通信費をユーザから得ている。この通信費は、ユーザの利用した料金を、モバイル通信事業者がユーザへ請求している。ユーザがサービス事業者の提供する有料コンテンツ等をモバイル通信経由で入手（ダウンロード）する場合、ユーザはコンテンツ代金とダウンロードに要した通信費を負担している。特許文献１の技術には、ユーザが利用したモバイル通信の中で、サービス事業者の提供するサービス利用時の通信を識別し、ユーザとサービス事業者の間で決まった関数に基づいた通信費負担割合を算出し、その通信費をユーザとサービス事業者に請求する技術が開示されている。

特許文献１の技術では、HTTP（Hypertext Transfer Protocol）レイヤの情報を利用してサービス事業者の識別等を行える。しかし、例えば、ユーザがサービス事業者の提供するサービスを利用した場合（サービス事業者へ代金支払いを行った場合）と、代金の支払いがなく、単に情報等を閲覧した場合との区別を行っていない。サービス事業者にとって、サービスを利用し、代金を支払うユーザを重要視（優遇）して通信費を負担するといった仕組みが考えられる。しかし特許文献１の技術では、サービスを利用した際の通信費とそれ以外の通信費を区別することができず、上記のようなサービスに対応することができない。

このような事象に鑑みて、本明細書では、ネットワークシステムにおいて、端末がサーバ装置からデータ等を購入する際の課金について、ネットワークシステムを運営する事業者が、特定のデータを購入等により端末が取得する際の端末とサーバ装置間の通信費用の算出と、その通信費用の負担先を決定する技術が開示される。

例えば、ユーザがサービスを利用した際の通信の通信費と、単に情報の閲覧等を行った際の通信の通信費を区別して算出する技術が開示される。

ネットワークシステムとは、例えば、WWW（World Wide Web）やメールシステム、データセンタ等のサーバ装置と端末との間で、データ通信する構成を指す。

本明細書では、より具体的には、ユーザがサービスを提供するサービス事業者のサーバからサービスを利用する際の通信費算出方法であって、ユーザが使用した通信の通信量の情報を含む通信ログと、通信ログそれぞれに対してユーザがサービスを利用したか否かを示す情報を対応づけ、対応づけた通信ログを格納した通信ログ管理テーブルを用いて、ユーザがサービスの利用に使用した通信量を算出する態様が開示される。

上記態様によれば、ユーザの要求に基づきサービス事業者の提供するサービスを利用した通信の通信量と、ユーザが情報の閲覧のみを行った通信の通信量を区別することができる。これにより、ユーザがサービスを利用する際の通信費を算出することができる。

開示によれば、ネットワークを介してサービスを利用する際の課金が適切に行える。

本明細書において開示される主題の、少なくとも一つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。

コンピュータシステムの基本的な構成例を示す図である。 各実施例が実現するサービスのモデルを例示する図である。 実施例１のコンピュータシステムを構成する管理サーバの構成例を示す図である。 実施例１のコンピュータシステムを構成するゲートウェイの構成例を示す図である。 実施例１の管理サーバにおいて実行される管理処理の一例を示すフローチャートである。 実施例１の管理サーバにおいて実行される通信ログ解析処理の一例を示すフローチャートである。 実施例２のゲートウェイにおいて実行されるTCPレイヤ処理の一例を示すフローチャートである。 実施例２のゲートウェイにおいて実行される中継処理の一例を示すフローチャートである。 実施例１のオンライン課金システムにおいて実行される管理情報更新処理の一例を示すフローチャートである。 実施例１のオンライン課金システムにおいて実行される通信量をポリシー及び課金ルール機能へ指示する処理の一例を示すフローチャートである。 実施例１のオンライン課金システムにおいて実行されるポリシー及び課金ルール機能からの通知を受けての処理の一例を示すフローチャートである。 実施例１のポリシー及び課金ルール機能において実行される通信量カウント処理の一例を示すフローチャートである。 実施例１の管理サーバが保持する課金管理テーブルの構成例を示す図である。 実施例１の管理サーバが保持する通信費負担元登録テーブルの構成例を示す図である。 実施例１の管理サーバとゲートウェイが保持する通信ログの構成例を示す図である。 実施例２のゲートウェイが保持するTCP通信管理テーブルの構成例を示す図である。 実施例１の管理サーバが保持する変換テーブルの構成例を示す図である。 実施例１のオンラインチャージングシステムが保持するオンラインチャージングシステム管理テーブルの構成例を示す図である。 実施例１のポリシー及び課金ルール機能が保持するポリシー及び課金ルール機能管理テーブルの構成例を示す図である。 端末とサーバ間において、HTTPダウンロードフローの一例を示す図である。 実施例２のコンピュータシステムを構成するゲートウェイの構成例を示す図である。 実施例２の管理サーバにおいて実行される管理処理の一例を示すフローチャートである。 実施例３の管理サーバが保持する通信ログ管理テーブルの構成例を示す図である。 実施例１のオンライン課金システムのメモリ内に格納されるプログラムと情報の例を示す図である。 実施例１のポリシー及び課金ルール機能が動作するサーバのメモリ内に格納されるプログラムと情報の例を示す図である。 実施例１のポリシー及び課金施行機能が動作するサーバのメモリ内に格納されるプログラムと情報の例を示す図である。

特許文献１の方法では、ユーザがサービスを利用した分の通信費と、サービスを利用せず、単に情報を閲覧した場合の通信費を区別して算出することができない。この結果、サービス提供事業者が、サービスを利用したユーザの通信費を負担するという仕組みを行うことができない。また、このような仕組みができないため、ユーザの通信費の負担が大きくなってしまうという問題が生じる。ユーザが通信費を負担する割合が増加することになり、モバイル通信を用いたサービス事業者のサービス利用が少なくなっていくことが考えられる。その結果、サービス事業者の収入が減少していくことが考えられる。

また、通信量を細かく計測して通信費として請求することは、モバイル通信の中で、特にプリペイド型の契約形態で影響が大きい。ポストペイド型の契約では、通信費を一定とする料金設定があるが、プリペイド型の料金設定では、通信費の従量課金が一般的であるためである。

本実施例では、プリペイド式の契約を形態のユーザを想定した場合の動作について説明する。なお、本説明におけるユーザとは端末1を使用するユーザを示す。

本実施形態のコンピュータシステムの構成は、１又は複数のPCEF（Policy and Charging Enforcement Function、ポリシーおよび課金施行機能）と、１又は複数のPCRF（Policy and Charging Rules Function、ポリシーおよび課金ルール機能）と、１又は複数のGW（Gateway、ゲートウェイ）と、１又は複数のOCS（online charging system、オンライン課金システム）と、管理サーバがネットワークで接続される。これらPCEF13やPCRF17、OCS12は、その機能を有するサーバであってもかまわない。

PCEF13はPCRF17やOCS12の通信ポリシーを実際の通信に適用させることなどを行う。PCRF17は通信速度等の通信ポリシーの管理を行なう。GW11は端末1から要求された情報の転送を行う。OCS12は通信量の管理やプリペイド残額の変換を行う。管理サーバ10は通信ログ1120の管理等を行なう。

図1は、端末1とPCEF13とGW11とOCS12、管理サーバ10、サービス事業者のサーバ16がネットワークによって接続されるコンピュータシステムの構成例を示す。端末1は、ネットワーク2を介してPCEF13と相互接続される。PCEF13は、ネットワーク5を介してOCS12と相互接続され、ネットワーク3を介してGW11と相互接続される。OCS12は、ネットワーク6を介して管理サーバ10と相互接続される。GW11は、ネットワーク7を介して管理サーバ10と相互接続され、ネットワーク4を介してインターネット15及びサービス事業者サーバ16と相互接続される。PCRF17は、ネットワーク90、91、92を介して、OCS12、管理サーバ10、及びPCEF13と相互接続される。管理サーバ10はネットワーク8を介して決済機関14と、ネットワーク93を通してユーザ情報管理サーバと相互に接続される。ユーザ情報管理サーバ18は、端末1の契約形態に関する情報を管理し、管理サーバ10に送信する機能を持つ。本実施例ではGW11や管理サーバ10、OCS12、PCRF17、PCEF13を別々のハードウエアで構成される形態を示しているが、これらが1又は複数の同じハードウエア上で動作する構成であっても構わない。サービス事業者のサーバ16は端末1から要求されたサービスの提供を行う。決済機関14は費用の決済を行なう。

図2は、本明細書で開示するモデル例を示す図である。ユーザはサービス事業者の提供するサービス（商品）を通信事業者経由で受領する。ユーザはサービス（商品）提供を受けるため、サービス事業者と契約を結び、会費等を支払う。またユーザはサービス（商品）提供を受ける際、サービス（商品）の代金をサービス事業者へ支払う。従来であれば、ユーザはサービス（商品）ダウンロードにかかった通信費を通信事業者に支払うが、本明細書のモデルではサービス事業者がその通信費を支払うモデルである。ただし、サービス事業者は、サービス事業者宛の全ての通信を対象に通信費を支払うのではなく、サービス事業者の提供するサービス（商品）を購入したユーザに限って、関連のある通信を選定した後の通信費を負担する。

図3は、管理サーバ10の構成例を示す図である。管理サーバ10は、1つ以上のCPU101と、1つ以上のネットワークインタフェース(NW I/F)102〜104、108、109と、入出力装置105と、メモリ107が内部バス等の通信路106を介して相互に接続されるコンピュータ上に実現される。

NW I/F102は、ネットワーク6を介してOCS12と接続される。NW I/F103は、ネットワーク8を介して決済機関14と接続される。NW I/F104は、ネットワーク7を介してGW11と接続される。NW I/F108は、ネットワーク91を介してPCRF17と接続される。NW I/F109は、ネットワーク93を介してユーザ管理サーバ18と接続される。

メモリ107には、以下に説明する管理機能111のプログラムと、課金管理テーブル121と、変換テーブル122と、通信費負担元登録テーブル123が格納される。管理機能111は、予め管理サーバ10のメモリ107に格納されていてもよいし、必要な時に管理サーバ10が利用可能な記録媒体を介して、メモリ107に導入されてもよい。記録媒体とは、例えば図示しない外部デバイスインタフェースに着脱可能な記憶媒体、又は通信媒体(すなわち、NW I/F102〜104に接続する有線又は無線、光等のネットワーク、又は当該ネットワークを伝搬する搬送波やディジタル信号)を指す。また、課金管理テーブル121と、変換テーブル122と、通信費負担元登録テーブル123も、メモリ107でなく、管理サーバ10に接続される利用可能な記録媒体に格納されてもよい。

管理機能111は、GW11から受信した通信ログ1120を基にして、課金対象の通信の識別と、通信範囲の確定と、それらの通信費算出する処理を実行する。通信ログ1120とは、端末１とサービス事業者16のサーバの間の接続の際に、GW11が行なった処理の記録を示すものである。

図4は、GW11の構成例を示す図である。GW11は、1つ以上のCPU1101と、1つ以上のネットワークインタフェース(NW I/F)1102〜1104と、入出力装置1105と、メモリ1107が内部バス等の通信路1106を介して相互に接続されるコンピュータ上に実現される。

NW I/F1102は、ネットワーク4を介してインターネット15経由でサービス事業者サーバ16と接続される。NW I/F1103は、ネットワーク3を介してPCEF13と接続される。NW I/F1104は、ネットワーク7を介して管理サーバ10と接続される。

メモリ1107には、以下に説明する中継機能1110と、通信ログ送信機能1111のプログラムと、通信ログ1120が格納される。中継機能1110と、通信ログ送信機能1111は、予めGW11のメモリ1107に格納されていてもよいし、必要な時にGW11が利用可能な記録媒体を介して、メモリ1107に導入されてもよい。また、通信ログ1120も、メモリ1107でなく、GW11に接続される利用可能な記録媒体に格納されてもよい。また、各プログラムにより実現される機能はプログラムに限らず、回路によって実現されてもよい。以降で説明される各プログラムも同様である。

中継機能1110は、端末１から受信した要求をサービス事業者サーバ16へ転送処理を実行する。通信ログ送信機能1111は、中継機能1110の処理で出力される通信ログ1120を管理サーバ10へ送信する処理を実行する。

図24から図26には、OCS12やPCEF13、OCRF17上のメモリ内に格納されるプログラムと情報の例を示す図である。OCS12やPCEF13、OCRF17の構成は、管理サーバ10やGW11と同様であるため、構成内に含むメモリ上の差異部のみ説明する。

図24は、OCS12上のメモリ1201内に格納されるプログラムと情報の例を示す図である。メモリ1201には、通信量を管理し、プリペイド残額との換算を行うOCS機能1202のプログラムと、OCS管理テーブル23、変換テーブル122が格納される。

図25には、PCRF17上のメモリ1701内に格納されるプログラムの例を示す図である。メモリ1701には、例えば通信速度等の通信ポリシーを管理し、OCS12と連携して残額等に応じて通信ポリシーを割り当てるPCRF処理1702のプログラムが格納される。

図26には、PCEF13上のメモリ1301内に格納されるプログラムと情報の例を示す図である。メモリ1301内には、PCRF17やOCS12の通信ポリシーを実際の通信に適用するPCRF処理1302のプログラムと、PCEF管理テーブル24が格納される。

図13は、管理サーバ10に具備される課金管理テーブル121の一例を示したものである。課金管理テーブル121には、ユーザ毎のプリペイド入金額や割引情報等が登録される。課金管理テーブル121のユーザ名欄211には、ユーザを識別するためのユーザ識別情報が登録される。入金額欄212には、ユーザ名欄211に登録されるユーザの入金額が登録される。割引区分欄213には、ユーザ毎の割引情報が登録される。遡り課金欄214には、ユーザ毎の遡り課金に関する同意情報が登録される。

図14は、管理サーバ10に具備される通信費負担元登録テーブル123の一例を示したものである。通信費負担元登録テーブル123には、通信費の負担元となるサービス事業者の情報が登録される。

通信費負担元登録テーブル123のサービス事業者欄251には、サービス事業者の名称が登録される。識別情報（URI欄）には、サービス事業者サーバ16を識別するためのURI（Uniform Resource Identifier）情報が登録される。識別情報（IP）欄253には、サービス事業者サーバ16を識別するためのIPアドレス情報が登録される。

図15は、管理サーバ10に具備される通信ログ管理テーブル124の一例を示したものである。通信ログ管理テーブル124には、端末1からサービス事業者サーバ16へのアクセスを中継したGW11の通信ログ1120が格納される。図15の１つの番号に対応する１つの行の情報が通信ログ1120である。

具体的に、通信ログ管理テーブル124には、端末1がアクセスした日時、ユーザ識別子、アクセス先情報、通信量、リクエスト条件が登録される。本実施例ではユーザ識別子はユーザ名として説明する。

通信ログ管理テーブル124のNO.欄261には、通し番号が登録される。日時欄262には、当該通信ログ1120が記録された日時情報が登録される。ユーザ名欄263には、ユーザを識別するためのユーザ名が登録され、URI欄264には、当該ユーザがアクセスしたアクセス先のURI情報が登録される。IP欄265には、アクセス先のIP情報が登録される。ポート欄266には、アクセス先サーバのポート情報が登録される。通信量欄267には、当該ユーザがアクセスしたデータのデータサイズが登録される。本実施例における通信量は、HTTPレベルでの通信量である。リクエスト条件欄268には、ユーザサービス事業者のサービスを利用したかを示す情報が登録される。例えば、ユーザがサービス事業者のコンテンツをダウンロードした場合、端末1のコンテンツのダウンロードを示す情報が登録される。この情報は、例えば、参照により本明細書に援用される非特許文献１（Generic Content Download Over The Air、＜URL：http://technical.openmobilealliance.org/Technical/release_program/download_v10.aspx＞）に記載されているようなHTTPのPOSTリクエストであって、ボディ部に「900 Success」が含むものである。これらのサービスを利用したか否かを示す情報は端末1、またはサービス事業者のサーバ16によって端末1の通信に付加され、GW11が端末1からの通信を中継する際に取得可能である。したがって、リクエスト条件の登録の有無がコンテンツをダウンロードしたか否かを示す情報となる。

図17は、管理サーバ10に具備される変換テーブル122の一例を示したものである。変換テーブル122には、データ当りの単価情報が登録される。変換テーブル122のデータサイズ欄221には、単位となるデータ量が登録される。割引区分欄222には、ユーザ毎の割引種別が登録される。金額欄223には、データサイズ221のデータ量と割引区分欄222の登録内容に基づいた単価となる金額が登録される。

図18は、OCS12に具備されるOCS管理テーブル23の一例を示したものである。OCS管理テーブル23には、OCS12がユーザ毎の残り通信量を管理するための情報が登録される。残り通信量とは、端末１が受け取ることが出来る情報の量であり、契約した使用可能な通信量から使用した通信量を減算した量である。OCS管理テーブル23のユーザ名欄231には、ユーザを識別するためのユーザ識別情報が登録される。残り通信量欄232には、ユーザ毎の残り通信量が登録される。

図19は、PCEF13に具備されるPCEF管理テーブル24の一例を示したものである。PCEF管理テーブル24には、PCEF13がユーザ毎の通信量を監視するために必要な通信量のカウンタ値や許可されている通信量が登録される。

PCEF管理テーブル24のユーザ名欄241には、ユーザを識別するためのユーザ識別情報が登録される。カウンタ値欄242には、これまで通信を行ったユーザ毎の通信量が登録される。許可通信量欄243には、当該ユーザに対して許可されている通信量が登録される。

図5は、管理サーバ10の管理機能111が通信ログ管理テーブル124の内容に基づいて商品購入した通信を特定し、その通信範囲を決め、その範囲内の通信費を算出する処理の流れの一例を示したフローチャートである。管理機能111は、決済機関14から端末1を識別するためのユーザ識別情報と該ユーザが入金した入金額を取得し、ユーザ情報管理サーバ18からユーザの割引区分の情報と遡り課金の情報を取得し、課金管理テーブル121へ登録する（S11（以下、ステップをSと表現する））。本実施例では、ユーザ識別情報としてユーザ名を使用しているが、ユーザを識別できればほかの情報でもよい。

ユーザ情報管理サーバ18への割引区分の情報と遡り課金の情報の登録は管理者が行なう。本実施例では詳しく触れないが、本実施例の採る手法は通信の内容をシステムで解析し、その結果を利用してサービス事業者等へ通信費の請求を行うものであるため、ユーザの了承を得ることを念頭においたものである。これは必須の項目ではないため、通信の内容を解析することを認められている国や自治体等の地域内では、無くても構わない。

次に、その入金額がプラスであるか確認を行う。プラス（正）判定であればS13へ移り、プラス判定でない（−）であれば最初に戻る（S12）。入金額に応じて利用可能なデータ量を算出する。この利用可能なデータ量の算出は、契約した単位情報量あたりの金額で入金額を除算することで計算できる。ここでは、変換テーブル122に登録されるデータサイズ欄221と金額欄223の情報を利用する（S13）。そして、S13で算出した通信量をOCS12へ残り通信量としてセット指示を行う（S14）。セット指示には、ユーザ名と算出した通信量が含まれている。

次に、課金管理テーブル121の遡り課金欄214に登録される情報に従って、ユーザが遡り課金に同意（OK）か否かを確認する。遡り課金欄214の登録情報がOKであればS16に移り、そうでない場合は処理を終了する（S15）。S15において遡り課金についてユーザの同意が得られている場合、通信ログ1120の解析処理を行う（S16）。本ステップは、図6に示すフローを実行する。詳細は図6説明部で述べる。S17において商品購入判定の有無を確認し、商品購入と判定された場合はS18に移り、そうでない場合はS16に移る。

図6は、管理サーバ10の管理機能111がGW11から受信した通信ログ管理テーブル124の内容を基に商品購入した通信を特定する処理の流れの一例を示したフローチャートである。

まず、管理サーバ10は通信ログ管理テーブル124から通信ログ1120を取得する（S150）。そして、取得した通信ログ1120のURIを参照し、該URIと該URIに対応するサービス事業者が通信費負担元登録テーブル123に登録されているか検索する。検索の結果、サービス事業者が登録されている場合はS152へ移り、登録されていない場合は処理を終了する（S151）。

S151において通信ログ1120の情報と通信費負担元登録テーブル123に登録されているサービス事業者が一致した場合、通信ログ管理テーブル124にユーザからのリクエスト条件268が登録されているか確認する。リクエスト条件が登録されている場合、S153へ移り、条件が一致しない場合はS150へ移る（S152）。そして、リクエスト条件268が登録されている場合、商品購入判定をONと捉え、処理を終了し（S153）、S16へ移る。

次に、S17において商品購入と判定された場合、その商品を購入に用いた通信の範囲を決定する処理を実行する（S18）。具体的には通信ログ管理テーブル124に登録されている当該ユーザの通信ログ1120を対象とし、そのURIに含まれるCookie IDが等しい商品購入が判断された通信ログ1120から過去に遡った一定期間を対象とする。または、一定期間全てを対象とする等の方式が考えられる。

S18において決定した通信範囲内の通信ログ1120を対象として、通信量の算出を行う（S19）。通信量を取得するにあたって、通信ログ管理テーブル124の通信量欄267の情報を利用する。この情報は、GW11において中継処理を実行するなかで、ユーザが要求したデータサイズであるHTTPコンテンツサイズを通信ログ1120として記録したものである。HTTPコンテンツサイズは、HTTPヘッダのContent−Length値を利用する。本ステップでは、通信範囲と決定された通信ログ1120全ての通信量の総和を算出する。

次に、管理サーバ10は、S19で算出した通信量を含めた管理テーブル更新指示をOCS12へ通知する（S20）。OCS12は、この通信量を自身が管理しているOCS管理テーブル23の残り通信量欄に登録されている値に加算する。具体的なOCS12での処理手順は図9に示すフローである。

図9は、OCS12がOCS管理テーブル23を更新する処理の流れの一例を示したフローチャートである。管理サーバ10からOCS管理テーブル23の更新指示を受信する（S31）。更新指示には更新対象のユーザ名と、算出した通信量が含まれている。OCS12は更新指示を受信すると、OCS管理テーブル23のユーザ名欄231に該当する行を検索し、その行の残り通信量欄232に算出した通信量を加算し更新する（S32）。そして、管理サーバ10に対して更新完了の応答処理を実行して終了する（S33）。

次に、S19で算出した通信量を基に、変換テーブル122を参照し、当該ユーザの割引区分に該当するデータサイズ当りの金額を算出する。ここで算出した金額は、ユーザの通信によって発生した通信費であるが、通信費負担元登録テーブル123に該当する通信先へのアクセスであるため、通信費負担元登録テーブル123のサービス事業者欄251に登録されるサービス事業者に対して、通信費を請求する（S21）。

次に、管理者のアボート処理の有無を確認し、アボート指示がある場合には処理を終了し、アボート指示がない場合はS16に移る（S22）。アボート処理とは、プログラムや処理の強制終了のことである。

図20は、端末1とサービス事業者のサーバ16の間でHTTPによる通信が行われた時の、ダウンロードフローの流れの一例を示したものである。ここで示すフローは非特許文献１やOMA（Open Mobile Alliance）で定義されているコンテンツダウンロードの仕様の一部である。例えば、このようなダウンロードフローにおいてコンテンツがダウンロードされた場合に、ダウンロードが決定するポイントを端末1からサービス事業者のサーバ16へInstall Notifyが送信され、通信事業者に設置されたGW11に届いた地点と定義する。例えば、通信範囲を決めるにあたって、このポイントを含め、過去に遡って、コンテンツ要求が行われた地点までを通信範囲を決める。これは直接コンテンツをダウンロードするに至った最少のステップを含むものであり、定義如何によっては範囲を拡大して通信範囲を決めても構わない。例えば、ダウンロードが決定したポイントのURIが同一のホストである場合などである。

図10、図11、図12は、OCS12による端末1の通信の使用による通信量カウントの流れである。

図10は、OCS12がユーザ毎の通信許可量をPCEF13へ指示する処理の流れの一例を示したフローチャートである。

まず、OCS12がOCS管理テーブル23に登録される当該ユーザ名と残り通信量に関する情報をPCEF13へ送信する（S41）。ここで、現在登録されている残り通信量全てを対象としてPCEF13へ送信してもよいし、管理者の指定するルールに則り一部だけを送信しても構わない。ここでPCEF13に通知した通信量を許可通信量と呼ぶ。次に、S41で指示した許可通信量をOCS管理テーブル23の当該ユーザが登録されている行の残り通信量欄232に登録される値から減算し、その値を新しい残り通信量として残り通信量欄232に登録し、処理を終了する（S42）。

図11は、OCS12が、PCEF13からユーザの許可通信量がゼロである通知を受信した場合に行う処理の流れの一例を示したフローチャートである。

OCS12は、PCEF13から許可通信量ゼロとの通知を受信する（S51）。

次に、OCS12は、OCS管理テーブル23の当該ユーザに該当する残り通信量欄232の値を取得し、その値がゼロか否か確認する。値がゼロの場合、S53へ移る。値がゼロでない場合、図10に示したS41〜S42を実行して終了する（S52）。S52において、値がゼロと判定された場合、PCEF13へ許可通信量ゼロを送信して処理を終了する（S53）。

図12は、PCEF13が、OCS12から許可通信量の通知を受け、その範囲内でユーザに対して通信を許可し、通信量のカウントを行う処理の流れの一例を示したフローチャートである。

OCS12から許可通信量の指示を受信する（S61）。S61で受信した許可通信量をPCEF管理テーブル24の当該ユーザの行の許可通信量欄243へ上書きする（S62）。そして、PCEF管理テーブル24の許可通信量欄243に登録された値の確認を行う。値がゼロの場合はS67へ移る。値がゼロでない場合は、S64へ移る（S63）。

S63で値がゼロと判断された場合、当該ユーザの通信を停止し、処理を終了する（S67）。

S63で値がゼロでないと判断された場合、当該ユーザの通信量カウント処理を実行する。そのカウント値はPCEF管理テーブル24のカウンタ値欄242へ登録する（S64）。 PCEF管理テーブル24のカウンタ値欄242の値と、許可通信量欄243の値を比較し、許可通信量欄243の値を超えていないか確認する。超えている場合は、S66へ移る。超えていない場合は、S64へ移る（S65）。

S65でカウンタ値が許可通信量を超えていると判定された場合、PCEF管理テーブル24のカウンタ値欄242の値と、許可通信量欄243の値をゼロと初期化し、OCS12へ許可通信量ゼロを通知し、処理を終了する（S66）。

本実施例では、ユーザがサービス事業者の提供するコンテンツ（商品）を購入した場合に、購入に関係のある通信を特定し、その通信費を算出して、サービス事業者へ請求する内容を示した。本実施例では、プリペイド式の契約形態の端末1を想定して記載したが、ポストペイド式の契約形態であっても同様の処理を行って、月末等の課金集計処理において通信費を除算させる形態も考えうる。また、本実施例に示した以外に、ある一定量の通信を行った場合にモバイル通信事業者が通信帯域を絞るといった制御を行っている場合もあり、本実施例で示した方法をそれに適用して、該当通信部の通信帯域を制限除外対象とする実施形態もありうる。また、本実施例ではコンテンツ（商品）購入を例に説明したが、サービス事業者の提供するサービスを利用するような通信の解析によって識別できるサービスの他の例であっても構わない。

本実施例によって、ユーザがサービスを利用した分の通信の通信費と、単に情報の閲覧などを行った分の通信の通信費の区別が可能となる。これにより、サービス提供事業者は、サービスを利用したユーザの通信費を負担するという仕組みを行うことが可能である。その結果、ユーザの通信費の負担を減らすことがかのうとなる。さらに、サービス事業者のサービスを利用するユーザの数が増えることも考えられる。

実施例１では、端末1からサービス事業者サーバ16の提供するコンテンツ（商品）購入に際し、端末1がコンテンツ購入時のダウンロードに関連する通信費をサービス事業者が負担する内容を記載した。その際の通信費を算出する元のデータとしてGW11の中継機能1110が出力した通信ログ1120のHTTPレベルの情報を利用する方法であった。実施例2では、通信費を算出する元のデータとして、GW11の中継機能1110と下位レイヤ情報取得機能1112が出力する通信ログ1120を利用し、通信費を算出する方法について説明する。

特許文献１の技術では、通信事業者に設置されるゲートウェイ相当の装置においてHTTPを基にした通信量の認識を行っている。特許文献１の技術では、例えばTCP（Transmission Control Protocol）を利用した場合の通信確立要求等の通信について考慮されておらず、これらの通信費をモバイル通信事業者が負担することになってしまう。例えば、TCPを利用した通信では、３ウェイハンドシェイクと呼ばれるコネクション確立の仕組みがあり、通信を行う端末とサーバ間で、通信確立要求や確認応答といった通信が行われる。この通信確立の後にユーザがサーバに対して、データ要求がHTTP等の上位プロトコルによってなされる。

特許文献１の技術では、この３ウェイハンドシェイクに伴う通信を考慮せずに通信量のカウントを行う。そのため、前述したように、サービス事業者が代金を支払うユーザを重要視（優遇）して通信費を負担するビジネスモデルを採る際、例えば少量のデータを大量にダウンロードするなど、コネクションが大量に発生して、３ウェイハンドシェイクに伴う通信が多発する場合に、通信費の負担をユーザが担うことになってしまいかねない。この結果、ユーザの通信量の負担が増えるという問題が生じる。本実施例はこれらの問題に着目したものである。

本実施例で示すコンピュータシステムの構成は、実施例1に示したものと同様である。本実施例では実施例1との相違点を中心に説明する。

図21は、GW11の構成例を示す図である。メモリ1107には、以下に説明する下位レイヤ情報取得機能1112のプログラムと、TCP通信管理テーブル1121、およびアクセスページログ1222が格納される。下位レイヤ情報取得機能1112は、予めGW11のメモリ1107に格納されていてもよいし、必要な時にGW11が利用可能な記録媒体を介して、メモリ1107に導入されてもよい。また、TCP通信管理テーブル1121、およびアクセスページログ1222はメモリ1107でなく、GW11に接続される利用可能な記録媒体に格納されてもよい。下位レイヤ情報取得機能1112は、TCPレイヤの通信に関する通信ログ1120として取得し、より上位レイヤの中継機能1110へ通信内容を通知し、TCPレイヤとより上位レイヤとの通信ログ1120の関連付ける処理を実行する。本実施例ではTCPレイヤを基準に説明をしているが、下位レイヤとしてIPレイヤにレベルをさらに落として考えることも可能である。

図16は、GW11に具備されるTCP通信管理テーブル1121の一例を示したものである。TCP通信管理テーブル1121には、GW11が端末1から通信要求を受け、TCPレイヤで通信を確立してから通信を切断するまでの通信ログ1120が登録される。

TCP通信管理テーブル1121の日時欄271には、当該レコードの更新日時が登録される。発IP欄272には、通信要求元（端末1）のIPアドレスが登録される。発ポート欄273には、通信要求元（端末1）のポート番号が登録される。宛IP欄274には、通信要求先（GW1）のIPアドレスが登録される。宛ポート欄275には、通信要求先（GW1）のポート番号が登録される。ユーザ名欄276には、ユーザを識別するためのユーザ識別情報が登録される。URI欄277には、端末1が要求を出そうとしている通信宛先（サービス事業者サーバ16のURI）が登録される。シーケンスNO.（開始）欄278には、通信要求元（端末1）と通信確立時に設定したTCPヘッダのシーケンス番号が登録される。シーケンスNO.（終了）欄279には、通信要求元（端末1）と通信終了時のTCPヘッダのシーケンス番号が登録される。

図7は、GW11の下位レイヤ情報取得機能1112が、端末1から通信要求を受けてから通信路を確立し、必要な通信を行った後に、通信を終了する処理の一例を示したフローチャートである。

まず、GW11は通信要求元（端末1）からSYNパケット（synchronize packet）を受信する（S70 ）。そして、その応答としてACK（acknowledge）+SYNのTCPパケットを生成時のシーケンス番号をTCP通信管理テーブル1121へ登録する（S71）。その後、端末1へACK+SYNを送信する（S72）。端末1からACKを受信する（S73）。そして、端末1からのリクエスト要求を受信する（S74）。このS74の処理は図8に示すフローを実行する。詳細は図8で説明する。要求データの送信が終了すると端末1からFIN（finish）を受信する（S75）。それに対して、端末１へACKを送信する（S76）。続けて端末1へFINを送信する（S77）。その応答として端末1からACKを受信する（S78）。以上の通信の流れを終了する前に、最終受信したACKのTPCヘッダに含まれるシーケンス番号を取得し、TCP通信管理テーブル1121へ登録して処理を終了する（S79）。

図8は、GW11の下位レイヤ情報取得機能1112、及び中継機能1110が、端末1から通信要求をTCPレイヤよりも上位のレイヤで受信した時の処理の流れ一例を示したフローチャートである。本フローは、図7のS74に示したデータ受信部分の処理フローである。TCPレイヤで受信したデータを上位のアプリケーション（HTTP）レイヤでデータを受信し、その内容解析を行って、GW11としての中継処理を行う処理フロー例を示している。

TCPレイヤよりデータ受信通知を受ける（S80）。全てのデータを受信した後に、HTTPリクエストの解析を行う。この解析は、具体的にリクエスト行に含まれるURIの取得である（S81）。そして、TCP通信管理テーブル1121へURIを登録する。またユーザ認証時のユーザ識別子も同様にTCP通信管理テーブル1121へ登録する（S82）。本実施例ではユーザ識別子はユーザ名として説明する。次に、GW11の中継機能1110が端末1からの要求に基づき、TCP通信管理テーブル1121のシーケンスNO.（終了）欄279とシーケンスNO.（開始）欄278にそれぞれ登録される値の差分を通信量として算出する。（S83）。一連の通信ログ1120として、TCP通信管理テーブル1121の情報を管理サーバ10へ送信する（S84）。そして処理を終了する。以上の処理により、HTTPレイヤでの通信量に加え、TCPレイヤでの通信量を算出することができる。これにより、コネクションを確立する際の通信量についても、ユーザがコンテンツをダウンロードする際の通信量と、ただの情報の閲覧の場合の通信量を区別することが可能になり、ユーザの通信費の負担を減らすことが可能になる。

図22は、管理サーバ10の管理機能111が通信ログ管理テーブル124の内容に基づいて端末1と該当サービス事業者サーバ16間の通信を特定し、その通信費を算出する処理の流れの一例を示したフローチャートである。図5に示したフローと比べ、S18〜S19が無く、S20以外のステップは図5で説明した内容と同様である。S20では、S17で商品購入と判定された通信ログ管理テーブル124のレコードの通信量欄267に登録される値を利用してOCS12へ通信量増分の指示を行う。この通信ログ管理テーブル124のレコードの通信量欄267に登録される値は、TCPレイヤで計測したデータサイズであるため、アプリケーションレイヤで解析して得られる値とは異なる。これはすなわち、TCPプロトコルのSYN、ACK、FIN等のデータが含まれているが故である。

実施例2では、端末1からサービス事業者サーバ16へ宛ての通信を通信事業者のGW11が中継する際に、TCPレイヤとアプリケーションレイヤのそれぞれの通信ログ1120を融合させて、特定の通信にかかる通信費をTCPレイヤの通信確立から終了に至るまでを含めて算出する方法を説明した。

実施例3では、実施例2で示したようにTCPレイヤの通信を含め、実施例1で示した特定の通信から、その通信に関連する通信の範囲を決定し、通信費を算出した後にサービス事業者へ請求する方法について説明する。

実施例3で示す多くの流れは、実施例1及び実施例2で示したものと同様である。実施例3では相違点を中心に説明する。

図23は、実施例3で用いる管理サーバ10に具備される通信ログ管理テーブル124の一例を示したものである。通信ログ管理テーブル124の階層関係欄269以外は、図15に示した内容と同様であるため、説明は省く。階層関係欄269は、それぞれのユーザが同じサービス事業者サーバ16で、当該行のURI欄264に登録されるURIへユーザがアクセスした順序を基に階層関係を登録する。例えば、図15の二行目の階層関係欄269には「親_#1」と記載されている。これは「yyy.yyy.yyy/2/2.html」で示されるURIが一行目のURI「yyy.yyy.yyy」と関係があり、一行目のアクセスの後に二行目がアクセスされたことを示している。このように順序で階層関係を認識してもよいし、URIで示されるHTMLデータ内のハイパーリンク情報を基にして階層関係を認識する方法も考えられる。

なお、図23に示す通信ログ管理テーブル124の通信量欄267に登録される値は、実施例2で示したTCPレイヤの通信を含む通信量である。

実施例1及び実施例2で示したように、GW11が取得、登録した通信ログ管理テーブル124の情報を管理サーバ10へ送信し、管理サーバ10の管理機能111が通信ログ管理テーブル124の内容に基づいて商品購入した通信を特定し、その通信範囲を決め、その範囲内の通信費を算出する処理を実行するが、それは図5に示したフローチャートと同様である。

ただし、通信ログ管理テーブル124の階層関係欄269が新たに追加されている。図5のS18において、この階層関係欄269の情報を利用して通信範囲の確定処理を実行する。ここでは、通信ログ管理テーブル124の階層関係欄269に登録される階層関係に従って、管理者が指定する数だけ階層の上位まで遡って通信範囲と捉える。

例えば、図23のNO.欄261の4と登録されている行（四行目）を商品購入判定されたと捉えた場合、管理者が2階層上位まで遡って通信範囲と指定しているならば、1つの上位階層に当たるものが、図23のNO.欄261の3と登録されている行（三行目）であり、さらに1つの上位階層（合計二階層目）に当たるものが、図23のNO.欄261の1と登録されている行（一行目）に該当する。四行目を起点として、三行目及び一行目までを商品購入に関係する通信範囲と捉える。このように通信範囲と捉えた通信の通信量（図23の通信量欄267）の合計値を用いて通信費を算出することができる。

上記開示は、代表的実施形態に関して記述されているが、当業者は、開示される主題の趣旨や範囲を逸脱することなく、形式及び細部において、様々な変更や修正が可能であることを理解するであろう。

１０：管理サーバ、１１：GW、１２４：通信ログ管理テーブル、１１２１：TCP通信管理テーブル、１１１２：下位レイヤ情報取得機能、１１１：管理機能

Claims (15)

1. ユーザがサービスを提供するサービス事業者のサーバからサービスを利用する際の通信費算出方法であって、
   前記ユーザが使用した通信の通信量の情報、前記サービス事業者のサーバにおける前記ユーザのアクセス先を識別するURI情報、前記ユーザがサービスを利用したか否かを示す情報を対応づけて通信ログとし、
   前記対応づけた通信ログを格納した通信ログ管理テーブルを用いて、前記ユーザがサービスを利用したことを示す情報と対応づけられた通信ログを特定し、前記特定した通信ログのURIに対して上位のURIを有する通信ログを前記通信ログ管理テーブルから抽出し、前記特定および前記抽出した通信ログの通信量の合計を算出し、前記算出した通信量に対応する通信費を前記サービス事業者に請求する
   ことを特徴とする通信費算出方法。
2. 請求項１に記載の通信費算出方法であって、
   前記サービスを利用したか否かを示す情報は、前記ユーザが前記サービス事業者からコンテンツをダウンロードしたか否かを示す情報である
   ことを特徴とする通信費算出方法。
3. 請求項１に記載の通信費算出方法であって、
   前記通信量はHTTPレイヤにおける通信量とTCPレイヤにおける通信量を合わせた通信量である
   ことを特徴とする通信費算出方法。
4. 請求項１に記載の通信費算出方法であって、
   前記サービス事業者のサーバにおける前記ユーザのアクセス先を識別するURI情報は、前記サービス事業者のサーバの識別子と、ファイルのリンクの階層位置の情報を含む
   ことを特徴とする通信費算出方法。
5. 請求項４に記載の通信費算出方法であって、
   前記特定した通信ログのURIに対して上位のURIを有する通信ログの前記通信ログ管理テーブルからの抽出は、設定された階層数のリンクを遡って通信ログを抽出する
   ことを特徴とする通信費算出方法。
6. 請求項２に記載の通信費算出方法であって、
   前記コンテンツのダウンロードを示す情報は、HTTPのPOSTリクエストであって900 successを含むものである
   ことを特徴とする通信費算出方法。
7. ユーザがサービスを提供するサービス事業者のサーバからサービスを利用する際の通信費を管理する管理装置であって、
   前記ユーザが使用した通信の通信量の情報、前記サービス事業者のサーバにおける前記ユーザのアクセス先を識別するURI情報、前記ユーザがサービスを利用したか否かを示す情報を対応づけて通信ログとし、前記通信ログを格納した通信ログ管理テーブルを記憶する記憶部と、
   前記通信ログ管理テーブルを用いて、前記ユーザがサービスを利用したことを示す情報と対応づけられた通信ログを特定し、前記特定した通信ログのURIに対して上位のURIを有する通信ログを前記通信ログ管理テーブルから抽出し、前記特定および前記抽出した通信ログの通信量の合計を算出し、前記算出した通信量に対応する通信費を前記サービス事業者に請求する処理部、を有する
   ことを特徴とする管理装置。
8. 請求項７に記載の管理装置であって、
   前記サービスを利用したか否かを示す情報は、前記ユーザが前記サービス事業者からコンテンツをダウンロードしたか否かを示す情報である
   ことを特徴とする管理装置。
9. 請求項７に記載の管理装置であって、
   前記通信量はHTTPレイヤにおける通信量とTCPレイヤにおける通信量を合わせた通信量である
   ことを特徴とする管理装置。
10. 請求項７に記載の管理装置であって、
    前記サービス事業者のサーバにおける前記ユーザのアクセス先を識別するURI情報は、前記サービス事業者のサーバの識別子と、ファイルのリンクの階層位置の情報を含む
    ことを特徴とする管理装置。
11. 請求項１０に記載の管理装置であって、
    前記特定した通信ログのURIに対して上位のURIを有する通信ログの前記通信ログ管理テーブルからの抽出は、設定された階層数のリンクを遡って通信ログを抽出する
    ことを特徴とする管理装置。
12. 請求項８に記載の管理装置であって、
    前記コンテンツのダウンロードを示す情報は、HTTPのPOSTリクエストであって900 successを含むものである
    ことを特徴とする管理装置。
13. ユーザにサービスを提供するネットワークシステムであって、
    前記ユーザがサービス事業者のサービスを利用する際の通信を中継し、前記ユーザが前記サービスを利用する際の通信量の情報、前記サービス事業者のサーバにおける前記ユーザのアクセス先を識別するURI情報、前記ユーザが前記サービスを利用したか否かを示す情報を対応づけた通信ログを取得する中継装置と、
    前記中継装置から取得した通信ログを通信ログ管理テーブルに格納し、前記通信ログ管理テーブルを用いて、前記ユーザがサービスを利用したことを示す情報と対応づけられた通信ログを特定し、前記特定した通信ログのURIに対して上位のURIを有する通信ログを前記通信ログ管理テーブルから抽出し、前記特定および前記抽出した通信ログの通信量の合計を算出し、前記算出した通信量に対する通信費を前記サービス事業者に請求する管理装置、を有する
    ことを特徴するネットワークシステム。
14. 請求項１３に記載のネットワークシステムであって、
    前記サービスを利用したか否かを示す情報は、前記ユーザが前記サービス事業者からコンテンツをダウンロードしたか否かを示す情報である
    ことを特徴とするネットワークシステム。
15. 請求項１３に記載のネットワークシステムであって、
    前記サービス事業者のサーバにおける前記ユーザのアクセス先を識別するURI情報は、前記サービス事業者のサーバの識別子と、ファイルのリンクの階層位置の情報を含み、
    前記特定した通信ログのURIに対して上位のURIを有する通信ログの前記通信ログ管理テーブルからの抽出は、設定された階層数のリンクを遡って通信ログを抽出する
    ことを特徴とするネットワークシステム。

Images