JP3636947B2 - 情報サービスシステム、サービス利用クライアント及びサービス規制方法 - Google Patents
情報サービスシステム、サービス利用クライアント及びサービス規制方法 Download PDFInfo
- Publication number
- JP3636947B2 JP3636947B2 JP24416699A JP24416699A JP3636947B2 JP 3636947 B2 JP3636947 B2 JP 3636947B2 JP 24416699 A JP24416699 A JP 24416699A JP 24416699 A JP24416699 A JP 24416699A JP 3636947 B2 JP3636947 B2 JP 3636947B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- restriction
- information
- use request
- server
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5022—Workload threshold
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/10015—Access to distributed or replicated servers, e.g. using brokers
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、情報通信サービスシステムにおいてサービス利用者からのサービス利用要求の発行を規制する技術に関する。
【０００２】
【従来の技術】
従来技術では、特開平６−２８４１８７号公報に記載のようなものがある。即ち、加入者端末と各種のサービス及びまたは仮想私設網とを交換接続する複数のサービス交換ポイントと、このサービス交換ポイントを通信網を介して制御するシステム制御プロセッサとを備えたシステムにおいて、システム制御プロセッサは、サービスまたは仮想私設網の利用、または私設網の種別対応それぞれについてトラフィックを計測し、これがそれぞれに設定された閾値を超えたトラフィックについてサービス交換ポイントに対し規制信号を送信する。そして、サービス交換ポイントはその規制信号にしたがってそれぞれの要求呼を棄却する。こうして、過負荷の要因となっている特定のサービスまたは特定の顧客が使用している私設網に関する呼のみを排除し、他のサービス等に対する呼接続については、これを継続するという木目細かい処理をするものである。
【０００３】
また、特開平１０−９７４７６号公報には、エンドユーザから情報通信サービスの利用要求が発行されると、サービスプロバイダ側で、ネットワーク上におけるユーザの活動範囲を定めるための情報であるコミュニティに優先度を付与し、ネットワークを介して配送し、エンドユーザは、そのコミュニティに基づいて獲得、終了、移動、中断、復帰の処理を行なうことが示されている。このようにして、優先度の高いコミュニティを優先的に実行させる事により、企業等の閉域ネットワークの輻輳を事前に回避するものである。
【０００４】
また、特開平８−２１３９８１号公報には、ホストと複数の端末間の論理的な１対ｎ通信において、ホストと複数の端末間に論理的な別線を持たせ、輻輳通知を一斉に端末に送ることが示されている。
【０００５】
【発明が解決しようとする課題】
特開平６−２８４１８７号公報に記載の従来の方式では、サービス交換ポイントではサービス要求は棄却される。したがって、システム制御プロセッサの負荷は軽減される。しかし、加入者端末からのサービス交換ポイントへのサービス要求は依然として規制されない。一般に、加入者端末の数は膨大なものになるので、サービス交換ポイントでは加入者端末からのサービス要求を棄却するだけでも負荷は掛かることになる。ここでは、システム制御プロセッサの過負荷防止は出来、サービス交換ポイントへの事実上の負荷分散は出来ているが、サービス交換ポイントの過負荷の問題は残っている。
【０００６】
例えば、電話サービスの呼設定要求が集中する大災害のパニック時や、特定の時間帯に呼設定要求が集中するチケット販売等においては、加入者端末（サービス利用者）が複数接続されているサービス交換ポイントが過負荷になり、サービス交換ポイントに接続している加入者（サービス利用者）がサービスを利用できなくなるという惧れがある。
【０００７】
すなわち、特開平６−２８４１８７号公報記載に記載の従来の方法では、加入者端末（サービス利用者の端末）からの多量の呼設定要求（サービス利用要求）そのものの発生を規制することはできないため、サービス提供者側の設備であるサービス交換ポイントの過負荷制御については、何ら配慮されていない。また、加入者（サービス利用者）とサービス交換ポイントを接続するネットワークにも、多量の呼設定要求（サービス利用要求）が流れるため、加入者（サービス利用者）とサービス交換ポイントを接続するネットワークに負荷がかかるということについても配慮されていない。
【０００８】
また、サービス利用者が、サービス利用要求の拒否により再びサービス利用要求を発行すると、情報通信サービスシステムがさらに過負荷状態になり輻輳状態がいっこうに解除されないという事態にもなる。
【０００９】
また、特開平１０−９７４７６号公報に記載の従来の方式では、サービス利用者からのサービス利用要求の応答に規制情報を付与することにより、サービス利用要求の発行を制御するため、特定のサービス利用者からのサービス利用要求の発行は制御できるが、多数存在するサービス利用者から同時にサービス利用要求が発行された場合は、個別に規制情報を送る必要があるために、情報通信サービスシステムが過負荷状態になるという問題があった。
【００１０】
例えば、ショッピングサービスシステムにおいて、あるサービス利用者からのサービス利用要求に対する応答に規制情報を付与することにより、該サービス利用者からのサービス利用要求の発行は制御できる。しかし、他のサービス利用者には、その規制情報は配布されないため、他のサービス利用者は、ショッピングサービスシステムの規制情報によることなく、サービス利用要求を発行する。したがって、例えば、チケットの発売開始時は、サービス利用者からのサービス利用要求の発行が集中し、これにより、ショッピングサービスシステムが過負荷状態になるという問題があった。
【００１１】
また、ショッピングサービスシステムが過負荷状態に陥り、サービス利用要求に対する応答を返せなくなるという事態が発生した場合、サービス利用者は、サービス利用要求の再発行を試みる。これにより、さらにショッピングサービスシステムの過負荷状態を悪化させるということもあった。
【００１２】
また、携帯電話網の例においても、会社員の帰宅時間などサービス利用者によるサービス利用要求（ダイヤリング）が集中する時間帯になると、携帯電話網が過負荷状態となり、電話がつながらない事態が発生する。このとき、サービス利用者が再ダイヤルを行うと、携帯電話網の負荷状態をさらに悪化させてしまうという問題があった。
【００１３】
更に、特開平８−２１３９８１号公報では輻輳の通知に、データ転送とは別に設けられた論理的な別線が必要である。これはシステムリソースをこの分余分に必要とする。
【００１４】
以上のことから、本発明の目的は、情報通信サービスを提供するシステムおよびネットワークの過負荷状態をより良く回避することにある。
【００１５】
【課題を解決するための手段】
上記目的を達成するために、情報通信サービスを提供するシステムは、サービス提供部の負荷状況を測定してサービス規制情報を発行するか否かを決定するサービス規制制御部と、サービス規制情報を格納するサービス規制情報テーブルと、サービス利用クライアントにサービス規制情報を発行するサービス規制情報発行部とを備え、さらに、前記サービス規制制御部でサービス提供システムの負荷の状態がある閾値を越えることを検出したときに、前記サービス規制情報発行部により、負荷の大きさがある閾値を越える状態となるサービス要求をしたサービス利用クライアントだけでなく、他のサービス要求をしていないサービス利用クライアントにも前記サービス規制情報テーブルに格納されたサービス規制情報をデータと同じ経路で送信する手段を備えたものである。
【００１６】
また、前記サービス利用クライアントは、前記サービス提供システムから発行されるサービス規制情報を受け付けるサービス規制情報受付部と、サービス規制情報受付部で受け付けたサービス規制情報を格納するサービス利用要求発行制御テーブルと、サービス利用者から受け付けたサービス利用要求をサービス利用要求発行制御テーブルをもとに発行するか否かを決定するサービス利用要求発行制御部とを備え、前記サービス提供システムから前記サービス利用クライアントに発行されるサービス規制情報に基づいて、前記サービス利用クライアント側でサービス利用要求の発行を制御する手段を備えたものである。
【００１７】
【発明の実施の形態】
以下に本発明の一実施形態をショッピングサービスシステムを例に図１から図２０を用いて説明する。
【００１８】
図１はショッピングサービスシステムの全体構成を示している。このシステムでは、サービス提供システム１０１は、ショッピングサービスを提供するサービス提供部１０８と、サービス利用者４０２からのサービス利用要求を受け付けるサービス利用要求受付部１０７と、サービス提供部１０８の負荷に応じてサービス規制情報を発行するか否かを判断する基準値となる負荷閾値を格納する負荷閾値テーブル１０３と、負荷閾値テーブル１０３をもとにサービス規制情報を発行するか否かを判断するサービス規制制御部１０５と、サービス利用クライアントでのサービス規制方法を格納するサービス規制情報テーブル１０４と、サービス利用クライアントにサービス規制情報を同報するサービス規制情報同報部１０６、負荷閾値テーブル１０３およびサービス規制情報テーブル１０４にそれぞれ負荷閾値、サービス規制情報を設定する情報設定部１０２とを備えている。
【００１９】
また、サービス提供システムの構成は、他の実施形態として、図１０に示すように、サービスを提供するサービス提供システムＡ０１と、サービス規制情報を発行するサービス規制情報発行サーバＡ０２とに分離する形態でも良い。
【００２０】
サービス利用クライアント３０１は、サービス規制情報にもとづいてサービス提供システムに接続するサービス接続部３００を内蔵している。図２０に示すように、サービス利用クライアント３０１は、サービス提供システム１０１との接続を行う前に、サービス提供システム１０１との接続に必要なサービス接続部３００をあらかじめ用意しておく。具体的には必要なプログラムを処理に先立ってロードしておく。
【００２１】
このように、サービス接続部３００のプログラムをロード出来るようにしてあるのは次の理由による。
サービス利用クライアント３０１は複数の機種が想定され、必ずしも、後で詳述するサービス規制情報に基づいてサービス利用要求発行を抑制する機能を持っているとは限らない。したがって、このように初期に上記の機能をもつプログラムをロードするようにすることにより、各種のサービス利用クライアントに同様のサービス利用要求を抑制する機能を持たせることが出来るのである。
【００２２】
図２０は、サービス接続部３００の提供処理において、サービス提供システム１０１に負荷をかけないようにするために、別に設置したサービス接続部提供サーバ５０１により、サービス接続部を提供する（各クライアントに必要なプログラムを配送すること）方式を示している。サービス利用者４０２は、サービス利用クライアント３０１からサービス接続部提供サーバ５０１に接続して、サービス提供部３００を入手する。また、Ｊａｖａアプレットのようにインストールせずにサービス接続部提供サーバ５０１からダウンロードしてそのまま動作するソフトウェアであってもよい。図２０の実施例では、ネットワーク経由でサーバ接続部３００を入手する例を説明したが、ＣＤ−ＲＯＭなどのソフトウェア格納媒体やＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）によりあらかじめサービス利用クライアント３０１に設置されていてもよい。また、サービス接続部提供サーバ５０１がサービス提供システム１０１に含まれている場合は、サービス提供システム１０１の負荷が低いときにあらかじめサービス接続部３００を提供しておくことも可能である。
【００２３】
ここで、サービス提供システム（サーバ）１０１と図１０のサービス規制情報発行サーバＡ０２や、図２０のサービス接続部提供サーバ５０１などサービスを提供する側のシステムを上記の変形例を含めて情報サービスシステムと総称する。
【００２４】
サービス接続部３００の構成は、サービス提供システム１０１から発行されるサービス規制情報を受け付けるサービス規制情報受付部３０２と、サービス提供システム１０１から受け付けたサービス規制情報を格納するサービス利用要求発行制御テーブル３０３と、サービス利用者４０２からのサービス利用要求を受け付けるサービス利用要求受付部３０６と、サービス利用要求をサービス利用要求発行制御テーブル３０３をもとに発行するか否かを判断するサービス利用要求発行制御部３０５と、サービス利用要求を発行するサービス利用要求発行部３０４と、サービス規制情報を受け付けたときにサービス利用者４０２にその旨を通知するユーザ通知部３０７を備えている。
【００２５】
負荷閾値テーブル１０３は、図２に示すように、サービス提供部１０８の負荷をもとにサービス規制を開始することを判断する閾値であるサービス規制開始閾値Ｔ２０１と、サービス規制を解除することを判断する閾値であるサービス規制解除閾値Ｔ２０２を格納する。
【００２６】
ここでいうサービス提供部１０８の負荷とは、プロセッサのビジー率、メモリやバッファの利用率、ディスクスペースの使用率、ネットワークやディスクの入出力利用率などサービス提供部１０８がサービス利用者４０２に提供するサービスで使用するリソースの利用状況を示している。図２で示したショッピングサービスシステムではサービス提供部１０８の負荷としてサービス提供部１０８のプロセッサ利用率を用いた例であり、サービスの品質に影響する負荷であれば、上記のネットワークやディスクの入出力利用率など種類を問わない。
【００２７】
サービス規制情報テーブル１０４は、図３に示すように、サーバ種別Ｔ３０１と、サービス種別Ｔ３０２と、規制種別Ｔ３０３としてサービス利用要求発行抑止と、例えば「ただ今、大変混み合っていますので、本サービスはご利用になれません。しばらくたってから、再度ご利用下さい。」のようなサービス利用者にサービス利用不可能を通知する規制メッセージＴ３０４を格納する。
【００２８】
サービス規制制御部１０５は、定期的にサービス提供部１０８の負荷状況を測定し、その測定結果と負荷閾値テーブル１０３をもとにサービス規制情報を発行するか否かを決定する。この処理を図５に示す。この処理の各ステップを以下に示す。
【００２９】
サービス規制制御部１０５は、サービス提供部１０８の負荷を測定し（Ｓ５０１）、現在のサービス規制状態を判断し（Ｓ５０２）、現在のサービス規制状態がサービス規制中でなければ、サービス提供部１０８の負荷と負荷閾値テーブル１０３のサービス規制開始閾値Ｔ２０１を比較する（Ｓ５０３）。サービス提供部１０８の負荷が負荷閾値テーブル１０３のサービス規制開始閾値Ｔ２０１を超えていなければ、終了する。サービス提供部１０８の負荷が負荷閾値テーブル１０３のサービス規制開始閾値Ｔ２０１を超えていれば、サービス規制状態を「サービス規制中」に設定し（Ｓ５０４）、サービス規制情報テーブル１０４から規制情報Ｔ３０１〜Ｔ３０４を取得し（Ｓ５０５）、サービス規制情報同報部１０６にサービス規制要求の発行を依頼する（Ｓ５０６）。
【００３０】
Ｓ５０２において、現在のサービス規制状態がサービス規制中であれば、サービス提供部１０８の負荷と負荷閾値テーブル１０３のサービス規制解除閾値Ｔ２０２を比較する（Ｓ５０７）。サービス提供部１０８の負荷が負荷閾値テーブル１０３のサービス規制解除閾値Ｔ２０２を下回っていなければ、終了する。サービス提供部１０８の負荷が負荷閾値テーブル１０３のサービス規制解除閾値Ｔ２０２を下回っていれば、サービス規制状態を「サービス非規制中」に設定し（Ｓ５０８）、サービス規制情報同報部１０６にサービス規制解除要求の発行を依頼する（Ｓ５０９）。ここで、サービス規制情報同報部１０６に発行を依頼するサービス規制情報には、サービス規制情報テーブル１０４の内容を含むものとする。
【００３１】
サービス規制情報同報部１０６は、サービス規制制御部１０５からの依頼を受け、サービス利用クライアント３０１にサービス規制情報を発行する。この処理を図６に示す。この処理の各ステップを以下に示す。
【００３２】
サービス規制情報同報部１０６は、サービス規制制御部１０５からの依頼の内容を判定し（Ｓ６０１）、サービス規制要求の発行依頼であれば、サービス利用クライアント３０１にサービス規制要求を発行する（Ｓ６０２）。サービス規制制御部１０５からの依頼の内容がサービス規制解除要求の発行依頼であれば、サービス利用クライアント３０１にサービス規制解除要求を発行する（Ｓ６０３）。
【００３３】
ここで、多数存在するサービス利用クライアント３０１にサービス規制要求あるいはサービス規制解除要求を一斉に発行する手段としては、例えば、ＩＰマルチキャストプロトコルと呼ばれる同報配信プロトコルを使用する。ＩＰマルチキャストプロトコルとは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルにより実現されるもので、サービス規制情報同報部１０６は、サービス規制情報をマルチキャストアドレスに送信することで、多数存在するサービス利用クライアント３０１に同報送信することができる。
【００３４】
ＩＰマルチキャストについては「コンピュータ＆ネットワークＬＡＮ」１９９９、１、ＶＯＬ．１７オーム社 ６ページから１０ページに説明がある。かいつまんでいえば、以下の様である。情報発信側は特定のマルチキャストアドレスに向けて１つのデータを送信するだけで良い。受信者はＩＧＭＰを利用してマルチキャスト配信を受けたいという要求をルータに伝える。ルータはマルチキャストルーティングによって、受信を希望するユーザの存在する方向へのみ自動的にコピーしながら配信する。このようにして大量のデータを多数のサイトに転送することが出来る。マルチキャストではデータの到着時間に多少の差が出るものの、ほぼ同時期の着信が期待出来る。
【００３５】
ここでいう、サービス規制情報同報とは、次節のものも含み、マルチキャストという手段に限定されず、また全くの同時性も要求してはいない。送信者が一度の送信を意識するだけで同一内容が多数の受信者に配送されることを意味している。
【００３６】
多数存在するサービス利用クライアント３０１に対してサービス規制情報を同報送信する手段として、前記ＩＰマルチキャストプロトコル以外にも衛星デジタル放送や地上波デジタル放送、携帯電話基地局など、同報送信することが可能であれば手段は問わない。
【００３７】
ここで、サービス規制情報の同報は、通常のデータの送受信と同じ経路を取り、特別に同報のための別線（論理的であっても）必要としない。なお、ここで同じ経路というのはＩＰアドレスレベルで同一の経路という意味で使用している。
【００３８】
サービス規制情報受付部３０２は、サービス規制情報同報部１０６からのサービス規制情報を受け付け、その内容をサービス利用要求発行制御テーブル３０３に格納する。この処理を図７に示す。この処理の各ステップを以下に示す。また、サービス利用要求発行制御テーブル３０３の内容を図１９に示す。
【００３９】
サービス規制情報受付部３０２は、サービス規制情報同報部１０６から受信した内容を判定し（Ｓ７０１）、サービス規制要求であれば、その内容をサービス利用要求発行制御テーブル３０３に格納する（Ｓ７０２）。サービス利用要求発行制御テーブル３０３に格納する内容は、図１９に示すように、サービス規制情報同報部１０６から受信した内容（ＴＪ０１、ＴＪ０２、ＴＪ０４の指す内容）と、該サービス提供システムの該サービスがサービス規制中であることを示すサービス状態ＴＪ０３と、サービス規制要求を受け付けた時刻を示す受付時刻ＴＪ０５である。複数の種類のサービスのサービス提供システムから同時にサービス規制要求を受け付けた場合は、これらの情報を格納する領域をサービス毎に複数持つ。サービス規制情報同報部１０６から受信した内容がサービス規制解除要求であれば、サービス利用要求発行制御テーブル３０３から該サービス提供システムの該サービスのサービス規制情報（ＴＪ０１〜ＴＪ０５）を削除する（Ｓ７０３）
サービス利用要求発行制御部３０５は、サービス利用要求受付部３０６からのサービス利用要求発行の依頼を受け付け、サービス利用要求発行制御テーブル３０３をもとに、サービス提供システム１０１へのサービス利用要求の発行を制御する。この処理を図８に示す。この処理の各ステップを以下に示す。
【００４０】
サービス利用要求発行制御部３０５は、サービス利用要求を発行するサービス提供システムおよびサービスの規制状態をサービス利用要求発行テーブル３０３のサービス状態ＴＪ０３をもとに判定する（Ｓ８０１）。サービス利用要求を発行するサービス提供システムおよびサービスがサービス規制中でなければ、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（Ｓ８０２）。サービス利用要求を発行するサービス提供システムおよびサービスがサービス規制中であれば、サービス利用要求発行制御テーブル３０３からサービス規制情報を取得し（Ｓ８０３）、ユーザ通知部３０７に規制メッセージの表示を依頼する（Ｓ８０４）。
【００４１】
規制メッセージの表示依頼は、ユーザ通知部３０７によって画面に表示される。そのイメージを図４に示す。即ち、サービス利用ボタンＤ４０２とともに、図３の規制メッセージＴ３０４に記憶されたメッセージが表示される。
【００４２】
ここで、規制メッセージは、図４に示したように画面に表示される形態でも良いし、音声によって通知する形態でも良く、サービス利用者に該サービス提供システムの該サービスが規制されていることが通知できる形態であれば種類を問わない。
【００４３】
図９では、サービス規制情報テーブル１０４の規制種別がサービス利用要求発行抑止Ｔ２０３の場合のサービス提供システム１０１、サービス利用クライアント３０１間のタイミングチャートを示している。
【００４４】
サービス提供システム１０１のサービス提供部１０８の負荷がサービス規制開始閾値Ｔ２０１を超えてサービス規制中になると（Ｓ９０１）、サービス規制要求が発行される（Ｓ９０２）。サービス利用者４０２が該サービス提供システムの該サービスにサービス利用要求を発行する（Ｓ９０３）。しかし、サービス利用クライアント３０１では、該サービス提供システムの該サービスがサービス規制中であることを認識しているため、サービス提供システム１０１へのサービス利用要求の発行は行わず、サービス利用者にサービス利用不可を通知する（Ｓ９０４）。この時、図４に示したように、サービスが利用できない旨の内容がサービス利用者４０２に通知される。サービス利用者４０２は、サービス利用不可の通知を受けて、サービス利用要求の発行を繰り返す（Ｓ９０５〜Ｓ９０６）。サービス提供システム１０１のサービス規制中が解除され（Ｓ９０７）、サービス規制解除要求が発行される（Ｓ９０８）。サービス利用クライアント３０１は、サービス規制解除要求を受け付けたため、サービス利用者４０２からのサービス利用要求の発行依頼を受け付け（Ｓ９０９）、サービス提供システム１０１へサービス利用要求を送信する（Ｓ９１０）。
【００４５】
また、前述したショッピングサービスシステムにおいて、サービス規制情報テーブル１０４を図１１のようにする方法もある。図３との違いは、規制種別ＴＢ０３がサービス利用要求発行固定時間抑止になったこと、規制メッセージＴＢ０４の内容が「…、ｘｘｘ後、…」になり、ｘｘｘには後述する抑止時間ＴＢ０５の値が埋め込まれること、規制情報種別として新たに抑止時間ＴＢ０５が設けられたこと、である。この方法では、サービス提供システム１０１から発行されるサービス規制情報に抑止時間ＴＢ０５を付加することにより、サービス利用クライアント３０１は、抑止時間ＴＢ０５の間、該サービス提供システムの該サービスへのサービス利用要求の発行を抑止する。サービス利用クライアント３０１は、抑止時間ＴＢ０５を経過すると、サービス利用者４０２からのサービス利用要求をサービス提供システム１０１へ発行するため、サービス提供システム１０１からのサービス規制解除要求は不要となる。
【００４６】
サービス規制情報テーブル１０４の規制種別ＴＢ０３がサービス利用要求発行固定時間抑止の場合のサービス利用要求発行制御部３０５の処理を図１３に示す。この処理の各ステップを以下に示す。
【００４７】
サービス利用要求発行制御部３０５は、サービス利用要求受付部３０６からサービス利用要求の発行依頼を受け付けると、サービス利用要求の発行先のサービス提供システムおよびサービスがサービス規制中か否かをサービス利用要求発行テーブル３０３をもとに判定する（ＳＤ０１）。サービス利用要求を発行するサービス提供システムおよびサービスがサービス規制中でなければ、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（ＳＤ０２）。サービス利用要求を発行するサービス提供システムおよびサービスがサービス規制中であれば、サービス利用要求発行制御テーブル３０３からサービス規制情報を取得し（ＳＤ０３）、サービス規制要求の受付時刻ＴＪ０５から現在時刻までの時間を求め、その時間が抑止時間を超えているかどうか判定する（ＳＤ０４）。抑止時間を超えていれば、サービス利用要求発行制御テーブル３０３から該サービス提供システムの該サービスのサービス規制情報を削除し（ＳＤ０５）、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（ＳＤ０６）。
【００４８】
抑止時間を超えていなければ、ユーザ通知部３０７に規制メッセージの表示を依頼する（ＳＤ０７）。規制メッセージの表示依頼は、ユーザ通知部３０７によって画面に表示される。そのイメージを図１２に示す。即ち、サービス利用ボタンと共に、図１１の規制メッセージＴＢ０４に抑止時間ＴＢ０５を埋め込んだメッセージが画面に表示される。
【００４９】
図１４では、サービス規制情報テーブル１０４の規制種別ＴＢ０３がサービス利用要求発行固定時間抑止の場合のサービス提供システム１０１、サービス利用クライアント３０１間のタイミングチャートを示している。図９との違いは、サービス提供システム１０１のサービス提供部１０８の負荷がサービス規制開始閾値Ｔ２０１を超えてサービス規制中になり（ＳＥ０１）、サービス規制要求が発行された時刻（ＳＥ０２）から、抑止時間の間は、サービス利用者４０２からのサービス利用要求をサービス提供システム１０１に発行せず、サービス利用クライアント３０１で抑止することである（ＳＥ０３〜ＳＥ０６）。抑止時間を超えてからのサービス利用要求は、サービス提供システム１０１へ発行する（ＳＥ０８〜ＳＥ０９）。
【００５０】
また、図１１のサービス規制情報テーブルにおいて、抑止時間ＴＢ０５を固定ではなく、サービス提供部１０８の負荷に応じて可変にする方法もことも可能である。サービス提供部１０８の負荷はサービス規制制御部１０５によって定期的に測定されるため、短時間で負荷が急激に上がる場合がある。これを考慮して、負荷閾値テーブル１０３は、図１５のようにサービス提供部１０８の負荷に応じて、抑止時間をサービス規制開始閾値に対してそれぞれ設定可能とする。即ち、規制開始閾値を高いときは負荷集中が高いために負荷集中の回復の時間が長いものとして抑止時間を長くする。この場合、サービス規制情報テーブル１０４は、図１６のように規制種別ＴＧ０３はサービス利用要求発行可変時間抑止となり、かつ、図１１には存在した抑止時間ＴＢ０５はなくなる。また、サービス利用クライアント３０１に発行されるサービス規制情報は、サービス規制情報テーブル３０１とサービス提供部１０８の負荷に対応した負荷閾値テーブル１０３の抑止時間とを含む内容となる。
【００５１】
また、あらかじめサービス利用者にランクを付けておき、サービス提供部１０８の負荷が規制開始閾値Ｔ２０１を超えた場合、ランクの低いサービス利用者のサービス利用要求の発行を抑止する、という方法も可能である。サービス規制情報テーブル１０４は、図１７に示すように、規制種別ＴＨ０３がサービス利用要求発行ランク抑止となり、新たに規制対象ランクＴＨ０５が追加される。本実施例で示しているランクは、Ａが一番高く、Ｃが一番低いランクである。ここでいう、サービス利用者のランクとは、ショッピングサービスシステムにおいては、過去の商品購入実績など、売り上げに寄与するかどうかをランク付けしたものである。ランク付けの方法は、過去の商品購入実績から自動的に付与される方法でも良いし、定期的にサービス運用者が過去の商品購入実績を参照し、手動で設定する方法でも良く、方法は問わない。サービス提供システム１０１から発行されるサービス規制情報には、この規制対象ランクＴＨ０５が付与され、サービス利用クライアント３０１のサービス利用要求発行制御部３０５では、自分のランクがサービス提供システム１０１から発行されたサービス規制情報の規制対象ランクに一致するかどうかを判定し、サービス利用要求を発行するかどうかを決定する。
【００５２】
サービス規制情報テーブル１０４の規制種別ＴＨ０３がサービス利用要求発行ランク抑止の場合のサービス利用要求発行制御部３０５の処理を図１８に示す。この処理の各ステップを以下に示す。
【００５３】
サービス利用要求発行制御部３０５は、サービス利用要求受付部３０６からサービス利用要求の発行依頼を受け付けると、サービス利用要求を発行するサービス提供システムおよびサービスの規制状態を判定する（ＳＩ０１）。サービス提供システムのサービスがサービス規制中でない場合、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（ＳＩ０４）。サービス提供システムのサービスがサービス規制中である場合、サービス利用要求発行制御テーブル３０３からサービス規制情報を取得し（ＳＩ０２）、サービス規制対象のランクが自分のランクと一致するか否かを判定する（ＳＩ０３）。サービス規制対象のランクが自分のランクと一致しなければ、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（ＳＩ０４）。サービス規制対象のランクが自分に一致すれば、ユーザ通知部３０７に規制メッセージの表示を依頼する（ＳＩ０５）。
【００５４】
以上、サービス規制情報テーブル１０４の規制種別毎に４種類の方法を説明した。この４種類の方法は、例えば、サービス利用要求発行可変時間抑止とサービス利用要求発行ランク抑止を組み合わせて、サービス提供部１０８の負荷に応じて、規制対象とするサービス利用者のランクを可変にするなど、組み合わせて実現する方法も可能である。
【００５５】
本発明により、ショッピングサービスシステムにおいて、サービス利用クライアントでは、サービス提供システムに接続するためのサービス接続部を具備しているため、サービス提供システムが過負荷状態になる前に、サービス規制要求をサービス利用クライアントに発行し、サービス利用クライアントでのサービス利用要求の発行を制御して、サービス提供システムが過負荷状態になることを未然に防ぐことが可能となる。
【００５６】
また、本発明は携帯電話網などの電話やデータ通信サービスに対してもそのまま適用可能であり、同様の効果を得ることができる。
【００５７】
【発明の効果】
本発明では、情報通信サービスシステムのサービス提供システムに負荷がかかることなく、サービス利用クライアントからのサービス利用要求の発行自体を規制することが可能となる。また、サービス提供システムが過負荷状態になることを未然に防ぐことが可能となる。
【図面の簡単な説明】
【図１】本発明の実施例を示したショッピングサービスシステムのブロック図である。
【図２】負荷閾値テーブルである。
【図３】サービス規制情報テーブルである。
【図４】サービス規制中の旨をサービス利用者に通知するサービス利用画面のイメージ図である。
【図５】サービス規制制御部の処理を示すフローチャートである。
【図６】サービス規制情報発行部の処理を示すフローチャートである。
【図７】サービス規制情報受付部の処理を示すフローチャートである。
【図８】サービス利用要求発行制御部の処理を示すフローチャートである。
【図９】サービス提供システム、サービス利用クライアント間のタイミングチャートである。
【図１０】本発明の実施例を示したショッピングサービスシステムのブロック図において、サービス規制情報発行部を別サーバに配置した場合のブロック図である。
【図１１】サービス規制情報テーブルである。
【図１２】サービス規制中の旨をサービス利用者に通知するサービス利用画面のイメージ図である。
【図１３】サービス利用要求発行制御部の処理を示すフローチャートである。
【図１４】サービス提供システム、サービス利用クライアント間のタイミングチャートである。
【図１５】負荷閾値テーブルである。
【図１６】サービス規制情報テーブルである。
【図１７】サービス規制情報テーブルである。
【図１８】サービス利用要求発行制御部の処理を示すフローチャートである。
【図１９】サービス利用要求発行制御テーブルである。
【図２０】本発明におけるサービス接続部を持ったサービスクライアントを持つシステムの例を示す図である。
【符号の説明】
１０１…サービス提供システム
１０２…情報設定部
１０３…負荷閾値テーブル
１０４…サービス規制情報テーブル
１０５…サービス規制制御部
１０６…サービス規制情報同報部
１０７…サービス利用要求受付部
１０８…サービス提供部
２０１…ネットワーク
３００…サービス接続部
３０１…サービス利用クライアント
３０２…サービス規制情報受付部
３０３…サービス利用要求発行制御テーブル
３０４…サービス利用要求発行部
３０５…サービス利用要求発行制御部
３０６…サービス利用要求受付部
３０７…ユーザ通知部
４０１…サービス運用者
４０２…サービス利用者
５０１…サービス接続部提供サーバ
Ａ０１…サービス提供システム
Ａ０２…サービス規制情報発行サーバ
【発明の属する技術分野】
本発明は、情報通信サービスシステムにおいてサービス利用者からのサービス利用要求の発行を規制する技術に関する。
【０００２】
【従来の技術】
従来技術では、特開平６−２８４１８７号公報に記載のようなものがある。即ち、加入者端末と各種のサービス及びまたは仮想私設網とを交換接続する複数のサービス交換ポイントと、このサービス交換ポイントを通信網を介して制御するシステム制御プロセッサとを備えたシステムにおいて、システム制御プロセッサは、サービスまたは仮想私設網の利用、または私設網の種別対応それぞれについてトラフィックを計測し、これがそれぞれに設定された閾値を超えたトラフィックについてサービス交換ポイントに対し規制信号を送信する。そして、サービス交換ポイントはその規制信号にしたがってそれぞれの要求呼を棄却する。こうして、過負荷の要因となっている特定のサービスまたは特定の顧客が使用している私設網に関する呼のみを排除し、他のサービス等に対する呼接続については、これを継続するという木目細かい処理をするものである。
【０００３】
また、特開平１０−９７４７６号公報には、エンドユーザから情報通信サービスの利用要求が発行されると、サービスプロバイダ側で、ネットワーク上におけるユーザの活動範囲を定めるための情報であるコミュニティに優先度を付与し、ネットワークを介して配送し、エンドユーザは、そのコミュニティに基づいて獲得、終了、移動、中断、復帰の処理を行なうことが示されている。このようにして、優先度の高いコミュニティを優先的に実行させる事により、企業等の閉域ネットワークの輻輳を事前に回避するものである。
【０００４】
また、特開平８−２１３９８１号公報には、ホストと複数の端末間の論理的な１対ｎ通信において、ホストと複数の端末間に論理的な別線を持たせ、輻輳通知を一斉に端末に送ることが示されている。
【０００５】
【発明が解決しようとする課題】
特開平６−２８４１８７号公報に記載の従来の方式では、サービス交換ポイントではサービス要求は棄却される。したがって、システム制御プロセッサの負荷は軽減される。しかし、加入者端末からのサービス交換ポイントへのサービス要求は依然として規制されない。一般に、加入者端末の数は膨大なものになるので、サービス交換ポイントでは加入者端末からのサービス要求を棄却するだけでも負荷は掛かることになる。ここでは、システム制御プロセッサの過負荷防止は出来、サービス交換ポイントへの事実上の負荷分散は出来ているが、サービス交換ポイントの過負荷の問題は残っている。
【０００６】
例えば、電話サービスの呼設定要求が集中する大災害のパニック時や、特定の時間帯に呼設定要求が集中するチケット販売等においては、加入者端末（サービス利用者）が複数接続されているサービス交換ポイントが過負荷になり、サービス交換ポイントに接続している加入者（サービス利用者）がサービスを利用できなくなるという惧れがある。
【０００７】
すなわち、特開平６−２８４１８７号公報記載に記載の従来の方法では、加入者端末（サービス利用者の端末）からの多量の呼設定要求（サービス利用要求）そのものの発生を規制することはできないため、サービス提供者側の設備であるサービス交換ポイントの過負荷制御については、何ら配慮されていない。また、加入者（サービス利用者）とサービス交換ポイントを接続するネットワークにも、多量の呼設定要求（サービス利用要求）が流れるため、加入者（サービス利用者）とサービス交換ポイントを接続するネットワークに負荷がかかるということについても配慮されていない。
【０００８】
また、サービス利用者が、サービス利用要求の拒否により再びサービス利用要求を発行すると、情報通信サービスシステムがさらに過負荷状態になり輻輳状態がいっこうに解除されないという事態にもなる。
【０００９】
また、特開平１０−９７４７６号公報に記載の従来の方式では、サービス利用者からのサービス利用要求の応答に規制情報を付与することにより、サービス利用要求の発行を制御するため、特定のサービス利用者からのサービス利用要求の発行は制御できるが、多数存在するサービス利用者から同時にサービス利用要求が発行された場合は、個別に規制情報を送る必要があるために、情報通信サービスシステムが過負荷状態になるという問題があった。
【００１０】
例えば、ショッピングサービスシステムにおいて、あるサービス利用者からのサービス利用要求に対する応答に規制情報を付与することにより、該サービス利用者からのサービス利用要求の発行は制御できる。しかし、他のサービス利用者には、その規制情報は配布されないため、他のサービス利用者は、ショッピングサービスシステムの規制情報によることなく、サービス利用要求を発行する。したがって、例えば、チケットの発売開始時は、サービス利用者からのサービス利用要求の発行が集中し、これにより、ショッピングサービスシステムが過負荷状態になるという問題があった。
【００１１】
また、ショッピングサービスシステムが過負荷状態に陥り、サービス利用要求に対する応答を返せなくなるという事態が発生した場合、サービス利用者は、サービス利用要求の再発行を試みる。これにより、さらにショッピングサービスシステムの過負荷状態を悪化させるということもあった。
【００１２】
また、携帯電話網の例においても、会社員の帰宅時間などサービス利用者によるサービス利用要求（ダイヤリング）が集中する時間帯になると、携帯電話網が過負荷状態となり、電話がつながらない事態が発生する。このとき、サービス利用者が再ダイヤルを行うと、携帯電話網の負荷状態をさらに悪化させてしまうという問題があった。
【００１３】
更に、特開平８−２１３９８１号公報では輻輳の通知に、データ転送とは別に設けられた論理的な別線が必要である。これはシステムリソースをこの分余分に必要とする。
【００１４】
以上のことから、本発明の目的は、情報通信サービスを提供するシステムおよびネットワークの過負荷状態をより良く回避することにある。
【００１５】
【課題を解決するための手段】
上記目的を達成するために、情報通信サービスを提供するシステムは、サービス提供部の負荷状況を測定してサービス規制情報を発行するか否かを決定するサービス規制制御部と、サービス規制情報を格納するサービス規制情報テーブルと、サービス利用クライアントにサービス規制情報を発行するサービス規制情報発行部とを備え、さらに、前記サービス規制制御部でサービス提供システムの負荷の状態がある閾値を越えることを検出したときに、前記サービス規制情報発行部により、負荷の大きさがある閾値を越える状態となるサービス要求をしたサービス利用クライアントだけでなく、他のサービス要求をしていないサービス利用クライアントにも前記サービス規制情報テーブルに格納されたサービス規制情報をデータと同じ経路で送信する手段を備えたものである。
【００１６】
また、前記サービス利用クライアントは、前記サービス提供システムから発行されるサービス規制情報を受け付けるサービス規制情報受付部と、サービス規制情報受付部で受け付けたサービス規制情報を格納するサービス利用要求発行制御テーブルと、サービス利用者から受け付けたサービス利用要求をサービス利用要求発行制御テーブルをもとに発行するか否かを決定するサービス利用要求発行制御部とを備え、前記サービス提供システムから前記サービス利用クライアントに発行されるサービス規制情報に基づいて、前記サービス利用クライアント側でサービス利用要求の発行を制御する手段を備えたものである。
【００１７】
【発明の実施の形態】
以下に本発明の一実施形態をショッピングサービスシステムを例に図１から図２０を用いて説明する。
【００１８】
図１はショッピングサービスシステムの全体構成を示している。このシステムでは、サービス提供システム１０１は、ショッピングサービスを提供するサービス提供部１０８と、サービス利用者４０２からのサービス利用要求を受け付けるサービス利用要求受付部１０７と、サービス提供部１０８の負荷に応じてサービス規制情報を発行するか否かを判断する基準値となる負荷閾値を格納する負荷閾値テーブル１０３と、負荷閾値テーブル１０３をもとにサービス規制情報を発行するか否かを判断するサービス規制制御部１０５と、サービス利用クライアントでのサービス規制方法を格納するサービス規制情報テーブル１０４と、サービス利用クライアントにサービス規制情報を同報するサービス規制情報同報部１０６、負荷閾値テーブル１０３およびサービス規制情報テーブル１０４にそれぞれ負荷閾値、サービス規制情報を設定する情報設定部１０２とを備えている。
【００１９】
また、サービス提供システムの構成は、他の実施形態として、図１０に示すように、サービスを提供するサービス提供システムＡ０１と、サービス規制情報を発行するサービス規制情報発行サーバＡ０２とに分離する形態でも良い。
【００２０】
サービス利用クライアント３０１は、サービス規制情報にもとづいてサービス提供システムに接続するサービス接続部３００を内蔵している。図２０に示すように、サービス利用クライアント３０１は、サービス提供システム１０１との接続を行う前に、サービス提供システム１０１との接続に必要なサービス接続部３００をあらかじめ用意しておく。具体的には必要なプログラムを処理に先立ってロードしておく。
【００２１】
このように、サービス接続部３００のプログラムをロード出来るようにしてあるのは次の理由による。
サービス利用クライアント３０１は複数の機種が想定され、必ずしも、後で詳述するサービス規制情報に基づいてサービス利用要求発行を抑制する機能を持っているとは限らない。したがって、このように初期に上記の機能をもつプログラムをロードするようにすることにより、各種のサービス利用クライアントに同様のサービス利用要求を抑制する機能を持たせることが出来るのである。
【００２２】
図２０は、サービス接続部３００の提供処理において、サービス提供システム１０１に負荷をかけないようにするために、別に設置したサービス接続部提供サーバ５０１により、サービス接続部を提供する（各クライアントに必要なプログラムを配送すること）方式を示している。サービス利用者４０２は、サービス利用クライアント３０１からサービス接続部提供サーバ５０１に接続して、サービス提供部３００を入手する。また、Ｊａｖａアプレットのようにインストールせずにサービス接続部提供サーバ５０１からダウンロードしてそのまま動作するソフトウェアであってもよい。図２０の実施例では、ネットワーク経由でサーバ接続部３００を入手する例を説明したが、ＣＤ−ＲＯＭなどのソフトウェア格納媒体やＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）によりあらかじめサービス利用クライアント３０１に設置されていてもよい。また、サービス接続部提供サーバ５０１がサービス提供システム１０１に含まれている場合は、サービス提供システム１０１の負荷が低いときにあらかじめサービス接続部３００を提供しておくことも可能である。
【００２３】
ここで、サービス提供システム（サーバ）１０１と図１０のサービス規制情報発行サーバＡ０２や、図２０のサービス接続部提供サーバ５０１などサービスを提供する側のシステムを上記の変形例を含めて情報サービスシステムと総称する。
【００２４】
サービス接続部３００の構成は、サービス提供システム１０１から発行されるサービス規制情報を受け付けるサービス規制情報受付部３０２と、サービス提供システム１０１から受け付けたサービス規制情報を格納するサービス利用要求発行制御テーブル３０３と、サービス利用者４０２からのサービス利用要求を受け付けるサービス利用要求受付部３０６と、サービス利用要求をサービス利用要求発行制御テーブル３０３をもとに発行するか否かを判断するサービス利用要求発行制御部３０５と、サービス利用要求を発行するサービス利用要求発行部３０４と、サービス規制情報を受け付けたときにサービス利用者４０２にその旨を通知するユーザ通知部３０７を備えている。
【００２５】
負荷閾値テーブル１０３は、図２に示すように、サービス提供部１０８の負荷をもとにサービス規制を開始することを判断する閾値であるサービス規制開始閾値Ｔ２０１と、サービス規制を解除することを判断する閾値であるサービス規制解除閾値Ｔ２０２を格納する。
【００２６】
ここでいうサービス提供部１０８の負荷とは、プロセッサのビジー率、メモリやバッファの利用率、ディスクスペースの使用率、ネットワークやディスクの入出力利用率などサービス提供部１０８がサービス利用者４０２に提供するサービスで使用するリソースの利用状況を示している。図２で示したショッピングサービスシステムではサービス提供部１０８の負荷としてサービス提供部１０８のプロセッサ利用率を用いた例であり、サービスの品質に影響する負荷であれば、上記のネットワークやディスクの入出力利用率など種類を問わない。
【００２７】
サービス規制情報テーブル１０４は、図３に示すように、サーバ種別Ｔ３０１と、サービス種別Ｔ３０２と、規制種別Ｔ３０３としてサービス利用要求発行抑止と、例えば「ただ今、大変混み合っていますので、本サービスはご利用になれません。しばらくたってから、再度ご利用下さい。」のようなサービス利用者にサービス利用不可能を通知する規制メッセージＴ３０４を格納する。
【００２８】
サービス規制制御部１０５は、定期的にサービス提供部１０８の負荷状況を測定し、その測定結果と負荷閾値テーブル１０３をもとにサービス規制情報を発行するか否かを決定する。この処理を図５に示す。この処理の各ステップを以下に示す。
【００２９】
サービス規制制御部１０５は、サービス提供部１０８の負荷を測定し（Ｓ５０１）、現在のサービス規制状態を判断し（Ｓ５０２）、現在のサービス規制状態がサービス規制中でなければ、サービス提供部１０８の負荷と負荷閾値テーブル１０３のサービス規制開始閾値Ｔ２０１を比較する（Ｓ５０３）。サービス提供部１０８の負荷が負荷閾値テーブル１０３のサービス規制開始閾値Ｔ２０１を超えていなければ、終了する。サービス提供部１０８の負荷が負荷閾値テーブル１０３のサービス規制開始閾値Ｔ２０１を超えていれば、サービス規制状態を「サービス規制中」に設定し（Ｓ５０４）、サービス規制情報テーブル１０４から規制情報Ｔ３０１〜Ｔ３０４を取得し（Ｓ５０５）、サービス規制情報同報部１０６にサービス規制要求の発行を依頼する（Ｓ５０６）。
【００３０】
Ｓ５０２において、現在のサービス規制状態がサービス規制中であれば、サービス提供部１０８の負荷と負荷閾値テーブル１０３のサービス規制解除閾値Ｔ２０２を比較する（Ｓ５０７）。サービス提供部１０８の負荷が負荷閾値テーブル１０３のサービス規制解除閾値Ｔ２０２を下回っていなければ、終了する。サービス提供部１０８の負荷が負荷閾値テーブル１０３のサービス規制解除閾値Ｔ２０２を下回っていれば、サービス規制状態を「サービス非規制中」に設定し（Ｓ５０８）、サービス規制情報同報部１０６にサービス規制解除要求の発行を依頼する（Ｓ５０９）。ここで、サービス規制情報同報部１０６に発行を依頼するサービス規制情報には、サービス規制情報テーブル１０４の内容を含むものとする。
【００３１】
サービス規制情報同報部１０６は、サービス規制制御部１０５からの依頼を受け、サービス利用クライアント３０１にサービス規制情報を発行する。この処理を図６に示す。この処理の各ステップを以下に示す。
【００３２】
サービス規制情報同報部１０６は、サービス規制制御部１０５からの依頼の内容を判定し（Ｓ６０１）、サービス規制要求の発行依頼であれば、サービス利用クライアント３０１にサービス規制要求を発行する（Ｓ６０２）。サービス規制制御部１０５からの依頼の内容がサービス規制解除要求の発行依頼であれば、サービス利用クライアント３０１にサービス規制解除要求を発行する（Ｓ６０３）。
【００３３】
ここで、多数存在するサービス利用クライアント３０１にサービス規制要求あるいはサービス規制解除要求を一斉に発行する手段としては、例えば、ＩＰマルチキャストプロトコルと呼ばれる同報配信プロトコルを使用する。ＩＰマルチキャストプロトコルとは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルにより実現されるもので、サービス規制情報同報部１０６は、サービス規制情報をマルチキャストアドレスに送信することで、多数存在するサービス利用クライアント３０１に同報送信することができる。
【００３４】
ＩＰマルチキャストについては「コンピュータ＆ネットワークＬＡＮ」１９９９、１、ＶＯＬ．１７オーム社 ６ページから１０ページに説明がある。かいつまんでいえば、以下の様である。情報発信側は特定のマルチキャストアドレスに向けて１つのデータを送信するだけで良い。受信者はＩＧＭＰを利用してマルチキャスト配信を受けたいという要求をルータに伝える。ルータはマルチキャストルーティングによって、受信を希望するユーザの存在する方向へのみ自動的にコピーしながら配信する。このようにして大量のデータを多数のサイトに転送することが出来る。マルチキャストではデータの到着時間に多少の差が出るものの、ほぼ同時期の着信が期待出来る。
【００３５】
ここでいう、サービス規制情報同報とは、次節のものも含み、マルチキャストという手段に限定されず、また全くの同時性も要求してはいない。送信者が一度の送信を意識するだけで同一内容が多数の受信者に配送されることを意味している。
【００３６】
多数存在するサービス利用クライアント３０１に対してサービス規制情報を同報送信する手段として、前記ＩＰマルチキャストプロトコル以外にも衛星デジタル放送や地上波デジタル放送、携帯電話基地局など、同報送信することが可能であれば手段は問わない。
【００３７】
ここで、サービス規制情報の同報は、通常のデータの送受信と同じ経路を取り、特別に同報のための別線（論理的であっても）必要としない。なお、ここで同じ経路というのはＩＰアドレスレベルで同一の経路という意味で使用している。
【００３８】
サービス規制情報受付部３０２は、サービス規制情報同報部１０６からのサービス規制情報を受け付け、その内容をサービス利用要求発行制御テーブル３０３に格納する。この処理を図７に示す。この処理の各ステップを以下に示す。また、サービス利用要求発行制御テーブル３０３の内容を図１９に示す。
【００３９】
サービス規制情報受付部３０２は、サービス規制情報同報部１０６から受信した内容を判定し（Ｓ７０１）、サービス規制要求であれば、その内容をサービス利用要求発行制御テーブル３０３に格納する（Ｓ７０２）。サービス利用要求発行制御テーブル３０３に格納する内容は、図１９に示すように、サービス規制情報同報部１０６から受信した内容（ＴＪ０１、ＴＪ０２、ＴＪ０４の指す内容）と、該サービス提供システムの該サービスがサービス規制中であることを示すサービス状態ＴＪ０３と、サービス規制要求を受け付けた時刻を示す受付時刻ＴＪ０５である。複数の種類のサービスのサービス提供システムから同時にサービス規制要求を受け付けた場合は、これらの情報を格納する領域をサービス毎に複数持つ。サービス規制情報同報部１０６から受信した内容がサービス規制解除要求であれば、サービス利用要求発行制御テーブル３０３から該サービス提供システムの該サービスのサービス規制情報（ＴＪ０１〜ＴＪ０５）を削除する（Ｓ７０３）
サービス利用要求発行制御部３０５は、サービス利用要求受付部３０６からのサービス利用要求発行の依頼を受け付け、サービス利用要求発行制御テーブル３０３をもとに、サービス提供システム１０１へのサービス利用要求の発行を制御する。この処理を図８に示す。この処理の各ステップを以下に示す。
【００４０】
サービス利用要求発行制御部３０５は、サービス利用要求を発行するサービス提供システムおよびサービスの規制状態をサービス利用要求発行テーブル３０３のサービス状態ＴＪ０３をもとに判定する（Ｓ８０１）。サービス利用要求を発行するサービス提供システムおよびサービスがサービス規制中でなければ、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（Ｓ８０２）。サービス利用要求を発行するサービス提供システムおよびサービスがサービス規制中であれば、サービス利用要求発行制御テーブル３０３からサービス規制情報を取得し（Ｓ８０３）、ユーザ通知部３０７に規制メッセージの表示を依頼する（Ｓ８０４）。
【００４１】
規制メッセージの表示依頼は、ユーザ通知部３０７によって画面に表示される。そのイメージを図４に示す。即ち、サービス利用ボタンＤ４０２とともに、図３の規制メッセージＴ３０４に記憶されたメッセージが表示される。
【００４２】
ここで、規制メッセージは、図４に示したように画面に表示される形態でも良いし、音声によって通知する形態でも良く、サービス利用者に該サービス提供システムの該サービスが規制されていることが通知できる形態であれば種類を問わない。
【００４３】
図９では、サービス規制情報テーブル１０４の規制種別がサービス利用要求発行抑止Ｔ２０３の場合のサービス提供システム１０１、サービス利用クライアント３０１間のタイミングチャートを示している。
【００４４】
サービス提供システム１０１のサービス提供部１０８の負荷がサービス規制開始閾値Ｔ２０１を超えてサービス規制中になると（Ｓ９０１）、サービス規制要求が発行される（Ｓ９０２）。サービス利用者４０２が該サービス提供システムの該サービスにサービス利用要求を発行する（Ｓ９０３）。しかし、サービス利用クライアント３０１では、該サービス提供システムの該サービスがサービス規制中であることを認識しているため、サービス提供システム１０１へのサービス利用要求の発行は行わず、サービス利用者にサービス利用不可を通知する（Ｓ９０４）。この時、図４に示したように、サービスが利用できない旨の内容がサービス利用者４０２に通知される。サービス利用者４０２は、サービス利用不可の通知を受けて、サービス利用要求の発行を繰り返す（Ｓ９０５〜Ｓ９０６）。サービス提供システム１０１のサービス規制中が解除され（Ｓ９０７）、サービス規制解除要求が発行される（Ｓ９０８）。サービス利用クライアント３０１は、サービス規制解除要求を受け付けたため、サービス利用者４０２からのサービス利用要求の発行依頼を受け付け（Ｓ９０９）、サービス提供システム１０１へサービス利用要求を送信する（Ｓ９１０）。
【００４５】
また、前述したショッピングサービスシステムにおいて、サービス規制情報テーブル１０４を図１１のようにする方法もある。図３との違いは、規制種別ＴＢ０３がサービス利用要求発行固定時間抑止になったこと、規制メッセージＴＢ０４の内容が「…、ｘｘｘ後、…」になり、ｘｘｘには後述する抑止時間ＴＢ０５の値が埋め込まれること、規制情報種別として新たに抑止時間ＴＢ０５が設けられたこと、である。この方法では、サービス提供システム１０１から発行されるサービス規制情報に抑止時間ＴＢ０５を付加することにより、サービス利用クライアント３０１は、抑止時間ＴＢ０５の間、該サービス提供システムの該サービスへのサービス利用要求の発行を抑止する。サービス利用クライアント３０１は、抑止時間ＴＢ０５を経過すると、サービス利用者４０２からのサービス利用要求をサービス提供システム１０１へ発行するため、サービス提供システム１０１からのサービス規制解除要求は不要となる。
【００４６】
サービス規制情報テーブル１０４の規制種別ＴＢ０３がサービス利用要求発行固定時間抑止の場合のサービス利用要求発行制御部３０５の処理を図１３に示す。この処理の各ステップを以下に示す。
【００４７】
サービス利用要求発行制御部３０５は、サービス利用要求受付部３０６からサービス利用要求の発行依頼を受け付けると、サービス利用要求の発行先のサービス提供システムおよびサービスがサービス規制中か否かをサービス利用要求発行テーブル３０３をもとに判定する（ＳＤ０１）。サービス利用要求を発行するサービス提供システムおよびサービスがサービス規制中でなければ、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（ＳＤ０２）。サービス利用要求を発行するサービス提供システムおよびサービスがサービス規制中であれば、サービス利用要求発行制御テーブル３０３からサービス規制情報を取得し（ＳＤ０３）、サービス規制要求の受付時刻ＴＪ０５から現在時刻までの時間を求め、その時間が抑止時間を超えているかどうか判定する（ＳＤ０４）。抑止時間を超えていれば、サービス利用要求発行制御テーブル３０３から該サービス提供システムの該サービスのサービス規制情報を削除し（ＳＤ０５）、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（ＳＤ０６）。
【００４８】
抑止時間を超えていなければ、ユーザ通知部３０７に規制メッセージの表示を依頼する（ＳＤ０７）。規制メッセージの表示依頼は、ユーザ通知部３０７によって画面に表示される。そのイメージを図１２に示す。即ち、サービス利用ボタンと共に、図１１の規制メッセージＴＢ０４に抑止時間ＴＢ０５を埋め込んだメッセージが画面に表示される。
【００４９】
図１４では、サービス規制情報テーブル１０４の規制種別ＴＢ０３がサービス利用要求発行固定時間抑止の場合のサービス提供システム１０１、サービス利用クライアント３０１間のタイミングチャートを示している。図９との違いは、サービス提供システム１０１のサービス提供部１０８の負荷がサービス規制開始閾値Ｔ２０１を超えてサービス規制中になり（ＳＥ０１）、サービス規制要求が発行された時刻（ＳＥ０２）から、抑止時間の間は、サービス利用者４０２からのサービス利用要求をサービス提供システム１０１に発行せず、サービス利用クライアント３０１で抑止することである（ＳＥ０３〜ＳＥ０６）。抑止時間を超えてからのサービス利用要求は、サービス提供システム１０１へ発行する（ＳＥ０８〜ＳＥ０９）。
【００５０】
また、図１１のサービス規制情報テーブルにおいて、抑止時間ＴＢ０５を固定ではなく、サービス提供部１０８の負荷に応じて可変にする方法もことも可能である。サービス提供部１０８の負荷はサービス規制制御部１０５によって定期的に測定されるため、短時間で負荷が急激に上がる場合がある。これを考慮して、負荷閾値テーブル１０３は、図１５のようにサービス提供部１０８の負荷に応じて、抑止時間をサービス規制開始閾値に対してそれぞれ設定可能とする。即ち、規制開始閾値を高いときは負荷集中が高いために負荷集中の回復の時間が長いものとして抑止時間を長くする。この場合、サービス規制情報テーブル１０４は、図１６のように規制種別ＴＧ０３はサービス利用要求発行可変時間抑止となり、かつ、図１１には存在した抑止時間ＴＢ０５はなくなる。また、サービス利用クライアント３０１に発行されるサービス規制情報は、サービス規制情報テーブル３０１とサービス提供部１０８の負荷に対応した負荷閾値テーブル１０３の抑止時間とを含む内容となる。
【００５１】
また、あらかじめサービス利用者にランクを付けておき、サービス提供部１０８の負荷が規制開始閾値Ｔ２０１を超えた場合、ランクの低いサービス利用者のサービス利用要求の発行を抑止する、という方法も可能である。サービス規制情報テーブル１０４は、図１７に示すように、規制種別ＴＨ０３がサービス利用要求発行ランク抑止となり、新たに規制対象ランクＴＨ０５が追加される。本実施例で示しているランクは、Ａが一番高く、Ｃが一番低いランクである。ここでいう、サービス利用者のランクとは、ショッピングサービスシステムにおいては、過去の商品購入実績など、売り上げに寄与するかどうかをランク付けしたものである。ランク付けの方法は、過去の商品購入実績から自動的に付与される方法でも良いし、定期的にサービス運用者が過去の商品購入実績を参照し、手動で設定する方法でも良く、方法は問わない。サービス提供システム１０１から発行されるサービス規制情報には、この規制対象ランクＴＨ０５が付与され、サービス利用クライアント３０１のサービス利用要求発行制御部３０５では、自分のランクがサービス提供システム１０１から発行されたサービス規制情報の規制対象ランクに一致するかどうかを判定し、サービス利用要求を発行するかどうかを決定する。
【００５２】
サービス規制情報テーブル１０４の規制種別ＴＨ０３がサービス利用要求発行ランク抑止の場合のサービス利用要求発行制御部３０５の処理を図１８に示す。この処理の各ステップを以下に示す。
【００５３】
サービス利用要求発行制御部３０５は、サービス利用要求受付部３０６からサービス利用要求の発行依頼を受け付けると、サービス利用要求を発行するサービス提供システムおよびサービスの規制状態を判定する（ＳＩ０１）。サービス提供システムのサービスがサービス規制中でない場合、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（ＳＩ０４）。サービス提供システムのサービスがサービス規制中である場合、サービス利用要求発行制御テーブル３０３からサービス規制情報を取得し（ＳＩ０２）、サービス規制対象のランクが自分のランクと一致するか否かを判定する（ＳＩ０３）。サービス規制対象のランクが自分のランクと一致しなければ、サービス利用要求の発行をサービス利用要求発行部３０４に依頼する（ＳＩ０４）。サービス規制対象のランクが自分に一致すれば、ユーザ通知部３０７に規制メッセージの表示を依頼する（ＳＩ０５）。
【００５４】
以上、サービス規制情報テーブル１０４の規制種別毎に４種類の方法を説明した。この４種類の方法は、例えば、サービス利用要求発行可変時間抑止とサービス利用要求発行ランク抑止を組み合わせて、サービス提供部１０８の負荷に応じて、規制対象とするサービス利用者のランクを可変にするなど、組み合わせて実現する方法も可能である。
【００５５】
本発明により、ショッピングサービスシステムにおいて、サービス利用クライアントでは、サービス提供システムに接続するためのサービス接続部を具備しているため、サービス提供システムが過負荷状態になる前に、サービス規制要求をサービス利用クライアントに発行し、サービス利用クライアントでのサービス利用要求の発行を制御して、サービス提供システムが過負荷状態になることを未然に防ぐことが可能となる。
【００５６】
また、本発明は携帯電話網などの電話やデータ通信サービスに対してもそのまま適用可能であり、同様の効果を得ることができる。
【００５７】
【発明の効果】
本発明では、情報通信サービスシステムのサービス提供システムに負荷がかかることなく、サービス利用クライアントからのサービス利用要求の発行自体を規制することが可能となる。また、サービス提供システムが過負荷状態になることを未然に防ぐことが可能となる。
【図面の簡単な説明】
【図１】本発明の実施例を示したショッピングサービスシステムのブロック図である。
【図２】負荷閾値テーブルである。
【図３】サービス規制情報テーブルである。
【図４】サービス規制中の旨をサービス利用者に通知するサービス利用画面のイメージ図である。
【図５】サービス規制制御部の処理を示すフローチャートである。
【図６】サービス規制情報発行部の処理を示すフローチャートである。
【図７】サービス規制情報受付部の処理を示すフローチャートである。
【図８】サービス利用要求発行制御部の処理を示すフローチャートである。
【図９】サービス提供システム、サービス利用クライアント間のタイミングチャートである。
【図１０】本発明の実施例を示したショッピングサービスシステムのブロック図において、サービス規制情報発行部を別サーバに配置した場合のブロック図である。
【図１１】サービス規制情報テーブルである。
【図１２】サービス規制中の旨をサービス利用者に通知するサービス利用画面のイメージ図である。
【図１３】サービス利用要求発行制御部の処理を示すフローチャートである。
【図１４】サービス提供システム、サービス利用クライアント間のタイミングチャートである。
【図１５】負荷閾値テーブルである。
【図１６】サービス規制情報テーブルである。
【図１７】サービス規制情報テーブルである。
【図１８】サービス利用要求発行制御部の処理を示すフローチャートである。
【図１９】サービス利用要求発行制御テーブルである。
【図２０】本発明におけるサービス接続部を持ったサービスクライアントを持つシステムの例を示す図である。
【符号の説明】
１０１…サービス提供システム
１０２…情報設定部
１０３…負荷閾値テーブル
１０４…サービス規制情報テーブル
１０５…サービス規制制御部
１０６…サービス規制情報同報部
１０７…サービス利用要求受付部
１０８…サービス提供部
２０１…ネットワーク
３００…サービス接続部
３０１…サービス利用クライアント
３０２…サービス規制情報受付部
３０３…サービス利用要求発行制御テーブル
３０４…サービス利用要求発行部
３０５…サービス利用要求発行制御部
３０６…サービス利用要求受付部
３０７…ユーザ通知部
４０１…サービス運用者
４０２…サービス利用者
５０１…サービス接続部提供サーバ
Ａ０１…サービス提供システム
Ａ０２…サービス規制情報発行サーバ
Claims (12)
- 複数のクライアントと、サービスを提供する複数のサーバとを有する情報処理システムであって、
それぞれの前記サーバは、
自サーバが提供するサービスに対応するサービス識別子と、前記サービスの利用要求を規制する規制情報とを対応付けて記憶される第１の記憶装置と、
自サーバの負荷状態が所定の値を超えた場合に、前記第１の記憶装置に記憶された前記サービス識別子と、該サービス識別子に対応付けて記憶された前記規制情報とを複数の前記クライアントに同報送信する規制情報同報部とを有し、
前記サービス識別子と前記規制情報とを受信したそれぞれの前記クライアントは、
それぞれの前記サーバが提供するサービスに対しての利用要求が発行可能で、利用者からのサービスの利用要求に応じて、当該サービスを提供するサーバに対して当該サービスの利用要求を送信するサービス利用要求発行部と、
前記サービス識別子と前記規制情報とを対応付けて記憶される第２の記憶装置と、
利用者から利用要求がされたサービスが、前記第２の記憶装置に記憶された前記サービス識別子から特定されるサービスと一致し、かつ当該サービス識別子と対応付けて規制情報が記憶されている場合に、前記利用者からの利用要求に基づいて、当該サービスを提供する前記サーバに送信される当該サービスの利用要求を規制する利用要求発行制御部
とを有することを特徴とする情報処理システム。 - 前記負荷状態は前記サービスを提供する前記サーバのリソースの利用率から求められることを特徴とする請求項１記載の情報処理システム。
- 前記規制情報を同報送信する対象である複数の前記クライアントは、前記サーバが提供するサービスに対しての利用要求を出していないクライアントを含むことを特徴とする請求項１記載の情報処理システム。
- 前記規制情報には規制メッセージを含み、
前記規制情報を送信された前記クライアントは、
利用者からのサービスの利用要求があった場合に、前記利用者に対し前記規制メッセージに対応する通知を行うユーザ通知部
を有することを特徴とする請求項１記載の情報処理システム。 - 複数のクライアントと、サービスを提供する複数のサーバとを有する情報処理システムであって、
それぞれの前記サーバは、
自サーバが提供するサービスに対応するサービス識別子と、前記サービスの利用要求を規制する規制情報と、規制対象ランクとを対応付けて記憶される第１の記憶装置と、
自サーバの負荷状態が所定の値を超えた場合に、前記第１の記憶装置に記憶された前記サービス識別子と、該サービス識別子に対応付けて記憶された前記規制情報と、前記規制対象ランクとを複数の前記クライアントに同報送信する規制情報同報部とを有し、
前記サービス識別子と前記規制情報と前記規制対象ランクとを受信したそれぞれの前記クライアントは、
それぞれの前記サーバが提供するサービスに対しての利用要求が発行可能で、利用者からのサービスの利用要求に応じて、当該サービスを提供するサーバに対して当該サービスの利用要求を送信するサービス利用要求発行部と、
前記サービス識別子と前記規制情報と前記規制対象ランクとを対応付けて記憶される第２の記憶装置と、
利用者から利用要求がされたサービスが、前記第２の記憶装置に記憶された前記サービス識別子から特定されるサービスと一致し、かつ前記利用者に付けられたランクが、前記第２の記憶装置に記憶された前記規制対象ランクと一致し、かつ当該サービス識別子と対応付けて規制情報が記憶されている場合に、前記利用者からの利用要求に基づいて、当該サービスを提供する前記サーバに送信される当該サービスの利用要求を規制する利用要求発行制御部
とを有することを特徴とする情報処理システム。 - 前記サーバの前記負荷状態に応じて、同報送信する前記規制対象ランクを変更することを特徴とする請求項５記載の情報処理システム。
- サービスを提供する複数のサーバと、それぞれの前記サーバが提供するサービスに対しての利用要求が発行可能な複数のクライアントに対する情報処理方法であって、
それぞれの前記サーバは、
自サーバの負荷状態が所定の値を超えた場合に、自サーバが提供するサービスに対応するサービス識別子と、前記サービスの利用要求を規制する規制情報とを対応付けて複数の前記クライアントに同報送信し、
前記サービス識別子と前記規制情報とを受信したそれぞれの前記クライアントは、
前記サービス識別子と前記規制情報とを対応付けて記憶し、
利用者から利用要求がされたサービスが、前記記憶された前記サービス識別子から特定されるサービスと一致し、かつ当該サービス識別子と対応付けて規制情報が記憶されている場合に、前記利用者からの利用要求に基づいて、当該サービスを提供する前記サーバに送信される当該サービスの利用要求を規制する
ことを特徴とする情報処理方法。 - 前記負荷状態は前記サービスを提供する前記サーバのリソースの利用率から求められることを特徴とする請求項７記載の情報処理方法。
- 前記規制情報を同報送信する対象である複数の前記クライアントは、前記サーバが提供するサービスに対しての利用要求を出していないクライアントを含むことを特徴とする請求項７記載の情報処理方法。
- 前記規制情報には規制メッセージを含み、
前記規制情報を送信された前記クライアントは、
利用者からのサービスの利用要求があった場合に、前記利用者に対し前記規制メッセージに対応する通知を行う
ことを特徴とする請求項７記載の情報処理方法。 - サービスを提供する複数のサーバと、それぞれの前記サーバが提供するサービスに対しての利用要求が発行可能な複数のクライアントに対する情報処理方法であって、
それぞれの前記サーバは、
自サーバの負荷状態が所定の値を超えた場合に、自サーバが提供するサービスに対応するサービス識別子と、前記サービスの利用要求を規制する規制情報と、規制対象ランクとを対応付けて、複数の前記クライアントに同報送信し、
前記サービス識別子と前記規制情報と前記規制対象ランクとを受信したそれぞれの前記クライアントは、
前記サービス識別子と前記規制情報と前記規制対象ランクとを対応付けて記憶し、
利用者から利用要求がされたサービスが、前記記憶された前記サービス識別子から特定されるサービスと一致し、かつ前記利用者に付けられたランクが、前記記憶された前記規制対象ランクと一致し、かつ当該サービス識別子と対応付けて規制情報が記憶されている場合に、前記利用者からの利用要求に基づいて、当該サービスを提供する前記サーバに送信される当該サービスの利用要求を規制する
ことを特徴とする情報処理方法。 - 前記サーバの前記負荷状態に応じて、同報送信する前記規制対象ランクを変更することを特徴とする請求項１１記載の情報処理方法。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24416699A JP3636947B2 (ja) | 1999-08-31 | 1999-08-31 | 情報サービスシステム、サービス利用クライアント及びサービス規制方法 |
| US09/644,892 US7007087B1 (en) | 1999-08-31 | 2000-08-24 | System and method for rejecting services in a information service system |
| DE60021812T DE60021812T2 (de) | 1999-08-31 | 2000-08-25 | System und Verfahren zur Zurückweisung von Dienstanforderungen in einem Nachrichtendienstsystem |
| EP00307342A EP1081917B1 (en) | 1999-08-31 | 2000-08-25 | System and method for rejecting service requests in an information service system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24416699A JP3636947B2 (ja) | 1999-08-31 | 1999-08-31 | 情報サービスシステム、サービス利用クライアント及びサービス規制方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001067314A JP2001067314A (ja) | 2001-03-16 |
| JP3636947B2 true JP3636947B2 (ja) | 2005-04-06 |
Family
ID=17114762
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP24416699A Expired - Fee Related JP3636947B2 (ja) | 1999-08-31 | 1999-08-31 | 情報サービスシステム、サービス利用クライアント及びサービス規制方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7007087B1 (ja) |
| EP (1) | EP1081917B1 (ja) |
| JP (1) | JP3636947B2 (ja) |
| DE (1) | DE60021812T2 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2460208A1 (en) | 2001-09-28 | 2003-04-10 | British Telecommunications Public Limited Company | An integrity manager for delaying client service requests |
| JP3904435B2 (ja) * | 2001-11-28 | 2007-04-11 | 株式会社日立製作所 | Ｗｅｂサービス向け輻輳制御装置及び方法 |
| JP4469535B2 (ja) * | 2002-01-10 | 2010-05-26 | 富士通株式会社 | 情報処理システム、情報処理装置並びにアクセス分散方法 |
| US7529839B2 (en) * | 2003-03-24 | 2009-05-05 | Nokia Corporation | Request redirection handling in IMC |
| US20050108333A1 (en) * | 2003-10-31 | 2005-05-19 | Martin Scholz | Blocking input with delayed message |
| JP4548125B2 (ja) * | 2005-01-18 | 2010-09-22 | 日本電気株式会社 | 輻輳制御方法および装置 |
| CN100438499C (zh) * | 2005-04-30 | 2008-11-26 | 华为技术有限公司 | 组播节目的转发处理方法及进行组播转发的接入设备 |
| JP4701018B2 (ja) * | 2005-06-22 | 2011-06-15 | キヤノン株式会社 | 通信装置及び通信方法 |
| JP2007249445A (ja) * | 2006-03-15 | 2007-09-27 | Hitachi Ltd | クラスタシステムの負荷分散制御方法およびその装置 |
| EP2096884A1 (en) * | 2008-02-29 | 2009-09-02 | Koninklijke KPN N.V. | Telecommunications network and method for time-based network access |
| EP2234397A1 (en) | 2009-03-24 | 2010-09-29 | Thomson Licensing | Methods for delivering and receiving interactive multimedia data attached to an audio video content |
| JP2011239215A (ja) * | 2010-05-11 | 2011-11-24 | Nippon Telegr & Teleph Corp <Ntt> | 輻輳制御方法、加入者呼制御装置、およびエッジルータ |
| JP5511707B2 (ja) * | 2011-02-17 | 2014-06-04 | 日本電信電話株式会社 | マルチキャスト通信システム及びマルチキャスト通信制御方法 |
| CN104426936A (zh) * | 2013-08-22 | 2015-03-18 | 中兴通讯股份有限公司 | 一种负载均衡方法及系统 |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0521892A1 (en) * | 1990-03-29 | 1993-01-13 | Micro Technology, Inc. | Method and apparatus for scheduling access to a csma communication medium |
| US5313454A (en) * | 1992-04-01 | 1994-05-17 | Stratacom, Inc. | Congestion control for cell networks |
| US5568612A (en) * | 1992-11-18 | 1996-10-22 | Canon Kabushiki Kaisha | Method and apparatus for advertising services of two network servers from a single network node |
| JPH06284187A (ja) | 1993-03-29 | 1994-10-07 | Nec Corp | 交換接続制御方式 |
| US5367523A (en) * | 1993-08-26 | 1994-11-22 | International Business Machines Corporation | Adaptive rate-based congestion and flow control in packet communications networks |
| DE69324274T2 (de) * | 1993-10-23 | 1999-10-14 | International Business Machines Corp. | Selektive überlastungsregelung für informationsnetze |
| US5544327A (en) * | 1994-03-01 | 1996-08-06 | International Business Machines Corporation | Load balancing in video-on-demand servers by allocating buffer to streams with successively larger buffer requirements until the buffer requirements of a stream can not be satisfied |
| US5553083B1 (en) * | 1995-01-19 | 2000-05-16 | Starburst Comm Corp | Method for quickly and reliably transmitting frames of data over communications links |
| JPH08213981A (ja) | 1995-02-02 | 1996-08-20 | Fujitsu Ltd | １対ｎ簡易輻輳制御方法 |
| US5812526A (en) * | 1995-12-21 | 1998-09-22 | Industrial Technology Research Institute | Traffic control mechanism in ATM communications network |
| US5799002A (en) * | 1996-07-02 | 1998-08-25 | Microsoft Corporation | Adaptive bandwidth throttling for network services |
| JPH1097476A (ja) | 1996-09-19 | 1998-04-14 | Nippon Telegr & Teleph Corp <Ntt> | コミュニティ優先制御方法及びシステム |
| US5938732A (en) * | 1996-12-09 | 1999-08-17 | Sun Microsystems, Inc. | Load balancing and failover of network services |
| JPH10336202A (ja) * | 1997-06-03 | 1998-12-18 | Fuji Xerox Co Ltd | データ転送装置および方法 |
| US5928331A (en) * | 1997-10-30 | 1999-07-27 | Matsushita Electric Industrial Co., Ltd. | Distributed internet protocol-based real-time multimedia streaming architecture |
| US6745237B1 (en) * | 1998-01-15 | 2004-06-01 | Mci Communications Corporation | Method and apparatus for managing delivery of multimedia content in a communications system |
| US6006269A (en) * | 1998-03-11 | 1999-12-21 | Hewlett-Packard Company | Admission control system with messages admitted or deferred for re-submission at a later time on a priority basis |
| US6539000B1 (en) * | 1998-07-21 | 2003-03-25 | Kabushiki Kaisha Toshiba | Multicast communication method and apparatus |
| US6360270B1 (en) * | 1998-11-16 | 2002-03-19 | Hewlett-Packard Company | Hybrid and predictive admission control strategies for a server |
| US6490249B1 (en) * | 1998-12-01 | 2002-12-03 | Nortel Networks Limited | Adaptive connection admission control scheme for packet networks |
| US6349340B1 (en) * | 2000-01-13 | 2002-02-19 | Exigent International, Inc. | Data multicast channelization |
-
1999
- 1999-08-31 JP JP24416699A patent/JP3636947B2/ja not_active Expired - Fee Related
-
2000
- 2000-08-24 US US09/644,892 patent/US7007087B1/en not_active Expired - Fee Related
- 2000-08-25 EP EP00307342A patent/EP1081917B1/en not_active Expired - Lifetime
- 2000-08-25 DE DE60021812T patent/DE60021812T2/de not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| DE60021812D1 (de) | 2005-09-15 |
| EP1081917A3 (en) | 2003-07-23 |
| DE60021812T2 (de) | 2006-06-22 |
| EP1081917B1 (en) | 2005-08-10 |
| JP2001067314A (ja) | 2001-03-16 |
| EP1081917A2 (en) | 2001-03-07 |
| US7007087B1 (en) | 2006-02-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3636947B2 (ja) | 情報サービスシステム、サービス利用クライアント及びサービス規制方法 | |
| US7796520B2 (en) | System and methods for announcing and locating services in a distributed peer-to-peer network | |
| EP1320237B1 (en) | System and method for controlling congestion in networks | |
| US5970126A (en) | Communication method and system | |
| JP3857907B2 (ja) | 情報挿入サービス提供システム、情報挿入方法及び通信ネットワーク | |
| JP4541563B2 (ja) | 無線プッシュツートークインターネット放送 | |
| US20050089053A1 (en) | Virtual queuing support system and method | |
| KR100566263B1 (ko) | 스케쥴 내용에 따라 메신저 상태 정보를 변경하는 메신저서비스 제공 시스템 및 방법 | |
| US8068866B2 (en) | Group communication server | |
| CN101132373A (zh) | 为流提供服务质量的方法 | |
| JPH11504471A (ja) | 非対称型ハイブリッド・アクセス・システム及び方法 | |
| CN101854287B (zh) | 一种p2p流量优化方法及装置 | |
| JP2008234165A (ja) | コンテンツ配信システム、Ｗｅｂアプリケーションサーバ、コンテンツ配信方法、およびプログラム | |
| CA2581199C (en) | System and methods for announcing and locating services in a distributed peer-to-peer network | |
| CN115829233A (zh) | 一种客服分配方法、装置、通信设备及可读存储介质 | |
| CN103516758A (zh) | 资源路由、呼叫中心坐席的业务请求处理方法及装置 | |
| CN112616143B (zh) | 一种分配通信号码的方法、装置、电子设备及存储介质 | |
| CN112925946B (zh) | 一种业务数据存储方法、装置及电子设备 | |
| JP7124779B2 (ja) | 管理装置、端末装置、およびプログラム | |
| CN111147678A (zh) | 接入电话的分配方法及存储介质 | |
| JP4897644B2 (ja) | 端末に対するアクセス数制御方法、端末、制御サーバ及びプログラム | |
| JP3303043B2 (ja) | キャンセル待ち情報案内サービス方法および装置 | |
| US6728359B1 (en) | Network with distributed service control point functionality | |
| CN115022110B (zh) | 消息分发方法、可读介质以及电子设备 | |
| JP2011109262A (ja) | コールセンタサーバ、帯域制御プログラム、及びコールセンタシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040810 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041012 |
|
| 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: 20041228 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050106 |
|
| LAPS | Cancellation because of no payment of annual fees |