(57)【要約】【課題】利用状況に適した通信料金を設定可能な技術を提供する。【解決手段】要求部５０は、購入したデータ量の範囲で高速通信を実行可能な端末装置１０が複数接続されるネットワーク内に備えられたパケット計測部２８であって、かつ複数の端末装置１０のそれぞれに対するデータ残量を管理するパケット計測部２８のＡＰＩ３２に対して、複数の端末装置１０のうちの１つに対するデータ残量の確認を要求する。受付部５２は、要求部５０において確認を要求した端末装置１０に対するデータ残量をＡＰＩ３２から受けつける。制御部５４は、要求部５０と受付部５２がデータ残量を確認すべき端末装置１０を変更させる。制御部５４は、データ残量の確認頻度を端末装置１０ごとに変える。【選択図】図１
2016197800.tif 000002
【特許請求の範囲】
【請求項１】
購入したデータ量の範囲で高速通信を実行可能な端末装置が複数接続されるネットワーク内に備えられた管理装置であって、かつ複数の端末装置のそれぞれに対するデータ残量を管理する管理装置のインターフェイスに対して、複数の端末装置のうちの１つに対するデータ残量の確認を要求する要求部と、
前記要求部において確認を要求した端末装置に対するデータ残量を前記インターフェイスから受けつける受付部と、
前記要求部と前記受付部がデータ残量を確認すべき端末装置を変更させる制御部とを備え、
前記制御部は、データ残量の確認頻度を端末装置ごとに変えることを特徴とする制御装置。
【請求項２】
前記制御部は、前記受付部において受けつけたデータ残量に応じて、前記要求部と前記受付部がデータ残量を確認すべき端末装置を決定することを特徴とする請求項１に記載の制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信技術に関し、特に通信システムのネットワークに接続される制御装置に関する。
【背景技術】
【０００２】
無線ネットワークからサーバに接続して通信する環境において、転送するパケット量によって料金が定められている。パケット量は、Ｗｅｂサイト等のネットワークで入手する情報の表現に依存し、かつ情報を入手する際に定かではない。そのため、パケット量による従量課金は、利用者にとって分かりにくい（例えば、特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−５３９７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
データ通信における通信料金を分かりやすくするために、例えば、月間定額制でサービスが提供される。月間定額制を適用した場合、非常に多くのデータ量によって無線ネットワークを占拠する利用者が出現する危険性がある。そのため、データ量に対する上限値を設け、上限値の範囲内で高速なデータ通信を提供し、上限値を超えると低速なデータ通信を提供するようにされている。なお、上限値は、追加の料金を支払うことによって増加可能である。しかしながら、月間定額制では、利用者がほとんどサービスを利用していない月についても、通信料金を支払う必要があり、利用者にとって無駄が多くなる。
【０００５】
本発明はこうした状況に鑑みてなされたものであり、その目的は、利用状況に適した通信料金を設定可能な技術を提供することにある。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のある態様の制御装置は、購入したデータ量の範囲で高速通信を実行可能な端末装置が複数接続されるネットワーク内に備えられた管理装置であって、かつ複数の端末装置のそれぞれに対するデータ残量を管理する管理装置のインターフェイスに対して、複数の端末装置のうちの１つに対するデータ残量の確認を要求する要求部と、要求部において確認を要求した端末装置に対するデータ残量をインターフェイスから受けつける受付部と、要求部と受付部がデータ残量を確認すべき端末装置を変更させる制御部とを備える。制御部は、データ残量の確認頻度を端末装置ごとに変える。
【０００７】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００８】
本発明によれば、利用状況に適した通信料金を設定できる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施例に係る通信システムの構成を示す図である。
【図２】図２（ａ）−（ｂ）は、図１のデータ量管理部における処理の概要を示す図である。
【図３】図３（ａ）−（ｂ）は、図１の課金処理部における処理の概要を示す図である。
【図４】図１の制御部に記憶されるテーブルのデータ構造を示す図である。
【図５】図１の制御装置による制御手順を示すフローチャートである。
【発明を実施するための形態】
【００１０】
本発明を具体的に説明する前に、概要を述べる。本発明の実施例は、移動体通信システムにおいてデータ通信を実行する端末装置に対して、通信料金を設定する制御装置に関する。移動体通信システムは、移動体通信事業者（ＭＮＯ：Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ  Ｏｐｅｒａｔｏｒ）に所有される。また、移動体通信システムの回線は、仮想移動体通信サービス提供者（ＭＶＮＥ：Ｍｏｂｉｌｅ  Ｖｉｒｔｕａｌ  Ｎｅｔｗｏｒｋ  Ｅｎａｂｌｅｒ）によって借り受けられる。ＭＶＮＥの通信機器（以下、「ＭＶＮＥプラットフォーム」という）は、移動体通信システムに接続され、ＭＶＮＥプラットフォームにおいて、例えば、通信に使用されたパケット信号の量、つまりデータ量が測定される。
【００１１】
測定されたデータ量は、データ通信の速度を制御するために使用される。前述のごとく、ＭＶＮＥでは、データ量に対する上限値が設定されており、データ量が上限値の範囲内であれば高速なデータ通信が提供されるが、データ量が上限値を超えると低速なデータ通信が提供される。この上限値は、基本となる通信料金（以下、「基本通信料金」という）を支払うことによって設定される。さらに、追加となる通信料金（以下、「追加通信料金」という）を支払うと、上限値が増加していく。前述のごとく、データ量が上限値に達しない月もあり、そのような月でもユーザは、上限値を考慮して設定された通信料金を支払う必要があり、無駄が多くなる。
【００１２】
これに対応するために、本実施例にかかる制御装置は、仮想移動体通信事業者（ＭＶＮＯ：Ｍｏｂｉｌｅ  Ｖｉｒｔｕａｌ  Ｎｅｔｗｏｒｋ  Ｏｐｅｒａｔｏｒ）に所有されるとともに、ＭＶＮＥプラットフォームに接続される。この制御装置は、基本通信料金と追加通信料金との組合せで実現されるＭＶＮＥの料金体系に従いながらも、従量制課金を実行する。具体的に説明すると、基本通信料金によって付与される上限値と、追加通信料金によって付与される上限値の増加幅が小さくなるように設定されるとともに、基本通信料金と追加通信料金も低くなるように設定される。そのため、制御装置は、追加通信料金の支払いによる上限値の増加を細かく繰り返すことによって、従量制課金に近づける。
【００１３】
追加通信料金の支払いによる上限値の増加は、ユーザに対するデータ量の残り（以下、「データ残量」という）に基づいてなされるべきであり、例えば、データ残量が小さくなった場合に上限値が増加されることが好ましい。各ユーザに対するデータ残量は、ＭＶＮＥプラットフォームに記憶されており、制御装置は、ＭＶＮＥプラットフォームにアクセスしてデータ残量を取得する。ここで、上限値および上限値の増加幅が小さくなると、データ残量を取得すべき頻度が増加し、ＭＶＮＥプラットフォームへのアクセス回数が増加する。ＭＶＮＥプラットフォームへのアクセス回数が増加すると、ＭＶＮＥプラットフォームの処理負荷が大きくなる。ＭＶＮＥプラットフォームの処理負荷が大きくなると、許容される時間内でのデータ残量の取得が不可能になる。
【００１４】
このようなアクセス回数の増加を抑制するために、制御装置は、各ユーザのデータ残量をもとに、ユーザごとにランキングを付与する。また、制御装置は、ランキングの高いユーザのデータ残量を取得するためのアクセスを優先的に実行する。そのため、ランキングの低いユーザのデータ残量を取得するためのアクセス回数が少なくなり、全体的なアクセス回数の増加が抑制される。
【００１５】
図１は、本発明の実施例に係る通信システム１００の構成を示す。通信システム１００は、端末装置１０、基地局装置１２、コアネットワーク１４、Ｓ−ＧＷ１６、ＭＶＮＥプラットフォーム１８、インターネット２０、制御装置４０を含む。端末装置１０は、ＳＩＭカード３４を含み、ＭＶＮＥプラットフォーム１８は、Ｐ−ＧＷ２２、認証処理部２４、速度制御部２６、パケット計測部２８、ＮＡＴ３０、ＡＰＩ３２を含む。制御装置４０は、要求部５０、受付部５２、制御部５４、データ量管理部５６、課金処理部５８、ＵＩ部６０を含む。ここで、基地局装置１２、コアネットワーク１４、Ｓ−ＧＷ１６は、ＭＮＯに所有され、ＭＶＮＥプラットフォーム１８は、ＭＶＮＥに所有され、制御装置４０は、ＭＶＮＯに所有される。また、通信システム１００には、１つの端末装置１０が示されるが、複数の端末装置１０が含まれてもよい。
【００１６】
端末装置１０は、ユーザによって使用される無線装置であり、移動体通信システムに対応した携帯電話、スマートホン、タブレット等である。端末装置１０は、データ通信、音声通信を実行可能であるが、ここでは、例えば、データ通信を実行するものとする。特に、端末装置１０は、購入したデータ量の上限値の範囲で高速通信を実行可能である。端末装置１０には、ＳＩＭカード（Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ  Ｍｏｄｕｌｅ）３４が装着されている。ＳＩＭカード３４には、ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）と呼ばれる固有の番号が付与されている。また、ＳＩＭカード３４あるいはＩＭＳＩは、端末装置１０ごとに異なっているので、ＳＩＭカード３４あるいはＩＭＳＩは、ユーザを識別するための識別情報として使用される。なお、ＳＩＭカード３４は、ＭＶＮＯによって提供される。
【００１７】
基地局装置１２は、一端側で無線通信を実行し、他端側で有線通信を実行する。基地局装置１２は、移動体通信システムに対応しており、一端側において端末装置１０と通信する。コアネットワーク１４は、一端側において基地局装置１２に接続され、他端側においてＳ−ＧＷ１６に接続される。コアネットワーク１４には公知の技術が使用されればよいので、ここでは説明を省略する。Ｓ−ＧＷ１６は、ＭＮＯ側のゲートウエイである。一方、Ｐ−ＧＷ２２は、ＭＶＮＥ側のゲートウエイであり、Ｓ−ＧＷ１６にも接続される。
【００１８】
ＭＶＮＥプラットフォーム１８内において、Ｐ−ＧＷ２２、認証処理部２４、速度制御部２６、パケット計測部２８、ＮＡＴ３０が順に接続される。認証処理部２４は、端末装置１０、特に端末装置１０に装着されたＳＩＭカード３４に対する認証処理を実行する。これは、ユーザに対する認証処理を実行することに相当する。認証処理については公知の技術が使用されればよいので、ここでは説明を省略する。
【００１９】
速度制御部２６は、各端末装置１０に対する通信速度を制御する。説明を明瞭にするために、ここでは、２種類の通信速度が規定されており、それらを第１通信速度と第２通信速度と示す。また、第１通信速度は、第２通信速度よりも高速であるとする。例えば、第１通信速度は、７５Ｍｂｐｓであり、第２通信速度は、１５０ｋｂｐｓである。なお、これらの通信速度は、端末装置１０と基地局装置１２との間の無線通信によって変化する。速度制御部２６における通信速度の制御は、パケット計測部２８と関連してなされるので、パケット計測部２８の処理を先に説明する。
【００２０】
パケット計測部２８は、データ通信に使用されたパケット信号の量、つまり前述のデータ量を端末装置１０ごとに測定する。また、パケット計測部２８は、各端末装置１０に対して設定された上限値を認識しており、上限値からデータ量を減算することによって、各端末装置１０に対するデータ残量を導出する。ここで、データ残量は「０」になるまで更新され続けられる。なお、上限値が増加されると、パケット計測部２８は、データ残量も増加させる。パケット計測部２８は、各端末装置１０に対するデータ残量を速度制御部２６に出力する。速度制御部２６は、パケット計測部２８から受けつけたデータ残量が「０」でない端末装置１０に対して、第１通信速度を使用させ、データ残量が「０」である端末装置１０に対して、第２通信速度を使用させる。
【００２１】
ＮＡＴ３０は、ネットワークのアドレス変換を実行する。インターネット２０は、端末装置１０の通信対象となるネットワークである。これらについては、公知の技術が使用されればよいので、ここでは説明を省略する。ＡＰＩ３２は、ＭＶＮＥプラットフォーム１８と制御装置４０におけるソフトウエアコンポーネントが互いにやりとりするために使用するインターフェイスである。複数のＡＰＩ３２が備えられていてもよい。ここで、ＭＶＮＥプラットフォーム１８は、ひとつの装置として構成されてもよく、複数の装置の組合せによって構成されてもよい。その際、パケット計測部２８が含まれた装置は、管理装置とも呼ばれる。
【００２２】
要求部５０は、複数の端末装置１０のそれぞれに対するデータ残量を管理するパケット計測部２８のＡＰＩ３２に対して、複数の端末装置１０のうちの１つに対するデータ残量の確認を要求する。そのために、要求部５０は、確認要求をＡＰＩ３２に出力する。確認要求は、ユーザを識別するための識別情報であるＳＩＭカード３４のＩＤあるいはＩＭＳＩを含む。
【００２３】
ＡＰＩ３２が確認要求を入力し、パケット計測部２８は、確認要求中の識別情報に対応したデータ残量を取得する。ＡＰＩ３２は、識別情報とデータ残量とが含まれた確認応答を受付部５２に出力する。受付部５２は、ＡＰＩ３２から確認応答を入力する。受付部５２は、確認応答に含まれた識別情報とデータ残量を抽出することによって、要求部５０において確認を要求した端末装置１０に対するデータ残量を取得する。これは、ユーザごとのデータ残量に相当する。受付部５２は、識別情報とデータ残量をデータ量管理部５６に出力する。要求部５０と受付部５２によるデータ残量の確認処理は、制御部５４からの指示に応じて、端末装置１０を変更しながら実行される。その結果、受付部５２は、複数の端末装置１０のそれぞれに対する識別情報とデータ残量をデータ量管理部５６に出力する。
【００２４】
ＵＩ部６０は、ユーザからの指示を受け、ユーザに対して情報を提示するためのインターフェイスである。ＵＩ部６０は、ウエブブラウザによって構成されてもよく、キーボードとモニタの組合せによって構成されてもよい。ＵＩ部６０においてユーザから受けつける指示の１つは、データ残量の計測期間の開始時点、例えば、月初において設定すべき上限値（以下、「初期上限値」ともいう）に関する情報である。これは、前述の基本通信料金に対して設定される上限値に相当する。ＵＩ部６０は、受けつけた初期上限値をデータ量管理部５６に出力する。
【００２５】
データ量管理部５６は、ＵＩ部６０から受けつけた初期上限値を設定するとともに、要求部５０、ＡＰＩ３２を介してパケット計測部２８に初期上限値を出力する。パケット計測部２８は、受けつけた初期上限値をもとにデータ残量を管理する。このような処理は、端末装置１０ごとになされる。また、データ量管理部５６は、受付部５２から端末装置１０ごとのデータ残量を受けつける。データ量管理部５６は、データ残量が「０」になった端末装置１０のユーザに対して、データ残量が「０」になったことを示すための情報、例えば、「なくなりました」のメッセージを、ＵＩ部６０を介してユーザに提示する。また、データ量管理部５６は、データ残量が「０」になりそう、例えば、データ残量が上限値の１５％よりも少なくなった端末装置１０のユーザに対して、データ残量が「０」になりそうなことを示すための情報を、ＵＩ部６０を介してユーザに提示する。データ残量が「０」になりそうなことを示すための情報は、例えば、「もうすぐなくなります」のメッセージである。
【００２６】
ＵＩ部６０は、ユーザからの指示として、初期上限値あるいは上限値に追加すべきデータ量（以下、「追加量」ともいう）に関する指示も受けつける。ＵＩ部６０は、受けつけた追加量をデータ量管理部５６に出力する。データ量管理部５６は、ＵＩ部６０から受けつけた追加量を初期上限値あるいは上限値に加算することによって、上限値を更新する。また、データ量管理部５６は、ＡＰＩ３２を介してパケット計測部２８に追加量を出力する。パケット計測部２８は、受けつけた追加量を初期上限値あるいは上限値に加算して、上限値を更新するとともに、更新した上限値（以下、これもまた「上限値」という）をもとにデータ残量を管理する。この処理も端末装置１０ごとになされる。なお、追加量による上限値の更新は、繰り返し実行可能である。
【００２７】
図２（ａ）−（ｂ）は、データ量管理部５６における処理の概要を示す。図２（ａ）は、「一括方式」による処理を示す。タイミングＴ０において、初期上限値Ｄ０が「５００ＭＢ」に設定される。一般的に、初期上限値は、２ＧＢから１０ＧＢに設定されることが多いが、ここでは、データの使用量の少ないユーザに対する無駄を小さくするために、初期上限値Ｄ０が小さくなるように設定される。なお、初期上限値Ｄ０は、ＵＩ部６０を介して自由に設定可能である。タイミングＴ０において、追加量「１ＧＢ」のリチャージがなされることによって、上限値Ｄ１が「１．５ＧＢ」に更新される。
【００２８】
図２（ａ）において、データ量８０の時間変化も示される。データ量８０は、時間の経過とともに増加していく。タイミングＴ０からタイミングＴ１の間において、上限値Ｄ１とデータ量８０との差異がデータ残量に相当する。タイミングＴ１において、追加量「０．８ＧＢ」のリチャージがなされることによって、上限値Ｄ２が「２．３ＧＢ」に更新される。そのため、タイミングＴ１以降において、上限値Ｄ２とデータ量８０との差異がデータ残量に相当する。
【００２９】
図２（ｂ）は、「逐次方式」による処理を示す。図２（ａ）と同様に、タイミングＴ０において、初期上限値Ｄ０が「５００ＭＢ」に設定される。また、タイミングＴ１’、Ｔ２’、Ｔ３’、Ｔ４’、Ｔ５’、Ｔ６’において、追加量「２００ＭＢ」のリチャージが逐次なされる。その結果、タイミングＴ１’、Ｔ２’、Ｔ３’、Ｔ４’、Ｔ５’、Ｔ６’において、上限値Ｄ１’、Ｄ２’、Ｄ３’、Ｄ４’、Ｄ５’、Ｄ６’が、「０．７ＧＢ」、「０．９ＧＢ」、「１．１ＧＢ」、「１．３ＧＢ」、「１．５ＧＢ」、「１．７ＧＢ」に更新される。図２（ｂ）は、図２（ａ）と比較して、追加量が小さいので、更新されていく上限値の時間変化が、データ量８０の時間変化に似ている。一方、図２（ｂ）は、図２（ａ）と比較して、追加量が小さいので、データ残量が少なくなっている。図１に戻る。
【００３０】
図２（ａ）−（ｂ）のようなデータ量管理部５６の処理に応じて、パケット計測部２８でもデータ残量が変化する。例えば、１つの端末装置１０に対するデータ残量が「０ＭＢ」である場合に、追加量「２００ＭＢ」のリチャージがなされると、データ残量は「２００ＭＢ」になる。また、１つの端末装置１０に対するデータ残量が「５０ＭＢ」である場合に、追加量「２００ＭＢ」のリチャージがなされると、データ残量は「２５０ＭＢ」になる。
【００３１】
課金処理部５８は、データ量管理部５６から、初期上限値および増加量に関する情報を入力する。これは、最終的な上限値に関する情報を入力することに相当する。これらの情報は、端末装置１０ごとに入力される。課金処理部５８は、データ残量の計測期間の終了時点、例えば、月末において、入力した情報をもとに通信料金を計算する。
【００３２】
図３（ａ）−（ｂ）は、課金処理部５８における処理の概要を示す。図３（ａ）は、初期上限値および増加量をもとにしたデータ量に対する料金の関係を示す。初期上限値に対応するように最低金額が設定される。増加量に応じて上限値が更新され続けて増加すると、最終的な上限値に対応するように最高金額が設定される。図３（ｂ）は、図３（ａ）と同様に、上限値が更新されるが、上限値１まで増加された後に更新が停止される場合である。その状況において、第２通信速度が使用される。さらに、増加量によって再び更新がなされ、上限値２まで上限値が増加される。ここで、上限値１に対応するように最高金額が設定され、上限値２に対応するように追加後最高金額が設定される。図１に戻る。
【００３３】
制御部５４は、要求部５０と受付部５２によるデータ残量の確認処理を制御する。制御部５４は、全端末装置１０のそれぞれをスキャンするように、端末装置１０を切りかえながら確認することを要求部５０と受付部５２に指示する。つまり、制御部５４は、要求部５０と受付部５２がデータ残量を確認すべき端末装置１０を変更させる。これは、ポーリングによる「全ＳＩＭスキャン」に相当し、１日１回、例えば、深夜時間帯（午前４時等）に実行される。
【００３４】
上限値が大きい場合や増加量が大きい場合、前回確認したときにデータ残量が「０」になりそうなことを通知していなくても、１日１回のスキャンで次に確認するまでの間にデータ残量が「０」になる可能性は高くない。一方、従量制課金に近づけるために上限値を小さく、かつ増加量を小さくした場合、１日１回のスキャンで次に確認するまでの間にデータ残量が「０」になる可能性が高くなる。ユーザの利便性を考慮すると、データ残量が「０」になるまでに、データ残量が「０」になりそうなことを通知した方が好ましい。
【００３５】
このような状況を考慮して、制御部５４は、１日１回の定期的な全スキャンに加えて、追加のスキャンを実行する。追加のスキャンが、全スキャンと同様に全端末装置１０を対象にしてなされると、制御装置４０、ＡＰＩ３２、パケット計測部２８における処理負荷が大きくなる。特に、一定時間内で処理できるＡＰＩ３２の数には制限があるので、データ残量を取得すべき端末装置１０の数が増加するにつれ、データ残量取得にかかる時間が長くなり、許容できる時間内での取得が不可能になる。
【００３６】
確認処理による負荷を小さくするために、制御部５４は、データ残量の確認頻度を端末装置１０ごとに変える。具体的に説明すると、１日あたりの確認処理の回数を端末装置１０ごとに変える。例えば、制御部５４は、受付部５２からユーザＩＤおよびデータ残量を受けつける。ユーザＩＤは、前述の識別情報に相当する。制御部５４は、複数のユーザＩＤのそれぞれに対するデータ残量を比較して、データ残量が少ないほど高くなるようなランキングを各ユーザＩＤに付与する。図４は、制御部５４に記憶されるテーブルのデータ構造を示す。図示のごとく、ユーザＩＤ欄２００、残量欄２０２、ランキング欄２０４が含まれる。ユーザＩＤ欄２００、残量欄２０２には、受付部５２から受けつけたユーザＩＤ、データ残量が示される。ランキング欄２０４には、制御部５４において付与したランキングが示される。ここでは、ランキング「１」が最も高いランキングに相当する。なお、２つ以上のユーザＩＤに対して、同一のランキングが付与されてもよい。図１に戻る。
【００３７】
制御部５４は、高いランキングのユーザＩＤに対応した端末装置１０を優先的に選択し、選択した端末装置１０に対する確認処理を要求部５０と受付部５２に指示する。このようにすることによって、ランキングの高いユーザＩＤに対応した端末装置１０ほど、スキャンの回数が増加するので、データ残量が「０」になりそうなことを通知できない可能性が低減される。一方、ランキングの低いユーザＩＤに対応した端末装置１０ほど、スキャンの回数が減少するので、処理負荷の増加が抑制される。追加のスキャンは、すべての端末装置１０を対象にしていないので、部分スキャンとも呼ばれる。このように、制御部５４は、受付部５２において受けつけたデータ残量に応じて、要求部５０と受付部５２がデータ残量を確認すべき端末装置１０を決定する。
【００３８】
この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされた通信機能のあるプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００３９】
以上の構成による通信システム１００の動作を説明する。図５は、制御装置４０による制御手順を示すフローチャートである。受付部５２は、データ残量を収集する（Ｓ１０）。制御部５４は、ランキングを更新する（Ｓ１２）。通知が必要であれば（Ｓ１４のＹ）、データ量管理部５６は、通知を実行し、追加購入があれば（Ｓ１６のＹ）、データ残量を増加させる（Ｓ１８）。追加購入がなければ（Ｓ１６のＮ）、ステップ１８をスキップする。一方、通知が必要でなければ（Ｓ１４のＮ）、ステップ１６、ステップ１８をスキップする。
【００４０】
本発明の実施例によれば、データ残量の確認頻度を端末装置ごとに変えるので、確認頻度の低い端末装置が存在することによって、確認回数の増加を抑制できる。また、データ残量の確認頻度を端末装置ごとに変えるので、確認頻度の高い端末装置が存在することによって、正確なデータ残量を把握できる。また、データ残量の確認頻度を高くするので、上限値および増加量を低くしても、確認前にデータ残量がゼロになってしまう状態の発生を抑制できる。また、上限値および増加量が低くなるので、従量制課金に近い通信料金を実現できる。また、従量制課金に近い通信料金が実現されるので、利用状況に適した通信料金を設定できる。また、データ残量に応じて、データ残量を確認すべき端末装置を決定するので、データ残量に応じて確認頻度を決定できる。また、データ残量に応じて確認頻度が決定されるので、データ残量の低い端末装置に対してデータ残量を細かく確認できる。
【００４１】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００４２】
本実施例において、データ残量がゼロに近づいた場合等に、ユーザからの指示によって上限値が更新されている。しかしながらこれに限らず例えば、データ残量がしきい値よりも少なくなった場合に、データ量管理部５６は、データ残量を自動で更新してもよい。さらに、予め定められた値まで上限値を更新し、予め定められた値に上限値が達した場合に、ユーザに上限値を更新するかを問い合わせてもよい。本変形例によれば、ユーザの利便性を向上できる。
【符号の説明】
【００４３】
１０  端末装置、  １２  基地局装置、  １４  コアネットワーク、  １６  Ｓ−ＧＷ、  １８  ＭＶＮＥプラットフォーム、  ２０  インターネット、  ２２  Ｐ−ＧＷ、  ２４  認証処理部、  ２６  速度制御部、  ２８  パケット計測部、  ３０  ＮＡＴ、  ３２  ＡＰＩ、  ３４  ＳＩＭカード、  ４０  制御装置、  ５０  要求部、  ５２  受付部、  ５４  制御部、  ５６  データ量管理部、  ５８  課金処理部、  ６０  ＵＩ部、  １００  通信システム。
【図１】
2016197800.tif 000003
【図２】
2016197800.tif 000004
【図３】
2016197800.tif 000005
【図４】
2016197800.tif 000006
【図５】
2016197800.tif 000007