JP2013020561A - 管理装置、携帯端末およびプログラム - Google Patents

Abstract

【課題】競技会を開催する労力・コストを低減した上で、競い合うという競技会の感覚を併せて得ることのできる技術を提供する。
【解決手段】
複数の携帯端末（２０）と通信する管理装置（１０）は、複数の携帯端末（２０）に共通の開始時刻での各携帯端末の位置を起点とした各携帯端末の移動距離を複数の携帯端末の各々について取得する距離取得部（１４）と、距離取得部（１４）が各携帯端末（２０）について取得した移動距離を対比するための距離通知情報を前記複数の携帯端末の各々に通知する情報通知部（１６）とを具備する。
【選択図】図１

Description

本発明は、場所を異にする参加者同士が共通の時間で実際にランニングなどをしたときに、参加者に順位等の情報を提供する技術に関する。

近年、健康志向の高まりにつれて、マラソンや自転車走行などの競技会が頻繁に開催されるようになってきた。ただし、この種の競技会を実際に開催するためには、参加者の募集や、道路の使用許可などのために官公庁への許可、警備員・記録員の手配など、多大な労力・コストを必要とする。そこで、競技会を開催する労力・コストを低減するために、各競技者が異なる日時で競技したタイム等を集計し、これによって順位等を決定する技術が提案されている（例えば特許文献１参照）。

特開２００８−２９９５３５号公報

しかしながら、この技術では、競技会を開催する労力・コストを低減することができるものの、参加者は、他の参加者の競技状況や自己の順位などの情報をリアルタイムで知ることができず、このため、競い合うという競技会本来の感覚を得難い、という問題があった。
本発明は、上述した事情に鑑みてなされたものであり、その目的の一つは、競技会を開催する労力・コストを低減した上で、競い合うという競技会の感覚を併せて得ることのできる技術を提供することにある。

上記課題を解決するために本発明が採用する手段を説明する。なお、本発明の理解を容易にするために、以下では図面の参照符号を便宜的に括弧書で付記するが、本発明を図示の形態に限定する趣旨ではない。

本発明に係る管理装置は、複数の携帯端末（２０）と通信する管理装置（１０）であって、前記複数の携帯端末（２０）に共通の開始時刻での前記各携帯端末の位置を起点とした前記各携帯端末（２０）の移動距離を前記複数の携帯端末の各々について取得する距離取得部（１４）と、前記距離取得部（１４）が前記各携帯端末（２０）について取得した移動距離を対比するための距離通知情報を前記複数の携帯端末の各々に通知する情報通知部（１６）とを具備することを特徴とする。

本発明では、携帯端末を携行する参加者がランニングなどの競技によって移動したときに、その移動距離が距離取得部によって取得される。したがって、複数の参加者が同じように競技によって移動すると、各携帯端末の移動距離が取得されて、当該移動距離を対比するための移動通知情報が作成される一方で、各携帯端末には、この移動通知情報が通知される。したがって、本発明によれば、各参加者が互いに場所を異にして競技することができる。このため、実際の競技会を開催する必要がないばかりか、参加者は、他参加者の移動距離を対比した情報をほぼリアルタイムで知ることができるので、他の参加者と競い合うという感覚を得ることも可能になる。

本発明において、前記各携帯端末（２０）の移動距離に応じた順位を決定する順位決定部（１５）を含み、前記情報通知部（１６）は、前記順位決定部（１５）が決定した順位を含む前記距離通知情報を生成して前記各携帯端末（２０）に通知する構成としても良い。この構成によれば、他の参加者と比較した順位を、ほぼリアルタイムで得ることができる。
また、本発明において、前記距離取得部（１４）は、前記各携帯端末の位置情報を取得する位置取得部（１４ａ）と、前記位置取得部（１４ａ）が前記各携帯端末（２０）について取得した複数の位置情報から当該携帯端末（２０）の前記移動距離を算定する距離算定部（１４ｂ）とを備える構成としても良い。この構成によれば、携帯端末から取得される位置情報から、当該携帯端末の移動距離が算定される。

本発明において、前記携帯端末（２０）からの参加登録を受け付ける参加受付部（１３）を具備し、前記距離取得部（１４）は、前記参加受付部（１３）が前記参加登録を受け付けた携帯端末（２０）について前記移動距離を取得する構成としても良い。この構成によれば、参加登録が受け付けられた携帯端末についての移動距離が取得される。
また、本発明において、前記距離取得部（１４）は、所定の基準周期で前記各携帯端末の移動距離を取得し、移動距離が相互に接近する各携帯端末については前記基準周期よりも短い周期で前記移動距離を取得する構成としても良い。この構成によれば、相互に接近する携帯端末の移動距離を取得頻度が高まるので、距離通知情報の精度を高めることができる。

本発明において、前記複数の携帯端末（２０）を複数のグループに区分する参加者分割部（ステップＳ１０４）を具備し、前記情報通知部（１６）は、前記参加者分割部が区分した前記複数のグループの各々について、当該グループに属する前記各携帯端末に関する前記距離通知情報を、当該グループに属する各携帯端末に通知する構成としても良い。この構成において、前記参加者分割部は、前記各携帯端末の利用者間の関係を規定するソーシャルグラフ情報に応じて前記複数の携帯端末を複数のグループに区分する態様が好ましい。
本発明は、上記管理装置と通信する携帯端末としても概念することができる。すなわち、上記管理装置（１９）と通信する携帯端末（２０）であって、前記管理装置の情報通知部から通知された距離通知情報に応じて前記複数の携帯端末のなかでの自端末の移動距離の順位を特定して音声で利用者に報知する構成としても良い。
また、本発明は、コンピュータに上記管理装置として機能させるためのプログラムとして概念することはできる、

本発明の実施形態に係る管理装置を含むシステムを示すブロック図である。 管理装置の構成を示すブロック図である。 携帯端末の構成を示すブロック図である。 仮想競技会を示す図である。 仮想競技会のエントリーまでのシーケンスを示す図である。 エントリー画面の一例である。 参加登録したときの参加者テーブルの内容例を示す図である。 仮想競技会のスタートまでのシーケンスを示す図である。 予告画面の一例である。 スタート直後における参加者テーブルの更新例を示す図である。 仮想競技会におけるシーケンスを示す図である。 参加者テーブルにおける走行距離の更新を示す図である。 参加者テーブルにおける順位の更新を示す図である。 仮想競技会における経過画面の一例である。 参加者テーブルにおいて完走者が現れたときの内容例を示す図である。 仮想競技会における結果画面の一例である。 参加者をグループ分けする場合のシーケンスを示す図である。 ソーシャルグラフを示す一例である。

＜実施形態の構成＞
以下、図面を参照して本発明の実施形態について説明する。図１は、本発明の実施形態に係る管理装置１０を含むシステム１の構成を示すブロック図である。
この図に示されるように、システム１は、実施形態に係る管理装置１０と、複数の携帯端末２０とを含む。このうち、複数の携帯端末２０の各々は、仮想競技会に参加するためのアプリケーションソフトウェアがそれぞれインストールされたハンドヘルドコンピュータや、ＰＤＡ（Personal Digital Assistant）、携帯電話機などであり、基地局ＢＳおよび移動通信網Ｎなどの携帯電話網を介して管理装置１０にそれぞれ接続される。

ここで、仮想競技会とは、互いに離れた場所にいる参加者同士、例えば全国各地に点在する参加者同士が共通の開始時刻でランニングなど移動を伴う競技をスタートするとともに、予め定められた設定距離を完走するまで順位を競い合う、という仮想的な競技会である。同じ場所で開催される実際の競技会とは異なり、各参加者は、場合によってはそれぞれ一人一人単独で走行することになるので、競技会そのものは「仮想的」に見える。このため、仮想競技会では、他の参加者がまったく見えないのが通常である。したがって、実際にランニングなどによって移動しても、そのままでは自己の順位や他の参加者の動向が把握できず、競技会という雰囲気に欠けてしまう。この点を考慮したのが本実施形態である。

管理装置１０は、機能ブロック図でいえば、送受信部１２、参加受付部１３、距離取得部１４、順位決定部１５および情報通知部１６を有する。これらの各部について概略すると、送受信部１２は、携帯端末２０から位置情報を受信したり、携帯端末２０に距離通知情報などを送信したりする。参加受付部１３は、仮想競技会に参加する者の携帯端末２０を登録する。距離取得部１４は、位置取得部１４ａと距離算定部１４ｂとを有する。このうち、位置取得部１４ａは、仮想競技会がスタートした後に携帯端末２０から位置情報を、送受信部１２を介して所定の周期（例えば２０秒）毎に取得する。距離算定部１４ｂは、位置情報が取得されたとき、その前に取得された位置情報で示される位置から、今回取得された位置情報で示される位置までの２点距離を算出するとともに、仮想競技会のスタートからの累積移動距離に加算する。なお、位置取得部１４ａによる距離情報の取得および距離算定部１４ｂによる２点距離の算出・累算は、参加受付部１３に登録された携帯端末２０の各々について実施される。
順位決定部１５は、登録された携帯端末２０のうち、累算移動距離の大きいものから順位を決定する。情報通知部１６は、本実施形態にあっては、登録された携帯端末２０の各々に対して、順位および累算移動距離を含む距離通知情報などを、送受信部１２を介して送信する。

図２は、管理装置１０のハードウェア的な構成を示すブロック図である。この図に示されるように、管理装置１０は、装置全体を制御するＣＰＵ（Central Processing Unit）１２１と、ＣＰＵ１２１の作業領域として機能するＲＡＭ（Random Access Memory）１２２と、ブートプログラムなどを記憶したＲＯＭ（Read Only Memory）１２３と、時刻情報を出力するＲＴＣ（Real Time Clock）１２４と、各種のプログラムやデータを記憶するハードディスク１２５と、キーボードやマウスなどを含む入力部１２７と、ネットワークを介して各携帯端末２０と通信するための通信インターフェース１３０と、を含む。

ハードディスク１２５には、仮想競技会を開催するためのプログラムや、当該仮想競技会を開催する際のデータベース１３５などが格納される。そして上記プログラムをＣＰＵ１２１が実行することによって、上述した参加受付部１３、距離取得部１４、順位決定部１５および情報通知部１６の機能ブロックが構築される。
なお、管理装置１０については複数のサーバで構成しても良い。例えば、携帯端末２０からの距離情報を受信して２点距離を算出するサーバと、算出された２点距離に応じてデータベースを更新するサーバとに分けても良い。

図３は、携帯端末２０のハードウェア的な構成を示すブロック図である。この図に示されるように、携帯端末２０は、ＣＰＵ２２１と、メモリ２２２と、ＲＴＣ２２４と、ＧＰＳ受信部２２６と、入力部２２７と、表示部２２８と、音声出力部２２９と、通信インターフェース２３０と、を含む。このうち、メモリ２２２は、フラッシュメモリなどの不揮発性半導体素子であり、基本プラグラムや各種のアプリケーションプログラムなどを記憶するほか、これらのプログラムの実行時における作業領域として用いられる。また、アプリケーションプログラムには、仮想競技会に参加するためのプログラムが含まれる。表示部２２８は、例えば液晶表示装置や有機ＥＬ（Electro Luminescence）表示装置などである。入力部２２７には、操作ボタンのほか、表示部２２８の表示面に操作面が重ねられるタッチパネルも含まれる。また、音声出力部２２９は、音声ファイルを音声信号に変換し、例えばイヤホン２２やスピーカーを介して参加者に出力する。

図４は、仮想競技会の参加者（競技者）とシステム１の各部との関係を示す図である。ここでは、参加者Ｒａを基準に考える。図に示されるように参加者Ｒａは、イヤホン２２に耳に装着するとともに、携帯端末２０を腰ベルトによって携行した状態でランニングする。参加者Ｒｂも同様に、イヤホン２２を装着するとともに携帯端末２０を携行した状態でランニングする。
本実施形態における仮想競技会では、参加者Ｒａは例えばＡ県でランニングするが、参加者ＲｂはＡ県とは全く異なるＢ県でランニングする場合もある。このため、参加者Ｒａは、参加者Ｒｂを目視することはできない状況にあるのが通常である。ただし、参加者Ｒａからみれば、他の参加者が共通の開始時刻でランニングを開始していることや、その中で自己が何位に相当しているのかなどは知るので、他の参加者の存在を意識することはできる。すなわち、参加者Ｒａからみれば、参加者Ｒｂを見えない存在として意識することはできる。その意味で、参加者Ｒｂについては図４において塗りつぶしている。
また、図４においては、参加者Ｒａ、Ｒｂだけを示しているが、後述するように参加者は多数の場合がある。

本実施形態において携帯端末２０は、ＧＰＳ（Global Positioning System）によって現在地を測位するとともに、測位した位置情報を、無線基地局ＢＳ（および移動通信網Ｎ）を介して管理装置１０に送信する。なお、携帯端末２０は、測位のために少なくとも３個のＧＰＳ衛星４０から発信される衛星信号を（ＧＰＳ受信部２２６によって）受信する。
また、位置情報については、ＧＰＳに限られず、複数の無線基地局ＢＳによる電波強度や電波到達時間などを比較して取得しても良いし、これらを組み合わせて取得しても良い。管理装置１０と携帯端末２０とについては、携帯電話網を介した通信だけではなく、無線ブロードバンドなどの無線ＬＡＮを介して通信しても良い。

＜実施形態の動作＞
次に、システム１における動作について、仮想競技会へのエントリーまで、仮想競技会のスタートまで、仮想競技会の終了まで、３段階に分けて説明する。

図５は、利用者が仮想競技会にエントリーするまでの動作シーケンスを示す図である。
まず、利用者の携帯端末２０には、仮想競技会に参加するためのアプリケーションソフトウェアがインストールされている状態が前提である。一方で、仮想競技会を開催するために管理装置１０では、仮想競技会を開催するためのプログラムが実行されているとともに、開催予定の仮想競技会の内容（開催日時や、設定距離など）がデータベース１３５にスケジューリングされている状態が前提である。

さて、利用者が入力部２２７を操作するなどして上記アプリケーションの起動を指示すると、携帯端末２０では、実際に当該アプリケーションが起動する（ステップＳ２０１）。当該アプリケーションが起動した携帯端末２０においてＣＰＵ２２１は、管理装置１０に対して仮想競技会の開催予定情報を要求（Ｒeq1）する。当該要求（Ｒeq1）を受信した管理装置１０においてＣＰＵ１２１は、データベース１３５から、例えば開催予定日時が現在時刻に近い仮想競技会をサーチして、当該仮想競技会の情報（Ｒeq2）を、要求した携帯端末２０に返信する（ステップＳ１０１）。
一方、情報（Ｒes1）を受信した携帯端末２０ではＣＰＵ１２１が、その情報（Ｒes1）に対応したエントリー画面を表示部２２８に表示させる（ステップＳ２０２）。

図６は、携帯端末２０の表示部２２８に表示されるエントリー画面の一例を示す図である。この図に示されるように、エントリー画面には、開催予定の仮想競技会についてスタート日時、設定距離などの情報とともに、その仮想競技会に参加するか否かを示すソフトウェアキー５１、５２が表示される。

携帯端末２０においてＣＰＵ２２１は、仮想競技会に参加する旨の操作がなされたか、または、参加しない旨の操作がなされたかを判別する（ステップＳ２０３）。利用者が参加しない旨の操作をしたと判別したとき、例えば図６において「いいえ」を示すソフトウェアキー５１と重なる部分がタッチ操作されたとき、ＣＰＵ２２１は、仮想競技会に参加するためのアプリケーションの実行を終了する。
一方、利用者が参加する旨の操作をしたと判別したとき、例えば図６において「はい」を示すソフトウェアキー５２がタッチ操作されたとき、ＣＰＵ２２１は、参加する旨の情報（Ｒeq2）を、通信インターフェース２３０を介し管理装置１０に送信する。

情報（Ｒeq2）を受信した管理装置１０ではＣＰＵ１２１が参加受付部１３として機能する。詳細には、ＣＰＵ１２１は、当該情報（Ｒeq2）を送信した携帯端末２０の利用者情報を当該仮想競技会に対応する参加者テーブルに登録する（ステップＳ１０２）。具体的には、ＣＰＵ１２１は、データベース１３５において、図７に示されるように開催予定の仮想競技会に対応した参加者テーブルを作成するとともに、参加の意思が示された場合には、当該参加者テーブルに利用者のユーザーネームが参加予定者として順次登録する。図７には、エントリーＮｏ．（番号）が「１」から「５０」まで順番に、５０名分が登録された例が示されている。

なお、この参加者テーブルには、ユーザーネーム毎に、現在順位、スタートからの累積移動距離（単位メートル）および現在のステータスを示す情報が記録される。ただし、ステップＳ１０２の参加登録の直後にあっては、仮想競技会の開催前であるので、参加者テーブルには参加者のユーザーネームが登録されただけの状態である。換言すれば、当該テーブルには、現在順位および累積走行距離にレコードはない。また、ステータスは、本実施形態では「スタート前」、「走行中」、「完走」のいずれかとするが、ステップＳ１０２の直後では、全員のステータスが「スタート前」となっている。

また、ステップＳ１０１においては、現在時刻に近い仮想競技会の情報をサーチしたが、複数の仮想競技会の予定をサーチして携帯端末２０に送信する一方で、ステップＳ２０２において表示部２２８に表示させて、利用者に対して参加希望の仮想競技会を選択させる構成としても良い。この構成において、管理装置１０は、複数の仮想競技会に対応するテーブルのうち、参加意思のあった仮想競技会のテーブルに参加予定者のユーザーネームを追加すれば良い。

図８は、エントリー後、仮想競技会がスタートするまでの動作シーケンスを示す図である。
まず、管理装置１０ではＣＰＵ１２１が、ＲＴＣ１２４から出力される現在時刻がデータベース１３５に記録された仮想競技会の開催予定日時の所定時間前、例えば２分前に至ったか否かを判別する（ステップＳ１０６）。具体的には例えば図６に示したような開催日時であれば、ＲＴＣ１２４から出力される現在時刻が２分前の１５時５８分００秒になったか否かが判別される。２分前に至っていなければ、手順がステップＳ１０６に再び戻る。換言すれば、２分前に至るまで、ステップＳ１０６が繰り返しループする。

現在時刻が開催時刻の２分前に至ると、ステップＳ１０６の判別結果が「Ｙｅｓ」となるので、管理装置１０のＣＰＵ１２１は、仮想競技会の参加予定者に対して開催時刻が２分前である旨の告知処理を実行する（ステップＳ１０７）。具体的には、ＣＰＵ１２１は、仮想競技会の参加者テーブルに登録された参加予定者の携帯端末２０に、当該仮想競技会の開催時刻を含む情報（Ｓcr）を携帯端末２０にそれぞれ送信する。

情報（Ｓcr）を受信した携帯端末２０のＣＰＵ２２１は、当該情報（Ｓcr）に基づいた予告画面を表示部２２８に表示させる。これにより参加予定者は、仮想競技会の開始時刻を確認することができる（ステップＳ２０４）。
図９は、表示部２２８に表示される予告画面の一例を示す図である。なお、この予告画面は、図７に示した参加者テーブルにおいてエントリーＮｏ．が「２５」である参加予定者の携帯端末２０の表示例であり、ユーザーネームとともに２分後に開始する旨が表示される。このとき、携帯端末２０ではＣＰＵ２２１が、予告画面のテキスト文を音声ファイルに変換して音声出力部２２９に供給し、イヤホン２２から音声として出力させても良い。これにより、視覚および聴覚によって、参加予定者は、仮想競技会のスタートが近いことを確認することができる。

次に、携帯端末２０ではＣＰＵ２２１が、ＲＴＣ２２４から出力される現在時刻が当該仮想競技会のスタート時刻の、例えば１０秒前に至ったか否かを判別する（ステップＳ２０５）。先の例でいえば、ＲＴＣ２２４から出力される現在時刻が１０秒前の１５時５９分５０秒になったか否かが判別される。
現在時刻がスタート時刻の１０秒前に至っていなければ、手順がステップＳ２０５に再び戻る一方で、１０秒前に至ったとき、ステップＳ２０５の判別結果が「Ｙｅｓ」となる。このとき、ＣＰＵ２２１は、ＲＴＣ２２４の時刻進行に合わせて、例えば「１０、９、８、…、１、スタート」というカウントダウンを音声出力および画面表示で実行する（ステップＳ２０６）。

携帯端末２０ではＣＰＵ２２１が、ＲＴＣ２２４から出力される現在時刻が当該仮想競技会のスタート時刻に至ったか否かを判別する（ステップＳ２０７）。先の例でいえば、ＲＴＣ２２４から出力される現在時刻が１６時００分００秒になったか否かが判別される。現在時刻がスタート時刻に至っていなければ、処理の手順がステップＳ２０７に再び戻る一方で、スタート時刻に至ったときには、ステップＳ２０７の繰り返しループを抜ける。なお、ステップＳ２０４〜Ｓ２０７の処理は、仮想競技会の参加者テーブルに登録された参加予定者の携帯端末２０の各々においてそれぞれ実行される。

一方、管理装置１０においてもＣＰＵ１２１は、ＲＴＣ１２４から出力される現在時刻が当該仮想競技会のスタート時刻に至ったか否かを判別する（ステップＳ１０８）。したがって、管理装置１０におけるＲＴＣ１２４と各携帯端末２０におけるＲＴＣ２２４とがそれぞれ正しい時刻情報を出力していれば、管理装置１０においてステップＳ１０８のループが抜けるタイミングと、各携帯端末２０においてステップＳ２０７のループが抜けるタイミングとが互いに一致する。これによって、管理装置１０と、参加予定者として登録された各携帯端末２０とでは、仮想競技会が予定されていたスタート時刻から開始することになる。

仮想競技会のスタート後、携帯端末２０のＣＰＵ２２１の各々は、ＧＰＳ受信部２２６で受信した衛星信号から現在地を測位して、その位置情報（緯度・経度情報）を、それぞれ管理装置１０に送信する。
管理装置１０ではＣＰＵ１２１が、スタート後において携帯端末２０から初めて受信した位置情報を参加者のスタート地点、すなわち累算移動距離を算出するにあたっての起点とするほか、例えば図１０に示されるように参加者テーブルにおいて参加予定者全員分のステータスを「走行中」に更新する（ステップＳ１０９）。

仮想競技会においては、管理装置１０におけるＲＴＣ１２４と各携帯端末２０におけるＲＴＣ２２４とが正しく時刻情報を出力していることが重要となる。このため、例えば携帯端末２０が情報（Ｓcr）を受信したときに、ＲＴＣ２２４の時刻情報を、ＧＰＳの衛星信号に含まれる時刻情報を用いて校正しても良い。
また、携帯端末２０では、情報（Ｓcr）を受信したタイミングから、ＲＴＣ２２４の時刻情報のズレを認識することができる。例えば、上述した例でいえば、情報（Ｓcr）を受信したタイミングにおいて、ＲＴＣ２２４で示される時刻が１５時５７分５０秒であったとき、ＣＰＵ２２１は、ＲＴＣ２２４が１０秒遅れていることを認識することができる。このとき、ＣＰＵ２２１は、ＲＴＣ２２４で示される時刻情報よりも１０秒だけ早めてステップＳ２０７のループを抜けるようにすれば、たとえ自己のＲＴＣ２２４を校正しなくても、他の参加者と同一時刻で仮想競技会をスタートさせることができる。

図１１は、仮想競技会が終了するまでの動作シーケンスを示す図である。
仮想競技会が開始すると、参加者の各々は実際にランニングを開始する。なお、ランニングのコース、ゴール先は仮想競技会では定められないので、参加者同士は、互いに遠隔の地にて、それぞれ比較的自由なスタイルでランニングすることになる。参加者の携帯端末２０の各々は、ＧＰＳ受信部２２６で受信した衛星信号から現在地を測位して、その位置情報をそれぞれ管理装置１０に送信する。

管理装置１０ではＣＰＵ１２１が、ＲＴＣ１２４による時刻情報を参照しつつ、仮想競技会が開始してから、または、前回の処理が実行されてから、設定時間が経過したか否かを判別する（ステップＳ１１０）。ここで、設定時間とは基準周期のことであり、例えば２０秒である。設定時間が経過していなければ、手順がステップＳ１１０に再び戻る。このため、設定時間が経過するまで、ステップＳ１１０が繰り返しループする。
設定時間が経過したとき、ＣＰＵ１２１は、位置取得部１４ａとして機能する。詳細にはＣＰＵ１２１は、ある参加者の携帯端末２０に着目するとともに、着目した携帯端末に対して位置情報を要求する一方、当該要求を受信した着目携帯端末が自機の位置情報を管理装置１０に送信する。これによって、ＣＰＵ１２１は、当該着目携帯端末の位置情報を取得する（ステップＳ１１１）。本実施形態において携帯端末２０については、例えば参加者テーブルに登録された参加者のうち、ステータスが「走行中」である者の携帯端末についてエントリーＮｏ．の順番で着目する。このため、例えば参加者全員が「走行中」であって、ステップＳ１１０の後、初めてステップＳ１１１が実行されるときに着目される携帯端末２０は、エントリーＮｏ．が「１」である参加者の携帯端末である。

次に、ＣＰＵ１２１は、距離算定部１４ｂとして機能する。詳細にはＣＰＵ１２１は、着目した携帯端末について、前回取得した位置情報で規定される地点から、今回取得した位置情報で規定される地点までの２点距離を算出する（ステップＳ１１２）。なお、仮想競技会がスタートしてからステップＳ１１２が初めて実行されるときには、ステップＳ１０９で取得したスタート時の位置情報が用いられる。

ＣＰＵ１２１は、算出した２点距離を、参加者テーブルのうち、着目した携帯端末に対応する累積移動距離に加算する（ステップＳ１１３）。ステップＳ１１２において算出された２点距離は、設定時間で参加者がランニングしたことによるものであり、この距離をスタート時から逐一累積したものが累積移動距離である。したがって、この累積移動距離によって、参加者がスタート時からランニングした総距離が算定される。

さて、ＣＰＵ１２１は、参加者テーブルに登録された携帯端末２０のすべてに対しステップＳ１１１〜Ｓ１１３の処理を実行したか否かを判別する（ステップＳ１１４）。本実施形態において携帯端末２０については参加者テーブルにおけるエントリーＮｏ．の順番で着目しているので、ここでは、着目している携帯端末が最終のエントリーＮｏ．であるか否かを判別すれば良い。

判別結果が「Ｎｏ」であれば、ＣＰＵ１２１は、同様な処理を異なる携帯端末に実行するために、着目する携帯端末を変更して、手順をステップＳ１１１に戻す。
一方、判別結果が「Ｙｅｓ」であれば、設定時間が経過した時点において、参加者テーブルに登録された参加者のランニング距離（累積移動距離）が、参加者全員分求められたことになる。そこで次に、ＣＰＵ１２１は順位決定部１５として機能する。詳細には、ＣＰＵ１２１は、ステータスが「走行中」である参加者の累積移動距離を互いに比較し、大きい値から順番に順位付けて、参加者テーブルの現在順位を更新する（ステップＳ１１５）。

次に、ＣＰＵ１２１は、完走者が現れたか否かを判別する（ステップＳ１１６）。例えば仮想競技会の設定距離が「１０ｋｍ」であれば、参加者テーブルの累積移動距離が「１０，０００」に達した参加者がいるか否かによって判別することができる。
ステップＳ１１６における判別結果が「Ｎｏ」であれば、または、後述するステップＳ１１９における判別結果が「Ｎｏ」であれば、ＣＰＵ１２１は、情報通知部１６として機能する。詳細にはＣＰＵ１２１は、参加者テーブルにおいてステータスが「走行中」である参加者の携帯端末２０に、当該参加者の順位および累積移動距離を距離通知情報として送信する（ステップＳ１１７）。一方、距離通知情報を受信した携帯端末２０ではＣＰＵ２２１が、表示部２２８に経過画面を表示させて、仮想競技会における順位等を参加者に知らせるとともに、経過画面のテキスト文を音声ファイルにしてイヤホン２２から音声として出力させる（ステップＳ２０８）。これにより、ランニング状態にある参加者は、現在の順位などを知ることができる。
なお、管理装置１０においてＣＰＵ１２１は、ステップＳ１１７において距離通知情報を送信した後、手順をステップＳ１１０に戻し、次に設定時間が経過するまで待機する。

一方、ステップＳ１１６において完走者がいれば、その判別結果が「Ｙｅｓ」となり、ＣＰＵ１２１は、参加者テーブルにおいて、完走した参加者のステータスを「走行中」から「完走」に変更するとともに、当該完走した参加者の携帯端末２０に、当該参加者の順位を結果情報として送信する（ステップＳ１１８）。なお、ステップＳ１１６における判別の根拠となった完走者が複数人であれば、当該完走者の各々に対してステータスの変更と結果情報の送信とがそれぞれ実行される。
一方、結果情報を受信した携帯端末２０ではＣＰＵ２２１が、表示部２２８に結果画面を表示させて仮想競技会における順位等を参加者に知らせるとともに、結果画面のテキスト文を音声ファイルにしてイヤホン２２から音声として出力する（ステップＳ２０９）。これにより、参加者は、自分が完走した旨および完走順位などを知ることができる。以降、完走した参加者の携帯端末２０は、位置情報の出力を停止して、仮想競技会に参加するために実行していたアプリケーションソフトウェアを終了させる。

管理装置１０においてＣＰＵ１２１は、参加者テーブルにおいて、参加者全員のステータスが「完走」であるか否かを判別する（ステップＳ１１９）。
この判別結果が「Ｎｏ」であれば、完走者が現れたが、まだ「走行中」の参加者もいる、ということを意味している。このため、ＣＰＵ１２１は、「走行中」の参加者に対して距離通知情報を知らせるために手順を上記Ｓ１１７にスキップさせる。
一方、この判別結果が「Ｙｅｓ」であれば、参加者全員が完走して、それぞれの結果情報の出力も済んだ、ということを意味している。このため、ＣＰＵ１２１は、今回の仮想競技会についての処理を終了して、次回以降に予定されている仮想競技会に備える。

ここで、仮想競技会のスタート後において、参加者テーブルに登録された参加者のステータスが「走行中」に更新されてからの具体的な動作について説明する。なお、この説明では、スタート後のステップＳ１０９において参加者テーブルが図１０に示されるように更新された場合を例にとる。

参加者の携帯端末２０の各々は、位置情報を管理装置１０の要求に応じてそれぞれ送信し続ける。
一方、管理装置１０では、スタート後に参加者テーブルのステータスがステップＳ１０９で更新されてから参加者全員が完走するまで、設定時間が経過する毎に、ステップＳ１１１〜Ｓ１１９の処理が実行される。このうち、ステップＳ１１１〜Ｓ１１４の繰り返しによって、参加者テーブルに登録された参加者のうち、ステータスが「走行中」である携帯端末２０について、設定時間における２点距離がそれぞれ算出され、累積移動距離に加算されて、参加者テーブルにおける累算移動距離が更新される。
例えば、エントリーＮｏ．が「２５」である携帯端末２０に着目した場合に、ステップＳ１１２において算出された２点距離が「７７」であって、更新前の累算移動距離が「１，２３７」であるとき、ステップＳ１１３においては、図１２に示されるように「１，３１４」に更新される。

参加者テーブルに登録された参加者のうち、ステータスが「走行中」である参加者全員分の累算移動距離が更新されると、ステップＳ１１５において当該累算移動距離同士が比較されて、順位が更新される。
例えば累算移動距離の更新によって、エントリーＮｏ．が「１」である参加者の累算移動距離よりも、エントリーＮｏ．が「２５」である参加者の累算移動距離を上回ったとき、図１３に示されるように参加者テーブルにあっては、エントリーＮｏ．が「１」である参加者の順位とエントリーＮｏ．が「２５」である参加者の順位とが入れ替えられるように更新される。

この後、ステップＳ１１７によって参加者テーブルにおいてステータスが「走行中」である参加者の携帯端末２０の各々に、当該参加者の距離通常情報がそれぞれ送信される。例えば、参加者テーブルが図１３に示した内容に更新されたときに、エントリーＮｏ．が「２５」である参加者の携帯端末２０の表示部２２８には、図１４に示されるような経過画面が表示されるとともに、音声出力部２２９によってイヤホン２２から、この経過画面のテキスト文が音声出力されることになる。このとき、順位が９位から８位に繰り上がったことを画面、音声で出力しても良い。
なお、ステップＳ１１１〜Ｓ１１９は、スタート後から完走するまで、設定時間経過する毎に実行されるので、図１４に示した経過画面／音声についても、設定時間経過する毎に参加者に表示／出力される。このため、参加者は、スタート後からの走行距離とともに、他の参加者との比較による順位について逐一知ることができる。

スタートしてから、ある程度の時間が経過すると、参加者テーブルにおいて累積移動距離が設定距離に達した完走者が現れる。完走者が現れたとき、参加者テーブルにおいて当該完走者のステータスが「完走」に変更されるとともに、完走者の携帯端末２０には、ステップＳ１１８によって完走者に結果情報が送信される。例えば、エントリーＮｏ．が「２５」である参加者の累積移動距離が図１５に示されるように設定距離に達したときに、参加者テーブルにおいて当該参加者のステータスが「走行中」から「完走」に変更されるとともに、その時点での順位を含む結果情報が当該参加者の携帯端末２０に送信される。
これにより、当該参加者の携帯端末２０の表示部２２８には、図１６に示されるよう結果画面が表示されるとともに、音声出力部２２９によってイヤホン２２から、この結果画面のテキスト文が音声出力されることになる。

なお、完走者の携帯端末２０は、参加者テーブルにおいてステータスが「完走」に変更されるので、以後、ステップＳ１１１〜Ｓ１１４において着目されず、またステップＳ１１７における距離通知情報の送信対象から除外されることになる。そして、ステータスが「完走」に変更された完走者の現在順位を示す順位がゴール順位となって確定され、それ以降のステップＳ１１５の処理では、ステータスが「走行中」の参加者に対してのみ順位の更新が行われる。また、他の参加者が完走しても、ステータスが「走行中」の参加者には、ステップＳ１１７によって距離通知情報が完走するまで繰り返し送信される。
参加者全員が完走すると、管理装置１０において、今回の仮想競技会についての処理を終了することになる。
なお、参加者テーブルにゴール時間の情報を追加することで、ゴールした時間を記録するようにしてもよい。

本実施形態によれば、参加者は、たとえ一人でランニングしていても、場所を異にして同じ時間を共有する他の参加者に対しての自己の順位を知るので、あたかも競技会でランニングしているかのような感覚を得ることができる。

＜応用・変形例＞
なお、本発明は、上述した各実施形態に限定されるものではなく、例えば次に述べるような各種の応用・変形が可能である。また、次に述べる応用・変形の態様は、任意に選択された一または複数を適宜に組み合わせることもできる。

＜ランニング以外の競技＞
実施形態においては、競技として予め定められた距離をランニングする場合を例にとったが、例えば自転車走行のように移動を伴う競技であれば適用可能である。自転車走行の場合に携帯端末２０は参加者（競技者）自身に対してではなく、自転車に装着されることもあり得る。このため、携帯端末２０は必ずしも参加者に装着または携行される必要はなく、参加者と一体で移動する構成であれば良い。

＜移動距離の算出主体、算出態様＞
実施形態においては、管理装置１０が、設定時間毎に位置情報から携帯端末２０の２点距離を算出したが、この算出については携帯端末２０が実行して、管理装置１０に通知する構成としても良い。２点距離の累算についても、管理装置１０ではなく携帯端末２０が実行して、累算移動距離を管理装置１０に通知する構成としても良い。
一方、実施形態では、設定時間経過したときの位置情報で示される２点間の距離を直線近似で算出する構成であったが、例えば管理装置１０側で道路などの地図情報を記憶しておき、位置情報と道路情報とのマッチングによって曲線的な道のりを算出するようにしても良い。また、携帯端末２０に地磁気センサーや加速度センサーなどのセンサーを設けて、当該センサーによる方位情報を、ＧＰＳによる位置情報とともに、道のりの算出に用いても良い。さらに、緯度・経度に加えて高度情報を反映して、距離や道のりを算出するようにしても良い。また、高度情報を反映する場合に、参加者同士で不均衡が生じる可能性があるとき、アップダウンに応じてハンディを与えるようにしても良い。

＜距離通知情報の通知態様＞
実施形態では、完走するまで各参加者に対して自己の順位と走行距離とを通知する構成としたが、他の参加者の順位、走行距離をリスト化して、自己の順位、走行距離が他者と区別できるような態様で通知する構成としても良い。
また、全体のなかの順位という絶対的な情報でなくても良い。例えば前の走行者まで、あと何メートルで追い付く旨や、後の走行者が背後何メートルまで迫っている旨などの相対的な情報を、絶対的情報に代えて、または、絶対的情報とともに通知する構成としても良い。
参加者の累算移動距離とその算出時刻とから、当該参加者の平均速度や、完走予定時刻などを通知しても良い。さらに、参加者全員の完走予定時刻を比較して、いまの走行ピッチからどれだけ早めた場合に、順位がどこまで繰り上がるかをガイダンスしても良い。
一方、位置情報の取得・距離通知情報の送信と、当該距離通知情報に基づく経過情報の出力とは、同期させなくても良い。例えば位置情報の取得・距離通知情報の送信の３回に対して、当該距離通知情報に基づく経過情報の出力を１回の割合で実行するようにしても良い。

＜設定時間の変更＞
実施形態では、ステップＳ１１０における設定時間、すなわち位置情報の取得周期を、例えば２０秒で一定としたが、競技状況に応じて動的に変更する構成としても良い。
例えば、二者間の累積移動距離が閾値以下に接近している場合、すなわち追い抜きが発生しそうな場合には、設定時間を短くして、より高精度に累積走行距離および順位を求めるようにしても良い。逆に、二者間の累積走行距離が離れている場合、すなわち追い抜きが発生しそうにもない場合には、設定時間を長くしても良い。
また例えば、完走間近になると、参加者がランニングペースを上げる場合が考えられる。このため、累積移動距離が設定距離に近づくにつれて、設定時間を例えば１０秒、５秒などのように段階的に短くして、完走に至る判別をより高精度に実行するようにしても良い。

＜設定時間の個別制御＞
実施形態では、ステップＳ１１１〜Ｓ１１４の繰り返しによって、ステータスが「走行中」である参加者の携帯端末を順番に着目して位置情報を取得する構成とした。このため、実施形態では、「走行中」である参加者の携帯端末の位置情報が共通の設定時間毎に取得する構成となっていた。これに限られず、位置情報の取得周期である設定時間を、参加者の競技状況に応じて携帯端末毎に動的に変更するとともに、各携帯端末の位置情報を独立して取得して、その都度、参加者テーブルの累積移動距離を更新する態様としても良い。
なお、順位等については、比較条件を揃えるために、各参加者にわたって同じタイミングで更新するのが良い。
この態様によれば、相互に接近する携帯端末同士についての移動距離の取得周期が短周期化される。
上述した実施形態において、設定時間を短くすると、ステータスが「走行中」である携帯端末のすべてについて位置情報の取得周期が短縮されるので、通信トラヒックが増加するだけなく、管理装置１０の負荷も高まってしまう。これに対して、上記態様によれば、位置情報の取得周期が短縮される携帯端末は、相互に接近するもの同士に限られるので、
通信トラヒックの増加や管理装置１０の高負荷化を回避することができる。

＜位置情報の取得契機＞
実施形態では、管理装置１０が、ステップＳ１１１において着目した携帯端末２０に対して位置情報を要求する一方、当該要求をした携帯端末２０が位置情報を管理装置１０に送信する構成であった。すなわち実施形態では、位置情報の取得が管理装置１０による要求を契機として実行される構成であった。この構成に限られず、携帯端末２０が管理装置１０の要求に依らずに自発的に設定時間毎に位置情報を送信する一方で、送信された位置情報を管理装置１０が取得するとともに、取得の都度、参加者テーブルの累積移動距離等を更新する構成としても良い。
なお、設定時間については、管理装置１０が参加者テーブルを参照しつつ、競技状況に応じて携帯端末２０に通知して変更すれば良い。

＜参加者のグループ分け＞
仮想競技会は、参加者が二人以上であれば成立する。一方で、参加者を無制限に受け付けることも可能ではあるが、参加者が多数であれば複数のグループに区分しても良い。

図１７は、参加者が多数の場合に複数のグループに区分する場合のシーケンスを示す図である。この場合、図５に示したステップＳ１０２において、ＣＰＵ１２１が、携帯端末２０の利用者情報を当該仮想競技会に対応する参加者テーブルに順番に登録している状態を前提としている。
この場合に、ＣＰＵ１２１は、予告の情報（Ｓcr）を出力する時間の例えば３分前に、当該参加登録者の人数が閾値以上となった否かを判別する（ステップＳ１０３）。この判別結果が「Ｎｏ」であれば、すなわち、複数グループに区分する必要がない場合であれば、ＣＰＵ１２１は、以後、図８におけるステップＳ１０６にスキップして、実施形態で説明したような動作を実行する。

一方、判別結果が「Ｙｅｓ」であれば、ＣＰＵ１２１は、それまでに登録した参加予定者を人数に応じた複数のグループに区分する（ステップＳ１０４）。
グループ区分に際しては、予め作成されていたソーシャルグラフ情報にしたがって参加者を分けるのが好ましい。ここでいうソーシャルグラフ情報とは、例えば図１８に示されるように、複数の利用者（参加者）同士がどのような関係性を持っているのかをリンクで結んで図式化した情報である。
仮想競技会には一意な識別符号（競技会ＩＤ）が付与されるとともに、利用者が、ある仮想競技会に参加すると、当該利用者情報に紐付けて競技会ＩＤが管理される。このとき、同一の仮想競技会に参加した参加者同士の結び付きが強くなるようにソーシャルグラフ情報が構成されている。図示の例においては、結び付きが強い関係ほど、リンクを示す線幅が太くなるように示されている。
図１８に示されるようなソーシャルグラフで関係性が規定された参加者「Ａ」〜「Ｉ」を２つのグループに区分する場合、結び付きの度合いを考慮して、例えば参加者「Ａ」〜「Ｄ」からなる第１グループと、参加者「Ｅ」〜「Ｉ」からなる第２グループとに区分されるグループに区分したときに、同じグループに属する参加者同士の結び付きをさらに強くなるようにしても良い。

グループの区分に際しては、ソーシャルグラフを用いない方法であっても良い。例えば、参加者が居住する地域や、競技レベル、性別、年齢など、予め登録しておいた属性を総合的に考慮して、属性が近似する参加者同士を同一グループとなるようにしても良い。
また、エントリーする際に、属性情報を参考にして良い否か、あるいは、ソーシャルグラフを参考にして良いのか否かを登録しておき、いざグループに区分する際には、これらの情報を参考にして、あるいはランダムに区分するように構成しても良い。

参加予定者を複数のグループに区分したとき、ＣＰＵ１２１は、１つのグループとして扱っていた元の参加者テーブルを、区分したグループの各々に対応するように作成し直す（ステップＳ１０５）。この後、ＣＰＵ１２１は、各携帯端末２０に、参加者が属することになったグループの情報を、グループ情報として送信する。このとき、携帯端末２０においてＣＰＵ２２１は、表示部２２８にグループ情報を表示させても良い。

仮想競技会においては、管理装置１０におけるＣＰＵ１２１が、複数のグループに対する処理を並列に実行することによって、あるグループに属する参加者の携帯端末２０には、参加者全員における順位ではなく、自己が属するグループにおける順位が距離通知情報として送信されることになる。

＜競技途中の音楽再生＞
音楽を再生することによって、参加者は、好みの音楽を聴きながらランニングしても良い。音楽を聴きながらランニングする場合には、再生中の音楽に、経過や結果などの音声をミキシングして出力する構成にすれば良い。
この構成において、仮想競技会に参加していた参加者が聴いていた音楽情報を管理装置１０などが収集して、仮想競技会終了後、ランキングとともに当該参加者に公開しても良いし、ダウンロードによって購入可能な構成にしても良い。

＜競技会のモード＞
仮想競技会に参加する際に複数モードを持たせるとともに、参加者にいずれかのモードを選択させるように構成しても良い。
例えば「モード」として「レースモード」または「ファンモード」のいずれかを参加者に選択させるように構成しても良い。このとき「レースモード」を選択した参加者に対しては、レース結果を重視させるために、順位等の情報を優先的に知らせる構成とすれば良い。一方、「ファンモード」を選択した参加者に対しては、仮想競技会において気のあった参加者同士で見掛け上の集団を形成し易くさせるために、前後を走行している走行者のネームや離間距離を知らせる構成とすれば良い。

＜参加者テーブルのステータス＞
上述した実施形態では、参加者テーブルのステータスを「スタート前」、「走行中」、「完走」のいずれかとしたが、これ以外のステータスを追加しても良い。
例えばステータスとして「リタイヤ」を追加しても良い。詳細には、スタート後において参加者が完走をあきらめて携帯端末２０の入力部２２７に対し所定の操作をしたときに、当該携帯端末２０が、その旨の情報を管理装置１０に送信する一方、その情報を受信した管理装置１０が、参加者テーブルにおいて当該参加者のステータスを「リタイヤ」に変更すれば良い。ステータスが「リタイヤ」となった参加者の携帯端末２０に対しては、それまでの距離通知情報を通知するとともに、以後、ステップＳ１１６における距離通知情報の送信対象から除外するようにしても良い。
また例えば、ステータスとして「足切り」を追加しても良い。詳細には、ゴールに制限時間を設け、制限時間内にゴールに到達できなかった参加者のステータスを「足切り」に変更するとともに、当該参加者の携帯端末２０に足切り時点における距離通知情報を通知して、それまでの累積移動距離を知らせても良い。

＜その他＞
音声ファイルの変換については、携帯端末２０側で実行するのではなく、管理装置１０側で実行して、当該音声ファイルを携帯端末２０に送信する構成としても良い。
参加者テーブルのユーザーネームについては、本名ではなく、任意に入力したハンドルネーム、ニックネームなどであっても良いのは、もちろんである。
また、設定時間における２点距離が、想定される距離よりも大きい場合には当該２点距離を無効化して、不正を防止する構成としても良い。

１…システム、１０…管理装置、１２…送受信部、１３…参加受付部、１４…距離取得部、１４ａ…位置取得部、１４ｂ…距離算定部、１５…順位決定部、１６…情報通知部、２０…携帯端末、１２１、２２１…ＣＰＵ。

Claims (9)

1. 複数の携帯端末と通信する管理装置であって、
   前記複数の携帯端末に共通の開始時刻での前記各携帯端末の位置を起点とした前記各携帯端末の移動距離を前記複数の携帯端末の各々について取得する距離取得部と、
   前記距離取得部が前記各携帯端末について取得した移動距離を対比するための距離通知情報を前記複数の携帯端末の各々に通知する情報通知部と
   を具備することを特徴とする管理装置。
2. 前記各携帯端末の移動距離に応じた順位を決定する順位決定部を含み、
   前記情報通知部は、前記順位決定部が決定した順位を含む前記距離通知情報を生成して前記各携帯端末に通知する
   ことを特徴とする請求項１の管理装置。
3. 前記距離取得部は、
   前記各携帯端末の位置情報を取得する位置取得部と、
   前記位置取得部が前記各携帯端末について取得した複数の位置情報から当該携帯端末の前記移動距離を算定する距離算定部と
   を備えることを特徴とする請求項１または請求項２の管理装置。
4. 前記携帯端末からの参加登録を受け付ける参加受付部を具備し、
   前記距離取得部は、前記参加受付部が前記参加登録を受け付けた携帯端末について前記移動距離を取得する
   ことを特徴とする請求項１、２または３に記載の管理装置。
5. 前記距離取得部は、所定の基準周期で前記各携帯端末の移動距離を取得し、移動距離が相互に接近する各携帯端末については前記基準周期よりも短い周期で前記移動距離を取得する
   ことを特徴とする請求項１乃至４のいずれかに記載の管理装置。
6. 前記複数の携帯端末を複数のグループに区分する参加者分割部を具備し、
   前記情報通知部は、前記参加者分割部が区分した前記複数のグループの各々について、当該グループに属する前記各携帯端末に関する前記距離通知情報を、当該グループに属する各携帯端末に通知する
   ことを特徴とする請求項１乃至５のいずれかに記載の管理装置。
7. 前記参加者分割部は、前記各携帯端末の利用者間の関係を規定するソーシャルグラフ情報に応じて前記複数の携帯端末を複数のグループに区分する
   ことを特徴とする請求項６に記載の管理装置。
8. 請求項１乃至７のいずれかに記載の管理装置と通信する携帯端末であって、
   前記管理装置の情報通知部から通知された距離通知情報に応じて前記複数の携帯端末のなかでの自端末の移動距離の順位を特定して音声で利用者に報知する
   ことを特徴とする携帯端末。
9. 複数の携帯端末と通信するコンピュータに、
   前記複数の携帯端末に共通の開始時刻での前記各携帯端末の位置を起点とした前記各携帯端末の移動距離を前記複数の携帯端末の各々について取得する距離取得処理と、
   前記各携帯端末の移動距離を対比するための距離通知情報を前記複数の携帯端末の各々に通知する情報通知処理と
   を実行させることを特徴とするプログラム。