図面 (/)

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

出願人 グーグル・インコーポレーテッド
発明者 ブッシュ,ラリー,エル.トムザック,クリストファー,ジェー.
出願日 2013年5月23日 (7年5ヶ月経過) 出願番号 2015-514187
公開日 2015年10月29日 (5年0ヶ月経過) 公開番号 2015-531093
状態 特許登録済
技術分野 金銭登録機・受付機
主要キーワード BCDデータ 特殊形式 サポートデバイス 静止データ 事前構築 送出用データ 不揮発性ストレージデバイス タグタイプ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2015年10月29日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (9)

課題・解決手段

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

概要

背景

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

モバイルデバイスまたは非接触式のクレジットカードもしくはデビットカードを、それらが通信的に連結され得るように、NFC対応の読み取り装置の近くに置くことは、時々、「ウェーブ」または「タップ」と呼ばれる。消費者がNFC対応のPOSシステムのところで「タップして支払う」ことを可能とするモバイルデバイス用のアプリケーションは、一般に、「財布アプリケーション」または「モバイル財布顧客アプリケーション」と呼ばれる。支払いに関連するアプリケーションは、一般に、「支払い」アプリケーションと呼ばれる。一般的な非接触支払いアプリケーションは、次の技術のうちの任意のものを用いて容易化される:American Express(登録商標)「ExpressPay」、Discover(登録商標)「ZIP」、Mastercard(登録商標)「PayPass」、またはVisa(登録商標)「PayWave」。

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

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

概要

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

目的

本明細書に記載する例としての態様は、一般的には非接触プロトコルに関し、より詳しくは、モバイルデバイスと、近距離無線通信(NFC)読み取り装置と、販売時点管理(POS)システムとの間での相互運用を可能とする非接触プロトコルを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

非接触取引を管理するシステムであって、少なくとも1つのプロセッサを備え、前記少なくとも1つのプロセッサは、起動要求を受信し、モバイルデバイスが前記システムに対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第1のタップ識別し、第1のアプリケーションに対応するアプリケーション識別子AID)を含む第1の選択コマンドを前記モバイルデバイスに送信し、前記第1の選択コマンドに基づいた第1の応答を前記モバイルデバイスから受信し、サポートされているデータタイプを示す情報を含むデータ要求を前記モバイルデバイスに送信し、前記データ要求に基づいた、取引データを含む第2の応答を前記モバイルデバイスから受信するように動作可能である、システム。

請求項2

前記少なくとも1つのプロセッサが、前記第1の選択コマンドが成功裏に処理されたかどうかを判定し、前記取引データを売主販売時点POS)システムに送信するようにさらに動作可能である、請求項1に記載のシステム。

請求項3

前記少なくとも1つのプロセッサが、支払いAID要求を前記モバイルデバイスに送信し、第2のアプリケーションに対応するAIDを前記モバイルデバイスから受信し、前記第2のアプリケーションに対応する前記AIDを含む第2の選択コマンドを前記モバイルデバイスに送信し、前記第2のアプリケーションに対応するファイル制御情報(FCI)を前記モバイルデバイスから受信し、支払いデータを前記モバイルデバイスから受信するようにさらに動作可能である、請求項1に記載のシステム。

請求項4

前記少なくとも1つのプロセッサが、前記第1の選択コマンドおよび前記第2の選択コマンドが成功裏に処理されたかどうかを判定し、前記取引データおよび前記支払いデータを売主POSシステムに送信するようにさらに動作可能である、請求項3に記載のシステム。

請求項5

前記少なくとも1つのプロセッサが、取引後データを売主POSシステムから受信し、前記モバイルデバイスが前記システムに対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第2のタップを識別し、前記取引後データを前記モバイルデバイスに送信するようにさらに動作可能である、請求項1または3に記載のシステム。

請求項6

前記少なくとも1つのプロセッサが、取引後データを売主POSシステムから受信し、前記モバイルデバイスが前記システムに対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第2のタップを識別し、支払いAID要求を前記モバイルデバイスに送信し、第2のアプリケーションに対応するAIDを前記モバイルデバイスから受信し、前記第2のアプリケーションに対応する前記AIDを含む第2の選択コマンドを前記モバイルデバイスに送信し、前記第2のアプリケーションに対応するファイル制御情報(FCI)を前記モバイルデバイスから受信し、支払いデータを前記モバイルデバイスから受信し、前記第1のアプリケーションに対応する前記AIDを含む第3の選択コマンドを前記モバイルデバイスに送信し、前記第3の選択コマンドに基づいた第3の応答を前記モバイルデバイスから受信し、前記取引後データを前記モバイルデバイスに送信し、前記取引後データに基づいた第4の応答を前記モバイルデバイスから受信し、前記第1の選択コマンド、第2の選択コマンド、および第3の選択コマンドが成功裏に処理されたかどうかを判定し、前記支払いデータを前記売主POSシステムに送信するようにさらに動作可能である、請求項1に記載のシステム。

請求項7

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

請求項8

前記第1の選択コマンドが成功裏に処理されたかどうかを判定するステップと、前記取引データを売主販売時点(POS)システムに送信するステップと、をさらに含む、請求項7に記載の方法。

請求項9

支払いAID要求を前記モバイルデバイスに送信するステップと、第2のアプリケーションに対応するAIDを前記モバイルデバイスから受信するステップと、前記第2のアプリケーションに対応する前記AIDを含む第2の選択コマンドを前記モバイルデバイスに送信するステップと、前記第2のアプリケーションに対応するファイル制御情報(FCI)を前記モバイルデバイスから受信するステップと、支払いデータを前記モバイルデバイスから受信するステップと、をさらに含む、請求項7に記載の方法。

請求項10

前記第1の選択コマンドおよび前記第2の選択コマンドが成功裏に処理されたかどうかを判定するステップと、前記取引データおよび前記支払いデータを、売主POSシステムに送信するステップと、をさらに含む、請求項9に記載の方法。

請求項11

取引後データを売主POSシステムから受信するステップと、前記モバイルデバイスが前記端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第2のタップを識別するステップと、前記取引後データを前記モバイルデバイスに送信するステップと、をさらに含む、請求項7または9に記載の方法。

請求項12

取引後データを売主POSシステムから受信するステップと、前記モバイルデバイスが前記端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第2のタップを識別するステップと、支払いAID要求を前記モバイルデバイスに送信するステップと、第2のアプリケーションに対応するAIDを前記モバイルデバイスから受信するステップと、前記第2のアプリケーションに対応する前記AIDを含む第2の選択コマンドを前記モバイルデバイスに送信するステップと、前記第2のアプリケーションに対応するファイル制御情報(FCI)を前記モバイルデバイスから受信するステップと、支払いデータを前記モバイルデバイスから受信するステップと、前記第1のアプリケーションに対応する前記AIDを含む第3の選択コマンドを前記モバイルデバイスに送信するステップと、前記第3の選択コマンドに基づいた第3の応答を前記モバイルデバイスから受信するステップと、前記取引後データを前記モバイルデバイスに送信するステップと、前記取引後データに基づいた第4の応答を前記モバイルデバイスから受信するステップと、前記第1の選択コマンド、第2の選択コマンド、および第3の選択コマンドが成功裏に処理されたかどうかを判定するステップと、前記支払いデータを前記売主POSシステムに送信するステップと、をさらに含む、請求項7に記載の方法。

請求項13

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

請求項14

前記1つ以上のプロセッサにさらに、前記第1の選択コマンドが成功裏に処理されたかどうかを判定させ、前記取引データを、売主販売時点(POS)システムに送信させるための命令のシーケンスを記憶した、請求項13に記載のコンピュータ可読記憶媒体。

請求項15

前記1つ以上のプロセッサにさらに、支払いAID要求を前記モバイルデバイスに送信させ、第2のアプリケーションに対応するAIDを前記モバイルデバイスから受信させ、前記第2のアプリケーションに対応する前記AIDを含む第2の選択コマンドを前記モバイルデバイスに送信させ、前記第2のアプリケーションに対応するファイル制御情報(FCI)を前記モバイルデバイスから受信させ、支払いデータを前記モバイルデバイスから受信させる、ための命令のシーケンスを記憶した、請求項13に記載のコンピュータ可読記憶媒体。

請求項16

前記1つ以上のプロセッサにさらに、前記第1の選択コマンドおよび前記第2の選択コマンドが成功裏に処理されたかどうかを判定させ、前記取引データおよび前記支払いデータを、売主POSシステムに送信させるための命令のシーケンスを記憶した、請求項15に記載のコンピュータ可読記憶媒体。

請求項17

前記1つ以上のプロセッサにさらに、取引後データを売主POSシステムから受信させ、前記モバイルデバイスが前記端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第2のタップを識別させ、前記取引後データを前記モバイルデバイスに送信させるための命令のシーケンスを記憶した、請求項13または15に記載のコンピュータ可読記憶媒体。

請求項18

前記1つ以上のプロセッサにさらに、取引後データを売主POSシステムから受信させ、前記モバイルデバイスが前記端末に対して所定の近傍内に置かれた場合に発生する、前記モバイルデバイスからの第2のタップを識別させ、支払いAID要求を前記モバイルデバイスに送信させ、第2のアプリケーションに対応するAIDを前記モバイルデバイスから受信させ、前記第2のアプリケーションに対応する前記AIDを含む第2の選択コマンドを前記モバイルデバイスに送信させ、前記第2のアプリケーションに対応するファイル制御情報(FCI)を前記モバイルデバイスから受信させ、支払いデータを前記モバイルデバイスから受信させ、前記第1のアプリケーションに対応する前記AIDを含む第3の選択コマンドを前記モバイルデバイスに送信させ、前記第3の選択コマンドに基づいた第3の応答を前記モバイルデバイスから受信させ、前記取引後データを前記モバイルデバイスに送信させ、前記取引後データに基づいた第4の応答を前記モバイルデバイスから受信させ、前記第1の選択コマンド、第2の選択コマンド、および第3の選択コマンドが成功裏に処理されたかどうかを判定させ、前記支払いデータを前記売主POSシステムに送信させるための命令のシーケンスを記憶した、請求項13に記載のコンピュータ可読記憶媒体。

技術分野

0001

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

背景技術

0002

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

0003

モバイルデバイスまたは非接触式のクレジットカードもしくはデビットカードを、それらが通信的に連結され得るように、NFC対応の読み取り装置の近くに置くことは、時々、「ウェーブ」または「タップ」と呼ばれる。消費者がNFC対応のPOSシステムのところで「タップして支払う」ことを可能とするモバイルデバイス用のアプリケーションは、一般に、「財布アプリケーション」または「モバイル財布顧客アプリケーション」と呼ばれる。支払いに関連するアプリケーションは、一般に、「支払い」アプリケーションと呼ばれる。一般的な非接触支払いアプリケーションは、次の技術のうちの任意のものを用いて容易化される:American Express(登録商標)「ExpressPay」、Discover(登録商標)「ZIP」、Mastercard(登録商標)「PayPass」、またはVisa(登録商標)「PayWave」。

0004

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

0005

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

0006

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

0007

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

0008

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

0009

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

図面の簡単な説明

0010

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

0011

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

実施例

0012

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

0013

「アプリケーション」、「アプレット」、「ウィジェット」という用語および/またはこれらの複数形態は、本明細書中では交換可能に用いられて、アプリケーション(他のアプリケーションとは独立にまたは共に機能する)または命令もしくはコードの集合もしくはサブ集合を意味し、(例えば、モバイルデバイス、カード読み取り装置、端末、販売時点(POS)システム、またはサーバ中の)1つ以上のプロセッサによって実行される場合に、プロセッサに特定のタスクを実施させる。例えば、財布アプリケーションを用いて、金融、ロイヤルティ、オファー、会員資格、またはアカウントのデータの記憶動作処理動作アクセス動作、または送信動作などの取引関連またはインターフェース関連の機能を実行することが可能である。財布アプリケーションはまた、American Express(登録商標)のExpressPay、Discover(登録商標)のNetwork ZIPSM、MasterCard(登録商標)のPayPass(商標)、およびVisa payWave(商標)の支払いアプレットなどの1つ以上の支払いアプリケーションを組み込み得るまたはこれと対話し得る。

0014

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

0015

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

0016

第3のアプリケーションは、モバイルデバイスのセキュア・エレメント上に、JavaCardアプレットという形態で存在する。このアプレットは、ロイヤルティおよびオファーなどの商業関連のデータを記憶して、このデータが管理され得る際に用いられるインターフェースを提供する。このアプレットは、国際標準化機構(ISO)7816−4に定義されるアプリケーションプロトコルデータユニットAPDU)コマンドを用いることによってアクセス可能である。

0017

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

0018

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

0019

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

0020

モバイルデバイス110は、例えば、携帯電話または同様なものであり得、プロセッサ111a、メモリ111b、非接触フロントエンド(CLF)111c、ベースバンドモデム111d、および、ディスプレイ(図示せず)などのユーザインターフェースを含む。ベースバンドモデム111dは、モバイルネットワーク通信用に用いられるデジタルモデムである。CLF111cは、非接触もしくはNFCの通信のアナログ態様ならびに非接触送信リンク通信プロトコル層を取り扱う回路である。CLF111cはまた、例えば、非接触取引を実行するために、読み取り装置120とモバイルデバイス110に含まれるセキュア・エレメント(すなわちSE)112との間でデータを交換するために用いられる。

0021

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

0022

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

0023

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

0024

商業アプレット113は、所与の売主に関連する全てのデータの記憶/管理を可能とするキャッシュド売主データテーブルを含む。これが、所与の売主の商業データを、財布アプリケーションによってセキュア・エレメント112またはモバイルデバイス110中に事前ロードすることを可能とする。キャッシュド売主データテーブルに含まれる例示の商業要素(および、タグ・長さ・値(TLV)符号化中に用いられるそれらの対応するタグ値)を、以下に定義する。このデータは、記録指向データバッファに記憶される。例示の実施形態では、売主識別子(Merchant Identifier)が、検索/回収タスク用のキーフィールドとして用いられる。オプションとして、索引(またはハッシュ表)が、性能を向上させるために作成され得る。

0025

1つ以上の商業アプレット113は、例えば、セキュア・エレメント112の製造および/または構成中にセキュア・エレメント112上にロードすることが可能であり、かつ、商業取引を実行するためにその使用を可能とするようにパーソナライズし得る。商業アプレット113は、商業アプリケーションプログラミングインターフェースAPI)123を介して読み取り装置120とインターフェースする。例示の実施形態では、商業アプレット113は、JavaCardアプレットという形態であって、ISO7816−4に定義されるAPDUコマンドを用いることによってアクセス可能である。特に、商業アプレット113は、NFC ISO14443プロトコル上でISO7816コマンドを用いてセキュア・エレメント112を介して商業要素を読み取り装置120に通信する。

0026

セキュア・エレメント112はまた、1つ以上の支払いアプレット117を含むことが可能であり、各々の支払いアプレット117は、支払いサービスプロバイダによって発行された支払いサービスおよびアカウントと関連付けられる。1つ以上の支払いアプレット117はまた、例えば、セキュア・エレメント112の製造および/または構成中にセキュア・エレメント112上にロードすることが可能であり、かつ、支払い取引を実行するためにその使用を可能とするようにパーソナライズし得る。支払いアプレット117は、API124を介して読み取り装置120とインターフェースする。例示の実施形態では、支払いアプレット117は、JavaCardアプレットという形態であり、ISO7816−4に定義されるAPDUコマンドの使用によってアクセス可能である。支払いアプレット113はまた、NFC ISO14443プロトコル上でISO7816コマンドを用いてセキュア・エレメント112を介して支払い要素を読み取り装置120に通信させる。

0027

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

0028

モバイルデバイス110上に記憶された財布アプリケーション114は、モバイルデバイス110のプロセッサによって実行される場合に、モバイルデバイス110を、例えば、非接触商業および/または支払い取引などの取引を処理するために機器として動作させる命令を含む。財布アプリケーション114は、ISO7816−4に定義されるAPDUコマンドの使用によって、商業API116を介して商業アプレット113と通信し、支払いAPI118を介して支払いアプレット117に通信する。

0029

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

0030

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

0031

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

0032

モバイルデバイス110は、モバイル財布プラットフォーム130にさらに通信可能に連結され、このプラットフォームは次に、オファープラットフォーム131、ロイヤルティプラットフォーム132、および報酬プラットフォーム133に通信可能に連結される。集合的に、オファープラットフォーム131、ロイヤルティプラットフォーム132、および報酬プラットフォーム133は、モバイル商業(MoCom)プラットフォーム134と呼ぶことが可能であり、本明細書では個々にかつ集合的にMoComサーバ(ここで図示する)と呼ばれる1つ以上のサーバ上に実装される。

0033

1つの実施形態では、顧客は、読み取り装置120を備えるPOSのところで非接触取引を実行するためにモバイルデバイス110を用い得る。顧客はモバイルデバイス110を非接触読み取り装置120の所定の必要近傍内において(すなわち、タップして)、モバイルデバイス110のCLF111cを、例えば、NFC ISO14443プロトコルを用いて、読み取り装置120と通信させる。読み取り装置120はまた、モバイルデバイス110上の財布アプリケーション114、商業アプレット113、および/または支払いアプリケーションと通信して、非接触取引を実行する。

0034

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

0035

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

0036

読み取り装置の初期化
読み取り装置120の初期化を、ここでより詳細に説明する。1つの実施形態では、読み取り装置120は、モバイルデバイス中のどのアプリケーションが選択されるかを制御するエントリポイントマネージャ(EPM)と呼ばれる機能を実装する。この実施形態では、EPMは、読み取り装置120が、商業取引を実施するアプリケーションを選択するためのモバイルデバイス110へのコマンドを送るか、または支払い取引を実施するコマンドを送るかどうかを制御する。商業アプリケーションを選択するコマンドは、本明細書では「Select Commerce(商業選択)」と呼ばれる。支払いアプリケーションを選択するコマンドは、本明細書では「PPSE Select(PPSE選択)」と呼ばれる。

0037

EPMはまた、チェックアウト過程中での、読み取り装置120の開始モードおよび後続のアプリケーション切り替えを制御する。EPMは、したがって、商業取引用のSelect Commerce(商業選択)コマンドと支払い取引用のPPSE Select(PPSE選択)コマンドとの間の(読み取り装置120における)切り替えを容易化する。

0038

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

0039

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

0040

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

0041

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

0042

自動開始モード
図1を参照すると、自動開始モードは、POSチェックアウト過程の開始時に読み取り装置120上に商業機能性を提供する。モバイルデバイス110が読み取り装置120をタップすると、読み取り装置アプリケーション121は、読み取り装置120に、非接触取引を実行するために用いられる商業アプリケーションに対応するAIDを含むモバイルデバイス110に対して「Select Commerce(商業選択)」メッセージを送らせる。このメッセージがモバイルデバイス110によって容認された場合それは、肯定応答メッセージ返送する。次に、読み取り装置120は、モバイルデバイス110に「Get Commerce Data(商業データ取得)」コマンドを送る。Get Commerce Data(商業データ取得)コマンドは、セキュア・エレメント112が商業取引を実施するために用いる売主固有のデータを含む。また、Get Commerce Data(商業データ取得)取引が成功裏に完了すれば、制御権はモバイルデバイス110に移る。読み取り装置120が「Select Commerce(商業選択)」メッセージに対して否定応答を受信する場合には、それは、制御権をEPMに戻す。

0043

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

0044

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

0045

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

0046

POS端末140は、例えば、取引識別子(ID)および償還されたクーポンIDを持つ読み取り装置120に「Post Transaction(取引後)」コマンドを送る。読み取り装置120は次に、支払いのためのタップに対する要求を送信する。このタップは、読み取り装置120が、最初にセキュア・エレメント112から支払認証情報を要求することを可能とし、次に、読み取り装置アプリケーション121に、商業データ(例えば、クーポンデータ)をセキュア・エレメント112に送らせる。双方の機能は、読み取り装置120のところでモバイルデバイス110によって単一のタップで実施される。

0047

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

0048

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

0049

売主のPOSシステム202は、支払い端末201の動作を制御する売主によって操作される売主サーバであり得る。例示の実施形態では、売主POSシステム202は、支払い端末201に、品目が走査される前に、品目が走査されている間に、または品目が走査された後で、読み取り装置を起動するように指令する(「Activate Reader(読み取り装置起動)」)。各々の場合において、読み取り装置120は、ステップ250(「Request 'Tap'(『タップ』を要求)」)に示すように、ユーザ(または消費者)に対して、モバイルデバイス110を読み取り装置120の近傍に置くように要求する。ユーザに対するモバイルデバイス110を読み取り装置120の近傍に置くことへの要求(ステップ250)に応答して、消費者は、ステップ251に示すように、モバイルデバイス110を読み取り装置120上にタップする。

0050

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

0051

最初にステップ262を参照すると、モバイルデバイスが読み取り装置120をタップした後で、読み取り装置120は、セキュア・エレメント112内のどの商業アプレット(例えば、商業アプレット113)と自身が協力することを求めているかを示す特定の商業AID(「Select Commerce AID(商業AID選択)」)と共にSelect Commerce(商業選択)コマンドを、セキュア・エレメント112に送る。それに応答して、セキュア・エレメント112は、肯定応答または否定応答を送る。否定応答(図示せず)は、結果として、読み取り装置120が、読み取り装置アプリケーション121を終了させて(図1)、制御権をEPM(図示せず)に送ることになる。この応答が肯定的(「Positive Response(肯定応答)」)であれば、読み取り装置120は、コマンド(「Get Commerce Data(商業データ取得)」)をセキュア・エレメント112に送って、売主/店舗識別子ならびに何らかのさらなるロイヤルティ、その位置でサポートされているオファーもしくは報酬のスキーム、データおよび時間の情報、読み取り装置120によってサポートされている読み取り装置商業アプリケーション121のバージョン、および何らかの商業機能データなどの識別情報を指定する。

0052

セキュア・エレメント112は、読み取り装置120から受信されたGet Commerce Data(商業データ取得)コマンド中のフィールドに基づいて、対応する商業要素(例えば、ロイヤルティデータ、オファーデータ、報酬データ)(「Loyalty & Offers Data(ロイヤルティ&オファーデータ)」)を読み取り装置120に返送する。1つの実施形態では、商業アプレット113は、商業データ(例えば、ロイヤルティデータ、オファーデータ、または報酬データを含むバッファまたはバッファの集合)を含むパッケージ構築する。別の実施形態では、バッファは、セキュア・エレメント112中のメモリ空間を用いて事前構築される。

0053

ステップ260を参照すると、1つの実施形態では、読み取り装置120は、PPSE要求(「PPSE Select(PPSE選択)」)をセキュア・エレメント112に送ることによって、支払い処理を開始する。

0054

Select CommerceAID(商業AID選択)およびPPSE Select(PPSE選択)要求が成功であれば、ステップ264(「Read Success Indication(成功表示の読み出し)」)に示すように、支払い端末201は、それが受信した商業アプリケーションデータおよび支払認証情報(「Payment & Commerce Data(支払い&商業のデータ)」)を、処理目的で、売主POSシステム202に転送する。売主POSシステム202は、すると、製品走査がステップ266に示すように継続する間に、ロイヤルティ識別子およびオファー(図示せず)を記録して、何らかの適用可能な割引を適用する。これで、商業アプリケーション過程が終了し、支払い処理が進む。

0055

一旦走査が完了して、支払いのための取引金額承認されると、支払いプラットフォーム203に対する支払い認可要求がなされる(「Payment Auth Request(支払い認可要求)」)。すると、支払いプラットフォーム203は、支払いが認可されたかどうかを示す認可結果(「Authorization Result」)を返送する。

0056

再度ステップ260を参照すると、1つの実施形態では、セキュア・エレメント112に対する読み取り装置120によるPPSE Select(PPSE選択)要求は、セキュア・エレメント112に、どの支払いアプレット(およびしたがって、どの対応する支払いネットワーク)を用いて支払い取引を実施すべきかを示すPPSE支払いAID(「PPSE Payment AID」)を返送させる。それに応答して、読み取り装置120は、それが特定のアプレットをサポートしていることを示すAID選択(「Select AID」)を送る。支払いアプレット(例えば、図1、117)と関連付けられたファイル制御情報(FCI)が、セキュア・エレメント112によって読み取り装置120に対して送られる。同様に、他の支払いおよびカードの情報が、セキュア・エレメント112によって読み取り装置120に送られる(「Payment/Card Data(支払い/カードデータ)」)。

0057

図3は、例示の実施形態に関わる二重タップおよび取引後データの送信を含む商業過程フローを図示するタイミング図300を示す。この実施形態は、売主が、モバイルデバイスに通信して返すデータを有している場合に用いることが可能である。便宜上、読み取り装置120(図1)およびPOS端末140(図1)を、1つの構成要素として図示し、集合的に支払い端末301と呼ぶ。各々の構成要素(すなわち、読み取り装置120またはPOS端末140)は、適用可能である場合に個々に参照される。一般に、POS端末140(図1)は、コマンド「Post Transaction Command(取引後コマンド)」を読み取り装置120に送ることによって、第2のタップを求める要求を開始する。読み取り装置120は、すると、消費者からの第2のタップを要求する。

0058

売主POSシステム302は、支払い端末301の操作を制御する売主によって操作される売主サーバであり得る。例示の実施形態では、売主POSシステム302は、支払い端末301に対して、品目が走査される前に、品目が走査されている間に、または品目が走査された後で、読み取り装置120を起動する(「Activate Reader(読み取り装置起動)」)ように指令する。各々の場合、読み取り装置120は、ステップ350(「Request 'tap'(『タップ』を要求)」)に示すように、ユーザに対して、モバイルデバイス110を読み取り装置120の近傍に位置付けるように要求する。モバイルデバイス110を読み取り装置120の近傍に位置付けるようにとのユーザに対する要求(ステップ350)に応答して、消費者は、ステップ351に示すように、モバイルデバイス110を読み取り装置120上にタップする。

0059

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

0060

最初にステップ362を参照すると、モバイルデバイス110が読み取り装置120をタップした後で、読み取り装置120は、セキュア・エレメント112内のどの商業アプレット(例えば、商業アプレット113)と自身が協力することを求めているかを示す特定の商業AID(「Select Commerce AID(商業AID選択)」)と共にSelect Commerce(商業選択)コマンドを、セキュア・エレメント112に送る。それに応答して、セキュア・エレメント112は、肯定応答または否定応答を送る。否定応答(図示せず)は、結果として、読み取り装置120が、読み取り装置アプリケーション121を終了させて(図1)、制御権をEPM(図示せず)に渡すことになる。この応答が肯定的(「Positive Response(肯定応答)」)であれば、読み取り装置120は、コマンド(「Get Commerce Data(商業データ取得)」)をセキュア・エレメント112に送って、売主/店舗識別子ならびに、その位置でサポートされている何らかのさらなるロイヤルティおよびオファーのスキーム、日付および時間の情報、読み取り装置120によってサポートされている読み取り装置商業アプリケーション121のバージョン、および何らかの商業機能データなどの識別情報を指定する。セキュア・エレメント112は、読み取り装置120から受信されたGet Commerce Data(商業データ取得)コマンド中のフィールドに基づいて、対応する商業要素(例えば、ロイヤルティデータおよびオファーデータ)(「Loyalty & Offers Data(ロイヤルティ&オファーデータ)」)を読み取り装置120に返送する。1つの実施形態では、これは、データのパッケージ(本質的には、オファーおよびロイヤルティのデータを含むバッファまたはバッファの集合)を構築する商業アプレット113によって遂行される。別の実施形態では、バッファは、セキュア・エレメント112中のメモリ空間を用いて事前構築することが可能である。

0061

次にステップ360を参照すると、1つの実施形態では、セキュア・エレメント112に対する読み取り装置120によるPPSE Select(PPSE選択)要求は、セキュア・エレメント112に、どの支払いアプレット(およびしたがって、支払いネットワーク)を用いて支払い取引を実施すべきかを示すPPSE支払いAID(「PPSE Payment AID」)を返送させる。それに応答して、読み取り装置120は、それが特定のアプレットをサポートしていることを示すAID選択(「Select AID」)を送る。支払いアプレット(例えば、117)と関連付けられたFCIが、セキュア・エレメント112によって読み取り装置120に対して送られる。同様に、他の支払いおよびカードの情報が、セキュア・エレメント112によって読み取り装置120に送られる(「Payment/Card Data(支払い/カードデータ)」)。Select Commerce AID(商業AID選択)およびPPSE select(PPSE選択)要求が成功であれば、ステップ364に示すように、支払い端末301は、それが受信した商業アプリケーションデータおよび支払認証情報(「Payment & Commerce Data(支払い&商業のデータ)」)を、処理目的で、売主POSシステム302に転送する。売主POSシステム302は、すると、製品走査がステップ366に示すように継続する間に、ロイヤルティ識別子およびオファー(図示せず)を記録して、何らかの適用可能な割引を適用する。

0062

一旦走査が完了して、取引金額が支払われたと承認されると、支払いプラットフォーム303に対する支払い認可要求がなされる(「Payment Auth Request(支払い認可要求)」)。すると、支払いプラットフォーム303は、支払いがされたかどうかを示す認可結果(「Authorization Result」)を返送する。

0063

支払い端末301に返送するデータが存在する場合、売主POSシステムは、正確に形式化されたTLVを持つコマンド「Post Transaction Data(取引後データ)」を作成して、このデータを読み取り装置120に転送する。Post Transaction(取引後)コマンドを受信すると、支払い端末301は、ステップ368(「Request 2nd 'tap'(2番目のタップを要求する)」)に示すように、消費者からの第2のタップを要求する。

0064

ステップ369および370を参照すると、モバイルデバイス110は、ステップ369に示すように読み取り装置120の近傍内に2回目に位置付けられるとき、読み取り装置120は、セキュア・エレメント112内のどの商業アプレット(例えば、商業アプレット113)とそれが協力することを希望するかを示す特定の商業AID(「Select Commerce AID(商業AID選択)」)と共にSelect Commerce(商業選択)コマンドを、セキュア・エレメント112に送る。

0065

否定応答が受信されると、読み取り装置120は、読み取り装置商業アプリケーション121を終了させる。肯定応答が受信されると、読み取り装置120は、POS端末140からのPost Transaction Data(取引後データ)コマンド(「Post Transaction Data(取引後データ)」)中で受信されたデータをセキュア・エレメント112に転送する。これで、この取引の商業処理が終了する。

0066

図4は、例示の実施形態に関わる二重タップならびに取引後データおよび支払いの送信を含む商業過程フローを図示するタイミング図400を示す。このシナリオでは、支払いデータおよび取引後データは、バスケットが合計され、すべての割引が適用された後で処理される。このフローの使用は、特定のビット(例えば、「Payment with Post Transaction(取引後支払い)」がオンに設定された状態で読み取り装置開始モードデータ要素によって制御される。

0067

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

0068

売主POSシステム402は、支払い端末401の操作を制御する売主によって操作される売主サーバであり得る。例示の実施形態では、売主POSシステム402は、支払い端末401に対して、品目が走査される前に、品目が走査されている間に、または品目が走査された後で、読み取り装置を起動する(「Activate Reader(読み取り装置起動)」)ように指令する。各々の場合、読み取り装置120は、ステップ450(「Request 'tap'(『タップ』を要求)」)に示すように、ユーザに対して、モバイルデバイス110を読み取り装置120の近傍に位置付けるように要求する。モバイルデバイス110を読み取り装置120の近傍に位置付けるようにとのユーザに対する要求(ステップ450)に応答して、消費者は、ステップ451に示すように、モバイルデバイス110を読み取り装置120上にタップする。

0069

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

0070

最初にステップ462を参照すると、モバイルデバイスが読み取り装置120をタップした後で、読み取り装置120は、セキュア・エレメント112内のどの商業アプレット(例えば、商業アプレット113)と協力するかを示す特定の商業AID(「Select Commerce AID(商業AID選択)」)と共にSelect Commerce(商業選択)コマンドを、セキュア・エレメント112に送る。それに応答して、セキュア・エレメント112は、肯定応答または否定応答を送る。否定応答(図示せず)は、結果として、読み取り装置120が、読み取り装置アプリケーション121を終了させて(図1)、制御権をEPM(図示せず)に渡すことになる。この応答が肯定的(「Positive Response(肯定応答)」)であれば、読み取り装置120は、コマンド(「Get Commerce Data(商業データ取得)」)をセキュア・エレメント112に送って、売主/店舗識別子ならびに、その位置でサポートされている何らかのさらなるロイヤルティおよびオファーのスキーム、日付および時間の情報、読み取り装置120によってサポートされている読み取り装置商業アプリケーション121のバージョン、および何らかの商業機能データなどの識別情報を指定する。セキュア・エレメント112は、読み取り装置120から受信されたGet Commerce Data(商業データ取得)コマンド中のフィールドに基づいて、対応する商業要素(例えば、ロイヤルティデータおよびオファーデータ)を読み取り装置120(「Loyalty & Offers Data(ロイヤルティ&オファーデータ)」)に返送する。1つの実施形態では、これは、データのパッケージ(本質的には、オファーおよびロイヤルティのデータを含むバッファまたはバッファの集合)を構築する商業アプレット113によって遂行される。別の実施形態では、バッファは、セキュア・エレメント112中のメモリ空間を用いて事前構築することが可能である。

0071

ステップ464で、読み取り装置120は、取引が完了したこと、および、ハンドセットが支払い端末401から除去することが可能であることを消費者に対して示し、これが、読み取り装置120に、商業アプリケーションデータをPOS端末140に転送させ、次に、処理目的で売主POSシステムに転送させる(「Loyalty & Offers Data(ロイヤルティ&オファーデータ)」)。店員は、買い物バスケットを処理し続け得る。

0072

売主POSシステム402は、製品走査がステップ466に示すように継続する間に、ロイヤルティ識別子およびオファー(図示せず)を記録して、何らかの適用可能な割引を適用する。バスケットの合計が計算された後、売主POSシステム402は、支払い要求を支払い端末401に送って、(送出用データ手元にあれば)取引後データを支払い端末401に送る(「Send Post Transaction Data and Payment Req(取引後データおよび支払い要求の送信)」)。

0073

ステップ468で、支払い端末140は、支払いに対するタップを要求する。読み取り装置120は、すると、読み取り装置フィールドを起動する。モバイルデバイス110が読み取り装置120のフィールドで検出されたとき、支払い処理はステップ472に示すように実施される。特に、PPSE Select(PPSE選択)要求は読み取り装置120によってセキュア・エレメント112に対してなされて、セキュア・エレメント112に、どの支払いアプレット(およびしたがって支払いネットワーク)を用いて支払い取引を実施すべきであるかを示すPPSE支払いAID(「PPSE Payment AID」)を返送させる。それに応答して、読み取り装置120は、それが特定のアプレットをサポートしていることを示すAID選択コマンド(「Select AID」)を送る。支払いアプレット(例えば、図1、117)と関連付けられたFCIが、セキュア・エレメント112によって読み取り装置120に送られる。同様に、他の支払いおよびカードの情報が、セキュア・エレメント112によって読み取り装置120に送られる(「Payment/Card Data(支払い/カードデータ)」)。

0074

ステップ474を参照すると、支払い端末401が取引後データを売主POSシステム402から受信した場合、読み取り装置120は、商業アプリケーション121(図1)を開始して、モバイルデバイスが読み取り装置120を二回目にタップした後で、特定の商業AIDと共にSelect Commerce(商業選択)コマンド(「Select Commerce AID(商業AID選択)」)をセキュア・エレメント112に送る。Select Commerce AID(商業AID選択)は、読み取り装置120と協力するために、セキュア・エレメント112内のどの商業アプレットを用いるべきであるかを特定する。それに応答して、セキュア・エレメント112は、肯定または否定の応答を送る。否定応答(図示せず)は、結果として、読み取り装置120が、読み取り装置アプリケーション121(図1)を終了させて、制御権をEPM(図示せず)に渡すことになる。応答が肯定的(「Positive Response(肯定応答)」)であれば、読み取り装置120は、正確に形式化されたTLVを持つ取引後データをセキュア・エレメント112に送る(「Post Transaction Data(取引後データ)」)。これで、この取引の商業処理が終了する。

0075

Select CommerceAID(商業AID選択)要求およびPPSE Select(PPSE選択)要求が成功すれば、支払い端末401は、それが受信した支払いアプリケーションデータおよび支払い認証情報を売主POSシステム402に処理目的で転送する(「Payment/Card Data(支払い/カードデータ)」)。すると、売主POSシステムは、支払い認可要求を支払いプラットフォーム403に送る(「Payment Auth Request(支払い認可要求)」)。すると、支払いプラットフォーム403は、支払いが認可されたかどうかを示す認可結果(Authorization Result)を返送する。

0076

商業および支払いの認証情報と情報とが成功裏に読み取られた場合、読み取り装置120は、ステップ478(「Read Success Indication(成功表示の読み出し)」)に示すように、支払い端末140上のインターフェース、商業ウィジェット115(図1)または支払いウィジェット119(図1)を介して通知を提供することが可能である。

0077

商業メッセージの規格
データの符号化
1つの実施形態では、全てのコマンド/応答のデータが、BER−TLV(ISO7816−4 Annex D)形式を用いて符号化される。一部の場合では、TLV(Tag、Length、Value)はネスティングされ得る(埋め込みTLV)。TLV符号化形式フレキシブル性質のために、タグ付けされたデータは、どのような順序でも位置付けされ得る。これは、入力ペイロードおよび出力ペイロードの双方のデータを形式化する場合に当てはまる。加えて、このデータは、記録指向の表に記憶される。その中に記憶されるTLV符号化されたデータの要素の順序は重要ではないが、しかしながら、一部のデータは、索引/検索性能を向上させるために記録の最初に位置付けされ得る。したがって、この文書に提供される記憶データテーブルは、参照目的のサンプルとして供給される。

0078

タグは、1つ以上の後続のバイト上に符号化されたプリミティブデータオブジェクトを表す「プライベートな」タグクラスとタグタイプとを用いて符号化される。したがって、第1のバイト(タグクラス)は、0xDFに設定される。あらゆる場合において、データ要素タグは、1つのバイト上で定義される。したがって、第2のタグバイトは、0に設定された最高位ビット(b8)を有する。これが、最大で128の有効なタグ値(0x00〜0x7F)を可能とする。

0079

長さを符号化することによって、短い形式または長い形式の双方をサポートする。長さがその128バイト未満(<)のとき、最高位ビット(b8)は0に設定され、実際の長さは、残りのビット(b7〜b1)で指定される。長さが128バイトを超える(>)とき、最高位ビット(b8)は1に設定され(長さマスク=0x80)、残りのビット(b7〜b1)は、長さフィールド中の後続のバイトの数を定義する。これらの後続のバイトは、値フィールド中のバイトの数に等しい整数を符号化する。

0080

BER−TLVの例
入力データが、8バイトの長さおよび(0x1122334455667788)の値を持つ0x21(消費者ID)のタグ値を用いると仮定すると、このデータは表1に示すように符号化される。

0081

TLV符号化は、長さのインジケータ複数バイトで表すことを可能とする。好ましくは、多バイト長がサポートされる。短い形式では、長さフィールドは、ビット8が0に設定され、ビット7〜1が、値フィールド中のバイト数を符号化する1バイトから成る。1バイトは、したがって、ゼロ〜127までの任意の数を符号化することが可能である。1〜127までのいかなる数も、LcおよびLeのフィールド中でと同じ方法でBER−TLV長さフィールド中で符号化されている。符号化は、ゼロ、128、およびそれ以上とで異なる。例えば、以下に説明するGet Commerce Data(商業データ取得)コマンド中のデータオブジェクトのコーディングを参照のこと。

0082

長い形式では、長さフィールドは、2バイト以上から成る。第1のバイトのビット8は1に設定され、ビット7〜1はすべてが等しいわけではなく、これで、長さフィールド中の後続のバイトの数を符号化する。これらの後続のバイトは、値フィールド中のバイトの数を符号化する。ISO/IEC7816は、1、2、・・・から最大で5バイトまでの長さフィールドをサポートするANSIISO/IEC7816の基本的符号化規則によって指定された「不定長」は用いない(表2)。ISO/IEC7816では、「80」および「85」〜「FF」の値は、長さフィールドの第1のバイトにとっては無効である。

0083

Select Commerce Applet(商業アプレット選択)
1つの実施形態では、読み取り装置120が、読み取り装置120のフィールド中のモバイルデバイス110を検出して、NFC通信が開始した場合に処理が開始される。その場合に、読み取り装置120は、商業アプレットを選択するために、コマンド、特に「Select Commerce(商業選択)」コマンドをセキュア・エレメント112に送る。Select Commerce(商業選択)コマンド(「Select Commerce Applet(商業アプレット選択)」コマンドとも呼ばれる)は、ISO78016−3規格中に定義されているように標準化される。例としてのSelect Commerce(商業選択)コマンドの構造を表3に示す。

0084

モバイルデバイス110中のセキュア・エレメント112は、「Select Commerce(商業選択)」コマンドを有効化して、適切な応答を送り返す。例としての応答(「ステータスコード」とも呼ばれる)を、表4に示す。

0085

「90 00」(「成功したコマンド実行」)以外の全ての応答は、商業アプリケーション121(図1)に、読み取り装置120中で終了させて、制御権をEPMに渡させる。

0086

Get Commerce Data(商業データ取得)
読み取り装置アプリケーション121が開始され、読み取り装置120とセキュア・エレメント112間の通信が開始されると、読み取り装置120は、コマンドをモバイルデバイス110に送って、商業データを獲得する(「Get Commerce Data(商業データ取得)」)。例示のGet Commerce Data(商業データ取得)コマンドは、以下の表5および6中に定義されている。この例では、特定のロイヤルティおよびオファーのデータが要求されている。「売主能力」フィールドは、どのフィールドが要求データおよび応答データ中に存在する必要があるかを判定するために、読み取り装置120によって利用される。

0087

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

0088

例示の実施形態では、Get Commerce Data(商業データ取得)要求中のデータ要素は、セットアップ時間において、読み取り装置120またはPOS端末140中で事前構成される。このデータは、読み取り装置120がインストールされ構成された後で修正し得る。







0089

表7に、Get Commerce Data(商業データ取得)コマンドによって返送され得る可能なステータスワード値を定義する。

0090

「61 xx」または「90 00」以外のいかなる応答も、結果として、読み取り装置120が、エラーを記録して、商業ウィジェット115に転送するデータを記憶した後で、商業アプリケーション121を終了させて、制御権をEPMに渡すことになる。

0091

Get Commerce Data(商業データ取得)要求が正確に形式化されると、セキュア・エレメント112上の商業アプレット113は、売主識別子(「Merchant_ID」)、ロイヤルティ識別子(「Loyalty_ID」)、およびオファータイプコード(「Offer_Type_Code」)に基づいてデータをフィルタリングして、要求中のバージョン番号に基づいて読み取り装置120用の応答データを形式化する。商業アプレット113は、2つ以上のロイヤルティIDおよび複数のオファーメッセージを、財布中の構成に基づいて返送し得る。表8に、例示の応答データをリストアップする。

0092

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

DF21 10 00 11 22 33 44 55 66 77 88 99 AA BB CCDDEEFFDF 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
(消費者ID)

DF 41 06 18 DB 6E 23 F4 0B (MoComロイヤルティID)

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 (MoComオファーID)#1

DF 53 09 02 42 41 31 38 37 36 35 34 (売主オファーコード)#1

DF 51 08 88 77 66 55 44 33 22

0093

取引後データ
上に説明したように、Post Transaction Data(取引後データ)コマンドは、売主POSシステム(MPOS)からデータを戻して受信する機構を提供する。このコマンドは、売主POS端末140によって開始され、好ましくは、売主機能フィールドにサポートされる。例示の実施形態では、このコマンドは、255バイトの最大データサイズを持つ単一のデータフレームから成る。データの内容は、標準のTLV形式化を用いているが、また可変でもあり得る。このコマンドは、動的調停または取引後データ統合を可能とする。さらなるデータタグが、POS端末/MPOSからのさらなるデータのモバイルデバイス110中のセキュア・エレメント112への送信目的で定義され得る。例示の取引後データコマンド(「Post Transaction Data(取引後データ)」)を表9および10に示す。

0094

マルチブロックデータの取り扱い
図5は、例としての実施形態に関わる例示のマルチブロックデータフローを示す。セキュア・エレメント112が送出する255バイトを超えるデータを有するとき、Get Response(応答取得)コマンド(C0)を用いて、残りの応答データを回収する。特に、このコマンドは、商業アプレット113が例えば、255バイトを超える応答データを送らなければならない場合に、残りのデータを獲得するために用いられる。

0095

図5を参照すると、ユーザが商業対応のモバイルデバイス110を読み取り装置120にタップした後、読み取り装置120はSelect Commerce(商業選択)コマンドをモバイルデバイス110のセキュア・エレメント112に送る。肯定応答(「90 00」)は、読み取り装置120に、Get Commerce Data(商業データ取得)コマンドを送らせる。それに応答して、セキュア・エレメント112は、ロイヤルティおよびオファーのデータを返送する。図5に示すように、Get Commerce Data(商業データ取得)応答ステータスSW1フラグは「61」に設定され、SW2フラグは「00」に設定される。

0096

Get Response(応答取得)コマンドは、Get Commerce Data(商業データ取得)応答中のSW1フラグが「61」に設定される場合にトリガされる。この例では、SW2フラグは「00」に設定されるが、それは、モバイルデバイス110上の商業アプレット113が、どれほど多くのデータが送られずに残っているか知り得ないからである。Get Response(応答取得)コマンドに対する後続の応答もまた、「61」に設定されたSW1フラグを含み、第2のGet Response(応答取得)コマンドに、モバイルデバイス110に対して読み取り装置120によって送られるようにする。

0097

このシーケンスは、Get Commerce Data(商業データ取得)応答のSW1フラグが「61」以外の任意の値に設定された場合に終了する。例えば、図5に示すようなGet Response(応答取得)コマンドに対する応答としての「90」のSW1の値は、正常完了を示す。他のいかなるSW1値も、エラーとしてログすることが可能である。

0098

表11に、Get Response Data(応答データ取得)APDUコマンドの例示の設定を定義する。

0099

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

0100

表12に、Get Response Data(応答データ取得)APDUコマンドによって返送され得る可能なステータスワード値(「ステータスコード」)を定義する。

0101

読み取り装置構成データ
1つの実施形態では、読み取り装置120の設置および構成中に、ある売主と商業とに固有のデータが、読み取り装置120中にロードされて保存される。このデータは、読み取り装置120からのGet Commerce Data(商業データ取得)コマンドに記入するために読み取り装置120によって用いられる。これらのデータ要素は、新しい特徴として更新することが可能であり、機能は利用可能となる。

0102

商業AID
上で説明したように、商業AIDは、Select Commerce(商業選択)コマンドで送られる。このコマンドがモバイルデバイス110によって容認されれば、商業アプレット113が開始され、APDUコマンド/応答のフローが、読み取り装置120とセキュア・エレメント112との間で開始される。例示の実施形態では、商業AID値は、A00000048510010101である。この値は、読み取り装置120上でハードコードすることが可能である。1つの実施形態では、読み取り装置120は、部分的選択をサポートするためには必要ない。

0103

Merchant_ID
売主識別子(Merchant_ID(DF31))は、読み取り装置120上にロードすることが可能である。売主IDは、サービスプロバイダによって割り当てられた値である。1つの実施形態では、この値は、MoComプラットフォーム操作者によって割り当てられる。これは、商業アプレット113に、ロイヤルティおよびクーポンのデータをフィルタリングして、適当な項目を読み取り装置120に送ることを可能とするために必要とされる。

0104

Merchant_Store_ID
売主店舗識別子値(Merchant_store_ID(DF32))は、読み取り装置120上にロードされ、かつサービスプロバイダによって割り当てられる値である。この値は、例えば、報告目的に用いることが可能である。

0105

Loyalty_ID
ロイヤルティ識別子値(Loyalty_ID(DF41))は、複数のロイヤルティIDがタップ中に要求された場合に用いられる。これは、二次ロイヤルティを売主能力(DF33)中に設定することによって遂行される。これが、商業アプレット113が、Get Commerce Data(商業データ取得)コマンドに応答してさらなるロイヤルティ番号を返送することを可能とする。複数(例えば5つ)のさらなるLoyalty_IDが、Get Commerce Data(商業データ取得)要求中にコーディングされる。

0106

Offer_Type_Codes
オファータイプのコード(Offer Type Codes(DF54))は、読み取り装置120上にロードされる。Offer Type Codesに割り当てられる値は、サービスプロバイダによって割り当てられる。この値は、オファーをフィルタリングして、適当な項目だけを読み取り装置120に送るために、商業アプレット113によって用いられる。複数のOffer_Type_Codesを、定義して、Get Commerce Data(商業データ取得)コマンド中でセキュア・エレメント112に送ることが可能である。

0107

Commerce_Application_Version
商業アプリケーションバージョン番号(Commerce_Application_Version)は、読み取り装置120上にロードして、読み取り装置120上のアプリケーションがコーディングされ、かつ証明された対象である商業読み取り装置規格のバージョンを表すことが可能である。

0108

Merchant_Capabilities
Merchant Capabilitiesの値は、特定の売主によってサポートされる商業の特徴を表す。このデータ要素もまた、Get Commerce Data(商業データ取得)コマンドを形式化するために読み取り装置120によって用いられることが可能である。

0109

Terminal_Startup_Mode
端末開始モードコマンド(Terminal Start Mode(DF34))は、読み取り装置120に対して、商業アプリケーション121を開始するために用いられる機構を提供することを指令する。このデータ要素は、セキュア・エレメント112には送られない。このデータ要素はまた、ハンドセット上で読み取り装置120とセキュア・エレメント112との間での処理フローを定義するために用いられる。

0110

Get Commerce Data(商業データ取得)フィールド
表13に、Select Commerce(商業選択)コマンドおよびGet Commerce Services(商業サービス取得)コマンドを形式化するために読み取り装置120によって必要とされるデータの例示の定義を提供する。

0111

商業アプレットバージョン形式
Commerce Applet Version(商業アプレットバージョン)値は、2バイトの16進法フィールドであり、第1のバイトがメジャーバージョン(xx)を含み、第2のバイトがマイナーバージョン(xx)を含んでいる。これらのフィールドは、読み取り装置120上に実装されている特定のバージョンの読み取り装置商業技法規格に従って更新される。例示の実施形態では、商業アプリケーション121の最初の公式発表は0x0100である。

0112

売主能力
売主能力フィールド(Merchant Capabilities Field(DF33))は、どの商業機能が売主によって実装されているかを判定する。読み取り装置120は、このフィールドをモバイルデバイス110に渡すことが可能であり、モバイルデバイス110はこの情報を用いて、Commerce Data Response(商業データ応答フレームと呼ばれる応答フレームを構築する。表14に、例示の売主能力を示す。

0113

消費者開始モード形式
商業開始モード形式値(Commerce Start Mode(DF34))は、読み取り装置120上の商業アプリケーション121を開始するために何の機構を用いるかを読み取り装置120に対して示す。1つの実施形態では、このデータ要素は、Get Commerce Data(商業データ取得)コマンド中でモバイルデバイス110に送られない。別の実施形態では、このデータ要素はオプションである。表15に、商業アプリケーション121を開始する為に例示の開始モードを用いることが可能であることを示す。例示の実施形態では、ビット7および8は、排他的であり、一時に1ビットしかオンされない。

0114

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

0115

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

0116

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

0117

ロイヤルティID
ロイヤルティ識別子(Loyalty ID)は、タップ事象中に要求された各々の消費者ロイヤルティ番号と共に送られる。ロイヤルティIDは、MoComプラットフォームによって割り当てられた各売主ロイヤルティプログラムに割り当てられた固有の値である。ほとんどの場合、読み取り装置によって受信されたロイヤルティIDは、Get Commerce data(商業データ取得)コマンドによって構成された売主IDと一致する。売主システムによるこの情報の使用はオプションである。

0118

消費者ロイヤルティコード
消費者ロイヤルティコード(Consumer Loyalty Code)は、特定の売主ロイヤルティプログラムに対して消費者に割り当てられたロイヤルティ番号と一致する。財布アプリケーション114は、複数のロイヤルティ番号がタップで提示されることを可能とする。システムが複数の消費者ロイヤルティコード用にセットアップされている場合、各々の消費者ロイヤルティコードは、その固有のロイヤルティIDに先行される。

0119

オファーID
モバイル商業オファー識別子(Offer ID)は、商業関連のセッション中に送られた各々の消費者オファー番号と共に送られる。オファーIDは、消費者の財布に対して送達された各々のオファーに割り当てられた固有の値である。1つの実施形態では、MoComプラットフォームによって生成された2つのオファーIDが同じ値であるということはない。

0120

売主オファーコード
売主オファーコード(「Merchant Offer Code」または「Offer Number」)は、売主によって生成されて、様々な手段によって消費者の財布アプリケーションにロードされる。この番号は、処理目的で、売主POSシステム上で定義された同じオファーと一致する。単一の商業取引中に、複数の売主オファー(例えば10の)が提示され得る。売主システムは、入力データを解析して、個々の売主オファーを抽出する。

0121

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

0122

1つの実施形態では、データ要素「Terminal Start Mode」は、読み取り装置120に渡されるが、セキュア・エレメント112には渡されない。読み取り装置120は、この情報を用いて、Select Commerce(商業選択)コマンドおよびSelect PPSE(PPSE選択)コマンドがいつセキュア・エレメント112に送られるかを制御する。

0123

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

0124

Select CommerceAID(商業AID選択)コマンド
商業アプリケーションが読み取り装置120上で開始され、デバイスが読み取り装置120のフィールド中で検出された後、送られる最初のコマンドはSelect Commerce AID(商業AID選択)である。このコマンドは、ISOによって割り当てられたRID値と、商業サービスプロバイダによって生成されたPIX値とを含む。商業AID値は、A00000048510010101である。この値は、読み取り装置120上にハードコードされるべきである。

0125

Get Commerce Data(商業データ取得)コマンド
Get Commerce Services Data(商業サービスデータ取得)コマンドは、セキュア・エレメント112に対する一般的なデータ要求である。Get Commerce Data(商業データ取得)は、商業アプレット113に情報を通信する多くの必要なフィールドおよびオプションのフィールドを有する。商業アプレット113は、この情報を用いて、読み取り装置120に送る必要があるデータ要素を構築する。読み取り装置120は、売主能力記録中のフィールドを用いて、そのオプションフィールドをハンドセットに対する要求中に含める必要があるかを判定する。

0126

取引後データ
Post Transaction Data(取引後データ)コマンドは、MPOSからデータを戻して受信するための機構を提供するために作成された。このコマンドは、255バイトの最大データサイズを持つデータの単一フレームから成る。このデータの内容は、標準のTLV形式化を用いているが、内容は可変である。更なるデータタグは、POS端末/MPOSからモバイルデバイス110中のセキュア・エレメント112に対して更なるデータを送信するように定義され得る。

0127

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

0128

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

0129

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

0130

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

0131

表18に、商業アプレット113によってサポートされている例示のAPDUコマンドのマスターリストを提供する。

0132

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

0133

例示の実施形態では、次のデータ要素は次の形式値を含む。
・ロイヤルティアカウントコード(DF43)
・オファーコード(DF53)

0134

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

0135

最初のニブルに16進法値「F」を含むBCD符号化されたデータ値は、奇数個の桁を含むデータストリームを特定するものとする。したがって、BCDデータストリーム12345は、0xF12345のように3バイトバッファで符号化される。

0136

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

0137

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

0138

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

0139

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

0140

ユーザはオファー(例えば、606a)を選択して、次に、画面の底部の「実施済み」バーを選択し得る。

0141

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

0142

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

0143

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

0144

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

0145

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

0146

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

0147

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

0148

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

0149

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

0150

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

0151

ブロック708で、MoCom消費者IDが存在しないことが判定された場合、ブロック706で、支払い過程が完了し、チェックアウト過程は支払いを処理することによって完了される。

0152

ブロック708で、MoCom消費者IDが存在することが判定された場合、ブロック710で、MoComオファー(例えば、財布アプリケーションを介してユーザによって選択されたオファー)が存在するかどうかについて判定される。ブロック710で、MoComオファーが存在すると判定された場合、ブロック712で、MoComインスタントオファーも定義されたかどうかについて判定される。ブロック712で、MoComインスタントオファーも定義されたと判定された場合、MoComオファー(すなわち、財布アプリケーションインターフェースを介してユーザによって選択されたオファー)とMoComインスタントオファーとの双方が、ブロック714に示すように処理される。一旦MoComオファーおよび/またはMoComインスタントオファーが処理されると、これらのオファーと関連付けられた支払いが、ステップ706に示すように処理される。

0153

ブロック710で、MoComオファーが存在しないと判定された場合、ブロック716で、MoComインスタントオファーが定義されているかどうかについて判定される。定義されていなければ、支払いは、ステップ706に示すように完了する。MoComインスタントオファーが存在すると、ブロック716で判定された場合、Mocomインスタントオファーはブロック718で示すように処理され、MoComインスタントオファーと関連付けられた支払いは、ブロック706に示すように処理される。

0154

MoComインスタントオファーが定義されているとブロック712で判定された場合、標準のMoComオファーが、ブロック720で示すように処理され、ブロック706で、処理された支払いが完了される。

0155

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

0156

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

0157

商業アプレットパッケージ/アプレット/インスタンス管理
次の章は、商業アプレット113(図1)のダウンロードインストール中に用いられるAID値およびアプリケーション固有パラメータを定義する。表20は、AIDを定義する。

0158

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

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

0159

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

0160

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

0161

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

0162

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

0163

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

0164

表24に、ロイヤルティデータテーブルに含まれるデータ要素(および、TLV符号化中に用いられるそれらの対応するタグ値)を定義する。

0165

データは、記録指向のデータバッファ中に記憶されるが、そこでロイヤルティ識別子(「Loyalty ID」)は、検索/回収のタスク用のキーフィールドとして利用される。

0166

例示の実施形態では、TLVデータオーバーヘッドは、BER−TLV符号化形式で必要とされる要素データオーバーヘッド(2バイトタグおよび3バイト長)当たり(最大で)5バイトを含む。

0167

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

0168

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

0169

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

0170

データは、記録指向のデータバッファ中に記憶されるが、そこで売主識別子(「Merchant ID」)は、検索/回収のタスク用のキーフィールドとして利用される。索引(またはハッシュ表)は、売主ID検索タスクをスピードアップするために内部で作成され得る。

0171

例示の実施形態では、TLVデータオーバーヘッドは、BER−TLV符号化形式で必要とされる要素データオーバーヘッド(2バイトタグおよび3バイト長)当たり(最大で)5バイトを含む。

0172

取引ログ
商業アプレット113は、売主の販売時点でのMoComプラットフォーム内での使用を追跡するために用いられる取引ログを含む。商業ウィジェット115およびセキュア・エレメント112の同期化タスク中、この取引ログは、後でMoComプラットフォームとの無線(「OTA」)同期化のために、商業ウィジェット115にまで送信される。

0173

この取引ログの実際の内容は、売主の販売時点での取引過程中で読み取り装置120によって提供されたGet Commerce Data(商業データ取得)コマンドデータ/パラメータによって異なる。Get Commerce Data(商業データ取得)APDUコマンドを介して読み取り装置120によって商業アプレット113に送られるデータペイロードの正確なコピーは、その商業取引の記録内に記憶される。

0174

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

0175

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

0176

データは、記録指向データバッファ中に記憶される。可変のGet Commerce Data(商業データ取得)コマンドのデータサイズがサポートされる。

0177

TLVデータオーバーヘッドは、BER−TLV符号化形式で必要とされる要素データオーバーヘッド(2バイトタグおよび3バイト長)当たり(最大で)5バイトを含む。

0178

エラー管理
例示の実施形態では、エラー検出および管理は、2つの水準で取り扱われる。第一は、APDUコマンドの応答は、2バイトのステータスワードの結果値を含む。これらの応答は、ISO7816−4によって標準化され、指示される。しかしながら、第2の水準のエラー取り扱いは、商業サービスアプレットによって内部で管理される。第2の水準の管理は、APDUコマンドに対する応答中での標準の0x6909のステータス語の発行を含む。この応答に続いて、顧客は、2バイトの内部エラーコードを得るために、第2のコマンド(「Get Internal Error Code(内部エラーコード取得)」)を発行し得る。このコードは、表27に相互参照され得る。表27は、エラーがアプレット内のどこで、かつなぜ発生したかの詳細を提供する。

0179

特に、表27は、商業アプレットによってサポートされているGet Internal Error Code(内部エラーコード取得)APDUコマンドによって返送された全ての可能な内部エラーコードのマスターリストを提供する。

0180

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

0181

APDUコマンド
商業アプレット113との全ての通信/データの交換は、ISO7816基準中に定義されているAPDUコマンドを介して実施される。さらなる規制およびデータ取り扱いは、以下に説明する。

0182

コマンドの使用制限
セキュリティ上の理由から、利用可能な商業サービスコマンドのサブ集合は、特定の接続モードに制限することが可能である。「接触(財布)モード」と呼ばれる1つの実施形態では、上の表18に定義されているAPDUコマンドの全てが利用可能である。しかしながら、非接触モードでは、次のコマンドが許容される。
・Get Version(バージョン取得)
・Get Internal Error Code(内部エラーコード取得)
・Get Response(応答取得) (残りのデータ)
・Get Commerce Data(商業データ取得)

0183

いずれかの他のAPDUコマンドが非接触モードで送られた場合、例外処理が実行され、Internal Error Code(内部エラーコード)が対応する無効コマンドモード値(0x0102)に設定される。

0184

1つの実施形態では、Get Commerce Data(商業データ取得)コマンドは、財布アプリケーション114が開かれている場合にしか成功裏には実行され得ない。財布アプリケーション114が消費者によって開始されたまたは終了された場合に、財布伴侶アプレット(WCAp)に通知し、それによって、それが監視、管理、および/またはセキュリティの機能を実施することが可能であるようにすることは、財布アプリケーション114の責任である。WCApアプレットは、すると、商業アプレットに、共有インターフェースを介して、財布アプリケーションの状態を通知する。WCApアプレットは、その全体が参照して本明細書に組み込まれる、「Systems, Metohods,and Computer Program Products For Securing And Managing Applications On Secure Elements」という題名の米国特許出願第13/857,400号に開示されている。

0185

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

0186

Get Version(バージョン取得)
Get Version(バージョン取得)コマンドは、現在ロードされている商業アプレット113のバージョン情報を得るために用いられる。バージョンは、3バイト(xx.yy.zz)で記憶されるが、式中、xx=発表バージョン、yy=メジャーバージョン(ウェーブ)番号、zz=マイナーバージョン番号である。この情報は、例えば、MoComプラットフォームによって割り当てられる、アプレットの開発またはパッケージング中に指定される、またはコード内に静止値として記憶されて、変更不可能である。

0187

表28に、Get Version(バージョン取得)APDUコマンドの設定を定義する。

0188

1つの実施形態では、商業アプレットには何もデータは送られない。Lcデータ長は0x00である。

0189

バージョン情報は、3バイトの応答内に含まれる。Leデータ長は0x03である。0x00の長さもまた許容される。例示の応答データ要素は、表29に定義されている。

0190

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

0191

Provision Applet(アプレット供給)
アプレット供給コマンド「Provision Applet(アプレット供給)」は、消費者IDおよび、オプションとして関連するセキュリティデータ鍵値および証明書)を含む消費者関連のデータの供給(または更新)を可能とする。新しい/更新されたデータ値は、コマンドデータを介して指定される。例示の実施形態では、Provision Applet(アプレット供給)コマンドは、消費者IDを更新するためにしか用いられ得ない。

0192

表31および32は、Provision Applet(アプレット供給)APDUコマンドの設定を定義する。

0193

表31に示す入力データは、TLV符号化された供給データから成る。したがって、Lcデータ長は可変である。

0194

1つの実施形態では、商業アプレット113によって返送されるデータはない。Leデータ長は0x00である。

0195

表33に、Provision Applet(アプレット供給)コマンドによって返送され得る可能なステータスワード値を定義する。

0196

Get Consumer Info(消費者情報取得)
Get Consumer Info(消費者情報取得)コマンドは、トークン所有者(すなわち、消費者)に関連する静止データのサブ集合を得るために用いられる。このデータは、次のものを含む:

0197

消費者識別子
表34に、Get Consumer Info(消費者情報取得)APDUコマンドの設定を定義する。

0198

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

0199

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

0200

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

0201

Get Commerce Data(商業データ取得)
Get Commerce Data(商業データ取得)コマンドは、指定された売主/ロイヤルティ識別子およびサポートされているオファータイプに基づいて、指定された売主(または売主の集合)に対する商業情報(例えば、ロイヤルティ、オファー、および報酬)を提供する。このコマンドは、売主のPOSシステム(例えば、POS端末)に付けられた読み取り装置120に対する単一の接触点を提供する。

0202

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

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

0203

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

0204

表37および38に、Get Commerce Data(商業データ取得)APDUコマンドの設定を定義する。

0205

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

0206

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

0207

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

0208

消費者ID
消費者IDはTLV形式で送られるが、この場合、データはタグCONSUMER_ID(0XDF21)を用いて送られる。1つの実施形態では、エラーが検出されない場合、消費者IDは、常に返送されるものとする。

0209

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

0210

このデータストリーム内で、第1のタグは、ロイヤルティ識別子タグ(T)バイト(0xDF41)を含むものとする。長さ(L)バイトは、ロイヤルティ識別子の長さを指定するものとする。値(V)は、すぐ後に続く対応するロイヤルティデータに対する長さLの実際のロイヤルティ識別子を含むものとする。

0211

第2のタグは、ロイヤルティアカウントコードタグ(T)バイト(0xDF43)を含むべきである。長さ(L)バイトは、前のロイヤルティ識別子にリンクされたアカウントコードデータの全長を指定するものとする。値(V)は、長さLの実際のロイヤルティデータを含むものとする。

0212

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

0213

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

0214

このデータストリーム内で、第1のタグは、オファーIDタグ(T)バイト(0xDF51)を含む。長さ(L)バイトは、オファーIDの長さを指定する。値(V)は、すぐ後に続く対応するオファーデータに対するオファーIDを含む。

0215

第2のタグは、好ましくは、オファーコードタグ(T)バイト値(0xDF53)を含む。長さ(L)バイトは、オファータイプコードの長さを指定する。値(V)は、対応するオファーIDに対するオファーコードデータを含む。

0216

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

0217

商業アプレット113は、合計のデータ長が256バイトを超える場合に、(Get Response(応答取得)コマンドを用いて)複数の応答パケットの送信を管理する。表40に、Get Response(応答取得)コマンドによって返送され得る可能なステータスワード値を定義する。

0218

取引後データ
Post Transaction Data(取引後データ)コマンドは、売主PoSシステムまたは支払い端末が、償還されたクーポン、新しいオファー、電子領収書、または他の向上した商業データを含む取引後データを返送し得る方法を提供する。

0219

表41および42に、Post Transaction Data(取引後データ)APDUコマンドの設定を定義する。

0220

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

0221

データは、商業アプレット113によって返送される必要はない。Leデータ長は0x00である。

0222

表43に、Post Transaction Data(取引後データ)コマンドによって返送され得る可能なステータスワード値を定義する。

0223

Get Transaction Log(取引ログ取得)
Get Transaction Log(取引ログ取得)は、取引ログ中に記憶されている全てのデータを得るために用いられる。このコマンドは、一般的には、ウィジェット目的の商業ウィジェットおよびセキュア・エレメントデータ同期化のタスクによって用いられる。

0224

表44に、Get Transaction Log(取引ログ取得)APDUコマンドの設定を定義する。

0225

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

0226

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

0227

取引ログ応答データ
各々の取引ログ記録は、埋め込みTLV取引ログタグとそれに続く全ての関連するデータ要素とから成りたつものとする。取引記録に含まれるデータ要素は、売主の販売時点での商業対応の支払い端末(NFC読み取り装置)によって要求される対応するGet Commerce Data(商業データ取得)コマンド中に提供されるもののミラーである。さらなる取引得ログ記録は、同じ形式を用いてデータに添付される。表45に、例示の応答データを示す。

0228

1つの実施形態では、商業アプレット113は、合計のデータ長が256バイトを超える場合に、Get Response(応答取得)コマンドを用いて複数の応答パケットの送信を管理する。

0229

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

0230

表47に、Get Transaction Log(取引ログ取得)コマンドによって返送され得る可能なステータスワード値を定義する。

0231

Get Internal Error Code(内部エラーコード取得)
Get Internal Error Code(内部エラーコード取得)コマンドは、商業サービスアプレットによって生成された最後の内部エラーコードを回収するために用いられる。このコードは、内部エラーコード表(表26)と相互参照されて、エラーのより具体的な説明を提供することが可能な値を提供する。このコマンドは、より詳細な診断およびエラー解決のために用いられる。

0232

表48は、Get Internal Error Code(内部エラーコード取得)APDUコマンドの設定を定義する。

0233

1つの実施形態では、アプレットにはデータは送られない。Lcデータ長は0x00である。エラーコードは、2バイトの応答内に含まれる。したがって、Leデータ長は0x02である。

0234

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 東芝テック株式会社の「 情報処理装置およびプログラム」が 公開されました。( 2020/09/24)

    【課題】本発明が解決しようとする課題は、プリンタが印字した顧客が受け取る印字物を確実に顧客側に発行することが可能な情報処理装置およびプログラムを提供することである。【解決手段】実施形態の情報処理装置は... 詳細

  • アパホテル株式会社の「 ルームキー回収ボックス及びこれを用いたチェックアウトシステム」が 公開されました。( 2020/09/24)

    【課題】 ルームキーの回収のみならず、回収したルームキーの部屋情報を取得可能なルームキー回収ボックス及びこれを用いたチェックアウトシステムを提供する。【解決手段】宿泊施設におけるルームキーを回収する... 詳細

  • 東芝テック株式会社の「 情報処理装置」が 公開されました。( 2020/09/24)

    【課題】 複数の税率が商品毎に選択的に適用される状況において、各商品がどの税率が適用される商品であるかを容易に確認可能とする。【解決手段】 実施形態の情報処理装置は、商品判定手段、税率判定手段... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ