JP3959242B2 - 分散型アクセス制御システムおよび分散型アクセス制御方法、並びに携帯電子機器端末、ロードバランサ装置 - Google Patents
分散型アクセス制御システムおよび分散型アクセス制御方法、並びに携帯電子機器端末、ロードバランサ装置 Download PDFInfo
- Publication number
- JP3959242B2 JP3959242B2 JP2001076112A JP2001076112A JP3959242B2 JP 3959242 B2 JP3959242 B2 JP 3959242B2 JP 2001076112 A JP2001076112 A JP 2001076112A JP 2001076112 A JP2001076112 A JP 2001076112A JP 3959242 B2 JP3959242 B2 JP 3959242B2
- Authority
- JP
- Japan
- Prior art keywords
- access
- electronic device
- portable electronic
- network
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、携帯電話機、ＰＨＳ、ＰＤＡなどの移動体の通信システムにおけるトラフィック量の増加に対する負荷分散を行うことが可能なシステムおよび方法に関する。
【０００２】
【従来の技術】
近年、移動体、例えば、携帯電話機が著しく普及し、今や数千万件の加入者数に達している。このような携帯電話機のユーザは、所望の場所から所望の者と電話通信を行うことができることに加えて、移動体通信事業者などが管理・運営するアプリケーションサーバから、インターネットなどのコンピュータ通信網、移動体通信網を介して様々なサービスの提供を受けることができる。例えば、携帯電話機間のメール交換、携帯電話機への各種情報の提供、さらには、携帯電話機への音楽、映像、ゲームコンテンツの配信など、様々なサービスが存在する。
【０００３】
図１４に、従来の移動体通信システムの構成例とともに、携帯電話機１０２がＡＰＮ１０４ａからサービスの提供を受ける際の流れ（▲１▼〜▲５▼）を示す。図１４において、インターネット１には、各種サーバのＵＲＬ（Uniform Resource Locator)をＩＰ（Internet Protocol）アドレスを変換して提供するＤＮＳ（Domain name Server）１０３、携帯電話機１０２に対し各種サービスを提供するＡＰＮ（Application Node：アプリケーションノード群）１０４ａ乃至１０４ｃ、携帯電話機１０２のユーザに対して、サービス提供による課金を行うＢＰＳ（Billing Provisioning System）１０５が接続されている。
【０００４】
ここで、ＡＰＮ１０４ａ乃至１０４ｃは、複数のアプリケーションサーバ（ＡＰＳ：Application Server）から構成される単一アプリケーションであり、それぞれ、固有のサービスを提供（ＡＰＮ１０４ａはサービスＸを、ＡＰＮ１０４ｂはサービスＹを、ＡＰＮ１０４ｃはサービスＺを、それぞれ提供）する。ＡＰＮに複数のＡＰＳを設けているのは、多くの携帯電話機からのサービスの要求に対応するためである。また、ＡＰＮ毎に共通の携帯電話加入者ＤＢ（データベース）を備えている。
【０００５】
また、ＢＰＳ１０５にも、ＡＰＮ１０４ａ乃至１０４ｃのそれぞれが設ける加入者ＤＢと同様のＤＢを設けており、移動体通信事業者の店舗や代理店などで、携帯電話利用契約を行った加入者の情報（例えば、携帯電話機の電話番号（ＭＳＮ）、加入者の住所、氏名、上記サービス利用の有無などの情報）は、通常、ＢＰＳ１０５の加入者ＤＢに最初に登録される。そして、その後、その加入者情報は、ＢＰＳ１０５より、インターネット１、公衆回線、専用回線などを介して各ＡＰＮの加入者ＤＢに書き込まれる。
【０００６】
また、携帯電話利用契約を行った加入者の携帯電話機１０２の内部メモリにも、必要な情報が記憶される。例えば、利用契約を行ったサービスに対応するＵＲＬが記憶される。
【０００７】
以上の構成において、携帯電話機１０２のユーザが、例えば、ＡＰＮ１０４ａからサービスＸの提供を受ける場合、携帯電話機１０２の内部メモリに記憶されたサービスＸのＵＲＬを表示部に表示させ、それを、操作ボタンにより選択し決定（ＡＰＮ１０４ａのＵＲＬを指定）すると、ＤＮＳ１０３にてＵＲＬがＩＰアドレスに変換された後、携帯電話機１０２は、かかるＩＰアドレスに基づき、ＡＰＮ１０４ａにアクセスし、サービスの要求（▲１▼）を行う。
【０００８】
ＡＰＮ１０４ａは、これに応じ、加入者情報ＤＢを参照して、アクセスしてきた携帯電話機１０２のユーザの認証（▲２▼）、即ち、加入者情報ＤＢに、そのユーザがサービスＸの提供を受ける者として登録され、かつ、ブラックリスト（料金未払い等の者のリスト）にない場合に、その携帯電話機１０２にサービスの提供（▲３▼）を行う。
【０００９】
なお、かかるサービス提供（▲３▼）の前に、ＡＰＮ１０４ａから携帯電話機１０２に対し認証結果が良好である旨の通知がなされる。
【００１０】
かかるサービスの提供により、ＡＰＮ１０４ａには、携帯電話機１０２のユーザに対する課金のための記録としてのＣＤＲ（Call Detailed Record：何月何日何時何分に何のサービスをどの携帯電話機のユーザに提供したかを示す記録）が発生し、図示しない所定のＤＢに蓄積される。
【００１１】
そして、ＢＰＳ１０５により定期的に行なわれるＣＤＲの収集により、かかるＣＤＲが収集され（▲４▼）、ＢＰＳ１０５において、上記サービスＸを利用したユーザに対する課金処理が行なわれることとなる（▲５▼）。
【００１２】
以上のようなサービス提供の流れ（▲１▼〜▲５▼）は、携帯電話機１０２がＡＰＮ１０４ｂ、ＡＰＮ１０４ｃ、その他のアプリケーションサーバからサービス提供を受ける場合にも同様である。
【００１３】
【発明が解決しようとする課題】
ところで、上記のようなサービスは、今後も趣向をこらし、益々発展していくことが予想され、移動体通信の加入者の増大と相まって、かかるサービス利用者が益々増大してゆくことが予想されるが、このことは、同時にトラフィック量の増加を招き、移動体通信システムに対して、多大な負荷を与えることを意味する。
【００１４】
従来の上記移動体通信システムにおいて、このような負荷に対応するためには、例えば、ＡＰＮ内のＡＰＳの数を増大させるなども考えられるが、これにも設備投資の問題でおのずと限界がある。また、同じ時間帯に、多くのアクセスが集中した場合には、ほとんど対応が困難となるという問題が容易に予想される。従って、従来の移動体通信システムでは、今後益々高まるであろうトラフィック量の増加による当該システムへの負荷を効果的に分散させ、低減することは、極めて困難である。
【００１５】
さらに、従来の上記移動体通信システムでは、上記トラフィック量の増加に伴い、以下の問題が、一層顕在化することが予想される。
【００１６】
即ち、上述したように、携帯電話機１０２へのサービスの提供毎にＡＰＮ側で認証を行わなければならないため、ＡＰＮ毎に、加入者ＤＢを設ける必要がある。このことは、多数の箇所に重複した加入者ＤＢを設けることを意味するので、無駄であるばかりか、これらの加入者ＤＢ内のデータに整合がとれているか保証できないという問題がある。例えば、上述したように、新たな加入者情報（解約する場合も同様）は、ＢＰＳ１０５の加入者ＤＢに登録された後、各ＡＰＮの加入者ＤＢに登録されるため、かかる情報を書き込むタイミングにずれが生じ、それぞれの加入者ＤＢで整合がとれていないこともありうる。
【００１７】
また、携帯電話機１０２へのサービスの提供毎にＡＰＮ側で認証を行わなければならないことより、認証のための余分なトラフィックの発生、さらには、認証のためのＡＰＮにおけるＣＰＵの浪費、通信設備の浪費が生じるという問題もある。
【００１８】
さらに、各ＡＰＮの加入者ＤＢへの新たな加入者情報の書き込みや、各ＡＰＮで発生したＣＤＲの収集などのＢＰＳ１０５に対する負担増大という問題もある。
【００１９】
本発明は、以上の問題に鑑みてなされたものであり、時間的に負荷を効率よく分散、軽減させ、加えて、システムの信頼性を高めることが可能な分散型アクセス制御システムおよび分散型アクセス制御方法、並びに携帯電子機器端末、ロードバランサ装置を提供することを目的とする。
【００２６】
【課題を解決するための手段】
請求項１に記載の発明は、ネットワーク上における通信制御を行う分散型アクセス制御システムであって、携帯電子機器端末を利用するユーザのユーザクラスを蓄積するデータベースと、前記携帯電子機器端末から、ネットワーク上で提供されるサービスのリストの要求を、前記ネットワークを介して受け付ける手段と、前記サービスのリストの要求をした前記携帯電子機器端末を利用するユーザのユーザクラスに対応するサービスを、複数のサービスの夫々に対応付けてユーザクラスとアクセス券の発行状況を蓄積するデータベースを備えた装置から提供された情報に基づいて選定して前記サービスのリストを生成し、前記携帯電子機器端末に対して、前記ネットワークを介して提供するサービスリスト提供手段と、前記携帯電子機器端末から、前記サービスのリストのうちからユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行要求を、前記ネットワークを介して受け付ける手段と、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するアクセス券発行手段と、を備えるように構成する。
ここで、ロードバランサ装置は、複数のサーバから構成されるサーバ群のうち何れかのサーバに対して携帯電子機器端末からのアクセスを振り分ける装置である。また、携帯電子機器端末には、携帯電話機、ＰＨＳ、ＰＤＡ等のモバイル型電子機器端末、などが含まれる。
【００２７】
請求項１に記載の発明によれば、分散型アクセス制御システムにおいて、携帯電子機器端末から、ネットワーク上で提供されるサービスのリストの要求が、ネットワークを介して受け付けられる。そして、要求されたサービスのリストであって携帯電子機器端末を利用するユーザのユーザクラスに対応するサービスのリストが、携帯電子機器端末に対して、ネットワークを介して提供される。次に、携帯電子機器端末においてサービスのリストのうちからユーザにより選択されたサービスの提供を担うネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行要求が、ネットワークを介して受け付けられる。そして、発行要求されたアクセス券が、携帯電子機器端末に対して、ネットワークを介して発行される。即ち、携帯電子機器端末のユーザは、当該アクセス券を、分散型アクセス制御システムから取得しなければ、特定のロードバランサ装置にアクセスすることができない。
【００２８】
従って、アクセス券を取得していない携帯電子機器端末からの特定のロードバランサ装置へのアクセスを自律的に禁止し、ロードバランサ装置により振り分けられるサーバへのアクセスを自律的に禁止することができる。また、ユーザは、アクセス券を取得する前に、それに関係するサービスのリストを見ることができるので大変便利である。
【００２９】
請求項２に記載の発明は、請求項１に記載の分散型アクセス制御システムにおいて、前記携帯電子機器端末を利用するユーザのユーザ情報を蓄積するデータベースと、前記データベースに蓄積されたユーザ情報を参照して、前記サービスのリストの要求を行った携帯電子機器端末のユーザ認証を行うユーザ認証手段と、をさらに備え、前記サービスリスト提供手段は、前記ユーザ認証の結果が妥当であった場合に、前記要求されたサービスのリストを、前記携帯電子機器端末に対して、前記ネットワークを介して提供するように構成する。
【００３０】
請求項３に記載の発明は、請求項１に記載の分散型アクセス制御システムにおいて、前記携帯電子機器端末を利用するユーザのユーザ情報を蓄積するデータベースと、前記データベースに蓄積されたユーザ情報を参照して、前記アクセス券の発行要求を行った携帯電子機器端末のユーザ認証を行うユーザ認証手段と、をさらに備え、前記アクセス券発行手段は、前記ユーザ認証の結果が妥当であった場合に、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するように構成する。
【００３１】
請求項２または３に記載の発明によれば、請求項１に記載の発明と同等の効果に加えて、分散型アクセス制御システムで、ユーザ認証を行い、ユーザ認証の結果が妥当であった場合に初めて当該アクセス券を発行するので、アクセス券にてアクセス対象となるロードバランサ装置に接続されるサーバでは、ユーザ認証する必要がなくなり、その結果、各サーバにおいて、ユーザ認証のために必要なユーザ情報が蓄積されたデータベースを削減することができ、ひいては、各サーバ毎の当該データベースの整合性がとれないという問題点を解消することができる。また、各サーバにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【００３２】
請求項４に記載の発明は、請求項１乃至３の何れかに記載の分散型アクセス制御システムにおいて、前記アクセス券の発行状況を蓄積するデータベースと、前記データベースに蓄積されたアクセス券の発行状況に基づいて、前記アクセス券の発行可否を決定するアクセス券発行可否決定手段と、をさらに備え、前記アクセス券発行手段は、前記アクセス券の発行が可能であると決定された場合に、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するように構成する。
【００３３】
請求項４に記載の発明によれば、データベースに蓄積されたアクセス券の発行状況（例えば、発行数量）に基づいて、アクセス券発行可否を制御することができるので、より一層サーバへのアクセスを事前に制御することができる。
【００３８】
請求項５に記載の発明は、請求項１乃至４の何れかに記載の分散型アクセス制御システムにおいて、前記アクセス券には、当該アクセス券によりアクセス可能なロードバランサ装置のアドレス情報が含まれているように構成する。
【００３９】
請求項５に記載の発明によれば、アクセス券にロードバランサ装置のアドレス情報（例えば、ＵＲＬ）を設けることで、携帯電子機器端末はかかるアドレス情報に基づいてアクセスすることができる。
【００４０】
請求項６に記載の発明は、請求項４に記載の分散型アクセス制御システムにおいて、前記アクセス券発行可否決定手段は、前記アクセス券の発行量と前記特定のサーバの負荷容量とを比較して、当該比較結果に応じて前記アクセス券の発行可否を決定するように構成する。
【００４２】
また、サーバの増設時においても、携帯電子機器端末側には影響を与えず、均等にアクセスを振り分けることができ、また、１つのサーバがダウンした時も、他のサーバに均等に振り分けることができ、サーバの信頼性を高めることができる。
【００４３】
請求項７に記載の発明は、ネットワーク上における通信制御を行う分散型アクセス制御システムにおける分散型アクセス制御方法であって、携帯電子機器端末から、ネットワーク上で提供されるサービスのリストの要求を、前記ネットワークを介して受け付ける工程と、前記サービスのリストの要求をした前記携帯電子機器端末を利用するユーザのユーザクラスに対応するサービスを、複数のサービスの夫々に対応付けてユーザクラスとアクセス券の発行状況を蓄積するデータベースを備えた装置から提供された情報に基づいて選定して前記サービスのリストを生成し、前記携帯電子機器端末に対して、前記ネットワークを介して提供する工程と、前記携帯電子機器端末から、前記サービスのリストのうちからユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行要求を、前記ネットワークを介して受け付ける工程と、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するアクセス券発行工程と、を備えるように構成する。
【００４４】
請求項７に記載の発明によれば、アクセスのための認証として発行されたアクセス券を取得していない携帯電子機器端末のユーザからの、ロードバランサ装置へのアクセスを自律的に禁止し、ロードバランサ装置により振り分けられるサービス提供を担うサーバへのアクセスを自律的に禁止することができるので、時間的に負荷を効率よく分散、軽減させることができる。
【００４５】
また、サービス用のサーバの増設時においても、携帯電子機器端末側には影響を与えず、均等にアクセスを振り分けることができ、また、１つのサーバがダウンした時も、他のサーバに均等に振り分けることができ、サーバの信頼性を高めることができる。
【００５２】
請求項８に記載の発明は、請求項７に記載の分散型アクセス制御方法において、前記アクセス券には、前記サーバに対するアクセスを制限する有効度数と、有効期間が含まれているように構成する。
【００５３】
請求項８に記載の発明によれば、アクセス券に有効期間（有効期限）、有効度数を設けることにより、サーバにアクセスできる期間や回数を制限することができるので、より一層サーバへのアクセスを事前に制御することができる。
【００５７】
請求項９に記載の発明は、請求項１に記載の分散型アクセス制御システムに対して、ネットワーク上で提供されるサービスのリストを、前記ネットワークを介して要求する携帯電子機器端末であって、前記要求に対して分散型アクセス制御システムから提供されたサービスのリストを、前記ネットワークを介して受け取る手段と、前記受け取ったサービスのリストのうち、ユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行を、前記ネットワークを介して分散型アクセス制御システムに要求する手段と、前記要求に対して分散型アクセス制御システムから発行されたアクセス券を、前記ネットワークを介して受け取る手段と、前記受け取ったアクセス券に基づいて、前記ネットワーク上のロードバランサ装置にアクセスするアクセス手段と、を備えるように構成する。
【００５８】
請求項９に記載の発明によれば、携帯電子機器端末において、ネットワーク上で提供されるサービスのリストが、ネットワークを介して、分散型アクセス制御システムに要求される。そして、要求に対して分散型アクセス制御システムから提供されたサービスのリストが、ネットワークを介して受け取られる。次に、受け取られたサービスのリストのうち、ユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行が、ネットワークを介して分散型アクセス制御システムに要求される。そして、要求に対して分散型アクセス制御システムから発行されたアクセス券が、ネットワークを介して受け取られる。携帯電子機器端末では、ユーザの指示に応じ、受け取ったアクセス券に基づいて、ネットワーク上の特定のロードバランサ装置にアクセスする。
【００５９】
従って、携帯電子機器端末のユーザは、サービスのリストを受け、その後アクセス券を、分散型アクセス制御システムから取得しなければ、ユーザが所望する特定のロードバランサ装置およびこれに接続されるサーバにアクセスすることができない。従って、アクセス券を取得していない携帯電子機器端末からの特定のサーバへのアクセスを自律的に禁止することができる。
【００６０】
請求項１０に記載の発明は、請求項９に記載の携帯電子機器端末において、前記アクセス券には、前記サーバへのアクセス回数を制限する有効度数が含まれており、前記アクセス手段は、前記有効度数に基づいて前記ロードバランサ装置へのアクセスが可能であるか否かを判断し、可能であると判断した場合には、前記ネットワーク上の前記ロードバランサ装置にアクセスするように構成する。
【００６１】
請求項１０に記載の発明によれば、アクセス券に有効度数を設けることにより、アクセス券を使用してロードバランサ装置にアクセスできる回数を制限できるので、より一層サーバへのアクセスを事前に制御することができる。
【００６２】
請求項１１に記載の発明は、請求項１０に記載の携帯電子機器端末において、前記アクセス手段が、前記ロードバランサ装置にアクセスする毎に、前記有効度数を所定数減らすように構成する。
【００６３】
請求項１１に記載の発明によれば、有効度数を携帯電子機器端末で管理することができる。
【００６４】
請求項１２に記載の発明は、請求項９乃至１１の何れかに記載の携帯電子機器端末において、前記アクセス券には、前記ロードバランサ装置へのアクセス期間を制限する有効期間が含まれており、前記アクセス手段は、前記有効期間に基づいて前記ロードバランサ装置へのアクセスが可能であるか否かを判断し、可能であると判断した場合には、前記ネットワーク上の前記ロードバランサ装置にアクセスするように構成する。
【００６５】
請求項１２に記載の発明によれば、アクセス券に有効期間を設けることにより、アクセス券を使用してロードバランサ装置にアクセスできる期間を制限できるので、より一層サーバへのアクセスを事前に制御することができる。
【００６６】
請求項１３に記載の発明は、請求項９乃至１２の何れかに記載する前記アクセス券を有する携帯電子機器端末からの前記ネットワークを介したアクセスを、複数のサーバから構成される所定のサービス提供を担うサーバ群のうち何れかのサーバに対して振り分けるように構成する。
【００６７】
請求項１３に記載の発明によれば、携帯電子機器端末にて取得したアクセス券で指定される特定のロードバランサ装置にアクセスするようにしたので、特定のサーバに同時にアクセスが集中することを避けることができる。また、アクセス券にて、事前に携帯電子機器端末がアクセスするロードバランサ装置を分散させることができるので、ある特定のロードバランサ装置のみに負荷がかかることを避けることができる。よって、時間的に負荷を効率よく分散、軽減させることができる。
【００６８】
【発明の実施の形態】
以下、本発明の好適な実施の形態を添付図面に基づいて説明する。以下の説明は、移動体通信システムに対して本発明を適用した場合の実施形態である。
【００６９】
先ず、本実施形態にかかる移動体通信システムの構成および機能について、図１乃至図３を参照して説明する。図１に、本実施形態にかかる移動体通信システムの構成例を示す。
【００７０】
図１に示すように、本実施形態にかかる移動体通信システム１００は、本発明の携帯電子機器端末としての携帯電話機２ａ乃至２ｃ、ＤＮＳ３、ＡＰＮ４ａ乃至４ｃ、ＢＰＳ５に加え、分散型アクセス制御システム６を含んで構成されている。また、ＤＮＳ３とＡＰＮ５ａ乃至５ｃとＢＰＳ５と分散型アクセス制御システム６とは、ネットワークとしてのインターネット１を介して相互に接続されている。
【００７１】
図２に、携帯電話機２ａ乃至２ｃの概略構成例を示す。図２に示すように、携帯電話機２ａ乃至２ｃは、それぞれ、移動体通信手段（無線基地局、交換局等）を介してインターネット１に接続し各種情報の送受信を行うための通信部２１、ユーザからの操作指令を入力するための操作部２２、各種情報や操作部より入力された操作内容を表示するための表示部２３、ユーザ認証に必要な情報（ＭＳＮ（電話番号）やユーザＩＤなど）、分散型アクセス制御システム６の後述するＩＡ７のＵＲＬ、さらには、本発明の「アクセス券」としての「Ｔｏｋｅｎ」や、Ｔｏｋｅｎ発行に必要な後述するサービスリストなどの情報を記録するクライアント記録部２４、以上の各要素の制御や、サービスリストや各種サービスの提示処理、Ｔｏｋｅｎの更新処理を行うＣＰＵよりなる制御・処理部２５を備えている。また、制御・処理部２５は、本発明のアクセス手段としての機能を有する。なお、図１の例では、便宜上、携帯電話機２ａ乃至２ｃを３台示しているが、実際には、これ以上の数が存在する。
【００７２】
ここで、図1に示す各構成要素の説明の前に、本発明の特徴である「アクセス券」としての「Ｔｏｋｅｎ」について説明する。Ｔｏｋｅｎとは、一言でいうと、ＡＰＮにアクセスしに行くための権利を意味し、ユーザからの要求に対して分散型アクセス制御システム６の後述するＩＡ７により、そのユーザの携帯電話機に対して発行されるものである。このＡＰＮにアクセスしに行くための権利は、金銭のやり取りには直接関わらないが、何かのサービスを受け付けて貰うために必要な権利である「整理券（但し、整理券の順番待ちをしなければならないという性質は除く）」に似ている。
【００７３】
即ち、携帯電話機は、このＴｏｋｅｎを取得して初めて、ＡＰＮにサービスを要求を行うためのアクセスをすることができ、Ｔｏｋｅｎを取得していない携帯電話機は、ＡＰＮにアクセスしにいくことすらできない（アクセスしに行ってから認証の結果で断られるのではなく、断られる事になっていると想定してアクセスしに行かない）ように制御部２５により制御される。
【００７４】
さらに、このＴｏｋｅｎは、かかる「整理券」の性質に加え、複数回利用することができる「回数券」の性質と、定められた期間内は有効である「定期券」の性質と、を含んでおり、ＡＰＮにアクセスしに行くための権利に、アクセスしに行くことができる回数（以下「有効度数」という）と、アクセスしに行くことができる期間（以下「有効期間」という）とが付加されている。より具体的には、携帯電話機は、Ｔｏｋｅｎを持っていても、それを使用する毎に、その有効度数が減っていき有効度数が「０」となった後は、ＡＰＮにアクセスしにいくことができなくなり、また、その有効期間が経過した後は、有効度数が「０」でなくとも、ＡＰＮにアクセスしにいくことができなくなるように制御される。
【００７５】
そして、このＴｏｋｅｎは、サービス毎、即ち、ＡＰＮ毎に対応して存在するものであり、ユーザは、後述する分散型アクセス制御システム６のＩＡ７から提供されるサービスリストのうち、所望するサービスに対応するＴｏｋｅｎを分散型アクセス制御システム６のＩＡ７に要求することができる。これにより、Ｔｏｋｅｎを携帯電話機で取得したユーザのみが、かかるＴｏｋｅｎに対応したＡＰＮにアクセスし、サービスの提供を受けることができる。
【００７６】
かかるＴｏｋｅｎのデータ構成としては、例えば、「アプリケーションサーバのＵＲＬ／有効度数／有効期間」などの情報で構成される。
【００７７】
このように、本通信システム１００にてＴｏｋｅｎという概念を用いることにより、これを取得していない携帯電話機からのＡＰＮへのアクセスを自律的に禁止することができるため、Ｔｏｋｅｎの発行を制御することで、ＡＰＮへのアクセスを事前に制御することができる。
【００７８】
図１の構成要素の説明に戻り、ＤＮＳ３は、従来の移動体通信システム（図１１参照）におけるＤＮＳ１０３と同様、各種サーバのＵＲＬをＩＰアドレスを変換して提供するサーバである。ＡＰＮ４ａ乃至４ｃも、従来の移動体通信システムにおけるＡＰＮ１０４ａ乃至１０４ｃと同様、携帯電話機２ａ乃至２ｃに対し各種サービスを提供するノード群であるが、従来の移動体通信システムのＡＰＮ１０４ａ乃至１０４ｃとは異なり、ＡＰＮ４ａ乃至４ｃには、上述したＴｏｋｅｎを取得している携帯電話機でなければアクセスすることができない。また、従来の移動体通信システムにおけるＡＰＮ１０４ａ乃至１０４ｃとは異なり、加入者ＤＢが設けられていない。これは、ユーザ認証は、後述する分散型アクセス制御システム６のＣＡ８により、Ｔｏｋｅｎ発行前に行なわれるので、ＡＰＮ４ａ乃至４ｃでは、携帯電話機２ａ乃至２ｃにサービスを提供する際のユーザ認証を行なう必要がないからである。なお、図１の例には、サービスＸを行うＡＰＮ４ａ、サービスＹを行うＡＰＮ４ｂ、サービスＺを行うＡＰＮ４ｃが、それぞれ、示されているが、実際には、サービスの種類は、これ以上存在し、かかるサービス毎にＡＰＮが設けられることとなる。
【００７９】
ＢＰＳ５も、従来の移動体通信システムにおけるＢＰＳ１０５と同様、携帯電話機２ａ乃至２ｃのユーザに対して、サービス提供による課金を行うシステムである。
【００８０】
分散型アクセス制御システム６は、図１に示すように、サービス情報提供装置（Information Agent：以下「ＩＡ」という）７と、加入者情報管理装置（Client Administrator：以下「ＣＡ」という）８と、サービス内容管理装置（Service Administrator：以下「ＳＡ」という）９と、を含んで構成される。ＩＡ７、ＣＡ８、ＳＡ９は、それぞれ、ハードウェア資源として、公知のパーソナルコンピュータ、中型、大型コンピュータ、ワークステーションなどのコンピュータからなる。
【００８１】
図３（Ａ）にＩＡ７の概略構成例を示す。図３（Ａ）に示すように、ＩＡ７は、各種情報を記憶する記憶部７１、インターネット１に接続し携帯電話機２ａ乃至２ｃ、ＣＡ８、ＳＡ９と各種情報の送受信を行うための通信部７２、以上の各要素の制御や、後述するサービスリストおよび、上述したＴｏｋｅｎを携帯電話機２ａ乃至２ｃに提供（発行）するための処理を行う制御・処理部７３を備えている。記憶部７１には、サービス情報データベース（ＤＢ）が論理的に構築されており、かかるＤＢには、ＡＰＮ４ａ乃至４ｃから携帯電話機２ａ乃至２ｃに対して提供することが可能なサービス情報が、後述するユーザクラスに対応付けられて蓄積されている。このサービス情報は、ＳＡ９からインターネット１を介して定期的に送信される。制御・処理部７３は、本発明のアクセス券発行手段としての機能を有する。
【００８２】
このＩＡ７は、分散型アクセス制御システム６のうち、携帯電話機２ａ乃至２ｃが唯一アクセスすることが可能な装置であり、携帯電話機２ａ乃至２ｃに対する受付窓口としての役割を担っている。ＩＡ７の制御・処理部７３は、携帯電話機２ａ乃至２ｃからのサービスリストの要求を受付け、後述するＣＡ８からのサービスリスト提供可否や、ユーザ情報（後述するユーザクラス）に基づいて携帯電話機２ａ乃至２ｃのそれぞれに提供可能なサービスを選定し、サービスリストを生成して、これを、通信部７２およびインターネット１等を介して、携帯電話機２ａ乃至２ｃに提供する。
【００８３】
また、ＩＡ７の制御・処理部７３は、携帯電話機２ａ乃至２ｃからのサービスリストに基づくＴｏｋｅｎの要求を受付け、これに伴なってＳＡ９にて生成された要求サービスに対応するＴｏｋｅｎを、通信部７２およびインターネット１等を介して、携帯電話機２ａ乃至２ｃに提供する。
【００８４】
図３（Ｂ）にＣＡ８の概略構成例を示す。図３（Ｂ）に示すように、ＣＡ８は、各種情報を記憶する記憶部８１、インターネット１に接続しＢＰＳ５、ＩＡ７、ＳＡ９と各種情報の送受信を行うための通信部８２、以上の各要素の制御や、ユーザ情報の登録・更新・削除、ユーザ認証、Ｔｏｋｅｎの有効度数、有効期間の決定、ユーザ毎のＴｏｋｅｎ取得状況の記録などの処理を行う制御・処理部８３を備えている。また、制御・処理部８３は、本発明のユーザ認証手段としての機能を有する。記憶部８１には、加入者情報ＤＢが論理的に構築されており、かかるＤＢには、移動体通信事業者の店舗や代理店などで、携帯電話利用契約を行った加入者（ユーザ）情報、例えば、ユーザ毎に付与されるユーザＩＤに対応付けて、携帯電話機の電話番号（ＭＳＮ）、ユーザの住所、氏名、どのサービスを利用するかを示すユーザクラス（ユーザの指定より設定）、Ｔｏｋｅｎについての特別取極、Ｔｏｋｅｎ取得状況、課金情報などの情報が蓄積されている。
【００８５】
ここで、Ｔｏｋｅｎについての特別取極とは、ユーザと分散型アクセス制御システム６の運営者との間の特別の取極めである。例えば、Ｔｏｋｅｎは、上述したように、整理券としての性質を有するため、それ自体を提供することで、原則として、課金はせず、一律に有効度数、有効期間を設定するものであるが、例外として、ユーザからの要求に応じて有効度数を通常のものより高く設定したり、有効期間を通常のものより長く設定したりする特別の取極めを行うこともできる。かかる場合、通常よりも高く、或いは長く設定した分の料金を、基本料金に上乗せる等を行うようにしてもよい。
【００８６】
また、特別待遇用Ｔｏｋｅｎを発行するか否かの特別の取極めも行うことができる。ＡＰＮ内に複数のアプリケーションサーバが設けられている場合、後述するＳＡ９において、アクセス配分を予め制御するよう、ＴｏｋｅｎにおけるＵＲＬを分散するように設定することができるが、特別待遇用Ｔｏｋｅｎにてアクセス可能なアプリケーションサーバに対しては、通常のＴｏｋｅｎにてアクセス可能なアプリケーションサーバよりも負荷を軽くするように設定する。これにより、特別待遇用Ｔｏｋｅｎを取得しているユーザは、通常のＴｏｋｅｎを取得しているユーザよりも、アクセス時間が早くなる。かかる場合も、通常よりも高く、或いは長く設定した分の料金を、基本料金に上乗せる等を行うようにしてもよい。
【００８７】
以上のようなユーザ情報は、ＢＰＳ１０５の加入者ＤＢに最初に登録された後、ＣＡ８の加入者情報ＤＢに登録するようにしても、ＣＡ８の加入者情報ＤＢに最初に登録するようにしても構わない。
【００８８】
ＣＡ８の制御・処理部８３は、携帯電話機２ａ乃至２ｃからのサービスリストの要求がＩＡ７にあった際のＩＡ７からの通知に応じ、加入者情報ＤＢのユーザ情報に基づいて、ユーザ認証、即ち、携帯電話機２ａ乃至２ｃのユーザ、例えば、ＭＳＮが、加入者情報ＤＢに登録されているか否かを判断するとともに、そのユーザの課金情報からユーザに対してサービスを提供しても良いかどうかを判断し、その結果（サービスリスト提供可否）をインターネット１を介してＩＡ７に通知する。
【００８９】
また、ＣＡ８の制御・処理部８３は、携帯電話機２ａ乃至２ｃからのサービスリストに基づくＴｏｋｅｎの要求がＩＡ７にあった際のＩＡ７からの通知に応じ、特別の取極めがあれば、その情報とともに、Ｔｏｋｅｎの要求があった旨の情報をインターネット１を介してＳＡ９に通知する。さらに、ＣＡ８の制御・処理部８３は、ＳＡ９にて生成されたＴｏｋｅｎを、一旦受けて、対応するユーザのユーザ情報に対応付けてＴｏｋｅｎ取得状況を加入者情報ＤＢに記録した後、かかるＴｏｋｅｎをＩＡ７に提供する。そして、このＴｏｋｅｎは、上述したように、ＩＡ７から携帯電話機に対して、発行されることとなる。
【００９０】
即ち、このＴｏｋｅｎ発行は、サービスリストの提供を経た後に行なわれるものであって、このサービスリストの提供は、ＣＡ７におけるユーザ認証等の判断結果、サービス提供可能であった場合に行なわれる。そして、携帯電話機２ａ乃至２ｃのユーザは、Ｔｏｋｅｎが無ければ、ＡＰＮ４ａ乃至４ｃに対してアクセスすることすらできないので、ＡＰＮ４ａ乃至４ｃ側でサービス提供時にユーザ認証を行う必要がなくなる。
【００９１】
従って、ＡＰＮ４ａ乃至４ｃにおける加入者ＤＢを削減することができ、ひいては、加入者ＤＢ内の情報の整合性がとれないという問題点を解消することができる。また、各ＡＰＮ４ａ乃至４ｃにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【００９２】
図３（Ｃ）にＳＡ９の概略構成例示す。図３（Ｃ）に示すように、ＳＡ９は、各種情報を記憶する記憶部９１、インターネット１に接続しＡＰＮ４ａ乃至４ｃ、ＣＡ８、ＳＡ９と各種情報の送受信を行うための通信部９２、以上の各要素の制御や、Ｔｏｋｅｎの生成、サービス内容の登録・更新・削除などの処理を行う制御・処理部９３を備えている。
【００９３】
記憶部９１には、サービス内容ＤＢが論理的に構築されており、かかるＤＢには、ＡＰＮ４ａ乃至４ｃのそれぞれにおいて提供されるサービス内容、即ち、サービスに関する詳細内容がサービスＩＤに対応付けて蓄積されている。かかるサービス内容は、例えば、ＡＰＮ４ａ乃至４ｃにおいてサービス内容が追加、変更された際、ＡＰＮ４ａ乃至４ｃからインターネット１を介して送信されたり、新たなＡＰＮが設けれた際に、そのＡＰＮからインターネット１を介して送信される。また、各ＡＰＮで提供されるサービス内容には、上述したユーザクラスが設定されている。さらに、サービス内容ＤＢには、ＡＰＮ毎に対応付けてＴｏｋｅｎ発行状況（Ｔｏｋｅｎ発行数）が蓄積されている。また、制御・処理部９３は、本発明のアクセス券発行可否決定手段としての機能を有する。
【００９４】
ＳＡ９の制御・処理部９３は、携帯電話機２ａ乃至２ｃからのＴｏｋｅｎの要求がＩＡ７にあった際のＣＡ８からの通知に応じ、先ず、発行要求があったＴｏｋｅｎに対応するＡＰＮのＴｏｋｅｎ発行状況から、Ｔｏｋｅｎを発行すべきか否かを決定する。これにより、携帯電話機のＡＰＮに対するアクセスを制御することができるので、例えば、同じ時間帯に、多くのアクセスが集中した場合にも、ＡＰＮにて十分に対応することが可能となる。
【００９５】
そして、ＳＡ９の制御・処理部９３は、Ｔｏｋｅｎを発行を決定した場合には、特別の取極めがあれば、その情報に基づいて、Ｔｏｋｅｎ（サーバのＵＲＬ／有効度数／有効期限）を生成し、それをインターネット１を介してＣＡ８に提供する。
【００９６】
ＡＰＮが複数のアプリケーションサーバから構成されている場合には、ＳＡ９の制御・処理部９３は、その都度、ＴｏｋｅｎにおけるＵＲＬを、それぞれのサーバに分散するように設定する。これにより、Ｔｏｋｅｎを取得した携帯電話機は、毎回特定のアプリケーションサーバにアクセスを試行することとなる。この事は、ＡＰＮに対する携帯電話機のアクセス配分を予め制御することができることを意味し、これにより、負荷分散を行うことができるので、同じ時間帯に、一つのアプリケーションサーバにアクセスが集中することを回避することができる。
【００９７】
なお、上述したように、特別の取極にて、特別待遇用Ｔｏｋｅｎを生成する場合には、ＴｏｋｅｎにおけるＵＲＬを特別のＵＲＬとして設定する。
【００９８】
また、ＳＡ９の制御・処理部９３は、サービス内容ＤＢにＡＰＮのサービス内容の新規登録、追加、変更があった場合には、その情報（サービスリスト生成のための情報）をインターネット１を介してＩＡ７に送信する。
【００９９】
次に、以上の本実施形態にかかる移動体通信システム１００における動作について、図４乃至図１０を参照して説明する。
【０１００】
図４に、携帯電話機２ａ乃至２ｃに対するサービスリスト提供時の本システム１００における模式図を、図５に、携帯電話機２ａ乃至２ｃに対するサービスリスト提供時の本システム１００における処理の流れ（フロー）を、それぞれ示す。
【０１０１】
先ず、携帯電話機の制御・処理部２５は、ユーザからの操作部２２を介した指示に応じて、移動体通信手段を介して、クライアント記録部２４に予め登録された分散型アクセス制御システム６のＩＡ７のＵＲＬを指定して、ＩＡ７とのインターネット１での接続を確立し、サービスリストを要求する（ステップＳ１）。図４の例では、３台の携帯電話機２ａ乃至２ｃが、それぞれ、ＩＡ７に対し、サービスリストを要求しているようすを示している。なお、携帯電話機２ａ乃至２ｃとＩＡ７との接続は、上述したように、ＤＮＳ３にて、ＵＲＬからＩＰアドレスに変換されることにより行なわれるが、かかるステップについては、以下の説明でも省略する。
【０１０２】
次に、ＩＡ７の制御・処理部７３は、かかるサービスリストの要求に応じ、ＣＡ８に対してユーザ認証等をインターネット２を介して要求する（ステップＳ２）。この際、当該携帯電話機２ａ乃至２ｃのＭＳＮが、ＣＡ８に対して通知されることとなる。続いて、ＣＡ８の制御・処理部８３は、かかるユーザ認証等の要求に応じ、サービスリストを要求した携帯電話機のＭＳＮが加入者情報ＤＢに登録されているか否かを判断し（ステップＳ３）、登録されている場合には、その携帯電話機のユーザの課金情報からユーザに対してサービスを提供しても良いかどうかを判断する（ステップＳ４）。
【０１０３】
そして、ＣＡ８の制御・処理部８３は、サービスを提供しても良いと判断した場合には、その旨および、加入者情報ＤＢに登録されたその携帯電話機に対応するユーザクラスを、インターネット３を介してＩＡ７に通知する（ステップＳ５）。
【０１０４】
例えば、加入者情報ＤＢには、図４の符号４０１部に示すように、ＭＳＮがＡである携帯電話機２ａのサービスクラスは”１”、ＭＳＮがＢである携帯電話機２ｂのサービスクラスも”１”、ＭＳＮがＣである携帯電話機２ｃのサービスクラスもは”２”、としてそれぞれ登録されており、このような情報をＩＡ７に通知するのである。
【０１０５】
一方、ＣＡ８の制御・処理部８３は、上記ステップＳ４にて、携帯電話機のＭＳＮが登録されていないと判断した場合や、ステップＳ５において、サービスを提供しても良くない判断した場合、例えば、ユーザが通話料、サービス料等の支払いを延滞していた場合には、サービス提供は行わない旨をＩＡ７に通知する。
【０１０６】
ＩＡ７の制御・処理部８３は、かかる通知に応じ、サービスの提供に問題ないと判断した場合には、携帯電話機のユーザクラスに対応する提供可能サービスを、上述したように、ＳＡ９から提供された情報に基づいて選定し、サービスリストを生成して、インターネット１を介して対応する携帯電話機に提供する（ステップＳ７）。
【０１０７】
例えば、図４の符号４０２部に示すように、ユーザクラス”１”に対して提供可能なサービスは、サービスＸ、Ｙ、Ｚであり、ユーザクラス”２”に対して提供可能なサービスは、サービスＸ、Ｙである。従って、携帯電話機２ａおよび２ｂに対しては、ユーザクラスが”１”であることより、サービスＸ、Ｙ、Ｚのサービスリストを提供することとなる。また、携帯電話機２ｃに対しては、ユーザクラスが”２”であることより、サービスＸ、Ｙのサービスリストを提供することとなる。
【０１０８】
このように、Ｔｏｋｅｎ発行前のサービスリスト提供時において、ユーザ認証を行うようにしたので、ＡＰＮ４ａ乃至４ｃにおけるサービス提供時には、ユーザ認証を行う必要がなく、従って、ＡＰＮ４ａ乃至４ｃにおける加入者ＤＢを削減することができ、ひいては、加入者ＤＢ内の情報の整合性がとれないという問題点を解消することができる。また、各ＡＰＮ４ａ乃至４ｃにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【０１０９】
一方、ＩＡ７の制御・処理部８３は、かかる通知に応答し、サービスの提供に問題があると判断した場合には、サービス提供ができない旨を、携帯電話機に送信することとなる。
【０１１０】
そして、各携帯電話機２ａ乃至２ｃでは、提供されたサービスリストをクライアント記録部２４に記憶する（ステップＳ８）とともに、表示部２３に表示する。こうして、各携帯電話機２ａ乃至２ｃのユーザは、表示部２３に表示されたサービスリストから、所望のＴｏｋｅｎを要求するための操作を操作部２２にて行うこととなる。
【０１１１】
図６に、携帯電話機２ａ乃至２ｃに対するＴｏｋｅｎ提供時の本システム１００における模式図を、図７に、携帯電話機２ａ乃至２ｃに対するＴｏｋｅｎ提供時の本システム１００における処理の流れ（フロー）を、それぞれ示す。
【０１１２】
先ず、携帯電話機の制御・処理部２５は、ユーザからの操作部２２を介したＴｏｋｅｎ選択指示に応じて、インターネット１を介して、Ｔｏｋｅｎを要求する（ステップＳ１１）。図６の例では、携帯電話機２ａは、サービスリストの中に表示されたサービスＸ、Ｙ、Ｚの全てを要求しており、携帯電話機２ｂは、サービスリストの中に表示されたサービスＸ、Ｙ、Ｚのうち、サービスＸ、Ｚを要求しており、携帯電話機２ｃは、サービスリストの中に表示されたサービスＸ、Ｙの全てを要求している。かかる要求には、要求対象のサービスに対応するサービスＩＤが含まれる。
【０１１３】
次に、ＩＡ７の制御・処理部７３は、かかるＴｏｋｅｎの要求に応じ、ＣＡ８に対して、その旨およびサービスＩＤを、それを要求した携帯電話機のＭＳＮに対応付けてインターネット１を介して通知する（ステップＳ１２）。続いて、ＣＡ８の制御・処理部８３は、かかる通知に応じ、加入者ＤＢを参照して、特別の取極があるか否か判断し（ステップＳ１３）、ある場合には、その情報とともに、サービスＩＤ、ＭＳＮとともにインターネット１を介してＳＡ９に通知する（ステップＳ１４）。
【０１１４】
ＳＡ９の制御・処理部９３は、かかる通知に応じ、先ず、サービス内容ＤＢを参照して、発行要求があった（サービスＩＤに対応する）Ｔｏｋｅｎに対応するＡＰＮのＴｏｋｅｎ発行状況から、Ｔｏｋｅｎを発行すべきか否かを決定する（ステップＳ１５）。例えば、発行要求があった（サービスＩＤに対応する）ＴｏｋｅｎにＡＰＮのＴｏｋｅｎ発行状況から、Ｔｏｋｅｎ発行量とそのＡＰＮの負荷容量とを比較して、問題が無ければ、Ｔｏｋｅｎの発行を決定する。
【０１１５】
これにより、携帯電話機のＡＰＮに対するアクセスを制御することができるので、例えば、同じ時間帯に、多くのアクセスが集中した場合にも、ＡＰＮにて十分に対応することが可能となる。
【０１１６】
そして、ＳＡ９の制御・処理部９３は、Ｔｏｋｅｎを発行を決定した場合には、Ｔｏｋｅｎを生成する（ステップＳ１６）。ここで、特別の取極めがある場合には、その情報に基づいて、Ｔｏｋｅｎを生成する。続いて、ＳＡ９の制御・処理部９３は、そのＴｏｋｅｎに対応するサービス（サービスＩＤ）のＴｏｋｅｎ発行状況を更新する（ステップＳ１７）。ここで、上述したように、ＡＰＮが複数のアプリケーションサーバから構成されている場合には、ＳＡ９の制御・処理部９３は、ＴｏｋｅｎにおけるＵＲＬを、それぞれのサーバに分散するように設定する。これにより、負荷分散を行うことができるので、同じ時間帯に、一つのアプリケーションサーバにアクセスが集中することを回避することができる。
【０１１７】
また、上述したように、特別の取極に基づいて、特別待遇用Ｔｏｋｅｎを生成する場合には、ＳＡ９の制御・処理部９３は、ＴｏｋｅｎにおけるＵＲＬを特別のＵＲＬとして設定する。これにより、特別待遇用Ｔｏｋｅｎを取得しているユーザは、通常のＴｏｋｅｎを取得しているユーザよりも、アクセス時間が早くなる。
【０１１８】
そして、ＳＡ９の制御・処理部９３は、かかるＴｏｋｅｎを、ＭＳＮとともにインターネット１を介してＣＡ８に提供する（ステップＳ１８）。
【０１１９】
続いて、ＣＡ８の制御・処理部８３は、かかるＴｏｋｅｎ等を受け取り、加入者ＤＢを参照して、そのＴｏｋｅｎを要求したユーザのＴｏｋｅｎ取得状況を更新し（ステップＳ１９）後、かかるＴｏｋｅｎ等をインターネット１を介してＩＡ８に提供する（ステップＳ２０）。
【０１２０】
そして、ＩＡ７の制御・処理部７３は、かかるＴｏｋｅｎ等を受け取り、それを要求した携帯電話機に対して、インターネット１を介して発行（送信）する（ステップＳ２１）。
【０１２１】
一方、上記ステップＳ１５にて、ＳＡ９の制御・処理部９３が、Ｔｏｋｅｎを発行しないと決定した場合には、ＩＡ７の制御・処理部７３は、ＣＡ８を介して、その旨の情報を受け取り、それをインターネット１を介して携帯電話機に通知することとなる。
【０１２２】
そして、各携帯電話機２ａ乃至２ｃでは、発行されたＴｏｋｅｎを受け取り、クライアント記録部２４に記憶する（ステップＳ２２）。こうして、各携帯電話機２ａ乃至２ｃのユーザは、取得したＴｏｋｅｎに基づいて、ＡＰＮ４ａ乃至４ｃに対してアクセスすることが可能となる。
【０１２３】
図８および図９に、携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における模式図を、図１０に、携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における処理の流れ（フロー）を、それぞれ示す。
【０１２４】
図８の例では、以上の手続きにより、携帯電話機２ａは、Ｔｏｋｅｎ（Ｘ）、Ｔｏｋｅｎ（Ｙ）、Ｔｏｋｅｎ（Ｚ）を取得しており、携帯電話機２ｂは、Ｔｏｋｅｎ（Ｘ）、Ｔｏｋｅｎ（Ｚ）を取得しており、携帯電話機２ｃは、Ｔｏｋｅｎ（Ｘ）、Ｔｏｋｅｎ（Ｙ）を取得しており、これらのＴｏｋｅｎは、ユーザが操作部２２からの予定の指示に基づいて、表示部２３に表示される。
【０１２５】
そして、ユーザが、アクセスしたいＡＰＮに対応するＴｏｋｅｎを操作部２２から指定すると、携帯電話機の制御・処理部２５は、かかるＴｏｋｅｎに含まれる有効度数、有効期間からアクセス可能か否かを判断する（ステップＳ３１）。携帯電話機の制御・処理部２５は、アクセス可能であると判断した場合には、Ｔｏｋｅｎに含まれるＵＲＬに基づいて、ＡＰＮの特定のアプリケーションサーバに移動体通信手段およびインターネット１を介して、アクセスを試行する（ステップＳ３２）。
【０１２６】
図８に示すように、Ｔｏｋｅｎ（Ｘ）を取得している携帯電話機２ａ乃至２ｃは、それぞれ、ＡＰＮ４ａにアクセスすることができ、Ｔｏｋｅｎ（Ｙ）を取得している携帯電話機２ａおよび２ｃは、それぞれ、ＡＰＮ４ｂにアクセスすることができ、Ｔｏｋｅｎ（Ｚ）を取得している携帯電話機２ａおよび２ｂは、それぞれ、ＡＰＮ４ｃにアクセスすることができる。
【０１２７】
また、図９の例では、ＡＰＮ４ａが複数のアプリケーションサーバから構成されている場合を示しているが、この例では、携帯電話機２ａ乃至２ｃのそれぞれに発行されたサービスＸのＴｏｋｅｎにおけるＵＲＬが分散するように設定されているので、携帯電話機２ａ乃至２ｃは、それぞれ、特定のアプリケーションサーバにアクセスすることとなる。
【０１２８】
即ち、携帯電話機２ａは、Ｔｏｋｅｎ（Ｘ１）に基づき、ＡＰＮ４ａ内のアプリケーションサーバ（ＡＰＳ）１に、携帯電話機２ｂは、Ｔｏｋｅｎ（Ｘ２）に基づき、ＡＰＮ４ａ内のアプリケーションサーバ（ＡＰＳ）２に、携帯電話機２ｃは、Ｔｏｋｅｎ（Ｘ３）に基づき、ＡＰＮ４ａ内のアプリケーションサーバ（ＡＰＳ）３に、それぞれ、アクセスすることとなる。これにより、負荷分散を行うことができるので、同じ時間帯に、一つのアプリケーションサーバにアクセスが集中することを回避することができる。
【０１２９】
一方、上記ステップＳ３１で、携帯電話機の制御・処理部２５は、アクセス不可であると判断した場合、例えば、有効期間が既に経過していた場合や、有効度数が「０」であった場合には、アクセス試行は行わない。
【０１３０】
こうして、携帯電話機がＡＰＮとのインターネット上での接続を確立すると、携帯電話機とＡＰＮとの間で、サービスの提供と利用が行なわれる（ステップＳ２２）こととなる。また、携帯電話機がＡＰＮとのインターネット上での接続の確立により、携帯電話機の制御・処理部２５は、Ｔｏｋｅｎにおける有効度数を１つ減らし更新する（ステップＳ３３）。
【０１３１】
なお、かかる有効度数は、携帯電話機の制御・処理部２５により、ＡＰＮへのアクセスを行う度に減算されるものであり、例えば、現在、有効度数が「１０」であるとすると、ＡＰＮのアクセスは、１０回行うことができる。また、かかる有効度数が「０」となる前、或いは、「０」となった時点で、携帯電話機の制御・処理部２５が、自動的に、分散型アクセス制御システム６のＩＡ７にアクセスし、かかるＴｏｋｅｎの更新（有効度数を増やす更新）を行うようにしてもよい。この事は、Ｔｏｋｅｎの有効期限についても同様で、有効期限が到来する数日前、或いは、有効期限が到来した際、携帯電話機の制御・処理部２５が、自動的に、分散型アクセス制御システム６のＩＡ７にアクセスし、かかるＴｏｋｅｎの更新（有効期限を延ばす更新）を行うようにしてもよい。
【０１３２】
そして、ＡＰＮでは、サービス提供に基づく上述したＣＤＲを生成する（ステップＳ３４）。ＢＰＳ５は、インターネット１を介して、かかるＣＤＲを収集し（ステップＳ３５）、当該ユーザに対する課金処理を行う（ステップＳ３６）。そして、ＢＰＳ５は、インターネット１を介して、分散型アクセス制御システム６のＣＡ８に対して、当該ユーザのＭＳＮに対応付けて課金情報を提供する（ステップＳ３７）。そして、分散型アクセス制御システム６のＣＡ８では、加入者情報ＤＢ内のかかるユーザに対応する課金情報を更新する（ステップＳ３８）。
【０１３３】
以上説明したように本実施形態によれば、Ｔｏｋｅｎという概念を用いることにより、これを取得していない携帯電話機からのＡＰＮへのアクセスを自律的に禁止することができるようにしたので、Ｔｏｋｅｎの発行を制御することで、ＡＰＮへのアクセスを事前に制御することができる。よって、時間的に負荷を効率よく分散、軽減させることができる。
【０１３４】
また、ＡＰＮに対応するＴｏｋｅｎ発行状況に基づいて、Ｔｏｋｅｎ発行可否を制御することができるので、さらにＡＰＮへのアクセスを事前に制御することができ、例えば、同じ時間帯に、多くのアクセスが集中した場合にも、ＡＰＮにて十分に対応することが可能となる。
【０１３５】
また、ＡＰＮが複数のアプリケーションサーバから構成されている場合に、ＴｏｋｅｎにおけるＵＲＬを、それぞれのサーバに分散するように設定することができるので、ＡＰＮへの負荷分散を制御することができ、同じ時間帯に、一つのアプリケーションサーバにアクセスが集中することを回避することができる。
【０１３６】
また、Ｔｏｋｅｎという概念を用いることで、サービス提供にかかるユーザ認証を、一個所で行うことができるので、各ＡＰＮにおけるサービス提供時に、ユーザ認証を行う必要がなくなり、その結果、各ＡＰＮおける加入者ＤＢを削減することができ、ひいては、加入者ＤＢ内の情報の整合性がとれないという問題点を解消することができる。また、各ＡＰＮにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【０１３７】
次に、上記実施形態において、ＡＰＮが複数のアプリケーションサーバから構成されている場合には、ＳＡ９の制御・処理部９３は、ＴｏｋｅｎにおけるＵＲＬを、それぞれのサーバに分散するように設定するように構成したが、さらに効果的な負荷分散の手法として、ロードバランサ（負荷平衡）装置を用いる構成について、図１１乃至図１３を参照して説明する。
【０１３８】
図１１は、ＡＰＮ４ａ乃至４ｃのそれぞれ対して、負荷のバランスを図るためのロードバランサ群１５ａ乃至１５ｃを設けた場合の移動体通信システムの構成例を示す図である。ロードバランサ群１５ａ乃至１５ｃのそれぞれには、複数のロードバランサ装置が設けられており、かかるロードバランサ装置は、ＡＰＮ内の複数のアプリケーションサーバへの携帯電話機からのアクセスを振り分ける機能を有する。
【０１３９】
なお、以下の図１１に示す移動体通信システム２００の説明において、上記図１に示す移動体通信制御システム１００と同様の構成、機能部分の説明は省略する。
【０１４０】
図１１に示す移動体通信システム２００の構成においても、上記図５を参照して説明したサービスリスト提供時における処理の流れ、および上記図７を参照して説明したＴｏｋｅｎ提供時における処理の流れは同様であるが、図７に示すステップＳ１６において、ＳＡ９の制御・処理部９３が生成するＴｏｋｅｎのデータ構成が異なる。
【０１４１】
即ち、上記図１に示す移動体通信制御システム１００においては、Ｔｏｋｅｎのデータ構成を「アプリケーションサーバのＵＲＬ／有効度数／有効期間」としたが、移動体通信システム２００において、ＳＡ９の制御・処理部９３により生成されるＴｏｋｅｎのデータ構成は、「ロードバランサ装置のＵＲＬ／有効度数／有効期間」とする。このロードバランサ装置のＵＲＬは、上記にて説明したアプリケーションサーバのＵＲＬと同様に、ＤＮＳ３にＩＰアドレス（以下「論理アドレス」という）に対応させて予め登録される。
【０１４２】
図１２に、携帯電話機２ａ乃至２ｈに対する各種サービス提供時の本システム２００における模式図を、図１３に、携帯電話機２ａ乃至２ｈに対する各種サービス提供時の本システム２００における処理の流れを、それぞれ示す。なお、図１３において、図１０のステップＳ３４からステップＳ３８に相当する流れは、省略している。
【０１４３】
図１２の例では、ロードバランサ群１５ａには、３台のロードバランサ装置が設けられており、それぞれのロードバランサ装置には、２つの受け口が設けられている。各受け口と論理アドレスは、１対１に対応付けられている。なお、かかる受け口は、２つとは限らずいくつであってもよい。
【０１４４】
携帯電話機が、上記図７における手続きにより、Ｔｏｋｅｎを受け取ると、携帯電話機は、かかるＴｏｋｅｎに含まれるＵＲＬを論理アドレスに変換する要求をＤＮＳ３に対して行う。ＤＮＳ３によりＴｏｋｅｎに含まれるロードバランサ装置のＵＲＬが論理アドレスに変換された後、携帯電話機は、これに基づいて、ロードバランサ装置の特定の受け口にアクセスする（ステップＳ５１）。
【０１４５】
例えば、図１２に示すように、携帯電話機２ａはロードバランサ装置１のＬ.A.1に、携帯電話機２ｂはロードバランサ装置１のＬ.A.2に、携帯電話機２ｃはロードバランサ装置２のＬ.A.2に、それぞれアクセスする。即ち、この段階で、先ず、静的に携帯電話機のロードバランサへの割付が行なわれるのである。
【０１４６】
そして、図１２の例では、ロードバランサ装置１にアクセスしてきた携帯電話機２ａ、２ｂ、２ｄを、ＡＰＮ４ａ内の実ＩＰアドレスのアプリケーションサーバ（ＡＰＳ）１乃至３の何れかに自動的に振り分ける（ステップＳ５２）。ロードバランサ装置２および３でも同様に、携帯電話機からのアクセスを動的にＡＰＳに振り分けることとなる。かかる振り分けは、ロードバランサ装置が、その時点で、アクセスされていないＡＰＳを選定して行うものである。これにより、携帯電話機とアプリケーションサーバとのインターネット１上における接続が確立し、サービスの提供と利用が行なわれることとなる（ステップＳ５３）。
【０１４７】
このように、図１１に示す移動体通信システム２００に示す実施形態によれば、ＡＰＮ毎にロードバランサ群を設けるように構成し、携帯電話機にて取得したＴｏｋｅｎで指定される特定のロードバランサ装置にアクセスするようにしたので、ＡＰＮ内のある特定のアプリケーションサーバ（ＡＰＳ）に同時にアクセスが集中することを避けることができる。また、Ｔｏｋｅｎにて、事前に携帯電話機がアクセスするロードバランサ装置を分散させることができるので、ある特定のロードバランサ装置のみに負荷がかかることを避けることができる。よって、時間的に負荷を効率よく分散、軽減させることができる。また、ロードバランサ装置の増設や収容替えをユーザのインパクトが少なく実施することができる。
【０１４８】
また、ロードバランサ装置により、アプリケーションサーバの増設や収容替え時においても、携帯電話機側には影響を与えず、均等にアクセスを振り分けることができ、また、１つのアプリケーションサーバがダウンした時も、他のアプリケーションサーバに均等に振り分けることができ、アプリケーションサーバの信頼性および本システム２００の信頼性を高めることができる。
【０１４９】
なお、図１１に示す移動体通信システム２００に示す実施形態の場合も、特別待遇Ｔｏｋｅｎがあり、この場合の特別待遇Ｔｏｋｅｎに含まれるＵＲＬは、最も信頼性の高いロードバランサ装置のＵＲＬとする。即ち、携帯電話機からアプリケーションサーバまでのアクセスルートを、ユーザ毎に異なるように負荷分散することができるので、例えば、特別待遇Ｔｏｋｅｎを取得したユーザに対しては、信頼性の高いサーバへ、通常のＴｏｋｅｎを取得したユーザに対しては、信頼性のあまり高くないサーバへ振り分けるなど、ユニークな負荷分散を行うことができる。
【０１５０】
なお、上記実施形態において、分散型アクセス制御システム６のＣＡ８にも、ＢＰＳ５が備える加入者ＤＢと同様のものを備えているので、ＢＰＳ５が行うＣＤＲ収集、課金処理などの役割の全部または一部を、分散型アクセス制御システム６のＣＡ８が行うように構成してもよい。このような構成にすれば、ＢＰＳ５の負担を低減させることができる。
【０１５１】
また、上記実施形態において、Ｔｏｋｅｎ発行は、ユーザによるサービスリストからの選択を経て行うように構成したが、これに限定されるものではなく、例えば、ユーザが、分散型アクセス制御システム６のオペレータに電話をし、口頭で所望のサービスのＴｏｋｅｎを携帯電話機に対して発行するように依頼することにより、かかる携帯電話機にＴｏｋｅｎを発行するように構成してもよい。このような構成においても、上記実施形態の構成と同等の効果を得ることができる。
【０１５２】
また、上記実施形態において、ＣＡ８によるユーザ認証は、サービスリスト提供時に１回行うように構成したが、これに代えて、サービスリスト提供時にユーザ認証を行わずに、サービスリストを携帯電話機に提供し、Ｔｏｋｅｎ発行要求があった際に、かかるユーザ認証を行うように構成してもよい。このような構成でも、加入者ＤＢは、ＡＰＮに設置する必要はないので、上記実施形態の構成と同等の効果を得ることができる。
【０１５３】
また、本実施形態において分散型アクセス制御システム６におけるＩＡ７とＣＡ８とＳＡ９とは、インターネット１を介して相互に接続されるように構成したが、これに限定されず、例えば、ＩＡ７とＣＡ８とＳＡ９をＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、ＧＡＮ（Global Area Network）などのネットワークおよびＨＵＢを介して相互に接続し、ＩＡ７のみがインターネット１に接続されるように構成してもよい。かかる場合には、ＣＡ８とＢＰＳ５間の通信や、ＳＡ９とＡＰＮ４ａ乃至４ｃ間の通信は、ＩＡ７を介して行なわれることとなる。
【０１５４】
また、上記実施形態において、Ｔｏｋｅｎには、ＵＲＬと有効期間と有効期限などからなることを説明したが、このような形式に限定されず、例えば、Ｔｏｋｅｎは、有効期間と有効期限から構成されるようにし、Ｔｏｋｅｎ発行の際、これに特定のロードバランサ装置のＵＲＬが添付されるように構成してもよい。
【０１５５】
【発明の効果】
以上で説明したように、本発明によれば、ネットワーク上の特定のロードバランサ装置にアクセスするためのアクセス券としてのＴｏｋｅｎという概念を用いることにより、これを取得していない携帯電子機器端末からのロードバランサ装置およびこれに接続されるサーバへのアクセスを自律的に禁止することができるので、Ｔｏｋｅｎの発行を制御することで、サーバへのアクセスを事前に制御することができる。よって、時間的に負荷を効率よく分散、軽減させることができる。
【０１５６】
また、ロードバランサ装置に対応するＴｏｋｅｎ発行状況に基づいて、Ｔｏｋｅｎ発行可否を制御することができるので、さらにロードバランサ装置へのアクセスを事前に制御することができ、例えば、同じ時間帯に、多くのアクセスが集中した場合にも、ロードバランサ装置およびサーバにて十分に対応することが可能となる。
【０１５７】
また、Ｔｏｋｅｎという概念を用いることで、サービス提供にかかるユーザ認証を、一個所で行うことができるので、各サーバにおけるサービス提供時に、ユーザ認証を行う必要がなくなり、その結果、各サーバおけるユーザ情報に関するデータベースを削減することができ、ひいては、かかるデータベース内の情報の整合性がとれないという問題点を解消することができる。また、各サーバにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【０１５８】
また、携帯電子機器端末にて取得したＴｏｋｅｎで指定される特定のロードバランサ装置にアクセスするようにしたので、特定のサーバに同時にアクセスが集中することを避けることができる。また、Ｔｏｋｅｎにて、事前に携帯電子機器端末がアクセスするロードバランサ装置を分散させることができるので、ある特定のロードバランサ装置のみに負荷がかかることを避けることができる。よって、時間的に負荷を効率よく分散、軽減させることができる。また、ロードバランサ装置の増設や収容替えをユーザのインパクトが少なく実施することができる。
【０１５９】
また、サーバの増設時においても、携帯電子機器端末側には影響を与えず、均等にアクセスを振り分けることができ、また、１つのサーバがダウンした時も、他のサーバに均等に振り分けることができ、サーバの信頼性およびシステムの信頼性を高めることができる。
【図面の簡単な説明】
【図１】本実施形態にかかる移動体通信システムの構成例を示す図である。
【図２】携帯電話機２ａ乃至２ｃの概略構成例を示す図である。
【図３】（Ａ）は、ＩＡ７の概略構成例を示す図、（Ｂ）は、ＣＡ８の概略構成例を示す図、（Ｃ）は、ＳＡ９の概略構成例示す図である。
【図４】携帯電話機２ａ乃至２ｃに対するサービスリスト提供時の本システム１００における模式図である。
【図５】携帯電話機２ａ乃至２ｃに対するサービスリスト提供時の本システム１００における処理の流れを示すフローチャートである。
【図６】携帯電話機２ａ乃至２ｃに対するＴｏｋｅｎ提供時の本システム１００における模式図である。
【図７】携帯電話機２ａ乃至２ｃに対するＴｏｋｅｎ提供時の本システム１００における処理の流れを示すフローチャートである。
【図８】携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における模式図である。
【図９】携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における模式図である。
【図１０】携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における処理の流れを示すフローチャートである。
【図１１】図１とは別の本実施形態にかかる移動体通信システム２００の構成例を示す図である。
【図１２】携帯電話機２ａ乃至２ｈに対する各種サービス提供時の本システム２００における模式図である。
【図１３】携帯電話機２ａ乃至２ｈに対する各種サービス提供時の本システム２００における処理の流れを示すフローチャートである。
【図１４】従来の移動体通信システムの構成例とともに、携帯電話機１０２がＡＰＮ１０４ａからサービスの提供を受ける際の流れ（▲１▼〜▲５▼）を示す図である。
【符号の説明】
１ インターネット
２ａ乃至２ｈ 携帯電話機
３ ＤＮＳ
４ａ、４ｂ、４ｃ ＡＰＮ
５ ＢＰＳ
６ 分散型アクセス制御システム
７ ＩＡ
８ ＣＡ
９ ＳＡ
１５ａ、１５ｂ、１５ｃ ロードバランサ群
１００、２００ 移動体通信システム
１０２ 携帯電話機
１０３ ＤＮＳ
１０４ａ、１０４ｂ、１０４ｃ ＡＰＮ
１０５ ＢＰＳ
【発明の属する技術分野】
本発明は、携帯電話機、ＰＨＳ、ＰＤＡなどの移動体の通信システムにおけるトラフィック量の増加に対する負荷分散を行うことが可能なシステムおよび方法に関する。
【０００２】
【従来の技術】
近年、移動体、例えば、携帯電話機が著しく普及し、今や数千万件の加入者数に達している。このような携帯電話機のユーザは、所望の場所から所望の者と電話通信を行うことができることに加えて、移動体通信事業者などが管理・運営するアプリケーションサーバから、インターネットなどのコンピュータ通信網、移動体通信網を介して様々なサービスの提供を受けることができる。例えば、携帯電話機間のメール交換、携帯電話機への各種情報の提供、さらには、携帯電話機への音楽、映像、ゲームコンテンツの配信など、様々なサービスが存在する。
【０００３】
図１４に、従来の移動体通信システムの構成例とともに、携帯電話機１０２がＡＰＮ１０４ａからサービスの提供を受ける際の流れ（▲１▼〜▲５▼）を示す。図１４において、インターネット１には、各種サーバのＵＲＬ（Uniform Resource Locator)をＩＰ（Internet Protocol）アドレスを変換して提供するＤＮＳ（Domain name Server）１０３、携帯電話機１０２に対し各種サービスを提供するＡＰＮ（Application Node：アプリケーションノード群）１０４ａ乃至１０４ｃ、携帯電話機１０２のユーザに対して、サービス提供による課金を行うＢＰＳ（Billing Provisioning System）１０５が接続されている。
【０００４】
ここで、ＡＰＮ１０４ａ乃至１０４ｃは、複数のアプリケーションサーバ（ＡＰＳ：Application Server）から構成される単一アプリケーションであり、それぞれ、固有のサービスを提供（ＡＰＮ１０４ａはサービスＸを、ＡＰＮ１０４ｂはサービスＹを、ＡＰＮ１０４ｃはサービスＺを、それぞれ提供）する。ＡＰＮに複数のＡＰＳを設けているのは、多くの携帯電話機からのサービスの要求に対応するためである。また、ＡＰＮ毎に共通の携帯電話加入者ＤＢ（データベース）を備えている。
【０００５】
また、ＢＰＳ１０５にも、ＡＰＮ１０４ａ乃至１０４ｃのそれぞれが設ける加入者ＤＢと同様のＤＢを設けており、移動体通信事業者の店舗や代理店などで、携帯電話利用契約を行った加入者の情報（例えば、携帯電話機の電話番号（ＭＳＮ）、加入者の住所、氏名、上記サービス利用の有無などの情報）は、通常、ＢＰＳ１０５の加入者ＤＢに最初に登録される。そして、その後、その加入者情報は、ＢＰＳ１０５より、インターネット１、公衆回線、専用回線などを介して各ＡＰＮの加入者ＤＢに書き込まれる。
【０００６】
また、携帯電話利用契約を行った加入者の携帯電話機１０２の内部メモリにも、必要な情報が記憶される。例えば、利用契約を行ったサービスに対応するＵＲＬが記憶される。
【０００７】
以上の構成において、携帯電話機１０２のユーザが、例えば、ＡＰＮ１０４ａからサービスＸの提供を受ける場合、携帯電話機１０２の内部メモリに記憶されたサービスＸのＵＲＬを表示部に表示させ、それを、操作ボタンにより選択し決定（ＡＰＮ１０４ａのＵＲＬを指定）すると、ＤＮＳ１０３にてＵＲＬがＩＰアドレスに変換された後、携帯電話機１０２は、かかるＩＰアドレスに基づき、ＡＰＮ１０４ａにアクセスし、サービスの要求（▲１▼）を行う。
【０００８】
ＡＰＮ１０４ａは、これに応じ、加入者情報ＤＢを参照して、アクセスしてきた携帯電話機１０２のユーザの認証（▲２▼）、即ち、加入者情報ＤＢに、そのユーザがサービスＸの提供を受ける者として登録され、かつ、ブラックリスト（料金未払い等の者のリスト）にない場合に、その携帯電話機１０２にサービスの提供（▲３▼）を行う。
【０００９】
なお、かかるサービス提供（▲３▼）の前に、ＡＰＮ１０４ａから携帯電話機１０２に対し認証結果が良好である旨の通知がなされる。
【００１０】
かかるサービスの提供により、ＡＰＮ１０４ａには、携帯電話機１０２のユーザに対する課金のための記録としてのＣＤＲ（Call Detailed Record：何月何日何時何分に何のサービスをどの携帯電話機のユーザに提供したかを示す記録）が発生し、図示しない所定のＤＢに蓄積される。
【００１１】
そして、ＢＰＳ１０５により定期的に行なわれるＣＤＲの収集により、かかるＣＤＲが収集され（▲４▼）、ＢＰＳ１０５において、上記サービスＸを利用したユーザに対する課金処理が行なわれることとなる（▲５▼）。
【００１２】
以上のようなサービス提供の流れ（▲１▼〜▲５▼）は、携帯電話機１０２がＡＰＮ１０４ｂ、ＡＰＮ１０４ｃ、その他のアプリケーションサーバからサービス提供を受ける場合にも同様である。
【００１３】
【発明が解決しようとする課題】
ところで、上記のようなサービスは、今後も趣向をこらし、益々発展していくことが予想され、移動体通信の加入者の増大と相まって、かかるサービス利用者が益々増大してゆくことが予想されるが、このことは、同時にトラフィック量の増加を招き、移動体通信システムに対して、多大な負荷を与えることを意味する。
【００１４】
従来の上記移動体通信システムにおいて、このような負荷に対応するためには、例えば、ＡＰＮ内のＡＰＳの数を増大させるなども考えられるが、これにも設備投資の問題でおのずと限界がある。また、同じ時間帯に、多くのアクセスが集中した場合には、ほとんど対応が困難となるという問題が容易に予想される。従って、従来の移動体通信システムでは、今後益々高まるであろうトラフィック量の増加による当該システムへの負荷を効果的に分散させ、低減することは、極めて困難である。
【００１５】
さらに、従来の上記移動体通信システムでは、上記トラフィック量の増加に伴い、以下の問題が、一層顕在化することが予想される。
【００１６】
即ち、上述したように、携帯電話機１０２へのサービスの提供毎にＡＰＮ側で認証を行わなければならないため、ＡＰＮ毎に、加入者ＤＢを設ける必要がある。このことは、多数の箇所に重複した加入者ＤＢを設けることを意味するので、無駄であるばかりか、これらの加入者ＤＢ内のデータに整合がとれているか保証できないという問題がある。例えば、上述したように、新たな加入者情報（解約する場合も同様）は、ＢＰＳ１０５の加入者ＤＢに登録された後、各ＡＰＮの加入者ＤＢに登録されるため、かかる情報を書き込むタイミングにずれが生じ、それぞれの加入者ＤＢで整合がとれていないこともありうる。
【００１７】
また、携帯電話機１０２へのサービスの提供毎にＡＰＮ側で認証を行わなければならないことより、認証のための余分なトラフィックの発生、さらには、認証のためのＡＰＮにおけるＣＰＵの浪費、通信設備の浪費が生じるという問題もある。
【００１８】
さらに、各ＡＰＮの加入者ＤＢへの新たな加入者情報の書き込みや、各ＡＰＮで発生したＣＤＲの収集などのＢＰＳ１０５に対する負担増大という問題もある。
【００１９】
本発明は、以上の問題に鑑みてなされたものであり、時間的に負荷を効率よく分散、軽減させ、加えて、システムの信頼性を高めることが可能な分散型アクセス制御システムおよび分散型アクセス制御方法、並びに携帯電子機器端末、ロードバランサ装置を提供することを目的とする。
【００２６】
【課題を解決するための手段】
請求項１に記載の発明は、ネットワーク上における通信制御を行う分散型アクセス制御システムであって、携帯電子機器端末を利用するユーザのユーザクラスを蓄積するデータベースと、前記携帯電子機器端末から、ネットワーク上で提供されるサービスのリストの要求を、前記ネットワークを介して受け付ける手段と、前記サービスのリストの要求をした前記携帯電子機器端末を利用するユーザのユーザクラスに対応するサービスを、複数のサービスの夫々に対応付けてユーザクラスとアクセス券の発行状況を蓄積するデータベースを備えた装置から提供された情報に基づいて選定して前記サービスのリストを生成し、前記携帯電子機器端末に対して、前記ネットワークを介して提供するサービスリスト提供手段と、前記携帯電子機器端末から、前記サービスのリストのうちからユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行要求を、前記ネットワークを介して受け付ける手段と、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するアクセス券発行手段と、を備えるように構成する。
ここで、ロードバランサ装置は、複数のサーバから構成されるサーバ群のうち何れかのサーバに対して携帯電子機器端末からのアクセスを振り分ける装置である。また、携帯電子機器端末には、携帯電話機、ＰＨＳ、ＰＤＡ等のモバイル型電子機器端末、などが含まれる。
【００２７】
請求項１に記載の発明によれば、分散型アクセス制御システムにおいて、携帯電子機器端末から、ネットワーク上で提供されるサービスのリストの要求が、ネットワークを介して受け付けられる。そして、要求されたサービスのリストであって携帯電子機器端末を利用するユーザのユーザクラスに対応するサービスのリストが、携帯電子機器端末に対して、ネットワークを介して提供される。次に、携帯電子機器端末においてサービスのリストのうちからユーザにより選択されたサービスの提供を担うネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行要求が、ネットワークを介して受け付けられる。そして、発行要求されたアクセス券が、携帯電子機器端末に対して、ネットワークを介して発行される。即ち、携帯電子機器端末のユーザは、当該アクセス券を、分散型アクセス制御システムから取得しなければ、特定のロードバランサ装置にアクセスすることができない。
【００２８】
従って、アクセス券を取得していない携帯電子機器端末からの特定のロードバランサ装置へのアクセスを自律的に禁止し、ロードバランサ装置により振り分けられるサーバへのアクセスを自律的に禁止することができる。また、ユーザは、アクセス券を取得する前に、それに関係するサービスのリストを見ることができるので大変便利である。
【００２９】
請求項２に記載の発明は、請求項１に記載の分散型アクセス制御システムにおいて、前記携帯電子機器端末を利用するユーザのユーザ情報を蓄積するデータベースと、前記データベースに蓄積されたユーザ情報を参照して、前記サービスのリストの要求を行った携帯電子機器端末のユーザ認証を行うユーザ認証手段と、をさらに備え、前記サービスリスト提供手段は、前記ユーザ認証の結果が妥当であった場合に、前記要求されたサービスのリストを、前記携帯電子機器端末に対して、前記ネットワークを介して提供するように構成する。
【００３０】
請求項３に記載の発明は、請求項１に記載の分散型アクセス制御システムにおいて、前記携帯電子機器端末を利用するユーザのユーザ情報を蓄積するデータベースと、前記データベースに蓄積されたユーザ情報を参照して、前記アクセス券の発行要求を行った携帯電子機器端末のユーザ認証を行うユーザ認証手段と、をさらに備え、前記アクセス券発行手段は、前記ユーザ認証の結果が妥当であった場合に、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するように構成する。
【００３１】
請求項２または３に記載の発明によれば、請求項１に記載の発明と同等の効果に加えて、分散型アクセス制御システムで、ユーザ認証を行い、ユーザ認証の結果が妥当であった場合に初めて当該アクセス券を発行するので、アクセス券にてアクセス対象となるロードバランサ装置に接続されるサーバでは、ユーザ認証する必要がなくなり、その結果、各サーバにおいて、ユーザ認証のために必要なユーザ情報が蓄積されたデータベースを削減することができ、ひいては、各サーバ毎の当該データベースの整合性がとれないという問題点を解消することができる。また、各サーバにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【００３２】
請求項４に記載の発明は、請求項１乃至３の何れかに記載の分散型アクセス制御システムにおいて、前記アクセス券の発行状況を蓄積するデータベースと、前記データベースに蓄積されたアクセス券の発行状況に基づいて、前記アクセス券の発行可否を決定するアクセス券発行可否決定手段と、をさらに備え、前記アクセス券発行手段は、前記アクセス券の発行が可能であると決定された場合に、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するように構成する。
【００３３】
請求項４に記載の発明によれば、データベースに蓄積されたアクセス券の発行状況（例えば、発行数量）に基づいて、アクセス券発行可否を制御することができるので、より一層サーバへのアクセスを事前に制御することができる。
【００３８】
請求項５に記載の発明は、請求項１乃至４の何れかに記載の分散型アクセス制御システムにおいて、前記アクセス券には、当該アクセス券によりアクセス可能なロードバランサ装置のアドレス情報が含まれているように構成する。
【００３９】
請求項５に記載の発明によれば、アクセス券にロードバランサ装置のアドレス情報（例えば、ＵＲＬ）を設けることで、携帯電子機器端末はかかるアドレス情報に基づいてアクセスすることができる。
【００４０】
請求項６に記載の発明は、請求項４に記載の分散型アクセス制御システムにおいて、前記アクセス券発行可否決定手段は、前記アクセス券の発行量と前記特定のサーバの負荷容量とを比較して、当該比較結果に応じて前記アクセス券の発行可否を決定するように構成する。
【００４２】
また、サーバの増設時においても、携帯電子機器端末側には影響を与えず、均等にアクセスを振り分けることができ、また、１つのサーバがダウンした時も、他のサーバに均等に振り分けることができ、サーバの信頼性を高めることができる。
【００４３】
請求項７に記載の発明は、ネットワーク上における通信制御を行う分散型アクセス制御システムにおける分散型アクセス制御方法であって、携帯電子機器端末から、ネットワーク上で提供されるサービスのリストの要求を、前記ネットワークを介して受け付ける工程と、前記サービスのリストの要求をした前記携帯電子機器端末を利用するユーザのユーザクラスに対応するサービスを、複数のサービスの夫々に対応付けてユーザクラスとアクセス券の発行状況を蓄積するデータベースを備えた装置から提供された情報に基づいて選定して前記サービスのリストを生成し、前記携帯電子機器端末に対して、前記ネットワークを介して提供する工程と、前記携帯電子機器端末から、前記サービスのリストのうちからユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行要求を、前記ネットワークを介して受け付ける工程と、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するアクセス券発行工程と、を備えるように構成する。
【００４４】
請求項７に記載の発明によれば、アクセスのための認証として発行されたアクセス券を取得していない携帯電子機器端末のユーザからの、ロードバランサ装置へのアクセスを自律的に禁止し、ロードバランサ装置により振り分けられるサービス提供を担うサーバへのアクセスを自律的に禁止することができるので、時間的に負荷を効率よく分散、軽減させることができる。
【００４５】
また、サービス用のサーバの増設時においても、携帯電子機器端末側には影響を与えず、均等にアクセスを振り分けることができ、また、１つのサーバがダウンした時も、他のサーバに均等に振り分けることができ、サーバの信頼性を高めることができる。
【００５２】
請求項８に記載の発明は、請求項７に記載の分散型アクセス制御方法において、前記アクセス券には、前記サーバに対するアクセスを制限する有効度数と、有効期間が含まれているように構成する。
【００５３】
請求項８に記載の発明によれば、アクセス券に有効期間（有効期限）、有効度数を設けることにより、サーバにアクセスできる期間や回数を制限することができるので、より一層サーバへのアクセスを事前に制御することができる。
【００５７】
請求項９に記載の発明は、請求項１に記載の分散型アクセス制御システムに対して、ネットワーク上で提供されるサービスのリストを、前記ネットワークを介して要求する携帯電子機器端末であって、前記要求に対して分散型アクセス制御システムから提供されたサービスのリストを、前記ネットワークを介して受け取る手段と、前記受け取ったサービスのリストのうち、ユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行を、前記ネットワークを介して分散型アクセス制御システムに要求する手段と、前記要求に対して分散型アクセス制御システムから発行されたアクセス券を、前記ネットワークを介して受け取る手段と、前記受け取ったアクセス券に基づいて、前記ネットワーク上のロードバランサ装置にアクセスするアクセス手段と、を備えるように構成する。
【００５８】
請求項９に記載の発明によれば、携帯電子機器端末において、ネットワーク上で提供されるサービスのリストが、ネットワークを介して、分散型アクセス制御システムに要求される。そして、要求に対して分散型アクセス制御システムから提供されたサービスのリストが、ネットワークを介して受け取られる。次に、受け取られたサービスのリストのうち、ユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行が、ネットワークを介して分散型アクセス制御システムに要求される。そして、要求に対して分散型アクセス制御システムから発行されたアクセス券が、ネットワークを介して受け取られる。携帯電子機器端末では、ユーザの指示に応じ、受け取ったアクセス券に基づいて、ネットワーク上の特定のロードバランサ装置にアクセスする。
【００５９】
従って、携帯電子機器端末のユーザは、サービスのリストを受け、その後アクセス券を、分散型アクセス制御システムから取得しなければ、ユーザが所望する特定のロードバランサ装置およびこれに接続されるサーバにアクセスすることができない。従って、アクセス券を取得していない携帯電子機器端末からの特定のサーバへのアクセスを自律的に禁止することができる。
【００６０】
請求項１０に記載の発明は、請求項９に記載の携帯電子機器端末において、前記アクセス券には、前記サーバへのアクセス回数を制限する有効度数が含まれており、前記アクセス手段は、前記有効度数に基づいて前記ロードバランサ装置へのアクセスが可能であるか否かを判断し、可能であると判断した場合には、前記ネットワーク上の前記ロードバランサ装置にアクセスするように構成する。
【００６１】
請求項１０に記載の発明によれば、アクセス券に有効度数を設けることにより、アクセス券を使用してロードバランサ装置にアクセスできる回数を制限できるので、より一層サーバへのアクセスを事前に制御することができる。
【００６２】
請求項１１に記載の発明は、請求項１０に記載の携帯電子機器端末において、前記アクセス手段が、前記ロードバランサ装置にアクセスする毎に、前記有効度数を所定数減らすように構成する。
【００６３】
請求項１１に記載の発明によれば、有効度数を携帯電子機器端末で管理することができる。
【００６４】
請求項１２に記載の発明は、請求項９乃至１１の何れかに記載の携帯電子機器端末において、前記アクセス券には、前記ロードバランサ装置へのアクセス期間を制限する有効期間が含まれており、前記アクセス手段は、前記有効期間に基づいて前記ロードバランサ装置へのアクセスが可能であるか否かを判断し、可能であると判断した場合には、前記ネットワーク上の前記ロードバランサ装置にアクセスするように構成する。
【００６５】
請求項１２に記載の発明によれば、アクセス券に有効期間を設けることにより、アクセス券を使用してロードバランサ装置にアクセスできる期間を制限できるので、より一層サーバへのアクセスを事前に制御することができる。
【００６６】
請求項１３に記載の発明は、請求項９乃至１２の何れかに記載する前記アクセス券を有する携帯電子機器端末からの前記ネットワークを介したアクセスを、複数のサーバから構成される所定のサービス提供を担うサーバ群のうち何れかのサーバに対して振り分けるように構成する。
【００６７】
請求項１３に記載の発明によれば、携帯電子機器端末にて取得したアクセス券で指定される特定のロードバランサ装置にアクセスするようにしたので、特定のサーバに同時にアクセスが集中することを避けることができる。また、アクセス券にて、事前に携帯電子機器端末がアクセスするロードバランサ装置を分散させることができるので、ある特定のロードバランサ装置のみに負荷がかかることを避けることができる。よって、時間的に負荷を効率よく分散、軽減させることができる。
【００６８】
【発明の実施の形態】
以下、本発明の好適な実施の形態を添付図面に基づいて説明する。以下の説明は、移動体通信システムに対して本発明を適用した場合の実施形態である。
【００６９】
先ず、本実施形態にかかる移動体通信システムの構成および機能について、図１乃至図３を参照して説明する。図１に、本実施形態にかかる移動体通信システムの構成例を示す。
【００７０】
図１に示すように、本実施形態にかかる移動体通信システム１００は、本発明の携帯電子機器端末としての携帯電話機２ａ乃至２ｃ、ＤＮＳ３、ＡＰＮ４ａ乃至４ｃ、ＢＰＳ５に加え、分散型アクセス制御システム６を含んで構成されている。また、ＤＮＳ３とＡＰＮ５ａ乃至５ｃとＢＰＳ５と分散型アクセス制御システム６とは、ネットワークとしてのインターネット１を介して相互に接続されている。
【００７１】
図２に、携帯電話機２ａ乃至２ｃの概略構成例を示す。図２に示すように、携帯電話機２ａ乃至２ｃは、それぞれ、移動体通信手段（無線基地局、交換局等）を介してインターネット１に接続し各種情報の送受信を行うための通信部２１、ユーザからの操作指令を入力するための操作部２２、各種情報や操作部より入力された操作内容を表示するための表示部２３、ユーザ認証に必要な情報（ＭＳＮ（電話番号）やユーザＩＤなど）、分散型アクセス制御システム６の後述するＩＡ７のＵＲＬ、さらには、本発明の「アクセス券」としての「Ｔｏｋｅｎ」や、Ｔｏｋｅｎ発行に必要な後述するサービスリストなどの情報を記録するクライアント記録部２４、以上の各要素の制御や、サービスリストや各種サービスの提示処理、Ｔｏｋｅｎの更新処理を行うＣＰＵよりなる制御・処理部２５を備えている。また、制御・処理部２５は、本発明のアクセス手段としての機能を有する。なお、図１の例では、便宜上、携帯電話機２ａ乃至２ｃを３台示しているが、実際には、これ以上の数が存在する。
【００７２】
ここで、図1に示す各構成要素の説明の前に、本発明の特徴である「アクセス券」としての「Ｔｏｋｅｎ」について説明する。Ｔｏｋｅｎとは、一言でいうと、ＡＰＮにアクセスしに行くための権利を意味し、ユーザからの要求に対して分散型アクセス制御システム６の後述するＩＡ７により、そのユーザの携帯電話機に対して発行されるものである。このＡＰＮにアクセスしに行くための権利は、金銭のやり取りには直接関わらないが、何かのサービスを受け付けて貰うために必要な権利である「整理券（但し、整理券の順番待ちをしなければならないという性質は除く）」に似ている。
【００７３】
即ち、携帯電話機は、このＴｏｋｅｎを取得して初めて、ＡＰＮにサービスを要求を行うためのアクセスをすることができ、Ｔｏｋｅｎを取得していない携帯電話機は、ＡＰＮにアクセスしにいくことすらできない（アクセスしに行ってから認証の結果で断られるのではなく、断られる事になっていると想定してアクセスしに行かない）ように制御部２５により制御される。
【００７４】
さらに、このＴｏｋｅｎは、かかる「整理券」の性質に加え、複数回利用することができる「回数券」の性質と、定められた期間内は有効である「定期券」の性質と、を含んでおり、ＡＰＮにアクセスしに行くための権利に、アクセスしに行くことができる回数（以下「有効度数」という）と、アクセスしに行くことができる期間（以下「有効期間」という）とが付加されている。より具体的には、携帯電話機は、Ｔｏｋｅｎを持っていても、それを使用する毎に、その有効度数が減っていき有効度数が「０」となった後は、ＡＰＮにアクセスしにいくことができなくなり、また、その有効期間が経過した後は、有効度数が「０」でなくとも、ＡＰＮにアクセスしにいくことができなくなるように制御される。
【００７５】
そして、このＴｏｋｅｎは、サービス毎、即ち、ＡＰＮ毎に対応して存在するものであり、ユーザは、後述する分散型アクセス制御システム６のＩＡ７から提供されるサービスリストのうち、所望するサービスに対応するＴｏｋｅｎを分散型アクセス制御システム６のＩＡ７に要求することができる。これにより、Ｔｏｋｅｎを携帯電話機で取得したユーザのみが、かかるＴｏｋｅｎに対応したＡＰＮにアクセスし、サービスの提供を受けることができる。
【００７６】
かかるＴｏｋｅｎのデータ構成としては、例えば、「アプリケーションサーバのＵＲＬ／有効度数／有効期間」などの情報で構成される。
【００７７】
このように、本通信システム１００にてＴｏｋｅｎという概念を用いることにより、これを取得していない携帯電話機からのＡＰＮへのアクセスを自律的に禁止することができるため、Ｔｏｋｅｎの発行を制御することで、ＡＰＮへのアクセスを事前に制御することができる。
【００７８】
図１の構成要素の説明に戻り、ＤＮＳ３は、従来の移動体通信システム（図１１参照）におけるＤＮＳ１０３と同様、各種サーバのＵＲＬをＩＰアドレスを変換して提供するサーバである。ＡＰＮ４ａ乃至４ｃも、従来の移動体通信システムにおけるＡＰＮ１０４ａ乃至１０４ｃと同様、携帯電話機２ａ乃至２ｃに対し各種サービスを提供するノード群であるが、従来の移動体通信システムのＡＰＮ１０４ａ乃至１０４ｃとは異なり、ＡＰＮ４ａ乃至４ｃには、上述したＴｏｋｅｎを取得している携帯電話機でなければアクセスすることができない。また、従来の移動体通信システムにおけるＡＰＮ１０４ａ乃至１０４ｃとは異なり、加入者ＤＢが設けられていない。これは、ユーザ認証は、後述する分散型アクセス制御システム６のＣＡ８により、Ｔｏｋｅｎ発行前に行なわれるので、ＡＰＮ４ａ乃至４ｃでは、携帯電話機２ａ乃至２ｃにサービスを提供する際のユーザ認証を行なう必要がないからである。なお、図１の例には、サービスＸを行うＡＰＮ４ａ、サービスＹを行うＡＰＮ４ｂ、サービスＺを行うＡＰＮ４ｃが、それぞれ、示されているが、実際には、サービスの種類は、これ以上存在し、かかるサービス毎にＡＰＮが設けられることとなる。
【００７９】
ＢＰＳ５も、従来の移動体通信システムにおけるＢＰＳ１０５と同様、携帯電話機２ａ乃至２ｃのユーザに対して、サービス提供による課金を行うシステムである。
【００８０】
分散型アクセス制御システム６は、図１に示すように、サービス情報提供装置（Information Agent：以下「ＩＡ」という）７と、加入者情報管理装置（Client Administrator：以下「ＣＡ」という）８と、サービス内容管理装置（Service Administrator：以下「ＳＡ」という）９と、を含んで構成される。ＩＡ７、ＣＡ８、ＳＡ９は、それぞれ、ハードウェア資源として、公知のパーソナルコンピュータ、中型、大型コンピュータ、ワークステーションなどのコンピュータからなる。
【００８１】
図３（Ａ）にＩＡ７の概略構成例を示す。図３（Ａ）に示すように、ＩＡ７は、各種情報を記憶する記憶部７１、インターネット１に接続し携帯電話機２ａ乃至２ｃ、ＣＡ８、ＳＡ９と各種情報の送受信を行うための通信部７２、以上の各要素の制御や、後述するサービスリストおよび、上述したＴｏｋｅｎを携帯電話機２ａ乃至２ｃに提供（発行）するための処理を行う制御・処理部７３を備えている。記憶部７１には、サービス情報データベース（ＤＢ）が論理的に構築されており、かかるＤＢには、ＡＰＮ４ａ乃至４ｃから携帯電話機２ａ乃至２ｃに対して提供することが可能なサービス情報が、後述するユーザクラスに対応付けられて蓄積されている。このサービス情報は、ＳＡ９からインターネット１を介して定期的に送信される。制御・処理部７３は、本発明のアクセス券発行手段としての機能を有する。
【００８２】
このＩＡ７は、分散型アクセス制御システム６のうち、携帯電話機２ａ乃至２ｃが唯一アクセスすることが可能な装置であり、携帯電話機２ａ乃至２ｃに対する受付窓口としての役割を担っている。ＩＡ７の制御・処理部７３は、携帯電話機２ａ乃至２ｃからのサービスリストの要求を受付け、後述するＣＡ８からのサービスリスト提供可否や、ユーザ情報（後述するユーザクラス）に基づいて携帯電話機２ａ乃至２ｃのそれぞれに提供可能なサービスを選定し、サービスリストを生成して、これを、通信部７２およびインターネット１等を介して、携帯電話機２ａ乃至２ｃに提供する。
【００８３】
また、ＩＡ７の制御・処理部７３は、携帯電話機２ａ乃至２ｃからのサービスリストに基づくＴｏｋｅｎの要求を受付け、これに伴なってＳＡ９にて生成された要求サービスに対応するＴｏｋｅｎを、通信部７２およびインターネット１等を介して、携帯電話機２ａ乃至２ｃに提供する。
【００８４】
図３（Ｂ）にＣＡ８の概略構成例を示す。図３（Ｂ）に示すように、ＣＡ８は、各種情報を記憶する記憶部８１、インターネット１に接続しＢＰＳ５、ＩＡ７、ＳＡ９と各種情報の送受信を行うための通信部８２、以上の各要素の制御や、ユーザ情報の登録・更新・削除、ユーザ認証、Ｔｏｋｅｎの有効度数、有効期間の決定、ユーザ毎のＴｏｋｅｎ取得状況の記録などの処理を行う制御・処理部８３を備えている。また、制御・処理部８３は、本発明のユーザ認証手段としての機能を有する。記憶部８１には、加入者情報ＤＢが論理的に構築されており、かかるＤＢには、移動体通信事業者の店舗や代理店などで、携帯電話利用契約を行った加入者（ユーザ）情報、例えば、ユーザ毎に付与されるユーザＩＤに対応付けて、携帯電話機の電話番号（ＭＳＮ）、ユーザの住所、氏名、どのサービスを利用するかを示すユーザクラス（ユーザの指定より設定）、Ｔｏｋｅｎについての特別取極、Ｔｏｋｅｎ取得状況、課金情報などの情報が蓄積されている。
【００８５】
ここで、Ｔｏｋｅｎについての特別取極とは、ユーザと分散型アクセス制御システム６の運営者との間の特別の取極めである。例えば、Ｔｏｋｅｎは、上述したように、整理券としての性質を有するため、それ自体を提供することで、原則として、課金はせず、一律に有効度数、有効期間を設定するものであるが、例外として、ユーザからの要求に応じて有効度数を通常のものより高く設定したり、有効期間を通常のものより長く設定したりする特別の取極めを行うこともできる。かかる場合、通常よりも高く、或いは長く設定した分の料金を、基本料金に上乗せる等を行うようにしてもよい。
【００８６】
また、特別待遇用Ｔｏｋｅｎを発行するか否かの特別の取極めも行うことができる。ＡＰＮ内に複数のアプリケーションサーバが設けられている場合、後述するＳＡ９において、アクセス配分を予め制御するよう、ＴｏｋｅｎにおけるＵＲＬを分散するように設定することができるが、特別待遇用Ｔｏｋｅｎにてアクセス可能なアプリケーションサーバに対しては、通常のＴｏｋｅｎにてアクセス可能なアプリケーションサーバよりも負荷を軽くするように設定する。これにより、特別待遇用Ｔｏｋｅｎを取得しているユーザは、通常のＴｏｋｅｎを取得しているユーザよりも、アクセス時間が早くなる。かかる場合も、通常よりも高く、或いは長く設定した分の料金を、基本料金に上乗せる等を行うようにしてもよい。
【００８７】
以上のようなユーザ情報は、ＢＰＳ１０５の加入者ＤＢに最初に登録された後、ＣＡ８の加入者情報ＤＢに登録するようにしても、ＣＡ８の加入者情報ＤＢに最初に登録するようにしても構わない。
【００８８】
ＣＡ８の制御・処理部８３は、携帯電話機２ａ乃至２ｃからのサービスリストの要求がＩＡ７にあった際のＩＡ７からの通知に応じ、加入者情報ＤＢのユーザ情報に基づいて、ユーザ認証、即ち、携帯電話機２ａ乃至２ｃのユーザ、例えば、ＭＳＮが、加入者情報ＤＢに登録されているか否かを判断するとともに、そのユーザの課金情報からユーザに対してサービスを提供しても良いかどうかを判断し、その結果（サービスリスト提供可否）をインターネット１を介してＩＡ７に通知する。
【００８９】
また、ＣＡ８の制御・処理部８３は、携帯電話機２ａ乃至２ｃからのサービスリストに基づくＴｏｋｅｎの要求がＩＡ７にあった際のＩＡ７からの通知に応じ、特別の取極めがあれば、その情報とともに、Ｔｏｋｅｎの要求があった旨の情報をインターネット１を介してＳＡ９に通知する。さらに、ＣＡ８の制御・処理部８３は、ＳＡ９にて生成されたＴｏｋｅｎを、一旦受けて、対応するユーザのユーザ情報に対応付けてＴｏｋｅｎ取得状況を加入者情報ＤＢに記録した後、かかるＴｏｋｅｎをＩＡ７に提供する。そして、このＴｏｋｅｎは、上述したように、ＩＡ７から携帯電話機に対して、発行されることとなる。
【００９０】
即ち、このＴｏｋｅｎ発行は、サービスリストの提供を経た後に行なわれるものであって、このサービスリストの提供は、ＣＡ７におけるユーザ認証等の判断結果、サービス提供可能であった場合に行なわれる。そして、携帯電話機２ａ乃至２ｃのユーザは、Ｔｏｋｅｎが無ければ、ＡＰＮ４ａ乃至４ｃに対してアクセスすることすらできないので、ＡＰＮ４ａ乃至４ｃ側でサービス提供時にユーザ認証を行う必要がなくなる。
【００９１】
従って、ＡＰＮ４ａ乃至４ｃにおける加入者ＤＢを削減することができ、ひいては、加入者ＤＢ内の情報の整合性がとれないという問題点を解消することができる。また、各ＡＰＮ４ａ乃至４ｃにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【００９２】
図３（Ｃ）にＳＡ９の概略構成例示す。図３（Ｃ）に示すように、ＳＡ９は、各種情報を記憶する記憶部９１、インターネット１に接続しＡＰＮ４ａ乃至４ｃ、ＣＡ８、ＳＡ９と各種情報の送受信を行うための通信部９２、以上の各要素の制御や、Ｔｏｋｅｎの生成、サービス内容の登録・更新・削除などの処理を行う制御・処理部９３を備えている。
【００９３】
記憶部９１には、サービス内容ＤＢが論理的に構築されており、かかるＤＢには、ＡＰＮ４ａ乃至４ｃのそれぞれにおいて提供されるサービス内容、即ち、サービスに関する詳細内容がサービスＩＤに対応付けて蓄積されている。かかるサービス内容は、例えば、ＡＰＮ４ａ乃至４ｃにおいてサービス内容が追加、変更された際、ＡＰＮ４ａ乃至４ｃからインターネット１を介して送信されたり、新たなＡＰＮが設けれた際に、そのＡＰＮからインターネット１を介して送信される。また、各ＡＰＮで提供されるサービス内容には、上述したユーザクラスが設定されている。さらに、サービス内容ＤＢには、ＡＰＮ毎に対応付けてＴｏｋｅｎ発行状況（Ｔｏｋｅｎ発行数）が蓄積されている。また、制御・処理部９３は、本発明のアクセス券発行可否決定手段としての機能を有する。
【００９４】
ＳＡ９の制御・処理部９３は、携帯電話機２ａ乃至２ｃからのＴｏｋｅｎの要求がＩＡ７にあった際のＣＡ８からの通知に応じ、先ず、発行要求があったＴｏｋｅｎに対応するＡＰＮのＴｏｋｅｎ発行状況から、Ｔｏｋｅｎを発行すべきか否かを決定する。これにより、携帯電話機のＡＰＮに対するアクセスを制御することができるので、例えば、同じ時間帯に、多くのアクセスが集中した場合にも、ＡＰＮにて十分に対応することが可能となる。
【００９５】
そして、ＳＡ９の制御・処理部９３は、Ｔｏｋｅｎを発行を決定した場合には、特別の取極めがあれば、その情報に基づいて、Ｔｏｋｅｎ（サーバのＵＲＬ／有効度数／有効期限）を生成し、それをインターネット１を介してＣＡ８に提供する。
【００９６】
ＡＰＮが複数のアプリケーションサーバから構成されている場合には、ＳＡ９の制御・処理部９３は、その都度、ＴｏｋｅｎにおけるＵＲＬを、それぞれのサーバに分散するように設定する。これにより、Ｔｏｋｅｎを取得した携帯電話機は、毎回特定のアプリケーションサーバにアクセスを試行することとなる。この事は、ＡＰＮに対する携帯電話機のアクセス配分を予め制御することができることを意味し、これにより、負荷分散を行うことができるので、同じ時間帯に、一つのアプリケーションサーバにアクセスが集中することを回避することができる。
【００９７】
なお、上述したように、特別の取極にて、特別待遇用Ｔｏｋｅｎを生成する場合には、ＴｏｋｅｎにおけるＵＲＬを特別のＵＲＬとして設定する。
【００９８】
また、ＳＡ９の制御・処理部９３は、サービス内容ＤＢにＡＰＮのサービス内容の新規登録、追加、変更があった場合には、その情報（サービスリスト生成のための情報）をインターネット１を介してＩＡ７に送信する。
【００９９】
次に、以上の本実施形態にかかる移動体通信システム１００における動作について、図４乃至図１０を参照して説明する。
【０１００】
図４に、携帯電話機２ａ乃至２ｃに対するサービスリスト提供時の本システム１００における模式図を、図５に、携帯電話機２ａ乃至２ｃに対するサービスリスト提供時の本システム１００における処理の流れ（フロー）を、それぞれ示す。
【０１０１】
先ず、携帯電話機の制御・処理部２５は、ユーザからの操作部２２を介した指示に応じて、移動体通信手段を介して、クライアント記録部２４に予め登録された分散型アクセス制御システム６のＩＡ７のＵＲＬを指定して、ＩＡ７とのインターネット１での接続を確立し、サービスリストを要求する（ステップＳ１）。図４の例では、３台の携帯電話機２ａ乃至２ｃが、それぞれ、ＩＡ７に対し、サービスリストを要求しているようすを示している。なお、携帯電話機２ａ乃至２ｃとＩＡ７との接続は、上述したように、ＤＮＳ３にて、ＵＲＬからＩＰアドレスに変換されることにより行なわれるが、かかるステップについては、以下の説明でも省略する。
【０１０２】
次に、ＩＡ７の制御・処理部７３は、かかるサービスリストの要求に応じ、ＣＡ８に対してユーザ認証等をインターネット２を介して要求する（ステップＳ２）。この際、当該携帯電話機２ａ乃至２ｃのＭＳＮが、ＣＡ８に対して通知されることとなる。続いて、ＣＡ８の制御・処理部８３は、かかるユーザ認証等の要求に応じ、サービスリストを要求した携帯電話機のＭＳＮが加入者情報ＤＢに登録されているか否かを判断し（ステップＳ３）、登録されている場合には、その携帯電話機のユーザの課金情報からユーザに対してサービスを提供しても良いかどうかを判断する（ステップＳ４）。
【０１０３】
そして、ＣＡ８の制御・処理部８３は、サービスを提供しても良いと判断した場合には、その旨および、加入者情報ＤＢに登録されたその携帯電話機に対応するユーザクラスを、インターネット３を介してＩＡ７に通知する（ステップＳ５）。
【０１０４】
例えば、加入者情報ＤＢには、図４の符号４０１部に示すように、ＭＳＮがＡである携帯電話機２ａのサービスクラスは”１”、ＭＳＮがＢである携帯電話機２ｂのサービスクラスも”１”、ＭＳＮがＣである携帯電話機２ｃのサービスクラスもは”２”、としてそれぞれ登録されており、このような情報をＩＡ７に通知するのである。
【０１０５】
一方、ＣＡ８の制御・処理部８３は、上記ステップＳ４にて、携帯電話機のＭＳＮが登録されていないと判断した場合や、ステップＳ５において、サービスを提供しても良くない判断した場合、例えば、ユーザが通話料、サービス料等の支払いを延滞していた場合には、サービス提供は行わない旨をＩＡ７に通知する。
【０１０６】
ＩＡ７の制御・処理部８３は、かかる通知に応じ、サービスの提供に問題ないと判断した場合には、携帯電話機のユーザクラスに対応する提供可能サービスを、上述したように、ＳＡ９から提供された情報に基づいて選定し、サービスリストを生成して、インターネット１を介して対応する携帯電話機に提供する（ステップＳ７）。
【０１０７】
例えば、図４の符号４０２部に示すように、ユーザクラス”１”に対して提供可能なサービスは、サービスＸ、Ｙ、Ｚであり、ユーザクラス”２”に対して提供可能なサービスは、サービスＸ、Ｙである。従って、携帯電話機２ａおよび２ｂに対しては、ユーザクラスが”１”であることより、サービスＸ、Ｙ、Ｚのサービスリストを提供することとなる。また、携帯電話機２ｃに対しては、ユーザクラスが”２”であることより、サービスＸ、Ｙのサービスリストを提供することとなる。
【０１０８】
このように、Ｔｏｋｅｎ発行前のサービスリスト提供時において、ユーザ認証を行うようにしたので、ＡＰＮ４ａ乃至４ｃにおけるサービス提供時には、ユーザ認証を行う必要がなく、従って、ＡＰＮ４ａ乃至４ｃにおける加入者ＤＢを削減することができ、ひいては、加入者ＤＢ内の情報の整合性がとれないという問題点を解消することができる。また、各ＡＰＮ４ａ乃至４ｃにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【０１０９】
一方、ＩＡ７の制御・処理部８３は、かかる通知に応答し、サービスの提供に問題があると判断した場合には、サービス提供ができない旨を、携帯電話機に送信することとなる。
【０１１０】
そして、各携帯電話機２ａ乃至２ｃでは、提供されたサービスリストをクライアント記録部２４に記憶する（ステップＳ８）とともに、表示部２３に表示する。こうして、各携帯電話機２ａ乃至２ｃのユーザは、表示部２３に表示されたサービスリストから、所望のＴｏｋｅｎを要求するための操作を操作部２２にて行うこととなる。
【０１１１】
図６に、携帯電話機２ａ乃至２ｃに対するＴｏｋｅｎ提供時の本システム１００における模式図を、図７に、携帯電話機２ａ乃至２ｃに対するＴｏｋｅｎ提供時の本システム１００における処理の流れ（フロー）を、それぞれ示す。
【０１１２】
先ず、携帯電話機の制御・処理部２５は、ユーザからの操作部２２を介したＴｏｋｅｎ選択指示に応じて、インターネット１を介して、Ｔｏｋｅｎを要求する（ステップＳ１１）。図６の例では、携帯電話機２ａは、サービスリストの中に表示されたサービスＸ、Ｙ、Ｚの全てを要求しており、携帯電話機２ｂは、サービスリストの中に表示されたサービスＸ、Ｙ、Ｚのうち、サービスＸ、Ｚを要求しており、携帯電話機２ｃは、サービスリストの中に表示されたサービスＸ、Ｙの全てを要求している。かかる要求には、要求対象のサービスに対応するサービスＩＤが含まれる。
【０１１３】
次に、ＩＡ７の制御・処理部７３は、かかるＴｏｋｅｎの要求に応じ、ＣＡ８に対して、その旨およびサービスＩＤを、それを要求した携帯電話機のＭＳＮに対応付けてインターネット１を介して通知する（ステップＳ１２）。続いて、ＣＡ８の制御・処理部８３は、かかる通知に応じ、加入者ＤＢを参照して、特別の取極があるか否か判断し（ステップＳ１３）、ある場合には、その情報とともに、サービスＩＤ、ＭＳＮとともにインターネット１を介してＳＡ９に通知する（ステップＳ１４）。
【０１１４】
ＳＡ９の制御・処理部９３は、かかる通知に応じ、先ず、サービス内容ＤＢを参照して、発行要求があった（サービスＩＤに対応する）Ｔｏｋｅｎに対応するＡＰＮのＴｏｋｅｎ発行状況から、Ｔｏｋｅｎを発行すべきか否かを決定する（ステップＳ１５）。例えば、発行要求があった（サービスＩＤに対応する）ＴｏｋｅｎにＡＰＮのＴｏｋｅｎ発行状況から、Ｔｏｋｅｎ発行量とそのＡＰＮの負荷容量とを比較して、問題が無ければ、Ｔｏｋｅｎの発行を決定する。
【０１１５】
これにより、携帯電話機のＡＰＮに対するアクセスを制御することができるので、例えば、同じ時間帯に、多くのアクセスが集中した場合にも、ＡＰＮにて十分に対応することが可能となる。
【０１１６】
そして、ＳＡ９の制御・処理部９３は、Ｔｏｋｅｎを発行を決定した場合には、Ｔｏｋｅｎを生成する（ステップＳ１６）。ここで、特別の取極めがある場合には、その情報に基づいて、Ｔｏｋｅｎを生成する。続いて、ＳＡ９の制御・処理部９３は、そのＴｏｋｅｎに対応するサービス（サービスＩＤ）のＴｏｋｅｎ発行状況を更新する（ステップＳ１７）。ここで、上述したように、ＡＰＮが複数のアプリケーションサーバから構成されている場合には、ＳＡ９の制御・処理部９３は、ＴｏｋｅｎにおけるＵＲＬを、それぞれのサーバに分散するように設定する。これにより、負荷分散を行うことができるので、同じ時間帯に、一つのアプリケーションサーバにアクセスが集中することを回避することができる。
【０１１７】
また、上述したように、特別の取極に基づいて、特別待遇用Ｔｏｋｅｎを生成する場合には、ＳＡ９の制御・処理部９３は、ＴｏｋｅｎにおけるＵＲＬを特別のＵＲＬとして設定する。これにより、特別待遇用Ｔｏｋｅｎを取得しているユーザは、通常のＴｏｋｅｎを取得しているユーザよりも、アクセス時間が早くなる。
【０１１８】
そして、ＳＡ９の制御・処理部９３は、かかるＴｏｋｅｎを、ＭＳＮとともにインターネット１を介してＣＡ８に提供する（ステップＳ１８）。
【０１１９】
続いて、ＣＡ８の制御・処理部８３は、かかるＴｏｋｅｎ等を受け取り、加入者ＤＢを参照して、そのＴｏｋｅｎを要求したユーザのＴｏｋｅｎ取得状況を更新し（ステップＳ１９）後、かかるＴｏｋｅｎ等をインターネット１を介してＩＡ８に提供する（ステップＳ２０）。
【０１２０】
そして、ＩＡ７の制御・処理部７３は、かかるＴｏｋｅｎ等を受け取り、それを要求した携帯電話機に対して、インターネット１を介して発行（送信）する（ステップＳ２１）。
【０１２１】
一方、上記ステップＳ１５にて、ＳＡ９の制御・処理部９３が、Ｔｏｋｅｎを発行しないと決定した場合には、ＩＡ７の制御・処理部７３は、ＣＡ８を介して、その旨の情報を受け取り、それをインターネット１を介して携帯電話機に通知することとなる。
【０１２２】
そして、各携帯電話機２ａ乃至２ｃでは、発行されたＴｏｋｅｎを受け取り、クライアント記録部２４に記憶する（ステップＳ２２）。こうして、各携帯電話機２ａ乃至２ｃのユーザは、取得したＴｏｋｅｎに基づいて、ＡＰＮ４ａ乃至４ｃに対してアクセスすることが可能となる。
【０１２３】
図８および図９に、携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における模式図を、図１０に、携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における処理の流れ（フロー）を、それぞれ示す。
【０１２４】
図８の例では、以上の手続きにより、携帯電話機２ａは、Ｔｏｋｅｎ（Ｘ）、Ｔｏｋｅｎ（Ｙ）、Ｔｏｋｅｎ（Ｚ）を取得しており、携帯電話機２ｂは、Ｔｏｋｅｎ（Ｘ）、Ｔｏｋｅｎ（Ｚ）を取得しており、携帯電話機２ｃは、Ｔｏｋｅｎ（Ｘ）、Ｔｏｋｅｎ（Ｙ）を取得しており、これらのＴｏｋｅｎは、ユーザが操作部２２からの予定の指示に基づいて、表示部２３に表示される。
【０１２５】
そして、ユーザが、アクセスしたいＡＰＮに対応するＴｏｋｅｎを操作部２２から指定すると、携帯電話機の制御・処理部２５は、かかるＴｏｋｅｎに含まれる有効度数、有効期間からアクセス可能か否かを判断する（ステップＳ３１）。携帯電話機の制御・処理部２５は、アクセス可能であると判断した場合には、Ｔｏｋｅｎに含まれるＵＲＬに基づいて、ＡＰＮの特定のアプリケーションサーバに移動体通信手段およびインターネット１を介して、アクセスを試行する（ステップＳ３２）。
【０１２６】
図８に示すように、Ｔｏｋｅｎ（Ｘ）を取得している携帯電話機２ａ乃至２ｃは、それぞれ、ＡＰＮ４ａにアクセスすることができ、Ｔｏｋｅｎ（Ｙ）を取得している携帯電話機２ａおよび２ｃは、それぞれ、ＡＰＮ４ｂにアクセスすることができ、Ｔｏｋｅｎ（Ｚ）を取得している携帯電話機２ａおよび２ｂは、それぞれ、ＡＰＮ４ｃにアクセスすることができる。
【０１２７】
また、図９の例では、ＡＰＮ４ａが複数のアプリケーションサーバから構成されている場合を示しているが、この例では、携帯電話機２ａ乃至２ｃのそれぞれに発行されたサービスＸのＴｏｋｅｎにおけるＵＲＬが分散するように設定されているので、携帯電話機２ａ乃至２ｃは、それぞれ、特定のアプリケーションサーバにアクセスすることとなる。
【０１２８】
即ち、携帯電話機２ａは、Ｔｏｋｅｎ（Ｘ１）に基づき、ＡＰＮ４ａ内のアプリケーションサーバ（ＡＰＳ）１に、携帯電話機２ｂは、Ｔｏｋｅｎ（Ｘ２）に基づき、ＡＰＮ４ａ内のアプリケーションサーバ（ＡＰＳ）２に、携帯電話機２ｃは、Ｔｏｋｅｎ（Ｘ３）に基づき、ＡＰＮ４ａ内のアプリケーションサーバ（ＡＰＳ）３に、それぞれ、アクセスすることとなる。これにより、負荷分散を行うことができるので、同じ時間帯に、一つのアプリケーションサーバにアクセスが集中することを回避することができる。
【０１２９】
一方、上記ステップＳ３１で、携帯電話機の制御・処理部２５は、アクセス不可であると判断した場合、例えば、有効期間が既に経過していた場合や、有効度数が「０」であった場合には、アクセス試行は行わない。
【０１３０】
こうして、携帯電話機がＡＰＮとのインターネット上での接続を確立すると、携帯電話機とＡＰＮとの間で、サービスの提供と利用が行なわれる（ステップＳ２２）こととなる。また、携帯電話機がＡＰＮとのインターネット上での接続の確立により、携帯電話機の制御・処理部２５は、Ｔｏｋｅｎにおける有効度数を１つ減らし更新する（ステップＳ３３）。
【０１３１】
なお、かかる有効度数は、携帯電話機の制御・処理部２５により、ＡＰＮへのアクセスを行う度に減算されるものであり、例えば、現在、有効度数が「１０」であるとすると、ＡＰＮのアクセスは、１０回行うことができる。また、かかる有効度数が「０」となる前、或いは、「０」となった時点で、携帯電話機の制御・処理部２５が、自動的に、分散型アクセス制御システム６のＩＡ７にアクセスし、かかるＴｏｋｅｎの更新（有効度数を増やす更新）を行うようにしてもよい。この事は、Ｔｏｋｅｎの有効期限についても同様で、有効期限が到来する数日前、或いは、有効期限が到来した際、携帯電話機の制御・処理部２５が、自動的に、分散型アクセス制御システム６のＩＡ７にアクセスし、かかるＴｏｋｅｎの更新（有効期限を延ばす更新）を行うようにしてもよい。
【０１３２】
そして、ＡＰＮでは、サービス提供に基づく上述したＣＤＲを生成する（ステップＳ３４）。ＢＰＳ５は、インターネット１を介して、かかるＣＤＲを収集し（ステップＳ３５）、当該ユーザに対する課金処理を行う（ステップＳ３６）。そして、ＢＰＳ５は、インターネット１を介して、分散型アクセス制御システム６のＣＡ８に対して、当該ユーザのＭＳＮに対応付けて課金情報を提供する（ステップＳ３７）。そして、分散型アクセス制御システム６のＣＡ８では、加入者情報ＤＢ内のかかるユーザに対応する課金情報を更新する（ステップＳ３８）。
【０１３３】
以上説明したように本実施形態によれば、Ｔｏｋｅｎという概念を用いることにより、これを取得していない携帯電話機からのＡＰＮへのアクセスを自律的に禁止することができるようにしたので、Ｔｏｋｅｎの発行を制御することで、ＡＰＮへのアクセスを事前に制御することができる。よって、時間的に負荷を効率よく分散、軽減させることができる。
【０１３４】
また、ＡＰＮに対応するＴｏｋｅｎ発行状況に基づいて、Ｔｏｋｅｎ発行可否を制御することができるので、さらにＡＰＮへのアクセスを事前に制御することができ、例えば、同じ時間帯に、多くのアクセスが集中した場合にも、ＡＰＮにて十分に対応することが可能となる。
【０１３５】
また、ＡＰＮが複数のアプリケーションサーバから構成されている場合に、ＴｏｋｅｎにおけるＵＲＬを、それぞれのサーバに分散するように設定することができるので、ＡＰＮへの負荷分散を制御することができ、同じ時間帯に、一つのアプリケーションサーバにアクセスが集中することを回避することができる。
【０１３６】
また、Ｔｏｋｅｎという概念を用いることで、サービス提供にかかるユーザ認証を、一個所で行うことができるので、各ＡＰＮにおけるサービス提供時に、ユーザ認証を行う必要がなくなり、その結果、各ＡＰＮおける加入者ＤＢを削減することができ、ひいては、加入者ＤＢ内の情報の整合性がとれないという問題点を解消することができる。また、各ＡＰＮにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【０１３７】
次に、上記実施形態において、ＡＰＮが複数のアプリケーションサーバから構成されている場合には、ＳＡ９の制御・処理部９３は、ＴｏｋｅｎにおけるＵＲＬを、それぞれのサーバに分散するように設定するように構成したが、さらに効果的な負荷分散の手法として、ロードバランサ（負荷平衡）装置を用いる構成について、図１１乃至図１３を参照して説明する。
【０１３８】
図１１は、ＡＰＮ４ａ乃至４ｃのそれぞれ対して、負荷のバランスを図るためのロードバランサ群１５ａ乃至１５ｃを設けた場合の移動体通信システムの構成例を示す図である。ロードバランサ群１５ａ乃至１５ｃのそれぞれには、複数のロードバランサ装置が設けられており、かかるロードバランサ装置は、ＡＰＮ内の複数のアプリケーションサーバへの携帯電話機からのアクセスを振り分ける機能を有する。
【０１３９】
なお、以下の図１１に示す移動体通信システム２００の説明において、上記図１に示す移動体通信制御システム１００と同様の構成、機能部分の説明は省略する。
【０１４０】
図１１に示す移動体通信システム２００の構成においても、上記図５を参照して説明したサービスリスト提供時における処理の流れ、および上記図７を参照して説明したＴｏｋｅｎ提供時における処理の流れは同様であるが、図７に示すステップＳ１６において、ＳＡ９の制御・処理部９３が生成するＴｏｋｅｎのデータ構成が異なる。
【０１４１】
即ち、上記図１に示す移動体通信制御システム１００においては、Ｔｏｋｅｎのデータ構成を「アプリケーションサーバのＵＲＬ／有効度数／有効期間」としたが、移動体通信システム２００において、ＳＡ９の制御・処理部９３により生成されるＴｏｋｅｎのデータ構成は、「ロードバランサ装置のＵＲＬ／有効度数／有効期間」とする。このロードバランサ装置のＵＲＬは、上記にて説明したアプリケーションサーバのＵＲＬと同様に、ＤＮＳ３にＩＰアドレス（以下「論理アドレス」という）に対応させて予め登録される。
【０１４２】
図１２に、携帯電話機２ａ乃至２ｈに対する各種サービス提供時の本システム２００における模式図を、図１３に、携帯電話機２ａ乃至２ｈに対する各種サービス提供時の本システム２００における処理の流れを、それぞれ示す。なお、図１３において、図１０のステップＳ３４からステップＳ３８に相当する流れは、省略している。
【０１４３】
図１２の例では、ロードバランサ群１５ａには、３台のロードバランサ装置が設けられており、それぞれのロードバランサ装置には、２つの受け口が設けられている。各受け口と論理アドレスは、１対１に対応付けられている。なお、かかる受け口は、２つとは限らずいくつであってもよい。
【０１４４】
携帯電話機が、上記図７における手続きにより、Ｔｏｋｅｎを受け取ると、携帯電話機は、かかるＴｏｋｅｎに含まれるＵＲＬを論理アドレスに変換する要求をＤＮＳ３に対して行う。ＤＮＳ３によりＴｏｋｅｎに含まれるロードバランサ装置のＵＲＬが論理アドレスに変換された後、携帯電話機は、これに基づいて、ロードバランサ装置の特定の受け口にアクセスする（ステップＳ５１）。
【０１４５】
例えば、図１２に示すように、携帯電話機２ａはロードバランサ装置１のＬ.A.1に、携帯電話機２ｂはロードバランサ装置１のＬ.A.2に、携帯電話機２ｃはロードバランサ装置２のＬ.A.2に、それぞれアクセスする。即ち、この段階で、先ず、静的に携帯電話機のロードバランサへの割付が行なわれるのである。
【０１４６】
そして、図１２の例では、ロードバランサ装置１にアクセスしてきた携帯電話機２ａ、２ｂ、２ｄを、ＡＰＮ４ａ内の実ＩＰアドレスのアプリケーションサーバ（ＡＰＳ）１乃至３の何れかに自動的に振り分ける（ステップＳ５２）。ロードバランサ装置２および３でも同様に、携帯電話機からのアクセスを動的にＡＰＳに振り分けることとなる。かかる振り分けは、ロードバランサ装置が、その時点で、アクセスされていないＡＰＳを選定して行うものである。これにより、携帯電話機とアプリケーションサーバとのインターネット１上における接続が確立し、サービスの提供と利用が行なわれることとなる（ステップＳ５３）。
【０１４７】
このように、図１１に示す移動体通信システム２００に示す実施形態によれば、ＡＰＮ毎にロードバランサ群を設けるように構成し、携帯電話機にて取得したＴｏｋｅｎで指定される特定のロードバランサ装置にアクセスするようにしたので、ＡＰＮ内のある特定のアプリケーションサーバ（ＡＰＳ）に同時にアクセスが集中することを避けることができる。また、Ｔｏｋｅｎにて、事前に携帯電話機がアクセスするロードバランサ装置を分散させることができるので、ある特定のロードバランサ装置のみに負荷がかかることを避けることができる。よって、時間的に負荷を効率よく分散、軽減させることができる。また、ロードバランサ装置の増設や収容替えをユーザのインパクトが少なく実施することができる。
【０１４８】
また、ロードバランサ装置により、アプリケーションサーバの増設や収容替え時においても、携帯電話機側には影響を与えず、均等にアクセスを振り分けることができ、また、１つのアプリケーションサーバがダウンした時も、他のアプリケーションサーバに均等に振り分けることができ、アプリケーションサーバの信頼性および本システム２００の信頼性を高めることができる。
【０１４９】
なお、図１１に示す移動体通信システム２００に示す実施形態の場合も、特別待遇Ｔｏｋｅｎがあり、この場合の特別待遇Ｔｏｋｅｎに含まれるＵＲＬは、最も信頼性の高いロードバランサ装置のＵＲＬとする。即ち、携帯電話機からアプリケーションサーバまでのアクセスルートを、ユーザ毎に異なるように負荷分散することができるので、例えば、特別待遇Ｔｏｋｅｎを取得したユーザに対しては、信頼性の高いサーバへ、通常のＴｏｋｅｎを取得したユーザに対しては、信頼性のあまり高くないサーバへ振り分けるなど、ユニークな負荷分散を行うことができる。
【０１５０】
なお、上記実施形態において、分散型アクセス制御システム６のＣＡ８にも、ＢＰＳ５が備える加入者ＤＢと同様のものを備えているので、ＢＰＳ５が行うＣＤＲ収集、課金処理などの役割の全部または一部を、分散型アクセス制御システム６のＣＡ８が行うように構成してもよい。このような構成にすれば、ＢＰＳ５の負担を低減させることができる。
【０１５１】
また、上記実施形態において、Ｔｏｋｅｎ発行は、ユーザによるサービスリストからの選択を経て行うように構成したが、これに限定されるものではなく、例えば、ユーザが、分散型アクセス制御システム６のオペレータに電話をし、口頭で所望のサービスのＴｏｋｅｎを携帯電話機に対して発行するように依頼することにより、かかる携帯電話機にＴｏｋｅｎを発行するように構成してもよい。このような構成においても、上記実施形態の構成と同等の効果を得ることができる。
【０１５２】
また、上記実施形態において、ＣＡ８によるユーザ認証は、サービスリスト提供時に１回行うように構成したが、これに代えて、サービスリスト提供時にユーザ認証を行わずに、サービスリストを携帯電話機に提供し、Ｔｏｋｅｎ発行要求があった際に、かかるユーザ認証を行うように構成してもよい。このような構成でも、加入者ＤＢは、ＡＰＮに設置する必要はないので、上記実施形態の構成と同等の効果を得ることができる。
【０１５３】
また、本実施形態において分散型アクセス制御システム６におけるＩＡ７とＣＡ８とＳＡ９とは、インターネット１を介して相互に接続されるように構成したが、これに限定されず、例えば、ＩＡ７とＣＡ８とＳＡ９をＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、ＧＡＮ（Global Area Network）などのネットワークおよびＨＵＢを介して相互に接続し、ＩＡ７のみがインターネット１に接続されるように構成してもよい。かかる場合には、ＣＡ８とＢＰＳ５間の通信や、ＳＡ９とＡＰＮ４ａ乃至４ｃ間の通信は、ＩＡ７を介して行なわれることとなる。
【０１５４】
また、上記実施形態において、Ｔｏｋｅｎには、ＵＲＬと有効期間と有効期限などからなることを説明したが、このような形式に限定されず、例えば、Ｔｏｋｅｎは、有効期間と有効期限から構成されるようにし、Ｔｏｋｅｎ発行の際、これに特定のロードバランサ装置のＵＲＬが添付されるように構成してもよい。
【０１５５】
【発明の効果】
以上で説明したように、本発明によれば、ネットワーク上の特定のロードバランサ装置にアクセスするためのアクセス券としてのＴｏｋｅｎという概念を用いることにより、これを取得していない携帯電子機器端末からのロードバランサ装置およびこれに接続されるサーバへのアクセスを自律的に禁止することができるので、Ｔｏｋｅｎの発行を制御することで、サーバへのアクセスを事前に制御することができる。よって、時間的に負荷を効率よく分散、軽減させることができる。
【０１５６】
また、ロードバランサ装置に対応するＴｏｋｅｎ発行状況に基づいて、Ｔｏｋｅｎ発行可否を制御することができるので、さらにロードバランサ装置へのアクセスを事前に制御することができ、例えば、同じ時間帯に、多くのアクセスが集中した場合にも、ロードバランサ装置およびサーバにて十分に対応することが可能となる。
【０１５７】
また、Ｔｏｋｅｎという概念を用いることで、サービス提供にかかるユーザ認証を、一個所で行うことができるので、各サーバにおけるサービス提供時に、ユーザ認証を行う必要がなくなり、その結果、各サーバおけるユーザ情報に関するデータベースを削減することができ、ひいては、かかるデータベース内の情報の整合性がとれないという問題点を解消することができる。また、各サーバにおけるユーザ認証に伴うＣＰＵおよび通信設備の労費、無駄なトラフィックを軽減することができる。
【０１５８】
また、携帯電子機器端末にて取得したＴｏｋｅｎで指定される特定のロードバランサ装置にアクセスするようにしたので、特定のサーバに同時にアクセスが集中することを避けることができる。また、Ｔｏｋｅｎにて、事前に携帯電子機器端末がアクセスするロードバランサ装置を分散させることができるので、ある特定のロードバランサ装置のみに負荷がかかることを避けることができる。よって、時間的に負荷を効率よく分散、軽減させることができる。また、ロードバランサ装置の増設や収容替えをユーザのインパクトが少なく実施することができる。
【０１５９】
また、サーバの増設時においても、携帯電子機器端末側には影響を与えず、均等にアクセスを振り分けることができ、また、１つのサーバがダウンした時も、他のサーバに均等に振り分けることができ、サーバの信頼性およびシステムの信頼性を高めることができる。
【図面の簡単な説明】
【図１】本実施形態にかかる移動体通信システムの構成例を示す図である。
【図２】携帯電話機２ａ乃至２ｃの概略構成例を示す図である。
【図３】（Ａ）は、ＩＡ７の概略構成例を示す図、（Ｂ）は、ＣＡ８の概略構成例を示す図、（Ｃ）は、ＳＡ９の概略構成例示す図である。
【図４】携帯電話機２ａ乃至２ｃに対するサービスリスト提供時の本システム１００における模式図である。
【図５】携帯電話機２ａ乃至２ｃに対するサービスリスト提供時の本システム１００における処理の流れを示すフローチャートである。
【図６】携帯電話機２ａ乃至２ｃに対するＴｏｋｅｎ提供時の本システム１００における模式図である。
【図７】携帯電話機２ａ乃至２ｃに対するＴｏｋｅｎ提供時の本システム１００における処理の流れを示すフローチャートである。
【図８】携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における模式図である。
【図９】携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における模式図である。
【図１０】携帯電話機２ａ乃至２ｃに対する各種サービス提供時の本システム１００における処理の流れを示すフローチャートである。
【図１１】図１とは別の本実施形態にかかる移動体通信システム２００の構成例を示す図である。
【図１２】携帯電話機２ａ乃至２ｈに対する各種サービス提供時の本システム２００における模式図である。
【図１３】携帯電話機２ａ乃至２ｈに対する各種サービス提供時の本システム２００における処理の流れを示すフローチャートである。
【図１４】従来の移動体通信システムの構成例とともに、携帯電話機１０２がＡＰＮ１０４ａからサービスの提供を受ける際の流れ（▲１▼〜▲５▼）を示す図である。
【符号の説明】
１ インターネット
２ａ乃至２ｈ 携帯電話機
３ ＤＮＳ
４ａ、４ｂ、４ｃ ＡＰＮ
５ ＢＰＳ
６ 分散型アクセス制御システム
７ ＩＡ
８ ＣＡ
９ ＳＡ
１５ａ、１５ｂ、１５ｃ ロードバランサ群
１００、２００ 移動体通信システム
１０２ 携帯電話機
１０３ ＤＮＳ
１０４ａ、１０４ｂ、１０４ｃ ＡＰＮ
１０５ ＢＰＳ
Claims (13)
- ネットワーク上における通信制御を行う分散型アクセス制御システムであって、
携帯電子機器端末を利用するユーザのユーザクラスを蓄積するデータベースと、
前記携帯電子機器端末から、ネットワーク上で提供されるサービスのリストの要求を、前記ネットワークを介して受け付ける手段と、
前記サービスのリストの要求をした前記携帯電子機器端末を利用するユーザのユーザクラスに対応するサービスを、複数のサービスの夫々に対応付けてユーザクラスとアクセス券の発行状況を蓄積するデータベースを備えた装置から提供された情報に基づいて選定して前記サービスのリストを生成し、前記携帯電子機器端末に対して、前記ネットワークを介して提供するサービスリスト提供手段と、
前記携帯電子機器端末から、前記サービスのリストのうちからユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行要求を、前記ネットワークを介して受け付ける手段と、
前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するアクセス券発行手段と、を備えることを特徴とする分散型アクセス制御システム。 - 前記携帯電子機器端末を利用するユーザのユーザ情報を蓄積するデータベースと、
前記データベースに蓄積されたユーザ情報を参照して、前記サービスのリストの要求を行った携帯電子機器端末のユーザ認証を行うユーザ認証手段と、をさらに備え、
前記サービスリスト提供手段は、前記ユーザ認証の結果が妥当であった場合に、前記要求されたサービスのリストを、前記携帯電子機器端末に対して、前記ネットワークを介して提供することを特徴とする請求項１に記載の分散型アクセス制御システム。 - 前記携帯電子機器端末を利用するユーザのユーザ情報を蓄積するデータベースと、
前記データベースに蓄積されたユーザ情報を参照して、前記アクセス券の発行要求を行った携帯電子機器端末のユーザ認証を行うユーザ認証手段と、をさらに備え、
前記アクセス券発行手段は、前記ユーザ認証の結果が妥当であった場合に、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行することを特徴とする請求項１に記載の分散型アクセス制御システム。 - 前記アクセス券の発行状況を蓄積するデータベースと、
前記データベースに蓄積されたアクセス券の発行状況に基づいて、前記アクセス券の発行可否を決定するアクセス券発行可否決定手段と、をさらに備え、
前記アクセス券発行手段は、前記アクセス券の発行が可能であると決定された場合に、前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行することを特徴とする請求項１乃至３の何れかに記載の分散型アクセス制御システム。 - 前記アクセス券には、当該アクセス券によりアクセス可能なロードバランサ装置のアドレス情報が含まれていることを特徴とする請求項１乃至４の何れかに記載の分散型アクセス制御システム。
- 前記アクセス券発行可否決定手段は、前記アクセス券の発行量と前記特定のサーバの負荷容量とを比較して、当該比較結果に応じて前記アクセス券の発行可否を決定することを特徴とする請求項４に記載の分散型アクセス制御システム。
- ネットワーク上における通信制御を行う分散型アクセス制御システムにおける分散型アクセス制御方法であって、
携帯電子機器端末から、ネットワーク上で提供されるサービスのリストの要求を、前記ネットワークを介して受け付ける工程と、
前記サービスのリストの要求をした前記携帯電子機器端末を利用するユーザのユーザクラスに対応するサービスを、複数のサービスの夫々に対応付けてユーザクラスとアクセス券の発行状況を蓄積するデータベースを備えた装置から提供された情報に基づいて選定して前記サービスのリストを生成し、前記携帯電子機器端末に対して、前記ネットワークを介して提供する工程と、
前記携帯電子機器端末から、前記サービスのリストのうちからユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行要求を、前記ネットワークを介して受け付ける工程と、
前記発行要求されたアクセス券を、前記携帯電子機器端末に対して、前記ネットワークを介して発行するアクセス券発行工程と、を備えることを特徴とする分散型アクセス制御方法。 - 前記アクセス券には、前記サーバに対するアクセスを制限する有効度数と、有効期間が含まれていることを特徴とする請求項７の何れかに記載の分散型アクセス制御方法。
- 請求項１に記載の分散型アクセス制御システムに対して、ネットワーク上で提供されるサービスのリストを、前記ネットワークを介して要求する携帯電子機器端末であって、
前記要求に対して分散型アクセス制御システムから提供されたサービスのリストを、前記ネットワークを介して受け取る手段と、
前記受け取ったサービスのリストのうち、ユーザにより選択されたサービスの提供を担う前記ネットワーク上のサーバにアクセスを振り分けるロードバランサ装置にアクセスするためのアクセス券の発行を、前記ネットワークを介して分散型アクセス制御システムに要求する手段と、
前記要求に対して分散型アクセス制御システムから発行されたアクセス券を、前記ネットワークを介して受け取る手段と、
前記受け取ったアクセス券に基づいて、前記ネットワーク上のロードバランサ装置にアクセスするアクセス手段と、を備えることを特徴とする携帯電子機器端末。 - 前記アクセス券には、前記サーバへのアクセス回数を制限する有効度数が含まれており、
前記アクセス手段は、前記有効度数に基づいて前記ロードバランサ装置へのアクセスが可能であるか否かを判断し、可能であると判断した場合には、前記ネットワーク上の前記ロードバランサ装置にアクセスすることを特徴とする請求項９に記載の携帯電子機器端末。 - 前記アクセス手段が、前記ロードバランサ装置にアクセスする毎に、前記有効度数を所定数減らすことを特徴とする請求項１０に記載の携帯電子機器端末。
- 前記アクセス券には、前記ロードバランサ装置へのアクセス期間を制限する有効期間が含まれており、
前記アクセス手段は、前記有効期間に基づいて前記ロードバランサ装置へのアクセスが可能であるか否かを判断し、可能であると判断した場合には、前記ネットワーク上の前記ロードバランサ装置にアクセスすることを特徴とする請求項９乃至１１の何れかに記載の携帯電子機器端末。 - 請求項９乃至１２の何れかに記載する前記アクセス券を有する携帯電子機器端末からの前記ネットワークを介したアクセスを、複数のサーバから構成される所定のサービス提供を担うサーバ群のうち何れかのサーバに対して振り分けることを特徴とするロードバランサ装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001076112A JP3959242B2 (ja) | 2001-03-16 | 2001-03-16 | 分散型アクセス制御システムおよび分散型アクセス制御方法、並びに携帯電子機器端末、ロードバランサ装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001076112A JP3959242B2 (ja) | 2001-03-16 | 2001-03-16 | 分散型アクセス制御システムおよび分散型アクセス制御方法、並びに携帯電子機器端末、ロードバランサ装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002278927A JP2002278927A (ja) | 2002-09-27 |
| JP3959242B2 true JP3959242B2 (ja) | 2007-08-15 |
Family
ID=18933099
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001076112A Expired - Fee Related JP3959242B2 (ja) | 2001-03-16 | 2001-03-16 | 分散型アクセス制御システムおよび分散型アクセス制御方法、並びに携帯電子機器端末、ロードバランサ装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3959242B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4865366B2 (ja) * | 2006-03-03 | 2012-02-01 | 株式会社ドワンゴ | ネットワークゲームシステム及びネットワークゲーム方法 |
| JP4586776B2 (ja) * | 2006-07-28 | 2010-11-24 | 日本電気株式会社 | トークンによるアクセス制御システム、アクセス制御方法 |
| JP5487374B2 (ja) * | 2008-06-30 | 2014-05-07 | エヌエイチエヌ エンターテインメント コーポレーション | サービス提供方法及びオンラインサービスシステム |
| JP5797012B2 (ja) * | 2011-05-25 | 2015-10-21 | 株式会社タイトー | ゲームサーバ処理システム |
| EP2798560B1 (en) * | 2011-12-28 | 2016-09-21 | Intel Corporation | Methods and apparatus to facilitate single sign-on services |
| JP5843325B2 (ja) * | 2013-03-29 | 2016-01-13 | Ｎｅｃプラットフォームズ株式会社 | 無線ｌａｎ管理方法およびシステム |
-
2001
- 2001-03-16 JP JP2001076112A patent/JP3959242B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002278927A (ja) | 2002-09-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7363055B2 (en) | Method, apparatus and article to remotely associate wireless communications devices with subscriber identities and/or proxy wireless communications devices | |
| US6310873B1 (en) | Internet telephony directory server | |
| JP2003289330A (ja) | インターネット接続装置自動選択方法，インターネット接続装置自動選択装置，及び、インターネット接続装置自動選択プログラム | |
| JP2002032216A (ja) | アプリケーションのホスティング装置 | |
| WO2000014919A2 (en) | Apparatus and methods for connecting a network user to a network service provider | |
| JP4372936B2 (ja) | 代行管理方法及びエージェント装置 | |
| JP3959242B2 (ja) | 分散型アクセス制御システムおよび分散型アクセス制御方法、並びに携帯電子機器端末、ロードバランサ装置 | |
| US8170032B2 (en) | Method and arrangement for externally controlling and managing at least one WLAN subscriber who is assigned to a local radio network | |
| JP3880903B2 (ja) | 無線ｌａｎシステムのアクセス管理サーバ、及びアクセス管理方法 | |
| US7480371B2 (en) | Method and system for billing network access capacities shared between internet service providers | |
| JP3959241B2 (ja) | 分散型アクセス制御システムおよび分散型アクセス制御方法、並びに携帯電子機器端末 | |
| JP2001237989A (ja) | 情報表示型携帯電話所有者に対する課金代行システム | |
| JP4065436B2 (ja) | 通信ネットワークにおけるネットワーク・アクセス及びサービス・トランザクションについてのデータを構築及び通信する方法及びシステム | |
| CA2188974C (en) | Conference mailbox service | |
| JP2002026954A (ja) | ネットワークアドレス管理システム及び方法 | |
| KR100831563B1 (ko) | 유료 컨텐츠 사용자의 계정 매핑을 이용한 과금대행 장치및 그방법 | |
| JP3878845B2 (ja) | 利用料金課金方法および課金装置 | |
| CN100499894C (zh) | 多管理域开放业务访问结构与接口方法 | |
| WO1999055067A1 (en) | Method for submitting user profiles to a telecommunications network | |
| JP2003123016A (ja) | 課金方法、課金システム、認証サーバ、およびプログラム | |
| JP2003008783A (ja) | 度数管理システム及び方法 | |
| JP2002149621A (ja) | コンテンツ配信サーバ装置及びコンテンツ配信方法 | |
| Rajala | Service provisioning in IP/ATM Network | |
| KR20040072117A (ko) | 무선인터넷에서의 수신자부담 과금을 지원하기 위한접속승인 방법 | |
| JP2005333213A (ja) | 情報提供システム，情報提供システムの制御方法，及びゲートウェイサーバ装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060530 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20060628 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060728 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061102 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070206 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070409 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070508 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070514 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100518 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110518 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |