JP2019040608A - 非接触プロトコルを提供するシステム、方法、およびコンピュータプログラムプロダクツ - Google Patents

Abstract

【課題】非接触取引を管理するシステム、方法およびコンピュータプログラム製品を提供する。
【解決手段】システム１００は、起動要求を受信する。モバイルデバイス１１０からの第１のタップが識別される。第１のタップは、モバイルデバイスがシステムに対して所定の近傍内に置かれた場合に発生する。第１のアプリケーションに対応するＡＩＤを含む第１の選択コマンドが、モバイルデバイスに送信される。第１の選択コマンドに基づいた第１の応答が、モバイルデバイスから送信される。サポートされているデータタイプを示す情報を含むデータ要求が、モバイルデバイスに送信される。データ要求に基づき、かつ取引データを含む第２の応答が、モバイルデバイスから送信される。
【選択図】図１

Description

本明細書に記載する例としての態様は、一般的には非接触プロトコルに関し、より詳しくは、モバイルデバイスと、近距離無線通信（ＮＦＣ）読み取り装置と、販売時点管理（ＰＯＳ）システムとの間での相互運用を可能とする非接触プロトコルを提供するシステム、方法、およびコンピュータプログラム製品に関する。

ＮＦＣ技術は、一般的には１０センチメートル未満だけ離間しているある近傍内に位置付けされたデバイス間でデータを交換することを可能とするある規格に基づいた無線通信技術である。このようなＮＦＣ技術のうちの１つの用途は、支払い、アクセス、および発券業務のための取引を含む非接触取引を実行することである。例えば、ＮＦＣ対応のモバイルデバイスには、支払いアプリケーションと、消費者の金融機関が発行した支払いアカウント情報（すなわち、クレジットカードまたはデビットカードなどの金融手段と関連付けられた認証情報）とを供給することが可能である。各々の支払いアプリケーションは、複数の売主、製造業者、またはブランドと関連付けられた複数の集合の商業データを安全な素子に記憶し、管理することが可能である。このアプリケーションおよび支払いアカウント情報は、一般的には、暗号化されて、モバイルデバイス中の安全なエリアに記憶される。モバイルデバイスは、すると、ＮＦＣ技術を用いて、店舗などの有人の場所および自動販売機などの無人の場所でＮＦＣ対応の販売時点管理（ＰＯＳ）システムと通信することが可能である。支払いをするためには、消費者は、単にモバイルデバイスを、非接触支払い可能なＰＯＳシステムから約１０センチメートル以内に持ち込めば、取引が発生する。この過程は、一般的には、非接触クレジットカードおよびデビットカードによって用いられるものと同じである。

モバイルデバイスまたは非接触式のクレジットカードもしくはデビットカードを、それらが通信的に連結され得るように、ＮＦＣ対応の読み取り装置の近くに置くことは、時々、「ウェーブ」または「タップ」と呼ばれる。消費者がＮＦＣ対応のＰＯＳシステムのところで「タップして支払う」ことを可能とするモバイルデバイス用のアプリケーションは、一般に、「財布アプリケーション」または「モバイル財布顧客アプリケーション」と呼ばれる。支払いに関連するアプリケーションは、一般に、「支払い」アプリケーションと呼ばれる。一般的な非接触支払いアプリケーションは、次の技術のうちの任意のものを用いて容易化される：Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（登録商標）「ＥｘｐｒｅｓｓＰａｙ」、Ｄｉｓｃｏｖｅｒ（登録商標）「ＺＩＰ」、Ｍａｓｔｅｒｃａｒｄ（登録商標）「ＰａｙＰａｓｓ」、またはＶｉｓａ（登録商標）「ＰａｙＷａｖｅ」。

ＮＦＣはまた、製品に関する情報を読み出す、または特別なオファー、ロイヤルティ、もしくは報酬の情報を、例えば、ＮＦＣタグ、スマートポスター、もしくはスマート看板から受信するために用いることが可能である。オファー、ロイヤルティ、もしくは報酬に関連するアプリケーションは、一般には、本明細書では「商業」アプリケーションと呼ばれる。

支払いおよび商業の技術の利用に関連付けられる１つの技法的な課題は、支払い情報を送出する同じタップ事象が売主のロイヤルティカード、オファー、報酬、および類似物と関連付けられたさらなる情報を含むことを可能とする機能を協同的に伴う。この目的のため、既存のＮＦＣ読み取り装置またはＮＦＣ対応の支払いＰＯＳ端末でのメッセージング技術は、（前述の支払いプロトコルを用いる）支払い認証情報とさらなる商業データ（ロイヤルティ、オファー、報酬、など）との双方が取引を実施するために用いられるモバイルデバイスから検索するおよび／または受信するメッセージング技術を効果的にサポートするようにアップグレードされることになる。さらに別の技法的課題は、商業の要素（例えば、オファー、ロイヤルティ、カード認証情報、報酬、および類似物）をモバイルデバイス中に公開し、それによって、これらの商業要素が、次に、一般的なＰＯＳ取引（例えば、購入）の一部として提示されるようにすることを伴う。

米国特許出願公開第２０１２／０１２３８４７号明細書 米国特許出願公開第２０１２／０１０９７６４号明細書 米国特許出願公開第２０１０／０２７４７２２号明細書 特開２００７−２４９５４４号公報 特開２００１−２２２６７２号公報 特開２０１０−２１８４５０号公報 特開２００４−２５８７４０号公報

本明細書に提示される例としての実施形態は、非接触プロトコルを提供するシステム、方法、およびコンピュータプログラム製品を提供することによって上記の必要性を満たす。

１つの実施形態では、非接触取引を管理するシステムは、少なくとも１つのプロセッサを含む。起動要求が受信される。モバイルデバイスからの第１のタップが識別される。第１のタップは、モバイルデバイスが、システムへの所定の近傍内に置かれた場合に発生する。第１のアプリケーションに対応するＡＩＤを含む第１の選択コマンドが、モバイルデバイスに送信される。第１の選択コマンドに基づいた第１の応答が、モバイルデバイスから受信される。サポートされているデータタイプを示す情報を含むデータ要求が、モバイルデバイスに送信される。データ要求に基づき、かつ取引データを含む第２の応答が、モバイルデバイスから受信される。

別の実施形態では、非接触取引を管理する方法は、起動要求を受信し、
前記モバイルデバイスが端末に対して所定の近傍内に置かれた場合に発生する、モバイルデバイスからの第１のタップを識別し、第１のアプリケーションに対応するアプリケーション識別子（ＡＩＤ）を含む第１の選択コマンドを前記モバイルデバイスに送信し、前記第１の選択コマンドに基づいた第１の応答を前記モバイルデバイスから受信し、サポートされているデータタイプを示す情報を含むデータ要求を前記モバイルデバイスに送信し、前記データ要求に基づいた、取引データを含む第２の応答を前記モバイルデバイスから受信することを含む。

別の実施形態では、コンピュータ可読記憶媒体は、１つ以上のプロセッサに、起動要求を受信させ、前記モバイルデバイスが前記端末に対して所定の近傍内に置かれた場合に発生する、モバイルデバイスからの第１のタップを識別させ、第１のアプリケーションに対応するアプリケーション識別子（ＡＩＤ）を含む第１の選択コマンドを前記モバイルデバイスに送信させ、
前記第１の選択コマンドに基づいた第１の応答を前記モバイルデバイスから受信させ、サポートされているデータタイプを示す情報を含むデータ要求を前記モバイルデバイスに送信させ、前記データ要求に基づいた、取引データを含む第２の応答を前記モバイルデバイスから受信させるための命令のシーケンスを記憶する。

本明細書に提示する本発明の例としての実施形態の特徴および利点は、次の図面と一緒にした場合に以下に記す詳細な説明からより明らかになるであろう。

例示の実施形態に関わるプラットフォームアーキテクチャのグラフ表示である。 例示の実施形態に関わる単一タップのタイミング図を示す。 例示の実施形態に関わる二重タップおよび取引後データの送信を含む商業過程フローを図示するタイミング図を示す。 例示の実施形態に関わる二重タップならびに取引後データおよび支払いの送信を含む商業過程フローを図示するタイミング図を示す。 例としての実施形態に関わる例示のマルチブロックデータフローを示す。 本発明の例としての実施形態に関わる財布アプリケーションに対するグラフィカルユーザインターフェースによって生成されたウインドウまたは画面ショットを示す。 本発明の実施形態に関わる例示のインスタントオファー実装例を示すフロー図を示す。 本発明の例としての実施形態に関わるコンピュータシステム上に展開された機能モジュールのコラボレーション図である。

本明細書に提示する例としての実施形態は、本明細書中では以下に例としての売主取引という点について説明する、非接触プロトコルを提供するシステム、方法、およびコンピュータプログラム製品を対象とする。この説明は、本明細書に提示する例としての実施形態の応用分野を制限する意図はない。事実、以下の説明を読んだ後では、以下の例としての実施形態を代替の実施形態（例えば、大量輸送端末とモバイルデバイスとの間で無線通信接続を必要とする大量輸送取引を伴うもの）でどのように実施するかが当業者には明らかであろう。

「アプリケーション」、「アプレット」、「ウィジェット」という用語および／またはこれらの複数形態は、本明細書中では交換可能に用いられて、アプリケーション（他のアプリケーションとは独立にまたは共に機能する）または命令もしくはコードの集合もしくはサブ集合を意味し、（例えば、モバイルデバイス、カード読み取り装置、端末、販売時点（ＰＯＳ）システム、またはサーバ中の）１つ以上のプロセッサによって実行される場合に、プロセッサに特定のタスクを実施させる。例えば、財布アプリケーションを用いて、金融、ロイヤルティ、オファー、会員資格、またはアカウントのデータの記憶動作、処理動作、アクセス動作、または送信動作などの取引関連またはインターフェース関連の機能を実行することが可能である。財布アプリケーションはまた、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（登録商標）のＥｘｐｒｅｓｓＰａｙ、Ｄｉｓｃｏｖｅｒ（登録商標）のＮｅｔｗｏｒｋ ＺＩＰＳＭ、ＭａｓｔｅｒＣａｒｄ（登録商標）のＰａｙＰａｓｓ（商標）、およびＶｉｓａ ｐａｙＷａｖｅ（商標）の支払いアプレットなどの１つ以上の支払いアプリケーションを組み込み得るまたはこれと対話し得る。

一般に、商業関連のサービスは、いくつかの異なるプラットフォームで利用可能な１組のアプリケーションを介して利用可能である。第１のアプリケーション（またはアプリケーションの組）は、モバイル商業（ＭｏＣｏｍ）プラットフォーム内でサーバ上に存在する。ＭｏＣｏｍプラットフォームは、ロイヤルティアカウントおよびオファーを含む消費者データの管理に対して責任がある。加えて、ＭｏＣｏｍプラットフォームは、オファーに対するキャンペーンマネージャとして機能し、財布アプリケーション内の利用可能な売主ポータルを介して消費者に利用可能とされるオファーに対する遠隔データストアを提供する。

第２のアプリケーションは、モバイルデバイス上に、財布アプリケーションという形態で存在する。この財布アプリケーションは、財布アプリケーションがモバイルデバイスのセキュア・エレメント（ＳＥ）上のさらなるリソースにアクセスし得る際に用いる主要ユーザインターフェース（ＵＩ）およびさらなる商業アプリケーションサービスを提供する。

第３のアプリケーションは、モバイルデバイスのセキュア・エレメント上に、ＪａｖａＣａｒｄアプレットという形態で存在する。このアプレットは、ロイヤルティおよびオファーなどの商業関連のデータを記憶して、このデータが管理され得る際に用いられるインターフェースを提供する。このアプレットは、国際標準化機構（ＩＳＯ）７８１６−４に定義されるアプリケーションプロトコルデータユニット（ＡＰＤＵ）コマンドを用いることによってアクセス可能である。

第４のアプリケーションは、ＮＦＣ対応の読み取り装置（本明細書では単に「読み取り装置」と呼ばれる）上に存在する。読み取り装置は、独立型であるかまたは、販売時点（ＰＯＳ）端末に取り付けられる（そして管理される）ことが可能である。このアプリケーションは、モバイルデバイス上のセキュア・エレメントとのインターフェースに対するアクセスを容易化または提供して、ＡＰＤＵコマンド／データ交換タスクを最適化する特定のタスクを実施する。例えば、それは、モバイルデバイスを読み取り装置の近傍に位置付け（すなわち、「タップ」）した後で、ロイヤルティまたはオファーの情報を読み取ることを含む。

第５のアプリケーション（またはアプリケーションの組）は、ＰＯＳ端末および何らかのさらなる売主固有のハードウエア／ソフトウエアを含む売主ＰＯＳシステム上に存在する。これらのアプリケーションは、読み取り装置を介してモバイルデバイス上のセキュア・エレメントから受信された支払い／ロイヤルティ／オファー／報酬に関連するデータを管理する。ほとんどの場合、このデータは、次に、対応するＭｏＣｏｍまたは売主固有のプラットフォームに転送される。

図１は、例示の実施形態に関わるプラットフォームアーキテクチャのグラフ表示である。図１に示すように、システム１００は、非接触（例えば、近傍のまたはＮＦＣの）読み取り装置１２０およびモバイル財布プラットフォーム１３０に通信可能に連結されたモバイルデバイス１１０を含む。読み取り装置１２０はまた、ＰＯＳ端末１４０に通信可能に連結される。ＰＯＳ端末１４０は、読み取り装置１２０と同じ筐体内にあり得る。代替的には、ＰＯＳ端末１４０および読み取り装置１２０は、互いと通信可能に連結されているが、これらの構成要素の各々は、個別に収納される。

モバイルデバイス１１０は、例えば、携帯電話または同様なものであり得、プロセッサ１１１ａ、メモリ１１１ｂ、非接触フロントエンド（ＣＬＦ）１１１ｃ、ベースバンドモデム１１１ｄ、および、ディスプレイ（図示せず）などのユーザインターフェースを含む。ベースバンドモデム１１１ｄは、モバイルネットワーク通信用に用いられるデジタルモデムである。ＣＬＦ１１１ｃは、非接触もしくはＮＦＣの通信のアナログ態様ならびに非接触送信リンクの通信プロトコル層を取り扱う回路である。ＣＬＦ１１１ｃはまた、例えば、非接触取引を実行するために、読み取り装置１２０とモバイルデバイス１１０に含まれるセキュア・エレメント（すなわちＳＥ）１１２との間でデータを交換するために用いられる。

セキュア・エレメント１１２は、汎用集積回路カード（ＵＩＣＣ）、埋め込み式ＳＥカード、安全マイクロ安全デジタル（ｍｉｃｒｏＳＤ）カード、および類似物として実装され得る。セキュア・エレメント１１２は、一般に安全であると考えられているが、それは、それが、専用のメモリを含む内蔵式のシステムであり、独立した検査によって検証されたハードウエアおよびソフトウエア硬化技法によって保護されているからである。

セキュア・エレメント１１２は、１つ以上の商業アプレット１１３を含む（例えば、その上に記憶される）。各々の商業アプレット１１３は、商業サービスプロバイダ（ＳＰ）によって発行される商業サービスおよびアカウントと関連付けられる。サービスプロバイダは、顧客または消費者にサービスを提供する会社、組織、エンティティ、または類似物である。サービスプロバイダの例は、銀行、売主、カード協会、マーケティング会社、および公共交通機関などのアカウント発行エンティティを含む。サービスは、活動、機能、機能性、作業、または、支払いサービス、信用、負債、照合、贈与、オファー、もしくはロイヤルティサービス、乗車券サービス、および類似物などの、サービスプロバイダによって許容されるもしくは提供される用途であり得る。

商業サービスプロバイダは、１つ以上の個別の商業アプレット１１３をセキュア・エレメント１１２上に供給する（または供給させる）ことが可能である。加えて、他の独立したサービスプロバイダは、それら自身の商業アプレット１１３をセキュア・エレメント１１２上に供給する（または供給させる）ことが可能である。一般に、商業アプレット１１３は、ロイヤルティとオファーの双方と関連したデータを記憶して、このデータを、それを介して管理することが可能なＡＰＤＵインターフェースを提供する。商業アプレット１１３は、一般的記憶装置として動作して、複数のロイヤルティ／オファーサービスが、ロイヤルティ／オファーデータ管理用の機構（例えば、セキュア・エレメント、モバイルデバイス）を共有することを可能とする。メモリ制限および性能要件がセキュア・エレメント１１２上に記憶することが可能なロイヤルティ／オファーデータの量を制限する場合、さらなるデータを、モバイルデバイスメモリ１１１ｂ中に記憶し、商業ウィジェット１１５を使用して消費者が管理することが可能である。例えば、オファーに関連するいかなる図形画像も、セキュア・エレメントのメモリ割り当てを最適化するために、メモリ１１１ｂ中に記憶することが可能である。ロイヤルティ／オファーデータ管理は、対応するオファープラットフォーム１３１、ロイヤルティプラットフォーム１３２、または報酬プラットフォーム１３３によって取り扱うことが可能である。

商業アプレット１１３は、所与の売主に関連する全てのデータの記憶／管理を可能とするキャッシュド売主データテーブルを含む。これが、所与の売主の商業データを、財布アプリケーションによってセキュア・エレメント１１２またはモバイルデバイス１１０中に事前ロードすることを可能とする。キャッシュド売主データテーブルに含まれる例示の商業要素（および、タグ・長さ・値（ＴＬＶ）符号化中に用いられるそれらの対応するタグ値）を、以下に定義する。このデータは、記録指向のデータバッファに記憶される。例示の実施形態では、売主識別子（Ｍｅｒｃｈａｎｔ Ｉｄｅｎｔｉｆｉｅｒ）が、検索／回収タスク用のキーフィールドとして用いられる。オプションとして、索引（またはハッシュ表）が、性能を向上させるために作成され得る。

１つ以上の商業アプレット１１３は、例えば、セキュア・エレメント１１２の製造および／または構成中にセキュア・エレメント１１２上にロードすることが可能であり、かつ、商業取引を実行するためにその使用を可能とするようにパーソナライズし得る。商業アプレット１１３は、商業アプリケーションプログラミングインターフェース（ＡＰＩ）１２３を介して読み取り装置１２０とインターフェースする。例示の実施形態では、商業アプレット１１３は、ＪａｖａＣａｒｄアプレットという形態であって、ＩＳＯ７８１６−４に定義されるＡＰＤＵコマンドを用いることによってアクセス可能である。特に、商業アプレット１１３は、ＮＦＣ ＩＳＯ１４４４３プロトコル上でＩＳＯ７８１６コマンドを用いてセキュア・エレメント１１２を介して商業要素を読み取り装置１２０に通信する。

セキュア・エレメント１１２はまた、１つ以上の支払いアプレット１１７を含むことが可能であり、各々の支払いアプレット１１７は、支払いサービスプロバイダによって発行された支払いサービスおよびアカウントと関連付けられる。１つ以上の支払いアプレット１１７はまた、例えば、セキュア・エレメント１１２の製造および／または構成中にセキュア・エレメント１１２上にロードすることが可能であり、かつ、支払い取引を実行するためにその使用を可能とするようにパーソナライズし得る。支払いアプレット１１７は、ＡＰＩ１２４を介して読み取り装置１２０とインターフェースする。例示の実施形態では、支払いアプレット１１７は、ＪａｖａＣａｒｄアプレットという形態であり、ＩＳＯ７８１６−４に定義されるＡＰＤＵコマンドの使用によってアクセス可能である。支払いアプレット１１３はまた、ＮＦＣ ＩＳＯ１４４４３プロトコル上でＩＳＯ７８１６コマンドを用いてセキュア・エレメント１１２を介して支払い要素を読み取り装置１２０に通信させる。

前述のデバイス間での他の通信は、他の介在システム、ハードウエア、および／またはソフトウエアとのまたはこれを介しての通信を含み得るし、このような通信は、データの受信、転送、および／または管理を含み得ることを理解すべきである。

モバイルデバイス１１０上に記憶された財布アプリケーション１１４は、モバイルデバイス１１０のプロセッサによって実行される場合に、モバイルデバイス１１０を、例えば、非接触商業および／または支払い取引などの取引を処理するために機器として動作させる命令を含む。財布アプリケーション１１４は、ＩＳＯ７８１６−４に定義されるＡＰＤＵコマンドの使用によって、商業ＡＰＩ１１６を介して商業アプレット１１３と通信し、支払いＡＰＩ１１８を介して支払いアプレット１１７に通信する。

商業ウィジェット１１５は、消費者が、例えば、モバイルデバイスのディスプレイまたはユーザインターフェースとの対話によって商業要素（例えば、ロイヤルティカード認証情報、オファー、および報酬）を管理するためのインターフェースを提供する財布アプリケーション１１４の構成要素である。商業ウィジェット１１５は、例えば、モバイルデバイスのメモリ（例えば、１１１ｂ）中のハンドセット上に存在する商業要素のマスターリストを保つ。用いられる準備が成っているものと特定されているオファーのサブ集合は、次に、セキュア・エレメント１１２に移動されて、非接触読み取り装置１２０およびＰＯＳ端末１４０に通信される。ロイヤルティアカウント識別子などの機密情報は、セキュア・エレメント１１２上に記憶することが可能である。

支払いウィジェット１１９は、消費者が、例えば、モバイルデバイスのディスプレイまたはユーザインターフェースとの対話を介して、支払い要素（例えば、クレジットカードまたはデビットカードの認証情報）を管理するためのインターフェースを提供する財布アプリケーション１１４の構成要素である。

読み取り装置１２０は、読み取り装置商業アプリケーション１２１（本明細書では単に「読み取り装置アプリケーション」と呼ぶ）およびＰＯＳインターフェース１２２を含む。読み取り装置１２０は、２つのインターフェースを管理する：一方のインターフェースは、モバイルデバイス１１０中のセキュア・エレメント１１２とのそれであり、他方のインターフェースは、読み取り装置インターフェース１４１および商業アプリケーションデータハンドラー１４２を含むＰＯＳ端末１４０とのそれである。読み取り装置１２０の機能性は、読み取り装置１２０が独立型であって支払い端末もしくは売主ＰＯＳに接続されているかまたはその中に組み込まれているかとは無関係に同じである。非接触支払い機能性もまた、読み取り装置１２０に含まれるが、図示されていない。

モバイルデバイス１１０は、モバイル財布プラットフォーム１３０にさらに通信可能に連結され、このプラットフォームは次に、オファープラットフォーム１３１、ロイヤルティプラットフォーム１３２、および報酬プラットフォーム１３３に通信可能に連結される。集合的に、オファープラットフォーム１３１、ロイヤルティプラットフォーム１３２、および報酬プラットフォーム１３３は、モバイル商業（ＭｏＣｏｍ）プラットフォーム１３４と呼ぶことが可能であり、本明細書では個々にかつ集合的にＭｏＣｏｍサーバ（ここで図示する）と呼ばれる１つ以上のサーバ上に実装される。

１つの実施形態では、顧客は、読み取り装置１２０を備えるＰＯＳのところで非接触取引を実行するためにモバイルデバイス１１０を用い得る。顧客はモバイルデバイス１１０を非接触読み取り装置１２０の所定の必要近傍内において（すなわち、タップして）、モバイルデバイス１１０のＣＬＦ１１１ｃを、例えば、ＮＦＣ ＩＳＯ１４４４３プロトコルを用いて、読み取り装置１２０と通信させる。読み取り装置１２０はまた、モバイルデバイス１１０上の財布アプリケーション１１４、商業アプレット１１３、および／または支払いアプリケーションと通信して、非接触取引を実行する。

セキュア・エレメントは、セキュア・エレメント１１２中に現在記憶されている利用可能な認証情報のディレクトリとして機能する近傍支払いシステム環境（ＰＰＳＥ）を用いる。各々の認証情報は、支払いアプリケーションと関連付けられ、かつＰＰＳＥに記憶されている対応するアプリケーション識別子（ＡＩＤ）を割り当てられる。セキュア・エレメント１１２を含むＮＦＣ対応のモバイルデバイスが、ＮＦＣ対応の非接触読み取り装置の近傍に置かれるとき、非接触読み取り装置は認証情報を読み出して、取引を完了する。そうする前に、しかしながら、読み取り装置は初期化される。

モバイルデバイス１１０上では、ＰＰＳＥは、セキュア・エレメント１１２上に記憶されている支払いアプリケーションのリストを保つために用いられるアプリケーションであって、モバイルデバイス１１２上に記憶されている各々の支払いアプリケーションに、それらをシステムまたはデバイスに対して可視または不可視（すなわちアクセス可能）とすることによって、アクセス可能性を提供する。

読み取り装置の初期化
読み取り装置１２０の初期化を、ここでより詳細に説明する。１つの実施形態では、読み取り装置１２０は、モバイルデバイス中のどのアプリケーションが選択されるかを制御するエントリポイントマネージャ（ＥＰＭ）と呼ばれる機能を実装する。この実施形態では、ＥＰＭは、読み取り装置１２０が、商業取引を実施するアプリケーションを選択するためのモバイルデバイス１１０へのコマンドを送るか、または支払い取引を実施するコマンドを送るかどうかを制御する。商業アプリケーションを選択するコマンドは、本明細書では「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）」と呼ばれる。支払いアプリケーションを選択するコマンドは、本明細書では「ＰＰＳＥ Ｓｅｌｅｃｔ（ＰＰＳＥ選択）」と呼ばれる。

ＥＰＭはまた、チェックアウト過程中での、読み取り装置１２０の開始モードおよび後続のアプリケーション切り替えを制御する。ＥＰＭは、したがって、商業取引用のＳｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドと支払い取引用のＰＰＳＥ Ｓｅｌｅｃｔ（ＰＰＳＥ選択）コマンドとの間の（読み取り装置１２０における）切り替えを容易化する。

読み取り装置上での商業取引の開始
読み取り装置は、以下にさらに詳述するいくつかのモードに従って読み取り装置上で商業取引を開始するように構成することが可能である。「自動開始」と呼ばれる１つのモードでは、読み取り装置アプリケーション１２１は、読み取り装置１２０でのデフォルトのアプリケーションである。デフォルトアプリケーションであることは、読み取り装置アプリケーション１２１を、第１のタップオプションとして（すなわち、モバイルデバイス１１０と非接触読み取り装置１２０との間の初期の連結通信時に）消費者に対して利用可能とすることを許容する。

「手動開始」と呼ばれる別のモードは、手動の介入を用いて読み取り装置の商業アプリケーション１２１を開始することを可能とする。手動の介入は、（例えば、ＰＯＳ端末インターフェースを用いることによって開始された）ＰＯＳ端末１３０からの、または、商業ウィジェット１１５を用いることによってモバイルデバイス上の商業アプリケーションを選択する消費者からのコマンドという形態であり得る。

「取引後データによる支払い」と呼ばれる別のモードは、どのようにして支払いが活動ストリーム中で取り扱われるかを制御することを伴う。売主が、例えば取引後データの供給をサポートする場合、売主データの支払いおよび領収は、取引の最終合計が計算された後などの同じタップ事象によって遂行することが可能である。

別のモードは、「先払い」と呼ばれる。先払いオプションは、自動開始モードおよび／または手動開始モードと一緒に動作して、支払い目的でＰＰＳＥ Ｓｅｌｅｃｔ（ＰＰＳＥ選択）コマンドを開始し、次に、Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドを開始して、商業データ（例えば、ロイヤルティデータ、オファーデータ、報酬データ、および類似物）を得る。商業データは、本明細書中では「商業要素」と交換可能に呼ばれる。

自動開始モード
図１を参照すると、自動開始モードは、ＰＯＳチェックアウト過程の開始時に読み取り装置１２０上に商業機能性を提供する。モバイルデバイス１１０が読み取り装置１２０をタップすると、読み取り装置アプリケーション１２１は、読み取り装置１２０に、非接触取引を実行するために用いられる商業アプリケーションに対応するＡＩＤを含むモバイルデバイス１１０に対して「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）」メッセージを送らせる。このメッセージがモバイルデバイス１１０によって容認された場合それは、肯定応答メッセージを返送する。次に、読み取り装置１２０は、モバイルデバイス１１０に「Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）」コマンドを送る。Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドは、セキュア・エレメント１１２が商業取引を実施するために用いる売主固有のデータを含む。また、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）取引が成功裏に完了すれば、制御権はモバイルデバイス１１０に移る。読み取り装置１２０が「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）」メッセージに対して否定応答を受信する場合には、それは、制御権をＥＰＭに戻す。

手動開始モード
さらに図１を参照すると、手動開始モードにおいては、読み取り装置１２０は、消費者またはＰＯＳ端末１４０からの要求に応答して読み取り装置アプリケーション１２１を開始する。この手動開始モードにおいては、チェックアウト過程の開始時に、読み取り装置１２０はＰＰＳＥ選択状態にある。消費者が開始した商業取引の場合、消費者は、顧客が対面しているデバイス（例えば、商業ウィジェット１１５）のところで商業アプリケーションを選択する。顧客が対面しているデバイスは次に、読み取り装置１２０にコマンドを送って、ＥＰＭを介して読み取り装置アプリケーション１２１を開始する。ＰＯＳ端末が開始した商業取引の場合、ＰＯＳ端末１４０は、読み取り装置１２０に読み取り装置１２０に、読み取り装置アプリケーション１２１を開始するように指令する。１つの実施形態では、これは、ＰＯＳ端末１４０上のインターフェースを介してレジ係りによって開始される。

一旦読み取り装置の商業アプリケーション１２１が読み取り装置１２０上で開始されると、商業アプリケーションは、自動開始モードで上述したように機能する。

取引後データでの支払い
取引後データモードでの支払いにおいては、支払い取引は、取引後データがＰＯＳ端末１４０と、読み取り装置１２０と、セキュア・エレメント１１２との間で通信されるように実施することが可能である。このオプションは、商業プロトコルを、消費者チェックアウトの開始時に開始させることを可能とするが、支払いは、最終的な取引合計が計算されるまでは、読み取り装置１２０によって要求されることはない。

ＰＯＳ端末１４０は、例えば、取引識別子（ＩＤ）および償還されたクーポンＩＤを持つ読み取り装置１２０に「Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ（取引後）」コマンドを送る。読み取り装置１２０は次に、支払いのためのタップに対する要求を送信する。このタップは、読み取り装置１２０が、最初にセキュア・エレメント１１２から支払認証情報を要求することを可能とし、次に、読み取り装置アプリケーション１２１に、商業データ（例えば、クーポンデータ）をセキュア・エレメント１１２に送らせる。双方の機能は、読み取り装置１２０のところでモバイルデバイス１１０によって単一のタップで実施される。

先払い
先払いモードでは、支払いは、商業取引に先立って最初に実行することが可能である。このオプションは、支払い／ＰＰＳＥ過程がいかなる商業処理にも先んじなければならない状況に対応するものである。先払いモードは、上述の自動開始モードと手動開始モードの双方と共に動作する。支払いおよび商業の処理は、単一のタップで遂行される。

例示の商業過程フロー
通常の商業過程フロー（単一タップ）
図２は、例示の実施形態に関わる単一タップのタイミング図２００を示す。次の過程フローは、購入中の品目がＰＯＳのところで走査されている間に、開始することが可能である。便宜上、読み取り装置１２０（図１）およびＰＯＳ端末１４０（図１）を、１つの構成要素として図示し、集合的には支払い端末２０１と呼ぶ。各々の構成要素（すなわち、読み取り装置１２０またはＰＯＳ端末１４０）は、必要に応じて個々に参照される。

売主のＰＯＳシステム２０２は、支払い端末２０１の動作を制御する売主によって操作される売主サーバであり得る。例示の実施形態では、売主ＰＯＳシステム２０２は、支払い端末２０１に、品目が走査される前に、品目が走査されている間に、または品目が走査された後で、読み取り装置を起動するように指令する（「Ａｃｔｉｖａｔｅ Ｒｅａｄｅｒ（読み取り装置起動）」）。各々の場合において、読み取り装置１２０は、ステップ２５０（「Ｒｅｑｕｅｓｔ 'Ｔａｐ'（『タップ』を要求）」）に示すように、ユーザ（または消費者）に対して、モバイルデバイス１１０を読み取り装置１２０の近傍に置くように要求する。ユーザに対するモバイルデバイス１１０を読み取り装置１２０の近傍に置くことへの要求（ステップ２５０）に応答して、消費者は、ステップ２５１に示すように、モバイルデバイス１１０を読み取り装置１２０上にタップする。

一旦ＮＦＣ接続がモバイルデバイス１１０と読み取り装置１２０との間で確立されると、サービスの初期化と、支払い取引と商業取引との双方の処理のために次のコマンド交換が開始される。支払い取引の初期化と、セキュア・エレメント１１２と読み取り装置１２０との間の処理交換とはステップ２６０を含み、商業取引の初期化と、セキュア・エレメント１１２と読み取り装置１２０との間の処理交換とはステップ２６２を含む。ステップ２６０は、ステップ２６２の前に、後で、または実質的に同時に実施され得る。

最初にステップ２６２を参照すると、モバイルデバイスが読み取り装置１２０をタップした後で、読み取り装置１２０は、セキュア・エレメント１１２内のどの商業アプレット（例えば、商業アプレット１１３）と自身が協力することを求めているかを示す特定の商業ＡＩＤ（「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）」）と共にＳｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドを、セキュア・エレメント１１２に送る。それに応答して、セキュア・エレメント１１２は、肯定応答または否定応答を送る。否定応答（図示せず）は、結果として、読み取り装置１２０が、読み取り装置アプリケーション１２１を終了させて（図１）、制御権をＥＰＭ（図示せず）に送ることになる。この応答が肯定的（「Ｐｏｓｉｔｉｖｅ Ｒｅｓｐｏｎｓｅ（肯定応答）」）であれば、読み取り装置１２０は、コマンド（「Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）」）をセキュア・エレメント１１２に送って、売主／店舗識別子ならびに何らかのさらなるロイヤルティ、その位置でサポートされているオファーもしくは報酬のスキーム、データおよび時間の情報、読み取り装置１２０によってサポートされている読み取り装置商業アプリケーション１２１のバージョン、および何らかの商業機能データなどの識別情報を指定する。

セキュア・エレメント１１２は、読み取り装置１２０から受信されたＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンド中のフィールドに基づいて、対応する商業要素（例えば、ロイヤルティデータ、オファーデータ、報酬データ）（「Ｌｏｙａｌｔｙ ＆ Ｏｆｆｅｒｓ Ｄａｔａ（ロイヤルティ＆オファーデータ）」）を読み取り装置１２０に返送する。１つの実施形態では、商業アプレット１１３は、商業データ（例えば、ロイヤルティデータ、オファーデータ、または報酬データを含むバッファまたはバッファの集合）を含むパッケージを構築する。別の実施形態では、バッファは、セキュア・エレメント１１２中のメモリ空間を用いて事前構築される。

ステップ２６０を参照すると、１つの実施形態では、読み取り装置１２０は、ＰＰＳＥ要求（「ＰＰＳＥ Ｓｅｌｅｃｔ（ＰＰＳＥ選択）」）をセキュア・エレメント１１２に送ることによって、支払い処理を開始する。

Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）およびＰＰＳＥ Ｓｅｌｅｃｔ（ＰＰＳＥ選択）要求が成功であれば、ステップ２６４（「Ｒｅａｄ Ｓｕｃｃｅｓｓ Ｉｎｄｉｃａｔｉｏｎ（成功表示の読み出し）」）に示すように、支払い端末２０１は、それが受信した商業アプリケーションデータおよび支払認証情報（「Ｐａｙｍｅｎｔ ＆ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（支払い＆商業のデータ）」）を、処理目的で、売主ＰＯＳシステム２０２に転送する。売主ＰＯＳシステム２０２は、すると、製品走査がステップ２６６に示すように継続する間に、ロイヤルティ識別子およびオファー（図示せず）を記録して、何らかの適用可能な割引を適用する。これで、商業アプリケーション過程が終了し、支払い処理が進む。

一旦走査が完了して、支払いのための取引金額が承認されると、支払いプラットフォーム２０３に対する支払い認可要求がなされる（「Ｐａｙｍｅｎｔ Ａｕｔｈ Ｒｅｑｕｅｓｔ（支払い認可要求）」）。すると、支払いプラットフォーム２０３は、支払いが認可されたかどうかを示す認可結果（「Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｓｕｌｔ」）を返送する。

再度ステップ２６０を参照すると、１つの実施形態では、セキュア・エレメント１１２に対する読み取り装置１２０によるＰＰＳＥ Ｓｅｌｅｃｔ（ＰＰＳＥ選択）要求は、セキュア・エレメント１１２に、どの支払いアプレット（およびしたがって、どの対応する支払いネットワーク）を用いて支払い取引を実施すべきかを示すＰＰＳＥ支払いＡＩＤ（「ＰＰＳＥ Ｐａｙｍｅｎｔ ＡＩＤ」）を返送させる。それに応答して、読み取り装置１２０は、それが特定のアプレットをサポートしていることを示すＡＩＤ選択（「Ｓｅｌｅｃｔ ＡＩＤ」）を送る。支払いアプレット（例えば、図１、１１７）と関連付けられたファイル制御情報（ＦＣＩ）が、セキュア・エレメント１１２によって読み取り装置１２０に対して送られる。同様に、他の支払いおよびカードの情報が、セキュア・エレメント１１２によって読み取り装置１２０に送られる（「Ｐａｙｍｅｎｔ／Ｃａｒｄ Ｄａｔａ（支払い／カードデータ）」）。

図３は、例示の実施形態に関わる二重タップおよび取引後データの送信を含む商業過程フローを図示するタイミング図３００を示す。この実施形態は、売主が、モバイルデバイスに通信して返すデータを有している場合に用いることが可能である。便宜上、読み取り装置１２０（図１）およびＰＯＳ端末１４０（図１）を、１つの構成要素として図示し、集合的に支払い端末３０１と呼ぶ。各々の構成要素（すなわち、読み取り装置１２０またはＰＯＳ端末１４０）は、適用可能である場合に個々に参照される。一般に、ＰＯＳ端末１４０（図１）は、コマンド「Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｃｏｍｍａｎｄ（取引後コマンド）」を読み取り装置１２０に送ることによって、第２のタップを求める要求を開始する。読み取り装置１２０は、すると、消費者からの第２のタップを要求する。

売主ＰＯＳシステム３０２は、支払い端末３０１の操作を制御する売主によって操作される売主サーバであり得る。例示の実施形態では、売主ＰＯＳシステム３０２は、支払い端末３０１に対して、品目が走査される前に、品目が走査されている間に、または品目が走査された後で、読み取り装置１２０を起動する（「Ａｃｔｉｖａｔｅ Ｒｅａｄｅｒ（読み取り装置起動）」）ように指令する。各々の場合、読み取り装置１２０は、ステップ３５０（「Ｒｅｑｕｅｓｔ 'ｔａｐ'（『タップ』を要求）」）に示すように、ユーザに対して、モバイルデバイス１１０を読み取り装置１２０の近傍に位置付けるように要求する。モバイルデバイス１１０を読み取り装置１２０の近傍に位置付けるようにとのユーザに対する要求（ステップ３５０）に応答して、消費者は、ステップ３５１に示すように、モバイルデバイス１１０を読み取り装置１２０上にタップする。

一旦ＮＦＣ接続がモバイルデバイス１１０と読み取り装置１２０との間に確立されると、支払い取引と商業取引との双方のサービス初期化および処理のために、次のコマンド交換が開始される。支払い取引の初期化および、セキュア・エレメント１１２と読み取り装置１２０との間の処理交換は、ステップ３６０を含み、商業取引の初期化および、セキュア・エレメント１１２と読み取り装置１２０との間の処理交換は、ステップ３６２を含む。ステップ３６０は、ステップ３６２の前に、後で、または実質的に同時に実施され得る。

最初にステップ３６２を参照すると、モバイルデバイス１１０が読み取り装置１２０をタップした後で、読み取り装置１２０は、セキュア・エレメント１１２内のどの商業アプレット（例えば、商業アプレット１１３）と自身が協力することを求めているかを示す特定の商業ＡＩＤ（「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）」）と共にＳｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドを、セキュア・エレメント１１２に送る。それに応答して、セキュア・エレメント１１２は、肯定応答または否定応答を送る。否定応答（図示せず）は、結果として、読み取り装置１２０が、読み取り装置アプリケーション１２１を終了させて（図１）、制御権をＥＰＭ（図示せず）に渡すことになる。この応答が肯定的（「Ｐｏｓｉｔｉｖｅ Ｒｅｓｐｏｎｓｅ（肯定応答）」）であれば、読み取り装置１２０は、コマンド（「Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）」）をセキュア・エレメント１１２に送って、売主／店舗識別子ならびに、その位置でサポートされている何らかのさらなるロイヤルティおよびオファーのスキーム、日付および時間の情報、読み取り装置１２０によってサポートされている読み取り装置商業アプリケーション１２１のバージョン、および何らかの商業機能データなどの識別情報を指定する。セキュア・エレメント１１２は、読み取り装置１２０から受信されたＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンド中のフィールドに基づいて、対応する商業要素（例えば、ロイヤルティデータおよびオファーデータ）（「Ｌｏｙａｌｔｙ ＆ Ｏｆｆｅｒｓ Ｄａｔａ（ロイヤルティ＆オファーデータ）」）を読み取り装置１２０に返送する。１つの実施形態では、これは、データのパッケージ（本質的には、オファーおよびロイヤルティのデータを含むバッファまたはバッファの集合）を構築する商業アプレット１１３によって遂行される。別の実施形態では、バッファは、セキュア・エレメント１１２中のメモリ空間を用いて事前構築することが可能である。

次にステップ３６０を参照すると、１つの実施形態では、セキュア・エレメント１１２に対する読み取り装置１２０によるＰＰＳＥ Ｓｅｌｅｃｔ（ＰＰＳＥ選択）要求は、セキュア・エレメント１１２に、どの支払いアプレット（およびしたがって、支払いネットワーク）を用いて支払い取引を実施すべきかを示すＰＰＳＥ支払いＡＩＤ（「ＰＰＳＥ Ｐａｙｍｅｎｔ ＡＩＤ」）を返送させる。それに応答して、読み取り装置１２０は、それが特定のアプレットをサポートしていることを示すＡＩＤ選択（「Ｓｅｌｅｃｔ ＡＩＤ」）を送る。支払いアプレット（例えば、１１７）と関連付けられたＦＣＩが、セキュア・エレメント１１２によって読み取り装置１２０に対して送られる。同様に、他の支払いおよびカードの情報が、セキュア・エレメント１１２によって読み取り装置１２０に送られる（「Ｐａｙｍｅｎｔ／Ｃａｒｄ Ｄａｔａ（支払い／カードデータ）」）。Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）およびＰＰＳＥ ｓｅｌｅｃｔ（ＰＰＳＥ選択）要求が成功であれば、ステップ３６４に示すように、支払い端末３０１は、それが受信した商業アプリケーションデータおよび支払認証情報（「Ｐａｙｍｅｎｔ ＆ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（支払い＆商業のデータ）」）を、処理目的で、売主ＰＯＳシステム３０２に転送する。売主ＰＯＳシステム３０２は、すると、製品走査がステップ３６６に示すように継続する間に、ロイヤルティ識別子およびオファー（図示せず）を記録して、何らかの適用可能な割引を適用する。

一旦走査が完了して、取引金額が支払われたと承認されると、支払いプラットフォーム３０３に対する支払い認可要求がなされる（「Ｐａｙｍｅｎｔ Ａｕｔｈ Ｒｅｑｕｅｓｔ（支払い認可要求）」）。すると、支払いプラットフォーム３０３は、支払いがされたかどうかを示す認可結果（「Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｓｕｌｔ」）を返送する。

支払い端末３０１に返送するデータが存在する場合、売主ＰＯＳシステムは、正確に形式化されたＴＬＶを持つコマンド「Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）」を作成して、このデータを読み取り装置１２０に転送する。Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ（取引後）コマンドを受信すると、支払い端末３０１は、ステップ３６８（「Ｒｅｑｕｅｓｔ ２ｎｄ 'ｔａｐ'（２番目のタップを要求する）」）に示すように、消費者からの第２のタップを要求する。

ステップ３６９および３７０を参照すると、モバイルデバイス１１０は、ステップ３６９に示すように読み取り装置１２０の近傍内に２回目に位置付けられるとき、読み取り装置１２０は、セキュア・エレメント１１２内のどの商業アプレット（例えば、商業アプレット１１３）とそれが協力することを希望するかを示す特定の商業ＡＩＤ（「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）」）と共にＳｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドを、セキュア・エレメント１１２に送る。

否定応答が受信されると、読み取り装置１２０は、読み取り装置商業アプリケーション１２１を終了させる。肯定応答が受信されると、読み取り装置１２０は、ＰＯＳ端末１４０からのＰｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）コマンド（「Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）」）中で受信されたデータをセキュア・エレメント１１２に転送する。これで、この取引の商業処理が終了する。

図４は、例示の実施形態に関わる二重タップならびに取引後データおよび支払いの送信を含む商業過程フローを図示するタイミング図４００を示す。このシナリオでは、支払いデータおよび取引後データは、バスケットが合計され、すべての割引が適用された後で処理される。このフローの使用は、特定のビット（例えば、「Ｐａｙｍｅｎｔ ｗｉｔｈ Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ（取引後支払い）」がオンに設定された状態で読み取り装置開始モードデータ要素によって制御される。

便宜上、読み取り装置１２０（図１）およびＰＯＳ端末１４０（図１）を、１つの構成要素として図示し、集合的に支払い端末４０１と呼ぶ。各々の構成要素（すなわち、読み取り装置１２０またはＰＯＳ端末１４０）は、適用可能である場合に個々に参照される。一般に、売主ＰＯＳシステム４０２は、取引後データコマンドを読み取り装置１２０に送ることによって、第２のタップ要求を開始する。読み取り装置１２０は、すると、消費者からの第２のタップを要求する。

売主ＰＯＳシステム４０２は、支払い端末４０１の操作を制御する売主によって操作される売主サーバであり得る。例示の実施形態では、売主ＰＯＳシステム４０２は、支払い端末４０１に対して、品目が走査される前に、品目が走査されている間に、または品目が走査された後で、読み取り装置を起動する（「Ａｃｔｉｖａｔｅ Ｒｅａｄｅｒ（読み取り装置起動）」）ように指令する。各々の場合、読み取り装置１２０は、ステップ４５０（「Ｒｅｑｕｅｓｔ 'ｔａｐ'（『タップ』を要求）」）に示すように、ユーザに対して、モバイルデバイス１１０を読み取り装置１２０の近傍に位置付けるように要求する。モバイルデバイス１１０を読み取り装置１２０の近傍に位置付けるようにとのユーザに対する要求（ステップ４５０）に応答して、消費者は、ステップ４５１に示すように、モバイルデバイス１１０を読み取り装置１２０上にタップする。

一旦ＮＦＣ接続がモバイルデバイス１１０と読み取り装置１２０との間に確立されると、次のコマンド交換が開始される。サービスの初期化と、支払い取引および商業取引の双方の処理とのために、コマンド交換が実施される。支払い取引の初期化および、セキュア・エレメント１１２と読み取り装置１２０との間の処理交換は、ステップ４７２を含み、商業取引の初期化および、セキュア・エレメント１１２と読み取り装置１２０との間の処理交換は、ステップ４６２および４７４を含む。

最初にステップ４６２を参照すると、モバイルデバイスが読み取り装置１２０をタップした後で、読み取り装置１２０は、セキュア・エレメント１１２内のどの商業アプレット（例えば、商業アプレット１１３）と協力するかを示す特定の商業ＡＩＤ（「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）」）と共にＳｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドを、セキュア・エレメント１１２に送る。それに応答して、セキュア・エレメント１１２は、肯定応答または否定応答を送る。否定応答（図示せず）は、結果として、読み取り装置１２０が、読み取り装置アプリケーション１２１を終了させて（図１）、制御権をＥＰＭ（図示せず）に渡すことになる。この応答が肯定的（「Ｐｏｓｉｔｉｖｅ Ｒｅｓｐｏｎｓｅ（肯定応答）」）であれば、読み取り装置１２０は、コマンド（「Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）」）をセキュア・エレメント１１２に送って、売主／店舗識別子ならびに、その位置でサポートされている何らかのさらなるロイヤルティおよびオファーのスキーム、日付および時間の情報、読み取り装置１２０によってサポートされている読み取り装置商業アプリケーション１２１のバージョン、および何らかの商業機能データなどの識別情報を指定する。セキュア・エレメント１１２は、読み取り装置１２０から受信されたＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンド中のフィールドに基づいて、対応する商業要素（例えば、ロイヤルティデータおよびオファーデータ）を読み取り装置１２０（「Ｌｏｙａｌｔｙ ＆ Ｏｆｆｅｒｓ Ｄａｔａ（ロイヤルティ＆オファーデータ）」）に返送する。１つの実施形態では、これは、データのパッケージ（本質的には、オファーおよびロイヤルティのデータを含むバッファまたはバッファの集合）を構築する商業アプレット１１３によって遂行される。別の実施形態では、バッファは、セキュア・エレメント１１２中のメモリ空間を用いて事前構築することが可能である。

ステップ４６４で、読み取り装置１２０は、取引が完了したこと、および、ハンドセットが支払い端末４０１から除去することが可能であることを消費者に対して示し、これが、読み取り装置１２０に、商業アプリケーションデータをＰＯＳ端末１４０に転送させ、次に、処理目的で売主ＰＯＳシステムに転送させる（「Ｌｏｙａｌｔｙ ＆ Ｏｆｆｅｒｓ Ｄａｔａ（ロイヤルティ＆オファーデータ）」）。店員は、買い物バスケットを処理し続け得る。

売主ＰＯＳシステム４０２は、製品走査がステップ４６６に示すように継続する間に、ロイヤルティ識別子およびオファー（図示せず）を記録して、何らかの適用可能な割引を適用する。バスケットの合計が計算された後、売主ＰＯＳシステム４０２は、支払い要求を支払い端末４０１に送って、（送出用データが手元にあれば）取引後データを支払い端末４０１に送る（「Ｓｅｎｄ Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ ａｎｄ Ｐａｙｍｅｎｔ Ｒｅｑ（取引後データおよび支払い要求の送信）」）。

ステップ４６８で、支払い端末１４０は、支払いに対するタップを要求する。読み取り装置１２０は、すると、読み取り装置フィールドを起動する。モバイルデバイス１１０が読み取り装置１２０のフィールドで検出されたとき、支払い処理はステップ４７２に示すように実施される。特に、ＰＰＳＥ Ｓｅｌｅｃｔ（ＰＰＳＥ選択）要求は読み取り装置１２０によってセキュア・エレメント１１２に対してなされて、セキュア・エレメント１１２に、どの支払いアプレット（およびしたがって支払いネットワーク）を用いて支払い取引を実施すべきであるかを示すＰＰＳＥ支払いＡＩＤ（「ＰＰＳＥ Ｐａｙｍｅｎｔ ＡＩＤ」）を返送させる。それに応答して、読み取り装置１２０は、それが特定のアプレットをサポートしていることを示すＡＩＤ選択コマンド（「Ｓｅｌｅｃｔ ＡＩＤ」）を送る。支払いアプレット（例えば、図１、１１７）と関連付けられたＦＣＩが、セキュア・エレメント１１２によって読み取り装置１２０に送られる。同様に、他の支払いおよびカードの情報が、セキュア・エレメント１１２によって読み取り装置１２０に送られる（「Ｐａｙｍｅｎｔ／Ｃａｒｄ Ｄａｔａ（支払い／カードデータ）」）。

ステップ４７４を参照すると、支払い端末４０１が取引後データを売主ＰＯＳシステム４０２から受信した場合、読み取り装置１２０は、商業アプリケーション１２１（図１）を開始して、モバイルデバイスが読み取り装置１２０を二回目にタップした後で、特定の商業ＡＩＤと共にＳｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンド（「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）」）をセキュア・エレメント１１２に送る。Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）は、読み取り装置１２０と協力するために、セキュア・エレメント１１２内のどの商業アプレットを用いるべきであるかを特定する。それに応答して、セキュア・エレメント１１２は、肯定または否定の応答を送る。否定応答（図示せず）は、結果として、読み取り装置１２０が、読み取り装置アプリケーション１２１（図１）を終了させて、制御権をＥＰＭ（図示せず）に渡すことになる。応答が肯定的（「Ｐｏｓｉｔｉｖｅ Ｒｅｓｐｏｎｓｅ（肯定応答）」）であれば、読み取り装置１２０は、正確に形式化されたＴＬＶを持つ取引後データをセキュア・エレメント１１２に送る（「Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）」）。これで、この取引の商業処理が終了する。

Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）要求およびＰＰＳＥ Ｓｅｌｅｃｔ（ＰＰＳＥ選択）要求が成功すれば、支払い端末４０１は、それが受信した支払いアプリケーションデータおよび支払い認証情報を売主ＰＯＳシステム４０２に処理目的で転送する（「Ｐａｙｍｅｎｔ／Ｃａｒｄ Ｄａｔａ（支払い／カードデータ）」）。すると、売主ＰＯＳシステムは、支払い認可要求を支払いプラットフォーム４０３に送る（「Ｐａｙｍｅｎｔ Ａｕｔｈ Ｒｅｑｕｅｓｔ（支払い認可要求）」）。すると、支払いプラットフォーム４０３は、支払いが認可されたかどうかを示す認可結果（Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｓｕｌｔ）を返送する。

商業および支払いの認証情報と情報とが成功裏に読み取られた場合、読み取り装置１２０は、ステップ４７８（「Ｒｅａｄ Ｓｕｃｃｅｓｓ Ｉｎｄｉｃａｔｉｏｎ（成功表示の読み出し）」）に示すように、支払い端末１４０上のインターフェース、商業ウィジェット１１５（図１）または支払いウィジェット１１９（図１）を介して通知を提供することが可能である。

商業メッセージの規格
データの符号化
１つの実施形態では、全てのコマンド／応答のデータが、ＢＥＲ−ＴＬＶ（ＩＳＯ７８１６−４ Ａｎｎｅｘ Ｄ）形式を用いて符号化される。一部の場合では、ＴＬＶ（Ｔａｇ、Ｌｅｎｇｔｈ、Ｖａｌｕｅ）はネスティングされ得る（埋め込みＴＬＶ）。ＴＬＶ符号化形式のフレキシブルな性質のために、タグ付けされたデータは、どのような順序でも位置付けされ得る。これは、入力ペイロードおよび出力ペイロードの双方のデータを形式化する場合に当てはまる。加えて、このデータは、記録指向の表に記憶される。その中に記憶されるＴＬＶ符号化されたデータの要素の順序は重要ではないが、しかしながら、一部のデータは、索引／検索性能を向上させるために記録の最初に位置付けされ得る。したがって、この文書に提供される記憶データテーブルは、参照目的のサンプルとして供給される。

タグは、１つ以上の後続のバイト上に符号化されたプリミティブなデータオブジェクトを表す「プライベートな」タグクラスとタグタイプとを用いて符号化される。したがって、第１のバイト（タグクラス）は、０ｘＤＦに設定される。あらゆる場合において、データ要素タグは、１つのバイト上で定義される。したがって、第２のタグバイトは、０に設定された最高位ビット（ｂ８）を有する。これが、最大で１２８の有効なタグ値（０ｘ００〜０ｘ７Ｆ）を可能とする。

長さを符号化することによって、短い形式または長い形式の双方をサポートする。長さがその１２８バイト未満（＜）のとき、最高位ビット（ｂ８）は０に設定され、実際の長さは、残りのビット（ｂ７〜ｂ１）で指定される。長さが１２８バイトを超える（＞）とき、最高位ビット（ｂ８）は１に設定され（長さマスク＝０ｘ８０）、残りのビット（ｂ７〜ｂ１）は、長さフィールド中の後続のバイトの数を定義する。これらの後続のバイトは、値フィールド中のバイトの数に等しい整数を符号化する。

ＢＥＲ−ＴＬＶの例
入力データが、８バイトの長さおよび（０ｘ１１２２３３４４５５６６７７８８）の値を持つ０ｘ２１（消費者ＩＤ）のタグ値を用いると仮定すると、このデータは表１に示すように符号化される。

ＴＬＶ符号化は、長さのインジケータを複数バイトで表すことを可能とする。好ましくは、多バイト長がサポートされる。短い形式では、長さフィールドは、ビット８が０に設定され、ビット７〜１が、値フィールド中のバイト数を符号化する１バイトから成る。１バイトは、したがって、ゼロ〜１２７までの任意の数を符号化することが可能である。１〜１２７までのいかなる数も、ＬｃおよびＬｅのフィールド中でと同じ方法でＢＥＲ−ＴＬＶ長さフィールド中で符号化されている。符号化は、ゼロ、１２８、およびそれ以上とで異なる。例えば、以下に説明するＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンド中のデータオブジェクトのコーディングを参照のこと。

長い形式では、長さフィールドは、２バイト以上から成る。第１のバイトのビット８は１に設定され、ビット７〜１はすべてが等しいわけではなく、これで、長さフィールド中の後続のバイトの数を符号化する。これらの後続のバイトは、値フィールド中のバイトの数を符号化する。ＩＳＯ／ＩＥＣ７８１６は、１、２、・・・から最大で５バイトまでの長さフィールドをサポートするＡＮＳＩ ＩＳＯ／ＩＥＣ７８１６の基本的符号化規則によって指定された「不定長」は用いない（表２）。ＩＳＯ／ＩＥＣ７８１６では、「８０」および「８５」〜「ＦＦ」の値は、長さフィールドの第１のバイトにとっては無効である。

Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ Ａｐｐｌｅｔ（商業アプレット選択）
１つの実施形態では、読み取り装置１２０が、読み取り装置１２０のフィールド中のモバイルデバイス１１０を検出して、ＮＦＣ通信が開始した場合に処理が開始される。その場合に、読み取り装置１２０は、商業アプレットを選択するために、コマンド、特に「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）」コマンドをセキュア・エレメント１１２に送る。Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンド（「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ Ａｐｐｌｅｔ（商業アプレット選択）」コマンドとも呼ばれる）は、ＩＳＯ７８０１６−３規格中に定義されているように標準化される。例としてのＳｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドの構造を表３に示す。

モバイルデバイス１１０中のセキュア・エレメント１１２は、「Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）」コマンドを有効化して、適切な応答を送り返す。例としての応答（「ステータスコード」とも呼ばれる）を、表４に示す。

「９０ ００」（「成功したコマンド実行」）以外の全ての応答は、商業アプリケーション１２１（図１）に、読み取り装置１２０中で終了させて、制御権をＥＰＭに渡させる。

Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）
読み取り装置アプリケーション１２１が開始され、読み取り装置１２０とセキュア・エレメント１１２間の通信が開始されると、読み取り装置１２０は、コマンドをモバイルデバイス１１０に送って、商業データを獲得する（「Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）」）。例示のＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドは、以下の表５および６中に定義されている。この例では、特定のロイヤルティおよびオファーのデータが要求されている。「売主能力」フィールドは、どのフィールドが要求データおよび応答データ中に存在する必要があるかを判定するために、読み取り装置１２０によって利用される。

日付と時間スタンプの情報がオプションである。１つの実施形態では、日付時間は、ＰＯＳと同期している。この情報がＰＯＳから入手不可能である場合には、ＰＯＳ端末１４０からの日付／時間を用いることが可能である。日付および時間が入手不可能であれば、読み取り装置１２０は、日付時間スタンプデータ要素を送らない。

例示の実施形態では、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）要求中のデータ要素は、セットアップ時間において、読み取り装置１２０またはＰＯＳ端末１４０中で事前構成される。このデータは、読み取り装置１２０がインストールされ構成された後で修正し得る。

表７に、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドによって返送され得る可能なステータスワード値を定義する。

「６１ ｘｘ」または「９０ ００」以外のいかなる応答も、結果として、読み取り装置１２０が、エラーを記録して、商業ウィジェット１１５に転送するデータを記憶した後で、商業アプリケーション１２１を終了させて、制御権をＥＰＭに渡すことになる。

Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）要求が正確に形式化されると、セキュア・エレメント１１２上の商業アプレット１１３は、売主識別子（「Ｍｅｒｃｈａｎｔ＿ＩＤ」）、ロイヤルティ識別子（「Ｌｏｙａｌｔｙ＿ＩＤ」）、およびオファータイプコード（「Ｏｆｆｅｒ＿Ｔｙｐｅ＿Ｃｏｄｅ」）に基づいてデータをフィルタリングして、要求中のバージョン番号に基づいて読み取り装置１２０用の応答データを形式化する。商業アプレット１１３は、２つ以上のロイヤルティＩＤおよび複数のオファーメッセージを、財布中の構成に基づいて返送し得る。表８に、例示の応答データをリストアップする。

以下は、例示の応答データ解析サンプルである。ＮＦＣ読み取り装置（またはＰＯＳ端末）は、この商業データを、消費者、ロイヤルティ、および／またはオファーのデータを含み得るデータのストリングとして、ＰＯＳシステムに送達する。売主ＰＯＳシステムは、次に、このデータを解析して、ロイヤルティおよびオファーのデータを得て、売主の規格ごとにこのデータを処理する。

DF 21 10 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF DF 41 06
18 DB 6E 23 F4 0B DF 43 0D 02 31 38 44 42 36 45 32 33 46 34 30 42
DF 51 08 88 77 66 55 44 33 22 05 DF 53 09 02 42 41 31 38 37 36 35
34 DF 51 08 88 77 66 55 44 33 22 06 DF 53 0C 02 41 39 39 39 39 31
33 33 35 37 38 DF 51 08 88 77 66 55 44 33 22 07 DF 53 10 02 5A 58
31 37 39 35 36 37 35 34 38 33 31 43 46 DF 51 08 88 77 66 55 44 33
22 08 DF 53 0C 02 31 38 30 30 38 37 32 30 30 30 31 DF 51 08 88 77
66 55 44 33 22 09 DF 53 33 02 57 4B 52 50 31 32 33 34 35 36 37 38
39 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 50 57 50 57 50
57 50 57 50 57 50 57 50 57 50 57 50 57 50 57 50 40 A1

データ解析例

DF 21 10 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF
（消費者ＩＤ）

DF 41 06 18 DB 6E 23 F4 0B （ＭｏＣｏｍロイヤルティＩＤ）

DF 43 0D 02 31 38 44 42 36 45 32 33 46 34 30 42
（消費者ロイヤルティコード）

DF 51 08 88 77 66 55 44 33 22 05 （ＭｏＣｏｍオファーＩＤ）＃１

DF 53 09 02 42 41 31 38 37 36 35 34 （売主オファーコード）＃１

DF 51 08 88 77 66 55 44 33 22

取引後データ
上に説明したように、Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）コマンドは、売主ＰＯＳシステム（ＭＰＯＳ）からデータを戻して受信する機構を提供する。このコマンドは、売主ＰＯＳ端末１４０によって開始され、好ましくは、売主機能フィールドにサポートされる。例示の実施形態では、このコマンドは、２５５バイトの最大データサイズを持つ単一のデータフレームから成る。データの内容は、標準のＴＬＶ形式化を用いているが、また可変でもあり得る。このコマンドは、動的調停または取引後データ統合を可能とする。さらなるデータタグが、ＰＯＳ端末／ＭＰＯＳからのさらなるデータのモバイルデバイス１１０中のセキュア・エレメント１１２への送信目的で定義され得る。例示の取引後データコマンド（「Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）」）を表９および１０に示す。

マルチブロックデータの取り扱い
図５は、例としての実施形態に関わる例示のマルチブロックデータフローを示す。セキュア・エレメント１１２が送出する２５５バイトを超えるデータを有するとき、Ｇｅｔ Ｒｅｓｐｏｎｓｅ（応答取得）コマンド（Ｃ０）を用いて、残りの応答データを回収する。特に、このコマンドは、商業アプレット１１３が例えば、２５５バイトを超える応答データを送らなければならない場合に、残りのデータを獲得するために用いられる。

図５を参照すると、ユーザが商業対応のモバイルデバイス１１０を読み取り装置１２０にタップした後、読み取り装置１２０はＳｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドをモバイルデバイス１１０のセキュア・エレメント１１２に送る。肯定応答（「９０ ００」）は、読み取り装置１２０に、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドを送らせる。それに応答して、セキュア・エレメント１１２は、ロイヤルティおよびオファーのデータを返送する。図５に示すように、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）応答ステータスＳＷ１フラグは「６１」に設定され、ＳＷ２フラグは「００」に設定される。

Ｇｅｔ Ｒｅｓｐｏｎｓｅ（応答取得）コマンドは、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）応答中のＳＷ１フラグが「６１」に設定される場合にトリガされる。この例では、ＳＷ２フラグは「００」に設定されるが、それは、モバイルデバイス１１０上の商業アプレット１１３が、どれほど多くのデータが送られずに残っているか知り得ないからである。Ｇｅｔ Ｒｅｓｐｏｎｓｅ（応答取得）コマンドに対する後続の応答もまた、「６１」に設定されたＳＷ１フラグを含み、第２のＧｅｔ Ｒｅｓｐｏｎｓｅ（応答取得）コマンドに、モバイルデバイス１１０に対して読み取り装置１２０によって送られるようにする。

このシーケンスは、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）応答のＳＷ１フラグが「６１」以外の任意の値に設定された場合に終了する。例えば、図５に示すようなＧｅｔ Ｒｅｓｐｏｎｓｅ（応答取得）コマンドに対する応答としての「９０」のＳＷ１の値は、正常完了を示す。他のいかなるＳＷ１値も、エラーとしてログすることが可能である。

表１１に、Ｇｅｔ Ｒｅｓｐｏｎｓｅ Ｄａｔａ（応答データ取得）ＡＰＤＵコマンドの例示の設定を定義する。

残りのデータの実際の長さは、可変である。したがって、Ｌｅのデータ長は０ｘ００であり、これで、商業アプレット１１３が、可変長応答を管理することを可能とする。

表１２に、Ｇｅｔ Ｒｅｓｐｏｎｓｅ Ｄａｔａ（応答データ取得）ＡＰＤＵコマンドによって返送され得る可能なステータスワード値（「ステータスコード」）を定義する。

読み取り装置構成データ
１つの実施形態では、読み取り装置１２０の設置および構成中に、ある売主と商業とに固有のデータが、読み取り装置１２０中にロードされて保存される。このデータは、読み取り装置１２０からのＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドに記入するために読み取り装置１２０によって用いられる。これらのデータ要素は、新しい特徴として更新することが可能であり、機能は利用可能となる。

商業ＡＩＤ
上で説明したように、商業ＡＩＤは、Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドで送られる。このコマンドがモバイルデバイス１１０によって容認されれば、商業アプレット１１３が開始され、ＡＰＤＵコマンド／応答のフローが、読み取り装置１２０とセキュア・エレメント１１２との間で開始される。例示の実施形態では、商業ＡＩＤ値は、Ａ００００００４８５１００１０１０１である。この値は、読み取り装置１２０上でハードコードすることが可能である。１つの実施形態では、読み取り装置１２０は、部分的選択をサポートするためには必要ない。

Ｍｅｒｃｈａｎｔ＿ＩＤ
売主識別子（Ｍｅｒｃｈａｎｔ＿ＩＤ（ＤＦ３１））は、読み取り装置１２０上にロードすることが可能である。売主ＩＤは、サービスプロバイダによって割り当てられた値である。１つの実施形態では、この値は、ＭｏＣｏｍプラットフォーム操作者によって割り当てられる。これは、商業アプレット１１３に、ロイヤルティおよびクーポンのデータをフィルタリングして、適当な項目を読み取り装置１２０に送ることを可能とするために必要とされる。

Ｍｅｒｃｈａｎｔ＿Ｓｔｏｒｅ＿ＩＤ
売主店舗識別子値（Ｍｅｒｃｈａｎｔ＿ｓｔｏｒｅ＿ＩＤ（ＤＦ３２））は、読み取り装置１２０上にロードされ、かつサービスプロバイダによって割り当てられる値である。この値は、例えば、報告目的に用いることが可能である。

Ｌｏｙａｌｔｙ＿ＩＤ
ロイヤルティ識別子値（Ｌｏｙａｌｔｙ＿ＩＤ（ＤＦ４１））は、複数のロイヤルティＩＤがタップ中に要求された場合に用いられる。これは、二次ロイヤルティを売主能力（ＤＦ３３）中に設定することによって遂行される。これが、商業アプレット１１３が、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドに応答してさらなるロイヤルティ番号を返送することを可能とする。複数（例えば５つ）のさらなるＬｏｙａｌｔｙ＿ＩＤが、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）要求中にコーディングされる。

Ｏｆｆｅｒ＿Ｔｙｐｅ＿Ｃｏｄｅｓ
オファータイプのコード（Ｏｆｆｅｒ Ｔｙｐｅ Ｃｏｄｅｓ（ＤＦ５４））は、読み取り装置１２０上にロードされる。Ｏｆｆｅｒ Ｔｙｐｅ Ｃｏｄｅｓに割り当てられる値は、サービスプロバイダによって割り当てられる。この値は、オファーをフィルタリングして、適当な項目だけを読み取り装置１２０に送るために、商業アプレット１１３によって用いられる。複数のＯｆｆｅｒ＿Ｔｙｐｅ＿Ｃｏｄｅｓを、定義して、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンド中でセキュア・エレメント１１２に送ることが可能である。

Ｃｏｍｍｅｒｃｅ＿Ａｐｐｌｉｃａｔｉｏｎ＿Ｖｅｒｓｉｏｎ
商業アプリケーションバージョン番号（Ｃｏｍｍｅｒｃｅ＿Ａｐｐｌｉｃａｔｉｏｎ＿Ｖｅｒｓｉｏｎ）は、読み取り装置１２０上にロードして、読み取り装置１２０上のアプリケーションがコーディングされ、かつ証明された対象である商業読み取り装置規格のバージョンを表すことが可能である。

Ｍｅｒｃｈａｎｔ＿Ｃａｐａｂｉｌｉｔｉｅｓ
Ｍｅｒｃｈａｎｔ Ｃａｐａｂｉｌｉｔｉｅｓの値は、特定の売主によってサポートされる商業の特徴を表す。このデータ要素もまた、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドを形式化するために読み取り装置１２０によって用いられることが可能である。

Ｔｅｒｍｉｎａｌ＿Ｓｔａｒｔｕｐ＿Ｍｏｄｅ
端末開始モードコマンド（Ｔｅｒｍｉｎａｌ Ｓｔａｒｔ Ｍｏｄｅ（ＤＦ３４））は、読み取り装置１２０に対して、商業アプリケーション１２１を開始するために用いられる機構を提供することを指令する。このデータ要素は、セキュア・エレメント１１２には送られない。このデータ要素はまた、ハンドセット上で読み取り装置１２０とセキュア・エレメント１１２との間での処理フローを定義するために用いられる。

Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）フィールド
表１３に、Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドおよびＧｅｔ Ｃｏｍｍｅｒｃｅ Ｓｅｒｖｉｃｅｓ（商業サービス取得）コマンドを形式化するために読み取り装置１２０によって必要とされるデータの例示の定義を提供する。

商業アプレットバージョン形式
Ｃｏｍｍｅｒｃｅ Ａｐｐｌｅｔ Ｖｅｒｓｉｏｎ（商業アプレットバージョン）値は、２バイトの１６進法フィールドであり、第１のバイトがメジャーバージョン（ｘｘ）を含み、第２のバイトがマイナーバージョン（ｘｘ）を含んでいる。これらのフィールドは、読み取り装置１２０上に実装されている特定のバージョンの読み取り装置商業技法規格に従って更新される。例示の実施形態では、商業アプリケーション１２１の最初の公式の発表は０ｘ０１００である。

売主能力
売主能力フィールド（Ｍｅｒｃｈａｎｔ Ｃａｐａｂｉｌｉｔｉｅｓ Ｆｉｅｌｄ（ＤＦ３３））は、どの商業機能が売主によって実装されているかを判定する。読み取り装置１２０は、このフィールドをモバイルデバイス１１０に渡すことが可能であり、モバイルデバイス１１０はこの情報を用いて、Ｃｏｍｍｅｒｃｅ Ｄａｔａ Ｒｅｓｐｏｎｓｅ（商業データ応答）フレームと呼ばれる応答フレームを構築する。表１４に、例示の売主能力を示す。

消費者開始モード形式
商業開始モード形式値（Ｃｏｍｍｅｒｃｅ Ｓｔａｒｔ Ｍｏｄｅ（ＤＦ３４））は、読み取り装置１２０上の商業アプリケーション１２１を開始するために何の機構を用いるかを読み取り装置１２０に対して示す。１つの実施形態では、このデータ要素は、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンド中でモバイルデバイス１１０に送られない。別の実施形態では、このデータ要素はオプションである。表１５に、商業アプリケーション１２１を開始する為に例示の開始モードを用いることが可能であることを示す。例示の実施形態では、ビット７および８は、排他的であり、一時に１ビットしかオンされない。

読み取り装置メッセージの転送
モバイルデバイス１１０から商業アプリケーションデータを読み出している間に、読み取り装置１２０は、データを売主ＰＯＳシステムまたは、ＰＯＳ端末１４０上に常駐するＰＯＳアプリケーションに転送する。読み取り装置１２０は、ＡＰＤＵヘッダを取り外して、モバイルデバイス１１０からデータを非ブロック化する。タグ付けされたＴＬＶフレームは、次に、適当なプロトコルにラッピングされて、売主ＰＯＳシステムまたは、ＰＯＳ端末上で走行中のＰＯＳアプリケーションに、処理目的で転送される。

消費者応答データ記述
読み取り装置１２０との成功した対話中に、データはＰＯＳ売主システム（またはＰＯＳ端末）に返送される。この情報は、一般的には、売主が定義して消費者の財布にロードした消費者ロイヤルティ番号および／またはいくらかの数のオファーから成る。

消費者ＩＤ
消費者識別子（Ｃｏｎｓｕｍｅｒ ＩＤ）は、財布起動過程中に消費者と関連付けられた固有の識別子である。一般的には、消費者ＩＤは、消費者がたとえその財布を新しいモバイルデバイスまたは異なるモバイルネットワークに移動させても、消費者に付き添う。
好ましい実施形態では、たとえハンドセットが送るべきロイヤルティまたはオファーデータを有しない場合でも、消費者ＩＤは、毎回の商業関連対話に際にモバイルデバイスから読み取り装置に送られる。消費者ＩＤの提示は、支払いだけのタップに関連する特定の動作をトリガするために、売主ＰＯＳシステムによって用いることが可能である。

ロイヤルティＩＤ
ロイヤルティ識別子（Ｌｏｙａｌｔｙ ＩＤ）は、タップ事象中に要求された各々の消費者ロイヤルティ番号と共に送られる。ロイヤルティＩＤは、ＭｏＣｏｍプラットフォームによって割り当てられた各売主ロイヤルティプログラムに割り当てられた固有の値である。ほとんどの場合、読み取り装置によって受信されたロイヤルティＩＤは、Ｇｅｔ Ｃｏｍｍｅｒｃｅ ｄａｔａ（商業データ取得）コマンドによって構成された売主ＩＤと一致する。売主システムによるこの情報の使用はオプションである。

消費者ロイヤルティコード
消費者ロイヤルティコード（Ｃｏｎｓｕｍｅｒ Ｌｏｙａｌｔｙ Ｃｏｄｅ）は、特定の売主ロイヤルティプログラムに対して消費者に割り当てられたロイヤルティ番号と一致する。財布アプリケーション１１４は、複数のロイヤルティ番号がタップで提示されることを可能とする。システムが複数の消費者ロイヤルティコード用にセットアップされている場合、各々の消費者ロイヤルティコードは、その固有のロイヤルティＩＤに先行される。

オファーＩＤ
モバイル商業オファー識別子（Ｏｆｆｅｒ ＩＤ）は、商業関連のセッション中に送られた各々の消費者オファー番号と共に送られる。オファーＩＤは、消費者の財布に対して送達された各々のオファーに割り当てられた固有の値である。１つの実施形態では、ＭｏＣｏｍプラットフォームによって生成された２つのオファーＩＤが同じ値であるということはない。

売主オファーコード
売主オファーコード（「Ｍｅｒｃｈａｎｔ Ｏｆｆｅｒ Ｃｏｄｅ」または「Ｏｆｆｅｒ Ｎｕｍｂｅｒ」）は、売主によって生成されて、様々な手段によって消費者の財布アプリケーションにロードされる。この番号は、処理目的で、売主ＰＯＳシステム上で定義された同じオファーと一致する。単一の商業取引中に、複数の売主オファー（例えば１０の）が提示され得る。売主システムは、入力データを解析して、個々の売主オファーを抽出する。

商業応答データフィールド
表１６に、成功した商業取引後に、売主ＰＯＳシステムに返送され得る例示のデータ要素を定義する。

１つの実施形態では、データ要素「Ｔｅｒｍｉｎａｌ Ｓｔａｒｔ Ｍｏｄｅ」は、読み取り装置１２０に渡されるが、セキュア・エレメント１１２には渡されない。読み取り装置１２０は、この情報を用いて、Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ（商業選択）コマンドおよびＳｅｌｅｃｔ ＰＰＳＥ（ＰＰＳＥ選択）コマンドがいつセキュア・エレメント１１２に送られるかを制御する。

読み取り装置商業アプリケーション機能性
次の章は、読み取り装置１２０内の商業アプリケーションが実施する機能のリストを提供する。これらの機能のうち自動式のものもあり、ＰＯＳ端末または売主ＰＯＳからのＡＰＩコールを介してトリガされるものもある。

Ｓｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）コマンド
商業アプリケーションが読み取り装置１２０上で開始され、デバイスが読み取り装置１２０のフィールド中で検出された後、送られる最初のコマンドはＳｅｌｅｃｔ Ｃｏｍｍｅｒｃｅ ＡＩＤ（商業ＡＩＤ選択）である。このコマンドは、ＩＳＯによって割り当てられたＲＩＤ値と、商業サービスプロバイダによって生成されたＰＩＸ値とを含む。商業ＡＩＤ値は、Ａ００００００４８５１００１０１０１である。この値は、読み取り装置１２０上にハードコードされるべきである。

Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンド
Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｓｅｒｖｉｃｅｓ Ｄａｔａ（商業サービスデータ取得）コマンドは、セキュア・エレメント１１２に対する一般的なデータ要求である。Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）は、商業アプレット１１３に情報を通信する多くの必要なフィールドおよびオプションのフィールドを有する。商業アプレット１１３は、この情報を用いて、読み取り装置１２０に送る必要があるデータ要素を構築する。読み取り装置１２０は、売主能力記録中のフィールドを用いて、そのオプションフィールドをハンドセットに対する要求中に含める必要があるかを判定する。

取引後データ
Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）コマンドは、ＭＰＯＳからデータを戻して受信するための機構を提供するために作成された。このコマンドは、２５５バイトの最大データサイズを持つデータの単一フレームから成る。このデータの内容は、標準のＴＬＶ形式化を用いているが、内容は可変である。更なるデータタグは、ＰＯＳ端末／ＭＰＯＳからモバイルデバイス１１０中のセキュア・エレメント１１２に対して更なるデータを送信するように定義され得る。

ＮＦＣエラー回復
好ましい実施形態では、読み取り装置１２０は、ハンドセットがＮＦＣフィールドから早期に除去された場合に生成される読み取り装置エラーから回復することが可能である。読み取り装置１２０は、「ビープ音」を出力するスピーカまたは光によってなどで光学的指示を提供するディスプレイなどの障害インターフェースを介して消費者に対して読み出しエラーを信号通知する。消費者は、再度タップするように要請され、エラー中に進行中であった取引が再開される。商業取引およびＰＰＳＥ取引などの複数の取引が処理中である場合、読み取り装置１２０は、実行中の最後の過程を回復しようとする。

大規模データブロックサポート
例示の実施形態では、読み取り装置１２０は、複数の２５５バイトブロックのデータを、単一のタップ過程で、モバイルデバイス１１２に対して読み出しおよび書き込みをする。

日付および時間スタンプサポート
読み取り装置１２０が売主ＰＯＳシステムに対して接続性を有するとき、日付および時間は、取引の開始時に、ＰＯＳ端末から回収することが可能である。

ＴＬＶマスタータグ一覧
表１７は、商業ベースのアプリケーションによって用いられるデータ要素ならびに対応するタグ値および目標／最大バイトサイズを定義する。さらなる値が、限られた／固定した値範囲を持つ要素に対して提供されている。

表１８に、商業アプレット１１３によってサポートされている例示のＡＰＤＵコマンドのマスターリストを提供する。

特殊形式化されたデータ要素 商業データペイロードに含まれるデータ要素は、その要素に対して用いられたデータ符号化を特定する形式バイトを含み得る。データ符号化は、販売時点での適合性を保証する目的で売主によって指定される。形式化されたデータ値は、商業プラットフォームによって、財布アプリケーション１１４に供給される。したがって、プラットフォーム１３０と、財布１１４と、セキュア・エレメント１１２と、読み取り装置１２０／ＰＯＳ端末１４０（集合的に、「支払い端末」と呼ばれる）との間でのさらなる解釈／形式化は不必要である。データを適当に解釈してそれを処理目的で売主システムに供給することは、支払い端末（または売主ＰＯＳシステム）の役割である。

例示の実施形態では、次のデータ要素は次の形式値を含む。
・ロイヤルティアカウントコード（ＤＦ４３）
・オファーコード（ＤＦ５３）

表１９に、可能な形式バイト値およびそれらの対応する符号化規則を定義する。

最初のニブルに１６進法値「Ｆ」を含むＢＣＤ符号化されたデータ値は、奇数個の桁を含むデータストリームを特定するものとする。したがって、ＢＣＤデータストリーム１２３４５は、０ｘＦ１２３４５のように３バイトバッファで符号化される。

例示の実施例
図６は、本発明の例としての実施形態に関わる財布アプリケーションに対するグラフィカルユーザインターフェースによって生成されたウインドウまたは画面ショットを示す。この例示の実施例の目的のために、モバイルデバイス１１０は、メモリ１１１ｂに記憶されている一部の償還可能なオファーおよびロイヤルティカードを有する。

財布ホーム画面６０１は、一片の売主タイル６０４を特徴とする。タイルは、モバイル財布中に存在する償還可能なオブジェクト（例えば、償還可能なオファーまたはロイヤルティカード）を有する全ての売主に対して存在する。ユーザは、たとえば、タイルを左右にスワイプし、特定の売主を見つけ得る。一旦特定の売主が見つかったら、タイルは、売主オファービュー６０２を開けるように選択される。これは、列を作って待っている間に、または早期に（例えば、店舗をぶらぶらしている間に）など、取引をするに先立って、または取引をする直前に実行することが可能である。

売主オファービュー６０２は、財布中の利用可能な償還可能なオファー６０３のリストを提示する。償還不可能な特典も提示され得る。もし存在すれば、ロイヤルティカード６０５もまた提示され、売主オファービュー６０２からアクセス可能とされる。

選択された売主が商業可能な売主でない場合、商業取引に対するオファーをロードするオプションは提示されない。しかしながら、その売主が商業可能な売主であれば、１つ以上のボタンまたはアイコン６０６ａ、６０６ｂが提示されて、商業取引が目的でオファーがロードされることを可能とする。

ユーザはオファー（例えば、６０６ａ）を選択して、次に、画面の底部の「実施済み」バーを選択し得る。

例示の実施形態では、オファーの数に関する制限を、セキュア・エレメント１１２によって実施することが可能であり（例えば、１０個のオファー）、商業ウィジェット１１５のユーザインターフェースは、ユーザがオファーを起動している間に、この制限を実施する。「実施済み」バーは、選択されたオファーをセキュア・エレメント１１２中にロードするようにトリガされる。セキュア・エレメント１１２中の別の売主からオファーがあれば、それらは、新しいオファーがロードされると同じ時点で除去することが可能であり、これが、どの時点でも、１１２中には１つの売主からのオファーしか存在しないことを保証する。

セキュア・エレメントのロードが完了したとき、ユーザは、モバイルデバイス１１０を読み取り装置１２０にタップする。次に何が発生するかは、複数の要因に依存する。タップされた読み取り装置が商業要素を処理することが不可能であれば、選択された支払いカードが送られるが、商業要素（例えば、オファーまたはロイヤルティ認証情報）は送られない。タップ後メッセージは、読み取り装置インターフェースを介して提示されて、支払い認証情報が送られたことを示すが、その他の情報は何も示されない。

タップされた読み取り装置が商業要素を処理することが可能であるが、売主ＩＤが選択された売主と一致しない場合、オファーは送られない。セキュア・エレメント１１２中の商業アプレット１１３はこの売主ＩＤのロイヤルティカードを検索して、ロイヤルティの認証情報を、もしあれば、送信することが可能である。タップ後メッセージは、インターフェースを介して提示されて、事象が発生したことを示し、売主を特定し、ロイヤルティ認証情報（もしそれらが入手可能であれば）および支払い認証情報が送られたことを報告する。

タップされた読み取り装置が商業可能な読み取り装置であって、売主ＩＤが選択された売主と一致すれば、選択されたオファーと、売主のロイヤルティカード認証情報（もしあれば）とが送られる。モバイルデバイス１１０は、商業ウィジェット１１５のユーザインターフェースを介してタップ後メッセージを提示して、オファーとロイヤルティ（もし存在すれば）とが、支払いと共に送られたことを確認することが可能である。

タップに続いて、セキュア・エレメント１１２中にロードされたオファーは、ユーザがそれらを除去するまたは別の売主からのオファーを選択するまで、セキュア・エレメント１１２中に残される。代替的には、オファーが期限切れになれば、それは、財布の保守が実施された場合に、セキュア・エレメント１１２から除去される。例示の実施形態では、選択された売主は、ユーザが異なる売主を選択するまで、財布ホームページ上で「アクティブな」売主のままとなる。

インスタントオファー実装例
図７に、本発明の実施形態に関わる例示のインスタントオファー実装例を示すフロー図を示す。この実施形態では、モバイル商業（ＭｏＣｏｍ）プラットフォームは、売主ＰＯＳシステムと統合して、売主が消費者に対して利用可能とする財布アプリケーションおよび／またはインスタントオファーを用いることによってユーザがオファーを選択する機構を実装することが可能である。

モバイルデバイス上で起動する財布アプリケーションを用いて、消費者が、支払い端末を介して購入に対する支払いを行い、ロイヤルティおよびオファーを提示すること可能にすることができる。消費者がオファーを償還することが可能な１つの方法は、財布アプリケーションを介してオファーを選択し、チェックアウトで提示することである。

消費者はまた、財布アプリケーションを介して瞬時に償還することが可能なオファーを提供され得る。このようなオファーは、本明細書では「インスタントオファー」と呼ばれる。この特徴は、財布アプリケーションで起動するモバイルデバイスを用いて購入を行う消費者に報酬を与えることを可能にする。消費者はインスタントオファーから恩典を得るが、それは、とりわけ、財布アプリケーションを介してオファーを具体的に選択する必要がないからである。実装次第で、インスタントオファーは、消費者によって財布アプリケーションから明示的に選択されたオファーと共に用いることが可能である。オファーが消費者によって選択されたか「瞬時に」提供されたかとは無関係に、モバイルデバイス（例えば、セキュア・エレメント１１２）から回収された消費者識別子（「Ｃｏｎｓｕｍｅｒ ＩＤ」）値は、インスタントオファーを回収して償還するための鍵として用いられる。

図７を参照すると、１つの実施形態では、消費者は、チェックアウトで提示される財布アプリケーションからオファーを選択する。ブロック７０２で、支払いがＰＯＳで要求される。ブロック７０４で、支払いは非接触支払いではないことが判定されれば、ブロック７０６で、この支払過程は代替の手段で（例えば、現金を用いて）完了され、チェックアウト過程は完了される。ブロック７０４で、支払いは非接触支払いであると判定されれば、モバイルデバイスのユーザは、彼または彼女のモバイルデバイスを読み取り装置（例えば、上述の読み取り装置１２０）にタップすることを求められる。

それに応答して、モバイルデバイスは読み取り装置に対してタップされる。タップ事象中、読み取り装置と上述のモバイルデバイス上のセキュア・エレメントとの間で多くのデータ要素を通過させることが可能である。１つの実施形態では、支払いカードデータ、消費者ＩＤ、ロイヤルティ番号、およびオファーコードが、読み取り装置のタップ中に読み取り装置に対して渡される。この実施形態では、消費者ＩＤは、たとえタップが支払い目的のみであって、オファーが選択されていない取引の場合でさえも、読み取り装置に送られる。

ブロック７０８で、ＭｏＣｏｍ消費者ＩＤが存在しないことが判定された場合、ブロック７０６で、支払い過程が完了し、チェックアウト過程は支払いを処理することによって完了される。

ブロック７０８で、ＭｏＣｏｍ消費者ＩＤが存在することが判定された場合、ブロック７１０で、ＭｏＣｏｍオファー（例えば、財布アプリケーションを介してユーザによって選択されたオファー）が存在するかどうかについて判定される。ブロック７１０で、ＭｏＣｏｍオファーが存在すると判定された場合、ブロック７１２で、ＭｏＣｏｍインスタントオファーも定義されたかどうかについて判定される。ブロック７１２で、ＭｏＣｏｍインスタントオファーも定義されたと判定された場合、ＭｏＣｏｍオファー（すなわち、財布アプリケーションインターフェースを介してユーザによって選択されたオファー）とＭｏＣｏｍインスタントオファーとの双方が、ブロック７１４に示すように処理される。一旦ＭｏＣｏｍオファーおよび／またはＭｏＣｏｍインスタントオファーが処理されると、これらのオファーと関連付けられた支払いが、ステップ７０６に示すように処理される。

ブロック７１０で、ＭｏＣｏｍオファーが存在しないと判定された場合、ブロック７１６で、ＭｏＣｏｍインスタントオファーが定義されているかどうかについて判定される。定義されていなければ、支払いは、ステップ７０６に示すように完了する。ＭｏＣｏｍインスタントオファーが存在すると、ブロック７１６で判定された場合、Ｍｏｃｏｍインスタントオファーはブロック７１８で示すように処理され、ＭｏＣｏｍインスタントオファーと関連付けられた支払いは、ブロック７０６に示すように処理される。

ＭｏＣｏｍインスタントオファーが定義されているとブロック７１２で判定された場合、標準のＭｏＣｏｍオファーが、ブロック７２０で示すように処理され、ブロック７０６で、処理された支払いが完了される。

売主ＰＯＳシステムは消費者ＩＤの存在を利用して、インスタントオファーの使用をトリガすることが可能である。オファーは、例えば、ＭｏＣｏｍシステムを用いる売主が定義するセント割引またはパーセント割引のタイプのオファーであり得る。これは、例えば、特定の品目の購入に適用することが可能である。例示の実装例では、売主は、財布オファーがタップ中に提示された場合に、インスタントオファー機能性をオフまたはオンにするオプションを提供される。

インスタントオファーは、売主によって定義されて、次にその小売位置に分配することが可能である。このオファーはまた、関連付けられた特定の開始日付と終了日付とを有することも可能である。インスタントオファーを異なる地理的エリアに分配する機能は、考慮に入れることが可能である。

商業アプレットパッケージ／アプレット／インスタンス管理
次の章は、商業アプレット１１３（図１）のダウンロード／インストール中に用いられるＡＩＤ値およびアプリケーション固有のパラメータを定義する。表２０は、ＡＩＤを定義する。

アプレット固有のインストールパラメータ
消費者アプレットの初期商業サービスデータ特徴は、アプレット固有のインストールパラメータを介して供給され得る。このデータは、標準のＪａｖａＣａｒｄ ＡＩＤおよびインストールパラメータの後に続く。

これらのパラメータは、表２１に示すようにコーディングしなければならない。

メモリ要件
例示のメモリ規格を以下の表２２にリストアップする。第１のメモリ規格「パッケージダウンロード」は、商業アプレットパッケージをダウンロードするために必要とされる不揮発性（ＥＥＰＲＯＭ）メモリスペースの概算量を示す。第２のメモリ規格「インスタンス化」は、商業アプレットの新しいインスタンスを実体化するために必要とされるメモリの量を示す。最終的なメモリ要件「一時的なデータスペース」は、商業アプレットの各々のインスタンスによって用いられる揮発性（ＲＡＭ）メモリの量を示す。

データ管理
利用可能な商業（例えば、ロイヤルティ、オファー、報酬、など）のデータは、セキュア・エレメント１１２上の商業アプレット１１３内に記憶される。関連する商業データの全てが、３つの個別のデータテーブルに記憶される。これらのデータテーブルは、商業アプレット１１３によって管理される。さらなる商業データは、ハンドセット上の対応する商業ウィジェット１１５内に記憶／管理され得る。

１つの実施形態では、本明細書中に定義するデータ要素は、可変長を有する。したがって、全ての要素（固定長を持つものを含んだ）には、最大長が割り当てられる。その結果、全ての長さおよびバイトサイズの言及は、最大値と解釈すべきである。

商業データ
商業アプレット１１３は、全ての商業サービスアプリケーションによって共有されるいくつかのデータフィールドを管理する。これらのデータフィールドは、持続的データ変数中に記憶される。例示のデータ要素である消費者ＩＤを表２３に定義する。消費者／プラットフォーム鍵および証明書などのさらなる要素もまた記憶され得る。

ロイヤルティデータテーブル
商業アプレット１１３はまた、全ての消費者ロイヤルティデータの記憶／管理を可能とするロイヤルティデータテーブルを含む。

表２４に、ロイヤルティデータテーブルに含まれるデータ要素（および、ＴＬＶ符号化中に用いられるそれらの対応するタグ値）を定義する。

データは、記録指向のデータバッファ中に記憶されるが、そこでロイヤルティ識別子（「Ｌｏｙａｌｔｙ ＩＤ」）は、検索／回収のタスク用のキーフィールドとして利用される。

例示の実施形態では、ＴＬＶデータオーバーヘッドは、ＢＥＲ−ＴＬＶ符号化形式で必要とされる要素データオーバーヘッド（２バイトタグおよび３バイト長）当たり（最大で）５バイトを含む。

代替の実施形態では、索引（またはハッシュ表）は、ロイヤルティＩＤ検索タスクをスピードアップするために内部で作成され得る。

キャッシュド売主データテーブル
商業アプレット１１３はまた、所与の売主に関連した全てのデータの記憶／管理を可能とする売主キャッシュドデータテーブルを含む。この特徴は、性能を向上させるために、所与の売主に対する商業データを、財布アプリケーション１１４によって事前ロードすることを可能とする。

表２５に、キャッシュド売主データテーブルに含まれるデータ要素（および、ＴＬＶ符号化中に用いられるそれらの対応するタグ値）を定義する。

データは、記録指向のデータバッファ中に記憶されるが、そこで売主識別子（「Ｍｅｒｃｈａｎｔ ＩＤ」）は、検索／回収のタスク用のキーフィールドとして利用される。索引（またはハッシュ表）は、売主ＩＤ検索タスクをスピードアップするために内部で作成され得る。

例示の実施形態では、ＴＬＶデータオーバーヘッドは、ＢＥＲ−ＴＬＶ符号化形式で必要とされる要素データオーバーヘッド（２バイトタグおよび３バイト長）当たり（最大で）５バイトを含む。

取引ログ
商業アプレット１１３は、売主の販売時点でのＭｏＣｏｍプラットフォーム内での使用を追跡するために用いられる取引ログを含む。商業ウィジェット１１５およびセキュア・エレメント１１２の同期化タスク中、この取引ログは、後でＭｏＣｏｍプラットフォームとの無線（「ＯＴＡ」）同期化のために、商業ウィジェット１１５にまで送信される。

この取引ログの実際の内容は、売主の販売時点での取引過程中で読み取り装置１２０によって提供されたＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドデータ／パラメータによって異なる。Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）ＡＰＤＵコマンドを介して読み取り装置１２０によって商業アプレット１１３に送られるデータペイロードの正確なコピーは、その商業取引の記録内に記憶される。

取引ステータスは、商業データ処理の論理的結果に基づいて判定される。データ／処理エラーが商業アプレット１１３内で検出された場合、対応する内部エラーコードを取引ログに添付することが可能である。

次の表は、取引ログ中に含まれるデータ要素（および、ＴＬＶ符号化中に用いられたそれらの対応するタグ値）を定義する。

データは、記録指向データバッファ中に記憶される。可変のＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドのデータサイズがサポートされる。

ＴＬＶデータオーバーヘッドは、ＢＥＲ−ＴＬＶ符号化形式で必要とされる要素データオーバーヘッド（２バイトタグおよび３バイト長）当たり（最大で）５バイトを含む。

エラー管理
例示の実施形態では、エラー検出および管理は、２つの水準で取り扱われる。第一は、ＡＰＤＵコマンドの応答は、２バイトのステータスワードの結果値を含む。これらの応答は、ＩＳＯ７８１６−４によって標準化され、指示される。しかしながら、第２の水準のエラー取り扱いは、商業サービスアプレットによって内部で管理される。第２の水準の管理は、ＡＰＤＵコマンドに対する応答中での標準の０ｘ６９０９のステータス語の発行を含む。この応答に続いて、顧客は、２バイトの内部エラーコードを得るために、第２のコマンド（「Ｇｅｔ Ｉｎｔｅｒｎａｌ Ｅｒｒｏｒ Ｃｏｄｅ（内部エラーコード取得）」）を発行し得る。このコードは、表２７に相互参照され得る。表２７は、エラーがアプレット内のどこで、かつなぜ発生したかの詳細を提供する。

特に、表２７は、商業アプレットによってサポートされているＧｅｔ Ｉｎｔｅｒｎａｌ Ｅｒｒｏｒ Ｃｏｄｅ（内部エラーコード取得）ＡＰＤＵコマンドによって返送された全ての可能な内部エラーコードのマスターリストを提供する。

商業サービス
次の章は、商業アプレット１１３を介して利用可能なＡＰＤＵコマンドの詳細な説明を提供する。

ＡＰＤＵコマンド
商業アプレット１１３との全ての通信／データの交換は、ＩＳＯ７８１６基準中に定義されているＡＰＤＵコマンドを介して実施される。さらなる規制およびデータ取り扱いは、以下に説明する。

コマンドの使用制限
セキュリティ上の理由から、利用可能な商業サービスコマンドのサブ集合は、特定の接続モードに制限することが可能である。「接触（財布）モード」と呼ばれる１つの実施形態では、上の表１８に定義されているＡＰＤＵコマンドの全てが利用可能である。しかしながら、非接触モードでは、次のコマンドが許容される。
・Ｇｅｔ Ｖｅｒｓｉｏｎ（バージョン取得）
・Ｇｅｔ Ｉｎｔｅｒｎａｌ Ｅｒｒｏｒ Ｃｏｄｅ（内部エラーコード取得）
・Ｇｅｔ Ｒｅｓｐｏｎｓｅ（応答取得） （残りのデータ）
・Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）

いずれかの他のＡＰＤＵコマンドが非接触モードで送られた場合、例外処理が実行され、Ｉｎｔｅｒｎａｌ Ｅｒｒｏｒ Ｃｏｄｅ（内部エラーコード）が対応する無効コマンドモード値（０ｘ０１０２）に設定される。

１つの実施形態では、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドは、財布アプリケーション１１４が開かれている場合にしか成功裏には実行され得ない。財布アプリケーション１１４が消費者によって開始されたまたは終了された場合に、財布伴侶アプレット（ＷＣＡｐ）に通知し、それによって、それが監視、管理、および／またはセキュリティの機能を実施することが可能であるようにすることは、財布アプリケーション１１４の責任である。ＷＣＡｐアプレットは、すると、商業アプレットに、共有インターフェースを介して、財布アプリケーションの状態を通知する。ＷＣＡｐアプレットは、その全体が参照して本明細書に組み込まれる、「Ｓｙｓｔｅｍｓ， Ｍｅｔｏｈｏｄｓ，ａｎｄ Ｃｏｍｐｕｔｅｒ Ｐｒｏｇｒａｍ Ｐｒｏｄｕｃｔｓ Ｆｏｒ Ｓｅｃｕｒｉｎｇ Ａｎｄ Ｍａｎａｇｉｎｇ Ａｐｐｌｉｃａｔｉｏｎｓ Ｏｎ Ｓｅｃｕｒｅ Ｅｌｅｍｅｎｔｓ」という題名の米国特許出願第１３／８５７，４００号に開示されている。

データペイロード管理
商業アプレット１１３は、全ての必要なパラメータがデータペイロード中に含まれたことを確認する。しかしながら、ほとんどの場合、全ての無関連のデータ要素は無視することが可能であり、コマンドはそれでも正常に処理する。１つの実施形態では、長さ期待（Ｌｅ）値は、商業アプレット１１３によっては検証されない。値がゼロであり、それで商業アプレット１１３は、全ての利用可能なデータを、応答を介して送ることを可能とされる、と推定することが可能である。

Ｇｅｔ Ｖｅｒｓｉｏｎ（バージョン取得）
Ｇｅｔ Ｖｅｒｓｉｏｎ（バージョン取得）コマンドは、現在ロードされている商業アプレット１１３のバージョン情報を得るために用いられる。バージョンは、３バイト（ｘｘ．ｙｙ．ｚｚ）で記憶されるが、式中、ｘｘ＝発表バージョン、ｙｙ＝メジャーバージョン（ウェーブ）番号、ｚｚ＝マイナーバージョン番号である。この情報は、例えば、ＭｏＣｏｍプラットフォームによって割り当てられる、アプレットの開発またはパッケージング中に指定される、またはコード内に静止値として記憶されて、変更不可能である。

表２８に、Ｇｅｔ Ｖｅｒｓｉｏｎ（バージョン取得）ＡＰＤＵコマンドの設定を定義する。

１つの実施形態では、商業アプレットには何もデータは送られない。Ｌｃデータ長は０ｘ００である。

バージョン情報は、３バイトの応答内に含まれる。Ｌｅデータ長は０ｘ０３である。０ｘ００の長さもまた許容される。例示の応答データ要素は、表２９に定義されている。

表３０に、このコマンドによって返送され得る可能なステータスワード値を定義する。

Ｐｒｏｖｉｓｉｏｎ Ａｐｐｌｅｔ（アプレット供給）
アプレット供給コマンド「Ｐｒｏｖｉｓｉｏｎ Ａｐｐｌｅｔ（アプレット供給）」は、消費者ＩＤおよび、オプションとして関連するセキュリティデータ（鍵値および証明書）を含む消費者関連のデータの供給（または更新）を可能とする。新しい／更新されたデータ値は、コマンドデータを介して指定される。例示の実施形態では、Ｐｒｏｖｉｓｉｏｎ Ａｐｐｌｅｔ（アプレット供給）コマンドは、消費者ＩＤを更新するためにしか用いられ得ない。

表３１および３２は、Ｐｒｏｖｉｓｉｏｎ Ａｐｐｌｅｔ（アプレット供給）ＡＰＤＵコマンドの設定を定義する。

表３１に示す入力データは、ＴＬＶ符号化された供給データから成る。したがって、Ｌｃデータ長は可変である。

１つの実施形態では、商業アプレット１１３によって返送されるデータはない。Ｌｅデータ長は０ｘ００である。

表３３に、Ｐｒｏｖｉｓｉｏｎ Ａｐｐｌｅｔ（アプレット供給）コマンドによって返送され得る可能なステータスワード値を定義する。

Ｇｅｔ Ｃｏｎｓｕｍｅｒ Ｉｎｆｏ（消費者情報取得）
Ｇｅｔ Ｃｏｎｓｕｍｅｒ Ｉｎｆｏ（消費者情報取得）コマンドは、トークン所有者（すなわち、消費者）に関連する静止データのサブ集合を得るために用いられる。このデータは、次のものを含む：

消費者識別子
表３４に、Ｇｅｔ Ｃｏｎｓｕｍｅｒ Ｉｎｆｏ（消費者情報取得）ＡＰＤＵコマンドの設定を定義する。

商業アプレット１１３にはデータは何も送られない。Ｌｃデータ長は、例えば、０ｘ００である。アプレットによって返送される要求された消費者情報の実際の長さは、可変であり、利用可能な消費者データに固有である。したがって、Ｌｅデータ長は０ｘ００であり、アプレットが、可変長応答を管理することを可能とする。

応答データは、ＴＬＶ形式化されたデータストリームとして返送される。消費者ＩＤもまた、返送され得る。

表３６に、このコマンドによって返送され得る可能なステータスワード値を定義する。

Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）
Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドは、指定された売主／ロイヤルティ識別子およびサポートされているオファータイプに基づいて、指定された売主（または売主の集合）に対する商業情報（例えば、ロイヤルティ、オファー、および報酬）を提供する。このコマンドは、売主のＰＯＳシステム（例えば、ＰＯＳ端末）に付けられた読み取り装置１２０に対する単一の接触点を提供する。

日付／時間スタンプ、売主ＩＤ、店舗ＩＤ、商業プロトコルバージョン、および売主能力バイトは、入力データの一部として送ることが可能である。さらなるロイヤルティもまた、要求されたロイヤルティ情報を指定（フィルタリング）するために送られ得る。アプレットは、指定された売主／ロイヤルティプログラムＩＤを求めてロイヤルティデータテーブル（表５）を検索して、対応するロイヤルティデータを回収する。さらなるオファータイプコードもまた、要求されたオファー情報のタイプを指定するために入力データの一部として送られ得る。商業アプレット１１３は、指定された売主識別子／オファーコードを求めてキャッシュド売主データテーブル（表２５）を検索して、対応するオファーデータを回収する。

必要とされるパラメータは次を含む：
・日付／時間スタンプ
・売主ＩＤ
・店舗ＩＤ
・アプリケーションバージョン

一旦送信が成功裏に完了されると、アプレットは、商業データ要求を記憶するその取引ログ中にエントリを作成するものとする。

表３７および３８に、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）ＡＰＤＵコマンドの設定を定義する。

入力データは、日付／時間スタンプ（取引のログ動作用に用いられる）、売主識別子、店舗識別子、売主能力バイト、ならびに、１つ以上のさらなるロイヤルティ識別子（売主位置によってサポートされているロイヤルティプログラムを示す）およびさらなるオファーコード（売主位置によってサポートされているオファーのタイプを示す）を含むさらなるデータ要素の任意選択的な集合から成る。１つの実施形態では、売主が売主能力パラメータを指定しないと、売主ベースのロイヤルティおよびオファーのみをサポートするデフォルトモードが用いられる。

アプレットによって返送される要求された商業データの実際の長さは、利用可能なロイヤルティ／オファー関連のデータに固有の可変値である。したがって、Ｌｅデータ長は０ｘ００であり、アプレットが可変長の応答を管理することを可能とする。

応答データは、ＴＬＶ形式化されたデータストリームとして返送される。ＭｏＣｏｍプラットフォーム固有の消費者識別子および全ての関連するロイヤルティ／オファーデータは、単一のデータペイロード中で返送される。

消費者ＩＤ
消費者ＩＤはＴＬＶ形式で送られるが、この場合、データはタグＣＯＮＳＵＭＥＲ＿ＩＤ（０ＸＤＦ２１）を用いて送られる。１つの実施形態では、エラーが検出されない場合、消費者ＩＤは、常に返送されるものとする。

ロイヤルティ
１つの実施形態では、ロイヤルティデータの各々のインスタンスは、次のＴＬＶ符号化されたデータ要素から成るものとする：
・ロイヤルティ識別子
・ロイヤルティアカウントコード

このデータストリーム内で、第１のタグは、ロイヤルティ識別子タグ（Ｔ）バイト（０ｘＤＦ４１）を含むものとする。長さ（Ｌ）バイトは、ロイヤルティ識別子の長さを指定するものとする。値（Ｖ）は、すぐ後に続く対応するロイヤルティデータに対する長さＬの実際のロイヤルティ識別子を含むものとする。

第２のタグは、ロイヤルティアカウントコードタグ（Ｔ）バイト（０ｘＤＦ４３）を含むべきである。長さ（Ｌ）バイトは、前のロイヤルティ識別子にリンクされたアカウントコードデータの全長を指定するものとする。値（Ｖ）は、長さＬの実際のロイヤルティデータを含むものとする。

ロイヤルティデータテーブル内に見られる任意の更なるロイヤルティ識別子は、この同じ形式を用いてＴＬＶ符号化されたデータペイロードに添付される。

オファー
オファーデータの各々のインスタンスは、次のＴＬＶ符号化されたデータ要素から成るものとする。
・オファーＩＤ
・オファーコード

このデータストリーム内で、第１のタグは、オファーＩＤタグ（Ｔ）バイト（０ｘＤＦ５１）を含む。長さ（Ｌ）バイトは、オファーＩＤの長さを指定する。値（Ｖ）は、すぐ後に続く対応するオファーデータに対するオファーＩＤを含む。

第２のタグは、好ましくは、オファーコードタグ（Ｔ）バイト値（０ｘＤＦ５３）を含む。長さ（Ｌ）バイトは、オファータイプコードの長さを指定する。値（Ｖ）は、対応するオファーＩＤに対するオファーコードデータを含む。

オファーデータテーブル内に見受けられるいかなる更なるオファー識別子も、この同じ形式を用いて、ＴＬＶ符号化されたデータペイロードに添付される。例示の応答データが、表３９に定義されている。

商業アプレット１１３は、合計のデータ長が２５６バイトを超える場合に、（Ｇｅｔ Ｒｅｓｐｏｎｓｅ（応答取得）コマンドを用いて）複数の応答パケットの送信を管理する。表４０に、Ｇｅｔ Ｒｅｓｐｏｎｓｅ（応答取得）コマンドによって返送され得る可能なステータスワード値を定義する。

取引後データ
Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）コマンドは、売主ＰｏＳシステムまたは支払い端末が、償還されたクーポン、新しいオファー、電子領収書、または他の向上した商業データを含む取引後データを返送し得る方法を提供する。

表４１および４２に、Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）ＡＰＤＵコマンドの設定を定義する。

入力データは、ＴＬＶ符号化された供給データおよび認証目的のプラットフォーム署名から成る。したがって、Ｌｃデータ長は可変である。

データは、商業アプレット１１３によって返送される必要はない。Ｌｅデータ長は０ｘ００である。

表４３に、Ｐｏｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｄａｔａ（取引後データ）コマンドによって返送され得る可能なステータスワード値を定義する。

Ｇｅｔ Ｔｒａｎｓａｃｔｉｏｎ Ｌｏｇ（取引ログ取得）
Ｇｅｔ Ｔｒａｎｓａｃｔｉｏｎ Ｌｏｇ（取引ログ取得）は、取引ログ中に記憶されている全てのデータを得るために用いられる。このコマンドは、一般的には、ウィジェット目的の商業ウィジェットおよびセキュア・エレメントデータ同期化のタスクによって用いられる。

表４４に、Ｇｅｔ Ｔｒａｎｓａｃｔｉｏｎ Ｌｏｇ（取引ログ取得）ＡＰＤＵコマンドの設定を定義する。

１つの実施形態では、商業アプレットにはデータは送られない。Ｌｃデータ長は０ｘ００である。アプレットによって返送される取引データの実際の長さは、取引記録の数と対応する取引ログデータの可変長とによって、変化し得る。したがって、Ｌｅデータ長は０ｘ００で、商業アプレット１１３が、可変長応答を管理することを可能とする。

好ましくは、応答データは、ＴＬＶ形式化されたデータストリームとして返送される。

取引ログ応答データ
各々の取引ログ記録は、埋め込みＴＬＶ取引ログタグとそれに続く全ての関連するデータ要素とから成りたつものとする。取引記録に含まれるデータ要素は、売主の販売時点での商業対応の支払い端末（ＮＦＣ読み取り装置）によって要求される対応するＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンド中に提供されるもののミラーである。さらなる取引得ログ記録は、同じ形式を用いてデータに添付される。表４５に、例示の応答データを示す。

１つの実施形態では、商業アプレット１１３は、合計のデータ長が２５６バイトを超える場合に、Ｇｅｔ Ｒｅｓｐｏｎｓｅ（応答取得）コマンドを用いて複数の応答パケットの送信を管理する。

取引ログステータス応答データ
取引ログステータスが要求されたとき、商業アプレットは、埋め込みＴＬＶデータペイロード内のステータス情報で応答する。このデータは、利用可能な取引ログ記録の数、ロイヤルティ、および最後の取引中に送られたオファー記録を含む。これは、共有インターフェースを介してＷＣＡｐに提供された同じデータペイロードである。表４６に、例示の応答データを示す。

表４７に、Ｇｅｔ Ｔｒａｎｓａｃｔｉｏｎ Ｌｏｇ（取引ログ取得）コマンドによって返送され得る可能なステータスワード値を定義する。

Ｇｅｔ Ｉｎｔｅｒｎａｌ Ｅｒｒｏｒ Ｃｏｄｅ（内部エラーコード取得）
Ｇｅｔ Ｉｎｔｅｒｎａｌ Ｅｒｒｏｒ Ｃｏｄｅ（内部エラーコード取得）コマンドは、商業サービスアプレットによって生成された最後の内部エラーコードを回収するために用いられる。このコードは、内部エラーコード表（表２６）と相互参照されて、エラーのより具体的な説明を提供することが可能な値を提供する。このコマンドは、より詳細な診断およびエラー解決のために用いられる。

表４８は、Ｇｅｔ Ｉｎｔｅｒｎａｌ Ｅｒｒｏｒ Ｃｏｄｅ（内部エラーコード取得）ＡＰＤＵコマンドの設定を定義する。

１つの実施形態では、アプレットにはデータは送られない。Ｌｃデータ長は０ｘ００である。エラーコードは、２バイトの応答内に含まれる。したがって、Ｌｅデータ長は０ｘ０２である。

次の表は、このコマンドによって返送され得る可能なステータスワード値を定義する。

ロイヤルティサービス
Ｇｅｔ Ｌｏｙａｌｔｙ Ｄａｔａ（ロイヤルティデータ取得）
表５０および５１に定義されているＧｅｔ Ｌｏｙａｌｔｙ Ｄａｔａ（ロイヤルティデータ取得）コマンドは、記憶されているロイヤルティ情報を、指定されたロイヤルティ識別子に基づいて得るために用いられる。２バイトのロイヤルティ識別子は、要求されるロイヤルティ情報を指定するために、入力データの一部として送られ得る。商業アプレット１１３は、指定された売主／ロイヤルティＩＤを求めてロイヤルティデータの表を検索して、対応するロイヤルティデータの全てを回収する。

（オプションの）入力データは、要求されたロイヤルティ情報を示すＴＬＶ符号化されたロイヤルティ識別子から成るものとする。Ｌｃが０ｘ００（データ入力データは何も指定されない）に設定されると、全ての利用可能なロイヤルティ識別子は返送される。

アプレットによって返送された要求されたロイヤルティデータの実際の長さは、要求された／利用可能なロイヤルティデータに固有の変更可能な値である。したがって、Ｌｅデータ長は０ｘ００であって、アプレットが可変長応答を管理することを可能とする。

応答データ（表５１）は、ＴＬＶ形式化されたデータストリームとして返送される。関連するロイヤルティデータの全てが、単一のデータペイロード中で返送される。

１つの実施形態では、ロイヤルティデータダンプが要求されると（Ｌｃ＝０ｘ００）、全てのロイヤルティ識別子のリストが、ＬＶ（タグなし）形式で返送される。したがって、各々のエントリに対するロイヤルティ識別子だけが、データペイロード中に含まれる。

ロイヤルティデータの各々のインスタンスは、次のデータ要素を含む：
・ロイヤルティ識別子
・ロイヤルティアカウントコード

表５３に、このコマンドによって返送され得る可能なステータスワード値を定義する。

Ｕｐｄａｔｅ Ｌｏｙａｌｔｙ Ｄａｔａ（ロイヤルティデータの更新）
Ｕｐｄａｔｅ Ｌｏｙａｌｔｙ Ｄａｔａ（ロイヤルティデータの更新）コマンドは、指定された売主ロイヤルティデータを追加または更新するために用いられる。このデータはＴＬＶ形式化されたデータストリームとして送られる。指定されたロイヤルティ識別子が存在すれば、対応するロイヤルティデータ要素が更新される。ロイヤルティ識別子が存在しなければ、新しいデータ記録が、ロイヤルティデータテーブル中に作成される。表５４および５５に、Ｕｐｄａｔｅ Ｌｏｙａｌｔｙ Ｄａｔａ（ロイヤルティデータの更新）ＡＰＤＵコマンドの設定を定義する。

入力データは、ＴＬＶ符号化されたロイヤルティデータから成ることとする。したがって、Ｌｃデータ長は可変である。１つの実施形態では、アプレットによって返送されるデータはない。Ｌｅデータ長は０ｘ００である。

表５６に、このコマンドによって返送され得る可能なステータスワード値を定義する。

Ｄｅｌｅｔｅ Ｌｏｙａｌｔｙ Ｄａｔａ（ロイヤルティデータの削除）
Ｄｅｌｅｔｅ Ｌｏｙａｌｔｙ Ｄａｔａ（ロイヤルティデータの削除）コマンドは、指定された売主ロイヤルティデータを削除するために用いられる。１バイトの売主コードが、コマンドデータを介して指定される。代替的には、Ｐ２バイトが、全ての既存のオファーを消去するために用いられ得る。Ｐ２が０ｘＦＦに設定されると、オファーデータストア全体が削除される。

表５７および５８に、Ｄｅｌｅｔｅ Ｌｏｙａｌｔｙ Ｄａｔａ（ロイヤルティデータの削除）ＡＰＤＵコマンドの設定を定義する。

入力データは、ＴＬＶ符号化されたロイヤルティ識別子から成る。したがって、Ｌｃデータ長は可変である。

１つの実施形態では、商業アプレット１１３によって返送されるデータはない。Ｌｅデータ長は０ｘ００である。

表５９に、Ｄｅｌｅｔｅ Ｌｏｙａｌｔｙ Ｄａｔａ（ロイヤルティデータの削除）コマンドによって返送され得る可能なステータスワード値を定義する。

キャッシュド売主データサービス
Ｇｅｔ Ｃａｃｈｅｄ Ｍｅｒｃｈａｎｔ Ｄａｔａ（キャッシュド売主データ取得）
Ｇｅｔ Ｃａｃｈｅｄ Ｍｅｒｃｈａｎｔ Ｄａｔａ（キャッシュド売主データ取得）コマンドは、特定の売主に関連する全ての以前にロードされたデータを得るために用いられる。売主識別子は、要求される事前ロードされたデータを指定するために入力データの一部として送られ得る。商業アプレットは、もし提供されれば、指定された売主識別子を求めてキャッシュド売主データのテーブルを検索して、対応するデータの全てを回収する。このコマンドもまた、商業サービスアプレット内に記憶されている全てのキャッシュド売主に関する情報を得るために用いられ得る。

表６０は、Ｇｅｔ ｃａｃｈｅｄ Ｍｅｒｃｈａｎｔ Ｄａｔａ（キャッシュド売主データ取得）ＡＰＤＵコマンドの設定を定義する。

１つの実施形態では、アプレットにはデータは送られない。Ｌｃデータ長は０ｘ００である。アプレットによって返送された要求されるキャッシュド売主データの実際の長さは、要求された／利用可能なキャッシュド売主データに固有であって、可変である。したがって、Ｌｅデータ長は０ｘ００であり、アプレットが可変長応答を管理することを可能とする。

応答データ（表６１）は、ＴＬＶ形式化されたデータストリームとして返送され得る。キャッシュドデータの全てが、単一のデータペイロードで返送される。キャッシュド売主データの各々のインスタンスは、次の対応するキャッシュド売主データ要素（もし利用可能であれば）を含む：
・売主識別子
・ロイヤルティ識別子
・ロイヤルティアカウントコード
・オファー識別子
・オファーコード

例示の実施形態では、キャッシュド売主データは、財布アプリケーションによってロード／管理されるが、その特定の売主に関連する複数のオファーＩＤ／コードを含み得る。しかしながら、アプレットは、消費者識別子を応答データの前に付けて、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドによって要求された何らかのさらなるロイヤルティ／オファーデータを添付するものとする。

表６２に、このコマンドによって返送され得る可能なステータスワード値を定義する。

Ｕｐｄａｔｅ Ｃａｃｈｅｄ Ｍｅｒｃｈａｎｔ Ｄａｔａ（キャッシュド売主データの更新）
Ｕｐｄａｔｅ Ｃａｃｈｅｄ Ｍｅｒｃｈａｎｔ Ｄａｔａ（キャッシュド売主データの更新）コマンドは、指定された売主に対するキャッシュド（迅速な応答）データを更新するために用いられる。このデータは、Ｇｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）コマンドによって返送される応答に類似して、ＴＬＶ形式化されたデータストリームとして送られる。このコマンドは、所与の売主のＧｅｔ Ｃｏｍｍｅｒｃｅ Ｄａｔａ（商業データ取得）応答を事前ロードするために用いられる。

表６３および６４に、Ｕｐｄａｔｅ Ｃａｃｈｅｄ Ｍｅｒｃｈａｎｔ Ｄａｔａ（キャッシュド売主データの更新）ＡＰＤＵコマンドの設定を定義する。

入力データは、埋め込みＴＬＶ符号化キャッシュド売主データから成る。したがって、Ｌｃデータ長は可変である。

商業アプレットは、キャッシュド売主データバッファ中に残っている利用可能なバイトの数を含む２バイトの応答を返送する。したがって、Ｌｅデータ長は０ｘ０２（または０ｘ００）である。

コマンドによって返送された応答データ（表６５）は、キャッシュド売主データバッファ中で利用可能な残っているバイトの数を表す２バイト（短い）値から成る。これは、財布アプリケーション１１４が、どれほど多くのキャッシュドオファーが商業サービスアプレットに「適合する」ことが可能であるかを管理することを可能とする。

表６６に、このコマンドによって返送され得る可能なステータスワード値を定義する。

表６７に、本明細書に記述する例としての態様に関わる商業ベースのアプリケーションによって用いられるデータ要素ならびに対応するタグ値および目標／最大バイトサイズを定義する。さらなる値は、制限された／固定された値範囲を持つ要素に対して提供されている。

特殊形式化されたデータ要素
商業データペイロードに含まれるデータ要素のうちの少しの要素は、その要素に対して用いられるデータ符号化を識別する形式バイトを含む。このデータ符号化は、販売時点での適合性を保証するために、売主によって指定される。形式化されたデータ値は、ＭｏＣｏｍプラットフォームによって財布アプリケーションに供給される。したがって、プラットフォームと、財布と、セキュア・エレメントと、支払い端末との間にさらなる解釈／形式化は必要ない。データを適当に解釈して、それを処理目的で売主システムに供給することは、支払い端末（または売主ＰＯＳシステム）の役割である。

次のデータ要素は、形式バイトを含むものとする：
・ロイヤルティアカウントコード
・オファーコード

表６８に、可能な形式バイト値とそれらの対応する符号化規則とを定義する：

１６進法値「Ｆ」を最初のニブル中に含むＢＣＤ符号化されたデータ値は、奇数個の桁を含むデータストリームを特定する。したがって、ＢＣＤデータストリーム１２３４５は、０ｘＦ１２３４５などの３バイトのバッファ中に符号化される。

コンピュータ読み取り可能媒体実装例
例えば、図１〜７に示したまたはこれらに関連して述べたシステムおよび手順などの上述の例としての実施形態またはそれらの任意の部分もしくは機能は、ハードウエア、ソフトウエア、またはこれら２者の組み合わせを用いることによって実装され得る。それは、１つ以上のコンピュータまたは他の処理システム中に実装され得る。これらの例としての実施形態によって実施される操作は、人間の操作者によって実施される知的操作と通常関連付けられる用語で呼ばれ得たが、本明細書に説明する操作のうちのそれを実施するためにも人間の操作者は必要ない。言い換えれば、これらの操作は、機械の操作で完全に実装され得る。本明細書に提示する例としての実施形態の操作を実施するのに有用な機械は、汎用のデジタルコンピュータまたは類似のデバイスを含む。

図８は、発明の例としての実施形態の一部に関わる汎用および／または特殊目的コンピュータ８００のブロック図である。コンピュータ８００は、とりわけ、例えば、ユーザデバイス、ユーザコンピュータ、顧客コンピュータおよび／またはサーバコンピュータであり得る。

コンピュータ８００は、制限なく、処理装置８１０、メインメモリ８２５、および相互接続バス８０５を含み得る。処理装置８１０は、制限なく、単一のマイクロプロセッサを含み得る、または、コンピュータ８００をマルチプロセッサシステムとして構成するために、複数のマイクロプロセッサを含み得る。メインメモリ８２５は、とりわけ、処理装置８１０による実行目的のための命令および／またはデータを記憶する。メインメモリ６２５は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）のバンクおよびキャッシュメモリを含み得る。

コンピュータ８００は、大容量記憶装置８３０、周辺機器８４０、携帯記憶媒体装置８５０、入力制御装置８８０、グラフィックスサブシステム８６０、および／または出力ディスプレイ８７０をさらに含み得る。説明目的で、コンピュータ８００中の全ての構成要素を、バス８０５を介して連結されているものとして図８には示す。しかしながら、コンピュータ８００は、そのようには制限されない。コンピュータ８００のデバイスは、１つ以上のデータ輸送手段を介して連結され得る。例えば、処理装置８１０および／またはメインメモリ８２５は、ローカルマイクロプロセッサバスを介して連結され得る。大容量記憶装置８３０、周辺機器８４０、携記憶媒体媒体装置８５０、および／またはグラフィックスサブシステム８６０は、１つ以上の入／出力（Ｉ／Ｏ）バスを介して連結され得る。大容量記憶装置８３０は、処理装置８１０によって用いられるデータおよび／または命令を記憶するための不揮発性ストレージデバイスであり得る。大容量記憶装置８３０は、例えば、磁気ディスクドライブまたは光ディスクドライブと共に実装され得る。ソフトウエア実施形態では、大容量記憶装置８３０は、大容量記憶装置８３０の内容をメインメモリ８２５中にロードするように構成される。

携帯記憶媒体装置８５０は、例えば、コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）などの不揮発性携帯記憶媒体と共に動作して、コンピュータ８００に対しておよびこれからデータおよびコードを入力および出力する。一部の実施形態では、内部識別子をメタデータ中に記憶するソフトウエアは、携帯記憶媒体上に記憶され得る、または、携帯記憶媒体デバイス８５０を介してコンピュータ８００中に入力され得る。周辺機器８４０は、例えば、コンピュータ８００にさらなる機能性を追加するように構成された入／出力（Ｉ／Ｏ）インターフェースなどの任意のタイプのコンピュータサポートデバイスを含み得る。例えば、周辺機器８４０は、コンピュータ８００をネットワーク８２０にインターフェースさせるネットワークインターフェースカードを含み得る。

入力制御装置８８０は、コンピュータ８００のユーザに対するユーザインターフェースの１部分を提供する。入力制御装置８８０は、キーパッドおよび／またはカーソル制御装置を含み得る。キーパッドは、英数字および／または他のキーの情報を入力するように構成され得る。カーソル制御装置は、例えば、マウス、トラックボール、スタイラス、および／またはカーソル方向キーを含み得る。原文および図形の情報を表示するために、コンピュータ８００は、グラフィックスサブシステム８６０および出力ディスプレイ８７０を含み得る。出力ディスプレイ８７０は、陰極線管（ＣＲＴ）ディスプレイおよび／または液晶表示（ＬＣＤ）を含み得る。グラフィックスサブシステム８６０は、原文および図形の情報を受信して、その情報を、出力ディスプレイ８７０に出力するために処理する。

コンピュータ８００の各々の構成要素は、汎用および／または特殊目的のコンピュータの広いカテゴリコンピュータ構成要素を表し得る。コンピュータ８００の構成要素は、本明細書に提供される特定の実装例には制限されない。

本発明の例としての実施形態の諸部分は、コンピュータの当業者には明らかなように、本開示の挟持に従ってプログラムされた従来の汎用コンピュータ、特殊目的デジタルコンピュータ、および／またはマイクロプロセッサを用いることによって便利に実装され得る。適切なソフトウエアコーディングは、本開示の挟持に基づいて、熟練したプログラマによって容易に準備され得る。

一部の実施形態はまた、特定用途向け集積回路、フィールドプログラム可能ゲートアレイを準備することによって、または、従来の構成要素回路の適切なネットワークを相互接続することによって実施され得る。

一部の実施形態は、コンピュータプログラム製品を含む。コンピュータプログラム製品は、コンピュータを制御または、それに、本発明の例としての実施形態の手順の任意のものを実施させるために用いることが可能な命令をその上にまたはその中に記憶する記憶媒体または媒体であり得る。記憶媒体は、制限なく、フロッピディスク、ミニディスク、光ディスク、Ｂｌｕ−Ｒａｙ Ｄｉｓｃ、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、磁気光ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ、フラッシュカード、磁気カード、光カード、ナノシステム、分子メモリ集積回路、ＲＡＩＤ、遠隔データストレージ／アーカイブ／ストア、および／または命令および／またはデータを記憶するために適切な任意のタイプのデバイスを含み得る。

１つまたは複数のコンピュータ読み取り可能のうちの任意の１つ上に記憶されている、一部の実装例は、汎用および／または特殊目的コンピュータまたはマイクロプロセッサのハードウェアの双方を制御するための、および、コンピュータまたはマイクロプロセッサが、本発明の例としての実施形態の結果を利用する人間のユーザまたは他の機構と対話することを可能とするためのソフトウエアを含む。このようなソフトウエアは、制限なく、デバイスドライバ、オペレーティングシステム、およびユーザアプリケーションを含み得る。究極には、このようなコンピュータ読み取り可能媒体は、上述したように、本発明の例としての態様を実施するソフトウエアをさらに含む。

汎用および／または特殊目的コンピュータもしくはマイクロプロセッサのプログラミングおよび／またはソフトウエアに含まれるものには、上述の手順を実施するソフトウエアモジュールがある。

本発明の様々な例としての実施形態を上述したが、それらは例として提示されたものであり、制限目的ではないことを理解すべきである。形態および詳細の様々な変更が可能であることが当業者には明らかである。したがって、本発明は、上述した例としての実施形態のどれによっても制限されるべきではなく、次の請求の範囲およびそれらの均等物にしたがってのみ定義されるべきである。

加えて、図面は例示目的のみで提示されていることを理解すべきである。本明細書に提示する例としての実施形態のアーキテクチャは、十分に順応性であって構成可能であり、それで、それは、添付図面で示されるもの以外の方法で利用して誘導し得る。

さらに、要約の目的は、米国特許および商標局と、一般公衆と、特に科学者、技術者、および特許用語または法律の用語もしくは言い回しに不慣れな実践者とに、本出願の技法的開示の性質および本質を大まかな検査で迅速に判定することを可能とすることである。要約は、いかようにも本明細書に提示する例としての実施形態の範囲について制限することを意図するものではない。請求の範囲中に述べる手順は提示された順序で実施する必要はないこともまた理解すべきである。

１００ システム
１１０ モバイルデバイス
１２０ 読み取り装置
１３０ モバイル財布プラットフォーム
１４０ ＰＯＳ端末

Claims (18)

1. 非接触取引を管理するシステムであって、
   少なくとも１つのプロセッサを備え、前記少なくとも１つのプロセッサは、
   起動要求を受信し、
   モバイルデバイスが前記システムに対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第１のタップを識別し、
   第１のアプリケーションに対応するアプリケーション識別子（ＡＩＤ）を含む第１の選択コマンドを前記モバイルデバイスに送信し、
   前記第１の選択コマンドに基づいた第１の応答を前記モバイルデバイスから受信し、
   サポートされているデータタイプを示す情報を含むデータ要求を前記モバイルデバイスに送信し、
   前記データ要求に基づいた、取引データを含む第２の応答を前記モバイルデバイスから受信する
   ように動作可能である、システム。
2. 前記少なくとも１つのプロセッサが、
   前記第１の選択コマンドが成功裏に処理されたかどうかを判定し、
   前記取引データを売主販売時点（ＰＯＳ）システムに送信する
   ようにさらに動作可能である、請求項１に記載のシステム。
3. 前記少なくとも１つのプロセッサが、
   支払いＡＩＤ要求を前記モバイルデバイスに送信し、
   第２のアプリケーションに対応するＡＩＤを前記モバイルデバイスから受信し、
   前記第２のアプリケーションに対応する前記ＡＩＤを含む第２の選択コマンドを前記モバイルデバイスに送信し、
   前記第２のアプリケーションに対応するファイル制御情報（ＦＣＩ）を前記モバイルデバイスから受信し、
   支払いデータを前記モバイルデバイスから受信する
   ようにさらに動作可能である、請求項１に記載のシステム。
4. 前記少なくとも１つのプロセッサが、
   前記第１の選択コマンドおよび前記第２の選択コマンドが成功裏に処理されたかどうかを判定し、
   前記取引データおよび前記支払いデータを売主ＰＯＳシステムに送信する
   ようにさらに動作可能である、請求項３に記載のシステム。
5. 前記少なくとも１つのプロセッサが、
   取引後データを売主ＰＯＳシステムから受信し、
   前記モバイルデバイスが前記システムに対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第２のタップを識別し、
   前記取引後データを前記モバイルデバイスに送信する
   ようにさらに動作可能である、請求項１または３に記載のシステム。
6. 前記少なくとも１つのプロセッサが、
   取引後データを売主ＰＯＳシステムから受信し、
   前記モバイルデバイスが前記システムに対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第２のタップを識別し、
   支払いＡＩＤ要求を前記モバイルデバイスに送信し、
   第２のアプリケーションに対応するＡＩＤを前記モバイルデバイスから受信し、 前記第２のアプリケーションに対応する前記ＡＩＤを含む第２の選択コマンドを前記モバイルデバイスに送信し、
   前記第２のアプリケーションに対応するファイル制御情報（ＦＣＩ）を前記モバイルデバイスから受信し、
   支払いデータを前記モバイルデバイスから受信し、
   前記第１のアプリケーションに対応する前記ＡＩＤを含む第３の選択コマンドを前記モバイルデバイスに送信し、
   前記第３の選択コマンドに基づいた第３の応答を前記モバイルデバイスから受信し、
   前記取引後データを前記モバイルデバイスに送信し、
   前記取引後データに基づいた第４の応答を前記モバイルデバイスから受信し、
   前記第１の選択コマンド、第２の選択コマンド、および第３の選択コマンドが成功裏に処理されたかどうかを判定し、
   前記支払いデータを前記売主ＰＯＳシステムに送信する
   ようにさらに動作可能である、請求項１に記載のシステム。
7. 非接触取引を管理する方法であって、
   起動要求を受信するステップと、
   モバイルデバイスが端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第１のタップを識別するステップと、
   第１のアプリケーションに対応するアプリケーション識別子（ＡＩＤ）を含む第１の選択コマンドを前記モバイルデバイスに送信するステップと、
   前記第１の選択コマンドに基づいた第１の応答を前記モバイルデバイスから受信するステップと、
   サポートされているデータタイプを示す情報を含むデータ要求を前記モバイルデバイスに送信するステップと、
   前記データ要求に基づいた、取引データを含む第２の応答を前記モバイルデバイスから受信するステップと、
   を含む、方法。
8. 前記第１の選択コマンドが成功裏に処理されたかどうかを判定するステップと、
   前記取引データを売主販売時点（ＰＯＳ）システムに送信するステップと、
   をさらに含む、請求項７に記載の方法。
9. 支払いＡＩＤ要求を前記モバイルデバイスに送信するステップと、
   第２のアプリケーションに対応するＡＩＤを前記モバイルデバイスから受信するステップと、
   前記第２のアプリケーションに対応する前記ＡＩＤを含む第２の選択コマンドを前記モバイルデバイスに送信するステップと、
   前記第２のアプリケーションに対応するファイル制御情報（ＦＣＩ）を前記モバイルデバイスから受信するステップと、
   支払いデータを前記モバイルデバイスから受信するステップと、
   をさらに含む、請求項７に記載の方法。
10. 前記第１の選択コマンドおよび前記第２の選択コマンドが成功裏に処理されたかどうかを判定するステップと、
    前記取引データおよび前記支払いデータを、売主ＰＯＳシステムに送信するステップと、
    をさらに含む、請求項９に記載の方法。
11. 取引後データを売主ＰＯＳシステムから受信するステップと、 前記モバイルデバイスが前記端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第２のタップを識別するステップと、
    前記取引後データを前記モバイルデバイスに送信するステップと、
    をさらに含む、請求項７または９に記載の方法。
12. 取引後データを売主ＰＯＳシステムから受信するステップと、
    前記モバイルデバイスが前記端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第２のタップを識別するステップと、
    支払いＡＩＤ要求を前記モバイルデバイスに送信するステップと、
    第２のアプリケーションに対応するＡＩＤを前記モバイルデバイスから受信するステップと、
    前記第２のアプリケーションに対応する前記ＡＩＤを含む第２の選択コマンドを前記モバイルデバイスに送信するステップと、
    前記第２のアプリケーションに対応するファイル制御情報（ＦＣＩ）を前記モバイルデバイスから受信するステップと、
    支払いデータを前記モバイルデバイスから受信するステップと、
    前記第１のアプリケーションに対応する前記ＡＩＤを含む第３の選択コマンドを前記モバイルデバイスに送信するステップと、
    前記第３の選択コマンドに基づいた第３の応答を前記モバイルデバイスから受信するステップと、
    前記取引後データを前記モバイルデバイスに送信するステップと、
    前記取引後データに基づいた第４の応答を前記モバイルデバイスから受信するステップと、
    前記第１の選択コマンド、第２の選択コマンド、および第３の選択コマンドが成功裏に処理されたかどうかを判定するステップと、
    前記支払いデータを前記売主ＰＯＳシステムに送信するステップと、
    をさらに含む、請求項７に記載の方法。
13. コンピュータ可読記憶媒体であって、
    １つ以上のプロセッサに、
    起動要求を受信させ、
    モバイルデバイスが端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第１のタップを識別させ、
    第１のアプリケーションに対応するアプリケーション識別子（ＡＩＤ）を含む第１の選択コマンドを前記モバイルデバイスに送信させ、
    前記第１の選択コマンドに基づいた第１の応答を前記モバイルデバイスから受信させ、
    サポートされているデータタイプを示す情報を含むデータ要求を前記モバイルデバイスに送信させ、
    前記データ要求に基づいた、取引データを含む第２の応答を前記モバイルデバイスから受信させるための命令のシーケンスを記憶したコンピュータ可読記憶媒体。
14. 前記１つ以上のプロセッサにさらに、
    前記第１の選択コマンドが成功裏に処理されたかどうかを判定させ、
    前記取引データを、売主販売時点（ＰＯＳ）システムに送信させる
    ための命令のシーケンスを記憶した、請求項１３に記載のコンピュータ可読記憶媒体。
15. 前記１つ以上のプロセッサにさらに、
    支払いＡＩＤ要求を前記モバイルデバイスに送信させ、
    第２のアプリケーションに対応するＡＩＤを前記モバイルデバイスから受信させ、 前記第２のアプリケーションに対応する前記ＡＩＤを含む第２の選択コマンドを前記モバイルデバイスに送信させ、
    前記第２のアプリケーションに対応するファイル制御情報（ＦＣＩ）を前記モバイルデバイスから受信させ、
    支払いデータを前記モバイルデバイスから受信させる、
    ための命令のシーケンスを記憶した、請求項１３に記載のコンピュータ可読記憶媒体。
16. 前記１つ以上のプロセッサにさらに、
    前記第１の選択コマンドおよび前記第２の選択コマンドが成功裏に処理されたかどうかを判定させ、
    前記取引データおよび前記支払いデータを、売主ＰＯＳシステムに送信させる
    ための命令のシーケンスを記憶した、請求項１５に記載のコンピュータ可読記憶媒体。
17. 前記１つ以上のプロセッサにさらに、
    取引後データを売主ＰＯＳシステムから受信させ、
    前記モバイルデバイスが前記端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第２のタップを識別させ、
    前記取引後データを前記モバイルデバイスに送信させる
    ための命令のシーケンスを記憶した、請求項１３または１５に記載のコンピュータ可読記憶媒体。
18. 前記１つ以上のプロセッサにさらに、
    取引後データを売主ＰＯＳシステムから受信させ、
    前記モバイルデバイスが前記端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第２のタップを識別させ、
    支払いＡＩＤ要求を前記モバイルデバイスに送信させ、
    第２のアプリケーションに対応するＡＩＤを前記モバイルデバイスから受信させ、
    前記第２のアプリケーションに対応する前記ＡＩＤを含む第２の選択コマンドを前記モバイルデバイスに送信させ、
    前記第２のアプリケーションに対応するファイル制御情報（ＦＣＩ）を前記モバイルデバイスから受信させ、
    支払いデータを前記モバイルデバイスから受信させ、
    前記第１のアプリケーションに対応する前記ＡＩＤを含む第３の選択コマンドを前記モバイルデバイスに送信させ、
    前記第３の選択コマンドに基づいた第３の応答を前記モバイルデバイスから受信させ、
    前記取引後データを前記モバイルデバイスに送信させ、
    前記取引後データに基づいた第４の応答を前記モバイルデバイスから受信させ、
    前記第１の選択コマンド、第２の選択コマンド、および第３の選択コマンドが成功裏に処理されたかどうかを判定させ、
    前記支払いデータを前記売主ＰＯＳシステムに送信させる
    ための命令のシーケンスを記憶した、請求項１３に記載のコンピュータ可読記憶媒体。

Images