JP2010514014A - キャッシュレス取引を許可する際に使用するための取引システム - Google Patents

Abstract

【課題】
【解決手段】第１のデバイスからの第１の識別データ及び第２のデバイスからの第２の識別データを読み取るためのエントリ・システムと、第１及び第２の識別データに基づいて取引アカウントの支払アカウント・データにアクセスするため及び支払アカウント・データを使用して支払取引に関する許可データを要求するためのデータベース・システムと、を含む取引システム。エントリ・システムは、許可データの受け取りに応答して、許可プロセスを実行する。データベース・システムは、許可データの受け取りに応答して、許可記録を許可時間と共に格納する。支払システムを使用して、第２の識別データを第２のデバイスから読み取り、支払額を表す支払データを生成することができる。次に、データベース・システムは、第２の識別データ及び許可記録に基づいて、並びに支払取引を実行するために、支払データ及び支払アカウント・データを支払処理システムに提出することに応答して、支払取引に対する許可を決定する。
【選択図】図１

Description

本発明は、取引システム、及び当該システムによって実行されるプロセスに関する。当該システムは、キャッシュレス取引を許可する際に使用するためのものである。

多くの異なるキャッシュレス取引システムが開発又は提案されてきたが、限られた数のものだけが首尾よく実施及び使用されている。システムは、通常、金融取引に関連付けられた様々な関係者に関する幾つかの競合する基準を満たす必要がある。この基準、並びに技術的な要件及び定義には、システムが消費者にとって便利かつ使いやすく、また、消費者、売買業者、アカウント発行者及び取引取得者のセキュリティ及びプライバシーを満たせるように対処する必要がある。

例えば、消費者が身に付けるか又は消費者の車両に搭載された無線周波識別デバイス（ＲＦＩＤ）を使用するキャッシュレス取引システムが提案されてきた。ＲＦＩＤはシステムによって読み取られ、以前に確立された支払アカウントを識別するために使用される識別データを提供する。ＲＦＩＤは、支払アカウントに直接関連付けられ、ここから商品又はサービスに対して直接支払いが実行される。支払アカウント及び関連付けられたＲＦＩＤが検証されると、消費者によって提供されるＰＩＮの入力又はバーコードのスキャンなどのＲＦＩＤに関連付けられた追加の識別データを提供する消費者によって購入時に支払いが実行できる。しかし、システムは、支払いが要求されるまで、支払アカウントに十分な資金があるか否かを判別せず、以前の検証は、ＲＦＩＤによって保持される第１の識別データに基づいて実行されるのみである。システムは、アカウントからの支払いを処理するためのインフラストラクチャを含むこと、及びデビット決済アカウントに資金を追加できるなどのいずれかの十分な資金が確実に使用可能であるようにするための設備を提供することも必要である。消費者がＰＩＮなどの第２の識別データを記憶する必要がある場合、消費者の利用しやすさも損なわれる。２つの形のデータ識別の相関関係なしではシステムのセキュリティが損なわれる。

従って、上記問題に対処するため、又は少なくとも有用な代替方法を提供するための技術的解決方法を提供することが望ましい。

本発明によれば、第１のデバイスからの第１の識別データ及び第２のデバイスからの第２の識別データを読み取るためのエントリ・システムと、上記第１及び第２の識別データに基づいて取引アカウントの支払アカウント・データにアクセスするため、及び上記支払アカウント・データを使用して支払取引に関する許可データを要求するためのデータベース・システムと、を含み、上記エントリ・システムが、上記許可データの受け取りに応答して、許可プロセスを実行する取引システムが提供される。

好ましくは、上記データベース・システムは、上記許可データの受け取りに応答して、許可記録を許可時間と共に格納する。

好ましくは、システムは、上記第２の識別データを上記第２のデバイスから読み取るため、及び支払額を表す支払データを生成するための支払システムをさらに含み、上記データベース・システムは、上記第２の識別データ及び上記許可記録に基づいて、並びに上記支払取引を実行するために、上記支払データ及び上記支払アカウント・データを支払処理システムに提出することに応答して、支払取引に対する許可を決定する。

本発明は、また、第１のデバイスからの第１の識別データ及び第２のデバイスからの第２の識別データを読み取ることと、上記第１及び第２の識別データに基づいて取引アカウントにアクセスすることと、上記取引アカウントの支払アカウント・データを使用して支払取引に関する許可データを要求することと、上記許可データの受け取りに応答して、許可記録を許可時間と共に格納することと、を含む取引プロセスも提供する。

好ましくは、プロセスは、上記第１及び第２の識別データを使用して上記第１及び第２のデバイスの妥当性を検査することをさらに含む。

有利なこととしては、取引プロセスは、上記第２のデバイスから上記第２の識別データを読み取り、支払額を表す支払データを生成することと、上記第２の識別データ及び上記許可記録に基づいて、支払取引に対する許可を決定することと、上記支払データ及び上記支払アカウント・データを、上記支払取引を実行するための支払処理システムに提出することと、をさらに含むことができる。

本発明は、また、第１のＲＦＩＤを読み取って妥当性を検査することと、第２のＲＦＩＤを読み取って妥当性を検査することと、上記第１のＲＦＩＤ及び上記第２のＲＦＩＤに関連付けられた支払アカウント・データにアクセスすることと、所定の期間内での支払いを許可するための上記第２のＲＦＩＤの後続使用に関する承認を表す許可データを取得するために、許可取引を上記支払アカウント・データと共に支払処理システムに提出することと、を含む取引プロセスも提供する。

添付の図面を参照しながら以下に本発明の好ましい実施形態について説明するが、これは単に例示としてのものに過ぎない。

取引システムの好ましい実施形態を示すブロック図である。 取引システムのエントリ・システムを示す概略図である。 取引システムの中央サーバ及びサイト構成要素を示すブロック図である。 取引システムのウェブ及びデータベース・サーバによって実行される取引アカウント確立プロセスを示すフローチャートである。 取引システムのエントリ・コントローラによって実行されるエントリ・プロセスを示すフローチャートである。 取引システムの支払コントローラによって実行される支払プロセスを示す図である。

２つの無線周波識別デバイス（ＲＦＩＤ）からの識別データを使用して２重許可プロセスを実行することによって、キャッシュレス取引を容易にするために、図１及び図３に示されるような取引システムが使用される。この取引システムは、ブロードバンド・データ通信ネットワーク１３０を使用して（例えば、ＤＳＬネットワークを介したインターネット・プロトコルを使用して）、幾つかのサイト・システム１０２と通信可能なサイト・システム１０２及び中央又はバック・オフィス・システム１０４を含む。サイト・システム１０２は、消費者が購入するための製品、すなわち商品又はサービスを提供するサイトに配置される。例えばサイトの例としては、スーパーマーケット、ショッピング・センター、駐車場、レストランなどが挙げられる。

中央システム１０４は、ウェブ・サーバ１２０と、データベース・サーバ１１０と、メッセージング・サーバ１３０とを含む。メッセージング・サーバ１３０は、図３に示されるように、ｅメール・サブシステム３０２と、ＳＭＳサブシステム３０４と、レポート生成器３０６とを含む。

データベース・サーバ１１０は、Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒ又はＬｉｎｕｘなどのオペレーティング・システム上で、ＭｙＳＱＬなどのデータベース・サーバ・コンピュータ・ソフトウェアを実行するＬｅｎｏｖｏ Ｇｒｏｕｐ Ｌｔｄ．又はＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．によって製造されるようなコンピュータ・サーバを含む。データベース・サーバ１１０は、以下で説明する中央データベース１１２内の取引システムのユーザに関する取引アカウント・データを維持する。データベース・サーバ１１０は、また、取引システムの他の構成要素間で渡される制御データの受信、送信、及び処理を扱うための通信コントローラ３１０を含む。通信コントローラ３１０は、ＤＳＬモデムなどの通信モジュール及び標準通信インタフェース構成要素を含む。モジュールは、Ｃ＋＋又はＪａｖａ（登録商標）などのコンピュータ・プログラム・コードで作成可能であるか、又は、例えばＡＳＩＣ及びＦＰＧＡなどの専用ハードウェア回路によって実施可能である。データベース・サーバ１１０は、支払処理システム（ＰＰＳ）１４０及び料金徴収システム１４２と通信することができる。ＰＰＳ１４０は、１つ又は複数の金融機関によって維持可能であり、クレジット・カード又はデビット・カードの取引を実行するための電子決済システムを含む。例えばＰＰＳ１４０は、既存の電子決済販売時点管理（ＥＦＴＰＯＳ）ネットワークを含むことができる。料金徴収システム１４２は、スウェーデンのＫａｐｓｃｈ ＴｒａｆｆｉｃＣｏｍ Ａｂによって製造されるようなトラフィック料金徴収システムとすることが可能な料金徴収システム１４２のユーザに関する料金徴収アカウント・データを維持するためのデータベース・サーバを含む。料金徴収データベース・サーバ１４２は、以下で説明するように、取引システムによって使用される第１のＲＦＩＤ２３０に関連付けられたデータを含むユーザの料金徴収アカウント・データにアクセスすることができる。

ウェブ・サーバ１２０は、Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒ又はＬｉｎｕｘなどのオペレーティング・システム上で、Ａｐａｃｈｅ、及びＪａｖａ（登録商標） Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＪＳＰ）、及びＪａｖａ（登録商標） Ｓｅｒｖｌｅｔｓなどのウェブ・サーバ・コードを実行するＬｅｎｏｖｏ Ｇｒｏｕｐ Ｌｔｄ．又はＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．によって製造されるようなサーバ・コンピュータを含む。ウェブ・サーバ１２０は、以下で説明するように、ウェブサイト３２０をサポートし、データベース・サーバ１１０によって維持される取引アカウントのリモートでの確立及び維持を可能にする。ウェブ・サーバ１２０のウェブサイトには、ユーザ（例えば消費者）のクライアント・コンピュータ１３２又は管理者のクライアント・コンピュータ１３４によって、インターネット１２５を介してアクセス可能である。

ｅメール・サブシステム３０２は、データベース・サーバ１１０又はレポート生成器３０６から受信した命令メッセージに基づいて、クライアント・システム１３２及び１３４にｅメール・メッセージを送信するためのＳＭＴＰサーバを含む。レポート生成器３０６は、データベース１１２からアクセスされたデータを使用して、要求に応じて、又は定期的に、レポートを生成することができる。その後、レポートは、ｅメール・サブシステム３０２によって生成及び送信されたメッセージに添付することができる。レポートは、ウェブサイト３２０にアクセスする管理者１３４によって要求することもできる。データベース・サーバ１１０からの命令で、ＳＭＳサブシステム３０４も、ＳＭＳゲートウェイ１２７によってユーザの携帯電話１３６に送信されることになるＳＭＳメッセージを生成することができる。

ウェブ・サーバ１２０及びメッセージング・サーバ１３０は、以下で説明するように、取引システムの管理者及びユーザのシステム又はデバイス１３２、１３４、及び１３６に対する通信サービスをサポートする。

サイト・システム１０２は、図１、図２、及び図３で示されるような１つ又は複数のエントリ制御システム１０６、及び図３で示されるような１つ又は複数の支払システム１０８を含む。複数のエントリ及び支払システムを有するサイトの場合、システムのデータ処理構成要素を組み合わせることができる。

図１、図２、及び図３で示されるように、エントリ・システム１０６は、ローカル・コンピュータ・システム２０２と、どちらも第１のリーダ２０４及びゲート・コントローラ２０６に対するデジタル入出力通信インタフェース・カード２０８によってローカル・コンピュータ・システム２０２に接続された第１のＲＦＩＤリーダ２０４及びブーム・ゲート・コントローラ２０６とを含む。ブーム・ゲート・コントローラ２０６は、液晶ディスプレイ２１０、第２のＲＦＩＤリーダ２１２、車両ブーム・ゲート２１４と、車両２２０の存在を検出するための車両存在リレー（ＶＰＲ）２１６とを含む。車両２２０は、本明細書では「ｅＴａｇ」と示された第１のＲＦＩＤデバイス２３０、及び本明細書では「ｉＴａｇ」と示された第２のＲＦＩＤデバイス２４０を含む。

ｅＴａｇ２３０は、リーダ２０４のレンジ内にあり、リーダ２０４によって照会された場合、第１の識別データをリーダ２０４に送信する。この識別データは、ｅＴａｇに固有の番号を表す。ｅＴａｇ２３０は、車両２２０と、料金徴収システム１４２によってユーザに対して維持されている料金徴収アカウントとに関連付けられる。ｅＴａｇ２３０を使用して、Ｔｒａｎｓｕｒｂａｎ ＬｉｍｉｔｅｄのＣｉｔｙＬｉｎｋネットワークなどのように、車両が有料道路上を走行している場合、車両と料金徴収システムに対するアカウントとを識別することができる。例えばｅＴａｇ２３０は、Ｋａｐｓｃｈ ＴｒａｆｆｉｃＣｏｍ Ａｂによって製造されるＰＲＥＭＩＤマイクロ波リンク・デバイスとすることができる。ｅＴａｇ２３０は、通常は、関連付けられた車両２２０内に取り付けられ、維持される。

第２のＲＦＩＤタグ２４０は、受動短距離トランスポンダである。トランスポンダは、リーダ２１２の近隣に配置された場合、高周波を使用して第２の識別データをｉＴａｇリーダ２１２に送信する。第２の識別データはｉＴａｇ２４０に対して固有であり、ｉＴａｇ２４０を使用するための取引アカウントに関連付けられる。ｉＴａｇ２４０は、小さな硬貨又はディスクのサイズとすることが可能であり、便利に配布し、財布、携帯電話、又はキーフォブに取り付けることができる。ｉＴａｇリーダ２１２は、ＨＩＤ Ｃｏｒｐｏｒａｔｉｏｎ、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ、及びＰｈｉｌｌｉｐｓによって製造されるような、ＨＦ（１３．５６ＭＨｚ）レンジ内で動作するＭＩＦＡＲＥに準拠したＲＦＩＤの固有の識別データを読み取ることができるデバイスである。

取引システムは、ｅＴａｇ２３０及び料金徴収アカウントの現在の保有者によって使用可能である。システムを使用するために、ユーザは、小売店などの販売店から無料で配布されるｉＴａｇ２４０を入手し、中央システム１０４にアクセスして、ｉＴａｇに関連付けられた取引アカウントを確立する必要がある。ウェブ・サーバ１２０のウェブサイト３２０は、図４に示されるように、ユーザのクライアント・システム１３２がアクセスし、取引アカウント確立プロセスを実行するために使用することが可能である。サイト３２０は、第１に、料金徴収アカウントに関するアカウント番号及び関連付けられた個人識別番号（ＰＩＮ）のクライアント１３２による入力を要求するログイン・ページを送信する（ステップ４０２）。提出された料金徴収アカウント番号及びＰＩＮは、料金徴収システム１４２から（番号によって識別された）料金徴収アカウントに関する料金徴収アカウント・データを取り出すために、データベース・サーバ１１０に渡される。戻されるデータに基づいて、ウェブサイト３２０は、入力された番号及びＰＩＮが有効な料金徴収アカウントの関連付け及び組み合わせを表すか否かを判別する（ステップ４０４）。無効な組み合わせの場合、サイト３２０はログイン・ページを再送する（ステップ４０２）。有効な組み合わせの場合、戻されたアクセス済み料金徴収アカウント・データを使用して、ユーザによる確認のための料金徴収アカウントの詳細表示が送信される（４０６）。料金徴収アカウント・データは、アカウントに関連付けられたｅＴａｇの番号、ｅＴａｇに関連付けられた車両登録番号及び車両、並びにアカウント保有者の名前及びアドレスなどの個人データを表す。戻された料金徴収アカウントの詳細と共に、取引システムの使用及び取引アカウントの保有に関連付けられた条件にアクセスするためのＨＴＴＰリンクが提供される。条件を受諾するためのＨＴＴＰリンクも提供され、関連付けられた応答をウェブ・サーバ１２０に戻すために受諾リンクが起動された場合にのみ、プロセスが進行する（ステップ４０８）。受諾応答を受信すると、ウェブ・サーバ１２０は料金徴収アカウント・データのコピーと共にその受諾を登録し、新しい取引アカウントに関するデータを入力するためのフィールドを備えた動的ページを戻す。データには以下の内容が含まれる。
（ｉ） ｉＴａｇと共に配布された資料に印刷されるか、又はｉＴａｇ自体に印刷されたｉＴａｇ２４０の識別番号に関するフィールド。データベース・サーバ１１０によって維持されるデータベース１１２は、配布されたあらゆるｉＴａｇ上に印刷されたｉＴａｇ番号を、そのｉＴａｇによって送信される識別データに関連付けるテーブルを含む。識別データは、ｉＴａｇ上に印刷されたものと異なるか又は同じである可能性があるトランスポンダに関する固有の識別番号を表す。
（ｉｉ） 取引アカウントに関する固有のユーザ名及びパスワードの組み合わせ。
（ｉｉｉ） 取引アカウントのユーザに関する名前、アドレス、及び連絡先詳細を表す個人データ。これには、メッセージング・サーバ１３０が後に使用可能なｅメール・アドレス及び携帯電話番号が含まれる。
（ｉｖ） 支払アカウント・データ。これには、商品又はサービスに対する支払いを完了するためにＰＰＳによる使用が可能な支払アカウントを表示及び定義するフィールドが含まれる。クレジット・カード・アカウントの場合、これには、カード保有者名、カード番号、カード・タイプ、及びカード有効期日に関するフィールドが含まれる。

上記のデータがウェブ・サーバ１２０に正常に提出されると、料金徴収アカウント・データ及び提出済みデータが、取引アカウントを作成及び確立するための要求と共に、データベース・サーバ１１０に送信される（４１０）。取引アカウント・データは、料金徴収アカウント・データ、識別されたｉＴａｇに関する提出済みデータ及びそれぞれの固有識別データ、及び料金徴収アカウントに関連付けられた１つ又は複数のｅＴａｇに対するフィールドを備えたテーブルに格納される。次に、取引アカウント始動ｅメールが、ｅメール・サブシステム３０２を使用してユーザにより提出されたｅメール・アドレスに送信される（４１２）。始動ｅメールは、新しい取引アカウントに関する識別子でコード化された固有のＵＲＬと共に送信される。ｅメールは、受信者に対して、取引アカウントを起動するためにＵＲＬを選択するように依頼する。ウェブ・サーバ３２０は、コード化されたＵＲＬと共にＨＴＴＰ要求を受け取り（４１４）、このイベントは、取引アカウントを起動するためにデータベース１１２内にフィールドを設定するように、データベース・サーバ１１０に渡される（４１６）。これにより、ユーザに関する有効なｅメール・アドレスに関連付けられた取引アカウントが確実に確立される。条件が受諾されない場合、要求されたデータが受け取られない場合、又はコード化されたＵＲＬが戻されない場合、確立プロセスは終了する（４１８）。

料金徴収アカウントは取引アカウントに関連付けられるが、この２つが確立され、動作する方法は、以下で説明するように、それらが、一方は料金徴収システム１４２に使用され、他方は商品及びサービスに対する支払取引を許可するための事実上異なる２つのアカウントであることを確保する。この関連付けが、取引許可プロセスに対して２要素認証を提供する。取引アカウント確立プロセスは、ｉＴａｇを事前に無料で配布し、その後、料金徴収アカウントと関連付けることを可能にする。料金徴収アカウントは、それに関連付けられた１つ又は複数の取引アカウント、並びにそれに関連付けられた１つ又は複数のｅＴａｇを有することができる。各取引アカウントには１つのｉＴａｇのみが関連付けられるが、同じ支払アカウント（例えばクレジット・カード）を１つ又は複数の取引アカウントに関連付けることができる。

エントリ・システム１０６は、図５に示されるようなエントリ・プロセスを実行し、支払システム１０８は、図６に示されるような支払プロセスを実行する。どちらも、許可又は承認を得るために取引アカウント・データの選択されたフィールドをＰＰＳ１４０に提出するが、支払いのために資金を移すことはない。支払いは、ＰＰＳ１４０により、支払アカウントを使用して実行及び処理される。取引システムは、支払アカウントの勘定残高を維持するものではない。従って、ユーザの２要素認証に加えて、取引許可は取引システムによって事実上２回実行される。

図５に示されるようなエントリ・プロセスは、車両２２０、ｅＴａｇ２３０、及びｉＴａｇ２４０が検出されたか否かを判別することによって、ステップ５０２で開始される。ｉＴａｇリーダ２１２はｉＴａｇ２４０の識別データを読み取り、これが、ローカル・コンピュータ・システム２０２のリーダ・コントローラ３３０に渡され、これによって検出される。ｉＴａｇが検出されると、読み取られた識別データは、検出イベントと共にエントリ・システム１０６のエントリ・コントローラ３３４に渡される。エントリ・コントローラ３３４は、同様の検出イベントを、ｅＴａｇリーダ２０４と通信するｅＴａｇリーダ・コントローラ３３２から受け取る。車両が入口ブーム・ゲート２０４に接近した場合、その存在は、通路内の車両存在リレー（ＶＰＲ）２１６によって検出される。このＶＰＲ検出イベントは、ゲート・コントローラ２０６によって、ローカル・コンピュータ・システム２０２のエントリ・コントローラ３３４に渡される。車両検出イベント、ｉＴａｇ検出イベント、及びｅＴａｇ検出イベントが互いの所定時間内に受け取られると、エントリ・コントローラ３３４は、後続のエントリ・プロセス・ステップの実行に進む。

エントリ・コントローラ３３４及びリーダ・コントローラ３３２は、Ｃ＋＋又はＪａｖａ（登録商標）などのコンピュータ・プログラム・コードで作成されたモジュールを含み、専用のハードウェア回路を使用して実施される。コントローラ３３２、３３４、及びゲート・コントローラ２０６は、Ｓｋｉ Ｄａｔａ ＡＧ、Ａｍａｎｏ Ｃｉｎｃｉｎｎａｔｉ，Ｉｎｃ．、又はＤａｔａ Ｐａｒｋ，Ｉｎｃ．によって製造されるエントリ・システムの構成要素を含む。

エントリ・コントローラ３３４は、読み取られたｅＴａｇの第１の識別データ及びｉＴａｇの第２の識別データを格納する（５０４）。ｅＴａｇに関する識別データは、ｅＴａｇが有効であるか否か、及びいずれかの取引アカウントがｅＴａｇに関連付けられているか否かを判別する要求と共に、データベース・サーバ１１０に渡される（５０６）。データベース・サーバ１１０は、ｅＴａｇが依然として有効であるか、及び禁止されたｅＴａｇのブラックリストに掲載されていないかを判別するために、料金徴収システム１４２と通信する。ｅＴａｇが有効であると報告された場合、データベース・サーバは、ｅＴａｇ２３０に関連付けられた任意の取引アカウントの取引アカウント・データを取り出し、その取引アカウント・データをエントリ・コントローラ３３４に戻す（５１０）。ｅＴａｇが有効でない場合、ｉＴａｇのユーザに表示するための拒否メッセージ（５０８）がＬＣＤ２１０に送信される。このメッセージは、支払いを容易にするためにｉＴａｇは使用できないことを通知する。

関連付けられた取引アカウントに関するデータを取得すると、エントリ・コントローラ３３４はこのデータを使用して、読み取られたｉＴａｇが現在有効であるか否かを判別する（ステップ５１２）。これには、第２の識別データが、ｅＴａｇに関して取り出された取引アカウントのうちの１つに関連付けられているか否か、及びｉＴａｇ又は識別された取引アカウントがブラックリストの対象であるか否かを判別することが含まれる。ｉＴａｇが無効であると判別された場合、拒否メッセージ（５０８）が表示され、そうでない場合は、識別された取引アカウントの支払アカウント・データを使用して、許可取引をＰＰＳ１４０に提出する。許可取引とは、取引アカウントの支払アカウントを使用して、例えば５０ドルなどの所定の金額の支払いに関する許可データを取得するためのテスト取引である。ＰＰＳ１４０が、取引が承認され続行可能であることを示す許可データを戻した場合、これによって、所定の期間中に支払いを実行するための適切な支払アカウントであるとして、事実上妥当性が検査される。正常な許可が通信コントローラ３１０に報告され、成功メッセージ（ステップ５１６）でエントリ・コントローラ３３４に送信される。成功メッセージが所定の時間内に受け取られない場合、又は所定の金額に関する支払アカウントが承認されないことが報告された場合、ＬＣＤ２１０上に表示するための拒否メッセージ（５０８）が送信される。成功メッセージが受け取られた場合、エントリ・コントローラ３３４及びデータベース・サーバ１１０は、取引アカウントに関連付けられた許可記録を格納する。許可記録は、許可取引と、具体的にはＰＰＳ１４０から承認メッセージが受け取られた時間とを表すデータを含む。許可記録の時間は、許可時間である。許可記録を格納すると（ステップ５１８）、エントリ・コントローラ３３４は成功プロセスを実行する（５２０）。成功プロセスには、以下の内容が含まれる。
（ｉ） ＬＣＤ２１０上に表示するための成功メッセージの送信。この成功メッセージは、ｉＴａｇ２４０が、サイトでの駐車に関する支払いを含む商品又はサービスに対するサイトでの支払いへの対応に使用可能であることをユーザに通知する。
（ｉｉ） 車両２２０がサイト内の駐車エリアに入場できるように、ゲート・コントローラにブーム・ゲート２１４を開けさせるゲート・コントローラ２０６へのオープン・メッセージの送信。

ユーザは、ｉＴａｇ２４０を使用し、第１に、サイトの支払システム１０８に接続されたｉＴａｇリーダ３４０の近くにｉＴａｇを置くことによって、サイト内での任意の商品又はサービスの支払いに対応することができる。支払システム１０８は、支払端末を形成し、リーダ３４０用の読み取りコントローラ３４２及び支払コントローラ３４４を含むローカル・コンピュータ・システムである。支払コントローラ３４４は、Ｃ＋＋又はＪａｖａ（登録商標）などのコンピュータ・プログラム・コードで作成されるか、又は専用ハードウェア回路を使用して実施されたモジュールを含み、既存のキャッシュ・レジスタ又は販売時点管理端末の構成要素を含むこともできる。読み取りコントローラ３４２及びｉＴａｇリーダ３４０は、エントリ・システム１０６によって使用されるものと同じである。読み取りコントローラ３４２がｉＴａｇを検出し、ｉＴａｇの識別データを読み取ると、図６に示されるように、データに付随する検出イベントが支払コントローラ３３４に渡される（６０２）。これに応答して、支払コントローラ３３４がデータベース・サーバ１１０と通信し、ｉＴａｇに関連付けられた取引アカウントに関する格納済みの許可記録を取得する（６０４）。支払コントローラ３４４は、取得された許可記録を処理し、（ｉ）そのサイト及びリーダ３４０の場所に対して有効であるか否か、及び（ｉｉ）許可時間から所定の時間内に発生した検出イベントであるか否かを判別する（６０６）。この処理によって、データが基準（ｉ）及び（ｉｉ）を満たすものと判別された場合、支払データを入力するように要求するメッセージが送信され、支払システム１０２のＬＣＤ３４６上に表示される。基準を満たすものでないと判別された場合、拒否メッセージが送信及び表示される（６０８）。

特定の場所にあるタグ・リーダ３４０の場合、支払コントローラ３４４が支払データ自体を生成することができる。例えば、タグ・リーダ３４０が出口ゲート・コントローラ内に配置され、車両２２０がこのサイトを離れようとしている場合、支払コントローラ３４４は、経過時間に基づいて、駐車に対して支払いが必要な金額を決定し、その金額に関する支払データを生成することができる。経過時間は、許可時間と、支払コントローラ３４４でのｉＴａｇ検出イベントの時間との差である。支払いの承認を受け取ると、出口コントローラは、その車両に対して出口ゲートを開くためのオープン・メッセージを発行することができる。例えば販売店などの他の状況では、人間がキーパッドなどの支払端末の入力デバイス３５０を使用して、金額及び必要な任意の他の詳細を入力することが必要な場合がある。支払システム１０８は、商品又はサービスを提供する店の支払い又はキャッシュ・レジスタに組み込むこともできる。支払データは、金額を示すことに加えて、商品又はサービスの説明などの他の情報を示すこともできる。支払コントローラ３４４が支払データを取得すると、支払コントローラ３４４は、ＰＰＳ１４０に対して取引要求を提出する（６１２）。取引要求には、支払金額及び取引アカウントの支払アカウントを表すデータなどの必要な支払データ及び取引アカウント・データが含まれる。取引要求には、ＰＰＳ１４０が、支払アカウントを使用する支払データに関連付けられた商品又はサービスに対する決済又は支払いに対応するために必要なデータが含まれる。ＰＰＳ１４０によって処理された取引の成功又は失敗の報告が、承認データとしてデータベース・サーバ１１０へ返送され、次に支払コントローラ３４４に報告される。支払取引がＰＰＳ１４０によって承認された場合、成功メッセージが支払コントローラ３４４に送信される。成功メッセージが所定の時間内に受け取られない場合（６１４）、ＬＣＤ３４６上に表示するための拒否メッセージ（６０８）が送信される。成功メッセージが受け取られた場合、支払コントローラ３４４は成功プロセスを実行する（６１６）。成功プロセスには、ＬＣＤ３４６上に支払成功メッセージを表示すること、及びプリンタ３４８を使用して支払いの領収書を印刷することが含まれる。支払システム１０８は、要求された場合にのみ、又はデフォルトとして、領収書を印刷することができる。

この取引システムにより、ユーザは、文書に署名する必要又はキャッシュを取り扱う必要なしに、サイトで商品又はサービスに対する支払いを実行することができる。また、クレジット・カードを提示する必要もない。ユーザにとって必要なことは、有効なｅＴａｇを所有する車両をサイトに駐車させることのみであり、入場時にｉＴａｇが許可されると、このｉＴａｇを様々な支払端末で使用して、支払いに対応することができる。その利便性にもかかわらず、この取引システムのセキュリティは、ｅＴａｇ及びｉＴａｇの両方を使用することによって与えられる２要素認証によって強化され、システムは支払取引を許可するために許可プロセスを２回実行する。

当業者であれば、添付の図面を参照しながら本明細書で説明された本発明の範囲を逸脱することなく、多くの改良が明らかとなろう。

Claims (23)

1. 第１のデバイスからの第１の識別データ及び第２のデバイスからの第２の識別データを読み取るためのエントリ・システムと、
   前記第１及び第２の識別データに基づいて取引アカウントの支払アカウント・データにアクセスするため、及び前記支払アカウント・データを使用して支払取引に関する許可データを要求するためのデータベース・システムと、を含み、
   前記エントリ・システムが、前記許可データの受け取りに応答して、許可プロセスを実行する取引システム。
2. 前記データベース・システムが、前記許可データの受け取りに応答して、許可記録を許可時間と共に格納する、請求項１に記載の取引システム。
3. 前記データベース・システムが、前記第１の識別データの受信時に前記第１のデバイスの妥当性を検査し、前記第１の識別データに関連付けられた取引アカウントにアクセスする、請求項１に記載の取引システム。
4. 前記データベース・システムが、前記第２の識別データの受信時に前記第２のデバイスの妥当性を検査し、前記第２の識別データに関連付けられた取引アカウントを決定する、請求項３に記載の取引システム。
5. 前記許可プロセスが、支払いに対応するために前記第２のデバイスの使用の許可を通知することを含む、請求項１に記載の取引システム。
6. 前記許可プロセスが、サイトへの入場を許可するためのメッセージを生成することを含む、請求項５に記載の取引システム。
7. 前記第２の識別データを前記第２のデバイスから読み取るため、及び支払額を表す支払データを生成するための支払システムを含み、
   前記データベース・システムが、前記第２の識別データ及び前記許可記録に基づいて、並びに前記支払取引を実行するために、前記支払データ及び前記支払アカウント・データを支払処理システムに提出することに応答して、支払取引に対する許可を決定する、請求項２に記載の取引システム。
8. 前記第１及び第２のデバイスがＲＦＩＤデバイスである、請求項１ないし７のいずれか１項に記載の取引システム。
9. 前記第１のデバイスが、料金徴収システムの料金徴収アカウントに関連付けられて、車両内に配置される、請求項８に記載の取引システム。
10. 第１のデバイスからの第１の識別データ及び第２のデバイスからの第２の識別データを読み取ることと、
    前記第１及び第２の識別データに基づいて取引アカウントにアクセスすること、
    前記取引アカウントの支払アカウント・データを使用して、支払取引に関する許可データを要求することと、
    前記許可データの受け取りに応答して、許可記録を許可時間と共に格納することと、
    を含む取引プロセス。
11. 前記第１及び第２の識別データを使用して前記第１及び第２のデバイスの妥当性を検査することを含む、請求項１０に記載の取引プロセス。
12. 前記妥当性を検査することが、前記識別データを、無効なデバイスに関するブラックリスト・データと比較することを含む、請求項１１に記載の取引プロセス。
13. 前記第１の識別データに関連付けられた取引アカウントにアクセスすることと、前記第２の識別データに関連付けられた前記取引アカウントのうちの取引アカウントを決定することとを含む、請求項１０に記載の取引プロセス。
14. 前記許可データの受け取りに応答して、支払いに対応するために前記第２のデバイスの使用の許可を通知することを含む、請求項１０に記載の取引プロセス。
15. 前記許可データの受け取りに応答して、前記第２のデバイスの使用者のサイトへの入場を許可するためのメッセージを生成することを含む、請求項１０に記載の取引プロセス。
16. 前記第２のデバイスから前記第２の識別データを読み取り、支払額を表す支払データを生成することと、
    前記第２の識別データ及び前記許可記録に基づいて、支払取引に対する許可を決定することと、
    前記支払データ及び前記支払アカウント・データを、前記支払取引を実行するための支払処理システムに提出することと、
    を含む、請求項１０又は１１に記載の取引プロセス。
17. 前記第１及び第２のデバイスがＲＦＩＤデバイスである、請求項１０から１６のいずれか１項に記載の取引プロセス。
18. 前記第１のデバイスが、料金徴収システムの料金徴収アカウントに関連付けられて、車両内に配置される、請求項１７に記載の取引プロセス。
19. 前記妥当性を検査することが、前記第１の識別データに基づいて前記料金徴収アカウントにアクセスすることを含む、請求項１８に記載の取引プロセス。
20. 前記第２のデバイスが、受動短距離ＲＦＩＤデバイスであり、前記第１のデバイスが約１００メートルのレンジを有する能動ＲＦＩＤデバイスである、請求項１７から１９のいずれか１項に記載の取引プロセス。
21. 第１のＲＦＩＤを読み取り、妥当性を検査することと、
    第２のＲＦＩＤを読み取り、妥当性を検査することと、
    前記第１のＲＦＩＤ及び前記第２のＲＦＩＤに関連付けられた支払アカウント・データにアクセスすることと、
    所定の期間内での支払いを許可するための前記第２のＲＦＩＤの後続使用に関する承認を表す許可データを取得するために、許可取引を前記支払アカウント・データと共に支払処理システムに提出することと、
    を含む取引プロセス。
22. 前記許可データの受け取りに応答して、サイトへの入場を許可するためのメッセージを生成することを含む、請求項１３に記載の取引プロセス。
23. 支払端末で前記第２のＲＦＩＤを読み取ることと、
    前記第２の識別データに基づいて、前記許可記録にアクセスすることと、
    前記許可記録に基づいて支払取引が許可されたか否かを判別することと、
    前記支払取引を、支払額を表す支払データと共に支払処理システムに提出することと、
    を含む、請求項１３に記載の取引プロセス。

Images