JP2009501395A - 統合支払い・電子商品転送のための装置および方法 - Google Patents

Abstract

支払いインフラストラクチャを使用した支払い取引処理は、ｅ−商品インフラストラクチャを使用してｅ−商品取引処理と効果的に組み合わされると同時に、各インフラストラクチャがその主な機能に集中することを可能にする。支払いインフラストラクチャに従って構成された電子支払いデバイスは、財務データを取得するために、第１の端末の（やはり支払いインフラストラクチャに従って構成された）支払いモジュールによって問い合わせられる。電子商品関連情報は、第１の端末の（電子商品インフラストラクチャに従って構成された）電子商品モジュールによって生成され、かかる情報は、財務データと支払いインフラストラクチャとに従って、実行される取引処理範囲内の電子支払いデバイスに転送される。

Description

本発明は、一般に、電子技術およびコンピュータ技術に関し、より詳細には、電子支払いおよび電子商品転送のための装置および方法に関する。

本特許出願は、２００５年７月１３日に出願した、「Ｔｉｃｋｅｔｉｎｇ Ｅｘｔｅｎｄｅｄ Ｃｏｎｔａｃｔｌｅｓｓ Ｐａｙｍｅｎｔ Ｄｅｖｉｃｅ」と題された、米国仮特許出願第６０／６９９，０１５号の利益を主張するものである。その完全な添付書類を含めて、前述の仮特許出願第６０／６９９，０１５号の開示は、参照により完全に本明細書に明示的に組み込まれている。

一般に、支払い取引処理および電子商品（ｅ−商品としても知られている。この用語は、本明細書で交換可能に使用される）の引渡しは、別個のインフラストラクチャによって処理される。例えば、支払い取引処理は、支払いだけを処理するインフラストラクチャと共に、支払いカードまたはその他の支払いデバイスを使用して行われることが可能である。同様に、ｅ−商品（例えば、電子チケット、トークン、デジタル資格（ｄｉｇｉｔａｌ ｃｒｅｄｅｎｔｉａｌ）、映画、音楽、著作権使用料ポイント、特典クーポン、引換券、データ、暗号化キーすなわち「アンロック」コード、および類似の非物質的商品）の引渡しは、別個のプロセスとして商品の料金を請求するために、支払いインフラストラクチャを起動することが可能である別個の、場合によっては、相補的なインフラストラクチャによって処理される。

１９９５年６月１日に公開された、オランダＰＴＴのオランダ特許出願第ＮＬ９３０１９０２号は、スマート・カードを用いて特定の設備に対する権利を獲得するための方法を開示する。権利の獲得は、端末と制御システムとを経由して実行される。設備に対する権利は、アクセス権または使用権であってよい。スマート・カードまたはその他の登録デバイスはアクセスを支援するために使用される。スマート・カードは、要求される設備に関して支払うためだけでなく、紙のチケットに取って代わる登録手段および確認手段としても使用される。したがって、同じスマート・カードは、将来の設備の権利の購入のため、その支払いのため、および設備のその後の使用、すなわち、購入した権利の行使のために使用されることが可能である。

２００２年４月２３日に発行された、Ｓｔａｎｄｆｏｒｄなどの米国特許第６，３７５，０８４号は、カード請求システムを説明する。ホスト・チケット設備は、カード読取り／書込みデバイスで使用可能なクレジット・カードおよび非接触（ｃｏｎｔａｃｔｌｅｓｓ）カード読取装置で使用可能な譲歩的（ｃｏｎｃｅｓｓｉｏｎａｒｙ）支払いカードの両方によって動作可能であり、カード読取装置とホスト設備の間に配置される安全・取引処理デバイスは、別個の記憶デバイス内に、ホスト設備が計算することができる完全料金と譲歩的料金とを記憶する。１つまたは複数のカード読取装置と、情報を清算センター（ｃｌｅａｒｉｎｇ ｃｅｎｔｅｒ）に送信し戻すためにカード読取装置とホスト設備の間に接続される安全・取引処理デバイスとを有するカード請求システムが説明される。２００２年６月１１日に発行された、Ｓｔａｎｆｏｒｄなどの米国特許第６，４０２，０３８号は、説明されたばかりのＳｔａｎｆｏｒｄなどの‘０８４引用例に類似するようである。

２０００年８月８日に発行された、Ｈｏｈｌｅなどの米国特許第６，１０１，４７７号は、旅行関連の多機能スマート・カードの方法および装置を開示する。一実施形態では、スマート・カード・システムは、カード所有者識別アプリケーションと、特に、旅行関連（例えば、航空会社、ホテル、レンタカー、および支払い関連のアプリケーション）で有用な様々な追加アプリケーションとを含む。特定のアプリケーション内のメモリ領域機能およびセキュリティ機能は、航空会社、ホテル・チェーン、およびレンタカー代理店などの提携組織にカスタム・セキュア・ファイル構造（ｃｕｓｔｏｍ ａｎｄ ｓｅｃｕｒｅ ｆｉｌｅ ｓｔｒｕｃｔｕｒｅ）を構築する能力を提供する。

２００６年３月９日に公開された、Ｐｉｉｋｉｖｉの米国特許公開第２００６／０４９２５８号は、スマート・カード読取装置に非接触インターフェースを提供する無線通信デバイスを開示する。接触スマート・カード、または端末もしくは端末セキュリティ構成要素などのスマート・カード・アプリケーション・ホストを含み、端末インターフェースを含み、またチケット発行システム内で非接触カード読取装置とのＲＦ通信を可能にするスマート・カード・ルータも含む無線端末が提供される。スマート・カード・アプリケーション・ホストは、非接触インターフェースを含まない。スマート・カード・ルータは、スマート・カード・アプリケーョン・ホストと分離し、かつその外部にあるＲＦアンテナ、ならびに変調器／復調器、そして到着する通信トラフィック内に含まれる情報に基づいて、ＲＦアンテナを経由して到着する通信トラフィックをスマート・カード・アプリケーション・ホストまたは端末インターフェースに経路付けるためのカード・アクセス・モジュールおよびルータを含む。

２００２年１０月１０日に公開された、Ｒｏｓｓの米国特許出願公開第２００２／０１４７９０７号は、特別にフォーマット設定されたスマート・カードを使用して取引処理を許可するためのシステムに関する。取引処理システムは、上位レベルのユーザ・インターフェースに関係なく、取引処理カードを認識し、取引処理カードにアクセスするために複数の店舗販売時点システムを可能にする固定データ構造の使用を含む。スマート・カードは、定義されたデータ・ファイル構造を有するメモリを含み、データ・ファイル構造は、少なくとも１つの読取り専用フィールドと、少なくとも１つの暗号化読取り／書込みフィールドと、少なくとも１つの非暗号化読取り／書込みフィールドとを含む。スマート・カードは、取引処理システム内で利用されることが可能であり、スマート・カード許可デバイスは、スマート・カード上に提供される定義されたデータ・ファイル構造と相互作用する。

２００１年８月３０日に公開された、Ｓｅｈｒの米国特許出願公開第２００１／００１８６６０号は、マルチサービスのビジター・カード（ｖｉｓｉｔｏｒ ｃａｒｄ）を利用した電子チケット発行システムおよび方法に関する。レジャー・イベントおよび娯楽イベントの入場のために、ならびにその他のカード・ベースの資格付与のために、チケット発行カードを自動的に集計、発行、利用、および処理するように、イベント主催者、入場センター、サービス・プロバイダおよびビジター集団など、複数の実体が包括される。携帯用チケット発行カードは、スマート・クレジットおよび／またはデビット・カード技術によって実現され、カード内にコンピュータ化されたチケット・テンプレートまたは電子グレジット・ポイントを記憶するための、またはカード上に予めロードされた金銭的価値もしくは特典ポイントをカードから差し引くための能力を有する。カード所有者の生体認証（ｂｉｏｍｅｔｒｉｃｓ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、ならびにカード・データおよびデータベース情報の暗号証明書は、カード内に任意選択で符号化されることが可能であり、入場のための、およびその他のサービスのためのカードの提示時に、様々なサービス時点位置で検証および確認されることが可能である。

先行技術の技法は、別個かつ連結されていない支払いインフラストラクチャおよび取引処理ならびにｅ−商品（例えば、チケット発行）インフラストラクチャおよび取引処理とを非効率的に用いる。
米国仮特許出願第６０／６９９，０１５号 オランダ特許出願第ＮＬ９３０１９０２号 米国特許第６，３７５，０８４号 米国特許第６，４０２，０３８号 米国特許第６，１０１，４７７号 米国特許公開第２００６／０４９２５８号 米国特許出願公開第２００２／０１４７９０７号 米国特許出願公開第２００１／００１８６６０号

先行技術の技法の欠陥を克服することが所望される。

本発明の原理は、支払いインフラストラクチャを使用した支払い取引処理とｅ−商品インフラストラクチャを使用したｅ−商品取引処理との効果的な組合せを可能にする技法を提供すると同時に、各インフラストラクチャが、通常、他方のインフラストラクチャの詳細な理解と組込みとを必要とせずに、その主な機能に集中することを可能にする。したがって、チケットまたはその他のｅ−商品の提供は、支払い取引処理などの取引処理に連結されることが可能である。本発明の一態様による（コンピュータ実施可能な）方法の例示的な実施形態は、財務データを取得するために第１の端末によって電子支払いデバイスの問合せを円滑にするステップと、ｅ−商品関連情報の生成を円滑にするステップと、ｅ−商品関連情報の転送を円滑にするステップとを含む。電子支払いデバイスは、電子支払いデバイスの所有者に関係する財務データと、任意選択でプロフィール・データとを取得するために、第１の端末によって問い合わせされることが可能である。電子支払いデバイスは、支払いインフラストラクチャに従って構成されることが可能である。第１の端末は、支払いインフラストラクチャに従って構成された第１の端末の支払いモジュールと、電子商品インフラストラクチャに従って構成され、かつ第１の端末の支払いモジュールに結合された第１の端末の電子商品モジュールとを有してよい。電子支払いデバイスの問合せは、第１の端末の支払いモジュールによって実行されることが可能である。

ｅ−商品関連情報の生成は、第１の端末の電子商品モジュールによって行われることが可能であり、電子支払いデバイスへのｅ−商品関連情報の転送は、第１の端末の支払いモジュールによって行われることが可能である。ｅ−商品関連情報の転送は、財務データと支払いインフラストラクチャとに従って実行される取引処理内で行われる。オプションのプロフィール・データが取得される場合、ｅ−商品関連情報はそのプロフィール・データに基づいて生成されてよい。

もう１つの態様では、統合支払い・電子商品転送（ｉｎｔｅｇｒａｔｅｄ ｐａｙｍｅｎｔ ａｎｄ ｅｌｅｃｔｒｏｎｉｃ ｍｅｒｃｈａｎｄｉｓｅ ｔｒａｎｓｆｅｒ）のための端末の例示的な実施形態は、支払いモジュールと、支払いモジュールに結合された電子商品モジュールとを含んでよい。支払いモジュールは、支払いインフラストラクチャに従って構成されることが可能であり、電子商品モジュールは、電子商品インフラストラクチャに従って構成されることが可能である。モジュールは、上で説明されたステップを円滑にするために構成され得る。

本発明のもう１つの態様による（カードまたは適切に構成されたセルラー電話などの）電子支払いデバイスの例示的な実施形態は、メモリと、メモリに結合された少なくとも１つのプロセッサを含んでよい。プロセッサは、本明細書で説明される１つまたは複数の方法ステップの実行を円滑にするために動作可能であってよい。本発明の１つまたは複数の方法ステップは、実行されると、かかる１つまたは複数のステップを実施する１つまたは複数のプログラムを含む機械可読媒体を含む製品の形で実施されてよい。

本発明の１つまたは複数の技法は、１つまたは複数の以下の実質的に有利な技術効果を提供することが可能である。これらの技術効果は、機能の分離と各々の責任とを依然として遵守しながら、例えば、電子支払いおよびチケット発行など、例えば、別個のインフラストラクチャの密結合を可能にすることを含んでよい。さらに、もう１つの態様では、本発明の１つまたは複数の技法は、既存の支払いプロトコルを交換するのではなく、拡張が既存の支払いインフラストラクチャのその他の部分と互換性があるような方法で拡張することを可能にする。しかもさらに、下でより完全に議論されるＥＭＶ支払い基準に適合する例示的な実施形態では、支払いカード・アプリケーションは、すべての関連するオープン・スタンダードに依然として準拠し、関連するタイプの承認プロセスが依然として適用可能である。

なおさらに、もう１つの態様では、支払いとデータ処理および／または記憶機能とを密結合することによって、クレジット・カード支払いなどのオープン・スキーム（ｏｐｅｎ ｓｃｈｅｍｅ）支払いの拡張は、伝統的にチケットまたは前払い輸送カードなどのクローズド・スキーム（ｃｌｏｓｅｄ ｓｃｈｅｍｅ）だけが受け入れられている環境内で円滑にされることが可能である。所望される場合、支払いとデータ処理および／または記憶とは、支払いカード上の単一のアプリケーション内で実施されることが可能でるため、取引処理時間および複雑さは大幅に削減され得る。特に、支払いとデータ処理および／または記憶とに別個のカード・アプリケーションを用いる場合とは対照的に、そして、特に、大量輸送のチケット発行および支払いなどの高速非接触操作のために、取引処理時間は先行技術の技法と比べてかなり削減され得る。しかもさらに、単一のカード・アプリケーションだけが管理されればよく、複数の電子商品アプリケーションは変更なしにサポートされることが可能であるため、カード管理プロセスの複雑さはかなり削減され得る。なおさらに、チケット発行およびその他のｅ−商品処理は支払いサイドを「理解する」必要がなく、支払い処理はｅ−商品機能性を「理解する」必要がない（すなわち、各サイドの機能性は実質的に依然として修正されなくてよい）ため、端末の複雑さが削減され得る。さらに別の態様では、本発明の１つまたは複数の技法は、支払い取引処理と、旅行許可などのｅ−商品の引渡しとが密接に結ばれ、したがって、引渡しを伴わない支払いまたは支払いを伴わない引渡しのリスクを最低限に抑えるように、そして、同じｅ−商品のための複数の支払いまたは単一の支払いのための商品の意図されない複数の引渡しが、一般に、回避され得るように、支払いと電子商品の引渡しとを単一のステップ内に組み合わせることを可能にすることができる。
本発明のこれらのおよびその他の特徴および利点は、添付の図面と共に読まれるべきであるその例示的な実施形態の以下の詳細な説明から明らかになるであろう。

次に、システムの様々な可能な構成要素と共に、システム１００の例示的な実施形態を示す図１に注目されたい。システム１００は、本発明の技法を実施することが可能であり、異なるタイプの携帯用支払いデバイスを含んでよい。例えば、１つのかかるデバイスは、カード１０２などのうちの１つもしくは複数の接触デバイスであってよい。カード１０２は、プロセッサ部分１０６とメモリ部分１０８とを有する集積回路（ＩＣ）チップ１０４を含んでよい。複数の電気接触１１０が通信目的で提供されてよい。カード１０２に加えて、またはその代わりに、システム１００は、カード１１２などの非接触デバイスと共働するように設計されてもよい。カード１１２は、プロセッサ部分１１６とメモリ部分１１８とを有するＩＣチップ１１４を含んでよい。アンテナ１２０は、例えば、無線周波数（ＲＦ）電磁波を使用するなど、非接触通信のために提供されてよい。１つまたは複数の発振器、および／または変調、復調、ダウンコンバージョンなどのうち１つもしくは複数のために追加の適切な回路が提供されてもよい。カード１０２、１１２は、本発明の技法と共に用いられることが可能な様々なデバイスの例である点に留意されたい。本発明の１つまたは複数の実施形態では、デュアル・インターフェース・デバイス１３０２が用いられる。デバイス１３０２は、例示的な便宜上、デバイス１０２、１１２よりも大きく示されるが、類似のフォーム・ファクタ（ｆｏｒｍ ｆａｃｔｏｒ）を有してもよい。デバイス１３０２は、プロセッサ部分１３０６とメモリ部分１３０８とを有するＩＣチップ１３０４を含む。デバイス１１２に関して説明されたように、１つまたは複数の発振器、および／または変調、復調、ダウンコンバージョンなどのうちの１つもしくは複数のための追加の適切な回路と共に、接触１１０に類似した複数の電気接触１３１０、ならびにアンテナ１２０に類似したアンテナ１３２０が提供されてよい。その他の点ではデバイス１０２、１１２に類似している動作を有する、２つの利用可能なインターフェースを管理するための適切なファームウェアが提供されてよい。本明細書を通じて、デバイス、要素、または構成要素１０２、１０４、１０６、１０８、１１０、１１２、１１４、１１６、１１８、１２０の記述は、対応する項目１３０２、１３０４、１３０６、１３０８、１３１０、１３２０に等しく適用可能である。メモリ１０８、１１８、１４８（下で議論される）および１３０８は、不揮発性メモリと揮発性メモリとにさらに分割されてよい。

ＩＣ １０４、１１４は、処理ユニット１０６、１１６と、メモリ・ユニット１０８、１１８とを含んでよい。好ましくは、ＩＣ １０４、１１４は、制御論理と、タイマと、入出力ポートのうちの１つまたは複数とを含んでもよい。かかる要素は、ＩＣ技術分野でよく知られており、別個に例示されない。ＩＣ １０４、１１４のうちの１つまたは両方は、やはりよく知られており、別個に例示されないコプロセッサを含んでもよい。制御論理は、処理ユニット１０６、１１６と共に、メモリ・ユニット１０８、１１８と入出力ポートの間の通信を処理するために必要な制御を提供することが可能である。タイマは、処理ユニット１０６、１１６と制御論理とからタイミング基準信号を提供することが可能である。コプロセッサは、暗号アルゴリズムによって要求されるものなど、リアルタイムで複雑な演算を実行する能力を提供することが可能である。

メモリ部分すなわちユニット１０８、１１８は、揮発性メモリおよび不揮発性メモリならびに読取り専用メモリおよびプログラム可能メモリなど、異なるタイプのメモリを含んでよい。メモリ・ユニットは、例えば、ユーザのプライマリ・アカウント番号（ｐｒｉｍａｒｙ ａｃｃｏｕｎｔ ｎｕｍｂｅｒ）（「ＰＡＮ」）など、取引処理カード・データを記憶することが可能である。メモリ部分すなわちユニット１０８、１１８は、カード１０２、１１２のオペレーティング・システムを記憶することが可能である。オペレーティング・システムは、アプリケーションをロードおよび実行し、ファイル管理またはその他の基本的なカード・サービスをアプリケーションに提供する。いくつかの実施形態では、１つまたは複数のアプリケーションは、ハードウェア上に直接「座し」てよい（例えば、オペレーティング・システムのドメインの外部であってよい）。本発明を実施するために使用され得る１つのオペレーティング・システムは、ＳｔｅｐＮｅｘｕｓ Ｉｎｃ．によって認可されたＭＵＬＴＯＳ（登録商標）である。あるいは、（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．，４１５０ Ｎｅｔｗｏｒｋ Ｃｉｒｃｌｅ，Ｓａｎｔａ Ｃｌａｒａ，ＣＡ ９５０５４ ＵＳＡによって認可された）ＪＡＶＡ（登録商標） ＣＡＲＤ（商標）技術に基づいたＪＡＶＡ（登録商標） ＣＡＲＤ（商標）ベースのオペレーティング・システム、またはいくつかのサプライヤーから利用可能な専有オペレーティング・システムが用いられてよい。好ましくは、オペレーティング・システムは、メモリ部分１０８、１１８内の読取り専用メモリ（「ＲＯＭ」）内に記憶される。代替の実施形態では、フラッシュ・メモリあるいはその他の不揮発性および／または揮発性タイプのメモリがメモリ・ユニット１０８、１１８内で使用されてもよい。

オペレーティング・システムによって提供される基本的なサービスに加えて、メモリ部分１０８、１１８は、本明細書で説明される１つまたは複数のアプリケーションを含んでもよい。現在、かかるアプリケーションが適合できる１つの好ましい基準は、ＥＭＶＣｏ，ＬＬＣ（ｈｔｔｐ：／／ｗｗｗ．ｅｍｖｃｏ．ｃｏｍ）によって公にされたＥＭＶ支払い基準である。厳密に言えば、ＥＭＶ基準は端末の行動様式を定義するが、カードは、かかるＥＭＶ準拠する端末行動様式に従うように構成されてよく、その意味で、それ自体ＥＭＶ準拠である点を理解されよう。本発明によるアプリケーションは様々な異なる方法で構成されてよい点も理解されよう。

言及されたように、カード１０２、１１２は、本発明の技法と共に用いられることが可能な様々な支払いデバイスの例である。支払いデバイスの主な機能は支払いでなくてもよく、例えば、本発明の技法を実施する、セルラー電話ハンドセット、または公共交通機関用のアクセス・カードである可能性がある。かかるデバイスは、通常のフォーム・ファクタを有するカード、より小さなまたはより大きなカード、異なる形状のカード、キー・フォブ（ｋｅｙ ｆｏｂｓ）、携帯情報端末（ＰＤＡ）、適切に構成されたセル電話ハンドセット、あるいは実際に、本発明の技法を実施するための処理能力およびメモリ能力を有するいかなるデバイスを含んでもよい。カード、またはその他の支払いデバイスは、メモリ１０８、１１８と、メモリに結合されたプロセッサ１０６、１１６とを含んでよい。任意選択で、ボディ部分（例えば、支払いカードの積層プラスチック層、ＰＤＡのケースまたはキャビネット、チップ・パッケージングなど）は、メモリ１０８、１１８とプロセッサ１０６、１１６とに関連づけられる。メモリ１０８、１１８は、本明細書で説明されるアプリケーションを含んでよい。プロセッサ１０６、１１６は、本明細書で説明されることになる１つまたは複数の方法ステップを実施するために動作可能であってよい。アプリケーションは、電気的に消去可能でプログラム可能な読取り専用メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）（ＥＥＰＲＯＭ）など、例えば、ファームウェアにカード・メモリ内のデータを加えた形でソフトウェア・コードに連結されたアプリケーション識別子（ＡＩＤ）であってよい。

いくつかの異なるタイプの端末がシステム１００と共に用いられてよい。かかる端末は、接触タイプのデバイス１０２とインターフェースを取るように構成された接触端末１２２、無線デバイス１１２とインターフェースを取るように構成された無線端末１２４、または組合せ端末１２６を含んでよい。「非接触」および「無線」は、本明細書で交換可能な形で使用され、当業者はかかる専門用語の意味に精通している点に留意されたい。組合せ端末１２６は、デバイス１０２、１１２のどちらのタイプともインターフェースを取るように設計される。端末は、差込み式の非接触読取装置を有する接触端末であってよい。組合せ端末１２６は、メモリ１２８と、プロセッサ部分１３０と、読取装置モジュール１３２とを含んでよい。端末１２６の構成の原理は、その他のタイプの端末に適用可能であり、例示的な目的で詳しく説明される点に留意されたい。読取装置モジュール１３２は、カードすなわちデバイス１０２との接触通信、またはカードすなわちデバイス１１２との非接触通信、またはその両方のために構成されてよい（異なるタイプのカード（例えば、接触または非接触）と相互作用するために異なるタイプの読取装置が提供されてよい）。端末１２２、１２４、１２６は、コンピュータ・ネットワーク１３８を経由して処理センター１４０に接続されることが可能である。ネットワーク１３８は、例えば、インターネット、または専有ネットワークを含んでよい。処理センター１４０は、例えば、支払いデバイスのイシュア（ｉｓｓｕｅｒ）のホスト・コンピュータを含んでよい。１つまたは複数の識別可能なネットワークが用いられてよい。下で議論されるように、本発明の端末は、電子商品モジュールに結合された支払いモジュールを有してよく、モジュールはソフトウェア、ファームウェア、および／またはハードウェアで実施されてよい。１つまたは複数の実施形態では、モジュールは、同じプロセッサ上で実行されるソフトウェア・モジュールであってよい。

独立型の端末１３４は、コンピュータ・ネットワークに接続されていない（設計によって、特定の時間に接続されない、またはまったく接続されない）端末を表し、その他の点では、説明されるその他の端末と一般的に類似する。

適切に構成されたセルラー電話ハンドセット１４２もシステム１００内で用いられることが可能である。ハンドセット１４２は、図１で、半概略形態で示され、処理ユニット１４６とメモリ・ユニット１４８とを含むチップ１４４など、１つまたは複数のＩＣチップを含んでよい。端末との無線通信は、アンテナ１５０を経由して、または上述のアンテナ１２０に類似した第２のアンテナ１８０を用いて提供されることが可能である（すなわち、ハンドセットは、支払いアプリケーションのために第２のアンテナを有してよい）。アンテナ１８０は概略的に示されるが、例えば、典型的な「スマート」カードで使用されるようなコイル・アンテナであってもよい。ハンドセット１４２は、各々、適切なディスプレイ１５６が装備されてよい。さらに、適切な電源装置１６２も提供されてよい。かかる電源装置は、例えば、電池と適切な回路とを含んでよい。ディスプレイおよび電源装置は、プロセッサ部分と相互接続されてよい。異なるタイプの携帯用支払いデバイスは、図１で例示的なデバイスに上に示された１つまたは複数の機能を組み合わせてよく、または「ミックス・アンド・マッチ（ｍｉｘ ａｎｄ ｍａｔｃｈ）」してよい。

本発明の一態様では、システム１００などのシステムの１２２、１２４、１２６、１３４などの端末を有するユーザによる取引処理を円滑にするために、携帯用であってよい電子支払いデバイスが提供される。デバイスは、プロセッサ（例えば、上で議論された処理ユニット１０６、１１６、１４６）を含んでよい。デバイスはまた、上で議論されたメモリ部分１０８、１１８、１４８など、プロセッサに結合されたメモリを含んでよい。さらに、デバイスは、プロセッサに結合され、端末１２２、１２４、１２６、１３４のうちの１つなどの端末とインターフェースを取るように構成された通信モジュールを任意選択で含んでよい。通信モジュールは、接触通信または無線通信を経由して端末とインターフェースを取ることを可能にする（前述の１つまたは複数の発振器および関連する回路などの）適切な回路と共に、例えば、接触１１０またはアンテナ１２０、１５０、１８０を含んでよい。装置のプロセッサは、本明細書で説明される方法の１つまたは複数のステップおよび技法を実行するために動作可能であってよい。プロセッサは、ハードウェア技法を経由して、かつ／またはメモリ・ユニットのうちの１つの中に記憶されたプログラム命令の影響を受けて、かかる動作を実行することができる。携帯用デバイスは、ボディ部分を含んでよい。例えば、これは、「スマート」カード１０２、１１２の場合、（上で議論された）積層プラスチック・ボディであってよく、またはハンドセット１４２の場合、ハンドセット・シャシおよびボディであってよい。

端末１２２、１２４、１２６、１３４は、本発明の１つまたは複数の例示的な実施形態に従って携帯用支払いデバイスと相互作用するための端末装置の例である点を理解されよう。装置は、例えば、プロセッサ１３０などのプロセッサ、プロセッサに結合されたメモリ１２８などのメモリおよびプロセッサに結合され、携帯用装置１０２、１１２、１４２とインターフェースを取るように構成された１３２などの通信モジュールを経由して実施される前述の支払いモジュールおよび電子商品モジュールを含んでよい。プロセッサ１３０は、通信モジュール１３２を経由してユーザの携帯用支払いデバイスと通信するために動作可能であってよい。端末装置は、プロセッサ１３０内のハードウェア技法を経由して、またはメモリ１２８内に記憶されたプログラム命令によって機能することが可能である。かかる論理は、ネットワーク１３８を経て処理センター１４０などの中枢の位置から任意選択で提供され得る。

上述のデバイス１０２、１１２は、好ましくは、ＩＳＯ８７１６準拠する接触カードもしくはデバイスまたはＮＦＣ（近距離無線通信（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ））あるいはＩＳＯ１４４４３準拠の近接型（ｐｒｏｘｉｍｉｔｙ）カードもしくはデバイスである。動作中、カード１１２は、端末１２４または１２８上で接触または押下されてよく、次いで、端末１２４または１２８は非接触で電子データをカード１１２またはその他の無線デバイス内の近接型ＩＣチップに送信する。

図２は、本発明の一態様による、制御されたアクセス・システムに対する本発明の技法の例示的な応用を示す。システム２００は、例えば、運搬用車両、１つまたは複数の鉄道駅またはバス・ターミナルを含む完全な交通機関のインフラストラクチャ、遊園地、博物館などであってよい。システム２００は、入口地点２０２と出口地点２０４を有してよい。第１の端末２０６は、入口地点２０２に隣接して配置されてよく、第２の端末２０８は、出口地点２０４に隣接して配置されてよい。複数の入口地点および出口地点が存在する可能性があり、各々に適切な端末が提供されてよい点を理解されよう。端末２０６などの端末は、電子商品インフラストラクチャと関連し、かつ、デバイス２１０など、支払いインフラストラクチャに従って構成された電子支払いデバイスと共に、支払いインフラストラクチャを経由して統合支払い・電子商品転送のために構成されることが可能である。デバイス２１０は、例えば、接触カード、非接触カード、セル電話、または上で説明されたその他のデバイスであってよい。

端末２０６は、支払いインフラストラクチャに従って構成され、財務データを取得するために電子支払いデバイス２１０に問い合わせるようにも構成された支払いモジュール２１２を含んでよい。さらに、端末２０６は、電子商品インフラストラクチャに従って構成され、支払いモジュール２１２に結合された電子商品モジュール２１４を含んでよい。電子商品モジュール２１４は、ｅ−商品関連情報（例えば、チケット発行情報）の処理を円滑にするように構成されてよい。支払いモジュール２１２は、財務データと支払いインフラストラクチャとに従って実行される取引処理において、電子支払いデバイス２１０へのｅ−商品関連情報の転送を円滑にするようにさらに構成されてよい。支払いモジュールは、非接触通信のためのアンテナ２１６を含んでよい（当技術分野でよく知られており、上で議論されたものに類似した適切な変調および変換回路が含まれてもよい）点に留意されたい。さらに、支払いモジュールは、接触カード用の読取装置、２１８を含んでよい。読取装置２１８およびアンテナ２１６は、別個の実体であってよく、または、所望される場合、端末２０６（例えば、その支払いモジュール２１２）と一体化されてもよい。支払いモジュール２１２および電子商品モジュール２１４は、ネットワーク接続２２０、２２２を有してよい。所望される場合、単一ネットワーク接続が提供されてよい点を理解されよう。接続は、図１に関して上で説明された任意のタイプのネットワークに対するものであってよく、所望される場合、異なるモジュールが同じまたは異なるネットワークに接続されてよい。端末２０８の要素２２４、２２６、２２８、２３０、２３２、２３６は、端末２０６の対応する要素２１２、２１４、２１６、２１８、２２０、２２２と同じように機能してよい。

１つまたは複数の実施形態では、支払いモジュール２１２は、それ自体がネットワークに接続されなくてよく、ネットワーク通信は商品モジュール２１４を経由して達成されてよい。さらに、１つまたは複数の実施形態では、カードまたはその他の支払いデバイスとの通信は、支払いモジュール２１２によって処理され、カードと商品モジュール２１４の間で引き渡される必要のある任意のデータは、（接触カードおよび非接触カードの両方に関して）支払いモジュール２１２によって処理される。

当業者の理解を助けるための例として、支払いインフラストラクチャの一例は、ＥＭＶインフラストラクチャ、すなわち、イシュア、アクワイアラ（Ａｃｑｕｉｒｅｒ）、販売店に関して、ＭａｓｔｅｒＣａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｉｎｃ．によって操作されるものなど、ＥＭＶを組み込んだ支払いシステムである。さらに、支払いインフラストラクチャの一例は、自動料金収集（ＡＦＣ）システムである。

任意選択で、支払いモジュール２１２は、電子支払いデバイスの所有者に関係するプロフィール・データを取得するために、電子支払いデバイス２１０に問い合わせるようにさらに構成されてよい。この場合、第１の端末２０６の電子商品モジュール２１４は、プロフィール・データに基づいてｅ−商品関連情報を処理するように構成されてよい。ｅ−商品関連情報の処理は、ｅ−商品関連情報の生成、読取りおよび／または更新を含んでよい。異なるタイプのｅ−商品モジュール２１４が可能である点を理解されよう。例えば、チケット自動販売機などのｅ−商品を生成するだけのいくつかのｅ−商品モジュールが存在する可能性があり、ｅ−商品を読み取るだけのいくつかのｅ−商品モジュール（例えば、列車の車掌もしくはその他の検札係の携帯用デバイス）が存在する可能性があり、ｅ−商品を更新するだけのいくつかのｅ−商品モジュール（例えば、チケット確認機械）が存在する可能性がある。さらに、前述のいくつかまたはすべてを任意の組合せで行う組合せモジュールが存在する可能性がある。例として、本発明の多くの態様は、例えば、交通機関のチケット発行システムに関して例示される点を重視されたい。しかし、これは単に例示であり、本発明の技法は、例えば、遊園地、博物館などへのアクセス制御など、支払いおよびｅ−商品インフラストラクチャの統合が有利になる場合には、多くの用途で用いられることが可能である。

説明されるモジュール２１２、２１４、２２４、２２６は、例えば、２つの物理的に別個のデバイス、２つの離散的サブデバイスを含む単一のデバイス、２つの離散的仮想デバイス（すなわち、ソフトウェア・モジュール）を含む単一のデバイス、および両方の仕事を行う単一の完全統合デバイスを含んでよい。

次に、本発明の態様による、例示的な方法ステップの流れ図３００を表す図３に注目されたい。コンピュータ実施され得る方法は、電子商品インフラストラクチャに関連して支払いインフラストラクチャを経由して統合支払い・電子商品転送のために用いられることが可能である。ｅ−商品は、上で説明された種類のものであってよい。ブロック３０２で開始後、ブロック３０４は、財務データを取得するために第１の端末によって電子支払いデバイスの問合せを円滑にすることを含む。財務データは、例えば、電子支払いデバイスのアカウント番号であってよい。電子支払いデバイスは、支払いインフラストラクチャに従って構成されてよく、図２に関して上で説明されたように、第１の端末は、支払いモジュールと電子商品モジュールとを有してよい。電子支払いデバイスの問合せは、第１の端末の支払いモジュールによって実行されてよい。任意選択で、問合せを円滑にするステップ３０４で、電子支払いデバイスの所有者に関係するプロフィール・データが取得されてよい。本明細書で使用されるように、活動を「円滑にすること」は、活動を実行すること、活動を容易にすること、活動を実行するのを助けること、または活動を実行させることを含む。したがって、限定ではなく例として、１つのプロセッサ上で実行される命令は、活動を実行させるためにもしくはそれを助けるために適切なデータまたはコマンドを送ることによって、遠隔プロセッサ上で実行される命令によって実行される活動を円滑にすることが可能である。

言及されたように、財務データは、例えば、支払いデバイスに関連するアカウント番号であってよい。限定ではなく例として、プロフィール・データは、その人物が低料金を受ける資格を有する学生または高齢者であるという事実などの情報を含んでよい。さらに、プロフィール・データの２つ以上の範疇が提供されてよい。例えば、１つの範疇は、高齢者または学生の地位など、チケット発行プロフィール・データを含んでよい。さらに、カード会員プロフィール・データが提供されてもよい。かかるデータは、取引処理のために必要とされない場合がある。これは、例えば、カード会員がいつどこで加入したか、衣類のサイズなどの個人情報などを含んでよい。プロフィール・データが取得される場合、ｅ−商品関連情報は、そのプロフィール・データに基づいて第１の端末の電子商品モジュールによって生成され得る。

オプションのステップ３０６が下で議論される。ステップ３０８は、第１の端末の電子商品モジュールによってｅ−商品関連情報の生成を円滑にすることを含んでよい。かかる情報は、例えば、チケット発行情報を含んでよい。オプションのステップ３１０から３１６が下で議論される。ステップ３１８は、財務データと支払いインフラストラクチャとに従って実行される取引処理内で、第１の端末の支払いモジュールを経由して、電子支払いデバイスへのｅ−商品関連情報の転送を円滑にすることを含んでよい。１つまたは複数の実施形態では、取引処理は支払い取引処理であってよい。しかし、取引処理はゼロ値に関してであってよく、かつ／または完全な支払い取引処理の流れのサブセットだけであってよい点を理解されたい。

言及されたように、ステップ３０４で、任意選択で取得され得るプロフィール・データは、クラス会員資格に関連する複数の資格付与範疇のうちの１つまたは複数を有するクラスの会員として電子支払いデバイスの所有者を識別する情報を含んでよい。資格付与範疇は電子商品に関連してよい。例えば、かかる範疇は、割引または特典に対する資格付与を含んでよい。言及されたように、１つの例示的な実施形態では、資格付与の範疇は、運賃範疇を含んでよく、ｅ−商品関連情報は輸送チケット情報を含んでよい。

言及されたように、本発明の技法は、制御されたアクセス・システムへの入場および／または制御されたアクセス・システムからの退場を制御するために使用されることが可能である。場合によっては、システムへの入場だけに関心がある可能性がある。これは、例えば、博物館もしくは遊園地への入場など、または任意の２つの駅の間で乗客に単一の料金が請求される、ニューヨークの地下鉄システムなどの大量輸送システムにおいて、アクセスに対して単一の固定料金が請求される場合に適切な可能性がある。しかし、その他の用途では、退場も制御し、かつ／またはチケットもしくは費用の情報を入口地点と出口地点の両方に連結することが所望される場合がある。これは、例えば、ロンドンの地下鉄またはワシントン市のメトロなどのシステムに対応できる。したがって、説明されたステップは、制御されたアクセス・システムへの所有者の入場に関して実行されることが可能であり、かかる場合、ステップ３０８および３１８のｅ−商品関連情報は、当初入場地点情報を含んでよい。したがって、図２の端末２０６など、第１の端末は、この場合、入口端末と考えることができる。この場合、追加ステップは、ステップ３２０、すなわち、システムからの所有者の退場時に、システム入場地点情報を取得するために、出口端末による電子支払いデバイスの問合せを円滑にすることを含んでよい（出口端末は、その独自の位置（すなわち、システム出口位置）を本質的にすでに「知っている」）。出口端末は、例えば、図２の端末２０８であってよい。ステップ３２２は、制御されたアクセス・システムの入場地点情報と制御されたアクセス・システムの退場地点情報（例えば、出口端末の位置）とに基づいて、出口端末の支払いモジュールを経由して、チケットを所有者に提供することおよび所有者に料金を請求することのうちの１つまたは複数を円滑にすることを含んでよい。ステップ３２２（または、本明細書の他の場所で）提供されるチケットは、電子チケット、物理的チケット、オプションのチケットなどであってよい点を理解されよう。

１つまたは複数の実施形態では、入口端末および出口端末２０６、２０８は、異なってよい。例えば、地下鉄、メトロ、または地下システムなどの交通機関システムでは、第１の端末、すなわち入口端末２０６は人物が電車に乗った駅に位置されてよく、第２の端末、すなわち出口端末２０８は人物が電車を降りた駅に位置されてよい。しかし、入口端末と出口端末とは、実際に、同じ端末でありえる可能性がある。これは、例えば、料金が、人物が移動する距離に依存するバスに関して発生する場合がある。入口端末と同じであることになる出口端末は、例えば、全地球測位システム（ＧＰＳ）またはその他の適切な技術によって人物がどれだけ移動したかに関する情報を取得してもよい。図３で示された方法と共に用いられる電子支払いデバイスは、例えば、非接触無線周波数（ＲＦ）近接型カード、接触カード、または非接触無線周波数（ＲＦ）と接触インターフェースの両方を有するデュアル・インターフェース・カードであってよい。さらに、デバイスは、例えば、セルラー電話、ＰＤＡ、キー・フォブなど、非カード形態要因を有してもよい。要求されることは、端末とインターフェースを取るために適切な能力が存在することだけである。

１つまたは複数の例示的な実施形態では、不正または不当使用の機会を最低限に抑えるために、適切なセキュリティ機能を提供することが所望される場合がある点を理解されよう。特定の例が、次に、チケット発行アプリケーションという状況に関して提供されることになる。チケットに関してオープン・データ記憶装置が使用される場合、カードまたはその他のデバイスは、データ記憶装置に関して、任意のセキュリティ・サービスをチケット発行アプリケーションに提供することはできない。この場合、チケット発行アプリケーションは、スキミング（すなわち、チケットをもう１枚のカードにコピーすること）またはリプレイなどの攻撃に対処する必要があることになる。しかし、その他の実施形態では、カードまたはその他のデバイスは、適切なセキュリティ・サポートを提供することが可能である。１つの方法は、攻撃を防止するために、データ書込みコマンドと共に、データ書込み（ＰｕｔＤａｔａ）オペレーション内のアプリケーション取引処理カウンタ（ＡＴＣ）などの取引処理カウンタを用いることであろう。この例は前述のＥＭＶ仕様という状況に関して提供される点に留意されたい。当業者は、本出願内に提示された教示を手にして、この例をその他のタイプのシステムおよび基準に容易に適合させることが可能であろう。

より具体的には、読取装置（端末の読取部分）は、ＡＴＣおよびプライマリ・アカウント番号（ＰＡＮ）を要求することができる。チケット発行モジュールは、チケット発行モジュールが計算するメッセージ認証コード（ＭＡＣ）内にＡＴＣとＰＡＮとを含むことができ、データ書込みコマンドを使用して、これをカードまたはその他のデバイスに引き渡すことが可能である。データ書込みコマンドは、ＰＡＮとＡＴＣとがその現在の値に一致しない限り、そのデータの記憶を受け入れることを拒絶することになる。これは、カード所有者による合法カード上へのリプレイを停止することになる。さらに、ＥＭＶ内に存在する組合せデータ認証（ＣＤＡ）機能と共にＰＡＮを使用することは、「スキミング」の機会、すなわち、誰かがもう１枚のカードから有効なチケット・データを読み取り、それを自分のカード上にコピーしようとする機会を削減または除去できる。ＭＡＣはＰＡＮを含み、かつＰＡＮはＣＤＡによって署名されるため、支払いモジュールはその不正な試みを検出し、取引処理を拒絶することができる。

図３を参照すると、セキュリティ技術を実施することが所望される場合、オプションのステップ３０６は、第１の端末によって、例えば、前述のＡＴＣおよびＰＡＮなど、取引処理カウンタおよびアカウント番号を取得するために電子支払いデバイスの問合せを円滑にすることを含んでよい。ステップ３１０は、取引処理カウンタとアカウント番号とを使用して、認証コードの計算を円滑にすることを含んでよく、コードは、例えば、ＭＡＣであってよい。ステップ３１２は、電子支払いデバイスから取得された取引処理カウンタとアカウント番号とが認証コード内に含まれた取引処理カウンタとアカウント番号とに一致するかどうかの決定を円滑にすることを含んでよい。ブロック３１２の「いいえ」分岐によって示されるように、これらが一致しない場合、ブロック３１６で示されるように、電子支払いデバイスによる認証コードの記憶の拒絶が円滑にされ得る。かかる拒絶は、電子支払いデバイスから取得された取引処理カウンタとアカウント番号とが認証コード内に含まれた取引処理カウンタとアカウント番号とに一致しないことを明らかにする決定ステップに対応する。これらのステップを実施することは、リプレイの不正の可能性を削減できる。ブロック３１２の「はい」分岐によって示されるように、一致が受け入れられる場合、任意選択で、アカウント番号と、取引処理に関連する独自のデータ認証署名（例えば、組合せＤＤＡ／ＡＣ生成（Ｃｏｍｂｉｎｅｄ ＤＤＡ／ＡＣ Ｇｅｎｅｒａｔｉｏｎ）として知られており、より一般に「ＣＤＡ」と呼ばれるＥＭＶ署名方法）とに基づいて、スキミング検出が決定ブロック３１４で円滑にされ得る。したがって、リプレイ（これまでの合法チケット発行データを元のカードにコピーし戻す試み）の機会、およびスキミング（合法チケット発行データをもう１つの正式なまたは不正なカード上にコピーする試み）の機会は、実質的に削減または除去されることが可能である。リプレイおよびスキミングの防止ステップは、任意の順序で実行されてよく、一緒に実行されなくてもよく、これらのうちのどちらかもしくは両方が実行されてよく、または実行されてなくてもよい点を理解されよう。実際には、一般に、図３で示されるステップは、任意の適切な順序で実行されてよく、任意の特定の状態では、すべてのステップが実行されなくてもよい。拒絶がブロック３１６で生成されると、処理はブロック３２４を続けるために進む。

セキュリティ強化に対する多くの可能な手法を例示するもう１つの手法では、ステップは、ＡＴＣなどの取引処理カウンタと、カードＩＤなどの電子支払いデバイス識別子と、ＲＮＤなどの電子支払いデバイス生成された乱数とを取得するために第１の端末によって電子支払いデバイスの問合せを円滑にすることと、ｅ−商品関連情報と、取引処理カウンタと、電子支払いデバイス識別子と、電子支払いデバイス生成された乱数とに基づいてＭＡＣなどの認証コードの計算を円滑にすることとを含んでよい。これらのステップは、電子支払いデバイス識別子に対するｅ−商品関連情報の連結に基づいて、取引処理カウンタと支払いデバイス生成された乱数とを経由してリプレイの不正の検出を円滑にすること、ならびにスキミング検出を円滑にすることを可能にする。さらなる詳細は、図７および図８に関して下で提供される。

レビューとして、本発明の１つまたは複数の実施形態は、支払いインフラクストラクチャおよび／またはとｅ−商品インフラクストラクチャおよび／または取引処理とを組み合わせるための技法を提供することが可能であると同時に、他方のインフラストラクチャの詳細な理解と組込みとをわずかに必要として、またはまったく必要とせずに、各インフラストラクチャがその主な機能に集中することを可能にする。したがって、１つまたは複数の態様では、本発明はデータ処理オペレーションを、支払い取引処理などの取引処理に組み込むための技法を提供することができる。１つの特定の例示的な実施形態では、支払い取引処理は前述のＥＭＶ基準を用いる。

したがって、本発明の技法は、支払い取引処理など、取引処理内で非支払いデータの処理を可能にする。１つまたは複数の例示的な実施形態では、データ処理は、かかる取引処理内で実行されることが可能である。図２に関して議論されたように、端末はｅ−商品モジュールと支払いモジュールとを含んでよい。これらは別個のハードウェア・モジュールまたは別個のソフトウェア・モジュールとして実施されてよい。１つまたは複数の実施形態では、２つの別個のアプリケーションが提供される。１つはチケット発行などのｅ−商品に関し、もう１つは支払いに関する。カードなどのデバイスは、支払い部分とどのようにインターフェースを取るかを「知る」必要だけがある。チケット発行などのｅ−商品データは、支払いアプリケーションまたはその他のタイプの支払いモジュールを介してカードまたはその他のデバイスに伝達されることが可能である。適切なチケット発行データまたはその他のｅ−商品データは、カードまたはその他のデバイス上に記憶され得るが、支払いインフラストラクチャを使用することはカード上に事前に存在している。１つまたは複数の実施形態では、既存の支払いインフラストラクチャは、前述のＥＭＶ仕様に従ってよい。標準ＥＭＶコマンドは、ｅ−商品データなど、非支払いデータを移動するために使用され得る。しかし、カードまたはその他の支払いデバイスは、後方互換性があるように作成されることが可能であり、その結果、通常の購入取引処理に容易に用いられることが可能である。ＥＭＶフレームワーク内での本発明の技法の応用を示すさらなる特定の例は、図４〜図６に関して提示される。

図４〜図８の以下の議論で、「読取装置」は、要素２１６および／または２１８を有する支払いモジュール２１２などの要素を包括し、一方、「端末」は、ｅ−商品モジュール２１４などの要素を包括する。図４は、支払いが入口で行われることになる取引処理の流れにおける制御されたアクセス・システムの入口での例示的な方法ステップを示す。ステップは、本発明の適切な修正と実施技法を用いて、前述のＥＭＶ基準という状況に関して説明される。技法は非接触アプリケーションと接触アプリケーションの両方に適用可能である。流れ図４００のステップ４０２で示されるように、活動化要求はチケット発行アプリケーションから支払いアプリケーションに送付されることが可能である。適切なカード・ポーリング（ｃａｒｄ ｐｏｌｌｉｎｇ）および活動化シーケンスは、ステップ４０４で実行され得る。ステップ４０６で決定されるように、無効カードまたは複数のカードが存在する場合、カード非活動化シーケンスがステップ４０８で実行されることが可能であり、ブロック４１０で（何かが失敗したことを端末に通知する読取装置に対応して）「ＮＡＫ」記号が読取装置から端末に送信されることが可能である。

単一のカードが存在する場合のみ、読取装置はアプリケーション選択を実施することになり、カード上の適切なアプリケーションがブロック４１２で選択される。次いで、ブロック４１４で、データがカードから読み取られる。かかるデータは、チケット発行プロフィール、ならびに差引残高などのプロフィール情報を含んでよい。「いいえ」分岐でのように、複数のカードが存在する場合、４０８で、読取装置は除去シーケンスを開始することになる。

ステップ４１６で、適切なアプリケーションが開始される。ステップ４１８で、読取装置は、カードまたはその他のデバイスからデータのすべてを読み取ることができるが、応答メッセージからＰＡＮだけを取り出して、その他のデータを後の使用のために保存することが可能である。図４で示される例では、アプリケーション・データは、ＭａｓｔｅｒＣａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｉｎｃｏｒｐｏｒａｔｅｄによって発表されたＰＡＹＰＡＳＳ Ｍ／ＣＨＩＰ（登録商標）としても知られているＯＮＥＳＭＡＲＴ ＰＡＹＰＡＳＳ（登録商標）アプリケーションに準拠する。しかし、これは単に例示の目的のためだけであり、その他の適切な仕様が準拠されてよく、または前記仕様が用いられてよい。同時に、ステップ４２０で、読取装置は、２つの成功裏のデータ取得（ＧｅｔＤａｔａ）コマンドの結果、入口活動化応答（ａｃｔｉｖａｔｅ ｅｎｔｒｙ ｒｅｓｐｏｎｓｅ）の一環として、チケット発行プロフィールと差引残高とを送信することができる。ステップ４２２で、読取装置は、第１のＡＣ生成コマンドが将来実行されるための準備として、入口借方記入（ｄｅｂｉｔ ｅｎｔｒｙ）コマンドと解析データとを端末から受信することができる。同時に、ステップ４１８で、適切なデータが記録読取りコマンドによってカードまたはその他のデバイスから読み取られる。一般に、最適化されたフローで、端末は、読取装置が第１のＡＣ生成コマンドを送信する準備ができる地点に達する前に、入口借方記入コマンドを送信することになる。ブロック４２４で、読取装置は取引処理証明書（ＴＣ）を要求する。ブロック４２６で、読取装置は、清算記録を含めて、入口借方記入応答を端末に送信する。

ブロック４２８で、カードまたはその他のデバイスがアプリケーション認証暗号文（ＡＡＣ）または許可要求暗号文（ＡＲＱＣ）を生成したかどうかが決定される。その場合、読取装置は、ブロック４１０で示すようにさらなる処理なしに取引処理を断る。逆に、ブロック４２８での「いいえ」分岐に続いて、組合せＤＤＡ／ＡＣ生成が要求されたかどうかが決定される。「ＤＤＡ」は動的データ認証（Ｄｙｎａｍｉｃ Ｄａｔａ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）を表し、「ＡＣ」はアプリケーション暗号文を表し、これら２つは組み合わせられて「組合せＤＤＡ／ＡＣ」を表す「ＣＤＡ」になる点に留意されたい。かかる生成が要求された場合、ブロック４３４で、読取装置は、（例えば、集積回路カード（ＩＣＣ）などの）電子支払いデバイスの公開鍵を取り出して、署名された動的アプリケーション・データ（ｓｉｇｎｅｄ ｄｙｎａｍｉｃ ａｐｐｌｉｃａｔｉｏｎ ｄａｔａ）（ＳＤＡＤ）を検証する。ブロック４３６で、ＳＤＡＤが正確である場合、処理はブロック４３８に流れ、一方、ＳＤＡＤが不正確である場合、読取装置は、ブロック４１０に従って取引処理を断る。ブロック４３０の「いいえ」分岐で、静的データ認証がブロック４３２で読取装置によって実行される。静的データ認証が失敗した場合、読取装置はＴＶＲ内に適切なビットを設定することになる。「ＴＶＲ」は、端末のリスク管理決定の結果を含む、端末によって生成されたフラッグのセットである端末検証結果を表す点に留意されたい。読取装置は、これを「ＡＣ生成」内のカードに渡す。ブロック４３８および４４０で、読取装置は、適切な処理規制と端末リスク管理とを実行する。この場合も、１つまたは複数の試験が失敗した場合、ＴＶＲ内に適切なビットが設定される。

ブロック４４２で、読取装置は、端末活動分析を実行する。ブロック４４４で決定されたように、結果がＴＣ要求である場合、読取装置は取引処理を受け入れる。逆に、ブロック４４４の「いいえ」分岐で、取引処理はブロック４１０で断られる。ブロック４４８で、読取装置は、清算記録を含めて、入口借方記入応答を端末に送信する。読取装置は、第１のＡＣ生成応答からの出力を含む入口借方記入応答を端末に送信することができる。カードまたはその他のデバイスがＡＣ生成コマンドに応答しない場合、読取装置によって適切な例外処理が実施されてよい。ブロック４０６、４１８、４２４、４２８、４３０〜４３６、４３８、４４０、４４２および４４６は、アプリケーション・レベルで起こされる活動に対応し得る点を理解されよう。さらに、ブロック４０２、４１０、４２０、４２２、および４４８は、輸送レベルまたはｅ−商品レベルで起こされる活動に対応し得る。図４のステップは、端末と読取装置の相互作用に関して実行されてよい。

一般論として、通常のＥＭＶ取引処理の流れでは、正しいアプリケーションがカードまたはその他のデバイス上で選択され、データがカードまたはその他のデバイスから読み取られ、端末リスク分析と端末活動分析とが実行され、カードは上の分析によって決定されたタイプの暗号化を要求され、次いで、カードはそのリスク分析を行い、適切な形で端末に応答する。本明細書で示される修正された取引処理の流れでは、カードからデータを読み取る場合、チケット発行データまたはｅ−商品関連データも任意選択で読み取られ、チケット発行端末またはその他のｅ−商品端末に供給されることが可能である。かかるデータは、通常のＥＭＶ記録読取コマンドによって、または１つもしくは複数のデータ取得コマンドによって読み取られることが可能である。カードまたはその他のデバイスが暗号文を要求される場合、カードはカードによって要求される形態で、ある種のデータ項目を知らされる。カード要求は、通常、チケット・タグを含むことになり、その結果、チケットが存在する場合、暗号文が要求されると、チケット・タグがカードに渡される（チケット発行が理解されない場合、単にゼロがカードに渡される）。カードは、通常の取引処理記録に対する延長の際にデータを記録する。任意選択で、暗号文要求の前または後にデータ記憶装置に書き込むことも可能である。これは、データ書込みコマンドにより行われ得るが、通常のＥＭＶに対する改変形態では、単にオープン・データ記憶装置として機能する何らのセキュリティなしで行われることが可能である。両方のオプションが上で議論されている。任意選択で、単に領域に入場を記録する場合、データ書込みの後に暗号文要求が続かなくてもよい。

適切なアプリケーションが選択されると、端末は処理オプション取得（ＧｅｔＰｒｏｃｅｓｓｉｎｇＯｐｔｉｏｎ）コマンドを実行することができる、このコマンドは、カードと取引処理とに関するいくつかの基本的な事実を知らせて、どの端末ファイル記録が読み取られる必要があるかを決定するために使用されるパラメータも提供する（１つまたは複数の実施形態では、かかるパラメータは、例えば、ＥＭＶ仕様からのアプリケーション・ファイル・ロケータすなわち「ＡＦＬ」パラメータであってよい）。この後者の記録は、所与の取引処理のために読み取られることになるデータ項目の一覧である。次いで、記録は記録読取コマンドを使用して読み取られることが可能である。オフライン差引残高など、その他のデータ項目は、データ取得コマンドにより読み取られることが可能である。

通常、データ書込みコマンドは、「スクリプティング（ｓｃｒｉｐｔｉｎｇ）」、すなわち、ＭＡＣを用いて暗号によって保護されたコマンドのシーケンスの一環として行われる。本発明の技法に従って構成された１つまたは複数のカード・アプリケーションでは、このタイプのデータ書込みとＭＡＣを有さないタイプのデータ書込みの両方がサポートされ得る。チケットを記録するために使用されるいくつかのデータ記憶装置が定義されてよい。これらのデータ記憶装置の半分は開放型であり、もう半分は保護型（すなわち、自由に読み取る書き込みのためにスクリプティング）であってよい。この場合も、これらの詳細は、本質的に例示的であり、その他の改変形態が可能である。

端末ファイル記録内で読み取られるデータ項目のうちの１つは、ＣＤＯＬ１と呼ばれる。このデータ項目は、暗号文要求内で供給されることになるタグの一覧、金額、通貨、などの項目などを端末に知らせる。このために、端末が暗号文要求でチケットまたはその他のｅ−商品を提供できるように、チケットまたはその他のｅ−商品のための追加タグが追加されてよい。ＥＭＶ基準に基づく基本規定は、タグが理解されない場合、ゼロが記入されることである。この機能は、非チケット発行端末または非ｅ−商品端末が本発明の技法を用いるカードまたはその他のデバイスを拒絶しないことになることを保証するために用いられることが可能である。

暗号文は、「ＡＣ生成」コマンドにより要求される場合がある。この暗号文は、一般に、イシュアだけによって理解されるが、カードまたはその他のデバイスは、ＲＳＡを使用してそれにデジタル化署名することができる。ＲＳＡは、デジタル署名のために使用されてもよい公開鍵暗号化に関してよく知られているアルゴリズムである。端末は、端末ファイル記録から必要な鍵を取得する際に、これを検査できる。

次に、チケットまたはその他のｅ−商品の記憶装置のための例示的な読取装置取引処理の流れを示す、図５に注目されたい。ブロック５０２で、読取装置はカードＩＤ取得（Ｇｅｔ Ｃａｒｄ ＩＤ）コマンドを受信して、ブロック５０４で、（非接触カードの場合）フィールド内でカードに関してポーリングを開始する。ブロック５０６で、単一のカードがフィールド内に存在する場合、読取装置はブロック５１２でアプリケーション選択に移動する。複数のカードが存在する場合、ブロック５０８およびブロック５１０で読取装置は除外シーケンスを開始する。ブロック５１６で、読取装置は、端末ファイル記録から第１の記録を読み取る。この記録は、ＰＡＮと、アプリケーション有効期限日と、任意選択で、ＰＡＮシーケンス番号とを含む。説明された構成は、高速の利点を提供することが可能であるが、所望される場合、ＰＡＮは任意のその他の記録内に配置されてよい。全体を通じて言及される改変形態は、ＥＭＶ仕様から当業者によく知られている。ブロック５１８で、読取装置は、記録１を解析して、ＰＡＮと、アプリケーション有効期限日と、ＰＡＮシーケンス番号とを取り出す。ＰＡＮシーケンス番号が記録内に含まれていない場合、読取装置は値「００」を使用する。

ブロック５２０で、読取装置は、カードＩＤ取得応答として、ＰＡＮと、ＰＡＮシーケンス番号と、アプリケーション有効期限日とを送信する。ブロック５２２で、読取装置は、チケット記憶コマンドを受信して、データ書込みコマンドのための準備としてデータを解析する。チケットまたはその他のｅ−商品のためのデータ書込みコマンドは、ブロック５２４で示される。読取装置は、（保護メッセージングを使用せずに）データ書込みコマンドにより、チケットまたはその他のｅ−商品をカードに送信する。ブロック５２６で、カード非活動化シーケンスが発生し、一方、ブロック５２８で、読取装置はすべてが適切に進んだことを端末に通知する。ブロック５１０の「ＮＡＫ送信」は、読取装置が何かが失敗したことを端末に通知することに対応する。

ブロック５０６、５１６、５１８、および５２４は、アプリケーション・レベルでの活動に対応し得る点が理解されよう。ブロック５０４および５２６は、輸送レベルでの活動に対応し得る。ブロック５０２、５１０、５２０、５２２、および５２８は、端末と読取装置の相互作用に対応し得る。

図６は、出口での支払いのための、交通機関システムなどの制御されたシステムの出口での取引処理の流れにおける例示的な方法ステップの流れ図６００を示す。ブロック６０２で、読取装置は、出口活動化（ＡＣＴＩＶＡＴＥ ＥＸＩＴ）コマンドを受信して、ブロック６０４で、フィールド内のカードに関してポーリングを開始する。出口活動化コマンドが受信されない場合、ブロック６０２の「いいえ」分岐で示されるように、監視が続く。カードのポーリングおよび活動化シーケンスはブロック６０４で示される。ブロック６０６で、単一のカードがフィールド内に存在するかどうかが決定される。そうであれば、読取装置は、ブロック６１２でアプリケーション選択に移動する。逆に、複数のカードが存在する場合、ブロック６０８で、読取装置は除去シーケンスを開始して、「ＮＡＫ送信」ブロック６１０が実行される。読取装置は、本明細書でさらに説明される第１のＡＣ生成応答からの状態バイトを含めて、借方応答を端末に送信する。ブロック６１２でのアプリケーション選択の後、チケットと、チケット発行プロフィールと、差引残高とがブロック６１４で読み取られることが可能であり、適切なアプリケーションがブロック６１６で開始される。ブロック６１８で、読取装置はＳＦＩ２の記憶１を読み取り、ＰＡＮと、ＰＡＮシーケンス番号と、アプリケーション有効期限日とを取り出す。ブロック６２４で、読取装置は、すべての要求されるアプリケーション・データを取り出すために、その他の記録を読み取る。同時に、ブロック６２０で示すように、読取装置は、出口活動化応答の一環として、チケットと、チケット発行プロフィールと、差引残高と、ＰＡＮと、ＰＡＮシーケンス番号と、アプリケーション有効期限日とを送信する。一方、ブロック６２４で、読取装置は、記録読取コマンドを経由してその他のカード・データを読み取っている。

ブロック６２２で、読取装置は、出口借方記入（Ｄｅｂｉｔ Ｅｘｉｔ）コマンドを受信して、将来の第１のＡＣ生成コマンドのための準備としてデータを解析する。この場合も、同時に、ブロック６２４で、読取装置は、記録読取コマンドを経由してカード・データを読み取り続ける。一般に、端末は、読取装置が第１のＡＣ生成コマンドを送信する前に出口借方記入コマンドを送信する。ブロック６２２で解析されたデータは、金額ならびに取引処理日および／または時刻印を含んでよい。ブロック６２６で、読取装置は、カードからチケットを除去するためにデータ書込みコマンドを送信し、一方、ブロック６２８で、読取装置は取引処理証明書を要求する。カード非活動化シーケンスは、ブロック６３０で発生する。ブロック６３２で、カードがＡＡＣまたはＡＲＱＣを生成したかどうかが決定される。その場合、「はい」分岐で、読取装置は、さらなる処理なしに取引処理を断る。そうでない場合、「いいえ」分岐で、組合せＤＤＡ／ＡＣ生成が要求されかたどうかが、ブロック６３４で決定される。この場合、読取装置は、ブロック６３６で、ＩＣＣ公開鍵を取り出して、署名された動的アプリケーション・データを検証する。ブロック６３８で決定されたように、署名された動的アプリケーション・データが不正確である場合、取引処理は断られ、一方、ＳＤＡＤが正確である場合、ブロック６４２で処理は続く。ブロック６３４での決定が否定的である場合、ブロック６４０で、読取装置によって静的データ認証が実行される。静的データ認証が失敗した場合、読取装置は、ＴＶＲ内に適切なビットを設定することになる。ブロック６４２および６４４で、読取装置は処理規制と端末リスク管理とを実行し、１つまたは複数の試験が失敗した場合、ＴＶＲ内に適切なビットを設定する。読取装置は、ブロック６４６で、端末活動分析を実行する。ブロック６４８で決定されたように、結果がＴＣ要求である場合、読取装置は、「はい」分岐により、取引処理を受け入れる。「いいえ」の回答の場合、取引処理は断られる。ブロック６５０で、清算記録に関して、読取装置は、端末リスク管理結果を収集するために使用されるＴＶＲではなく、カードに送信されたＴＶＲを使用すべきである。ブロック６５２で、読取装置は、清算記録を含めて、出口借方記入応答を端末に送信する。

図６で示される方法は、例えば、ステップ６２０および６２２を加えた、標準ＥＭＶ手続きの修正形態である点を理解されよう。ブロック６０６、６１４、６１８、６２４、６２６、６２８、６３２、６３４〜６３８、６４０、６４２、６４４、６４６、および６５０は、アプリケーション・レベルでの活動に対応し得る点をさらに理解されよう。さらに、ブロック６０４、６０８、および６３０は、輸送レベルでの活動に対応し得る。最後に、ブロック６０２、６１０、６２０、６２２、および６５２は、端末と読取装置の相互作用に対応し得る。

図７は、支払い取引処理の一環として、ｅ−商品がどのように（「カード」と呼ばれる）支払いデバイスに書き込まれるかを示す。図７および図８に関して、当業者は、その状況から、改変形態の重要性を理解されよう、また異なる可変名称が選択されてよい点も理解されよう。端末、読取装置、およびカードは、以下のステップを経る。ステップ７０１で、端末は、乱数ＵＮ^＊を生成する。端末は、一方向機能（ＯＷＦ）を使用して、乱数ＵＮ^＊から課題Ｈ^＊を計算する。この段階で、端末だけがＵＮ^＊を知っており、Ｈ^＊が知られている場合、ＵＮ^＊を計算するのは困難である。７０２で、端末は、アプリケーションを開始するために活動化コマンドを読取装置に送信する。端末は、読取装置が活動化応答メッセージ内で返すべきデータ要素のタグを含む。これは、例えば、ＲＮＤタグ、ＡＴＣタグ、カードＩＤタグ、および顧客プロフィール・タグを含む。端末はまた、コミット・コマンドによりカードとの相互作用が完成しなければならないことを読取装置に示すＨ^＊も含む。

ステップ７０３で、読取装置は、カードに関してポーリングを開始する。カードが見つかった場合、読取装置は、カードを活動状態にする。ステップ７０４で、読取装置は、適切なアプリケーションを選択して、そのアプリケーションを開始する。ステップ７０５で、読取装置はＨ^＊をカードに送信して、ＲＮＤとＡＴＣとを受信する。カードは、借方コマンドおよびコミット・コマンドの間の後の使用のために揮発性メモリ内にＲＮＤとＨ^＊とを記憶する。Ｈ^＊の存在は、不揮発性メモリがコミット・コマンドにより更新されなければならないことをカードに示す。読取装置は、ステップ７０６で、カードから顧客プロフィールとカードＩＤとを取り出す。

ステップ７０７で、読取装置は、ステップ７０２で要求されたデータ対象を活動化応答メッセージ内で端末に送信する。これは、ＲＮＤと、ＡＴＣと、カードＩＤと、顧客プロフィールとを含む。端末は、ステップ７０８で、顧客プロフィールに基づいて金額を決定して、ステップ７０９で、商品、ＲＮＤ、ＡＴＣ、およびカードＩＤのデータに対してＭＡＣを計算する。このように、商品はカードＩＤに連結され、したがって、もう１つの（本物の）カードで使用されることはできない。データ対象はＲＮＤおよびＡＴＣも含むため、同じカードに対してリプレイされることもできない。端末は、商品エンベロープ内に商品を記憶して、１６進法の「Ｆ」でＲＮＤとＡＴＣとに記入する。ステップ７１０で、端末は受領書を作成する。

ステップ７１１で、端末は、借方書込み（ＤＥＢＩＴＷＲＩＴＥ）コマンドの一環として、支払い関連データおよび受領書と一緒に、商品エンベロープを読取装置に送付する。ステップ７１２で、読取装置は、借方コマンドの一環として、支払い関連データおよび受領書と一緒に商品エンベロープをカードに送付する。ステップ７１３で、カードはそのカード・リスク管理を実行して、支払証明を作成する。カードは、コミット・コマンドの一環としてＵＮ^＊が提示されるまで、商品および受領書を含めて、いずれの更新も揮発性メモリ内に維持する。ステップ７１４で、読取装置は、コミット・コマンドの一環としてＵＮ^＊をカードに送信する。コミット・コマンドの受領時に、ブロック７１５で、カードは、課題^＊取得（ＧＥＴ ＣＨＡＬＬＥＮＧＥ）の一環として受信されたＨ^＊が、ＯＷＦ（ＵＮ^＊）と同じかどうかを検証する。この場合、カードはその不揮発性メモリを更新する。カードは、商品の入れ物（ｃｏｎｔａｉｎｅｒ）内にＲＮＤおよびＡＴＣと共に商品を記憶して、受領書の入れ物内に受領書を記憶する。カードはまた、不揮発性メモリ内の支払い関連パラメータも更新する。

ブロック７１６で、読取装置はカードを認証する。カード認証は、カードＩＤに連結したカードが本物のカードであることを読取装置に保証する。読取装置は、ブロック７１７で支払証明を端末に渡す。

図８は、ｅ−商品が、どのように読み込まれるか、完全性および信頼性に関して検査されるか、次いで、商品の更新と交換されるかを示す。元の商品が、ロンドン地下鉄の割引回数券のように、複数のチケット・パッケージである場合、更新された商品は１枚少ないチケットを含むことになる。元の商品が単一のチケットである場合、更新はチケットを無効にする。端末は以下のステップを経る。ステップ８０１で、端末は、アプリケーションを開始するために活動化コマンドを読取装置に送信する。端末は、読取装置が活動化応答メッセージ内で返さなければならないデータ要素のタグを含む。端末は、Ｈ^＊を読取装置に送信しない。これは、取引処理がコミット・コマンドにより完成されなくてよいことを読取装置に示す。

ブロック８０２で、読取装置は、カードに関してポーリングを開始する。カードが見つかると、読取装置はカードを活動状態にする。ステップ８０３で、読取装置は、適切なアプリケーションを選択して、そのアプリケーションを開始する。ステップ８０４で、読取装置は、課題^＊取得コマンドを送信して、ＲＮＤとＡＴＣとを受信する。カードは、借方コマンドの間の後の使用のために揮発性メモリ内にＲＮＤを記憶する。カードは、読取装置からＨ^＊を受信しない。これは、コミット・コマンドは送られることにならず、不揮発性メモリは借方コマンドにより更新されなければならないことをカードに示す。

ステップ８０５で、読取装置は、現在、カード内に記憶された商品エンベロープを取り出す。商品エンベロープは、商品’と、ＲＮＤ’と、ＡＴＣ’とを含む。ステップ８０６で、読取装置はカードからカードＩＤを取り出す。ステップ８０７で、読取装置は、活動化応答メッセージ内でカードＩＤと、ＲＮＤと、ＡＴＣと、商品エンベロープとを端末に送信する。ブロック８０８で、端末は、商品’が特定のカードＩＤに関してＲＮＤ’およびＡＴＣ’に対して計算されたかどうかを検査する。そうである場合、ブロック８０９で、端末は、同じカードＩＤに対して新しい商品を計算するが、新しいＲＮＤとＡＴＣとを使用する。端末は商品エンベロープ内に商品を記憶して、１６進法の「Ｆ」を用いてＲＮＤとＡＴＣとに記入する。ブロック８１０で、端末は受領書を作成する。

ステップ８１１で、端末は、借方書込みコマンドの一環として、受領書と共に新しい商品エンベロープを読取装置に送信する。カードに財務上の影響が存在しないように、借方書込みコマンドはゼロの金額用であってよい。ステップ８１２で、借方コマンドの一環として、読取装置は、受領書と共に新しい商品エンベロープをカードに送信する。ブロック８１３で、カードは、商品の入れ物内にＲＮＤおよびＡＴＣと共に商品を記憶して、受領書の入れ物の中に受領証を記憶する。

ステップ８１４、８１５、および８１６で、読取装置は、カードを認証して（カード認証は、カードＩＤに連結されたカードが本物のカードであることを読取装置に保証する）、読取装置は、（ゼロの金額用の）支払証明を端末に引き渡す。

一般的に、先行技術のシステムは支払いの後に引き渡されることになる商品に依存する点が理解されよう。本発明の１つまたは複数の技法は、支払いが発生する前に商品が引き渡されることを可能にするデータ記憶装置の信用モデルを可能にする。このデータ記憶装置の概念の範囲内で、商品の可用性は自由であるが、使用（「消費」）は制限される。物理的な商品と異なり、ビットとバイトを「生産する」ことは何の費用もかからない。ｅ−商品が消費される前に支払いが受理されることが確信できる限り、ｅ−商品を提供するリスクを冒すことができる。したがって、データ記憶装置の信用モデルは、特にｅ−商品に関係すると思われる。販売店は、例えば、（イシュアにおける信用など）追加のカード機能に依存することができる場合、この信用モデルを使用することができる。カード・アプリケーションは、クローニングに対して、ならびに商品の再使用に対して保護を提供すべきである。したがって、カード上のデータ記憶（例えば、チケット発行またはその他のｅ−商品）との支払いの統合は新しい信用モデルを可能にし、本発明の１つまたは複数の技法は、高速かつ簡単な取引処理の流れを使用して、カード上のデータ記憶を実施することができる。

レビューのために、カード支払いのための伝統的な信用モデルでは、販売店は、支払いに関してアクワイアラを信頼する。販売店は、アクワイアラからの簡単な「ＯＫ」の後に商品を顧客に提供する。販売店は、アクワイアラがこの「ＯＫ」を守り、決算手続きの一環として販売店に支払うであろうことを理解している。拡張モデルでは、販売店は、ｅ−商品の販売および使用を制御するために、端末内およびカード内の追加の機能性にも依存する。したがって、販売店は、商品の管理に関して、アクワイアラとイシュアの両方を信用する必要がある。

図９は、伝統的な信用モデルを例示する。このモデルでは、責任の明確な分離が存在する：
・販売店は販売機９０２に対して責任を負う。
・アクワイアラは（支払い）端末９０４に対して責任を負う。

販売店およびアクワイアラは、信用に基づく（商取引処理）関係を有する。（端末を経由して）アクワイアラが、取引処理が成功したことを販売店（すなわち、販売機）に対して確認する場合、商品９０８が引き渡される。アクワイアラは、カードの相互作用の複雑さを販売店から保護する。販売店とカード９０６のイシュアの間には直接的な関係は存在しない。

商品が電子形態である場合、拡張された信用モデルが適用される。この場合、ｅ−商品は、さらに「使用」と呼ばれる、サービス（輸送、音楽など）に対するアクセスを与える。典型的な事例は、顧客が販売機でチケット（ｅ−商品）を購入して、次いで、ゲートを開くためにチケットを回転式改札口に入れる（使用）場合である。ｅ−チケットに関係する場合、データを維持するためのデータ記憶媒体が必要である。かかるデータ記憶媒体のための１つの選択肢は、チケットを購入するために使用される支払いカードである。カードはチケットの記憶媒体であるため、カードは使用時に必要とされることになる。カードのこの追加の関与は、信用モデルの拡張がアクワイアラとイシュアの両方を含むことを要求する。図１０は、販売機でｅ−チケットを購入するための信用モデル案を例示する。図１１は、ゲートでの信用モデル案を例示する。

図９と異なり、図１０の販売機１００２は、支払いの確認に先立って、商品（ｅ−商品）１００８を端末１００４に提供する。これは、販売店から追加の信用レベルを要求する。販売店は、支払いを伴わない商品へのアクセスを予防する取引処理の流れを実施するためにアクワイアラに依存する。販売店からのこの追加の信用レベルは、ｅ−商品（バイナリ・データ）に関係するため、受け入れ可能である。ｅ−商品は、前記商品がアクセスを与えるサービス以外の価値を有さない。非支払いの場合、顧客が商品を使用できない限り、販売店は財務上の損失を負わない。カード１００６のイシュアは、図９でのように示される。

図１１で分かるように、顧客が鉄道輸送１１１２などのサービスのためにｅ−商品１００８を交換する場合、ゲート１１１０は、カード１１０６に直接「話しかける」。清算すべき支払いが存在しないため、アクワイアラおよび端末は輪の外である。販売店は、偽造品に対する保護として、追加のカード機能性に依存する。したがって、販売店とイシュアの間に信頼の関係が存在しなければならない。
偽造品は以下を含む。
１．本物の商品に類似したまたは前記商品と同じ詐欺師によって生み出されたデータ
２．本物の商品のクローン
３．本物の商品のリプレイ
販売店は、ゲートで偽の商品を検出する方法をすでに有する。販売店は、クローニングおよびリプレイに対する保護のためにカード機能性に依存する。したがって、拡張された信用モデルの範囲内では、販売店は、ｅ−商品の使用を制御して、クローニングおよびリプレイに対する対策を提供するためにイシュアに依存する。

要約すれば、拡張された信用モデルが機能するためには、データ記憶装置は、以下に対する保護を提供すべきである。
１．未払いの商品の使用（アクワイアラの拡大責任）
２．商品のクローニング（イシュアの拡大責任）
３．商品の再使用（イシュアの拡大責任）
偽の商品に対する保護は、依然として販売店の責任である。

カード上および端末上に一般的なデータ記憶機能性を有することの妥当性は、次に、拡張された信用モデルという状況において説明される。本発明の１つまたは複数の実施形態では、説明されたばかりの保護機構は、以下のように実施され得る。
・一般的な（支払い）端末を経由して
・一般的な（支払い）カードを経由して
・カードまたは端末において販売店制御される鍵を要求せずに
一般的なデバイスの使用は以下を可能にする。
・イシュアが以下の支払いカードを提供する
・チケット発行、忠誠などに使用され得る支払いカード
・イシュアと販売店の間に事前の取決めを伴わない支払いカード
・販売店の特定の要件の知識を伴わない支払いカード
・アクワイアラが以下の端末を提供する
・チケット発行、忠誠などに使用され得る端末
・販売店の特定の要件の知識を伴わない端末
・販売店が一般的な支払いカードと端末とを使用する
・特定のデータ記憶装置アプリケーションのための手段として
・支払いアプリケーションの知識を伴わずに
一般的なデータ記憶装置によって提供される機能性に関して、さらなる詳細が次に提示される。完全な利益を有するために、カード（および端末）内のデータ記憶機能は、すべての販売店特定要件を可能にするべきである。１つまたは複数の実施形態では、想定される機能性対象は、以下の表で示されることができる。

本発明は、ハードウェアおよび／またはソフトウェアの態様を用いることが可能である。ソフトウェアは、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むが、これらに限定されない。ソフトウェアは、例えば、端末１２２、１２４、１２６、１３４、２０６、２０８に関して用いられてよい。ファームウェアは、例えば、カード１０２、１１２、１３０２などの支払いデバイスに関して用いられてよい。図１２は、本発明の１つまたは複数の態様またはプロセスの一部またはすべてを実施できるシステム１２００のブロック図である。図１２に示すように、メモリ１２３０は、（集合的に、図１２ではプロセス１２８０として示される）本明細書で開示される方法、ステップ、および機能の１つまたは複数の態様を実施するように（例えば、プロセッサ部分１０６、１１６に対応し得る）プロセッサ１２２０を構成する。メモリ１２３０は、分散型であっても局所的であってもよく、プロセッサ１２２０は、分散型であっても特異（ｓｉｎｇｕｌａｒ）であってもよい。メモリ１２３０は、電気メモリ、磁気メモリ、もしくは光メモリ、またはそれらの組合せ、あるいは（カード１０２、１１２に関して上で説明されたようなメモリ部分を含めて）その他のタイプの記憶装置デバイスであってもよい。分散型プロセッサが用いられる場合、プロセッサ１２２０を作り上げる各分散型プロセッサは、一般に、その独自のアドレス可能なメモリ領域を含む点に留意されたい。コンピュータ・システム１２００のいくつかまたはすべては、特定用途向けの集積回路内または一般用途の集積回路内に組み込まれてよい点にも留意されたい。例えば、１つまたは複数の方法ステップは、ファームウェアを使用するのではなく、ＡＳＩＣ内のハードウェア内で実施されてよい。ディスプレイ１２４０は、様々な可能な入出力デバイスを表す。

システムおよび製品の詳細
当技術分野で知られているように、本明細書で議論された方法および装置の１つまたは複数の態様の一部またはすべては、それ自体が、その上にコンピュータ可読コード手段が実施されたコンピュータ可読媒体を含む製品として販売されることが可能である。コンピュータ可読プログラム・コード手段は、コンピュータ・システムと共に、本明細書で議論された方法を実行するため、または本明細書で議論された装置を作り出すためのステップのすべてまたはいくつかを実行するために動作可能である。コンピュータ可読媒体は、記録可能な媒体（例えば、フロッピー（登録商標）・ディスク、ハード・ドライブ、コンパクト・ディスク、ＥＥＰＲＯＭ、もしくはメモリ・カード）であってよく、または伝送媒体（例えば、光ファイバーを含むネットワーク、ワールドワイド・ウェブ、ケーブル、もしくは時分割多元接続、符号分割多元接続、またはその他の無線周波数チャネルを使用する無線チャネル）であってもよい。コンピュータ・システムと共に使用するのに適した情報を記憶できる、知られているまたは開発された任意の媒体が使用されてよい。コンピュータ可読コード手段は、コンピュータが、磁気媒体に関する磁気改変、またはコンパクト・ディスクの表面上の高さ改変など、命令およびデータを読み取ることを可能にする任意の機構である。

本明細書で説明されたコンピュータ・システムおよびサーバは各々、本明細書で説明された方法、ステップ、および機能を実施するように関連するプロセッサを構成することになるメモリを含む。かかる方法、ステップ、および機能は、例えば、要素１０２、１１２、１４２、１２２、１２４、１２６、１３４、１４０、２０６、２０８上の処理能力によって、または前述の任意の組合せによって実行されてよい。メモリは、分散型であっても局所的であってもよく、プロセッサは分散型であっても特異であってもよい。メモリは、電気メモリ、磁気メモリ、もしくは光メモリ、またはそれらの組合せ、あるいはその他のタイプの記憶装置デバイスであってもよい。さらに、用語「メモリ」は、関連するプロセッサによってアクセスされるアドレス可能な領域内でアドレスから読み取ることまたは前記アドレスに書き込むことが可能な任意の情報を包括できるよう十分広く解釈されるべきである。この定義により、関連するプロセッサはネットワークから情報を取り出すことができるため、ネットワーク上の情報は、依然として、メモリ範囲内に存在する。

したがって、例えば、前述の端末１２２、１２４、１２６、１３４、２０６、２０８、またはカード１０２、１１２、１３０２などの支払いデバイスなど、本発明の１つまたは複数の実施形態の要素は、本明細書で説明された方法ステップを実施するための適切な命令を伴うコンピュータ技術を利用してよい。さらなる例として、端末装置１２２、１２４、１２６、１３４、２０６、２０８は、通信モジュールと、通信モジュールに結合されたアンテナと、メモリと、メモリと通信モジュールとに結合され、非接触支払いデバイスに問い合わせるために動作可能な少なくとも１つのプロセッサとを含んでよい（アンテナおよび通信モジュールの代わりに、接触カードなど、接触支払いデバイスに問い合わせるために適切な接触要素およびその他の要素が提供されてもよい）。

したがって、本発明の１つまたは複数の実施形態は、コンピュータ・プログラム・コード手段を含むコンピュータ・プログラムがコンピュータ上で実行される場合、本明細書で示される任意の方法または請求項の１つまたはすべてのステップを実行するように適合された、コンピュータ・プログラム・コード手段を含むコンピュータ・プログラムを含んでよく、かかるプログラムはコンピュータ可読媒体上に実施され得る点を理解されよう。さらに、本発明の１つまたは複数の実施形態は、本明細書で示され、かつ説明された１つまたは複数の装置要素もしくは機能と共に、コンピュータに本明細書で示された方法または請求項の１つまたは複数のステップを実行させるように適合されたコードを含むコンピュータを含んでもよい。

本発明の例示的な実施形態が添付の図面を参照して本明細書で説明されているが、本発明はそれらの厳密な実施形態に限定されず、本発明の範囲または精神から逸脱せずに、様々なその他の変更および修正が当業者によって行われてよい点を理解されたい。

本発明の技法を実施できるシステムおよびその様々な構成要素の例を示す図である。 制御されたアクセス・システムに対する本発明の技法の１つの特定の例示的な応用を示す図である。 本発明の態様による例示的な方法ステップの流れ図である。 システムの入口での支払いのための、システム入口での例示的な取引処理の流れを示す特定の例示的な流れ図である。 読取装置で電子チケットを記憶するための１つの特定の例示的な取引処理の流れにおける例示的な方法ステップを示す特定の詳細な流れ図である。 出口での支払いのための、制御されたアクセス・システムの出口での取引処理の流れの特定の例示的な方法ステップを示す図である。 例示的なセキュリティ機能を含む、ｅ−商品の購入および記憶のための例示的なデータ・フローを示す図である。 例示的なセキュリティ機能を含む、ｅ−商品の更新のための例示的なデータ・フローを示す図である。 伝統的な信用モデルを示す図である。 本発明の例示的な拡張された信用モデル内の購入を示す図である。 本発明の例示的な拡張された信用モデル内の使用法を示す図である。 本発明の１つまたは複数の実施形態で有用な例示的なコンピュータ・システムのブロック図である。

Claims (33)

1. 電子商品インフラストラクチャに関連して支払いインフラストラクチャを経由した統合支払い・電子商品転送のためのコンピュータ実施される方法であって、
   財務データを取得するために第１の端末によって電子支払いデバイスの問合せを円滑にするステップであって、前記電子支払いデバイスが前記支払いインフラストラクチャに従って構成されており、前記第１の端末が前記支払いインフラストラクチャに従って構成された第１の端末の支払いモジュールと、前記電子商品インフラストラクチャに従って構成され、かつ前記第１の端末の支払いモジュールに結合された第１の端末の電子商品モジュールとを有し、前記電子支払いデバイスの前記問合せが前記第１の端末の支払いモジュールによって実行されているステップと、
   前記第１の端末の電子商品モジュールによってｅ−商品関連情報の生成を円滑にするステップと、
   前記財務データと前記支払いインフラストラクチャとに従って実行される取引処理範囲内で、前記第１の端末の支払いモジュールを経由して前記電子支払いデバイスへの前記ｅ−商品関連情報の転送を円滑にするステップと
   を含む方法。
2. 問合せを円滑にする前記ステップにおいて、
   前記電子支払いデバイスの所有者に関係するプロフィール・データが取得され、
   前記ｅ−商品関連情報が前記プロフィール・データに基づいて前記第１の端末の電子商品モジュールによって生成される
   請求項１に記載の方法。
3. 前記プロフィール・データが、それに関連する複数の資格付与範疇のうちの少なくとも１つを有するクラスの会員として前記電子支払いデバイスの前記所有者を識別する情報を含み、前記資格付与範疇が前記ｅ−商品に関連する、請求項２に記載の方法。
4. 前記資格付与範疇が輸送料金範疇を含み、前記ｅ−商品関連情報が輸送チケット情報を含む、請求項３に記載の方法。
5. 前記ステップが、制御されたアクセス・システムへの所有者の入場に関連して実行され、前記ｅ−商品関連情報が初期入場地点情報を含む、請求項１に記載の方法。
6. 前記第１の端末が入口端末であり、
   前記システムからの前記所有者の退場時に、前記初期入場地点情報を取得するために出口端末によって前記電子支払いデバイスの取合せを円滑にするステップであって、前記出口端末が、前記支払いインフラストラクチャに従って構成された出口端末の支払いモジュールと、前記電子商品インフラストラクチャに従って構成され、かつ前記出口端末の支払いモジュールに結合された出口端末の電子商品モジュールとを有するステップと、
   前記初期入場地点情報と前記出口端末の位置とに基づいて、前記出口端末の支払いモジュールを経由して
   前記所有者にチケット提供することと、
   前記所有者に料金を請求することと
   のうちの少なくとも１つを円滑にするステップと
   をさらに含む、請求項５に記載の方法。
7. 前記入口端末と前記出口端末とが同じである、請求項６に記載の方法。
8. 前記入口端末と前記出口端末とが識別可能である、請求項６に記載の方法。
9. 問合せを円滑にする前記ステップにおいて、前記電子支払いデバイスの所有者に関係するプロフィール・データが取得され、前記プロフィール・データがそれに関連する複数の資格付与範疇のうちの少なくとも１つを有するクラスの会員として前記電子支払いデバイスの前記所有者を識別する情報を含み、前記資格付与範疇が前記ｅ−商品に関連する、請求項６に記載の方法。
10. 前記資格付与範疇が輸送料金範疇を含み、前記ｅ−商品関連情報が輸送チケット情報を含む、請求項９に記載の方法。
11. 前記電子支払いデバイスが非接触無線周波数（ＲＦ）近接型カードである、請求項１に記載の方法。
12. 前記電子支払いデバイスが接触カードである、請求項１に記載の方法。
13. 前記電子支払いデバイスが、非接触無線周波数（ＲＦ）と接触インターフェースの両方を有するデュアル・インターフェース・カードである、請求項１に記載の方法。
14. 前記電子支払いデバイスが非カード・フォーム・ファクタを有する、請求項１に記載の方法。
15. 取引処理カウンタとアカウント番号とを取得するために前記第１の端末によって前記電子支払いデバイスの問合せを円滑にするステップと、
    前記取引処理カウンタと前記アカウント番号とを含む認証コードの計算を円滑にするステップと、
    前記電子支払いデバイスから取得された前記取引処理カウンタと前記アカウント番号とが、前記認証コード内に含まれた前記取引処理カウンタと前記アカウントとに一致するかどうかを決定することを円滑にするステップと、
    前記決定することが、前記電子支払いデバイスから取得された前記取引処理カウンタと前記アカウント番号とが、前記認証コード内に含まれた前記取引処理カウンタと前記アカウント番号と一致しないことを明らかにすることに対応して、前記電子支払いデバイスによって前記認証コードの記憶の拒絶を円滑にし、それによりリプレイの不正の可能性を削減するステップと
    をさらに含む、請求項１に記載の方法。
16. 前記アカウント番号と、前記認証コードと、前記取引処理に関連する独自のデータ認証署名とに基づいて、スキミング検出を円滑にする追加ステップをさらに含み、前記認証コードが前記アカウント番号を含み、前記アカウント番号が前記独自のデータ認証署名によって署名されている、請求項１５に記載の方法。
17. 取引処理カウンタと、電子支払いデバイス識別子と、電子支払いデバイス生成された乱数とを取得するために前記第１の端末によって前記電子支払いデバイスの問合せを円滑にする追加のステップと、
    前記ｅ−商品関連情報と、前記取引処理カウンタと、前記電子支払いデバイス識別子と、前記電子支払いデバイス生成された乱数とに基づく認証コードの計算を円滑にするための追加のステップと、
    前記取引処理カウンタと前記支払いデバイス生成された乱数とを経由してリプレイの不正の検出を円滑にする追加のステップと
    をさらに含む、請求項１に記載の方法。
18. 前記電子支払いデバイス識別子への前記ｅ−商品関連情報の連結に基づいてスキミング検出を円滑にする追加のステップ
    をさらに含む、請求項１７に記載の方法。
19. 前記ｅ−商品のための支払いを円滑にする追加のステップをさらに含み、前記支払いが前記電子支払いデバイスへの前記ｅ−商品関連情報の前記転送の後に発生する、請求項１に記載の方法。
20. 前記ｅ−商品関連情報の企てられた使用と実質的に同時に不正検出を円滑にする追加のステップをさらに含む、請求項１９に記載の方法。
21. 電子商品インフラストラクチャに関連して、かつ支払いインフラストラクチャに従って構成された電子支払いデバイスと共に、前記支払いインフラストラクチャを経由した統合支払い・電子商品転送のための端末であって、
    前記支払いインフラストラクチャに従って構成され、かつ財務データを取得するために前記電子支払いデバイスに問い合わせるように構成された支払いモジュールと、
    前記電子商品インフラストラクチャに従って構成され、かつ前記支払いモジュールに結合された電子商品モジュールであって、ｅ−商品関連情報の処理を円滑にするように構成されている電子商品モジュールと
    をさらに含み、
    前記支払いモジュールが、前記財務データと前記支払いインフラストラクチャとに従って実行される取引処理において、前記電子支払いデバイスへの前記ｅ−商品関連情報の転送を円滑にするようにさらに構成された端末。
22. 前記支払いモジュールが、前記電子支払いデバイスの所有者に関係するプロフィール・データを取得するために、前記電子支払いデバイスに問い合わせるようにさらに構成され、
    前記第１の端末の電子商品モジュールが前記プロフィール・データに基づいて前記ｅ−商品関連情報を処理するように構成された、
    請求項２１に記載の端末。
23. 前記ｅ−商品関連情報を前記処理することが、前記ｅ−商品関連情報を生成することを含む、請求項２１に記載の端末。
24. 前記ｅ−商品関連情報を前記処理することが、前記ｅ−商品関連情報を読み取ることを含む、請求項２１に記載の端末。
25. 前記ｅ−商品関連情報を前記処理することが、前記ｅ−商品関連情報を更新することを含む、請求項２１に記載の端末。
26. 電子商品インフラストラクチャに関連して支払いインフラストラクチャを経由した統合支払い・電子商品転送のためのコンピュータ読み取り可能プログラム・コードを含むコンピュータ使用可能媒体を含むコンピュータ・プログラム製品であって、
    財務データを取得するために第１の端末によって電子支払いデバイスの問合せを円滑にするためのコンピュータ使用可能プログラム・コードであって、前記電子支払いデバイスが前記支払いインフラストラクチャに従って構成されており、前記第１の端末が前記支払いインフラストラクチャに従って構成された第１の端末の支払いモジュールと、前記電子商品インフラストラクチャに従って構成され、かつ前記第１の端末の支払いモジュールに結合された第１の端末の電子商品モジュールとを有し、前記電子支払いデバイスの前記問合せが前記第１の端末の支払いモジュールによって実行されているコンピュータ使用可能プログラム・コードと、
    前記第１の端末の電子商品モジュールによってｅ−商品関連情報の生成を円滑にするためのコンピュータ使用可能プログラム・コードと、
    前記財務データと前記支払いインフラストラクチャとに従って実行される取引処理において、前記第１の端末の支払いモジュールを経由して前記電子支払いデバイスへの前記ｅ−商品関連情報の転送を円滑にするためのコンピュータ使用可能プログラム・コードと
    を含む、コンピュータ・プログラム製品。
27. 前記電子支払いデバイスの所有者に関係するプロフィール・データを取得するためのコンピュータ使用可能プログラム・コードをさらに含み、前記ｅ−商品関連情報が前記プロフィール・データに基づいて前記第１の端末の電子商品モジュールによって生成される、請求項２６に記載のコンピュータ・プログラム製品。
28. 前記プロフィール・データが、それに関連する複数の資格付与範疇のうちの少なくとも１つを有するクラスの会員として前記電子支払いデバイスの前記所有者を識別する情報を含み、前記資格付与範疇が前記ｅ−商品に関連する、請求項２７に記載のコンピュータ・プログラム製品。
29. 電子商品インフラストラクチャに関連して支払いインフラストラクチャを経由した統合支払い・電子商品転送のための電子支払いデバイスであって、前記電子支払いデバイスが、前記支払いインフラストラクチャに従って構成されており、
    メモリと、
    前記メモリに結合された少なくとも１つのプロセッサであって、
    財務データを取得するために第１の端末によって前記電子支払いデバイスの問合せを円滑にし、前記第１の端末が、前記支払いインフラストラクチャに従って構成された第１の端末の支払いモジュールと、前記電子商品インフラストラクチャに従って構成され、かつ前記第１の端末の支払いモジュールに結合された第１の端末の電子商品モジュールとを含み、前記電子支払いデバイスの前記問合せが、前記第１の端末の支払いモジュールによって実行されており、
    前記第１の端末の電子商品モジュールによってｅ−商品関連情報の生成を円滑にし、さらに
    前記財務データと前記支払いインフラストラクチャに従って実行される取引処理範囲内で、前記第１の端末の支払いモジュールを経由して前記電子支払いデバイスへの前記ｅ−商品関連情報の転送を円滑にする
    ために動作可能であるプロセッサと
    を含む、電子支払いデバイス。
30. 前記プロセッサが、前記端末が前記電子支払いデバイスの所有者に関係するプロフィール・データを取得することを円滑にするためにさらに動作可能であり、前記ｅ−商品関連情報が前記プロフィール・データに基づいて前記第１の端末の電子商品モジュールによって生成される、請求項２９に記載の電子支払いデバイス。
31. 前記プロフィール・データが、それに関連する複数の資格付与範疇のうちの少なくとも１つを有するクラスの会員として前記電子支払いデバイスの前記所有者を識別する情報を含み、前記資格付与範疇が前記ｅ−商品に関する、請求項３０に記載の電子支払いデバイス。
32. 前記プロセッサが、制御されたアクセス・システムへの所有者の入場に関連して前記ステップを実行するために動作可能であり、前記ｅ−商品関連情報が初期入場地点情報を含む、請求項２９に記載の電子支払いデバイス。
33. 前記第１の端末が入口端末であって、前記プロセッサが、
    前記システムからの前記所有者の退場時に出口端末によって前記初期入場地点情報を得るために前記電子支払いデバイスの問合せを円滑にし、前記出口端末が、前記支払いインフラストラクチャに従って構成された出口端末の支払いモジュールと、前記電子商品インフラストラクチャに従って構成され、かつ前記出口端末の支払いモジュールに結合された出口端末の電子商品モジュールとを有し、
    前記初期入場地点情報と前記出口端末の位置とに基づいて、前記出口端末の支払いモジュールを経由して
    前記所有者にチケット提供することと、
    前記所有者に料金を請求することと
    のうちの少なくとも１つを円滑にする
    ためにさらに動作可能である、請求項３２に記載の電子支払いデバイス。

Images