(57)【要約】  駅（Ｓ１１…Ｓ００）間の旅のために旅客輸送システム（ＶＳＹ）の輸送手段（ＶＭ１、ＶＭ２）に乗車および／または下車するための駅（Ｓ１１…Ｓ００）を備える旅客輸送システム（ＶＳＹ）内で旅のチケットを取得するための方法であって、システム（ＶＳＹ）の少なくとも１つの駅（Ｓ１１…Ｓ００）に少なくとも１つの非接触読取り可能データ・キャリア（Ｔ１１…Ｔ００）が割り当てられ、および／またはシステム（ＶＳＹ）の少なくとも１つの輸送手段（ＶＭ１、ＶＭ２）に少なくとも１つの非接触読取り可能データ・キャリア（Ｔ１０、Ｔ２０）が割り当てられ、非接触読取り可能データ・キャリア（Ｔ１１…Ｔ００；Ｔ１０、Ｔ２０）がチケット情報アイテム（ＩＮ１１、ＩＮ２３、ＩＮ００）を含み、非接触読取り可能データ・キャリア（Ｔ１１…Ｔ００；Ｔ１０、Ｔ２０）のうちの１つが、少なくとも１つの駅（Ｓ１１…Ｓ００）および／または少なくとも１つの輸送手段（ＶＭ１、ＶＭ２）内でモバイル・リーダ（ＭＯＤ）によって読み取られ、対応する１つまたは複数のチケット情報アイテム（ＩＮ１１、ＩＮ２３、ＩＮ００）がモバイル・リーダ（ＭＯＤ）内に格納される。
2008509471.tif 000002
【特許請求の範囲】
【請求項１】
駅間の旅のために旅客輸送システムの輸送手段に乗車および／または下車するための前記駅を備える前記旅客輸送システム内で旅のチケットを取得するための方法であって、
前記システムの少なくとも１つの駅に少なくとも１つの非接触読取り可能データ・キャリアが割り当てられ、および／または前記システムの少なくとも１つの輸送手段に少なくとも１つの非接触読取り可能データ・キャリアが割り当てられ、
前記非接触読取り可能データ・キャリアがチケット情報アイテムを含み、
前記非接触読取り可能データ・キャリアのうちの１つが、少なくとも１つの駅および／または少なくとも１つの輸送手段内でモバイル・リーダによって読み取られ、
前記対応する１つまたは複数のチケット情報アイテムが前記モバイル・リーダ内に格納される方法。
【請求項２】
駅および／または輸送手段に割り当てられた前記少なくとも１つの非接触読取り可能データ・キャリアが、前記それぞれの駅または前記それぞれの輸送手段を一意に識別する駅固有または輸送手段固有のチケット情報アイテムを含み、前記モバイル・リーダによって読み取られた前記チケット情報アイテムが運賃計算のために使用される請求項１に記載の方法。
【請求項３】
ａ）出発駅でその駅に割り当てられた非接触読取り可能データ・キャリアが読み取られ、前記対応する第１のチケット情報アイテムが前記モバイル・リーダ内に格納され、
ｂ）到着駅でその駅に割り当てられた非接触読取り可能データ・キャリアが読み取られ、前記対応する第２のチケット情報アイテムが前記モバイル・リーダ内に少なくともバッファ格納され、
ｃ）前記旅の運賃が前記第１および第２のチケット情報アイテムから決定される請求項２に記載の方法。
【請求項４】
前記運賃を決定するのに到着駅の非接触読取り可能データ・キャリアのチケット情報アイテムが使用できない場合は、固定して事前定義された運賃が決定される請求項３に記載の方法。
【請求項５】
前記チケット情報アイテムからの前記運賃の決定が前記モバイル・リーダ内で実施される請求項１に記載の方法。
【請求項６】
前記モバイル・リーダ内に少なくともバッファ格納された前記チケット情報アイテムが、前記運賃の決定のためにリモート計算サーバに送信される請求項１に記載の方法。
【請求項７】
前記チケット情報アイテムが前記モバイル・リーダのセキュア・メモリ内に格納される請求項１に記載の方法。
【請求項８】
パッシブ非接触読取り可能データ・キャリアが前記駅および／または前記輸送手段内で使用され、それに割り当てられる請求項１ないし７のいずれかに記載の方法。
【請求項９】
駅間の旅のために旅客輸送システムの輸送手段に乗車および下車するための前記駅を備える前記旅客輸送システムであって、前記システムの少なくとも１つの駅および／または少なくとも１つの輸送手段に、少なくとも１つの読取り可能チケット情報アイテムを含む少なくとも１つの非接触読取り可能データ・キャリアが割り当てられるシステム。
【請求項１０】
駅におよび／または輸送手段に割り当てられた前記少なくとも１つの非接触読取り可能データ・キャリアが、前記それぞれの駅または前記それぞれの輸送手段を一意に識別する駅固有または輸送手段固有のチケット情報アイテムを含む請求項９に記載のシステム。
【請求項１１】
モバイル・リーダから送信される非接触読取り可能データ・キャリアの前記チケット情報アイテムに基づいて運賃を決定するための少なくとも１つの計算サーバを備える請求項９に記載のシステム。
【請求項１２】
前記非接触読取り可能データ・キャリアに結合されたアクセス・バリアが前記駅内に設けられ、前記アクセス・バリアが、前記非接触読取り可能データ・キャリアが読み取られた後にだけ前記駅への入場および退出を可能にするために開かれる請求項９に記載のシステム。
【請求項１３】
前記非接触読取り可能データ・キャリアがパッシブ・データ・キャリアである請求項９ないし１２のいずれかに記載のシステム。
【請求項１４】
モバイル・リーダによって読み取られる前記非接触読取り可能データ・キャリアのチケット情報アイテムを受信し、これらのチケット情報アイテムに基づいて運賃を決定するように設計される請求項９ないし１３に記載のシステムのための計算サーバ。
【請求項１５】
非接触読取り可能データ・キャリア内に収容されるチケット情報アイテムを読み取る手段と、
前記対応する１つまたは複数のチケット情報アイテムを格納する手段と、
前記チケット情報アイテムから運賃を決定する手段、または前記格納されたチケット情報アイテムを、運賃を決定するリモート計算サーバに送信する手段と、を備えるモバイル・リーダ。
【請求項１６】
駅または輸送手段の名前が現れ、またはこの駅またはこの輸送手段を表す別の記号が配列される位置に固定されて、前記それぞれの駅または前記それぞれの輸送手段を一意に識別する駅固有または輸送手段固有のチケット情報アイテムを含む非接触読取り可能データ・キャリアが存在する時刻表。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、駅間の旅のために旅客輸送システムの輸送手段に乗車しおよび／または下車するための駅を備える旅客輸送システム内で旅のチケットを取得するための方法に関する。
【０００２】
本発明はさらに、上述のタイプの旅客輸送システム、ならびに本発明による方法を実施するための計算サーバ、モバイル・リーダおよび時刻表に関する。
【背景技術】
【０００３】
例えばいわゆる非接触チップ・カードなど、非接触読取り可能データ・キャリアの多くの応用分野がある。例を挙げると、こうした非接触読取り可能データ・キャリアを用いた建物の出入管理が知られている。この場合、出入許可されたユーザは、こうしたデータ・キャリアを備える社員バッジを有し、データ・キャリアが複数桁の一意の通し番号を含む。データ・キャリアは、建物に設置されたリーダによって読み取られ、その有効性についてチェックされ、それが有効である場合は、建物に入るためのドア、回転ドアなどが制御ユニットによって開かれる。
【０００４】
例えばフットボール・スタジアムの出入管理のためのチケット・システムは、同じように動作する。このため、スタジアムの入口エリアにはリーダが設置されており、リーダは、非接触読取り可能データ・キャリアが備わった対応する入場チケットを読み取り、適切な場合には、（例えばやはり回転ドアを介して）入場を可能にしても良い。
【０００５】
非接触読取り可能データ・キャリアをスキー・パスとして使用することも比較に値する。ユーザは、対応するパスを有し、非接触読取り可能なデータ・キャリアは、例えばスキー・リフトを使用した旅の特定の回数、または例えば１週間などの特定の時間の長さの間有効である。スキー・リフトへの入口エリアには、スキー・パスを非接触に読み取り、パスが有効である場合はスキー・リフトの利用を可能にするリーダがある。
【０００６】
非接触読取り可能データ・キャリアの使用の多大な市場潜在性が、（ローカル）公共旅客輸送の分野に現在備わっている。この場合、知られている紙のチケットは、現代的な電子運賃管理システムに置き換えられることができ、これは旅客輸送システムのオペレータと、またユーザの両方にとって利益をもたらす。
【０００７】
具体的には、既知の旅客輸送システム内のユーザ（乗客）は、非接触読取り可能データ・キャリア、例えばパッシブ・セキュア・メモリ・チップ（ＩＳＯ１４４４３Ａに準拠したＦｅｌｉｃａＴＭまたはＭＩＦＡＲＥ（登録商標）カード）またはスマート・カード・チップ上に電子チケットを有する。アクティブ・リーダがチケットの有効性をチェックし、クレジットで入金［load］され得るチケットの場合に多分運賃を引き落とすために使用される。リーダとパッシブ読取り可能データ・キャリアの間の通信は通常、通信プロトコルＩＳＯ７８１６および／または１４４４３に基づく。
【０００８】
こうした旅客輸送システムのオペレータにとっては、紙のチケットの製造および複雑な販売が省かれ得ることは有利である。ユーザにとっては、紙のチケットを購入する必要なく、また入金可能なチケットの場合には対応する運賃が単にチケットから引き落とされることは有利である。次いで、運賃表、また特にその地域の者でない乗客にとってしばしば問題となる何かについて知る必要はもはやない。特定の期間の間だけ有効なチケット、例えば１ヶ月定期券は、月のどの日からでも開始することができる。
【０００９】
旅客輸送システム用のこれらの既知のチケット・システムの１つの欠点は、通常リーダを持たないユーザがそのデータ・キャリアの内容を読み取ることができないことである。したがって、ユーザには、そのチケットの有効期間を知り、またはチケットにまだ残っているクレジット額を知る単純な可能性がない。
【００１０】
さらに、旅客輸送システムの駅および／または車両にアクティブ・リーダを設置することが必要であり、一方で、これらのリーダは維持され、電力が供給されなければならず、もう一方で、それらはユーザのパッシブ・データ・キャリアに比べて大幅により高価である。
【００１１】
したがって、こうした既知のチケット・システムは、オペレータが設定と維持の両方を行なうのに高価で複雑なものである。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の一目的は、上記で述べられた欠点が回避される、第１の段落で述べられたタイプの方法、および第２の段落で述べられたタイプのシステムを提供することである。
【課題を解決するための手段】
【００１３】
上述の目的を達成するために、上記で述べられたタイプの方法について具体的に述べられるが、
この方法では、システムの少なくとも１つの駅に少なくとも１つの非接触読取り可能データ・キャリアが割り当てられ、および／またはシステムの少なくとも１つの輸送手段に少なくとも１つの非接触読取り可能データ・キャリアが割り当てられ、
この方法では、非接触読取り可能データ・キャリアがチケット情報アイテムを含み、
この方法では、非接触読取り可能データ・キャリアのうちの１つが、少なくとも１つの駅および／または少なくとも１つの輸送手段内でモバイル・リーダによって読み取られ、
この方法では、対応する１つまたは複数のチケット情報アイテムがモバイル・リーダ内に格納される。
【００１４】
上述の目的を達成するために、上記で述べられたタイプの旅客輸送システムについても具体的に述べられるが、この旅客輸送システムでは、システムの少なくとも１つの駅および／または少なくとも１つの輸送手段に、少なくとも読取り可能チケット情報アイテムを含む少なくとも１つの非接触読取り可能データ・キャリアが割り当てられる。
【００１５】
本発明による目的はさらに、モバイル・リーダによって読み取られる非接触読取り可能データ・キャリアのチケット情報アイテムを受信し、これらのチケット情報アイテムに基づいて運賃を決定するように設計された計算サーバによって達成される。
【００１６】
さらに、この目的は、
非接触読取り可能データ・キャリア内に収容されるチケット情報アイテムを読み取る手段と、
対応する１つまたは複数のチケット情報アイテムを格納する手段と、
チケット情報アイテムから運賃を決定する手段、および／または格納されたチケット情報アイテムを、運賃を決定するリモート計算サーバに送信する手段と、を備えるモバイル・リーダによって達成される。
【００１７】
最後に、本発明による目的を達成するために、時刻表についても具体的に述べられるが、この時刻表では、駅または輸送手段の名前が現れ、またはこの駅または輸送手段を表す別の記号が配列された位置に固定されて、それぞれの駅またはそれぞれの輸送手段を一意に識別する駅固有または輸送手段固有のチケット情報アイテムを含む非接触読取り可能データ・キャリアが存在する。
【００１８】
本発明による諸特徴により、多くの費用がかかり、集約的な維持を要する［maintenance-intensive］リーダを駅内で使用することが、旅客輸送システムの駅および／または輸送手段に安価な非接触読取り可能データ・キャリアを割り当てることによって省かれ得るという利点が得られる。データ・キャリアを読み取るためのモバイル・リーダは、ユーザがそのチケットおよび／または旅行の状況について知らせを受けることができるようにユーザと共に置かれる。
【００１９】
ユーザは、駅または輸送手段内の非接触読取り可能データ・キャリアを読み取ることによって旅客輸送システムにチェック・インすることができ、すなわち、ユーザは仮想チケットを購入する。したがって、ユーザは、仮想電子チケットの形で旅行の許可を得る。単純な一実施形態では、このチケット購入は一定額（例えば１日乗車券の額）で「課金」され、この額が、例えばモバイル・リーダにそれで入金されるクレジットから引き落とされる。
【００２０】
駅および／または輸送手段に割り当てられた少なくとも１つの非接触読取り可能データ・キャリアが、それぞれの駅またはそれぞれの輸送手段を一意に識別する駅固有または輸送手段固有のチケット情報アイテムを含み、モバイル・リーダによって読み取られたチケット情報アイテムが運賃の計算に使用されるならば特に有利である。これらの方策により、旅の運賃は、読み取られたチケット情報アイテムに基づいて決定されることができ、すなわち、ユーザは、その１つまたは複数の旅行から独立した一定額ではなく、実際に行なわれた旅行の代金だけが課金される。この場合もまた、ユーザは原則としてチケットを購入し、さらにこのチケットは、ユーザが旅客輸送システム内にいる限りチェックされることができる。
【００２１】
原則として、ユーザが駅内で非接触読取り可能データ・キャリアを読み取ることによってシステムにチェック・インするか、それとも輸送手段内でそうすることによってチェック・インするかは本来重要ではない。しかし、駅でのチェック・インには、旅行が正確にどこで開始したかに関する情報アイテムが運賃計算のために既に存在しているという利点がある。これらの情報アイテムは、輸送手段内で直接にチェック・インする場合には通常存在しないが、非接触読取り可能データ・キャリアが位置決定手段に接続されていることが原則として考えられる。
【００２２】
この点に関して、一例は、衛星、あるいはＧＳＭ基地局を使用して位置を決定するＧＳＭモジュール（モバイル通信用グローバル・システム）を使用して輸送手段の位置を決定するＧＰＳ（Global Position System：全地球測位システム）受信機である。この場合、対応する位置情報アイテムが、結果として非接触読取り可能データ・キャリアに送信され、したがって旅客輸送システムのために使用され得る。
【００２３】
位置決定の別の可能性は時間である。具体的には、輸送手段が多かれ少なかれ時刻表に従って移動するならば、輸送手段は、ある特定の時点で特定の場所に位置する。しばしば、輸送手段の停止もまた、ラウドスピーカのアナウンスによって告げられる。アナウンスは、輸送手段が次の駅に近づくときに運転手によって手動で、あるいは自動的にオンにされる。このアクティブ化も有利には、位置情報アイテムを非接触読取り可能データ・キャリアに送信するために使用されても良い。
【００２４】
最後に、輸送網のグラフィック図、すなわち、例えば移動される全ての駅の路線図、または旅の時刻を示す従来の時刻表に複数の非接触読取り可能データ・キャリアを備えることも考えられる。この場合には、駅の名前が現れ、またはこの駅を表す別の記号が見える時刻表のある位置に固定されて、物理的に本当の駅にあるデータ・キャリアと同じ情報、またはそれに対応する情報を含む非接触読取り可能データ・キャリアが存在する。さらに、それは、時刻表がどこに置かれているかに関する情報アイテムをも含んでも良い。次いで、この追加の情報アイテムは、課金サーバによってそれに応じて評価されても良い。
【００２５】
こうした時刻表は、様々な場所、すなわち例えば停留所自体、輸送手段内、または他の任意の場所で使用可能にされても良い。したがって、乗客は実際にどこにいるかに関係なくチェック・インおよびアウトすることが可能である。例えば、バス停でチェック・インし忘れた乗客は、次いでバスの中でチェック・インすることができる。乗客は、目的地でチェック・アウトし忘れるリスクを負わないように、行き先の停留所について同時にチェック・アウトすることもできる（このプロセスについては、以下でより詳細に説明される）。時間および場所に関して旅の実際の開始／終了から独立したチェック・イン／チェック・アウト操作は、輸送業務の旅客ガイドライン内で定められ、それに応じて規制されることができる。
【００２６】
また前記時刻表および概要マップは、もちろん駅の中に固定されても良い。駅固有情報アイテムを含む非接触読取り可能データ・キャリアに加えて、こうした時刻表はもちろん、物理的に本当の輸送手段内のデータ・キャリアと同じ情報、またはそれに対応する情報を含む非接触読取り可能データ・キャリアをも含んでも良い。どの輸送手段が使用されたかを区別することは、同一の経路が、かかる費用がそれぞれ異なる輸送手段によって移動され得る場合には特に重要である。この点に関しての一例は、例えばバスまたは地下鉄によって移動され得る都市部の経路である。地域間リンクの別の例は、電車または船が使用されても良い沿岸の経路である。
【００２７】
原則として本発明は、非接触読取り可能データ・キャリアが１つまたは数個の駅だけ、または１つまたは複数の数個の輸送手段内だけに置かれる場合でも実施され得る。しかし、ユーザがデータ・キャリアのない駅または輸送手段内で旅客輸送システムに入る場合は、旅客輸送システムにチェック・インすることができず、すなわち「チケット」を購入することができないので、ユーザは本発明の利益を得ることができない。
【００２８】
したがって通常は、１つまたは複数の非接触読取り可能データ・キャリアが旅客輸送システムの各駅に置かれることが定められ、また上述されたように有利でもある。さらに、非接触読取り可能データ・キャリアが輸送手段内にも設けられるのならば、さらに好ましいことがある。
【００２９】
もちろん、本発明は、データ・キャリアが輸送手段内だけに置かれている場合にも実施されることができるが、その場合、特にデータ・キャリアが位置情報アイテムを含まないならば、本発明の一部の利点の利益を得ることは不可能かもしれない。
【００３０】
運賃を決定するには、単に旅客輸送システムにチェック・インすることで十分である。しかし、
ａ）出発駅において、前記駅に割り当てられた非接触読取り可能データ・キャリアが読み取られ、対応する第１のチケット情報アイテムがモバイル・リーダ内に格納され、
ｂ）到着駅において、前記駅に割り当てられた非接触読取り可能データ・キャリアが読み取られ、対応する第２のチケット情報アイテムがモバイル・リーダ内にバッファ格納され、
ｃ）旅の運賃が第１および第２のチケット情報アイテムから決定されるならば、特に有利である。これらの方策により、ユーザがどこで旅客輸送システムに入り、そこを離れたかに関する（位置）情報アイテムがあるので大幅により正確な運賃の計算が実施され得るという利点が得られる。
【００３１】
ユーザが、非接触読取り可能データ・キャリアが設けられた駅または輸送手段内で旅客輸送システムにチェック・インしたが、非接触読取り可能データ・キャリアがない駅で旅客輸送システムを離れる場合は、実際の運賃は計算され得ず、実際の運賃より通常高い単位運賃［unit fare］が計算される。
【００３２】
システムの各駅および／または輸送手段に少なくとも１つの非接触読取り可能データ・キャリアが割り当てられる場合は、本発明が空間的観点から旅客輸送システムの特定の駅にもはや限定されず、したがって旅客輸送システム全体のために使用され得るので、これらの欠点が生じ得ないという利点が得られる。
【００３３】
旅の間、駅固有のチケット情報アイテムが他の駅内の非接触読取り可能データ・キャリアから読み取られる場合、および／または輸送手段固有のチケット情報アイテムが輸送手段内の非接触読取り可能データ・キャリアから読み取られる場合には特に有利であることが証明されており、これらの情報アイテムが運賃の決定のために使用される。結果として、ユーザが旅する間の特定の経路選択および／または輸送手段選択が運賃決定の際に考慮に入れられ得るという利点が得られる。
【００３４】
本発明の一変形形態では、チケット情報アイテムからの運賃の決定が、モバイル・リーダ内で実施される。これらの方策により、運賃が、ユーザにとって自然な位置で、単純で迅速なやり方で決定され得る。
【００３５】
本発明のさらなる変形形態では、モバイル・リーダ内に少なくともバッファ格納されたチケット情報アイテムが、運賃の決定のためにリモート計算サーバに送信される。しかし、これらの方策では、チケット情報アイテムが、このためにそれに応じて設計されたモバイル・リーダから計算サーバに送信されることが必要となる。しかし、このため、運賃計算のための計算アルゴリズムおよび料金表データの中央維持が可能であり、料金表の変更が直ちに考慮に入れられることができ、モバイル・リーダがより単純に設計されることができるという利点が得られ、この点に関して、モバイル・リーダの維持および更新は必要ない。
【００３６】
チケット情報アイテムがモバイル・リーダのセキュア・メモリ内に格納される場合も有利である。結果としてチケット情報アイテム、ならびに旅の許可、価値単位［value unit］、および旅客認証に関する情報などの他のセキュリティ関連の情報アイテムもがモバイル・リーダ内に確実に格納され得るという利点が得られる。これは、これらの情報アイテムが犯罪者によって発見され、コピーされることができ、したがって「無許可の人々」がシステムに入り込み得るので特に重要である。例を挙げると、「不正使用防止」のスマート・カード・コントローラがここでは使用される。このように、本発明によるシステムは、モバイル・リーダを介したハードウェア攻撃に対して耐性を持つようになる。
【００３７】
運賃を決定するのに到着駅の非接触読取り可能データ・キャリアのチケット情報アイテムが使用できない場合に、固定して事前定義された運賃が決定されることも有利である。結果として、実際の運賃より通常高い固定運賃が旅の代金として課金されないためにユーザが旅客輸送システムをチェック・アウトするようにも促されるという利点が得られる。しかし、これらの方策は、例えばユーザが、例えば駅に非接触読取り可能データ・キャリアがないのでシステムをチェック・アウトする可能性がない場合にも提供される。
【００３８】
運賃が決定されると前記運賃がモバイル・リーダ上に出力され、例えばモバイル・リーダの表示画面上に表示される場合、および／または出発駅内の非接触読取り可能データ・キャリアが読み取られると「チェック・イン済み」の状況がモバイル・リーダ上に出力され、例えばモバイル・リーダの表示画面上に表示される場合にはさらに有利である。このように、ユーザは、旅の状況を、または旅が完了すると運賃について知らせを受けることができる。
【００３９】
料金の決定がモバイル・リーダまたはリモート計算サーバ内で、事前定義可能な期間、または読み取られた特定の数のチケット情報アイテムの後にしか実施されない場合も有利である。このように、ユーザのために「最良運賃」の運賃計算が行なわれることができ、すなわち、運賃計算において複数の旅が考慮に入れられることができ、したがって、ユーザのために最良の価格が決定されることができる。
【００４０】
本発明の誤用は、非接触読取り可能データ・キャリアに結合されたアクセス・バリアが駅内に設けられており、非接触読取り可能データ・キャリアが読み取られた後にだけ駅への入場または退出を許可するためにアクセス・バリアが開かれる場合には、特に信頼性の高いやり方で防止されることができる。したがって、駅への入場または退出は、ユーザが対応する非接触読取り可能データ・キャリアを事前に読み取っている場合にだけ可能である。回転ドアなどのこうしたアクセス・バリアなしでは、「不正乗車」は、システム自体によっては回避されることはできず、したがって、不正乗車は、検査員によってしか発見され得ない。
【００４１】
本発明は、パッシブ非接触読取り可能データ・キャリアが駅および／または輸送手段内で使用され、それに割り当てられる場合には、非常に低い維持要件、したがって低い維持および運営コストを伴って特にコスト効率の高いやり方で、したがって特に有利なやり方で実施されることができる。
【００４２】
本発明について、図面に示される実施形態の例を参照してさらに述べられるが、しかし、本発明は、それに限定されない。
【発明を実施するための最良の形態】
【００４３】
図１は、例示するために２つの地下鉄路線ＵＬ１、ＵＬ２を備える旅客輸送システムＶＳＹ（以下、略して「システム」と称される）を示している。輸送手段ＶＭ１、ＶＭ２、この場合、地下鉄電車は、地下鉄路線ＵＬ１、ＵＬ２上を移動する。もちろん、こうしたシステムＶＳＹは原則として、１つの路線だけからなることも、複数の路線、また具体的には様々な路線（路面電車路線、バス路線、高速道路路線、船など）からなることもある。
【００４４】
さらに、以下ではシステムＶＳＹの「オペレータ」について通常言及されているが、しかし、本発明は複数のシステムに渡って、すなわち様々なシステムＶＳＹのオペレータ間の適切な契約上の合意または協力を伴って適用されることもでき、システムＶＳＹがそれに応じて技術的に装備されている場合には、ユーザ（乗客）は様々なシステムの輸送手段ＶＭ１、ＶＭ２を使用し、本発明の利点の利益をやはり得ることもできる。
【００４５】
図１で分かるように、地下鉄路線ＵＬ１は、この地下鉄路線ＵＬ１上を移動する輸送手段ＶＭ１にユーザが乗車しまたは下車することができる複数の駅Ｓ１１、Ｓ１２、Ｓ１３、Ｓ１４を有する。対応するやり方で、地下鉄路線ＵＬ２は、駅Ｓ２１、Ｓ２２、Ｓ２３を有する。共通の駅Ｓ００も示されており、この共通の駅では、２つの地下鉄路線ＵＬ１、ＵＬ２間での乗換え、もちろんシステムＶＳＹに入りまたはそこを離れることも原則として可能である。こうした乗換駅Ｓ００は実際には、頻繁に存在する。しかし、本発明は、こうした乗換駅Ｓ００が存在しない場合にも制約なしに使用されることができる。
【００４６】
それぞれの駅Ｓ１１、Ｓ１２、Ｓ１３、Ｓ１４、Ｓ２１、Ｓ２２、Ｓ２３、Ｓ００、略して「Ｓ１１…Ｓ００」に、少なくとも１つの非接触読取り可能データ・キャリアＴ１１、Ｔ１２、Ｔ１３、Ｔ１４、Ｔ２１、Ｔ２２、Ｔ２３、Ｔ００、略して「Ｔ１１…Ｔ００」が割り当てられる。原則として、それぞれの駅Ｓ１１…Ｓ００にただ１つのこうした非接触読取り可能データ・キャリアＴ１１…Ｔ００が割り当てられれば十分であり、単純にするため、以下でも駅Ｓ１１…Ｓ００内のただ１つの非接触読取り可能データ・キャリアについて通常言及される。
【００４７】
しかし、実際には、それぞれの駅Ｓ１１…Ｓ００に比較的大きい数のこうした非接触読取り可能データ・キャリアＴ１１…Ｔ００が割り当てられれば、その場合これらはユーザにとってより容易に到達され、読み取られ得るので有利であり、したがって、本発明の利便性および受け入れは大幅に向上される。
【００４８】
もちろん、これに関して、非接触読取り可能データ・キャリアＴ１１…Ｔ００が利用し易い場所に、また乗客がよく訪れる場所に固定される場合も有利である。データ・キャリアＴ１１…Ｔ００は、例えば非接触読取り可能データ・キャリアＴ１１…Ｔ００の位置を示す対応するポスタ、サインなどによって、またはこうしたポスタ、サイン、さらには時刻表などに直接組み込まれたデータ・キャリアＴ１１…Ｔ００によって、データ・キャリアＴ１１…Ｔ００が容易に見えるように印が付けられるならばさらに有利である。
【００４９】
駅Ｓ１１…Ｓ００に割り当てられたデータ・キャリアＴ１１…Ｔ００は、それぞれの駅Ｓ１１…Ｓ００を識別する駅固有のチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００を含む。これらの一意のチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００は、例えば一意の数、一意の名前または他の情報アイテム、例えばそれぞれの駅Ｓ１１…Ｓ００を識別し、それを互いに区別する地理情報アイテムであっても良い。駅Ｓ１１…Ｓ００の全てのデータ・キャリアＴ１１…Ｔ００はこの場合、駅Ｓ１１…Ｓ００の各データ・キャリアＴ１１…Ｔ００に同一であり、本発明の文脈の中でまた本発明のために各駅Ｓ１１…Ｓ００の一意の識別を可能にする１組の情報アイテムを含む。
【００５０】
本発明の文脈では、ユーザは、非接触読取り可能データ・キャリアＴ１１…Ｔ００からのチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００がそれによって読み取られ格納され得るモバイル・リーダＭＯＤを有する。モバイル・リーダＭＯＤは好ましくは、携帯電話または携帯情報端末（ＰＤＡ―Personal Digital Assistant―）として設計される。データ・キャリアＴ１１…Ｔ００は、いわゆる「無線周波数識別（ＲＦＩＤ―Radio Frequency Identification―）」タグとして設計される。
【００５１】
図２に示すように、ＲＦＩＤタグとして設計されたデータ・キャリアＴｉｉは、例えばモバイル・リーダＭＯＤによって送信される電磁信号ＳＩＧを受信し、モバイル・リーダＭＯＤに電磁信号ＳＩＧ´を送信するためのアンテナＡＮＴの形の結合素子と、またアンテナＡＮＴに接続された通信インターフェースＫＩＦと、データ・メモリＴＳＰとを備える。例えばデータ・キャリアＴｉｉが、本発明の文脈において使用されるような規格ＩＳＯ／ＩＥＣ−１４４４３によるパッシブ・データ・キャリアである場合、モバイル・リーダＭＯＤから受信される電磁信号ＳＩＧを用いて、データ・キャリアＴｉｉに電力が供給されることもできる。この場合、モバイル・リーダＭＯＤは、パルス幅変調された情報を運ぶＨＦ搬送波信号を１３．５６ＭＨｚの周波数で送信する。この実施形態では、範囲は一般に最大１ｍである。
【００５２】
原則として、非接触通信に関して本発明は、特定のタイプの無線通信技術に限定されず、すなわち原則として、任意のタイプの無線通信がモバイル・リーダＭＯＤとデータ・キャリアＴｉｉの間で提供されても良い。
【００５３】
しかし、ユーザが駅Ｓ１１…Ｓ００に入るとすぐＶＳＹに不注意にチェック・インしないために、輸送手段ＶＭ、ＶＭ２を使用する意図なしに駅Ｓ１１…Ｓ００に入ることは実際に生じることがあるが、モバイル・リーダＭＯＤのアクティブ範囲が制限されるならば有利である。原則として、約１ｍの範囲が本発明では有利である。しかし、範囲がより短く、約２０ｃｍ未満ならば特に有利である。この範囲では、チェック・イン／アウトするために、ユーザによる故意の取扱い、すなわちモバイル・リーダＭＯＤを非接触読取り可能データ・キャリアＴｉｉの近くに持ってくる動作が必要である。これらの範囲では、不注意なチェック・インまたはチェック・アウトは高い確率で取り除かれ得る。
【００５４】
これらの理由により、モバイル・リーダＭＯＤおよびデータ・キャリアＴｉｉは、例えば規格ＩＳＯ１８０９２またはＭＩＦＡＲＥ（登録商標）規格に準拠したＮＦＣデバイス（近距離無線通信デバイス―Near Field Communication Device―）として設計されることが好ましい。ＮＦＣデバイスでは、範囲は一般にアクティブ・モードでは約２０ｃｍであり、パッシブ・モードでは約１０ｃｍであり、ＭＩＦＡＲＥ（登録商標）規格に準拠したデバイスでは、範囲は一般に約２ｃｍである。単純な一実施形態では、データ・キャリアＴｉｉは、電磁信号ＳＩＧを介して十分な電力を受信するときにアクティブ状態に入り、このアクティブ状態では、通信インターフェースＫＩＦは、メモリＴＳＰ内に格納されたデータ、すなわち駅固有のチケット情報アイテムＩＮｉｉ、および任意選択で追加のデータＯＰＴを、電磁信号ＳＩＧ’として変調されたやり方でモバイル・リーダＭＯＤに送信する。任意選択の追加のデータＯＰＴは、さらなる詳細、背景情報または他の情報アイテムを備えても良い。こうした任意選択の追加のデータＯＰＴは、位置関連のサービス情報アイテム、例えば旅客輸送システムＶＳＹの最も近い切符売り場の位置、駅Ｓ１１…Ｓ００の料金表の区間などであっても良い。
【００５５】
送信は、連続して行なわれても、要求に応じて一度行なわれても良く、複数のタグがモバイル・リーダＭＯＤの読取り範囲内に置かれている場合には、有利には衝突防止プロトコルが使用される。データ・キャリアＴｉｉのより効率的な一実施形態では、通信インターフェースＫＩＦは、通信プロトコルを実装するための「状態マシン」またはマイクロプロセッサとして設計される。このような通信プロトコルは、例えばデータ・キャリアＴｉｉが、モバイル・リーダＭＯＤからの「ブロードキャスト」またはインベントリ・コマンドにより情報送信を要求される場合にだけ情報を送信することを定めても良い。同様に、通信プロトコルは、モバイル・リーダＭＯＤがデータ・キャリアＴｉｉにチケット情報アイテムＩＮｉｉおよび追加のデータＯＰＴをそれぞれ別々に要求することを定めても良い。
【００５６】
データ・キャリアＴｉｉは、様々な実施形態で、例えばチップとして存在しても良いが、しかし、それはまた、時々非常に小さい形で、ポスタ、時刻表などの物の中に組み込まれても良い。
【００５７】
上述されたように、それぞれのデータ・キャリアＴｉｉは、モバイル・リーダＭＯＤがそのアクティブ範囲に到達したときに、それぞれのデータ・キャリアＴｉｉに割り当てられた駅Ｓｉｉの駅固有チケット情報アイテムＩＮｉｉ（または以下でより詳細に説明されるようにそれぞれのデータ・キャリアＴｉｉに割り当てられた輸送手段ＶＭ１、ＶＭ２の輸送手段固有のチケット情報アイテム）を、また任意選択で追加のデータＯＰＴを、（自動的に、または従来通りにモバイル・リーダＭＯＤからの要求があるとすぐ）モバイル・リーダＭＯＤに送信する。モバイル・リーダＭＯＤは、アンテナＭＡＴを介して、データ・キャリアＴｉｉから送信された電磁信号ＳＩＧ´を受信する。アンテナＭＡＴは通信インターフェースＫＩＭに接続されており、この通信インターフェースＫＩＭは、チケット情報アイテムＩＮｉｉ、および適切な場合には、受信された電磁信号ＳＩＧ´からの追加のデータＯＰＴを変調し、メモリＭＳＰ内にチケット情報アイテムＩＮｉｉを格納する。
【００５８】
メモリＭＳＰは有利には、セキュア・メモリである。これは、システムがモバイル・リーダＭＯＤを介した攻撃に対してセキュリティ保護されるという上述の利点をもたらす。さらに、無線読取り可能データ・キャリアＴｉｉがモバイル・リーダＭＯＤまたはセキュア・メモリＭＳＰと通信するのに適した暗号化プロトコルは、認証されたデータ・キャリアＴｉｉが読み取られたことをさらに保証する。このため、例えばそれぞれのデータ・キャリアＴｉｉは、オペレータだけに知られている秘密鍵を格納する。この秘密鍵は、モバイル・リーダＭＯＤ内に組み込まれたセキュア・メモリＭＳＰに対してデータ・キャリアＴｉｉを認証するために使用される。
【００５９】
データ・キャリアＴｉｉが盗難に対して十分に保護されていない場合、従来のシステムにおいても生じるように、システムＶＳＹが害されることがあり得る。しかし、本発明のさらなる一利点は、アクティブ・リーダを保護するよりも、単純なパッシブ・データ・キャリアＴｉｉを盗難および破壊行為から保護することが、しかしながらよりコスト効率が高いことである。
【００６０】
図１に戻ると、駅Ｓ１１で開始し、Ｓ２３で終了する地下鉄路線ＵＬ１およびＵＬ２を使用したユーザの旅について次に考慮されたい。ユーザは、駅Ｓ００で路線を変更する。
【００６１】
ユーザが駅Ｓ１１に入るとき、または通信が路線ＵＬ１の輸送手段に入る前、前記ユーザは、「チェック・イン」またはチケットの仮想購入のために、そのモバイル・リーダＭＯＤを駅Ｓ１１内の非接触読取り可能データ・キャリアＴ１１の近くに持っていかなければならない。図２を参照して上述されたように、少なくともチケット情報アイテムＩＮ１１が、モバイル・リーダＭＯＤに送信され、そこでメモリＭＳＰ内に格納される。さらに、それは、特にユーザがシステムＶＳＹにチェック・インしたモバイル・リーダＭＯＤの表示装置ＤＳＰ（図２）上に表示されても良く、このように、ユーザは、システムＶＳＹに関してユーザの現在の状態について包括的に通知を受ける。
【００６２】
次いで、ユーザは、地下鉄路線ＵＬ１およびＵＬ２の輸送手段（電車）を用いて到着駅Ｓ２３に移動し、この到着駅Ｓ２３でユーザは、そこに設けられたモバイル・データ・キャリアＴ２３をユーザのモバイル・リーダＭＯＤで再び読み取る。対応するチケット情報アイテムＩＮ２３が、モバイル・リーダＭＯＤに送信される。またこれらのチケット情報アイテムＩＮ２３は好ましくは、情報損失を防止するためにメモリＭＳＰ内に格納される。
【００６３】
これらのチケット情報アイテムＩＮ１およびＩＮ２３に基づいて、移動される経路の運賃が次いで決定される。運賃は、対応する評価手段ＰＲＯを用いてモバイル・リーダＭＯＤ内で直接決定されることが定められても良い。これを行なうため、対応する評価アルゴリズムおよび料金表情報がモバイル・リーダＭＯＤ内に格納されることが必要であり、このアルゴリズムおよび情報を用いて、またそれに基づいて運賃が決定される。決定された運賃は有利には、モバイル・リーダＭＯＤの表示装置ＤＳＰ上に表示される。さらに、状況「チェック・アウト済み」も表示されても良い。
【００６４】
しかし、本発明の有利な一実施形態においては、運賃の計算は、モバイル・リーダＭＯＤ自体ではなく、リモート計算サーバＳＥＲ内で行なわれる。このため、チケット情報アイテムＩＮ１１、ＩＮ２３は、モバイル・リーダＭＯＤから計算サーバＳＥＲに送信される。このため、モバイル・リーダＭＯＤは、通常アンテナＣＡＴが割り当てられている少なくとも１つの通信モジュールＣＭＤを有する。この通信モジュールＣＭＤを用いて、この場合には好ましくは携帯電話として設計されたモバイル・リーダＭＯＤは、チケット情報アイテムＩＮ１１、ＩＮ２３を計算サーバＳＥＲに送信し、次いでこの計算サーバＳＥＲ内で、次いで運賃の決定が実施される。またモバイル・リーダＭＯＤはもちろん、この場合には例えば対応する通信モジュールＣＭＤを備えたＰＤＡであっても良い。
【００６５】
通信モジュールＣＭＤを使用した送信は例えば、図示されるように携帯電話網ＮＥＴ、例えばＧＳＭおよび／またはＵＭＴＳネットワークを介して、ＷＡＰまたはＧＰＲＳを用いてまたはＳＭＳ、ＭＭＳ、ＥＭＳなどの形で、あるいは例えばＷＬＡＮを介して行なわれる。
【００６６】
計算サーバＳＥＲで運賃が計算されると、運賃は有利にはモバイル・リーダＭＯＤに送信され、そこでユーザに、例えば表示装置ＤＳＰ上で表示される。例を挙げると、運賃は、ＳＭＳの形で送信されても良い。さらに、運賃はユーザから、例えば口座から引き落とされ、またはモバイル・リーダＭＯＤに特定の金額（クレジット）が入金され、運賃が前記金額から引き落とされる。
【００６７】
運賃課金、すなわち口座からの引落とし、あるいはモバイル・リーダＭＯＤに格納されまたはモバイル・リーダＭＯＤに割り当てられたクレジットからの引落としのための、例示するために示された両方の方法は、運賃がモバイル・リーダＭＯＤ内で決定される本発明の変形形態と、決定がリモート計算サーバＳＥＲで行なわれる後者の変形形態の両方で使用されても良い。
【００６８】
特定の金額（クレジット）が入金されたモバイル・リーダＭＯＤと、モバイル・リーダＭＯＤ自体内で運賃を決定することの組合せは、この場合にはリモート計算サーバＳＥＲに、あるいは引落としシステムまたは口座にデータを送信する必要が全くないので有利である。
【００６９】
リモート計算サーバＳＥＲ内で運賃を決定することには、運賃がユーザの口座から落とされるならば、この場合にはユーザはモバイル・リーダＭＯＤへの入金について心配する必要がないので、特に有利である。
【００７０】
リモート計算サーバＳＥＲ内で運賃を決定することにはさらに、モバイル・リーダＭＯＤが運賃を決定するように設計される必要がなく、その結果として、前記モバイル・リーダＭＯＤが遥かにより単純に設計され得るという利点がある。さらに、データ、例えば運賃を決定するための料金表データへの維持および配慮は、したがってサーバＳＥＲ内で実施され得る。モバイル・リーダＭＯＤ内で計算する場合にはあまり簡単には行なうことができず、また多数のモバイル・リーダＭＯＤの更新を必要とすることである料金表の変更は、直ちに考慮に入れられ得る。
【００７１】
ユーザが到着駅Ｓ２３でシステムＶＳＹをチェック・アウトし忘れる場合、事前定義可能な額が運賃として計算され、それに応じて引き落とされることが定められても良い。例を挙げると、運賃は、１日乗車券の代金であると定められても良い。
【００７２】
上述されたように、運賃は、開始および到着駅Ｓ１１、Ｓ２３に関するチケット情報アイテムＩＮ１１、ＩＮ２３に基づいて計算されることが通常定められる。原則として、例えば乗換駅Ｓ００の非接触データ・キャリアからのさらなるチケット情報アイテムＩＮ００が考慮に入れられることも定められても良い。このように、ユーザの特定の旅の経路が考慮に入れられ、料金表計算に含められることもできる。例えば、対応するチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００は、終点Ｓ２３に達し、チェック・アウトが完了されるとすぐに計算サーバＳＥＲに一緒に送信され、または計算はモバイル・リーダＭＯＤ内で実施される。
【００７３】
原則として駅Ｓ１１…Ｓ００は制約なしに入場することができ、制約なしに退出することもできる。したがって、ユーザが「チケット」の購入を望むか、そうするより「運賃不正」したいかどうかは、システムＶＳＹのユーザ次第である。しかし、地下鉄路線の利用が、回転ドア、ゲートなどのアクセス・バリアＤＲＫを介してだけ可能であることも一部の都市から知られており、このアクセス・バリアＤＲＫは、従来のチケットがそれに応じて有効化された後にだけ駅に入場しおよび／または退出することを可能にする。こうしたアクセス・バリアＤＲＫが、図１の駅Ｓ１１およびＳ１４に概略的に示されている。
【００７４】
同様に、本発明では、こうしたアクセス・バリアＤＲＫが非接触読取り可能データ・キャリアＴ１１およびＴ１４に適切に接続され、ユーザがデータ・キャリアＴ１１およびＴ１４を読み取ることによって事前にチェック・インした場合にだけアクセスを可能にし、すなわちアクセス・バリアＤＲＫを開くことが定められても良い。あるいはまたは好ましくはさらに、対応するデータ・キャリアＴ１１およびＴ１４を読み取ることによってユーザがもう一度チェック・アウトする場合にだけ駅Ｓ１１およびＳ１４を離れることも次いで可能である。このように、輸送手段ＶＭ１、ＶＭ２を使用する代金を支払わずにそうできることはめったにない。
【００７５】
中間の駅Ｓ００が考慮に入れられる運賃計算のための上述の手順は有利には、輸送手段ＶＭ１、ＶＭ２を変更する場合には通常、新しい輸送手段ＶＭ１、ＶＭ２を下車し乗車するために対応するデータ・キャリアＴ００がいずれにせよ読み取られなければならないので、乗車または降車を、それに応じてデータ・キャリアＴ１１…Ｔ００が読み取られた後にだけ可能にするこうしたシステムＶＳＹに具体的には適用され得る。
【００７６】
上述されたように、中間駅を多分考慮に入れる運賃の計算および多分引落としは、それぞれの旅の後に行なわれることが定められても良い。しかし、特定の数のチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００がまず収集され、またはチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００が特定の期間、例えば１ヶ月に渡って収集され、すなわちモバイル・リーダＭＯＤのセキュア・メモリＭＳＰ内に格納され、次いで総運賃の計算だけが行なわれることも定められても良い。このため、次いで、チケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００は、計算が行なわれる計算サーバＳＥＲに送信される。この手順では、いわゆる「最良運賃」計算が、ユーザの利益のために実施されても良い。例えば、ユーザがある月に特定の回数の旅を行ない、個々の運賃が１ヶ月定期の代金を超える場合、こうした計算では、ユーザのためにより有利な１ヶ月定期が計算され得る。
【００７７】
従来（紙）のチケットの購入、および本発明による新しい引落としが可能なシステムのユーザにとって、これは、ユーザが新しいシステムへと進もうとするさらなる動機となるものであり、この新しいシステムではユーザは、所与の期間についてより低い価格がいずれにせよ計算されるため、ある期間の最初にユーザにとってどのタイプの「チケット」が最良かをユーザが考慮する必要がないので、遥かにより有利である。
【００７８】
さらに、ユーザがシステムＶＳＹから自動的にチェック・アウトし得ることも定められても良い。これは、例えばユーザのモバイル・リーダＭＯＤ上の対応するボタンを押下することによって行なわれても良い。これは、例えば到着駅Ｓ２３内の非接触読取り可能データ・キャリアＴ２３の読取り中に行なわれても、読取り後に行なわれても良い。
【００７９】
次いで、収集された（すなわち格納されているが、引き落とされていない）全てのチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００の運賃計算が、モバイル・リーダＭＯＤ内で直接に行なわれ、またはチケット情報アイテムが計算サーバＳＥＲに送信され、そこで計算が行なわれる。
【００８０】
監視スタッフ、例えば車掌または検査員による制御のため、モバイル・リーダＭＯＤは、適切なモバイル読取りデバイス、例えばアクティブ・スマート・カード・リーダを使用してこうした監視者によって読み取られ得る。モバイル・リーダＭＯＤに関する認証の成功の後に続いて、監視者は、モバイル・リーダＭＯＤ上に収集されたチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００を読み取ることができる。このように、監視者は、乗客が適切なやり方でシステムＶＳＹにチェック・インしたかどうか、すなわち乗客が現在の旅に有効なデータ・キャリアＴ１１…Ｔ００を読み取ったかどうか確認することができる。
【００８１】
このため、システムＶＳＹへのチェック・インおよび／またはアウトの時間についてもまた取決めが定められる［protocolled］場合にも有利であるかもしれない。例示すると、モバイル・リーダＭＯＤ内にインストールされたクロックが、各手順について時間をチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００と共に格納するために使用されても良い。時間がデータ・キャリアＴ１１…Ｔ００に送信され、次いでそこからモバイル・リーダＭＯＤにロードされることも考えられる。この場合、例えば天井に取り付けられており、したがって破壊行為に対して大部分は保護されている読取り／書込みデバイスが、複数のデータ・キャリアＴ１１…Ｔ００に、例えば分単位で時間を送信しても良い。もちろん、他の可変のデータが、このようにデータ・キャリアＴ１１…Ｔ００に送信されることもできる。
【００８２】
次いで、検査員は、そのモバイル読取りデバイスをモバイル読取り計算サーバＳＥＲに安全に接続することができ、次いで、さらに収集されたチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００がサーバＳＥＲに送信される必要があるかどうか確認することができる。これは、モバイル・リーダＭＯＤ自体が、（ユーザが望むにしろ、望まないにしろ）リモート計算サーバＳＥＲへのオンライン接続を確立することができない／し得ない場合に重要である。この場合、収集されたチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００は、モバイル・リーダＭＯＤのメモリＭＳＰ内に当分の間だけ残っている。乗客が検査員によってチェックされるとき、検査員のモバイル読取りデバイス上の収集されたチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００は、ＮＦＣインターフェースを介して送信される。次いで、これらのチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００に基づいて、行なわれた旅の運賃が決定される。
【００８３】
運賃は検査員のモバイル読取りデバイス内で直接に決定されることが定められても良く、あるいは、これらのチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００は、運賃の決定のために検査員のモバイル読取りデバイスからリモート計算サーバＳＥＲに送信される。
【００８４】
まだ引き落とされていない、収集されたチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００がユーザのモバイル・リーダＭＯＤ内に格納される場合、この送信経路は、計算サーバＳＥＲを乗客のモバイル・デバイスＭＯＤと同期させるために使用されることができる。そうでなければ、乗客は、無賃で旅するために、そのモバイル・リーダＭＯＤとリモート・サーバＳＥＲの間の接続を確立しようと決して試み得ない。
【００８５】
リモート・サーバＳＥＲ上で引落としが正確に行なわれる場合は、ユーザのモバイル・リーダＭＯＤは電子受領書を受信し、収集されたチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００は「引落とし済み」と印が付けられ、メモリのログブックまたはログファイル内に書き込まれる。引落としがローカルで、例えばモバイル・リーダＭＯＤ自体で行なわれるならば、その場合ユーザのモバイル・リーダＭＯＤは、収集されたチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００に「引落とし済み」と印を付けることができるように、権限のある機関に電子受領書を要求し、取得しなければならない。
【００８６】
図１は、少なくとも１つの非接触読取り可能データ・キャリアＴ１１…Ｔ００がシステムＶＳＹの各駅Ｓ１１…Ｓ００内に置かれている典型例を示している。このように、通常旅の開始および到着駅、また多分、中間の駅も知られているので、運賃の最適な計算が可能である。ユーザがチェック・アウトし忘れる場合、例えば１日乗車券がユーザのために計算され得る。しかし、この状況は、「最良料金」計算において考慮に入れられることもできる。
【００８７】
図１は、非接触読取り可能な、好ましくはパッシブ・データ・キャリアＴ１０、Ｔ２０が輸送手段ＶＭ１、ＶＭ２内にも置かれる可能性をも示している。これらのデータ・キャリアが輸送手段固有のチケット情報アイテムを含む場合、このように、旅の間にどの輸送手段ＶＭ１、ＶＭ２が使用されたかについて、さらに考慮され得る。
【００８８】
ユーザは輸送手段ＶＭ１、ＶＭ２内でシステムＶＳＹにチェック・インすることもでき、データ・キャリアＴ１０、Ｔ２０が輸送手段固有のチケット情報アイテムだけを、または駅固有のチケット情報アイテムをも含む場合が区別されなければならない。最初に述べられた場合では、旅の開始点は知られていない。知られていることは、どの輸送手段ＶＭ１、ＶＭ２（また多分他のどの輸送手段および／または停留所もしくは到着駅）が使用されたかである。次いで、この状況は、運賃を計算するときに特に考慮に入れられなければならない。しかし、データ・キャリアＴ１０、Ｔ２０が駅固有のチケット情報アイテムをも含む場合は、上述されたような運賃計算は可能である。
【００８９】
対応するデータ・キャリアＴ１０、Ｔ２０が、輸送網を図示する路線図または時刻表に組み込まれても良い。こうした概要マップは通常、それぞれの輸送手段ＶＭ１、ＶＭ２内に置かれる。駅の名前Ｓ１１…Ｓ００が現れ、またはこの駅Ｓ１１…Ｓ００を表す別の記号が配列されている位置に固定されて、それぞれの駅Ｓ１１…Ｓ００を一意に識別する駅固有チケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００を含む非接触読取り可能データ・キャリアＴ１１…Ｔ００が存在する。したがって、システムＶＳＹのチェック・インおよびアウトが遥かにより単純なやり方で可能である。
【００９０】
非接触読取り可能データ・キャリアＴ１１…Ｔ００が少なくとも駅Ｓ１１…Ｓ００内に置かれるならばさらに有利である。しかし、原則として、データ・キャリアＴ１０、Ｔ２０が輸送手段ＶＭ１、ＶＭ２内だけに置かれ、駅Ｓ１１…Ｓ００にはデータ・キャリアＴ１１…Ｔ００が存在しないこともあり得る。
【００９１】
もちろん、輸送手段固有チケット情報アイテムを含むデータ・キャリアＴ１０、Ｔ２０が輸送手段ＶＭ１、ＶＭ２内に置かれないこともあり得る。そうではなく、対応するデータ・キャリアＴ１０、Ｔ２０が、個々の路線を図示する路線図または時刻表に組み込まれる。こうした概要マップ、または旅の時刻を示す時刻表は通常、各駅Ｓ１１…Ｓ００内に置かれている。輸送手段ＶＭ１、ＶＭ２の名前Ｓ１１…Ｓ００が現れ、またはこの輸送手段ＶＭ１、ＶＭ２を表す別の記号が配列されている位置に固定されて、それぞれの輸送手段ＶＭ１、ＶＭ２を一意に識別する輸送手段固有チケット情報アイテムを含む非接触読取り可能データ・キャリアＴ１０、Ｔ２０が存在する。もちろん、同一のマップまたは時刻表上に、輸送手段固有チケット情報アイテムを含むデータ・キャリアＴ１０、Ｔ２０と、駅固有チケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００を含むデータ・キャリアＴ１１…Ｔ００とが存在することもあり得る。
【００９２】
上述の実施形態例は、非接触読取り可能データ・キャリアＴ１１…Ｔ００、Ｔ１０、２０が、駅Ｓ１１…Ｓ００、および輸送手段ＶＭ１、ＶＭ２を一意に識別し、また互いに区別するチケット情報アイテムを含む、本発明の特に有利な一実施形態について述べている。これは、上記でより詳細に述べられている利点を有する。
【００９３】
しかし、原則として本発明は、同一の「チケット情報アイテム」だけを含む非接触読取り可能データ・キャリアＴ１１…Ｔ００、Ｔ１０、２０で実装されることもできる。しかし、こうした一実施形態では、運賃の計算はもはや可能ではなく、ユーザは仮想電子チケットの形で旅の許可を購入するにすぎず、この仮想電子チケットはチェックされることもできるが旅のコース（経路）に関する情報が使用できないので、一定額（単位価格）だけ引き落とされなければならない。
【００９４】
こうした一実施形態は、既に述べられている多くの利点、例えば紙のチケットの購入がもはや必要なく、または他の電子チケット・システムより設定および維持が容易であるという事実をやはりもたらす。しかし、図面を参照して述べられた実施形態例に比べて、運賃の正確な計算が不可能であるという欠点がある。
【００９５】
したがって、本発明が実施形態例で述べられたように実施され、非接触読取り可能データ・キャリアＴ１１…Ｔ００、Ｔ１０、２０が駅Ｓ１１…Ｓ００および輸送手段ＶＭ１、ＶＭ２を一意に識別するチケット情報アイテムに加えて、同一の「チケット情報アイテム」をも含めば、特に有利である。システムＶＳＹにチェック・インするとすぐに、次いでユーザは仮想電子チケットの形で旅の許可を受信し、この旅行の許可はチェックされることもできるが、一定額（単位価格）だけ引き落とされなければならない。しかし、次いで乗客が、データ・キャリアＴ１１…Ｔ００、Ｔ１０、２０上で駅／輸送手段を識別するチケット情報アイテムＩＮ１１、ＩＮ２３、ＩＮ００に基づいて可能である実際の旅のコース（経路）に関する情報アイテムのさらなる収集を行なう場合には、ユーザはチェック・アウトする可能性をも有する。既に支払われた一定額（単位価格）が考慮に入れられ、請求額［billing］に含められることができる。したがって、この実施形態では、運賃の正確な計算も可能である。
【００９６】
最後に、従来技術と比べた本発明の利点および違いについて再び言及されるべきである。リーダＭＯＤを使用してユーザによって読み取られる駅Ｓ１１…Ｓ００内のパッシブ無線データ・キャリアＴ１１…Ｔ００の使用により、電池が供給されなければならず、また大幅により高価なものである駅Ｓ１１…Ｓ００内のアクティブ・データ・キャリアＴ１１…Ｔ００は必要ない。したがって、設定、維持および運営コストは削減され得る。さらに、例えば駅内にアクティブ・リーダがある場合のように、パッシブ・データ・キャリアＴ１１…Ｔ００が例えば固定回線を介してバックグラウンドのシステムに接続されることは必要ではない。
【００９７】
ユーザは、その（アクティブ）リーダＭＯＤを使用して、ユーザの旅およびチケットの現在の状態について継続的に通知を受けることができる。
【００９８】
所与の時間枠内で１つまたは複数の旅を記録し、それに応じて多分引き落とすために、駅Ｓ１１…Ｓ００内の高価なアクティブ・スマート・カード・リーダはもはや必要なく、必要とされるのは、駅Ｓ１１…Ｓ００内の安価なパッシブ・データ・キャリアＴ１１…Ｔ００である。
【００９９】
「チケット購入」および引落とし操作は、迅速で単純な便利なやり方で行なわれ、乗客が切符売り場に行き、または、マシンから複雑なやり方でチケットを購入する必要はもはやなく、必要とされるのは、システム・オペレータとの対応する契約の１度限りの締結、または「チケット」クレジットでのモバイル・リーダＭＯＤへの入金である。
【０１００】
好ましくは、ＮＦＣリーダであるモバイル・リーダＭＯＤは、システムＶＳＹが既存の公衆輸送基盤と下位互換性があるように、リーダ（スマート・カード・リーダなど）としての「アクティブ」と、データ・キャリア（スマート・カード、ＩＳＯ１４４３インターフェースなど）としての「パッシブ」の両方のやり方で操作されても良い。
【０１０１】
従来技術の一部をなすようにアクティブ・リーダが駅Ｓ１１…Ｓ００内に既に置かれている場合、モバイル・リーダＭＯＤを有するユーザは同様に、ユーザのモバイル・リーダＭＯＤのＮＦＣインターフェースがパッシブ・データ・キャリアをエミュレートすることもできるので、システムにチェック・インすることができ、それが、システムＶＳＹがより古いシステムと互換性がある理由である。
【０１０２】
最後に、それぞれ個々におよび組み合わせて説明された本発明の特徴および利点、それぞれ個々におよび組み合わせて生じ得る特徴および利点もまた、指摘されるべきである。
【図面の簡単な説明】
【０１０３】
【図１】本発明による一方法について、本発明による旅客輸送システムを概略的に示す図である。
【図２】非接触読取り可能データ・キャリアを対応するモバイル・リーダと共に示す図である。
【図１】
2008509471.tif 000003
【図２】
2008509471.tif 000004
【国際調査報告】
2008509471.tif 000005
2008509471.tif 000006
2008509471.tif 000007