(57)【要約】  種々の間隔で、地理的に分散したプレーヤが同一の問題に実質的に同時に解答するような種類のコンテストを実現する。代表的な実施形態では、問題（一般には質問）は一日の中で、見かけ上、ランダムな時間、あるいは特定の時間間隔で出題され、プレーヤは問題に解答するか、あるいは問題が出題されたときにそのプレーヤの時間がとれないなどの場合には、現在の問題をパスして次の問題を待つかを選択する。このような実施形態では、プレーヤが解答しても良い問題数以上の問題がゲームのルールにしたがって出題され、プレーヤは問題の解答時点に関して柔軟性を有する。また、実質的に同時にアラートを生成するシステムであって、複数のユーザ装置は少なくとも一つの公衆が利用可能なネットワークでもってアクセスするシステムを提供する。各ユーザ装置にはアラートベースのクライアントが実装されている。サーバは暗号化されたメッセージを含む同一のアラート情報を複数のユーザ装置にダウンロードするように構成される。アラートベースのクライアントは、アラート情報を受信し、アラート情報を受信したら(i)メッセージを暗号化された形式で特定の配信時刻の直前まで保存し、(ii)実質的に特定の配信時刻においてメッセージを復号して配信するように構成される。以上の構成により、メッセージを実質的に同時にユーザ装置に配信することができる。
2009512019.tif 000002
【特許請求の範囲】
【請求項１】
間欠的に競技を行うコンテストを同時開催する方法であって、
（ａ）  地理的に分散したプレーヤに、同じ問題を実質的に同時に配信する工程と、
（ｂ）  前記問題に対する応答をプレーヤから受信し、該応答の応答時間を測定する工程と、
（ｃ）  前記応答と前記応答時間に基づいて、各プレーヤのスコアを決定する工程と、
（ｄ）  連続する問題の配信間隔の時間の中央値を少なくとも３０分とし、各プレーヤ毎に合計スコアを保持しながら前記（ａ）乃至（ｃ）の工程を複数回繰り返す工程と、
を備えた方法。
【請求項２】
少なくとも１００人のプレーヤがいることを特徴とする請求項１に記載の方法。
【請求項３】
少なくとも多数のプレーヤのそれぞれに対して前記問題が配信され、前記応答の入力及び前記応答時間の測定が同じユーザ装置上で行われることを特徴とする請求項１に記載の方法。
【請求項４】
公衆が利用可能なネットワークを介して、前記ユーザ装置に予め前記問題をダウンロードする工程を更に備えたことを特徴とする請求項３に記載の方法。
【請求項５】
現在の問題に参加するか否かをプレーヤが決定することを許可する工程を更に備え、
現在の問題に参加したプレーヤのみに現在の問題についてのスコアを付与することを特徴とする請求項１に記載の方法。
【請求項６】
プレーヤに解答が許可される問題数以上の前記問題が提供され、プレーヤが参加する時期に関してプレーヤが柔軟性を有することを特徴とする請求項５に記載の方法。
【請求項７】
（ｅ）  少なくとも一人の他のプレーヤと自発的に提携することをプレーヤに許可する工程と、
（ｆ）  第一のプレーヤと第二のプレーヤとが提携している場合、前記第二のプレーヤが獲得したポイント数に直接的に基づくポイントを前記第一のプレーヤに付与する工程と、
を更に備えたことを特徴とする請求項１に記載の方法。
【請求項８】
前記第一のプレーヤは、前記第二のプレーヤから第三のプレーヤに前記提携を変更することができ、この場合、前記第一のプレーヤは、前記第二のプレーヤが獲得したポイントに基づくポイントの受取りを中止し、前記第三のプレーヤが獲得したポイント数に直接的に基づくポイントを受け取り始めることを特徴とする請求項７に記載の方法。
【請求項９】
正解と認められるためには、プレーヤは前記問題が配信されてから所定の時間内に前記問題に解答しなければならないことを特徴とする請求項１に記載の方法。
【請求項１０】
前記所定の時間は９０秒以内であることを特徴とする請求項９に記載の方法。
【請求項１１】
前記問題に解答する機会は、プレーヤに予め知らされていない時点にプレーヤに与えられることを特徴とする請求項１に記載の方法。
【請求項１２】
与えられた問題に正答したときには、その問題が配信された後、前記正答がどのくらい早く提出されたかによってポイント数が付与されることを特徴とする請求項１に記載の方法。
【請求項１３】
前記（ａ）乃至（ｃ）の工程は、少なくとも５日間に渡って、毎日繰り返されることを特徴とする請求項１に記載の方法。
【請求項１４】
間欠的に競技を行うコンテストを同時開催するシステムであって、
（ａ）  地理的に分散したプレーヤに、同じ問題を実質的に同時に配信する手段と、
（ｂ）  前記問題に対する応答をプレーヤから受信し、該応答の応答時間を測定する手段と、
（ｃ）  前記応答と前記応答時間に基づいて、各プレーヤのスコアを決定する手段と、
（ｄ）  連続する問題の配信間隔の時間の中央値を少なくとも３０分とし、各プレーヤ毎に合計スコアを保持しながら前記（ａ）乃至（ｃ）の手段の実行を複数回繰り返す手段と、
を備えたシステム。
【請求項１５】
少なくとも１００人のプレーヤがいることを特徴とする請求項１４に記載のシステム。
【請求項１６】
少なくとも多数のプレーヤのそれぞれに対して前記問題が配信され、前記応答の入力及び前記応答時間の測定が同じユーザ装置上で行われることを特徴とする請求項１４に記載のシステム。
【請求項１７】
公衆が利用可能なネットワークを介して、前記ユーザ装置に予め前記問題をダウンロードする手段を更に備えたことを特徴とする請求項１６に記載のシステム。
【請求項１８】
（ｄ）  少なくとも一人の他のプレーヤと自発的に提携することをプレーヤに許可し、第一のプレーヤと第二のプレーヤとが提携している場合、前記第二のプレーヤが獲得したポイント数に直接的に基づくポイントを前記第一のプレーヤに付与する手段を更に備えたことを特徴とする請求項１４に記載のシステム。
【請求項１９】
前記第一のプレーヤは、前記第二のプレーヤから第三のプレーヤに前記提携を変更することができ、この場合、前記第一のプレーヤは、前記第二のプレーヤが獲得したポイントに基づくポイントの受取りを中止し、前記第三のプレーヤが獲得したポイント数に直接的に基づくポイントを受け取り始めることを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記問題に解答する機会は、プレーヤに予め知らされていない時点にプレーヤに与えられることを特徴とする請求項１４記載のシステム。
【請求項２１】
実質的に同時にアラートを生成するシステムであって、
（ｄ）  アラートベースのクライアントが実装され、少なくとも一つの公衆が利用可能なネットワークを介してアクセス可能な複数のユーザ装置と、
（ｅ）  暗号化されたメッセージを含む同一のアラート情報を前記複数のユーザ装置にダウンロードするように構成されたサーバと、
を備え、
前記アラートベースのクライアントは、
前記アラート情報を受信し、
（ｉ）前記メッセージを暗号化された形式で特定の配信時刻の直前まで保存し、
（ｉｉ）実質的に前記特定の配信時刻において前記メッセージを復号して配信するよう構成され、
これにより、前記ユーザ装置に前記メッセージを実質的に同時に提供することを特徴とするシステム。
【請求項２２】
少なくとも１００の前記ユーザ装置が存在し、前記ユーザ装置は地理的に分散していることを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記サーバは、クロック同期情報を前記複数のユーザ装置にダウンロードするように構成されていることを特徴とする請求項２１に記載のシステム。
【請求項２４】
前記アラートベースのクライアントは、
前記ユーザ装置の、リアルタイムクロックからの情報とデバイスクロックからの情報とを比較して、クロック異常を特定するように構成されていることを特徴とする請求項２１記載のシステム。
【請求項２５】
前記アラートベースのクライアントは、前記メッセージに対してユーザが直ぐに応答の操作ができるユーザインターフェースと共に前記メッセージを配信するように構成されていることを特徴とする請求項２１に記載のシステム。
【請求項２６】
前記アラートベースのクライアントは、前記メッセージが配信された後、前記操作がどのくらい早く行われたかを計時し、これによりユーザ応答時間を生成するように構成されていることを特徴とする請求項２５に記載のシステム。
【請求項２７】
前記アラートベースのクライアントは、前記ユーザ応答時間を前記サーバに提供するように構成され、前記サーバは前記ユーザ応答時間に基づいて判断するように構成されていることを特徴とする請求項２６に記載のシステム。
【請求項２８】
前記操作がユーザ応答となり、前記アラートベースのクライアントは前記ユーザ応答を前記サーバに提供するように構成されていることを特徴とする請求項２５に記載のシステム。
【請求項２９】
前記アラート情報は、少なくとも一つの公衆が利用可能なセルラー無線ネットワークを介して多数の前記ユーザ装置にダウンロードされることを特徴とする請求項２１に記載のシステム。
【請求項３０】
前記アラート情報は前記特定の配信時刻を含むことを特徴とする請求項２１に記載のシステム。
【請求項３１】
前記特定の配信時間を、前記特定の配信時刻前に、ユーザ装置又はユーザに知らせないことを特徴とする請求項２１記載のシステム。
【請求項３２】
アラートを受信して提供する装置であって、
（ｄ）  実行可能な処理ステップを記憶した、少なくとも１つのメモリ又は記憶装置と、
（ｅ）  前記処理ステップを実行するプロセッサと、
（ｆ）  日時を刻むリアルタイムクロックと、
（ｇ）  前記メモリ又は前記記憶装置と前記プロセッサとに、処理同期信号を供給するデバイスクロックと、
を備え、
前記実行可能な処理ステップは、
メッセージを含むアラート情報を受信するステップと、
（ｉ）前記少なくとも１つのメモリ又は記憶装置に、前記メッセージを暗号化された形式で特定の配信時刻の直前まで保存するステップと、
（ｉｉ）実質的に前記特定の配信時刻において前記メッセージを復号して配信ステップと、を含み、
また、前記実行可能な処理ステップは、
前記リアルタイムクロックからの情報と前記デバイスクロックからの情報とを比較し、クロック異常を特定するステップを含むことを特徴とする装置。
【請求項３３】
前記クロック異常はユーザによる改ざんを含むことを特徴とする請求項３２に記載の装置。
【請求項３４】
前記実行可能な処理ステップは外部源からクロック同期情報を受信するステップを含み、前記クロック同期情報は前記クロックのクロック異常の特定にも利用されることを特徴とする請求項３２記載の装置。
【請求項３５】
前記実行可能な処理ステップは、前記メッセージに対してユーザが直ぐに応答の操作ができるユーザインターフェースと共に前記メッセージを配信するステップを含むことを特徴とする請求項３２に記載のシステム。
【請求項３６】
前記実行可能な処理ステップは、前記メッセージが配信された後、前記操作がどのくらい早く行われたかを計時するステップを含み、これによりユーザ応答時間を生成することを特徴とする請求項３５に記載の装置。
【請求項３７】
前記実行可能な処理ステップは、前記ユーザ応答時間を外部サーバに提供するステップを含むことを特徴とする請求項３６に記載の装置。
【請求項３８】
前記操作がユーザ応答となり、前記実行可能な処理ステップは前記ユーザ応答を前記外部サーバに提供するステップを含むことを特徴とする請求項３５に記載の装置。
【請求項３９】
前記装置は携帯電話であることを特徴とする請求項３２に記載の装置。
【請求項４０】
前記アラート情報は前記特定の配信時刻を含むことを特徴とする請求項３２に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２００５年１０月６に出願され、「Real-Time Incentivezed Game Platform」と題する米国特許仮出願第６０／７２４、４７３号の利益を主張するものであり、この出願の内容は本書に組み込まれる。
【０００２】
＜技術分野＞
本発明は、地理的に分散した多数のプレーヤによって、実質的に同時であり、間欠的な間隔で競技を行うコンテスト、及び、無線携帯電話やＰＤＡなどの、多数の異なるユーザ装置に実質的に同時にメッセージを配信するシステムに関する。
【背景技術】
【０００３】
多様な種類のゲームやコンテストは存在する。しかしながら、他人と競争する新たな方法を人々は常に求めている。
【発明の開示】
【０００４】
本発明は、このようなニーズに着目したものであり、全く新たなコンテストを提供する。このコンテストでは、様々な感覚で、地理的に分散したプレーヤが同じ問題を、実質的に同時に解答することができる。代表的な実施形態では、問題（代表的には質問）は一日の中で、見かけ上、ランダムな時間（あるいは特定の時間間隔）で出題され、プレーヤは問題に応答するか、あるいは、現在の問題をパスして次の問題を待つか（例えば、問題が出題されたときにそのプレーヤが時間をとれない場合等）、を選択することができる。このような実施形態では、そのゲームのルールに従ってプレーヤが解答可能な数以上の質問が出題され、プレーヤは参加時期に関して柔軟性を有する。
【０００５】
すなわち、本発明の一態様は、間欠的に競技を行うコンテストを同時開催するシステム、方法及び技術に関する。まず、同一の問題が、地理的に分散したすべてのプレーヤに実質的に同時に配信される。問題に対するプレーヤからの応答が受信され、その応答時間が測定され、前記応答と前記応答時間とに基づいてプレーヤのスコアが決定される。これらのステップは、連続する問題の配信間隔の時間の中央値を少なくとも３０分とし、各プレーヤ毎に合計スコアを保持しながら複数回繰り返される。
【０００６】
本発明の他の態様は、実質的に同時にアラートを生成するシステムに関し、このシステムでは複数のユーザ装置が、少なくとも一つの公衆が利用可能なネットワークを介してアクセス可能である。各ユーザ装置にはアラートベースのクライアントが実装されている。サーバは、暗号化されたメッセージを含む同一のアラート情報を、複数のユーザ装置にダウンロードするように構成される。アラートベースのクライアントは、アラート情報を受信し、アラート情報を受信したら：（ｉ）メッセージを暗号化された形式で特定の配信時刻の直前まで保存し、（ｉｉ）実質的に特定の配信時刻においてメッセージを復号して配信するように構成される。以上の構成により、メッセージを実質的に同時にユーザ装置に配信することができる。
【０００７】
本発明の更に他の態様は、アラートを受信して提供する装置に関する。この装置は、実行可能な処理ステップを保存する少なくとも一つのメモリ又は記憶装置と、処理ステップを実行するプロセッサと、日時を刻むリアルタイムクロックと、処理同期信号をメモリ／記憶装置とプロセッサに提供するデバイスクロックが含まれる。実行可能な処理ステップには、メッセージを含むアラート情報を受信し、アラート情報を受信したらメッセージを暗号化された形式で少なくとも一つのメモリ／記憶装置に特定の配信時刻の直前まで保存し、実質的に特定の配信時刻においてメッセージを復号して配信するステップが含まれる。実行可能な処理ステップには、リアルタイムクロックからの情報とデバイスクロックからの情報とを比較してクロック異常を特定するステップがさらに含まれる。以上の構成により、情報が配信されるタイミングを正確に制御することが可能となる。
【０００８】
以上の概要は、本発明の概略を簡単に説明したものである。本発明は、特許請求の範囲や、以下の好適な実施形態の詳細説明を添付図面とともに参照することで、より深く理解することができよう。
【発明を実施するための最良の形態】
【０００９】
以下の説明は複数のセクションからなる。第一セクションでは、コンテストを実現するための技術的な事柄と本発明の他の方法とを説明する。第二セクションでは、このようなプラットフォームを用いて実現され得るコンテストの例を説明する。続くセクションでは、見出しに示す他の情報を説明する。
【００１０】
＜実質的に同時のアラート技術＞
本発明中の複数の技術は、メッセージを実質的に同時に多数の地理的に分散した（異なる市、州、さらには国などに散らばっている）個人や装置に配信するために必要となるものである。図１は、本発明の代表的な実施形態に基づき、このような目的を達成するためのアラートシステム１０の全体を示している。
【００１１】
概して、アラートシステム１０は、中央サーバ１２が、複数の異なるユーザ装置（装置２１−２６など）と通信することで動作する。通常、各装置２１−２６には、装置２１に対するユーザ３１、装置２２に対するユーザ３２などのように、一人のユーザが対応する。ただし、一人のユーザ（例えばユーザ３３）が複数の装置（例えば装置２３と２４）を保持し、詳細は後述するようにそれぞれがサーバ１２に登録されていることもあり得る。
【００１２】
サーバ１２は単一の物理デバイスとして実現され得るが、良く知られているように、一般には冗長性を持ったサーバクラスタ、適切な負荷共有ハードウェア／ソフトウェア、種々の物理ボックスに分散配置された種々の機能群として実現され得る。実施形態の１つとしては、種々の物理デバイスが、直接インターネットを介したり、SMSメッセージングを用いたり、独自の無線プロトコルを用いたりして、多様なネットワークを介して通信を行うために用いられる。
【００１３】
図１では、６つのユーザ装置２１−２６が示されているが、これは説明をわかりやすくするためであることに留意されたい。一般には、アラートシステム１０に参加するユーザ装置の数は、５０、１００、５００、１０００、さらには１００００などというように多くなる（ユーザ数も同様である）。また、同じサーバ１２を用いて複数のアラートシステムを実現することも可能であり、この場合、そのような異なるシステム毎に異なる配布先リストやバックエンド処理ルーチンを用いることができる。
【００１４】
各ユーザ３１−３５は、好ましくは、予め現在のアラートシステム１０のサーバ１２に登録し、ユーザ３１−３５がアラートを受信したい装置や、サーバ１２がその装置と通信する態様を指示する。この後者の点において、本発明は、サーバ１２と種々のユーザ装置２１−２６との間に複数の異なる通信モードを想定している。
【００１５】
最も多く使われると思われる通信モードは、無線ネットワーク４１である。無線ネットワーク４１を用いることで、対応するユーザ装置２１が、いつでもサーバ１２と通信し易くなる。しかし、詳細は後述するが、本発明の好適な実施形態では、所望の動作を行わせるためにリアルタイム通信は必須ではない。
【００１６】
無線ネットワーク４１を介する通信では、多様な通信技術を用いることができる。例えば、ショートメッセージングサービス（SMS）を介したり、無線ウェブ通信を用いたり、無線キャリアが導入している公開のあるいは独自の無線データプロトコルを用いたりして、メッセージが送信される。
【００１７】
多く使われると思われる他の通信モードとして、直接のインターネット通信４２を挙げることができる。この一般的名モードでは、また、ハイパーテキスト転送プロトコル（HTTP）、ファイル転送プロトコル（FTP）、独自のデータ転送プロトコル、インスタントメッセージング、電子メールメッセージングプロトコルなどといった多様なプロトコルを用いて、情報を転送することができる。
【００１８】
上述の通り、一人のユーザ３３が別々の装置２３と２４を特定のアラートシステムに参加させるようにサーバ１２に登録することもできる。また、図１に示すように、別々の装置２３と２４に対して、複数の異なる通信パス４３を用いることもできる。例えば、装置２３には無線ネットワークを、装置２４には直接インターネット接続を用いることができる。
【００１９】
ユーザ３３は、複数の装置２３と２４を現在アクティブなものとして指定することができる。これにより、発生したアラートは双方の装置に配信され、適切な時刻において装置２３と２４のいずれかの近くにユーザ３３が位置する可能性が高まる。また、ユーザ３３は、メッセージが配信される時点に基づいて、装置２３と２４のいずれか一方にメッセージが配信されるように指定することもできる。この場合、どの時点において装置２３と２４のどちらをアクティブにするといったスケジュールを、ユーザ３３は指定することになる。さらに、装置２３と２４以外の装置を登録することも可能であり、ある時点でアクティブとする装置数をユーザ３３が自在に指定することができることが好ましい。
【００２０】
また、直接接続４４などを用いて、サーバ１２とネットワーク接続されていない装置２５（ユーザ３４に対応）とが通信することもできる。例えば、対向ケーブル、赤外線やBluetoothなどの無線接続を用いて、必要となるデータが転送される。なお、サーバ１２が、まず必要情報をネットワーク接続されたコンピュータや他の装置にダウンロードし、次いでユーザ装置２５にその情報を直接転送する場合のように、直接配信４４は全体の配信プロセスの一つのステップとなることもある。
【００２１】
最後に、サーバ１２は放送メディア（無線周波数を用いた無線放送、テレビケーブルやインターネット放送を用いた有線放送など）を介してユーザ装置２６と通信することもできる。図示の実施形態では、ユーザ装置２６は、インタラクティブテレビを示しているが、汎用コンピュータや携帯電話など他の装置を用いて放送を受信することもあり得る。
【００２２】
サーバ１２と多様なユーザ装置２１−２６とが通信する上述の手法は、あくまでも例として示したものである。これらに代えて他の通信モードやパスを利用してもよく、また、これらにに追加して用いることもできる。また、異なるパスやモードを組み合わせて用いることもできる。
【００２３】
図１は、サーバ１２と多様なユーザ装置２１−２６との間の一方向通信を示している。しかしながら、本発明の他の好適な実施形態では、サーバ１２とユーザ装置２１−２６との間の通信が双方向となる。
【００２４】
図２は、サーバ１２とユーザ装置２１とが双方向で通信する様子を示している。詳細は後述するが、この実施形態では、サーバ１２はアラート情報６１と時刻同期情報６２とをユーザ装置２１に送信し、ユーザ装置２１はそのアラート情報６１に対する応答６３をサーバ１２に返信する。本発明の好適な実施形態では、このような通信はある程度の時間間隔を空けて行われ、通信がなされる時点がユーザ装置２１と他のユーザ装置２２−２６とで大きく異なることもあり得る。このような事象は、すべてのユーザ装置２１−２６がメッセージ６１を実質的に同時に配信し、対応ユーザ３１−３５が応答６３を実質的に同時に返信するような場合に起こる。具体的には、好適な実施形態において、アラート情報６１はスケジュールされた時点に先立ってユーザ装置２１に保存され、対応ユーザ３１が入力した以降の時点で応答がサーバ１２に送信される。なお、多様な種類の情報が多様な通信チャネルを用いて送信される。
【００２５】
図３は、本発明の代表的な実施形態におけるユーザ装置２１の一部を示したブロック図である。本実施形態において、ユーザ装置２１は、本発明に関連する特定の機能のすべて、あるいはほとんどを実行するアラートベースのクライアントアプリケーション８０を含む。アプリケーション８０は、Ｊａｖａ（登録商標） midlet やBrew アプリケーションなどのように完全にソフトウェアで実装されることが好ましいが、他の手法で実装されていても良い。
【００２６】
図示のように、アプリケーション８０は装置２１の入力／出力インタフェース８２と通信する。具体的な装置２１に応じて、一般にインタフェース８２はハードウェア部とソフトウェア部とからなり、TCP/IP(Transmission Control Protocol / Internet Protocol) ネットワークや無線通信チャネル（セルラーベース、802.11x ファミリーのプロトコル、Bluetooth、赤外線など）を介して通信がなされる。一般には、入力／出力インタフェース８２が、装置２１内のクライアントアプリケーション８０とサーバ１２との間の主たる通信リンクとなる。
【００２７】
詳細は後述するが、アプリケーション８０はインタフェース８２から受信したある情報を、指定された配信時刻といったある適当な時刻まで装置メモリや記憶装置８３（不揮発性のものが好ましい）に保存する。また、アプリケーション８０はデバイスクロック８５やリアルタイムクロック８６を監視することが好ましい。ここで、デバイスクロック８５は一般にハードウェアデバイスであり、装置２１内の複数のハードウェア要素（例えば、アプリケーション８０を実行する汎用プロセッサを含む）が同期処理を行うためのタイミングクロック信号を生成する。一方、リアルタイムクロック８６は一般にソフトウェアアプリケーションとして実現され、現在の日時を提供する。現在の日時は、対応ユーザ３１に提示されたり、装置２１内のデータアイテムにタイムスタンプをつけるために用いられる。
【００２８】
図４は、本発明の代表的な実施形態に基づくアラート情報６１と時刻同期情報６２とを含むパケット９０の一例を示したものである。この例において、同期情報６２にはサーバ１２の現在時刻である単一のタイムスタンプが含まれている（ここでは、０．０１秒に丸められて表示されている）。アラート情報６１には、複数のエントリ９１−９３と、対応する配信時刻９５とメッセージ９６が含まれる。３つのエントリ９１−９３をここでは示しているが、３以外の数のエントリが同時に送信されても良い。また、同期情報６２がアラート情報６１と同一のパケット９０で送信される例が示されているが、同期情報６２は別のパケットで送信されても良い。さらに、この例ではメッセージ９６は質問であるが、詳細は後述するように、質問以外に多様な種類のメッセージが含まれていても良い。
【００２９】
図５は、本発明の代表的な実施形態に基づくアラートシステムを実現するプロセスの概略を示すフローチャートである。このプロセスはすべてソフトウェア（ステップ１００はサーバ１２において実行され、他のステップは一般にクライアントアプリケーション８０において実行される）で実現されることが好ましいが、他の形態で実現されてもよい。また、本プロセスの説明は、図１−３に示したハードウェア構成を参照しながら行うが、ここでの参照は利便性や理解の容易さのためであり、単なる一例であることを理解されたい。
【００３０】
はじめに、ステップ１００において、サーバ１２はアラート情報６１と時刻同期情報６２とを複数のユーザ装置２１−２６に送信する。ここで、最終的な受取人である者３１−３５が指定時刻以前に目にすることを防ぐために、少なくともアラート情報６１は暗号化されたフォーマットで送信されることが好ましい。現時点では暗号技術としてAES(Advanced Encryption Standard)を用いることが好ましいが、他の安全な暗号を用いても良い。
【００３１】
一実施形態においては、アラート情報６１と時刻同期情報６２はすべてのユーザ装置２１−２６に同時に、あるいは実質的に同時に送信される。他の実施形態では、これらの情報は複数のユーザ装置２１−２６に異なる時刻で送信される。後者のアプローチは、それぞれのメッセージ９６の配信希望時刻からのずれが許容範囲を超える程度に遅延が変動するような際に有効である。遅延差（種々の装置２１−２６が実際に同期情報６２を受信した時刻の差）が、種々の装置２１−２６間での同期が取れなくなってしまうためである。少なくとも同期情報６２を個別に各ユーザ装置２１−２６に送信することで、装置への遅延をある程度推定して対処することが可能となる。
【００３２】
例えば、伝送遅延が変動し、所望の許容範囲以上となる場合には、他の手法を用いてサーバ１２と個々の装置２１−２６との間の遅延を推定し、遅延補正を行うことができる。サーバ１２は、同期時刻を単に送信するのではなく、まず一つ以上のプローブパケットをそのユーザ装置２１に送信する。ユーザ装置２１のクライアントアプリケーション８０は応答パケットを自動的に送信するように構成されており、そのユーザ装置２１に対してピングがなされるように動作する。これにより、伝送遅延が対称であるとすると、サーバ１２は往復遅延（一つ以上のパケットが送信された場合には往復遅延の平均）を半分にし、その量を送信同期時刻６２に付加するなどの調整を行うことで、予想一方向遅延を補償することができる。
【００３３】
なお、他の手法を用いて、予想遅延を推定し、調整することもできる。また、アラート情報６１の量が送信帯域に比して多いような場合には、同期時刻６２をアラート情報６１と別に送信することが遅延時間の低減に資する場合もある。
【００３４】
アラート情報６１は、典型的には比較的簡単に作成される。ユーザあるいは別の自動プロセスがサーバ１２に一つ以上のメッセージ９６を提供することで、１つあるいは複数の特定の配信時刻９５にユーザ装置２１−２６の特定のグループにそのメッセージが配信される。装置２１−２６のリストは、予定配信時刻にアクティブにさせたい装置を示すユーザ嗜好情報に基づいて生成される。このようなアラート情報６１は最先の特定の配信時刻９５よりも以前に、好ましくは暗号化された形で配信される。
【００３５】
ここで、ステップ１００は、図５中の他の処理ステップとは異なる形で示されていることに注意されたい。サーバ１２が配信する新しいアラート６１を得たときのように、ステップ１００は全体の処理の中でいつでも実行され得るためである。また、ステップ１００は、メッセージを予め配信するにあたって時計が正しく動いているかをチェックするなどのために、サーバ１２あるいはユーザ装置２１上で動いているアラートベースのクライアント８０いずれかからの要求によって実行されることもあり得る。
【００３６】
すなわち、ステップ１００は通常の環境ではスリープモードあるいはバックグラウンドモード（後述）から起動されるが、通常の処理フローの外に位置するステップとなる。しかし、初期時刻の同期やアラート情報６１のダウンロードを行うために、ステップ１００は本プロセスの第一ステップとして実行されることが好ましい。
【００３７】
次いで、ステップ１０２において、クライアント８０はリアルタイムクロック８６をチェックする時間まで待機する。ここで、本実施形態では、クライアント８０が最少の処理を行う「スリープ」モードと「バックグラウンド」モードとを具備していることを注意されたい。スリープモード中のクライアント８０が実行する機能の一つは、リアルタイムクロック８６を定期的にチェックして、メッセージを配信する時間であるかどうか、時計の精度を確認する時間であるかどうかを決定することである。ステップ１０２における待機時間は、デバイスクロック８５によって生成される所定数のクロックサイクルである。
【００３８】
ここで、クロックサイクルの計数はソフトウェアで実行される。ただし、不必要なプロセッサの利用を避けたい場合には、所望カウントに達したときにインタラプト信号を生成するような単純なハードウェアカウンタを用いることもできる。好適な実施形態においては、クライアント８０は約５分ごとにリアルタイムクロック８６をチェックする。
【００３９】
ステップ１０４において、クライアント８０はリアルタイムクロック８６の現在値を読み取り、変化や潜在的な改ざんをチェックする。他の箇所で説明しているように、本実施形態では、規定の配信時刻前に、ある情報（例えば、コンテストの質問や金融ニュース）を知りたいという欲求が生じる場合がある。そのため、本発明では、好ましくは、改ざんや通常生じる時間のずれを検出して補正する複数の手段を用いる。
【００４０】
上述のように、クライアント８０は、少なくとも３種類の時刻指標にアクセスできることが好ましい。第一は、サーバ１２から提供される同期時刻６２である。最も正確であるものの、更新頻度は最も少ない。第二は、デバイスクロック８５に基づく定期的なクロックチェック信号セットである。絶対時刻は得られないが、時間間隔の指標となる。第三は、リアルタイムクロック８６である。絶対時刻の最新の指標となるが、サーバ１２のクロックとの同期がずれることや、しばしばタイムゾーンが異なることもある。また、少なくとも第二と第三の指標はユーザの操作の影響を受けることもある。時刻同期の完全性を保持するために、ステップ１０４において、クライアントアプリケーション８０は、好ましくは、これら３つの指標のずれに基づいて、定常バイアスなのか、定常ドリフトなのか、突然の変化が生じたのかなどを検出する。
【００４１】
例えば、二つの連続するチェック信号間でリアルタイムクロック８６が示す時刻に大きな変化があり、その変化が予想時刻間隔と比べて大きく異なっている場合（あるいは時刻が逆戻りしている場合）には、改ざん状態であると決定され得る。また、変化が予想時間間隔と比べてそれ程大きくない場合には更に監視を続け（例えば、続くクロックチェック点間の間）、ユーザ装置２１のリアルタイムクロック８６が本来よりも（例えば特定の範囲以上に）単に進んでいるだけなのか、遅れているだけなのかの判断を行う。もちろん、このような状況は、リアルタイムクロック８６の時刻を、より巧妙に操作することによっても生じ得る。いずれにせよ、検出した相違を考慮して、少なくとも各メッセージの配信時刻９５（あるいは、内部クロック較正）の調整がなされる。
【００４２】
ステップ１０６において、リセットを行うか否かの判断がなされる。リセットを行うのは、例えば、（ｉ）リアルタイムクロック８６の時刻とデバイスクロック８５に基づく周期チェック信号から推測される時刻との間のずれが大きい場合や、（ｉｉ）デバイスクロック８５とリアルタイムクロック８６の許容誤差により正しい時刻を決定するのが難しい場合などである。なお、これに加えて、或いは、これに代えて、より精密に改ざんを特定するために、リセット判断処理は、固定時間間隔やランダムなどのように任意のタイミングで実行され得る。
【００４３】
ステップ１０６においてリセットが決定されると、処理はステップ１００に戻り、新たな時刻同期信号６２を要求するか（このようなオンデマンド要求がサポートされている構成の場合）、あるいは単にサーバ１２からの次の時刻同期信号６２を待機する（同期信号の発生時点までユーザ装置をアラートシステムから無効とする）。リセットが不要な場合（例えば、値が許容範囲内の場合、および／又は、ずれが調整によって処理できる場合）は、処理は単にステップ１０８に進む。
【００４４】
図５には示していないが、改ざんの決定がなされると、クライアントアプリケーション８０はサーバ１２に通知し、該当ユーザを以降のシステムのアラートの対象から外すことが好ましい。なお、故意の改ざんによらずに、リアルタイムクロック８６の時刻が実際の時刻と大きく異なってしまう場合もあり得る。例えば、リセットされた装置２１が無線キャリアに接続できないと、リアルタイムクロック８６は任意の時間あるいはデフォルトの時間（例えば、午後12:00時）にリセットされてしまうような場合である。そのため、改ざん状態の決定ロジックは、このようなすべての場合を考慮してチェックするものであることが好ましく、少なくとも、改ざん状態との決定の前には、いくつかの不明なずれを許容できることが好ましい。
【００４５】
上述の実施形態において、クライアントアプリケーション８０は、リアルタイムクロック８６とサーバ１２が保持しているクロックとの間の時刻のずれを示す時刻オフセット数を保持する。すなわち、アプリケーション８０は、上述の３つの指標からの入力を用いるなどして、内部にリアルタイムクロックを保持する。
【００４６】
ステップ１０８において、装置２１がスリープモードからウェイクアップする時刻であるかどうかの判断がなされる。メッセージの配信が特定の時間内（例えば、２〜１０秒以内）に予定されている場合、あるいは次のクロックチェック信号の前である場合、次のクロックチェック信号から所定のマージン以内である場合などにウェイクアップすると判断されることが好ましい。また、ウェイクアップ処理を実行しないと判断した場合には、処理はステップ１０２に戻り、次のクロックチェック信号を待つ。ウェイクアップすると判断した場合には、処理はステップ１１０に進む。
【００４７】
ステップ１１０では、多様な種類の処理のいずれかが実行される。まず、クライアントアプリケーション８０は、ユーザインタフェースの少なくとも一部を実行することが好ましい（干渉するユーザインタフェースは無効にすることが好ましい）。概して、ここでのユーザインタフェースの第一の目的は、ユーザの注意を惹きつけることである。したがって、メッセージが配信されるという警告信号を含むことが好ましい。このような信号として、音声警告のみならず、振動や他の触覚刺激、視覚キューなどを用いることが好ましい。ステップ１０８において説明した２〜１０秒は、このような警告信号を可能とすること（及びメッセージを所定時刻に配信するために必要な他の準備を行うこと）を目的としている。ここで、メッセージが配信される時間が予め既知でないような実施形態においては、警告信号は特に重要であり、より長く出力されることが好ましい。
【００４８】
通常、ユーザインタフェースには、テキストメッセージやロゴといった視覚表示要素が含まれる。しかしながら、全てのメッセージが音で提供されたり（例えば、小さいディスプレイを備えた装置あるいはディスプレイを具備しない装置においては、合成音声あるいは音声サンプルなどを用いて）、振動や他の触覚刺激のみの場合（視覚障害者向けの装置など）もある。
【００４９】
また、本発明のある実施形態においては、警告信号はオプトインあるいはオプトアウトのメッセージとともに、ユーザ３１−３５がメッセージの受信を選択するか、あるいはメッセージの受信を選択しないかを決める間、出力される（選択したデフォルト設定に基づいて）。一般には、受信したメッセージごとに支払いを行うような場合やメッセージが慎重を期する内容であり他のユーザに見られるべきでないような場合には、限定されたメッセージのみをユーザ３１−３５が受信するオプトインシステムの方が好ましい。
【００５０】
ユーザがメッセージ９６の受信を選択して場合、好ましくは配信時刻９５の直前に、メッセージ９６の暗号を復号し、ユーザ３１−３５に配信する。複数のユーザ装置２１−２６が同様のクライアントアプリケーション８０を具備する場合には、すべてのユーザ３１−３５がメッセージを実質的に同時に受信することになる。ここで、「実質的に同時」といった表現やメッセージ配信に関する同様の表現は、通常時（例えば、システムが適切に動作しており、不適切な改ざんがない場合）において、メッセージの受信が早くなったことで受信者が得をしたり、メッセージの受信が遅くなったことで損をしたりしないように、十分近い時刻にメッセージが配信されるという意味で用いている。ここで示すほとんどの実施形態においては、最大でも１〜３秒程度の時間窓の中ですべての受信に配信される意味で本表現を用いている。
【００５１】
メッセージ９６を単に提供するのみならず、本発明のある実施形態では、ユーザ３１−３５がメッセージ９６に応答する機能をも備えている。具体的には、このような実施形態では、応答インタフェース（例えば、一つ以上のクリック可能なあるいは選択可能なボタン、ドラッグできるオブジェクト及び／又は、テキスト入力可能なフィールド）が、メッセージ９６が表示されたのと同じユーザインタフェース上に表示される。特定の実施形態や応答の時間精度に応じて、応答情報はサーバ１２にすぐに送信されるか、あるいはメモリ／記憶装置８３に保存（暗号化された形式で）され、後でサーバ１２に送信される。
【００５２】
ステップ１１０が終了すると、処理はステップ１０２に戻り、次のメッセージ配信に向けて待機モードとなる。
【００５３】
今まで、メッセージを複数のユーザに同時に配信する内容の中で技術の説明を行ってきたが、利用方法はこれに限定されない。明らかなように、上述の技術は、受信者がそれぞれ異なる指定時刻に情報を受信できるように、情報の配信時刻を制御する場合にも利用できる。また、上述の技術は人間に限定されるものではない。配信時刻を制御して自動化プロセスに情報を配信するような場合にも利用できる。後者の例として、電子振替決済や電子支払などを挙げることができる。
【００５４】
上述の説明は、メッセージを地理的に分散している複数の受信者にメッセージを実質的に同時に配信するための技術に関するものである。続く２つの節では、メッセージを実質的に同時に配信するシステムと方法について説明する。上述のアプローチは所望の実質的な同時配信を実現に向けて好適なものであるものの、以下で説明するシステムや手段も多様な他のアプローチでもって実現することができる。
【００５５】
例えば、メッセージを受信者に配信するのに必要な時間に比べて遅延が大きくない場合には、情報を直接放送しても良い。また、メッセージ自身は前もって送信し（例えば、暗号化された形式で）、メッセージ配信時点でサーバ１２（或いは他の装置）からリリース信号のみを放送しても良い。さらに、放送メッセージは１つ以上のユーザ装置上の各クライアントアプリケーションを単にウェイクアップするだけに用いて、各ユーザ装置とサーバ１２との間や、ユーザ装置とサーバ１２のすべて（あるいは一部）の間での通信チャネルを後で開く形態もあり得る。
【００５６】
別の実施形態では、多様なプッシュ技術が用いられる。例えば、SMSメッセージを用いて、各クライアントアプリケーション８０を「ウェイクアップ」させ、SMSの受信確認をサーバ１２が受信する形態もあり得る。
【００５７】
また、別の実施形態では、予めプログラムされたアラートがユーザ装置２１−２６にポップアップされ（例えば、デバイスタイマを用いて）、メッセージを取り出すためのボタンをユーザ３１−３５にクリックさせる。１クリックでサーバ１２に直接にアクセスし（例えば、HTTP）、所望のコンテンツが取り出される。
【００５８】
さらなる別の実施形態では、そのコンテンツがリアルタイムにユーザ３１−３５に放送される。このようなユーザ３１−３５は、ブロードバンド回線で応答する。
【００５９】
＜実質的に同時な間欠コンテスト＞
図６は、本発明の代表的な実施形態に基づくコンテストを実施する処理を示したフロー図である。概して、図６に基づくコンテストは、地理的に分散した複数のプレーヤによって、間欠的な時刻において、実質的に同時に実施される。各プレーヤは、図１に示したインターネット接続可能なコンピュータ、携帯電話、携帯情報端末（PDA）などを含む、装置（典型的にはネットワーク接続可能なもの）を用いて参加する。先の節の好適な実施形態における技術プラットフォームを用いる場合には、必ずしもプレーヤの装置が、プレーしている時点で実際にネットワークに接続されている必要がないことに注意されたい。このような技術は、コンテストの問題が配信されるメッセージであり、プレーヤ装置がユーザ装置２１−２６に対応し、コンテストサーバがサーバ１２に対応するようなプレゼントコンテストの実施にあたって好適なものである。したがって、説明を容易にするために、以下ではこのような実施を想定して説明する。もちろん、ここでの説明はあくまでも例として行うものであることに注意されたい。
【００６０】
コンテストは、数日から１か月、さらにはより長い期間といった、ある程度の期間にわって実施されることが好ましい。詳細は後述するが、コンテストでは、多項選択問題や他の種類の質問などを含む複数の問題が出題される。各問題はすべてのプレーヤに実質的に同時に出題され、複数の問題がコンテスト実施期間中の毎日出題されることが好ましい。また、全員が必ずしも同時にプレーしなくても良いような状況を考慮して、各プレーヤが応答することが許される問題数以上の問題をコンテストの規則にしたがって出題することが好ましい。
【００６１】
まず、コンテストの開始にあたって、第一の問題が配信されるまでの待機期間１３１がある。本発明の好適な実施形態では、問題と問題が配信される時刻のいずれも予めプレーヤには明らかにされていない。プレーヤの観点からは、問題は一日のうちでランダムに、あるいはある決められた時間窓内に配信されることが好ましい。時間窓を用いる場合には、プレーヤが存在すると想定される時間ゾーンに基づいて配信される。本発明の別の実施形態では、問題が配信される特定の時刻、あるいは少なくともいくつかの時刻は、予め一部のあるいはすべてのプレーヤに明らかになっている。
【００６２】
本コンテストの特徴は、問題がある期間内で間欠的な時刻に配信されることである。例えば、問題と問題との間隔は、典型的には少なくとも３０分、通常は１〜２時間、あるいはさらに長くして、プレーのランダム性を高める。一般に、問題の配信間隔の中央値は、少なくとも３０分、６０分、２時間であることが好ましい。また、コンテストは、少なくとも３日間、１週間、２週間、１か月、あるいはさらに長い期間にわたって実施される。好適な実施形態では、各コンテストは一か月にわたって実施し、毎日（週末や休日は除外されることがある）出題される３あるいは４の問題のうち、プレーヤは１つの問題のみを解答する。
【００６３】
いかなる場合においても、問題が配信される時刻の直前に、ステップ１３２において、プレーヤの装置を介してすべてのプレーヤにユーザインタフェースが提供される。好適な実施形態では、ユーザインタフェースはコンテスト特有のリングトーンなどの音声要素を含む警告信号であることが好ましい。ここで、警告信号が出力されるタイミングは、多様なプレーヤが事前警告を受ける時間がほぼ同じ、あるいはある一定値以上であれば、実際の問題の配信と比べて正確である必要はない。
【００６４】
また同時に、ユーザインタフェースは、プレーヤが問題に応答したいのか、あるいはパスしたいのかを確認することが好ましい。図７に、例としてのユーザインタフェース１７０を示す。図示されているように、インタフェース１７０には、新しい問題が配信されようとしていることをプレーヤに伝え、プレーヤがこの問題に参加したいかを尋ねるメッセージ１７１が含まれる。プレーヤはペアのラジオボタン１７３を用いて彼あるいは彼女の選択を指定する。また、タイマ１７５はデフォルトオプション（あるいは、プレーヤがほかのオプションを選択した際には、現在選択されているオプション）が選択されるまでの残り時間を示している。好適な実施形態では、図７に示しているように、プレーヤが問題の解答をパスするのがデフォルトオプション、すなわちプレーヤが何も応答しない場合のオプションである。また、代表的な実施形態では、タイマ１７５はおよそ４〜７秒から開始し、カウントダウンされる。
【００６５】
図６に戻り、ステップ１３４において、本問題に参加するプレーヤ（問題を受信したいプレーヤ全員）が特定される。好適な実施形態では、プレーヤが参加すると判断するより前に、問題に関する情報、あるいは少なくとも問題自身を入手することはできない。別の実施形態では、問題が属する分野などといった問題に関する限定的な情報が、警告信号とともにプレーヤに提供される。したがって、このような別の実施形態では、単に好都合などという理由のみならず、問題の分野が得意であるか否かなどといった要素に基づいて、プレーヤが参加するか否かを判断することができる。
【００６６】
さらなる実施形態として、参加するか否かのオプションをプレーヤに提示しない、あるいはプレーヤが正しく解答しなくてもペナルティがなく参加を妨げる要因がないといった形態もあり得る。このような実施形態では、すべてのプレーヤが参加するという前提に基づき、ステップ１３４を省略することができる。この実施形態の変形として、ステップ１３２を省略し、問題の配信時刻に関する警告信号を予めユーザに発出しない形態もあり得る。
【００６７】
いずれの場合においても、現在の問題の参加者グループには、現在の期間における最大割当問題（例えば、一日一問題など）を解答してしまったプレーヤが含まれないことが好ましい。好適な例では、２〜８問題を毎日出題し、１〜５問題以下（必ず出された全部の問題数以下である）を各プレーヤが解答する。なお、毎日３〜４問題を出題し、１問題以下を各プレーヤが解答することがより好ましい。
【００６８】
参加していないプレーヤはステップ１３２を省略し、不必要な警告信号を発しない形態もあり得る。また、別の実施形態では、すでに最大割当問題を解答してしまったプレーヤや選択していないプレーヤに対しても、参加しているプレーヤと同時に問題を出題する。しかし、これは単に楽しみ目的のみのためであって、解答が許可されていたとしてもコンテストの結果には反映されないことが好ましい。なお、参加プレーヤにより問題に対する解答がなされるまで、非参加プレーヤには問題が提示されないことが好ましい。
【００６９】
ステップ１３７において、参加プレーヤ全員に実質的に同時に問題が提示される。本実施形態では、通常の問題（特別な問題に対しては後述する）に対して参加プレーヤは３０秒以内に解答することが要求される。３０秒以内に解答がなされない場合には、問題は不正解となる。したがって、不公平な利益が生じないようにするために、通常の環境においてはすべての、あるいは略全ての参加プレーヤに問題が３秒の時間窓内に提示されることが好ましい。もちろん、プレーヤ端末の故障や少なくとも他の物理的な制約により、３秒時間窓内にプレーヤ端末に、１００％で問題が提示されないこともあり得る。
【００７０】
問題としては、知識を問う問題、技術を問う問題など、多様な種類の問題があり得る。しかしながら、一般に多く出される問題は質問、特に多項選択式の質問となることが予想される。
【００７１】
このような問題を提供するユーザインタフェース１９０の例を図８に示す。図示されているように、ユーザインタフェース１９０には、多項選択式の質問１９１、解答の選択肢１９３、解答可能な残り時間を示すカウントダウンタイマ１９５が含まれる。アプリケーション８０内のタイマを用いることで、多様なプレーヤ装置への問題配信の絶対時間に少々のずれ（１秒あるいは２秒など）があったとしても、参加者には問題が最初に配信（あるいは表示）されてから十分な解答時間（３０秒など）が与えられる。
【００７２】
解答の選択肢１９３は、同一ユーザインタフェース１９０において所望の解答１９３を単に指定するだけで直接にかつ素早くプレーヤが解答できるように、入力インタフェース要素（ここではラジオボタン）として機能することが好ましい。解答が指定され、選択（入力）されると、現在のプレーヤについて問題が終了する。
【００７３】
多くの他の種類の問題を出題することもできる。例えば、多項選択式問題のみならず、携帯電話のキーパッドなどを介して文字入力や数字入力を必要とする質問とすることも可能である。
【００７４】
また、想定解答の形式に関わらず、質問には単なる文字質問以上の他のメディアを用いることもできる。例えば、(i)写真やビデオセグメント中の人物を特定させる、(ii)参加者に提示される歌セグメントに続く３音符や小節を特定させる、(iii)写真中の特定のアイテムの数を求めさせる、(iv) 映画クリップとサウンドトラックの３つの組み合わせのうち適切なものを特定させるなどといった質問を参加者に出すこともできる。さらに、参加者がスクリーン上で操作するようなパズルやビデオゲームなどのような性質の問題を出すこともできる。
【００７５】
また、プレーヤ装置２１−２６の四隅の外にある外部イベントやメディアを問題に含めることも可能である。このような問題は、解答時間を余分に割り当てるような特別ｎ問題であることが好ましい。一つの例として、プレーヤにインターネット上で解答やアイテムを探させる問題がある。より練られた問題として、解答が見つかるまで、あるいは時間切れとなるまで、プレーヤが一つのウェブサイトから別のウェブサイトに渡り歩き次の手がかりを見つけるといったscavenger hunt などのようなものもあり得る。
【００７６】
いずれの場合でも、ステップ１３９において、解答をまずは個々のプレーヤ装置自身で受信し、次いでコンテストサーバ（サーバ１２など）にすぐにあるいは後で解答を送信するといった解答の受信処理がなされる。以下で説明するように、解答に要した時間がサーバに送信されることもある。また、解答が所定の時間内になされたか否かのみをプレーヤ装置が送信することもある。好適な実施形態では、解答情報を蓄積あるいはコンテストサーバに送信する前に、プレーヤ装置は解答情報を暗号化する。
【００７７】
ステップ１４１において、プレーヤの応答が採点される。このステップはプレーヤ装置２１−２６自身で行われることもあるし、送信後サーバ１２で行われ、採点結果は後ほど入手する（プレーヤ装置２１−２６を介するなどして）こともある。好適な実施形態では、所定の時間内（問題が配信されてから３０秒以内など）に正しい応答が提出された場合には所定のポイントが与えられ、誤応答の場合には所定のポイント（正しい応答時のポイント数分など）が引かれる。これに対して、別の実施形態では、異なる採点方法が用いられる。例えば、誤応答の場合でも減点しないこともある。また、正しい応答の場合に与えられるポイント数を参加者が応答に要した時間の関数とすることもある（サーバで採点を行う場合には、応答に加えて、参加者の応答時間もサーバに送信されることになる）。さらに、scavenger huntにおいて同一時間内に８０％達成した場合と９０％達成した場合とで異なるポイント数を付与するなど、問題に対する種々の達成レベルに応じて異なるポイント数を付与することもある。
【００７８】
次に、ステップ１４３において、現在の問題がコンテストの最終問題であるか否かの判断がなされる。最終問題でなければステップ１３１に戻り、次の問題を待つ。最終問題であればステップ１４４に進む。
【００７９】
ステップ１４４において、コンテストは終了し、貯めたポイント数に基づいて勝者（もしいれば）が特定される。ここで、本発明に基づくコンテストは、勝者（一位、二位、三位や種々のサブ分野ごとのランキングなど）がいるようなトーナメントでも良いし、製品やサービスに還元できるポイントを貯めるためだけのものであっても良い。
【００８０】
本発明のコンテストでは、異なる問題が異なるポイント数に対応していても良い。例えば、より長い、より難しい、より複雑な問題には、より短いあるいはより簡単な問題よりも多くのポイントを与えることが好ましい。好適な実施形態では、多数の通常問題（最大３０秒の解答時間で標準ポイント数の問題など）の中にいくつかのより多くのポイント数のより複雑な問題が含まれる。ある実施形態では、複数の問題（ポイント数がそれぞれ異なる標準、難解、超難関といった問題など）が特定の配信時刻に提示され、個々のプレーヤが受信したい問題を選択する。このような場合、すべての問題を配信時刻に先立ってダウンロードし、各プレーヤには選択された問題のみ提供するような形態が好ましい。
【００８１】
上述のコンテストの種々の特徴により、現在のゲームやコンテストには存在しないような刺激や目新しさを提供することが可能になる。第一に、上述の通り、このコンテストは多くのタイムゾーンにまたがるコンテストを実施するにあたって生じる現実的な問題に起因するような地理的な制約を受けない。第二に、コンテストはすべての参加者に実質的に同時に実施することができる。そのため、大きな群衆の中に警告信号を受信してコンテストに参加する人がいるような状況では、従来のゲームやコンテストのようにパーソナル装置上でコンテストに参加するのに比べ、このコンテストをより社会的なイベントとすることができる。また、問題が配信される時間が予め既知でないため、刺激、自発性、社会的つながり感を一層高めることができる。
【００８２】
上述の説明はコンテストの実際の実施に関するものである。実際にプレーしている時間の合間には、種々の他の動作が発生し得る。例えば、獲得ポイント数の確認、ランキングや順位などの確認、詳細な統計やリーダ写真の閲覧、過去の問題の解答や解法などの閲覧、成績統計の検討、個々のプレーヤが特定の基準に関してどのような成績を残しているかといった個別レポートの生成、他のコンテスト結果の閲覧、他のコンテストへの登録、獲得ポイントの使用などといった動作を個々のプレーヤができることが好ましい。以上の項目は、以下の段落で説明する「パワーアップ(powering)」が行われるときに特に重要となり得る。
【００８３】
ここで、上述した通常のコンテスト構造に対して、数多くのバリエーションが可能である。一つの興味あるバリエーションは、個々のプレーヤに少なくとも他の一人のプレーヤと「パワーアップ」する能力を持たせることである。ここで、各プレーヤは同時に他の一人のプレーヤを選択しパワーアップする能力を持つことが好ましい。この場合、「パワーアップするプレーヤ」（選択を行ったプレーヤ）は、パワーアップされたプレーヤ（リーダ）が獲得したポイントに基づいてポイントを獲得できる。逆に、パワーアップされたプレーヤはパワーアップしたプレーヤが獲得したポイントに基づいてポイントを獲得できる。すなわち、優れたプレーヤとパワーアップすることで、個々のプレーヤは自身のポイントを増大させることができる。逆に、多くの他のプレーヤからパワーアップされれば、プレーヤ自身の全ポイント数を増大させることができる。すなわち、リーダの全ポイント数は、問題に対する応答の正答率のみならず、他のプレーヤをどれだけ多く自身にパワーアップさせるかによって決まる。ここで、誤応答のときに減点するような実施形態においても、パワーアップするプレーヤがリーダのポイント数の低減につながることは好ましくなく、パワーアップ関係にある間はリーダのポイント数が増加することが好ましい。一方、好適な実施形態では、いかなるプレーヤのポイント数がゼロ以下となることはないものの、リーダのポイント数の増減は、リーダにパワーアップしたプレーヤのポイント数に反映される。
【００８４】
好適な実施形態では、パワーアップしたプレーヤは、優れたプレーヤとパワーアップすることで他の利点を得ることができる。例えば、トーナメントコンテストにおいて、パワーアップしたプレーヤ自身ではトーナメントを続けられないとしても、リーダがトーナメントに残っている限りは、プレーを続行できることが好ましい。
【００８５】
本段落では、本発明の好適な実施形態におけるパワーアップの詳細を説明する。本実施形態では、「ドッツ(Dotz)」「パワーアップポイント」「ゲームポイント」の３種類のポイントを用いる。月初めにコンテストへの月額参加費を支払うと、5、000ドッツがプレーヤのアカウントに積み立てられ、前月の負のポイント数は（許可されれば）クリアされる。すなわち、各プレーヤは少なくとも5、000ドッツ保持する。自身の成績によってドッツを獲得するのみならず、各プレーヤは一時に一人の他のプレーヤとパワーアップし、自身のドッツを所望の期間その他のプレーヤと結合する。パワーアップしているか否かに関わらず、個々のプレーヤの正答率ならびに個々の問題に割り当てられたドッツ数に基づいて、プレーヤのポイント数は増減する。また、プレーヤがパワーアップすると、リーダの解答に基づいて同じドッツ数が増減する。プレーヤはいつでもリーダとのパワーアップを解消してドッツを引き上げたり、他のリーダに移ったりすることができる。ただし、一度パワーアップを解消したリーダにはコンテスト期間内に再度パワーアップすることはできない。これに対し、リーダは、自身とパワーアップしているすべてのプレーヤが獲得したすべてのドッツ数に等しいパワーアップポイント数を獲得することができる。ただし、パワーアップしているプレーヤが誤応答した場合であってもパワーアップポイントを失うことはない。あるいは、パワーアップ関係のあるパワーアップされたプレーヤに起因して全ポイント数の減少は少なくとも生じない。また、また更なる実施形態では、パワーアップされたプレーヤに起因するパワーアップポイントは、そのパワーアップされたプレーヤの誤解答によって後で失われる。プレーヤはリーダとパワーアップすることで自身のドッツを増加させることができるが、自身が他のプレーヤからパワーアップされたことで得られるパワーアップポイントは増やすことができない。各プレーヤのゲーム点数は、プレーヤのドッツとパワーアップポイントを足したものとなる。コンテストが終了すると、コンテストでの総合ランキングとプレーヤが獲得したゲームポイント数に基づいてスライドスケールでさらなるドッツを各プレーヤに付与する。図９はスライドスケールの一例であり、最終ゲームスコア２０２、プレーヤ数２０４、ゲームスコアに基づいて付与されるドッツ２０５が示されている。この例では、ドッツは順位に基づいて付与される。最大のゲームポイントを獲得したプレーヤには1、000、000ドッツを、次の高ポイントを獲得した５プレーヤには500、000ドッツを、続く高ポイントを獲得した１０プレーヤには100、000ドッツなどといったようにポイントが付与される。なお、ゲームスコアカットオフ２０２はコンテスト終了時に決定される。別の実施形態では、ゲームスコアカットオフ２０２は固定であり、それぞれの範囲に入るプレーヤ数はコンテストごとに可変となる。なお、総合順位と全ゲームポイント数の組み合わせを用いる他の変換手法を用いることも可能である。
【００８６】
上述のパワーアップ機能により、個々のプレーヤは他のプレーヤの成績を見守ったり、他のプレーヤを応援したりする動機が生まれ、孤独なあるいは匿名の行為を、グループあるいはチームの行為に変えることが可能となる。本発明の好適な実施形態では、プレーヤは自在に異なるリーダに変更することができる。これにより、他のプレーヤの成績を見守る動機が生まれる。ただし、パワーアップするプレーヤには注意深くリーダの変更を行わなければならないような制約が課せられる。コンテストにおいて、プレーヤは同じリーダに二回パワーアップすることが認められないことが好ましい。すなわち、一旦リーダとのパワーアップを解消すると、同一コンテスト内ではそのリーダと再びパワーアップできない。
【００８７】
パワーアップの概念には種々のバリエーションがあり得る。例えば、パワーアップするプレーヤは、リーダが獲得したポイントのうち特定のパーセンテージ（あるいは他の関数）のみを獲得できるといった形態もあり得る。また、逆の形態もあり得る。さらに、パワーアップするに際してコストがかかる形態もあり得る。例えば、自身が獲得するポイントの５０％分をコストとして差し引く、すなわちパワーアップするプレーヤよりもリーダの成績の方が優れている場合にのみパワーアップが得になるような形態もあり得る。さらに、パワーアップするプレーヤの成績がリーダのスコアに影響を与えるような実施形態では、そのパワーアップするプレーヤをリーダが制御できることが好ましい。
【００８８】
種々のバリエーションがあり得るが、パワーアップの概念は、個々のプレーヤに一人以上の他のプレーヤと所望の期間提携する機能を保持させ、提携を自在に変更できるようにすることで、提携したプレーヤの好成績から利益を得ることにある（ある実施形態では、提携したプレーヤの損失により損害を受けることもあり得る）。パワーアップの別の好適な特徴は、個々のプレーヤが他のプレーヤにパワーアップされる動機が生まれることである。
【００８９】
また、パワーアップに替えて（あるいは、加えて）、本発明に基づくコンテストは自在にチームを構成することができる。一つの実施形態では、個々のメンバーがチームに所属している期間のチーム全体の成績がメンバーのポイント獲得数に影響する。パワーアップとある点では似ているものの、チームのアプローチでは個々のプレーヤ間での直接の一対一の関係は存在しない。そのため、個々のメンバーからなる小さなアドホッククラスタが構成されやすくなる。
【００９０】
パワーアップとチームのいずれにしても、ある実施形態では、生成されたグループの組織と個々のプレーヤがグループ内でのポイントの獲得方法に関するルールがコンテストで定められる。例えば、リーダが最も多いパーセンテージを獲得し、次のレベルのプレーヤ（おそらく一定の人数に限られる）は二番目のパーセンテージを獲得するなど、グループ内に多レベルポイント獲得構造を導入するルームも考えられる。このような構造を用いることで、どのレベルに誰を割り当てるかに関する交渉が密に行われるとともに、他のグループ（あるいはリーダ）に属したときによりポイントを獲得できるといった場合には他のグループ（あるいはリーダ）に個々のプレーヤが移ってしまうというリスクも生じる。
【００９１】
さらなる別の実施形態では、グループ単位にポイントを構造化することで、知識分野や専門分野を適切に網羅するように、またグループ内に多様なレベルが存在するように、グループを構成する動機が生まれる。
【００９２】
本発明によるコンテストは、プレーヤの幅広い知識や技能を試すものや、スポーツやエンターテインメントなど特定の興味、知識、技能分野に関するもの、特定の年代（子供、トゥイーン、ティーンなど）を対象にするものなどがあり得る。
【００９３】
上述の通り、勝者を決定し、最後にはボーナスポイントや賞を授与するような試合（通常はトーナメントと呼ばれる）としてコンテストを実現することもできるし、製品やサービスに交換できるポイントを獲得する期限付きの機会としてコンテストを実現することもできる。また、この両者を組み合わせることもできる。一つの例として、コンテストの最後に、高ポイントを獲得した個々のプレーヤをそのプレーヤにパワーアップしたプレーヤとともに、予選トーナメントへの参加を招待し、リーダがトーナメントに残っている限りはパワーアップしたプレーヤもトーナメントに参加し続けられる形態もあり得る。
【００９４】
予選トーナメントや同種の試合を行うにあたっては、どの段階でもプレーヤが獲得したポイントのみを考慮する（パワーアップポイントは除外する）、プレーヤのすべてのポイントを考慮する（パワーアップポイントを含む）、両者の組み合わせ（重みづけするなど）を考慮するなどといった多様なルールを考えることができる。
【００９５】
＜実質的に同時な配信の他のシステム及び方法＞
メッセージを同時配信する上述の技術は、同時プレーを行うコンテスト以外の目的にも利用することができる。一つの利用形態として、同時通信が望まれているあるいは必要であるような状況を挙げることができる。従来、この目的に向けて放送メディアが用いられてきたが、受信者がメディアにアクセスしなければならないとともに、アナウンスがなされる時点でチャネル合わせを行わなければならないという点で放送メディアには本質的に制約がある。また、テレビやケーブル放送などのように遅延の変動が小さな放送メディアは、情報を小規模に配信するには一般に適していない。上述の通り、本発明の好適な実施形態では、メッセージが配信される時点でのネットワーク接続が不必要であり、多種多様な装置に対してメッセージを配信することができる。したがって、受信者は重要なメッセージを他の受信者と同じ時刻に入手できるとより強く認識することができる。このような実質的に同時な通信が重要となる状況として、経済ニュースや金融ニュースのアナウンスを挙げることができる。
【００９６】
別の利用形態として、共同行為が望まれている状況がある。上述の通り、本発明の一つの特徴によれば、すべての参加者のユーザ装置を実質的に同時にウェイクアップあるいは起動させることができ、すべての参加者に速やかに操作をさせることができる。例えば、オンラインオークションにおいて注目している商品のオークション時間が残り５分となったときにアラートを出すシステムに適用することができる。ここでは、最初のアナウンス時点ではネットワーク接続は必要ないものの、入札を実際に行う際にはネットワーク接続が必要となる。
【００９７】
ネットワーク接続がなくても共同ショッピング行為を実現できる例として、製品やサービスを最初の購入者に販売する形態を挙げることができる。上述の好適なメッセージ配信技術を用いれば、最初のアナウンスはユーザ装置に配信時刻とともに前もって蓄積される。次いで、メッセージが配信された後、装置は応答と応答時間とを蓄積し、ネットワーク接続がなされた後の時点でサーバにこれらの情報を送信する。これにより、サーバは応答時間を順位づけするだけで購入者を決定することができる。本実施形態によれば、コンサートチケットなどの商品をきわめて短い時間内に販売する従来システムでの遅延問題を、ほぼ解決することができる。
【００９８】
本技術のさらなる応用として、遠隔で再プログラミングされるスプリンクラーシステム、銀行や他の施設のカギの同時開閉、効率的なトラヒック流実現のための交通信号のリアルタイム同期制御、電子掲示板の内容の更新、州やある地理的エリアでの学校試験の制御、スーパマーケット価格の多くの店舗での同時更新、オフピーク時の消費をユーザに金銭的に動機づけする電気メータや種々の機器への所定の価格変化の同時リアルタイムダウンロード、ゲームプレーの種々の局面の制御や時間調節、時間調整やスケジュール更新などといった投薬制御、参加者には瞬時に応答する動機づけをするなどして瞬時の反応を集めたり、時系列での応答を集めて応答の時間変化を把握したりするためのリアルタイム投票（ニールセンのテレビ投票など）、店舗内プロモーション（来店した登録者に対して商品価格を所定額割り引くプロモーションなど）などを挙げることができる。
【００９９】
本技術の別の利用形態として、放送番組と同時に用いるものがある。一つの実施形態では、テレビやラジオショーなどの放送番組に関連するコンテンツをユーザ装置２１−２６にダウンロードし、番組に同期して対応ユーザ３１−３５に配信される。ここで、メッセージの配信は、ユーザ３１−３５の自身の装置２１−２６上での選択に基づいて行われることが好ましい。これにより、特別なハードウェアや放送番組を視聴する以外のネットワーク接続性を必要とせずに、インタラクティブ体験を可能にすることができる。また、他の実施形態では、ユーザ装置２５において上述したように、番組録画機や再生機のクロックをユーザ装置と同期させることで、放送番組を録画する。なお、この実施形態では、共通メッセージの実質的に同時の、大量配信技術ではなく、メッセージ配信の個人化技術が用いられる。
【０１００】
本技術のさらなる利用形態として、放送メディアを介した視聴者参加型リアルタイムコンテストの実現がある。一つの例では、放送事業者はウェイクアップ信号を複数のユーザ装置２１−２６に送信する（放送する）。ユーザ装置２１−２６は実質的に同時にウェイクアップし、対応するユーザにプレーを開始させる。この際、同時にサーバ１２への通信チャネルを確立することが好ましい。また、ウェイクアップ信号と解答する問題とのいずれかあるいは両方は、リアルタイムに送信される、あるいは上述の通り前もって送信されて対応装置２１−２６に蓄積されることに注意されたい。いずれにしても、ウェイクアップ信号はすべての対象プレーヤに、あるいはランダムに選択された一部のプレーヤなどに配信される。好適な実施形態では、参加プレーヤのみならずすべての視聴メンバーにテレビ放送を介して同時に問題が配信される。なお、コンテストの成績には、参加プレーヤからの応答のみを考慮することが好ましい。また、ウェイクアップ信号を受信すると、ユーザ装置２１−２６はユーザ解答時間をローカルに計測し、応答結果と応答時間とをサーバ１２に返信することで、種々のユーザ装置２１−２６間での通信遅延ずれに対応する。
【０１０１】
＜システム環境＞
特に説明した場合を除き、上述のシステム、手法、技術のすべては、概して１つ以上のプログラム制御の汎用コンピュータ装置で実現される。このような装置には、例えば、お互いが共通バスを介して相互接続されている少なくとも以下の要素が含まれる。１つ以上の中央演算処理装置（CPU）、読出し専用メモリ（ROM）、ランダムアクセスメモリ（RAM）、入力／出力ソフトウェアと他の装置とのインタフェース回路（シリアルポート、パラレルポート、USB接続、firewire接続などの有線接続や、Bluetooth、802.11プロトコルなどの無線プロトコル）、１つ以上のネットワークに接続するためのソフトウェアや回路（イーサネット（登録商標）カードなどの有線接続、符号分割多重（CDMA）、汎欧州デジタルセルラーシステム（GSM）、Bluetooth、802.11プロトコル、他のセルラーシステムあるいは非セルラーシステムなどの無線接続。本発明の実施形態の多くでは、ネットワークはインターネットや他のネットワークに接続される）、ディスプレイ（ブラウン管、液晶ディスプレイ、有機ELディスプレイ、他の薄幕ディスプレイなど）、他の出力装置（１つ又はそれ以上のスピーカ、ヘッドフォンセット、プリンタなど）、１つ又はそれ以上の入力装置（マウス、タッチパッド、タブレット、タッチスクリーンディスプレイや他のポインティング装置、キーボード、キーパッド、マイクロフォン、スキャナなど）、大容量記憶装置（ハードディスクドライブなど）、リアルタイムクロック、リムーバブルRead/Write記憶装置（RAM、磁気ディスク、光磁気ディスク、光ディスクなどからの読み出しと書き込み）、モデム（ファックス送信、インターネットやダイヤルアップ接続を介しての他のコンピュータネットワークへの接続などのため）。動作時、上述の手法と機能を実現する汎用コンピュータなどで実行される処理ステップは、一般にはじめはハードディスクなどの大容量記憶装置に保持されており、RAMにダウンロードされて、RAMからCPUで実行される。なお、ある例では、処理ステップははじめからRAMやROMに保持されることもある。
【０１０２】
本発明を実現する適切な装置は、種々のベンダから入手可能である。多様な実施形態において、サイズやタスクの複雑さに応じて種々の種類の装置が用いられる。適切な装置として、スタンドアロンで動作する、あるいはネットワークに有線接続もしくは無線接続して動作するメインフレームコンピュータ、マルチプロセッサコンピュータ、ワークステーション、パーソナルコンピュータ、PDAなどの小型コンピュータ、携帯電話や他の情報家電や装置などが挙げられる。
【０１０３】
また、以上では汎用プログラマブル装置の利用を示したが、他の実施形態では１つ以上の特殊用途プロセッサやコンピュータを替わりに（あるいは追加して）用いる。明示していない場合には、上述の機能はソフトウェア、ハードウェア、ファームウェア、あるいはこれらの組み合わせとして一般に実現されることに注意されたい。ここで、これらの実現方法は、既知のエンジニアリングトレードオフの観点から選択される。具体的には、上述の機能が一定の、予め決められた、論理的な形態で実現される場合には、専門家であれば容易に理解できるように、プログラミング（ソフトウェアやファームウェアなど）、適切な論理要素構成（ハードウェア）、あるいはこれらの組み合わせとして実現できる。
【０１０４】
本発明は、本発明の手法と機能を実行するプログラム命令が蓄積されるマシン可読メディアにも関する。このようなメディアとして、磁気ディスク、磁気テープ、CD ROMやDVD ROMなどの光学式読み取りメディア、PCMCIAカードなどの半導体メモリ、種々のメモリカード、USBメモリ装置などがある。ここで、メディアの形状として、小型ディスクドライブや小型ディスク、ディスケット、カセット、カートリッジ、カード、スティックなどの携帯型の形状や、ハードディスクドライブ、コンピュータや他の装置に含まれるROMやRAMなどの比較的大きな形状や動かすことのない形状があり得る。
【０１０５】
以上、主として電子コンピュータや装置を用いるものとして説明した。しかしながら、電子、光、生物、化学処理の組み合わせで実現される装置などのように、他の種類のコンピュータや装置を替わりに用いることもできる。
【０１０６】
＜追加説明＞
上述の説明では、ユーザインタフェースボタンのクリックやダブルクリック、ユーザインタフェースアイテムのドラッグ、特定のユーザインタフェース機構を介して特定の方法でのコマンドや情報の入力などにところどころ言及している。これらの言及すべては例示するためのものであって、本発明は、同様のあるいは他のユーザインタフェース機構を用いた他の方法によってユーザがそのコマンドや情報を入力することをも含む。また、自動化（コンピュータ実行された）プロセスによってコマンドや情報が入力されることもある。
【０１０７】
上述の説明では、本発明の種々の実施形態を、個々の実施形態が特定の特徴を有するものとして説明している。しかしながら、ひとつの実施形態の説明にあたって述べた特徴は、その実施形態のみに限定されるものではなく、専門家ではれば理解できるように、他の実施形態における種々の組み合わせにおいても得られるものである。
【０１０８】
同様に、上述の説明では、機能を特定のモジュールや要素に対応させて説明した。しかしながら、一般に、機能は種々のモジュールや要素間で分散されて実現されることもある。いくつかの場合においては、特定の要素やモジュールが不必要となることもあり、新たな要素やモジュールが必要となることもある。専門家であれば容易に理解できるように、本発明の特定の実施形態に対応するように機能を適切に分散させるのは、既知のエンジニアリングトレードオフに基づいてなされることが好ましい。
【０１０９】
すなわち、例示的な実施形態ならびに添付図面を用いて本発明を詳細に説明したが、本発明の精神や範囲から逸れることなく種々の適応や修正が可能であることは専門家には明らかである。したがって、本発明は図面や上述の説明で示された具体的な実施形態に限定されない。本発明の精神から逸れることのない全ての実施形態は、特許請求範囲で示される範囲に含まれるものである。
【図面の簡単な説明】
【０１１０】
【図１】本発明の代表的な実施形態におけるアラートシステムの概略図である。
【図２】本発明の代表的な実施形態におけるユーザ装置とサーバとの間の通信を示す。
【図３】本発明の代表的な実施形態におけるユーザ装置のいくつかの要素を示すブロック図である。
【図４】本発明の代表的な実施形態におけるアラート情報と時刻同期情報の例である。
【図５】本発明の代表的な実施形態においてアラートシステムを実現する処理の概略を示すフロー図である。
【図６】本発明の代表的な実施形態においてコンテストを実施する処理を示すフロー図である。
【図７】本発明の代表的な実施形態において、プレーヤが現在の問題に参加するか否かを尋ねる初期ユーザインタフェースを示す図である。
【図８】本発明の代表的な実施形態におけるコンテストにおいて、問題を提示し、その問題に対する応答を受け付けるユーザインタフェースを示す図である。
【図９】本発明の代表的な実施形態において、ゲームポイントを”ドッツ”に変換するスライディングスケールを示す図である。
【図１】
2009512019.tif 000003
【図２】
2009512019.tif 000004
【図３】
2009512019.tif 000005
【図４】
2009512019.tif 000006
【図５】
2009512019.tif 000007
【図６】
2009512019.tif 000008
【図７】
2009512019.tif 000009
【図８】
2009512019.tif 000010
【図９】
2009512019.tif 000011
【国際調査報告】
2009512019.tif 000012