JP2016085552A - 携帯端末、携帯端末プログラム、チェックポイント管理システム、およびチェックポイント管理方法 - Google Patents

Abstract

【課題】ＲＦＩＤタグの識別もしくは認証機能を有する制御プログラムを備えた複数種類のリーダ／ライタ装置との間で携帯端末が通信を行うことを可能とする。
【解決手段】アプリケーション１５と、携帯端末１０の現在位置情報を取得するＧＰＳ処理部１１と、リーダ／ライタ装置４１から発信された搬送波もしくはコマンドに係る信号を受信してトリガーを出力するＲＦＩＤタグ処理部１２と、トリガーを受けてアプリケーション１５を動作させる端末コントローラ１４とを有し、アプリケーション１５は、携帯端末１０の利用者４０の識別情報を含む個人情報もしくは携帯端末１０の識別情報、およびアプリケーション１５が動作した日時またはリーダ／ライタ装置４１とＲＦＩＤタグ処理部１２が通信を行った日時の情報を携帯端末１０から取得し、現在位置情報に基づいて特定したチェックポイントの情報と併せてアプリケーションサーバ２０に送信する。
【選択図】図１

Description

本発明は、携帯端末による通信技術に関し、特に、ＲＦＩＤ（Radio Frequency IDentification）タグのリーダ／ライタ機能を有する装置や機器との間で通信を行い、パッシブ型ＲＦＩＤタグとして機能する携帯端末や携帯端末プログラム、およびこのような携帯端末を用いたチェックポイント管理システムやチェックポイント管理方法に適用して有効な技術に関するものである。

例えば、鉄道の駅等では、自動改札装置がＲＦＩＤタグ（以下では、“ＩＣタグ”や“無線タグ”などの称呼も含めて“ＲＦＩＤタグ”と総称する場合がある）のリーダ／ライタ機能を備え、利用者が持つ乗車券や定期券としてのＩＣカードとの間で非接触で通信を行い、入退場や課金決済を行う仕組みが広く用いられている。さらに、利用者は、ＩＣカードに代えて、ＲＦＩＤタグとしての機能を備えたスマートフォン等の携帯端末を利用することが可能である。

例えば、特開平１０−２０７８０号公報（特許文献１）に記載されている技術を基礎としたＦｅｌｉＣａ（登録商標）の技術では、自動改札装置や、コンビニエンスストア等の店舗のレジに設置されているリーダ／ライタ装置と、利用者が持つＲＦＩＤタグ機能を備えた携帯端末に内蔵されたＩＣチップとの間で、リーダ／ライタ装置側およびＩＣチップ側それぞれの制御プログラム（これらを“ＦｅｌｉＣａプログラム”と記載する場合がある）により通信を制御する。なお、ＦｅｌｉＣａと同様な仕組みを有する技術としてＭｉｆａｒｅ（登録商標）の技術がある（以下では、特に断らない限り、“ＦｅｌｉＣａ”と記載した場合はＭｉｆａｒｅの技術も含まれるものとする）。

ＦｅｌｉＣａの技術によると、ＦｅｌｉＣａプログラムが実装されたリーダ／ライタは、ＲＦＩＤタグの捕捉、排他的通信、および認証シーケンスを行う事で、ＲＦＩＤタグが予め許可されたものであるか否かを判断する。ＲＦＩＤタグの捕捉および排他的通信のシーケンスでは、リーダ／ライタ装置は、ＲＦＩＤタグに対してＩＤ情報等の識別情報を送り、ＲＦＩＤタグは一致したＩＤ情報等の識別情報を保持する場合にこれに対して応答する。よって、ＲＦＩＤタグ側では、通信したいリーダ／ライタ装置の示す識別情報を予め記憶しておく必要がある。

また、課金決済における通信など、より高度なセキュリティを要する通信には、さらに相互認証シーケンスも用意されている。相互認証シーケンスでは、リーダ／ライタ装置は、ＲＦＩＤタグに識別情報を問い合わせ、リーダ／ライタ装置を備えた装置またはシステムが予め記憶している識別情報と一致するか否かを判断する。一致する場合はさらに自らの識別情報を送信し、ＲＦＩＤタグに予め設定された識別情報と一致するか判定させる。なお、この通信には暗号処理が施される。リーダ／ライタ装置は、この相互認証の結果から、通信を許可できるＲＦＩＤタグであるか否を決定し、許可されたものである場合にのみ当該ＲＦＩＤタグとの間で必要な情報通信を行う。よって、必要な情報通信を行うためには、あらかじめＩＤ情報または認証キー等の相手方の識別情報を、リーダ／ライタ装置を備えた装置またはシステム、およびＲＦＩＤタグに登録しておく必要がある。

特開平１０−２０７８０号公報

上記の理由により、ＦｅｌｉＣａプログラムを備えた携帯端末を持つ利用者は、自らの携帯端末がどのリーダ／ライタ装置で利用できるのか、すなわち、当該携帯端末が有するＲＦＩＤタグが、どのリーダ／ライタ装置との間で認証を行って通信が可能であるかの情報を予め把握して記憶しておく必要があり、場合によっては、利用するリーダ／ライタ装置に応じてＲＦＩＤタグの機能を使い分ける必要があった。

例えば、鉄道事業者各社がＩＣカード乗車券の相互利用を許可する前までは、利用者は、各鉄道会社専用のＩＣカード乗車券を使う必要があった。これに対し、ＩＣカード乗車券の相互利用を可能とするため、各鉄道会社は、自社の自動改札機のリーダ／ライタ装置や自動改札システムのプログラムに対して、他社のＩＣカード乗車券（すなわちＲＦＩＤタグ）の利用を許可するためのプログラムを加える（もしくは識別情報や認証情報を追加する）等の対応を行った。これにより、現在では利用者は一つのＩＣカード乗車券で国内のほとんどの鉄道会社を利用できるようになった。

しかしながら、相互利用を実現するためには、上述のように、各鉄道会社が予め他社のＲＦＩＤタグを承認するためのプログラムをリーダ／ライタ装置や自動改札システムに追加する必要がある。また、承認するプログラムを追加しても、例えば、複数の鉄道会社（もしくはサービスエリア）間の移動の際には同じＲＦＩＤタグが使えず、これらの鉄道会社（もしくはサービスエリア）をまたがる路線に乗車する場合には別途切符を購入することが必要となる場合が現在でもある。

この点、例えば、鉄道等の公共交通機関の場合は、運営事業者がほぼ限定されており、事業者の参入や撤退がほとんどないことから、各事業者において他の事業者（種類）のＲＦＩＤタグを利用可能とするためのプログラムの追加や、識別情報・認証情報などの登録を予めリーダ／ライタ装置やシステム等に行っておくことで、比較的容易に複数種類のＲＦＩＤタグを利用可能とすることができる。

しかしながら、各利用者が保持するＲＦＩＤタグには、鉄道会社以外のものも含めて様々な種類のものがあることが想定され、不特定多数の利用者が保持する各種のＲＦＩＤタグについて、それぞれに対応するプログラムの追加や、識別情報・認証情報の登録などを予めリーダ／ライタ装置やシステムに対して行っておくことは困難である。

また、現在、鉄道各社等は、携帯端末のＲＦＩＤタグを自社のリーダ／ライタ装置と通信させるためのアプリケーションを自社のＷｅｂページ等で公開しており、携帯端末の利用者は、これをダウンロードするなどして入手・利用できる。しかし、複数種類のリーダ／ライタ装置に対してそれぞれに対応するアプリケーションを取得して使い分けることは困難であり、また、様々な種類の不特定多数のリーダ／ライタ装置に対応するアプリケーションを事前に全て入手し、これらを使い分けることは事実上不可能である。従って、各事業者におけるリーダ／ライタ装置は、現在でも基本的には限られた種類のＲＦＩＤタグとのみ通信可能であり、その結果、用途は限定されて汎用性を欠き、高価な設備を有効活用できておらず、大規模事業者の間でのみ普及するに留まっているという問題がある。

この点は、ＦｅｌｉＣａプログラムやＭｉｆａｒｅプログラムによるＲＦＩＤタグを用いる場合に限らず、例えば、スマートフォンにおけるＡｎｄｒｏｉｄ（登録商標）ＯＳ（Operating System）が有するＨＣＥ（Host Card Emulation）機能もＭｉｆａｒｅプログラムをベースにしており、類似した認証機能を備えることから、上記と同様に汎用性に欠ける。さらに、ＵＨＦ（Ultra High Frequency）波を用いる中距離通信タイプのリーダ／ライタ装置とパッシブ型ＲＦＩＤタグとの通信プログラムにおいても同様である。

そこで本発明の目的は、ＲＦＩＤタグの識別もしくは認証機能を有する制御プログラムを備えた複数種類のリーダ／ライタ装置との間で通信を行うことができる、ＲＦＩＤタグ機能を有する携帯端末および当該携帯端末に用いられる携帯端末プログラム、さらに、これらを利用したチェックポイント管理システムおよびチェックポイント管理方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による携帯端末は、パッシブ型ＲＦＩＤタグのリーダ／ライタ装置と非接触通信を行う携帯端末であって、アプリケーションサーバとの間で通信を介して連携するアプリケーション処理部と、前記携帯端末の現在位置情報を取得する位置情報取得部と、前記リーダ／ライタ装置から発信された搬送波もしくはコマンドに係る信号を受信してトリガーを出力するＲＦＩＤタグ処理部と、前記トリガーを受けて前記アプリケーション処理部を動作させる端末コントローラと、を有するものである。

そして、前記アプリケーション処理部は、前記携帯端末の利用者の識別情報を含む個人情報もしくは前記携帯端末の識別情報、および前記アプリケーション処理部が動作した日時または前記リーダ／ライタ装置と前記ＲＦＩＤタグ処理部が通信を行った日時の情報を前記携帯端末から取得し、前記位置情報取得部により取得した前記現在位置情報に基づいて特定した前記リーダ／ライタ装置に係るチェックポイントの情報と併せて前記アプリケーションサーバに送信する。

また、本発明は、情報処理装置を上記の携帯端末として動作させるプログラムにも適用することができる。また、本発明は、上記のリーダ／ライタ装置と携帯端末およびアプリケーションサーバを有するチェックポイント管理システムおよびチェックポイント管理方法にも適用することができる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、不特定多数の利用者が保持するＲＦＩＤタグ機能を有する携帯端末が、ＲＦＩＤタグの識別もしくは認証機能を有する制御プログラムを備えた複数種類のリーダ／ライタ装置との間で通信を行うことが可能となる。これにより、社会に広く普及している多様な種類のリーダ／ライタ装置の用途を拡大して有効活用することが可能となる。

本発明の実施の形態１であるチェックポイント管理システムの構成例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態におけるリーダ／ライタ装置とＲＦＩＤタグの通信のシーケンスの例について概要を示した図である。 本発明の実施の形態１における携帯端末を保持する利用者が様々な場所に設置されたリーダ／ライタ装置と通信を行う場合の例について概要を示した図である。 本発明の実施の形態１におけるリーダ／ライタ装置と携帯端末との間の通信処理の流れの例について概要を示したフローチャートである。 （ａ）、（ｂ）は、本発明の実施の形態１におけるリーダ／ライタ装置とＲＦＩＤタグとの間の通信に用いられるパケットの構造について概要を示した図である。 本発明の実施の形態１におけるアプリケーションの画面の例について概要を示した図である。 本発明の実施の形態１における利用者が通過時刻の予測を希望する経路に係る情報を入力するための設定選択画面の例について概要を示した図である。 本発明の実施の形態１における利用者が通過時刻の予測を希望する経路に係る情報を入力するための新規追加画面の例について概要を示した図である。 本発明の実施の形態１における利用者が通過時刻の予測を希望する経路に係る情報を入力する際の抽出条件追加画面の例について概要を示した図である。 本発明の実施の形態１における利用者が通過時刻の予測を希望する経路に係る情報を入力する際の待ち合わせ情報追加画面の例について概要を示した図である。 本発明の実施の形態１における店舗の販売者等が特売情報を入力するための設定選択画面の例について概要を示した図である。 本発明の実施の形態１における店舗の販売者等が特売情報を入力するための新規追加画面の例について概要を示した図である。 本発明の実施の形態１における通過時刻の予測結果と特売情報を通知する画面の例について概要を示した図である。 本発明の実施の形態２であるチェックポイント管理システムの構成例について概要を示した図である。 本発明の実施の形態２におけるリーダ／ライタ装置と携帯端末との間の通信処理の流れの例について概要を示したフローチャートである。 本発明の実施の形態２におけるリーダ／ライタ装置をチェックポイントとして登録する画面の例について概要を示した図である。 本発明の実施の形態２におけるチェックポイントの検出画面の例について概要を示した図である。 （ａ）、（ｂ）は、従来技術におけるリーダ／ライタ装置とＲＦＩＤタグの通信のシーケンスの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

（概要）
リーダ／ライタ装置とパッシブ型ＲＦＩＤタグの機能を有する携帯端末との通信は、リーダ／ライタ装置からの通信により開始され、ＲＦＩＤタグへのコマンド（命令）の送信と電力供給が行われる。

図１８は、従来技術におけるリーダ／ライタ装置とＲＦＩＤタグの制御プログラムの処理による通信のシーケンスの例について概要を示した図である。図１８（ａ）は、認証処理が不要な場合（例えば、課金決済を行わない場合）のシーケンスを示しており、図１８（ｂ）は、認証処理を行う場合（例えば、課金決済を行う場合）のシーケンスを示している。

いずれの場合も、最初に、リーダ／ライタ装置からの搬送波による電力供給と通信コマンド（例えば、ポーリングコマンド）の送信が行われる。これらを受けたＲＦＩＤタグは、供給された電力により起動して、受信した通信コマンドに従った応答信号をリーダ／ライタ装置に対して送信する。このとき、ポーリングコマンドには識別情報（例えば「システムコード」）が含まれており、ＲＦＩＤタグは、自らが保持する「システムコード」がポーリングコマンドに含まれる「システムコード」と一致する場合にのみ、リーダ／ライタ装置に対して応答する。

応答信号には、ＲＦＩＤタグ内のＩＤ情報（例えば、「製造ＩＤ（ＩＤｍ）」や「製造パラメータ（ＰＭｍ）」）が含まれ、リーダ／ライタ装置は、受信したＩＤ情報の少なくとも１つを以降のコマンド（例えば、図中の「サービス存在確認コマンド」など）に含めて送信する。ＲＦＩＤタグは、受信したＩＤ情報と自らの持つＩＤ情報とが一致する場合にのみ応答する。これにより、結果的に、リーダ／ライタ装置は、ポーリングコマンドの応答信号を送信してきたＲＦＩＤタグとのみ継続的（排他的）に通信を行うことができる。このような通信方法で、以降の相互認証（例えば、図中の「認証１実行コマンド」、「認証２実行コマンド」）やデータの読み書き（例えば、図中の「暗号なし読み書きコマンド」、「読み書きコマンド」）を行い、例えば、自動改札機におけるゲートの開閉や課金決済、その他の特定機能（アプリケーションプログラム）の起動等が実行される。

なお、変則的な例として、ＦｅｌｉＣａ技術では、リーダ／ライタ装置がポーリングコマンドに対する応答信号を受信した後に、アプリケーションを起動させるためのプッシュコマンドを送信するプログラムも用意されている。しかし、この例においても、リーダ／ライタ装置およびＲＦＩＤタグは、「システムコード」および「製造ＩＤ（ＩＤｍ）」による識別を必要とする。

これに対し、本発明の一実施の形態では、ＲＦＩＤタグがリーダ／ライタ装置から最初のコマンド（例えば、ポーリングコマンド）を受信した際に、当該コマンドをトリガーとして、当該ＲＦＩＤタグを有する携帯端末に予め実装された特定のアプリケーションプログラムを起動させる。

図２は、本発明の一実施の形態におけるリーダ／ライタ装置とＲＦＩＤタグの制御プログラムの処理による通信のシーケンスの例について概要を示した図である。図１８の例と同様に、図２（ａ）は、認証処理が不要な場合（例えば、課金決済を行わない場合）のシーケンスを示しており、図２（ｂ）は、認証処理を行う場合（例えば、課金決済を行う場合）のシーケンスを示している。

いずれの場合も、上述したように、ＲＦＩＤタグは、ポーリングコマンドを受けると、携帯端末内の端末コントローラに対してアプリケーションプログラムを起動するためのトリガーを出力する。端末コントローラは当該トリガーを受けて所定のアプリケーションプログラムを起動する。なお、本発明の一実施の形態では、携帯端末の動作は起動されたアプリケーションプログラムによって規定される。従って、ポーリングコマンド以降のリーダ／ライタ装置とＲＦＩＤタグとの間の通信は、成立・不成立に関わらず意味を持たないことになり、図２（ａ）と（ｂ）の通信のシーケンスは実質的には差異がない。

起動されるアプリケーションプログラムには、利用者もしくは携帯端末のＩＤ等の個人情報や、携帯端末の位置情報およびポーリングコマンドの受信日時を含む情報を取得するための機能が実装されている。また、当該アプリケーションプログラムには、特定のサーバと通信する機能が予め実装されており、必要な情報の送受信を行うことができる。これにより、例えば、特定のサーバがポーリングコマンドを送信したリーダ／ライタ装置が属するシステムのサーバであった場合は、通信結果に基づいて当該システムにおける業務処理を自動的に行うことも可能である。

例えば、当該システムが入退場管理システムである場合は、通信結果からゲートの位置を特定してゲート開閉を自動的に行うことも可能である。また、例えば、特定のサーバが決済サーバである場合は、当該アプリケーションプログラムが決済情報（例えば、電子マネー情報やクレジットカード番号等）を保有もしくはユーザから取得していれば、決済の場所および購入商品またはサービスを特定して決済を行うことができる。

すなわち、ＲＦＩＤタグにより個別のシステムやサービス（入退場管理システムや課金決済サービス）を利用する限りは、結果的に従来技術と同様の機能・動作となる一方で、本発明の一実施の形態では、リーダ／ライタ装置とＲＦＩＤタグとの間で識別もしくは認証処理は行っていない。従って、リーダ／ライタ装置もしくはシステムの側において、通信可能なＲＦＩＤタグの情報を予め登録しておく必要がなく、利用可能なＲＦＩＤタグが限定されることがない。このように、リーダ／ライタ装置とＲＦＩＤタグとの間の識別もしくは認証処理が不要となったことにより、ＲＦＩＤタグ機能を有する携帯端末を保持するユーザは、当該携帯端末により、様々な場所に設置された各種のリーダ／ライタ装置を利用することができる。

例えば、利用者は、ＲＦＩＤタグ機能を有するスマートフォンを１つ保有することで、駅や空港の自動改札機やゲート、コンビニエンスストアのレジ、コインロッカー、自動販売機、オフィスや工場の入退場ゲート等に設置されたリーダ／ライタ装置を利用することが可能となり、複数のＲＦＩＤタグを保持してリーダ／ライタ装置に合わせて使い分けるという必要がなくなる。利用者が保有するスマートフォンに実装されたアプリケーションプログラムが、例えば、ＩＤ情報等の識別／認証機能、ＲＦＩＤタグの位置情報を取得する機能、通信日時を特定する機能、課金決済の機能、および特定のサーバと通信する機能などを有していれば、これらが可能となる。

また、種類の異なるリーダ／ライタ装置でも通信が可能であることにより、リーダ／ライタ装置を移動におけるチェックポイントとして設定して利用することが容易に可能となる。例えば、国際線出発空港では、航空会社のチェックインカウンタや保安検査場、出国審査場、出発ゲート等に、また到着空港では、入国審査場や税関等にリーダ／ライタ装置が設置されている場合がある。ここで、それぞれのリーダ／ライタ装置を管理する団体が異なる場合（例えば、チェックインカウンタのリーダ／ライタ装置は航空会社が管理しているが、出国審査場は政府機関である場合や、出発空港と到着空港とが異なる国である場合など）でも、容易に一貫したチェックポイントを設置することができる。

例えば、政府機関と民間、もしくはある国と他国との間の情報共有が難しい状況下では、それぞれが独自に種類の異なるリーダ／ライタ装置を設置していることが多いが、本発明の一実施の形態では、リーダライタ装置とＲＦＩＤタグとの間の識別や認証処理が不要なことにより、同じ種類の統一したリーダ／ライタ装置を設置した場合と同様な効果が得られる。このようなケースでは、国際的に移動する人や物の追跡に大きな効果をもたらす。例えば、ある国で犯罪者が旅客機を利用して外国へ逃亡した場合、外国の到着空港での移動ルートを国内空港の場合と同様に追跡することが可能となる。

さらに、例えば、現在日本国内で異なる２つの鉄道会社間（２つの異なるサービスエリア間）をまたぐ乗車時に、ＲＦＩＤタグによる乗車券が相互利用できず、別途切符を購入しなければならないという問題も解決できる。このように、世界規模でビッグデータの収集・分析・利用を容易に行うシステムを構築することができる。

さらに、本発明の一実施の形態によれば、チェックポイントの設置コストを低く抑えることができる。従来技術では、ＲＦＩＤタグの種類に合わせたリーダ／ライタ装置を用意する必要があり、その特殊性から生産台数は多くはなく製造コストは高くなる。例えば、ＦｅｌｉＣａの技術を用いたＩＣカードであるＳｕｉｃａ（登録商標）サービスに対応するチェックポイントを設置するには、Ｓｕｉｃａサービス対応機器を購入する必要があるが、Ｓｕｉｃａサービス対応機器は限定されたサービスを提供するための機器であり、その特殊性から生産台数は多くはなく高価な機器である。

これに対し、本発明の一実施の形態では、ＲＦＩＤタグの種類による制約を受けないため、汎用のリーダ／ライタ装置を利用することができ、また、生産台数が多いことから製造コストは小さくなる。例えば、安価な機器構成の例としては、ＰＣ（Personal Computer）等にＵＳＢ（Universal Serial Bus）接続できる汎用のリーダ／ライタ装置がコンピュータ周辺機器として販売されており、汎用ＰＣに汎用リーダ／ライタ装置を接続した構成によってチェックポイントを設置することができる。

現在は、リーダ／ライタ装置の導入・設置コストが高く汎用性が低いことから、資金の豊富な大企業が利用するに留まっている。例えば、小売店の場合は、フランチャイズ店や系列店を持つ大規模小売店が主に利用している。これに対し、リーダ／ライタ装置の導入・設置コストが下がると、資金力の小さな個人商店や中小零細企業であっても容易に導入可能となり、社会のあらゆる場所にチェックポイントが存在することに対する期待可能性が生じる。

そして、これらのチェックポイントから取得したビッグデータを活用した事故・犯罪防止、予測、追跡等の技術が進み、旅行、買い物、ビジネス等の人々の社会活動はより安全に管理され効率的になる。電子マネーサービスだけを取っても、現在は限られた店舗でのみ利用できるが、安価な汎用リーダ／ライタ装置の導入が進むと、社会のあらゆる店舗で電子マネーを利用できる環境が整い、現金を所持しなくても欲しい時に欲しい物を好きな店舗で購入できる社会生活が実現できる。

（実施の形態１）
以下では、本発明の実施の形態１である携帯端末とリーダ／ライタ装置およびこれを用いたチェックポイント管理システムについて説明する。なお、本実施の形態では、自動改札機やゲート、電子マネーの決済等のサービスにおいて広く利用されているＦｅｌｉＣａプログラム（ISO/IEC18092 Type F）で動作するリーダ／ライタ装置とＲＦＩＤタグ機能を有する携帯端末を例として説明するが、これに限られない。

例えば、Ｍｉｆａｒｅプログラム（ISO/IEC14443 Type A）で動作するリーダ／ライタ装置とＲＦＩＤタグ機能を有する携帯端末にも同様に適用することができる。Ａｎｄｒｏｉｄ ＯＳを有する携帯端末においても、実質的にはＦｅｌｉＣａやＭｉｆａｒｅプログラムと同様の処理手順によりデータ通信が行われているので、同様に適用することができる。さらに、ＵＨＦ波を用いる中距離通信タイプのリーダ／ライタ装置とパッシブ型ＲＦＩＤとの間の通信（例えば、ISO/IEC18000-6 Type BまたはC）にも同様に適用することができる。

また、本実施の形態では、チェックポイント管理システムの利用形態として、移動する人や物（以下ではこれらを「移動物体」と記載する場合がある）のチェックポイントの通過時刻の予測を行うシステムに適用するケースを例として説明するが、他の類似システム（例えば、顧客の導線調査システム等）に適用する場合も同様である。また、自動改札機やゲートの開閉、課金決済など、リーダ／ライタ装置を有するシステムにおける各種サービスに適用する場合も同様である。

［システム構成］
図１は、本発明の実施の形態１であるチェックポイント管理システムの構成例について概要を示した図である。チェックポイント管理システム１は、例えば、利用者４０が保有するＲＦＩＤタグ機能を有する携帯端末１０と、一般に広く設置されているリーダ／ライタ装置４１、およびインターネット等のネットワーク３０に接続されたアプリケーションサーバ２０とを有する。なお、携帯端末１０は、例えば、スマートフォンなどの情報処理端末であるが、スマートフォンではない携帯電話などであってもよく、また、通話機能や、ツール、ゲームなどの他のアプリケーション等を有していなくてもよい。

携帯端末１０は、上述したように、例えば、チェックポイントとして機能する自動改札機や店舗のレジなどの各種のリーダ／ライタ装置４１との間で通信を行うことができ、ハードウェアおよび／または図示しないＯＳなどのミドルウェア上で稼働するソフトウェアプログラムとして実装されるＧＰＳ処理部１１、ＲＦＩＤタグ処理部１２、通信部１３、および端末コントローラ１４を有する。また、通過時刻の予測などのサービスに係るアプリケーション処理を行うソフトウェアプログラムであるアプリケーション１５を有する。アプリケーション１５には、ネットワーク３０を介してアプリケーションサーバ２０の図示しないＷｅｂサーバプログラムにアクセスし、アプリケーションに係る処理を行うためのＷｅｂブラウザなどの汎用ソフトウェアも含まれる。

ＧＰＳ処理部１１は、図示しないＧＰＳ（Global Positioning System）センサを有し、携帯端末１０の所在位置に係る緯度・経度情報を得る位置情報取得機能を有する。ＲＦＩＤタグ処理部１２は、図示しないパッシブ型ＲＦＩＤタグとして機能し、リーダ／ライタ装置４１との間でＲＦＩＤによる非接触通信を制御するためのＦｅｌｉＣａプログラムを有する。基本的にはＲＦＩＤタグとして機能するためのＩＣチップを有するが、後述するように、ＩＣチップを有さない構成とすることも可能である。通信部１３は、携帯端末１０がキャリアの基地局と移動体用無線通信を行う機能、およびネットワーク３０に接続するためのＷｉ−Ｆｉ等による近距離無線通信を行う機能などを有する。

端末コントローラ１４は、携帯端末１０の動作全般を制御する機能を有し、本実施の形態では、例えば、上述したように、リーダ／ライタ装置４１からのポーリングコマンドをＲＦＩＤタグ処理部１２が検知してトリガーが出力された際に、これを受けて所定のアプリケーション１５を起動するなどの制御を行う。

アプリケーション１５は、各種のサービスに係る処理を行うソフトウェアであり、例えば、本実施の形態では、リーダ／ライタ装置４１からなるチェックポイントへの到着やチェックポイントの通過、またはチェックポイントからの出発等（以下ではこれらの態様を「通過」と総称する場合がある）の履歴情報や、利用者４０の移動予定の情報などに基づいて、他のチェックポイントへの通過時刻の予測などの処理を行う。後述するように、アプリケーションサーバ２０と連携してサーバサイドで処理を行ってもよい。

なお、これらの処理を行うため、アプリケーション１５は、例えば、携帯端末１０に予め利用者・端末情報１６として設定・保持されている利用者４０のＩＤ、もしくは携帯端末１０のＩＤ等の個人情報を取得して識別／認証を行う機能を有している。また、ＧＰＳ処理部１１を介して携帯端末１０の位置情報を取得する機能や、ＯＳを介してＲＦＩＤタグ処理部１２により通信を行った日時を特定する機能、課金決済を行う機能、特定のサーバと通信部１３を介して通信を行う機能などを有している。

アプリケーションサーバ２０は、サーバ機器やクラウドコンピューティングサービス上の仮想サーバ上に構築されたサーバシステムであり、例えば、図示しないＯＳやＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装されたチェックポイント管理部２１、予測処理部２２、および推奨情報管理部２３などの各部を有する。また、データベース等により実装された通過履歴テーブル（以下では「テーブル」を「ＴＢ」と略記する場合がある）２４、移動予定情報ＴＢ２５、予測設定情報ＴＢ２６、チェックポイントマスタ２７、ユーザマスタ２８、および店舗マスタ２９などの各データストアを有する。

チェックポイント管理部２１は、利用者４０がリーダ／ライタ装置４１からなるチェックポイントを通過したこと、すなわち、当該利用者４０が保持する携帯端末１０がリーダ／ライタ装置４１との間で通信を行ったことに係る情報を当該携帯端末１０からネットワーク３０を介して取得し、ユーザマスタ２８に登録されている利用者４０（すなわち携帯端末１０）毎に、後述する旅行レポートの単位で通過履歴ＴＢ２４に蓄積する機能を有する。また、チェックポイントマスタ２７に登録されたチェックポイントのマスタ情報について登録・削除・変更などの処理を行うためのユーザインタフェースの機能を有する。

予測処理部２２は、携帯端末１０のアプリケーション１５を介した利用者４０からの要求に基づいて、当該利用者４０（すなわち携帯端末１０）の移動予定の経路上にある各チェックポイントの出発時刻、通過時刻または到着時刻（以下ではこれらを「通過時刻」と総称する場合がある。なお、これには、絶対時刻での算出に加えて、前のチェックポイントとの間の相対時刻（絶対時刻の差分、すなわち所要時間）での算出も含まれるものとする）を、予測設定情報ＴＢ２６に設定されている条件に基づいて予測し、予測結果を移動予定情報ＴＢ２５に記録するとともに、アプリケーション１５を介して携帯端末１０に出力する機能を有する。予測の処理については、詳細は後述するが、例えば、通過履歴ＴＢ２４に蓄積された各利用者４０についてのチェックポイント間の移動の実績から得られる統計情報、および予測設定情報ＴＢ２６に設定されている条件などに基づいて、通過時刻の予測値を算出する。

推奨情報管理部２３は、利用者４０の移動予定の経路上のチェックポイントについて、詳細は後述するが、その周辺に所在する店舗の情報、および当該店舗において実施される特売等の広告の情報を店舗マスタ２９から抽出し、推奨情報として移動予定情報ＴＢ２５に記録するとともに、アプリケーション１５を介して携帯端末１０に出力する機能を有する。また、店舗マスタ２９に登録された各店舗のマスタ情報および特売情報について登録・削除・変更などの処理を行うためのユーザインタフェース機能を有する。

図３は、携帯端末１０を保持する利用者４０が様々な場所に設置されたリーダ／ライタ装置４１と通信を行う場合の例について概要を示した図である。図３では、移動物体としての利用者４０が旅行者であり、携帯端末１０としてスマートフォンを所持する場合を例としている。利用者４０は、「空港Ａ」の自動ゲート→「空港Ｂ」の自動ゲート→「店舗Ｃ」のレジ→「駅Ｄ」の自動改札機→「駅Ｅ」の自動改札機→「出社用入口Ｆ」の自動ゲート→「退社用出口Ｇ」の自動ゲート→「通路Ｈ」に設置された自動販売機→「港Ｉ」の自動改札機→「港Ｊ」の自動改札機、の順で各チェックポイントに通過し、その都度、同一の携帯端末１０により対応するリーダ／ライタ装置４１との間で通信を行うことを示している。

各リーダ／ライタ装置との間の通信結果、すなわち、各リーダ／ライタ装置４１に対応するチェックポイントを利用者４０が通過した旨の情報は、携帯端末１０のアプリケーション１５により通信部１３を介してネットワーク３０を経由してアプリケーションサーバ２０に送信される。アプリケーションサーバ２０では、携帯端末１０から受信した情報を、チェックポイント管理部２１により通過履歴ＴＢ２４に蓄積する。

一方、各チェックポイントのリーダ／ライタ装置４１は、例えば、これらを含むシステムとして管理を行う運営事業者（図３の例では、航空会社や販売店、鉄道会社、企業、飲料販売事業者、船舶会社など）が有するサーバである事業者サーバ４２にインターネットやイントラネットなどのネットワークを介して接続されている。例えば、「空港Ａ」と「空港Ｂ」のリーダ／ライタ装置４１は、それぞれ、同じ航空会社の事業者サーバ４２に接続されており、「空港Ａ」で利用者４０が携帯端末１０により通信を行った（自動ゲートを通過した）ことを航空会社の事業者サーバ４２が把握することで、「空港Ｂ」のリーダ／ライタ装置４１（自動ゲート）に指示を行ってその動作を制御する（例えば、自動ゲートの開閉や、メッセージの表示などを行う）ことが可能となる。

なお、各運営事業者の事業者サーバ４２は、ネットワーク３０などを介して相互に接続可能であってもよく、また、アプリケーションサーバ２０とも相互に接続可能であってもよい。事業者サーバ４２とアプリケーションサーバ２０とが統合された１つのサーバシステムとして構成されていてもよい。事業者サーバ４２やアプリケーションサーバ２０が相互に通信を行って情報を授受することにより、例えば、利用者４０の移動や所在位置の状況に応じて、より適切に各チェックポイントのリーダ／ライタ装置４１の動作を制御することができる。

［処理内容］
図４は、ＦｅｌｉＣａプログラムを用いたリーダ／ライタ装置４１とＲＦＩＤタグ機能を有する携帯端末１０との間の通信処理の流れの例について概要を示したフローチャートである。図４の例において、自動改札機やレジ等が有するリーダ／ライタ装置４１は、従来技術と同様のものを用いており、上述したように、まず、搬送波による電力供給とポーリングコマンドの送信を行う（Ｓ０１）。

図５は、ＦｅｌｉＣａ技術におけるリーダ／ライタ装置４１とＲＦＩＤタグとの間の通信に用いられるパケットの構造について概要を示した図である。図５（ａ）に示したデータ構造の中の「パケットデータ」には、コマンドパケットまたはレスポンスパケットが含まれる。図５（ｂ）ではこれらのパケットの構造を示している。ポーリングコマンドはコマンドパケットに含まれる。ポーリングコマンドの「コマンドデータ」には「システムコード」の情報が含まれ、ＲＦＩＤタグは、受信したポーリングコマンドに含まれる「システムコード」の情報と、自身が保持する「システムコード」の情報とが一致した場合にのみ、レスポンスパケットを応答する。

図４に戻り、リーダ／ライタ装置４１は、ポーリングコマンドを送信した後、予め設定されたタイムアウト時間が経過するまでの間、ＲＦＩＤタグ（携帯端末１０）からのレスポンスパケットを待ち受け、当該パケットを受信したか否か、すなわち、ＲＦＩＤタグからのレスポンスがあったか否かを判定する（Ｓ０２）。具体的には、ＦｅｌｉＣａ技術の場合は、「０１ｈ」がポーリングコマンドに対するレスポンスコードとして使用されるため、リーダ／ライタ装置４１が受信したレスポンスパケットの先頭１バイト（レスポンスコード）に「０１ｈ」が設定されている場合は、ＲＦＩＤタグからのレスポンスがあったと判定する。それ以外の場合はレスポンスがないと判定し、ステップＳ０１に戻ってポーリングコマンドの送信から処理を繰り返す。

ステップＳ０２でレスポンスがあったと判定した場合は、次に、レスポンスパケットのレスポンスデータに含まれるＲＦＩＤタグのＩＤ情報（「製造ＩＤ（ＩＤｍ）」）を取得してＲＦＩＤタグを捕捉する（Ｓ０３）。その後は、ステップＳ０３で取得したＩＤ情報を、サービスのリクエストやデータの読み書き、相互認証等の各種コマンドのパケットに設定することで、当該ＩＤ情報を有するＲＦＩＤタグを一連の処理の中で捕捉し続ける。

ＲＦＩＤタグでは、受信したコマンドの中に含まれるＩＤ情報が自身の保持するＩＤ情報と一致しない場合は応答しないため、結果的に、リーダ／ライタ装置４１は、ステップＳ０３で取得したＩＤ情報を持つＲＦＩＤタグからのみレスポンスを受ける、すなわち、捕捉したＲＦＩＤタグとのみ通信を行うことになる。リーダ／ライタ装置４１では、当該通信の結果に基づいて、例えば、自動ゲートの開閉等の制御や、電子マネーによる決済などの業務処理を行う。なお、携帯端末１０の中に複数種類のＲＦＩＤタグ機能（複数種類のシステム機能）が存在する場合は、各ＲＦＩＤタグ機能にそれぞれ固有のＩＤ情報が割り当てられているため、携帯端末１０は、そのうちのいずれかのＲＦＩＤタグ機能におけるＩＤ情報が一致すれば応答する。

本実施の形態では、従来技術と同様のリーダ／ライタ装置４１の上記の各ステップのうち、ステップＳ０１のみを利用する。すなわち、ＲＦＩＤタグではリーダ／ライタ装置４１からのステップＳ０１によるポーリングコマンドのみを必要とし、さらに、これに対する応答を行わない。従って、リーダ／ライタ装置４１では、ステップＳ０２においてレスポンスを受けることがないため、ステップＳ０１に戻ってポーリングコマンドの送信を繰り返すことになる。なお、ＲＦＩＤタグ処理部１２のＩＣチップにＦｅｌｉＣａプログラムも並行的に実装している場合は、当該ＩＣチップが応答を行うことになり、後述するトリガーにより起動するアプリケーションのサービスと、ＦｅｌｉＣａプログラムにより起動するサービスの両者が並行的に実行されてもよい。

一方、携帯端末１０が保持するＲＦＩＤタグ（ＲＦＩＤタグ処理部１２）は、図４に示すように、まずリーダ／ライタ装置４１からの搬送波およびコマンドの待ち受け状態となる（Ｓ１１）。ここでは、ＲＦＩＤタグ処理部１２は、リーダ／ライタ装置４１とＲＦＩＤタグとの間の磁界を利用して回路を起動する（電磁誘導方式）、もしくはリーダ／ライタ装置４１からの放射電磁波を利用して回路を起動する（電波方式）。

次に、ＲＦＩＤタグ処理部１２は、受信したコマンドがポーリングコマンドであるか否かを判定する（Ｓ１２）。具体的には、ＦｅｌｉＣａ技術の場合は、「００ｈ」がポーリングコマンドのコマンドコードとして使用されるため、ＲＦＩＤタグ処理部１２が受信したコマンドパケットの先頭１バイト（コマンドコード）に「００ｈ」が設定されている場合は、ポーリングコマンドを受信したと判定する。ポーリングコマンドでない場合は、ステップＳ１１に戻ってコマンドの待ち受けを継続する。

ステップＳ１２でポーリングコマンドを受信したと判定した場合は、次に、所定のアプリケーション１５を起動するためのトリガーを端末コントローラ１４に対して送信する（Ｓ１３）。その後、ＲＦＩＤタグ処理部１２は、予め設定されたウェイト時間が経過するまでの間、コマンドの待ち受けを一時停止してもよい（Ｓ１４）。ウェイト時間は、例えば、所定のアプリケーション１５が起動するのに要する時間とし、通常は０．５秒程度に設定されるが、これに限定されるものではない。ウェイト時間の経過後は、ステップＳ１１に戻ってコマンドの待ち受けを継続する。

なお、Ｍｉｆａｒｅプログラムおよびこれを基にしているＡｎｄｒｏｉｄ ＯＳ ｖ４．４（以下では単に「Ａｎｄｒｏｉｄ」と記載する場合がある）においては、ＲＦＩＤタグがリーダ／ライタ装置４１から受信するコマンドはＡＰＤＵ（Application Protocol Data Unit）コマンドと呼ばれ、ＲＦＩＤタグからの応答はＡＰＤＵレスポンスと呼ばれる。

Ａｎｄｒｏｉｄにおいては、通常、リーダ／ライタ装置４１が最初にＲＦＩＤタグに送信するＡＰＤＵコマンドは“ＳＥＬＥＣＴ ＡＩＤ”とされ、これがＦｅｌｉＣａプログラムにおけるポーリングコマンドに相当する。ＦｅｌｉＣａプログラムでは「システムコード」の情報がポーリングコマンドに含まれるが、ＡｎｄｒｏｉｄではＡＩＤ（Application ID）が“ＳＥＬＥＣＴ ＡＩＤ”コマンドに含まれる。従って、ＭｉｆａｒｅプログラムおよびＡｎｄｒｏｉｄにおいては、ＲＦＩＤタグが“ＳＥＬＥＣＴ ＡＩＤ”コマンド等の最初に受信するＡＰＤＵコマンドを受信した際にトリガーを発生させればよい。

携帯端末１０の端末コントローラ１４は、図４に示すように、まず待ち受け状態となり（Ｓ２１）、所定の間隔でトリガーの受信の有無を確認する（Ｓ２２）。トリガーを受信していない場合は、ステップＳ２１に戻って待ち受けを継続する。ステップＳ２２でトリガーを受信していた場合は、所定のアプリケーション１５を起動する（Ｓ２３）。

なお、アプリケーション１５の起動については、例えば、アプリケーション１５の起動および所定の画面の表示を同時に行う方法であってもよいし、利用者４０等が予めアプリケーション１５を起動しておき、トリガーの受信によって所定の画面を表示する方法であってもよい（すなわち、ここではアプリケーション１５を「動作」させる）。後者の方法では、利用者４０の操作等によるアプリケーション１５の起動を予め必要とするが、トリガーを受信した際の所定の画面の表示に要する時間を短縮することができる。一方で、前者の方法では、利用者４０の操作等を必要としないが、トリガーを受信した際のアプリケーション１５の起動と所定の画面の表示を同時に行うので処理に要する時間が長くなってしまう。

アプリケーション１５は、例えば、携帯端末１０のメーカーが出荷前に予めインストールしておいてもよいし、利用者４０が携帯端末１０の購入後に所定の販売・ダウンロード用Ｗｅｂサイトからダウンロードしてインストールしてもよい。

利用者４０が携帯端末１０でアプリケーション１５を初めて起動すると、携帯端末１０は、当該利用者４０の個人情報等を登録させるためのユーザ登録画面（図示しない）を表示する。利用者４０が当該画面を介してユーザ登録を行って、アプリケーションサーバ２０のユーザマスタ２８に情報が登録されると、当該利用者４０がアプリケーション１５を利用可能となる。ユーザ登録画面は、アプリケーション１５が有していてもよいし、アプリケーション１５とは別個に携帯端末１０が有していてもよい。

利用者４０が登録する個人情報には、例えば、ユーザ名、国籍、郵便番号、住所、生年月日、性別、氏名、電話番号、ＦＡＸ番号、電子メールアドレス、職業、身体の障害の有無、ソーシャルセキュリティ番号、クレジット／デビットカード番号、生体認証情報（指紋、虹彩、顔情報など）、会員情報（サービスやサークル等に入会した際に割り当てられるＩＤ番号等）、ユーザＩＤ／パスワード、携帯端末１０のＩＤ等が含まれ得る。

また、必要とされる個人情報が、利用者４０が携帯端末１０の購入時等に携帯端末１０に入力した情報で足りる場合は、当該情報をアプリケーション１５が自動取得することでユーザ登録を省略してもよい。この場合、携帯端末１０は、利用者４０が初めてアプリケーション１５を起動した際に当該利用者４０が携帯端末１０に登録した個人情報等を取得する。取得の際、携帯端末１０が、例えば「入力済み個人情報をアプリが取得します。よろしいですか？」等の確認メッセージを画面に表示し、利用者４０から同意を得るステップを追加してもよい。

利用者４０がユーザ登録画面で個人情報等を入力した後、画面上のボタンの押下等により送信を指示すると、携帯端末１０は、ユーザＩＤもしくは携帯端末１０のＩＤにその他の個人情報等を関連付けるか、個人情報等のそれぞれを互いに関連付けるかしてアプリケーションサーバ２０に送信する。このとき、同時に携帯端末１０が有する不揮発メモリ等の所定の記憶領域に個人情報等を記録するようにしてもよい。アプリケーションサーバ２０では、受信した情報をユーザマスタ２８に記録する。

なお、上述したように、本実施の形態では、携帯端末１０では、リーダ／ライタ装置４１からのポーリングコマンドを受けるのみで、ＩＤ情報の認証を行わない。すなわち、携帯端末１０は、ＲＦＩＤタグ機能を実現するためのＩＣチップもしくはＲＦＩＤタグ処理部１２を有しない構成であってもよい。この場合、ＲＦＩＤタグ処理部１２（ＩＣチップ）が行う処理は端末コントローラ１４が代行する。具体的には、端末コントローラ１４は、携帯端末１０が備えるアンテナによって、リーダ／ライタ装置４１からのポーリングコマンド等のコマンドを受信したか否かを予め設定されたタイミングで確認し、当該コマンドを受信した場合に所定のアプリケーション１５を起動する、もしくはアプリケーション１５の画面を表示させる処理を行う。

［画面内容（通過チェックポイント記録）］
図６は、携帯端末１０においてＲＦＩＤタグ処理部１２からのトリガーを受けて端末コントローラ１４により起動されるアプリケーション１５の画面の例について概要を示した図である。本実施の形態におけるアプリケーション１５は、ＲＦＩＤタグ機能を有するスマートフォンなどの携帯端末１０の利用者４０である旅行者が、当該携帯端末１０を所持して移動する場合に、各チェックポイントに設置されたリーダ／ライタ装置４１との間で携帯端末１０により通信を行い、当該チェックポイント（リーダ／ライタ装置４１）の情報および日時の情報をアプリケーションサーバ２０へ送信するというものである。

アプリケーションサーバ２０では、取得した情報を通過履歴ＴＢ２４に蓄積し、また、新しいチェックポイント情報の入力があった場合は、その情報をチェックポイントマスタ２７に蓄積するとともに、蓄積されたデータを統計処理することにより、当該利用者４０が他のチェックポイントへ移動する際のチェックポイントの通過時刻（もしくはチェックポイント間の所要時間）を予測する。また、各利用者４０について予測された通過予想時刻の情報に基づいて、例えば、店舗などの販売者が行う特売セール期間中に付近を通過する予定の利用者４０に対して、通過時刻の予測情報と併せて特売セールに係る情報を送信する。

図６の例に示した画面は、旅行者（利用者４０）が、移動経路上のチェックポイントを通過したことを旅行レポートとして記録するための画面である。当該画面は、種々のリーダ／ライタ装置４１を備えた各チェックポイント（例えば、交通機関の自動改札機や店舗のレジ、コインロッカー、事業所の入退室管理用の自動ゲートなど）において、利用者４０がＲＦＩＤタグ機能を有するスマートフォン等の携帯端末１０をリーダ／ライタ装置４１に近づけて通信させた際に、当該携帯端末１０の画面上に表示される。

当該画面は、アプリケーション１５が直接生成して表示してもよいし、ネットワーク３０を介してアプリケーションサーバ２０にアクセスして、アプリケーションサーバ２０により生成されたＷｅｂページを表示するようにしてもよい。後者の場合、アプリケーションサーバ２０は、携帯端末１０を含む外部からのアクセスがあった場合に、ユーザＩＤおよびパスワード、もしくは携帯端末１０のＩＤを要求し、ユーザマスタ２８に保持するユーザＩＤおよびパスワード、もしくは携帯端末ＩＤと一致した場合にのみアクセスを許可するようにしてもよい。

図６の例に示した画面において、「チェックポイント検出日時」の項目には、旅行者（利用者４０）の携帯端末１０が、当該旅行者が通過したチェックポイントのリーダ／ライタ装置４１と通信を行った日時の情報が自動的に設定・表示される。トリガーによりアプリケーション１５が起動（動作)した日時の情報が自動的に設定・表示されるようにしてもよい。それ以降の欄では、利用者４０に対して当該チェックポイントの位置や関連情報、および当該チェックポイントからの移動方法などについて、情報の選択もしくは入力を促す構成となっている。

なお、新しいチェックポイント情報が入力された場合は、アプリケーション１５（またはアプリケーションサーバ２０）は、新たに入力されたチェックポイントに関する各項目の値を、以降の画面生成時に、図６の画面例におけるチェックポイントに関する各欄のプルダウンリストに追加して表示する。

「緯度、経度」の項目には、旅行者（利用者４０）の指定した地図上の位置情報に基づいて自動計算された緯度・経度の値が表示されるようにしてもよい。また、交通機関に関する欄では、上記のチェックポイントの欄と同様に、交通機関について選択だけでなく新規入力もできる構成としてもよい。この場合、アプリケーション１５（またはアプリケーションサーバ２０）は、新規入力された交通機関情報を図示しない交通機関マスタ等に蓄積し、以降の画面生成時に、図６の画面例における交通機関に関する各欄のプルダウンリストに追加して表示する。また、「交通機関の種類」の欄のプルダウンリストには、例えば、徒歩などの交通手段を用いない移動方法が含まれていてもよい。

当該画面では、さらに、当該チェックポイントにおける気象情報や、利用者４０の当該移動ルートの使用頻度など、利用者４０の通過時刻に影響を与える可能性のある情報を選択・入力させることができる。

なお、チェックポイントの位置情報の特定には、携帯端末１０のＧＰＳ処理部１１による位置特定機能を利用してもよい。屋内や地下にあるチェックポイントの場合は、例えば、チェックポイントのある階の天井や壁、柱等の部分にＧＰＳ用の測位装置やＷｉ−Ｆｉアンテナ、モバイルネットワーク用のアンテナ等を設置し、三角測量法等を用いて緯度・経度を算出することで携帯端末１０の位置を特定する方法を用いることも可能である。

アプリケーション１５（もしくはアプリケーション１５から処理要求を受けたアプリケーションサーバ２０）は、例えば、ＧＰＳ処理部１１により得られる利用者４０の現在位置（緯度および経度）の情報に基づいて、これに一致する、もしくは所定の距離内（例えば、半径１００ｍ以内）にあるチェックポイントの情報を、アプリケーションサーバ２０のチェックポイントマスタ２７から検索して取得し、当該チェックポイントの名称を含む情報を画面表示してもよい。アプリケーション１５は、図６の画面例に示すように、プルダウンリスト等を用いて、複数のチェックポイントの候補の中から適切なものを選択させるようにしてもよいし、適切なチェックポイントがない場合には新規入力させるようにしてもよい。

さらに、旅行レポートとして、携帯端末１０がチェックポイントのリーダ／ライタ装置４１と通信を行った際の、利用者４０の生体認証情報を記録することも可能である。例えば、携帯端末１０が備えるカメラ機能やスキャナーアプリケーションなどを用いて、利用者４０の虹彩や顔、指紋情報などを取得し、他の情報と関連付けてアプリケーションサーバ２０に送信してもよい。この場合、図６の例に示した画面では、虹彩や顔、指紋情報などを取得および承認するためのボタン等（図示しない）を設け、利用者４０に対してカメラやスキャナーが撮影可能な位置に自身の目や顔、指などをセットしてボタンを押下するよう促す。利用者４０がボタンを押下することで、携帯端末１０は、虹彩や顔、指紋などの情報を取得（撮影）する。

図６の例に示した画面において、利用者４０がチェックポイントについての情報や、そこからの移動方法の情報、利用者４０の生体認証情報などを入力して、「送信」ボタンを押下すると、アプリケーション１５は、入力、選択および自動表示された情報を１つの旅行レポートとして、利用者４０の個人情報（少なくとも利用者４０もしくは携帯端末１０のＩＤ）と関連付けるか、当該利用者４０に係る旅行レポート情報内の各情報を相互に関連付けてアプリケーションサーバ２０へ送信する。アプリケーションサーバ２０では、受信した旅行レポート毎にＩＤやシーケンス番号を付して通過履歴ＴＢ２４に記録する。

その後、携帯端末１０は、アプリケーション１５を終了させる。終了に際しては、例えば、ＲＦＩＤタグ処理部１２から出力されたトリガーに基づいて端末コントローラ１４がアプリケーション１５の起動および所定の画面の表示を行った場合は、その両者を終了させる。また、アプリケーション１５は起動済みであり、トリガーに基づいて端末コントローラ１４が所定の画面表示のみ行った場合は、当該所定の画面の表示を終了させる。

［画面内容（通過時刻予測設定）］
図７〜図１０は、携帯端末１０のアプリケーション１５において、利用者４０が通過時刻の予測を希望する経路に係る情報を入力するための画面の例について概要を示した図である。図７は、アプリケーションサーバ２０の予測処理部２２が予測を行う際に必要となる情報を抽出するための条件を利用者４０が選択する画面である。ここでは、過去に予測を行ったときの設定内容を保存したもの、もしくは予め登録された設定内容から利用者４０が選択する。設定内容を選択可能とすることにより、同じ内容での予測処理を繰り返し行う際に、利用者４０が条件を都度入力・設定する必要を省くことができる。図７の例では、設定内容として現在「設定００２」が選択されていることを示している。

利用者４０が新たに経路に係る情報やその他の条件を設定する場合は、図７の画面において「新規設定追加」ボタンを押下する。これにより、図８に示したような設定内容の新規追加のための画面が表示される。ここでは、利用者４０が予定する移動経路上に設置されているチェックポイント（開始チェックポイント、接続チェックポイント、終了チェックポイント）の情報、およびこれらのチェックポイント間の移動手段に係る情報を利用者４０が入力・選択する欄が設けられている。ここで、図８〜図１０の各プルダウンリストに表示される項目には、チェックポイントマスタ２７や、図示しない交通機関マスタ、ユーザマスタ２８などの各テーブルに記録されたものが含まれる。また、図８の画面例における「割り当て番号」の欄の値は、自動的に設定・表示されるようにしてもよい。

また、利用者４０は、必要に応じて、アプリケーションサーバ２０において通過時刻の予測のために必要な情報を抽出するための追加条件を設定することができる。例えば、図８の画面例において、利用者４０が「抽出のための詳細条件を設定する」という項目を選択すると、図９に示したような抽出条件の追加設定のための画面が表示される。ここで利用者４０が必要な情報を入力・選択することで、利用者４０の移動条件により適した条件で予測のためのデータを抽出することができる。

また、利用者４０は、移動先で待ち合わせの相手がいる場合に、待ち合わせ相手にも通過時刻の予測情報を提供して共有できるよう、待ち合わせ相手、待ち合わせ名、および待ち合わせ場所の情報に加えて、待ち合わせ相手に対する情報の送信先の情報を設定することができる。例えば、図８の画面例において、利用者４０が「待ち合わせ情報を設定する」という項目を選択すると、図１０に示したような待ち合わせ情報の設定のための画面が表示される。ここで利用者４０が待ち合わせ相手の電子メールアドレスや、待ち合わせのチェックポイントの情報を入力・選択することで、待ち合わせ相手も待ち合わせ場所（チェックポイント）への利用者４０の到着予想時間を知ることができ、より効率的な待ち合わせが可能となる。

なお、図１０の待ち合わせチェックポイント欄のプルダウンリストに含まれるチェックポイントの情報は、図８の画面例において利用者４０が開始チェックポイント、接続チェックポイント、および終了チェックポイントとしてそれぞれ選択した情報のみを表示してもよい。

図８の画面例において、利用者４０が必要な情報を入力・選択して「設定」ボタンを押下すると、アプリケーション１５は、入力、選択および自動表示された情報を利用者４０の個人情報（少なくとも利用者４０もしくは携帯端末１０のＩＤ）と関連付けるか、当該利用者４０の個人情報を含む各情報を相互に関連付けてアプリケーションサーバ２０へ送信する。アプリケーションサーバ２０では、受信した予測設定の情報を予測設定情報ＴＢ２６に記録する。

なお、上記の例では、移動予測の設定内容を入力・選択する画面を、図７〜図１０に分けて構成しているが、これに限られるものではない。１画面で全ての情報を入力・選択できるように構成してもよいし、上記の例とは異なる単位で画面を分けて構成してもよい。また、図７〜図１０の各画面は、アプリケーション１５が直接生成して表示してもよいし、ネットワーク３０を介してアプリケーションサーバ２０にアクセスして、アプリケーションサーバ２０により生成されたＷｅｂページを表示するようにしてもよい。

後者の場合、アプリケーションサーバ２０は、携帯端末１０を含む外部からのアクセスがあった場合に、ユーザＩＤおよびパスワード、もしくは携帯端末１０のＩＤを要求し、ユーザマスタ２８に保持するユーザＩＤおよびパスワード、もしくは携帯端末ＩＤと一致した場合にのみアクセスを許可するようにしてもよい。なお、ユーザ（利用者４０）は、携帯端末１０からではなく、図示しない固定端末からアプリケーションサーバ２０にアクセスして、図７〜図１０の画面を表示してもよい。

アプリケーションサーバ２０の予測処理部２２では、上記の設定内容に従って通過時刻の予測情報を計算する。予測のために必要となるデータの抽出および予測計算を実行するタイミングは、例えば、利用者４０もしくは待ち合わせ相手に対して、通過時刻の予測情報もしくは後述する特売情報を電子メールにより送信する直前とする。

上述したような画面を介して利用者４０が移動中に携帯端末１０を介して入力したチェックポイント（リーダ／ライタ装置４１）の情報と、その通過時刻（通信の検出日時）の情報は、アプリケーションサーバ２０の通過履歴ＴＢ２４に蓄積されている。従って、通過時刻の予測計算に際しては、予測設定情報ＴＢ２６に設定されている内容（利用者４０が入力・選択したチェックポイントや、利用予定交通機関、追加の抽出条件など）に基づいて抽出条件を決定して、通過履歴ＴＢ２４から全ての利用者４０についての該当する旅行レポートを抽出し、各チェックポイントの通過時刻を取得する。そして、チェックポイント毎に通過時刻の平均値と平均値±３シグマの値を計算する。ここで、シグマは通過時刻の標準偏差である。

平均値は、メジアンやモードで代用されてもよい（特にデータ数が多い場合は、三者は同等の値を示すので代替可能である）。また、３シグマは、予測したい確度によって、例えば、０シグマ、１シグマ、２シグマ、４シグマ等に変更してもよい。また、予測計算においては、平均値もしくは標準偏差の計算に代えて、多変量解析によって得られる予測値や、信頼区間もしくは予測区間を用いてもよい。通過時刻の予測結果は、例えば、（平均値）を予想通過時刻、（平均値−３シグマ）を下限予想時刻、（平均値＋３シグマ）を上限予想時刻として示される。予想通過時刻に代えてチェックポイント間の予想所要時間を算出する場合は、例えば、任意のチェックポイントの通過時刻から直前のチェックポイントの通過時刻を引くことにより当該２つのチェックポイント間の通過に係る所要時間を算出し、これを同様に統計処理することで得ることができる。より詳しくは、例えば、特許５１２９４１４号公報または特許５１７４９９３号公報に記載がある。

［画面内容（特売情報広告設定）］
図１１、図１２は、店舗の販売者等（すなわち、本実施の形態では広告主）が特売情報を入力するための画面の例について概要を示した図である。これらの画面は、例えば、アプリケーションサーバ２０の推奨情報管理部２３が、図示しないＷｅｂサーバプログラムにより生成して、店舗の販売者等が使用する情報処理端末上のＷｅｂブラウザ等を介して表示させるものである。なお、ここでの情報処理端末は、携帯型であるか据置型であるかを問わない。

販売者等からのアクセスに対して、アプリケーションサーバ２０の推奨情報管理部２３は、販売者のユーザＩＤおよびパスワード、および広告主のカテゴリー情報を含む個人情報等を登録させるためのユーザ登録画面（図示しない）を生成して情報処理端末上に表示させる。当該個人情報には、例えば、販売者名、担当者名、部署名、役職、住所、郵便番号、電話、ＦＡＸ、電子メールアドレス、ホームページまたは広告用Ｗｅｂページの情報等が含まれる。販売者が必要な情報を入力すると、情報処理端末は、ユーザＩＤと他のユーザ登録情報とを関連付けるか、各ユーザ登録情報を相互に関連付けてアプリケーションサーバ２０へ送信する。アプリケーションサーバ２０では、受信したユーザ登録情報をユーザマスタ２８等に記録する。

その後、アプリケーションサーバ２０の推奨情報管理部２３は、特売情報の広告の出力に係る設定情報を販売者に入力・設定させるための画面を表示させる。図１１は、特売情報の広告についての設定内容を販売者のユーザが選択する画面である。ここでは、過去に広告を行ったときの設定内容を保存したもの、もしくは予め登録された設定内容から販売者のユーザが選択する。設定内容を選択可能とすることにより、同じ内容での広告を繰り返し行う際に、内容を都度入力・設定する必要を省くことができる。図１１の例では、設定内容として現在「広告００１」が選択されていることを示している。

販売者が新たに特売情報の広告に係る内容を設定する場合は、図１１の画面において「新規広告追加」ボタンを押下する。これにより、図１２に示したような広告の新規追加のための画面が表示される。ここでは、販売者が特売を計画する商品やサービスおよび特売の情報、広告の出力条件などの情報を販売者が入力・選択する欄が設けられている。なお、「広告番号」および「緯度、経度」の欄の値は、自動的に設定・表示されるようにしてもよい。図１２の画面例において、販売者が必要な情報を入力・選択して「設定」ボタンを押下すると、販売者が使用する情報処理端末は、入力、選択および自動表示された情報を少なくとも販売者のユーザＩＤと関連付けるか、当該販売者のユーザＩＤを含む各情報を相互に関連付けてアプリケーションサーバ２０へ送信する。アプリケーションサーバ２０では、受信した広告設定の情報を店舗マスタ２９もしくは図示しない特売情報テーブル等に記録する。

アプリケーションサーバ２０では、上述した予測処理部２２による処理により利用者４０の通過時刻の予測計算を行った後、推奨情報管理部２３により特売情報の抽出を行う。抽出の条件は、予測された各チェックポイントの通過時刻と特売の実施時間との関係として、予め設定しておく。例えば、ある特売の実施時間が、あるチェックポイントにおいて計算された通過時刻についての予想区間（下限予想時刻と上限予想時刻との間の範囲）を包含し、かつ、当該特売の実施場所が、当該チェックポイントの位置から予め定められた距離以内にある場合に、当該特売に係る情報を抽出して、通過時刻の予測結果の情報とともに利用者４０の携帯端末１０に対して提供する。

より具体的には、例えば、アプリケーションサーバ２０の予測処理部２２が、通過履歴ＴＢ２４に蓄積された「チェックポイントＡ」の通過時刻を、「利用者Ｂ」が図７〜図１０に示したような予測設定の画面で入力した情報（予測設定情報ＴＢ２６に登録された情報）に基づいて抽出し、通過時刻の予測計算を行った結果、通過時刻の予想が「午後３時±１０分」と計算されたとする（この情報は移動予定情報ＴＢ２５に記録される）。

一方、店舗マスタ２９等において、特売情報として、例えば、「チェックポイントＡ」の半径１ｋｍ以内にある「店舗（販売者）Ｃ」が「午後２時〜午後４時」で特売を行うことが登録されているとした場合、「利用者Ｂ」に対して、予測結果の情報（「チェックポイントＡ」を「午後３時±１０分」に通過予定）と、当該特売情報（「店舗Ｃ」で「午後２時〜午後４時」に特売あり）を電子メールにて通知する。なお、「利用者Ｂ」の電子メールアドレスは、アプリケーションサーバ２０のユーザマスタ２８に登録されているものを用いることができる。また、「利用者Ｂ」が、図８および図１０の画面で待ち合わせ相手の電子メールアドレスを登録している場合は、当該待ち合わせ相手にも電子メールで同様の内容を通知するようにしてもよい。

［画面内容（移動予測結果）］
図１３は、利用者４０および待ち合わせ相手に対して通過時刻の予測結果と特売情報を通知する画面の例について概要を示した図である。当該画面は、例えば、利用者４０および待ち合わせ相手に対して通知される電子メールの内容として直接表示されるものであってもよいし、当該電子メールに含まれる、アプリケーションサーバ２０によって当該画面を表示させるためのＵＲＬ（Uniform Resource Locator）を介して、アプリケーションサーバ２０の図示しないＷｅｂサーバプログラムにより生成して利用者４０の携帯端末１０に表示させるものであってもよい。

図１３の例では、下段の表において、「チェックポイント１」〜「チェックポイント３」および待ち合わせ場所の予想通過時刻の情報が表示され、上段の表には、各チェックポイントの予想通過時刻に商品やサービスの特売を行う予定の販売者（特売の広告主）の情報が一覧表示される。画面上部の宛名の欄は、自動的に設定・表示されるようにしてもよい。なお、図１３の例では、利用者４０が、「チェックポイント１」〜「チェックポイント３」を経て、最後のチェックポイントで待ち合わせを行うという移動経路（すなわち、出発、通過および到着するチェックポイントは合計４つ）を予定している場合を示している。待ち合わせは開始または途中のチェックポイントで行われてもよい。また、チェックポイントの数は４つに限るものではない。

アプリケーションサーバ２０は、上記の画面内容（もしくはＵＲＬ）を含む電子メールを、予め定められたタイミングで対象の利用者４０および待ち合わせ相手に送信する。電子メールを送信するタイミングは、例えば、利用者４０が通過時刻の予測設定を行った直後、もしくは、図８の画面における「保存条件を設定してください」欄の「適用曜日」の項目で利用者４０が選択した曜日に該当し、かつ移動経路における最初のチェックポイントである「チェックポイント１」の予想通過時刻より所定の時間（例えば５時間）前などとする。これにより、利用者４０および待ち合わせ相手は、実際に移動を行う前に移動に要する時間を詳細に予測することができ、かつ、移動経路付近で実施される特売の情報も事前に把握することが可能となる。

特売は、通常、購入者に移動コスト（来店コスト）を支払って来店してもらうための動機付けに利用され、購入者が来店時に他の商品も購入することで販売者は利益を得る。この特売情報を、特売時間に特売場所の付近を通過すると予想される旅行者（利用者４０）に提供することは、すなわち、来店コストがない、もしくは小さい利用者４０に特売情報を提供することになる。この場合、当該利用者４０は、特売情報の提供を受ける他の一般の者より、特売情報をより価値のある情報と評価することになり、特売を行う販売者の店舗等を訪問する確率が高くなり、結果として販売者にとって効果的な販売促進につながることになる。

なお、本実施の形態では、利用者４０に推奨する情報として、販売者が行う特売の情報を例としているが、これに限られない。移動を行う利用者４０にとって利益となるようなイベント等の情報を推奨するものであれば適用することができる。

以上に説明したように、本発明の実施の形態１であるチェックポイント管理システム１によれば、ＲＦＩＤタグ機能を有する携帯端末１０において、リーダ／ライタ装置４１からのポーリングコマンド等のコマンドの受信をトリガーとして所定のアプリケーション１５を起動して処理を行うことで、複数種類のリーダ／ライタ装置４１との間で通信を行うことが可能となる。そして、この仕組みを利用することで、例えば、携帯端末１０を保持して移動する旅行者等の利用者４０が、種々のリーダ／ライタ装置４１が設置された各地のチェックポイントにおいて携帯端末１０とリーダ／ライタ装置４１との通信を行うことで、各チェックポイントの通過日時の履歴情報を把握する。

そして、この履歴情報に基づいて、利用者４０の移動予定における各チェックポイントについての予想通過時刻を算出し、当該予測情報を、利用者４０および待ち合わせ相手に対して提供することで、例えば、乗り換えや待ち合わせ等で生じる待ち時間を低減し、利用者４０の効率的な移動を支援することが可能となる。さらに、販売者が行う特売等が行われる予定の場所および時間の情報と、利用者４０の各チェックポイントについての予想通過時間の情報に基づいて、利用者４０の移動経路上やその付近で実施予定の特売等のイベントの情報を推奨する。これにより、利用者４０が移動中にお得な商品やサービスの購入等することを支援することも可能となり、利用者４０（旅行者等）だけでなく、イベントの提供者（販売者等）も利益を得ることが可能となる。

（実施の形態２）
以下では、本発明の実施の形態２である携帯端末とリーダ／ライタ装置およびこれを用いたチェックポイント管理システムについて説明する。上述した実施の形態１では、携帯端末１０は、リーダ／ライタ装置４１が送信するポーリングコマンド等のコマンドを受け、これをトリガーとしてアプリケーション１５を起動する構成をとっていたのに対し、本実施の形態では、後述するように、リーダ／ライタ装置４１からのポーリングコマンドではなく、搬送波から得た起電力でＲＦＩＤタグ処理部１２の回路が起動したことをトリガーとして端末コントローラ１４がアプリケーション１５を起動するというものである。

［システム構成］
図１４は、本発明の実施の形態２であるチェックポイント管理システムの構成例について概要を示した図である。本実施の形態は、基本的には上述した実施の形態１と同様の構成を有している。実施の形態１では、アプリケーション１５およびアプリケーションサーバ２０は、チェックポイントの通過時刻の予測および予測結果に基づく特売情報の提供というサービスを実装したものであり、本実施の形態も同様に当該サービスに適用することが可能であるが、本実施の形態では、他の適用可能なサービスの例として、自動ゲートの開閉の制御および利用者４０への課金というサービスを実装するものとする。なお、当該サービスを実施の形態１の構成において適用することも当然可能である。

図１４の例では、上記サービスを実装するため、アプリケーションサーバ５０は、例えば、図示しないＯＳやＤＢＭＳ、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装されたチェックポイント管理部５１、リーダ／ライタ装置制御部５２、および課金処理部５３などの各部を有する。また、データベース等により実装された通過履歴ＴＢ５４、課金情報ＴＢ５６、チェックポイントマスタ５７、ユーザマスタ５８、および店舗・事業者マスタ５９などの各データストアを有する。

チェックポイント管理部５１、および通過履歴ＴＢ５４、チェックポイントマスタ５７、ユーザマスタ５８の各テーブルは、それぞれ、図１に示した実施の形態１のチェックポイント管理部２１、および通過履歴ＴＢ２４、チェックポイントマスタ２７、ユーザマスタ２８の各テーブルと同様であるため、詳細な説明は省略する。なお、実施の形態１におけるユーザマスタ２８は、利用者４０および販売者（すなわち広告主）の個人情報を保持していたのに対し、本実施の形態におけるユーザマスタ５８では、利用者４０の個人情報のみを保持するようにしてもよい。

リーダ／ライタ装置制御部５２は、利用者４０の携帯端末１０のアプリケーション１５からネットワーク３０を介して取得したチェックポイントの通過情報に基づいて、当該チェックポイントもしくは当該利用者４０の移動予定上のチェックポイントとして設置されたリーダ／ライタ装置４１の動作をリモートから制御する機能を有する。例えば、対象のリーダ／ライタ装置４１が属するシステムにおける事業者サーバ４２に対して、ネットワーク３０等を介して制御に係る情報を送信することで、各リーダ／ライタ装置４１を間接的に制御する。

課金処理部５３は、利用者４０の携帯端末１０のアプリケーション１５から取得したチェックポイントの通過情報および店舗・事業者マスタ５９等の登録情報などに基づいて、当該チェックポイントに対応するサービスの利用（例えば、電子マネーによる商品等の購買や、施設への入場等）に係る課金処理を行い、結果を課金情報ＴＢ５６に記録する機能を有する。図示しない対象のサービスを運営する事業者のシステム等（例えば、クレジット／デビットカード会社などの金融機関のシステムやネットワークなど）に接続して処理を行うものであってもよい。

なお、実施の形態１と同様に、各運営事業者の事業者サーバ４２は、ネットワーク３０などを介して相互に接続可能であってもよく、また、アプリケーションサーバ５０とも相互に接続可能であってもよい。事業者サーバ４２とアプリケーションサーバ５０とが統合された１つのサーバシステムとして構成されていてもよい。さらに、課金決済のサービスを提供する金融機関のシステムが有するサーバ等と統合されていてもよい。

［処理内容］
図１５は、本実施の形態におけるＦｅｌｉＣａプログラムを用いたリーダ／ライタ装置４１とＲＦＩＤタグ機能を有する携帯端末１０との間の通信処理の流れの例について概要を示したフローチャートである。本実施の形態では、実施の形態１と異なり、自動改札機やレジ等が有するリーダ／ライタ装置４１は、まず、搬送波のみを発して、ＲＦＩＤタグ機能を有する携帯端末１０が備えるアンテナに対して電力を供給する（Ｓ３１）。なお、実施の形態１と同様の従来技術であるＦｅｌｉＣａプログラムにより、搬送波とポーリングコマンドを発する形態であっても、搬送波により電力を供給することができるため、同様に利用可能である。

一方、携帯端末１０が保持するＲＦＩＤタグ（ＲＦＩＤタグ処理部１２）は、電源がＯＦＦの状態で待ち受け状態にあるが（Ｓ４１）、携帯端末１０が備えるアンテナにより搬送波から起電力を得て起動し（Ｓ４２）、端末コントローラ１４に対してトリガーを送信する（Ｓ４３）。その後のＲＦＩＤタグ処理部１２での処理（ステップＳ４４）、および端末コントローラ１４での処理（ステップＳ５１〜Ｓ５３）は、それぞれ、実施の形態１における図４に示した処理の流れ（ステップＳ１４、およびステップＳ２１〜Ｓ２３）と同様であるため再度の説明は省略する。

アプリケーション１５の起動方法や、起動時の個人情報等の取得方法、およびアプリケーション１５の終了方法などは、実施の形態１の場合と同様であるが、本実施の形態では、個人情報等を登録させるためのユーザ登録画面（図示しない）は、旅行者等の利用者４０に加えて、交通機関の事業者や販売者等に対してもそれぞれ設けられる。なお、交通機関の事業者や販売者等の個人情報等には、それぞれが有する事業者サーバ４２またはリーダ／ライタ装置４１に関する情報も含まれる。これらの各ユーザは、それぞれ、自身が使用する情報処理端末（利用者４０の場合は携帯端末１０を含む）を利用してネットワーク３０等を介してアプリケーションサーバ５０にアクセスし、個人情報等を入力するための画面を表示させる。

これらの各ユーザが、ユーザＩＤを含む必要な個人情報等をユーザ登録画面を介して入力し、画面上のボタンの押下等により送信を指示すると、各情報処理端末は、ユーザＩＤにその他の個人情報等を関連付けるか、ユーザＩＤを含む入力された個人情報等のそれぞれを互いに関連付けるかしてアプリケーションサーバ５０に送信する。アプリケーションサーバ５０では、受信した情報をユーザマスタ５８や店舗・事業者マスタ５９に記録する。

ユーザ登録画面は、交通機関の事業者や販売者等がそれぞれ運営するシステムの事業者サーバ４２によって表示される構成であってもよい。この場合、交通機関の事業者や販売者等の各ユーザは、それぞれ、自身が使用する情報処理端末を介して事業者サーバ４２にアクセスし、事業者サーバ４２上のＷｅｂサーバプログラムなどを介してユーザ登録画面を取得することができる。旅行者（利用者４０）の個人情報については、実施の形態１と同様に、携帯端末１０のアプリケーション１５などがユーザ登録画面を表示させる構成としてもよい。

なお、上述したように、本実施の形態では、携帯端末１０では、リーダ／ライタ装置４１からの搬送波を受けるのみで、実施の形態１と異なりポーリングコマンド等も必要としない。すなわち、携帯端末１０は、ＲＦＩＤタグ機能を実現するためのＩＣチップもしくはＲＦＩＤタグ処理部１２を有しない構成であってもよく、リーダ／ライタ装置４１からの搬送波を受けて端末コントローラ１４にトリガーを送信できる構成であればよい。例えば、搬送波から得られる起電力を抵抗器や増幅器もしくは整流器等で調節し、タイマー装置によって予め定めた電圧と電流を一定時間端末コントローラ１４に送ることでトリガーとする構成とすることができる。または、端末コントローラ１４が、搬送波によって得られる予め定められた電流と電圧を、予め定められた間隔で確認する構成であってもよい。

［画面内容（チェックポイント登録）］
図１６は、交通機関の事業者や販売者等が有するリーダ／ライタ装置４１をチェックポイントとして登録する画面の例について概要を示した図である。ここでは、事業者等のユーザが、各事業者等が有するリーダ／ライタ装置４１を有する自動改札機や自動ゲート、店舗のレジ、コインロッカー、自動販売機等の設置場所を、チェックポイントとして登録することができる。ここで、「日時」、「チェックポイントＩＤ」および「緯度、経度」の欄の値は自動的に設定・表示されるようにしてもよい。図１６に示す画面は、例えば、アプリケーションサーバ５０により表示される。各事業者等がそれぞれ有する事業者サーバ４２により表示される構成であってもよい。各事業者等のユーザは、それぞれ、自身が使用する情報処理端末を介してアプリケーションサーバ５０や事業者サーバ４２にアクセスし、これらのサーバ上のＷｅｂサーバプログラムなどを介して当該画面を取得することができる。

なお、アプリケーションサーバ５０は、各事業者等のユーザが使用する情報処理端末（携帯型であるか据置型であるかを問わない）を含む外部からのアクセスがあった場合に、ユーザＩＤおよびパスワード、もしくは携帯端末ＩＤを要求し、店舗・事業者マスタ５９等に保持するユーザＩＤおよびパスワード、もしくは携帯端末ＩＤと一致した場合にのみアクセスを許可するようにしてもよい。各事業者等がそれぞれ有する事業者サーバ４２についても、一般的な認証機能を備えているものとする。

図１６の画面において、各事業者等のユーザが、チェックポイントの位置や種類などの情報を入力・選択して「設定」ボタンを押下すると、当該情報処理端末は、各事業者等のユーザＩＤに入力、選択および自動表示された情報を関連付けるか、ユーザＩＤを含む入力、選択および自動表示された情報のそれぞれを互いに関連付けるかしてアプリケーションサーバ５０に送信する。アプリケーションサーバ５０では、受信した情報をチェックポイントマスタ５７に記録する。さらに各事業者がそれぞれ有する事業者サーバ４２に記録するようにしてもよい。

なお、図１６の画面における「チェックポイントＩＤ」の項目は、例えば、各事業者がそれぞれ運営するシステムが有する自動改札機やレジ等のリーダ／ライタ装置４１を有する機器や装置のＩＤ情報と同一とする。もしくは、異なる値とする場合は、チェックポイントの設定情報を受けて登録するアプリケーションサーバ５０や各事業者が有する事業者サーバ４２において、チェックポイントＩＤを、対応する自動改札機やレジ等の機器や装置のＩＤ情報と関連付けて記録する。これにより、各チェックポイントとリーダ／ライタ装置４１との対応関係を把握可能とする。

［画面内容（チェックポイント検出）］
図１７は、利用者４０が携帯端末１０をチェックポイントのリーダ／ライタ装置４１と通信させた際のチェックポイントの検出画面の例について概要を示した図である。ここでは、旅行者等のユーザが、移動経路上にある種々のリーダ／ライタ装置４１を有するチェックポイント（例えば、自動改札機や店舗のレジ、コインロッカー、自動販売機、事業所の自動ゲート等）において、ＲＦＩＤタグ機能を有する携帯端末１０をリーダ／ライタ装置４１に近付けて通信させた際に、携帯端末１０に表示される画面の例を示している。当該画面は、携帯端末１０のアプリケーション１５が直接生成して表示してもよいし、ネットワーク３０を介してアプリケーションサーバ５０にアクセスして、アプリケーションサーバ５０により生成されたＷｅｂページを表示するようにしてもよい。

図１７の例に示した画面において、「検出日時」の項目は、旅行者（利用者４０）の携帯端末１０が、チェックポイントのリーダ／ライタ装置４１と通信を行った日時の情報が自動的に設定・表示される。トリガーによりアプリケーション１５が起動（動作)した日時の情報が自動的に設定・表示されるようにしてもよい。それ以降の欄では、利用者４０に対して当該チェックポイントを特定するための位置や関連情報などについて、プルダウンリスト等により情報の選択を促す構成となっている。地図上に表示されたマークを選択することでチェックポイントを特定してもよい（プルダウンリストの内容と地図上でのマークの情報は相互に関連付けられており、いずれか一方を指定することでチェックポイントを特定することができるものとする）。なお、プルダウンリストに表示される内容は、各事業者等のユーザにより、図１６に示した画面を介して予め登録され、アプリケーションサーバ５０のチェックポイントマスタ５７に記録されている情報である。

携帯端末１０のＧＰＳ処理部１１により得られる利用者４０の現在位置（緯度および経度）の情報に基づいて、その時点で最も近くに存在するチェックポイントが一意に特定できる場合は、図１７の画面のプルダウンリストには当該チェックポイントに係る情報のみを表示する。もしくは、当該画面によるチェックポイントの特定自体を省略し、携帯端末１０（アプリケーション１５）もしくはアプリケーションサーバ５０のチェックポイント管理部５１により、自動的にチェックポイントを特定することも可能である。また、チェックポイントを一意に特定することはできないものの、所定の距離内（例えば、半径１００ｍ以内）にあるチェックポイントをチェックポイントマスタ５７から複数抽出できる場合は、抽出された各チェックポイントの情報をプルダウンリストに表示するようにしてもよい。

図１７の画面において、旅行者（利用者４０）が対象のチェックポイントとして適した情報を選択して「送信」ボタンを押下すると、携帯端末１０（アプリケーション１５）は、入力、選択および自動表示された情報を当該利用者４０のユーザＩＤもしくは携帯端末１０のＩＤに関連付けるか、ユーザＩＤ若しくは携帯端末１０のＩＤを含む各情報を相互に関連付けてアプリケーションサーバ５０に送信する。

アプリケーションサーバ５０は、チェックポイント管理部５１により、受信したチェックポイントＩＤ等の情報、およびチェックポイントマスタ５７や店舗・事業者マスタ５９などの内容に基づいて該当するチェックポイントを特定するとともに、当該チェックポイントに係るリーダ／ライタ装置４１を運営する事業者およびチェックポイントの種類等を特定する。

そして、リーダ／ライタ装置制御部５２により、特定された事業者等が有する事業者サーバ４２に対して、当該チェックポイントが有するリーダ／ライタ装置４１の操作を要求する。例えば、チェックポイントが有するリーダ／ライタ装置４１が自動改札機の入場ゲートや自動ゲートなどの場合は、ゲートの開閉や入場に係る情報（日時、場所、利用者４０など）の記録を、交通機関の運営事業者や企業等が有する事業者サーバ４２に対して指示する。指示を受けた事業者サーバ４２では、特定されたチェックポイントが有するリーダ／ライタ装置４１（自動改札機や自動ゲート等）に対して、ゲートの開閉や入場の記録などの動作をリモートから実行させる。同様に、リーダ／ライタ装置４１がコインロッカー（施錠時）の場合は、施錠を行う際に、施錠や利用に係る情報の記録を実行させる。

また、特定されたチェックポイントが有するリーダ／ライタ装置４１がレジ等の場合は、当該チェックポイントが有するリーダ／ライタ装置４１が、図１６の画面における「検出日時」のタイミングで画面等により旅行者（利用者４０）に対して表示・出力している情報を、事業者等が有する事業者サーバ４２が当該リーダ／ライタ装置４１から取得し、これを当該利用者４０が保持する携帯端末１０にアプリケーションサーバ５０を介して送信する。

すなわち、チェックポイントが有するリーダ／ライタ装置４１がレジ等の場合、図１６の画面における「検出日時」の情報は、利用者４０が商品やサービスを購入したタイミングを示していることから、その際にリーダ／ライタ装置４１が利用者４０に対して表示・出力している情報は、利用者４０が購入しようとする商品やサービスに係る各種情報（例えば、商品／サービスの名称や、容量、入数、サイズ、グレード、購入数量、単価、合計金額等）である。本実施の形態では、当該情報を利用者４０が保持する携帯端末１０に対して送信する。

このとき、携帯端末１０は、例えば、受信した商品やサービスに係る情報を表示するとともに、利用者４０に承認や同意、確認などを要求する画面を表示することができる。利用者４０が画面に表示されたボタンを押下する等により承認や同意等を行うと、アプリケーション１５（およびアプリケーションサーバ５０の課金処理部５３）は、課金決済の処理を行う。

課金決済は、例えば、利用者４０が予めユーザ登録時等に登録したクレジット／デビットカードの情報を用いて行われる。課金決済の情報（例えば、利用者４０が購買しようとする商品／サービスおよび購買店舗の情報、購買日時、課金額など）および利用者４０のクレジット／デビットカードの情報は、携帯端末１０もしくはアプリケーションサーバ５０の課金処理部５３から、クレジット／デビットカード会社などの金融機関のサーバに送信される。金融機関のサーバは、所定の決済処理を行った後、アプリケーションサーバ５０の課金処理部５３に対して決済情報を送信する。その後、アプリケーションサーバ５０の課金処理部５３から、携帯端末１０および事業者サーバ４２に対して決済情報を送信する。

販売者の有する事業者サーバ４２が独自に課金の仕組みを有している場合には、これを用いることも可能である。例えば、販売者は、通常、クレジットカード会社等と提携して、上記と同様の課金の仕組みを有しているため、これを用いることができる。この場合、例えば、携帯端末１０のアプリケーション１５は、利用者４０のクレジット／デビットカードの情報を、アプリケーションサーバ５０から販売者の有する事業者サーバ４２に対して送信し、独自の仕組みにより課金決済を行う。

課金決済が完了すると、事業者サーバ４２は、完了した課金決済の情報の少なくとも一部を、リーダ／ライタ装置４１（レジやコインロッカー、自動販売機等）が有する画面に表示する。課金決済の情報をアプリケーションサーバ５０の課金情報ＴＢ５６に記録するようにしてもよい。

リーダ／ライタ装置４１（チェックポイント）が自動改札機の退場ゲート、コインロッカー（開錠時）、自動販売機などの場合は、課金決済に加えて、上述したようにゲートの開閉や退場に係る情報の記録、もしくは開錠や商品の放出に係る動作を事業者サーバ４２に対して指示する。課金決済の処理は、上述したように、携帯端末１０のアプリケーション１５（およびアプリケーションサーバ５０の課金処理部５３）により行なってもよいし、交通機関の事業者等が有する事業者サーバ４２が独自に有する課金の仕組みにより行ってもよい。

［効果］
以上に説明したように、本発明の実施の形態１および２の携帯端末１０およびアプリケーションサーバ２０（アプリケーションサーバ５０）、さらにこれらを用いたチェックポイント管理システム１によれば、ＲＦＩＤタグ機能を有する携帯端末１０において、リーダ／ライタ装置４１からのポーリングコマンド等のコマンド、もしくは搬送波の受信をトリガーとして所定のアプリケーション１５を起動して処理を行うことで、複数種類のリーダ／ライタ装置４１との間で通信を行うことが可能となる。これにより、各チェックポイントのリーダ／ライタ装置４１の制御プログラムの相違や、その上位システムのプログラム（例えば、提携関係のある鉄道事業者と販売事業者との間で共同利用されている課金システムのプログラムなど）の利用有無などに関わらず、旅行者等の利用者４０の移動経路上にあるリーダ／ライタ装置４１を利用し、かつチェックポイントとすることができる。

例えば、システムの共同利用の有無に関わらず、各鉄道事業者、各航空会社、各バス事業者、各社の自動販売機、各社のコインロッカー、各コンビニエンスストアのレジ、各企業の入退場ゲートなどのリーダ／ライタ装置４１を利用することができる。これにより、例えば、特定の交通機関およびこれと提携する販売者の店舗におけるチェックポイント間の移動に留まらず、提携範囲を超えた移動においても、チェックポイントを利用して、通過情報を一元的に把握することができ、チェックポイントの通過予想時間や、移動経路上での特売情報などを提供することができる。これにより、例えば、旅行者（利用者４０）は、提携関係の異なる（提携関係にない）交通機関の間の乗換時間の予測や、全体の旅行時間の予測を行うことが可能となる。

特に、運行遅延が発生することが多い航空機を利用した海外旅行では、空港での待ち時間、航空機の乗り継ぎ時間および航空機から陸上交通への乗り継ぎ時間等が大きくばらつき、移動時間の予測が難しい。また、移動に際して、複数の交通機関の運営事業者を利用する場合や、国をまたがった移動をする際には、１つのＲＦＩＤタグでチェックポイントの通過を管理することは困難であり、本発明の実施の形態１および２に係る仕組みの普及によりこれらの課題が解決されることが期待される。

さらに、旅行者（利用者４０）は移動中に各種の支払をする。例えば、移動中に飲食したり、土産物を購入したり、交通費を支払ったり、宿泊したり、レジャーを楽しんだりする。これらの支払いは、１つの事業者のみに対して行われるのではなく、また１地点のみで行われるものでもない。移動経路の様々な場所で様々な事業者に対して行われる。支払先の事業者や支払場所によって利用できる課金決済システムが異なる場合は、利用者４０は、それぞれの課金決済システムに対応するＲＦＩＤタグを有していることが必要になる。しかし、本発明の実施の形態１および２に係る仕組みによれば、１つのＲＦＩＤタグを有することで全ての支払いが可能となる。

現在、日本の主要な鉄道事業者は、自動改札機を各駅に設置し、乗客の持つＲＦＩＤタグ機能付携帯端末の利用を可能にしており、主要鉄道各社は乗客の利便性を考慮して、自社のＲＦＩＤタグ機能が他社設置の自動改札機でも使える相互利用を実現している。しかしながら、上記の相互利用に参加していない鉄道事業者は、自社の乗客の持つＲＦＩＤタグ機能付携帯端末を他社の駅に設置された自動改札機で利用させることができない。例えば、地方の私鉄運営会社（ローカル鉄道会社）が人件費削減を目的に各駅に自動改札機を設置しても、主要鉄道各社が参加するＲＦＩＤタグ機能付携帯端末の相互利用の仕組みに参加しなければ、当該ローカル鉄道会社の乗客は、主要鉄道各社の駅に設置された自動改札機を通過することはできない。この場合、当該主要鉄道会社の乗車券を購入する等の対応を行う必要があり、利便性が高いとは言えない。

また、相互利用に参加している鉄道事業者であっても、自社の乗客が相互利用に参加していない鉄道事業者の駅の自動改札を通過する際に自社のＲＦＩＤタグ機能付携帯端末を利用させることはできない。例えば、相互利用の仕組みに参加している主要鉄道各社のＲＦＩＤタグ機能付携帯端末を持つ乗客が、海外旅行で外国の鉄道を利用する場合、当該主要鉄道会社と当該外国鉄道会社との間の相互利用の仕組みがなければ、旅行先の駅で乗車券を購入する等の対応を行う必要がある。生活、文化、言語等の異なる慣れない外国で乗車券を正しく購入して乗車することは容易な作業ではない。

これに対し、本発明の実施の形態１および２の仕組みによれば、例えば、経済的に余裕のない地方鉄道事業者であっても、外国の交通機関事業者であっても、また個人事業主の経営する小さな小売店または飲食店であっても、安価な汎用型のリーダ／ライタ装置を設置することで、一つのＲＦＩＤタグ機能付携帯端末での利用を可能とすることができる。また、ＲＦＩＤタグ機能付携帯端末を持つ旅行者等の利用者４０は、交通機関や店舗等の運営事業者や地域、国などの違いによる制限を受けず、旅先や移動先に設置された様々なパッシブ型ＲＦＩＤタグのリーダ／ライタ装置を利用することができる。

電子マネー技術は既に実現しているが、装置の用途が限定されている上に高価であるため、ほとんど全ての事業者に普及しているとは言えない。そのため、現金を持たずに国内外を旅行（移動）することは現実的には困難である。しかし、本発明の実施の形態１および２の仕組みによれば、安価な汎用リーダ／ライタ装置をほとんど全ての事業者に普及させることができ、キャッシュレスの旅行（移動）が本格的に実現することを期待できる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

例えば、上記の実施の形態１および２では、移動物体として旅行者（利用者４０）を例に挙げて説明したが、移動物体は、車両または歩行ロボットなどの物であってもよい。この場合、例えば、携帯端末１０の画面に表示されるチェックポイントの入力・選択画面や、課金決済時の商品・サービスに関する情報を表示する画面等は、他の遠隔地においてユーザが操作する情報処理端末に表示され、当該ユーザは、当該情報処理端末への操作や入力等によって処理を行う。この場合、例えば、チェックポイントが自動ゲートであり、ユーザが通過しようとする自動ゲートを、携帯端末１０のＧＰＳ処理部１１によって得られる位置情報などから特定できる場合は、ユーザが遠隔操作を行う必要はない。

本発明は、ＲＦＩＤタグのリーダ／ライタ機能を有する装置や機器との間で通信を行い、パッシブ型ＲＦＩＤタグとして機能する携帯端末や携帯端末プログラム、およびこのような携帯端末を用いたチェックポイント管理システムやチェックポイント管理方法に利用可能である。

１…チェックポイント管理システム、
１０…携帯端末、１１…ＧＰＳ処理部、１２…ＲＦＩＤタグ処理部、１３…通信部、１４…端末コントローラ、１５…アプリケーション、１６…利用者・端末情報、
２０…アプリケーションサーバ、２１…チェックポイント管理部、２２…予測処理部、２３…推奨情報管理部、２４…通過履歴ＴＢ、２５…移動予定情報ＴＢ、２６…予測設定情報ＴＢ、２７…チェックポイントマスタ、２８…ユーザマスタ、２９…店舗マスタ、
３０…ネットワーク、
４０…利用者、４１…リーダ／ライタ装置、４２…事業者サーバ、
５０…アプリケーションサーバ、５１…チェックポイント管理部、５２…リーダ／ライタ装置制御部、５３…課金処理部、５４…通過履歴ＴＢ、５６…課金情報ＴＢ、５７…チェックポイントマスタ、５８…ユーザマスタ、５９…店舗・事業者マスタ

Claims (16)

1. パッシブ型ＲＦＩＤタグのリーダ／ライタ装置と非接触通信を行う携帯端末であって、
   アプリケーションサーバとの間で通信を介して連携するアプリケーション処理部と、
   前記携帯端末の現在位置情報を取得する位置情報取得部と、
   前記リーダ／ライタ装置から発信された搬送波もしくはコマンドに係る信号を受信してトリガーを出力するＲＦＩＤタグ処理部と、
   前記トリガーを受けて前記アプリケーション処理部を動作させる端末コントローラと、を有し、
   前記アプリケーション処理部は、前記携帯端末の利用者の識別情報を含む個人情報もしくは前記携帯端末の識別情報、および前記アプリケーション処理部が動作した日時または前記リーダ／ライタ装置と前記ＲＦＩＤタグ処理部が通信を行った日時の情報を前記携帯端末から取得し、前記位置情報取得部により取得した前記現在位置情報に基づいて特定した前記リーダ／ライタ装置に係るチェックポイントの情報と併せて前記アプリケーションサーバに送信する、携帯端末。
2. パッシブ型ＲＦＩＤタグのリーダ／ライタ装置と非接触通信を行う携帯端末であって、
   アプリケーションサーバとの間で通信を介して連携するアプリケーション処理部と、
   前記携帯端末の現在位置情報を取得する位置情報取得部と、
   前記リーダ／ライタ装置から発信された搬送波もしくはコマンドに係る信号を受信して前記アプリケーション処理部を動作させる端末コントローラと、を有し、
   前記アプリケーション処理部は、前記携帯端末の利用者の識別情報を含む個人情報もしくは前記携帯端末の識別情報、および前記アプリケーション処理部が動作した日時または前記リーダ／ライタ装置と前記端末コントローラが通信を行った日時の情報を前記携帯端末から取得し、前記位置情報取得部により取得した前記現在位置情報に基づいて特定した前記リーダ／ライタ装置に係るチェックポイントの情報と併せて前記アプリケーションサーバに送信する、携帯端末。
3. 請求項１または２に記載の携帯端末において、
   前記アプリケーション処理部は、前記アプリケーションサーバに予め登録された複数の前記チェックポイントから前記現在位置情報に基づいて前記アプリケーションサーバによって抽出された１つ以上の前記チェックポイントのうち、前記リーダ／ライタ装置に係る前記チェックポイントを前記利用者に選択させることで特定する、携帯端末。
4. パッシブ型ＲＦＩＤタグのリーダ／ライタ装置と、
   前記リーダ／ライタ装置と非接触通信を行う請求項１または２のいずれか１項に記載の携帯端末と、
   前記携帯端末と通信可能なアプリケーションサーバと、を有するチェックポイント管理システムであって、
   前記アプリケーションサーバは、
   前記携帯端末から送信された情報を、前記利用者が出発、通過、または到着した前記チェックポイントについての履歴情報として記録する、チェックポイント管理システム。
5. 請求項４に記載のチェックポイント管理システムにおいて、
   前記アプリケーションサーバは、
   複数の前記チェックポイントに係るマスタ情報を保持しており、
   指定された位置情報に基づいて所定の距離範囲内に所在する前記チェックポイントの情報を前記マスタ情報から抽出するチェックポイント管理部を有し、
   前記携帯端末の前記アプリケーション処理部は、
   前記現在位置情報に基づいて前記アプリケーションサーバによって抽出された１つ以上の前記チェックポイントのうち、前記リーダ／ライタ装置に係る前記チェックポイントを前記利用者に選択させることで特定する、チェックポイント管理システム。
6. 請求項４または５に記載のチェックポイント管理システムにおいて、
   前記アプリケーションサーバは、さらに、前記利用者が出発、通過または到着する予定の１つ以上の前記チェックポイント、および利用する交通機関の情報を受け付けて、前記履歴情報に記録された情報を統計処理することにより、前記各チェックポイントの出発、通過または到着の時刻に係る予想または予想区間を算出して移動予定情報として出力する予測処理部を有する、チェックポイント管理システム。
7. 請求項６に記載のチェックポイント管理システムにおいて、
   前記アプリケーションサーバは、販売者が行うイベントに係る広告の出力条件の情報を含む、前記販売者に係るマスタ情報を保持しており、
   さらに、前記移動予定情報に含まれる前記各チェックポイントの出発、通過または到着の時刻に係る前記予想または前記予想区間の情報と、前記販売者に係るマスタ情報に登録された前記広告の出力条件とに基づいて、前記利用者が出発、通過または到着する予定の前記各チェックポイントから所定の距離範囲内において実施される予定の前記イベントの情報を抽出して出力する推奨情報管理部を有する、チェックポイント管理システム。
8. 請求項４〜７のいずれか１項に記載のチェックポイント管理システムにおいて、
   前記アプリケーションサーバは、さらに、前記利用者が出発、通過、または到着した、もしくはする予定の前記チェックポイントに設置された前記リーダ／ライタ装置に対する動作の指示を出力するリーダ／ライタ装置制御部を有する、チェックポイント管理システム。
9. 請求項４〜８のいずれか１項に記載のチェックポイント管理システムにおいて、
   前記アプリケーションサーバは、さらに、前記利用者が出発、通過、または到着した前記チェックポイントに対応するサービスの利用に係る課金処理を行う課金処理部を有する、チェックポイント管理システム。
10. パッシブ型ＲＦＩＤタグのリーダ／ライタ装置と、
    前記リーダ／ライタ装置と非接触通信を行う携帯端末と、
    前記携帯端末と通信可能なアプリケーションサーバと、を有する情報処理システムにおけるチェックポイント管理方法であって、
    前記携帯端末が、現在位置情報を取得する位置情報取得ステップと、
    前記携帯端末が、前記リーダ／ライタ装置から発信された搬送波もしくはコマンドに係る信号を受信した際にトリガーを出力するステップと、
    前記携帯端末が、前記トリガーに基づいて、前記アプリケーションサーバとの間で通信を介して連携するアプリケーション処理を実行するステップと、
    前記アプリケーションサーバが、前記携帯端末から送信された情報を、前記利用者が出発、通過、または到着した前記チェックポイントについての履歴情報として記録するステップと、を有し、
    前記アプリケーション処理は、前記携帯端末の利用者の識別情報を含む個人情報もしくは前記携帯端末の識別情報、および前記アプリケーション処理が実行された日時または前記リーダ／ライタ装置と前記ＲＦＩＤタグ処理部が通信を行った日時の情報を前記携帯端末から取得し、前記位置情報取得ステップにより取得した前記現在位置情報に基づいて特定した前記リーダ／ライタ装置に係るチェックポイントの情報と併せて前記アプリケーションサーバに送信するものである、チェックポイント管理方法。
11. パッシブ型ＲＦＩＤタグのリーダ／ライタ装置と、
    前記リーダ／ライタ装置と非接触通信を行う携帯端末と、
    前記携帯端末と通信可能なアプリケーションサーバと、を有する情報処理システムにおけるチェックポイント管理方法であって、
    前記携帯端末が、現在位置情報を取得する位置情報取得ステップと、
    前記携帯端末が、前記リーダ／ライタ装置から発信された搬送波もしくはコマンドに係る信号を受信した際に、前記アプリケーションサーバとの間で通信を介して連携するアプリケーション処理を実行するステップと、
    前記アプリケーションサーバが、前記携帯端末から送信された情報を、前記利用者が出発、通過、または到着した前記チェックポイントについての履歴情報として記録するステップと、を有し、
    前記アプリケーション処理は、前記携帯端末の利用者の識別情報を含む個人情報もしくは前記携帯端末の識別情報、および前記アプリケーション処理が実行された日時または前記リーダ／ライタ装置と前記ＲＦＩＤタグ処理部が通信を行った日時の情報を前記携帯端末から取得し、前記位置情報取得ステップにより取得した前記現在位置情報に基づいて特定した前記リーダ／ライタ装置に係るチェックポイントの情報と併せて前記アプリケーションサーバに送信するものである、チェックポイント管理方法。
12. 請求項１０または１１のいずれか１項に記載のチェックポイント管理方法において、
    さらに、前記アプリケーションサーバが、複数の前記チェックポイントに係るマスタ情報を保持するステップと、
    前記アプリケーションサーバが、指定された位置情報に基づいて所定の距離範囲内に所在する前記チェックポイントの情報を前記マスタ情報から抽出するステップと、を有し、
    前記携帯端末の前記アプリケーション処理は、前記現在位置情報に基づいて前記アプリケーションサーバによって抽出された１つ以上の前記チェックポイントのうち、前記リーダ／ライタ装置に係る前記チェックポイントを前記利用者に選択させることで特定する、チェックポイント管理方法。
13. 請求項１０〜１２のいずれか１項に記載のチェックポイント管理方法において、
    さらに、前記アプリケーションサーバが、前記利用者が出発、通過または到着する予定の１つ以上の前記チェックポイント、および利用する交通機関の情報を受け付けて、前記履歴情報に記録された情報を統計処理することにより、前記各チェックポイントの出発、通過または到着の時刻に係る予想または予想区間を算出して移動予定情報として出力するステップを有する、チェックポイント管理方法。
14. 請求項１３に記載のチェックポイント管理方法において、
    さらに、前記アプリケーションサーバが、販売者が行うイベントに係る広告の出力条件の情報を含む、前記販売者に係るマスタ情報を保持するステップと、
    前記アプリケーションサーバが、前記移動予定情報に含まれる前記各チェックポイントの出発、通過または到着の時刻に係る前記予想または前記予想区間の情報と、前記販売者に係るマスタ情報に登録された前記広告の出力条件とに基づいて、前記利用者が出発、通過または到着する予定の前記各チェックポイントから所定の距離範囲内において実施される予定の前記イベントの情報を抽出して出力するステップと、を有する、チェックポイント管理方法。
15. 請求項１０〜１４のいずれか１項に記載のチェックポイント管理方法において、
    さらに、前記アプリケーションサーバが、前記利用者が出発、通過、または到着した、もしくはする予定の前記チェックポイントに設置された前記リーダ／ライタ装置に対する動作の指示を出力するステップを有する、チェックポイント管理方法。
16. 請求項１０〜１５のいずれか１項に記載のチェックポイント管理方法において、
    さらに、前記アプリケーションサーバが、前記利用者が出発、通過、または到着した前記チェックポイントに対応するサービスの利用に係る課金処理を行うステップを有する、チェックポイント管理方法。