JP5652298B2 - 行き先決定プログラム、および行き先決定方法 - Google Patents

Description

本発明は、利用者の行き先を決定する行き先決定プログラム、および行き先決定方法に関する。

従来、オフィスでは、従業員が現在どこにいるのかを他の人に伝えるために、従業員が移動時に共有のホワイトボードや黒板に書き込む行き先掲示板がよく利用されている。近年では、従業員の行き先情報をサーバで管理し、従業員がサーバ上のデータベースに記憶された行き先情報を更新することで、他の従業員はブラウザ等でサーバ上のデータベースから各従業員の行き先情報を確認する電子的な行き先掲示板システムも使われている。

しかし、従業員が、サーバ上の行き先掲示板用のデータベースに記憶された従業員の行き先の更新を忘れたり、行き先掲示板の行き先の更新後に従業員が向かった場所を変更した場合、従業員の居場所を特定できないという問題点がある。そこで、たとえば、会議室にＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を設置し、従業員が所持する携帯端末が設置されたＲＦＩＤの情報を読み込む。そして、読み込んだＲＦＩＤの情報に基づいて自動的にサーバ上のデータベースの行き先を更新する技術（以下、「従来技術１」と称する。）が知られている（たとえば、下記特許文献１参照。）。

また、たとえば、固定されているＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）の位置情報に応じて移動する携帯端末の位置情報を推定する技術（以下、「従来技術２」と称する。）が知られている（たとえば、下記特許文献２参照。）。

また、たとえば、携帯端末のＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）の位置情報、携帯端末のログイン情報、会議室の予約情報、入退場履歴情報、スケジュール管理情報に基づいて携帯端末の位置を推定する技術が知られている。そして、推定した携帯端末の位置と行き先掲示板に登録されている行き先が不一致の場合、不一致であることを表示する技術（以下、「従来技術３」と称する。）が（たとえば、下記特許文献３参照。）知られている。

特開２００７−１０２３９２号公報 特開２００３−２０３２８７号公報 特開２００９−２５１６２４号公報

しかしながら、従来技術では、サーバ上の行き先掲示板用のデータベースに記憶された従業員の行き先の更新を忘れたり、行き先掲示板の行き先の更新後に従業員が向かった場所を変更した場合、依然として従業員の居場所を特定できないという問題点がある。たとえば、従来技術１，２では、ＲＦＩＤやＰＣが設置されていない場所では行き先掲示板の行き先を自動更新することができない。

たとえば、従来技術３では、ＧＰＳを用いると、オフィスのような屋内では、ＧＰＳの位置情報を取得できない場合があるため、行き先掲示板の行き先を自動更新することができない場合がある。たとえば、ＧＰＳをオフィスのような屋内で用いることができても、屋内では正確な行き先を特定することができない。行き先掲示板で通常使用される情報は場所名（たとえば、会議室名）であるが、ＧＰＳにより取得できるのは緯度・経度などの情報である。よって、緯度・経度などの情報と場所名とが対応付けられた情報を事前に作成し、行き先掲示板の運用時にはＧＰＳを用いて取得した情報と場所名とを対応付ける処理を行わなければならない。

また、たとえば、従来技術３では、携帯端末のログイン情報、会議室の予約情報、入退場履歴情報、スケジュール管理情報を用いるには、従業員がそれぞれの情報に行き先掲示板と同じ情報を入力していることを前提にしている。すなわち、行き先掲示板に加えて、携帯端末のログイン情報、会議室の予約情報、入退場履歴情報やスケジュール管理情報への正確な行き先の入力および予定変更等に応じて適切な行き先の更新が行われなければならない。そのため、携帯端末のログイン情報、会議室の予約情報、入退場履歴情報やスケジュール管理情報への更新を忘れると、従業員の居場所を特定することができない。

本発明は、上述した従来技術による問題点を解消するため、行き先掲示板の利用者の行き先を自動更新することができる行き先決定プログラム、および行き先決定方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明の一側面によれば、複数の利用者のうちいずれかの利用者が所持する第１の携帯端末から、前記いずれかの利用者の識別情報と、前記第１の携帯端末の通信圏内にある第２の携帯端末から受信された前記第２の携帯端末を所持する他の利用者の識別情報とを受信し、複数の利用者の各々の利用者の識別情報と前記各々の利用者の行き先とを関連付けて記憶するデータベースを参照して、受信された前記他の利用者の識別情報と関連付けて記憶されている前記他の利用者の行き先を特定し、特定された前記他の利用者の行き先に基づいて、前記いずれかの利用者の行き先を決定し、決定結果と受信された前記いずれかの利用者の識別情報とを関連付けて出力する行き先決定プログラム、および行き先決定方法が提案される。

本発明の一側面によれば、行き先掲示板の利用者の行き先を自動更新することができるという効果を奏する。

図１は、本発明の一例を示す説明図である。 図２は、掲示板管理システムの一例を示す説明図である。 図３は、サーバ２００のハードウェア例を示すブロック図である。 図４は、携帯端末のハードウェア例を示すブロック図である。 図５は、実施の形態１にかかる行き先データベース２１０の一例を示す説明図である。 図６は、実施の形態１にかかる近接ユーザＩＤデータベース２２０−１の一例を示す説明図である。 図７は、実施の形態１にかかる携帯端末２０１−ｘとサーバ２００のそれぞれの機能例を示すブロック図である。 図８は、実施の形態１にかかる携帯端末２０１―１と近接携帯端末とのユーザＩＤの交換例を示す説明図である。 図９は、実施の形態１にかかる通知情報例を示す説明図である。 図１０は、実施の形態１にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図である。 図１１は、実施の形態１にかかる携帯端末２０１−ｘによるユーザＩＤの交換処理手順の一例を示すフローチャートである。 図１２は、実施の形態１にかかる携帯端末２０１−ｙによるユーザＩＤの交換処理手順の一例を示すフローチャートである。 図１３は、実施の形態１にかかる携帯端末２０１−ｘによる通知情報の送信処理手順の一例を示すフローチャートである。 図１４は、実施の形態１にかかるサーバ２００による行き先決定処理手順の一例を示すフローチャートである。 図１５は、実施の形態１にかかるサーバ２００による更新処理手順を示すフローチャートである。 図１６は、実施の形態２にかかる行き先データベース２１０の一例を示す説明図である。 図１７は、実施の形態２にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図である。 図１８は、実施の形態２にかかるサーバ２００による行き先決定処理手順の一例を示すフローチャートである。 図１９は、実施の形態２にかかるサーバ２００による更新処理手順を示すフローチャートである。 図２０は、実施の形態３にかかる行き先データベース２１０の一例を示す説明図である。 図２１は、実施の形態３にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図である。 図２２は、実施の形態３にかかるサーバ２００による行き先決定処理手順の一例を示すフローチャートである。 図２３は、実施の形態３にかかるサーバ２００による更新処理手順を示すフローチャートである。 図２４は、実施の形態４にかかる近接ユーザＩＤデータベース２２０−１の一例を示す説明図である。 図２５は、実施の形態４にかかる携帯端末２０１―１と近接携帯端末とのユーザＩＤの交換例を示す説明図である。 図２６は、実施の形態４にかかる通知情報例を示す説明図である。 図２７は、実施の形態４にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図である。 図２８は、実施の形態４にかかる携帯端末２０１−ｘによるユーザＩＤの交換処理手順の一例を示すフローチャートである。 図２９は、実施の形態４にかかるサーバ２００による行き先決定処理手順の一例を示すフローチャートである。 図３０は、実施の形態５にかかる行き先データベース２１０の一例を示す説明図である。 図３１は、実施の形態５にかかる携帯端末２０１―１と近接携帯端末とのユーザＩＤの交換例を示す説明図である。 図３２は、実施の形態５にかかる通知情報例を示す説明図である。 図３３は、実施の形態５にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図（その１）である。 図３４は、実施の形態５にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図（その２）である。 図３５は、実施の形態５にかかるサーバ２００による行き先決定処理手順を示すフローチャート（その１）である。 図３６は、実施の形態５にかかるサーバ２００による行き先決定処理手順を示すフローチャート（その２）である。 図３７は、実施の形態５にかかるサーバ２００による行き先決定処理手順を示すフローチャート（その３）である。 図３８は、実施の形態５にかかるサーバ２００による更新処理手順を示すフローチャートである。

以下に添付図面を参照して、本発明にかかる行き先決定プログラム、および行き先決定方法を詳細に説明する。

図１は、本発明の一例を示す説明図である。サーバ１００は、複数の利用者の行き先を、行き先データベース１１０を用いて管理する。行き先データベース１１０は、利用者を識別するユーザＩＤ、利用者の氏名、行き先のフィールドを有する。各フィールドに情報が設定されることにより、行き先情報（たとえば、行き先情報１１１−１〜１１１−４）がレコードとして記憶される。

たとえば、ＡさんのユーザＩＤが「００００１２３４」であり、ＢさんのユーザＩＤが「００００１２３５」であり、ＣさんのユーザＩＤが「００００１２３６」であり、ＤさんのユーザＩＤが「００００１２３７」である。

ここでは、複数の利用者のうちのＡさんの行き先に着目して説明する。たとえば、Ａさんが所持する携帯端末１０１−１が、近距離無線通信での通信圏内にある他の携帯端末に接続する。近距離無線通信としては、たとえば、ＢｌｕｅｔｏｏｔｈやＺｉｇｂｅｅが例に挙げられる。ここでは、携帯端末１０１−１は、Ｂさんが所持する携帯端末１０１−２とＣさんが所持する携帯端末１０１−３とのそれぞれに接続する。携帯端末１０１−１が、携帯端末１０１−２から、携帯端末１０１−２を所持するそれぞれの利用者のユーザＩＤを受信する。携帯端末１０１−１が、携帯端末１０１−３から、携帯端末１０１−３を所持するそれぞれの利用者のユーザＩＤを受信する。

携帯端末１０１−１が、携帯端末１０１−１を所持する利用者のユーザＩＤと、受信した携帯端末１０１−２を所持する利用者のユーザＩＤと、受信した携帯端末１０１−３を所持する利用者のユーザＩＤと、を有する通知情報をサーバ１００へ通知する。

サーバ１００は、携帯端末１０１−１からの接続を受け付けると、携帯端末１０１−１から通知情報を受信する。サーバ１００は、行き先データベース１１０を参照し、通知情報に含まれる携帯端末１０１−１の通信圏内である携帯端末１０１−２と携帯端末１０１−３を所持する利用者のユーザＩＤを含む行き先情報の行き先を特定する。ここでは、行き先情報１１１−２の行き先が「会議室１」であり、行き先情報１１１−３の行き先が「会議室１」である。

サーバ１００が、特定した行き先情報１１１−２の行き先と行き先情報１１１−３の行き先に基づいて、通知情報の送信元の携帯端末１０１−１を所持する利用者の行き先を決定する。サーバ１００が、行き先データベース１１０に記憶された、携帯端末１０１−１を所持する利用者のユーザＩＤを含む行き先情報１１１−１の行き先のフィールドに、決定した行き先である「会議室１」を出力する。

ここで、実施の形態１〜実施の形態５を用いて詳細に説明する。まず、実施の形態１では、ある利用者の行き先とある利用者の近距離にいる他の利用者の行き先のうち、最多の行き先をある利用者の行き先にある利用者の行き先を決定する例を示す。

つぎに、実施の形態２では、ある利用者の行き先とある利用者の近距離にいる他の利用者の行き先のうち、更新日時が最新である利用者の行き先をある利用者の行き先にある利用者の行き先を決定する例を示す。

つぎに、実施の形態３では、ある利用者が行き先を更新した更新回数と、ある利用者の近距離にいる他の利用者が行き先を更新した更新回数と、のうち、更新回数が最多の利用者の行き先に、ある利用者の行き先を決定する例を示す。

つぎに、実施の形態４では、ある利用者の行き先を、ある利用者の近距離にいる他の利用者の所持する携帯端末とある利用者の所持する携帯端末との間の信号の受信強度が最も強い携帯端末を所持する利用者の行き先に決定する。

つぎに、実施の形態５では、ある利用者の行き先を、実施の形態１〜実施の形態４で示した決定方法を組み合わせて決定する例を示す。

（実施の形態１）
まず、実施の形態１では、ある利用者の行き先を、ある利用者の行き先とある利用者の近距離にいる他の利用者の行き先のうち、最多の行き先に決定する例を示す。

図２は、掲示板管理システムの一例を示す説明図である。図２では、利用者の行き先掲示板を管理する掲示板管理システムを示す。複数の利用者は、それぞれ携帯端末２０１−１〜携帯端末２０１−ｉ（ｉ≧２）を所持して移動することとする。携帯端末２０１−１〜携帯端末２０１−ｉは、それぞれ近接ユーザＩＤデータベース２２０−１〜近接ユーザＩＤデータベース２２０−ｉを有する。また、各携帯端末には、あらかじめ所持者のユーザＩＤが登録されていることとする。

図２では、Ａさん〜Ｃさんが会議室１に居り、ＤさんとＦさんが会議室２に居り、Ｅさんが自席に居る。Ａさん〜Ｆさんは、それぞれ携帯端末２０１−１〜携帯端末２０１−６を所持している。

サーバ２００は、各利用者の行き先を管理する。サーバ２００は、サーバ室に配置されていることとする。サーバ２００は、行き先データベース２１０を有する。実施の形態１では、Ａさんの居場所を推定し、Ａさんの行き先を自動更新する例を説明する。また、実施の形態１では、サーバ２００が行き先掲示板を管理し、かつ本行き先決定に関する処理を実行している、これに限らず、行き先掲示板を管理する装置とは異なる装置が本行き先決定に関する処理を実行してもよい。

（サーバ２００のハードウェア例）
図３は、サーバ２００のハードウェア例を示すブロック図である。図３において、サーバ２００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０３と、磁気ディスクドライブ３０４と、磁気ディスク３０５と、光ディスクドライブ３０６と、光ディスク３０７と、ディスプレイ３０８と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０９と、キーボード３１０と、マウス３１１と、スキャナ３１２と、プリンタ３１３と、を備えている。また、各構成部はバス３００によってそれぞれ接続されている。

ここで、ＣＰＵ３０１は、サーバ２００の全体の制御を司る。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。磁気ディスクドライブ３０４は、ＣＰＵ３０１の制御にしたがって磁気ディスク３０５に対するデータのリード／ライトを制御する。磁気ディスク３０５は、磁気ディスクドライブ３０４の制御で書き込まれたデータを記憶する。

光ディスクドライブ３０６は、ＣＰＵ３０１の制御にしたがって光ディスク３０７に対するデータのリード／ライトを制御する。光ディスク３０７は、光ディスクドライブ３０６の制御で書き込まれたデータを記憶したり、光ディスク３０７に記憶されたデータをコンピュータに読み取らせたりする。

ディスプレイ３０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ３０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

Ｉ／Ｆ３０９は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク３１４に接続され、このネットワーク３１４を介して他の装置や携帯端末２０１−１〜携帯端末２０１−ｉに接続される。そして、Ｉ／Ｆ３０９は、ネットワーク３１４と内部のインターフェースを司り、携帯端末２０１−ｉや外部装置からのデータの入出力を制御する。Ｉ／Ｆ３０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード３１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス３１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ３１２は、画像を光学的に読み取り、サーバ２００内に画像データを取り込む。なお、スキャナ３１２は、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能を持たせてもよい。また、プリンタ３１３は、画像データや文書データを印刷する。プリンタ３１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。

（携帯端末のハードウェア例）
図４は、携帯端末のハードウェア例を示すブロック図である。図４において、携帯端末２０１−ｘ（ｘ＝１〜ｉ）は、ＣＰＵ４０１−ｘと、無線ＬＡＮ用のＩ／Ｆ４０２−ｘと、Ｂｌｕｅｔｏｏｔｈ用のＩ／Ｆ４０３−ｘと、ディスプレイ４０４−ｘと、キーボード４０５−ｘと、ＲＯＭ４０６−ｘと、ＲＡＭ４０７−ｘと、を有している。携帯端末２０１−ｘは、フラッシュＲＯＭ４０８−ｘと、フラッシュＲＯＭコントローラ４０９−ｘと、フラッシュＲＯＭ４１０−ｘと、を有している。ＣＰＵ４０１−ｘと、ディスプレイ４０４−ｘと、キーボード４０５−ｘと、ＲＯＭ４０６−ｘと、ＲＡＭ４０７−ｘと、フラッシュＲＯＭ４０８−ｘと、フラッシュＲＯＭコントローラ４０９−ｘとは、バス４１１−ｘを介して接続されている。

ここで、ＣＰＵ４０１−ｘは、携帯端末２０１−ｘの全体の制御を司り、レジスタとコアとキャッシュを有している。ディスプレイ４０４−ｘは、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ４０４−ｘは、たとえば、ＴＦＴ液晶ディスプレイなどを採用することができる。キーボード４０５−ｘは、数字、各種指示などの入力のためのキーを有し、データの入力を行う。また、キーボード４０５−ｘは、タッチパネル式の入力パッドやテンキーなどであってもよい。

Ｂｌｕｅｔｏｏｔｈ用のＩ／Ｆ４０３−ｘは、近距離無線通信によって他の携帯端末２０１−ｘに直接接続される。そして、Ｂｌｕｅｔｏｏｔｈ用のＩ／Ｆ４０３−ｘは、他の携帯端末２０１−ｘと内部のインターフェースを司り、他の携帯端末２０１−ｘからのデータの入出力を制御する。たとえば、近距離無線通信にＢｌｕｅｔｏｏｔｈを使用する場合は、他の携帯端末と相互に通信可能にするために、あらかじめペアリングの設定をしておく。または、他の携帯端末２０１−ｙ（ｙ＝１〜ｉ≠ｘ）のＢｌｕｅｔｏｏｔｈ用のＩ／Ｆの発見時には、自動的に共通の認証鍵を携帯端末間で送信し合ってペアリングを行ってもよい。

無線ＬＡＮ用のＩ／Ｆ４０２−ｘは、無線通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワーク３１４に接続され、ネットワーク３１４を介してサーバ２００や他の携帯端末２０１−ｙに接続される。そして、無線ＬＡＮ用のＩ／Ｆ４０２−ｘは、ネットワークと内部のインターフェースを司り、サーバ２００や他の携帯端末２０１−ｘからのデータの入出力を制御する。無線ＬＡＮ用のＩ／Ｆ４０２−ｘには、たとえば、モデムやＬＡＮアダプタなどを採用することができる。

ＲＯＭ４０６−ｘは、ブートプログラムなどのプログラムを記憶している。ＲＡＭ４０７−ｘは、ＣＰＵ４０１−ｘのワークエリアとして使用される。フラッシュＲＯＭ４０８−ｘは、ＯＳなどのシステムソフトウェアやアプリケーションのプログラムを記憶している。ＲＡＭ４０７−ｘはフラッシュＲＯＭ４０８−ｘよりもＣＰＵ４０１−ｘからのアクセス速度が速い。

フラッシュＲＯＭコントローラ４０９−ｘは、ＣＰＵ４０１−ｘの制御に従ってフラッシュＲＯＭ４１０−ｘに対するデータのリード／ライトを制御する。フラッシュＲＯＭ４１０−ｘは、フラッシュＲＯＭコントローラ４０９−ｘの制御で書き込まれたデータを記憶する。データの具体例としては、携帯端末２０１−ｘを使用するユーザが無線ＬＡＮ用のＩ／Ｆ４０２−ｘを通して取得した画像データ、映像データなどである。フラッシュＲＯＭ４１０−ｘは、たとえば、メモリカード、ＳＤカードなどを採用することができる。

図５は、実施の形態１にかかる行き先データベース２１０の一例を示す説明図である。行き先データベース２１０では、各利用者の行き先情報を有している。行き先データベース２１０は、ユーザＩＤ、氏名、行き先のフィールドを有する。ユーザＩＤは、利用者を識別する識別情報である。ユーザＩＤとしては、たとえば、社員番号のように利用者によって異なる番号である。

氏名は、ユーザＩＤで識別される利用者の氏名である。氏名については、本行き先決定の処理では用いていないが、理解の容易化のために、行き先データベース２１０に示している。行き先は、各ユーザＩＤで識別される利用者の行き先である。行き先としては、たとえば、自席や休憩室や会議室の名称などの場所名が挙げられる。

各フィールドに情報が設定されることで、行き先情報（たとえば、行き先情報５００−１〜行き先情報５００−７）がレコードとして記憶されている。行き先データベース２１０は、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されていることとする。

図６は、実施の形態１にかかる近接ユーザＩＤデータベース２２０−１の一例を示す説明図である。近接ユーザＩＤデータベース２２０−１は、近接ユーザＩＤ、サーチ時刻のフィールドを有する。近接ユーザＩＤは、携帯端末２０１−１がＢｌｕｅｔｏｏｔｈ用のＩ／Ｆ４０３−１を用いる無線通信での通信圏内にある他の携帯端末を所持する利用者のユーザＩＤである。ここで、携帯端末２０１−１の通信圏内にある他の携帯端末を近接携帯端末と称する。携帯端末２０１−１を所持する利用者のユーザＩＤを携帯端末２０１−１のユーザＩＤと称する。

サーチ時刻は、近接ユーザＩＤのフィールドに登録されたユーザＩＤで識別される利用者が所持する携帯端末２０１−１の近接携帯端末と該利用者が所持する携帯端末２０１−１とがユーザＩＤを交換した最新の時刻である。各フィールドに情報が設定されることで、近接ユーザ情報（たとえば、近接ユーザ情報６００−１〜近接ユーザ情報６００−３）がレコードとして記憶されている。近接ユーザＩＤデータベース２２０−１は、ＲＡＭ４０７−１、フラッシュＲＯＭ４０８−１などの記憶装置に記憶されていることとする。

（実施の形態１にかかる携帯端末２０１−ｘとサーバ２００とのそれぞれの機能例）
図７は、実施の形態１にかかる携帯端末２０１−ｘとサーバ２００のそれぞれの機能例を示すブロック図である。サーバ２００は、受信部７０１と、特定部７０２と、決定部７０３と、判定部７０４と、出力部７０５と、受付部７１１と、更新部７１２と、を有している。携帯端末２０１−ｘ（ｘ＝１〜ｉ）は、受信部７２１−ｘと、送信部７２２−ｘと、設定部７２３−ｘと、検出部７２４−ｘと、を有している。携帯端末２０１−ｙ（ｙ＝１〜ｉ≠ｘ）は、受信部７２１−ｙと、送信部７２２−ｙと、設定部７２３−ｙと、検出部７２４−ｙと、を有している。携帯端末２０１−ｙは、携帯端末２０１−ｘを所持する利用者と異なる利用者の携帯端末である。

受信部７２１−ｘ〜検出部７２４−ｘの処理がプログラムにコーディングされ、該プログラムはＲＯＭ４０６−ｘ、ＲＡＭ４０７−ｘ、フラッシュＲＯＭ４０８−ｘなどの記憶装置に記憶されている。ＣＰＵ４０１−ｘが、記憶装置に記憶された該プログラムを読み出し、該プログラムにコーディングされた処理を実行することにより、受信部７２１−ｘ〜検出部７２４−ｘの処理がＣＰＵ４０１−ｘによって実行される。

受信部７２１−ｙ〜検出部７２４−ｙの処理がプログラムにコーディングされ、該プログラムはＲＯＭ４０６−ｙ、ＲＡＭ４０７−ｙ、フラッシュＲＯＭ４０８−ｙなどの記憶装置に記憶されている。ＣＰＵ４０１−ｙが、記憶装置に記憶された該プログラムを読み出し、該プログラムにコーディングされた処理を実行することにより、受信部７２１−ｙ〜検出部７２４−ｙの処理がＣＰＵ４０１−ｙによって実行される。

受信部７０１〜出力部７０５と受付部７１１と更新部７１２との処理が行き先決定プログラムにコーディングされ、行き先決定プログラムはＲＯＭ３０２、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されている。ＣＰＵ３０１が、記憶装置に記憶された行き先決定プログラムを読み出し、行き先決定プログラムにコーディングされた処理を実行する。これにより、受信部７０１〜出力部７０５と受付部７１１と更新部７１２との処理がＣＰＵ３０１によって実行される。ここで、実施の形態１では、ｘが１である例を示す。

図８は、実施の形態１にかかる携帯端末２０１―１と近接携帯端末とのユーザＩＤの交換例を示す説明図である。まず、たとえば、送信部７２２−１が、Ｂｌｕｅｔｏｏｔｈ用のＩ／Ｆ４０３−１を用いて、携帯端末２０１−１と通信可能か否かに関する情報を周辺の携帯端末に通知する。ここで、周辺の携帯端末とは、携帯端末２０１−１が有するＢｌｕｅｔｏｏｔｈ用のＩ／Ｆ４０３−１を用いて無線通信可能な通信圏内の携帯端末である。受信部７２１−２〜受信部７２１−４が、携帯端末２０１−１からの通信可否に関する情報を受信し、送信部７２２−２〜送信部７２２−４が、携帯端末２０１−１へ通信可能を示す情報を送信する。

受信部７２１−１が、携帯端末２０１−２〜携帯端末２０１−４から通信可能を示す情報を受信すると、送信部７２２−１と受信部７２１−１が、（１）携帯端末２０１−２〜携帯端末２０１−４のそれぞれとユーザＩＤを交換する。ここでは、受信部７２１−１が、ユーザＩＤの交換により、「００００１２３５」と、「００００１２３６」と、「００００１２３７」と、を受信する。設定部７２３−１が、現時刻を取得する。

設定部７２３−１が、近接ユーザＩＤデータベース２２０−１を参照し、「００００１２３５」、「００００１２３６」、「００００１２３７」のいずれかを含む近接ユーザ情報を特定する。ここでは、近接ユーザ情報６００−１が「００００１２３５」を近接ユーザＩＤのフィールドに有し、近接ユーザ情報６００−２が「００００１２３６」を近接ユーザＩＤのフィールドに有している。設定部７２３−１が、（２）近接ユーザ情報６００−１のサーチ時刻のフィールドの時刻と、近接ユーザ情報６００−２のサーチ時刻のフィールドの時刻と、をそれぞれ現時刻に更新する。ここで、現時刻を１６：００とする。

「００００１２３７」を含む近接ユーザ情報が近接ユーザＩＤデータベース２２０−１から特定されないため、設定部７２３−１が、（２）近接ユーザＩＤデータベース２２０−１のユーザＩＤのフィールドに「００００１２３７」を登録する。設定部７２３−１が、近接ユーザＩＤデータベース２２０−１のサーチ時刻のフィールドに現時刻を設定し、新たな近接ユーザ情報６００−４を作成する。

設定部７２３−１が、近接ユーザＩＤデータベース２２０−１を参照し、交換したユーザＩＤ以外のユーザＩＤを含む近接ユーザ情報を特定する。ここでは、たとえば、近接ユーザＩＤのフィールドに「００００１２３８」が登録されている近接ユーザ情報６００−３が特定される。

設定部７２３−１が、特定した近接ユーザ情報６００−３のサーチ時刻のフィールドに登録されている時刻から現時刻までの時間が所定時間以上であるか否かを判断する。たとえば、所定時間を１５［分］とする。ここでは、該時間が３０［分］あるため、所定時間以上であると判断される。設定部７２３−１が、（３）近接ユーザ情報６００−３を近接ユーザＩＤデータベース２２０−１から削除する。また、図示していないが、該時間が所定時間以上でないと判断された場合、設定部７２３−１が、（３）近接ユーザ情報６００−３を近接ユーザＩＤデータベース２２０−１から削除しない。

送信部７２２−１が、（４）近接ユーザＩＤデータベース２２０−１の変化を検出する。送信部７２２−１が、（５）近接ユーザＩＤデータベース２２０−１の近接ユーザＩＤのフィールドに登録されているユーザＩＤと携帯端末２０１−１を所持する利用者のユーザＩＤと、を有する通知情報を、ネットワーク３１４を介してサーバ２００へ送信する。

図９は、実施の形態１にかかる通知情報例を示す説明図である。通知情報９００は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ ＭａｒｋＵｐ Ｌａｎｇｕａｇｅ）文書である。通知情報９００には、＜ｕｓｅｒｉｄ＞のタグから＜／ｕｓｅｒｉｄ＞のタグまでの間に、通知情報９００の通知元の携帯端末２０１−１を所持する利用者のユーザＩＤが記述されている。

通知情報９００には、＜ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグから＜／ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグまでの間に、通知元の携帯端末２０１−１の通信圏内にある１近接携帯端末を所持する利用者のユーザＩＤが記述されている。すなわち、通知情報９００では、通知元の携帯端末２０１−１を所持する利用者のユーザＩＤが「００００１２３４」であることを示している。通知情報９００では、通知元の携帯端末２０１−１の通信圏内にある近接携帯端末を所持する利用者のユーザＩＤが「００００１２３５」、「００００１２３６」、「００００１２３７」であることを示している。

図１０は、実施の形態１にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図である。具体的には、たとえば、受信部７０１が、携帯端末からの接続を受け付けると、携帯端末２０１−１から通知情報９００を受信する。受信部７０１が、通知情報９００に含まれる＜ｕｓｅｒｉｄ＞のタグと＜／ｕｓｅｒｉｄ＞のタグとの間に記述された番号を、携帯端末２０１−１を所持する利用者のユーザＩＤとして検出する。受信部７０１が、通知情報９００に含まれる＜ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグから＜／ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグまでの間に記述された番号を、携帯端末２０１−１の通信圏内にある近接携帯端末のユーザＩＤとして検出する。

つぎに、特定部７０２が、携帯端末２０１−１を所持する利用者のユーザＩＤに関連付けられた行き先を行き先データベース２１０から特定する。特定部７０２が、携帯端末２０１−２〜携帯端末２０１−４を所持するそれぞれの利用者のユーザＩＤに関連付けられた行き先を行き先データベース２１０から特定する。

具体的には、たとえば、特定部７０２が、行き先データベース２１０を参照し、ユーザＩＤのフィールドに「００００１２３４」が登録されている行き先情報を検索する。ここでは、行き先情報５００−１が検索される。具体的には、たとえば、特定部７０２が、検索した行き先情報５００−１の行き先のフィールドに登録された行き先を抽出する。これにより、（１）行き先情報５００−１から、携帯端末２０１−１を所持する利用者の行き先が特定される。すなわち、携帯端末２０１−１を所持する利用者の行き先は、「自席」である。

具体的には、たとえば、特定部７０２が、行き先データベース２１０を参照し、ユーザＩＤのフィールドに「００００１２３５」と、「００００１２３６」と、「００００１２３７」と、が登録されている行き先情報をそれぞれ検索する。ここでは、行き先情報５００−２と、行き先情報５００−３と、行き先情報５００−４が検索される。具体的には、たとえば、特定部７０２が、検索した行き先情報５００−２〜行き先情報５００−４の行き先のフィールドに登録されているそれぞれの行き先を抽出する。

これにより、（１）携帯端末２０１−１の通信圏内にある携帯端末２０１−２〜携帯端末２０１−４を所持する利用者のそれぞれの行き先が特定される。すなわち、携帯端末２０１−２を所持する利用者の行き先は、「会議室１」であり、携帯端末２０１−３を所持する利用者の行き先は、「会議室１」である。携帯端末２０１−４を所持する利用者の行き先は、「会議室２」である。

つぎに、決定部７０３が、携帯端末２０１−１を所持する利用者の行き先を、特定部７０２により特定された行き先情報の行き先のうち、最多の行き先に決定する。具体的には、たとえば、決定部７０３が、特定した行き先から、未選択の行き先を選択する。具体的には、たとえば、決定部７０３が、選択した行き先がテーブル１０００に登録されているか否かを判断する。具体的には、たとえば、決定部７０３が、（２）選択した行き先がテーブル１０００に登録されている場合、該選択した行き先に対応するカウント値をカウントアップする。具体的には、たとえば、決定部７０３が、（２）選択した行き先がテーブル１０００に登録されていない場合、該選択した行き先をテーブル１０００に登録し、カウント値を１に設定する。

テーブル１０００では、「自席」のカウント値が１であり、「会議室１」のカウント値が２であり、「会議室２」のカウント値が１である。具体的には、たとえば、決定部７０３が、携帯端末２０１−１を所持する利用者の行き先を、（３）カウント値が最も多い「会議室１」に決定する。

具体的には、たとえば、判定部７０４が、（４）特定部７０２により特定された行き先情報５００−１の行き先と、決定部７０３により決定された携帯端末２０１−１を所持する利用者の行き先と、が一致するか否かを判定する。決定された携帯端末２０１−１を所持する利用者の行き先は「会議室１」であり、行き先情報５００−１の行き先は「自席」である。そのため、決定された携帯端末２０１−１を所持する利用者の行き先と、行き先情報５００−１の行き先と、が一致しないと判定される。

出力部７０５は、決定部７０３による決定結果と携帯端末２０１−１を所持する利用者のユーザＩＤとを関連付けて出力する。具体的には、たとえば、出力部７０５が、（５）行き先データベース２１０に記憶された行き先情報５００−１の行き先を「会議室１」に更新する。

ここでは、決定された決定された携帯端末２０１−１を所持する利用者の行き先と、特定された行き先情報５００−１の行き先とが不一致の際に、行き先データベース２１０を更新している。これに限らず、たとえば、不一致であることを示す情報を行き先データベース２１０の行き先情報５００−１に関連付けてもよい。たとえば、いずれかの携帯端末が、行き先データベース２１０から、行き先情報５００−１の行き先を参照する際に、不一致であることを示す情報が関連付けられて取得されてもよい。

また、受付部７１１が、利用者の操作入力により、利用者の識別情報と利用者の行き先とを有する更新指示を受け付ける。利用者の操作入力による更新指示は、サーバ２００へ利用者が所持する携帯端末２０２−ｉ（ｉ≧１）や利用者が保有するＰＣなどから送信される。具体的には、たとえば、利用者としてＡさんを挙げると、Ａさんが所持する携帯端末２０１−１のキーボード４０５−１を用いて該携帯端末２０１−１へ更新指示を入力し、受付部７１１が、携帯端末２０１−１から該更新指示をネットワーク３１４を介して受信することにより受け付ける。具体的には、たとえば、利用者が所持するＰＣのキーボードを用いて該ＰＣへ更新指示を入力し、受付部７１１が、該ＰＣから該更新指示を受信することにより受け付けてもよい。

また、具体的には、たとえば、サーバ２００のマウス３１１やキーボード３１０を用いて利用者がサーバ２００へ更新指示を入力し、受付部７１１が該更新指示を受け付けてもよい。更新部７１２が、行き先データベース２２０を参照し、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の行き先を更新指示に含まれる利用者の行き先に更新する。

（実施の形態１にかかる携帯端末２０１−ｘによるユーザＩＤの交換処理手順）
図１１は、実施の形態１にかかる携帯端末２０１−ｘによるユーザＩＤの交換処理手順の一例を示すフローチャートである。まず、携帯端末２０１−ｘが、前回のサーチから一定時間経過したか否かを判断する（ステップＳ１１０１）。携帯端末２０１−ｘが、前回のサーチから一定時間経過していないと判断した場合（ステップＳ１１０１：Ｎｏ）、ステップＳ１１０１へ戻る。携帯端末２０１−ｘが、前回のサーチから一定時間経過したと判断した場合（ステップＳ１１０１：Ｙｅｓ）、近接する携帯端末をサーチする（ステップＳ１１０２）。近接する携帯端末とは、携帯端末２０１−ｘの通信圏内にある携帯端末である。

携帯端末２０１−ｘが、サーチした携帯端末とユーザＩＤを交換し（ステップＳ１１０３）、現時刻を取得し（ステップＳ１１０４）、交換したユーザＩＤのうち、未選択なユーザＩＤがあるか否かを判断する（ステップＳ１１０５）。携帯端末２０１−ｘが、交換したユーザＩＤのうち、未選択なユーザＩＤがあると判断した場合（ステップＳ１１０５：Ｙｅｓ）、未選択なユーザＩＤから１つのユーザＩＤを選択する（ステップＳ１１０６）。

携帯端末２０１−ｘが、選択したユーザＩＤが近接ユーザＩＤデータベース２２０−ｘに登録済みであるか否かを判断する（ステップＳ１１０７）。携帯端末２０１−ｘが、選択したユーザＩＤが近接ユーザＩＤデータベース２２０−ｘに登録済みであると判断した場合（ステップＳ１１０７：Ｙｅｓ）、近接ユーザＩＤデータベース２２０−ｘの選択したユーザＩＤを有する近接ユーザ情報のサーチ時刻を現時刻に更新し（ステップＳ１１０８）、ステップＳ１１０５に戻る。

携帯端末２０１−ｘが、選択したユーザＩＤが近接ユーザＩＤデータベース２２０−ｘに登録済みでないと判断した場合（ステップＳ１１０７：Ｎｏ）、選択したユーザＩＤと現時刻とを近接ユーザＩＤデータベース２２０−ｘに登録することにより、あらたに近接ユーザ情報を作成し（ステップＳ１１０９）、ステップＳ１１０５に戻る。

携帯端末２０１−ｘが、交換したユーザＩＤのうち、未選択なユーザＩＤがないと判断した場合（ステップＳ１１０５：Ｎｏ）、近接ユーザＩＤデータベース２２０−ｘを参照し、交換したユーザＩＤを除くユーザＩＤを有する近接ユーザ情報を特定する（ステップＳ１１１０）。携帯端末２０１−ｘが、交換したユーザＩＤを除くユーザＩＤを有する近接ユーザ情報を特定したか否かを判断する（ステップＳ１１１１）。

携帯端末２０１−ｘが、交換したユーザＩＤを除くユーザＩＤを有する近接ユーザ情報を特定したと判断した場合（ステップＳ１１１１：Ｙｅｓ）、ステップＳ１１１２へ移行する。携帯端末２０１−ｘが、特定した近接ユーザ情報のサーチ時刻から現時刻までの時間が所定時間以上であるか否かを判断する（ステップＳ１１１２）。

携帯端末２０１−ｘが、特定した近接ユーザ情報のサーチ時刻から現時刻までの時間が所定時間以上であると判断した場合（ステップＳ１１１２：Ｙｅｓ）、特定した近接ユーザ情報を近接ユーザＩＤデータベース２２０−ｘから削除し（ステップＳ１１１３）、ステップＳ１１０１へ戻る。

ステップＳ１１１１において、携帯端末２０１−ｘが、交換したユーザＩＤを除くユーザＩＤを有する近接ユーザ情報を特定しなかったと判断した場合（ステップＳ１１１１：Ｎｏ）、ステップＳ１１０１へ戻る。ステップＳ１１１２において、携帯端末２０１−ｘが、特定した近接ユーザ情報のサーチ時刻から現時刻までの時間が所定時間以上でないと判断した場合（ステップＳ１１１２：Ｎｏ）、ステップＳ１１０１へ戻る。

図１２は、実施の形態１にかかる携帯端末２０１−ｙによるユーザＩＤの交換処理手順の一例を示すフローチャートである。ここでは、携帯端末２０１−ｘがユーザＩＤの交換処理を開始した場合における携帯端末２０１−ｘの無線通信による通信圏内である他の携帯端末２０１−ｙのユーザＩＤの交換処理手順について説明する。携帯端末２０１−ｙが、受信部７２１−ｙにより、他の携帯端末からの接続を受け付けたか否かを判断する（ステップＳ１２０１）。携帯端末２０１−ｙが、他の携帯端末２０１−ｙからの接続を受け付けていないと判断した場合（ステップＳ１２０１：Ｎｏ）、ステップＳ１２０１へ戻る。

携帯端末２０１−ｙが、他の携帯端末からの接続を受け付けたと判断した場合（ステップＳ１２０１：Ｙｅｓ）、現時刻を取得し（ステップＳ１２０２）、送信部７２２−ｙと受信部７２１−ｙにより、接続元の他の携帯端末とユーザＩＤを交換する（ステップＳ１２０３）。携帯端末２０１−ｙが、設定部７２３−ｙにより、交換したユーザＩＤと現時刻を近接ユーザＩＤデータベース２２０−ｙに登録することにより、あらたな近接ユーザ情報を作成し（ステップＳ１２０４）、ステップＳ１２０１へ戻る。

図１３は、実施の形態１にかかる携帯端末２０１−ｘによる通知情報の送信処理手順の一例を示すフローチャートである。携帯端末２０１−ｘが、近接ユーザＩＤデータベース２２０−ｘの更新を検出したか否かを判断する（ステップＳ１３０１）。携帯端末２０１−ｘが、近接ユーザＩＤデータベース２２０−ｘの更新を検出していないと判断した場合（ステップＳ１３０１：Ｎｏ）、ステップＳ１３０１へ戻る。

携帯端末２０１−ｘが、近接ユーザＩＤデータベース２２０−ｘの更新を検出したと判断した場合（ステップＳ１３０１：Ｙｅｓ）、携帯端末２０１−ｘを所持する利用者のユーザＩＤと近接ユーザＩＤデータベース２２０−ｘに登録されているユーザＩＤとを含む通知情報９００をサーバ２００へ送信し（ステップＳ１３０２）、ステップＳ１３０１へ戻る。

（実施の形態１にかかるサーバ２００による行き先決定処理手順）
図１４は、実施の形態１にかかるサーバ２００による行き先決定処理手順の一例を示すフローチャートである。まず、サーバ２００が、携帯端末からの接続を受け付けたか否かを判断する（ステップＳ１４０１）。サーバ２００が、携帯端末からの接続を受け付けていないと判断した場合（ステップＳ１４０１：Ｎｏ）、ステップＳ１４０１へ戻る。サーバ２００が、携帯端末からの接続を受け付けたと判断した場合（ステップＳ１４０１：Ｙｅｓ）、携帯端末から、送信元の携帯端末を所持する利用者のユーザＩＤと送信元の携帯端末の通信圏内の近接携帯端末を所持する利用者のユーザＩＤとを含む通知情報９００を受信する（ステップＳ１４０２）。

つぎに、サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を特定し（ステップＳ１４０３）、近接携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を特定する（ステップＳ１４０４）。サーバ２００が、送信元の携帯端末を所持する利用者の行き先を、特定した行き先情報の行き先のうち、最多の行き先に決定する（ステップＳ１４０５）。

サーバ２００が、特定された送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なるか否かを判断する（ステップＳ１４０６）。サーバ２００が、特定された送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なると判断した場合（ステップＳ１４０６：Ｙｅｓ）、ステップＳ１４０７へ移行する。サーバ２００が、行き先データベース２１０に記憶された送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を決定した行き先に更新し（ステップＳ１４０７）、ステップＳ１４０１へ戻る。サーバ２００が、特定された送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が一致すると判断した場合（ステップＳ１４０６：Ｎｏ）、ステップＳ１４０１へ戻る。

（実施の形態１にかかるサーバ２００による更新処理手順）
図１５は、実施の形態１にかかるサーバ２００による更新処理手順を示すフローチャートである。まず、サーバ２００が、利用者の操作入力による更新指示を受け付けたか否かを判断し（ステップＳ１５０１）、利用者の操作入力による更新指示を受け付けていないと判断した場合（ステップＳ１５０１：Ｎｏ）、ステップＳ１５０１へ戻る。

サーバ２００が、利用者の操作入力による更新指示を受け付けたと判断した場合（ステップＳ１５０１：Ｙｅｓ）、行き先データベース２１０を参照し、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の行き先を更新指示に含まれる利用者の行き先に更新する（ステップＳ１５０２）。そして、サーバ２００が、ステップＳ１５０２のつぎにステップＳ１５０１へ戻る。

（実施の形態２）
つぎに、実施の形態２では、ある利用者の行き先を、ある利用者の行き先とある利用者の近距離にいる他の利用者の行き先のうち、更新日時が最新である利用者の行き先に決定する例を示す。実施の形態２では、実施の形態１と同一機能や同一情報については同一符号を付し、詳細な説明については省略する。

図１６は、実施の形態２にかかる行き先データベース２１０の一例を示す説明図である。行き先データベース２１０では、各利用者の行き先情報を有している。行き先データベース２１０は、ユーザＩＤ、氏名、行き先、更新日時のフィールドを有する。ユーザＩＤは、利用者を識別する識別情報である。ユーザＩＤとしては、たとえば、社員番号のように利用者によって異なる番号である。

氏名は、ユーザＩＤで識別される利用者の氏名である。氏名については、本行き先決定の処理では用いていないが、理解の容易化のために、行き先データベース２１０に示している。行き先は、各ユーザＩＤで識別される利用者の行き先である。行き先としては、たとえば、自席や休憩室や会議室の名称などが挙げられる。更新日時は、ユーザＩＤで識別される利用者が行き先を更新した日時である。

各フィールドに情報が設定されることで、行き先情報（たとえば、行き先情報１６００−１〜１６００−７）がレコードとして記憶されている。行き先データベース２１０は、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されていることとする。

ここで、携帯端末２０１−ｘによるユーザＩＤの交換処理については、実施の形態１で説明した携帯端末２０１−ｘによるユーザＩＤの交換処理と同一であるため、ここでは詳細な説明を省略する。

図１７は、実施の形態２にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図である。具体的には、たとえば、受信部７０１が、携帯端末２０１−１からの接続を受け付けると、携帯端末２０１−１から通知情報９００を受信する。受信部７０１が、通知情報９００に含まれる＜ｕｓｅｒｉｄ＞のタグと＜／ｕｓｅｒｉｄ＞のタグとの間に記述された番号を、携帯端末２０１−１を所持する利用者のユーザＩＤとして検出する。受信部７０１が、通知情報９００に含まれる＜ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグから＜／ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグまでの間に記述された番号を、携帯端末２０１−１の通信圏内にある近接携帯端末のユーザＩＤとして検出する。

つぎに、特定部７０２が、近接携帯端末を所持する利用者の行き先と携帯端末２０１−１を所持する利用者の行き先とのうち更新日時が最新の行き先を特定する。

具体的には、たとえば、特定部７０２が、行き先データベース２１０を参照し、ユーザＩＤのフィールドに「００００１２３４」が登録されている行き先情報を検索する。ここでは、行き先情報１６００−１が検索される。具体的には、たとえば、特定部７０２が、検索した行き先情報１６００−１の行き先のフィールドに登録された行き先と更新日時のフィールドに登録された日時を抽出する。

具体的には、たとえば、特定部７０２が、行き先データベース２１０を参照し、ユーザＩＤのフィールドに「００００１２３５」と、「００００１２３６」と、「００００１２３７」と、が登録されている行き先情報をそれぞれ検索する。ここでは、行き先情報１６００−２と、行き先情報１６００−３と、行き先情報１６００−４が検索される。具体的には、たとえば、特定部７０２が、検索した行き先情報１６００−２〜行き先情報１６００−４の行き先のフィールドに登録されているそれぞれの行き先と更新日時のフィールドに登録されたそれぞれの日時を抽出する。

具体的には、たとえば、特定部７０２が、（２）抽出した行き先のうち、日時が最新の日時である行き先を特定する。ここでは、「会議室１」が特定される。

決定部７０３が、携帯端末２０１−１を所持する利用者の行き先を、特定部７０２により特定された更新日時が最新の行き先に決定する。具体的には、たとえば、決定部７０３が、（２）所持する利用者の行き先を「会議室１」を携帯端末２０１−１に決定する。

具体的には、たとえば、判定部７０４が、（３）検索された行き先情報１６００−１の行き先と、決定部７０３により決定された携帯端末２０１−１を所持する利用者の行き先と、が一致するか否かを判定する。決定された携帯端末２０１−１を所持する利用者の行き先は「会議室１」であり、行き先情報１６００−１の行き先は「自席」である。そのため、決定された携帯端末２０１−１を所持する利用者の行き先と、行き先情報１６００−１の行き先と、が一致しないと判定される。

具体的には、たとえば、出力部７０５が、（４）行き先データベース２１０に記憶された行き先情報１６００−１の行き先を「会議室１」に更新する。

また、受付部７１１が、利用者の操作入力による更新指示を受け付ける。利用者の操作入力による更新指示は、サーバ２００へ利用者が所持する携帯端末２０１−ｉ（ｉ≧１）や利用者が保有するＰＣなどから送信されてもよいし、サーバ２００のマウス３１１やキーボード３１０を用いて利用者が直接入力してもよい。更新部７１２が、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の行き先を更新指示に含まれる利用者の行き先に更新する。更新部７１２が、現日時を取得し、行き先情報の更新日時を現日時に更新する。

（実施の形態２にかかるサーバ２００による行き先決定処理手順）
図１８は、実施の形態２にかかるサーバ２００による行き先決定処理手順の一例を示すフローチャートである。まず、サーバ２００が、携帯端末からの接続を受け付けたか否かを判断する（ステップＳ１８０１）。サーバ２００が、携帯端末からの接続を受け付けていないと判断した場合（ステップＳ１８０１：Ｎｏ）、ステップＳ１８０１へ戻る。サーバ２００が、携帯端末からの接続を受け付けたと判断した場合（ステップＳ１８０１：Ｙｅｓ）、送信元の携帯端末を所持する利用者のユーザＩＤと送信元の携帯端末の通信圏内の近接携帯端末を所持する利用者のユーザＩＤとを含む通知情報を受信する（ステップＳ１８０２）。

つぎに、サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と更新日時を特定する（ステップＳ１８０３）。サーバ２００が、近接携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と更新日時を特定する（ステップＳ１８０４）。

サーバ２００が、特定した行き先から、更新日時が最新である行き先を特定する（ステップＳ１８０５）。サーバ２００が、送信元の携帯端末を所持する利用者の行き先を、更新日時が最新である行き先に決定し（ステップＳ１８０６）、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なるか否かを判断する（ステップＳ１８０７）。

サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なると判断した場合（ステップＳ１８０７：Ｙｅｓ）、ステップＳ１８０８へ移行する。サーバ２００が、行き先データベース２１０に記憶された送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を決定した行き先に更新し（ステップＳ１８０８）、ステップＳ１８０１へ戻る。

サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が一致すると判断した場合（ステップＳ１８０７：Ｎｏ）、ステップＳ１８０１へ戻る。

（実施の形態２にかかるサーバ２００による更新処理手順）
図１９は、実施の形態２にかかるサーバ２００による更新処理手順を示すフローチャートである。まず、サーバ２００が、利用者の操作入力による更新指示を受け付けたか否かを判断し（ステップＳ１９０１）、利用者の操作入力による更新指示を受け付けていないと判断した場合（ステップＳ１９０１：Ｎｏ）、ステップＳ１９０１へ戻る。

サーバ２００が、利用者の操作入力による更新指示を受け付けたと判断した場合（ステップＳ１９０１：Ｙｅｓ）、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の行き先を更新指示に含まれる利用者の行き先に更新する（ステップＳ１９０２）。サーバ２００が、現日時を取得し（ステップＳ１９０３）、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の更新日時を取得した現日時に更新し（ステップＳ１９０４）、ステップＳ１９０１へ戻る。

（実施の形態３）
つぎに、実施の形態３では、ある利用者の行き先を、ある利用者が行き先を更新した更新回数と、ある利用者の近距離にいる他の利用者が行き先を更新した更新回数と、のうち、更新回数が最多の利用者の行き先に決定する例を示す。

実施の形態３では、実施の形態１や実施の形態２と同一機能や同一情報については同一符号を付し、詳細な説明については省略する。

図２０は、実施の形態３にかかる行き先データベース２１０の一例を示す説明図である。行き先データベース２１０では、各利用者の行き先情報を有している。行き先データベース２１０は、ユーザＩＤ、氏名、行き先、更新回数（本日）、更新回数（昨日）のフィールドを有する。ユーザＩＤは、利用者を識別する識別情報である。ユーザＩＤとしては、たとえば、社員番号のように利用者によって異なる番号である。

氏名は、ユーザＩＤで識別される利用者の氏名である。氏名については、本行き先決定の処理では用いていないが、理解の容易化のために、行き先データベース２１０に示している。行き先は、各ユーザＩＤで識別される利用者の行き先である。行き先としては、たとえば、自席や休憩室や会議室の名称などが挙げられる。更新回数（本日）は、ユーザＩＤで識別される利用者が更新した本日の更新回数である。更新回数（昨日）は、ユーザＩＤで識別される利用者が更新した昨日の更新回数である。

各フィールドに情報が設定されることで、行き先情報（たとえば、行き先情報２０００−１〜２０００−７）がレコードとして記憶されている。行き先データベース２１０は、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されていることとする。

ここで、携帯端末２０１−１によるユーザＩＤの交換処理については、実施の形態１で説明した携帯端末２０１−ｘによるユーザＩＤの交換処理と同一であるため、ここでは詳細な説明を省略する。

図２１は、実施の形態３にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図である。具体的には、たとえば、受信部７０１が、携帯端末からの接続を受け付けると、携帯端末２０１−１から通知情報９００を受信する。受信部７０１が、通知情報９００に含まれる＜ｕｓｅｒｉｄ＞のタグと＜／ｕｓｅｒｉｄ＞のタグとの間に記述された番号を、携帯端末２０１−１を所持する利用者のユーザＩＤとして検出する。受信部７０１が、通知情報９００に含まれる＜ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグから＜／ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグまでの間に記述された番号を、携帯端末２０１−１の通信圏内にある近接携帯端末のユーザＩＤとして検出する。

つぎに、特定部７０２が、行き先データベース２１０を参照して、携帯端末２０１−１を保持する利用者と、携帯端末２０１−１の通信圏内に近接携帯端末を保持する利用者とのうち、更新回数が最多の利用者の行き先を特定する。

具体的には、たとえば、特定部７０２が、行き先データベース２１０を参照し、ユーザＩＤのフィールドに「００００１２３４」が登録されている行き先情報を検索する。ここでは、行き先情報２０００−１が検索される。具体的には、たとえば、特定部７０２が、（１）検索した行き先情報２０００−１の行き先のフィールドに登録された行き先と更新回数（本日）のフィールドに登録された本日の更新回数と、更新回数（昨日）のフィールドに登録された昨日の更新回数と、を抽出する。

具体的には、たとえば、特定部７０２が、行き先データベース２１０を参照し、ユーザＩＤのフィールドに「００００１２３５」、「００００１２３６」、「００００１２３７」が登録されている行き先情報をそれぞれ検索する。ここでは、行き先情報２０００−２と、行き先情報２０００−３と、行き先情報２０００−４が検索される。

具体的には、たとえば、特定部７０２が、（１）検索した行き先情報２０００−２〜行き先情報２０００−４の行き先のフィールドに登録されているそれぞれの行き先を抽出する。具体的には、たとえば、特定部７０２が、（１）検索した行き先情報２０００−２〜行き先情報２０００−４の更新回数（本日）のフィールドに登録されたそれぞれの本日の更新回数を抽出する。具体的には、たとえば、特定部７０２が、（１）検索した行き先情報２０００−２〜行き先情報２０００−４の更新回数（昨日）のフィールドに登録されたそれぞれの昨日の更新回数を抽出する。

具体的には、たとえば、特定部７０２が、（２）利用者ごとに抽出した本日の更新回数と昨日の更新回数との合計値を算出する。具体的には、たとえば、特定部７０２が、算出した合計値が最多の利用者の行き先を特定する。テーブル２１００では、合計更新回数が最多である行き先が「会議室１」である。

決定部７０３が、携帯端末２０１−１を所持する利用者の行き先を、特定部７０２により特定された更新回数が最多の利用者の行き先に決定する。具体的には、たとえば、決定部７０３が、（２）携帯端末２０１−１を所持する利用者の行き先を「会議室１」に決定する。

具体的には、たとえば、判定部７０４が、（３）検索された行き先情報２０００−１の行き先と、決定部７０３により決定された携帯端末２０１−１を所持する利用者の行き先と、が一致するか否かを判定する。決定された携帯端末２０１−１を所持する利用者の行き先は「会議室１」であり、行き先情報２０００−１の行き先は「自席」である。そのため、決定された携帯端末２０１−１を所持する利用者の行き先と、行き先情報２０００−１の行き先と、が一致しないと判定される。

具体的には、たとえば、出力部７０５が、（４）行き先データベース２１０に記憶された行き先情報２０００−１の行き先を「会議室１」に更新する。

また、受付部７１１が、利用者の操作入力による更新指示を受け付ける。利用者の操作入力による更新指示は、サーバ２００へ利用者が所持する携帯端末２０１−ｉ（ｉ≧１）や利用者が保有するＰＣなどから送信される。更新部７１２が、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の行き先を更新指示に含まれる利用者の行き先に更新する。更新部７１２が、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の更新回数（本日）をカウントアップする。

また、受付部７１１が、日付の更新を受け付ける。たとえば、あらかじめサーバ２００のカレンダー機能等を用いて日付が変わると、受付部７１１に日付の更新が入力されることとする。更新部７１２が、各行き先情報の更新回数（昨日）を各行き先情報の更新回数（本日）に更新する。更新部７１２が、各行き先情報の更新回数（本日）に０を設定する。

また、実施の形態３では、本日の更新回数と昨日の更新回数を利用する例を示したが、これに限らず、たとえば、１年間分の利用者の行き先の更新回数をカウントし、該１年間分の更新回数を用いてもよい。これにより、各利用者の更新の頻度の傾向を判別することができる。

（実施の形態３にかかるサーバ２００による行き先決定処理手順）
図２２は、実施の形態３にかかるサーバ２００による行き先決定処理手順の一例を示すフローチャートである。まず、サーバ２００が、携帯端末からの接続を受け付けたか否かを判断する（ステップＳ２２０１）。サーバ２００が、携帯端末からの接続を受け付けていないと判断した場合（ステップＳ２２０１：Ｎｏ）、ステップＳ２２０１へ戻る。サーバ２００が、携帯端末からの接続を受け付けたと判断した場合（ステップＳ２２０１：Ｙｅｓ）、送信元の携帯端末を所持する利用者のユーザＩＤと送信元の携帯端末の通信圏内の近接携帯端末を所持する利用者のユーザＩＤとを含む通知情報を受信する（ステップＳ２２０２）。

つぎに、サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と本日の更新回数と昨日の更新回数とを特定する（ステップＳ２２０３）。つぎに、サーバ２００が、近接携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と本日の更新回数と昨日の更新回数とを特定する（ステップＳ２２０４）。サーバ２００が、利用者ごとに本日の更新回数と昨日の更新回数の合計値を算出し（ステップＳ２２０５）、合計値が最多の利用者の行き先を特定する（ステップＳ２２０６）。サーバ２００が、送信元の携帯端末を所持する利用者の行き先を特定した行き先に決定する（ステップＳ２２０７）。サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なるか否かを判断する（ステップＳ２２０８）。

サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なると判断した場合（ステップＳ２２０８：Ｙｅｓ）、ステップＳ２２０９へ移行する。サーバ２００が、行き先データベース２１０に記憶された送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を決定した行き先に更新し（ステップＳ２２０９）、ステップＳ２２０１へ戻る。

サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が一致すると判断した場合（ステップＳ２２０８：Ｎｏ）、ステップＳ２２０１へ戻る。

（実施の形態３にかかるサーバ２００による更新処理手順）
図２３は、実施の形態３にかかるサーバ２００による更新処理手順を示すフローチャートである。まず、サーバ２００が、利用者の操作入力による更新指示を受け付けたかまたは日付の変更を受け付けたか否かを判断し（ステップＳ２３０１）、利用者の操作入力による更新指示および日付の変更を受け付けていないと判断した場合（ステップＳ２３０１：Ｎｏ）、ステップＳ２３０１へ戻る。

サーバ２００が、利用者の操作入力による更新指示を受け付けたと判断した場合（ステップＳ２３０１：更新）、行き先データベース２１０を参照し、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の行き先を更新指示に含まれる利用者の行き先に更新する（ステップＳ２３０２）。サーバ２００が、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の本日の更新回数をカウントアップし（ステップＳ２３０３）、ステップＳ２３０１へ戻る。

サーバ２００が、日付の変更を受け付けたと判断した場合（ステップＳ２３０１：日付）、行き先情報の昨日の更新回数をそれぞれの行き先情報の本日の更新回数に設定する（ステップＳ２３０４）。サーバ２００が、行き先情報の本日の更新回数を０に設定し（ステップＳ２３０５）、ステップＳ２３０１へ戻る。

（実施の形態４）
つぎに、実施の形態４では、ある利用者の行き先を、ある利用者の近距離にいる他の利用者の所持する携帯端末とある利用者の所持する携帯端末との間の信号の受信強度が最も強い携帯端末を所持する利用者の行き先に決定する。実施の形態４では、実施の形態１〜実施の形態３と同一機能や同一情報については同一符号を付し、詳細な説明については省略する。

実施の形態４にかかる行き先データベース２１０は、図５で示した行き先データベース２１０と同一であるため詳細な説明を省略する。

図２４は、実施の形態４にかかる近接ユーザＩＤデータベース２２０−１の一例を示す説明図である。近接ユーザＩＤデータベース２２０−１は、近接ユーザＩＤ、サーチ時刻、受信信号強度のフィールドを有する。近接ユーザＩＤは、携帯端末２０１−１がＢｌｕｅｔｏｏｔｈ用のＩ／Ｆ４０３−１を用いて無線通信での通信圏内にある他の携帯端末を所持する利用者のユーザＩＤである。ここで、他の携帯端末を近接携帯端末と称する。携帯端末２０１−１を所持する利用者のユーザＩＤを携帯端末のユーザＩＤと称する。

サーチ時刻は、近接ユーザＩＤのフィールドに登録されたユーザＩＤで識別される利用者が所持する携帯端末２０１−１の近接携帯端末と該利用者が所持する携帯端末２０１−１とがユーザＩＤを交換した最新の時刻である。受信信号強度は、携帯端末２０１−１と近接携帯端末との間の信号の受信強度である。受信信号強度は、たとえば、ＲＳＳＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）値で示される。ＲＳＳＩ値は所定範囲内の数値である、ＲＳＳＩ値では、数値が大きい方が強いことを示す。各フィールドに情報が設定されることで、近接ユーザ情報（たとえば、近接ユーザ情報２４００−１〜近接ユーザ情報２４００−３）がレコードとして記憶されている。近接ユーザＩＤデータベース２２０−１は、ＲＡＭ４０７−１、フラッシュＲＯＭ４０８−１などの記憶装置に記憶されていることとする。

図２５は、実施の形態４にかかる携帯端末２０１―１と近接携帯端末とのユーザＩＤの交換例を示す説明図である。携帯端末２０１−１を所持する利用者のユーザＩＤと近接携帯端末を所持する利用者のユーザＩＤとの交換例については、実施の形態１で説明した例と同一であるため、図２５で示す（１）と（３）〜（６）との詳細な説明を省略する。

受信部７２１−１が、携帯端末２０１−２〜携帯端末２０１−４のそれぞれから該それぞれを所持する利用者のユーザＩＤを受信する。検出部７２４−１が、（２）該ユーザＩＤの受信時の信号に基づいて携帯端末２０１−２〜携帯端末２０１−４のそれぞれの受信信号強度を検出する。

図２６は、実施の形態４にかかる通知情報例を示す説明図である。通知情報２６００は、ＸＭＬ文書である。通知情報２６００には、＜ｕｓｅｒｉｄ＞のタグから＜／ｕｓｅｒｉｄ＞のタグまでの間に、通知情報２６００の通知元の携帯端末２０１−１を所持する利用者のユーザＩＤが記述されている。

通知情報２６００には、＜ｎｅａｒ＿ｕｓｅｒｉｄ ｒｓｓｉ＝数値＞のタグから＜／ｕｓｅｒｉｄ＞のタグまでの間に、通知元の携帯端末２０１−１の通信圏内にある１近接携帯端末を所持する利用者のユーザＩＤが記述されている。＜ｎｅａｒ＿ｕｓｅｒｉｄ ｒｓｓｉ＝数値＞のタグの数値の箇所にＲＳＳＩ値が設定される。すなわち、通知情報２６００では、通知元の携帯端末２０１−１を所持する利用者のユーザＩＤが「００００１２３４」であることを示している。通知情報２６００では、通知元の携帯端末２０１−１の通信圏内にある近接携帯端末を所持する利用者のユーザＩＤが「００００１２３５」、「００００１２３６」、「００００１２３７」であることを示している。

また、ユーザＩＤが「００００１２３５」で識別される利用者が所持する携帯端末のＲＳＳＩ値が２３であり、ユーザＩＤが「００００１２３６」で識別される利用者が所持する近接携帯端末のＲＳＳＩ値が１５である。ユーザＩＤが「００００１２３７」で識別される利用者が所持する携帯端末のＲＳＳＩ値が１である。

図２７は、実施の形態４にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図である。具体的には、たとえば、受信部７０１が、携帯端末からの接続を受け付けると、携帯端末２０１−１から通知情報１２０００を受信する。受信部７０１が、通知情報１２０００に含まれる＜ｕｓｅｒｉｄ＞のタグと＜／ｕｓｅｒｉｄ＞のタグとの間に記述された番号を、携帯端末２０１−１を所持する利用者のユーザＩＤとして検出する。受信部７０１が、通知情報１２０００に含まれる＜ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグから＜／ｎｅａｒ＿ｕｓｅｒｉｄ＞のタグまでの間に記述された番号を、携帯端末２０１−１の通信圏内にある近接携帯端末のユーザＩＤとして検出する。

つぎに、特定部７０２が、行き先データベース２１０を参照して、携帯端末２０１−１の通信圏内である携帯端末を保持する利用者のうち、受信信号強度が最大の利用者の行き先を特定する。

具体的には、たとえば、特定部７０２が、行き先データベース２１０を参照し、ユーザＩＤのフィールドに「００００１２３４」が登録されている行き先情報を検索する。ここでは、行き先情報５００−１が検索される。具体的には、たとえば、特定部７０２が、（１）検索した行き先情報５００−１の行き先のフィールドに登録された行き先を抽出する。

具体的には、たとえば、特定部７０２が、行き先データベース２１０を参照し、ユーザＩＤのフィールドに「００００１２３５」と、「００００１２３６」と、「００００１２３７」と、が登録されている行き先情報をそれぞれ検索する。ここでは、行き先情報５００−２と、行き先情報５００−３と、行き先情報５００−４が検索される。

具体的には、たとえば、特定部７０２が、（１）検索した行き先情報５００−２〜行き先情報５００−４の行き先のフィールドに登録されているそれぞれの行き先を抽出する。特定部７０２が、ＲＳＳＩ値を通知情報２０００から取得する。特定部７０２が、取得したＲＳＳＩ値と抽出した行き先とを各ユーザＩＤに基づいて関連付ける。テーブル２７００が、関連付けられた結果である。

具体的には、たとえば、特定部７０２が、（２）テーブル２７００から、受信信号強度が最大である行き先を特定する。テーブル２７００では、受信信号強度が最大である行き先が「会議室１」である。

決定部７０３が、携帯端末２０１−１を所持する利用者の行き先を特定部７０２により特定された受信信号強度が最大の携帯端末を所持する利用者の行き先に決定する。具体的には、たとえば、決定部７０３が、（２）携帯端末２０１−１を所持する利用者の行き先を「会議室１」に決定する。

具体的には、たとえば、判定部７０４が、（３）検索された行き先情報５００−１の行き先と、決定部７０３により決定された携帯端末２０１−１を所持する利用者の行き先と、が一致するか否かを判定する。決定された携帯端末２０１−１を所持する利用者の行き先は「会議室１」であり、行き先情報５００−１の行き先は「自席」である。そのため、決定された携帯端末２０１−１を所持する利用者の行き先と、行き先情報５００−１の行き先と、が一致しないと判定される。

具体的には、たとえば、出力部７０５が、（４）行き先データベース２１０に記憶された行き先情報５００−１の行き先を「会議室１」に更新する。

また、受付部７１１と更新部７１２による更新処理については、実施の形態１で説明した更新処理と同一であるため、詳細な説明を省略する。

（実施の形態４にかかる携帯端末２０１−ｘによるユーザＩＤの交換処理手順）
図２８は、実施の形態４にかかる携帯端末２０１−ｘによるユーザＩＤの交換処理手順の一例を示すフローチャートである。まず、携帯端末２０１−ｘが、前回のサーチから一定時間経過したか否かを判断する（ステップＳ２８０１）。携帯端末２０１−ｘが、前回のサーチから一定時間経過していないと判断した場合（ステップＳ２８０１：Ｎｏ）、ステップＳ２８０１へ戻る。携帯端末２０１−ｘが、前回のサーチから一定時間経過したと判断した場合（ステップＳ２８０１：Ｙｅｓ）、近接する携帯端末をサーチする（ステップＳ２８０２）。近接する携帯端末とは、携帯端末２０１−ｘの通信圏内にある携帯端末である。

携帯端末２０１−ｘが、サーチした携帯端末とユーザＩＤを交換し（ステップＳ２８０３）、サーチした携帯端末ごとに受信信号強度を受信する（ステップＳ２８０４）。携帯端末２０１−ｘが、現時刻を取得し（ステップＳ２８０５）、交換したユーザＩＤのうち、未選択なユーザＩＤがあるか否かを判断する（ステップＳ２８０６）。携帯端末２０１−ｘが、交換したユーザＩＤのうち、未選択なユーザＩＤがあると判断した場合（ステップＳ２８０６：Ｙｅｓ）、未選択なユーザＩＤから１つのユーザＩＤを選択し（ステップＳ２８０７）。

携帯端末２０１−ｘが、選択したユーザＩＤが近接ユーザＩＤデータベース２２０−ｘに登録済みであるか否かを判断する（ステップＳ２８０８）。携帯端末２０１−ｘが、選択したユーザＩＤが近接ユーザＩＤデータベース２２０−ｘに登録済みであると判断した場合（ステップＳ２８０８：Ｙｅｓ）、サーチ時刻を現時刻に更新し（ステップＳ２８０９）、強度を受信した受信信号強度に更新し（ステップＳ２８１０）、ステップＳ２８０６に戻る。

携帯端末２０１−ｘが、選択したユーザＩＤが近接ユーザＩＤデータベース２２０−ｘに登録済みでないと判断した場合（ステップＳ２８０８：Ｎｏ）、選択したユーザＩＤと現時刻と受信信号強度を近接ユーザＩＤデータベース２２０−ｘに登録し（ステップＳ２８１１）、ステップＳ２８０６に戻る。

携帯端末２０１−ｘが、交換したユーザＩＤのうち、未選択なユーザＩＤがないと判断した場合（ステップＳ２８０６：Ｎｏ）、交換したユーザＩＤを除くユーザＩＤを有する近接ユーザ情報を特定する（ステップＳ２８１２）。携帯端末２０１−ｘが、近接ユーザＩＤデータベースを参照し、交換したユーザＩＤを除くユーザＩＤを有する近接ユーザ情報を特定したか否かを判断する（ステップＳ２８１３）。

携帯端末２０１−ｘが交換したユーザＩＤを除くユーザＩＤを有する近接ユーザ情報を特定したと判断した場合（ステップＳ２８１３：Ｙｅｓ）、ステップＳ２８１４へ移行する。携帯端末２０１−ｘが、特定した近接ユーザ情報のサーチ時刻から現時刻までの時間が所定時間以上であるか否かを判断する（ステップＳ２８１４）。

携帯端末２０１−ｘが、特定した近接ユーザ情報のサーチ時刻から現時刻までの時間が所定時間以上であると判断した場合（ステップＳ２８１４：Ｙｅｓ）、特定した近接ユーザ情報を近接ユーザＩＤデータベース２２０−ｘから削除し（ステップＳ２８１５）、ステップＳ２８０１へ戻る。

ステップＳ２８１３において、交換したユーザＩＤを除くユーザＩＤを有する近接ユーザ情報を特定していないと判断した場合（ステップＳ２８１３：Ｎｏ）、ステップＳ２８０１へ戻る。ステップＳ２８１４において、携帯端末２０１−ｘが、特定した近接ユーザ情報のサーチ時刻から現時刻までの時間が所定時間以上でないと判断した場合（ステップＳ２８１４：Ｎｏ）、ステップＳ２８０１へ戻る。

（実施の形態４にかかるサーバ２００による行き先決定処理手順）
図２９は、実施の形態４にかかるサーバ２００による行き先決定処理手順の一例を示すフローチャートである。まず、サーバ２００が、携帯端末からの接続を受け付けたか否かを判断する（ステップＳ２９０１）。サーバ２００が、携帯端末からの接続を受け付けていないと判断した場合（ステップＳ２９０１：Ｎｏ）、ステップＳ２９０１へ戻る。サーバ２００が、携帯端末からの接続を受け付けたと判断した場合（ステップＳ２９０１：Ｙｅｓ）、ステップＳ２９０２へ移行する。サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤと送信元の携帯端末の通信圏内の近接携帯端末を所持する利用者のユーザＩＤと近接携帯端末を所持する利用者の受信信号強度と、を含む通知情報２６００を受信する（ステップＳ２９０２）。利用者の受信信号強度とは、利用者が所持する携帯端末と送信元の携帯端末との間の信号の受信強度である。

つぎに、サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する。行き先情報の行き先を特定する（ステップＳ２９０３）。つぎに、サーバ２００が、近接携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を特定する（ステップＳ２９０４）。サーバ２００が、近接携帯端末を保持する利用者のうち、受信信号強度が最大の利用者の行き先を特定し（ステップＳ２９０５）、送信元の携帯端末を所持する利用者の行き先を受信信号強度が最大の利用者の行き先に決定する（ステップＳ２９０６）。サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なるか否かを判断する（ステップＳ２９０７）。

サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なると判断した場合（ステップＳ２９０７：Ｙｅｓ）、ステップＳ２９０８へ移行する。サーバ２００が、行き先データベース２１０に記憶された送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を決定した行き先に更新し（ステップＳ２９０８）、ステップＳ２９０１へ戻る。

サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が一致すると判断した場合（ステップＳ２９０７：Ｎｏ）、ステップＳ２９０１へ戻る。

また、サーバ２００による更新処理手順については、実施の形態１で説明したサーバ２００による更新処理手順と同一であるため、詳細な説明を省略する。

（実施の形態５）
実施の形態５では、実施の形態１〜実施の形態４のある利用者の行き先の決定方法を組み合わせた例を示す。

図３０は、実施の形態５にかかる行き先データベース２１０の一例を示す説明図である。行き先データベース２１０では、各利用者の行き先情報を有している。行き先データベース２１０は、ユーザＩＤ、氏名、行き先、更新日時、更新回数（本日）、更新回数（昨日）のフィールドを有する。行き先データベース２１０では、各利用者の行き先情報を有している。ユーザＩＤは、利用者を識別する識別情報である。ユーザＩＤとしては、たとえば、社員番号のように利用者によって異なる番号である。

氏名は、ユーザＩＤで識別される利用者の氏名である。氏名については、本行き先決定の処理では用いていないが、理解の容易化のために、行き先データベース２１０に示している。行き先は、各ユーザＩＤで識別される利用者の行き先である。行き先としては、たとえば、自席や休憩室や会議室の名称などが挙げられる。更新日時は、ユーザＩＤで識別される利用者が行き先を更新した日時である。更新回数（本日）は、ユーザＩＤで識別される利用者が更新した本日の更新回数である。更新回数（昨日）は、ユーザＩＤで識別される利用者が更新した昨日の更新回数である。

各フィールドに情報が設定されることで、行き先情報（たとえば、行き先情報３０００−１〜行き先情報３０００−６）がレコードとして記憶されている。行き先データベース２１０は、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されていることとする。また、実施の形態５にかかる近接ユーザＩＤデータベースについては、図２４で示した近接ユーザＩＤデータベースと同一であるため、詳細な説明を省略する。

図３１は、実施の形態５にかかる携帯端末２０１―１と近接携帯端末とのユーザＩＤの交換例を示す説明図である。まず、たとえば、送信部７２２−１が、Ｂｌｕｅｔｏｏｔｈ用のＩ／Ｆ４０３−１を用いて、携帯端末２０１−１と通信可能か否かに関する情報を周辺の携帯端末に通知する。ここで、周辺の携帯端末とは、携帯端末２０１−１が有するＢｌｕｅｔｏｏｔｈ用のＩ／Ｆ４０３を用いて無線通信可能な通信圏内の携帯端末である。受信部７２１−２〜受信部７２１−４（携帯端末２０１−２〜携帯端末２０１−４）が、携帯端末２０１−１からの通信可否に関する情報を受信し、送信部７２２−２〜送信部７２２−４（携帯端末２０１−２〜携帯端末２０１−４）が、携帯端末２０１−１へ通信可能を示す情報を送信する。

受信部７２１−１が、携帯端末２０１−２〜携帯端末２０１−４から通信可能を示す情報を受信すると、送信部７２２−１と受信部７２１−１が、（１）携帯端末２０１−２〜携帯端末２０１−４のそれぞれとユーザＩＤを交換する。ここでは、ユーザＩＤの交換により、「００００１２３５」と、「００００１２３６」と、「００００１２３７」と、「００００１２３９」と、を取得する。

検出部７２４−１が、（２）受信部７２１−１により携帯端末２０１−２〜携帯端末２０１−４のそれぞれとユーザＩＤが受信される際に、携帯端末２０１−１と携帯端末２０１−２〜携帯端末２０１−４との間の信号のＲＳＳＩ値を検出する。設定部７２３−１が、現時刻を取得する。

設定部７２３−１が、近接ユーザＩＤデータベース２２０−１を参照し、「００００１２３５」と、「００００１２３６」と、「００００１２３７」と、「００００１２３９」と、のいずれかを含む近接ユーザ情報を特定する。ここでは、近接ユーザ情報２４００−１が「００００１２３５」を近接ユーザＩＤのフィールドに有し、近接ユーザ情報２４００−２が「００００１２３６」を近接ユーザＩＤのフィールドに有している。

設定部７２３−１が、（３）近接ユーザ情報２４００−１のサーチ時刻のフィールドの時刻と、近接ユーザ情報２４００−２のサーチ時刻のフィールドの時刻と、をそれぞれ現時刻に更新する。ここで、現時刻を１６：００とする。設定部７２３−１が、（２）近接ユーザ情報２４００−１の受信信号強度のフィールドの値を、検出部７２４−１により検出された携帯端末２０１−１と携帯端末２０１−２との間の信号のＲＳＳＩ値に更新する。設定部７２３−１が、（３）近接ユーザ情報２４００−２の受信信号強度のフィールドの値を、検出部７２４−１により検出された携帯端末２０１−１と携帯端末２０１−３との間の信号のＲＳＳＩ値に更新する。

「００００１２３７」を含む近接ユーザ情報が近接ユーザＩＤデータベース２２０−１から特定されないため、設定部７２３−１が、（３）近接ユーザＩＤデータベース２２０−１のユーザＩＤのフィールドに「００００１２３７」を設定する。設定部７２３−１が、近接ユーザＩＤデータベース２２０−１のサーチ時刻のフィールドに現時刻を設定する。設定部７２３−１が、近接ユーザＩＤデータベース２２０−１の受信信号強度のフィールドの値に、検出部７２４−１により検出された携帯端末２０１−１と携帯端末２０１−４との間の信号のＲＳＳＩ値を設定し、新たな近接ユーザ情報２４００−４を作成する。

「００００１２３９」を含む近接ユーザ情報が近接ユーザＩＤデータベース２２０−１から特定されないため、設定部７２３−１が、（３）近接ユーザＩＤデータベース２２０−１のユーザＩＤのフィールドに「００００１２３９」を登録する。設定部７２３−１が、近接ユーザＩＤデータベース２２０−１のサーチ時刻のフィールドに現時刻を設定し、新たな近接ユーザ情報２４００−５を作成する。設定部７２３−１が、近接ユーザＩＤデータベース２２０−１の受信信号強度のフィールドの値に、検出部７２４−１により検出された携帯端末２０１−１と携帯端末２０１−６との間の信号のＲＳＳＩ値を設定し、新たな近接ユーザ情報２４００−５を作成する。

たとえば、設定部７２３−１が、近接ユーザＩＤデータベース２２０−１を参照し、交換したユーザＩＤ以外のユーザＩＤを含む近接ユーザ情報を特定する。ここでは、たとえば、近接ユーザＩＤのフィールドに「００００１２３８」が登録されている近接ユーザ情報２４００−３が特定される。

たとえば、設定部７２３−１が、特定した近接ユーザ情報２４００−３のサーチ時刻のフィールドに登録されている時刻から現時刻までの時間が所定時間以上であるか否かを判断する。たとえば、所定時間を１５［分］とする。ここでは、該時間が３０［分］であるため、所定時間以上であると判断される。設定部７２３−１が、（４）近接ユーザ情報２４００−３を近接ユーザＩＤデータベース２２０−１から削除する。また、図示していないが、該時間が所定時間以上でないと判断された場合、設定部７２３−１が、（４）近接ユーザ情報６００−３を近接ユーザＩＤデータベース２２０−１から削除しない。

送信部７２２−１が、（５）近接ユーザＩＤデータベース２２０−１の変化を検出する。送信部７２２−１が、（６）近接ユーザＩＤデータベース２２０−１の近接ユーザＩＤのフィールドに登録されているユーザＩＤと携帯端末２０１−１を所持する利用者のユーザＩＤと、を有する通知情報を、ネットワーク３１４を介してサーバ２００へ送信する。

図３２は、実施の形態５にかかる通知情報例を示す説明図である。通知情報３２００は、ＸＭＬ文書である。通知情報３２００には、＜ｕｓｅｒｉｄ＞のタグから＜／ｕｓｅｒｉｄ＞のタグまでの間に、通知情報３２００の通知元の携帯端末２０１−１を所持する利用者のユーザＩＤが記述されている。

通知情報３２００には、＜ｎｅａｒ＿ｕｓｅｒｉｄ ｒｓｓｉ＝数値＞のタグから＜／ｕｓｅｒｉｄ＞のタグまでの間に、通知元の携帯端末２０１−１の通信圏内にある１近接携帯端末を所持する利用者のユーザＩＤが記述されている。＜ｎｅａｒ＿ｕｓｅｒｉｄ ｒｓｓｉ＝数値＞のタグの数値の箇所にＲＳＳＩ値が設定される。すなわち、通知情報３２００では、通知元の携帯端末２０１−１を所持する利用者のユーザＩＤが「００００１２３４」であることを示している。通知情報３２００では、通知元の携帯端末２０１−１の通信圏内にある近接携帯端末を所持する利用者のユーザＩＤが「００００１２３５」、「００００１２３６」、「００００１２３７」、「００００１２３９」であることを示している。

また、ユーザＩＤが「００００１２３５」で識別される利用者が所持する携帯端末のＲＳＳＩ値が２３であり、ユーザＩＤが「００００１２３６」で識別される利用者が所持する近接携帯端末のＲＳＳＩ値が１５である。ユーザＩＤが「００００１２３７」で識別される利用者が所持する携帯端末のＲＳＳＩ値が１であり、ユーザＩＤが「００００１２３９」で識別される利用者が所持する携帯端末のＲＳＳＩ値が５である。

図３３は、実施の形態５にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図（その１）である。まず、受信部７０１と特定部７０２を用いて実施の形態１で説明した決定方法を用いて、近接携帯端末を所持する利用者の行き先のうち、最多の行き先を特定する。

図３３で示す（１）、（２）の処理については、実施の形態１で説明した処理と同一であるため、詳細な説明を省略する。テーブル３３００では、「自席」のカウント値が１であり、「会議室１」のカウント値が２であり、「会議室２」のカウント値が２である。よって、「会議室１」と「会議室２」とのカウント値が同一値であるため、最多の行き先が一意に特定されない。

図３４は、実施の形態５にかかる携帯端末２０１−１を所持する利用者の行き先の決定例を示す説明図（その２）である。具体的には、たとえば、特定部７０２が、行き先データベース２１０を参照し、行き先情報３０００−１〜行き先情報３０００−４と行き先情報３０００−６のうち、行き先のフィールドが「会議室１」または「会議室２」である行き先情報を特定する。ここでは、行き先情報３０００−２〜行き先情報３０００−４と行き先情報３０００−６が特定される。

具体的には、たとえば、特定部７０２が、（１）特定した行き先情報の更新日時のフィールドに登録されている更新日時を抽出する。特定部７０２が、（２）抽出した更新日時が古い順に特定し、古い順に０〜３までのポイントを付与する。

具体的には、たとえば、特定部７０２が、（３）特定した行き先情報の更新回数（本日）のフィールドに登録されている本日の更新回数を抽出する。具体的には、たとえば、特定部７０２が、（３）特定した行き先情報の更新回数（昨日）のフィールドに登録されている昨日の更新回数を抽出する。具体的には、たとえば、特定部７０２が、抽出した本日の更新回数と昨日の更新回数との合計値を利用者ごとに算出する。特定部７０２が、（４）算出した合計値が少ない順に特定し、少ない順に０〜３までのポイントを付与する。

具体的には、たとえば、特定部７０２が、（５）特定した行き先情報のユーザＩＤのフィールドに登録されているユーザＩＤに基づいて、通知情報３２００のＲＳＳＩ値と特定した行き先情報に含まれる行き先とを関連付けて抽出する。具体的には、たとえば、特定部７０２が、（６）受信信号強度が弱い順に特定する。

具体的には、たとえば、特定部７０２が、受信信号強度が第１所定値以下であれば、０ポイントを付与する。具体的には、たとえば、特定部７０２が、受信信号強度が第２所定値以上であれば、２ポイントを付与する。具体的には、たとえば、特定部７０２が、受信信号強度が第１所定値より大きく、第２所定値未満であれば、１ポイントを付与する。たとえば、第１所定値が４であり、第２所定値が１４である。

テーブル３４０１〜テーブル３４０３では、行き先ごとにスコアが登録されている。具体的には、たとえば、特定部７０２が、同一行き先ごとに合計スコアを算出することにより、同一行き先ごとにスコアを集約する。テーブル３４０４では、同一行き先ごとに合計スコアが登録されている。具体的には、たとえば、特定部７０２が、（８）合計スコアが最多の行き先を特定する。具体的には、たとえば、決定部７０３が、（９）携帯端末２０１−１を所持する利用者の行き先を特定した行き先に決定する。

具体的には、たとえば、判定部７０４が、（１０）特定部７０２により特定された行き先情報３０００−１の行き先と、決定部７０３により決定された携帯端末２０１−１を所持する利用者の行き先と、が一致するか否かを判定する。決定された携帯端末２０１−１を所持する利用者の行き先は「会議室１」であり、行き先情報３０００−１の行き先は「自席」である。そのため、決定された携帯端末２０１−１を所持する利用者の行き先と、行き先情報３０００−１の行き先と、が一致しないと判定される。

出力部７０５は、決定部７０３による決定結果と携帯端末２０１−１を所持する利用者のユーザＩＤとを関連付けて出力する。具体的には、たとえば、出力部７０５が、（５）行き先データベース２１０に記憶された行き先情報３０００−１の行き先を「会議室１」に更新する。

上述した例では、最多の行き先が複数ある場合に、他の確度を基準にポイントを付与して、携帯端末２０１−１を所持する利用者の行き先を決定している。これに限らず、更新日時が最新の利用者が複数いる場合に、他の確度を基準にポイントを付与して、携帯端末２０１−１を所持する利用者の行き先を決定してもよい。

また、更新回数が最多の利用者が複数いる場合に、他の確度を基準にポイントを付与して、携帯端末２０１−１を所持する利用者の行き先を決定してもよい。また、受信信号強度が最大の利用者が複数いる場合に、他の確度を基準にポイントを付与して、携帯端末２０１−１を所持する利用者の行き先を決定してもよい。

実施の形態１〜実施の形態４では、携帯端末２０１−１を所持する利用者の行き先を決定するための確度がそれぞれ異なる。よって、どの確度が最良かは一意でないため、どのように確度を組み合わせてもよいこととする。

また、実施の形態５にかかる携帯端末２０１−ｘによるユーザＩＤの交換処理手順については、実施の形態４にかかる携帯端末２０１−ｘによるユーザＩＤの交換処理手順と同一手順であるため、詳細な説明を省略する。

（実施の形態５にかかるサーバ２００による行き先決定処理手順）
図３５〜図３７は、実施の形態５にかかるサーバ２００による行き先決定処理手順を示すフローチャートである。まず、サーバ２００が、携帯端末からの接続を受け付けたか否かを判断する（ステップＳ３５０１）。サーバ２００が、携帯端末からの接続を受け付けていないと判断した場合（ステップＳ３５０１：Ｎｏ）、ステップＳ３５０１へ戻る。

サーバ２００が、携帯端末からの接続を受け付けたと判断した場合（ステップＳ３５０１：Ｙｅｓ）、ステップＳ３５０２へ移行する。サーバ２００が、携帯端末から、送信元の携帯端末を所持する利用者のユーザＩＤと、送信元の携帯端末の通信圏内の近接携帯端末を所持する利用者のユーザＩＤと、近接携帯端末を所持する利用者の受信信号強度と、を含む通知情報９００を受信する（ステップＳ３５０２）。

つぎに、サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を特定し（ステップＳ３５０３）、近接携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を特定する（ステップＳ３５０４）。サーバ２００が、特定した行き先情報の行き先のうち、最多の行き先を特定する（ステップＳ３５０５）。

サーバ２００が、最多の行き先が複数あるか否かを判断する（ステップＳ３５０６）。サーバ２００が、最多の行き先が複数ないと判断した場合（ステップＳ３５０６：Ｎｏ）、送信元の携帯端末を所持する利用者の行き先を特定した行き先に決定する（ステップＳ３５０７）。

サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なるか否かを判断する（ステップＳ３５０８）。サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が異なると判断した場合（ステップＳ３５０８：Ｙｅｓ）、ステップＳ３５０９へ移行する。

サーバ２００が、行き先データベース２１０に記憶された送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先を決定した行き先に更新し（ステップＳ３５０９）、ステップＳ３５０１へ戻る。サーバ２００が、送信元の携帯端末を所持する利用者のユーザＩＤを有する行き先情報の行き先と、決定した行き先と、が一致すると判断した場合（ステップＳ３５０８：Ｎｏ）、ステップＳ３５０１へ戻る。

サーバ２００が、最多の行き先が複数あると判断した場合（ステップＳ３５０６：Ｙｅｓ）、送信元の携帯端末の行き先情報と、近接携帯端末の行き先情報とから、特定した最多の行き先を有する行き先情報を特定する（ステップＳ３５１０）。送信元の携帯端末の行き先情報とは、送信元の携帯端末を所持する利用者のユーザＩＤを含む行き先情報であり、近接携帯端末の行き先情報とは、近接携帯端末を所持する利用者のユーザＩＤを含む行き先情報である。

サーバ２００が、特定した最多の行き先を有する行き先情報の更新日時を抽出し（ステップＳ３５１１）、抽出した更新日時が古い順に利用者の行き先にポイントを付与する（ステップＳ３５１２）。

サーバ２００が、送信元の携帯端末の行き先情報と、近接携帯端末の行き先情報とから、特定した最多の行き先を有する行き先情報の本日の更新回数と昨日の更新回数を抽出する（ステップＳ３５１３）。

サーバ２００が、抽出した行き先情報ごとに本日の更新回数と昨日の更新回数の合計値を算出し（ステップＳ３５１４）、算出した合計値が小さい順に利用者の行き先にポイントを付与する（ステップＳ３５１５）。

サーバ２００が、特定した最多の行き先を有する行き先情報のユーザＩＤのうち、未選択なユーザＩＤがあるか否かを判断する（ステップＳ３５１６）。サーバ２００が、特定した最多の行き先を有する行き先情報のユーザＩＤのうち、未選択なユーザＩＤがあると判断した場合（ステップＳ３５１６：Ｙｅｓ）、選択したユーザＩＤの受信信号強度を通知情報から特定する（ステップＳ３５１７）。

サーバ２００が、特定した受信信号強度が第１所定値以下であるか否かを判断する（ステップＳ３５１８）。サーバ２００が、特定した受信信号強度が第１所定値以下であると判断した場合（ステップＳ３５１８：Ｙｅｓ）、選択したユーザＩＤを有する行き先情報の行き先に第１ポイントを付与し（ステップＳ３５１９）、ステップＳ３５１６へ戻る。たとえば、第１ポイントが０ポイントである。

サーバ２００が、特定した受信信号強度が第１所定値以下でないと判断した場合（ステップＳ３５１８：Ｎｏ）、特定した受信信号強度が第２所定値以上であるか否かを判断する（ステップＳ３５２０）。サーバ２００が、特定した受信信号強度が第２所定値以上でないと判断した場合（ステップＳ３５２０：Ｎｏ）、選択したユーザＩＤを有する行き先情報の行き先に第２ポイントを付与し（ステップＳ３５２１）、ステップＳ３５１６へ戻る。

サーバ２００が、特定した受信信号強度が第２所定値以上であると判断した場合（ステップＳ３５２０：Ｙｅｓ）、選択したユーザＩＤを有する行き先情報の行き先に第３ポイントを付与し（ステップＳ３５２２）、ステップＳ３５１６へ戻る。

ステップＳ３５１６において、サーバ２００が、特定した最多の行き先を有する行き先情報のユーザＩＤのうち、未選択なユーザＩＤがないと判断した場合（ステップＳ３５１６：Ｎｏ）、同一行き先ごとにポイントを集約する（ステップＳ３５２３）。サーバ２００が、ポイント数が最多の行き先を特定し（ステップＳ３５２４）、ステップＳ３５０７へ移行する。

（実施の形態５にかかるサーバ２００による更新処理手順）
図３８は、実施の形態３にかかるサーバ２００による更新処理手順を示すフローチャートである。まず、サーバ２００が、利用者の操作入力による更新指示を受け付けたかまたは日付の変更を受け付けたか否かを判断し（ステップＳ３８０１）、利用者の操作入力による更新指示および日付の変更を受け付けていないと判断した場合（ステップＳ３８０１：Ｎｏ）、ステップＳ３８０１へ戻る。

サーバ２００が、利用者の操作入力による更新指示を受け付けたと判断した場合（ステップＳ３８０１：更新）、行き先データベース２１０を参照し、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の行き先を更新指示に含まれる利用者の行き先に更新する（ステップＳ３８０２）。サーバ２００が、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の本日の更新回数をカウントアップする（ステップＳ３８０３）。サーバ２００が、現日時を取得し（ステップＳ３８０４）、更新指示に含まれる利用者のユーザＩＤを含む行き先情報の更新日時を取得した現日時に更新し（ステップＳ３８０５）、ステップＳ３８０１へ戻る。

ステップＳ３８０１において、サーバ２００が、日付の変更を受け付けたと判断した場合（ステップＳ３８０１：日付）、行き先情報の昨日の更新回数をそれぞれの行き先情報の本日の更新回数に設定する（ステップＳ３８０６）。サーバ２００が、行き先情報の本日の更新回数を０に設定し（ステップＳ３８０７）、ステップＳ３８０１へ戻る。

実施の形態１〜５では、携帯端末２０１−１がサーバ２００へ行き先の決定を依頼しているが、複数の携帯端末が同時にサーバ２００へ行き先の決定依頼を行った場合、サーバ２００は、同時に行き先決定処理を行わなくてもよい。

以上実施の形態１〜５で説明したように、行き先決定プログラム、および行き先決定方法によれば、利用者が所持する第１の携帯端末の近距離にいる第２の携帯端末の所持者の行き先に応じて利用者の居場所を推定することができる。これにより、利用者が行き先掲示板への更新を忘れたとしても、行き先掲示板の行き先の更新後に従業員が該行き先と異なる場所に向かったとしても、利用者の行き先を特定することができる。さらに、特定した利用者の行き先を行き先掲示板に反映することで、行き先掲示板上の利用者の行き先を自動更新することができる。また、ＰＣやＲＦＩＤなどの高価な機器の設置することなく、利用者の居場所を推定するため、費用を抑制することができる。また、利用者の行き先として場所名が特定されるため、各ＰＣやＲＦＩＤなどの機器と場所名との対応付ける処理や、緯度・経度などの情報と場所名を対応付ける処理が不要となる。

また、行き先掲示板上の利用者の行き先と、第２の携帯端末の所持者の行き先とに、応じて利用者の居場所を推定する。これにより、利用者自身の更新にも信頼をおいて、利用者の行き先を自動更新することができる。

また、実施の形態１で説明したように、利用者の行き先と、第２の携帯端末の所持者の行き先のうち、最多の行き先を利用者の居場所として推定する。複数のユーザの中から最も多く設定されている行き先を高く信頼することができ、利用者の行き先を自動更新することができる。

また、実施の形態２で説明したように、利用者が行き先を更新した更新日時と、第２の携帯端末の所持者が行き先を更新した更新日時と、のうち、最新の更新日時である行き先を利用者の居場所として推定する。更新日時が新しく信頼性の高い行き先に応じて、利用者の行き先を自動更新することができる。

また、実施の形態３で説明したように、利用者の行き先掲示板の更新頻度と、第２の端末の所持者の行き先掲示板の更新頻度とに、応じて、利用者の居場所を推定する。更新頻度が高い利用者は行き先掲示板の更新を確実に行う可能性があり、信頼性の高い行き先により、利用者の行き先を自動更新することができる。

また、実施の形態４で説明したように、第１の携帯端末と第２の携帯端末との間の受信信号強度に応じて、利用者の居場所を推定する。たとえば、通信圏内であっても、利用者と異なる部屋にいる他の利用者の受信信号強度は弱くなる可能性があるため、誤った行き先によって、利用者の行き先が自動更新されるのを防止することができる。

また、利用者の入力操作により、行き先掲示板の行き先を更新することにより、行き先掲示板に登録された利用者の行き先の精度を向上させることができる。

なお、本実施の形態で説明した行き先決定方法は、あらかじめ用意された行き先決定プログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本行き先決定プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本行き先決定プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）複数の利用者の各々の利用者の識別情報と前記各々の利用者の行き先とを関連付けて記憶するデータベースにアクセス可能なコンピュータに、
前記複数の利用者のうちいずれかの利用者が所持する第１の携帯端末から、前記いずれかの利用者の識別情報と、前記第１の携帯端末の通信圏内にある１以上の第２の携帯端末から受信された前記第２の携帯端末を所持する他の利用者の識別情報とを受信する受信処理と、
前記データベースを参照して、前記受信処理により受信された前記他の利用者の識別情報と関連付けて記憶されている前記他の利用者の行き先を特定する特定処理と、
前記特定処理により特定された前記他の利用者の行き先に基づいて、前記いずれかの利用者の行き先を決定する決定処理と、
前記決定処理による決定結果と前記受信処理により受信された前記いずれかの利用者の識別情報とを関連付けて出力する出力処理と、
を実行させることを特徴とする行き先決定プログラム。

（付記２）前記特定処理は、
さらに、前記データベースを参照して、前記いずれかの利用者の識別情報と関連付けて記憶されている前記いずれかの利用者の行き先を特定し、
前記決定処理は、
前記特定処理により特定された前記他の利用者の行き先と前記いずれかの利用者の行き先とに基づいて、前記いずれかの利用者の行き先を決定することを特徴とする付記１に記載の行き先決定プログラム。

（付記３）前記決定処理は、
前記いずれかの利用者の行き先を、前記特定処理により特定された前記他の利用者の行き先と前記いずれかの利用者の行き先とのうち最多の行き先に決定することを特徴とする付記２に記載の行き先決定プログラム。

（付記４）前記データベースは、前記各々の利用者の識別情報と前記各々の利用者の行き先と前記各々の利用者の行き先が更新された更新日時とを関連付けて記憶しており、
前記特定処理は、
前記データベースを参照して、前記他の利用者の行き先と前記いずれかの利用者の行き先とのうち更新日時が最新の行き先を特定し、
前記決定処理は、
前記いずれかの利用者の行き先を、前記特定処理により特定された前記更新日時が最新の行き先に決定することを特徴とする付記２または３に記載の行き先決定プログラム。

（付記５）前記データベースは、前記各々の利用者の識別情報と前記各々の利用者の行き先と前記各々の利用者が行き先を更新した更新回数とを関連付けて記憶しており、
前記特定処理は、
前記データベースを参照して、前記他の利用者と前記いずれかの利用者とのうち更新回数が最多の利用者の行き先を特定し、
前記決定処理は、
前記いずれかの利用者の行き先を、前記特定処理により特定された前記更新回数が最多の利用者の行き先に決定することを特徴とする付記２〜４のいずれか一つに記載の行き先決定プログラム。

（付記６）前記受信処理は、
さらに、前記第１の携帯端末と前記第２の携帯端末との間の信号の受信強度を前記第１の携帯端末から受信し、
前記特定処理は、
前記データベースを参照して、前記他の利用者のうち前記受信処理により受信された信号の受信強度が最大の利用者の行き先を特定し、
前記決定処理は、
前記いずれかの利用者の行き先を、前記特定処理により特定された前記受信強度が最大の利用者の行き先に決定することを特徴とする付記１〜５のいずれか一つに記載の行き先決定プログラム。

（付記７）前記出力処理は、
前記データベースに記憶されている前記いずれかの利用者の行き先を、前記決定処理により決定された前記いずれかの利用者の行き先に更新することを特徴とする付記１〜６のいずれか一つに記載の行き先決定プログラム。

（付記８）前記コンピュータに、
前記いずれかの利用者の操作入力により、前記いずれかの利用者の識別情報と前記いずれかの利用者の行き先を受け付ける受付処理と、
前記受付処理により受け付けられた前記いずれかの利用者の識別情報と関連付けて前記データベースに記憶されている前記いずれかの利用者の行き先を、前記受付処理により受け付けられた前記いずれかの利用者の行き先に更新する更新処理と、
を実行させることを特徴とする付記１〜７のいずれか一つに記載の行き先決定プログラム。

（付記９）前記コンピュータに、
前記特定処理により特定された前記いずれかの利用者の行き先と、前記決定処理により決定された前記いずれかの利用者の行き先と、が一致するか否かを判定する判定処理を実行させ、
前記出力処理は、
前記判定処理により不一致であると判定された場合、前記不一致を示す情報を前記いずれかの利用者の識別情報に関連付けて出力することを特徴とする付記１〜８のいずれか一つに記載の行き先決定プログラム。

（付記１０）複数の利用者の各々の利用者の識別情報と前記各々の利用者の行き先とを関連付けて記憶するデータベースにアクセス可能なコンピュータが、
前記複数の利用者のうちいずれかの利用者が所持する第１の携帯端末から、前記いずれかの利用者の識別情報と、前記第１の携帯端末の通信圏内にある１以上の第２の携帯端末から受信された前記第２の携帯端末を所持する他の利用者の識別情報とを受信する受信処理と、
前記データベースを参照して、前記受信処理により受信された前記他の利用者の識別情報と関連付けて記憶されている前記他の利用者の行き先を特定する特定処理と、
前記特定処理により特定された前記他の利用者の行き先に基づいて、前記いずれかの利用者の行き先を決定する決定処理と、
前記決定処理による決定結果と前記受信処理により受信された前記いずれかの利用者の識別情報とを関連付けて出力する出力処理と、
を実行することを特徴とする行き先決定方法。

２００ サーバ
２０１−１〜２０１−６ 携帯端末
２１０ 行き先データベース

Claims (9)

1. 複数の利用者の各々の利用者の識別情報と前記各々の利用者の行き先とを関連付けて記憶するデータベースにアクセス可能なコンピュータに、
   前記複数の利用者のうちいずれかの利用者が所持する第１の携帯端末から、前記いずれかの利用者の識別情報と、前記第１の携帯端末の通信圏内にある１以上の第２の携帯端末から受信された前記第２の携帯端末を所持する他の利用者の識別情報とを受信する受信処理と、
   前記データベースを参照して、前記受信処理により受信された前記他の利用者の識別情報と関連付けて記憶されている前記他の利用者の行き先を特定する特定処理と、
   前記特定処理により特定された前記他の利用者の行き先に基づいて、前記いずれかの利用者の現在の行き先を決定する決定処理と、
   前記決定処理による決定結果と前記受信処理により受信された前記いずれかの利用者の識別情報とを関連付けて出力する出力処理と、
   を実行させることを特徴とする行き先決定プログラム。
2. 前記特定処理は、
   さらに、前記データベースを参照して、前記いずれかの利用者の識別情報と関連付けて記憶されている前記いずれかの利用者の行き先を特定し、
   前記決定処理は、
   前記特定処理により特定された前記他の利用者の行き先と前記いずれかの利用者の行き先とに基づいて、前記いずれかの利用者の現在の行き先を決定することを特徴とする請求項１に記載の行き先決定プログラム。
3. 前記決定処理は、
   前記いずれかの利用者の現在の行き先を、前記特定処理により特定された前記他の利用者の行き先と前記いずれかの利用者の行き先とのうち最多の行き先に決定することを特徴とする請求項２に記載の行き先決定プログラム。
4. 前記データベースは、前記各々の利用者の識別情報と前記各々の利用者の行き先と前記各々の利用者の行き先が更新された更新日時とを関連付けて記憶しており、
   前記特定処理は、
   前記データベースを参照して、前記他の利用者の行き先と前記いずれかの利用者の行き先とのうち更新日時が最新の行き先を特定し、
   前記決定処理は、
   前記いずれかの利用者の現在の行き先を、前記特定処理により特定された前記更新日時が最新の行き先に決定することを特徴とする請求項２または３に記載の行き先決定プログラム。
5. 前記データベースは、前記各々の利用者の識別情報と前記各々の利用者の行き先と前記各々の利用者が行き先を更新した更新回数とを関連付けて記憶しており、
   前記特定処理は、
   前記データベースを参照して、前記他の利用者と前記いずれかの利用者とのうち更新回数が最多の利用者の行き先を特定し、
   前記決定処理は、
   前記いずれかの利用者の現在の行き先を、前記特定処理により特定された前記更新回数が最多の利用者の行き先に決定することを特徴とする請求項２〜４のいずれか一つに記載の行き先決定プログラム。
6. 前記受信処理は、
   さらに、前記第１の携帯端末と前記第２の携帯端末との間の信号の受信強度を前記第１の携帯端末から受信し、
   前記特定処理は、
   前記データベースを参照して、前記他の利用者のうち前記受信処理により受信された信号の受信強度が最大の利用者の行き先を特定し、
   前記決定処理は、
   前記いずれかの利用者の現在の行き先を、前記特定処理により特定された前記受信強度が最大の利用者の行き先に決定することを特徴とする請求項１〜５のいずれか一つに記載の行き先決定プログラム。
7. 前記出力処理は、
   前記データベースに記憶されている前記いずれかの利用者の行き先を、前記決定処理により決定された前記いずれかの利用者の現在の行き先に更新することを特徴とする請求項１〜６のいずれか一つに記載の行き先決定プログラム。
8. 前記コンピュータに、
   前記いずれかの利用者の操作入力により、前記いずれかの利用者の識別情報と前記いずれかの利用者の行き先を受け付ける受付処理と、
   前記受付処理により受け付けられた前記いずれかの利用者の識別情報と関連付けて前記データベースに記憶されている前記いずれかの利用者の行き先を、前記受付処理により受け付けられた前記いずれかの利用者の行き先に更新する更新処理と、
   を実行させることを特徴とする請求項１〜７のいずれか一つに記載の行き先決定プログラム。
9. 複数の利用者の各々の利用者の識別情報と前記各々の利用者の行き先とを関連付けて記憶するデータベースにアクセス可能なコンピュータが、
   前記複数の利用者のうちいずれかの利用者が所持する第１の携帯端末から、前記いずれかの利用者の識別情報と、前記第１の携帯端末の通信圏内にある１以上の第２の携帯端末から受信された前記第２の携帯端末を所持する他の利用者の識別情報とを受信する受信処理と、
   前記データベースを参照して、前記受信処理により受信された前記他の利用者の識別情報と関連付けて記憶されている前記他の利用者の行き先を特定する特定処理と、
   前記特定処理により特定された前記他の利用者の行き先に基づいて、前記いずれかの利用者の現在の行き先を決定する決定処理と、
   前記決定処理による決定結果と前記受信処理により受信された前記いずれかの利用者の識別情報とを関連付けて出力する出力処理と、
   を実行することを特徴とする行き先決定方法。

Images