JP2013058254A - 予約管理システム、およびその方法 - Google Patents

Abstract

【課題】アミューズメントパークなどのアトラクション、乗り物、ショー、もしくはイベントなどのリソースを利用する時間枠を予約するための、予約を管理する装置、システム、および方法を提供する。
【解決手段】リソースユーザによるリソースの利用を管理するために、予約要求を入力するモジュール入力部１００と、上記予約要求を受けて、リソースユーザが上記リソースを利用し得る時間枠を、更新可能なリソース利用パラメータに基づいて特定するプロセッサ１４０と、上記モジュールのユーザに特定された上記時間枠を示すモジュール出力部１６０と、を備え、ネットワークのユーザから受けたトークン数を決定する。
【選択図】図２

Description

本発明は、たとえばアミューズメントパークにおいて目にする、アトラクション、乗り物、ショー、もしくはイベントなどのリソースを利用する時間枠を予約するための、予約を管理する装置、システム、および方法に関する。

多く場合、アトラクションは、ある特定の時間にそれを利用しようとする人々に対して、限られた収容能力しか有さない。たとえば、アミューズメントパークにおける乗り物は、所定数の席しか有さない。その利用は、なるべく効率的に上記アトラクションを利用するために、管理されていることが好ましい。行列は、この利用を管理するためのよく知られた方法である。だが、上記アトラクションを利用し得るユーザは、行列に並びながら時間を持て余すだろう。上記アトラクションのユーザとなりうるもの、および上記アトラクションの実際のユーザを満足させつつ、上記アトラクションを効率的に利用するために上記リソースの利用を管理することは、特に困難である。

従来のアプローチは、上記アトラクションを利用したいという人々を、２つのグループに分ける。第１のグループに属する人は、上記アトラクションについての第１のアクセスポイントにおける現実の行列に配置される。第２のグループに属する各人には、彼らが上記アトラクションを利用可能な、ある割り当てられた時間枠が知らされる。上記アトラクションを利用するためには、上記第２のグループに属する人は、彼らの割り当てられた時間枠に、上記アトラクションについての第２のアクセスポイントへ実際に現れるだけでよい。上記時間枠は、上記第２のグループの人が上記第２のアクセスポイントにおける長い列の中で待つことなく上記アトラクションを利用できるように、選ばれる。上記第１のグループのサイズは、ゼロより大きいか、もしくはゼロである。

この一般的な方法に関するあるシステムは、上記第２のグループに属する人に紙のチケットを与える。これらのチケットは、上記アトラクションを利用するための定まった時間を指定しているので、このシステムでは、そのスループットが変化するときには、上記アトラクションを効率的に利用することは容易ではない。

この一般的なアプローチに関する代替のシステムが、特許文献１に記載されている。このシステムは、上記第２のグループに、キューボットと称される手で持つことのできるユニットを与えている。これらは、予約し、そして予約を完了するために用いられる。上記キューボットは、固有の特定コードを送るためのショートレンジトランスミッタと、レシーバと、を備える。特定のアトラクションを利用するための予約をするために、キューボットは、予約もしくは入力ポイントにおいて、スキャンもしくはドッキングされる。上記キューボットは、この予約を記録し、上記予約は、キューマネージャーに送られる。各予約に対して、上記キューマネージャーは、上記スループットおよび上記アトラクションに対する要求に基づいて、上記予約をした人が上記アトラクションを利用すべき時間を決定する。

この時間は、上記スループットや上記アトラクションに対する要求が変化するときには、都合がよいことに、上記キューマネージャーにより変更することができる。たとえば、座席が上記アトラクションに追加されたり、上記アトラクションから取り除かれたりする場合や、短期間の間、上記アトラクションを使用できない場合がある。上記キューマネージャーは、トランスミッタにつながっている。各予約に対して、上記キューマネージャーは、上記キューボットを持ち運んでいる人が決定した上記時間に上記アトラクションを利
用できるように、上記予約の記録を有しているキューボットに信号を送る。

このシステムは、紙のチケットを用いるものよりも良い。しかしながら、それには多くの問題がある。第１に、上記キューボットを用いる人が、予約をするために、予約もしくは入場ポイントに実際に現れる必要がある。第２に、このシステムは、上記キューマネージャーに接続しているトランスミッタにより送られる信号が十分なレンジを有していることを、必要としている。全てのキューボットがこの信号を受けることができるようにするためである。キューマネージャーは、上記システムの効率的な管理を乱さないのであれば、キューボットとの接続を減らすため、限られた数のキューボットにしか接続できない場合がある。このため、複数のキューマネージャーが必要とされる場合がある。したがって、このシステムは、大規模な固定の設備を必要とする。

米国特許６５２９７８６号公報

このような背景に対して、第１の側面において、本願発明は、複数のリソースユーザによるリソースの利用を管理するためのポータブルモジュールであって、上記複数のリソースユーザのうちの少なくとも１人のリソースユーザから発せられた、上記リソースの利用を希望する旨の予約要求を、当該ポータブルモジュールに入力するモジュール入力部と、上記予約要求を受けて、上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を、更新可能なリソース利用パラメータに基づいて特定するプロセッサと、を備えており、上記更新可能なリソース利用パラメータが、（ｉ）追加のポータブルモジュールを持っているリソースユーザによりなされた上記リソースについての予約要求の数、および（ｉｉ）ポータブルモジュールを持っている上記リソースの各ユーザに対する見積スループット、に基づいて決定され、上記見積スループットは、（ａ）上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率、および（ｂ）上記リソースに対する評価スループット、の組み合わせに基づいて決定され、さらに、特定された上記時間枠を上記ポータブルモジュールのユーザに対して表示するモジュール出力部を備える、ポータブルモジュールを提供する。

これによって、上記ポータブルモジュールは、情報についての単一の値や項目を備える、もしくは情報についての複数の値や項目を備えるパラメータに基づいて、上記ポータブルモジュールのユーザが上記リソースを利用できる時間を特定できる。上記パラメータは、予約要求の数と、上記ポータブルモジュールのユーザに対する見積スループットと、に基づいている。好ましくは、上記ポータブルモジュールは、ドッキングステーションを必要とすることなく、全ての予約や待ち行列の時間についての集中データベースとの継続的な交信を必要とすることもなく、利用時間を決定することができる。

好ましくは、上記交信可能なリソース利用パラメータは、上記少なくとも１人のリソースユーザが上記リソースを利用し得るまでの待ち時間を含む。

好ましい形態においては、上記ポータブルモジュールは、上記モジュール入力部が受けた予約要求を格納し、且つ、上記更新可能なリソース利用パラメータに関する情報を格納するデータストレージと、上記データストレージに格納された予約要求の指示を交信するトランスミッタと、上記更新可能なリソース利用パラメータに関する情報を受けるレシーバと、をさらに備える。上記トランスミッタおよびレシーバは、無線、光、赤外線、または他のワイヤレス通信手段を用いてもよい。また、上記トランスミッタはさらに、上記更
新可能なリソース利用パラメータに関する情報を交信する。同期プロトコルが用いられてもよく、もしくは、さらに非同期プロトコルが用いられてもよい。

本発明は、複数のリソースユーザによるリソースの利用を管理するためのサーバモジュールであって、上記複数のリソースユーザのうちの少なくとも１人のリソースユーザから発せられた、上記リソースの利用を希望する旨の予約要求に関する情報を受信するレシーバと、更新可能なリソース利用パラメータを決定するプロセッサと、を備えており、上記更新可能なリソース利用パラメータは、（ｉ）上記リソースについて受けた予約要求の数、および、（ｉｉ）ポータブルモジュールを持っている上記リソースの各ユーザに対する見積スループット、に基づいて決定され、上記見積スループットは、（ａ）上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率、および（ｂ）上記リソースに対する評価スループット、の組み合わせに基づいて決定され、さらに、上記更新可能なリソース利用パラメータを交信するトランスミッタを備える、サーバモジュールをも含む。

好ましい形態においては、上記トランスミッタはさらに、ポータブルモジュールを持っている上記リソースの各ユーザに対する上記見積スループットを交信する。

本発明は、複数のポータブルモジュールを備え、複数のリソースユーザによるリソースの利用を管理するためのシステムであって、各ポータブルモジュールは、上記複数のリソースユーザのうちの少なくとも１人のリソースユーザから発せられた、上記リソースの利用を希望する旨の予約要求を、当該ポータブルモジュールに入力するモジュール入力部と、予約要求の指示を交信するトランスミッタと、更新可能なリソース利用パラメータを受信するレシーバと、上記予約要求を受けて、上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を、上記更新可能なリソース利用パラメータに基づいて特定するプロセッサと、特定された上記時間枠を上記ポータブルモジュールのユーザに対して表示するモジュール出力部と、を備え、上記更新可能なリソース利用パラメータは、（ｉ）上記リソースについて受けた予約要求の数、および、（ｉｉ）ポータブルモジュールを持っている上記リソースの各ユーザに対する見積スループット、に基づいて決定され、上記見積スループットは、（ａ）上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率、および（ｂ）上記リソースに対する評価スループット、の組み合わせに基づいて決定される、システム、によっても具現化される。

好ましい形態においては、各ポータブルモジュールの上記トランスミッタはそれぞれ、上記更新可能なリソース利用パラメータを交信する。各ポータブルモジュールの上記レシーバはそれぞれ、他のポータブルモジュールから伝えられた上記リソースの予約要求の指示を受信し、上記ポータブルモジュールの上記データストレージは、受信した上記指示を格納する。このように、上記システムは、予約要求の総数を決定する。上記システムは、第１の修正因子に基づいて、上記リソースについての予約要求の数を決定する。

好ましい形態においては、上記システムは、上記（ａ）および上記（ｂ）の積に基づいて、ポータブルモジュールを持っている上記リソースの各ユーザに対する上記見積スループットを決定する。好ましくは、上記システムは、上記（ａ）および上記（ｂ）の積と比例因子とに基づいて、上記見積スループットを決定する。さらに、上記システムは、（ｉｉｉ）第２の修正因子、に基づいて上記更新可能なリソース利用パラメータを決定する。上記第２の修正因子は、時刻、リソースの場所、およびリソースの人気、の少なくともいずれかに基づいて、決定される。

好ましい形態においては、上記システムはさらに、上記（ｉ）を上記（ｉｉ）で割った
ものに基づいて、上記更新可能なリソース利用パラメータを決定する。また、比例因子に基づいて上記更新可能なリソース利用パラメータが決定される。

上記システムはさらに、上記リソースの全てのユーザに対する上記リソースのスループットを計算することにより、上記リソースに対する評価スループットを決定する。これは、ルックアップテーブルを用いることによりなされる。有利なことに、上記比率は、あるモデルを用いて、決定される。さらに、上記モデルは、要素として、ポータブルモジュールのユーザの総数を含む。

本願発明は、複数のリソースユーザによるリソースの利用を管理するための方法であって、上記複数のリソースユーザのうちで上記リソースの利用を希望する少なくとも１人のリソースユーザにより入力された予約要求をポータブルモジュールにおいて取得するステップと、上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を、更新可能なリソース利用パラメータに基づいて特定するステップと、を備えており、上記更新可能なリソース利用パラメータは、（ｉ）追加のポータブルモジュールを持っているリソースユーザによりなされた上記リソースについての予約要求の数、および（ｉｉ）ポータブルモジュールを持っている上記リソースの各ユーザに対する見積スループット、に基づいて決定され、上記見積スループットは、（ａ）上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率、および（ｂ）上記リソースに対する評価スループット、の組み合わせに基づいて決定され、さらに、上記ポータブルモジュールのそれぞれのユーザに特定された上記時間枠を示すステップを備える、方法、をも含む。

第２の側面において、本願発明は、複数のリソースユーザによるリソースの利用を管理するためのポータブルモジュールであって、上記複数のリソースユーザのうちの少なくとも１人のリソースユーザから発せられた、上記リソースの利用を希望する旨の予約要求を、当該ポータブルモジュールに入力するモジュール入力部と、更新可能なリソース利用パラメータを受信するレシーバと、上記予約要求を受けて、上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を、上記更新可能なリソース利用パラメータに基づいて特定するプロセッサと、上記更新可能なリソース利用パラメータを交信するトランスミッタと、特定された時間枠を、上記ポータブルモジュールのユーザに示すモジュール出力部と、を備える、ポータブルモジュールである。

本願発明は、複数のリソースユーザによるリソースの利用を管理するための方法であって、上記複数のリソースユーザのうちで上記リソースの利用を希望する少なくとも１人のリソースユーザにより入力された予約要求をポータブルモジュールにおいて取得するステップと、各ポータブルモジュールにおいて、更新可能なリソース利用パラメータを受信するステップと、上記各ポータブルモジュールにおいて、上記更新可能なリソース利用パラメータを送信するステップと、上記更新可能なリソース利用パラメータに基づいて、上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を特定するステップと、を備える、方法、でもある。

第３の側面において、本願発明は、ポータブルモジュールであって、トークン数に関する情報を入力するモジュール入力部と、当該ポータブルモジュールにおいて受けた上記トークン数を格納するデータストレージと、当該ポータブルモジュールとネットワーク内のルートノードとの間のリンククオリティに関する、上記ポータブルモジュールに対するリンククオリティパラメータを決定するとともに、追加のポータブルモジュールに対する上記リンククオリティパラメータに関する情報を受信するトランシーバと、上記ポータブルモジュールとルートノードとの間のリンククオリティが、上記追加のポータブルモジュールと上記ルートノードとの間のリンククオリティよりも高い場合には、上記トランシーバ
は、上記追加のポータブルモジュールに格納された上記トークン数に関する情報を受信し、且つ、上記データストレージは、上記データストレージ内に格納された数に、受信した上記トークン数を加え、上記追加のポータブルモジュールとルートノードとの間のリンククオリティが、上記ポータブルモジュールと上記ルートノードとの間のリンククオリティよりも高い場合には、上記トランシーバは、上記データストレージ内に格納された上記トークン数に関する情報を、上記追加のポータブルモジュールに送信する、ポータブルモジュール、である。

これにより、上記ネットワークは、たとえば予約要求であるトークン数を決定できる。この際には、大規模な固定の設備を必要としない。その代わりに、上記ポータブルモジュールは、あるものから他のものへ情報を交換する。そして、上記情報が上記ルートノードに到達するまで、交換するごとに、受け取ったトークン数を加える。予約要求のこの数は、都合がよいことに、上記リソースを利用するための時間枠を特定するために用いられることができる。

好ましい形態においては、上記追加のポータブルモジュールとルートノードとの間のリンククオリティが、当該ポータブルモジュールと上記ルートノードとの間のリンククオリティよりも、高い場合、上記データストレージは、その中に格納された上記トークン数をゼロにセットする。代わりに、上記データストレージは、これらのトークン数がすでに送信されてしまったことを示すために適合されていてもよい。

好ましくは、当該ポータブルモジュールとルートノードとの間のリンククオリティが、上記追加のポータブルモジュールとルートノードとの間のリンククオリティよりも高い場合には、上記トランシーバはさらに、確認メッセージを送信し、上記追加のポータブルモジュールとルートノードとの間のリンククオリティが、当該ポータブルモジュールとルートノードと間のリンククオリティよりも高い場合には、上記トランシーバは確認メッセージを受信する。上記確認メッセージは、上記追加のポータブルモジュールからのトークン数を受けて、交信されてもよい。また、上記トランシーバが上記確認メッセージを受信した後に、上記データストレージは、その中に格納された上記トークン数をゼロにセットする。

好ましい形態における上記トランシーバは、上記追加のポータブルモジュールに対する上記リンククオリティパラメータに基づいて、上記ポータブルモジュールに対する上記リンククオリティパラメータを決定する。送信中の追加のポータブルモジュールやサーバモジュールのホップ数は、受信され、これは、上記ポータブルモジュールのホップ数を決定するために用いられる。

本願発明は、本明細書におけるポータブルモジュールを複数備え、ルートノードを含むネットワーク、を含む。上記ルートノードはポータブルモジュールを備える。好ましい形態において、上記ルートノードは、サーバモジュールを備え、上記サーバモジュールは、ポータブルモジュールに格納された上記トークン数を受信するレシーバを備える。

本願発明は、ルートノードおよび複数のポータブルモジュールを含むネットワークのユーザから受けたトークン数を決定するための方法であって、第１のポータブルモジュールへの入力において、トークン数に関する情報をユーザから受信するステップと、第１のポータブルモジュールにおいて受信したトークン数を、データストレージ内に格納するステップと、上記第１のポータブルモジュールと、上記ネットワーク内の上記ルートノードと、の間のリンククオリティに関するリンククオリティパラメータを決定するステップと、第２のポータブルモジュールの上記リンククオリティパラメータに関する情報を、上記第１のポータブルモジュールにおいて受信するステップと、上記第１ポータブルモジュール
と上記ルートノードとの間のリンククオリティが、上記第２のポータブルモジュールと上記ルートノードとの間のリンククオリティよりも、高い場合、上記第２のポータブルモジュール内に格納されたトークン数に関する情報を、上記第１のポータブルモジュールにおいて受信し、受信したトークン数を上記第１のポータブルモジュールの上記データストレージ内に格納された上記トークン数に加えるステップと、上記第２のポータブルモジュールと上記ルートノードとの間のリンククオリティが、上記第１のポータブルモジュールと上記ルートノードとの間のリンククオリティよりも、高い場合、上記第１のポータブルモジュールから上記第２のポータブルモジュールへ、上記第１のポータブルモジュール内に格納された上記トークン数を送信するステップと、を備える、方法、を含む。

本発明は、様々な形態に適用できるが、本発明のうちの一つが、一例として、添付している図面を参照しつつ記載される。

リソースの利用を管理するためのシステムを示している図を表している。 図１のシステムにおいて用いられる、本発明の第１の側面にかかるリソースの利用を管理するためのポータブルモジュールの概略図を示している。 本発明の第２の側面にかかり、図１のシステムにおいて用いられるリソースの利用を管理するためのサーバモジュールの概略図を示している。 図１のシステムにかかるサーバモジュールに関するポータブルモジュールの配置を示している。

まず図１について説明する。同図には、アトラクションへのアクセスを管理するためのシステムが示されている。本明細書においてアトラクションなる用語を使用するが、これは複数の人が利用しうるリソースであって、収容能力が限られているものであれば何であってもよい。リソース１０、すなわちアトラクション、の利用を希望する人が複数いるとし、このような人をたとえばリソースユーザと称することにする。リソースとしては、遊園地における乗り物やショー、イベントなどのほか、店舗または企業におけるサービスカウンタなどがあげられる。

通常、複数いるリソースユーザのうちの何割かは、ポータブルモジュール２０を入手するであろう。各ポータブルモジュールは、個人あるいはグループとしてのリソースユーザに対し、販売されたり、一時的あるいは所定の期間にわたって貸し出されたりする。リソースユーザ３０は、一台のポータブルモジュール２０を個人で所有している。同様にリソースユーザ４０も、一台のポータブルモジュール２０を個人で所有している。リソースユーザのグループ５０は３人からなり、一台のポータブルモジュール２０を共有している。リソースユーザ６０の中には、ポータブルモジュールを持たない人がいる。

上記システムはさらに、サーバモジュール７０を備える。上記サーバモジュールは、好ましくは、上記リソースから情報を受け取るため、コミュニケーションリンク８０を用いてリソース１０につながっている。

図２は、本発明の第１の側面にかかるポータブルモジュールの概略図を示している。上記ポータブルモジュールは、モジュール入力部１１０、トランスミッタ１２０、レシーバ１３０、およびプロセッサ１４０を備える。

ポータブルモジュール２０は、モジュール入力部１００を有している。これは、たとえば、１または複数のボタン、もしくはキーパッドである。上記モジュール入力部は、リソースユーザからの予約要求を取得するために用いられる。これは、上記ポータブルモジュ
ールを用いるリソースユーザのうちの１人のリソースユーザが上記アトラクションの利用を希望していることを、示している。たとえば、上記モジュール入力部が上記アトラクションに対する３つの予約要求を受け取った場合には、これは、上記ポータブルモジュールを使っている３人の人が、上記アトラクションの利用を希望していることを表している。上記モジュール入力部は、１または複数の予約要求のキャンセルをするためにも用いられる。

予約要求はそれぞれ、上記モジュール入力部からプロセッサ１４０まで伝わる。上記プロセッサは、本実施形態においてはメモリであるデータストレージ１５０に、上記予約要求を格納する。予約要求の数は、上記リソースの利用を希望しているユーザの数に一致する。上記予約要求は、データストレージ１５０にトークン信号として格納される。よって、３つの予約要求を受け取った場合には、３のトークン信号がデータストレージ１５０に格納される。

本実施形態においては、プロセッサ１４０は、トランスミッタ１２０にもつながっている。上記トランスミッタの出力部は、アンテナ１１０につながっており、これにより、上記予約要求についての情報を送信できるようになっている。レシーバ１３０にも、その入力部につながっているアンテナ１１０が、接続されている。上記トランスミッタおよび上記レシーバは、トランシーバを含む。上記レシーバの出力部は、上記プロセッサにつながっている。好ましくは、上記トランスミッタおよび上記レシーバは、同期プロトコルに従い、少なくとも１つの通信チャネルによって通信している。このことにより、必要な時にだけ、上記トランスミッタや上記レシーバにために電力を用いることができる。

予約要求が上記モジュール入力部から上記プロセッサに伝わると、上記予約要求を入力し且つ上記ポータブルモジュールを持っている上記リソースユーザが上記アトラクションを利用し得る時間枠を、上記プロセッサは特定する。上記プロセッサは、上記モジュールのユーザにこの時間枠を表示するモジュール出力部１６０と、つながっている。

上記プロセッサは、更新可能なリソース利用パラメータに基づいて、上記時間枠を特定する。上記更新可能なリソース利用パラメータは、追加のポータブルモジュールを持っているリソースユーザによりなされた上記リソースの予約要求の数（ｉ）と、ポーラブルモジュールを持っている各リソースユーザに対する見積スループット（ｉｉ）と、の組み合わせをとおして決定される。上記システムの好ましい形態によれば、上記更新可能なリソース利用パラメータは、サーバモジュール７０から受け取った、上記リソースの利用に対する待ち時間である。

上記ポータブルモジュールは、第２のトランシーバ内に、第２のトランスミッタ１２５と第２のレシーバ１３５とをさらに備える。上記第２のトランスミッタと上記第２のレシーバは、赤外線通信手段を用いる。

図３は、本願発明の第２の側面にかかるサーバモジュール７０の概略図を示している。上記サーバモジュールは、レシーバ２２０への入力部として且つトランスミッタ２３０からの出力部として接続されたアンテナ２１０を備えている。上記レシーバの出力部は、プロセッサ２４０への入力部として、接続されている。上記トランスミッタの入力部は、上記プロセッサへの出力部として、接続されている。上記プロセッサの第２の入力部は、サーバモジュール入力部２５０に接続している。上記プロセッサの第３の入力部は、コミュニケーションリンク８０によって、リソース１０に接続している。

図４は、ポータブルモジュールの配置を示しており、この配置はサーバモジュール７０に対するそれらの位置に関する。ある期間にわたって、特定のポータブルモジュール、た
とえばポータブルモジュール３１０は、少なくとも１つの位置において、そのトランスミッタを作動させる。同様にある期間にわたって、ポータブルモジュール３１０は、たとえばポータブルモジュール３２０やポータブルモジュール３２１などの他のポータブルモジュールから送信された送信信号を受信する。ポータブルモジュール３１０からサーバモジュール７０に情報を伝達するために、ポータブルモジュール３１０は、この情報を、第１の追加のポータブルモジュール３２０に送ることができる。上記第１の追加のポータブルモジュール３２０はこのとき、これを第２の追加のポータブルモジュールに中継する、などといったことができる。この中継は、上記情報がサーバモジュール７０に伝わるまで行われる。それによって、各ポータブルモジュールは、サーバモジュール７０に至るまでの「ホップ数」を決定する。このホップ数は、伝達の回数を意味するリンククオリティパラメータであり、すなわち、伝達信号が上記ポータブルモジュールからサーバモジュール７０にうまく中継されるために必要な「ホップス」である。この点において、上記サーバモジュール７０は、ポータブルモジュールおよび少なくとも１つのサーバモジュール７０によるネットワーク、に対するルートノードとしての役割を果たす。したがって、このホップ数は、上記ポータブルモジュールからの伝達信号がサーバモジュール７０に到達するのに必要な時間を意味する。上記ポータブルモジュールのホップ数が小さくなれば、そのリンククオリティが高くなる。上記ホップ数は、上記ポータブルモジュールの位置が変化するにつれて変化する。

本実施形態において、サーバモジュール７０のプロセッサ２４０は、以下のステップに従って、ポータブルモジュールを持っており且つ予約要求をしたユーザに対する待ち時間として、上記更新可能なリソース利用パラメータを決定する。

サーバモジュール７０は、リソースユーザによりなされる上記リソースについての予約要求の数を決定する。予約要求の数を決定する方法はここで記載され、この方法は、ある通信プロトコルを用いている。

上記モジュール入力部をとおして予約要求を受けた第１のポータブルモジュール３１０は、ポータブルモジュールデータストレージ１５０内に格納された少なくとも１つの予約要求を有している。第１のポータブルモジュール３１０は、第２のポータブルモジュール３２０と交信し、そして、上記２つのポータブルモジュールはそれらのホップ数を交換する。

第２のポータブルモジュール３２０のホップ数が第１のポータブルモジュール３１０のホップ数よりも小さい場合、上記第１のポータブルモジュールは、そのデータストレージに格納された予約要求の総数を、第２のポータブルモジュール３２０に送信する。第２のポータブルモジュール３２０は、確認メッセージをポータブルモジュール３１０に送り返し、そして、予約要求の総数を決定するため、第１のポータブルモジュール３１０から受信した予約要求の数に、既にそのストレージに格納されている予約要求の数を加える。上記確認メッセージを受け取ると、第１のポータブルモジュール３１０はそのデータストレージから、送信した上記予約要求を削除する。

第１のポータブルモジュール３１０のホップ数が第２のポータブルモジュール３２０のホップ数よりも小さい場合、かつ、第２のポータブルモジュール３２０がそのデータストレージに格納されている予約要求を有している場合、第２のポータブルモジュール３２０は、そのデータストレージに格納されている予約要求の総数を第１のポータブルモジュール３１０に送信する。第１のポータブルモジュール３１０は、確認メッセージをポータブルモジュール３２０に送り返し、そして、予約要求の総数を決定するため、第２のポータブルモジュール３２０から受信した予約要求の数に、既にそのストレージに格納されている予約要求の数を加える。上記確認メッセージを受け取ると、第２のポータブルモジュー
ル３２０はそのデータストレージから、送信した上記予約要求を削除する。

このプロトコルは、さらに他のポータブルモジュールと交信できる各ポータルブルモジュールに対して繰り返される。ポータブルモジュール２０がサーバモジュール７０と直接接続できるとき、上記ポータブルモジュールは、そのデータストレージ１５０内に格納されている予約要求の総数をサーバモジュール７０に送る。それによって、上記サーバモジュール７０は予約要求の数を決定する。

ポータブルモジュールが、そのデータストレージ内に予約要求を全く格納していない場合、それは、他のポータブルモジュールと交信しようとしない。これは、通信量を占有することになるだけだからである。この方法は、ツリーを検索する固定パケットを必要とすることなく、予約要求の数を決定するために必要な通信量をさらに減少させる。

予約要求の総数が各ポータブルモジュールから集められることは必ずしも必要ない。このことは、上記ネットワークが多数のポータブルモジュールを含んでいる場合に、特に妥当する。しかしながら、データが集められているポータブルモジュールのサンプルサイズは、典型的な代表例であるべきである。これにより、上記システムを際限なく大きくすることができる。なぜなら、上記ポータブルモジュールの数が非常に大きい場合、上記ポータブルモジュールのほとんどは受信データしか必要としないからである。すると、予約要求の数は、あらゆるポータブルモジュールのうちランダムに選択された代表例から集められていることしか必要とせず、さらに、これらのポータブルモジュールからのみしか送信する必要がない。

サーバモジュール７０に交信できる範囲の外に一時的に存在するポータブルモジュールが一定の割合で存在しうる。たとえば、これは、無線通信のための踏み石としての役割を果たす仲介のポータブルモジュールを有さない、距離を隔てて孤立したポータブルモジュールのグループがある場合に発生しうる。そのため、サーバモジュール７０が、ポータブルモジュールのサンプルサイズがどれほど大きいのかを、把握する必要があり、これらのポータブルモジュールからは、上記データの総数が集められている。これは、実在しないダミーリソースに対して、上記ポータブルモジュールに自動的に定期的な予約をさせることによりなされる。たとえば、上記ポータブルモジュールが１０分に１回、上記ダミーリソースに予約をする場合、１０分の周期を終えると、上記ダミーリソースに対する予約数は、現在明らかなサンプルサイズに等しいこととなる。

長い周期を終えたあと、上記サーバモジュールは、予約要求の総数を正確に確定する。しかしながら、短い周期においては、確定された予約要求の数は、誤りを含む場合がある。特に、いくつかのポータブルモジュールが一時的に上記サーバの接続範囲外にある間に、予約される割合に変化が生じた場合に、誤りを含む可能性がある。これを埋め合わせるため、上記サーバにおいては受け取っていない予約要求の数の見積もりが、上記明らかなサンプルサイズについての直近の計測に基づいてなされる。そして、これに基づいて、たとえば、サーバプロセッサ２４０は、第１の補正因子を予約要求の数に適用する。

このように上記アトラクションの利用を希望するユーザの数を決定する際において、送られる情報の量は抑えられる。予約要求の数の変化だけが送られるからである。

上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率＜ａ＞と、上記リソースに対する評価スループット＜ｂ＞と、の組み合わせをとおして、サーバモジュール７０は、ポータブルモジュールを持っている、上記リソースの各ユーザに対する見積スループットをも決定する。

リソース２０を利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率は、たとえば、サーバプロセッサ２４０により決定される。サーバプロセッサ２４０は、ポータブルモジュールを持っている人の数を受け取る。そして、上記サーバプロセッサは、この数を用いて、上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率を計算する。

上記リソースを利用できる人の総数、たとえば上記アミューズメントパークの入場者が、あるしきい値以下であるとき、ポータブルモジュールを持っている人の数は少ない。一方、上記リソースを利用できる人の総数が上記しきい値を上回っているとき、ポータブルモジュールを持っている人の数は、上記リソースを利用できる人の総数が増加するのに比例して、増加する。オペレータや自動回転式改札システムは、上記リソースを利用できる人の実際の総数を監視し、上記比率を見積もってもよい。補正因子は、この比率から誤差を調整するために用いられる。

上記リソースに対する評価スループットは、コミュニケーションリンク８０をとおして与えられる。上記評価スループットは、上記リソースにおける外部の装置を用いて決定されてもよいし、もしくは、それは、オペレータが上記リソースにおいて入力したものとして与えられてもよい。上記評価スループットは、作動している間に劇的に変化してもかまわない。上記アトラクションが乗り物である場合、これらは次のものを含んでいてもよい。たとえば、第２の客車を上記乗り物に加えることによりその収容能力を倍増できることや、上記乗り物に乗客を乗せることや下ろす点におけるスタッフの効率が変化することや、清掃のために故障したり閉鎖したりすることによりスループットがゼロにまで減少してしまうこと、などである。

本発明において、見積スループットは、好ましくは以下のアプローチを用いて決定されることが理解される。サーバモジュールプロセッサ２４０は、上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率と、上記リソースに対する評価スループットと、の積を得ることにより、見積スループットを決定する。決定した上記見積スループットによって、上記ユーザにとって合理的であるといえるよりも、待ち時間が、はるかに長くなったり短くなったりすることがある。第２の修正因子が、このエラーを減少させるべく、上記見積スループットに用いられる。上記第２の修正因子は、たとえば、時刻、リソースの場所、およびリソースの人気、などを含む多数の特性に基づいている。

そして、上記待ち時間は、リソースユーザによりなされた予約要求の数と、上記見積スループットと、の組み合わせにより決定される。上記サーバモジュールは、上記アトラクションの予約要求の数のうち実行されているものの総数を維持する。これは、アトラクションキューレングスと称される。上記サーバモジュールは、ポータブルモジュールを持っている上記リソースの各ユーザに対して、上記見積スループットにより決定された割合で、このアトラクションキューレングスを減少させる。上記キューレングスが負になった場合、それはゼロにセットされる。上記待ち時間は上記見積スループットで、上記キューレングスを割り算することにより決定される。ただし、これは測定要素により適正化される場合もある。

上記待ち時間は、サーバモジュールトランスミッタ２３０を用いている少なくとも１つのポータブルモジュールに送られる。ポータブルモジュールを持っている上記リソースの各ユーザに対する上記見積もられたスループット、および、この情報が確定した時間も、サーバモジュールトランスミッタ２３０を用いている少なくとも１つのポータブルモジュ
ール対して交信される。この交信信号は、たとえば、リソース状態テーブル、もしくは、パーク状態テーブル、と称される。データが変化するときに大半のポータブルモジュールが最新のものとなっているように、この交信信号は、恒常的に、そして、十分な頻度で発生するようになっている。この頻度は、通常は、５分から１０分に一度の範囲内である。

上記リソース状態テーブルを受信すると、上記ポータブルモジュールは、上記リソース状態テーブルを、もしくは、少なくとも上記待ち時間を、公知のネットワーク技術に従って、上記サーバモジュールから上記データを受信することができない他のポータブルモジュールに送信する。上記ポータブルモジュールは、上記リソース状態テーブルを再送信するまで、バックオフ時間待機をする。このように、上記サーバモジュールの上記トランスミッタについて要求される帯域幅を、都合よく減少させることができる。ポータブルモジュールの位置が変化する場合には、上記リソース状態テーブルは、強力なトランスミッタを有するサーバモジュールや、上記レシーバにおける高性能なレシーバを必要とすることなく、多数のポータブルモジュールに、うまく、効率的に送られる。

上記リソース状態テーブルに含まれる値は、上記ホップ数である。ルートノードとしての機能する上記サーバモジュールは、上記ホップ数をゼロにセットした状態で、上記リソース状態テーブルを送る。ポータブルモジュールが、上記リソース状態テーブルを受信し、そして、上記リソース状態テーブルがそれに格納されている情報よりも新しい情報を含んでいると判断した場合、受信したホップ数に１を加え、そして、そのデータストレージ１５０にこのホップ数を格納する。上記ポータブルモジュールが上記リソース状態テーブルを送信した場合、上記リソース状態テーブルにおける上記ホップ数の値は、上記ポータブルモジュールにおけるデータストレージ１５０内に格納されているものであり、受け取ったものではない。このように、各ポータブルモジュールが、上記ホップ数の値を決定してもよい。

ポータブルモジュールがリソース状態テーブルを送信すると、それは、他のポータブルモジュールから予約要求の情報を受信するための待機状態となる。

上記待ち時間および上記見積スループットを受け取ると、ポータブルモジュールが、受け取った情報がそのポータブルモジュールの各データストレージ内に格納された情報よりも新しい、と判断する場合には、上記ポータブルモジュールは、そのデータストレージに格納されている情報を、より新しい情報に置き換える。次の予約要求がなされる場合には、上記ポータブルモジュールは、上記の複数のリソースユーザのうちの少なくとも一人が直近に受け取った待ち時間に基づいて上記リソースを利用する時間枠を特定する。

上記ポータブルモジュールが時間枠を特定したものの、上記見積スループットを受け取って上記プロセッサが、上記見積スループットが変化したと判断した場合、上記ポータブルモジュールは、アップデートされた時間枠を特定してもよい。このアップデートされた時間枠において、変化した上記見積スループットに基づき、上記リソースユーザが上記リソースを利用できる。このようにして、上記ポータブルモジュールは、スループットの変化に対応して、上記特定された時間枠をうまく調整してもよい。

上記待ち時間および上記見積スループットの値を既に受け取ったポータブルモジュールが、上記サーバモジュールの送信範囲や他のポータブルモジュールによりなされる再送信範囲の外部にまさに移動してしまっている場合、上記ポータブルモジュールは、リソースユーザからの予約要求を受け取ると、既に受け取った待ち時間を用いて、上記リソースユーザが上記リソースを利用し得る時間枠を特定してもよい。この時間枠は、最適な時間枠ではないかもしれないが、少数のポータブルモジュールだけしか上記サーバモジュールや他のポータブルモジュールの範囲外にないだろうから、上記アトラクションを利用するう
えで最終的な結果には、たいした影響はないと思われる。時間枠を特定した上記ポータブルモジュールがちょうど上記サーバモジュールの送信範囲に戻ってきたとき、上記ポータブルモジュールは、上記見積スループットを受け取ればよい。上記見積スループットが変化していた場合、上記サーバモジュールは、変化した上記見積スループットを用いて、上記時間枠をアップデートする。

仮にポータブルモジュールのグループが孤立した場合には、そのグループの中においては、それらは、ある一定の時間以上、サーバモジュール７０との交信信号を受信もしくは送信することができない。上記ポータブルモジュールのうちのいずれかは、直近の有用なデータに基づいて、リソース状態テーブルを自動的に送ってもよい。この孤立したグループ内のポータブルモジュールが、上記リソース状態テーブルを受け取り、そして、そのポータブルモジュール自体のリソース状態テーブルが受信したものよりも新しいと判断した場合には、それは、そのポータブルモジュール自体のリソース状態テーブルを、他のポータブルモジュールに送る。

電力消費を最小化するため、上記無線レシーバがなるべく少ない時間だけしか作動しないことが好ましい。これを実現するため、すべての上記無線通信は、短い所定の周期的時間枠の間に実行される。これは、たとえば、毎分につきその２分の１の時間である。一分に１回、上記サーバモジュールが新しいリソース状態テーブルを送る。ポータブルモジュールは、この時より少し前に、それらのレシーバをスイッチオンし、上記リソース状態テーブルを待機する状態となる。前述したように、これは、サーバモジュールから直接受け取られ、または、１もしくは複数の仲介のポータブルモジュールによって、まもなく送られる。リソース状態テーブルが受け取られると、上記ポータブルモジュールは、前述したように、上記情報を送り、そして、上記ポータブルモジュールが全ての予約要求の情報を受け入れる次の所定の期間を、待機する状態となる。上記レシーバは、次のリソース状態テーブルの送信が予想されるまで、シャットダウンされる。

この方法が要求する同期をとるために、上記ポータブルモジュールが正確なクロックを有していることが必要である。これはたとえば、現在の時間を、送信された上記リソース状態テーブルに加えることにより実現される。ポータブルモジュールが（以前に受け取ったものではなく）新しいリソース状態テーブルを受け取る時はいつでも、上記受け取った信号により示された現在の時間に従って、そのポータブルモジュールのクロックを調整する。ポータブルモジュールがリソース状態テーブルを送る時はいつでも、そのポータブルモジュールは、それ自体のクロックに従って現在の時間に、上記リソース状態テーブル内の受け取った時間を置き換える。

上記リソース状態テーブルはタイムスタンプをも含み、このタイムスタンプは、サーバモジュールから上記リソース状態テーブルが最初に送られた時間を示す。現在の時間は、ポータブルモジュールにより再び送られる時において、上記サーバモジュールによりセットされた値のまま保たれているタイムスタンプとは区別される。

時間枠が特定される時はいつでも、上記モジュール出力部をとおして、上記ポータブルモジュールを持ち運んでいる人にこの時間枠が示されている。時間枠が変化した場合、上記モジュール出力部をとおして警告メッセージも示される。あらゆるメッセージが上記ポータブルモジュールのプロセッサにより発生させられる。そのため、都合がよいことに、上記サーバモジュールへの断続的な接続が必要とされない。

少なくとも１以上の予約要求がなされ、上記アトラクションを利用するための時間枠がやってくる時、１または複数の予約要求をした人々は、上記アトラクションに向かっている。ポータブルモジュールを持っており且つ予約要求をした人は、ポータブルモジュール
により示された時間よりも後のいつの時間においてか、上記アトラクションを利用する。彼らは、さまざまな方法で上記アトラクションを利用する。そのため、上記ポータブルモジュールにより特定された時間枠は、単一の時間のみから構成される。利用するための好ましい方法は、以下に記載される。

上記アトラクションの入口のアテンダントは、たとえば入場モジュールを持っている。この入場モジュールは、トランスミッタ、レシーバ、プロセッサ、およびモジュール出力部を備える。上記トランスミッタおよび上記レシーバは、特定された上記時間枠を確認するために、また、これを上記入場モジュールのプロセッサに伝えるために、上記リソースユーザにより持ち運ばれているポータブルモジュールの赤外線トランスミッタ１２５および赤外線レシーバ１３５と通信する赤外線通信を用いる。その際、上記入場モジュールのプロセッサは、上記アテンダントに適切なメッセージを伝えるために、上記入場モジュールの出力部を用いる。そうすることで、このアテンダントは、適切に、利用について許可や不許可することができる。利用が許可された場合、上記ポータブルモジュールは、エントリーポイントはパスした、というようにそのユーザに表示する。所定の時間経過後に、上記ポータブルモジュールは、待機状態に戻る。

好ましい形態は上述されたが、当業者は、この形態に対する代替例を考えるかもしれない。上記ポータブルモジュールにおいて、上記データストレージは、代替的に、たとえばハードディスクなどの固定されたデータストレージ装置であってもよいし、たとえばメモリーカードなどの着脱可能なデータストレージ装置であってもよい。上記トランスミッタやレシーバは、好ましくは無線の使用のために用いられる。ただし、当業者は、それらを、光や、その他の種類の通信手段の使用のために用いることもありうる。上記ポータブルモジュールは、ここでは、専用の装置として記載されているが、それは、たとえば持ち運び可能なコンピュータや携帯電話機などの携帯電子機器の一部を構成していてもよい。この場合においては、上記ポータブルモジュールの機能の中には、たとえば上記持ち運び可能なコンピュータや携帯電話機が元々備えている構成によって提供される機能があり、残りの機能は、たとえば追加のハードウエアやソフトウエア、もしくは、ハードウエアおよびソフトウエアの結合において、実現される。さらに、当業者が考えるように、上記転送プロトコルのアスペクトは、このハードウエアの上記トランスミッタやレシーバの装備にマッチするように、うまく適用される。

当業者は、上記モジュール入力部が多様な構成に従って作動する場合がある、といったことを考えるだろう。たとえば、上記モジュール入力部が、上記ポータブルモジュールを用いる人の数とともに、事前にプログラムされていてもよい。このとき、たとえば身長や体重の情報などの、上記ポータブルモジュールを用いる人に関する追加の情報が与えられる。この情報は、たとえば特定のリソースを用いるための各人の許容能力を自動的に決定するために用いられる。したがって、アトラクションに対する予約要求が上記ポータブルモジュールに入力された場合、なされた予約要求の数は、上記ポータブルモジュールを用いている人の数、からこのアトラクションを利用できない人の数、を引いた数に一致するだろう。

上記リソースに対して見積もられたスループットは、リソース１０へのコミュニケーションリンク１０を必要とすることなく、予めセットされたスループットを手作業で選ぶことにより、決定されればよい。このスループットは、さらに、スループット修正因子により適正化されてもよい。上記更新可能なリソース利用パラメータは待ち時間として記載されているが、当業者は、本発明は、他の更新可能なリソース利用パラメータを用いて構成されていてもよいことを理解するだろう。このような他の更新可能なリソース利用パラメータは、予約要求の数および見積スループットに基づいている。

スループットという用語が用いられているが、当業者は、これは代わりに計算能力であるとすることを理解するだろう。当業者は、上記評価スループットは、他の公知の技術を用いて、測定され、評価され、計算され、もしくは決定されることをも理解するだろう。

上記サーバモジュールは、上記待ち時間および上記見積スループットと同様に、上記評価スループット；たとえば、オープンしている、クローズしている、一時的に閉鎖している、などといった上記リソースすなわちアトラクションの状態；上記アトラクションにおける待ち行列の状態；上記アトラクションがオープンしていると予想される時間；を含む他の情報を送信してもよい。この情報は、上記リソース状態テーブルの一部を構成してもよい。

上記アトラクションにエントリーをすることが、特定された時間より後にするように制限されるだけでなく、第２の特定された時間の前にするように制限される場合がある。このように、上記アトラクションへのエントリーは、限られた時間枠に制限される場合がある。

当業者は、上記ポータブルモジュールは、たとえば無線通信などの、赤外線通信の代わりとなるものを用いるエントリーモジュールに接続してもよいことを理解するだろう。この場合、第２のトランスミッタ１２５および第２のレシーバ１３５は、たとえばリダンダントであり、上記第１の送受信機のみが必要とされる。

当業者は、上記アトラクションを利用するための他の方法を考えるかもしれない。記載される代わりの方法は、トランスミッタ、レシーバ、およびゲートを備える自動回転扉を提供する。このゲートは通常閉じている。上記回転扉は、上記リソースユーザが利用を許可されているか、およびこの場合にゲートを開けるか、といったことを決定するため、トランスミッタおよびレシーバを用いているポータブルモジュールと、交信している。

当業者は、リソースユーザによりなされる上記リソースの予約要求の数を決定するための他の方法をも考えるかもしれない。このような方法は、たとえばリモートセンサネットワークや他のアドホックネットワーク技術において用いられる、当業者によく知られた通信ネットワークプロトコルに基づいていてもよい。

上記の好ましい形態において、ホップ数はリンククオリティパラメータとして用いられたけれども、当業者は、シグナルストレングス、他のポータブルモジュールのシグナルストレンスグス、もしくはそれに関する関数、などの他のリンククオリティパラメータが用いられることを考えるだろう。当業者は、上記ポータブルモジュールは、上記リンククオリティパラメータに依存して適切に適合されることをも認識するだろう。

リソースユーザによりなされる上記リソースの予約要求の数を決定する際に、上記ポータブルモジュールは、送られた上記予約要求を、そのデータストレージから削除することは必ずしも必要ない。一方、当業者は、上記ポータブルモジュールは、代替的に、これらの予約要求が送られたことを特定し、そしてこれらが再度送られないように表示する、他の手段を用いてもよいことを理解するだろう。

当業者は、本発明に関する上記システムの代替の形態を考えるかもしれない。第１の代替の形態においては、複数のサーバモジュールが用いられる。上記サーバモジュールは、ポータブルモジュールと同じように互いに接続する。この形態において、各サーバモジュールは、上記リソースの予約要求の数のうちの一定割合の数を得る場合がある。

第２の代替の形態においては、サーバモジュールを必要としない。というより、上記ポ
ータブルモジュールの１つが、上記サーバモジュールにとって代わる。このポータブルモジュールには、必要な入力、具体的に言うと、上記リソースを利用する可能性のあるユーザの総数に対する、ポータブルモジュールを持っており且つ上記リソースを利用する可能性のあるユーザの比率、および、上記リソースに対する評価スループット、が与えられる。この情報は、手動で、もしくはコミュニケーションリンク１０を用いて、リソース１０に与えられる。代替的にそれは、ある公式、ルックアップテーブル、もしくは他の処理手段を用いて計算される。上記サーバモジュールにとって代わる上記ポータブルモジュールは、リソースユーザによりなされる上記リソースについての予約要求の数を、上述したのと同様に、決定できる。

さらなる代替の形態においては、サーバモジュールにとって代わる上記ポータブルモジュールのうちの１つは不要である。というより、上記待ち時間の決定は、たとえば各ポータブルモジュールにより、個々に実行される。上記ポータブルモジュールは、公知のアドホック接続技術を用いて、それらどうしの接続を形成しており、互いにここで記載されるコミュニケーションプロトコルを有している。このように、上記待ち時間を決定するのに必要な情報はいずれも、分散型の方法により決定される。いったん決定すると、この待ち時間は、公知のアドホックプロセス技術を用いて、上記ポータブルモジュールどうしの間を通る。この形態も、複雑な設備をあまり必要としない。

単一のリソースに対して、上記システムが記載されたけれども、当業者は、記載された各形態における上記ポータブルモジュール、サーバモジュール、およびシステムを、複数のリソースについて適合できるだろう。この場合、待ち時間は、各リソースについて必要とされる。しかしながら、複数のリソースを利用できるとき、上記システムのうちのいくつかの部分が、複製されている必要のないことは、当業者にとっては明らかであろう。たとえば、複数のリソースを利用するための要求をするためには、単一のポータブルモジュールのみしか、１人の人や、一つの人々のグループに対して必要とされない。

さらに、第１のリソースを利用するための時間枠が特定され、第２のリソースに対する予約要求を受けると、上記ポータブルモジュールは、上記第２のリソースを利用するための時間枠を特定する際に、上記第１のポータブルモジュールに対して特定された時間枠を考慮してもよい。

代わりに、上記ポータブルモジュールは追加的に、たとえばグローバルポジショニングシステムレシーバなどのその位置に関する情報を決定する手段を備えていてもよい。そして、それは、たとえばサーバモジュールや他のポータブルモジュールにより三角測量されたその位置に関する情報を受けとってもよい。上記ポータブルモジュールが、その位置を決定するための手段を備えている場合、それは、都合がよいことに、待ち時間およびその位置情報に基づき、さまざまなリソースの時間枠を特定できる。

Claims (47)

1. 複数のリソースユーザによるリソースの利用を管理するためのポータブルモジュールであって、
   上記複数のリソースユーザのうちの少なくとも１人のリソースユーザから発せられた、上記リソースの利用を希望する旨の予約要求を、当該ポータブルモジュールに入力するモジュール入力部と、
   上記予約要求を受けて、上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を、更新可能なリソース利用パラメータに基づいて特定するプロセッサと、
   を備えており、上記更新可能なリソース利用パラメータが、
   （ｉ）追加のポータブルモジュールを持っているリソースユーザによりなされた上記リソースについての予約要求の数、および
   （ｉｉ）ポータブルモジュールを持っている上記リソースの各ユーザに対する見積スループット、
   に基づいて決定され、上記見積スループットは、
   （ａ）上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率、および
   （ｂ）上記リソースに対する評価スループット、
   の組み合わせに基づいて決定され、
   さらに、特定された上記時間枠を上記ポータブルモジュールのユーザに対して表示するモジュール出力部を備える、ポータブルモジュール。
2. 上記モジュール入力部が受けた予約要求を格納し、且つ、上記更新可能なリソース利用パラメータに関する情報を格納するデータストレージと、
   上記データストレージに格納された予約要求の指示を交信するトランスミッタと、
   上記更新可能なリソース利用パラメータに関する情報を受けるレシーバと、
   をさらに備える、請求項１に記載のポータブルモジュール。
3. 上記トランスミッタはさらに、上記更新可能なリソース利用パラメータに関する情報を交信する、請求項２に記載のポータブルモジュール。
4. 上記レシーバはさらに、上記見積スループットに関する情報を受信する、請求項２に記載のポータブルモジュール。
5. 上記レシーバはさらに、上記リソースに対する上記評価スループットに関する情報を受信する、請求項２に記載のポータブルモジュール。
6. 上記トランスミッタおよび上記レシーバは、同期通信プロトコルを用いる、請求項２に記載のポータブルモジュール。
7. 上記モジュール出力部は、上記特定された時間枠を上記ポータブルモジュールのユーザに示すディスプレイ装置を含む、請求項１に記載のポータブルモジュール。
8. 複数のリソースユーザによるリソースの利用を管理するためのサーバモジュールであって、
   上記複数のリソースユーザのうちの少なくとも１人のリソースユーザから発せられた、上記リソースの利用を希望する旨の予約要求に関する情報を受信するレシーバと、
   更新可能なリソース利用パラメータを決定するプロセッサと、
   を備えており、上記更新可能なリソース利用パラメータは、
   （ｉ）上記リソースについて受けた予約要求の数、および、
   （ｉｉ）ポータブルモジュールを持っている上記リソースの各ユーザに対する見積スループット、
   に基づいて決定され、上記見積スループットは、
   （ａ）上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率、および
   （ｂ）上記リソースに対する評価スループット、
   の組み合わせに基づいて決定され、
   さらに、上記更新可能なリソース利用パラメータを交信するトランスミッタを備える、サーバモジュール。
9. 上記トランスミッタはさらに、ポータブルモジュールを持っている上記リソースの各ユーザに対する上記見積スループットを交信する、請求項８に記載のサーバモジュール。
10. 複数のポータブルモジュールを備え、複数のリソースユーザによるリソースの利用を管理するためのシステムであって、各ポータブルモジュールは、
    上記複数のリソースユーザのうちの少なくとも１人のリソースユーザから発せられた、上記リソースの利用を希望する旨の予約要求を、当該ポータブルモジュールに入力するモジュール入力部と、
    予約要求の指示を交信するトランスミッタと、
    更新可能なリソース利用パラメータを受信するレシーバと、
    上記予約要求を受けて、上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を、上記更新可能なリソース利用パラメータに基づいて特定するプロセッサと、
    特定された上記時間枠を上記ポータブルモジュールのユーザに対して表示するモジュール出力部と、を備え、
    上記更新可能なリソース利用パラメータは、
    （ｉ）上記リソースについて受けた予約要求の数、および、
    （ｉｉ）ポータブルモジュールを持っている上記リソースの各ユーザに対する見積スループット、
    に基づいて決定され、上記見積スループットは、
    （ａ）上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率、および
    （ｂ）上記リソースに対する評価スループット、
    の組み合わせに基づいて決定される、システム。
11. 各ポータブルモジュールの上記トランスミッタはそれぞれ、上記更新可能なリソース利用パラメータを交信する、請求項１０に記載のシステム。
12. 各ポータブルモジュールの上記レシーバはそれぞれ、他のポータブルモジュールから伝えられた上記リソースの予約要求の指示を受信し、上記ポータブルモジュールの上記データストレージは、受信した上記指示を格納する、請求項１１に記載のシステム。
13. ポータブルモジュールの上記プロセッサは、上記ポータブルモジュールの上記データストレージ内に格納されている上記予約要求の組み合わせに基づき予約要求の総数を決定し、且つ、上記ポータブルモジュールの上記トランスミッタはさらに、上記予約要求の総数を交信する、請求項１２に記載のシステム。
14. 第１の修正因子に基づいて、上記リソースについての予約要求の数を決定する、請求項１０に記載のシステム。
15. 上記（ａ）および上記（ｂ）の積に基づいて、ポータブルモジュールを持っている上記リソースの各ユーザに対する上記見積スループットを決定する、請求項１０に記載のシステム。
16. 上記（ａ）および上記（ｂ）の積と比例因子とに基づいて、上記見積スループットを決定する、請求項１５に記載のシステム。
17. （ｉｉｉ）第２の修正因子、
    に基づいて上記更新可能なリソース利用パラメータを決定する、請求項１６に記載のシステム。
18. 時刻、リソースの場所、およびリソースの人気、の少なくともいずれかに基づいて、上記第２の修正因子を決定する、請求項１７に記載のシステム。
19. 上記（ｉ）を上記（ｉｉ）で割ったものに基づいて、上記更新可能なリソース利用パラメータを決定する、請求項１０に記載のシステム。
20. 比例因子に基づいて上記更新可能なリソース利用パラメータを決定する、請求項１９に記載のシステム。
21. 上記リソースの全てのユーザに対する上記リソースのスループットを計算することにより、上記リソースに対する評価スループットを決定する、請求項１０に記載のシステム。
22. 上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率を決定する、請求項１０に記載のシステム。
23. ルックアップテーブルをさらに備え、上記システムはさらに、上記ルックアップテーブルを用いて、上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率を決定する、請求項２２に記載のシステム。
24. サーバモジュールをさらに備え、上記サーバモジュールは、
    上記複数のリソースユーザのうちの少なくとも１人のリソースユーザから発せられた、上記リソースの利用を希望する旨の予約要求に関する情報を受信するレシーバと、
    上記更新可能なリソース利用パラメータを決定するプロセッサと、
    を備える、請求項１０に記載のシステム。
25. 上記サーバモジュールの上記プロセッサはさらに、上記リソースについての予約要求の数を決定する、請求項２４に記載のシステム。
26. 複数のリソースユーザによるリソースの利用を管理するための方法であって、
    上記複数のリソースユーザのうちで上記リソースの利用を希望する少なくとも１人のリソースユーザにより入力された予約要求をポータブルモジュールにおいて取得するステップと、
    上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を、更新可能なリソース利用パラメータに基づいて特定するステップと、
    を備えており、上記更新可能なリソース利用パラメータは、
    （ｉ）追加のポータブルモジュールを持っているリソースユーザによりなされた上記リソースについての予約要求の数、および
    （ｉｉ）ポータブルモジュールを持っている上記リソースの各ユーザに対する見積スループット、
    に基づいて決定され、上記見積スループットは、
    （ａ）上記リソースを利用する可能性のあるユーザの総数に対する、上記リソースを利用する可能性があり且つポータブルモジュールを持っているユーザの数の比率、および
    （ｂ）上記リソースに対する評価スループット、
    の組み合わせに基づいて決定され、
    さらに、上記ポータブルモジュールのそれぞれのユーザに特定された上記時間枠を示すステップを備える、方法。
27. 各ポータブルモジュールにおいて、上記入力された予約要求を格納するステップと、
    上記各ポータブルモジュールにおいて、他のポータブルモジュールから発せられた上記リソースに対する少なくとも１つの予約要求に関する情報を受信するステップと、
    上記各ポータブルモジュールにおいて、上記入力された予約要求と、受信された上記少なくとも１つの予約要求に関する上記情報と、の組み合わせにより、上記リソースに対する予約要求の総数を決定するステップと、
    上記各ポータブルモジュールにおいて、上記予約要求の総数に関する情報を送信するステップと、をさらに備える、請求項２６に記載の方法。
28. 互いに異なる各ポータブルモジュールにおいて、上記格納するステップ、上記受信するステップ、上記決定するステップ、および上記送信するステップ、を繰り返す、請求項２８に記載の方法。
29. 各ポータブルモジュールにおいて、上記更新可能なリソース利用パラメータを受信するステップと、
    上記各ポータブルモジュールにおいて、上記更新可能なリソース利用パラメータを格納するステップと、をさらに備える、請求項２６に記載の方法。
30. あるポータブルモジュールから他のポータブルモジュールへ、上記更新可能なリソース利用パラメータを送信するステップをさらに備える、請求項３０に記載の方法。
31. 請求項２６に記載の方法を実行する指示がプログラムされた、ポータブル電子デバイス。
32. 請求項２６に記載の方法を実行するコンピュータプログラムが記録された、コンピュータ読取可能な記録媒体。
33. 複数のリソースユーザによるリソースの利用を管理するためのポータブルモジュールであって、
    上記複数のリソースユーザのうちの少なくとも１人のリソースユーザから発せられた、上記リソースの利用を希望する旨の予約要求を、当該ポータブルモジュールに入力するモジュール入力部と、
    更新可能なリソース利用パラメータを受信するレシーバと、
    上記予約要求を受けて、上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を、上記更新可能なリソース利用パラメータに基づいて特定するプロセッサと、
    上記更新可能なリソース利用パラメータを交信するトランスミッタと、
    特定された時間枠を、ユーザに示すモジュール出力部と、
    を備える、ポータブルモジュール。
34. 複数のリソースユーザによるリソースの利用を管理するための方法であって、
    上記複数のリソースユーザのうちで上記リソースの利用を希望する少なくとも１人のリソースユーザから入力された予約要求をポータブルモジュールにおいて取得するステップと、
    各ポータブルモジュールにおいて、更新可能なリソース利用パラメータを受信するステップと、
    上記各ポータブルモジュールにおいて、上記更新可能なリソース利用パラメータを送信するステップと、
    上記更新可能なリソース利用パラメータに基づいて、上記少なくとも１人のリソースユーザが上記リソースを利用し得る時間枠を特定するステップと、
    を備える、方法。
35. ポータブルモジュールであって、
    トークン数に関する情報を入力するモジュール入力部と、
    当該ポータブルモジュールにおいて受けた上記トークン数を格納するデータストレージと、
    当該ポータブルモジュールとネットワーク内のルートノードとの間のリンククオリティに関するリンククオリティパラメータを決定するとともに、追加のポータブルモジュールに対する上記リンククオリティパラメータに関する情報を受信するトランシーバと、
    当該ポータブルモジュールとルートノードとの間のリンククオリティが、上記追加のポータブルモジュールとルートノードとの間のリンククオリティよりも高い場合には、上記トランシーバは、上記追加のポータブルモジュールに格納された上記トークン数に関する情報を受信し、且つ、上記データストレージは、上記データストレージ内に格納された数に、受信した上記トークン数を加え、
    上記追加のポータブルモジュールとルートノードとの間のリンククオリティが、当該ポータブルモジュールとルートノードとの間のリンククオリティよりも、高い場合には、上記トランシーバは、上記データストレージ内に格納された上記トークン数に関する情報を、上記追加のポータブルモジュールに送信する、ポータブルモジュール。
36. 上記追加のポータブルモジュールと上記ルートノードとの間のリンククオリティが、上記ポータブルモジュールと上記ルートノードとの間のリンククオリティよりも、高い場合、上記データストレージは、その中に格納された上記トークン数をゼロにセットする、請求項３５に記載のポータブルモジュール。
37. 当該ポータブルモジュールとルートノードとの間のリンククオリティが、上記追加のポータブルモジュールと上記ルートノードとの間のリンククオリティよりも高い場合には、上記トランシーバは確認メッセージを送信し、
    上記追加のポータブルモジュールと上記ルートノードとの間のリンククオリティが、上記ポータブルモジュールとルートノードとの間のリンククオリティよりも高い場合には、上記トランシーバは確認メッセージを受信する、請求項３６に記載のポータブルモジュール。
38. 上記トランシーバが上記確認メッセージを受信した後に、上記データストレージは、その中に格納された上記トークン数をゼロにセットする、請求項３７に記載のポータブルモジュール。
39. 上記トランシーバは、上記追加のポータブルモジュールに対する上記リンククオリティパラメータに基づいて、当該ポータブルモジュールに対する上記リンククオリティパラメータを決定する、請求項３５に記載のポータブルモジュール。
40. ルートノードを含むとともに、請求項３５にかかるポータブルモジュールを複数備えるネットワーク。
41. 上記ルートノードはポータブルモジュールを備える、請求項４０に記載のネットワーク。
42. 上記ルートノードは、サーバモジュールを備え、上記サーバモジュールは、
    ポータブルモジュールに格納された上記トークン数を受信するレシーバを備える、請求項４０に記載のネットワーク。
43. ルートノードおよび複数のポータブルモジュールを含むネットワークのユーザから受けたトークン数を決定するための方法であって、
    第１のポータブルモジュールへの入力において、トークン数に関する情報をユーザから受信するステップと、
    第１のポータブルモジュールにおいて受信したトークン数を、データストレージ内に格納するステップと、
    上記第１のポータブルモジュールと、上記ネットワーク内の上記ルートノードと、の間のリンククオリティに関するリンククオリティパラメータを決定するステップと、
    第２のポータブルモジュールの上記リンククオリティパラメータに関する情報を、上記第１のポータブルモジュールにおいて受信するステップと、
    上記第１ポータブルモジュールと上記ルートノードとの間のリンククオリティが、上記第２のポータブルモジュールと上記ルートノードとの間のリンククオリティよりも、高い場合、上記第２のポータブルモジュール内に格納されたトークン数に関する情報を、上記第１のポータブルモジュールにおいて受信し、受信したトークン数を上記第１のポータブルモジュールの上記データストレージ内に格納された上記トークン数に加えるステップと、
    上記第２のポータブルモジュールと上記ルートノードとの間のリンククオリティが、上記第１のポータブルモジュールと上記ルートノードとの間のリンククオリティよりも、高い場合、上記第１のポータブルモジュールから上記第２のポータブルモジュールへ、上記第１のポータブルモジュール内に格納された上記トークン数を送信するステップと、
    を備える、方法。
44. 上記第２のポータブルモジュールと上記ルートノードとの間のリンククオリティが、上記第１のポータブルモジュールと上記ルートノードとの間のリンククオリティよりも、高い場合、上記第１のポータブルモジュール内に格納されたトークン数をゼロにセットするステップをさらに備える、請求項４３に記載の方法。
45. 上記第１のポータブルモジュールと上記ルートノードとの間のリンククオリティが、上記第２のポータブルモジュールと上記ルートノードとの間のリンククオリティよりも、高い場合、確認メッセージを交信するステップと、
    上記第２のポータブルモジュールと上記ルートノードとの間のリンククオリティが、上記第１のポータブルモジュールと上記ルートノードとの間のリンククオリティよりも、高い場合、確認メッセージを受信するステップと、
    をさらに備える、請求項４３に記載の方法。
46. 上記確認メッセージを受信するステップの後に、上記トークン数をゼロにセットするステップが実行される、請求項４５に記載の方法。
47. 上記リンククオリティパラメータを決定するステップにおいて、上記第２のポータブルモジュールに対する上記リンククオリティパラメータに基づいて、上記第１のポータブル
    モジュールに対する上記リンククオリティパラメータを決定する、請求項４３に記載の方法。

Images