(57)【要約】  支払い端末は、チップカードからの電子支払い情報を至急処理モードで処理する要求を受け付けてもよい。支払い端末はオプトイン要求を提供してもよい。ユーザが受け入れると、支払い端末は支払い要求を受け付け、チップカードに電子支払い応答を要求してもよい。支払い端末は電子支払い応答をチップカードから受信し、それを支払い端末のメモリに格納してもよい。支払い端末は、電子支払い応答に関連付けられた支払いトランザクションを承認することで、チップカードが支払い端末から取り除かれることを可能としてもよい。支払い端末は、追加的な支払い要求を処理し、各電子支払い応答に支払いタイプインジケータおよび時刻インジケータを関連付けてもよい。支払い端末は、承認要求を送信可能であると前記端末が判定したとき、ひとつ以上の支払いサーバに、承認要求を送信し、各要求に対して、支払い承認応答を受信してもよい。【選択図】図１
2019527873.tif 000002
【特許請求の範囲】
【請求項１】
チップカードから受信した電子支払い情報を至急処理モードで処理する支払い端末のための方法であって、
前記支払い端末のユーザインタフェースにおいて、第１支払い要求を受け付けることと、
前記第１支払い要求に応じて前記支払い端末の処理要素が、第１電子支払い応答を第１チップカードに、前記支払い端末のチップカードインタフェースを介して、要求することと、
前記支払い端末のメモリにおいて、前記第１電子支払い応答を格納することと、
前記第１電子支払い応答に関連付けられた第１トランザクションを承認することと、
前記ユーザインタフェースにおいて、追加的な支払い要求を受け付けることと、
前記追加的な支払い要求に応じて前記支払い端末の前記処理要素が、追加的な電子支払い応答を追加的なチップカードに、前記チップカードインタフェースを介して、要求することと、
前記メモリにおいて、前記追加的な電子支払い応答を格納することと、
前記追加的な電子支払い応答に関連付けられた追加的なトランザクションを承認することと、
前記第１電子支払い応答および前記追加的な電子支払い応答のそれぞれに支払いタイプインジケータを関連付けることであって、前記支払いタイプインジケータはひとつ以上の支払いサーバに、前記第１電子支払い応答および前記追加的な電子支払い応答が至急支払いプロトコルにしたがう処理の対象であることを示す、関連付けることと、
前記第１電子支払い応答および前記追加的な電子支払い応答を格納し、前記第１トランザクションおよび前記追加的なトランザクションを承認した後、前記ひとつ以上の支払いサーバに支払い承認要求を送信可能であると判定することであって、各支払い承認要求が前記第１電子支払い応答または前記追加的な電子支払い応答のうちのひとつと、前記電子支払い応答のそれぞれについて、それに関連付けられた支払いタイプインジケータと、を含む、判定することと、
前記支払い端末の通信インタフェースから前記ひとつ以上の支払いサーバへ、前記支払い承認要求を送信することと、を含み、
通常支払いプロトコルは前記チップカードのそれぞれに、該チップカードのトランザクションを処理するための追加的情報を要求し、前記至急支払いプロトコルは前記ひとつ以上の支払いサーバに前記追加的情報なしで前記第１トランザクションおよび前記追加的なトランザクションを処理させ、前記第１トランザクションおよび前記追加的なトランザクションは前記第１トランザクションおよび前記追加的なトランザクションが前記支払い端末によって承認された後に前記至急支払いプロトコルにしたがって前記ひとつ以上のサーバにおいて処理される方法。
【請求項２】
支払い承認要求を送信可能であると判定することは、前記支払い端末の前記通信インタフェースが前記ひとつ以上の支払いサーバと通信可能であると判定することを含む請求項１に記載の方法。
【請求項３】
前記支払い端末の前記通信インタフェースにおいて、前記支払い承認要求のそれぞれに関連付けられた支払い承認応答を受け付けることをさらに含み、
前記支払い承認応答が前記支払いタイプインジケータに基づく請求項１に記載の方法。
【請求項４】
支払い承認要求を送信可能であると判定することは、支払い要求の頻度が閾値より小さいと判定することを含む請求項１に記載の方法。
【請求項５】
各支払い承認要求に時刻インジケータを関連付けることであって、各時刻インジケータが将来トランザクション時刻に対応する、関連付けることと、
各時刻インジケータをそれに関連付けられた電子支払い応答と共に前記ひとつ以上の支払いサーバに送信することと、をさらに含む請求項１に記載の方法。
【請求項６】
各時刻インジケータおよびそれに関連付けられた支払い承認要求が、該時刻インジケータの前記時刻に対応する時刻に送信される請求項５に記載の方法。
【請求項７】
各時刻インジケータおよびそれに関連付けられた支払い承認要求が、該時刻インジケータの前記時刻に対応する時刻より前に送信され、前記ひとつ以上の支払いサーバが該時刻インジケータの前記時刻まで待ってから前記支払い承認要求を処理する請求項５に記載の方法。
【請求項８】
チップカードから受信した無線電子支払い情報を至急処理モードで処理するための支払い端末であって、
チップカードインタフェースと、
ひとつ以上の支払いサーバと通信するよう構成された通信インタフェースと、
ユーザから支払い要求を受け付けるよう構成されたユーザインタフェースと、
前記チップカードインタフェース、前記通信インタフェースおよび前記ユーザインタフェースと接続されたひとつ以上の処理要素であって、前記ひとつ以上の処理要素がユーザインタフェースインストラクション、至急処理インストラクションおよびトランザクション処理インストラクションを実行するよう構成される、ひとつ以上の処理要素と、
前記ユーザインタフェースインストラクション、前記至急処理インストラクションおよび前記トランザクション処理インストラクションを保持するよう構成されたひとつ以上のメモリと、を備え、
ユーザインタフェースインストラクションは前記ひとつ以上の処理要素に、前記ユーザインタフェースにおいて第１支払い要求を受け付けることと、前記ユーザインタフェースにおいて追加的な支払い要求を受け付けることと、を行わせ、
至急処理インストラクションは前記ひとつ以上の処理要素に、前記第１支払い要求に応じて前記チップカードインタフェースを介して第１チップカードに第１電子支払い応答を要求することと、前記支払い端末のメモリにおいて前記第１電子支払い応答を格納することと、前記チップカードインタフェースを介して追加的なチップカードに追加的な電子支払い応答を要求することと、前記メモリにおいて前記追加的な電子支払い応答を格納することと、前記第１電子支払い応答および前記追加的な電子支払い応答のそれぞれに支払いタイプインジケータを関連付けることであって、前記支払いタイプインジケータはひとつ以上の支払いサーバに、前記第１電子支払い応答および前記追加的な電子支払い応答が至急支払いプロトコルにしたがう処理の対象であることを示す、関連付けることと、を行わせ、
前記トランザクション処理インストラクションは前記ひとつ以上の処理要素に、前記第１電子支払い応答に関連付けられた第１トランザクションを承認することと、前記追加的な電子支払い応答に関連付けられた追加的なトランザクションを承認することと、前記第１電子支払い応答および前記追加的な電子支払い応答を格納し、前記第１トランザクションおよび前記追加的なトランザクションを承認した後、前記ひとつ以上の支払いサーバに前記通信インタフェースを介して支払い承認要求を送信可能であると判定することと、前記支払い承認要求を前記ひとつ以上の支払いサーバに送信することと、を行わせ、
各支払い承認要求が前記第１電子支払い応答または前記追加的な電子支払い応答のうちのひとつと、前記電子支払い応答のそれぞれについて、それに関連付けられた支払いタイプインジケータと、を含み、
通常支払いプロトコルは前記チップカードのそれぞれに、該チップカードのトランザクションを処理するための追加的情報を要求し、前記至急支払いプロトコルは前記ひとつ以上の支払いサーバに前記追加的情報なしで前記第１トランザクションおよび前記追加的なトランザクションを処理させ、前記第１トランザクションおよび前記追加的なトランザクションは前記第１トランザクションおよび前記追加的なトランザクションが前記支払い端末によって承認された後に前記至急支払いプロトコルにしたがって前記ひとつ以上のサーバにおいて処理される支払い端末。
【請求項９】
複数の支払いインタフェースを通じて電子支払い情報を選択的に処理する支払い端末のための方法であって、
前記支払い端末のユーザインタフェースにおいて、スワイプモードに入る要求を受け付けることと、
前記支払い端末の前記ユーザインタフェースにおいて、前記スワイプモードに入る前記要求に応じてオプトイン確認を提供することであって、前記支払い端末は前記オプトイン確認がユーザによって受け入れられた場合にのみ前記スワイプモードに入ることが許可される、提供することと、
前記支払い端末の前記ユーザインタフェースにおいて、支払いトランザクション要求を受け付けることと、
前記支払い端末のスワイプインタフェースにおいて、前記支払いトランザクション要求に応じて、支払いカードから、スワイプ支払いタイプの電子支払い情報を受け付けることと、
前記支払い端末において、前記支払い端末が前記スワイプモードに入ることおよび前記支払いカードがチップカードであるというインジケータに基づいて、スワイプモード処理インジケータを生成することであって、前記スワイプモード処理インジケータは前記スワイプ支払いタイプの手順にしたがって前記電子支払い情報を処理することを可能とする、生成することと、
前記支払い端末の通信インタフェースから、ひとつ以上の支払いサーバに、前記スワイプモード処理インジケータおよび前記電子支払い情報を送信することと、
前記支払い端末の前記通信インタフェースにおいて、前記電子支払い情報に対する支払い承認応答を受信することであって、前記支払い承認応答が前記スワイプモード処理インジケータに基づく、受信することと、を含む方法。
【請求項１０】
前記スワイプモード処理インジケータは、前記トランザクションが技術的後退トランザクションではないことを示し、前記技術的後退トランザクションは、前記チップカードが前記支払い端末のチップカードインタフェースにおいて処理に失敗したことを示す請求項９に記載の方法。
【請求項１１】
遅延条件を特定することであって、前記電子支払い情報の前記送信がその遅延条件の間遅延されるべきである、特定することと、
前記支払い端末のメモリに前記電子支払い情報を格納することと、
前記遅延条件の満了に基づいて前記電子支払い情報を送信することと、をさらに含む請求項９に記載の方法。
【請求項１２】
前記遅延条件が支払いトランザクションの頻度を含み、前記遅延条件の前記満了は支払いトランザクションの前記頻度がしきい値を下回ることを含む請求項１１に記載の方法。
【請求項１３】
前記遅延条件が前記支払い端末と前記ひとつ以上の支払いサーバとの間の接続スピードを含み、前記遅延条件の前記満了は前記接続スピードがしきい値を超えることを含む請求項１１に記載の方法。
【請求項１４】
前記支払い端末の前記ユーザインタフェースにおいて、第２支払いトランザクション要求を受け付けることと、
前記支払い端末の前記スワイプインタフェースにおいて、前記第２支払いトランザクション要求に応じて、第２支払いカードから、スワイプ支払いタイプの電子支払い情報を受け付けることと、
前記第２支払いカードがチップカードでないと判定することと、
前記判定に基づいて、前記第２支払いカードを、通常のスワイプカードプロトコルにしたがって処理することと、をさらに含む請求項９に記載の方法。
【請求項１５】
前記支払い端末の前記ユーザインタフェースにおいて、第２支払いトランザクション要求を受け付けることと、
前記支払い端末のチップカードインタフェースにおいて、前記第２支払いトランザクション要求に応じて、第２チップカードから、チップカード支払いタイプの第２電子支払い情報を受け付けることと、
前記支払い端末の前記通信インタフェースから、ひとつ以上の支払いサーバに、前記第２電子支払い情報を送信することと、
前記支払い端末の前記通信インタフェースにおいて、前記第２電子支払い情報に対する支払い承認応答を受信することと、をさらに含む請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願へのクロスリファレンス
本願は、２０１６年６月２９日に出願された「Expedited Processing of Electronic Payment Transactions」というタイトルの米国特許出願第15/197,708号の優先権の利益を享受する。その出願は、参照により本明細書に組み入れられる。本願は、２０１６年６月２９日に出願された「Multi-Interface Processing of Electronic Payment Transactions」というタイトルの米国出願第15/197,711号の優先権の利益を享受する。その出願は、参照により本明細書に組み入れられる。
【背景技術】
【０００２】
各種方法で電子的支払いを行うことができる。支払い端末は支払いトランザクションを処理してもよく、支払いデバイスと相互作用してもよい。そのようなデバイスは、例えば、支払い端末の磁気リーダでスワイプされる磁気ストライプを有する支払いカードや、支払い端末の対応するＥＭＶスロットに差し込まれるユーロペイ／マスターカード／ビザ（ＥＭＶ）チップを有する支払いデバイスや、支払い端末にタップしてセキュアな無線接続を介して支払い情報を送信するスマートフォンやＥＭＶカードなどの近距離無線通信（ＮＦＣ）可能デバイスなどである。支払い端末は支払いデバイスからトランザクションについての情報と共に支払い情報を受信してもよく、トランザクションの処理のためにこの情報を支払いシステムに伝達してもよい。
【０００３】
ときどき、支払い端末が支払いトランザクションを完了させるために支払いサーバと通信することを妨げる条件が生じうる。そのような条件は、ネットワーク接続失敗などの、支払い端末と支払いサーバとの間の通信リンクの欠如により引き起こされる場合がある。そうでない場合でも、例えば支払い端末とサーバとの間の接続が高いレイテンシを経験しているときなどには、支払い端末は、支払いサーバによる承認のための情報を送信することができないであろう。ある場合、支払い端末がサーバに支払い情報を送信可能となるまで支払い処理を完了することができないならば、これらの条件は支払い処理における長い遅延を引き起こしうる。遅延が十分に長くなると、支払い端末のユーザも支払いトランザクションを完了しようとしている消費者も我慢しきれなくなる可能性がある。支払いトランザクション中の遅延は、トランザクションを完了しようとしている消費者をいらだたせ、またマーチャントのトランザクション量を低下させうる。
【０００４】
加えて、大きな支払いトランザクション量を経験している支払い端末は、支払いデバイスと支払いサーバ、例えば金融機関に設けられたサーバ、との間の通信が高速で生じる場合でも、かなりの遅延を経験しうる。トランザクションの継続期間は、支払いデバイスから電子支払い情報を読み出すのに支払い端末が必要とする時間によって影響を受けうる。支払いトランザクションを完了するのに用いられる支払いデバイスのタイプに基づいて遅延が生じる場合がある。例えば、チップカードは、処理が生じている間、支払い端末に物理的に挿入されていなければならない。特に、チップカードトランザクションの処理における遅延は、支払いトランザクション中の不快感または摩擦を生じさせうる。
【図面の簡単な説明】
【０００５】
本開示の上述及び他の側面、性質および種々の利点は、添付図面と併用される以下の詳細な説明の考慮のもとにより明らかとなるであろう。
【０００６】
【図１】本開示のある実施の形態に係る、支払いシステムの説明的ブロック図を示す。
【０００７】
【図２】本開示のある実施の形態に係る、支払いデバイスおよび支払い端末の説明的ブロック図を示す。
【０００８】
【図３】本開示のある実施の形態に係る、支払いリーダの説明的ブロック図を示す。
【０００９】
【図４】本開示のある実施の形態に係る、マーチャントデバイスの説明的ブロック図を示す。
【００１０】
【図５】本開示のある実施の形態に係る、支払いサービスシステムの説明的ブロック図を示す。
【００１１】
【図６】本開示のある実施の形態に係る、チップカードから受信した電子支払い情報を至急処理モードで処理するための例示的方法を説明する非限定的フロー図を示す。
【００１２】
【図７】本開示のある実施の形態に係る、チップカードから受信した電子支払い情報を至急処理モードで処理するための例示的方法を説明する非限定的ラダー図を示す。
【００１３】
【図８】本開示のある実施の形態に係る、複数のインタフェースを通じて電子支払い情報を選択的に処理するための例示的方法を説明する非限定的フロー図を示す。
【発明を実施するための形態】
【００１４】
支払いシステムは支払い端末と、支払いサーバと、を含んでもよい。支払い端末は支払いリーダとマーチャントデバイスとを有してもよい。支払いリーダは、ＥＭＶチップカードや磁気ストライプカードやＮＦＣ支払いデバイスなどの支払いデバイスから支払い情報を受信する。マーチャントデバイスは、マーチャントのためのユーザインタフェースを提供し、かつ、支払いリーダおよび支払いサーバとの通信するポイントオブセールアプリケーションを有する。支払いサーバは、マーチャントデバイスから受信した他の情報（例えば、支払額、マーチャント、位置など）と支払い情報とに基づいてトランザクションを処理し、マーチャントデバイスに支払い結果（例えば、許否）を伝達する。
【００１５】
マーチャントデバイスは、チップカードからの電子支払い情報を至急処理モードで処理する要求を、マーチャントデバイスのユーザインタフェースにおいて、受け付けてもよい。至急処理モードにおいて、マーチャントデバイスは電子支払いトランザクションを、通常の処理ステップを用いた場合よりも速く処理してもよい。至急処理モードに入る前に、マーチャントデバイスはユーザインタフェースに、オプトイン要求を提供してもよい。ある実施の形態では、オプトイン要求は、そのオプトイン要求を受け入れることの結果に関する通知または開示などの、ユーザ用情報を含んでもよい。
【００１６】
ユーザがそのオプトイン要求を受け入れると、マーチャントデバイスは、支払い要求を受け付け、支払いリーダのインタフェース（例えば、接触インタフェース）で挿入されているチップカードに、電子支払い応答を要求してもよい。チップカードからの電子支払い応答は、暗号化された支払い情報などのチップカードからの情報を含んでもよい。ある実施の形態では、チップカードは認証要求暗号（「ＡＲＱＣ」）を含む電子支払い応答を提供してもよい。マーチャントデバイスは電子支払い応答をチップカードから受信し、それをマーチャントデバイスのメモリに格納してもよい。
【００１７】
マーチャントデバイスは、チップカードからの電子支払い応答に関連付けられた支払いトランザクションを承認してもよい。ある実施の形態では、承認は「オフライン承認」として提供されてもよい。ある実施の形態では、マーチャントデバイスからの支払いトランザクションの承認は、チップカードを支払いリーダから取り除くことを可能としうる。マーチャントデバイスは、追加的な支払い要求を処理し、追加的な電子支払い応答を各対応するチップカードから受信し、それらをマーチャントデバイスのメモリに格納してもよい。ある実施の形態では、承認を示している（例えば、ＡＲＱＣを含んでいる）電子支払い応答を提供している各対応するチップカードについて、マーチャントデバイスは、チップカードに対して、トランザクションの承認を提供してもよい。マーチャントデバイスが支払いトランザクションの承認を提供した後、マーチャントデバイスは、各電子支払い応答に、支払いタイプインジケータおよび時刻インジケータを関連付けてもよい。マーチャントデバイスは承認要求を、その承認要求が送信可能であるとマーチャントデバイスが判定した場合、ひとつ以上の支払いサーバに送信してもよい。支払いタイプインジケータは支払いサーバに、承認要求が至急支払いプロトコルにしたがう処理の対象であることを知らせてもよい。したがって、支払いサーバとの追加的な通信のためにチップカードがチップカードスロットのなかに残る必要はなく、むしろトランザクションの初期段階（例えば、最初の電子支払い応答が受信された後）で、チップカードを取り除くことができる。
【００１８】
図１は、本開示のある実施の形態に係る、支払いシステム１の説明的ブロック図を示す。ある実施の形態では、支払いシステム１は、支払いデバイス１０と、支払い端末２０と、ネットワーク３０と、支払いサーバ４０と、を含む。例示的な実施の形態では、支払いサーバ４０は、支払いサービスシステム５０や銀行サーバ６０などの異なる主体により運用される複数のサーバを含んでもよい。支払いシステム１のこれらのコンポーネントは、マーチャントと顧客との間の電子支払いトランザクションを促進する。
【００１９】
マーチャントと顧客との間の電子的やりとりは、顧客の支払いデバイス１０とマーチャントの支払い端末２０との間で生じる。顧客は、磁気ストライプを有するクレジットカードや、ＥＭＶチップを有するクレジットカードや、支払いアプリケーションを実行するスマートフォンなどのＮＦＣ可能電子デバイスなどの支払いデバイス１０を有する。マーチャントは支払い端末や他の電子デバイスなどの支払い端末２０を有する。そのような他の電子デバイスは支払い情報（例えば、暗号化された支払いカードデータおよびユーザ認証データ）およびトランザクション情報（例えば、購入量およびポイントオブパーチェイス情報）を処理することができ、例えば支払いアプリケーションを実行するスマートフォンやタブレットである。
【００２０】
ある実施の形態（例えば、廉価トランザクションやＮＦＣまたはＥＭＶ支払いデバイス１０によって示される支払い上限よりも少ない支払いトランザクションについてのもの）では、支払いトランザクションの初期処理および承認は支払い端末２０において処理されてもよい。他の実施の形態では、支払い端末２０はネットワーク３０を介して支払いサーバ４０と通信してもよい。支払いサーバ４０が単一の主体により運用されてもよいが、ある実施の形態では、支払いサーバ４０は任意の適切な主体により運用される任意の適切な数のサーバを含んでもよいこと、例えば支払いサービスシステム５０ならびにマーチャントおよび顧客のひとつ以上の銀行（例えば、銀行サーバ６０）を含んでもよいこと、は理解されるべきである。支払い端末２０および支払いサーバ４０は支払い情報およびトランザクション情報をやりとりし、トランザクションを承認するか否かを決定する。例えば、支払い端末２０はネットワーク３０を介して支払いサーバ４０に、暗号化された支払いデータとユーザ認証データと購入量情報とポイントオブパーチェイス情報とを提供してもよい。支払いサーバ４０は、この受信した情報と顧客アカウントまたはマーチャントアカウントに関する情報とに基づいて、トランザクションを承認するか否かを決定し、支払いトランザクションが承認されたか否かを示すためにネットワーク３０を介して支払い端末２０に応答してもよい。支払いサーバ４０はまた、支払い端末２０に、トランザクション識別子などの追加情報を送信してもよい。
【００２１】
支払い端末２０において支払いサーバ４０から受信した情報に基づいて、マーチャントはトランザクションが承認されたか否かを顧客に示してもよい。ある実施の形態、例えばチップカード支払いデバイス、では、承認は支払い端末において、例えば支払い端末の画面に、示されてもよい。ＮＦＣ支払いデバイスとして動作するスマートフォンやウォッチなどの他の実施の形態では、承認されたトランザクションおよび追加情報（例えば、レシート、特別なオファー、クーポン、ロイヤリティプログラム情報など）についての情報がＮＦＣ支払いデバイスに提供され、スマートフォンやウォッチの画面に表示されるかまたはメモリに格納されてもよい。
【００２２】
ある実施の形態では、支払いサーバ４０は支払い端末２０から複数の支払い承認要求を受信してもよい。後に詳述されるように、各支払い承認要求は、電子支払い応答と、関連する支払いタイプインジケータと、を含んでもよく、該支払いタイプインジケータは、支払い応答が至急処理モードを用いて処理されるべきであることを示す。支払いサーバ４０はまた、支払い端末２０から、支払い端末２０の通信インタフェースの、支払いサーバ４０と通信する能力、または支払い端末２０と支払いサーバ４０との間の接続速度、をチェックするためのインジケータを含む支払い承認要求を受信してもよい。ある実施の形態では、支払いサーバ４０は、支払い承認要求と、関連する時刻インジケータと、を受信し、時刻インジケータにより示される時刻にしたがって支払い承認要求を処理してもよい。さらに、ある実施の形態では、支払いサーバ４０は、電子支払い情報と、スワイプモード処理インジケータと、を受信し、電子支払い情報用の支払い承認応答を提供してもよい。
【００２３】
図２は、本開示のある実施の形態に係る、支払いデバイス１０および支払い端末２０の説明的ブロック図を示す。支払いシステム１の支払い端末２０および支払いデバイス１０が任意の適切な態様で実装可能であることは理解されるところであるが、ある実施の形態では、支払い端末２０は支払いリーダ２２とマーチャントデバイス２９とを備えてもよい。しかしながら、本明細書で用いられる場合、支払い端末という語は、支払い端末２０全体を、または支払いリーダ２２やマーチャントデバイス２９などの支払い端末２０の任意の適切なコンポーネントを、指してもよいことは理解されるであろう。ある実施の形態では、支払い端末２０の支払いリーダ２２は、支払いデバイス１０と、ポイントオブセールアプリケーションを実行するマーチャントデバイス２９と、の間のトランザクションを促進する無線通信デバイスであってもよい。
【００２４】
ある実施の形態では、支払いデバイス１０は、支払い端末２０と（例えば、支払いリーダ２２を介して）通信可能なデバイス、ＮＦＣデバイス１２やＥＭＶチップカード１４などであってもよい。チップカード１４はセキュアな集積回路を含んでもよい。この集積回路は、支払い端末２０などの支払い端末と通信することができ、暗号化された支払い情報を生成することができ、ＥＭＶＣｏによって公表されているものなどのひとつ以上の電子的支払い規格にしたがい、その暗号化された支払い情報と他の支払いまたはトランザクション情報（例えば、ローカルで処理される支払いについてのトランザクション上限）とを提供することができる。チップカード１４は支払いリーダ２２と通信するための接触ピン（例えば、ＩＳＯ７８１６にしたがうもの）を含んでもよく、ある実施の形態では、近距離場１５を介して支払いリーダ２２と誘導的に結合されてもよい。支払いリーダ２２と誘導的に結合するチップカード１４は、ＩＳＯ１４４４３などの無線通信規格にしたがい支払いリーダ２２によって提供される無線キャリア信号の負荷変調を用いて、支払いリーダ２２と通信してもよい。
【００２５】
ＮＦＣデバイス１２は、支払い端末２０との（例えば、支払いリーダ２２との通信を介した）セキュアなトランザクションを行うことができる、スマートフォンやタブレットやスマートウォッチなどの電子デバイスであってもよい。ＮＦＣデバイス１２は、セキュアなトランザクション機能を実行するためのハードウエア（例えば、ハードウエアおよび実行可能コードを含むセキュアエレメント）および／またはソフトウエア（例えば、ホストカードエミュレーションルーチンにしたがいプロセッサ上で実行される実行可能コード）を有してもよい。支払いトランザクション中、ＮＦＣデバイス１２は近距離場１５を介して支払いリーダ２２と誘導的に結合されてもよく、ＩＳＯ１４４４３およびＩＳＯ１８０９２などのひとつ以上の無線通信規格にしたがい支払いリーダ２２によって提供される無線キャリア信号の能動的または受動的負荷変調によって支払い端末２０と通信してもよい。
【００２６】
支払い端末２０は任意の適切な態様で実装可能であるが、ある実施の形態では、支払い端末２０は支払いリーダ２２とマーチャントデバイス２９とを含んでもよい。マーチャントデバイス２９は、マーチャントのためのユーザインタフェースを提供し、かつ、支払いリーダ２２および支払いサーバ４０との通信を促進するポイントオブセールアプリケーションを実行する。支払いリーダ２２は支払いデバイス１０とマーチャントデバイス２９との間の通信を促進してもよい。本明細書で説明される通り、ＮＦＣデバイス１２やチップカード１４などの支払いデバイス１０は誘導的結合を介して支払いリーダ２２と通信してもよい。これは図２において近距離場１５として描かれている。この近距離場１５は、支払いリーダ２２から発せられる適切な周波数（例えば、１３．５６ＭＨｚ）を有する無線キャリア信号を含む。
【００２７】
ある実施の形態では、支払いデバイス１０はＮＦＣデバイス１２やチップカード１４などの非接触支払いデバイスであってもよく、支払いリーダ２２および非接触支払いデバイス１０は近距離場１５内の無線キャリア信号を変調することによって通信してもよい。支払いデバイス１０に情報を伝達するために、支払いリーダ２２は、支払いリーダ２２から送信するべきデータに基づいて無線キャリア信号の振幅および／または位相を変化させ、その結果支払いデバイスへと送信される無線データ信号が生成される。この信号は、１３．５６ＭＨｚで送信するようチューンされた支払いリーダ２２のアンテナによって送信され、支払いデバイス１０もまた近距離場１５の範囲内（例えば、０ｃｍから１０ｃｍ）に適切にチューンされたアンテナを有する場合、支払いデバイスは支払いリーダ２２によって送信された無線キャリア信号または無線データ信号を受信する。無線データ信号の場合、支払いデバイス１０の処理回路は、受信した信号を復調し、支払いリーダ２２から受信されたデータを処理することができる。
【００２８】
支払いデバイス１０などの非接触支払いデバイスが近距離場１５の範囲内にある場合、それは支払いリーダ２２と誘導的に結合される。したがって、支払いデバイス１０はまた、能動的または受動的負荷変調を介して、無線キャリア信号を変調することができる。支払いデバイス１０のアンテナのチューニング特性を変えることによって（例えば、アンテナ回路において送信対象の被変調データに基づいて選択的に並列負荷を選択することによって）、支払いデバイス１０および支払いリーダ２２の両方において無線キャリア信号が変調され、これにより被変調無線キャリア信号が生成される。このようにして、支払いデバイスは支払いリーダ２２に被変調データを送信することができる。
【００２９】
ある実施の形態では、支払いリーダ２２はまた、チップカード１４を受けることができるＥＭＶスロット２１を含む。チップカード１４は、チップカード１４がＥＭＶスロット２１に挿入されたときに支払いリーダ２２の対応する接点と係合する接点を有してもよい。支払いリーダ２２はこれらの接点を通じてチップカード１４のＥＭＶチップに給電し、支払いリーダ２２とチップカード１４とはそれらの接点によって確立される通信経路を通じて通信する。
【００３０】
支払いリーダ２２はまた、磁気ストライプカードとのインタフェースとなるハードウエアをふくんでもよい（図２では不図示）。ある実施の形態では、ハードウエアは、磁気ストライプカードの磁気ストライプをスワイプするか沈めるよう顧客を案内するスロットを含んでもよく、この場合、磁気ストライプリーダは磁気ストライプカードから支払い情報を受けることができる。次いで、受信された支払い情報は支払いリーダ２２によって処理される。
【００３１】
マーチャントデバイス２９は、タブレット支払いデバイス２４やモバイル支払いデバイス２６や支払い端末２８などの任意の適切なデバイスであってもよい。タブレット支払いデバイス２４やモバイル支払いデバイス２６などの計算デバイスの場合、ポイントオブセールアプリケーションは、購入および支払い情報の入力、顧客とのやりとり、および支払いサーバ４０との通信を担当してもよい。例えば、支払いアプリケーションは、マーチャントがそのなかから選択できるサービスメニューと、トランザクションを自動化するための一連のメニューまたは画面と、を提供してもよい。支払いアプリケーションはまた、署名やＰＩＮ番号や生体情報などの顧客認証情報の入力を促進してもよい。専用支払い端末２８に同様の機能が提供されてもよい。
【００３２】
マーチャントデバイス２９は、通信経路２３／２５／２７を介して支払いリーダ２２と通信してもよい。通信経路２３／２５／２７は有線接続（例えば、イーサネット、ＵＳＢ、ファイヤワイヤ、ライトニング）または無線接続（例えば、Ｗｉ−Ｆｉ、ブルートゥース、ＮＦＣ、ＺｉｇＢｅｅ）を介して実装されてもよいが、ある実施の形態では、支払いリーダ２２はブルートゥースローエナジーインタフェースを介してマーチャントデバイス２９と通信してもよく、この場合、支払いリーダ２２とマーチャントデバイス２９とは接続されたデバイスとなる。ある実施の形態では、例えば、トランザクション量が少ないか支払いサーバ４０への接続がない場合、支払いトランザクションの処理が支払いリーダ２２およびマーチャントデバイス２９においてローカルで生じうる。他の実施の形態では、マーチャントデバイス２９または支払いリーダ２２は公衆または専用通信ネットワーク３０を介して支払いサーバ４０と通信してもよい。通信ネットワーク３０は任意の適切な通信ネットワークであってもよいが、ある実施の形態では、通信ネットワーク３０はインターネットであってもよく、支払いおよびトランザクション情報は支払い端末２０と支払いサーバ４０との間で暗号化形式で、例えばトランスポートレイヤセキュリティ（ＴＬＳ）やセキュアソケットレイヤ（ＳＳＬ）プロトコルにより、通信されてもよい。
【００３３】
図３は、本開示のある実施の形態に係る、例示的支払いリーダ２２のブロック図を示す。ある実施の形態では、支払いリーダ２２は、例えばブルートゥースクラシックやブルートゥースローエナジーを用いて、マーチャントデバイス２９などの双方向電子デバイスと無線通信する無線通信デバイスであってもよい。図３において特定のコンポーネントが特定の構成で描かれているが、支払いリーダ２２が追加のコンポーネントを含んでもよいこと、図３に示されるコンポーネントのうちのひとつ以上が支払いリーダ２２に含まれなくてもよいこと、および支払いリーダ２２のコンポーネントが任意の適切な態様で再構成されうること、は理解されるであろう。ある実施の形態では、支払いリーダ２２は、リーダチップ１００と、複数の支払いインタフェース（例えば、非接触インタフェース１０２、接触インタフェース１０４、およびスワイプインタフェース１０５）と、電源１０６と、無線通信インタフェース１０８と、有線インタフェース１１０と、トランザクションチップ１１４と、を含む。支払いリーダ２２はまた、リーダチップ１００内に処理ユニット１２０とメモリ１２２とを含み、トランザクションチップ１１４内に汎用処理ユニット１２４と暗号化処理ユニット１２５と汎用メモリ１２６と暗号化メモリ１２８とを含む。ある実施の形態では、処理ユニット１２０およびメモリ１２２はリーダチップ１００およびトランザクションチップ１１４のそれぞれにパッケージされたものとして、また特定の態様で構成されるものとして説明されるが、処理ユニット１２０、汎用処理ユニット１２４、暗号化処理ユニット１２５、メモリ１２２、汎用メモリ１２６および暗号化メモリ１２８を任意の適切な態様で構成することで、本明細書で説明されるような支払いリーダ２２の機能を実行できることは理解されるであろう。リーダチップ１００およびトランザクションチップ１１４の機能が単一のチップまたは複数のチップにおいて実現可能であること、および、そのそれぞれが任意の適切な処理ユニットおよびメモリの組み合わせを含み、それにより合わせて本明細書で説明されるリーダチップ１００およびトランザクションチップ１１４の機能を行うことは、理解されるであろう。
【００３４】
ある実施の形態では、支払いリーダ２２はユーザに出力を提供するための種々のインタフェース要素（不図示）を含んでもよい。ある実施の形態では、インタフェース要素は、支払いリーダ２２におけるトランザクションまたは処理の進捗のインジケータを提供してもよい。インタフェース要素は、タッチ画面、光、テキスト表示、スピーカ、または他のインタフェースなどの、支払いリーダ２２のユーザに出力を提供するための任意の適切なデバイスであってもよい。ある実施の形態では、インタフェース要素は、ユーザから入力を受け付け、リーダチップ１００やトランザクションチップ１１４などの支払いリーダ２２の種々のリソースにその入力を提供するよう構成されてもよい。
【００３５】
ある実施の形態では、リーダチップ１００はFreescale Semiconductor, Incにより供給されるＫ２１チップなどの任意の適切なチップであってもよい。支払いリーダ２２のリーダチップ１００の処理ユニット１２０は任意の適切なプロセッサであってもよく、支払いリーダ２２の機能を実行し制御するのに必要な限り、ハードウエア、ソフトウエア、メモリ、および回路を含みうる。処理ユニット１２０はひとつ以上のプロセッサを含んでもよく、また、任意の適切な数のメモリやメモリタイプ内のインストラクションに基づいてリーダチップ１００の動作を行ってもよい。ある実施の形態では、処理ユニット１２０は、マルチコアプロセッサや他の同様のコンポーネントなどの複数の独立した処理ユニットを有してもよい。処理ユニット１２０は、リーダチップ１００のメモリ１２２に保持されるインストラクションを実行することで、支払いリーダ２２の動作および処理を制御してもよい。本明細書で用いられる場合、プロセッサまたは処理ユニットは、本明細書で説明される処理機能を行うために必要な処理能力を有するひとつ以上のプロセッサを含んでもよく、例えば、ハードウエアロジック（例えば、ハードウエア記述言語（ＨＤＬ）などのハードウエアの構成を記述するソフトウエアによって設計されたハードウエア）やプロセッサが実行するコンピュータ可読インストラクションやそれらの任意の適切な組み合わせなどを含むがそれらに限定されない。プロセッサは本明細書で説明される動作を行うためにソフトウエアを実行してもよく、そのようなソフトウエアは、実体的非一時的コンピュータ可読保持媒体上の機械可読形態でアクセスされたソフトウエアを含む。
【００３６】
例示的な実施の形態では、リーダチップ１００の処理ユニット１２０は、支払いリーダ２２の種々のコンポーネントの動作を、メモリ１２２に保持されるインストラクションに基づいて、制御するためのハブとして動作するよう構成された二つのＲＩＳＣプロセッサを含んでもよい。本明細書で用いられる場合、メモリは、任意の適切な実体的または非一時的保持媒体を指してもよい。実体的（または、非一時的）保持媒体の例は、ディスクと、サム（thumb）ドライブと、メモリと、を含むが、伝送信号は含まない。実体的コンピュータ可読保持媒体は、コンピュータ可読インストラクションやデータ構造やプログラムモジュールや他のデータなどの、揮発性および不揮発性、取り外し可能および取り外し不可媒体を含む。そのような媒体の例は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＳＲＡＭ、フラッシュメモリ、ディスクまたは光学ストレージ、磁気ストレージ、あるいはプロセッサまたは計算デバイスによってアクセスされる情報を保持する任意の他の非一時的媒体を含む。
【００３７】
リーダチップ１００はまた、インタフェース回路やアナログフロントエンド回路やセキュリティ回路やコンポーネント監視回路などの追加回路を含んでもよい。ある実施の形態では、インタフェース回路は、無線通信インタフェース１０８（例えば、Ｗｉ−Ｆｉ、ブルートゥースクラシック、ブルートゥースローエナジー）とのインタフェースとなる回路と、有線インタフェース１１０（例えば、ＵＳＢ、イーサネット、ファイヤワイヤ、およびライトニング）とのインタフェースとなる回路と、他の通信インタフェースまたはバス（例えば、Ｉ２Ｃ、ＳＰＩ、ＵＡＲＴおよびＧＰＩＯ）とのインタフェースとなる回路と、電源１０６とのインタフェースとなる回路（例えば、電力管理回路、電力変換回路、整流器、および電池充電回路）と、を含んでもよい。
【００３８】
トランザクションチップ１１４は、本明細書で説明される処理機能を行うために必要な処理能力を有するひとつ以上のプロセッサを含んでもよく、例えば、ハードウエアロジックやプロセッサが実行するコンピュータ可読インストラクションやそれらの任意の適切な組み合わせなどを含むがそれらに限定されない。例示的な実施の形態では、トランザクションチップ１１４は、支払いトランザクションの処理や支払いデバイスとのインタフェースや暗号化や他の支払い特定機能に関する機能を行ってもよい。ある実施の形態では、トランザクションチップ１１４は汎用支払い機能に関連付けられたインストラクションを実行するための汎用処理ユニット１２４と、暗号化処理動作を扱うための暗号化処理ユニット１２５と、を含んでもよい。汎用処理ユニット１２４および暗号化処理ユニット１２５のそれぞれは、それに関連付けられた専用メモリ（すなわち、汎用メモリ１２６と、暗号化メモリ１２８）を有してもよい。この態様では、特定の暗号化処理および重要セキュリティ情報（例えば、暗号化鍵、パスワード、ユーザ情報等）は、暗号化メモリ１２８および暗号化処理ユニット１２５によって安全に保持され、処理されうる。
【００３９】
トランザクションチップ１１４の汎用処理ユニット１２４および暗号化処理ユニット１２５の一方または両方は、例えば任意の適切な内部バスおよび通信技術を用いてリーダチップ１００（例えば、処理ユニット１２０）と通信してもよい。この態様では、リーダチップ１００とトランザクションチップ１１４とは併せて、トランザクションを処理し、処理されたトランザクションに関する情報を（例えばマーチャントデバイス２９に）伝達してもよい。
【００４０】
トランザクションチップ１１４はまた、接触インタフェース１０４とのインタフェースとなるための回路（例えば、スロット２１に挿入されたチップカード１４のＥＭＶチップと直接インタフェースするための電源および通信回路）を含んでもよい。ある実施の形態では、トランザクションチップ１１４はまた、非接触インタフェース１０２のアナログコンポーネントとのインタフェースとなるアナログフロントエンド回路（例えば、電磁整合（ＥＭＣ）回路、整合回路、変調回路、および測定回路）を含んでもよい。
【００４１】
非接触インタフェース１０２は、チップカード１４やＮＦＣデバイス１２などの非接触デバイスとのＮＦＣ通信を提供してもよい。リーダチップ１００によって提供される信号に基づいて、非接触インタフェース１０２のアンテナはキャリア信号または変調信号のいずれかを出力してもよい。キャリア信号は、１３．５６ＭＨｚなどの固定周波数を有する信号であってもよい。変調信号は、ＩＳＯ  １４４４３やＩＳＯ  １８０９２などの変調手順にしたがい変調されたバージョンのキャリア信号であってもよい。支払いリーダ２２が非接触デバイスと誘導的に結合するとき、非接触デバイスはまたキャリア信号を変調し、変調された信号は非接触インタフェース１０２によって検出され、処理のためにリーダチップ１００に提供されてもよい。キャリア信号のこの変調に基づいて、支払いリーダ２２および非接触デバイスは支払い情報などの情報を伝達することができる。
【００４２】
接点インタフェース１０４は、チップカード１４のＥＭＶチップなどの支払いチップに給電し、ＥＭＶチップと通信するための適切なインタフェースであってもよい。接点インタフェース１０４は、ＥＭＶ規格にしたがいチップカード１４との物理的なインタフェースとなる複数の接触ピン（図３では不図示）を含んでもよい。ある実施の形態では、接触インタフェース１０４は、電源（ＶＣＣ）ピンと、グランド（ＧＮＤ）ピンと、ＥＭＶカードをリセットするためのリセット（ＲＳＴ）ピンと、クロック信号を提供するためのクロック（ＣＬＫ）ピンと、ＥＭＶカードにプログラミング電圧を提供するためのプログラミング電圧（ＶＰＰ）ピンと、ＥＭＶ通信を提供するための入出力（Ｉ／Ｏ）ピンと、二つの補助ピンと、を含んでもよい。この態様では、支払いリーダおよびチップカードは支払い情報などの情報を交換することができる。
【００４３】
ある実施の形態では、接触インタフェース１０４にチップカード検出回路１１２が設けられてもよく、この回路１１２はチップカードが接触インタフェース１０４のチップカードインタフェース（例えば、カードスロット）に挿入されたときを検出してもよい。例示的な実施の形態では、チップカード検出回路は、接触インタフェース１０４のカードスロットのなかにチップカードが存在することを検出するための適切なハードウエア（例えば、スイッチ、光学検出回路、近接センサ等）を含んでもよい。この信号は、次いで、支払いリーダ２２のひとつ以上の他のコンポーネント（例えば、支払いリーダ２２のリーダチップ１００）による処理のために提供されてもよい。
【００４４】
スワイプインタフェース１０５は、スワイプインタフェース１０５を通じてスワイプされた、クレジットカードやデビットカードなどの支払いデバイスの磁気的ストリップ（「磁気ストリップ」）から情報を読み出すためのインタフェースを提供してもよい。ある実施の形態では、スワイプインタフェース１０５は、トランザクションチップ１１４と通信してもよく、スワイプインタフェース１０５を通じてユーザが磁気ストリップをスワイプしたときに受信された電子支払い情報を、処理のためにトランザクションチップ１１４に提供してもよい。ある実施の形態では、スワイプインタフェース１０５は、支払いカードの磁気ストリップから情報を読み出すための、かつ、その情報をトランザクションチップ１１４に提供するための、任意の適切なハードウエアを含んでもよい。
【００４５】
ある実施の形態では、汎用処理ユニット１２４は、本明細書で説明される支払いリーダ２２の支払い処理機能を行うための任意の適切なプロセッサを含んでもよい。ある実施の形態では、汎用メモリ１２６は本明細書で説明されるような任意の適切なメモリであってもよく、支払いリーダ２２の汎用トランザクション処理動作を行うためのインストラクションの複数の集合を含んでもよく、そのようなインストラクションの集合は例えばトランザクション処理インストラクション１６６や、データ認証インストラクション１６８や、信号調整インストラクション１７０などである。
【００４６】
トランザクション処理インストラクション１６６は、支払いリーダ２２と支払いデバイス１０との間の相互作用（例えば、非接触インタフェース１０２および接触インタフェース１０４を介して支払いデバイスとのインタフェースとなるためのもの）を制御することや、（例えば、支払い方法に関連付けられた支払い処理主体に基づいて）支払い処理手順を選択することや、暗号化プロセッサ１２５とのインタフェースとなることや、トランザクション処理の任意の他の適切な側面などの、支払いリーダ２２の汎用トランザクション処理動作を制御するためのインストラクションを含んでもよい。 
【００４７】
データ認証インストラクション１６８は、支払い端末２０の設定情報を提供するためのインストラクションを含んでもよい。設定情報は、支払い上限やローカルトランザクション（すなわち、支払いサーバ４０に接続せずに生じるトランザクション）のトランザクションタイプやサポートされるアプリケーションなどの任意の適切な情報を含んでもよい。ある実施の形態では、一例として、データ認証インストラクション１６８はＴＭＳ−ＣＡＰＫインストラクションなどの設定インストラクションを含んでもよい。ある実施の形態では、ＴＭＳ−ＣＡＰＫインストラクションは、特定の法域（例えば、国に特有）用に調整されてもよい。
【００４８】
信号調整インストラクション１７０は、非接触インタフェース１０２を介して支払いデバイス１０から（例えば、ＮＦＣ支払いデバイス１０から）受信した信号を調整するインストラクションを含んでもよい。ある実施の形態では、信号調整インストラクション１７０は非接触インタフェース１０２を介して受信された信号を操作するためのインストラクションを含んでもよく、信号調整インストラクション１７０は、非接触インタフェース１０２を介して受信されるＮＦＣ信号を処理するのに必要とされる任意の適切なハードウエア、ロジック、またはアルゴリズムを用いて信号を調整するためのインストラクションを含んでもよい。
【００４９】
暗号化処理ユニット１２５は本明細書で説明された任意の適切なプロセッサであってもよく、ある実施の形態では、支払いトランザクションの処理のための暗号化機能を行ってもよい。例えば、ある実施の形態では、暗号化処理ユニット１２５はひとつ以上の暗号化鍵に基づいてデータを暗号化および復号してもよく、これは、支払いリーダ２２の他のコンポーネントから暗号化機能を隔離することで、暗号化鍵を支払いリーダ２２の他のコンポーネントへの暴露から守るような態様でなされる。
【００５０】
ある実施の形態では、暗号化メモリ１２８は本明細書で説明された任意の適切なメモリまたはその組み合わせであってもよく、支払い処理インストラクション１７６および暗号化インストラクション１７８などの暗号化動作を行うためのインストラクションの複数の集合を含んでもよい。支払い処理インストラクション１７６は、特定の支払い手順に関連付けられて用いられるべき暗号化技術を提供することや、アカウントにアクセスして情報を処理することや、任意の他の適切な支払い処理機能や、それらの任意の適切な組み合わせなどの、支払い処理の側面を行うためのインストラクションを含んでもよい。暗号化インストラクション１７８は、暗号化動作を行うためのインストラクションを含んでもよい。暗号化処理ユニット１２５は、暗号化機能や復号機能やサイン機能や、支払いの際の署名を検証したり支払いトランザクションの一部としてトランザクション情報を検証する機能などの各種暗号化機能を行うための暗号化インストラクション１７８を実行してもよい。
【００５１】
無線通信インタフェース１０８は、適切な無線通信ハードウエア（例えば、アンテナなど）と、（例えば、ブルートゥースローエナジーなどのプロトコルを介したマーチャントデバイス２９との）無線通信に参加し、関連回路を制御するのに必要な処理能力を有するひとつ以上のプロセッサと、を含んでもよく、関連回路はハードウエアロジック、プロセッサで実行されるコンピュータ可読インストラクション、またはそれらの任意の適切な組み合わせを含むがそれらに限定されない。無線通信インタフェース１０８は任意の適切な態様で実装されうるが、例示的な実施の形態では、無線通信インタフェース１０８は、処理ユニット（不図示）およびメモリ（不図示）を含んでもよい、Texas Instruments CC2640デバイスとして実装されてもよい。 
【００５２】
電源１０６はＡＣ電源や電池への物理的接続などのひとつ以上の電源を含んでもよい。電源１０６は、ＡＣまたはＤＣ電源を、支払いリーダ２２のコンポーネントによる使用のための複数のＤＣ電圧に変換するための電力変換回路を含んでもよい。電源１０６が電池を含む場合、電池は物理的な電力接続を介して、または、誘導充電を介して、または、任意の他の適切な方法を介して、充電可能である。図３では支払いリーダ２２の他のコンポーネントに物理的に接続されているようには描かれていないが、電源１０６はコンポーネントの要件にしたがって、支払いリーダ２２のコンポーネントに各種電圧を供給してもよい。
【００５３】
有線インタフェース１１０は、ＵＳＢやライトニングやファイヤワイヤやイーサネットや任意の他の適切な有線通信インタフェースやそれらの任意の組み合わせなどの、他のデバイスや通信ネットワークとの有線通信のための任意の適切なインタフェースを含んでもよい。ある実施の形態では、有線インタフェース１１０は、支払いリーダが、マーチャントデバイス２９および支払いサーバ４０のうちの一方または両方と通信できるようにしてもよい。
【００５４】
リーダチップ１００のメモリ１２２は、オペレーティングインストラクション１３０やトランザクション処理インストラクション１３２などの、支払いリーダ２２の動作を制御するためのインストラクションの複数の集合を含んでもよい。
【００５５】
オペレーティングインストラクション１３０は、内部通信や電力管理やメッセージ処理やシステム監視やスリープモードやユーザインタフェース応答および制御や無線インタフェース１０８の動作やトランザクションチップ１１４の動作やインストラクションの他の集合の管理などの、支払いリーダ２２の汎用動作を制御するためのインストラクションを含んでもよい。ある実施の形態では、オペレーティングインストラクション１３０は、支払いリーダ２２のリーダチップ１００の処理ユニット１２０によって実行される処理動作のほとんどを実行するのに必要なオペレーティングシステムおよびアプリケーションを提供してもよい。
【００５６】
オペレーティングインストラクション１３０はまた、マーチャントデバイス２９とのインタフェースとなるためのインストラクションを含んでもよい。ある実施の形態では、マーチャントデバイス２９はポイントオブセールアプリケーションを実行していてもよい。オペレーティングインストラクション１３０は、そのポイントオブセールアプリケーションと情報を交換するための、リーダチップ１００の処理ユニット１２０で実行される相補アプリケーション用のインストラクションを含んでもよい。例えば、ポイントオブセールアプリケーションは、マーチャントなどのユーザが、顧客との購入トランザクションを行うことを容易にするユーザインタフェースを提供してもよい。メニューは、アイテム選択と、税金計算と、チップの追加と、他の関連機能と、を提供してもよい。支払いを受けるときになると、ポイントオブセールアプリケーションは支払いリーダ２２に（例えば、無線インタフェース１０８を介して）メッセージを送信してもよい。オペレーティングインストラクション１３０は、例えば、非接触インタフェース１０２や接触インタフェース１０４を介して支払い情報を取得し、その支払い情報を処理するためにトランザクションチップ１１４を呼び出し、無線インタフェース１０８を介してマーチャントデバイスのポイントオブセールアプリケーションに伝送される応答メッセージを生成することによって、支払い処理を促進する。
【００５７】
オペレーティングインストラクション１３０はまた、支払いサーバ４０の支払いサービスシステム５０とのインタフェースとなるためのインストラクションを含んでもよい。ある実施の形態では、支払いサービスシステム５０は支払いリーダ２２およびマーチャントデバイス２９のポイントオブセールアプリケーションに関連付けられてもよい。例えば、支払いサービスシステム５０は、支払いサービスシステム５０に登録されている（例えば、一意の識別子に基づいて）支払いリーダ２２およびマーチャントデバイス２９についての情報を有してもよい。この情報を用いることで、マーチャントおよび顧客金融機関のサーバとのトランザクションを処理し、マーチャントに解析および報告を提供し、トランザクションデータを収集することができる。支払いリーダ２２は、支払い情報を（例えば、リーダチップ１００およびトランザクションチップ１１４の動作に基づいて）処理し、そのように処理された支払い情報をポイントオブセールアプリケーションに伝達してもよく、そのアプリケーションは次いで支払いサービスシステム５０と通信する。この態様では、支払いリーダ２２からのメッセージは支払いサーバ４０の支払いサービスシステム５０に転送され、この場合、支払いリーダ２２および支払いサービスシステム５０は支払いトランザクションを協働して処理してもよい。
【００５８】
トランザクション処理インストラクション１３２は支払いリーダ２２における支払いトランザクションの処理のためのインストラクションを含んでもよい。ある実施の形態では、トランザクション処理インストラクションは、ＥＭＶによって公表されているもののような支払い標準に準拠してもよい。使用中の支払い方法（例えば、ユーロペイ、マスターカード、ビザ、アメリカンエキスプレス等）に依存して、その支払い方法に関連付けられた特定の処理手順が選択され、その手順にしたがってトランザクションを処理してもよい。処理ユニット１２０によって実行されると、これらのインストラクションは、トランザクションをローカルで処理するか否かを決定し、支払いデバイスからの支払い情報へのアクセスをどのようにするかを決定し、その支払い情報をどのように処理するかを決定し、どの暗号化機能を実行するかを決定し、支払いサーバと交換する通信タイプを決定し、支払いトランザクションの処理に関する任意の他の適切な情報を決定してもよい。ある実施の形態では、トランザクション処理インストラクション１３２は高位の処理を実行し、処理ユニット１２０がトランザクションチップ１１４と通信して大抵のトランザクション処理動作を行うためのインストラクションを提供してもよい。
【００５９】
トランザクション処理インストラクション１３２は、支払いトランザクション中にプリチャージ動作を行う際に支払い情報を支払いデバイスに伝達するためのプリチャージインストラクションを含んでもよい。ある実施の形態では、トランザクション処理インストラクション１３２は、（例えば、支払いリーダと通信するマーチャントデバイス２９で実行されるポイントオブセールアプリケーションにおいて）支払いトランザクションが完了するまでの支払いリーダ２２による処理のための予備的チャージを、チップカードに提供することを意図するトランザクションを取り扱うためのインストラクションを含んでもよい。ある実施の形態では、予備的チャージまたは複数の予備的チャージは、チップカードが認証応答（例えば、認証応答暗号）を生成するためにダミーのチャージ量を提供してもよい。プリチャージ要求がマーチャントデバイスからいつ受信されるかに依存して、この認証応答は、マーチャントが支払いトランザクションを完了する前に、マーチャントデバイスに（例えば、無線インタフェース１０８または有線インタフェース１１０を介して）返される場合がある。
【００６０】
ある実施の形態では、プリチャージ中に返された承認応答を、マーチャントによって完了されるべきトランザクションの実際の支払い量とマッチする支払い量と共に処理することが望ましい。そのようなプリチャージは、チップカードによる、トランザクション処理インストラクション１３２に基づく承認用の、複数の予備的支払い量を取得することを含んでもよい。リーダチップ１００は、例えばマーチャントデバイス２９や支払いサーバ４０におけるポイントオブセールアプリケーションから、複数の予備的支払い量のそれぞれをメッセージで受信してもよい。以下で詳述されるように、ある実施の形態では、複数の予備的支払い量は任意に決定されてもよく、リーダチップ１００による使用のために支払いリーダ２２に提供されてもよい。後に詳述されるように、他の実施の形態では、マーチャントデバイス２９の履歴データを用いた予測技術に基づいて複数の予備的支払い量を導出してもよく、ある実施の形態では、その予測に他の支払い端末２０からのデータを用いてもよい。トランザクション処理インストラクション１３２は、実際の支払い量が受信される（例えば、支払いトランザクションからの支払い情報の処理が完了する）まで予備的チャージを提供し続けるためのインストラクションを含んでもよい。
【００６１】
他の実施の形態では、トランザクション処理インストラクション１３２は、チャージ要求がプリチャージ要求であるとのインジケータを受信し、プリチャージ要求に関連付けられたインジケータに優先度を割り当て、そのインジケータおよびそれに割り当てられた優先度をメモリ１２２などのメモリに格納するためのインストラクションを含んでもよい。この点で、リーダチップ１００はインジケータに基づいてプリチャージ要求の優先度を上げるか下げるかしてもよい。ある実施の形態では、リーダチップ１００は、優先度の順番（例えば、最高から最低への優先付け）で、各プリチャージ要求の承認を獲得してもよい。ある実施の形態では、トランザクション処理インストラクション１３２は、予備的支払い量に割り当てられたスコアであって予備的支払い量がトランザクションの実際の支払い量とマッチする蓋然性を示すスコアに対して比例する優先度を割り当てるためのインストラクションを含んでもよい。さらに他の実施の形態では、リーダチップ１００は、トランザクション処理インストラクション１３２に保持されるインストラクションを用いて、要求がプリチャージ要求か否かに関わらず、支払い情報の要求を格納し、その優先度を上げたり下げたりしてもよい。
【００６２】
トランザクション処理インストラクション１３２は、支払いトランザクション中にチャージが開始される前に、支払い情報以外の情報を収集するためのインストラクションを含んでもよい。例えば、チップカードが接触インタフェース１０４に挿入された場合であって、しかしながらトランザクションチップ１１４がそのカードに電子支払い情報（すなわち、チャージ）を要求する前に、リーダチップ１００は、チップカードの詳細や消費者金融機関を特定する情報やチップカードを発行したイシュアを特定する情報やアカウント番号やチップカードの有効期限や他の情報などの、チップカードからの支払いトランザクションを処理するのに必要な他の情報を集めてもよい。加えて、トランザクション処理インストラクション１３２は、顧客を特定する情報やトランザクション履歴や他の情報を含む、支払いデバイスを用いている顧客についての情報を決定するためのインストラクションを含んでもよい。ある実施の形態では、トランザクション処理インストラクション１３２は、電子支払い情報を要求するかそうでなければ支払いデバイス１０においてチャージを開始する前に、支払いデバイス１０から任意の適切な情報を収集するためのインストラクションを含んでもよい。
【００６３】
図４は、本開示のある実施の形態に係る、例示的マーチャントデバイス２９を示す。マーチャントデバイス２９は任意の適切な態様で実現されてもよいが、ある実施の形態では、マーチャントデバイス２９は、ユーザインタフェースを提供し、ひとつ以上の他のデバイスと通信する双方向電子デバイスであってもよい。双方向電子デバイスの例は、タブレット、スマートフォン、スマートウォッチ、デスクトップコンピュータ、ラップトップコンピュータ、カスタム電子デバイス、または本明細書で説明される機能を実行するために必要なユーザインタフェースおよび通信能力を有する任意の他の適切な電子デバイスを含む。
【００６４】
図４において特定のコンポーネントが特定の構成で描かれているが、マーチャントデバイス２９が追加のコンポーネントを含んでもよいこと、図４に示されるコンポーネントのうちのひとつ以上がマーチャントデバイス２９に含まれなくてもよいこと、およびマーチャントデバイス２９のコンポーネントが任意の適切な態様で再構成されうること、は理解されるであろう。ある実施の形態では、マーチャントデバイス２９は、処理ユニット２０２と、メモリ２０４と、インタフェースバス２０６と、電源２０８と、ユーザインタフェース２１０と、第１無線インタフェース２１２と、第２無線インタフェース２１４と、有線インタフェース２１６と、を含む。
【００６５】
ある実施の形態では、マーチャントデバイス２９は、マーチャントデバイス２９の必要動作を制御し行うよう構成された処理ユニット２０２およびメモリ２０４を含む。ある実施の形態では、処理ユニット２０２は、メモリ２０４に保持されてもよいインストラクションに基づいて、モバイルオペレーティングシステム、プログラムおよびアプリケーションのインストラクションを実行する汎用プロセッサであってもよい。メモリ２０４は本明細書で説明されるような任意の適切なメモリタイプまたはそれらの組み合わせを含んでもよく、これはインストラクションおよび他のデータを保持し、マーチャントデバイス２９のオペレーティングシステム、プログラムおよびアプリケーションの実行用のワーキングメモリを提供するためのものであり、例えばフラッシュメモリやＲＡＭメモリである。ある実施の形態では、メモリ２０４は、オペレーティングインストラクション２２０やポイントオブセールアプリケーションインストラクション２２２やＥＭＶオフラインインストラクション２２４やＥＭＶ／スワイプモードインストラクション２２６などのインストラクションの複数の集合を含んでもよい。
【００６６】
処理ユニット２０２は、メモリ２０４のインストラクションを実行することによって、マーチャントデバイス２９のひとつ以上の他のコンポーネントと相互作用し、それを制御してもよい。処理ユニット２０２はマーチャントデバイス２９の他のコンポーネントと任意の適切な態様で通信してもよいが、ある実施の形態では、処理ユニットはインタフェースバス２０６を用いてもよい。インタフェースバス２０６は、I2C、SPI、USB、UART、およびGPIOなどのひとつ以上の通信バスを含んでもよい。ある実施の形態では、処理ユニット２０２は、メモリのインストラクションを実行し、それらのインストラクションに基づいて、インタフェースバス２０６の通信バスを介してマーチャントデバイス２９の他のコンポーネントと通信してもよい。
【００６７】
マーチャントデバイス２９はまた電源２０８を含んでもよい。電源２０８は、ＡＣ電力を変換するための、および／または、マーチャントデバイス２９のコンポーネントによる使用のために複数のＤＣ電圧を生成するための、電力変換回路を含んでもよい。電源２０８が電池を含む場合、電池は物理的な電力接続を介して、または、誘導充電を介して、または、任意の他の適切な方法を介して、充電可能である。図４ではマーチャントデバイス２９の他のコンポーネントに物理的に接続されているようには描かれていないが、電源２０８はコンポーネントの要件にしたがって、マーチャントデバイス２９のコンポーネントに各種電圧を供給してもよい。
【００６８】
マーチャントデバイス２９はまたユーザインタフェース２１０を含んでもよい。ユーザインタフェース２１０は、マーチャントデバイス２９のユーザに、マーチャントデバイス２９で実行されているアプリケーションやプログラムと相互作用するための各種オプションを提供してもよい。例示的なユーザインタフェース２１０は、タッチスクリーンインタフェースや音声コマンドインタフェースやキーボードやマウスジェスチャ認識や任意の他の適切なユーザインタフェースやそれらの任意の組み合わせなどの任意の適切なユーザインタフェース用のハードウエアおよびソフトウエアを含んでもよい。ある実施の形態では、ユーザインタフェース２１０は、マーチャントデバイス２９で実行されているポイントオブセールアプリケーションなどのアプリケーションやプログラム用の双方向ユーザインタフェースを表示するタッチスクリーンインタフェースであってもよい。
【００６９】
マーチャントデバイス２９はまた複数の無線通信インタフェースを含んでもよい。無線通信インタフェースは、ブルートゥースクラシックやブルートゥースローエナジーやＷｉＦｉやセルラやショートメッセージサービス（ＳＭＳ）やＮＦＣや任意の他の適切な無線通信インタフェースやそれらの任意の組み合わせなどの無線通信インタフェースを提供するための任意の適切なハードウエアおよびソフトウエアを含んでもよい。ある実施の形態では、第１無線通信インタフェース２１２は主として支払いリーダ２２と通信する無線通信インタフェース（例えば、ブルートゥースローエナジーインタフェース）であってもよく、一方、第２無線通信インタフェース２１４は主として支払いサーバ４０の支払いサービスシステム５０と（例えばインターネットを介して）通信する無線通信インタフェース（例えば、ＷｉＦｉ）であってもよい。
【００７０】
マーチャントデバイスはまた有線インタフェース２１６を含んでもよく、有線インタフェース２１６は、ＵＳＢやライトニングやファイヤワイヤやイーサネットや任意の他の適切な有線通信インタフェースやそれらの任意の組み合わせなどの、他のデバイスや通信ネットワークとの有線通信のための任意の適切なインタフェースを含んでもよい。
【００７１】
オペレーティングインストラクション２２０は、内部通信や電力管理やＩ／Ｏデバイスの制御や通信デバイスの制御やマーチャントデバイス２９の他のハードウエアの制御や任意の他の適切なインストラクションやそれらの任意の組み合わせなどの、マーチャントデバイス２９の任意の適切な汎用動作を制御するためのインストラクションを含んでもよい。ある実施の形態では、オペレーティングインストラクションは、マーチャントデバイス２９で動作している大抵のドライバ、プログラムおよびアプリケーションと共にマーチャントデバイス２９のオペレーティングシステムにインストラクションを提供してもよい。
【００７２】
オペレーティングインストラクション２２０は、ユーザインタフェース２１０の動作を制御するためのインストラクションを含んでもよい。ユーザインタフェース２１０は、オペレーティングインストラクション２２０やポイントオブセールアプリケーションインストラクション２２２やＥＭＶオフラインインストラクション２２４やＥＭＶ／スワイプモードインストラクション２２６のプログラムおよびアプリケーションのインストラクションにしたがい制御されてもよい。ある実施の形態では、オペレーティングインストラクション２２０は、ＥＭＶオフラインモードまたはＥＭＶ／スワイプモードについての情報を表示するインストラクションを含んでもよい。オペレーティングインストラクション２２０はまた、支払いサーバ４０の支払いサービスシステム５０とのインタフェースとなり、かつ、支払いリーダ２２とのインタフェースとなるためのインストラクションを含んでもよい。支払いリーダ２２および／またはマーチャントデバイス２９で実行されているアプリケーションは支払いサービスシステム５０に（例えば、登録処理を介して）知られていてもよく、この場合、マーチャントデバイス２９はポイントオブセールアプリケーションインストラクション２２２にしたがって支払いサービスシステム５０と共に支払いを処理してもよい。
【００７３】
ポイントオブセールアプリケーションインストラクション２２２はマーチャントデバイス２９においてポイントオブセールアプリケーションを実行するためのインストラクションを含む。処理ユニット２０２によって実行されると、ポイントオブセールアプリケーションインストラクション２２２は、マーチャントが顧客との支払いトランザクションを処理することを可能とする、双方向インタフェースの豊かな表示を提供してもよい。これらのインストラクションは、マーチャントまたは顧客が、購入商品を選択することや、販売税を計算することや、チップを処理することや、レシートを提供することや、値引きや特別オファーを生成することや、顧客ロイヤリティプログラムを処理することや、アイテムの在庫検索やデリバリ検索をすることや任意の他の適切な小売りオペレーションを行うことを可能とするカスタマイズされたインタフェースを含んでもよい。ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、ＥＭＶオフラインモードまたはＥＭＶ／スワイプモードなどの至急処理モードに関する情報の豊かな表示を提供するためのインストラクションを含んでもよい。
【００７４】
ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、至急処理モードに入る要求を処理するためのインストラクションを含んでもよい。ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、例えばユーザインタフェース２１０を介して、至急処理モードに入る要求をユーザから受信してもよい。例示的な実施の形態では、通常の手順を用いた支払いトランザクションの処理を非現実的とするさまざまな条件が生じうる。例えば、支払い端末２０と支払いサーバ４０との間の接続が失われ、支払い端末２０が支払いサーバ４０と通信不能となる場合である。後述の通り、至急処理モードに入ることで、マーチャントデバイス２９は、支払い端末２０と支払いサーバ４０との間の接続が回復するまで、支払いトランザクションを処理し続けることができる。加えて、ピークトランザクション時間帯の間において、または大集団がマーチャントロケーションを訪問し、購入を行う顧客が長い列を経験するかあるいは支払いを提供してマーチャントの店舗を出るまで長い間待つような他の時間帯の間において、通常処理動作は非現実的であろう。マーチャントデバイス２９においてスワイプモードに入ることで、顧客は、磁気ストリップを伴う支払いデバイスをスワイプすることによりトランザクションを処理することを通じて利用可能な支払い情報の高速処理の利点を享有することができる。
【００７５】
ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、至急処理モードに入ることを要求する入力を、ユーザインタフェース２１０においてユーザから受け付けるためのインストラクションを含んでもよい。例えば、ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、至急処理モードに入る要求に応じてオプトイン要求を表示してもよい。ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、ユーザに、ユーザが至急処理モードを実行可能となる前に、オプトイン要求を受け入れることを要求してもよい。この点で、ユーザは、ポイントオブセールアプリケーションインストラクション２２２からのオプトイン要求を受け入れてもよいし、拒否してもよい。ユーザが要求を拒否する場合、ポイントオブセールアプリケーションインストラクション２２２は、至急処理モードに入ることなく、トランザクションを通常通りに処理してもよい。ユーザが受け入れる場合、ポイントオブセールアプリケーションインストラクション２２２は、ユーザに、ユーザがあるモードのオプトイン要求を受け入れた場合に、そのモード（例えば、ＥＭＶオフラインモードまたはスワイプモード）のステップで進めることを許可してもよい。
【００７６】
ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、至急処理モードに関するユーザインタフェースフレームワークおよび通知または開示を提供し表示するためのインストラクションを含んでもよい。例えば、ユーザは、支払いトランザクションが至急処理モードにしたがって行われることの通知を、オプトイン要求を受け入れた後に、受信してもよい。ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、支払いデバイス１０（例えば、チップカードやスワイプカード）のイシュアから支払いトランザクションを処理するために支払い端末２０を用いているマーチャントへの責任の転換などの、至急処理モードの一部として生じうる責任の転換の通知を、ユーザに、提供してもよい。他の実施の形態では、他の通知や開示が提供されてもよい。ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、開示が要求されるか適切である至急処理モードに関する任意の情報をユーザに提供してもよい。
【００７７】
ある実施の形態では、ポイントオブセールアプリケーションインストラクション２２２は、ユーザによるオプトイン要求の受け入れに応じて、マーチャントデバイス２９の処理要素２０２に種々の通知を提供するためのインストラクションを含んでもよい。ある実施の形態では、通知は、トランザクションが至急支払いプロトコルにしたがい至急処理モードで処理されている最中であることを示すものを含んでもよい。ある実施の形態では、処理ユニット２０２は通知に応じて、至急処理モードのステップを実行してもよい。ある実施の形態では、通知は、トランザクションがスワイプモードトランザクションとして処理される理由を示すものを含んでもよい。例えば、スワイプモードに入る要求が受信され、ユーザがオプトイン要求を受け入れたから、スワイプインタフェース１０５において磁気ストリップを読み取ることによって支払い情報が受信されるのであって、支払い端末２０におけるチップカードの読み取り失敗によりトランザクションを技術的後退トランザクションとして処理する（例えば、支払いリーダ２２がＥＭＶチップを読み取ることができないから、ユーザがチップカードをスワイプすることを可能とする場合）こととなったからではないことを、通知が表してもよい。他の実施の形態において、通知はユーザによるオプトイン要求の受け入れに応じて他の情報を提供してもよい。
【００７８】
ＥＭＶオフラインインストラクション２２４は、マーチャントデバイス２９においてＥＭＶオフラインモードに入り、ＥＭＶオフラインモードで支払いデバイス１０（例えば、チップカード）からの支払い情報を処理するためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、マーチャントデバイス２９に、種々のイベントに応じてＥＭＶオフラインモードに入らせてもよい。ＥＭＶオフラインインストラクション２２４に基づいて、マーチャントデバイス２９は、ユーザがユーザインタフェース２１０においてオプトイン要求を受け入れた場合、マーチャントデバイス２９の通信インタフェース（例えば、無線インタフェース２１４）がひとつ以上の支払いサーバと通信不能であると処理ユニット２０２が判定した場合、マーチャントデバイス２９と支払いサーバ４０との間の通信のレイテンシがしきい値を上回った場合、または他の事象や他の基準に応じて、ＥＶＭオフラインモードに入ってもよい。
【００７９】
ある実施の形態では、ＥＶＭオフラインインストラクション２２４は、ＥＭＶオフラインモードの一部として、チップカードからの電子支払い情報を処理するためのインストラクションを含んでもよい。ＥＶＭオフラインモードのステップは、Ｖｉｓａ（登録商標）ＱｕｉｃｋＣｈｉｐ  ｆｏｒ  ＥＭＶ（登録商標）を用いたトランザクション処理動作または他の同様の処理動作などの、チップカードからの電子支払い応答に応じて支払い承認を提供するための既存のＥＭＶ処理タスクの態様を含んでもよい。例えば、ある実施の形態では、ＥＶＭオフラインインストラクションは、至急処理モードの一部として、チップカードに電子支払い情報を要求し、それを受信してもよい。ＥＭＶオフラインインストラクション２２４は、処理ユニット２０２に、支払いリーダ２２のチップカードインタフェース１０４におけるチップカードからの電子支払い応答の要求を支払いリーダ２２に提供させてもよい。ある実施の形態では、電子支払い応答の要求は、ポイントオブセールアプリケーション２２２またはそれ以外において受信された第１支払い要求に応じて提供されてもよい。
【００８０】
ある実施の形態では、ＥＭＶオフラインインストラクション２２４は電子支払い応答を受信するためのインストラクションを含んでもよい。ある実施の形態では、電子支払い応答は、支払いリーダ２２の接触インタフェース１０４で挿入されているチップカードによって提供されてもよい。チップカードは、電子支払い応答の要求に応じてリスク管理を実行し、オフラインでトランザクションを承認することを拒否するかまたはオンライン認証要求に必要な情報を提供してもよい。ある実施の形態では、チップカードによって提供される情報は認証要求暗号（「ＡＲＱＣ」）または電子支払い要求のオンライン認証を実行するのに必要な他の同様な情報を含んでもよい。ある実施の形態では、支払いリーダ２２から電子支払い応答を受信するための他のステップが行われてもよい。
【００８１】
ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、支払いリーダ２２から受信された電子支払い応答に時刻インジケータまたはタイムスタンプを割り当てるためのインストラクションを含んでもよい。ＥＭＶオフラインインストラクション２２４は、電子支払い応答に、トランザクションに適用可能な種々のファクタや要件に依存するひとつ以上の時刻インジケータを関連付けるためのインストラクションを含んでもよい。例えば、後述の通り、ひとつ以上の支払いサーバにおける電子支払い応答の処理は、特定のトランザクションの時間帯内に入るために、電子支払い応答に関連付けられた時刻インジケータを要求してもよい。ある実施の形態では、時刻インジケータは、電子支払い応答の処理のために要求された際にチップカードが電子支払い応答を提供した時刻に対応してもよい（例えば、時刻インジケータは応答認証に要求されるハッシュまたはＡＲＱＣの一部である）。この点で、ある実施の形態では、電子支払い応答に二つ以上の時刻インジケータを関連付けてもよく、例えば、チップカードが電子支払い応答を提供した時刻とひとつ以上の支払いサーバが電子支払い応答を受信した時刻との間の時間がしきい値（例えば、レイテンシしきい値）を超える場合にそうである。ある実施の形態では、関連付けられた時刻インジケータは、将来の可能な限り早い時刻における、または予め予定された時刻における、支払いサーバへの送信を特定してもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、チップカードからの電子支払い応答に複数の時刻インジケータを割り当てるためのインストラクションを含んでもよい。この点で、複数の時刻インジケータのうちのひとつは、ひとつ以上の支払いサーバによって要求されるトランザクションの時間帯内の時刻にマッチしてもよい。ある実施の形態では、電子支払い応答に関連付けられた時刻インジケータは、マーチャントデバイス２９が、ＥＭＶオフラインインストラクション２２４に基づいてひとつ以上の支払いサーバに電子支払い応答を送信するための時刻をスケジュールすることを可能としてもよい。
【００８２】
ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、マーチャントデバイス２９のメモリ２０４に、支払いトランザクション情報をオフライントランザクションとして格納するためのインストラクションを含んでもよい。支払いトランザクション情報は、電子支払い応答と、ひとつ以上の関連する時刻インジケータまたは支払いタイプインジケータと、を含んでもよい。ある実施の形態では、支払いタイプインジケータは、チップカードなどの、電子支払い応答を提供した支払いデバイス１０についての情報を含んでもよい。ある実施の形態では、インジケータは、チップカードのイシュアからマーチャントへの責任の転換などの責任の転換が生じたか生じていないかのインジケータを含んでもよい。
【００８３】
ある実施の形態では、ＥＭＶオフラインインストラクション２２４は電子支払い応答に関連付けられたトランザクションを承認するためのインストラクションを含んでもよい。この承認は、マーチャントデバイス２９における通常動作中に実行されるＥＭＶ処理などの、マーチャントデバイス２９における標準のＥＭＶ処理ステップに基づいてもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、最初の電子支払い応答がマーチャントデバイス２９において受信されるという通知などの、オフライン承認として承認を提供するためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、承認に続いて、チップカードインタフェース１０４からのチップカードの除去を促すユーザのための通知を（例えばユーザインタフェースに）提供してもよい。ユーザは、トランザクションに関連付けられた情報、例えば電子支払い応答や他の情報、の送信が生じる前に、チップカードを取り除いてもよい。この点で、ユーザによって知覚される支払いトランザクション時間を減らすことができる。
【００８４】
ＥＭＶオフラインインストラクション２２４は、マーチャントデバイス２９において追加的な支払い要求が受信された場合、前述のステップを実行するためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、ユーザインタフェースにおいて、追加的な支払い要求に応じて追加的な電子支払い応答を要求し、メモリ２０４に追加的な電子支払い応答を格納し、追加的な電子支払い応答に関連付けられた追加的なトランザクションを承認するためのインストラクションを含んでもよい。マーチャントデバイス２９のユーザインタフェース２１０において受け付けられた支払い要求について必要な限り、これらのステップを繰り返してもよい。
【００８５】
ある実施の形態では、ＥＭＶオフラインインストラクション２２４はひとつ以上の支払いサーバに支払い承認要求を送信するためのインストラクションを含んでもよい。ある実施の形態では、支払い承認要求は、ひとつ以上の電子支払い応答と、各電子支払い応答についてそれに関連付けられた支払いタイプインジケータと、を含んでもよい。ある実施の形態では、支払いタイプインジケータはひとつ以上の支払いサーバに、ひとつ以上の電子支払い応答が至急支払いプロトコルにしたがう処理の対象であることを示してもよい。至急支払いプロトコル（例えば、Ｖｉｓａ  ｑｕｉｃｋチップ）の下では、トランザクションは、支払いサーバとチップカードとの間のさらなる通信なしに承認可能である。これにより、支払いプロセスの初期の段階でチップカードを取り除くことができる（例えば、電子支払い応答が送信された後、トランザクションの特定の段階、またはマーチャントデバイスによる予備的な承認の際）。加えて、支払い承認要求は、マーチャントへの責任の転換が生じたことのインジケータなどの、責任の転換についての情報を含むインジケータを含んでもよい。
【００８６】
ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、様々な時刻において、または、さまざまなイベントに応じて、支払い承認要求を送信するためのインストラクションを含んでもよい。例えば、ある実施の形態では、メモリにひとつ以上の電子支払い応答を格納した後、ＥＭＶオフラインインストラクション２２４は、ひとつ以上の支払い承認要求が送信可能であるとの判定に基づいてひとつ以上の支払いサーバにひとつ以上の支払い承認要求を送信するオプションを含んでもよい。ＥＭＶオフラインインストラクションは、支払い端末２０の通信インタフェース（例えば、マーチャントデバイス２９の無線インタフェース２１４）が利用可能であるとの判定に基づいて、ひとつ以上の支払い承認要求が送信可能であると判定してもよい。この点で、処理ユニット２０２は（ＥＭＶオフラインインストラクション２２４に基づいて）、任意の適切な態様で、通信インタフェースがひとつ以上の支払いサーバ（例えば、支払いサーバ４０）と通信可能であるか否かについてチェックしてもよい。これは例えば、通信インタフェースにおいて受信された伝送を監視することによって、または、通信インタフェースから送信されたメッセージに対する応答をひとつ以上の支払いサーバから受信することによって、なされる。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、マーチャントデバイス２９において第１電子支払い応答が受信された後に、そのチェックを実行するためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、支払い承認要求が送信可能であると判定することの一部として、支払い要求の頻度がしきい値より小さいと判定するためのインストラクションを含んでもよい。この点で、ＥＭＶオフラインインストラクション２２４は、ユーザインタフェース２１０において各支払い要求が受け付けられた時刻を記録し、要求の頻度を所定のしきい値と比較するためのインストラクションを含んでもよい。しきい値は、支払い端末２０と支払いサーバ４０との間の通信のレイテンシや他の同様の情報などの種々のファクタに基づいて、ときどき、更新されてもよい。
【００８７】
ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、通信インタフェースがひとつ以上の支払いサーバと通信可能である場合、ひとつ以上の支払い承認要求をひとつ以上の支払いサーバに転送するためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、例えば時刻インジケータが電子支払い応答に関連付けられたＡＲＱＣの一部でない場合、支払い承認要求に時刻インジケータを割り当ててもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、支払い承認要求に関連付けられた時刻インジケータによって示される時刻まで待機してからひとつ以上の支払いサーバに支払い承認要求を送信するためのインストラクションを含んでもよい。時刻インジケータによって示される時刻は、特定のまたは明示的な時刻、経過時間、または暫定時刻であってもよい。例えば、時刻インジケータによって示される時刻は、支払い端末２０と支払いサーバ４０との間の通信のレイテンシがしきい値を下回ったとの判定、または支払い要求の頻度がしきい値を下回ったとの判定に基づいてもよい。他の実施の形態において、時刻インジケータは他の情報を含んでもよい。
【００８８】
ＥＭＶオフラインインストラクション２２４は、関連付けられた時刻インジケータの時刻に対応する時刻に、支払い承認要求を転送するためのインストラクションを含んでもよい。時刻インジケータに対応する時刻は、支払い承認要求の送信が予定されている将来の時刻であってもよい。ある実施の形態では、複数の支払い承認要求はそれぞれ、同様の時刻に対応する関連時刻インジケータに関連付けられてもよい。この点で、ＥＭＶオフラインインストラクションは、時刻インジケータに関連付けられた時刻に対応する時刻において、複数の支払い承認要求を処理してもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、時刻インジケータの時刻に対応する時刻より前の時刻において、ひとつ以上の支払いサーバに、支払い承認要求およびそれに関連付けられた時刻インジケータを転送するためのインストラクションを含んでもよい。この点で、ひとつ以上の支払いサーバは、時刻インジケータの時刻に対応する時刻まで待機してから支払い承認要求を処理してもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、支払い承認要求を中間サーバに転送するためのインストラクションを含んでもよく、該中間サーバは、後の時刻に、支払い承認要求をひとつ以上の支払いサーバに転送してもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、所与の時刻において送信可能な全ての支払い承認要求をひとつ以上の支払いサーバに転送するためのインストラクションを含んでもよい。他の実施の形態において、ＥＭＶオフラインインストラクション２２４は、他の技術を用いて支払い承認要求を処理するためのインストラクションを含んでもよい。
【００８９】
ＥＭＶオフラインインストラクション２２４は、ひとつ以上の支払いサーバに送信された支払い承認要求に応じて支払い承認応答を受信するためのインストラクションを含んでもよい。ある実施の形態では、支払い承認応答はひとつ以上の支払い承認要求に関連付けられてもよく、例えばチップカードのイシュアによって、特定の支払いトランザクションが承認されたか拒否されたことを示してもよい。ある実施の形態では、ＥＭＶオフラインインストラクション２２４は、支払い承認応答によって示される支払い承認要求の最終的な承認または拒否についての通知をユーザインタフェース２１０に提供するためのインストラクションを含んでもよい。支払い承認応答は、ひとつ以上の支払いサーバに送信された各支払い承認要求について受信されてもよい。
【００９０】
以降、マーチャントデバイス２９がスワイプインタフェース１０５を備え、チップカードとの支払いトランザクションをスワイプモードで処理するよう構成されてもよい実施の形態を説明する。ある条件下で、支払い端末２０は、顧客がチップカードを用いた電子支払い情報の提供を試行する支払いトランザクションを処理することができないことがある。例えば、チップカードのＥＭＶチップの損傷、不適切な使用、支払い端末２０における様々なハードウエアおよびソフトウエア問題、または他の問題により、通常のＥＭＶ手順を用いた支払い情報の処理が妨げられることがある。支払いリーダ２２が通常のＥＭＶ処理を用いて支払い情報を読み取ることができない場合、ＥＭＶチップカードの処理は磁気ストリップを用いてなされてもよい。一般に、チップカードの磁気ストリップを用いてチップカードからの支払い情報を処理することを可能とする「後退（falling back）」用処理は「後退トランザクション」と称されてもよい。磁気ストリップを備えるがＥＭＶチップを備えないカードが関与するスワイプトランザクション中に、トランザクションが拒否された場合の不払いのリスクの責任は、カードのイシュアからスワイプトランザクションを受け入れたマーチャントへと転換される。しかしながら、技術後退トランザクション（例えば、支払い手順の技術的問題の結果として後退トランザクションが生じた場合）の一部としては責任の転換は生じないし、責任はカードのイシュアに残り続ける。チップカードが関与する支払いトランザクションがスワイプトランザクションとして処理されることを許可するようマーチャントがオプトインすることを許すために、カードのイシュアおよび種々の監督官庁は、不払いの責任がマーチャントに転換されることを要求してもよい。カードのイシュアからマーチャントへの責任の転換の要求を受け入れることで、マーチャントは支払い端末２０をスワイプモードで動作させることが許され、それにより、より高速な支払いトランザクション処理およびチェックアウト時間の低減を達成することができる。
【００９１】
ＥＭＶ／スワイプモードインストラクション２２６は、支払い端末２０にスワイプモードに入らせるためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、マーチャントデバイス２９においていつスワイプモードに入るかを決定するためのインストラクションを含んでもよい。例えば、マーチャントデバイス２９は、ユーザインタフェース２１０において受信されたスワイプモードに入る要求に応じて（例えば、ポイントオブセールアプリケーション２２２でのユーザ入力によって）、または、所定の基準（例えば、キューのサイズ、トランザクションの頻度など）がしきい値を満たすとの判定に応じて、スワイプモードに入ってもよい。ある実施の形態では、スワイプモードに入る要求は、ユーザインタフェース２１０における支払い情報の要求に応じて提供されてもよいし、支払い端末２０の例えば接触インタフェース１０４においてチップカードが検出されたときに提供されてもよい。
【００９２】
ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、支払いトランザクションがスワイプモードのステップを実行することにより進行することを許す前に、オプトイン要求を受け入れるかまたはカードのイシュアからマーチャントへの責任の転換を受け入れることをユーザに要求してもよい。ユーザがオプトイン要求の受け入れを拒否した場合、その要求が提供された対象の支払いトランザクションの処理は通常の処理動作にしたがって（例えば、チップカードが、磁気ストリップインタフェースではなくむしろチップカードインタフェースを通じて処理されることを要求する）継続されてもよい。オプトイン要求の受け入れにより、マーチャントデバイス２９は、支払いトランザクションをスワイプモードで処理するためのステップを実行することが許されてもよい。オプトイン要求は、そのオプトイン要求に併せてユーザに表示する任意の適切な情報、例えば、マーチャントへの責任の転換に関する通知や開示、または他の情報、を含んでもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、ユーザがユーザインタフェース２１０を介して要求を提供したときや、マーチャントが大量の顧客を経験しているとの判定（例えば、センサやカメラからの情報に基づいて）や、支払い端末における支払いトランザクション間の時間がしきい値時間を下回ったときや、顧客が支払い端末２０において支払いトランザクションを完了するのに遅延を経験しているかもしれないことを示す他のイベント、などの種々のイベントに応じて、オプトイン要求を提供するためのインストラクションを含んでもよい。
【００９３】
ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、スワイプモード動作の一部として、スワイプ支払いタイプの電子支払い情報を処理するためのインストラクションを含んでもよい。ユーザは、ユーザインタフェース２１０において、支払いトランザクション要求を提供してもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、ユーザインタフェース２１０における支払いトランザクション要求に応じて、スワイプインタフェース１０５を通じてスワイプされた支払いカード磁気ストリップから電子支払い情報を受信するためのインストラクションを含んでもよい。電子支払い情報は、カードのイシュア情報やカードおよびカード所有者特定情報などの、従来のスワイプ支払いトランザクションの一部として提供される情報を含んでもよい。
【００９４】
ＥＭＶ／スワイプモードインストラクション２２６は、インジケータを生成し、スワイプモード中に受信された電子支払い情報に関連付けるためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、スワイプモードに入る支払い端末に基づいてスワイプモードインジケータを生成してもよい。スワイプモードインジケータは、電子支払い情報が、スワイプ支払いタイプの処理用の手順にしたがって処理されることを許してもよい。加えて、スワイプモードインジケータは、トランザクションが技術後退トランザクションでないことを示してもよい。チップカードは技術後退がないなかでスワイプモードで動作しているので、インジケータは支払いサーバに、トランザクションが、マーチャントへの責任の転換を要求するスワイプトランザクションとして処理されるべきであることを知らせてもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、電子支払い情報を提供した支払いカードがチップカードであるとのインジケータを生成してもよい。支払いカードがチップカードであるとのインジケータは、マーチャントデバイス２９において受信される、支払いカードがチップカードであるとの通知を含む任意の適切な情報に基づいてもよい。他の実施の形態では、支払いカードがチップカードであるとのインジケータは他の情報に基づいてもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、スワイプモード中に支払い端末において受信された電子支払い情報に、スワイプモードインジケータおよび支払いカードがチップカードであるとのインジケータを、関連付けるためのインストラクションを含んでもよい。他の実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は他のインジケータを生成し、関連付けてもよい。
【００９５】
ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、チップカードではない支払いカードによって提供されるスワイプ支払いタイプの電子支払い情報と併せて、支払いトランザクションを処理するためのインストラクションを含んでもよい。この点で、ＥＭＶ／スワイプモードインストラクション２２６は、マーチャントデバイス２９に、支払いトランザクション要求とスワイプ支払いタイプの電子支払い情報とを支払いリーダ２２のスワイプインタフェース１０５から受信させてもよい。ＥＭＶ／スワイプモードインストラクション２２６は、マーチャントデバイス２９に、電子支払い情報を提供したカードはチップカードではないと判定させ、そのカードによって提供された電子支払い情報をスワイププロトコルにしたがって処理させてもよい。ある実施の形態では、スワイププロトコルは、従来の方法を用いて電子スワイプ支払い情報を処理するためのステップを含んでもよい（例えば、支払いリーダ１０５にスワイプ専用カードが提供された場合、マーチャントへの責任の転換は生じないであろう）。
【００９６】
ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、スワイプモードに入る要求が受け入れられた後（例えば、ある支払いトランザクションから別の支払いトランザクションへと）、支払いトランザクションの通常の処理を許すためのインストラクションを含んでもよい。例えば、マーチャントデバイス２９は、スワイプモードに入る要求を促した条件が取り除かれたかもはや存在しないと判定してもよい。ある実施の形態では、そのような判定は、マーチャントの敷地にいる顧客の数がしきい値を下回ったとの判定、または支払いトランザクション間の時間がそれまで下回っていたしきい値時間を超えたとの判定に基づいてもよい。この点で、マーチャントデバイス２９は、スワイプモードを出て、支払いトランザクションの通常処理の動作に戻ってもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、スワイプモードに入った後、通常の支払い処理を用いて接触インタフェース１０４におけるチップカードからの支払い情報を処理するためのインストラクションを含んでもよい。通常チップカード処理の要求はユーザインタフェース２１０から提供されてもよく、ＥＭＶ／スワイプモードインストラクション２２６は、チップカードからの電子支払い情報を通常の態様（例えば、接触インタフェース１０４におけるチップカードとの通信を通じて）で処理するためのインストラクションを含んでもよい。例えば、ＥＭＶ／スワイプモードインストラクション２２６は、マーチャントデバイス２９に、支払い情報を受信させ、その電子支払い情報をひとつ以上の支払いサーバに送信させてもよい。ＥＭＶ／スワイプモードインストラクション２２６は、それに応じて、支払い端末２０の通信インタフェース（例えば、無線インタフェース２１４）において支払い承認応答を受信してもよい。この点で、チップカードからの電子支払い情報の処理の一部として責任の転換が生じることはない（例えば、支払いトランザクション要求の責任はマーチャントに課されない）。
【００９７】
ＥＭＶ／スワイプモードインストラクション２２６は、例えば無線インタフェース２１４を介して、ひとつ以上の支払いサーバに、支払いトランザクション要求に関連付けられた電子支払い情報を送信するためのインストラクションを含んでもよい。電子支払い情報は、通常処理またはスワイプモードを実行することを介してマーチャントデバイス２９において受信されてもよく、スワイプモードインジケータおよび電子支払い情報を提供したカードがチップカードであるとのインジケータのうちのひとつ以上を含んでもよい。ＥＭＶ／スワイプモードインストラクション２２６は、ひとつ以上の支払いサーバに送信された電子支払い情報に関連付けられた支払い承認応答を受信するためのインストラクションを含んでもよい。したがって、例示的な実施の形態では、複数の電子支払い情報の伝送について、支払い端末２０の通信インタフェースにおいて（例えば、無線インタフェース２１４において）電子支払い情報に関連付けられた支払い承認応答が受信されてもよい。ある実施の形態では、支払い承認応答は、スワイプモードインジケータおよび電子支払い情報を提供したカードがチップカードであるとのインジケータのうちのひとつ以上に基づいてもよい。他の実施の形態では、支払い承認応答は他の情報に基づいてもよい。
【００９８】
ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、電子支払い情報のひとつ以上の支払いサーバへの送信がある遅延条件の間遅延すべきである場合のその遅延条件を特定するためのインストラクションを含んでもよい。その条件は、ひとつ以上の支払いサーバとの接続の喪失、大量のトランザクション、接続速度の低下、またはそれらの任意の組み合わせなどのイベントであってもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、遅延条件の特定に応じて、（例えば、メモリ２０４に）電子支払い情報を格納するためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション２２６は、マーチャントデバイス２９に、遅延条件を監視させ、遅延条件が解消すると、その遅延条件に応じて格納された電子支払い情報をひとつ以上の支払いサーバに送信させてもよい。ある実施の形態では、遅延条件は、（例えば、支払い端末２０における）支払いトランザクションの頻度がしきい値頻度を超えたとの判定であってもよい。ある実施の形態では、遅延条件は、支払い端末２０（例えば、マーチャントデバイス２９）とひとつ以上の支払いサーバとの間の接続速度を含んでもよい。ある実施の形態では、しきい値は、マーチャントの特定情報、マーチャントのタイプ、マーチャントの所在地、従業員の特定情報、顧客の特定情報、商品のタイプ、時刻、または他の情報を含む任意の適切な情報に基づいてもよい。ある実施の形態では、遅延条件の解消は、支払いトランザクションの頻度がしきい値を下回ることを含んでもよい。ある実施の形態では、遅延条件の解消は、接続速度がしきい値接続速度を超えることを含んでもよい。他の実施の形態では、遅延条件の解消は任意の適切な情報に基づいてもよい。
【００９９】
ある実施の形態では、ＥＭＶオフラインインストラクション２２４およびＥＭＶ／スワイプモードインストラクション２２６に基づいてマーチャントデバイス２９に割り当てられる能力は組み合わされてもよい。例えば、ＥＭＶオフラインインストラクション２２４に基づく至急処理モードを用いての支払いトランザクションの処理の期間がしきい値を超えたと判定されると、マーチャントデバイス２９はＥＭＶ／スワイプモードインストラクション２２６を実行することで、支払いトランザクション時間の低減を試行してもよい。その判定は、トランザクションについての任意の適切な情報、および、ＥＭＶオフラインインストラクション２２４にしたがう至急処理モードおよびＥＭＶ／スワイプインストラクション２２６にしたがうスワイプモードのうちのひとつ以上を用いて実行される支払いトランザクションの平均期間に基づいてもよい。そのような能力は、本明細書で説明される目的を達成するために任意の適切な構成で組み合わされてもよいことは理解されるであろう。
【０１００】
図５は、本開示のある実施の形態に係る、支払いサーバ４０の例示的な支払いサービスシステム５０を示す。支払いサービスシステム５０は単一のサーバとして描かれているが、支払いサービスシステム５０の動作およびメモリは任意の適切な数のサーバに分散していてもよいことは理解されるであろう。図５において特定のコンポーネントが特定の構成で描かれているが、支払いサービスシステム５０が追加のコンポーネントを含んでもよいこと、図５に示されるコンポーネントのうちのひとつ以上が支払いサービスシステム５０に含まれなくてもよいこと、および支払いサービスシステム５０のコンポーネントが任意の適切な態様で再構成されうること、は理解されるであろう。ある実施の形態では、支払いサービスシステム５０が本明細書で支払いサーバ４０に属する機能のいずれかを行うために必要なコンポーネントを含みかつ必要な構成を有してもよいことは理解されるであろう。ある実施の形態では、支払いサービスシステム５０は、少なくともひとつの処理ユニット３０２と、メモリ３０４と、インタフェースバス３０６と、電源３０８と、通信インタフェース３１０と、を含む。
【０１０１】
ある実施の形態では、支払いサービスシステム５０は、支払いサービスシステム５０の必要動作を制御し行うよう構成された処理ユニット３０２およびメモリ３０４を含む。ある実施の形態では、処理ユニット３０２は、メモリ３０４に保持されてもよいインストラクションに基づいて、サーバ用のオペレーティングシステム、プログラムおよびアプリケーションのインストラクションを実行する高速プロセッサであってもよい。メモリ３０４は本明細書で説明されるような任意の適切なメモリタイプまたはそれらの組み合わせを含んでもよく、これはインストラクションおよび他のデータを保持し、支払いサービスシステム５０のオペレーティングシステム、プログラムおよびアプリケーションの実行用のワーキングメモリを提供するためのものである。ある実施の形態では、メモリは、オペレーティングインストラクション３２０や支払い処理インストラクション３２２やＥＭＶオフラインインストラクション３２４やＥＭＶ／スワイプモードインストラクション３２６を含むがそれらに限定されないインストラクションの複数の集合を含んでもよい。
【０１０２】
処理ユニット３０２は、メモリ３０４のインストラクションを実行することによって、支払いサービスシステム５０のひとつ以上の他のコンポーネントと相互作用し、それを制御してもよい。処理ユニット３０２は支払いサービスシステム５０の他のコンポーネントと任意の適切な態様で通信してもよいが、ある実施の形態では、処理ユニット３０２はインタフェースバス３０６を用いてもよい。インタフェースバス３０６は、I2C、SPI、USB、UART、およびGPIOなどのひとつ以上の通信バスを含んでもよい。ある実施の形態では、処理ユニット３０２は、メモリ３０４のインストラクションを実行し、それらのインストラクションに基づいて、インタフェースバス３０６の通信バスを介して支払いサービスシステム５０の他のコンポーネントと通信してもよい。
【０１０３】
支払いサービスシステム５０はまた電源３０８を含んでもよい。電源３０８は、ＡＣ電力を変換するための、および／または、支払いサービスシステム５０のコンポーネントによる使用のために複数のＤＣ電圧を生成するための、電力変換回路を含んでもよい。ある実施の形態では、電源３０８は、停電時のサービス中断を避けるために電池バックアップなどのバックアップシステムを含んでもよい。図５では支払いサービスシステム５０の他のコンポーネントに物理的に接続されているようには描かれていないが、電源３０８はコンポーネントの要件にしたがって、支払いサービスシステム５０のコンポーネントに各種電圧を供給してもよい。
【０１０４】
支払いサービスシステム５０はまた通信インタフェース３１０を含んでもよい。通信インタフェース３１０は任意の適切な通信インタフェースまたはそれらの組み合わせを含んでもよいが、ある実施の形態では、通信インタフェース３１０はＷｉＦｉやセルラやイーサネットや光ファイバなどの高速通信インタフェースを用いてもよい。通信インタフェース３１０は、処理対象のトランザクションやファームウエア更新やアプリケーション更新などに関するメッセージを交換するために、支払い端末２０（例えば、マーチャントデバイス２９を介した支払いリーダ２２）とのセキュアな接続（例えば、ＴＬＳやＳＳＬを介して）を確立してもよい。通信インタフェース３１０はまた、支払いサーバなどの支払いサーバ４０の他のサーバと通信してもよく、それらはある実施の形態では、支払いサービスシステム５０から離れたところに配置されていてもよく、支払いサービスシステム５０を制御する主体とは異なる主体により運営されていてもよい。例えば、ある実施の形態では、支払いサービスシステム５０は支払いリーダ２２、マーチャントデバイス２９、またはポイントオブセールアプリケーション２２２のうちのひとつ以上を提供する主体によって運営されていてもよい。支払いサーバはマーチャント、イシュア、または顧客の銀行のうちのひとつ以上に関連付けられ、かつそれによって運営されていてもよい。
【０１０５】
メモリ３０４は、オペレーティングインストラクション３２０や支払いインストラクション３２２やＥＭＶオフラインインストラクション３２４やＥＭＶ／スワイプモードインストラクション３２６や支払いサービスシステム５０を動作させるための任意の他の適切なインストラクション（例えば、支払いサービスシステム５０のひとつ以上の他のアプリケーションやコンポーネントの動作に関するインストラクション）などの、支払いサービスシステム５０の処理動作を実行するためのインストラクションの複数の集合を含んでもよい。
【０１０６】
オペレーティングインストラクション３２０は、内部通信や電力管理や通信デバイスの制御や支払いサービスシステム５０の他のハードウエアの制御や任意の他の適切なインストラクションやそれらの任意の組み合わせなどの、支払いサービスシステム５０の任意の適切な汎用動作を制御するためのインストラクションを含んでもよい。ある実施の形態では、オペレーティングインストラクションは、支払いサービスシステム５０で動作している大抵のドライバ、プログラムおよびアプリケーションと共に支払いサービスシステム５０のオペレーティングシステムにインストラクションを提供してもよい。
【０１０７】
オペレーティングインストラクション３２０はまた、マーチャントデバイス２９とのインタフェースとなるためのインストラクションを含んでもよい。ある実施の形態では、支払いサービスシステム５０は通信インタフェース３１０を介してマーチャントデバイス２９と通信してもよい。オペレーティングインストラクション３２０は、処理ユニット３０２によって実行された場合、これらの通信を制御し、ＴＬＳやＳＳＬや鍵に基づき暗号化されたデータとしてなどの手順を実装することによってセキュアな通信を提供するインストラクションを含んでもよい。
【０１０８】
支払い処理インストラクション３２２は支払いを処理するためのインストラクションを含み、マーチャントデバイス２９、支払いリーダ２２（例えば、マーチャントデバイス２９を介して）、および／または支払いサーバに伝達されるメッセージの内容を制御してもよい。ある実施の形態では、支払い処理インストラクションは、支払いリーダ２２およびインストールされたポイントオブセールアプリケーション２２２を有するマーチャントデバイス２９のそれぞれについての情報を含んでもよい。量やクレジットカード番号などの支払い情報をトランザクション処理システムに提供し、マーチャントに応答を返すことなどの支払い処理機能を実行することに加えて、支払いサービスシステム５０はまた、マーチャントデータの複雑な解析を実行し、それを用いてマーチャント（例えば、複数の場所で複数のマーチャントデバイス２９を運用するマーチャント）にレポートやメトリックや他のデータを提供してもよい。支払い処理インストラクション３２２はまた、支払いデバイス１０、支払いリーダ２２またはマーチャントデバイス２９のうちのひとつ以上によって提供されるデータを暗号化および復号するための共有秘密鍵や公開鍵／秘密鍵ペアの鍵などの暗号化鍵にアクセスするためのインストラクションを含んでもよい。
【０１０９】
ＥＭＶオフラインインストラクション３２４は、支払い端末２０から受信したＥＭＶオフライン支払い承認要求を処理するためのインストラクションを含んでもよい。ＥＭＶオフラインインストラクション３２４は、支払い承認要求を処理するためのステップを実行する時刻を決定するためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶオフラインインストラクション３２４は、支払いサービスシステム５０に、支払い承認要求に関連付けられた時刻インジケータによって示される時刻に対応する時刻を決定させ、その時刻まで待ってから支払い承認要求の処理を開始させてもよい。ある実施の形態では、ＥＭＶオフラインインストラクション３２４は、支払い承認要求の時刻インジケータと、ＡＲＱＣや暗号化ハッシュなどの、電子支払い応答により示される時刻と、のマッチングを行うためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶオフラインインストラクション３２４は、電子支払い応答のＡＲＱＣまたは暗号化ハッシュによって時刻インジケータが指定されていない場合、任意に割り当てられた時刻に支払い承認要求を処理するためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶオフラインインストラクション３２４は、支払いサービスシステム５０に、支払いサービスシステム５０が支払い承認要求を受信するとすぐに、電子支払い応答に含まれる支払い情報を銀行サーバに承認のために提供させてもよく、または、支払い承認要求またはそれに関連付けられた電子支払い応答に関連付けられた時刻インジケータに対応する時刻まで待機してもよい。加えて、ＥＭＶオフラインインストラクション３２４は、支払いトランザクションの一部としての責任の転換の発生を示すインジケータを支払い承認要求に割り当てるためのインストラクションを含んでもよい。他の実施の形態では、ＥＭＶオフラインインストラクション３２４は、他の情報を支払い承認要求に割り当ててもよい。
【０１１０】
ある実施の形態では、ＥＭＶオフラインインストラクション３２４は、銀行サーバでの処理のための送信の時まで、支払いサービスシステム５０のメモリ３０４に、ひとつ以上の支払い承認要求を保持するためのインストラクションを含んでもよい。支払い承認要求は、支払いサービスシステム５０の通信インタフェース３１０において受信されたときや、支払い承認要求の時刻インジケータに関連付けられた時刻に対応する時刻や、支払いサービスシステム５０において受信された支払い承認要求の数がしきい値を超えたときや、他のとき、などの種々のときに、ひとつ以上の銀行サーバに送信されてもよい。ある実施の形態では、支払い承認要求の送信の時刻はユーザ入力または任意の他の適切な情報にしたがって決定されてもよい。
【０１１１】
ある実施の形態では、ＥＭＶオフラインインストラクション３２４は、支払いサービスシステム５０に、支払い承認応答を（例えば、銀行サーバから）受信させ、その応答を支払い端末２０に提供させてもよい。支払い承認応答は、対応する支払い承認要求に基づいてイシュアが支払いトランザクションを承認したかまたは拒否したかを示してもよい。ある実施の形態では、支払い承認応答は、支払い承認要求に関連付けられた支払いタイプインジケータに基づいてもよい（例えば、支払い承認応答はチップカードとの追加的な往復通信の必要性なしに提供されてもよい）。この点で、支払い承認応答は、支払い承認応答の結果の根拠（例えば、銀行サーバがなぜ関連支払い承認要求を承認または拒否したか）を示してもよい。
【０１１２】
ＥＭＶ／スワイプモードインストラクション３２６は、支払い端末２０から受信した電子支払い情報を処理するためのインストラクションを含んでもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション３２６は、電子支払い情報が、随伴するスワイプモードインジケータおよび電子支払い情報を提供したカードがチップカードであるとのインジケータと一緒に提供されたと判定するためのインストラクションを含んでもよい。ＥＭＶ／スワイプモードインストラクション３２６は、支払いサービスシステム５０に、支払い情報およびインジケータに基づいて、支払いトランザクションがスワイプモードトランザクションとして完了したと判定させてもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション３２６は、支払いサービスシステム５０に、インジケータを変更させるか該インジケータを電子支払い情報に割り当てさせ、該電子支払い情報をひとつ以上のサーバ（例えば、銀行サーバ）に承認のために送信させてもよい。ある実施の形態では、ＥＭＶ／スワイプモードインストラクション３２６は、支払い端末２０から複数の電子支払い情報を受信し、ひとつ以上のサーバへの送信用にその複数の電子支払い情報を格納するためのインストラクションを含んでもよい。ＥＭＶ／スワイプモードインストラクション３２６はさらに、複数の電子支払い情報をひとつ以上のサーバに承認のために送信するためのインストラクションを含んでもよい。
【０１１３】
ある実施の形態では、ＥＭＶ／スワイプモードインストラクション３２６は、電子支払い情報に対する支払い承認応答を受信し、その支払い承認応答を支払い端末２０に送信するためのインストラクションを含んでもよい。ある実施の形態では、支払い承認応答は、支払いトランザクションがカードのイシュアによって許容されたか拒否されたかを示してもよい。ある実施の形態では、支払い承認応答は、スワイプモードインジケータおよび電子支払い情報を提供したカードがチップカードであるとのインジケータのうちのひとつ以上に基づいてもよい。ある実施の形態では、インジケータは、チップカードがスワイプ支払いタイプの電子支払い情報を提供したことをひとつ以上の支払いサーバに示す情報を含んでもよい。この点で、インジケータは、ひとつ以上のサーバが、技術的後退が生じたわけではなく、マーチャントがオプトイン要求を受け入れ、したがって支払い要求の責任がマーチャントに転換されたと判定することを可能としてもよい。ある実施の形態では、インジケータは、電子スワイプ支払い情報を提供した支払いカードはチップカードからのものではなかったのであって、支払い要求の責任は銀行やイシュアに残ったままであることを示してもよい。ＥＭＶ／スワイプモードインストラクション３２６は、支払い承認応答を受信し、それを支払い端末２０に送信するためのインストラクションを含んでもよい。ある実施の形態では、支払いサービスシステムは、ＥＭＶ／スワイプモードインストラクション３２６に基づいて、支払いサービスシステム５０において受信された複数の電子支払い情報のそれぞれについて、処理を繰り返してもよい。
【０１１４】
上述の構成およびデバイスに照らし、開示される主題にしたがい実装されうる方法は、図６-８のフローチャートを参照することでより良く理解されるであろう。説明の簡単化を目的として、方法が一連のステップとして示され説明されるが、そのような図示または対応する説明はステップの順番に限定されるものではなく、いくつかのステップが本明細書で図示され説明されるものとは異なる順番でおよび／または他のステップと同時に生じうることは理解され認識されるべきである。フローチャートを介して図示される任意のシーケンシャルでないまたは枝分かれのフローは、同じまたは同様の結果を達成する種々の他の枝分かれやフローパスやステップの順番が実装可能であることを示すものとして理解されるべきである。さらに、以下に説明される方法を実装するために、図示される全てのステップが要求されるわけではない場合がある。
【０１１５】
図６は、本開示のある実施の形態に係る、電子支払いトランザクションの至急処理の例示的方法を説明する。ある実施の形態では、図６に示されるように、電子支払いトランザクションの至急処理の方法は、支払い端末２０デバイスによって実行されてもよい（例えば、図６の例示的な実施の形態で説明されるように、支払いリーダ２２とマーチャントデバイス２９との組み合わせ）。ある実施の形態では、これらのステップは特定のデバイスによって行われるように描かれているが、デバイス間でのステップの割り当てが任意の適切な態様で変更されてもよいことや、ステップを行うデバイスの数が任意の適切な態様で変更されてもよいことは、理解されるであろう。
【０１１６】
ステップ６０２において、至急処理モードのステップにしたがってマーチャントデバイス２９および支払いリーダ２２において支払いトランザクションを処理するために、至急処理モードに入る要求が、マーチャントデバイス２９のユーザインタフェース２１０において受け付けられてもよい。ある実施の形態では、要求は、ユーザインタフェース２１０に表示されるポイントオブセールアプリケーションインストラクション２２２を介したユーザからの入力として受け付けられてもよい。ある実施の形態では、支払いトランザクションが開始するとき（例えば、ユーザがポイントオブセールアプリケーションインストラクション２２２を開くとき、支払いデバイス１０が検出されたとき、顧客が支払いリーダ２２において入力を提供するとき、またはそれらの任意の組み合わせ）、要求はユーザインタフェース２１０を介してユーザに表示されるメッセージに応じて生成されてもよい。ある実施の形態では、マーチャントデバイス２９がひとつ以上の支払いサーバと通信不能であるとの判定に応じて、またはトランザクション頻度やキューのサイズなどの他の基準に基づいて、要求が自動的に生成されてもよい。至急処理モードに入る要求が受け付けられた後、処理はステップ６０４に続いてもよい。
【０１１７】
ステップ６０４で、ステップ６０２で至急処理モードに入る要求が受け付けられたことに応じて、マーチャントデバイス２９のユーザインタフェース２１０にオプトイン要求を提供してもよい。ある実施の形態では、オプトイン要求は、ユーザインタフェース２１０においてユーザに対してグラフィカルなメッセージとして表示されてもよく、ユーザがオプトイン要求を受け入れるか否かを示す入力を提供するためにユーザが選択可能なＧＵＩ要素を含んでもよい。ある実施の形態では、オプトイン要求は、マーチャントが至急処理モードに入った場合には所定のトランザクション（例えば、チップカードトランザクション）についてマーチャントへの責任の転換が要求される旨を示す情報などの、オプトイン要求を受け入れるか拒否することの結果に関する開示または通知を含んでもよい。オプトイン要求がユーザインタフェース２１０に提供されてしまった後、処理はステップ６０６に続いてもよい。
【０１１８】
ステップ６０６で、マーチャントデバイス２９はオプトイン要求が受け入れられたか否かを判定してもよい。その判定は、ステップ６０４からの入力に基づいてなされてもよい。ある実施の形態では、ユーザは、ユーザがオプトイン要求を受け入れた場合に限り、至急処理モードのステップの実行を許されてもよい。ある実施の形態では、ユーザがオプトイン要求を拒否した場合、処理はステップ６０７に続いてもよく、そこでは、マーチャントデバイス２９および支払いリーダ２２における支払いトランザクションの処理は、通常トランザクション処理モードのステップにしたがって（例えば、通常チップカード処理手順にしたがって）続いてもよい。ユーザがオプトイン要求を受け入れた場合、処理はステップ６０８へと進んでもよい。
【０１１９】
ステップ６０８で、マーチャントデバイス２９は、至急処理モードに入り、図６に示される残りのステップを実行してもよい。ステップ６１０で、第１支払い要求情報がマーチャントデバイス２９のユーザインタフェース２１０において受け付けられてもよい。支払い要求は、マーチャントおよび顧客のトランザクション遂行の進捗に基づく、ポイントオブセールアプリケーション２２２を介したマーチャントからの入力として提供されてもよい。顧客は次いで、例えばユーザインタフェースまたはマーチャントにより提供される指示により、支払いリーダ２２にチップカードを挿入するよう促されてもよい。支払い要求情報が受信された後、処理はステップ６１１に続いてもよい。
【０１２０】
ステップ６１１において、マーチャントデバイス２９は、挿入されたチップカードからの電子支払い応答の電子要求を、支払いリーダ２２に、提供してもよい。チップカードは、電子支払い応答の要求に応じてリスク管理を実行し、オフラインでトランザクションを承認する（例えば、チップカードに保持されるオフライン支払い限度に基づくものであって、この場合、責任の転換を伴ってトランザクションを処理する必要はない）か、または、オフライン承認が利用可能でない場合、至急支払いプロトコルにしたがいオンライン認証要求に必要とされる情報を含む電子支払い応答を提供してもよい。ある実施の形態では、支払い応答は、認証要求暗号または電子支払い要求のオンライン認証を実行するのに必要な他の同様な情報を含んでもよい。電子支払い応答の要求がチップカードに提供され、チップカードが関連する電子支払い応答を提供した後、処理はステップ６１２に続いてもよい。
【０１２１】
ステップ６１２において、マーチャントデバイス２９は、チップカードから受信した電子支払い応答を、マーチャントデバイス２９のメモリ（例えば、マーチャントデバイス２９のメモリ２０４）に格納してもよい。ある実施の形態では、電子支払い応答の複数の要求に関連付けられた複数の電子支払い応答が任意の所与の時刻に格納されてもよい。例えば、マーチャントデバイス２９における第１要求に関連付けられた第１電子支払い応答の受信に続き、マーチャントデバイス２９は追加的な電子支払い応答を要求してもよく、追加的な要求に関連付けられた追加的な応答が受信されて、マーチャントデバイス２９に格納されてもよい。この点で、複数の電子支払い応答が受信されて、バッチとして、ひとつずつ、またはそれらの任意の組み合わせとして、格納されてもよい。電子支払い応答がマーチャントデバイス２９のメモリに格納された後、処理はステップ６１４に続いてもよい。
【０１２２】
ステップ６１４で、マーチャントデバイス２９は、支払いトランザクションについての電子支払い応答が提供された場合のその支払いトランザクションの承認を提供してもよい。この承認は、マーチャントデバイス２９における通常動作中に実行されるＥＭＶ処理などの、マーチャントデバイス２９における標準のＥＭＶ処理ステップに基づいてもよい。図６に示される実施の形態では、マーチャントデバイス２９は、承認を、電子支払い応答を支払いサーバに伝達することを伴わないオフライン承認として提供してもよい。ある実施の形態では、マーチャントデバイス２９は、承認に続いて、チップカードインタフェース１０４からのチップカードの除去を促すユーザのための通知を（例えばユーザインタフェースに）提供してもよい。ユーザは、トランザクションに関連付けられた情報、例えば電子支払い応答や他の情報、の送信が生じる前に、チップカードを取り除いてもよい。トランザクションの承認が提供された後、処理はステップ６１６に続いてもよい。
【０１２３】
他の実施の形態では、図６には描かれていないが、マーチャントデバイスは、支払いサーバとの接続速度や支払いサーバの平均応答時間や現在のトランザクションの経過時間やトランザクション量やトランザクションの完了にかかると予想される時間などのパラメータを監視することで、オフライン承認を提供するか、または承認を取得するために支払いサーバと通信するか（例えば、標準支払いプロトコルを用いるかまたは至急支払いプロトコルを用いるか）を判定してもよい。ある実施の形態では、オフラインで承認されないトランザクションは、マーチャントへの責任の転換が要求されない態様で処理されてもよく、この場合、例えば、支払いサーバから応答が受信されるまでトランザクションは承認されない。しかしながら、遅延がトランザクションを遅らせる蓋然性が低く、また、マーチャントや顧客に不快感を与える蓋然性が低い場合にこれらのオンライントランザクションが要求されるように、条件が較正されてもよい。したがって、適切な条件の下では、トランザクションのうちのいくつかのみが責任の転換を伴って処理されてもよい。
【０１２４】
図６のステップに戻り、ステップ６１６で、マーチャントデバイス２９は、電子支払い応答の要求に応じて受信された電子支払い応答のそれぞれに、ひとつ以上のインジケータを、関連付けてもよい。ある実施の形態では、ひとつ以上のインジケータは、支払いタイプインジケータを含んでもよい。支払いタイプインジケータはひとつ以上の支払いサーバに、ひとつ以上の電子支払い応答が至急支払いプロトコルにしたがう処理の対象であることを示してもよい。至急支払いプロトコルにしたがって、トランザクションは、チップカードとの追加的な通信を必要とすることなく、支払いサーバによって承認されるか拒否されてもよい。これにより、トランザクションの初期段階でチップカードを取り除くことが可能となり、また、電子支払い応答を、支払いサーバへの後の送信のために支払いリーダまたはマーチャントデバイスに格納することが可能となる。
【０１２５】
ある実施の形態では、ひとつ以上のインジケータは、支払い承認要求に関連付けられた時刻インジケータを含んでもよい。ある実施の形態では、時刻インジケータは、各支払い承認要求に関連付けられてもよく、将来トランザクション時刻に対応してもよい。ひとつ以上のインジケータが各電子支払い応答に関連付けられた後、処理はステップ６１８に続いてもよい。
【０１２６】
ステップ６１８で、マーチャントデバイス２９は、ひとつ以上の支払いサーバに支払い承認要求を送信するか否かを決定してもよい。ある実施の形態では、この決定は、マーチャントデバイス２９の通信インタフェース（例えば、無線インタフェース２１４）がひとつ以上の支払いサーバと通信可能であるか否かを判定するための、マーチャントデバイス２９が実行してもよいチェックに基づいてもよいし、または通信速度や平均トランザクション処理時間などの他のパラメータに基づいてもよい。通信インタフェース２１４がひとつ以上の支払いサーバと通信不能である場合、または、予測トランザクション時間がしきい値を超える場合、マーチャントデバイス２９は、支払い承認要求をまだ送信すべきではないと判定してもよく、処理はステップ６２４に続いてもよい。通信インタフェース２１４がひとつ以上の支払いサーバと通信可能である場合、マーチャントデバイス２９は、支払い承認要求を送信可能であると判定してもよく、処理はステップ６２０に続いてもよい。
【０１２７】
ステップ６２０で、マーチャントデバイス２９は、ひとつ以上の支払いサーバに、ひとつ以上の支払い承認要求およびそれに関連付けられたひとつ以上のインジケータを送信してもよい。ある実施の形態では、マーチャントデバイス２９は、それが支払い承認要求をいつ送信可能となるかを、その要求に関連付けられた時刻インジケータに基づいて判定してもよい。ある実施の形態では、マーチャントデバイス２９において追加的な電子支払い応答が受信される前に、第１支払い承認要求が送信されてもよい。ある実施の形態では、各支払い承認要求は、それに関連付けられた時刻インジケータの時刻に対応する時刻に送信されてもよい。ある実施の形態では、マーチャントデバイス２９は、時刻インジケータが将来の時刻に対応する場合、時刻インジケータの時刻よりも前に、支払い承認要求およびインジケータを送信してもよい。この点で、時刻インジケータは、ひとつ以上の支払いサーバが、時刻インジケータの時刻に対応する時刻まで待機してから支払い承認要求を処理すべきであることを示してもよい。そのような実施の形態では、支払いサービスシステムは、時刻インジケータの時刻に、要求を、支払いサーバのうちの銀行サーバまたはイシュアサーバに転送してもよい。マーチャントデバイス２９がひとつ以上の支払い承認要求を送信した後、処理はステップ６２２に続いてもよい。
【０１２８】
ステップ６２２で、マーチャントデバイス２９は、ひとつ以上の支払い承認要求を送信することに応じて、ひとつ以上の支払いサーバから、ひとつ以上の支払い承認応答を受信してもよい。ある実施の形態では、マーチャントデバイス２９は、通信インタフェース（例えば、無線インタフェース２１４）を介して、各支払い承認応答を受信してもよい。ある実施の形態では、各支払い承認応答は、マーチャントデバイス２９から送信された各支払い承認要求に関連付けられてもよい。マーチャントデバイスは、次いで、例えば承認および拒否の記録を格納し、（例えば、責任の転換に続くトランザクションの拒否の）通知を提供することによって、受信された支払い承認応答を処理してもよい。
【０１２９】
上述の通り、マーチャントデバイス２９が承認要求を送信できない場合、処理はステップ６２４に続いてもよい。ステップ６２４で、マーチャントデバイス２９は、例えばマーチャントデバイス２９のユーザインタフェース２１０において、追加的な支払い要求が受け付けられたか否かを判定してもよい。ユーザは、それぞれが一意の支払い要求に関連付けられた複数の後続支払いトランザクションを行ってもよい。追加的な支払い要求が受け付けられた場合、処理はステップ６１０に戻ってもよく、ステップ６１０から６１８までが繰り返されてもよい。追加的な支払い要求が受け付けられなかった場合、処理はステップ６１８に戻ってもよく、そこで承認要求が送信可能か否かを判定する。追加的な支払いが要求されるか、または、既存のトランザクションが承認のために支払いサーバに送信されるまで、処理はこれらの二つの状態の間を（例えば、一定の間隔で）行き来し続けてもよい。
【０１３０】
図７は、本開示のある実施の形態に係る、電子支払いトランザクションの至急処理の例示的ステップを示す非限定的なラダー図を示す。ある実施の形態では、図７に示されるように、電子支払いトランザクションの至急処理の方法は、支払い端末２０デバイス（例えば、支払いリーダ２２とマーチャントデバイス２９との組み合わせ）と、支払いサービスシステム５０と、銀行サーバ６０と、によって実行されてもよい。ある実施の形態では、これらのステップは特定のデバイスによって行われるように描かれているが、デバイス間でのステップの割り当てが任意の適切な態様で変更されてもよいことや、ステップを行うデバイスの数が任意の適切な態様で変更されてもよいことは、理解されるであろう。
【０１３１】
ステップ７０２で、マーチャントデバイス２９は、支払い要求に応じて、チップカード１０に対する第１電子支払い応答の要求を提供する。本明細書で説明されるように、支払い要求は、ユーザインタフェース２１０またはマーチャントデバイス２９を介して提供されてもよく、チップカード１０は支払いリーダ２２の接触インタフェース１０４に挿入されてもよい。支払い要求は支払額または他の適切な情報を含んでもよい。支払いリーダ２２が支払い要求を受信した後、処理はステップ７０４に続いてもよい。
【０１３２】
ステップ７０４で、支払いリーダ２２はチップカード１０に電子支払い応答を要求してもよく、ステップ７０６で、チップカードは電子支払い応答を提供する。本明細書で説明されるように、電子支払い応答は、チップカード１０がトランザクションの承認を提供するのを拒否したことを示してもよい。ある実施の形態では、チップカード１０はトランザクションを承認し、電子支払い情報（例えば、ＡＲＱＣ）を提供してもよい。ステップ７０８で、支払いリーダ２２は、電子支払い情報をマーチャントデバイス２９に転送してもよい。支払いリーダ２２が電子支払い応答をチップカード１０からマーチャントデバイス２９へ転送した後、処理はステップ７０９に続いてもよい。
【０１３３】
ステップ７０９で、マーチャントデバイス２９は支払いリーダ２２に、支払いトランザクションについての電子支払い応答が提供された場合のその支払いトランザクションの承認を提供してもよい。本明細書で説明されるように、承認はマーチャントデバイス２９における標準のＥＭＶ処理ステップに基づいてもよいし、または、電子支払い応答を支払いサーバに伝達することなしのオフライン認証としてであってもよい。ステップ７１０で、支払いリーダ２２は、チップカードへのトランザクションの承認を示すチップカード１０へのトランザクションの承認を提供してもよい。上述の通り、マーチャントデバイスは、チップカード１０を取り除いてもよいことの通知をユーザに提供してもよい。
【０１３４】
至急処理モードの一部としてのマーチャントデバイス２９および支払いリーダ２２によって実行される例示的なステップは線７１１を参照して特定されてもよい。例示的な実施の形態において至急処理モードを含むステップは、図７の線７１１の左側に描かれているように、支払いサービスシステム５０や銀行サーバ６０と通信することなく、マーチャントデバイス２９および支払いリーダ２２によって実行可能である。トランザクションの至急処理の承認を完了するために後に生じうるステップは、線７１１の右側に実線で描かれている（例えば、ステップ７１２、７１４、７１６および７１８）。通常動作モードでは支払いカードとの通信は支払いサービスシステム５０および銀行サーバ６０との通信の後にも継続するが、この通常動作モードで実行されるステップは、線７１１の右側に描かれており、破線で示されている（例えば、ステップ７２０、７２２、７２４、７２６、７２８および７３０）。これらのステップは至急処理モードではスキップされ、その結果、チップカードはステップ７１０の後、取り除くことができるようになる。
【０１３５】
ステップ７１２で、マーチャントデバイス２９は、支払いサービスシステム５０に、ひとつ以上の支払い承認要求を提供してもよい。本明細書で上述されたように、支払い承認要求のそれぞれは、ひとつ以上の電子支払い応答と、それぞれについてそれに関連付けられた支払いタイプインジケータと、を含んでもよい。ある実施の形態では、例えば支払い処理の頻度がしきい値を下回った場合や、接続速度がしきい値を超えた場合、複数の支払い承認要求をバッチで送信してもよい。ある実施の形態では、上述の通り、各支払い承認要求はまた、トランザクション時刻（例えば、将来の時刻）に対応し、かつ、送信時刻を示してもよい時刻インジケータを含んでもよい。ステップ７１４で、支払いサービスシステム５０は、それが受信するひとつ以上の支払い承認要求のそれぞれを、承認のために銀行サーバ６０に転送してもよい。本明細書で触れられた通り、ひとつ以上の支払い承認要求のそれぞれは、時刻インジケータの時刻に対応する時刻に送信されてもよい。ある実施の形態では、支払いサービスシステム５０は、時刻インジケータの時刻まで待機してから支払い承認要求を送信してもよい
【０１３６】
ステップ７１６で、支払いサービスシステム５０は、支払いサービスシステム５０の通信インタフェースにおいて、銀行サーバ６０によって提供されるひとつ以上の支払い承認応答を受信してもよい。ある実施の形態では、支払い承認応答のそれぞれは、ステップ７１４で承認のために銀行サーバ６０に対して提供されたひとつ以上の支払い承認要求のうちのひとつに対応してもよい。支払いサービスシステム５０が銀行サーバ６０から支払い承認応答を受信した後、処理はステップ７１８に続いてもよい。
【０１３７】
ステップ７１８で、支払いサービスシステム５０は、ステップ７１６で受信したひとつ以上の支払い承認応答を、マーチャントデバイス２９に、提供してもよい。本明細書で説明される通り、各承認応答は、支払いトランザクションの一部として取得された特定の支払い承認要求に対応してもよい。この点で、マーチャントデバイス２９は、特定の支払いトランザクションが対応する各銀行サーバ６０によって承認されたか拒否されたかの確認を受信してもよい。支払い承認応答がステップ８１８で受信された後、処理はステップ７２０に続いてもよい。
【０１３８】
上述の通り、ステップ７２０、７２２、７２４、７２６、７２８および７３０は、至急処理が発生していない通常動作モードの間に実行されてもよい。したがって、ステップ７２０から７３０は、マーチャントデバイス２９および支払いリーダ２２が本明細書で説明される至急処理モードのステップを実行する実施の形態では生じないであろう。しかしながら、マーチャントデバイス２９および支払いリーダ２２が至急処理モードで動作していない場合、マーチャントデバイス２９はステップ７２０で支払いリーダ２２に支払い承認応答を提供し、支払いリーダ２２は支払い承認応答をステップ７２２でチップカード１０に転送してもよい。チップカード１０が支払い承認応答を受信した場合、それはステップ７２４で支払いリーダ２２に受信メッセージを提供してもよい。ある実施の形態では、受信メッセージは、チップカード１０が支払い承認応答を受信したことの確認を示すものであってもよい。ステップ７２６で、支払いリーダ２２は、チップカードから受信した受信メッセージをマーチャントデバイス２９に送信する。マーチャントデバイス２９がひとつ以上のチップカード１０からひとつ以上の受信メッセージを受信すると、処理はステップ７２８に進んでもよい。
【０１３９】
ステップ７２８で、マーチャントデバイス２９は、チップカード１０からのひとつ以上の受信メッセージを、支払いサービスシステム５０に送信してもよい。本明細書で説明されるように、マーチャントデバイス２９は、時刻インジケータなどのひとつ以上の関連インジケータにしたがって、受信メッセージを送信してもよい。支払いサービスシステム５０は、ステップ７３０で、受信メッセージを、対応する銀行サーバ６０に送信してもよい。その後、処理は終わってもよい。
【０１４０】
図８は、本開示のある実施の形態に係る、複数のインタフェースを通じて電子支払い情報を選択的に処理するための例示的ステップを説明する非限定的フロー図を示す。任意の適切なデバイスが電子支払い情報を処理してもよいことは理解されるであろうが、例示的な実施の形態では、トランザクションは、マーチャントデバイス２９および支払いリーダ２２を含む支払い端末によって完了されてもよい。
【０１４１】
ステップ８０２で、スワイプモードのステップにしたがって用いてチップカード支払いトランザクションを処理する要求はマーチャントデバイス２９のユーザインタフェース２１０において受信されてもよい。ある実施の形態では、要求は、ユーザインタフェース２１０に表示されるポイントオブセールアプリケーションインストラクション２２２を介したユーザからの入力として受け付けられてもよい。ある実施の形態では、支払いトランザクションが開始するとき（例えば、ユーザがポイントオブセールアプリケーションインストラクション２２２を開くとき、支払いデバイス１０が検出されたとき、顧客が支払いリーダ２２において入力を提供するとき、またはそれらの任意の組み合わせ）、要求はユーザインタフェース２１０を介してユーザに表示されるメッセージに応じて生成されてもよい。ある実施の形態では、チップカードが支払い端末２０に挿入されたとの判定に応じて、トランザクションの頻度に基づいて、キューのサイズに基づいて、または他の同様のファクタに基づいて、自動的に要求を生成してもよい。スワイプモードに入る要求が受け付けられた後、処理はステップ８０４に続いてもよい。
【０１４２】
ステップ８０４で、ステップ８０２でスワイプモードに入る要求が受け付けられたことに応じて、マーチャントデバイス２９のユーザインタフェース２１０にオプトイン要求を提供してもよい。ある実施の形態では、オプトイン要求は、ユーザインタフェース２１０においてユーザに対してグラフィカルなメッセージとして表示されてもよく、ユーザがオプトイン要求を受け入れるか否かを示す入力を提供するためにユーザが選択可能なインジケータを含んでもよい。ある実施の形態では、オプトイン要求は、オプトイン要求（例えば、カードのイシュアからマーチャントへの責任の転換）を受け入れるか拒否することの結果に関する開示または通知を含んでもよく、カードのイシュアやマーチャントや監督官庁やそれらの任意の組み合わせからの情報を含んでもよい。オプトイン要求がユーザインタフェース２１０に提供されてしまった後、処理はステップ８０６に続いてもよい。
【０１４３】
ステップ８０６で、マーチャントデバイス２９は、ユーザがステップ８０４で提供されたオプトイン要求を受け入れたか否かを判定してもよい。その判定は、ステップ８０４からの入力に基づいてなされてもよい。ある実施の形態では、ユーザは、ユーザがオプトイン要求を受け入れた場合に限り、スワイプモードのステップの実行を許されてもよい。ある実施の形態では、ユーザがオプトイン要求を拒否した場合、処理はステップ８０７に続いてもよく、そこでは、支払い端末２０における支払いトランザクションの処理は、通常動作モードのステップにしたがって（例えば、技術的後退状況などの特別な状況の下を除いて、チップカードが支払いリーダ２２のチップカードインタフェースに挿入されることを要求すること）続いてもよいユーザがオプトイン要求を受け入れた場合、処理はステップ８０８へと進んでもよい。
【０１４４】
ステップ８０８で、マーチャントデバイス２９はスワイプ処理モードに入ってもよく、そのモードでは、チップカードはチップカードとして動作することをまず試行することなしに、磁気ストリップカードとして実行されてもよい。処理はステップ８１０に続いてもよく、そこでは、第１支払いトランザクション要求がマーチャントデバイス２９のユーザインタフェース２１０において受け付けられてもよい。支払い要求は、ポイントオブセールアプリケーション２２２を介したマーチャントからの入力として提供されてもよく、電子支払い情報ベースの購入進捗（例えば、支払いトランザクションの所望のポイントへの進行、支払額のファイナライズなど）の要求を示してもよい。支払いトランザクション要求が受信された後、処理はステップ８１１に続いてもよい。
【０１４５】
ステップ８１１で、マーチャントデバイス２９は、支払いリーダ２２からスワイプ支払い情報を受信してもよい。ある実施の形態では、支払いリーダ２２は、スワイプインタフェース１０５を通じてスワイプされた支払いカードの磁気ストリップを読み出してもよい。支払いトランザクション要求に応じたスワイプ支払いタイプの電子支払い情報がマーチャントデバイスにおいて受信された後、処理はステップ８１２に続いてもよい。
【０１４６】
ステップ８１２で、マーチャントデバイス２９は、スワイプ支払いタイプの電子支払い情報を提供した支払いカードがチップカードであるか否かを判定してもよい。ある実施の形態では、マーチャントデバイス２９は、支払いリーダ２２のスワイプインタフェース１０５において提供された電子支払い情報に基づいて、支払いカードがチップカードであるか否かを判定してもよい。スワイプ支払いタイプの電子支払い情報を提供した支払いカードがチップカードでないとマーチャントデバイス２９が判定した場合、処理はステップ８１４に続いてもよく、支払い端末２０はその判定に基づいて、通常のスワイプ支払いトランザクションプロトコルを用いてトランザクションのための支払い処理を完了してもよい。マーチャントデバイス２９がスワイプ支払いタイプの電子支払い情報を提供した支払いカードがチップカードであると判定した場合、処理はステップ８１６に続いてもよい。
【０１４７】
ステップ８１６で、マーチャントデバイス２９は、インジケータを生成し、スワイプモード中に受信された電子支払い情報にそのインジケータを関連付けでもよい。ある実施の形態では、マーチャントデバイス２９は、スワイプモードに入る支払い端末に基づいてスワイプモード処理インジケータを生成してもよい。スワイプモード処理インジケータは、スワイプ支払いタイプを処理するための手順にしたがって電子支払い情報を処理することを許してもよく、また、トランザクションが技術後退トランザクションでない（例えば、トランザクションが、支払い端末のチップカードインタフェースにおけるチップカードの処理に失敗したトランザクションでない）ことを示してもよい。チップカードは技術後退がないなかでスワイプモードで動作しているので、スワイプモード処理インジケータはひとつ以上の支払いサーバに、トランザクションが、マーチャントへの責任の転換を要求するスワイプトランザクションとして処理されるべきであることを知らせてもよい。ある実施の形態では、マーチャントデバイス２９は、電子支払い情報を提供した支払いカードがチップカードであるとのインジケータを生成してもよい。支払いカードがチップカードであるとのインジケータは、マーチャントデバイス２９において受信される、支払いカードがチップカードであるとの通知（例えば、ステップ８１２における支払いカードがチップカードであるとの判定に続くもの）を含む任意の適切な情報に基づいてもよい。ある実施の形態では、スワイプモード中に支払い端末において受信された電子支払い情報に、スワイプモードインジケータおよび支払いカードがチップカードであるとのインジケータを、関連付けてもよい。インジケータが生成され、割り当てられた後、処理はステップ８１８に続いてもよい。
【０１４８】
ステップ８１８で、マーチャントデバイス２９は、例えばユーザインタフェース２１０を介して、追加的な支払いトランザクション要求が受け付けられたか否かを判定してもよい。追加的な要求が受け付けられたとマーチャントデバイス２９が判定した場合、電子支払いおよびインジケータは、現在のトランザクションに対して格納され、メモリに格納されてもよく、処理はステップ８１０に戻ってもよい。追加的な支払いトランザクション要求が受け付けられなかった場合、処理はステップ８２０に続いてもよく、そこではマーチャントデバイス２９は遅延条件を特定してもよい。ある実施の形態では、マーチャントデバイス２９が特定可能な遅延条件は、ひとつ以上の支払いサーバとの接続の喪失、大量のトランザクション、接続速度の低下、またはそれらの任意の組み合わせなどのイベントであってもよい。ある実施の形態では、遅延条件は、（例えば、支払い端末２０における）支払いトランザクションの頻度がしきい値頻度を超えたとの判定であってもよい。ある実施の形態では、遅延条件は、支払い端末２０（例えば、マーチャントデバイス２９）とひとつ以上の支払いサーバとの間の接続速度を含んでもよい。マーチャントデバイス２９がステップ８２０で遅延条件を特定した場合、処理はステップ８２２に続いてもよい。遅延条件が特定されない場合、処理はステップ８２４に続いてもよい。
【０１４９】
ステップ８２２で、マーチャントデバイス２９は、遅延条件の特定に応じて、（例えばメモリ２０４に）電子支払い情報およびインジケータを格納してもよい。ある実施の形態では、マーチャントデバイス２９は、遅延条件を監視し、遅延条件が解消すると、メモリに格納された電子支払い情報およびインジケータをひとつ以上の支払いサーバに送信してもよい。ある実施の形態では、遅延条件の解消は、支払いトランザクションの頻度がしきい値を下回ることを含んでもよい。ある実施の形態では、しきい値は、マーチャントの特定情報、マーチャントのタイプ、マーチャントの所在地、従業員の特定情報、顧客の特定情報、接続速度、平均承認時間、商品のタイプ、時刻、または他の情報を含む任意の適切な情報に基づいてもよい。ひとつ以上の遅延条件が解消したとマーチャントデバイス２９が判定した後、処理はステップ８２４に続いてもよい。
【０１５０】
ステップ８２４で、マーチャントデバイス２９は、例えば無線インタフェース２１４を介して、ひとつ以上の支払いサーバに、電子支払い情報および関連するスワイプモード処理インジケータを送信してもよい。送信された電子支払い情報は、通常処理またはスワイプモードを実行することを介してマーチャントデバイス２９において受信されてもよく、スワイプモードインジケータおよび電子支払い情報を提供したカードがチップカードであるとのインジケータのうちのひとつ以上を含んでもよい。電子支払い情報および関連するスワイプモード処理インジケータがひとつ以上の支払いサーバに送信された後、処理はステップ８２６に続いてもよい。
【０１５１】
ステップ８２６で、マーチャントデバイス２９は、電子支払い情報についての支払い承認応答を受信してもよい。ある実施の形態では、マーチャントデバイス２９は、ひとつ以上の支払いサーバに送信された電子支払い情報に関連付けられた支払い承認応答を受信してもよい。したがって、例示的な実施の形態では、複数の電子支払い情報の伝送について、支払い端末２０の通信インタフェースにおいて（例えば、無線インタフェース２１４において）電子支払い情報に関連付けられた支払い承認応答が受信されてもよい。ある実施の形態では、支払い承認応答は、スワイプモードインジケータおよび電子支払い情報を提供したカードがチップカードであるとのインジケータのうちのひとつ以上に基づいてもよい。マーチャントデバイスは、次いで、例えば承認および拒否の記録を格納し、（例えば、責任の転換に続くトランザクションの拒否の）通知を提供することによって、受信された支払い承認応答を処理してもよい。その後、処理は終わってもよい。
【０１５２】
ある実施の形態では、チップカードから受信された電子支払い情報を処理する支払い端末のための方法は、前記支払い端末のユーザインタフェースにおいて、至急処理モードに入る要求を受け付けることと、前記支払い端末の前記ユーザインタフェースにおいて、前記至急処理モードに入る前記要求に応じて、オプトイン要求を提供することと、を含み、ユーザは前記ユーザによって前記オプトイン要求が受け入れられた場合に限り、前記至急処理モードに入ることが許される。方法はさらに、前記支払い端末の前記ユーザインタフェースにおいて、第１支払い要求を受け付けることと、前記支払い端末の処理要素が、前記第１支払い要求に応じて第１チップカードに第１電子支払い応答を要求することと、前記支払い端末の通信インタフェースがひとつ以上の支払いサーバと通信可能であるか否かをチェックすることと、前記通信インタフェースが前記ひとつ以上の支払いサーバと通信不可である場合、前記支払い端末のメモリにおいて、前記第１電子支払い応答を格納することと、前記第１電子支払い応答に関連付けられた第１トランザクションを承認することと、を含んでもよい。方法はさらに、前記ユーザインタフェースにおいて追加的な支払い要求を受け付けることと、前記支払い端末の前記処理要素によって、追加的なチップカードに追加的な電子支払い応答を要求することと、前記支払い端末の前記メモリにおいて、前記追加的な電子支払い応答を格納することと、前記追加的な電子支払い応答に関連付けられた追加的なトランザクションを承認することと、をさらに含んでもよい。方法はさらに、前記第１電子支払い応答および前記追加的な電子支払い応答を格納し、前記第１トランザクションおよび前記追加的なトランザクションを承認した後、前記支払い端末の前記通信インタフェースが前記ひとつ以上の支払いサーバと通信可能であると判定することと、前記第１電子支払い応答および前記追加的な電子支払い応答のそれぞれに支払いタイプインジケータを関連付けることであって、前記支払いタイプインジケータは前記ひとつ以上の支払いサーバに、前記第１電子支払い応答および前記追加的な電子支払い応答が至急支払いプロトコルにしたがう処理の対象であることを示す、関連付けることと、を含んでもよい。方法はさらに、前記支払い端末の前記通信インタフェースから、前記第１電子支払い応答と前記追加的な電子支払い応答と前記関連付けられた支払いタイプインジケータとを、前記ひとつ以上の支払いサーバに、送信することであって、通常支払いプロトコルは前記チップカードのそれぞれに、該チップカードのトランザクションを処理するための追加的情報を要求し、前記至急支払いプロトコルは前記ひとつ以上の支払いサーバに前記追加的情報なしで前記第１トランザクションおよび前記追加的なトランザクションを処理させ、前記第１トランザクションおよび前記追加的なトランザクションは前記第１トランザクションおよび前記追加的なトランザクションが前記支払い端末によって承認された後に前記至急支払いプロトコルにしたがって前記ひとつ以上のサーバにおいて処理される、送信することと、前記支払い端末の前記通信インタフェースにおいて、前記第１電子支払い応答および前記追加的な電子支払い応答のそれぞれに関連付けられた支払い承認応答を受信することであって、前記支払い承認応答が前記支払いタイプインジケータに基づく、受信することと、を含んでもよい。
【０１５３】
ある実施の形態では、方法はさらに、前記第１電子支払い応答および各前記追加的な電子支払い応答に時刻インジケータを関連付けることであって、各時刻インジケータが将来トランザクション時刻に対応する、関連付けることと、各時刻インジケータをそれに関連付けられた電子支払い応答と共に送信することと、を含んでもよい。
【０１５４】
方法のある実施の形態では、各時刻インジケータおよびそれに関連付けられた電子支払い応答が、該時刻インジケータの前記時刻に対応する時刻に送信される。
【０１５５】
方法のある実施の形態では、各時刻インジケータおよびそれに関連付けられた電子支払い応答が、該時刻インジケータの前記時刻に対応する時刻より前に送信され、前記ひとつ以上の支払いサーバが該時刻インジケータの前記時刻まで待ってから前記電子支払い応答を処理する。
【０１５６】
ある実施の形態では、チップカードから受信された電子支払い情報を至急処理モードで処理する支払い端末のための方法は、前記支払い端末のユーザインタフェースにおいて、第１支払い要求を受け付けることと、前記第１支払い要求に応じて前記支払い端末の処理要素が、第１電子支払い応答を第１チップカードに、前記支払い端末のチップカードインタフェースを介して、要求することと、前記支払い端末のメモリにおいて、前記第１電子支払い応答を格納することと、前記第１電子支払い応答に関連付けられた第１トランザクションを承認することと、を含んでもよい。方法はさらに、前記ユーザインタフェースにおいて追加的な支払い要求を受け付けることと、前記追加的な支払い要求に応じて前記支払い端末の前記処理要素が、追加的な電子支払い応答を追加的なチップカードに、前記チップカードインタフェースを介して、要求することと、前記メモリにおいて、前記追加的な電子支払い応答を格納することと、前記追加的な電子支払い応答に関連付けられた追加的なトランザクションを承認することと、をさらに含んでもよい。方法はさらに、前記第１電子支払い応答および前記追加的な電子支払い応答のそれぞれに支払いタイプインジケータを関連付けることであって、前記支払いタイプインジケータはひとつ以上の支払いサーバに、前記第１電子支払い応答および前記追加的な電子支払い応答が至急支払いプロトコルにしたがう処理の対象であることを示す、関連付けることを含んでもよい。方法はさらに、前記第１電子支払い応答および前記追加的な電子支払い応答を格納し、前記第１トランザクションおよび前記追加的なトランザクションを承認した後、前記ひとつ以上の支払いサーバに支払い承認要求を送信可能であると判定することであって、各支払い承認要求が前記第１電子支払い応答または前記追加的な電子支払い応答のうちのひとつと、前記電子支払い応答のそれぞれについて、それに関連付けられた支払いタイプインジケータと、を含む、判定することと、前記支払い端末の通信インタフェースから前記ひとつ以上の支払いサーバへ前記支払い承認要求を送信することと、を含んでもよく、通常支払いプロトコルは前記チップカードのそれぞれに、該チップカードのトランザクションを処理するための追加的情報を要求し、前記至急支払いプロトコルは前記ひとつ以上の支払いサーバに前記追加的情報なしで前記第１トランザクションおよび前記追加的なトランザクションを処理させ、前記第１トランザクションおよび前記追加的なトランザクションは前記第１トランザクションおよび前記追加的なトランザクションが前記支払い端末によって承認された後に前記至急支払いプロトコルにしたがって前記ひとつ以上のサーバにおいて処理される。
【０１５７】
ある実施の形態では、方法はさらに、前記支払い端末の前記ユーザインタフェースにおいて、前記至急処理モードに入る要求を受け付けることと、前記支払い端末の前記ユーザインタフェースにおいて、前記至急処理モードに入る前記要求に応じて、オプトイン要求を提供することと、を含んでもよく、ユーザは前記ユーザによって前記オプトイン要求が受け入れられた場合に限り、前記至急処理モードのステップを実行することが許される。
【０１５８】
ある実施の形態では、方法はさらに、前記第１支払い応答を受信した後、前記支払い端末の前記通信インタフェースが前記ひとつ以上の支払いサーバと通信可能であるか否かをチェックすることと、前記追加的な電子支払い応答を受信する前に、前記通信インタフェースが通信可能である場合に該通信インタフェースから前記ひとつ以上の支払いサーバへ前記第１電子支払い応答を送信することと、を含んでもよい。
【０１５９】
方法のある実施の形態では、支払い承認要求を送信可能であると判定することは、前記支払い端末の前記通信インタフェースが前記ひとつ以上の支払いサーバと通信可能であると判定することを含む。
【０１６０】
ある実施の形態では、方法はさらに、前記支払い端末の前記通信インタフェースにおいて、前記支払い承認要求のそれぞれに関連付けられた支払い承認応答を受け付けることを含んでもよく、前記支払い承認応答が前記支払いタイプインジケータに基づく。
【０１６１】
方法のある実施の形態では、支払い承認要求を送信可能であると判定することは、支払い要求の頻度が閾値より小さいと判定することを含む。
【０１６２】
ある実施の形態では、方法はさらに、各支払い承認要求に時刻インジケータを関連付けることであって、各時刻インジケータが将来トランザクション時刻に対応する、関連付けることと、各時刻インジケータをそれに関連付けられた電子支払い応答と共に前記ひとつ以上の支払いサーバに送信することと、を含んでもよい。
【０１６３】
方法のある実施の形態では、各時刻インジケータおよびそれに関連付けられた支払い承認要求が、該時刻インジケータの前記時刻に対応する時刻に送信される。
【０１６４】
方法のある実施の形態では、各時刻インジケータおよびそれに関連付けられた支払い承認要求が、該時刻インジケータの前記時刻に対応する時刻より前に送信され、前記ひとつ以上の支払いサーバが該時刻インジケータの前記時刻まで待ってから前記支払い承認要求を処理する。
【０１６５】
ある実施の形態では、チップカードから受信した無線電子支払い情報を至急処理モードで処理するための支払い端末は、チップカードインタフェースと、ひとつ以上の支払いサーバと通信するよう構成された通信インタフェースと、ユーザから支払い要求を受け付けるよう構成されたユーザインタフェースと、前記チップカードインタフェース、前記通信インタフェースおよび前記ユーザインタフェースと接続されたひとつ以上の処理要素であって、前記ひとつ以上の処理要素がユーザインタフェースインストラクション、至急処理インストラクションおよびトランザクション処理インストラクションを実行するよう構成される、ひとつ以上の処理要素と、を備えてもよい。支払い端末はさらに、前記ユーザインタフェースインストラクション、前記至急処理インストラクションおよび前記トランザクション処理インストラクションを保持するよう構成されたひとつ以上のメモリをさらに備えてもよく、ユーザインタフェースインストラクションは前記ひとつ以上の処理要素に、前記ユーザインタフェースにおいて第１支払い要求を受け付けることと、前記ユーザインタフェースにおいて追加的な支払い要求を受け付けることと、を行わせ、至急処理インストラクションは前記ひとつ以上の処理要素に、前記第１支払い要求に応じて前記チップカードインタフェースを介して第１チップカードに第１電子支払い応答を要求することと、前記支払い端末のメモリにおいて前記第１電子支払い応答を格納することと、前記チップカードインタフェースを介して追加的なチップカードに追加的な電子支払い応答を要求することと、前記メモリにおいて前記追加的な電子支払い応答を格納することと、前記第１電子支払い応答および前記追加的な電子支払い応答のそれぞれに支払いタイプインジケータを関連付けることであって、前記支払いタイプインジケータはひとつ以上の支払いサーバに、前記第１電子支払い応答および前記追加的な電子支払い応答が至急支払いプロトコルにしたがう処理の対象であることを示す、関連付けることと、を行わせ、前記トランザクション処理インストラクションは前記ひとつ以上の処理要素に、前記第１電子支払い応答に関連付けられた第１トランザクションを承認することと、前記追加的な電子支払い応答に関連付けられた追加的なトランザクションを承認することと、前記第１電子支払い応答および前記追加的な電子支払い応答を格納し、前記第１トランザクションおよび前記追加的なトランザクションを承認した後、前記ひとつ以上の支払いサーバに前記通信インタフェースを介して支払い承認要求を送信可能であると判定することと、前記支払い承認要求を前記ひとつ以上の支払いサーバに送信することと、を行わせ、各支払い承認要求が前記第１電子支払い応答または前記追加的な電子支払い応答のうちのひとつと、前記電子支払い応答のそれぞれについて、それに関連付けられた支払いタイプインジケータと、を含み、通常支払いプロトコルは前記チップカードのそれぞれに、該チップカードのトランザクションを処理するための追加的情報を要求し、前記至急支払いプロトコルは前記ひとつ以上の支払いサーバに前記追加的情報なしで前記第１トランザクションおよび前記追加的なトランザクションを処理させ、前記第１トランザクションおよび前記追加的なトランザクションは前記第１トランザクションおよび前記追加的なトランザクションが前記支払い端末によって承認された後に前記至急支払いプロトコルにしたがって前記ひとつ以上のサーバにおいて処理される。
【０１６６】
支払い端末のある実施の形態では、ユーザインタフェースインストラクションは前記ひとつ以上の処理要素にさらに、前記ユーザインタフェースから、前記至急処理モードに入る要求を受け付けることと、前記ユーザインタフェースにおいて、前記至急処理モードに入る前記要求に応じて、オプトイン要求を提供することと、を行わせ、ユーザは前記ユーザによって前記オプトイン要求が受け入れられた場合に限り、前記至急処理モードのステップを実行することが許される。
【０１６７】
支払い端末のある実施の形態では、トランザクション処理インストラクションは前記ひとつ以上の処理要素にさらに、前記第１支払い応答を受信した後、前記支払い端末の前記通信インタフェースが前記ひとつ以上の支払いサーバと通信可能であるか否かをチェックすることと、前記追加的な電子支払い応答を受信する前に、前記通信インタフェースが通信可能である場合に該通信インタフェースを介して前記ひとつ以上の支払いサーバへ前記第１電子支払い応答を送信することと、を行わせる。
【０１６８】
支払い端末のある実施の形態では、支払い承認要求を送信可能であるとの判定は、前記支払い端末の前記通信インタフェースが前記ひとつ以上の支払いサーバと通信可能であるとの判定を含む。
【０１６９】
支払い端末のある実施の形態では、トランザクション処理インストラクションは前記ひとつ以上の処理要素にさらに、前記支払い端末の前記通信インタフェースを介して、前記支払い承認要求のそれぞれに関連付けられた支払い承認応答を受け付けることを行わせ、前記支払い承認応答が前記支払いタイプインジケータに基づく。
【０１７０】
支払い端末のある実施の形態では、支払い承認要求を送信可能であるとの判定は、支払い要求の頻度が閾値より小さいとの判定を含む。
【０１７１】
支払い端末のある実施の形態では、トランザクション処理インストラクションは前記ひとつ以上の処理要素にさらに、各支払い承認要求に時刻インジケータを関連付けることであって、各時刻インジケータが将来トランザクション時刻に対応する、関連付けることと、各時刻インジケータをそれに関連付けられた電子支払い応答と共に送信することと、を行わせる。
【０１７２】
支払い端末のある実施の形態では、各時刻インジケータおよびそれに関連付けられた支払い承認要求が、該時刻インジケータの前記時刻に対応する時刻に送信される。
【０１７３】
支払い端末のある実施の形態では、各時刻インジケータおよびそれに関連付けられた支払い承認要求が、該時刻インジケータの前記時刻に対応する時刻より前に送信され、前記ひとつ以上の支払いサーバが該時刻インジケータの前記時刻まで待ってから前記支払い承認要求を処理する。
【０１７４】
ある実施の形態では、非一時的コンピュータ可読保持媒体はそれに保持されるインストラクションを備えてもよく、該インストラクションはひとつ以上のプロセッサによって実行された場合、前記ひとつ以上のプロセッサに、支払い端末のユーザインタフェースを介して第１支払い要求を受け付けることと、前記第１支払い要求に応じてチップカードインタフェースを介して第１チップカードに第１電子支払い応答を要求することと、前記支払い端末のメモリに前記第１電子支払い応答を提供することと、前記第１電子支払い応答に関連付けられた第１トランザクションを承認することと、を含む動作を行わせる。動作はさらに、前記ユーザインタフェースを介して追加的な支払い要求を受け付けることと、前記追加的な支払い要求に応じて追加的な電子支払い応答を追加的な支払いカードに、前記チップカードインタフェースを介して、要求することと、前記メモリに格納されるべき前記追加的な電子支払い応答を提供することと、前記追加的な電子支払い応答に関連付けられた追加的なトランザクションを承認することと、をさらに含んでもよい。動作はさらに、前記第１電子支払い応答および前記追加的な電子支払い応答のそれぞれに支払いタイプインジケータを関連付けることであって、前記支払いタイプインジケータは前記ひとつ以上の支払いサーバに、前記第１電子支払い応答および前記追加的な電子支払い応答が至急支払いプロトコルにしたがう処理の対象であることを示す、関連付けることと、前記第１電子支払い応答および前記追加的な電子支払い応答を格納し、前記第１トランザクションおよび前記追加的なトランザクションを承認した後、前記ひとつ以上の支払いサーバに支払い承認要求を送信可能であると判定することであって、各支払い承認要求が前記第１電子支払い応答および前記追加的な電子支払い応答のうちのひとつと、前記電子支払い応答のそれぞれについて、それに関連付けられた支払いタイプインジケータと、を含む、判定することと、を含んでもよい。方法はさらに、前記支払い端末の通信インタフェースを介した前記ひとつ以上の支払いサーバへの送信用の支払い承認要求を提供することを含んでもよく、通常支払いプロトコルは前記チップカードのそれぞれに、該チップカードのトランザクションを処理するための追加的情報を要求し、前記至急支払いプロトコルは前記ひとつ以上の支払いサーバに前記追加的情報なしで前記第１トランザクションおよび前記追加的なトランザクションを処理させ、前記第１トランザクションおよび前記追加的なトランザクションは前記第１トランザクションおよび前記追加的なトランザクションが前記支払い端末によって承認された後に前記至急支払いプロトコルにしたがって前記ひとつ以上のサーバにおいて処理される。
【０１７５】
ある実施の形態では、インストラクションは前記ひとつ以上のプロセッサにさらに、前記ユーザインタフェースから、前記至急処理モードに入る要求を受け付けることと、前記ユーザインタフェースに対して、前記至急処理モードに入る前記要求に応じて、オプトイン要求を提供することと、を含む動作を行わせてもよく、ユーザは前記ユーザによって前記オプトイン要求が受け入れられた場合に限り、前記至急処理モードのステップを実行することが許される。
【０１７６】
ある実施の形態では、インストラクションは前記ひとつ以上のプロセッサにさらに、前記第１支払い応答を受信した後、前記通信インタフェースが前記ひとつ以上の支払いサーバと通信可能であるか否かをチェックすることと、前記追加的な電子支払い応答を受信する前に、前記通信インタフェースが通信可能である場合に該通信インタフェースに対して、前記ひとつ以上の支払いサーバへ送信されるべき前記第１電子支払い応答を提供することと、を含む動作を行わせてもよい。
【０１７７】
ある実施の形態では、支払い承認要求を送信可能であると判定することは、前記支払い端末の前記通信インタフェースが前記ひとつ以上の支払いサーバと通信可能であると判定することを含む。
【０１７８】
ある実施の形態では、支払い承認要求を送信可能であると判定することは、支払い要求の頻度が閾値より小さいと判定することを含む。
【０１７９】
ある実施の形態では、インストラクションは前記ひとつ以上のプロセッサにさらに、各支払い承認要求に時刻インジケータを関連付けることであって、各時刻インジケータが将来トランザクション時刻に対応する、関連付けることと、各時刻インジケータをそれに関連付けられた電子支払い応答と共に、前記ひとつ以上の支払いサーバに送信されるべきものとして前記通信インタフェースに提供することと、を含む動作を行わせてもよい。
【０１８０】
ある実施の形態では、各時刻インジケータおよびそれに関連付けられた支払い承認要求が、該時刻インジケータの前記時刻に対応する時刻における送信用に、前記通信インタフェースに提供される。
【０１８１】
ある実施の形態では、各時刻インジケータおよびそれに関連付けられた支払い承認要求が、該時刻インジケータの前記時刻に対応する時刻より前における送信用に、前記通信インタフェースに提供され、支払いサーバが該時刻インジケータの前記時刻まで待ってから前記支払い承認要求を処理する。
【０１８２】
ある実施の形態では、複数の支払いインタフェースを通じて電子支払い情報を選択的に処理する支払い端末のための方法は、前記支払い端末のユーザインタフェースにおいて、第１支払いトランザクション要求を受け付けることと、前記支払い端末のチップカードインタフェースにおいて、前記第１支払いトランザクション要求に応じて、チップカードから、第１電子支払い情報タイプの第１電子支払い情報を受け付けることと、前記支払い端末の通信インタフェースから、ひとつ以上の支払いサーバに、前記第１電子支払い情報を送信することと、前記支払い端末の前記通信インタフェースにおいて、前記第１電子支払い情報に対する第１支払い承認応答を受信することと、を含んでもよい。方法はさらに、前記支払い端末の前記ユーザインタフェースにおいて、スワイプモードに入る要求を受け付けることと、前記支払い端末の前記ユーザインタフェースにおいて、前記スワイプモードに入る前記要求に応じてオプトイン確認を提供することであって、前記支払い端末は前記オプトイン確認がユーザによって受け入れられた場合にのみ前記スワイプモードに入ることが許可される、提供することと、前記支払い端末の前記ユーザインタフェースにおいて、第２支払いトランザクション要求を受け付けることと、前記支払い端末のスワイプインタフェースにおいて、前記第２支払いトランザクション要求に応じて、支払いカードから、第２電子支払い情報タイプの第２電子支払い情報を受け付けることと、を含んでもよい。方法はさらに、前記支払い端末において、前記支払いカードがチップカードであるとの通知を受け付けることと、前記支払い端末において、前記支払い端末が前記スワイプモードに入ったことおよび前記通知に基づいてスワイプモード処理インジケータを生成することであって、前記スワイプモード処理インジケータは前記第２電子支払い情報タイプの手順にしたがって前記第２電子支払い情報が処理されることを可能とする、生成することと、前記支払い端末の前記通信インタフェースから、前記ひとつ以上の支払いサーバに、前記スワイプモード処理インジケータおよび前記第２電子支払い情報を送信することと、前記支払い端末の前記通信インタフェースにおいて、前記第２電子支払い情報に対する第２支払い承認応答を受信することであって、前記支払い承認応答が前記スワイプモード処理インジケータに基づく、受信することと、を含んでもよい。
【０１８３】
方法のある実施の形態では、前記スワイプモード処理インジケータは、前記トランザクションが技術的後退トランザクションではないことを示し、前記技術的後退トランザクションは、前記チップカードが前記支払い端末の前記チップカードインタフェースにおいて処理に失敗したことを示す。
【０１８４】
ある実施の形態では、方法はさらに、遅延条件を特定することであって、前記第２電子支払い情報の前記送信がその遅延条件の間遅延されるべきである、特定することと、前記支払い端末のメモリに前記第２電子支払い情報を格納することと、前記遅延条件の前記満了に基づいて前記第２電子支払い情報を送信することと、を含んでもよい。
【０１８５】
方法のある実施の形態では、前記遅延条件が支払いトランザクションの頻度を含み、前記遅延条件の前記満了は支払いトランザクションの前記頻度がしきい値を下回ることを含む。
【０１８６】
ある実施の形態では、複数の支払いインタフェースを通じて電子支払い情報を選択的に処理する支払い端末のための方法は、前記支払い端末のユーザインタフェースにおいて、スワイプモードに入る要求を受け付けることと、前記支払い端末の前記ユーザインタフェースにおいて、前記スワイプモードに入る前記要求に応じてオプトイン確認を提供することであって、前記支払い端末は前記オプトイン確認がユーザによって受け入れられた場合にのみ前記スワイプモードに入ることが許可される、提供することと、前記支払い端末の前記ユーザインタフェースにおいて、支払いトランザクション要求を受け付けることと、前記支払い端末のスワイプインタフェースにおいて、前記支払いトランザクション要求に応じて、支払いカードから、スワイプ支払いタイプの電子支払い情報を受け付けることと、を含んでもよい。方法はさらに、前記支払い端末において、前記支払い端末が前記スワイプモードに入ったことおよび前記支払いカードがチップカードであるとのインジケータに基づいてスワイプモード処理インジケータを生成することであって、前記スワイプモード処理インジケータは前記スワイプ支払いタイプの手順にしたがって前記電子支払い情報が処理されることを可能とする、生成することと、前記支払い端末の通信インタフェースから、前記ひとつ以上の支払いサーバに、前記スワイプモード処理インジケータおよび前記電子支払い情報を送信することと、前記支払い端末の前記通信インタフェースにおいて、前記電子支払い情報に対する支払い承認応答を受信することであって、前記支払い承認応答が前記スワイプモード処理インジケータに基づく、受信することと、を含んでもよい。
【０１８７】
方法のある実施の形態では、前記スワイプモード処理インジケータは、前記トランザクションが技術的後退トランザクションではないことを示し、前記技術的後退トランザクションは、前記チップカードが前記支払い端末のチップカードインタフェースにおいて処理に失敗したことを示す。
【０１８８】
ある実施の形態では、方法はさらに、遅延条件を特定することであって、前記電子支払い情報の前記送信がその遅延条件の間遅延されるべきである、特定することと、前記支払い端末のメモリに前記電子支払い情報を格納することと、前記遅延条件の満了に基づいて前記電子支払い情報を送信することと、を含んでもよい。
【０１８９】
方法のある実施の形態では、前記遅延条件が支払いトランザクションの頻度を含み、前記遅延条件の前記満了は支払いトランザクションの前記頻度がしきい値を下回ることを含む。
【０１９０】
方法のある実施の形態では、前記遅延条件が前記支払い端末と前記ひとつ以上の支払いサーバとの間の接続スピードを含み、前記遅延条件の前記満了は前記接続スピードがしきい値を超えることを含む。
【０１９１】
ある実施の形態では、方法はさらに、前記支払い端末において、前記支払いカードがチップカードであるとの通知を受信することであって、前記支払いカードがチップカードであるとの前記インジケータが前記通知に基づく、受信することを含んでもよい。
【０１９２】
ある実施の形態では、方法はさらに、前記支払い端末の前記ユーザインタフェースにおいて、第２支払いトランザクション要求を受け付けることと、前記支払い端末の前記スワイプインタフェースにおいて、前記第２支払いトランザクション要求に応じて、第２支払いカードから、スワイプ支払いタイプの電子支払い情報を受け付けることと、前記第２支払いカードがチップカードでないと判定することと、前記判定に基づいて、前記第２支払いカードを、通常のスワイプカードプロトコルにしたがって処理することと、を含んでもよい。
【０１９３】
ある実施の形態では、方法はさらに、前記支払い端末の前記ユーザインタフェースにおいて、第２支払いトランザクション要求を受け付けることと、前記支払い端末のチップカードインタフェースにおいて、前記第２支払いトランザクション要求に応じて、第２チップカードから、チップカード支払いタイプの第２電子支払い情報を受け付けることと、前記支払い端末の前記通信インタフェースから、ひとつ以上の支払いサーバに、前記第２電子支払い情報を送信することと、前記支払い端末の前記通信インタフェースにおいて、前記第２電子支払い情報に対する支払い承認応答を受信することと、を含んでもよい。
【０１９４】
方法のある実施の形態では、前記第１支払いトランザクション要求の責任は、前記支払い端末を運用するマーチャントに課され、前記第２支払いトランザクション要求の責任は前記マーチャントに課されない。
【０１９５】
ある実施の形態では、複数の支払いインタフェースを通じて電子支払い情報を選択的に処理するための支払い端末は、磁気ストリップ支払いカードからスワイプ支払いタイプの電子支払い情報を受信するよう構成されたスワイプインタフェースと、チップカードから電子支払い情報を受信するよう構成されたチップカードインタフェースと、ひとつ以上の支払いサーバと通信するよう構成された通信インタフェースと、スワイプモードに入る要求、オプトイン確認、および支払いトランザクション要求を受け付けるよう構成されたユーザインタフェースと、前記スワイプインタフェース、通信インタフェースおよび前記ユーザインタフェースと接続されたひとつ以上の処理要素と、を備え、前記ひとつ以上の処理要素が、ユーザインタフェースインストラクション、スワイプモードインストラクション、およびトランザクション処理インストラクションを実行するよう構成される。支払い端末はさらに、前記ユーザインタフェースインストラクション、前記スワイプモードインストラクションおよび前記トランザクション処理インストラクションを保持するよう構成されたひとつ以上のメモリをさらに備えてもよく、前記ユーザインタフェースインストラクションは前記ひとつ以上の処理要素に、スワイプモードに入る要求を前記ユーザインタフェースから受信することと、前記スワイプモードに入る前記要求に応じて前記ユーザインタフェースにオプトイン確認を提供することと、前記ユーザインタフェースから支払いトランザクション要求を受信することと、を行わせ、前記スワイプモードインストラクションは前記ひとつ以上の処理要素に、前記オプトイン確認がユーザによって受け入れられた場合に限り前記支払い端末が前記スワイプモードに入ることを許可することと、前記支払い端末が前記スワイプモードに入ったことおよび前記支払いカードがチップカードであるとのインジケータに基づいてスワイプモード処理インジケータを生成することであって、前記スワイプモード処理インジケータは前記スワイプ支払いタイプの手順にしたがって前記電子支払い情報が処理されることを可能とする、生成することと、を行わせ、前記トランザクション処理インストラクションは前記ひとつ以上の処理要素に、前記支払いトランザクション要求に応じて前記支払いカードから前記スワイプ支払いタイプの電子支払い情報を受信することと、前記通信インタフェースを介して前記ひとつ以上の支払いサーバに、前記スワイプモード処理インジケータおよび前記電子支払い情報を送信することと、前記電子支払い情報に対する支払い承認応答を受信することであって、前記支払い承認応答が前記スワイプモード処理インジケータに基づく、受信することと、を行わせる。
【０１９６】
支払い端末のある実施の形態では、前記スワイプモード処理インジケータは、前記トランザクションが技術的後退トランザクションではないことを示し、前記技術的後退トランザクションは、前記チップカードが前記支払い端末の前記チップカードインタフェースにおいて処理に失敗したことを示す。
【０１９７】
支払い端末のある実施の形態では、トランザクション処理インストラクションは前記ひとつ以上の処理要素にさらに、遅延条件を特定することであって、前記電子支払い情報の前記送信がその遅延条件の間遅延されるべきである、特定することと、前記支払い端末のメモリに前記電子支払い情報を格納することと、前記遅延条件の満了に基づいて前記電子支払い情報の前記送信を許可することと、を行わせる。
【０１９８】
支払い端末のある実施の形態では、前記遅延条件が支払いトランザクションの頻度を含み、前記遅延条件の前記満了は支払いトランザクションの前記頻度がしきい値を下回ることを含む。
【０１９９】
支払い端末のある実施の形態では、前記遅延条件が前記支払い端末と前記ひとつ以上の支払いサーバとの間の接続スピードを含み、前記遅延条件の前記満了は前記接続スピードがしきい値を超えることを含む。
【０２００】
支払い端末のある実施の形態では、前記スワイプモードインストラクションはさらに、前記支払い端末において、前記支払いカードがチップカードであるとの通知を受信することであって、前記支払いカードがチップカードであるとの前記インジケータが前記通知に基づく、受信することを含む。
【０２０１】
支払い端末のある実施の形態では、前記ユーザインタフェースインストラクションは前記ひとつ以上のプロセッサにさらに、前記ユーザインタフェースから、第２支払いトランザクション要求を受け付けることを行わせ、前記トランザクション処理インストラクションは前記ひとつ以上のプロセッサにさらに、前記スワイプインタフェースから、前記第２支払いトランザクション要求に応じて、第２支払いカードから、スワイプ支払いタイプの電子支払い情報を受け付けることと、前記第２支払いカードがチップカードでないと判定することと、前記判定に基づいて、前記第２支払いカードを、通常のスワイプカードプロトコルにしたがって処理することと、を行わせてもよい。
【０２０２】
支払い端末のある実施の形態では、前記ユーザインタフェースインストラクションは前記ひとつ以上のプロセッサにさらに、前記ユーザインタフェースにおいて、第２支払いトランザクション要求を受け付けることを行わせ、前記トランザクション処理インストラクションは前記ひとつ以上のプロセッサにさらに、前記チップカードインタフェースから、前記第２支払いトランザクション要求に応じて、前記チップカードから、チップカード支払いタイプの第２電子支払い情報を受け付けることと、前記通信インタフェースを介して、ひとつ以上の支払いサーバに、前記第２電子支払い情報を送信することと、前記通信インタフェースを介して、前記第２電子支払い情報に対する支払い承認応答を受信することと、を行わせる。
【０２０３】
支払い端末のある実施の形態では、前記第１支払いトランザクション要求の責任は、前記支払い端末を運用するマーチャントに課され、前記第２支払いトランザクション要求の責任は前記マーチャントに課されない。
【０２０４】
ある実施の形態では、非一時的コンピュータ可読保持媒体はそれに保持されるインストラクションを備えてもよく、該インストラクションはひとつ以上のプロセッサによって実行された場合、前記ひとつ以上のプロセッサに、前記支払い端末のユーザインタフェースから、スワイプモードに入る要求を受け付けることと、前記支払い端末の前記ユーザインタフェースに対して、前記スワイプモードに入る前記要求に応じてオプトイン確認を提供することであって、前記支払い端末は前記オプトイン確認がユーザによって受け入れられた場合にのみ前記スワイプモードに入ることが許可される、提供することと、前記支払い端末の前記ユーザインタフェースから、支払いトランザクション要求を受け付けることと、前記支払い端末のスワイプインタフェースを介して、前記支払いトランザクション要求に応じて、支払いカードから、スワイプ支払いタイプの電子支払い情報を受け付けることと、を含む動作を行わせる。動作はさらに、前記処理要素において、前記支払い端末が前記スワイプモードに入ったことおよび前記支払いカードがチップカードであるとのインジケータに基づいてスワイプモード処理インジケータを生成することであって、前記スワイプモード処理インジケータは前記スワイプ支払いタイプの手順にしたがって前記電子支払い情報が処理されることを可能とする、生成することと、前記支払い端末の通信インタフェースからひとつ以上の支払いサーバへの送信用に、前記スワイプモード処理インジケータおよび前記電子支払い情報を提供することと、を含んでもよい。動作はさらに、前記支払い端末の前記通信インタフェースから、前記電子支払い情報に対する支払い承認応答を受信することであって、前記支払い承認応答が前記スワイプモード処理インジケータに基づく、受信することを含んでもよい。
【０２０５】
ある実施の形態では、前記スワイプモード処理インジケータは、前記トランザクションが技術的後退トランザクションではないことを示し、前記技術的後退トランザクションは、前記チップカードが前記支払い端末のチップカードインタフェースにおいて処理に失敗したことを示す。
【０２０６】
ある実施の形態では、インストラクションは前記ひとつ以上のプロセッサにさらに、遅延条件を特定することであって、前記電子支払い情報の前記送信がその遅延条件の間遅延されるべきである、特定することと、前記支払い端末のメモリに前記電子支払い情報を格納することと、前記遅延条件の満了に基づいて前記電子支払い情報の前記送信を許可することと、を含む動作を行わせてもよい。
【０２０７】
ある実施の形態では、前記遅延条件が支払いトランザクションの頻度を含み、前記遅延条件の前記満了は支払いトランザクションの前記頻度がしきい値を下回ることを含む。
【０２０８】
ある実施の形態では、前記遅延条件が前記支払い端末と前記ひとつ以上の支払いサーバとの間の接続スピードを含み、前記遅延条件の前記満了は前記接続スピードがしきい値を超えることを含む。
【０２０９】
ある実施の形態では、インストラクションは前記ひとつ以上のプロセッサにさらに、前記支払いカードがチップカードであるとの通知を受信することであって、前記支払いカードがチップカードであるとの前記インジケータが前記通知に基づく、受信することを含む動作を行わせてもよい。
【０２１０】
ある実施の形態では、インストラクションは前記ひとつ以上のプロセッサにさらに、前記支払い端末の前記ユーザインタフェースから、第２支払いトランザクション要求を受け付けることと、前記スワイプインタフェースから、前記第２支払いトランザクション要求に応じて、第２支払いカードから、スワイプ支払いタイプの電子支払い情報を受け付けることと、前記第２支払いカードがチップカードでないと判定することと、前記判定に基づいて、前記第２支払いカードを、通常のスワイプカードプロトコルにしたがって処理することと、を含む動作を行わせてもよい。
【０２１１】
ある実施の形態では、インストラクションは前記ひとつ以上のプロセッサにさらに、前記支払い端末の前記ユーザインタフェースから、第２支払いトランザクション要求を受け付けることと、チップカードインタフェースを介して、前記第２支払いトランザクション要求に応じて、第２チップカードから、チップカード支払いタイプの第２電子支払い情報を受け付けることと、前記支払い端末の前記通信インタフェースから前記ひとつ以上の支払いサーバへの送信用に、前記第２電子支払い情報を提供することと、前記支払い端末の前記通信インタフェースから、前記第２電子支払い情報に対する支払い承認応答を受信することと、を含む動作を行わせてもよい。
【０２１２】
ある実施の形態では、前記第１支払いトランザクション要求の責任は、前記支払い端末を運用するマーチャントに課され、前記第２支払いトランザクション要求の責任は前記マーチャントに課されない。
【０２１３】
上記は本開示の原理の単なる説明に過ぎず、当業者であれば本開示の範囲から逸脱することなく種々の変更を行える。上述の実施の形態は、限定では無く説明の目的のために示されたものである。本開示はまた、本明細書で明示的に説明されたもの以外の多くの形態をとることができる。したがって、本開示は明示的に開示された方法、システムおよび装置に限定されず、むしろそれらの変形例や変更例であって以下の請求の範囲内のものを含むことが意図されていることを強調しておく。
【０２１４】
さらなる例として、本明細書で示され説明された提供された構成、デバイスおよび方法をさらに最適化するために、装置またはプロセスパラメータ（例えば、寸法、設定、コンポーネント、プロセスステップの順番等）の変更を行うことができる。いずれにせよ、本明細書で説明される構成およびデバイス、ならびに関連方法は、多くのアプリケーションを有する。したがって、開示された主題は本明細書で説明されるいずれかの単一の実施の形態に限定されるべきではなく、むしろ添付の請求の範囲にしたがう範囲において解釈されるべきものである。
【図１】
2019527873.tif 000003
【図２】
2019527873.tif 000004
【図３】
2019527873.tif 000005
【図４】
2019527873.tif 000006
【図５】
2019527873.tif 000007
【図６】
2019527873.tif 000008
【図７】
2019527873.tif 000009
【図８】
2019527873.tif 000010
【国際調査報告】
2019527873.tif 000011
2019527873.tif 000012
2019527873.tif 000013