交通網における非接触支払いカードの使用方法及びシステム
交通網の自動料金収集ソリューションは、市販の支払いカード産業によるスマート支払いカード（例えば、マスターカードのペイパス（登録商標）カードを使用する。市販のカード発行者及び銀行から発行されたスマート支払いカードは、非接触支払いカードに対するＩＳＯ１４４４３規格のような共通の又はオープンな業界標準に従う。交通サービスに対するアクセスを要求するカードホルダは、交通網の入口のＲＦＩＤ使用可能なカードリーダにスマートカードを提示する。カードホルダは、スマートカードが「ホット」カード（すなわち、紛失又は盗難カード、満了した又は滞納しているカード）のリストにない場合には迅速に許可される。カード取引記録が準備され、カードリーダから交通支払いプラットホームに送信される。交通支払いプラットホームは、カード取引の認証、クリア及び決済のために通常のカードごとに支払いを行う電子的なネットワークによってカード発行者及び銀行にリンクされる。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願のクロスリファレンス
この出願は、２００５年５月１６日に出願した仮特許出願第６０／６８１，５１３号及び２００５年９月１６日に出願した仮特許出願第６０／７１７，６２６号の利益を主張し、これらの両方を、全体を参照することによってここに組み込む。
【背景技術】
【０００２】
スマートカード技術は、我々の文化及び日々の生活において一般的になりつつある。スマートカードは、マイクロプロセッサ及びメモリチップを組み込んだ又はプログラマブル論理を有するメモリチップのみを組み込んだカードである。マイクロプロセッサカードは、カードに情報を追加し、カードの情報を削除し又はカードの情報を操作し、それに対して、メモリチップカード（例えば、プリペイドテレホンカード）は、予め規定された動作しか保証できない。スマートカードは、磁気ストライプカードとは異なり、全ての必要な機能及び情報を保持することができる。したがって、スマートカードは、取引時にリモートデータベースにアクセスする必要がない。
【０００３】
業界において「マイクロチップカード」又は「チップカード」と一般的に称されるスマートカードは、従来の磁気ストライプカードより大きな記憶容量及びデータのセキュリティを提供する。スマートカードは、８キロバイトまでのＲＡＭ、３４６キロバイトまでのＲＯＭ、２５６キロバイトまでのプログラマブルＲＯＭ及び１６ビットのマイクロプロセッサを有することができる。スマートカードは、シリアルインターフェースを有し、カードリーダのような外部ソースから給電される。プロセッサは、暗号のようなアプリケーション用の制限された命令セットを用いる。スマートカードは、多様なアプリケーション、特に、多数の操作が要求される暗号を組み込んだアプリケーションに用いられる。したがって、スマートカードは、セキュア・デジタル・アイデンティティを保持するカード用のメインプラットホームを有する。大抵の共通のスマートカードアプリケーションは、
＊クレジットカード
＊電子マネー
＊コンピュータセキュリティシステム
＊無線通信
＊（頻繁に飛行機を利用する地点のような）ロイヤリティシステム
＊銀行取引
＊衛星テレビ
＊政府認証
である。
【０００４】
配送セキュリティ、すなわち、アクセスの保証は、許可されたカードホルダによる許可された使用に対してのみ許容され、スマートカードの基本的な属性である。配送セキュリティにおけるスマートカードの有効性は、特に金融サービス及び携帯電話において広く採用され、スマートカードの成長が著しく、かつ、スマートカードが個人識別カードや、有料ＴＶ／エンターテイメントへのアクセスや、医療サービスや、取引のような他のアプリケーションに急速に拡張が予測される理由の一つである。
【０００５】
鉄道、地下鉄、バス、フェリー及び遮断ゲートを含む輸送網又は交通網は、何億もの人々によって利用される。費用効率が高く、有効かつ信頼性のある交通は、現代の大都市圏の市民が必要としている。スマートカードは、紙幣及び硬貨を交通環境から有効に取り除く。スマートカードの支払いは、高速かつ信頼性があるだけでなく、装置メンテナンスのコストを減少するのにも役に立つ。世界中の主要な交通網は、スマートカード技術に基づく新しい支払い機構に移ろうとしている。
【０００６】
複数のＲＦＩＤ技術が、非接触スマートカード及びカードリーダ／端末での使用の際に利用される。非接触システムの基本的な構成要素は、非接触リーダ（又は近接型結合装置（ＰＣＤ））及びトランスポンダである。非接触リーダは、電子回路に接続したアンテナである。トランスポンダは、誘導アンテナと、このアンテナの両端に接続した集積回路から構成される。リーダとトランスポンダとの組合せは、変成器として動作する。交流が、電磁界を生じる１次コイル（リーダのアンテナ）をながれえ、これによって、２次コイル（トランスポンダのアンテナ）に電流が誘導される。トランスポンダは、非接触リーダ（ＰＣＤ）によって伝達された電磁界（ＲＦ界）を、ダイオード整流器によって直流電圧に変換する。この直流電圧は、トランスポンダの内部回路をパワーアップする。両方のアンテナの配置及びチューニングは、一方の装置から他方の装置へのカップリング効率を決定する。トランスポンダを非接触支払いカードとすることができる。
【０００７】
経済的に実現可能であるとともに市販用とすることができる非接触支払いカードシステムに対して、カード及び端末が、特定のカードプロバイダ／発行者、ベンダー又は端末製造者に特有の技術的な特徴を有する場合でも、非接触支払いカードは、ほとんど又は全てのＲＦＩＤ使用可能な支払い端末で相互運用可能となる必要がある。業界全体で相互運用可能であることが望ましい。これに向かって、業界標準機構及びグループ（例えば、国際標準化機構（ＩＳＯ）及び国際電気標準会議（ＩＥＣ））は、非接触スマートカード支払い技術の実現のために規格化された任意の業界標準を有する。ＩＳＯ／ＩＥＣによって規定されたそのような典型的な三つの規格は、密着型カード、近接型カード及び近傍型カードにそれぞれ適用可能なＩＳＯ／ＩＥＣ１０５３６規格、ＩＳＯ／ＩＥＣ１４４４３規格及びＩＳＯ／ＩＥＣ１５６９３である。
【０００８】
最近、譲受人マスターカードインターナショナル社（「マスターカード」）は、近接型（非接触）支払いカード技術の実現のためにメーカ独自仕様のマスターカードペイパス（登録商標）ＩＳＯ／ＩＥＣ１４４４３の実現仕様（「ペイパス」（登録商標））を開発した。ペイパス（登録商標）は、ＲＦＩＤ使用可能な非接触支払いプラットホームであり、これによって、ユーザは、取引を処理するために特別なリーダの前方で装置を軽くたたき又は振ることができる。ペイパス（登録商標）の実現は、ＩＳＯ１４４４３規格に適合し、本発明の原理を表す便利な例を提供する。例えば、Smets等による米国特許出願第１１／１８２，３５４号、米国特許出願第１１／１８２，３５７号、米国特許出願第１１／１８２，３５８号、米国特許出願第１１／１８２，３５６号、米国特許出願第１１／１８２，３５５号及び米国特許出願第１１／１８２，３５１号参照。これらの全ては、参照によりここに組み込まれる。譲受人マスターカードは、クレジット支払いソリューション、デビット支払いソリューション及びプリペイド支払いソリューションを含む、マスターカードファミリーのブランドを利用するオープンな支払いソリューションを提供する国際的なリーダである。さらに、マスターカードは、特に交通の必要のために調整されたプリペイド自社ブランド支払いプログラムを可能とするために良好に配置されている。ペイパス（登録商標）の実現は、典型的には（例えば、５０米ドル未満の）小額に対して迅速なサービス及び高い処理能力を要求するマーチャントの要求に適合することを目的としている。例えば、https://sdp.mastercadintl.com/pdf/pcd_manual.pdfで２００５年１月に利用できるマスターカード支払いカード業界データセキュリティ規格及びwww.mastercadmerchant.com/acquirers/index.htmlで２００５年７月に利用できるとともに２００５年８月に改定されたマスターカードのセキュリティルール及び手順参照。この両方の刊行物は、全体を参照することによりここに組み込まれる。ペイパス（登録商標）形態の他の公知文献は、https://mbe2stl101.mastercard.net/hsm2stl101/public/login/ebusiness/mobile_commerce/paypass/documentation/index.jspで利用できる。
【０００９】
交通網環境で利用される支払いソリューションを高める考察をここで与える。望ましい支払いソリューションは、「オープン」ソリューション、すなわち、交通網に特有の非接触アクセスカード及び／又は交通網を越えて広く市販されているスマートカードを用いてユーザが交通網にアクセスすることができるソリューションである。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は、交通網の自動料金収集（ＡＦＣ）システム及び方法を提供する。
【００１１】
典型的なＡＦＣシステムは、市販のカード発行者によって発行されたＲＦＩＤ使用可能な非接触支払いカードの仕様に基づく。ＲＦＩＤ使用可能な非接触支払いカードは、非接触支払いカードのオープンな業界標準（例えば、ＩＳＯ１４４４３規格）に従う。ＡＦＣシステムは、交通網の有料エリアへの入口に配置されたＲＦＩＤ使用可能なカードリーダと、交通支払いプラットホームとを有する。ＲＦＩＤ使用可能なカードリーダを、端末又はステーションコントローラに結合することができる。ＡＦＣシステムは、取引支払い認証プロセス、クリアプロセス及び決済プロセスをカード支払い産業に共通の電子ネットワーク上で行うよう設計された交通支払いプラットホーム又はアプリケーションも有する。
【００１２】
交通網のゲートの有料エリアへのアクセスを所望する顧客は、料金を支払うために、ＲＦＩＤ使用可能なカードリーダによって読み出される非接触支払いカード（例えば、マスターカードのペイパス（登録商標）カード）を提示する。カードリーダ／端末コントローラは、ホットカード（すなわち、紛失、盗難、満了又は滞納と報告されたカード）のリストに対して、読み出した非接触支払いカードデータを評価し、それに応じて、交通網のゲートの有料エリアへの顧客のアクセスを許可し又は拒否する。カード取引記録は、支払い認証、クリア及び決済のために交通支払いプラットホームと通信を行うよう準備される。１回の乗車の料金に対して、取引の支払いは、カード発行者により顧客のカードアカウント（例えば、クレジット又はデビットアカウント）にチャージされる。
【００１３】
交通支払いプラットホームを、非接触支払いカードにリンクしたプレファンド交通アカウントを顧客が登録し又はセットアップするように形成することもできる。プレファンドアカウントは、通貨バランス（例えば、ドルの総額）、乗車決済バランス（例えば、乗車回数）又はタイムバランスを有することができ、これらは、例えば、ペーパーライドチケットの料金、最大乗車数ごとのチケットの料金及び制限のない乗車チケットの料金に対応する。そのような非接触支払いカードによる料金取引に対して、交通支払いプラットホームは、取引を行う顧客の非接触支払いカードに関連したプレファンド交通アカウントに対する取引の支払いを決済する。
【００１４】
本発明の他の態様、性質及び種々の利点を、添付図面及び以下の詳細な説明から明らかにする。
【発明を実施するための最良の形態】
【００１５】
本発明は、交通網の自動料金収集（ＡＦＣ）ソリューションを提供する。スマートカードの使用に基づくこのようなＡＦＣソリューションは、交通網で実現される自動料金収集システム及び手順を提供する。自動料金収集システム及び手順は、例えば、通貨取り扱い手数料、自動券売機及び回転式改札口の維持費、料金媒体調達価格（例えば、プラスチック／紙の料金前払いカード）並びに営業中のスタッフを配備したチケットブースの数を減少することによって、操業コストを大幅に減少することができる。ＡＦＣソリューションは、非接触支払い装置の共通の又はオープンな業界標準（例えば、ＩＳＯ１４４４３規格）に適合するスマートカード（例えば、マスターカードのペイパス（登録商標））に基づく。
【００１６】
図１は、交通網の典型的な電子支払いソリューション１００の論理的及び構成的な要素を示すブロック図である。典型的な電子支払いソリューション１００は、マスターカードのペイパス（登録商標）の実現に基づく。ソリューション１００において、カードホルダを、発行者１２０によって発行されたペイパス（登録商標）カード１１０とする。顧客は、例えば、交通網の門のある有料エリアへの入場するために回転式改札口（例えば、地下鉄の回転式改札口又はゲート）で料金を支払うようペイパス（登録商標）カードを提示することができる。回転式改札口１３２には、自動料金収集（ＡＦＣ）の際に顧客によって提示されたペイパス（登録商標）カードを電子的に読み出すためにＲＦＩＤイネーブルカードリーダ１３０が設けられる。カードリーダ１３０は、オプションの端末コントローラ１５０及びペイパス（登録商標）交通支払いプラットホーム１６０を通じて交通網の支払いホスト１４０に電子的にリンクされる。顧客の料金支払いを、例えば、小売業界においてペイパス（登録商標）クレジット又はデビットカードの支払取引を処理するのに用いられる現行のカードによる支払い形態と同様に電子的に処理することができる。このために、交通機関支払いホスト１７０は、従来のカードによる支払いの電子的なネットワーク１９０を通じてカード発行者１２０及び他の団体又は機関にリンクされている。取引支払い処理ステップ（例えば、取引／支払い認証要求ステップ、承認ステップ及び決済ステップ）は、ネットワーク１９０によってリンクされた取得者１７０やペイパス（登録商標）カード団体１８０（例えば、マスターカード）のような従来の電子的な支払いのインフラストラクチャエンティティを伴う。
【００１７】
支払いソリューション１００の実現に際し、顧客は、顧客のペイパス（登録商標）カードにリンクされる予め供給される交通料を設定し及び登録することができる。実際には、顧客は、交通網の門のある有料エリアにアクセスするために、交通の回転式改札口１３２に装着されたカードリーダ１３０に顧客のペイパス（登録商標）カード１１０を提示し又は「タップ」することができる。カードにエンコードされたデータが読み出され、端末コントローラ１５０に送信される。端末コントローラ１５０は、カードを許可し又は拒絶することによって応答する。それに応じて、顧客は、回転式改札口へのアクセスが与えられ又は否定される。端末コントローラ１５０のソフトウエアは、取引データ記録をペイパス（登録商標）交通支払いプラットホーム１６０に送信する。ペイパス（登録商標）交通支払いプラットホーム１６０は、カード端末ソフトウエアの継続的なメンテナンスとともに、取引に必要な認証及びバッチ合意処理機能を提供する。
【００１８】
説明のためのペイパス（登録商標）の実現の選択は例示に過ぎず、本発明の原理を、他の共通の又は専用の規格の下で動作する電子的な支払い装置又はシステムに更に一般的に適用することができる。他の電子的な支払い装置及びシステムは、アメリカンエキスプレスのエキスプレスペイやビザウェーブのような非接触カードに基づくことができる。ペイパス（登録商標）の実現により、交通環境にオープンな支払いをもたらすとともに、配置しようと計画されている交通機関又は既に配置された交通機関に対する新たなオプションを、スマートカードに基づく支払いソリューションに提供する。ペイパス（登録商標）の実現を、交通機関及びその顧客に有用となるようオープンな支払いソリューションを利用するために好適に調整することができる。
【００１９】
さらに、本発明による支払いソリューションのアプリケーションを、ニューヨーク市の大都市交通局（ＭＴＡ）によって操作される典型的な地下鉄交通網ＮＹシティー交通（ＮＹ交通）を参照してここで説明する。ＭＴＡ／ＮＹ交通の選択は説明のみのためであり、本発明による電子支払いソリューションを、他のあらゆる交通網（例えば、スターテン島鉄道、ロングアイランド鉄道、ロングアイランドバス、メトロノース鉄道、並びに橋及びトンネル）に利用することができる。
【００２０】
電子支払いソリューション１００を、複数の交通網（例えば、地下鉄、バス、鉄道等）間で統合されたＡＦＣアプリケーションに対して設計することができ、ＡＦＣに対してＭＴＡの橋及びトンネル操作の際に配置されるＥ−ＺＰａｓｓソリューションのような他の電子支払いソリューションに統合することもできる。
【００２１】
図１を更に参照すると、ソリューション１００は、あらゆる適切な数の種々のカードタイプ及びカード分配モデルとともに操作可能である。これらの種々のカードタイプの交通機能は、交通支払いプラットホーム１４０の適切な設計によってイネーブルされる。
【００２２】
適切な数のカードタイプ及びカード分配モデルを、交通網の利用者数の割合を経済的に広げるようスマートカードの使用を拡張する観点から選択することができる。選択されたカードタイプは、例えば、１回の乗車をサポートするカード、操作の時間に基づく（制限のない乗車）モード、及び／又は、操作の乗車ごとの支払いモードをサポートする値に基づくカードを含む。あり得るカード分配モデルの例は、次のものを含む。
【００２３】
（１）銀行が発行したカード（例えば、マスターカードのペイパス（登録商標））
銀行は、マーチャントのカードホルダによる一般的な使用のためにペイパス（登録商標）がイネーブルされた標準的なクレジットカード又はデビットカードを発行することができる。これらペイパス（登録商標）カードを、ＭＴＡシステム内での旅行に用いることもでき、これらペイパス（登録商標）カードは、ある地域への頻繁でない旅行者及び訪問者に加えて規則的な通勤者の必要に応じることができる。カードを、（Ｅ−ＺＰａｓｓと同様に）ＭＴＡ環境内でのみ費やされる乗車ごとに支払われる予め設定された交通料を設定するために交通網によって登録することができる。登録されたペイパス（登録商標）カードは、値に基づく（乗車ごとの支払い）又は時間に基づく（制限のない乗車）製品に対して規則的なメトロカードの機能を実行することができる。登録されていないペイパス（登録商標）カードを、各月の少数の乗車に対してゲートで支払いを行うためにＭＴＡ内で用いることができる。
【００２４】
（２）ＭＴＡ／銀行提携カード（例えば、ＭＴＡ／マスターカードペイパス（登録商標）提携メトロカード）
提携カードを、「通勤」カード、「都市」カード又は「旅行」カードとして銀行により市販し及び発行することができる。ＭＴＡシステム内で、提携カードは、値に基づく（乗車ごとの支払い）又は時間に基づく（制限のない乗車）製品に対して、磁気ストライプ機能に基づく規則的なメトロカードチケットの機能と同様な機能を有する。カードは、ＭＴＡ環境外では通常の銀行支払いカードとして機能する。全てのカードホルダは、記録時のカードホルダ選択により値に基づいて（乗車ごとの支払い）又は時間に基づいて（制限のない乗車）、旅行のために交通網によって自動的に登録される。
【００２５】
（３）ペイパス（登録商標）を備えたＭＴＡ自社ブランドカード
ＭＴＡ自社ブランドカードは、システムの規則的な使用者であるが旅券に銀行支払いカードを組み合わせることを所望しない利用者をターゲットとすることができる。ＭＴＡ及びその代理店は、発行パートナーを通じて自社ブランドカードを分布することができる。このカード製品は、値に基づく（乗車ごとの支払い）又は時間に基づく（制限のない乗車）製品に対して規則的なメトロカードの機能と同様な機能を有する。
【００２６】
ＭＴＡ自社ブランドカードは、ＭＴＡ環境内でのみ用いることができる実際のプリペイドカードである。ＭＴＡ自社ブランドカードは、預金した顧客及び／又は旅行のために個別の支払いカードを所望する顧客に対して適切である。顧客は、カードを得るために料金を支払い及び／又は預金を行うことができる。全てのカードホルダは、記録時のカードホルダ選択により値に基づいて（乗車ごとの支払い）又は時間に基づいて（制限のない乗車）、旅行のために交通網によって自動的に登録される。
【００２７】
実際には、マスターカード及びその加盟銀行は、米国中で取引を迅速に行うためにＲＦＩＤイネーブルされたペイパス（登録商標）の概念を促進する。配置がニューヨーク市以外の地域で行われるので、ある区域から他の区域で利用できる交通機能をリンクアップし始めることができる。先ず、これを、地域に基づいて行うことができるが、全国的に拡大することができる。したがって、米国の他の地域からの訪問者は、現存するペイパス（登録商標）カードを用いてＭＴＡシステムに入ることができる。これによって、ＭＴＡのコストが減少するとともに、利用者のシステム全体に亘る有用性が向上する。ペイパス（登録商標）のソリューションをＭＴＡに採用することによって、利用者は、マスターカードのペイパス（登録商標）カードを用いてアルバニーからニューヨーク市に旅行することができる。
【００２８】
マスターカードのペイパス（登録商標）に基づくソリューション１００の典型的な実現を、交通網によって用いられる既に存在する料金体系及びカード又はチケットタイプに一致し又は適合することができる。付記Ａは、ＭＴＡ／ＮＹ交通の料金体系を示す。さらに、付記Ｂは、これまで説明した三つのカードタイプの各々によってサポートされる交通料体系の比較を表で示す。
【００２９】
ソリューション１００を、任意の数のＡＦＣアーキテクチャ又は形態をサポートするように構成することができる。典型的なＡＦＣアーキテクチャ−「ホストプラス分散型ネガティブファイル」は、標準的なペイパス（登録商標）支払いカードの使用に基づく。このアーキテクチャにおいて、特定の交通アプリケーションを支払いカードにロードする必要がない。顧客は、料金収集のために回転式改札口１３０／リーダ１３２に標準的なペイパス（登録商標）カード１１０を提示する。回転式改札口１３０は、カードデータ（例えば、個人口座番号、有効期限及び認証コード）を確認し、カードがネガティブファイル又はほっとリストにリストされているか否か検査する。カードがネガティブファイルにリストされている場合、回転式改札口１３０／端末１５０は、交通網のゲートの有料エリアへの顧客のアクセスを拒否する。それに対して、カードがネガティブファイルにリストされていない場合、回転式改札口１３０／端末１５０は、ゲートを動かし、顧客が交通網の有料エリアにアクセスするのを許容する。回転式改札口１３０／端末１５０は、カードの使用に関連した生の取引データ記録を、１回の乗車、乗車ごとの支払い及び制限のない乗車の取引を処理するよう形成された交通支払いプラットホーム１６０に同時に又は後に送信する。交通支払いプラットホーム１６０は、生の取引を交通網（例えば、ＭＴＡ）から受け取り、生の取引を、登録された顧客アカウントに対して処理する。適切な場合には、交通支払いプラットホームホスト１４０は、１回の乗車取引データを、更なる処理のために取得者１７０に送信することができる。交通支払いプラットホームホスト１４０は、例えば端末コントローラ１５０を通じて回転式改札口１３０に分配されるネガティブファイルを発生し及び維持する。
【００３０】
他の典型的なＡＦＣアーキテクチャ−「ホストプラス分散型ネガティブファイル」は、標準的なペイパス（登録商標）支払いカードの使用に基づく。このアーキテクチャにおいて、交通支払いプラットホームホスト１４０は、エンタイトルメントのポジティブファイルを交通網の回転式改札口１３０に分配する。エンタイトルメントを、有効な制限のない乗車カードとポジティブプリファンドバランスを有する有効値に基づくカードとのリストとして表すことができる。顧客が料金収集のために標準的なペイパス（登録商標）カード１１０を回転式改札口１３０／リーダ１３２に提示すると、回転式改札口１３０は、カードデータを確認し、カードがエンタイトルメントリストにリストされているか否か検査する。カードがエンタイトルメントファイルにリストされている場合、回転式改札口１３０は、ゲートを動かし、顧客が交通網の有料エリアにアクセスするのを許容する。それに対して、カードがエンタイトルメントファイルにリストされていない場合、回転式改札口１３０は、交通網のゲートの有料エリアへの顧客のアクセスを拒否する。回転式改札口１３０は、カードに関連した生の取引データ記録を交通支払いプラットホームホスト１４０に同時に又は後に送信することができる。交通支払いプラットホームホスト１４０は、取引を処理し、分配を回転式改札口１３０に戻すためにエンタイトルメントファイル及びバランスを更新する。
【００３１】
ホストプラス分散型エンタイトルメントアーキテクチャは、ホストプラスネガティブファイルアーキテクチャとともに未払い乗車の発生を大幅に減少することができる。しかしながら、ホストプラス分散型エンタイトルメントアーキテクチャで用いられるエンタイトルメントファイルが大きくなることがある。大きなエンタイトルメントファイルは、ホストプラスネガティブファイルアーキテクチャで用いられる小さなネガティブファイルに必要なメモリに対して、回転式改札口１３０／端末コントローラ１５０に追加のメモリを設ける必要がある。
【００３２】
ホストプラスネガティブファイルアーキテクチャのように、ホストプラス分散型エンタイトルメントアーキテクチャは、標準的なペイパス（登録商標）カードを用いる。特定の交通アプリケーションをカードにロードする必要がない。
【００３３】
更に別の典型的なアーキテクチャ−「ホストプラススマート発見アプリケーションオンペイパス（登録商標）カード」は、特定の交通アプリケーションによって機能強化された標準的なペイパス（登録商標）カードを用いる。特定の交通アプリケーションは、リアルタイムの乗車及びシャドープレファンドバランスを記録する。カードのプレファンドバランス／エンタイトルメントを、例えば、ＭＴＡペイパス（登録商標）が使用可能な自動販売機において顧客によって更新することができる。このアーキテクチャにおいて、回転式改札口１３０／リーダ１３２は、カードに記憶された乗車記録を読出し及び更新するように構成される。顧客が料金収集のために標準的なペイパス（登録商標）カード１１０を回転式改札口１３０／リーダ１３２に提示すると、回転式改札口１３０は、カードデータを確認し、カードがネガティブファイル又はエンタイトルメントファイルにリストされているか否か検査する。さらに、自動的な料金収集取引処理を、これまで説明した二つのＡＦＣアーキテクチャの処理と同様に行うことができる。
【００３４】
図２は、公共交通網におけるホストプラス分散型ネガティブファイルＡＦＣアーキテクチャの典型的な実現であるＡＦＣソリューション２００を示す。このソリューションの構成要素は、ペイパス発行者２９０のようなエンティティと、標準的なペイパス（登録商標）カード／装置２１０、ゲートリーダ２２０、券売機２３０、バス料金箱２４０、ステーションコントローラ２５０、交通網ホスト２６０、交通支払いプラットホーム２７０、ペイパス（登録商標）カード発行者２９０、再供給ホスト２８０、電子支払いネットワーク（マスターカードネットワーク２９２）等のソフトウェアコンポーネント及びハードウェアコンポーネントとを有する。
【００３５】
ＡＦＣソリューション２００において、ペイパス（登録商標）カード／装置２１０を、マスターカードペイパス（登録商標）アプリケーションを含むＩＳＯ１４４４３スマートカード又は他の装置（例えば、キーフォブ）とすることができる。ゲートリーダ２２０を、ＩＳＯ１４４４３カードリーダ及びペイパス（登録商標）端末アプリケーションによって増強された通常の回転式改札口又はゲートとすることができる。同様に、バス料金箱２４０を、ＩＳＯ１４４４３カードリーダ及びペイパス（登録商標）端末アプリケーションによって増強された通常のバス料金箱とすることができる。券売機２３０を、地下鉄の駅においてＭＴＡによって現在は位置されている券売機と同様な通常の券売機とすることができる。ステーションコントローラ２５０を、ペイパス（登録商標）取引を処理するとともにネガティブファイルを取り扱うように変更された通常のステーションコントローラとすることができる。交通網ホスト２６０を、ＭＴＡによって用いられる現存する交通網ホストとすることができる。交通料支払い取引を、ホスト２６０及び取引支払いプラットホーム２７０を通じて、米国及び世界のマスターカードの取引を処理し及び送出するように配置されたマスターカードネットワーク２９２に送出することができる。交通料支払い取引を、個別のゲートウェイホスト（例えば、ネットワークゲートウェイ２９６）を通じてマスターカードネットワーク２９２に送出することもできる。交通料支払い取引の送出の代わりとしてネットワークゲートウェイ２９６を用いることによって、ＭＴＡによって用いられる現存するシステムホストの処理ロード又は影響を最小にすることができる。
【００３６】
マスターカードネットワーク２９２は、交通支払いプラットホーム２７０、オプションの再供給ホスト２８０、ペイパス（登録商標）発行者２９０及びペイパス（登録商標）マーチャントＰｏＳ２９４にリンクする。ペイパス（登録商標）発行者２９０を、ペイパス（登録商標）クレジットカード又はデビットカードの通常の発行者（例えば、マスターカード加盟銀行）とすることができる。図２において、ペイパス（登録商標）マーチャントＰｏＳ２９４は、マスターカードペイパス（登録商標）クレジットカード及びデビットカードのマーチャント承認（例えば、小売店−顧客販売）のためのＭＴＡの外側のセールインフラストラクチャのポイントを表す。
【００３７】
交通支払いプラットホーム２７０を、ＭＴＡ／ＮＹ交通網及び他の交通網（例えば、交通網２９８）の１回の乗車、乗車ごとの支払い及び制限のない乗車の取引を管理するのに適切に構成されたホストシステムとすることができる。交通支払いプラットホーム２７０は、ＭＴＡ交通網ホスト２６０又は他のネットワークゲートウェイ２９６から生の取引を受け取り、登録されたカードホルダアカウントに対する生の取引を処理する。交通支払いプラットホーム２７０は、適切な場合には、１回の乗車の取引を第三者（例えば、取得者）に送り出すことができる。さらに、交通支払いプラットホーム２７０は、ステーションコントローラ２５０に分配するためにＭＴＡ交通網ホスト２６０に戻されるネガティブファイルを発生し又は維持する。
【００３８】
オプションの再供給ホスト２８０を、値及び時間に基づく（プレファンド）カードアカウントを自動的に又は要求に応じて再ロードするように構成されたホストシステムとすることができる。再供給は、値をプレファンドアカウントにロードするマスターカードのブランドのついた設備である。再供給ホストは、例えば、インターネット、テキストメッセージ又は電話を通じて再ロード要求を簡単にする適切なインタフェースを有することができる。再供給ホスト２８０は、更新された再ロード情報を、リンクされた交通支払いプラットホーム２７０に供給する。
【００３９】
顧客が料金支払いのためにペイパス（登録商標）カード／装置２１０を提示すると、ソリューション２００は、料金のタイプ（例えば、１回の乗車、値に基づく乗車ごとの支払い、又は時間に基づく支払い）に従ってＡＦＣに対する典型的なペイパス（登録商標）交通カード処理手順３００を用いることができる。ゲートリーダ２２０及び／又は交通支払いプラットホーム２７０で行われる典型的な処理ステップ及び結果を、表１にリストする。
【００４０】
【表１−１】
【表１−２】
【００４１】
表１に示すように、ペイパス（登録商標）交通カード処理手順３００は、２段階におけるペイパス（登録商標）カードの使用のチェックを有する。先ず、提示されたカードが、ゲート２２０でネガティブファイルに対してチェックされる（ステップ３１２）。次に、３２０において、提示されたカードが、交通支払いプラットホームでチェックされる（支払い認証ステップ３２２ａ，３２３ａ及び乗車エンタイトルメントチェックステップ３２４ａ）いずれかのチェックで否定されると、カードはネガティブファイルに加えられる。
【００４２】
交通支払いプラットホームチェックを、非同期的に（すなわち、カード提示後に）行うことができる。したがって、カードが第１の「ゲート」チェックをクリアしたカードホルダは、後の交通支払いプラットホームチェックが否定されたとしても交通網のゲートの有料エリアにアクセスすることができる。
【００４３】
提示されたカードがネガティブファイルに存在しないことの確認に加えて、ゲート２２０で実行されるゲートチェック（ステップ３１２）は、カードデータのフォーマットが正確であること及びカードが満了していないことの確認を含むことができる。ゲートチェックは、他の認証、例えば、速度プロファイリング（すなわち、提示されたカードが同日に同一の交通ステーションで固定回数を超えて用いられなかったことの認証）を含むこともできる。
【００４４】
同様に、交通支払いプラットホームチェックは、提示されたカードが満了せず、かつ、紛失又は盗難として報告されていないカードのリストにないことの認証を含むことができる。交通サービス業者に紛失又は盗難として報告されたＭＴＡ自社ブランドカードに対して、サービス業者は、紛失又は盗難として報告されたカードの交通支払いプラットホームリストを更新することができる。マスターカードブランドのカードに対して、交通支払いプラットホーム２７０は、マスターカードの広域紛失／盗難カードファイルにアクセスするとともに、提示されたカードが紛失又は盗難として報告されていないことを確認するために当該ファイルを用いることができる。
【００４５】
交通支払いプラットホーム２７０を、料金プランのルール（例えば、経路／路線間の乗換に関するルール）を実現するために取引データ記録の更なるチェックを行うように構成することができる。そのようなルールを実現するのに適切な場合には、交通支払いプラットホーム２７０は、追加の支払い取引を発生することができる。料金ルールを実現するよう設定されたチェックは、料金取引のタイプに依存する。例えば、１回の乗車の取引に対して、追加のチェックは、１ヶ月の最大乗車数（例えば、１０）を超えなかったこと及び支払いがカード発行者によって承認されたことの認証を含むことができる。乗車ごとの支払いの取引に対して、追加のチェックは、カードホルダのプレファンド交通アカウントバランスが運賃を支払うのに十分であることの認証を有することができる。制限のない乗車取引に対して、追加のチェックは、カードホルダの制限のない旅行期間を満了していないこと及び制限された期間（例えば、磁気ストライプ技術を用いるＭＴＡメトロカードに対して現在のところ１８分）内にカードが同一ステーションで複数回提示されなかったことの認証を含むことができる。
【００４６】
ＡＦＣソリューション２００は、カードホルダが不適切にシステムにアクセスするのを防止するためにカードのホットリスト（すなわち、ネガティブリスト）に頼る。カードがネガティブファイルに含まれる場合、交通網の有料エリアのゲートは開かない。実際には、不適切なアクセスを防止するこの方法の有効性は、ネガティブファイルが更新されるとともに交通網全体に亘って分配される頻度に依存する。更新されたネガティブファイルを、通常は毎日分配することができる。しかしながら、更に頻繁に更新／分配を行うことによって、未払い乗車の発生が減少する。
【００４７】
ＡＦＣソリューション２００を、適切なときにはカードリストをネガティブファイルから除去又は削除するよう構成することもできる。例えば、ペイパーライドカードがロードされ又は制限のない乗車カードが更新されたとき、ネガティブファイルのあらゆる対応するエントリが除去される。更新されたネガティブファイルは、ネガティブファイルの次の分配後にのみ効力を生じることができる。毎日の分配スケジュールの場合、これは、ペイパーライド／制限のない乗車カードが次の日からのみ旅行に有効であることを意味する。ネガティブファイルの更に頻繁な更新及び分配を所望することができる。
【００４８】
図２は、値をプレファンド交通アカウントにロードするマスターカードブランドの設備である再供給ホスト２８０を示す。カードホルダは、インターネットを通じてフォームを満たすことにより又は交通アカウントセットアップ手順の一部として再供給を登録することができる。登録に従って、カードホルダは、インターネット、電話、携帯電話テキストメッセージ、ｅメール又はＩＶＲＵを通じてプリファンド交通アカウントをトップアップすることができる。再供給設備を、ＡＴＭ，ＰｏＳ装置、マシンに拡張することもでき、可能な場合には、現存する発券業者に拡張することができる。
【００４９】
ソリューション２００を、アカウントバランスが所定レベルより下になるときに関連のデビットカード又はクレジットカードからプレファンド交通アカウントに値を再充填する自動トップアップオプションをカードホルダに設けるように構成することができる。値を充填する取引において、再供給ホスト２８０は、先ず、未払いの乗車に対する運賃を引き出すことができ、又は交通料に対する指定されたロード量に返金を追加することができる。さらに、再ロードされたカードに関連したネガティブファイルのエントリが削除される。
【００５０】
同様に、制限のない乗車券が購入され又は更新されると、あらゆる未払いの料金が購買量に加えられる。さらに、更新された制限のない乗車券に関連するネガティブファイルエントリが削除される。
【００５１】
ＡＦＣソリューション２００は、交通網動作の他の従来の態様に影響を及ぼすことがある。しかしながら、ＡＦＣソリューション２００を、影響が及ぼされる態様を向上し又はかかる態様に適合するために変更することができる。例えば、ＡＦＣソリューション２００の下では、交通網の乗客は、電車内の車掌によって点検することができる従来のペーパーチケットを有しない。車内での点検が所望される場合には、ソリューション２００は、車内の車掌又は検札係に携帯用ペイパス（登録商標）カードリーダを設けることができる。携帯用ペイパス（登録商標）カードリーダを、乗客によって提示されるペイパス（登録商標）カードを点検するために用いることができる。携帯用ペイパス（登録商標）カードリーダに、乗客の料金エンタイトルメント又は支払いを例えば交通網ホストによって確認できるように移動通信機能を設けることができる。
【００５２】
ＡＦＣソリューションは、２タイプの取引及び支払いの決済を伴うことができる。第１のタイプの決済は、ペイパス（登録商標）発行者２９０によって認証された１回の乗車の取引に関連する。これらの取引の決済を、第三者（例えば、図１の取得者）を通じて交通支払いプラットホーム及びＭＴＡに送り出すことができる。１回の乗車の取引の決済は、取引の集約又は予め認証された量の使用を伴うことができる。乗客又は口座名義人によって複数の１回の乗車の取引を集約する取引の集約は、有効な決済を行うことができる。
【００５３】
第２のタイプの決済は、ペイパーライド又は制限のない乗車のペイパス（登録商標）カードを用いて行われる乗客の取引に関連する。このタイプの決済は、交通支払いプラットホーム２７０とＭＴＡとの間で直接的に行うことができる。このために、適切な業務用の装置を、交通支払いプラットホーム２７０のオペレータとＭＴＡとの間にセットすることができる。
【００５４】
これまでの説明は、本発明の原理を説明するためだけのものであり、種々の変更を、本発明の範囲を逸脱することなく当業者によって行うことができる。例えば、ＭＴＡ／ＮＹ交通の地下鉄のＡＦＣソリューション２００を、ＭＴＡバス又は他の輸送モードに容易に拡張することができる。そのような拡張において、バス若しくは他の車両又はアクセスポイントに、現存する料金箱／検札器２４０に取り付けられたスマートカードリーダを設けることができる。取引は装置内に格納し、バスがベースに戻るときにホストシステムにダウンロードされる。さらに、例えば、ＡＦＣソリューションの原理を、簡潔のためにここでは更に詳しく説明しないホストプラススマート発券アプリケーションオンペイパス（登録商標）カードアーキテクチャ及びホストプラス分散型エンタイトルメントアーキテクチャの実現に容易に拡張することができる。
【００５５】
図３は、ＭＴＡ／ＮＹ交通のＡＦＣソリューションに基づくペイパス（登録商標）のデモンストレーションに関連したペイパス（登録商標）交通支払いプラットホーム５１０及び地下鉄回転式改札口インフラストラクチャ５２０の所望される又は必要な機能を示す。同様に、付記Ｃは、主要な構成要素の各々の機能及び処理ステップをリストする。
【００５６】
地下鉄回転式改札口インフラストラクチャ５２０：全てのペイパス（登録商標）リーダ５２２及び端末５２４のハードウェア及びソフトウェアは、好適には、発行されたマスターカードのペイパス（登録商標）に従う。ペイパス（登録商標）リーダ５２２及び端末５２４は、好適には、許可されていない情報へのアクセスを防止するために情報を格納し及び（例えば、暗号形態で）安全に情報を送信する。ペイパス（登録商標）リーダ５２２及び端末５２４は、好適には、通信エラー時の情報値を記憶し又は記録することができる。これらの記録（例えば、エラーログ及び取引ログ）が一度充満されると、記録された情報が端末５２４からアップロードされるまでデータを上書きすることができない。ペイパス（登録商標）交通支払いプラットホーム５１０と通信を行うとき、ペイパス（登録商標）リーダ５２２及び端末５２４は、好適には、（例えば、装置が正確に機能する）装置状態情報を提供する。
【００５７】
ペイパス（登録商標）交通支払いプラットホーム５１０：ペイパス（登録商標）交通支払いプラットホーム５１０は、回転式改札口のアクセスに対するペイパス（登録商標）取引のみを処理する。現存する全ての回転式改札口へのアクセスのレガシー機能は、現存する交通機関のインフラストラクチャ（例えば、ステーションコントローラ５０４、発券機５０６）を利用し続けることができる。
【００５８】
ペイパス（登録商標）交通支払いプラットホーム５１０は、ペイパス（登録商標）取引に関連した動作を管理するアプリケーションを有する。これらアプリケーションは、顧客アカウント管理アプリケーション６０２及び６０４と、アカウントメンテナンスアプリケーション５１２と、支払い処理アプリケーション５１６と、ファイル管理アプリケーション５１６と、ネットワーク管理アプリケーション５１８とを有する。ペイパス（登録商標）支払いプラットホーム５１０は、ペイパス（登録商標）取引の処理をサポートする際にＭＴＡシステムとやり取りを行うことができる。ペイパス（登録商標）交通支払いプラットホーム５１０は、毎日の動作（例えば、得られた認証、金の調達のために設定された取引、回転式改札口の動作等）をＭＴＡに報告する適切な管理報告機能を有することができる。
【００５９】
ペイパス（登録商標）交通支払いプラットホーム５１０は、プレファンド顧客アカウント及びポストファンド顧客アカウントをそれぞれ管理する顧客アカウント管理アプリケーション６０２及び６０４を有する。２タイプのアカウントの取引は、異なる支払い処理フロー（すなわち、取引認証フロー及びクリーニングフロー）を有する。
【００６０】
ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、ペイパス（登録商標）カード番号を回転式改札口入場用のプレファンドアカウントにリンクする機能（予備登録）を有する。ファンディングオプションは、自動ローディング、カードホルダが要求したウェブサイトの再ロード、ＳＭＳ等を有することができる。さらに、ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、プレファンドアカウントを確立し及び維持するためのカードホルダに対する機構を有する。ペイパス（登録商標）交通支払いプラットホーム５１０は、集約したポストファンド取引及び／又はプレファンド取引に関する乗車履歴並びにプレファンドアカウント「トップアップ」動作に関連した取引履歴をカードホルダが取得できるウェブに基づく顧客インタフェースを提供することができる。ウェブに基づく顧客インタフェースは、プレファンドアカウントに対する登録及び未登録をカードホルダに許容することもできる。
【００６１】
図４は、発行銀行によりペイパス（登録商標）カードが郵送された顧客が交通網で使用するためにペイパス（登録商標）カードを予め登録するとともにカードをプレファンド交通アカウントにリンクすることができるプロセッサ４００を示す。プロセス４００のステップ４１において、銀行は、ペイパス（登録商標）カードをカードホルダに郵送する。ステップ４２において、カードホルダは、交通網にカードを登録するよう選択を行う。カードホルダがカードの登録を選択しない場合、カードホルダは、交通網で予め支払われた料金の取引に対してカードを用いることができる。カードホルダがカードを登録することを選択する場合、ペイパス（登録商標）交通支払いプラットホーム５１０は、ステップ４３において、カードに関連したプレファンドアカウントを自動クレジットサービス（ＡＣＳ）でセットアップする。カードホルダは、ステップ４４において、プレファンドアカウントに対して自動再ロード形態を起動することを更に選択することができる。カードホルダが、自動再ロードを行うことを選択しない場合、プレファンドアカウントは、１回の値を割り当てる（ステップ４６）。それに対して、カードホルダが自動再ロード形態を起動することを選択する場合、ステップ４５において、アカウントロードリミットが、自動的な再ロードに対して設定される。ステップ４５は、カードホルダの制限を検査するために従来のアドレス検証サービス（ＡＶＳ）を利用することができる。３回の連続的な登録の試みに対してＡＶＳ検査が否定された場合、発行銀行に通知を行うことができる。しかしながら、否定されたカードを自動的にホットリストに挙げないようにすることができる。発行銀行は、必要な情報を有し、カードをホットリストに挙げ又はＡＶＳ検査パラメータをリセットすることができる。
【００６２】
カードを予め登録すると、ペイパス（登録商標）交通支払いプラットホーム５１０は、交通機関が規定した料金オプション（例えば、一括購入の値引き、５個買うごとに１個がただになる、等々）の選択をカードホルダに許容する交通機関の料金ルール（例えば、付記Ａ参照）へのアクセスを有することができる。
【００６３】
ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、プレファンドアカウントの「トップアップ」動作に関連した認証及びクリア機能を実行することができる。交通機関を、これらの取引のマーチャントとすることができ、既に設定されている現存するマーチャント／取得者関係を利用することができる。ペイパス（登録商標）交通支払いプラットホーム５１０は、全てのプレファンドアカウントのバランスを維持し及び管理することができる。予め登録されたカードアカウントバランスが使い尽くされて再ロードされない場合、カードはネガティブファイルに加えられる。もはやプレファンド機能を用いることを所望せずにポストファンド機能を用いることを所望することを決定するカードホルダに対して、キャンセル機能を設けることができる。自動ロード機能が予め設定されている場合、カードホルダに対して、自動ロード機能のみ又は自動ロード機能とプレファンドアカウントそれ自体の両方の選択を与えることができる。プレファンドアカウントは、１８分間に６回までの乗車に対して「パスバック」を許容する。一旦、プレファンドペイパス（登録商標）装置が損失したことを報告されると、カードホルダは、新たなペイパス（登録商標）アカウントに転送された残りの値を取得することができる。
【００６４】
ポストファンドアカウントに対して、ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、予め規定されたビジネスルールのセットに基づいて後にクリアし及び認証するために支払いカード取引を集約することができる。実証プロジェクトに対して、マスターカード、交通機関及びカード発行者は、共同でルールを規定することができる。ポストファンドアカウントは、１８分間に６回までの乗車に対して「パスバック」を許容する。
【００６５】
ポストファンド取引の認証手順を、以下のようにすることができる。
【００６６】
あらゆる取引の開始時に、ペイパス（登録商標）交通支払いプラットホーム５１０は、回転式改札口で用いられるカードが既に設定されたプレファンドアカウントを有するか否か検査し、プレファンドアカウントが見つからない場合、取引はポストファンドであると考えることができる。
【００６７】
最初のポストファンド取引に対して、ペイパス（登録商標）交通支払いプラットホーム５１０は、認証を行うことができる。この認証を、以下の集約ビジネスルールで説明するアカウントに対するものとすることができる。発行者がこの認証要求を拒否する場合、アカウントをネガティブファイルに加えることができる。
【００６８】
この認証が一度得られると、カードを、適切なビジネスルールに従って交通網で用いることができる。
【００６９】
ポストファンド取引の集約に対する適切なビジネスルールは、以下の条件に適合し又は以下の条件を超えたときにクリアするために送信される集約された取引量を必要とする。
（１）１０回の乗車が行われた。
（２）最初の乗車から最大半月経過した。１ヶ月の１〜１５日において、少なくとも２週間オープンであった予め支払われた累積量を記入することができる。
（３）取引が許容された後であるが集約された量が認証前に送出される前には、カードがホットリストに挙げられる。
【００７０】
これらの条件はパラメータに基づく。パラメータを、ペイパス（登録商標）交通支払いプラットホーム５１０を通じて設定するとともに、ペイパス（登録商標）リーダ／端末にダウンロードすることができる。集約したビジネスルール条件のいずれか一つに適合した後、ペイパス（登録商標）交通支払いプラットホーム５１０は、クリア取引を形成することができる。カードの次の（予めの決済）使用に対して、ペイパス交通支払いプラットホーム５１０は、カードを未知のものとして取り扱うとともに認証要求を処理することができる。
【００７１】
ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、認証及びクリア機能を実行するためにネットワークへのアクセスを有する。交通機関がこれら取引のマーチャントであるとともに現存するマーチャント／取得者関係が既に設定されていると仮定される。ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、全ての取引の監査トレイル及び回転式改札口でプラットホームに発生するインタラクションを提供することができる。このデータは、設計されたサポートシステム及びファイルフォーマットに送出することができる。
【００７２】
ペイパス交通支払いプラットホーム５１０は、ポジティブ（エンタイトルメント）及びネガティブファイルを維持し及び管理することができる。ネガティブファイルを、ホットカード（例えば、紛失、盗難及び「発行の際に受け取られなかった」（ＮＲＩ）カード）をリストするのに用いられる。ネガティブファイルは、規則的に、好適には、４時間ごとに端末５２４にダウンロードされる。ペイパス（登録商標）交通支払いプラットホーム５１０は、カード発行者から供給されるデータ、マスターカードから供給されるデータ及び／又はペイパス（登録商標）交通支払いプラットホーム動作に基づいて毎日複数回ネガティブファイルを更新することができる（例えば、プレファンドアカウントバランスの全てを使い尽くしたカードをネガティブファイルに加えることができる。）。カードを穂一途リストから除外するよう発行銀行から要求されるとき（例えば、以前にホットリストに加えられた滞納の顧客が料金を支払うとき）、又は使い尽くされたプレファンドアカウントが充填されたとき、カードをホットリストから外すことができる。
【００７３】
ペイパス（登録商標）交通支払いプラットホーム５１０及び端末システムは、ペイパス（登録商標）装置の使用を追跡するベロシティファイルを維持することができる。このベロシティファイルを、１日に複数回交通機関に送信することができる。例えば、ＭＴＡによって設けられるとともに維持されるダイヤルアップ電話線上で端末と通信を行うためにペイパス（登録商標）交通支払いプラットホームを要求することができる。
【００７４】
図５は、交通網のカードリーダでの料金支払いに対して顧客がペイパス（登録商標）カードを提示するときにＡＦＣプロセス７００に含まれる典型的なステップを示す。ステップ７１において、カードの銀行識別番号（ＢＩＮ）を検査する。ＢＩＮが範囲内にある場合、ステップ７２において、カードがホットリストに対して検査される。ステップ７１及び７２の検査の結果が否定された場合、取引が拒否される（ステップ７３）。ステップ７１及び７２の検査の結果が肯定された場合、取引が行われ（ステップ７４）、処理のためにペイパス（登録商標）交通支払いプラットホームに送信される（ステップ７５）。
【００７５】
ステップ７６において、ペイパス（登録商標）交通支払いプラットホームは、カードに関連するプレファンドアカウントが存在するか否か決定する。プレファンドアカウントが存在する場合、ステップ７７において、ペイパス（登録商標）交通支払いプラットホームは、プレファンドアカウント動作を実行する。カードに関連するプレファンドアカウントが存在しない場合、ステップ７８において、ペイパス（登録商標）交通支払いプラットホームは、カードに関連する蓄積又は集約アカウントが存在するか否か決定する。カードに関連する蓄積アカウントが存在しない場合、ステップ７９において、ペイパス交通支払いプラットホームは、カードに関連する蓄積アカウントをセットアップする。カードに関連する蓄積アカウントが存在する場合、ステップ８０において、ペイパス（登録商標）交通支払いプラットホームは、取引を蓄積アカウントに蓄積する。最後に、ステップ８１において、ペイパス（登録商標）交通支払いプラットホームは、ビジネスルール条件がトリガされるときに集約のために記録のアカウント／クリアの準備を行う。
【００７６】
本発明によれば、上記ＡＦＣソリューションを実現するソフトウェア（すなわち、命令）を、コンピュータ読出し可能媒体に設けることができる。（本発明による既に説明した）ステップの各々及びこれらステップの組合せを、コンピュータプログラム命令を、マシンを製造するためにコンピュータ又は他のプログラマブル装置にロードすることができ、したがって、コンピュータ又は他のプログラマブル装置で実行する命令は、上記ＡＦＣソリューションの機能を実現する手段を形成する。これらプログラマブル命令を、特定の方法で機能するようにコンピュータ又は他のプログラマブル装置に命令することができるコンピュータ読出し可能メモリに記憶することもでき、したがって、コンピュータ読出し可能メモリに格納された命令は、上記ＡＦＣソリューションの機能を実現する命令手段を含む製品を製造する。コンピュータプログラム命令を、一連の動作ステップをコンピュータ又は他のプログラマブル装置上で実行してコンピュータで実現されるプロセスを生成するためにコンピュータ又は他のプログラマブル装置にロードすることもでき、したがって、コンピュータ又は他のプログラマブル装置上で実行する命令は、上記ＡＦＣソリューションの機能を実現するステップを提供する。上記ＡＦＣソリューションを実現する命令が設けられたコンピュータ読出し可能媒体は、ファームウェア、マイクロコントローラ、マイクロプロセッサ、集積回路、ＡＳＩＣＳ及び他の利用できる媒体を含むが、これらに限定されるものではない。
【００７７】
付記Ａ
ＭＴＡ料金構造
・１回の乗車−通常料金−２ドル
・１回の乗車−割引料金−１ドル
・ペイパーライドメトロカード（通常料金又は割引料金のプレファンド旅行）
・４ドルから８０ドルまでの乗車数の購入
・１０ドル以上をカードに入れ、２０％のボーナスを受け取る。
・地下鉄とバスとの間又はバス間の自動的な自由乗換
・（地下鉄から地下鉄又は出発したバスルートへの乗換なし）
・（カードが満了するまで好みに応じてしばしば再充填）
・（１度に４人まで支払いに用いることができる。）
・制限のない乗車メトロカード（所定の期間中のプレファンド無制限旅行）
・１日ファンパス
・７日
・３０日
・７日エクスプレスバスプラス
・３０日無制限乗車（ＪＫＦエアトレインのみ）
・（再充填なし−新たな期間の各々に対する新たなカードの購入）
・（同一の地下鉄の駅又は同一のバスルートで１８分間使用できない。）
（１度に一人だけ利用できる。）
【００７８】
付記Ｂ
【表２】
【００７９】
付記Ｃ
主要構成要素の機能／処理
この付記は、主要システム構成要素への処理の影響の包括的な説明のリストである。
ゲート処理
・読出しカード（ＰＡＮ＋満了日＋ＣＶＣ）
・認証カード（ローカル）
・ＰＡＮチェックサムＯＫ
・満了日を超えていないかチェック
・ローカルネガティブファイルに対するカードデータのチェック
・識別がＯＫの場合、ゲートを開く。
・フォーマット取引記録
・駅＋ゲート＋カードデータ＋取引タイプ（エントリのみ）＋データ／タイムスタンプ
ステーションコントローラ処理
・ネガティブファイル受信
・ネガティブファイル問合せに対する応答
・取引記録の格納及び送信
・ペイパス（登録商標）取引を新たな交通支払いプラットホームに送出
・現存するメトロカード取引を現在のキュービックプラットホームに送出
交通支払いプラットホーム処理
・テーブルメンテナンス
・料金
・アクティブステーション
・システム内のゲート−料金制御エリアによる
・カードタイプ
・料金プラン
・トラベルルール
・登録カード＋料金プラン
・カードアカウント／エンタイトルメント
・アカウント情報におけるカード問合せ
・更新料金プラン
・ブロックカード（例えば、紛失／盗難）
・ネガティブファイルメンテナンス
・新たなエンティティ追加
・エンティティクリーンアップ
・ネガティブファイル分配
・取引バッチの受信／認証
・バッチ認証
・取引認証
・分類（ＰＡＮ、日付／時間、ステーション／ゲート）
・取引バッチの処理（ノート１）
・旅行取引の形成及び旅費の計算
・（例外処理）
・ペイパーライド取引の処理
・制限のない乗車の取引の処理
・１回の乗車の取引の処理
・（１回を超えるクレジット／デビット旅行を集約できるか否かの問合せ）
・再供給からの再ロード処理
・（デビット／クレジット取引に対する）取得者インタフェース
・危機管理／不正検出
・決済
・ＭＴＡによる
・取得者による
・再供給による
・顧客サービス
【図面の簡単な説明】
【００８０】
【図１】図１は、本発明の原理による、交通網に対する電子的な支払いの解決の論理素子を示すブロック図である。
【図２】図２は、本発明の原理による、料金支払いに対するペイパス（登録商標）カードの使用に基づく交通機関の典型的な自動料金収集アーキテクチャを示すブロック図である。
【図３】図３は、本発明の原理による、自動料金収集の交通網インフラストラクチャに接続したスマートカード支払いプラットホームの構成要素を示す線形図である。
【図４】図４は、本発明の原理による、交通網で用いられる顧客のスマートカードを登録するプロセスに含まれる典型的なステップを示す流れ図である。
【図５】図５は、本発明の原理による、料金支払いの際に顧客が交通網のカードリーダにスマートカードを提示するときに料金取引を処理するプロセスに含まれる典型的なステップを示す流れ図である。
【技術分野】
【０００１】
関連出願のクロスリファレンス
この出願は、２００５年５月１６日に出願した仮特許出願第６０／６８１，５１３号及び２００５年９月１６日に出願した仮特許出願第６０／７１７，６２６号の利益を主張し、これらの両方を、全体を参照することによってここに組み込む。
【背景技術】
【０００２】
スマートカード技術は、我々の文化及び日々の生活において一般的になりつつある。スマートカードは、マイクロプロセッサ及びメモリチップを組み込んだ又はプログラマブル論理を有するメモリチップのみを組み込んだカードである。マイクロプロセッサカードは、カードに情報を追加し、カードの情報を削除し又はカードの情報を操作し、それに対して、メモリチップカード（例えば、プリペイドテレホンカード）は、予め規定された動作しか保証できない。スマートカードは、磁気ストライプカードとは異なり、全ての必要な機能及び情報を保持することができる。したがって、スマートカードは、取引時にリモートデータベースにアクセスする必要がない。
【０００３】
業界において「マイクロチップカード」又は「チップカード」と一般的に称されるスマートカードは、従来の磁気ストライプカードより大きな記憶容量及びデータのセキュリティを提供する。スマートカードは、８キロバイトまでのＲＡＭ、３４６キロバイトまでのＲＯＭ、２５６キロバイトまでのプログラマブルＲＯＭ及び１６ビットのマイクロプロセッサを有することができる。スマートカードは、シリアルインターフェースを有し、カードリーダのような外部ソースから給電される。プロセッサは、暗号のようなアプリケーション用の制限された命令セットを用いる。スマートカードは、多様なアプリケーション、特に、多数の操作が要求される暗号を組み込んだアプリケーションに用いられる。したがって、スマートカードは、セキュア・デジタル・アイデンティティを保持するカード用のメインプラットホームを有する。大抵の共通のスマートカードアプリケーションは、
＊クレジットカード
＊電子マネー
＊コンピュータセキュリティシステム
＊無線通信
＊（頻繁に飛行機を利用する地点のような）ロイヤリティシステム
＊銀行取引
＊衛星テレビ
＊政府認証
である。
【０００４】
配送セキュリティ、すなわち、アクセスの保証は、許可されたカードホルダによる許可された使用に対してのみ許容され、スマートカードの基本的な属性である。配送セキュリティにおけるスマートカードの有効性は、特に金融サービス及び携帯電話において広く採用され、スマートカードの成長が著しく、かつ、スマートカードが個人識別カードや、有料ＴＶ／エンターテイメントへのアクセスや、医療サービスや、取引のような他のアプリケーションに急速に拡張が予測される理由の一つである。
【０００５】
鉄道、地下鉄、バス、フェリー及び遮断ゲートを含む輸送網又は交通網は、何億もの人々によって利用される。費用効率が高く、有効かつ信頼性のある交通は、現代の大都市圏の市民が必要としている。スマートカードは、紙幣及び硬貨を交通環境から有効に取り除く。スマートカードの支払いは、高速かつ信頼性があるだけでなく、装置メンテナンスのコストを減少するのにも役に立つ。世界中の主要な交通網は、スマートカード技術に基づく新しい支払い機構に移ろうとしている。
【０００６】
複数のＲＦＩＤ技術が、非接触スマートカード及びカードリーダ／端末での使用の際に利用される。非接触システムの基本的な構成要素は、非接触リーダ（又は近接型結合装置（ＰＣＤ））及びトランスポンダである。非接触リーダは、電子回路に接続したアンテナである。トランスポンダは、誘導アンテナと、このアンテナの両端に接続した集積回路から構成される。リーダとトランスポンダとの組合せは、変成器として動作する。交流が、電磁界を生じる１次コイル（リーダのアンテナ）をながれえ、これによって、２次コイル（トランスポンダのアンテナ）に電流が誘導される。トランスポンダは、非接触リーダ（ＰＣＤ）によって伝達された電磁界（ＲＦ界）を、ダイオード整流器によって直流電圧に変換する。この直流電圧は、トランスポンダの内部回路をパワーアップする。両方のアンテナの配置及びチューニングは、一方の装置から他方の装置へのカップリング効率を決定する。トランスポンダを非接触支払いカードとすることができる。
【０００７】
経済的に実現可能であるとともに市販用とすることができる非接触支払いカードシステムに対して、カード及び端末が、特定のカードプロバイダ／発行者、ベンダー又は端末製造者に特有の技術的な特徴を有する場合でも、非接触支払いカードは、ほとんど又は全てのＲＦＩＤ使用可能な支払い端末で相互運用可能となる必要がある。業界全体で相互運用可能であることが望ましい。これに向かって、業界標準機構及びグループ（例えば、国際標準化機構（ＩＳＯ）及び国際電気標準会議（ＩＥＣ））は、非接触スマートカード支払い技術の実現のために規格化された任意の業界標準を有する。ＩＳＯ／ＩＥＣによって規定されたそのような典型的な三つの規格は、密着型カード、近接型カード及び近傍型カードにそれぞれ適用可能なＩＳＯ／ＩＥＣ１０５３６規格、ＩＳＯ／ＩＥＣ１４４４３規格及びＩＳＯ／ＩＥＣ１５６９３である。
【０００８】
最近、譲受人マスターカードインターナショナル社（「マスターカード」）は、近接型（非接触）支払いカード技術の実現のためにメーカ独自仕様のマスターカードペイパス（登録商標）ＩＳＯ／ＩＥＣ１４４４３の実現仕様（「ペイパス」（登録商標））を開発した。ペイパス（登録商標）は、ＲＦＩＤ使用可能な非接触支払いプラットホームであり、これによって、ユーザは、取引を処理するために特別なリーダの前方で装置を軽くたたき又は振ることができる。ペイパス（登録商標）の実現は、ＩＳＯ１４４４３規格に適合し、本発明の原理を表す便利な例を提供する。例えば、Smets等による米国特許出願第１１／１８２，３５４号、米国特許出願第１１／１８２，３５７号、米国特許出願第１１／１８２，３５８号、米国特許出願第１１／１８２，３５６号、米国特許出願第１１／１８２，３５５号及び米国特許出願第１１／１８２，３５１号参照。これらの全ては、参照によりここに組み込まれる。譲受人マスターカードは、クレジット支払いソリューション、デビット支払いソリューション及びプリペイド支払いソリューションを含む、マスターカードファミリーのブランドを利用するオープンな支払いソリューションを提供する国際的なリーダである。さらに、マスターカードは、特に交通の必要のために調整されたプリペイド自社ブランド支払いプログラムを可能とするために良好に配置されている。ペイパス（登録商標）の実現は、典型的には（例えば、５０米ドル未満の）小額に対して迅速なサービス及び高い処理能力を要求するマーチャントの要求に適合することを目的としている。例えば、https://sdp.mastercadintl.com/pdf/pcd_manual.pdfで２００５年１月に利用できるマスターカード支払いカード業界データセキュリティ規格及びwww.mastercadmerchant.com/acquirers/index.htmlで２００５年７月に利用できるとともに２００５年８月に改定されたマスターカードのセキュリティルール及び手順参照。この両方の刊行物は、全体を参照することによりここに組み込まれる。ペイパス（登録商標）形態の他の公知文献は、https://mbe2stl101.mastercard.net/hsm2stl101/public/login/ebusiness/mobile_commerce/paypass/documentation/index.jspで利用できる。
【０００９】
交通網環境で利用される支払いソリューションを高める考察をここで与える。望ましい支払いソリューションは、「オープン」ソリューション、すなわち、交通網に特有の非接触アクセスカード及び／又は交通網を越えて広く市販されているスマートカードを用いてユーザが交通網にアクセスすることができるソリューションである。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は、交通網の自動料金収集（ＡＦＣ）システム及び方法を提供する。
【００１１】
典型的なＡＦＣシステムは、市販のカード発行者によって発行されたＲＦＩＤ使用可能な非接触支払いカードの仕様に基づく。ＲＦＩＤ使用可能な非接触支払いカードは、非接触支払いカードのオープンな業界標準（例えば、ＩＳＯ１４４４３規格）に従う。ＡＦＣシステムは、交通網の有料エリアへの入口に配置されたＲＦＩＤ使用可能なカードリーダと、交通支払いプラットホームとを有する。ＲＦＩＤ使用可能なカードリーダを、端末又はステーションコントローラに結合することができる。ＡＦＣシステムは、取引支払い認証プロセス、クリアプロセス及び決済プロセスをカード支払い産業に共通の電子ネットワーク上で行うよう設計された交通支払いプラットホーム又はアプリケーションも有する。
【００１２】
交通網のゲートの有料エリアへのアクセスを所望する顧客は、料金を支払うために、ＲＦＩＤ使用可能なカードリーダによって読み出される非接触支払いカード（例えば、マスターカードのペイパス（登録商標）カード）を提示する。カードリーダ／端末コントローラは、ホットカード（すなわち、紛失、盗難、満了又は滞納と報告されたカード）のリストに対して、読み出した非接触支払いカードデータを評価し、それに応じて、交通網のゲートの有料エリアへの顧客のアクセスを許可し又は拒否する。カード取引記録は、支払い認証、クリア及び決済のために交通支払いプラットホームと通信を行うよう準備される。１回の乗車の料金に対して、取引の支払いは、カード発行者により顧客のカードアカウント（例えば、クレジット又はデビットアカウント）にチャージされる。
【００１３】
交通支払いプラットホームを、非接触支払いカードにリンクしたプレファンド交通アカウントを顧客が登録し又はセットアップするように形成することもできる。プレファンドアカウントは、通貨バランス（例えば、ドルの総額）、乗車決済バランス（例えば、乗車回数）又はタイムバランスを有することができ、これらは、例えば、ペーパーライドチケットの料金、最大乗車数ごとのチケットの料金及び制限のない乗車チケットの料金に対応する。そのような非接触支払いカードによる料金取引に対して、交通支払いプラットホームは、取引を行う顧客の非接触支払いカードに関連したプレファンド交通アカウントに対する取引の支払いを決済する。
【００１４】
本発明の他の態様、性質及び種々の利点を、添付図面及び以下の詳細な説明から明らかにする。
【発明を実施するための最良の形態】
【００１５】
本発明は、交通網の自動料金収集（ＡＦＣ）ソリューションを提供する。スマートカードの使用に基づくこのようなＡＦＣソリューションは、交通網で実現される自動料金収集システム及び手順を提供する。自動料金収集システム及び手順は、例えば、通貨取り扱い手数料、自動券売機及び回転式改札口の維持費、料金媒体調達価格（例えば、プラスチック／紙の料金前払いカード）並びに営業中のスタッフを配備したチケットブースの数を減少することによって、操業コストを大幅に減少することができる。ＡＦＣソリューションは、非接触支払い装置の共通の又はオープンな業界標準（例えば、ＩＳＯ１４４４３規格）に適合するスマートカード（例えば、マスターカードのペイパス（登録商標））に基づく。
【００１６】
図１は、交通網の典型的な電子支払いソリューション１００の論理的及び構成的な要素を示すブロック図である。典型的な電子支払いソリューション１００は、マスターカードのペイパス（登録商標）の実現に基づく。ソリューション１００において、カードホルダを、発行者１２０によって発行されたペイパス（登録商標）カード１１０とする。顧客は、例えば、交通網の門のある有料エリアへの入場するために回転式改札口（例えば、地下鉄の回転式改札口又はゲート）で料金を支払うようペイパス（登録商標）カードを提示することができる。回転式改札口１３２には、自動料金収集（ＡＦＣ）の際に顧客によって提示されたペイパス（登録商標）カードを電子的に読み出すためにＲＦＩＤイネーブルカードリーダ１３０が設けられる。カードリーダ１３０は、オプションの端末コントローラ１５０及びペイパス（登録商標）交通支払いプラットホーム１６０を通じて交通網の支払いホスト１４０に電子的にリンクされる。顧客の料金支払いを、例えば、小売業界においてペイパス（登録商標）クレジット又はデビットカードの支払取引を処理するのに用いられる現行のカードによる支払い形態と同様に電子的に処理することができる。このために、交通機関支払いホスト１７０は、従来のカードによる支払いの電子的なネットワーク１９０を通じてカード発行者１２０及び他の団体又は機関にリンクされている。取引支払い処理ステップ（例えば、取引／支払い認証要求ステップ、承認ステップ及び決済ステップ）は、ネットワーク１９０によってリンクされた取得者１７０やペイパス（登録商標）カード団体１８０（例えば、マスターカード）のような従来の電子的な支払いのインフラストラクチャエンティティを伴う。
【００１７】
支払いソリューション１００の実現に際し、顧客は、顧客のペイパス（登録商標）カードにリンクされる予め供給される交通料を設定し及び登録することができる。実際には、顧客は、交通網の門のある有料エリアにアクセスするために、交通の回転式改札口１３２に装着されたカードリーダ１３０に顧客のペイパス（登録商標）カード１１０を提示し又は「タップ」することができる。カードにエンコードされたデータが読み出され、端末コントローラ１５０に送信される。端末コントローラ１５０は、カードを許可し又は拒絶することによって応答する。それに応じて、顧客は、回転式改札口へのアクセスが与えられ又は否定される。端末コントローラ１５０のソフトウエアは、取引データ記録をペイパス（登録商標）交通支払いプラットホーム１６０に送信する。ペイパス（登録商標）交通支払いプラットホーム１６０は、カード端末ソフトウエアの継続的なメンテナンスとともに、取引に必要な認証及びバッチ合意処理機能を提供する。
【００１８】
説明のためのペイパス（登録商標）の実現の選択は例示に過ぎず、本発明の原理を、他の共通の又は専用の規格の下で動作する電子的な支払い装置又はシステムに更に一般的に適用することができる。他の電子的な支払い装置及びシステムは、アメリカンエキスプレスのエキスプレスペイやビザウェーブのような非接触カードに基づくことができる。ペイパス（登録商標）の実現により、交通環境にオープンな支払いをもたらすとともに、配置しようと計画されている交通機関又は既に配置された交通機関に対する新たなオプションを、スマートカードに基づく支払いソリューションに提供する。ペイパス（登録商標）の実現を、交通機関及びその顧客に有用となるようオープンな支払いソリューションを利用するために好適に調整することができる。
【００１９】
さらに、本発明による支払いソリューションのアプリケーションを、ニューヨーク市の大都市交通局（ＭＴＡ）によって操作される典型的な地下鉄交通網ＮＹシティー交通（ＮＹ交通）を参照してここで説明する。ＭＴＡ／ＮＹ交通の選択は説明のみのためであり、本発明による電子支払いソリューションを、他のあらゆる交通網（例えば、スターテン島鉄道、ロングアイランド鉄道、ロングアイランドバス、メトロノース鉄道、並びに橋及びトンネル）に利用することができる。
【００２０】
電子支払いソリューション１００を、複数の交通網（例えば、地下鉄、バス、鉄道等）間で統合されたＡＦＣアプリケーションに対して設計することができ、ＡＦＣに対してＭＴＡの橋及びトンネル操作の際に配置されるＥ−ＺＰａｓｓソリューションのような他の電子支払いソリューションに統合することもできる。
【００２１】
図１を更に参照すると、ソリューション１００は、あらゆる適切な数の種々のカードタイプ及びカード分配モデルとともに操作可能である。これらの種々のカードタイプの交通機能は、交通支払いプラットホーム１４０の適切な設計によってイネーブルされる。
【００２２】
適切な数のカードタイプ及びカード分配モデルを、交通網の利用者数の割合を経済的に広げるようスマートカードの使用を拡張する観点から選択することができる。選択されたカードタイプは、例えば、１回の乗車をサポートするカード、操作の時間に基づく（制限のない乗車）モード、及び／又は、操作の乗車ごとの支払いモードをサポートする値に基づくカードを含む。あり得るカード分配モデルの例は、次のものを含む。
【００２３】
（１）銀行が発行したカード（例えば、マスターカードのペイパス（登録商標））
銀行は、マーチャントのカードホルダによる一般的な使用のためにペイパス（登録商標）がイネーブルされた標準的なクレジットカード又はデビットカードを発行することができる。これらペイパス（登録商標）カードを、ＭＴＡシステム内での旅行に用いることもでき、これらペイパス（登録商標）カードは、ある地域への頻繁でない旅行者及び訪問者に加えて規則的な通勤者の必要に応じることができる。カードを、（Ｅ−ＺＰａｓｓと同様に）ＭＴＡ環境内でのみ費やされる乗車ごとに支払われる予め設定された交通料を設定するために交通網によって登録することができる。登録されたペイパス（登録商標）カードは、値に基づく（乗車ごとの支払い）又は時間に基づく（制限のない乗車）製品に対して規則的なメトロカードの機能を実行することができる。登録されていないペイパス（登録商標）カードを、各月の少数の乗車に対してゲートで支払いを行うためにＭＴＡ内で用いることができる。
【００２４】
（２）ＭＴＡ／銀行提携カード（例えば、ＭＴＡ／マスターカードペイパス（登録商標）提携メトロカード）
提携カードを、「通勤」カード、「都市」カード又は「旅行」カードとして銀行により市販し及び発行することができる。ＭＴＡシステム内で、提携カードは、値に基づく（乗車ごとの支払い）又は時間に基づく（制限のない乗車）製品に対して、磁気ストライプ機能に基づく規則的なメトロカードチケットの機能と同様な機能を有する。カードは、ＭＴＡ環境外では通常の銀行支払いカードとして機能する。全てのカードホルダは、記録時のカードホルダ選択により値に基づいて（乗車ごとの支払い）又は時間に基づいて（制限のない乗車）、旅行のために交通網によって自動的に登録される。
【００２５】
（３）ペイパス（登録商標）を備えたＭＴＡ自社ブランドカード
ＭＴＡ自社ブランドカードは、システムの規則的な使用者であるが旅券に銀行支払いカードを組み合わせることを所望しない利用者をターゲットとすることができる。ＭＴＡ及びその代理店は、発行パートナーを通じて自社ブランドカードを分布することができる。このカード製品は、値に基づく（乗車ごとの支払い）又は時間に基づく（制限のない乗車）製品に対して規則的なメトロカードの機能と同様な機能を有する。
【００２６】
ＭＴＡ自社ブランドカードは、ＭＴＡ環境内でのみ用いることができる実際のプリペイドカードである。ＭＴＡ自社ブランドカードは、預金した顧客及び／又は旅行のために個別の支払いカードを所望する顧客に対して適切である。顧客は、カードを得るために料金を支払い及び／又は預金を行うことができる。全てのカードホルダは、記録時のカードホルダ選択により値に基づいて（乗車ごとの支払い）又は時間に基づいて（制限のない乗車）、旅行のために交通網によって自動的に登録される。
【００２７】
実際には、マスターカード及びその加盟銀行は、米国中で取引を迅速に行うためにＲＦＩＤイネーブルされたペイパス（登録商標）の概念を促進する。配置がニューヨーク市以外の地域で行われるので、ある区域から他の区域で利用できる交通機能をリンクアップし始めることができる。先ず、これを、地域に基づいて行うことができるが、全国的に拡大することができる。したがって、米国の他の地域からの訪問者は、現存するペイパス（登録商標）カードを用いてＭＴＡシステムに入ることができる。これによって、ＭＴＡのコストが減少するとともに、利用者のシステム全体に亘る有用性が向上する。ペイパス（登録商標）のソリューションをＭＴＡに採用することによって、利用者は、マスターカードのペイパス（登録商標）カードを用いてアルバニーからニューヨーク市に旅行することができる。
【００２８】
マスターカードのペイパス（登録商標）に基づくソリューション１００の典型的な実現を、交通網によって用いられる既に存在する料金体系及びカード又はチケットタイプに一致し又は適合することができる。付記Ａは、ＭＴＡ／ＮＹ交通の料金体系を示す。さらに、付記Ｂは、これまで説明した三つのカードタイプの各々によってサポートされる交通料体系の比較を表で示す。
【００２９】
ソリューション１００を、任意の数のＡＦＣアーキテクチャ又は形態をサポートするように構成することができる。典型的なＡＦＣアーキテクチャ−「ホストプラス分散型ネガティブファイル」は、標準的なペイパス（登録商標）支払いカードの使用に基づく。このアーキテクチャにおいて、特定の交通アプリケーションを支払いカードにロードする必要がない。顧客は、料金収集のために回転式改札口１３０／リーダ１３２に標準的なペイパス（登録商標）カード１１０を提示する。回転式改札口１３０は、カードデータ（例えば、個人口座番号、有効期限及び認証コード）を確認し、カードがネガティブファイル又はほっとリストにリストされているか否か検査する。カードがネガティブファイルにリストされている場合、回転式改札口１３０／端末１５０は、交通網のゲートの有料エリアへの顧客のアクセスを拒否する。それに対して、カードがネガティブファイルにリストされていない場合、回転式改札口１３０／端末１５０は、ゲートを動かし、顧客が交通網の有料エリアにアクセスするのを許容する。回転式改札口１３０／端末１５０は、カードの使用に関連した生の取引データ記録を、１回の乗車、乗車ごとの支払い及び制限のない乗車の取引を処理するよう形成された交通支払いプラットホーム１６０に同時に又は後に送信する。交通支払いプラットホーム１６０は、生の取引を交通網（例えば、ＭＴＡ）から受け取り、生の取引を、登録された顧客アカウントに対して処理する。適切な場合には、交通支払いプラットホームホスト１４０は、１回の乗車取引データを、更なる処理のために取得者１７０に送信することができる。交通支払いプラットホームホスト１４０は、例えば端末コントローラ１５０を通じて回転式改札口１３０に分配されるネガティブファイルを発生し及び維持する。
【００３０】
他の典型的なＡＦＣアーキテクチャ−「ホストプラス分散型ネガティブファイル」は、標準的なペイパス（登録商標）支払いカードの使用に基づく。このアーキテクチャにおいて、交通支払いプラットホームホスト１４０は、エンタイトルメントのポジティブファイルを交通網の回転式改札口１３０に分配する。エンタイトルメントを、有効な制限のない乗車カードとポジティブプリファンドバランスを有する有効値に基づくカードとのリストとして表すことができる。顧客が料金収集のために標準的なペイパス（登録商標）カード１１０を回転式改札口１３０／リーダ１３２に提示すると、回転式改札口１３０は、カードデータを確認し、カードがエンタイトルメントリストにリストされているか否か検査する。カードがエンタイトルメントファイルにリストされている場合、回転式改札口１３０は、ゲートを動かし、顧客が交通網の有料エリアにアクセスするのを許容する。それに対して、カードがエンタイトルメントファイルにリストされていない場合、回転式改札口１３０は、交通網のゲートの有料エリアへの顧客のアクセスを拒否する。回転式改札口１３０は、カードに関連した生の取引データ記録を交通支払いプラットホームホスト１４０に同時に又は後に送信することができる。交通支払いプラットホームホスト１４０は、取引を処理し、分配を回転式改札口１３０に戻すためにエンタイトルメントファイル及びバランスを更新する。
【００３１】
ホストプラス分散型エンタイトルメントアーキテクチャは、ホストプラスネガティブファイルアーキテクチャとともに未払い乗車の発生を大幅に減少することができる。しかしながら、ホストプラス分散型エンタイトルメントアーキテクチャで用いられるエンタイトルメントファイルが大きくなることがある。大きなエンタイトルメントファイルは、ホストプラスネガティブファイルアーキテクチャで用いられる小さなネガティブファイルに必要なメモリに対して、回転式改札口１３０／端末コントローラ１５０に追加のメモリを設ける必要がある。
【００３２】
ホストプラスネガティブファイルアーキテクチャのように、ホストプラス分散型エンタイトルメントアーキテクチャは、標準的なペイパス（登録商標）カードを用いる。特定の交通アプリケーションをカードにロードする必要がない。
【００３３】
更に別の典型的なアーキテクチャ−「ホストプラススマート発見アプリケーションオンペイパス（登録商標）カード」は、特定の交通アプリケーションによって機能強化された標準的なペイパス（登録商標）カードを用いる。特定の交通アプリケーションは、リアルタイムの乗車及びシャドープレファンドバランスを記録する。カードのプレファンドバランス／エンタイトルメントを、例えば、ＭＴＡペイパス（登録商標）が使用可能な自動販売機において顧客によって更新することができる。このアーキテクチャにおいて、回転式改札口１３０／リーダ１３２は、カードに記憶された乗車記録を読出し及び更新するように構成される。顧客が料金収集のために標準的なペイパス（登録商標）カード１１０を回転式改札口１３０／リーダ１３２に提示すると、回転式改札口１３０は、カードデータを確認し、カードがネガティブファイル又はエンタイトルメントファイルにリストされているか否か検査する。さらに、自動的な料金収集取引処理を、これまで説明した二つのＡＦＣアーキテクチャの処理と同様に行うことができる。
【００３４】
図２は、公共交通網におけるホストプラス分散型ネガティブファイルＡＦＣアーキテクチャの典型的な実現であるＡＦＣソリューション２００を示す。このソリューションの構成要素は、ペイパス発行者２９０のようなエンティティと、標準的なペイパス（登録商標）カード／装置２１０、ゲートリーダ２２０、券売機２３０、バス料金箱２４０、ステーションコントローラ２５０、交通網ホスト２６０、交通支払いプラットホーム２７０、ペイパス（登録商標）カード発行者２９０、再供給ホスト２８０、電子支払いネットワーク（マスターカードネットワーク２９２）等のソフトウェアコンポーネント及びハードウェアコンポーネントとを有する。
【００３５】
ＡＦＣソリューション２００において、ペイパス（登録商標）カード／装置２１０を、マスターカードペイパス（登録商標）アプリケーションを含むＩＳＯ１４４４３スマートカード又は他の装置（例えば、キーフォブ）とすることができる。ゲートリーダ２２０を、ＩＳＯ１４４４３カードリーダ及びペイパス（登録商標）端末アプリケーションによって増強された通常の回転式改札口又はゲートとすることができる。同様に、バス料金箱２４０を、ＩＳＯ１４４４３カードリーダ及びペイパス（登録商標）端末アプリケーションによって増強された通常のバス料金箱とすることができる。券売機２３０を、地下鉄の駅においてＭＴＡによって現在は位置されている券売機と同様な通常の券売機とすることができる。ステーションコントローラ２５０を、ペイパス（登録商標）取引を処理するとともにネガティブファイルを取り扱うように変更された通常のステーションコントローラとすることができる。交通網ホスト２６０を、ＭＴＡによって用いられる現存する交通網ホストとすることができる。交通料支払い取引を、ホスト２６０及び取引支払いプラットホーム２７０を通じて、米国及び世界のマスターカードの取引を処理し及び送出するように配置されたマスターカードネットワーク２９２に送出することができる。交通料支払い取引を、個別のゲートウェイホスト（例えば、ネットワークゲートウェイ２９６）を通じてマスターカードネットワーク２９２に送出することもできる。交通料支払い取引の送出の代わりとしてネットワークゲートウェイ２９６を用いることによって、ＭＴＡによって用いられる現存するシステムホストの処理ロード又は影響を最小にすることができる。
【００３６】
マスターカードネットワーク２９２は、交通支払いプラットホーム２７０、オプションの再供給ホスト２８０、ペイパス（登録商標）発行者２９０及びペイパス（登録商標）マーチャントＰｏＳ２９４にリンクする。ペイパス（登録商標）発行者２９０を、ペイパス（登録商標）クレジットカード又はデビットカードの通常の発行者（例えば、マスターカード加盟銀行）とすることができる。図２において、ペイパス（登録商標）マーチャントＰｏＳ２９４は、マスターカードペイパス（登録商標）クレジットカード及びデビットカードのマーチャント承認（例えば、小売店−顧客販売）のためのＭＴＡの外側のセールインフラストラクチャのポイントを表す。
【００３７】
交通支払いプラットホーム２７０を、ＭＴＡ／ＮＹ交通網及び他の交通網（例えば、交通網２９８）の１回の乗車、乗車ごとの支払い及び制限のない乗車の取引を管理するのに適切に構成されたホストシステムとすることができる。交通支払いプラットホーム２７０は、ＭＴＡ交通網ホスト２６０又は他のネットワークゲートウェイ２９６から生の取引を受け取り、登録されたカードホルダアカウントに対する生の取引を処理する。交通支払いプラットホーム２７０は、適切な場合には、１回の乗車の取引を第三者（例えば、取得者）に送り出すことができる。さらに、交通支払いプラットホーム２７０は、ステーションコントローラ２５０に分配するためにＭＴＡ交通網ホスト２６０に戻されるネガティブファイルを発生し又は維持する。
【００３８】
オプションの再供給ホスト２８０を、値及び時間に基づく（プレファンド）カードアカウントを自動的に又は要求に応じて再ロードするように構成されたホストシステムとすることができる。再供給は、値をプレファンドアカウントにロードするマスターカードのブランドのついた設備である。再供給ホストは、例えば、インターネット、テキストメッセージ又は電話を通じて再ロード要求を簡単にする適切なインタフェースを有することができる。再供給ホスト２８０は、更新された再ロード情報を、リンクされた交通支払いプラットホーム２７０に供給する。
【００３９】
顧客が料金支払いのためにペイパス（登録商標）カード／装置２１０を提示すると、ソリューション２００は、料金のタイプ（例えば、１回の乗車、値に基づく乗車ごとの支払い、又は時間に基づく支払い）に従ってＡＦＣに対する典型的なペイパス（登録商標）交通カード処理手順３００を用いることができる。ゲートリーダ２２０及び／又は交通支払いプラットホーム２７０で行われる典型的な処理ステップ及び結果を、表１にリストする。
【００４０】
【表１−１】
【表１−２】
【００４１】
表１に示すように、ペイパス（登録商標）交通カード処理手順３００は、２段階におけるペイパス（登録商標）カードの使用のチェックを有する。先ず、提示されたカードが、ゲート２２０でネガティブファイルに対してチェックされる（ステップ３１２）。次に、３２０において、提示されたカードが、交通支払いプラットホームでチェックされる（支払い認証ステップ３２２ａ，３２３ａ及び乗車エンタイトルメントチェックステップ３２４ａ）いずれかのチェックで否定されると、カードはネガティブファイルに加えられる。
【００４２】
交通支払いプラットホームチェックを、非同期的に（すなわち、カード提示後に）行うことができる。したがって、カードが第１の「ゲート」チェックをクリアしたカードホルダは、後の交通支払いプラットホームチェックが否定されたとしても交通網のゲートの有料エリアにアクセスすることができる。
【００４３】
提示されたカードがネガティブファイルに存在しないことの確認に加えて、ゲート２２０で実行されるゲートチェック（ステップ３１２）は、カードデータのフォーマットが正確であること及びカードが満了していないことの確認を含むことができる。ゲートチェックは、他の認証、例えば、速度プロファイリング（すなわち、提示されたカードが同日に同一の交通ステーションで固定回数を超えて用いられなかったことの認証）を含むこともできる。
【００４４】
同様に、交通支払いプラットホームチェックは、提示されたカードが満了せず、かつ、紛失又は盗難として報告されていないカードのリストにないことの認証を含むことができる。交通サービス業者に紛失又は盗難として報告されたＭＴＡ自社ブランドカードに対して、サービス業者は、紛失又は盗難として報告されたカードの交通支払いプラットホームリストを更新することができる。マスターカードブランドのカードに対して、交通支払いプラットホーム２７０は、マスターカードの広域紛失／盗難カードファイルにアクセスするとともに、提示されたカードが紛失又は盗難として報告されていないことを確認するために当該ファイルを用いることができる。
【００４５】
交通支払いプラットホーム２７０を、料金プランのルール（例えば、経路／路線間の乗換に関するルール）を実現するために取引データ記録の更なるチェックを行うように構成することができる。そのようなルールを実現するのに適切な場合には、交通支払いプラットホーム２７０は、追加の支払い取引を発生することができる。料金ルールを実現するよう設定されたチェックは、料金取引のタイプに依存する。例えば、１回の乗車の取引に対して、追加のチェックは、１ヶ月の最大乗車数（例えば、１０）を超えなかったこと及び支払いがカード発行者によって承認されたことの認証を含むことができる。乗車ごとの支払いの取引に対して、追加のチェックは、カードホルダのプレファンド交通アカウントバランスが運賃を支払うのに十分であることの認証を有することができる。制限のない乗車取引に対して、追加のチェックは、カードホルダの制限のない旅行期間を満了していないこと及び制限された期間（例えば、磁気ストライプ技術を用いるＭＴＡメトロカードに対して現在のところ１８分）内にカードが同一ステーションで複数回提示されなかったことの認証を含むことができる。
【００４６】
ＡＦＣソリューション２００は、カードホルダが不適切にシステムにアクセスするのを防止するためにカードのホットリスト（すなわち、ネガティブリスト）に頼る。カードがネガティブファイルに含まれる場合、交通網の有料エリアのゲートは開かない。実際には、不適切なアクセスを防止するこの方法の有効性は、ネガティブファイルが更新されるとともに交通網全体に亘って分配される頻度に依存する。更新されたネガティブファイルを、通常は毎日分配することができる。しかしながら、更に頻繁に更新／分配を行うことによって、未払い乗車の発生が減少する。
【００４７】
ＡＦＣソリューション２００を、適切なときにはカードリストをネガティブファイルから除去又は削除するよう構成することもできる。例えば、ペイパーライドカードがロードされ又は制限のない乗車カードが更新されたとき、ネガティブファイルのあらゆる対応するエントリが除去される。更新されたネガティブファイルは、ネガティブファイルの次の分配後にのみ効力を生じることができる。毎日の分配スケジュールの場合、これは、ペイパーライド／制限のない乗車カードが次の日からのみ旅行に有効であることを意味する。ネガティブファイルの更に頻繁な更新及び分配を所望することができる。
【００４８】
図２は、値をプレファンド交通アカウントにロードするマスターカードブランドの設備である再供給ホスト２８０を示す。カードホルダは、インターネットを通じてフォームを満たすことにより又は交通アカウントセットアップ手順の一部として再供給を登録することができる。登録に従って、カードホルダは、インターネット、電話、携帯電話テキストメッセージ、ｅメール又はＩＶＲＵを通じてプリファンド交通アカウントをトップアップすることができる。再供給設備を、ＡＴＭ，ＰｏＳ装置、マシンに拡張することもでき、可能な場合には、現存する発券業者に拡張することができる。
【００４９】
ソリューション２００を、アカウントバランスが所定レベルより下になるときに関連のデビットカード又はクレジットカードからプレファンド交通アカウントに値を再充填する自動トップアップオプションをカードホルダに設けるように構成することができる。値を充填する取引において、再供給ホスト２８０は、先ず、未払いの乗車に対する運賃を引き出すことができ、又は交通料に対する指定されたロード量に返金を追加することができる。さらに、再ロードされたカードに関連したネガティブファイルのエントリが削除される。
【００５０】
同様に、制限のない乗車券が購入され又は更新されると、あらゆる未払いの料金が購買量に加えられる。さらに、更新された制限のない乗車券に関連するネガティブファイルエントリが削除される。
【００５１】
ＡＦＣソリューション２００は、交通網動作の他の従来の態様に影響を及ぼすことがある。しかしながら、ＡＦＣソリューション２００を、影響が及ぼされる態様を向上し又はかかる態様に適合するために変更することができる。例えば、ＡＦＣソリューション２００の下では、交通網の乗客は、電車内の車掌によって点検することができる従来のペーパーチケットを有しない。車内での点検が所望される場合には、ソリューション２００は、車内の車掌又は検札係に携帯用ペイパス（登録商標）カードリーダを設けることができる。携帯用ペイパス（登録商標）カードリーダを、乗客によって提示されるペイパス（登録商標）カードを点検するために用いることができる。携帯用ペイパス（登録商標）カードリーダに、乗客の料金エンタイトルメント又は支払いを例えば交通網ホストによって確認できるように移動通信機能を設けることができる。
【００５２】
ＡＦＣソリューションは、２タイプの取引及び支払いの決済を伴うことができる。第１のタイプの決済は、ペイパス（登録商標）発行者２９０によって認証された１回の乗車の取引に関連する。これらの取引の決済を、第三者（例えば、図１の取得者）を通じて交通支払いプラットホーム及びＭＴＡに送り出すことができる。１回の乗車の取引の決済は、取引の集約又は予め認証された量の使用を伴うことができる。乗客又は口座名義人によって複数の１回の乗車の取引を集約する取引の集約は、有効な決済を行うことができる。
【００５３】
第２のタイプの決済は、ペイパーライド又は制限のない乗車のペイパス（登録商標）カードを用いて行われる乗客の取引に関連する。このタイプの決済は、交通支払いプラットホーム２７０とＭＴＡとの間で直接的に行うことができる。このために、適切な業務用の装置を、交通支払いプラットホーム２７０のオペレータとＭＴＡとの間にセットすることができる。
【００５４】
これまでの説明は、本発明の原理を説明するためだけのものであり、種々の変更を、本発明の範囲を逸脱することなく当業者によって行うことができる。例えば、ＭＴＡ／ＮＹ交通の地下鉄のＡＦＣソリューション２００を、ＭＴＡバス又は他の輸送モードに容易に拡張することができる。そのような拡張において、バス若しくは他の車両又はアクセスポイントに、現存する料金箱／検札器２４０に取り付けられたスマートカードリーダを設けることができる。取引は装置内に格納し、バスがベースに戻るときにホストシステムにダウンロードされる。さらに、例えば、ＡＦＣソリューションの原理を、簡潔のためにここでは更に詳しく説明しないホストプラススマート発券アプリケーションオンペイパス（登録商標）カードアーキテクチャ及びホストプラス分散型エンタイトルメントアーキテクチャの実現に容易に拡張することができる。
【００５５】
図３は、ＭＴＡ／ＮＹ交通のＡＦＣソリューションに基づくペイパス（登録商標）のデモンストレーションに関連したペイパス（登録商標）交通支払いプラットホーム５１０及び地下鉄回転式改札口インフラストラクチャ５２０の所望される又は必要な機能を示す。同様に、付記Ｃは、主要な構成要素の各々の機能及び処理ステップをリストする。
【００５６】
地下鉄回転式改札口インフラストラクチャ５２０：全てのペイパス（登録商標）リーダ５２２及び端末５２４のハードウェア及びソフトウェアは、好適には、発行されたマスターカードのペイパス（登録商標）に従う。ペイパス（登録商標）リーダ５２２及び端末５２４は、好適には、許可されていない情報へのアクセスを防止するために情報を格納し及び（例えば、暗号形態で）安全に情報を送信する。ペイパス（登録商標）リーダ５２２及び端末５２４は、好適には、通信エラー時の情報値を記憶し又は記録することができる。これらの記録（例えば、エラーログ及び取引ログ）が一度充満されると、記録された情報が端末５２４からアップロードされるまでデータを上書きすることができない。ペイパス（登録商標）交通支払いプラットホーム５１０と通信を行うとき、ペイパス（登録商標）リーダ５２２及び端末５２４は、好適には、（例えば、装置が正確に機能する）装置状態情報を提供する。
【００５７】
ペイパス（登録商標）交通支払いプラットホーム５１０：ペイパス（登録商標）交通支払いプラットホーム５１０は、回転式改札口のアクセスに対するペイパス（登録商標）取引のみを処理する。現存する全ての回転式改札口へのアクセスのレガシー機能は、現存する交通機関のインフラストラクチャ（例えば、ステーションコントローラ５０４、発券機５０６）を利用し続けることができる。
【００５８】
ペイパス（登録商標）交通支払いプラットホーム５１０は、ペイパス（登録商標）取引に関連した動作を管理するアプリケーションを有する。これらアプリケーションは、顧客アカウント管理アプリケーション６０２及び６０４と、アカウントメンテナンスアプリケーション５１２と、支払い処理アプリケーション５１６と、ファイル管理アプリケーション５１６と、ネットワーク管理アプリケーション５１８とを有する。ペイパス（登録商標）支払いプラットホーム５１０は、ペイパス（登録商標）取引の処理をサポートする際にＭＴＡシステムとやり取りを行うことができる。ペイパス（登録商標）交通支払いプラットホーム５１０は、毎日の動作（例えば、得られた認証、金の調達のために設定された取引、回転式改札口の動作等）をＭＴＡに報告する適切な管理報告機能を有することができる。
【００５９】
ペイパス（登録商標）交通支払いプラットホーム５１０は、プレファンド顧客アカウント及びポストファンド顧客アカウントをそれぞれ管理する顧客アカウント管理アプリケーション６０２及び６０４を有する。２タイプのアカウントの取引は、異なる支払い処理フロー（すなわち、取引認証フロー及びクリーニングフロー）を有する。
【００６０】
ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、ペイパス（登録商標）カード番号を回転式改札口入場用のプレファンドアカウントにリンクする機能（予備登録）を有する。ファンディングオプションは、自動ローディング、カードホルダが要求したウェブサイトの再ロード、ＳＭＳ等を有することができる。さらに、ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、プレファンドアカウントを確立し及び維持するためのカードホルダに対する機構を有する。ペイパス（登録商標）交通支払いプラットホーム５１０は、集約したポストファンド取引及び／又はプレファンド取引に関する乗車履歴並びにプレファンドアカウント「トップアップ」動作に関連した取引履歴をカードホルダが取得できるウェブに基づく顧客インタフェースを提供することができる。ウェブに基づく顧客インタフェースは、プレファンドアカウントに対する登録及び未登録をカードホルダに許容することもできる。
【００６１】
図４は、発行銀行によりペイパス（登録商標）カードが郵送された顧客が交通網で使用するためにペイパス（登録商標）カードを予め登録するとともにカードをプレファンド交通アカウントにリンクすることができるプロセッサ４００を示す。プロセス４００のステップ４１において、銀行は、ペイパス（登録商標）カードをカードホルダに郵送する。ステップ４２において、カードホルダは、交通網にカードを登録するよう選択を行う。カードホルダがカードの登録を選択しない場合、カードホルダは、交通網で予め支払われた料金の取引に対してカードを用いることができる。カードホルダがカードを登録することを選択する場合、ペイパス（登録商標）交通支払いプラットホーム５１０は、ステップ４３において、カードに関連したプレファンドアカウントを自動クレジットサービス（ＡＣＳ）でセットアップする。カードホルダは、ステップ４４において、プレファンドアカウントに対して自動再ロード形態を起動することを更に選択することができる。カードホルダが、自動再ロードを行うことを選択しない場合、プレファンドアカウントは、１回の値を割り当てる（ステップ４６）。それに対して、カードホルダが自動再ロード形態を起動することを選択する場合、ステップ４５において、アカウントロードリミットが、自動的な再ロードに対して設定される。ステップ４５は、カードホルダの制限を検査するために従来のアドレス検証サービス（ＡＶＳ）を利用することができる。３回の連続的な登録の試みに対してＡＶＳ検査が否定された場合、発行銀行に通知を行うことができる。しかしながら、否定されたカードを自動的にホットリストに挙げないようにすることができる。発行銀行は、必要な情報を有し、カードをホットリストに挙げ又はＡＶＳ検査パラメータをリセットすることができる。
【００６２】
カードを予め登録すると、ペイパス（登録商標）交通支払いプラットホーム５１０は、交通機関が規定した料金オプション（例えば、一括購入の値引き、５個買うごとに１個がただになる、等々）の選択をカードホルダに許容する交通機関の料金ルール（例えば、付記Ａ参照）へのアクセスを有することができる。
【００６３】
ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、プレファンドアカウントの「トップアップ」動作に関連した認証及びクリア機能を実行することができる。交通機関を、これらの取引のマーチャントとすることができ、既に設定されている現存するマーチャント／取得者関係を利用することができる。ペイパス（登録商標）交通支払いプラットホーム５１０は、全てのプレファンドアカウントのバランスを維持し及び管理することができる。予め登録されたカードアカウントバランスが使い尽くされて再ロードされない場合、カードはネガティブファイルに加えられる。もはやプレファンド機能を用いることを所望せずにポストファンド機能を用いることを所望することを決定するカードホルダに対して、キャンセル機能を設けることができる。自動ロード機能が予め設定されている場合、カードホルダに対して、自動ロード機能のみ又は自動ロード機能とプレファンドアカウントそれ自体の両方の選択を与えることができる。プレファンドアカウントは、１８分間に６回までの乗車に対して「パスバック」を許容する。一旦、プレファンドペイパス（登録商標）装置が損失したことを報告されると、カードホルダは、新たなペイパス（登録商標）アカウントに転送された残りの値を取得することができる。
【００６４】
ポストファンドアカウントに対して、ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、予め規定されたビジネスルールのセットに基づいて後にクリアし及び認証するために支払いカード取引を集約することができる。実証プロジェクトに対して、マスターカード、交通機関及びカード発行者は、共同でルールを規定することができる。ポストファンドアカウントは、１８分間に６回までの乗車に対して「パスバック」を許容する。
【００６５】
ポストファンド取引の認証手順を、以下のようにすることができる。
【００６６】
あらゆる取引の開始時に、ペイパス（登録商標）交通支払いプラットホーム５１０は、回転式改札口で用いられるカードが既に設定されたプレファンドアカウントを有するか否か検査し、プレファンドアカウントが見つからない場合、取引はポストファンドであると考えることができる。
【００６７】
最初のポストファンド取引に対して、ペイパス（登録商標）交通支払いプラットホーム５１０は、認証を行うことができる。この認証を、以下の集約ビジネスルールで説明するアカウントに対するものとすることができる。発行者がこの認証要求を拒否する場合、アカウントをネガティブファイルに加えることができる。
【００６８】
この認証が一度得られると、カードを、適切なビジネスルールに従って交通網で用いることができる。
【００６９】
ポストファンド取引の集約に対する適切なビジネスルールは、以下の条件に適合し又は以下の条件を超えたときにクリアするために送信される集約された取引量を必要とする。
（１）１０回の乗車が行われた。
（２）最初の乗車から最大半月経過した。１ヶ月の１〜１５日において、少なくとも２週間オープンであった予め支払われた累積量を記入することができる。
（３）取引が許容された後であるが集約された量が認証前に送出される前には、カードがホットリストに挙げられる。
【００７０】
これらの条件はパラメータに基づく。パラメータを、ペイパス（登録商標）交通支払いプラットホーム５１０を通じて設定するとともに、ペイパス（登録商標）リーダ／端末にダウンロードすることができる。集約したビジネスルール条件のいずれか一つに適合した後、ペイパス（登録商標）交通支払いプラットホーム５１０は、クリア取引を形成することができる。カードの次の（予めの決済）使用に対して、ペイパス交通支払いプラットホーム５１０は、カードを未知のものとして取り扱うとともに認証要求を処理することができる。
【００７１】
ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、認証及びクリア機能を実行するためにネットワークへのアクセスを有する。交通機関がこれら取引のマーチャントであるとともに現存するマーチャント／取得者関係が既に設定されていると仮定される。ペイパス（登録商標）交通支払いプラットホーム５１０は、好適には、全ての取引の監査トレイル及び回転式改札口でプラットホームに発生するインタラクションを提供することができる。このデータは、設計されたサポートシステム及びファイルフォーマットに送出することができる。
【００７２】
ペイパス交通支払いプラットホーム５１０は、ポジティブ（エンタイトルメント）及びネガティブファイルを維持し及び管理することができる。ネガティブファイルを、ホットカード（例えば、紛失、盗難及び「発行の際に受け取られなかった」（ＮＲＩ）カード）をリストするのに用いられる。ネガティブファイルは、規則的に、好適には、４時間ごとに端末５２４にダウンロードされる。ペイパス（登録商標）交通支払いプラットホーム５１０は、カード発行者から供給されるデータ、マスターカードから供給されるデータ及び／又はペイパス（登録商標）交通支払いプラットホーム動作に基づいて毎日複数回ネガティブファイルを更新することができる（例えば、プレファンドアカウントバランスの全てを使い尽くしたカードをネガティブファイルに加えることができる。）。カードを穂一途リストから除外するよう発行銀行から要求されるとき（例えば、以前にホットリストに加えられた滞納の顧客が料金を支払うとき）、又は使い尽くされたプレファンドアカウントが充填されたとき、カードをホットリストから外すことができる。
【００７３】
ペイパス（登録商標）交通支払いプラットホーム５１０及び端末システムは、ペイパス（登録商標）装置の使用を追跡するベロシティファイルを維持することができる。このベロシティファイルを、１日に複数回交通機関に送信することができる。例えば、ＭＴＡによって設けられるとともに維持されるダイヤルアップ電話線上で端末と通信を行うためにペイパス（登録商標）交通支払いプラットホームを要求することができる。
【００７４】
図５は、交通網のカードリーダでの料金支払いに対して顧客がペイパス（登録商標）カードを提示するときにＡＦＣプロセス７００に含まれる典型的なステップを示す。ステップ７１において、カードの銀行識別番号（ＢＩＮ）を検査する。ＢＩＮが範囲内にある場合、ステップ７２において、カードがホットリストに対して検査される。ステップ７１及び７２の検査の結果が否定された場合、取引が拒否される（ステップ７３）。ステップ７１及び７２の検査の結果が肯定された場合、取引が行われ（ステップ７４）、処理のためにペイパス（登録商標）交通支払いプラットホームに送信される（ステップ７５）。
【００７５】
ステップ７６において、ペイパス（登録商標）交通支払いプラットホームは、カードに関連するプレファンドアカウントが存在するか否か決定する。プレファンドアカウントが存在する場合、ステップ７７において、ペイパス（登録商標）交通支払いプラットホームは、プレファンドアカウント動作を実行する。カードに関連するプレファンドアカウントが存在しない場合、ステップ７８において、ペイパス（登録商標）交通支払いプラットホームは、カードに関連する蓄積又は集約アカウントが存在するか否か決定する。カードに関連する蓄積アカウントが存在しない場合、ステップ７９において、ペイパス交通支払いプラットホームは、カードに関連する蓄積アカウントをセットアップする。カードに関連する蓄積アカウントが存在する場合、ステップ８０において、ペイパス（登録商標）交通支払いプラットホームは、取引を蓄積アカウントに蓄積する。最後に、ステップ８１において、ペイパス（登録商標）交通支払いプラットホームは、ビジネスルール条件がトリガされるときに集約のために記録のアカウント／クリアの準備を行う。
【００７６】
本発明によれば、上記ＡＦＣソリューションを実現するソフトウェア（すなわち、命令）を、コンピュータ読出し可能媒体に設けることができる。（本発明による既に説明した）ステップの各々及びこれらステップの組合せを、コンピュータプログラム命令を、マシンを製造するためにコンピュータ又は他のプログラマブル装置にロードすることができ、したがって、コンピュータ又は他のプログラマブル装置で実行する命令は、上記ＡＦＣソリューションの機能を実現する手段を形成する。これらプログラマブル命令を、特定の方法で機能するようにコンピュータ又は他のプログラマブル装置に命令することができるコンピュータ読出し可能メモリに記憶することもでき、したがって、コンピュータ読出し可能メモリに格納された命令は、上記ＡＦＣソリューションの機能を実現する命令手段を含む製品を製造する。コンピュータプログラム命令を、一連の動作ステップをコンピュータ又は他のプログラマブル装置上で実行してコンピュータで実現されるプロセスを生成するためにコンピュータ又は他のプログラマブル装置にロードすることもでき、したがって、コンピュータ又は他のプログラマブル装置上で実行する命令は、上記ＡＦＣソリューションの機能を実現するステップを提供する。上記ＡＦＣソリューションを実現する命令が設けられたコンピュータ読出し可能媒体は、ファームウェア、マイクロコントローラ、マイクロプロセッサ、集積回路、ＡＳＩＣＳ及び他の利用できる媒体を含むが、これらに限定されるものではない。
【００７７】
付記Ａ
ＭＴＡ料金構造
・１回の乗車−通常料金−２ドル
・１回の乗車−割引料金−１ドル
・ペイパーライドメトロカード（通常料金又は割引料金のプレファンド旅行）
・４ドルから８０ドルまでの乗車数の購入
・１０ドル以上をカードに入れ、２０％のボーナスを受け取る。
・地下鉄とバスとの間又はバス間の自動的な自由乗換
・（地下鉄から地下鉄又は出発したバスルートへの乗換なし）
・（カードが満了するまで好みに応じてしばしば再充填）
・（１度に４人まで支払いに用いることができる。）
・制限のない乗車メトロカード（所定の期間中のプレファンド無制限旅行）
・１日ファンパス
・７日
・３０日
・７日エクスプレスバスプラス
・３０日無制限乗車（ＪＫＦエアトレインのみ）
・（再充填なし−新たな期間の各々に対する新たなカードの購入）
・（同一の地下鉄の駅又は同一のバスルートで１８分間使用できない。）
（１度に一人だけ利用できる。）
【００７８】
付記Ｂ
【表２】
【００７９】
付記Ｃ
主要構成要素の機能／処理
この付記は、主要システム構成要素への処理の影響の包括的な説明のリストである。
ゲート処理
・読出しカード（ＰＡＮ＋満了日＋ＣＶＣ）
・認証カード（ローカル）
・ＰＡＮチェックサムＯＫ
・満了日を超えていないかチェック
・ローカルネガティブファイルに対するカードデータのチェック
・識別がＯＫの場合、ゲートを開く。
・フォーマット取引記録
・駅＋ゲート＋カードデータ＋取引タイプ（エントリのみ）＋データ／タイムスタンプ
ステーションコントローラ処理
・ネガティブファイル受信
・ネガティブファイル問合せに対する応答
・取引記録の格納及び送信
・ペイパス（登録商標）取引を新たな交通支払いプラットホームに送出
・現存するメトロカード取引を現在のキュービックプラットホームに送出
交通支払いプラットホーム処理
・テーブルメンテナンス
・料金
・アクティブステーション
・システム内のゲート−料金制御エリアによる
・カードタイプ
・料金プラン
・トラベルルール
・登録カード＋料金プラン
・カードアカウント／エンタイトルメント
・アカウント情報におけるカード問合せ
・更新料金プラン
・ブロックカード（例えば、紛失／盗難）
・ネガティブファイルメンテナンス
・新たなエンティティ追加
・エンティティクリーンアップ
・ネガティブファイル分配
・取引バッチの受信／認証
・バッチ認証
・取引認証
・分類（ＰＡＮ、日付／時間、ステーション／ゲート）
・取引バッチの処理（ノート１）
・旅行取引の形成及び旅費の計算
・（例外処理）
・ペイパーライド取引の処理
・制限のない乗車の取引の処理
・１回の乗車の取引の処理
・（１回を超えるクレジット／デビット旅行を集約できるか否かの問合せ）
・再供給からの再ロード処理
・（デビット／クレジット取引に対する）取得者インタフェース
・危機管理／不正検出
・決済
・ＭＴＡによる
・取得者による
・再供給による
・顧客サービス
【図面の簡単な説明】
【００８０】
【図１】図１は、本発明の原理による、交通網に対する電子的な支払いの解決の論理素子を示すブロック図である。
【図２】図２は、本発明の原理による、料金支払いに対するペイパス（登録商標）カードの使用に基づく交通機関の典型的な自動料金収集アーキテクチャを示すブロック図である。
【図３】図３は、本発明の原理による、自動料金収集の交通網インフラストラクチャに接続したスマートカード支払いプラットホームの構成要素を示す線形図である。
【図４】図４は、本発明の原理による、交通網で用いられる顧客のスマートカードを登録するプロセスに含まれる典型的なステップを示す流れ図である。
【図５】図５は、本発明の原理による、料金支払いの際に顧客が交通網のカードリーダにスマートカードを提示するときに料金取引を処理するプロセスに含まれる典型的なステップを示す流れ図である。
【特許請求の範囲】
【請求項１】
交通網で料金を自動的に収集する方法であって、
端末コントローラに結合したＲＦＩＤ使用可能なカードリーダを使用して、前記交通網のゲートの有料エリアにアクセスするために顧客によって提示された非接触支払いカードを読み出し、
読み出した非接触支払いカードを、カードのリストを有するファイルに対して評価し、前記交通網のゲートの有料エリアへの顧客のアクセスを許容し又は否定し、
カード取引記録を準備するとともに、前記カード取引記録を交通支払いプラットホームに送信し、
前記交通網が、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を自動的に収集できるようにするために、前記交通支払いプラットホームで前記カード取引記録を処理する方法。
【請求項２】
請求項１記載の方法において、さらに、前記カードのリストを有するファイルを、前記交通支払いプラットホームから、前記ＲＦＩＤ使用可能なカードリーダに結合された端末コントローラに送信し、前記カードのリストが、紛失、盗難及び滞納を含むことを特徴とする方法。
【請求項３】
請求項１記載の方法において、前記交通支払いプラットホームでのカード取引記録の処理が、顧客によって提示された非接触支払いカードの発行者にリンクした市販のカードによる支払いの電子的なネットワーク上の認証、クリア及び決済を具えることを特徴とする方法。
【請求項４】
請求項３記載の方法において、さらに、非接触支払いカード及び取引支払い処理に対するオープンなＩＳＯ業界標準に従うことを特徴とする方法。
【請求項５】
請求項３記載の方法において、顧客によって提示された非接触支払いカードの発行者にリンクした市販のカードによる支払いの電子的なネットワーク上の認証、クリア及び決済が、集約されたカード取引の認証を更に具えることを特徴とする方法。
【請求項６】
請求項１記載の方法において、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を前記交通網が自動的に収集できるようにするための前記交通支払いプラットホームでの前記カード取引記録の処理が、前記顧客によって提示された非接触支払いカードが未登録カードであるかプレファンド交通支払いアカウントに関連する予め登録されたカードであるかを決定することを特徴とする方法。
【請求項７】
請求項６記載の方法において、プレファンド交通支払いアカウントに関連した登録されたカードに対して、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を前記交通網が自動的に収集できるようにするための前記交通支払いプラットホームでの前記カード取引記録の処理が、前記プレファンド交通支払いアカウントのバランスを検査し、前記プレファンド交通支払いアカウントから料金の支払いを取得することを特徴とする方法。
【請求項８】
請求項７記載の方法において、前記プレファンド交通支払いアカウントのバランスが前記プレファンド交通支払いアカウントから料金の支払いを取得するのに不十分であるとき、紛失、盗難及び滞納のカードのリストに前記カードを追加することを特徴とする方法。
【請求項９】
請求項６記載の方法において、前記プレファンド交通支払いアカウントを乗車決済アカウントとし、前記プレファンド交通支払いアカウントのバランスの検査が、乗車決済の可能性を検査し、前記プレファンド交通支払いアカウントからの料金支払いの取得が、前記アカウントから乗車決済を推測することを特徴とする方法。
【請求項１０】
請求項１記載の方法において、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を前記交通網が自動的に収集できるようにするための前記交通支払いプラットホームでの前記カード取引記録の処理が、交通網料金スケジュールを実現することを特徴とする方法。
【請求項１１】
交通網の有料エリアにアクセスするために市販のカード発行者から発行されたＲＦＩＤ使用可能なスマートカードを提示する顧客から料金を収集するために交通網で自動的に料金を収集するシステムであって、
交通支払いプラットホームと、
前記交通網の有料エリアに導くゲートに配置され、前記顧客によって提示されたスマートカードを非接触に読み出すＲＦＩＤ操作可能なカードリーダと、
前記カードリーダに結合された端末コントローラとを具え、カードのリストを有するファイルに対し、前記カードリーダによって読み出されたスマートカードを許容し又は拒否し、前記顧客が前記ゲートを通過するのを許可し又は拒絶し、カード取引記録を発生し及び前記カード取引記録を前記交通支払いプラットホームに送信するように、前記端末コントローラ及びカードリーダを構成し、
前記交通網が、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を自動的に収集できるようにするために、前記交通支払いプラットホームで前記カード取引記録を処理するように、前記交通網プラットホームを構成したシステム。
【請求項１２】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、前記支払いカード取引の認証、クリア及び決済のためにカードによる支払いの電気的なネットワークにリンクした認証／クリアアプリケーションを具えることを特徴とするシステム。
【請求項１３】
請求項１２記載のシステムにおいて、前記スマートカード及びカードによる支払いの電子的なネットワークが、非接触支払いのオープンなＩＳＯ業界標準に従うことを特徴とするシステム。
【請求項１４】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、紛失、盗難又は滞納のカードを含むカードのリストを維持するように設計したファイルアプリケーションを有することを特徴とするシステム。
【請求項１５】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、カードのリストを維持するように設計されるとともに料金及び乗車決済に関連したファイルアプリケーションを具えることを特徴とするシステム。
【請求項１６】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、前記スマートカードをプレファンド交通アカウントにリンクすることができる顧客アカウント管理アプリケーションを具えることを特徴とするシステム。
【請求項１７】
請求項１６記載のシステムにおいて、前記交通支払いプラットホームが、前記カード取引をプレファンドアカウント取引とポストファンドアカウント取引のうちの一方として前記カード取引を処理するように設計した顧客支払いアプリケーションを具えることを特徴とするシステム。
【請求項１８】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、前記ＲＦＩＤ操作可能なカードリーダ及び前記端末コントローラに設定更新を供給するように設計されたネットワーク管理アプリケーションを具えることを特徴とするシステム。
【請求項１９】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、交通網料金スケジュールに従って取引料金を実現するよう設計されたアカウントメンテナンスアプリケーションを具えることを特徴とするシステム。
【請求項２０】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、アカウント形態及び取引報告に対する双方向アクセスを前記顧客に提供するよう設計された交通顧客インタフェースを具えることを特徴とするシステム。
【請求項１】
交通網で料金を自動的に収集する方法であって、
端末コントローラに結合したＲＦＩＤ使用可能なカードリーダを使用して、前記交通網のゲートの有料エリアにアクセスするために顧客によって提示された非接触支払いカードを読み出し、
読み出した非接触支払いカードを、カードのリストを有するファイルに対して評価し、前記交通網のゲートの有料エリアへの顧客のアクセスを許容し又は否定し、
カード取引記録を準備するとともに、前記カード取引記録を交通支払いプラットホームに送信し、
前記交通網が、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を自動的に収集できるようにするために、前記交通支払いプラットホームで前記カード取引記録を処理する方法。
【請求項２】
請求項１記載の方法において、さらに、前記カードのリストを有するファイルを、前記交通支払いプラットホームから、前記ＲＦＩＤ使用可能なカードリーダに結合された端末コントローラに送信し、前記カードのリストが、紛失、盗難及び滞納を含むことを特徴とする方法。
【請求項３】
請求項１記載の方法において、前記交通支払いプラットホームでのカード取引記録の処理が、顧客によって提示された非接触支払いカードの発行者にリンクした市販のカードによる支払いの電子的なネットワーク上の認証、クリア及び決済を具えることを特徴とする方法。
【請求項４】
請求項３記載の方法において、さらに、非接触支払いカード及び取引支払い処理に対するオープンなＩＳＯ業界標準に従うことを特徴とする方法。
【請求項５】
請求項３記載の方法において、顧客によって提示された非接触支払いカードの発行者にリンクした市販のカードによる支払いの電子的なネットワーク上の認証、クリア及び決済が、集約されたカード取引の認証を更に具えることを特徴とする方法。
【請求項６】
請求項１記載の方法において、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を前記交通網が自動的に収集できるようにするための前記交通支払いプラットホームでの前記カード取引記録の処理が、前記顧客によって提示された非接触支払いカードが未登録カードであるかプレファンド交通支払いアカウントに関連する予め登録されたカードであるかを決定することを特徴とする方法。
【請求項７】
請求項６記載の方法において、プレファンド交通支払いアカウントに関連した登録されたカードに対して、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を前記交通網が自動的に収集できるようにするための前記交通支払いプラットホームでの前記カード取引記録の処理が、前記プレファンド交通支払いアカウントのバランスを検査し、前記プレファンド交通支払いアカウントから料金の支払いを取得することを特徴とする方法。
【請求項８】
請求項７記載の方法において、前記プレファンド交通支払いアカウントのバランスが前記プレファンド交通支払いアカウントから料金の支払いを取得するのに不十分であるとき、紛失、盗難及び滞納のカードのリストに前記カードを追加することを特徴とする方法。
【請求項９】
請求項６記載の方法において、前記プレファンド交通支払いアカウントを乗車決済アカウントとし、前記プレファンド交通支払いアカウントのバランスの検査が、乗車決済の可能性を検査し、前記プレファンド交通支払いアカウントからの料金支払いの取得が、前記アカウントから乗車決済を推測することを特徴とする方法。
【請求項１０】
請求項１記載の方法において、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を前記交通網が自動的に収集できるようにするための前記交通支払いプラットホームでの前記カード取引記録の処理が、交通網料金スケジュールを実現することを特徴とする方法。
【請求項１１】
交通網の有料エリアにアクセスするために市販のカード発行者から発行されたＲＦＩＤ使用可能なスマートカードを提示する顧客から料金を収集するために交通網で自動的に料金を収集するシステムであって、
交通支払いプラットホームと、
前記交通網の有料エリアに導くゲートに配置され、前記顧客によって提示されたスマートカードを非接触に読み出すＲＦＩＤ操作可能なカードリーダと、
前記カードリーダに結合された端末コントローラとを具え、カードのリストを有するファイルに対し、前記カードリーダによって読み出されたスマートカードを許容し又は拒否し、前記顧客が前記ゲートを通過するのを許可し又は拒絶し、カード取引記録を発生し及び前記カード取引記録を前記交通支払いプラットホームに送信するように、前記端末コントローラ及びカードリーダを構成し、
前記交通網が、前記交通網の有料エリアへのアクセスが許容された顧客に対する料金を自動的に収集できるようにするために、前記交通支払いプラットホームで前記カード取引記録を処理するように、前記交通網プラットホームを構成したシステム。
【請求項１２】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、前記支払いカード取引の認証、クリア及び決済のためにカードによる支払いの電気的なネットワークにリンクした認証／クリアアプリケーションを具えることを特徴とするシステム。
【請求項１３】
請求項１２記載のシステムにおいて、前記スマートカード及びカードによる支払いの電子的なネットワークが、非接触支払いのオープンなＩＳＯ業界標準に従うことを特徴とするシステム。
【請求項１４】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、紛失、盗難又は滞納のカードを含むカードのリストを維持するように設計したファイルアプリケーションを有することを特徴とするシステム。
【請求項１５】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、カードのリストを維持するように設計されるとともに料金及び乗車決済に関連したファイルアプリケーションを具えることを特徴とするシステム。
【請求項１６】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、前記スマートカードをプレファンド交通アカウントにリンクすることができる顧客アカウント管理アプリケーションを具えることを特徴とするシステム。
【請求項１７】
請求項１６記載のシステムにおいて、前記交通支払いプラットホームが、前記カード取引をプレファンドアカウント取引とポストファンドアカウント取引のうちの一方として前記カード取引を処理するように設計した顧客支払いアプリケーションを具えることを特徴とするシステム。
【請求項１８】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、前記ＲＦＩＤ操作可能なカードリーダ及び前記端末コントローラに設定更新を供給するように設計されたネットワーク管理アプリケーションを具えることを特徴とするシステム。
【請求項１９】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、交通網料金スケジュールに従って取引料金を実現するよう設計されたアカウントメンテナンスアプリケーションを具えることを特徴とするシステム。
【請求項２０】
請求項１１記載のシステムにおいて、前記交通支払いプラットホームが、アカウント形態及び取引報告に対する双方向アクセスを前記顧客に提供するよう設計された交通顧客インタフェースを具えることを特徴とするシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２００８−５４１３０３（Ｐ２００８−５４１３０３Ａ）
【公表日】平成２０年１１月２０日（２００８．１１．２０）
【国際特許分類】
【出願番号】特願２００８−５１２４１４（Ｐ２００８−５１２４１４）
【出願日】平成１８年５月１６日（２００６．５．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０１８７８７
【国際公開番号】ＷＯ２００６／１２４８０８
【国際公開日】平成１８年１１月２３日（２００６．１１．２３）
【出願人】（５００５５７８６４）マスターカード インターナシヨナル インコーポレーテツド (18)
【Ｆターム（参考）】
【公表日】平成２０年１１月２０日（２００８．１１．２０）
【国際特許分類】
【出願日】平成１８年５月１６日（２００６．５．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０１８７８７
【国際公開番号】ＷＯ２００６／１２４８０８
【国際公開日】平成１８年１１月２３日（２００６．１１．２３）
【出願人】（５００５５７８６４）マスターカード インターナシヨナル インコーポレーテツド (18)
【Ｆターム（参考）】
[ Back to top ]