JP2002082906A

JP2002082906A - 前処理装置とその装置を利用可能なリクエスト処理装置およびリクエスト処理方法

Info

Publication number: JP2002082906A
Application number: JP2000269700A
Authority: JP
Inventors: Shoichi Hayashi; 彰一林; Hideaki Nishikawa; 英彰西川; Toshio Inadate; 利雄稲舘; Tadahiro Kanai; 忠裕金井; Katsumasa Sasaki; 功昌佐々木; Haruhiko Kondo; 治彦近藤; Shoichi Akimoto; 祥一秋本
Original assignee: Sony Communications Network Corp
Current assignee: Sony Network Communications Inc
Priority date: 2000-09-06
Filing date: 2000-09-06
Publication date: 2002-03-22

Abstract

(57)【要約】【課題】人気のあるサイトへアクセスが集中すると、
ユーザリクエストに対するサーバの反応が遅くなるか、
最悪の場合サーバがダウンする。【解決手段】リクエスト処理装置３０はサービスを実
行する主処理装置３４と、ユーザのリクエストを制限す
る前処理装置３２を含む。前処理装置３２のリクエスト
制限部４０は整理券を発行してリクエストを待機させ
る。状況提示部３８はユーザに待ち情報と整理券番号を
伝える。待合室管理部４４は、待ち状態にあるユーザに
娯楽性のある付加サービスを提供する。リクエスト発行
許可部４２は、サービスの順番が巡ってきたユーザのリ
クエスト発行を許可する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、リクエスト処理
技術とその要素技術に関する。この発明はとくに、ユー
ザのリクエストにしたがって所定のサービスをなすリク
エスト処理装置とリクエスト処理方法、およびそれらに
利用可能な前処理装置に関する。

【０００２】

【従来の技術】インターネットをはじめとするコンピュ
ータネットワークの利用が進むにつれ、従来はいわゆる
リアルの世界を中心にしたサービスが急速にネットワー
ク上で提供されつつある。最近ではインターネットを通
じたバンクサービス、証券取引、ニュースなど各種リア
ルタイムな情報の配信、コンサートや飛行機のチケット
の予約と販売などがさかんに行われている。

【０００３】そうしたネットワークサービスが普及した
最大の理由として、必要な手続がどこにいても手軽にと
れる利便性が挙げられる。例えば、長距離列車の切符を
買うために大きな荷物をかかえて長い行列に並んだり、
人気商品の購入のために徹夜して並んだりといった経験
のある者にとって、インターネットでそうした手続が完
結することの魅力はきわめて大きく、関連技術およびサ
ービス分野がさらに成長を遂げることに疑いはない。

【０００４】しかしながらインターネット利用者が激増
するにつれ、ネットワーク本来の利便性が損なわれる事
態も急増している。すなわち、人気サイトへのアクセス
が集中し、サーバの反応が遅くなったり、場合によって
はダウンする現象が日常的に見られるようになった。ネ
ットワーク社会において、サーバがユーザのリクエスト
を即時処理することは当然との認識が根底にあり、サー
ビス提供側は、負荷の増大を理由にサービスの遅延また
は中止を言い出しにくい状況にある。

【０００５】

【発明が解決しようとする課題】サーバの負荷が大きす
ぎる場合、サーバ運用者は、場合により単にサービスを
中止し、その旨をユーザ端末のブラウザへ表示すること
がある。しかし、そうして門前払いを喰ったユーザに
は、当然感情的なしこりを残す。サービス提供者として
は、サーバの負荷の増大は人気、希少性、大衆による支
持のダイレクトな反映であり、たとえ現実にサービスが
困難な状況にあっても、いかにユーザの理解を得るか、
また場合によっては、相当長時間待たせることにいかに
ユーザの了承を得るかは、ネット企業を中心に、企業姿
勢の問われる課題になりつつある。

【０００６】この発明はこうした状況に鑑みてなされた
ものであり、その目的は、ユーザリクエストに応じてネ
ットワーク経由でサービスをなす際、サービスの即時性
が確保できないときであっても、ユーザに相応の環境を
提供するリクエスト処理技術およびそのための前処理技
術の提供にある。

【０００７】

【課題を解決するための手段】本発明のある態様は、ユ
ーザからオンラインでリクエストを受けて所定のサービ
スを実行する主処理装置の前処理を行う装置に関する。
この装置は、前記主処理装置のステイタスがビジーのと
き、前記ユーザからの前記主処理装置に対するリクエス
トの発行を一旦待機状態におくリクエスト制限部と、前
記主処理装置における前記サービスの進行状況を検出す
る状況検出部と、前記検出された進行状況をもとに前記
ユーザに対して待ち情報を提示する状況提示部と、前記
サービスのタイミングが巡ってきたユーザによる前記主
処理装置へのリクエストの発行を許可するリクエスト発
行許可部とを含む。

【０００８】この構成では、リクエスト制限部が主処理
装置に対するリクエストの発行自体を待機させるので、
主処理装置の負荷の増加を抑えることができる。一方、
状況提示部がユーザに対して待ち情報を提示するため、
従来一般的なサーバのごとく単に「現在アクセスが集中
しています」などと表示することに比べ、ユーザによる
状況の把握に寄与できる。「待ち情報」として、そのユ
ーザの前に待っている人の人数、そのユーザの順番まで
の概算所要時間、チケットなど数量に限度のあるサービ
スについてはその残数や待ち人数、別の曜日や時間帯に
アクセスしたほうが空いている場合はそうしたガイダン
スなどがある。

【０００９】リクエスト発行許可部は、サービスのタイ
ミングまたは順番が巡ってきたユーザによる前記主処理
装置へのリクエストの発行を許可する。主処理装置は、
リクエストを発行したユーザに対してサービスを提供す
る。したがって、主処理装置は自らユーザのリクエスト
を待ちのキューに貯めなくとも、前処理装置が適切なタ
イミングでリクエストを投入してくれるため、主処理装
置の負荷やリソースを低減することができる。

【００１０】ひとつの設計指針として、通常リクエスト
が集中するサーバの部分を主処理装置と考え、それとユ
ーザ端末の間に前処理装置を新設して主処理装置の負荷
調整を行えばよい。主処理装置が既存の一般的なサーバ
の場合、前処理装置をその主処理装置から見て高度にト
ランスパレントに構成することにより、主処理装置の構
成の変更を最小限にとどめることができる。

【００１１】前記リクエスト制限部は、前記ユーザに電
子的な整理券を発行してそのユーザのリクエストの発行
を待機状態におき、前記状況提示部は、そのユーザの整
理券番号を用いて前記待ち情報を提示してもよい。

【００１２】前記前処理装置はさらに、前記リクエスト
の発行が待機状態におかれたユーザが入室可能な電子的
な待合室を提供する待合室管理部を含んでもよい。待機
中のユーザに待合室を提供することにより、待ち状態の
苦痛を軽減する趣旨である。この待合室は電子的に構成
されているため、ユーザが映画、音楽、スポーツ中継、
ゲームなどのコンテンツを楽しむことのできるコンテン
ツルームの形で提供できる。コンテンツを鑑賞中のユー
ザにリクエストの発行が許可されるときは、その旨がそ
のユーザへ通知されるよう構成してもよい。待合室の別
の態様として、入室したユーザどうしが電子的に会話を
もつためのチャットルームも可能である。

【００１３】前記リクエスト制限部は、ユーザの個人情
報をもとに、一部のユーザの順序を操作して整理券を発
行してもよい。個人情報は個人の属性の他、前記サービ
スになんらかの形で関連するユーザごとの履歴その他の
情報であってもよく、個人情報をもとに、例えば以下の
ユーザの待ち順位を繰り上げることができる。

【００１４】１．過去に同様のサービスについて定員オ
ーバー等でリクエストが受け付けられなかったユーザ２．このサービスの提供者の得意先であるユーザ３．このサービスに対して特別な対価を支払うユーザ４．防災やセキュリティなどの公益的事由について、こ
のサービスをとくに必要とするユーザ。

【００１５】本発明の別の態様は、ユーザ端末とネット
ワークを介して接続され、前処理装置および主処理装置
を含むリクエスト処理装置に関する。この前処理装置
は、前記ユーザ端末とのやりとりをテキストデータを基
礎とするページデータ、例えばＨＴＭＬ（Hyper Text M
arkup Language）やＸＭＬ（eXtensible Markup Langua
ge）などのマークアップ言語で記述されたページデータ
を介して行うＷｅｂサーバなどのサーバ機能を含み、か
つ、例えばＣＧＩ（Common Gateway Interface）などを
利用してそのサーバ機能に組み込まれ、または支援され
る形にて、以下の構成を含む。

【００１６】すなわち、前記ユーザ端末が前記主処理装
置のサービスに対してリクエストを発行するためのペー
ジへアクセスしたとき、前記主処理装置のステイタスが
ビジーであれば、前記リクエストを受け付ける代わりに
前記ユーザに対して電子的な整理券を発行するリクエス
ト制限部と、前記主処理装置における前記サービスの進
行状況を前記整理券の番号をもとに検出する状況検出部
と、前記検出された進行状況をもとに前記ユーザに対し
てページデータの形で待ち情報を提示する状況提示部
と、前記ユーザの整理券の番号を検査することにより、
前記サービスのタイミングが巡ってきたユーザを識別し
てそのリクエストの発行を許可するリクエスト発行許可
部である。一方、前記主処理装置は、前記リクエストの
発行が許可されたユーザに対して順次前記サービスをオ
ンラインで提供するサービス実行部を含む。

【００１７】本発明のさらに別の態様は、リクエスト処
理方法に関する。この方法は、ユーザが所定のサービス
に対してリクエストを発行する意思表示をしたとき、そ
のリクエストの発行を一旦待機状態におく前処理工程
と、前記リクエストが発行された後、前記ユーザに対し
て前記サービスを提供する主処理工程とを含む。

【００１８】前記前処理工程は、前記リクエストが待機
状態におかれたユーザに対して娯楽的要素のある付加サ
ービスを提供しつつ、前記所定のサービスのタイミング
が巡ってきたユーザを前記主処理工程へ移管する。一
方、前記主処理工程は、前記移管されたユーザに対して
順次前記サービスを提供していく。この方法によれば、
サービスを待つユーザに前記付加サービスが提供される
ため、待ちの苦痛が軽減される。また、前処理工程を設
けることで主処理工程の負荷を軽くすることができ、一
般に全体のスループットが改善される。

【００１９】なお、以上の構成要素の任意の組合せや、
本発明の構成要素や表現を方法、装置、システムなどの
間で相互に置換したものもまた、本発明の態様として有
効である。

【００２０】

【発明の実施の形態】図１は、実施の形態に係るリクエ
スト処理装置３０が適用されるネットワークシステム１
０の全体構成を示す。このネットワークシステム１０で
は、複数のユーザ端末１２とサービスサイト１６がイン
ターネット１４に接続されている。サービスサイト１６
はインターネット１４への通信経路であるルータ１８
と、ＷＷＷサーバ２０、メールサーバ２２、ＤＮＳサー
バ２４などを含み、リクエスト処理装置３０はＷＷＷサ
ーバ２０内部に設けられている。リクエスト処理装置３
０をＷＷＷサーバ２０内部に構築する手法にはいろいろ
あるが、ここでは一例として、リクエスト処理装置３０
の機能をＷＷＷサーバ２０のＣＧＩで実現し、ユーザ端
末１２に対するＨＴＭＬ等のページデータをＷＷＷサー
バ２０のフロントエンドで実施する。

【００２１】ここでは、ゲームソフトや情報端末などの
商品（以下単に「商品」という）をオンラインで購入す
る場面を考える。すなわち、ユーザ端末１２からサービ
スサイト１６に対して商品の発注がリクエストとして出
され、サービスサイト１６がユーザ端末１２のためにそ
の商品を確保して配送手続をとり、決済まで代行する。
以下、その一連の処理、またはその任意の一部をリクエ
スト処理装置３０による「サービス」とよぶ。その商品
の人気は高く、単にオンラインで受注を開始した場合、
サービスサイト１６へアクセスが集中し、ＷＷＷサーバ
２０のサーバ機能が著しく阻害されるとする。このため
に、リクエスト処理装置３０にはリクエストを適切に捌
くための前処理機能が設けられている。

【００２２】図２は、リクエスト処理装置３０の構成を
示す。この構成は、ハードウエア的には、ＷＷＷサーバ
２０のＣＰＵ、メモリ、その他の周辺回路で実現され、
ソフトウエア的にはＣＧＩにおけるリクエスト処理プロ
グラムによって実現されるが、ここではそれらの連携に
よって実現される機能ブロックを描いている。したがっ
て、これらの機能ブロックがハードウエアとソフトウエ
アの組合せによっていろいろな形で実現できることは、
当業者には理解されるところである。

【００２３】リクエスト処理装置３０は、前処理装置３
２と主処理装置３４を含む。主処理装置３４がユーザ端
末１２からのリクエストに応えてサービスをなす中核部
分で、従来一般的なインタラクティブタイプのサーバを
基礎としている。一方、前処理装置３２は主処理装置３
４へのアクセスの集中を予防する構成で、主処理装置３
４から直接見えないトランスパレンシーを有する。

【００２４】前処理装置３２は、ユーザ端末１２からの
リクエストを受け付け、主処理装置３４のステイタスが
ビジーの際にこれらのリクエストを一旦待機状態におく
リクエスト制限部４０を含む。状況検出部３６はそのた
めに主処理装置３４のステイタスを検出する。ステイタ
スは、後述の主処理装置３４のリクエスト受付部６２に
おけるリクエストの処理状況であり、リクエストが混雑
してユーザを待たせるべき状況にあれば「ビジー（Bus
y）」、そうでなければ「レディ（Ready）」と表現され
る。

【００２５】主処理装置３４のリクエスト受付部６２
は、リクエスト発行許可部４２から通知されたリクエス
トのテンポラリバッファとして機能し、例えば、リクエ
ストを発行したユーザ名、リクエスト発行許可部４２か
ら入力されたリクエストのうち未処理の数、現時点から
一定時間後に完了できると予想されるリクエストの数な
どを把握している。したがって、状況検出部３６はリク
エスト受付部６２の内部情報を監視することにより、ス
テイタスに加え、それがビジーのときはその程度も検出
できる。状況検出部３６はそれらの情報（以下「ステイ
タス等５４」という）をリクエスト制限部４０、リクエ
スト発行許可部４２、待合室管理部４４へ通知する。

【００２６】主処理装置３４のサービス実行部６４は、
リクエスト受付部６２から順に未処理のリクエストを読
み出し、実際にサービスを実行していく。サービスされ
たユーザ端末１２へその旨が通知されるとともに、サー
ビスの結果が記録テーブル６６へ記録され、サービスサ
イト１６の運営者へ報告される。

【００２７】図３はリクエスト制限部４０の内部構成
で、主処理装置３４がビジーのとき、整理券発行部７０
はリクエストを発する意思表示をしたユーザに整理券を
発行する。整理券は待ちの順番を数値化したもので、そ
の番号は待ち情報の一部として状況提示部３８からユー
ザ端末１２へ送られ、表示される。意思表示は、例えば
商品購入のためのページへアクセスしたことで確認でき
るが、「購入ボタン」を押すなど、より明示的な行為に
よって確認してもよく、サイトの設計に依存する。いず
れにしても、この意思表示の段階ではまだ主処理装置３
４へのリクエストは出されず、主処理装置３４の負荷軽
減が図られる。

【００２８】個人情報確認部７２は個人情報テーブル５
０を参照し、所定の条件を満たすユーザの待ちの順番を
繰り上げる。ここでは一例として、サービスサイト１６
における過去のオンラインショッピングの購入総額が一
定値を超えるユーザ（以下「優先ユーザ」という）の順
番を一律約２０％繰り上げる。このため整理券発行部７
０は、完全にシーケンシャルに整理券を発行せず、時折
飛び番号を設け、優先ユーザのためにリサーブしてお
く。整理券が発行されたとき、ユーザ端末１２にはその
番号が表示され、そのユーザ名と整理券番号が組み合わ
され、リクエスト発行許可部４２へ伝えられる。以下こ
の組合せデータを「待ちユーザデータ」という。なお、
主処理装置３４がレディの場合、リクエスト制限部４０
は整理券を発行せず、即座にユーザリクエスト、すなわ
ち購入意思とユーザ名をリクエスト発行許可部４２へ転
送する。主処理装置３４がレディの場合の処理は以下の
説明から明らかなため、ビジーの場合を中心に説明す
る。

【００２９】図４は、リクエスト制限部４０によってユ
ーザ端末１２に表示された画面例を示す。ここでは、
「Ｆｉｎａｌｘｘｘｘｘ」という商品の購入リクエス
トが混雑してユーザを待たせている旨のコメントが記載
され、整理券発行ボタン７４によってユーザによる整理
券の受取が促されている。

【００３０】図５は、状況提示部３８の内部構成を示
す。整理券番号通知部７６、待ち情報通知部７８はそれ
ぞれ、リクエスト制限部４０から伝えられた整理券番
号、状況検出部３６から伝えられた待ち情報をユーザへ
通知する。待ち情報通知部７８は過去のリクエスト処理
の進行状況をもとに、待ち状況にある各ユーザに対する
サービス開始時刻を予測する。

【００３１】図６は状況提示部３８によってユーザ端末
１２へ表示された画面例を示す。ここでは、あるユーザ
（以下このユーザを「ｘｙｚ」と名付ける）の整理券番
号が「１５０８９番」、ユーザｘｙｚよりも前でリクエ
スト処理を待っているユーザの数が「１５８８人」、ユ
ーザｘｙｚに対するサービス開始まで、「約２３分」と
表示され、「近所の人とチャットする」ボタン８０、
「コンテンツを楽しむ」ボタン８２、および「購入画面
へ」ボタン８４が設けられている。「近所の人とチャッ
トする」ボタン８０を押すことにより、このユーザは後
述のチャットルームへ入室して待ち時間を過ごすことが
できる。同様に「コンテンツを楽しむ」ボタン８２を押
せば、コンテンツを鑑賞しながら待ち時間を過ごすこと
ができる。「購入画面へ」ボタン８４を押せば、後述の
ようにリクエスト発行許可部４２によるチェックを経て
そのユーザによるリクエストが主処理装置３４へ発行さ
れる。

【００３２】図２に戻り、リクエスト発行許可部４２は
主処理装置３４によるサービスのタイミングが訪れたユ
ーザのリクエストを主処理装置３４へ発行する。リクエ
スト発行許可部４２はリクエスト制限部４０から予め待
ちユーザデータを得ており、これをもとに待ちユーザテ
ーブル５２を生成して管理する。

【００３３】図７はリクエスト発行許可部４２の内部構
成を示す。テーブル更新部９０は、リクエスト制限部４
０から通知された待ちユーザデータを待ちユーザテーブ
ル５２に追加する一方、リクエストを発行したユーザを
処理の対象から外し、待ちユーザテーブル５２における
データの一貫性を保つ。いずれのタイミングで何人のユ
ーザにリクエストの発行を許可するかは、ステイタス等
５４をもとに決定される。部屋別処理部９２は後述のご
とく、待合室管理部４４からの情報に基づき、同一のチ
ャットルームに入ったユーザに対し一括してリクエスト
の発行を許可するための付加機能を提供する。番号検査
部９４は、ユーザが購入画面へ進もうとするとき、その
整理券番号を検査する。番号検査部９４に許可されたユ
ーザはすでにサービスのタイミングが巡ってきたユーザ
である。許可通知部９６は、番号検査部９４によって許
可されたユーザにその旨を通知する。通知を受けたユー
ザは図１３で後述する「購入」ボタンを押すことによ
り、リクエストを発行する。発行されたリクエストはリ
クエスト発行許可部４２から主処理装置３４のリクエス
ト受付部６２へ送られる。

【００３４】図２に戻り、待合室管理部４４はリクエス
トの発行が待たされているユーザ、すなわち待ちユーザ
テーブル５２に記載されたユーザに娯楽要素のある付加
サービスを提供する。ここでは、動画または音楽を提供
するコンテンツルーム４６と、他のユーザと対話ができ
るチャットルーム４８が提供される。コンテンツルーム
４６に入室したユーザは、例えばサービスサイト１６の
運用者が提供するコンテンツをＶＯＤ（ビデオオンデマ
ンド）によって楽しむことができる。そのユーザに対す
るサービスの順番が巡ってくると、リクエスト発行許可
部４２からユーザ端末１２へその旨が表示される。

【００３５】一方、チャットルーム４８は複数の部屋Ｃ
１、Ｃ２、・・・Ｃｎを有する。これらの部屋Ｃ１、Ｃ
２、・・・Ｃｎは、互いに待ち時間が近い、すなわち整
理券番号が近いユーザをそれぞれひとつのグループとし
て収容する。番号が近いユーザ間は運命共同体的な意味
で共感をもちやすく、また、前述の部屋別処理部９２に
よって、部屋単位でリクエストの発行を許可できるメリ
ットがある。

【００３６】図８は待ちユーザテーブル５２の内部構成
を示す。待ちユーザテーブル５２は、整理券番号欄１１
０、ユーザ名欄１１２、チャットルーム欄１１４、許可
欄１１６を含む。チャットルーム欄１１４は、チャット
ルーム４８にユーザが入室している場合、その部屋をＣ
１、Ｃ２、・・・Ｃｎで示す。チャットルーム４８に入
室していないユーザについてこの欄は「−」と記述され
る。許可欄１１６はすでにリクエストの発行が許可され
たユーザについて「１」、まだ待ち状態にあるユーザに
ついて「０」が記述されている。ただし、この欄が
「１」であるユーザは待ちユーザテーブル５２から削除
してもよい。

【００３７】図８のごとく、いま問題にしている整理券
番号「１５０８９」のユーザｘｙｚの前後はまだ待ち状
態にあり、ユーザｘｙｚと整理券番号「１５０８６」の
ユーザｃｅｄ、同「１５０８８」のユーザｈｅａが同一
の部屋Ｃｉでチャットをしている。さらに先の整理券番
号「１５１２０」のユーザｔｓｂは、より後ろの部屋Ｃ
ｊに入室している。

【００３８】図９は、ユーザｘｙｚが入った部屋Ｃｉに
おけるチャットの様子を示す。ここでは同じ部屋へ入っ
たユーザどうしがチャットするための領域１１８、サー
ビスの進行状況を示す領域１２０（以下「状況領域１２
０」という）、および「購入画面へ」ボタン１２２が表
示されている。

【００３９】図１０は、図９の状態においてユーザｘｙ
ｚが「購入画面へ」ボタン１２２を押したときに表示さ
れる画面を示す。ここではユーザｘｙｚの順番がまだで
あるため、リクエスト制限部４０の番号検査部９４によ
ってリクエストの発行が拒絶され、「もとの画面へ」ボ
タン１２４が表示されている。

【００４０】図１１は、ユーザｘｙｚがさらに待ち時間
を過ごした結果、同じ部屋へ入ったユーザとともにリク
エスト発行許可通知を得たときの状況領域１２０を示
す。ここでは、チャットルームのうち部屋Ｃｉの全員に
対して同報的に許可通知が出され、「購入画面へ」ボタ
ン１２２の押下が促されている。

【００４１】一方、図１２は、仮にユーザｘｙｚがチャ
ットルーム４８に入らなかった場合に出される許可通知
を含む状況領域１２０を示す。チャットルーム４８に入
らない場合、「同一の部屋のユーザ」という概念がない
ため、ユーザｘｙｚ単独で許可が出されている。

【００４２】図１３は、ユーザｘｙｚが「購入画面へ」
ボタン１２２を押したときに表示される画面を示す。こ
こでは、当該ユーザの氏名、住所その他の情報を入力す
るための欄が表示され、最終意思確認のための「購入」
ボタン１３０および入力しなおしのための「やりなお
し」ボタン１３２が表示されている。ユーザｘｙｚが
「購入」ボタン１３０を押すと、はじめて正式のリクエ
ストがリクエスト発行許可部４２からリクエスト受付部
６２へ発行され、サービス実行部６４によるサービスが
ユーザｘｙｚへ提供され、一連の処理を終える。

【００４３】以上、本発明を実施の形態をもとに説明し
た。この実施の形態は例示であり、それらの各構成要素
や各処理プロセスの組合せにいろいろな変形例が可能な
こと、またそうした変形例も本発明の範囲にあることは
当業者に理解されるところである。以下、そうした例を
挙げる。

【００４４】実施の形態では、前処理装置３２を主処理
装置３４に対してトランスパレントに設計したが、もち
ろん当初より前処理装置３２と主処理装置３４の組合せ
を意識して両者の最適化を図ってもよい。とくに、前処
理装置３２と主処理装置３４の実現に利用可能なリソー
ス、とりわけＣＰＵパワーが一定の場合、そうした最適
化設計はさらにリクエスト処理効率を高めることがあ
る。

【００４５】リクエスト処理装置３０はＷＷＷサーバ２
０の中に設けられたが、当然これに限る必要はない。例
えば、リクエストやサービスが電子メールを利用して行
われる場合、むしろメールサーバ２２にリクエスト処理
装置３０の機能を組み込んだほうが効率的なこともあ
る。

【００４６】待合室として、コンテンツとチャットを挙
げたが、当然これらに限られない。ＢＢＳ的な機能や、
待ち時間にクイズを出す機能その他の機能を提供しても
よい。

【００４７】チャットルーム４８では、整理券番号が近
いユーザを同じ部屋へ割り当てたが、もちろんそれに限
られない。例えば年齢層が高いユーザその他属性を手が
かりに割り当ててもよいし、まったくランダムに割り当
ててもよい。ただし、いずれの場合も処理の負荷が大き
くならないよう配慮することが好ましい。

【００４８】単純な意思表示の順番だけでなく、他の方
法も組み合わせてリクエストを制限してもよい。例え
ば、クイズの正解者に限ってリクエストの発行を許可し
たり、ユーザのＩＰアドレスの偶奇で絞り込んだり、ユ
ーザの端末環境、例えばＯＳやブラウザの種類などで絞
り込みをかけてもよい。オンライン抽選を組み合わせて
リクエスト数を大幅に絞り込む方法もある。

【００４９】

【発明の効果】本発明によれば、ユーザリクエストに対
してリアルタイムに応ずることができない場合でも、そ
のリクエストを効率的に処理することができる。

【図面の簡単な説明】

【図１】実施の形態に係るリクエスト処理装置が適用
されるネットワークシステムの構成図である。

【図２】実施の形態に係るリクエスト処理装置の構成
図である。

【図３】リクエスト制限部の内部構成図である。

【図４】リクエスト制限部によってユーザ端末に表示
される画面を示す図である。

【図５】状況提示部の内部構成図である。

【図６】状況提示部よってユーザ端末に表示される画
面を示す図である。

【図７】リクエスト発行許可部の内部構成図である。

【図８】待ちユーザテーブルのデータ構成図である。

【図９】チャットルーム内部の様子を示す図である。

【図１０】リクエスト発行許可部によって、まだ順番
が巡ってこないユーザの端末に表示される画面を示す図
である。

【図１１】リクエスト発行許可部によって、順番が巡
ってきた、チャットルームに入っているユーザの端末に
表示される画面を示す図である。

【図１２】リクエスト発行許可部によって、順番が巡
ってきた、チャットルームに入っていないユーザの端末
に表示される画面を示す図である。

【図１３】リクエスト発行許可が出されたユーザの端
末に表示される画面を示す図である。

【符号の説明】

１２ユーザ端末、２０ＷＷＷサーバ、３０リ
クエスト処理装置、３２前処理装置、３４主処理
装置、３６状況検出部、３８状況提示部、４
０リクエスト制限部、４２リクエスト発行許可
部、４４待合室管理部、４６コンテンツルー
ム、４８チャットルーム、５２待ちユーザテー
ブル、６４サービス実行部、７０整理券発行
部、７２個人情報確認部、７８待ち情報通知部、
１２０状況領域。

フロントページの続き (72)発明者西川英彰東京都品川区北品川４丁目７番35号ソニーコミュニケーションネットワーク株式会社内 (72)発明者稲舘利雄東京都品川区北品川４丁目７番35号ソニーコミュニケーションネットワーク株式会社内 (72)発明者金井忠裕東京都品川区北品川４丁目７番35号ソニーコミュニケーションネットワーク株式会社内 (72)発明者佐々木功昌東京都品川区北品川４丁目７番35号ソニーコミュニケーションネットワーク株式会社内 (72)発明者近藤治彦東京都品川区北品川４丁目７番35号ソニーコミュニケーションネットワーク株式会社内 (72)発明者秋本祥一東京都品川区北品川４丁目７番35号ソニーコミュニケーションネットワーク株式会社内Ｆターム(参考） 5B049 CC01 EE00 FF03 GG00 GG07 5B085 AC12 BG07

Claims

【特許請求の範囲】

【請求項１】ユーザからオンラインでリクエストを受
けて所定のサービスを実行する主処理装置の前処理を行
う装置であって、前記主処理装置のステイタスがビジーのとき、前記ユー
ザからの前記主処理装置に対するリクエストの発行を一
旦待機状態におくリクエスト制限部と、前記主処理装置における前記サービスの進行状況を検出
する状況検出部と、前記検出された進行状況をもとに前記ユーザに対して待
ち情報を提示する状況提示部と、前記サービスのタイミングが巡ってきたユーザによる前
記主処理装置へのリクエストの発行を許可するリクエス
ト発行許可部と、を含むことを特徴とする前処理装置。
【請求項２】前記リクエスト制限部は、前記ユーザに
電子的な整理券を発行してそのユーザのリクエストの発
行を待機状態におき、前記状況提示部は、そのユーザの整理券番号を用いて前
記待ち情報を提示することを特徴とする請求項１に記載
の前処理装置。
【請求項３】前記リクエストの発行が待機状態におか
れたユーザが入室可能な電子的な待合室を提供する待合
室管理部をさらに含むことを特徴とする請求項１、２の
いずれかに記載の前処理装置。
【請求項４】前記待合室は、入室したユーザがコンテ
ンツを鑑賞することのできるコンテンツルームとして構
成され、かつ前記リクエストの発行が許可されたときそ
の旨がコンテンツを鑑賞中のユーザへ通知されるよう構
成されていることを特徴とする請求項３に記載の前処理
装置。
【請求項５】前記待合室は、互いに待ち時間が近いユ
ーザをそれぞれひとつのグループとして収容する複数の
仮想的な部屋を含むことを特徴とする請求項３に記載の
前処理装置。
【請求項６】前記仮想的な部屋は、その部屋へ入室し
たユーザどうしが電子的に会話をもつためのチャットル
ームとして構成されていることを特徴とする請求項５に
記載の前処理装置。
【請求項７】前記リクエスト発行許可部は、前記仮想
的な部屋を処理の単位として前記リクエストの発行を許
可することを特徴とする請求項５、６のいずれかに記載
の前処理装置。
【請求項８】前記リクエスト制限部は、ユーザの個人
情報をもとに、一部のユーザの順序を操作して整理券を
発行することを特徴とする請求項２から７のいずれかに
記載の前処理装置。
【請求項９】前記前処理装置が、前記主処理装置から
見て高度にトランスパレントに構成されていることを特
徴とする請求項１から８のいずれかに記載の前処理装
置。
【請求項１０】ユーザ端末とネットワークを介して接
続され、前処理装置および主処理装置を含むリクエスト
処理装置であって、前記前処理装置は、前記ユーザ端末とのやりとりをテキ
ストデータを基礎とするページデータを介して行うサー
バ機能を含み、かつそのサーバ機能に組み込まれ、また
は支援される形にて、前記ユーザ端末が前記主処理装置のサービスに対してリ
クエストを発行するためのページへアクセスしたとき、
前記主処理装置のステイタスがビジーであれば、前記リ
クエストを受け付ける代わりに前記ユーザに対して電子
的な整理券を発行するリクエスト制限部と、前記主処理装置における前記サービスの進行状況を前記
整理券の番号をもとに検出する状況検出部と、前記検出された進行状況をもとに前記ユーザに対してペ
ージデータの形で待ち情報を提示する状況提示部と、前記ユーザの整理券の番号を検査することにより、前記
サービスのタイミングが巡ってきたユーザを識別してそ
のリクエストの発行を許可するリクエスト発行許可部と
を含み、前記主処理装置は、前記リクエストの発行が許可された
ユーザに対して順次前記サービスをオンラインで提供す
るサービス実行部を含むことを特徴とするリクエスト処
理装置。
【請求項１１】ユーザが所定のサービスに対してリク
エストを発行する意思表示をしたとき、そのリクエスト
の発行を一旦待機状態におく前処理工程と、前記リクエストが発行された後、前記ユーザに対して前
記サービスを提供する主処理工程とを含み、前記前処理工程は、前記リクエストが待機状態におかれ
たユーザに対して娯楽的要素のある付加サービスを提供
しつつ、前記所定のサービスのタイミングが巡ってきた
ユーザを前記主処理工程へ移管し、前記主処理工程は、前記移管されたユーザに対して順次
前記サービスを提供していくことを特徴とするリクエス
ト処理方法。