(57)【特許請求の範囲】
【請求項１】
支払いデバイスでトランザクションを処理するための支払いリーダであって、
前記支払いデバイスとのインタフェースとなるよう、かつ、前記支払いデバイスから支払い情報を受けるよう構成された支払いインタフェースと、
複数のファームウエアモジュールを含むメモリであって、前記複数のファームウエアモジュールがメッセージディスパッチャモジュールと複数の機能モジュールとを含み、前記複数の機能モジュールが前記支払いインタフェースに関連付けられた支払いモジュールと前記支払い情報の処理に関連付けられたトランザクション処理モジュールとを有する、メモリと、
前記複数のファームウエアモジュールにおいてインストラクションを実行するよう構成されたプロセッサであって、前記プロセッサが前記複数の機能モジュールに関連付けられたインストラクションを、前記メッセージディスパッチャモジュールによって提供されたひとつ以上のメッセージに基づいて、実行するよう構成され、かつ、前記支払いモジュールと前記ひとつ以上のメッセージのうちの第１メッセージとに基づいて支払い情報を受けるよう構成され、かつ、前記トランザクション処理モジュールと前記ひとつ以上のメッセージのうちの第２メッセージとに基づいて該支払い情報を処理するよう構成される、プロセッサと、を備え、
前記ひとつ以上のメッセージのうちの第１メッセージタイプは前記機能モジュールの同時動作に関連付けられ、前記ひとつ以上のメッセージのうちの第２メッセージタイプは前記機能モジュールの順番動作に関連付けられる支払いリーダ。
【請求項２】
前記第１メッセージタイプが前記第１メッセージに関連付けられ、前記第２メッセージタイプが前記第２メッセージに関連付けられる請求項１に記載の支払いリーダ。
【請求項３】
前記第１メッセージタイプが計時メッセージを含み、前記第２メッセージタイプが標準メッセージを含む請求項１に記載の支払いリーダ。
【請求項４】
前記プロセッサが、タイミング値と前記メッセージディスパッチャモジュールの前記インストラクションとに基づいて、前記機能モジュールの前記同時動作を可能とするよう構成される請求項１から３のいずれか一項に記載の支払いリーダ。
【請求項５】
前記プロセッサが、前記メッセージディスパッチャモジュールの前記インストラクションに基づいて、前記タイミング値が満了しない間に、前記支払いモジュールに前記第１メッセージタイプの前記第１メッセージを提供するよう構成される請求項４に記載の支払いリーダ。
【請求項６】
前記プロセッサが、前記メッセージディスパッチャモジュールの前記インストラクションに基づいて、前記タイミング値が満了したときに、前記支払いモジュールに前記第１メッセージタイプの前記第１メッセージを提供するよう構成される請求項４に記載の支払いリーダ。
【請求項７】
支払いトランザクションを処理する方法であって、
複数のファームウエアモジュールのうちのメッセージディスパッチャモジュールから前記複数のファームウエアモジュールのうちの複数の機能モジュールのうちのひとつ以上にひとつ以上のメッセージを提供することであって、前記ひとつ以上のメッセージのうちの第１メッセージタイプが前記機能モジュールの同時動作に関連付けられ、前記ひとつ以上のメッセージのうちの第２メッセージタイプが前記機能モジュールの順番動作に関連付けられる、提供することと、
前記複数の機能モジュールのうちの支払いモジュールが支払い情報を受けるべきであることを、前記メッセージディスパッチャモジュールのインストラクションに基づいて、決定することと、
前記決定することと前記支払いモジュールのインストラクションと前記ひとつ以上のメッセージの第１メッセージとに基づいて、支払いインタフェースから支払い情報を受けることと、
前記複数の機能モジュールのうちのトランザクション処理モジュールのインストラクションと前記ひとつ以上のメッセージのうちの第２メッセージとに基づいて、前記受けた支払い情報を処理することと、を含む方法。
【請求項８】
前記第１メッセージタイプが前記第１メッセージに関連付けられ、前記第２メッセージタイプが前記第２メッセージに関連付けられる請求項７に記載の方法。
【請求項９】
タイミング値と前記メッセージディスパッチャモジュールの前記インストラクションとに基づいて、前記機能モジュールの前記同時動作を可能とすることをさらに含む請求項７または８に記載の方法。
【請求項１０】
前記メッセージディスパッチャモジュールの前記インストラクションに基づいて、前記タイミング値が満了しない間に、前記支払いモジュールに前記第１メッセージタイプの前記第１メッセージを提供することをさらに含む請求項９に記載の方法。
【請求項１１】
前記メッセージディスパッチャモジュールの前記インストラクションに基づいて、前記タイミング値が満了したときに、前記支払いモジュールに前記第１メッセージタイプの前記第１メッセージを提供することをさらに含む請求項９に記載の方法。
【請求項１２】
複数のファームウエアモジュールのうちのメッセージディスパッチャモジュールから前記複数のファームウエアモジュールのうちの複数の機能モジュールのうちのひとつ以上にひとつ以上のメッセージを提供する機能であって、前記ひとつ以上のメッセージのうちの第１メッセージタイプが前記機能モジュールの同時動作に関連付けられ、前記ひとつ以上のメッセージのうちの第２メッセージタイプが前記機能モジュールの順番動作に関連付けられる、提供する機能と、
前記複数の機能モジュールのうちの支払いモジュールが支払い情報を受けるべきであることを、前記メッセージディスパッチャモジュールのインストラクションに基づいて、決定する機能と、
前記決定することと前記支払いモジュールのインストラクションと前記ひとつ以上のメッセージの第１メッセージとに基づいて、支払いインタフェースから支払い情報を受ける機能と、
前記複数の機能モジュールのうちのトランザクション処理モジュールと前記ひとつ以上のメッセージのうちの第２メッセージとに基づいて、前記受けた支払い情報を処理する機能と、をコンピュータに実現させるためのコンピュータプログラム。
【請求項１３】
前記第１メッセージタイプが前記第１メッセージに関連付けられ、前記第２メッセージタイプが前記第２メッセージに関連付けられる請求項１２に記載のコンピュータプログラム。
【請求項１４】
タイミング値と前記メッセージディスパッチャモジュールの前記インストラクションとに基づいて、前記機能モジュールの前記同時動作を可能とする機能をさらに前記コンピュータに実現させる請求項１２または１３に記載のコンピュータプログラム。
【請求項１５】
前記メッセージディスパッチャモジュールの前記インストラクションに基づいて、前記タイミング値が満了しない間に、前記支払いモジュールに前記第１メッセージタイプの前記第１メッセージを提供する機能をさらに前記コンピュータに実現させる請求項１４に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願へのクロスリファレンス
本願は、２０１５年９月２３日に出願された「Message Dispatcher for Payment System」と題する米国特許出願第14/863,381号（２０１６年５月３日に米国特許第9,330,383号として特許された）の優先権の利益を享受する。この出願は、参照によりその全体が本明細書に組み入れられる。本願はまた、２０１６年２月２４日に出願された「Message Dispatcher for Payment System」と題する米国特許出願第15/052,790号の優先権の利益を享受する。この出願は、参照によりその全体が本明細書に組み入れられる。本願はまた、２０１６年２月２４日に出願された「Message Dispatcher for Payment System」と題する米国特許出願第15/052,792号の優先権の利益を享受する。この出願は、参照によりその全体が本明細書に組み入れられる。
【背景技術】
【０００２】
電子トランザクション処理システムは支払いカードと支払い端末とを用いてもよい。支払いカードは、支払い端末でスワイプされる磁気ストライプを有する。支払い端末は磁気ストライプからクレジットカード番号などの支払い情報を読み取り、その支払い情報をトランザクションに関する情報と共にリモートトランザクションサーバに送信する。リモートトランザクションサーバはトランザクションの許否を決定し、支払い端末に応答を提供する。そのような電子トランザクション処理システムは不正行為にさらされやすいことが知られている。例えば、支払いカードの磁気ストライプはクレジットカード番号を支払いターミナルに暗号化なしで提供する。この場合、この情報は支払いカードまたは支払い端末のいずれかから取得可能である。
【０００３】
支払い技術は、不正トランザクションの可能性を低減するよう発展してきた。Europay/Mastercard/Visa（「ＥＭＶ」）システムは支払いカードの一部分として受動的電子チップを備えてもよい。支払い端末によって受動的電子回路に電力が供給される。この支払い端末は、受動的電子回路に物理的に係合するか、または、支払い端末によって送信される無線キャリア信号の誘導結合によって給電する。支払いカードの受動的電子回路は、物理的インタフェースを介して、または、無線キャリア信号の変調によって、支払い端末を活性化してそれと通信する。支払い端末に送信される前に、支払い情報は受動的電子回路によって暗号化される。
【０００４】
近距離無線通信（「ＮＦＣ」）システムはスマートフォンやスマートウォッチやタブレットなどの電子デバイスの間のデータ伝送を促進する。ＮＦＣ支払いシステムが実装されてきており、そこでは、電子デバイスが無線キャリア信号を提供する支払い端末に、支払い情報を伝達する。電子デバイスおよび支払い端末は無線キャリア信号を変調することによって通信する。ＥＭＶ支払いシステムと同様に、ＮＦＣ可能デバイスは支払い端末に支払い情報を暗号化された形態で送信してもよい。ＥＭＶまたはＮＦＣ支払いトランザクションを処理する支払い端末は、チップカードまたは電子デバイスとリモート支払いサーバとの間のトランザクションを処理するための専用ソフトウエアを含んでもよい。
【図面の簡単な説明】
【０００５】
本開示の上述及び他の側面、性質および種々の利点は、添付図面と併用される以下の詳細な説明の考慮のもとにより明らかとなるであろう。
【０００６】
【図１】本開示のある実施の形態に係る、支払いシステムの説明的ブロック図を示す。
【０００７】
【図２】本開示のある実施の形態に係る、支払いデバイスおよび支払いリーダの説明的ブロック図を示す。
【０００８】
【図３】本開示のある実施の形態に係る、支払いリーダのブロック図を示す。
【０００９】
【図４】本開示のある実施の形態に係る、ＮＦＣチップのコンポーネントのブロック図を示す。
【００１０】
【図５】本開示のある実施の形態に係る、支払いリーダのソフトウエアブロック図を示す。
【００１１】
【図６】本開示のある実施の形態に係る、メッセージディスパッチャモジュールおよび機能モジュールでメッセージを処理するための例示的ステップを説明する非限定的フロー図を示す。
【発明を実施するための形態】
【００１２】
支払いリーダは、ポイントオブセール（point-of-sale）アプリケーションと、ＥＭＶチップカードやＮＦＣ支払いデバイスなどの支払いデバイスと、の間のインタフェースを提供する。支払いトランザクションは、マーチャントがモバイルデバイス上でポイントオブセールアプリケーションを実行することなどによって開始される。ポイントオブセールアプリケーションは、通信インタフェースを介して支払いリーダと通信し、支払いリーダはトランザクションの処理に進む。支払いリーダは、近距離無線通信を用いて支払いデバイスとの通信を開始するか、または、顧客が支払いリーダのスロットにチップカードを挿入した場合は、そのチップカードとの直接電気接触を介して通信を開始する。支払いデバイスが支払い情報を提供するのを支払いリーダが待っている間、支払いリーダはまた、ポイントオブセールアプリケーションとの通信や支払いリーダの他のコンポーネントの動作などの他の機能を実行するであろう。
【００１３】
支払いデバイスから支払い情報を受信すると、支払いリーダはトランザクション処理手順にしたがってトランザクションを処理するであろう。例えば、支払いリーダは、ユーザによって提供された支払いのタイプ（例えば、Visa, Mastercard等）に基づいて、トランザクション処理手順を選択してもよい。支払いリーダは、次いで、トランザクション処理手順にしたがって支払いを処理するであろう。これは、支払いサーバへの最終的な伝達のために支払い情報を暗号化することを含む。支払いリーダはポイントオブセールアプリケーションと（例えば、ブルートゥースなどの無線接続を用いて）通信し、ポイントオブセールアプリケーションはインターネットプロトコル（ＩＰ）接続などの通信接続を介して支払いサーバと通信する。支払いサーバはトランザクションの許否を決定し、これをポイントオブセールアプリケーションおよび支払いリーダに返す。
【００１４】
支払いリーダはメモリを有し、該メモリは支払いリーダの機能を実行するためのインストラクションを保持し、また支払いリーダはそのようなインストラクションを実行するための処理ユニットを有する。インストラクションはファームウエアに実装され、複数のファームウエアモジュールに分割される。ファームウエアモジュールは、メッセージディスパッチャモジュールと機能モジュールとを含む。機能モジュールのそれぞれは支払いリーダの異なる機能に関連付けられる。例えば、支払いアプリケーションモジュールは支払いを扱うための、かつ、他のデバイスとのインタフェースとなるためのインストラクションを有し、非接触モジュールは非接触ＮＦＣ通信インタフェースを動作させるためのインストラクションを有し、接触モジュールは接触インタフェースを動作させるためのインストラクションを有し、トランザクション処理モジュールはトランザクション処理手順のためのインストラクションを有し、暗号モジュールは暗号化を行うためのインストラクションを有し、通信モジュールは通信インタフェースを動作させるための（例えば、ポイントオブセールアプリケーションと通信するための）インストラクションを有する。
【００１５】
メッセージディスパッチャモジュールは機能モジュールの実行を調整する。その動作中、機能モジュールはメッセージを生成する。これらのメッセージは、提供されているメッセージのタイプを示すメッセージ識別子（「メッセージＩＤ」）を含む。メッセージディスパッチャは、メッセージを含むキュー化データ構造、例えばメッセージの巡回待ち行列やメッセージのプッシュポップスタック、を生成する。メッセージがキュー化データ構造内の適切な位置に到達した場合、メッセージディスパッチャはそのメッセージを機能モジュールのうちのひとつ以上に提供する。機能モジュールがメッセージＩＤに応じて、ある動作を行うべきであると決定すると、機能モジュールはそのインストラクションを実行する。処理が完了すると、機能モジュールはメッセージ内のフラグをセットする。メッセージディスパッチャモジュールは、キュー化データ構造からそのメッセージを除去し、次のメッセージに移る。
【００１６】
あるメッセージは同時処理が可能となっている計時メッセージであってもよい。例えば、計時メッセージは、ある機能モジュールの処理のためにかかる時間が延長される蓋然性が高い場合に用いられてもよい。例えば、非接触モジュールや接触モジュールなどの支払いモジュールは、チップカードやＮＦＣ可能電子デバイスとのインタフェースとなるためのインストラクションを実行する。これらの通信がいつ生じるかについてのタイミングは、支払いリーダに対して適切な位置にチップカードまたはＮＦＣ可能電子デバイスを置くユーザに依存する。したがって、チップカードまたはＮＦＣ可能電子デバイスが支払いリーダと通信するための適切な場所にあるように、遅延を伴って非接触モジュールおよび接触モジュールを呼び出すためのメカニズムを、計時メッセージは提供できる。計時メッセージが呼び出されるまで、他の機能モジュールは他のメッセージを同時に処理してもよい。
【００１７】
計時メッセージはタイミング値を含む。メッセージディスパッチャはこのタイミング値を用いることで、メッセージを機能モジュールにいつどのように配信するかを決定する。ある実施の形態では、タイミング値は計時メッセージがキュー化データ構造にいつ配信されるべきかを決定してもよい。計時メッセージがキュー化データ構造の先頭に到着したときはいつでも、（例えば、計時メッセージが生成されたときからの経過時間とタイミング値との比較に基づいて）タイミング値が満了しているかが判定される。タイミング値が満了するまで、計時メッセージはキューに戻される。いったん配信されると、非接触モジュールも接触モジュールも処理を止めるべきである（処理が完了したと、またはエラーが生じたと、示すことによって）と示さない場合、計時メッセージはキュー化データ構造に戻される。他の実施の形態では、タイミング値は、計時メッセージが機能モジュールに配信されかつキューに戻され続けるべき期間を決定してもよい。計時メッセージがキュー化データ構造の先頭に到着したときはいつでも、それは機能モジュールに配信される。タイミング値が満了するかメッセージが処理されるまで、メッセージは自動的にキュー化データ構造に戻される。タイミング値が満了すると、メッセージはキューから除去され、エラーが示されてもよい。
【００１８】
図１は、本開示のある実施の形態に係る、支払いシステム１の説明的ブロック図を示す。ある実施の形態では、支払いシステム１は、支払いデバイス１０と、支払い端末２０と、ネットワーク３０と、支払いサーバ４０と、を含む。支払いシステム１のこれらのコンポーネントは、マーチャントと顧客との間の電子支払いトランザクションを促進する。
【００１９】
マーチャントと顧客との間の電子的やりとりは、顧客の支払いデバイス１０とマーチャントの支払い端末２０との間で生じる。顧客は、磁気ストライプを有するクレジットカードや、ＥＭＶチップを有するクレジットカードや、支払いアプリケーションを実行するスマートフォンなどのＮＦＣ可能電子デバイスなどの支払いデバイス１０を有する。マーチャントは支払い端末や他の電子デバイスなどの支払い端末２０を有する。そのような他の電子デバイスは支払い情報（例えば、暗号化された支払いカードデータおよびユーザ認証データ）およびトランザクション情報（例えば、購入量およびポイントオブパーチェイス情報）を処理することができ、例えば支払いアプリケーションを実行するスマートフォンやタブレットである。
【００２０】
ある実施の形態（例えば、廉価トランザクションやＮＦＣまたはＥＭＶ支払いデバイス１０によって示される支払い上限よりも少ない支払いトランザクションについてのもの）では、支払いトランザクションの初期処理および承認は支払い端末２０において処理されてもよい。他の実施の形態では、支払い端末２０はネットワーク３０を介して支払いサーバ４０と通信してもよい。支払いサーバ４０が単一の単純化されたブロックとして描かれているが、支払いサーバ４０は任意の適切な主体により運用される任意の適切な数のサーバを含んでもよいこと、例えば支払いサービスシステムならびにマーチャントおよび顧客のひとつ以上の銀行のものを含んでもよいこと、は理解されるべきである。支払い端末２０および支払いサーバ４０は支払い情報およびトランザクション情報をやりとりし、トランザクションを承認するか否かを決定する。例えば、支払い端末２０はネットワーク３０を介して支払いサーバ４０に、暗号化された支払いデータとユーザ認証データと購入量情報とポイントオブパーチェイス情報とを提供してもよい。支払いサーバ４０は、この受信した情報と顧客アカウントまたはマーチャントアカウントに関する情報とに基づいて、トランザクションを承認するか否かを決定し、支払いトランザクションが承認されたか否かを示すためにネットワーク３０を介して支払い端末２０に応答してもよい。支払いサーバ４０はまた、支払い端末２０に、トランザクション識別子などの追加情報を送信してもよい。
【００２１】
支払い端末２０において支払いサーバ４０から受信した情報に基づいて、マーチャントはトランザクションが承認されたか否かを顧客に示してもよい。ある実施の形態、例えばチップカード支払いデバイス、では、承認は支払いリーダにおいて、例えば支払い端末の画面に、示されてもよい。ＮＦＣ支払いデバイスとして動作するスマートフォンやウォッチなどの他の実施の形態では、承認されたトランザクションおよび追加情報（例えば、レシート、特別なオファー、クーポン、ロイヤリティプログラム情報など）についての情報がＮＦＣ支払いデバイスに提供され、スマートフォンやウォッチの画面に表示されるかまたはメモリに格納されてもよい。
【００２２】
図２は、本開示のある実施の形態に係る、支払いデバイス１０および支払いリーダ２０の説明的ブロック図を示す。支払いシステム１の支払いリーダ２０および支払いデバイス１０が任意の適切な態様で実装可能であることは理解されるところであるが、ある実施の形態では、支払いリーダ２０は支払いリーダ２２とマーチャントデバイス２９とを備えてもよい。支払い端末２０のリーダ２２は、支払いデバイス１０と、ポイントオブセールアプリケーションを実行するマーチャントデバイス２９と、の間のトランザクションを促進してもよい。
【００２３】
ある実施の形態では、支払いデバイス１０は、支払い端末２０と（例えば、支払いリーダ２２を介して）通信可能なデバイス、例えばＮＦＣデバイス１２やＥＭＶチップカード１４などであってもよい。チップカード１４はセキュアな集積回路を含んでもよい。この集積回路は、支払い端末２０などの支払い端末と通信することができ、暗号化された支払い情報を生成することができ、ＥＭＶＣｏによって公表されているものなどのひとつ以上の電子的支払い規格にしたがい、その暗号化された支払い情報と他の支払いまたはトランザクション情報（例えば、ローカルで処理される支払いについてのトランザクション上限）とを提供することができる。チップカード１４は支払いリーダ２２と通信するための接触ピン（例えば、ＩＳＯ７８１６にしたがうもの）を含んでもよく、ある実施の形態では、近距離場１５を介して支払いリーダ２２と誘導的に結合されてもよい。支払いリーダ２２と誘導的に結合するチップカード１４は、ＩＳＯ１４４４３などの無線通信規格にしたがい支払いリーダ２２によって提供される無線キャリア信号の負荷変調を用いて、支払いリーダ２２と通信してもよい。
【００２４】
ＮＦＣデバイス１２は、支払い端末２０との（例えば、支払いリーダ２２との通信を介した）セキュアなトランザクションを行うことができる、スマートフォンやタブレットやスマートウォッチなどの電子デバイスであってもよい。ＮＦＣデバイス１２は、セキュアなトランザクション機能を実行するためのハードウエア（例えば、ハードウエアおよび実行可能コードを含むセキュアエレメント）および／またはソフトウエア（例えば、ホストカードエミュレーションルーチンにしたがいプロセッサ上で実行される実行可能コード）を有してもよい。支払いトランザクション中、ＮＦＣデバイス１２は近距離場１５を介して支払いリーダ２２と誘導的に結合されてもよく、ＩＳＯ１４４４３およびＩＳＯ１８０９２などのひとつ以上の無線通信規格にしたがい支払いリーダ２２によって提供される無線キャリア信号の能動的または受動的負荷変調によって支払い端末２０と通信してもよい。
【００２５】
支払い端末２０は任意の適切な態様で実装可能であるが、ある実施の形態では、支払い端末２０は支払いリーダ２２とマーチャントデバイス２９とを含んでもよい。マーチャントデバイス２９は、マーチャントのためのユーザインタフェースを提供し、かつ、支払いリーダ２２および支払いサーバ４０との通信を促進するポイントオブセールアプリケーションを実行する。支払いリーダ２２は支払いデバイス１０とマーチャントデバイス２９との間の通信を促進してもよい。本明細書で説明される通り、ＮＦＣデバイス１２やチップカード１４などの支払いデバイス１０は誘導的結合を介して支払いリーダ２２と通信してもよい。これは図２において近距離場１５として描かれている。この近距離場１５は、支払いリーダ２２から発せられる適切な周波数（例えば、１３．５６ＭＨｚ）を有する無線キャリア信号を含む。
【００２６】
ある実施の形態では、支払いデバイス１０はＮＦＣデバイス１２やチップカード１４などの非接触支払いデバイスであってもよく、支払いリーダ２２および非接触支払いデバイス１０は近距離場１５内の無線キャリア信号を変調することによって通信してもよい。支払いデバイス１０に情報を伝達するために、支払いリーダ２２は、支払いリーダ２２から送信するべきデータに基づいて無線キャリア信号の振幅および／または位相を変化させ、その結果支払いデバイスへと送信される無線データ信号が生成される。この信号は、１３．５６ＭＨｚで送信するようチューンされた支払いリーダ２２のアンテナによって送信され、支払いデバイス１０もまた近距離場１５の範囲内（例えば、０ｃｍから１０ｃｍ）に適切にチューンされたアンテナを有する場合、支払いデバイスは支払いリーダ２２によって送信された無線キャリア信号または無線データ信号を受信する。無線データ信号の場合、支払いデバイス１０の処理回路は、受信した信号を復調し、支払いリーダ２２から受信されたデータを処理することができる。
【００２７】
支払いデバイス１０などの非接触支払いデバイスが近距離場１５の範囲内にある場合、それは支払いリーダ２２と誘導的に結合される。したがって、支払いデバイス１０はまた、能動的または受動的負荷変調を介して、無線キャリア信号を変調することができる。支払いデバイス１０のアンテナのチューニング特性を変えることによって（例えば、アンテナ回路において送信対象の被変調データに基づいて選択的に並列負荷を選択することによって）、支払いデバイス１０および支払いリーダ２２の両方において無線キャリア信号が変調され、これにより被変調無線キャリア信号が生成される。このようにして、支払いデバイスは支払いリーダ２２に被変調データを送信することができる。
【００２８】
ある実施の形態では、支払いリーダ２２はまた、チップカード１４を受けることができるＥＭＶスロット２１を含む。チップカード１４は、チップカード１４がＥＭＶスロット２１に挿入されたときに支払いリーダ２２の対応する接点と係合する接点を有してもよい。支払いリーダ２２はこれらの接点を通じてチップカード１４のＥＭＶチップに給電し、支払いリーダ２２とチップカード１４とはそれらの接点によって確立される通信経路を通じて通信する。
【００２９】
支払いリーダ２２はまた、磁気ストライプカードとのインタフェースとなるハードウエアをふくんでもよい（図２では不図示）。ある実施の形態では、ハードウエアは、磁気ストライプカードの磁気ストライプをスワイプするか沈めるよう顧客を案内するスロットを含んでもよく、この場合、磁気ストライプリーダは磁気ストライプカードから支払い情報を受けることができる。次いで、受信された支払い情報は支払いリーダ２２によって処理される。
【００３０】
マーチャントデバイス２９は、タブレット支払いデバイス２４やモバイル支払いデバイス２６や専用支払い端末２８などの任意の適切なデバイスであってもよい。タブレット支払いデバイス２４やモバイル支払いデバイス２６などの計算デバイスの場合、ポイントオブセールアプリケーションは、購入および支払い情報の入力、顧客とのやりとり、および支払いサーバとの通信を担当してもよい。例えば、支払いアプリケーションは、マーチャントがそのなかから選択できるサービスメニューと、トランザクションを自動化するための一連のメニューまたは画面と、を提供してもよい。支払いアプリケーションはまた、署名やＰＩＮ番号や生体情報などの顧客認証情報の入力を促進してもよい。専用支払い端末２８に同様の機能が提供されてもよい。
【００３１】
マーチャントデバイス２９は、通信経路２３／２５／２７を介して支払いリーダ２２と通信してもよい。通信経路２３／２５／２７は有線接続（例えば、イーサネット、ＵＳＢ、ファイヤワイヤ、ライトニング）または無線接続（例えば、ＷｉＦｉ、ブルートゥース、ＮＦＣ、ＺｉｇＢｅｅ）を介して実装されてもよいが、ある実施の形態では、支払いリーダ２２はブルートゥースまたはブルートゥースローエナジーインタフェースを介してマーチャントデバイス２９と通信してもよい。本明細書で説明される通り、ある実施の形態では、例えば、トランザクション量が少ないか支払いサーバへの接続がない場合、支払いトランザクションの処理が支払いリーダ２２およびマーチャントデバイス２９においてローカルで生じうる。他の実施の形態では、マーチャントデバイス２９または支払いリーダ２２は公衆または専用通信ネットワーク３０を介して支払いサーバ４０と通信してもよい。通信ネットワーク３０は任意の適切な通信ネットワークであってもよいが、ある実施の形態では、通信ネットワーク３０はインターネットであってもよく、支払いおよびトランザクション情報は支払い端末２０と支払いサーバ４０との間で暗号化形式で通信されてもよい。
【００３２】
図３は、本開示のある実施の形態に係る、支払いリーダ２２のブロック図を示す。図３において特定のコンポーネントが特定の構成で描かれているが、支払いリーダ２２が追加のコンポーネントを含んでもよいこと、図３に示されるコンポーネントのうちのひとつ以上が支払いリーダ２２に含まれなくてもよいこと、および支払いリーダ２２のコンポーネントが任意の適切な態様で再構成されうること、は理解されるであろう。とりわけ、支払いリーダ２２は支払いデバイス１０などの非接触支払いデバイスとデータを交換するためのＮＦＣ通信デバイスとして動作してもよい。ある実施の形態では、支払いリーダ２２は、ＮＦＣチップ１０２と、ＮＦＣ回路１００と、無線通信インタフェース１６０と、有線通信インタフェース１６２と、電源１６４と、接点インタフェース１６６と、を含む。ＮＦＣ回路１００および接点インタフェース１６６が支払いリーダ２２内に含まれうる支払いインタフェースのタイプの例であるが、本開示の実施の形態に係る、任意の適切な支払いインタフェース（例えば、磁気カードリーダ）が支払いリーダ２２内に含まれうることは理解されるであろう。
【００３３】
支払いリーダ２２のＮＦＣチップ１０２は、支払いリーダ２２の機能を実行し制御するのに必要な限り、任意の適切なハードウエア、ソフトウエア、メモリ、および回路を含みうる。ある実施の形態では、ＮＦＣチップ１０２は、ＮＦＣチップ１０２のメモリに保持されるインストラクションを実行することで支払いリーダ２２の動作および処理を制御するひとつ以上のプロセッサを含む。本明細書で用いられる場合、プロセッサは、本明細書で説明される処理機能を行うために必要な処理能力を有するひとつ以上のプロセッサを含んでもよく、例えば、ハードウエアロジックやプロセッサが実行するコンピュータ可読インストラクションやそれらの任意の適切な組み合わせなどを含むがそれらに限定されない。プロセッサは本明細書で説明される動作を行うためにソフトウエアを実行してもよく、そのようなソフトウエアは、実体的非一時的コンピュータ可読保持媒体上の機械可読形態でアクセスされたソフトウエアと、チップを設計するために用いられるハードウエア記述言語（ＨＤＬ）ソフトウエアなどのハードウエアの構成を記述するソフトウエアと、を含む。 
【００３４】
ある実施の形態では、ＮＦＣチップ１０２は二つのＲＩＳＣプロセッサを含んでもよい。この二つのプロセッサはそれぞれ、それぞれのメモリに保持される実行可能インストラクションに基づいて、汎用処理機能および暗号化処理機能を行うよう構成される。本明細書で用いられる場合、メモリは、実体的または非一時的保持媒体を指してもよい。実体的（または、非一時的）保持媒体の例は、ディスクと、サム（thumb）ドライブと、メモリと、を含むが、伝送信号は含まない。実体的コンピュータ可読保持媒体は、コンピュータ可読インストラクションやデータ構造やプログラムモジュールや他のデータなどの、揮発性および不揮発性、取り外し可能および取り外し不可媒体を含む。そのような媒体の例は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＳＲＡＭ、フラッシュメモリ、ディスクまたは光学ストレージ、磁気ストレージ、あるいはプロセッサまたは計算デバイスによってアクセスされる情報を保持する任意の他の非一時的媒体を含む。
【００３５】
ＮＦＣチップ１０２はまた、インタフェース回路やアナログフロントエンド回路やセキュリティ回路などの追加回路を含んでもよい。ある実施の形態では、インタフェース回路は、無線インタフェース１６０（例えば、ＷｉＦｉ、ブルートゥース、ブルートゥースローエナジー）とのインタフェースとなる回路と、有線インタフェース１６２（例えば、ＵＳＢ、イーサネット、ファイヤワイヤ、およびライトニング）とのインタフェースとなる回路と、他の通信インタフェースまたはバス（例えば、Ｉ２Ｃ、ＳＰＩ、ＵＡＲＴおよびＧＰＩＯ）とのインタフェースとなる回路と、電力インタフェース１６４（例えば、電力管理回路、電力変換回路、整流器、および電池充電回路）とのインタフェースとなる回路と、接点インタフェース１６６（例えば、チップカード１４のＥＭＶチップとのインタフェースのための電力および通信回路）とのインタフェースとなる回路と、を含んでもよい。
【００３６】
ある実施の形態では、ＮＦＣチップ１０２のアナログフロントエンド回路はＮＦＣ回路１００のアナログコンポーネントとのインタフェースとなる回路（例えば、電磁環境整合（ＥＭＣ）回路、整合回路、および変調回路）を含む。ＮＦＣチップ１０２のセキュリティ回路は、暗号化キーやマーチャント情報や顧客情報などの機微な情報を保護するための回路を含んでもよい。本明細書で後に詳述される通り、ある実施の形態では、セキュリティ回路は、ＮＦＣチップ１０２への不正アクセスを得ようとする試みに応じて、ＮＦＣチップのひとつ以上のコンポーネントの電源を選択的にオフにするか無効化するためのタンパ保護回路および電子ヒューズを含んでもよい。
【００３７】
無線インタフェース１６０は、外部の電子デバイスと無線で、例えばＷｉＦｉ、ブルートゥース、ブルートゥースローエナジーなどで、通信するためのハードウエアおよびソフトウエアを含んでもよい。有線インタフェース１６２は、ＵＳＢ、イーサネット、ファイヤワイヤ、またはライトニングなどのインタフェースを介した外部の電子デバイスとの有線通信を促進するためのハードウエア、ソフトウエアおよび物理的インタフェースを含む。無線インタフェース１１６および有線インタフェース１６２を用いることで、支払いリーダ２２はマーチャントデバイス２９などの外部の電子デバイスと通信することができる。ある実施の形態では、支払いリーダ２２は、（例えば、サーバに直接支払いまたはトランザクション情報を提供するために、または、サーバから更新を受けるために、または、認証および承認データをサーバに伝達するために）リモートサーバなどの他の電子デバイスと通信してもよいし、別の電子デバイスと通信してもよい。
【００３８】
電源１６４はＡＣ電源や電池への物理的接続などのひとつ以上の電源を含んでもよい。電源１６４は、ＡＣ電力を変換するための、および／または、支払いリーダ２２のコンポーネントによる使用のために複数のＤＣ電圧を生成するための、電力変換回路を含んでもよい。電源１６４が電池を含む場合、電池は物理的な電力接続を介して、または、誘導充電を介して、または、任意の他の適切な方法を介して、充電可能である。
【００３９】
接点インタフェース１６６は、チップカード１４のＥＭＶチップなどの支払いチップに給電し、ＥＭＶチップと通信するための適切なインタフェースであってもよい。接点インタフェース１６６は、ＥＭＶ規格にしたがいチップカード１４との物理的なインタフェースとなる複数の接触ピンを含んでもよい。
【００４０】
支払いリーダ２２のＮＦＣチップ１０２は、正伝送ピン（ＴＸＰ）、負伝送ピン（ＴＸＮ）および受信ピン（ＲＸ）などの複数のピンを介してＮＦＣ回路１００と通信する。伝送ピンＴＸＰおよびＴＸＮは、振幅、周波数および波形を有する出力信号を提供してもよい。ある実施の形態では、ＴＸＰおよびＴＸＮから提供される信号は、差動方形波信号であり、ＮＦＣ回路１００の変調回路１１０に提供されてもよい。
【００４１】
変調回路１１０は、ＴＸＰおよびＴＸＮの出力にしたがい変調された信号を出力するための回路（例えば、Ｈブリッジ回路）を含んでもよい。変調回路１１０はまた、アンテナ１４０を介した伝送に適切な増大した電圧を印加することなどの他の機能を行ってもよい。変調回路１１０の出力はＥＭＣ回路１２０に提供されてもよい。ＥＭＣ回路１２０は、他の高周波信号との受け入れ可能な電磁環境整合性を提供するために、インダクタやキャパシタなどのひとつ以上のコンポーネントを含んでもよい。ＥＭＣ回路１２０の出力は整合回路１３０に提供されてもよい。整合回路１３０は、アンテナ１４０のインピーダンスマッチングおよびチューニングを提供するために、抵抗器やインダクタやキャパシタなどの適切なコンポーネントを含んでもよい。
【００４２】
変調回路１１０、ＥＭＣ回路１２０および整合回路１３０は合わせて、アンテナ１４０と結合する送信回路を形成してもよい。しかしながら、送信回路がＮＦＣチップ１０２（例えば、ＴＸＰおよびＴＸＮピンによって示されるようなその処理ユニットの出力）と結合する任意の適切な回路を含んでもよいこと、図３に示される回路コンポーネントが任意の適切な態様で構成可能であること、および任意の適切なコンポーネントが追加または削除されうること、は理解されるであろう。
【００４３】
支払いリーダ２２のＮＦＣチップ１０２の動作中、伝送ピンＴＸＰおよびＴＸＮはキャリア信号または被変調信号のいずれかを出力してもよい。キャリア信号は、１３．５６ＭＨｚなどの固定周波数を有する信号であってもよい。キャリア信号は変調回路１１０に提供され、変調回路１１０はＮＦＣチップ１０２からの出力信号を一様な態様で（例えば、昇圧を適用することによって）変調してもよい。ＥＭＣ回路１２０および整合回路１３０のコンポーネント（例えば、抵抗器、インダクタおよびキャパシタ）は、例えば、アンテナ１４０により送信される信号がキャリア周波数を有する正弦波に近似されるように近似方形波出力を変調することによって、キャリア信号の出力波形を変更する。したがって、送信回路の第１部分はＴＸＰピンの出力をアンテナ１４０の第１端子に結合させ、送信回路の第２部分はＴＸＮピンの出力をアンテナ１４０の第２端子に結合させる。次いで、キャリア信号は無線キャリア信号としてアンテナ１４０を介して送信される。
【００４４】
ＮＦＣチップ１０２によってキャリア信号に変調が適用される場合、変調回路１１０は、データ信号に応じて振幅または位相もしくはその両方が元のキャリア信号から変化する被変調信号を出力してもよい。本明細書で説明される通り、ＮＦＣチップ１０２は、それ単体でまたは変調回路１１０と連携して、被変調信号を生成するために変調手順を実装してもよい。この被変調信号は、送信回路に提供され、無線データ信号としてアンテナ１４０を介して送信される。
【００４５】
ＮＦＣチップ１０２は、受信ピンＲＸを通じてアンテナ１４０における信号を監視する。受信ピンＲＸは受信回路に結合されている。ある実施の形態では、受信回路は整合回路１３４を含んでもよく、アンテナ１４０の第２端子と結合されてもよい。このようにすることで、ＮＦＣチップ１０２は何が送信されているか（例えば、無線キャリアおよび被変調信号）を監視することができ、また、ＮＦＣデバイス１２やチップカード１４などの非接触支払いデバイス１０によってキャリア信号に適用される変化を監視することができる。受信信号のこれらの変調に基づいて、ＮＦＣチップ１０２は非接触支払いデバイス１０からの通信を受信することができる。
【００４６】
図４は、本開示のある実施の形態に係る、ＮＦＣチップ１０２のコンポーネントのブロック図を示す。図４において特定のコンポーネントが特定の構成で描かれているが、ＮＦＣチップ１０２が追加のコンポーネントを含んでもよいこと、所定のコンポーネントがＮＦＣチップ１０２に含まれなくてもよいこと、およびＮＦＣチップ１０２のコンポーネントが任意の適切な態様で再構成されうること、は理解されるであろう。
【００４７】
ある実施の形態では、ＮＦＣチップ１０２は処理ユニット２０４とメモリ２１０とを含んでもよい。ある実施の形態では、処理ユニット２０４はＣＰＵ０  ２０６およびＣＰＵ１  ２０８との符号が付された二つのＣＰＵを含んでもよい。ＣＰＵ０  ２０６は、ＮＦＣチップ１０２のほとんどの機能を制御する汎用プロセッサであってもよい。ＣＰＵ２０８は、ＮＦＣチップ１０２の他のコンポーネント（不図示）から物理的に隔離された暗号プロセッサであってもよい。この場合、ＮＦＣチップ１０２のひとつ以上のコンポーネント（例えば、ＣＰＵ０  ２０６）が危うくなっても、暗号ユニットのプロセッサＣＰＵ１  ２０８およびその関連メモリ（例えば、フラッシュＳＲＡＭ１  ２１４）は危うくならない。
【００４８】
ある実施の形態では、ＣＰＵ０  ２０６およびＣＰＵ１  ２０８はＲＩＳＣプロセッサであってもよい。メモリ２１０は適切なメモリを含んでもよいが、ある実施の形態では、ＣＰＵ０  ２０６およびＣＰＵ１  ２０８のそれぞれは、フラッシュＳＲＡＭ０  ２１２およびフラッシュＳＲＡＭ１  ２１４などの関連フラッシュＳＲＡＭを有してもよい。フラッシュＳＲＡＭ０  ２１２およびフラッシュＳＲＡＭ１  ２１４は、対応するＣＰＵであるＣＰＵ０  ２０６およびＣＰＵ１  ２０８で実行されるインストラクションを保持し、ＮＦＣチップ１０２の動作中に用いられるデータを保持してもよい。電池でバックアップされたＲＡＭ２１６は、暗号化キーなどの高度に機微な情報を保持する別個のメモリであってもよい。このようにすることで、ＮＦＣチップ１０２が危うくなった場合、例えば電池でバックアップされたＲＡＭ２１６への電力を除去することで、電池でバックアップされたＲＡＭ２１６に保持される情報は消去されてもよい。
【００４９】
処理ユニット２０４（例えば、処理ユニット２０４のＣＰＵ０  ２０６）は、ひとつ以上の通信インタフェース２２０とのインタフェースとなってもよい。通信インタフェース２２０は、外部デバイスおよび支払いリーダ２２の他の回路との通信を可能としてもよい。例えば、通信インタフェース２２０は、無線通信回路などの支払いリーダ２２の回路（例えば、ＷｉＦｉ、ブルートゥース、ブルートゥースローエナジー）、支払いリーダ２２の電力管理回路、支払いリーダ２２の有線通信インタフェース（例えば、イーサネット、ＵＳＢ、ファイヤワイヤ、ライトニング）および支払いリーダ２２の他のコンポーネント、との通信を可能としてもよい。例示的な通信インタフェース２２０は、ＵＳＢハブと、ＵＳＢデバイスと、Ｉ２Ｃと、ＳＰＩと、ＵＡＲＴと、ＧＰＩＯと、を含む
【００５０】
ＮＦＣチップ１０２はまた、バイアス生成器２３４と、クロック２３２と、クロック管理ユニット２３６と、改ざん検知回路２４０と、電子ヒューズ２４２と、を含む。バイアス生成器２３４は電源と接続され、バイアス電圧を生成してもよい。このバイアス電圧は、アナログフロントエンド２６０や処理ユニット２０４やメモリ２１０などのＮＦＣチップ１０２のコンポーネントへ提供される。ある実施の形態では、バイアス生成器２３４によって生成される適切なバイアス電圧は３．３ボルトであってもよい。クロック２３２は水晶発振器などの任意の適切なクロックであってもよく、クロック管理ユニット２３６にクロック周波数のクロック信号を提供してもよい。クロック管理ユニット２３６は、クロック２３２からの入力に基づいて複数のクロック信号を生成することで、例えば、処理ユニット２０４のＣＰＵ０  ２０６およびＣＰＵ１  ２０８のためのクロック信号と、近距離通信の伝送に適切な周波数（例えば、１３．５６ＭＨｚ）を有するクロック信号と、を提供してもよい。
【００５１】
改ざん検知２４０は電源に接続される。改ざん検知２４０は改ざん検知入力２４４を含み、該入力２４４はＮＦＣチップ１０２または支払いリーダ２２のひとつ以上の電気的または物理的コンポーネントに結合されてもよい。これらの入力のうちのひとつが、支払いリーダ２２のひとつ以上のコンポーネントに対する改ざんの試みがあったことを示す場合、改ざん検知２４０はＮＦＣチップ１０２のひとつ以上のコンポーネントに対する電力の供給を止めてもよい。改ざん検知２４０が処理ユニット２０４および電池でバックアップされたＲＡＭ２１６とのみ通信するように描かれているが、改ざん検知２４０がフラッシュＳＲＡＭ０  ２１２およびフラッシュＳＲＡＭ１  ２１４などのＮＦＣチップ１０２の任意の他のコンポーネントへの電力の中断を提供してもよいことは、理解されるであろう。
【００５２】
ＮＦＣチップ１０２はまた電子ヒューズ２４２を含む。電子ヒューズ２４２はＮＦＣチップ１０２のひとつ以上のコンポーネントへの電力または通信を無効化するよう提供されてもよい。例えば、電子ヒューズ２４２はＣＰＵ１  ２０８によって制御されてもよい。ＣＰＵ１  ２０８によってＮＦＣチップ１０２の不適切なアクセス試行または使用が特定された場合、ＣＰＵ１はひとつ以上の電子ヒューズ２４２を活性化させることで、ＮＦＣチップ１０２のひとつ以上のコンポーネントへの電力を遮断したり、ＮＦＣチップ１０２のひとつ以上のコンポーネントへのクロック信号を遮断したり、ＮＦＣチップ１０２のひとつ以上のコンポーネントの間の通信を遮断したり、してもよい。例えば、ＣＰＵ１  ２０８は、ＣＰＵ０  ２０６がＣＰＵ１  ２０８と通信することもそれと共に動作することもできないように、電子ヒューズ２４２の部分集合を制御してもよい。
【００５３】
ＮＦＣチップ１０２はまた、アナログフロントエンド２６０とＤＰＰリンクロジック２６２とを含む。ＤＰＰリンクロジック２６２は、処理ユニット２０４のＣＰＵ０  ２０６からのデジタル信号と、アナログフロントエンド２６０のアナログ信号と、の間のインタフェースを提供してもよい。アナログフロントエンド２６０は、非接触インタフェース（例えば、ＮＦＣ回路１００）への、および、チップカード用の接触インタフェースへの、インタフェースを提供する。
【００５４】
動作中、クロック２３２はクロック信号をＣＭＵ２３６に提供し、ＣＭＵ２３６は処理ユニット２０４に複数のクロック信号を提供する。改ざん検知２４０は入力２４４を監視し、改ざん試行がない場合は、電力が通常の態様でＮＦＣチップ１０２のコンポーネントへ供給されてもよい。ＮＦＣチップ１０２への不適切なアクセス試行がない場合、ＣＰＵ１  ２０８は、ＮＦＣチップ１０２のコンポーネントが通常通りに動作できるように電子ヒューズ２４２を制御してもよい。
【００５５】
マーチャントデバイス２９は支払いリーダ２２のブルートゥース通信回路と通信してもよく、このブルートゥース通信回路は通信インタフェース２２０を介してＣＰＵ０  ２０６と通信してもよい。ある実施の形態では、マーチャントデバイス２９はＮＦＣチップ１０２に対して、支払いを受けるための要求を送信してもよく、この要求はＣＰＵ０  ２０６によって受け取られてもよい。ＣＰＵ０  ２０６は、フラッシュＳＲＡＭ０  ２１２に保持されるインストラクションにしたがってその要求を処理し、ＤＰＰリンクロジック２６２およびアナログフロントエンド２６０を介して、非接触インタフェース（例えば、ＮＦＣ回路１００）または接触インタフェースもしくはその両方を活性化してもよい。非接触インタフェースに関して、ＣＰＵ０  ２０６は近距離通信イニシエータの中のものとして機能してもよく、ＤＰＰリンクロジック２６２、アナログフロントエンド２６０および非接触インタフェースを介してキャリア信号および被変調信号を提供する。ＣＰＵ０  ２０６は、非接触インタフェース、アナログフロントエンド２６０およびＤＰＰリンクロジック２６２を介して、ターゲット（例えば、ＮＦＣデバイス１２やＥＭＶデバイス１４）からの応答があるか監視してもよい。
【００５６】
支払いデバイスとの通信が確立されると、例えば非接触回路を介して非接触デバイス（例えば、ＮＦＣデバイスやチップカード）との通信が確立されると、または、接触インタフェースを介して接触カードとの通信が確立されると、ＣＰＵ０  ２０６は支払いデバイスと通信することで支払いトランザクションを処理してもよい。このプロセス中、ＣＰＵ０  ２０６は、ＣＰＵ２０８が暗号機能を実行できるようにＣＰＵ１  ２０８と通信してもよい。ある実施の形態では、ＣＰＵ０  ２０６およびＣＰＵ１  ２０８はトランザクションをローカルで処理してもよく、一方、ある実施の形態では、ＣＰＵ０  ２０６はマーチャントデバイス２９と通信してもよく、または通信インタフェース２２０および関連通信回路（例えば、ＷｉＦｉ、ブルートゥース、イーサネット）を介して支払いサーバ４０と直接通信してもよい。
【００５７】
図５は、本開示のある実施の形態に係る、支払いリーダ２２のソフトウエアブロック図３００を示す。ソフトウエアブロック図３００の各ブロックはファームウエアモジュールを表す。図５では特定のファームウエアモジュールが描かれているが、支払いリーダ２２が追加のファームウエアモジュールを含んでもよいこと、またはひとつ以上のファームウエアモジュールが変更または除去されてもよいこと、は理解されるであろう。さらに、図５は、暗号計算機３２０以外の全てのファームウエアモジュールがＣＰＵ０で実行され、暗号計算機３２０が別個のプロセッサＣＰＵ１で実行されることを示しているが、全てのファームウエアモジュールが単一のＣＰＵで実行されてもよく、または複数のＣＰＵに任意の適切な態様で割り当てられてもよいことは理解されるであろう。
【００５８】
ある実施の形態では、暗号計算機３２０は別個のＣＰＵ（例えば、ＣＰＵ１）に配置されてもよい。この場合、暗号機能は支払いリーダ２２のＮＦＣチップ１０２の他の機能とは独立して実行される。加えて、暗号化キーおよび他の重要な情報は、ＣＰＵ１上の暗号計算機３２０によってのみアクセス可能である。このようにすることで、重要で秘密の情報を、ＮＦＣチップ１０２および支払いリーダ２２のソフトウエアの残りの部分から隔離することができる。
【００５９】
ソフトウエアシステム３０２はメッセージディスパッチャモジュール３１０を含み、このモジュール３１０は機能モジュールである他のファームウエアモジュールの動作およびそれらの間のやりとりを管理する。機能モジュールは、メッセージディスパッチャモジュール３１０にメッセージを提供してもよい。メッセージディスパッチャモジュール３１０は、キュー化データ構造メカニズムを通じてそれらのメッセージを管理し、キュー化データ構造から機能モジュールへメッセージを配信する。本明細書で説明される通り、ポインタは、キュー化データ構造におけるメッセージの位置を参照してもよい。メッセージは機能モジュールに任意の適切な態様で提供されてもよい（例えば、メッセージのコピーが機能モジュールによってアクセスされるメモリ位置に提供されてもよい）が、ある実施の形態では、ポインタ位置への参照が機能モジュールに提供されてもよく、この場合、機能モジュールはキュー化データ構造内においてメッセージに関連付けられたメモリ位置にアクセスし、ある実施の形態では、ひとつ以上のフラグなどのメッセージ内のデータを編集する。
【００６０】
ＣＰＵ０のソフトウエアモジュールについて、ＣＰＵ０の処理はメッセージディスパッチャモジュール３１０と機能モジュールとの間で行き来し、ＣＰＵ０の処理が再びメッセージディスパッチャモジュール３１０に戻るまで、機能モジュールがそのインストラクションを実行する。このようにすることで、一度に一つの機能モジュールに特定の順番でメッセージを提供することができる。ある実施の形態では、メッセージディスパッチャモジュールはメッセージフィールドまたはフラグを監視することで、どの機能モジュールがメッセージを受信すべきか、メッセージが他の機能モジュールに配信され続けるべきか、メッセージを受信すべき機能モジュールのそれぞれにメッセージを一度だけ配信するか否か、機能モジュールへのメッセージの配信の順番、およびメッセージがキュー化データ構造に戻されるべきか否か、を決定してもよい。
【００６１】
ある実施の形態では、メッセージディスパッチャ３１０はキュー化データ構造を巡回待ち行列として実装する。この巡回待ち行列は、メッセージのアレイまたはメッセージのリンク化リストを有し、それぞれがキューの先頭（例えば、キューのトップまたはフロント）へのポインタと、キューの後尾（例えば、キューのボトムまたはエンド）へのポインタと、を有する。そのような巡回待ち行列は先入れ先出し（ＦＩＦＯ）キューであってもよく、そこでは、キューに入れるべき新たなメッセージは、キュー内の最後のメッセージの後となるメモリ内の次の位置に挿入される。エンドポインタは次いで、新たにキューに入ったメッセージの位置を指すよう変更される。キューの先頭においてフロントポインタをその現在の位置から次のメッセージへと動かすことで、メッセージは廃棄される。キューがそのキューを含むメモリ部分を巡回しうるという点でそのキューは巡回的である。ここでは、古いメッセージ（すなわち、スタートポインタとエンドポインタとの間にないメッセージ）はポインタが巡回待ち行列を周回するにつれて上書きされる。キューがフルの場合（すなわち、キューに入れられるべき次のメッセージがスタートポインタの位置に保持されるメッセージを上書きしてしまう場合）、キューに追加のメモリが割り当てられるか、または例外が提供されてもよい。
【００６２】
本明細書で説明される実施の形態にしたがい巡回待ち行列（すなわち、キュー）が議論されるであろうが、メッセージを保持し、かつ、メッセージへのアクセスを提供する任意の適切なキュー化データ構造が提供されてもよいことは理解されるであろう。シーケンシャルなキュー化データ構造の他の実施の形態では、メッセージングシステムはプッシュポップスタックとして実装されてもよい。プッシュポップスタックは後入れ先出し（ＬＩＦＯ）データ構造であってもよく、そこでは、格納されるべき新たなメッセージはスタック内の最初のメッセージの前となるメモリ内の位置に挿入される。スタックは原点位置を有してもよく、ポインタはキューの先頭を指してもよい。メッセージが廃棄される場合、ポインタは原点に向けてデクリメントされ、したがって、次のメッセージを指してもよい。メッセージがスタックに追加される場合、ポインタは原点から離れる向きにインクリメントされ、したがって、新たに追加されるメッセージを指してもよい。本明細書で説明されるようにキューに戻される計時メッセージを実装する実施の形態では、スタックの先頭以外のスタックの位置に計時メッセージを置くようにスタックのコンテンツが変更されてもよい。
【００６３】
ある実施の形態では、メモリにおいて、メッセージＩＤ、処理フラグおよびデータフィールドなどの複数のフィールドを含むメッセージデータ構造としてメッセージを実装してもよい。メッセージはメッセージ長を有してもよく、各フィールドはメッセージデータ構造内の相対位置に関連付けられてもよい。メモリ内のメッセージの位置が分かると（例えば、ポインタに基づいて）、メッセージの特定のフィールドは、既知のメッセージデータ構造内のその相対位置に基づいてアクセス可能である。メッセージＩＤは送信されているメッセージのタイプを示してもよい。このメッセージＩＤに基づいて、機能モジュールはメッセージに応じてアクションをとるか否かを決定し、かつ、メッセージに応じてどのアクションを行うかを決定してもよい。処理フラグは、メッセージが処理されたことをメッセージディスパッチャモジュール３１０に知らせてもよい。処理フラグは、機能モジュールがメッセージに応じて処理を完了すると、その機能モジュールによって設定されてもよい。処理フラグが設定されると、メッセージディスパッチャモジュール３１０はそのメッセージをキューから除去してもよい。処理エラーを示すために処理フラグおよび／または他のフラグを用いてもよい。コールミーフラグは、メッセージを提供したモジュールがメッセージディスパッチャモジュールからメッセージを受けるべきか否かを示してもよい。データフィールドは、メッセージと共に提供されるべきデータを含んでもよく、このデータはメッセージに応じてアクションを行う機能モジュールによって用いられる。ある実施の形態では、データフィールドは追加メッセージを含んでもよい。
【００６４】
メッセージディスパッチャモジュール３１０は、メッセージのタイプに基づいて異なる態様でキューを管理してもよい。メッセージディスパッチャモジュール３１０は受信したメッセージを任意の適切なメッセージタイプにしたがって処理してもよいが、ある実施の形態では、メッセージタイプは計時メッセージおよび標準メッセージであってもよい。標準メッセージはキュー内で一回の処理を受けてもよい。標準メッセージが処理されると、それはキューから除去されてもよい。標準メッセージが処理されるまで、それはキュー内でのその位置を維持し、キューの開始に対して移動する（例えば、ポインタは標準メッセージの位置に近づくように移動しうる）。計時メッセージはタイミング値を含んでもよく、メッセージ配信およびキューイングはそのタイミング値に基づいて変更されてもよい。
【００６５】
タイミング値は多くの方法により実装可能である。ある実施の形態では、計時メッセージは、タイミング値が満了せずかつ処理フラグが設定されない限り、キュー内に残ってもよい。計時メッセージがキューの先頭に到着すると、それは機能モジュール（例えば、計時メッセージを受信する権利がある機能モジュールの部分集合）にラウンドロビン方式で配信され、これはそのメッセージを受けるべき全ての機能モジュールにそのメッセージが配信されてしまうまで、または、そのメッセージのフィールドが更新され、そのメッセージがさらに配信されるべきではないことを示す（例えば、タイミング値または処理フラグを変更することによって）ようになるまで、続く。ある実施の形態では、どの機能モジュールも処理フラグを設定することはなく、かつ、タイミング値が満了しない限り、メッセージは、そのメッセージを受けるべき全ての機能モジュールへ配信された後、キューに戻される（例えば、ある実施の形態では、所定の機能モジュールのみが計時メッセージを受信でき、またはメッセージはコールミーフラグに基づいてメッセージを提供した機能モジュールには提供されなくてもよい）。次いで、計時メッセージがキューの先頭に戻ってくるまでキュー内の他のメッセージが処理され、戻ってくると、その計時メッセージは再び機能モジュールに配信される。処理フラグが設定されると、計時メッセージはキューから除去されてもよい。処理フラグが設定される前にタイミング値が満了すると、これは計時メッセージが処理されなかったことを示す。計時メッセージはキューから除去され、計時メッセージに関連付けられた支払い失敗メッセージなどのエラーメッセージまたはフラグが生成されてもよい。
【００６６】
他の実施の形態では、計時メッセージは、タイミング値が満了しない限りキューに戻されてもよい。ある実施の形態では、タイミング値は生成時刻（例えば、計時メッセージの開始時刻）と現在時刻とに基づいて満了する。生成時刻が現在時刻から減算され、その結果がタイミング値よりも大きい場合、タイミング値は満了する。タイミング値は任意の適切な態様で実装されてもよいが、他の実施の形態では、タイミング値はカウントダウン、カウントアップ、またはタイミング値が満了しうる将来の時刻の設定であってもよい。タイミング値が満了すると、計時メッセージは機能モジュールのうちのひとつ以上に配信される。機能モジュールが計時メッセージのタイミング値のリセットを望む場合、それは計時メッセージを再送信してもよく、またはタイミング値に関連付けられた生成時刻を変更してもよく、またはタイミング値を変更してもよい。計時メッセージがキューから除去されるべきである場合、処理フラグが設定されてもよい。ある実施の形態では、計時メッセージに関連付けられた支払い失敗メッセージなどのエラーメッセージまたはフラグが生成されてもよい。
【００６７】
巡回待ち行列のある実施の形態では、キューにメモリが割り当てられ、メッセージがキューの次に利用可能な位置へ追加されてもよい。メッセージを配信するとき、メッセージディスパッチャモジュール３１０はキューに入れられたメッセージが位置するキュー内の位置へのポインタを提供する。機能モジュールは、ポインタに基づいて、メッセージＩＤフィールドや処理フラグやデータフィールドなどのキュー内メッセージのフィールドにアクセスすることができる。このようにすることで、メッセージディスパッチャモジュール３１０はメッセージを機能モジュールに提供し、機能モジュールはキューに入れられたメッセージを更新することができる。キューに入れられたメッセージが処理されるか除去されるかキューの異なる位置へ動かされると、ポインタは次のキューに入れられたメッセージへと動かされてもよい。
【００６８】
機能モジュールは、メッセージディスパッチャモジュール３１０から受信したメッセージに応じてメッセージを生成してもよい。加えて、機能モジュールの処理がモジュール内で開始され、ハードウエア割り込みやソフトウエア割り込みなどのある外的刺激に応じてメッセージが生成されてもよい。割り込みに応じて、ＣＰＵ０  ２０６の処理は機能モジュールへと渡り、該機能モジュールは割り込みに応じて初期化されてもよい。
【００６９】
機能モジュールは、内部通信モジュール３４０などのひとつ以上の通信モジュールを含んでもよい。内部通信モジュール３４０は、ＵＳＢインタフェース、Ｉ２Ｃインタフェース、ＳＰＩインタフェース、ＵＡＲＴインタフェース、およびＧＰＩＯインタフェースなどのＮＦＣチップ１０２の内部通信インタフェース２２０と通信するためのインストラクションを含んでもよい。これらのインタフェースは、外部デバイス（例えば、ＵＳＢインタフェースを介するもの）との、またはＷｉＦｉやブルートゥースや電力制御ハードウエアなどの内部ハードウエアとの通信をサポートしてもよい。外部デバイスとの、または支払いリーダ２２の内部ハードウエアとの通信は任意の適切な態様で開始されてもよく、例えば通信インタフェースを介して提供される割り込みにより開始されてもよい。通信インタフェースからの通信に応じて、内部通信モジュール３４０は、メッセージＩＤと、通信のソースを示すデータと、通信対象のデータと、他の任意の適切な情報と、を有するメッセージを生成してもよい。これらのメッセージはメッセージディスパッチャモジュール３１０に提供され、他の機能モジュールのうちのひとつ以上に配信されてもよい。内部通信モジュール３４０はまた、メッセージディスパッチャモジュール３１０から、外部デバイスまたは支払いリーダ２２の内部ハードウエアへ送信されるべきメッセージを受信してもよい。そのようなメッセージは、支払いアプリケーションモジュール３３０やホスト通信モジュール３４２やハードウエアモジュール３３８などの他の機能モジュールから生じたものであってもよい。
【００７０】
非接触モジュール３３４は送信対象のデータを受信してもよく、支払いリーダ２２とＮＦＣデバイス１２やチップカード１４などの支払いデバイス１０との間の近距離無線通信を制御するためのインストラクションを含む。非接触モジュール３３４は、ＩＳＯ１４４４３およびＩＳＯ１８０９２で概説されるものなどの通信プロトコルを介したそのようなデバイスとの通信を提供する。非接触モジュール３３４は支払いデバイス１０（例えば、ターゲット）にメッセージを提供するイニシエータとして機能してもよい。ＮＦＣモジュール３３４は、被変調キャリア信号を介した支払いデバイス１０との通信を促進するためのメッセージを生成し、かつ、支払いデバイス１０が支払いリーダ２２のアンテナから提供されるキャリア信号を変調することに基づいて支払いデバイス１０からメッセージを受信する。これらの受信したメッセージは、暗号化されたクレジットカード番号などの支払い情報を含んでもよく、ある実施の形態では、ＰＩＮ番号や指紋情報や他の生体情報などの認証情報を含んでもよい。
【００７１】
ある実施の形態では、非接触モジュール３３４はメッセージディスパッチャモジュール３１０のキューからのメッセージにアクセスしてもよい。そのメッセージは支払いデバイス１０に情報を要求してもよく、または支払いデバイス１０に送信されるデータを提供してもよい。例えば、支払いアプリケーションモジュール３３０はメッセージディスパッチャモジュール３１０のキューにメッセージを提供してもよい。このメッセージは、トランザクションのローカル処理についての上限に関する情報を要求する。非接触モジュール３３４は、キューからのメッセージにアクセスし、被変調キャリア信号を介して支払いデバイス１０にローカル支払い上限についての要求を送信してもよい。支払いデバイス１０はキャリア信号を変調することによって、その支払い上限で応答してもよい。非接触モジュール３３４は受信したデータに基づいてメッセージを生成し、そのメッセージをメッセージディスパッチャモジュール３１０に提供してもよい。メッセージディスパッチャ３１０は、メッセージがキューの先頭に至るとそのメッセージを配信し、支払いアプリケーション３３０はこのメッセージにアクセスすることで、ローカル支払い上限がトランザクション量よりも小さいか否かを判定してもよい。他の実施の形態では、非接触モジュール３３４は、支払いパラメータの更新や支払いデバイスのキーなどの、支払いデバイス３１０に書き込まれるべきデータを提供してもよい。
【００７２】
接触モジュール３３６は、チップカード１４などの接触デバイスとの通信を提供する。非接触モジュール３３４について本明細書で説明される通り、接触モジュール３３６は支払いデバイス１０とのインタフェースとなり、ＮＦＣソフトウエア３０２の他の機能モジュールとメッセージを交換してもよい。接触モジュール３３６は、支払いリーダ２２の接触インタフェースを介してチップカード１４と通信してもよく、また、メッセージディスパッチャモジュール３１０のキューに送信されるかそれからアクセスされるメッセージを介して他の機能モジュールと通信してもよい。
【００７３】
任意の適切な機能モジュールが計時メッセージを用いてもよいが、ある実施の形態では、非接触モジュール３３４および接触モジュール３３６の両方が動作中に計時メッセージを用いてもよい。例えば、支払いデバイス１０から支払い情報を受けるためのメッセージを受信すると、非接触モジュール３３４および接触モジュール３３６はそれぞれメッセージディスパッチャ３１０に計時メッセージを提供してもよい。この計時メッセージはキューの先頭に周期的に到着し、到着したときには、そのメッセージはタイミング値に基づいて配信され、非接触モジュール３３４または接触モジュール３３６によって、支払い情報が受信されたか否かが判定される。支払い情報が受信されたかまたは計時メッセージの処理を終えるべきであると機能モジュールが決定した場合、支払い情報を受信したモジュールは計時メッセージの処理フラグを変更し、支払い情報が受信されたかまたは支払いエラーが生じたことを示すメッセージをメッセージディスパッチャモジュール３１０のキューに提供する。ある実施の形態では、支払い情報が受信されるかまたはタイマが満了するまで、計時メッセージは配信され続け、キューに戻され続けてもよい。他の実施の形態では、タイミング値は、支払い情報が受信されていなければならない期間の長さに対応してもよく、計時メッセージはこのタイミング値が満了したときにのみ機能モジュールに送信されてもよい。次いで、計時メッセージの処理を終えるべきであることを処理フラグが示すまで、計時メッセージは配信され続けてもよく、またはタイミング値はリセットされてもよい（例えば、計時メッセージの生成時刻またはタイミング値を更新することによって）。ある実施の形態では、計時メッセージに関連付けられた支払い失敗メッセージなどのエラーメッセージが生成されてもよい。
【００７４】
ＮＦＣソフトウエア３０２はまた、ホストアプリケーションとの通信のためのホスト通信モジュール３４２などの通信モジュールを含んでもよい。ある実施の形態では、ホストアプリケーションはＮＦＣチップ１０２とは異なるプロセッサで実行されてもよい。例えば、ホストアプリケーションは支払いリーダ２２の他のプロセッサで実行されていてもよく、本明細書で記載されるある実施の形態では、マーチャントデバイス２９で実行されていてもよい。処理動作はＮＦＣソフトウエア３０２と外部ホストアプリケーションとの間で任意の適切な態様で分散していてもよいが、ある実施の形態では、ホストアプリケーションは、ユーザインタフェース機能と、支払いサーバ４０などの外部デバイスとの通信と、を制御してもよい。ＮＦＣソフトウエア３０２は、支払い処理を扱い（例えば、支払いアプリケーションモジュール３３０およびＥＭＶモジュール３３２を介して）、支払いデバイスとのインタフェースとなり（例えば、非接触モジュール３３４および接触モジュール３３６を介して）、支払いサーバ４０に送信されるべきデータを暗号化してもよい（例えば、暗号計算機モジュール３２０を介して）。ホスト通信モジュール３４２のインストラクションは、ホストアプリケーションから受信したデータを処理し、機能モジュールの動作に関するメッセージを生成し、受信したメッセージに基づいてホストアプリケーションに送信すべきメッセージを生成する。
【００７５】
ハードウエアモジュール３３８は、支払いリーダ２２の内部ハードウエアと通信するためのインストラクションを含んでもよい。内部通信モジュール３４０から通信を受信し、その通信に関するメッセージがメッセージディスパッチャモジュール３１０にキューされると、ハードウエアモジュール３３８は、そのメッセージが支払いリーダ２２の内部コンポーネントからのものであるか否かを判定してもよい。メッセージが支払いリーダ２２の内部ハードウエアコンポーネントからのものである場合、ハードウエアモジュール３３８はそのメッセージおよびデータを処理し、ひとつのまたは他の機能モジュールによって処理されるためにメッセージディスパッチャモジュール３１０においてキューに入れられるべき応答メッセージを生成する。
【００７６】
支払いアプリケーションモジュール３３０は支払いリーダ２２における支払いの処理のためのインストラクションを含む。支払いアプリケーションモジュール３３０はホスト通信モジュール３４２および内部通信モジュール３４０を介してホストアプリケーションと通信し、また、支払い処理のために用いられる機能モジュール（例えば、暗号計算機モジュール３２０、ＥＭＶモジュール３３２、非接触モジュール３３４、および接触モジュール３３６）の動作を調整する。例えば、支払いトランザクションがホストアプリケーションによって開始されると、支払いアプリケーションモジュール３３０はメッセージディスパッチャモジュール３１０（例えば、これはホスト通信モデル３４２により開始された）からキュー内のメッセージを取得し、支払い要求を処理してもよい。支払いアプリケーションモジュール３３０は、支払い情報を（例えばＮＦＣデバイス１２またはチップカード１４から）受信するために、非接触モジュール３３４および接触モジュール３３６のうちのひとつ以上を初期化するためのメッセージまたは複数のメッセージを生成してもよい。
【００７７】
支払い情報が受信されたことを示すメッセージがメッセージディスパッチャモジュール３１０のキューに到着し、支払いアプリケーションモジュール３３０によって受信されると、支払いアプリケーションモジュール３３０はＥＭＶモジュール３３２のひとつ以上のトランザクション処理モジュール（Ａ、Ｂ、ＣおよびＤとして示されている）にアクセスするためのメッセージを生成してもよい。例えば、トランザクション処理モジュールＡ−Ｄのそれぞれは、Europay, MasterCard, Visa, または American Expressなどの支払いプラットフォームに対応してもよい。支払いアプリケーションモジュール３３０は、メッセージディスパッチャモジュール３１０においてキューに入れられているメッセージを介したＥＭＶモジュール３３２のトランザクション処理モジュールとの通信を続けてもよく、また、暗号計算機モジュール３２０によってアクセスされるメッセージを提供してもよい。ある実施の形態では、支払いアプリケーションモジュール３３０は（例えば、廉価トランザクションについての）トランザクションをローカルで処理してもよく、または、ある実施の形態では、マーチャントデバイス２９を介した支払いサーバ４０との通信を促進してもよい。いずれの場合でも、支払いアプリケーションモジュール３３０はメッセージディスパッチャモジュール３１０にメッセージを提供してもよく、そのメッセージはホスト通信モジュール３４２によってアクセスされ、ホスト通信モジュール３４２はトランザクション承認処理の結果を、マーチャントデバイス２９で実行されるホストアプリケーションに（例えば、内部通信モジュール３４０を通じてアクセスされるブルートゥース接続を介して）伝達する。
【００７８】
ＥＭＶモジュール３３２は、Europay, MasterCard, Visa, American Express,および他の発行企業などの支払い処理者によって指定されるひとつ以上のトランザクション処理手順にしたがい、支払いトランザクションを処理するためのインストラクションを含む。支払い情報が非接触モジュール３３４または接触モジュール３３６から受信されると、支払いアプリケーション３３０は、ＥＭＶモジュール３３２のどのトランザクション処理モジュールにアクセスすべきかを決定してもよい。ＥＭＶモジュール３３２のトランザクション処理モジュール（例えば、図５にＡ、Ｂ、ＣおよびＤとして描かれている）には、発行企業の規格に準拠することが要求される。ＥＭＶモジュール３３２の処理モジュールによる規格への準拠性は、認証プロセスによって確認されてもよい。ＥＭＶモジュール３３２は要求されたトランザクション処理モジュールにアクセスし、メッセージディスパッチャモジュール３１０においてキューに入れられたメッセージを介して他の機能モジュールと通信する。
【００７９】
暗号計算機モジュール３２０は支払い処理トランザクションの暗号化機能を行うためのインストラクションを含む。暗号計算機モジュール３２０は、支払いサーバ４０などの外部デバイスに送信される情報を暗号化するために用いられてもよいキーへのアクセスを有してもよい。支払いアプリケーションモジュール３３０およびＥＭＶモジュール３３２などの機能モジュールは、暗号計算機３２０がアクセスしてもよいメッセージを、メッセージディスパッチャ３１０のキューに提供してもよい。アクセスされるメッセージは、暗号化対象のデータを含んでもよい。暗号計算機モジュール３２０は、別個のプロセッサ（例えば、ＣＰＵ１）上で暗号化を行ってもよい。暗号計算機モジュール３２０は次いで、暗号化されたデータを含むメッセージを生成し、そのメッセージをメッセージディスパッチャモジュール３１０のキューに提供してもよい。そのメッセージはキューから（例えば、支払いアプリケーションモジュール３３０によって）アクセスされてもよく、最終的に支払いサーバ４０に伝達されてもよい（例えば、支払いアプリケーションモジュール３３０、ホスト通信モジュール３４２および内部通信モジュール３４０からメッセージディスパッチャモジュール３１０のキューに提供されるメッセージを介して、および、マーチャントデバイス２９を介して、ネットワーク３０へと）。
【００８０】
上述の構成およびデバイスに照らし、開示される主題にしたがい実装されうる方法は、図６のフローチャートを参照することでより良く理解されるであろう。説明の簡単化を目的として、方法が一連のステップとして示され説明されるが、そのような図示または対応する説明はステップの順番に限定されるものではなく、いくつかのステップが本明細書で図示され説明されるものとは異なる順番でおよび／または他のステップと同時に生じうることは理解され認識されるべきである。フローチャートを介して図示される任意のシーケンシャルでないまたは枝分かれのフローは、同じまたは同様の結果を達成する種々の他の枝分かれやフローパスやステップの順番が実装可能であることを示すものとして理解されるべきである。さらに、以下に説明される方法を実装するために、図示される全てのステップが要求されるわけではない場合がある。
【００８１】
図６は、本開示のある実施の形態に係る、メッセージディスパッチャモジュール３１０および機能モジュールでメッセージを処理するためのステップ６００を示す。ステップ６０２で、メッセージディスパッチャモジュール３１０はメッセージを受信したか否かを判定してもよい。本明細書で説明されるように、メッセージは、機能モジュールによって処理されたメッセージや割り込みや他の適切な処理に応じてひとつ以上の機能モジュールから受信されてもよい。メッセージが受信されると、処理はステップ６０４へと続いてもよい。メッセージが受信されないと、処理はステップ６０６へと続いてもよい。
【００８２】
ステップ６０４で、受信されたメッセージはメッセージディスパッチャモジュール３１０によってキューに入れられてもよい。ある実施の形態では、キューは巡回待ち行列であってもよく、この場合、最も直近に受信されたメッセージがキューの後端に置かれる。他の実施の形態では、キューに入れられるメッセージは異なる態様で配置されてもよく、例えばこの場合、最も直近に受信されたメッセージがキューの先頭などのどこかに置かれる。ある実施の形態では、キューは受信されたメッセージのひとつ以上のフィールドのコンテンツ（例えば、これはメッセージ優先度を設定する）に基づいて、または、任意の他の適切な方法に基づいて、調整されてもよい。メッセージがキューに入れられると、処理はステップ６０６へと続いてもよい。
【００８３】
ステップ６０６で、メッセージディスパッチャモジュール３１０は、キューにおいて、処理対象のメッセージにアクセスしてもよい。メッセージは任意の適切な態様でアクセスされてもよいが、ある実施の形態では、ポインタはキューの先頭のメッセージに対応する位置を指してもよい。キューにアクセスする際、メッセージディスパッチャモジュール３１０は、メッセージＩＤ、メッセージ長、コールミーフィールド、処理フラグ、およびデータフィールドなどのメッセージのひとつ以上のフィールドにアクセスしてもよい。ある実施の形態では、メッセージディスパッチャモジュール３１０はこれらのフィールドのうちのひとつ以上を用いることで、メッセージを機能モジュールへ配信すべきか否か、またはメッセージを機能モジュールへどのように配信すべきかを決定してもよい。例えば、フィールド値またはメッセージＩＤは、メッセージが計時メッセージであることを示す情報を含んでもよい。コールミーフィールドの状態に基づいて、メッセージディスパッチャは、メッセージを提供した機能モジュールへメッセージを戻すことはしない。メッセージディスパッチャモジュール３１０がキューにおいてメッセージにアクセスすると、処理はステップ６０８へ続いてもよい。
【００８４】
ステップ６０８で、メッセージディスパッチャモジュール３１０は、現在のメッセージが計時メッセージであるか否か、および、そのメッセージが処理されずにキューに戻されるべきか否かを判定してもよい。ある実施の形態では、メッセージＩＤフィールドは、メッセージが計時か否かに対応するメッセージＩＤを含んでもよい。例えば、支払いアプリケーションモジュール３３０、ＥＭＶモジュール３３２、非接触モジュール３３４、または接触モジュール３３６からのあるタイプのメッセージは計時メッセージであってもよい。他の実施の形態では、メッセージは、メッセージが計時メッセージであるか否かを示すフィールドを含んでもよい。計時メッセージは、タイミング値にしたがい、所定間隔で、周期ベースで、または遅延された態様で、所定の処理が行われること可能としてもよい。これは、所定の処理機能が、同時にかつ不必要な処理時間を費やすことなしに、生じることを可能としてもよい。例えば、非接触モジュール３３４または接触モジュール３３６がチップカードやＮＦＣデバイスを探し始めると、ＣＰＵ０  ２０６の処理は他のメッセージを同時に処理することに戻るのが望ましい。接触モジュール３３６および非接触モジュール３３４は、他のメッセージが処理されている間にも動作可能なハードウエアおよびソフトウエアを含み、チップカードやＮＦＣデバイスをチェックするための処理は、タイミング値に基づいて、接触モジュール３３６や非接触モジュール３３４に渡されてもよい。メッセージが計時メッセージでない場合、処理はステップ６１２へと続いてもよい。それが計時メッセージである場合、タイミング値が満了したか否かが判定されてもよい。
【００８５】
メッセージが計時メッセージであるとメッセージディスパッチャモジュール３１０が決定した場合、メッセージディスパッチャモジュール３１０はまた、タイミング値が満了したか否かを判定してもよい。ある実施の形態では、計時メッセージのタイミング値が満了するまで計時メッセージがキューに戻されてもよく、タイミング値が満了したときにのみ配信されてもよい。このようにすることで、タイミング値が満了するまで、計時メッセージは処理のために機能モジュールに（例えば、接触モジュール３３６に、または非接触モジュール３３４に）渡されることはない。ある実施の形態では、タイミング値の満了は、計時メッセージを生成した機能モジュールによって設定された生成時刻値およびタイミング値に基づいてもよい。メッセージディスパッチャモジュール３１０は、それがキューにおけるメッセージにアクセスしている現在時刻を決定し、その現在時刻から生成時刻を減算してもよい。その結果がタイミング値より小さい場合、計時メッセージはどの機能モジュールに送信されることもなく、キューに戻されてもよい。その結果がタイミング値より大きい（または、ある実施の形態では、以上）場合、計時メッセージは、（例えば、計時メッセージのフィールドまたはメッセージＩＤに基づいて、）その計時メッセージを受信することとなっている機能モジュールに送信されてもよい。このようにすることで、計時メッセージの間隔は、タイミング値および生成時刻に基づいて制御可能である。例えば、タイミング値が小さいほど、計時メッセージがすぐに機能モジュールに送信される。生成時刻またはタイミング値を変更またはリセットすることにより、満了までの時間を延長することができる。タイミング値が満了すると、処理はステップ６１２へと続いてもよい。タイミング値が満了しないと、処理はステップ６１０へと続いてもよい。
【００８６】
他の実施の形態（図６では不図示）では、計時メッセージは、それがキューの先頭に到着するたびに、ターゲットの機能モジュールに提供されてもよい。他のこの実施の形態では、ステップ６０８でタイミング値はチェックされず、タイミング値はメッセージが機能モジュールへと配信された（例えば、ステップ６１８で）後にのみチェックされてもよい。したがって、処理はステップ６１２をスキップするであろう。
【００８７】
ステップ６１０で、メッセージディスパッチャモジュール３１０は、計時メッセージをキューに戻してもよい。計時メッセージはキューの任意の適切な位置へ任意の適切な態様で戻されてもよいが、ある実施の形態では、計時メッセージはキューの後尾に戻されてもよい。計時メッセージがキューに戻されると、処理はステップ６０２へと続いてもよい。
【００８８】
ステップ６１２で、メッセージディスパッチャモジュール３１０は、メッセージを機能モジュールに送信してもよい。ある実施の形態では、メッセージディスパッチャモジュール３１０は機能モジュールに、キュー内のメッセージの位置へのポインタを送信してもよい。ある実施の形態では、メッセージは所定の機能モジュールにのみ送信されてもよい（例えば、計時メッセージは、メッセージＩＤまたはメッセージフィールドに基づいて、所定の機能モジュールにのみ配信されてもよい）。メッセージはラウンドロビン方式で機能モジュールに（例えば、ステップ６１２、６１４および６１６のループ内のステップ６１２の各繰り返しにおいて）提供されてもよく、メッセージを受信する機能モジュールはそのメッセージに応じて何らかのアクションを起こすべきか否かを判定する（例えば、メッセージＩＤに基づいて）。機能モジュールがメッセージに応じてアクションを起こす場合、プロセッサ（例えば、ＣＰＵ０  ２０６）の処理の制御はその機能モジュールに渡されてもよい。機能モジュールによって行われる処理は、メッセージＩＤにしたがってメッセージ内のデータを処理することと、メッセージディスパッチャに提供されるメッセージを生成することと、処理フラグを変更することと、任意の他の適切な処理と、を含んでもよい。機能モジュールがその処理を完了すると、ＣＰＵ０  ２０６の処理の制御はメッセージディスパッチャモジュール３１０に戻り、ステップ６１４でメッセージディスパッチャモジュール３１０は、メッセージが処理されたか否かを判定してもよい。
【００８９】
ステップ６１４で、メッセージディスパッチャモジュール３１０は、キュー内の現在のメッセージが処理されたか否かを判定してもよい。ある実施の形態では、メッセージディスパッチャモジュール３１０は、メッセージに関連付けられた処理フラグの状態に基づいて、メッセージが処理されたか否かを判定してもよい。例えば、機能モジュールがその機能モジュールによる処理を要求するメッセージＩＤを伴うメッセージを受信すると、機能モジュールはその処理を完了し、機能モジュールはメッセージ内における処理フラグの既知の位置に基づいて処理フラグを変更してもよい。（例えば、処理フラグの状態に基づいて）メッセージが既に処理されたとメッセージディスパッチャモジュール３１０が判定した場合、処理はステップ６２０へと続いてもよい。メッセージがまだ処理されていないとメッセージディスパッチャモジュール３１０が判定した場合、処理はステップ６１６へと続いてもよい。
【００９０】
ステップ６１６で、メッセージディスパッチャモジュール３１０は、メッセージを受け取る権利のある全ての機能モジュールにそのメッセージが送信されたか否かを判定してもよい。最初は、メッセージはどの機能モジュールにも送信されていないであろう。処理はステップ６１２、６１４および６１６へと続き、そこではメッセージがメッセージを受信すべき機能モジュールへと送信され（ステップ６０１２において）、処理フラグがチェックされ（ステップ６１４において）、メッセージを受け取る権利のある全ての機能モジュールにそのメッセージが送信されたか否かが判定される（ステップ６１６において）。メッセージを受け取る権利のある全ての機能モジュールにそのメッセージが送信された（例えば、計時メッセージについては、または、コールミーフラグがアサートされていない場合は、メッセージは機能モジュールの全てに送られるわけではない）と、またはメッセージが処理された（例えば、処理フラグの状態に基づいて）と、メッセージディスパッチャモジュールが決定するまで、このループは続いてもよい。メッセージを受け取る権利のある全ての機能モジュールにそのメッセージが送信されると、処理はステップ６１８へと続いてもよい。メッセージを受け取る権利のある全ての機能モジュールにそのメッセージが送信されてしまわない限り、処理はステップ６１２に戻る。
【００９１】
ステップ６１８で、メッセージディスパッチャモジュール３１０は、現在のメッセージが計時メッセージであるか否かを判定してもよい。本明細書で説明されるように、これは、メッセージＩＤフィールドやメッセージが計時メッセージであるか否かを示すフィールドや任意の他の適切な態様に基づいて判定されてもよい。メッセージが計時メッセージである場合、メッセージをキューに戻すために、処理はステップ６２２へと続いてもよい。メッセージが計時メッセージでない場合、メッセージをキューから除去するために、処理はステップ６２０へと続いてもよい。
【００９２】
他の実施の形態（図６では不図示）では、計時メッセージは、それがキューの先頭に到着するたびに、機能モジュールに提供されてもよく、かつ、タイミング値が満了しておらずかつ処理フラグがセットされていない限りキューに戻されてもよい。そのメッセージについて処理フラグが設定されていない限り、かつ、タイミング値が満了していない限り、そのメッセージはキューに戻される。このような態様で設定されるタイミング値によると、タイミング値によって表される期限がくるまで、機能モジュールを周期的にポーリングすることが可能となる。タイミング値が満了する（例えば、機能モジュールによる処理中にリセットされることなく）と、計時メッセージに関連付けられた支払い失敗メッセージなどのエラーメッセージが生成されてもよい。他のこの実施の形態では、ステップ６０８でタイミング値はチェックされず、タイミング値はメッセージが機能モジュールへと配信された（例えば、ステップ６１８で）後にのみチェックされてもよい。他のこの実施の形態では、ステップ６１８でタイミング値が満了しないと、処理はステップ６２２へと続いてもよい。タイミング値が満了すると、処理はステップ６２０へと続いてもよい。
【００９３】
ステップ６２０で、メッセージディスパッチャモジュール３１０は、処理されたメッセージをキューから除去してもよい。処理されたメッセージは任意の適切な態様でキューから除去されてもよいが、ある実施の形態では、メッセージディスパッチャモジュール３１０は、キュー内の次のメッセージを指すようポインタを調整してもよい。処理されたメッセージは最終的に、他のメッセージがキューに入ることに基づいて上書きされてもよい。次いで、処理はステップ６０２に戻ってもよい。 
【００９４】
ステップ６２２で、メッセージディスパッチャモジュール３１０は、計時メッセージをキューに戻してもよい。計時メッセージはキューの任意の適切な位置へ任意の適切な態様で戻されてもよいが、ある実施の形態では、計時メッセージはキューの後尾に戻されてもよい。加えて、ある実施の形態では、計時メッセージのタイミング値および／または生成時刻はひとつ以上の機能モジュールによって変更またはリセットされてもよい。例えば、ステップ６０８におけるタイミング値の次の満了までの時間を延長するために、タイミング値または生成時刻を変更またはリセットしてもよい。計時メッセージがキューに戻されると、処理はステップ６０２へと続いてもよい。
【００９５】
上記は本開示の原理の単なる説明に過ぎず、当業者であれば本開示の範囲から逸脱することなく種々の変更を行える。上述の実施の形態は、限定では無く説明の目的のために示されたものである。本開示はまた、本明細書で明示的に説明されたもの以外の多くの形態をとることができる。したがって、本開示は明示的に開示された方法、システムおよび装置に限定されず、むしろそれらの変形例や変更例であって以下の請求の範囲内のものを含むことが意図されていることを強調しておく。
【００９６】
さらなる例として、本明細書で示され説明された提供された構成、デバイスおよび方法をさらに最適化するために、装置またはプロセスパラメータ（例えば、寸法、設定、コンポーネント、プロセスステップの順番等）の変更を行うことができる。いずれにせよ、本明細書で説明される構成およびデバイス、ならびに関連方法は、多くのアプリケーションを有する。したがって、開示された主題は本明細書で説明されるいずれかの単一の実施の形態に限定されるべきではなく、むしろ添付の請求の範囲にしたがう範囲において解釈されるべきものである。
【図１】
0006505948.tif 000002
【図２】
0006505948.tif 000003
【図３】
0006505948.tif 000004
【図４】
0006505948.tif 000005
【図５】
0006505948.tif 000006
【図６】
0006505948.tif 000007