特許 7222484 セキュアなインラインフレームを使用したオンライン支払い処理のシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-02-07

(45)【発行日】2023-02-15

(54)【発明の名称】セキュアなインラインフレームを使用したオンライン支払い処理のシステムおよび方法

(51)【国際特許分類】

   G06F 21/62 20130101AFI20230208BHJP

   G06Q 20/40 20120101ALI20230208BHJP

   G06F 21/60 20130101ALI20230208BHJP

【ＦＩ】

G06F21/62 309

G06Q20/40

G06F21/60 360

【請求項の数】 24

(21)【出願番号】P 2019566577

(86)(22)【出願日】2018-06-04

(65)【公表番号】

(43)【公表日】2020-07-30

(86)【国際出願番号】 US2018035850

(87)【国際公開番号】W WO2018223127

(87)【国際公開日】2018-12-06

【審査請求日】2021-05-26

(31)【優先権主張番号】62/514,324

(32)【優先日】2017-06-02

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】516282592

【氏名又は名称】ブルーフィン ペイメント システムズ エルエルシー

【氏名又は名称原語表記】ＢＬＵＥＦＩＮ ＰＡＹＭＥＮＴ ＳＹＳＴＥＭＳ，ＬＬＣ

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(74)【代理人】

【識別番号】100142907

【弁理士】

【氏名又は名称】本田 淳

(72)【発明者】

【氏名】プトレ、グラント

(72)【発明者】

【氏名】マッカーシー、ドナル

【審査官】宮司 卓佳

(56)【参考文献】

【文献】米国特許出願公開第２０１０／００９４７５５（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０１７８８１９（ＵＳ，Ａ１）

【文献】国際公開第２０１５／１０５６８８（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／６２

Ｇ０６Ｑ ２０／４０

Ｇ０６Ｆ ２１／６０

(57)【特許請求の範囲】

【請求項1】

システムであって、
ｉＦｒａｍｅコントローラであって、
サーバ上でホストされるマーチャント・ウェブサイトでｉＦｒａｍｅを作成すること、
前記マーチャント・ウェブサイトでの取引に対応する支払いデータを前記ｉＦｒａｍｅから受信すること、
第三者が前記ｉＦｒａｍｅを偽装していないことを保証するために、前記支払いデータが信頼できる署名によって署名されていることを検証すること、
受信した前記支払いデータを暗号化して格納すること、
暗号化された前記支払いデータに対応するｅＴｏｋｅｎを生成する要求を受信することであって、前記ｅＴｏｋｅｎを生成する要求は、前記支払いデータとは別に受信される、前記要求を受信すること、
暗号化された支払いデータに対応するｅＴｏｋｅｎを生成すること、
前記ｅＴｏｋｅｎを前記サーバに送信することであって、前記サーバは、前記ｅＴｏｋｅｎを支払いゲートウェイサーバに送信する、前記ｅＴｏｋｅｎをサーバに送信すること、を実行する前記ｉＦｒａｍｅコントローラと、
ｅＴｏｋｅｎ復号化プロセッサであって、
前記支払いゲートウェイサーバから前記ｅＴｏｋｅｎを受信すること、
前記ｅＴｏｋｅｎを認証して、対応する暗号化された支払いデータを決定すること、
前記暗号化された支払いデータを復号化すること、
取引を処理するために、復号化された前記支払いデータを前記支払いゲートウェイサーバに送信すること、を実行する前記ｅＴｏｋｅｎ復号化プロセッサと、を備えるシステム。

【請求項2】

前記ｉＦｒａｍｅは、第２のＨＴＭＬ文書内に埋め込まれた第１のＨＴＭＬ文書を含む、請求項１に記載のシステム。

【請求項3】

前記受信した支払いデータは、クレジットカード番号、クレジットカード有効期限、クレジットカード照合値、銀行口座ルーティング番号、デビットカード番号、デビットカード有効期限、またはＰＩＮ番号のうちの少なくとも１つを含む、請求項１に記載のシステム。

【請求項4】

前記支払いデータは、前記マーチャント・ウェブサイトまたは前記サーバによりアクセス可能ではない、請求項３に記載のシステム。

【請求項5】

前記支払いゲートウェイサーバおよび前記ｉＦｒａｍｅコントローラは、前記サーバとは別個に管理される、請求項１に記載のシステム。

【請求項6】

前記ｉＦｒａｍｅコントローラは、前記ｅＴｏｋｅｎを前記サーバに送信する前に前記ｅＴｏｋｅｎを暗号化する、請求項１に記載のシステム。

【請求項7】

前記ｅＴｏｋｅｎ復号化プロセッサは、前記ｅＴｏｋｅｎを認証する前に前記ｅＴｏｋｅｎを復号化する、請求項６に記載のシステム。

【請求項8】

前記ｉＦｒａｍｅは、前記マーチャント・ウェブサイト上のフォントまたはテキストスタイルに一致する１つまたは複数のフォントまたはテキストスタイルを含む、請求項１に記載のシステム。

【請求項9】

前記ｉＦｒａｍｅコントローラは、前記ｉＦｒａｍｅを作成するためのユーザ入力に基づいて、前記マーチャント・ウェブサイト上のフォントまたはテキストスタイルを実質的に自動的に一致させるように構成される、請求項８に記載のシステム。

【請求項10】

前記ｉＦｒａｍｅコントローラは、マーチャントが複数のｉＦｒａｍｅパラメータを入力することを可能にするｉＦｒａｍｅビルダーユーザインタフェースからの入力に少なくとも部分的に基づいて前記ｉＦｒａｍｅを作成する、請求項１に記載のシステム。

【請求項11】

前記ｉＦｒａｍｅビルダーユーザインタフェースは、前記マーチャントが前記マーチャント・ウェブサイト上のフォントおよびテキストスタイルのうちの少なくとも１つを一致させることを可能にするコマンドを含む、請求項１０に記載のシステム。

【請求項12】

方法であって、
サーバ上でホストされているマーチャント・ウェブサイトでｉＦｒａｍｅを作成すること、
前記マーチャント・ウェブサイトでの取引に対応する支払いデータを前記ｉＦｒａｍｅから受信すること、
第三者が前記ｉＦｒａｍｅを偽装していないことを保証するために、前記支払いデータが信頼できる署名によって署名されていることを検証すること、
受信した前記支払いデータを暗号化すること、
暗号化された前記支払いデータに対応するｅＴｏｋｅｎを生成する要求を受信することであって、前記ｅＴｏｋｅｎを生成する要求は、前記支払いデータとは別に受信される、前記要求を受信すること、
暗号化された前記支払いデータを格納すること、
前記暗号化された支払いデータに対応するｅＴｏｋｅｎを生成すること、
前記ｅＴｏｋｅｎをサーバに送信することであって、前記サーバは、前記ｅＴｏｋｅｎを支払いゲートウェイサーバに送信する、前記ｅＴｏｋｅｎをサーバに送信すること、
前記支払いゲートウェイサーバから前記ｅＴｏｋｅｎを受信すること、
前記ｅＴｏｋｅｎを認証して、対応する暗号化された支払いデータを決定すること、
前記暗号化された支払いデータを復号化すること、
取引を処理するために、復号化された前記支払いデータを前記支払いゲートウェイサーバに送信すること、を備える方法。

【請求項13】

前記ｉＦｒａｍｅは、第２のＨＴＭＬ文書内に埋め込まれた第１のＨＴＭＬ文書を含む、請求項１２に記載の方法。

【請求項14】

前記受信した支払いデータは、クレジットカード番号、クレジットカード有効期限、クレジットカード照合値、銀行口座ルーティング番号、デビットカード番号、デビットカード有効期限、またはＰＩＮ番号のうちの少なくとも１つを含む、請求項１２に記載の方法。

【請求項15】

前記支払いデータは、前記マーチャント・ウェブサイトまたは前記サーバによりアクセス可能ではない、請求項１４に記載の方法。

【請求項16】

前記支払いゲートウェイサーバは、前記サーバとは別個に管理される、請求項１２に記載の方法。

【請求項17】

前記ｅＴｏｋｅｎをサーバに送信する前に前記ｅＴｏｋｅｎを暗号化することをさらに備える請求項１２に記載の方法。

【請求項18】

前記ｅＴｏｋｅｎを認証する前に前記ｅＴｏｋｅｎを復号化することをさらに備える請求項１７に記載の方法。

【請求項19】

前記サーバ上でホストされる前記マーチャント・ウェブサイトであって、該マーチャント・ウェブサイトは、前記ｉＦｒａｍｅを含む、前記マーチャント・ウェブサイトをさらに備え、
前記サーバは、
前記ｉＦｒａｍｅコントローラから、前記暗号化された支払いデータに対応する前記ｅＴｏｋｅｎを受信すること、
前記取引に対応し且つ前記ｅＴｏｋｅｎおよび非機密性の支払いデータを含む取引データを生成すること、
前記取引を処理するために、前記取引データを前記支払いゲートウェイサーバに送信すること、
前記支払いゲートウェイサーバから少なくとも１つの処理結果を受信すること、を実行する、請求項１に記載のシステム。

【請求項20】

前記支払いゲートウェイサーバは、前記ｅＴｏｋｅｎ復号化プロセッサに前記ｅＴｏｋｅｎを送信し、データベースは、受信した支払いデータを格納する、請求項１９に記載のシステム。

【請求項21】

前記ｅＴｏｋｅｎを前記ｅＴｏｋｅｎ復号化プロセッサに送信することに応答して、前記支払いゲートウェイサーバは、前記受信した支払いデータを受信する、請求項２０に記載のシステム。

【請求項22】

前記非機密性の支払いデータは、取引識別子、取引価格、および連絡先情報のうちの少なくとも１つを含む、請求項１９に記載のシステム。

【請求項23】

前記ｉＦｒａｍｅを含む前記マーチャント・ウェブサイトをホストすること、
前記暗号化された支払いデータに対応するｅＴｏｋｅｎを受信すること、
前記取引に対応し且つ前記ｅＴｏｋｅｎおよび非機密性の支払いデータを含む取引データを生成すること、
前記取引を処理するために、前記取引データを送信すること、
少なくとも１つの処理結果を受信すること、をさらに備える請求項１２に記載の方法。

【請求項24】

前記非機密性の支払いデータは、取引識別子、取引価格、および連絡先情報のうちの少なくとも１つを含む、請求項２３に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本システムおよび方法は、概して、オンライン支払い処理に関し、より詳細には、埋め込みＨＴＭＬ文書を使用してオンライン支払い処理を可能にすることに関する。

【背景技術】

【0002】

毎日、（例えば、マーチャントからの購入のための支払い、公共料金の支払いなどの）何百万もの支払いがインターネットを使ってオンラインで行われ、取引量は毎年指数関数的に増加している。支払いを処理するために、支払い先（例えば、マーチャント、公益事業者等）は、典型的には、個人の非常に高い機密性の支払い情報／データ（例えば、支払いカード情報、銀行口座情報など）を受け取り、その支払いデータを、支払い取引が可能な支払いプロセッサに送信する。概して、支払いデータが第三者（例えば、支払い先）と共有されており、セキュリティ侵害によってその支払いデータが誤って公開される可能性があるため、これら取引の各々は、個人の非常に高い機密性の支払いデータを盗む機会となる可能性がある。

【0003】

標準的な取引プロセスのセキュリティを向上させるために、一部の支払い先は、支払いデータを支払い処理者に渡す代わりに、支払い先が支払いデータを処理しないように、支払い処理者のＷｅｂサイトに消費者を直接向かわせて取引を完了する。しかしながら、消費者が複数のウェブサイトを訪問することを要求するだけでなく、適切な支払いが行われることを補償するために支払い先が複数の情報を調整することを要求するので、この分散取引は、消費者と支払い先の両方の観点から煩雑で遅い。さらに、この分散取引は、支払い先の提供されたデータ（例えば、消費者名、住所など）の一部に対する制御量を低減させる。

【0004】

そのため、支払い先が支払いデータを処理することなく、支払い先ウェブサイトからのオンライン支払いを可能にするシステムまたは方法に対する長年の未解決のニーズがある。

【発明の概要】

【0005】

簡単に説明すると、一実施形態によれば、本開示の態様は、概して、埋め込みＨＴＭＬ文書を使用して、支払い先が支払いデータを処理することなく支払い先ウェブサイトからのオンライン支払い処理を可能にするシステムおよび方法に関する。

【0006】

様々な実施形態では、開示されたｉＦｒａｍｅシステムは、（例えば、インラインフレームまたはｉＦｒａｍｅであり、埋め込まれたＨＴＭＬ文書はｉＦｒａｍｅであり、ｉＦｒａｍｅが埋め込まれたＨＴＭＬ文書は「ｉＦｒａｍｅコンテナ」と呼称される）支払い先ウェブサイト上の別のＨＴＭＬ文書内に埋め込まれたＨＴＭＬ文書を介してオンライン支払いを可能にして、（例えば、マーチャント、公益事業者、政府機関、非営利団体などの）支払い先が支払者の支払いデータ（例えば、クレジットカード情報、銀行口座情報、ブロックチェーンベースの取引情報など）を処理することを要求することなく、支払者（例えば、消費者、構成員、提供者など）は、支払い先ウェブサイト上の取引（購入、公共料金の支払い、罰金、寄付、会費など）のために支払うことができる。この開示では、ｉＦｒａｍｅシステムを使用して受信および処理できる支払いデータの種類に制限はない。概して、ｉＦｒａｍｅによって、支払い先Ｗｅｂサイトは、支払いデータを表示することなく、支払いデータを受信して受理することができ、その代わり、支払い処理のために支払いデータを直接的にｉＦｒａｍｅシステムに渡す。様々な実施形態において、支払者がｉＦｒａｍｅを含む支払い先ウェブサイトに支払いデータを入力しているとき、支払者は概してそうするために別のウェブサイトに誘導されず、支払者には支払い先が支払いデータを直接受け取っているように見える。

【0007】

様々な実施形態では、ｉＦｒａｍｅを介して支払いデータが受信された後、ｉＦｒａｍｅシステムは、支払いデータに対応するｅＴｏｋｅｎ（例えば、支払いデータを識別するためにｉＦｒａｍｅシステムと支払い先によって使用される暗号化された識別子）を生成し、それを支払い先に提供する。支払い先は、概して、ｅＴｏｋｅｎを（例えば、取引価格、取引識別子などの）他の関連する取引データとともにｉＦｒａｍｅシステムに提供することによって、取引の処理を要求する。従って、様々な実施形態において、ｉＦｒａｍｅシステムは、取引データに対応する適切な支払いデータを決定し、（例えば、クレジットカード会社、銀行、マイナーなどの）適切な支払いネットワークを介して取引を処理する。

【0008】

概して、ｉＦｒａｍｅシステムは、支払い先が支払いデータにアクセスできないようにすることで、取引のセキュリティを強化する。さらに、ｉＦｒａｍｅシステムは、支払者が別のＷｅｂサイトにアクセスする必要がなく、支払い先が複雑な取引調整プロセスを実行する必要がないため、取引をより効率的にする。さらに、ｉＦｒａｍｅシステムは、支払い先が、消費者から提供された（例えば、名前、住所、連絡先などの）低い機密性のデータの処理をより細かく制御すること、つまり、どのデータを要求するか、どのようにデータを要求するかなどを制御することを可能にする。

【0009】

１つまたは複数の特許請求の範囲に記載された発明のこれらおよび他の態様、特徴、および利点は、以下の図面に関連して取られる好ましい実施形態および態様の以下の詳細に記載された説明から明らかになるであろうが、それに対する変更および修正は、開示の新規な概念の趣旨および範囲から逸脱することなく実施され得る。

【図面の簡単な説明】

【0010】

添付の図面は、本開示の１つ又は複数の実施形態及び／又は態様を示し、明細書とともに、本開示の原理を説明する役割を果たす。可能な限り、図面全体を通して同じ参照番号を使用して、実施形態の同じかまたは同様の要素を指す。

【図1】開示されたシステムの一実施形態の例示的な概略図を示す。

【図2】開示されたシステムの一実施形態の例示的なアーキテクチャを示す。

【図3】本開示の一実施形態による、例示的なｉＦｒａｍｅシステムプロセスを示すフローチャートである。

【図4】本開示の一実施形態による、例示的なｅＴｏｋｅｎ生成プロセスを示すフローチャートである。

【図5】本開示の一実施形態による、例示的なｅＴｏｋｅｎ取引プロセスを示すフローチャートである。

【図6】本開示の一実施形態による、例示的な支払い先システムプロセスを示すフローチャートである。

【図7】開示されたシステムの一実施形態の例示的な代替アーキテクチャを示す。

【発明を実施するための形態】

【0011】

本開示の原理の理解を促進するために、図面に示された実施形態を参照し、特定の言語を使用してこれを説明する。それでもなお、本開示の範囲の限定はそれによって意図されないことが理解されるであろう。説明または例示された実施形態の変更およびさらなる修正、および明細書に例示された本開示の原理のさらなる適用は、本開示が関連する当業者によって通常行われるように企図される。範囲のすべての制限は、特許請求の範囲に従って説明されているように決定されるべきである。

【0012】

用語が大文字化されているかどうかは、用語の意味の決定または限定とはみなされない。この明細書で使用されているように、大文字の用語は、大文字の用語のより制限的な意味が意図されていることを使用の文脈で具体的に示していない限り、大文字でない用語と同じ意味を有する。しかし、この明細書の残りの部分における大文字の使用またはその欠如は、文脈がそのような制限が意図されていることを明確に示さない限り、必ずしも制限することを意図していない。

【0013】

概要
一実施形態によれば、本開示の態様は、概して、埋め込みＨＴＭＬ文書を使用して、支払い先が支払いデータを処理することなく支払い先ウェブサイトからのオンライン支払い処理を可能にするシステムおよび方法に関する。

【0014】

様々な実施形態では、開示されたｉＦｒａｍｅシステムは、（例えば、インラインフレームまたはｉＦｒａｍｅであり、埋め込まれたＨＴＭＬ文書はｉＦｒａｍｅであり、ｉＦｒａｍｅが埋め込まれたＨＴＭＬ文書は「ｉＦｒａｍｅコンテナ」と呼称される）支払い先ウェブサイト上の別のＨＴＭＬ文書内に埋め込まれたＨＴＭＬ文書を介してオンライン支払いを可能にして、（例えば、マーチャント、公益事業者、政府機関、非営利団体などの）支払い先が支払者の支払いデータ（例えば、クレジットカード情報、銀行口座情報、ブロックチェーンベースの取引情報など）を処理することを要求することなく、支払者（例えば、消費者、構成員、提供者など）は、支払い先ウェブサイト上の取引（購入、公共料金の支払い、罰金、寄付、会費など）のために支払うことができる。この開示では、ｉＦｒａｍｅシステムを使用して受信および処理できる支払いデータの種類に制限はない。概して、ｉＦｒａｍｅによって、支払い先ウェブサイトは、支払いデータを表示することなく、支払いデータを受信して受理することができ、その代わり、支払い処理のために支払いデータを直接的にｉＦｒａｍｅシステムに渡す。様々な実施形態において、支払者がｉＦｒａｍｅを含む支払い先ウェブサイトに支払いデータを入力しているとき、支払者は概してそうするために別のウェブサイトに誘導されず、支払者には支払い先が支払いデータを直接受け取っているように見える。

【0015】

様々な実施形態では、ｉＦｒａｍｅを介して支払いデータが受信された後、ｉＦｒａｍｅシステムは、支払いデータに対応するｅＴｏｋｅｎ（例えば、支払いデータを識別するためにｉＦｒａｍｅシステムと支払い先によって使用される暗号化された識別子）を生成し、それを支払い先に提供する。支払い先は、概して、ｅＴｏｋｅｎを（例えば、取引価格、取引識別子、消費者名、消費者住所などの）他の関連する取引データとともにｉＦｒａｍｅシステムに提供することによって、取引の処理を要求する。従って、様々な実施形態において、ｉＦｒａｍｅシステムは、取引データに対応する適切な支払いデータを決定し、（例えば、クレジットカード会社、銀行、マイナー（miner）などの）適切な支払いネットワークを介して取引を処理する。

【0016】

概して、ｉＦｒａｍｅシステムは、支払い先による支払いデータへのアクセスを防止することによって、取引のセキュリティを強化する（この分離により、適度に信頼される（semi-trusted）ブラウザ環境から発せられるアクションが制限され、検証、暗号化、一時的なストレージに制限され得る）。例えば、ｉＦｒａｍｅを使用すると、支払いデータの取得によって、支払いデータが暗号化されて一時的にのみ格納される適度に信頼されるプロセスから信頼プロセスに変換される。これは、生成されたｅＴｏｋｅｎが支払い先のＡＰＩキー（例えば、支払い先に対応する固有の識別子）と組み合わせた場合にのみ価値があり／有用であるためである。したがって、ハッカーはｉＦｒａｍｅを用いた（ＡＰＩキーへのアクセスの有無で）承認を行うためにトランスペアレントリダイレクト（transparent redirect）を操作することはできない。さらに、ｉＦｒａｍｅシステムは、支払者が別のウェブサイトにアクセスする必要がなく、支払い先が複雑な取引調整プロセスを実行する必要がないため、取引をより効率的にする。さらに、ｉＦｒａｍｅシステムは、支払い先が、消費者から提供された（例えば、名前、住所、連絡先などの）低い機密性のデータの処理をより細かく制御すること、つまり、どのデータを要求するか、どのようにデータを要求するかなどを制御することを可能にする。

【0017】

例示的な実施形態
ここで図面を参照すると、開示されたシステムおよび方法の基本的なプロセスおよびコンポーネントの例および説明のために、ｉＦｒａｍｅシステム３００の一実施形態の例示的な概略図１０００を示す図１が参照される。理解され、認識されるように、図１に示される例示的な概略図１０００は、本システムの特定のアプローチまたは実施形態のみを表し、他の態様は本システムの様々な実施形態に従って使用される。概して、限定ではなく例として、概略図１０００は、ステップ「１」から「５」として示された一連の番号付きステップを用いて図１に示されており、これらのステップは円で注釈が付されている。

【0018】

様々な実施形態では、ｉＦｒａｍｅシステム３００は、支払い先ウェブサイト６０２（例えば、インラインフレームまたはｉＦｒａｍｅ）上の別のＨＴＭＬ文書内に埋め込まれたＨＴＭＬ文書を介してオンライン支払いを可能にして、（例えば、マーチャント、公益事業者、政府機関、非営利団体などの）支払い先６００が支払者１０２の支払いデータ（例えば、クレジットカード情報、銀行口座情報、ブロックチェーンベースの取引情報など）を処理することを要求することなく、支払者１０２（例えば、消費者、構成員、提供者など）は、支払い先ウェブサイト６０２上の取引（購入、公共料金の支払い、罰金、寄付、会費など）のために支払うことができる。概して、ｉＦｒａｍｅによって、支払い先ウェブサイト６０２は、支払いデータを表示することなく、支払いデータを受信して受理することができ、その代わり、支払い処理のために支払いデータを直接的にｉＦｒａｍｅシステム３００に渡す。様々な実施形態において、支払者１０２が開示されるシステムおよび方法を展開したウェブサイト６０２に支払いデータを入力しているとき、支払者１０２は概してそうするために別のウェブサイトに誘導されず、支払者１０２には支払い先６００が支払いデータを直接受け取っているように見える。より詳細な例は、ｉＦｒａｍｅシステム３００を介した支払い処理をさらに説明するのに有用である。

【0019】

特定の非限定的な例では、インターネット１０４上で（例えば、ペット用品、衣類、台所用品などの）アイテムを消費者に直接販売するマーチャント（merchant）６００は、本明細書にさらに開示されるように、ｉＦｒａｍｅシステム３００を介した支払いを受理するために、そのウェブサイト６０２を配置する（deploy）ことができる。概して、この例を続けて、マーチャントの消費者１０２が購入したいアイテムを決定し、自身のオンラインショッピングカートに入れ、注文を完了して支払いをする準備が完了した後、消費者１０２は、マーチャント・ウェブサイト６０２の支払いページに案内される。

【0020】

様々な実施形態において、この支払いページは、消費者１０２がマーチャント・ウェブサイト６０２を介して支払いデータをｉＦｒａｍｅシステム３００に直接入力することを可能にする（ｉＦｒａｍｅシステム３００によって生成される）ｉＦｒａｍｅまたは埋め込みＨＴＭＬ文書を表示する。概して、（ＪａｖａＳｃｒｉｐｔ ＳＤＫを用いた）ｉＦｒａｍｅでは、現在および／またはカスタムのフォント、スタイル、言語、およびレイアウト（これは支払い先ウェブサイト６０２で使用されているものと全て一致し、ｉＦｒａｍｅが支払い先ウェブサイト６０２の他の部分と異なって表示されることはない）を表示できるように、ユーザインタフェースのカスタマイズが可能である。従って、その支払いページでは、ステップ１において、様々な実施形態において、消費者１０２は、選択された支払い方法に応じてｉＦｒａｍｅの提供されたスペースに支払いデータを入力するように指示され、他の関連／必要な低い機密性の支払いデータ（例えば、消費者名、連絡先など）が、ｉＦｒａｍｅの外側のマーチャントのウェブサイト６０２によって収集される。例えば、消費者１０２は、自分のクレジットカード番号、有効期限、およびカード照合値（card verification value）を入力してもよい。その支払いデータは、概して、マーチャント・ウェブサイト６０２上のｉＦｒａｍｅによって、ｅＴｏｋｅｎの生成のためにｉＦｒａｍｅシステム３００のｉＦｒａｍｅコントローラ４００に直接的に供給される。様々な実施形態において、ｅＴｏｋｅｎは、供給された支払いデータを識別するためにｉＦｒａｍｅシステム３００およびマーチャント・ウェブサイト６０２によって使用される暗号化された識別子を含む。様々な実施形態において、消費者が支払いデータを入力すると、支払いデータが、ｅＴｏｋｅｎ生成のために自動的かつリアルタイムでｉＦｒａｍｅコントローラ４００に提供される。代替の実施形態では、支払いデータは、消費者１０２がそうすることを肯定的に確認する（例えば、ステップ３のように「今すぐ支払う」ボタンをクリックする）ときにのみ、ｉＦｒａｍｅコントローラに供給される。ｅＴｏｋｅｎ生成後、ステップ２において、様々な実施形態では、ｅＴｏｋｅｎはマーチャント・ウェブサイト６０２に戻され、マーチャント６００は、それを現在の取引および将来の処理のための他のデータと関連付けてもよい。

【0021】

概して、ステップ２においてｅＴｏｋｅｎを受信した後でかつ消費者がステップ３で肯定確認を行った後に、ステップ４での支払い処理のために、マーチャント・ウェブサイト６０２は、取引データ（例えば、ｅＴｏｋｅｎ、取引価格、取引識別子など）をｉＦｒａｍｅシステム３００内のｅＴｏｋｅｎ取引プロセッサ５００に送信する。従って、ｅＴｏｋｅｎ取引プロセッサ５００は、支払いデータを受信し、一実施形態では、適切な支払いネットワーク１０６（例えば、クレジットカード会社、銀行、マイナーなど）を通じて支払いを処理する。概して、ｅＴｏｋｅｎ取引プロセッサ５００は、後続のアクションのために、マーチャント・ウェブサイト６０２に支払い処理の結果を提供する。例えば、支払いが確認された場合、マーチャント６００は、ステップ５において、マーチャント・ウェブサイト６０２に注文確認ページを提供し、注文されたアイテムを消費者１０２に出荷してもよい。しかし、支払いが確認されない場合、マーチャント６００は、マーチャント・ウェブサイト６０２に取引無効ページを表示して、消費者１０２が新しい支払いデータを提供するか、または取引の処理を再度要求することを可能にする。従って、ｉＦｒａｍｅシステム３００は、マーチャント６００がその取引の支払いデータを視認することなく、マーチャント・ウェブサイト６０２上で支払いを直接的に許可するｉＦｒａｍｅの使用を介してマーチャント・ウェブサイト６０２上でのオンライン支払いを可能にする。

【0022】

次に図２を参照すると、開示されたｉＦｒａｍｅシステム３００の一実施形態の例示的なアーキテクチャ２０００が示されている。様々な実施形態において、例示的なｉＦｒａｍｅシステム３００は、ネットワーク１０４を介して、１つ以上の支払い先システム６００および１つ以上の支払いネットワーク１０６に動作可能に接続される。概して、ネットワーク１０４は、２つ以上のコンピュータシステム間でデータを転送できる任意の接続（例えば、セキュアまたは非セキュア接続、ブルートゥース、無線または有線ローカルエリアネットワーク（ＬＡＮ）、セルネットワーク、インターネットなど）であり得る。図２に示されるように、各ネットワーク１０４は、示された複数の通信のための別個のネットワークであってもよく、またはネットワーク１０４は、すべての通信がルーティングされる単一のネットワークであってもよい。様々な実施形態において、ネットワーク１０４は、暗号化または他の方法を用いたセキュアな通信を可能にする。

【0023】

概して、ｉＦｒａｍｅシステム３００は、本明細書に開示する機能を実行可能な任意のコンピューティングデバイス（例えば、デスクトップ・コンピュータ、ラップトップ、サーバ、タブレットなど）、複数のコンピューティングデバイスの組み合わせ、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせであってもよく、その詳細は、図１および図３の説明に関連して説明される。例示的なｉＦｒａｍｅシステム３００は、様々な実施形態において、ｉＦｒａｍｅコントローラ４００、１つ以上のシステムデータベース２０２、およびｅＴｏｋｅｎ取引プロセッサ５００を含む。一実施形態では、ｉＦｒａｍｅコントローラ４００は、ｅＴｏｋｅｎ生成プロセス（その詳細は、図４の説明に関連して説明される）を実行し、支払い先ウェブサイト６０２およびシステムデータベース２０２と通信し、本明細書に開示される機能を実行可能な任意のコンピューティングデバイス（例えば、デスクトップ・コンピュータ、ラップトップ、サーバ、タブレットなど）、複数のコンピューティングデバイスの組み合わせ、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせであってもよい。一実施形態では、ｅＴｏｋｅｎ取引プロセッサ５００は、ｅＴｏｋｅｎ処理プロセス（その詳細は、図５の説明に関連して説明される）を実行し、１つまたは複数の支払い先サーバ６０４およびシステムデータベース２０２と通信し、本明細書に開示される機能を実行可能な任意のコンピューティングデバイス（例えば、デスクトップ・コンピュータ、ラップトップ、サーバ、タブレットなど）、複数のコンピューティングデバイスの組み合わせ、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせであってもよい。様々な実施形態では、システムデータベース２０２は、任意のコンピューティングデバイス（例えば、デスクトップ・コンピュータ、ラップトップ、サーバ、タブレットなど）、複数のコンピューティングデバイスの組合せ、ソフトウェア、ハードウェア、ソフトウェアとハードウェアの組合せ、データベース（例えば、クラウドまたはオンプレミス（on premise）に格納され、リレーショナルとして構造化されている）、又は本明細書に開示される機能を実行可能な複数のデータベースの組合せであってもよい。

【0024】

様々な実施形態において、例示的な支払い先システム６００は、支払い先ウェブサイト６０２および１つまたは複数の支払い先サーバ６０４を含む。概して、例示的な支払い先システム６００は、ネットワーク１０４を介して、例示的なｉＦｒａｍｅシステム３００および１つまたは複数の消費者システム１０２に動作可能に接続される。概して、例示的な支払い先システム６００は、本明細書に開示する機能を実行可能な任意のコンピューティングデバイス（例えば、デスクトップ・コンピュータ、ラップトップ、サーバ、タブレットなど）、複数のコンピューティングデバイスの組み合わせ、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせであってもよく、その詳細は、図１および図６の説明に関連して説明される。一実施形態では、支払い先ウェブサイト６０２は、本明細書で開示される機能を実行可能なウェブサイト、モバイルアプリケーション、ウェブページ、複数のウェブページの集合、または他のハードウェア／ソフトウェア（またはその組み合わせ）である。一実施形態では、支払い先サーバ６０４は支払い先ウェブサイト６０２をホストし、ｅＴｏｋｅｎ取引プロセッサ５００と通信し、本明細書に開示する機能を実行可能な任意のコンピューティングデバイス（例えば、デスクトップ・コンピュータ、ラップトップ、サーバ、タブレットなど）、複数のコンピューティングデバイスの組み合わせ、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせであってもよい。

【0025】

概して、支払い先ウェブサイト６０２は、ｉＦｒａｍｅシステム３００からｉＦｒａｍｅを受信するｉＦｒａｍｅコンテナ（container）を生成するようにコード化されてもよい。例えば、支払い先ウェブサイト６０２は、支払い先ウェブサイト６０２（例えば、ＨＴＭＬページ）とｉＦｒａｍｅ（例えば、別のＨＴＭＬページ）との間の通信を管理するＪａｖａＳｃｒｉｐｔ ＳＤＫを含み得る。概して、ＳＤＫは、（例えば、プロセス４０００の一部として）ｅＴｏｋｅｎの生成を可能にする。さらに、少なくとも１つの実施形態では、ＳＤＫは、マスクされたデータの送信を可能にする。一実施形態では、ＳＤＫは、支払い先ウェブサイト６０２にｉＦｒａｍｅを自動的に埋め込む。消費者システム１０２上の支払者のインターネットブラウザが、ｉＦｒａｍｅが（例えば、ｉＦｒａｍｅシステム３００に関連付けられた）支払い先ウェブサイト６０２とは異なるドメインからロードされたことを検出すると、様々な実施形態では、ブラウザが、概して通信を特定の組のカスタムコマンドに制限するメカニズムを適用するので、支払い先ウェブサイト６０２に適用されるセキュリティを大幅に増加させる。ＪａｖａＳｃｒｉｐｔ ＳＤＫは概して、複雑なコマンドメッセージを隠す開発者に優しい（developer-friendly）機能を提供する。１つ以上の実施形態によれば、ＳＤＫは、暗号化されたｅＴｏｋｅｎを支払い先に渡す。

【0026】

消費者システム１０２は、一実施形態では、消費者が支払い先ウェブサイト６０２と対話して取引を行うことを可能にし、本明細書に開示する機能を実行可能な任意の装置（例えば、デスクトップ・コンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、スマートウォッチなど）である。当業者には明らかなように、本開示は、本明細書に記載されるように使用される消費者システム１０２のタイプを制限しない。

【0027】

概して、支払いネットワーク１０６は、金融取引を決済し、典型的に、金融機関（例えば、銀行、クレジットカード会社など）によって運営されており、本明細書に開示する機能を実行可能な任意のコンピューティングデバイス（例えば、デスクトップ・コンピュータ、ラップトップ、サーバ、タブレットなど）、複数のコンピューティングデバイスの組み合わせ、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせであってもよい。当業者には明らかなように、本開示は、本明細書に記載されるように使用される支払いネットワーク１０６のタイプを制限しない。

【0028】

次に図３を参照すると、本開示の一実施形態による例示的なｉＦｒａｍｅシステムプロセス３０００のフローチャートが示されている。当業者によって理解されるように、図３に示されるステップおよびプロセス（および明細書に示され説明されている他のすべてのフローチャートおよびシーケンス図）は、同時かつ連続的に実行することができ、典型的には非同期であり、独立しており、必ずしも示される順序で実行されるわけではない。概して、例示的なｉＦｒａｍｅシステムプロセス３０００は、ｉＦｒａｍｅシステム３００が、支払い先ウェブサイト６０２を通じて開始されるオンライン取引の一部として支払いデータを受信および処理するプロセスである。

【0029】

様々な実施形態では、例示的なｉＦｒａｍｅシステムプロセス３０００は、ステップ３０１において開始し、ｉＦｒａｍｅシステム３００は、支払い先ウェブサイト６０２のｉＦｒａｍｅを介して、一つ以上の支払いデータ（例えば、クレジットカード番号、ルーティング番号、有効期限、社会保障番号、ビットコインのアドレスなど）に対応するｅＴｏｋｅｎを生成する要求を受信する。一実施形態では、例示的なｉＦｒａｍｅシステムプロセス３０００は、要求を生成するｉＦｒａｍｅをｉＦｒａｍｅシステム３００が生成／作成したときに開始する（様々な実施形態では、ｉＦｒａｍｅは、ｉＦｒａｍｅシステム３００にリンクしている／ｉＦｒａｍｅシステム６０２がホストしている第１のＨＴＭＬ文書を含み、支払い先ウェブサイトに配置された（ｉＦｒａｍｅコンテナとしても知られる）第２のＨＴＭＬ文書に埋め込まれ、この構造では、支払い先ウェブサイト６０２は、第１のＨＴＭＬ文書によって処理されるデータ（典型的には、支払いデータ）にアクセスできない／視認性を有していない）。様々な実施形態において、ＳＤＫは、支払い先ウェブサイト６０２において支払い先の好みに合わせてスタイル設定されたｉＦｒａｍｅを自動的に生成する設定オプションに対応する。概して、ｅＴｏｋｅｎを生成する要求は、支払いデータがｉＦｒａｍｅに入力されると（またはｉＦｒａｍｅが同じエントリを検出した場合は、ＳＤＫを介して）自動的に生成され、または支払者１０２がそのようにするための肯定的な確認をした（例えば、「今すぐ支払う」ボタンをクリックした）ときに生成される。一実施形態では、要求は、支払いデータを含み得る。一実施形態では、ｉＦｒａｍｅは、要求とは別に支払いデータをｉＦｒａｍｅコントローラ４００に供給し得る。したがって、ｅＴｏｋｅｎを生成するために、様々な実施形態において、ｉＦｒａｍｅシステム３００は、ｉＦｒａｍｅコントローラ４００を介してｅＴｏｋｅｎ生成プロセス４０００を開始し、そのさらなる詳細は、図４の記載に関連して説明される。

【0030】

（プロセス４０００の一部として）ｅＴｏｋｅｎが生成されると、ステップ３０３において、一実施形態では、ｉＦｒａｍｅシステム３００は、関係する特定の取引に関連付けられている（例えば、ＳＤＫのコールバック関数（callback function）を使用してｅＴｏｋｅｎを支払い先サーバ６０４に渡す）場合、ｅＴｏｋｅｎを支払い先システム６００に送信する（例えば、ｅＴｏｋｅｎがｉＦｒａｍｅシステム３００からネットワーク１０４を介して支払い先ウェブサイト６０２上の第１のＨＴＭＬ文書に渡され、第１のＨＴＭＬ文書は、ｅＴｏｋｅｎをｉＦｒａｍｅコンテナに渡し、ｅＴｏｋｅｎはＪａｖａＳｃｒｉｐｔ・ＳＤＫによってピックアップされる（picked up））。様々な実施形態では、ｉＦｒａｍｅシステム３００は、ステップ３０５において取引の支払いを処理する要求を受信する。概して、支払いを処理する要求は、取引に対応する取引データ（請求額、ｅＴｏｋｅｎ、取引識別子、消費者名、消費者連絡先情報など）を含む。従って、取引を処理するために、様々な実施形態では、ｉＦｒａｍｅシステム３００は、ｅＴｏｋｅｎ取引プロセッサ５００を用いてｅＴｏｋｅｎ取引プロセス５０００を開始し、その詳細は図５の記載に関連して説明される。

【0031】

概して、ステップ３０７において、（プロセス５０００の一部として）取引が処理された後、ｉＦｒａｍｅシステム３００は、適切な動作のために取引処理の結果（例えば、確認、拒否、追加情報の要求など）を支払い先システム６００に送信し、例示的なｉＦｒａｍｅシステムプロセス３０００はその後終了する。

【0032】

次に図４を参照すると、本開示の一実施形態による例示的なｅＴｏｋｅｎ生成プロセス４０００を示すフローチャートが示されている。概して、ｅＴｏｋｅｎ生成プロセス４０００は、ｉＦｒａｍｅコントローラ４００が、支払者１０２によって入力された支払いデータを表す／それに対応するｅＴｏｋｅｎを生成するプロセスである。当業者には明らかなように、本開示は、ｉＦｒａｍｅシステム３００（例えば、クレジットカード、デビットカード、銀行口座、暗号通貨（cryptocurrency）など）によって容認される支払いデータのタイプを制限しない。概して、ｅＴｏｋｅｎは、支払者１０２の支払いデータを識別するためにｉＦｒａｍｅシステム３００および支払い先システム６００によって使用される識別子である。一実施形態では、許可されていない第三者がｅＴｏｋｅｎによって示されるデータにアクセス／使用することができないように、ｅＴｏｋｅｎは、暗号化アルゴリズム（例えば、ＲＳＡ、ＡＥＳなど）、セキュアハッシュアルゴリズム（例えば、ＳＨＡ－２５６など）、または他のシステム／方法によって暗号化または他の方法で難読化される。

【0033】

様々な実施形態において、例示的なｅＴｏｋｅｎ生成プロセス４０００は、ステップ４０１において始まり、ｉＦｒａｍｅコントローラ４００は、支払い先ウェブサイト６０２上のｉＦｒａｍｅから支払いデータを受信する。一実施形態では、ｉＦｒａｍｅは、ｉＦｒａｍｅシステム３００に送信する前に、（例えば、クレジットカード番号の適切な長さ、クレジット照合値、ルーティング番号、適切な日付フォーマットなどの特定のフォーマット基準を満たしていることを確認する、必要なすべての支払いデータを有していることを確認する、ボットではなく生の支払者１０２からのものであることを確認するなど）支払いデータを検証する。

【0034】

概して、ステップ４０３において、ｉＦｒａｍｅコントローラ４００は、正しい支払いデータが受信されたこと、および受信された支払いデータが悪意のある攻撃（例えば、ｉＦｒａｍｅになりすましてｉＦｒａｍｅシステム３００に侵入する第三者）ではなかったことを保証するために、（例えば、支払いデータが予期されたフォーマットで受信された、支払いデータが適切な署名によって署名されたなど）受信された支払いデータに対して追加のセキュリティチェックを実行する。

【0035】

支払いデータが追加のセキュリティチェックをパスした場合、一実施形態では、ｉＦｒａｍｅコントローラ４００は、（例えば、暗号化アルゴリズム、セキュアハッシュアルゴリズムなどを使用して）支払いデータを暗号化し、暗号化された支払いデータをシステムデータベース２０２に格納する。さらに、ステップ４０７において、様々な実施形態では、ｉＦｒａｍｅコントローラ４００は、支払いデータに対応するｅＴｏｋｅｎを生成し、そのｅＴｏｋｅｎを暗号化された支払いデータ（および支払い先６００の識別子等の他のデータ）と関連付けてシステムデータベース２０２に格納し、その後、例示的なｅＴｏｋｅｎ生成プロセス４００は終了する。しかし、支払いデータが追加のセキュリティチェックをパスしない場合、ｉＦｒａｍｅコントローラ４００は、様々な実施形態において、ステップ４０９において（例えば、エラーメッセージを送信する、適切なセキュリティ担当者に通知する、支払いデータを監視するなど）適切な動作を行い、その後、例示的なｅＴｏｋｅｎ生成プロセス４００は終了する。

【0036】

次に図５を参照すると、本開示の一実施形態による例示的なｅＴｏｋｅｎ取引プロセス５０００のフローチャートが示されている。概して、ｅＴｏｋｅｎ取引プロセス５０００は、ｅＴｏｋｅｎ取引プロセッサ５００が支払者１０２によって要求された取引を処理するプロセスである。

【0037】

様々な実施形態において、例示的なｅＴｏｋｅｎ取引プロセス５０００はステップ５０１において始まり、ｅＴｏｋｅｎ取引プロセッサ５００は、１つまたは複数の支払い先サーバ６０４から取引データを受信する。概して、ステップ５０３において、ｅＴｏｋｅｎ取引プロセッサ５００は、取引データ（例えば、ｅＴｏｋｅｎ、支払い先など）を検証して正しい取引データが受信されたこと、および受信された取引データが悪意のある攻撃（例えば、第三者が支払い先６００になりすまして偽の支払い等を処理するなど）ではなかったことを確認する。一実施形態では、取引データ（および、特に、ｅＴｏｋｅｎ）が、（例えば、ステップ４０７において）ｅＴｏｋｅｎを生成した後から始まる特定の時間枠（例えば、１分、３分、５分、１０分など）内に受信されない場合、ｅＴｏｋｅｎ取引プロセッサは、取引データを検証しない。

【0038】

取引データが検証された場合、一実施形態では、ｅＴｏｋｅｎ取引プロセッサ５００は、システムデータベース２０２から取引データ内のｅＴｏｋｅｎに対応する支払いデータを検索し（例えば、一実施形態では、まずｅＴｏｋｅｎを最初に復号化して適切なｅＴｏｋｅｎであるかを判定する必要がある）、取引データ内の他の情報に従って、適切な支払いネットワーク１０６を介して取引を処理する。さらに、ステップ５０７において、様々な実施形態において、ｅＴｏｋｅｎ取引プロセッサ５００は、支払い先システム６００への送信のために複数の取引結果（例えば、支払い確認、支払い拒否など）を収集して（compile）、その後、例示的なｅＴｏｋｅｎ取引プロセス５００は終了する。

【0039】

しかし、取引データが検証できない場合、ｅＴｏｋｅｎ取引プロセッサ５００は、様々な実施形態において、ステップ５０９において（例えば、エラーメッセージを送信する、適切なセキュリティ担当者に通知する、エラーを記録するなど）適切な動作を行い、その後、例示的なｅＴｏｋｅｎ取引プロセス５００は終了する。一実施形態では、ステップ５０９で、支払者はエラーデータを再入力することができるように、ｉＦｒａｍｅ内のエラーメッセージが、エラーデータフィールドを空白／強調表示し、残りの正しいデータフィールドを（例えば、完全にまたは部分的に隠されるなど）マスクして支払者に表示される。一実施形態では、エラーフィールドは、（ＪａｖａＳｃｒｉｐｔ ＳＤＫを介して送信される）適切なｅＴｏｋｅｎおよび１つ以上のマスクされたデータオブジェクトから取り込まれる。支払者がデータフィールドのデータを変更しない場合、ｅＴｏｋｅｎおよび１つ以上のマスクされたデータオブジェクトは変更されない。ただし、支払者がデータフィールド内のデータのいずれか（例えば、エラーフィールド、マスクされたフィールドなど）を変更した場合、新しいデータは、新しいｅＴｏｋｅｎおよび／またはマスクされたデータオブジェクトを生成するために使用される。

【0040】

次に図６を参照すると、本開示の一実施形態による例示的な支払い先システムプロセス６０００のフローチャートが示されている。概して、例示的な支払い先システムプロセス６０００は、支払い先システム６００が支払い先ウェブサイト６０２を通じて開始されるオンライン取引の一部として支払い先６００へのオンライン支払いを可能にするプロセスである。

【0041】

様々な実施形態において、例示的な支払い先システムプロセス６０００は、支払い先ウェブサイト６０２がｉＦｒａｍｅを含む支払いページを表示するステップ６０１で始まる。概して、支払者１０２は、コンピューティングデバイスを用いてｉＦｒａｍｅに支払いデータを入力し、ステップ６０３において、検証された場合、支払い先６００は、取引で使用するために入力された支払いデータに対応するｉＦｒａｍｅシステム３００によって生成されたｅＴｏｋｅｎを受け取る。支払い先６００がステップ６０３においてｅＴｏｋｅｎを受信しない場合、一実施形態では、支払い先６００は、支払者１０２にエラーメッセージを送信するか、支払者１０２に追加情報を要求するように構成され得る。

【0042】

概して、ステップ６０５において、１つまたは複数の支払い先サーバ６０４は、支払い先６００がｉＦｒａｍｅシステム３００への適切な支払いデータを特定できるように、ｅＴｏｋｅｎを特定の取引に関連付ける。一実施形態では、ステップ６０７において、１つまたは複数の支払い先サーバ６０４は、取引の支払いを処理する要求を支払者１０２から受け取る。従って、ステップ６０９において、様々な実施形態において、１つまたは複数の支払い先サーバ６０４は、適切な取引データを収集し、取引の支払いを処理する要求をｉＦｒａｍｅシステム３００に送信する。

【0043】

様々な実施形態において、１つまたは複数の支払い先サーバ６０４は、ステップ６１１において取引処理の結果を受信する。一実施形態では、ステップ６１３において、１つまたは複数の支払い先サーバ６０４は、支払い先ウェブサイト６０２上に取引処理の結果（例えば、支払いが成功した場合には注文確認、支払いが成功しなかった場合には追加情報の要求または取引の拒否など）を表示し、その後、例示的な支払い先システムプロセス６０００は終了する。

【0044】

次に図７を参照すると、開示されたｉＦｒａｍｅシステム３００の一実施形態の例示的な代替アーキテクチャ７０００が示されている。概して、例示的な代替アーキテクチャ７０００は、（図２に示される）例示的なアーキテクチャ２０００と同じであり、後述する場合を除き、図２（並びに図３～６）の説明は図７にも適用可能である。様々な実施形態において、例示的なｉＦｒａｍｅシステム３００は、ネットワーク１０４を介して、１つ以上の支払い先システム６００および１つ以上の支払いゲートウェイ（payment gateway）７００に動作可能に接続されて、ｉＦｒａｍｅシステムプロセス３０００を実行する。

【0045】

概して、ｉＦｒａｍｅシステム３００は、ｉＦｒａｍｅコントローラ４００、１つまたは複数のシステムデータベース２０２、およびｅＴｏｋｅｎ暗号解読プロセッサ／サービス５０２を含む。一実施形態では、ｅＴｏｋｅｎ暗号解読プロセッサ５０２は、（一実施形態では、ｅＴｏｋｅｎ取引プロセス５０００の一部として）複数のｅＴｏｋｅｎを復号化し、１つまたは複数の支払い先サーバ６０４、システムデータベース２０２および１つまたは複数のゲートウェイサーバ７０２と通信し、本明細書に開示される機能を実行可能な任意のコンピューティングデバイス（例えば、デスクトップ・コンピュータ、ラップトップ、サーバ、タブレットなど）、複数のコンピューティングデバイスの組み合わせ、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせであってもよい。

【0046】

様々な実施形態では、支払いゲートウェイ７００は、複数の支払い（複数のクレジットカード支払い、直接支払いなど）を処理し、および／または支払いネットワーク１０６のためにシステム（例えば、ｉＦｒａｍｅシステム３００、支払い先システム６００等）と通信する第三者システムである。概して、支払いゲートウェイ７００は、１つまたは複数のゲートウェイサーバ７０２を含む。一実施形態では、支払いゲートウェイ７００は、支払いネットワーク１０６、ｉＦｒａｍｅシステム３００、および支払い先システム６００と通信する。様々な実施形態では、支払いゲートウェイ７００および１つまたは複数のゲートウェイサーバ７０２は、本明細書に開示する機能を実行可能な任意のコンピューティングデバイス（例えば、デスクトップ・コンピュータ、ラップトップ、サーバ、タブレットなど）、複数のコンピューティングデバイスの組み合わせ、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせであってもよい。一実施形態では、支払いネットワーク１０６は、支払いゲートウェイ７００を備え、支払いゲートウェイ７００は、支払いネットワーク１０６の外部の複数のシステム（例えば、ｉＦｒａｍｅシステム３００、支払い先システム６００等）とインタフェースする。

【0047】

図７に示される実施形態を続行すると、システムデータベース２０２は、（例えば、ｉＦｒａｍｅコントローラ４００から受信された）暗号化されたカード名義人データを保持する。様々な実施形態では、支払い先サーバ６０４は、（例えば、少なくとも１つの実施形態では、消費者の名前、住所などの追加の非機密性の取引データを用いて、例えば、支払い先システムプロセス６０００のステップ６０９において）１つまたは複数のゲートウェイサーバ７０２にｅＴｏｋｅｎを送信する。これらの実施形態では、１つまたは複数のゲートウェイサーバ７０２は、次に、ｅＴｏｋｅｎをｅＴｏｋｅｎ復号化プロセッサ５０２に送信し、（例えば、ｅＴｏｋｅｎを復号化すること、有効なｅＴｏｋｅｎであることを確認すること、有効な時間枠内にｅＴｏｋｅｎが受信されたことを確認することなど）ｅＴｏｋｅｎが検証され、暗号化されたカード名義人データがシステムデータベース２０２から取り出され（またはその他の方法で受信され）、カード名義人データが復号化されて１つまたは複数のゲートウェイサーバ７０２に送り返される。理解されるように、１つまたは複数のゲートウェイサーバ７０２が暗号化されていないカード名義人データを受信すると、支払いゲートウェイ７００は、（例えば、ｅＴｏｋｅｎ取引プロセス５０００のステップ５０３～５０９において）支払いネットワーク１０６を介してカード名義人データを処理し、処理の結果を支払い先サーバ６０４に報告し得る。

【0048】

上記から、本明細書で説明されるプロセスの様々な態様は、システムの複数の部分を形成する複数のコンピュータシステム上で実行される複数のソフトウェアプロセスであることを理解されたい。従って、本明細書に記載されるシステムの様々な実施形態は、概して、様々なコンピュータハードウェアコンポーネントを含む特別に構成されたコンピュータとして具体化され、多くの場合、本明細書にさらに詳細に説明されるように、従来のまたは既知のコンピュータ、プロセス等と比較して、重要な追加の特徴を有することが理解されるであろう。本開示の範囲内の実施形態はまた、複数のコンピュータ実行可能命令または複数のデータ構造を搬送するかまたは有するためのコンピュータ可読媒体を含む。そのようなコンピュータ可読媒体は、コンピュータによってアクセス可能であるか、または通信ネットワークを介してダウンロード可能な任意の利用可能な媒体であり得る。一例として、限定するものではないが、このようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭ、ＤＶＤ、または他の光ディスク記憶装置、磁気ディスク記憶装置、ソリッドステートドライブ（solid state drives : SSDs）、他のデータ記憶装置、セキュアデジタル（secure digital : SD）、フラッシュメモリ、メモリスティックなどの任意のタイプの取外し可能な不揮発性メモリ、またはコンピュータ実行可能な命令またはデータ構造の形態でコンピュータプログラムコードを転送または記憶するために使用することができ、コンピュータによってアクセス可能な任意の他の媒体を含み得る。

【0049】

ネットワークまたは別の通信接続（有線、無線、または有線または無線の組み合わせ）を介して情報がコンピュータに転送または提供されると、コンピュータは、その接続をコンピュータ可読媒体として適切に認識する。従って、そのような接続は、適切にコンピュータ可読媒体と呼ばれ、コンピュータ可読媒体とみなされる。上記した組み合わせも、コンピュータ可読媒体の範囲内に含まれるべきである。コンピュータ実行可能命令は、例えば、コンピュータに特定の機能または１群の機能を実行させる命令およびデータを含む。

【0050】

当業者は、本開示の態様が実装され得る適切なコンピューティング環境の特徴および態様を理解するであろう。必須ではないが、特許請求の範囲に記載されたシステムのいくつかの実施形態は、先に説明したように、ネットワーク化された環境においてコンピュータによって実行されるプログラムモジュールまたはエンジンなどのコンピュータ実行可能命令の文脈で説明され得る。そのようなプログラムモジュールは、フローチャート、シーケンス図、例示的な画面表示、およびそのようなコンピュータプログラムモジュールを作成および使用する方法を通信するために当業者によって使用される他の技術によって、しばしば反映および示される。概して、プログラムモジュールは、コンピュータ内で特定のタスクを実行するか、または特定の定義されたデータタイプを実装するローカルまたはリモートなどの他のコンピュータに対するルーチン、プログラム、関数、オブジェクト、コンポーネント、データ構造、アプリケーションプログラミングインタフェース（application programming interface : API）コールを含む。コンピュータ実行可能命令、関連するデータ構造および／またはスキーマ、およびプログラムモジュールは、本明細書で開示される方法のステップを実行するためのプログラムコードの複数の例を示す。そのような実行可能な命令または関連するデータ構造の特定のシーケンスは、そのようなステップで説明される機能を可能にするための対応する複数の動作の例を示す。

【0051】

当業者はまた、特許請求の範囲に記載されたおよび／または説明されたシステムおよび方法が、パーソナルコンピュータ、スマートフォン、タブレット、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家電製品、ネットワーク化されたＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む多くのタイプのコンピュータシステム構成を有するネットワークコンピューティング環境において実施され得ることを理解するであろう。特許請求の範囲に記載されたシステムの実施形態（および／または方法）は、複数のタスクが、（ハードワイヤードリンク、ワイヤレスリンク、またはハードワイヤードリンクとワイヤレスリンクの組み合わせによって）通信ネットワークを介してリンクされたローカル処理デバイスおよびリモート処理デバイスによって実行される分散コンピューティング環境において実施される。分散コンピューティング環境では、複数のプログラムモジュールは、ローカルとリモートの両方のメモリ記憶装置に配置され得る。

【0052】

説明されていない動作の様々な態様を具体化するための例示的なシステムは、処理ユニット、システムメモリ、およびシステムメモリを含む様々なシステムコンポーネントを処理ユニットに結合するシステムバスを含むコンピューティングデバイスを含む。コンピュータは、典型的には、データを読み書きするための１つ以上のデータ記憶装置を含む。データ記憶装置は、コンピュータによって実行可能な命令、データ構造、プログラムモジュール、およびコンピュータのためのその他のデータの不揮発性記憶装置を提供する。

【0053】

本明細書で説明される機能を具体化するコンピュータプログラムコードは、典型的には、データ記憶装置に格納される１つまたは複数のプログラムモジュールを含む。このプログラムコードは、当業者に知られているように、典型的には、オペレーティングシステム、１つまたは複数のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータを含む。ユーザは、キーボード、タッチスクリーン、ポインティングデバイス、スクリプト言語で記述されたコンピュータプログラムコードを含むスクリプト、またはマイクなどの他の入力デバイス（図示せず）を介して、コンピュータにコマンドと情報を入力できる。これらおよびその他の入力デバイスは、多くの場合、既知の電気接続、光学接続、または無線接続を介して処理ユニットに接続される。

【0054】

説明したプロセスの多くの態様に影響を与えるコンピュータは、典型的には、以下にさらに説明する１つまたは複数のリモートコンピュータまたはデータソースへの論理接続を使用して、ネットワーク化された環境において動作する。リモートコンピュータは、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることができ、典型的には、システムが具体化されるメインコンピュータシステムに関して上述した要素の多くまたは全てを含む。複数のコンピュータ間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、仮想ネットワーク（ＷＡＮまたはＬＡＮ）、および無線ＬＡＮ（ＷＬＡＮ）を含み、これらは明細書において例として示されているが、これらに限定されるものではない。このようなネットワーク環境は、オフィス全体または企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。

【0055】

ＬＡＮまたはＷＬＡＮネットワーク環境で使用される場合、システムの態様を具体化するコンピュータシステムは、ネットワークインタフェースまたはアダプタを介してローカルネットワークに接続される。ＷＡＮまたはＷＬＡＮネットワーク環境で使用される場合、コンピュータは、モデム、ワイヤレスリンク、またはインターネットなどの広域ネットワーク上で通信を確立するための他のメカニズムを含んでもよい。ネットワーク化された環境では、コンピュータに関連して示されたプログラムモジュールまたはその一部は、遠隔データ記憶装置に記憶されてもよい。説明または図示されたネットワーク接続は例示的なものであり、広域ネットワークまたはインターネットを介して通信を確立する他の機構を使用してもよいことが理解されよう。

【0056】

代替的な態様
次に、本システムおよび方法の様々な態様について説明する。以下の複数の態様のいずれかが、以下に記載される他の態様または本明細書に記載される特徴を組み込み、含むことができることは、当業者によって理解されるであろう。従って、以下の複数の態様は、態様の任意の組み合わせを含むと理解されるべきであり、以下に提示される組み合わせに限定されるべきではない。例えば、第２の態様は第１の態様のコンピュータシステムを含むが、第２６の態様、第１の態様、または第１００の態様の特徴も含み得る。

【0057】

第１の態様に従ったシステムは、ｉＦｒａｍｅコントローラであって、サーバ上でホストされているマーチャント・ウェブサイトでｉＦｒａｍｅを作成すること、マーチャント・ウェブサイトでの取引に対応する支払いデータをｉＦｒａｍｅから受信すること、受信した支払いデータを暗号化して格納すること、暗号化された支払いデータに対応するｅＴｏｋｅｎを生成すること、ｅＴｏｋｅｎをサーバに送信することであって、サーバは、ｅＴｏｋｅｎを支払いゲートウェイサーバに送信する、ｅＴｏｋｅｎをサーバに送信すること、を実行するｉＦｒａｍｅコントローラと、ｅＴｏｋｅｎ復号化プロセッサであって、支払いゲートウェイサーバからｅＴｏｋｅｎを受信すること、ｅＴｏｋｅｎを認証して、対応する暗号化された支払いデータを決定すること、暗号化された支払いデータを復号化すること、取引を処理するために、復号化された支払いデータを支払いゲートウェイサーバに送信すること、を実行するｅＴｏｋｅｎ復号化プロセッサと、を備える。

【0058】

第２の態様に従った、第１の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅは、第２のＨＴＭＬ文書内に埋め込まれた第１のＨＴＭＬ文書を含む。
第３の態様に従った、第１の態様または任意の他の態様のシステムまたは方法において、受信した支払いデータは、クレジットカード番号、クレジットカード有効期限、クレジットカード照合値、銀行口座ルーティング番号、デビットカード番号、デビットカード有効期限、またはＰＩＮ番号のうちの少なくとも１つを含む。

【0059】

第４の態様に従った、第３の態様または任意の他の態様のシステムまたは方法において、支払いデータは、マーチャント・ウェブサイトまたはサーバによりアクセス可能ではない。

【0060】

第５の態様に従った、第１の態様または任意の他の態様のシステムまたは方法において、支払いゲートウェイサーバおよびｉＦｒａｍｅコントローラは、サーバとは別個に管理される。

【0061】

第６の態様に従った、第１の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅコントローラは、ｅＴｏｋｅｎをサーバに送信する前にｅＴｏｋｅｎを暗号化する。

【0062】

第７の態様に従った、第６の態様または任意の他の態様のシステムまたは方法において、ｅＴｏｋｅｎ復号化プロセッサは、ｅＴｏｋｅｎを認証する前にｅＴｏｋｅｎを復号化する。

【0063】

第８の態様に従った、第１の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅは、マーチャント・ウェブサイト上のフォントまたはテキストスタイルに一致する１つまたは複数のフォントまたはテキストスタイルを含む。

【0064】

第９の態様に従った、第８の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅコントローラは、ｉＦｒａｍｅを作成するためのユーザ入力に基づいて、マーチャント・ウェブサイト上のフォントまたはテキストスタイルを実質的に自動的に一致させるように構成される。

【0065】

第１０の態様に従った、第１の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅコントローラは、マーチャントが複数のｉＦｒａｍｅパラメータを入力することを可能にするｉＦｒａｍｅビルダーユーザインタフェースからの入力に少なくとも部分的に基づいてｉＦｒａｍｅを作成する。

【0066】

第１１の態様に従った、第１０の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅビルダーユーザインタフェースは、マーチャントがマーチャント・ウェブサイト上のフォントおよびテキストスタイルのうちの少なくとも１つを一致させることを可能にするコマンドを含む。

【0067】

第１２の態様に従った方法は、サーバ上でホストされているマーチャント・ウェブサイトでｉＦｒａｍｅを作成すること、マーチャント・ウェブサイトでの取引に対応する支払いデータをｉＦｒａｍｅから受信すること、受信した支払いデータを暗号化すること、暗号化された支払いデータを格納すること、暗号化された支払いデータに対応するｅＴｏｋｅｎを生成すること、ｅＴｏｋｅｎをサーバに送信することであって、サーバは、ｅＴｏｋｅｎを支払いゲートウェイサーバに送信する、ｅＴｏｋｅｎをサーバに送信すること、支払いゲートウェイサーバからｅＴｏｋｅｎを受信すること、ｅＴｏｋｅｎを認証して、対応する暗号化された支払いデータを決定すること、暗号化された支払いデータを復号化すること、取引を処理するために、復号化された支払いデータを支払いゲートウェイサーバに送信すること、を備える。

【0068】

第１３の態様に従った、第１２の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅは、第２のＨＴＭＬ文書内に埋め込まれた第１のＨＴＭＬ文書を含む。

【0069】

第１４の態様に従った、第１２の態様または任意の他の態様のシステムまたは方法において、受信した支払いデータは、クレジットカード番号、クレジットカード有効期限、クレジットカード照合値、銀行口座ルーティング番号、デビットカード番号、デビットカード有効期限、またはＰＩＮ番号のうちの少なくとも１つを含む。

【0070】

第１５の態様に従った、第１２の態様または任意の他の態様のシステムまたは方法において、支払いデータは、マーチャント・ウェブサイトまたはサーバによりアクセス可能ではない。

【0071】

第１６の態様に従った、第１２の態様または任意の他の態様のシステムまたは方法において、支払いゲートウェイサーバは、サーバとは別個に管理される。
第１７の態様に従った、第１２の態様または任意の他の態様のシステムまたは方法において、ｅＴｏｋｅｎをサーバに送信する前にｅＴｏｋｅｎを暗号化することをさらに備える。

【0072】

第１８の態様に従った、第１２の態様または任意の他の態様のシステムまたは方法において、ｅＴｏｋｅｎを認証する前にｅＴｏｋｅｎを復号化することをさらに備える。
第１９の態様に従ったシステムは、サーバ上でホストされるウェブサイトであって、該ウェブサイトは、ｉＦｒａｍｅを含み、該ｉＦｒａｍｅは、ウェブサイト上での取引に対応する支払いデータを受信し、ｉＦｒａｍｅコントローラによって生成される、ウェブサイトと、サーバであって、ｉＦｒａｍｅコントローラから受信した支払いデータに対応するｅＴｏｋｅｎを受信すること、取引に対応し且つｅＴｏｋｅｎおよび非機密性の支払いデータを含む取引データを生成すること、取引を処理するために、取引データを支払いゲートウェイサーバに送信すること、支払いゲートウェイサーバから少なくとも１つの処理結果を受信すること、を実行するサーバと、を備える。

【0073】

第２０の態様に従った、第１９の態様または任意の他の態様のシステムまたは方法において、支払いゲートウェイサーバは、ｉＦｒａｍｅコントローラに動作可能に接続されたｅＴｏｋｅｎ復号化プロセッサにｅＴｏｋｅｎを送信し、データベースは、受信した支払いデータを格納する。

【0074】

第２１の態様に従った、第２０の態様または任意の他の態様のシステムまたは方法において、ｅＴｏｋｅｎをｅＴｏｋｅｎ復号化プロセッサに送信することに応答して、支払いゲートウェイサーバは、受信した支払いデータを受信する。

【0075】

第２２の態様に従った、第１９の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅは、第２のＨＴＭＬ文書内に埋め込まれた第１のＨＴＭＬ文書を含む。

【0076】

第２３の態様に従った、第１９の態様または任意の他の態様のシステムまたは方法において、受信した支払いデータは、クレジットカード番号、クレジットカード有効期限、クレジットカード照合値、銀行口座ルーティング番号、デビットカード番号、デビットカード有効期限、またはＰＩＮ番号のうちの少なくとも１つを含む。

【0077】

第２４の態様に従った、第２３の態様または任意の他の態様のシステムまたは方法において、支払いデータは、ウェブサイトまたはサーバによりアクセス可能ではない。
第２５の態様に従った、第２４の態様または任意の他の態様のシステムまたは方法において、非機密性の支払いデータは、取引識別子、取引価格、および連絡先情報のうちの少なくとも１つを含む。

【0078】

第２６の態様に従った、第２５の態様または任意の他の態様のシステムまたは方法において、支払いゲートウェイサーバは、サーバとは別個に管理される。
第２７の態様に従った方法は、ｉＦｒａｍｅを含むウェブサイトをホストすることであって、ｉＦｒａｍｅは、ウェブサイト上での取引に対応する支払いデータを受信する、ホストすること、受信した支払いデータに対応するｅＴｏｋｅｎを受信すること、取引に対応し且つｅＴｏｋｅｎおよび非機密性の支払いデータを含む取引データを生成すること、取引を処理するために、取引データを送信すること、少なくとも１つの処理結果を受信すること、を備える。

【0079】

第２８の態様に従った、第２７の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅは、第２のＨＴＭＬ文書内に埋め込まれた第１のＨＴＭＬ文書を含む。

【0080】

第２９の態様に従った、第２８の態様または任意の他の態様のシステムまたは方法において、受信した支払いデータは、クレジットカード番号、クレジットカード有効期限、クレジットカード照合値、銀行口座ルーティング番号、デビットカード番号、デビットカード有効期限、またはＰＩＮ番号のうちの少なくとも１つを含む。

【0081】

第３０の態様に従った、第２９の態様または任意の他の態様のシステムまたは方法において、支払いデータは、ウェブサイトによりアクセス可能ではない。
第３１の態様に従った、第３０の態様または任意の他の態様のシステムまたは方法において、非機密性の支払いデータは、取引識別子、取引価格、および連絡先情報のうちの少なくとも１つを含む。

【0082】

第３２の態様に従ったシステムは、ｉＦｒａｍｅコントローラであって、サーバ上でホストされているマーチャント・ウェブサイトでｉＦｒａｍｅを作成すること、マーチャント・ウェブサイトでの取引に対応する支払いデータをｉＦｒａｍｅから受信すること、受信した支払いデータに対応するｅＴｏｋｅｎを生成すること、ｅＴｏｋｅｎをサーバに送信すること、を実行するｉＦｒａｍｅコントローラと、ｅＴｏｋｅｎ取引プロセッサであって、サーバから、取引に対応し且つｅＴｏｋｅｎおよび非機密性の支払いデータを含む取引データを受信すること、ｅＴｏｋｅｎを認証して、対応する受信した支払いデータを決定すること、受信した支払いデータを用いて、受信した取引データに基づいて取引を処理すること、を実行するｅＴｏｋｅｎ取引プロセッサと、を備える。

【0083】

第３３の態様に従った、第３２の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅは、第２のＨＴＭＬ文書内に埋め込まれた第１のＨＴＭＬ文書を含む。

【0084】

第３４の態様に従った、第３２の態様または任意の他の態様のシステムまたは方法において、受信した支払いデータは、クレジットカード番号、クレジットカード有効期限、クレジットカード照合値、銀行口座ルーティング番号、デビットカード番号、デビットカード有効期限、またはＰＩＮ番号のうちの少なくとも１つを含む。

【0085】

第３５の態様に従った、第３４の態様または任意の他の態様のシステムまたは方法において、支払いデータは、マーチャント・ウェブサイトまたはサーバによりアクセス可能ではない。

【0086】

第３６の態様に従った、第３２の態様または任意の他の態様のシステムまたは方法において、非機密性の支払いデータは、取引識別子、取引価格、および連絡先情報のうちの少なくとも１つを含む。

【0087】

第３７の態様に従った、第３２の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅコントローラは、ｅＴｏｋｅｎをサーバに送信する前にｅＴｏｋｅｎを暗号化する。

【0088】

第３８の態様に従った、第３７の態様または任意の他の態様のシステムまたは方法において、ｅＴｏｋｅｎ取引プロセッサは、ｅＴｏｋｅｎを認証する前にｅＴｏｋｅｎを復号化する。

【0089】

第３９の態様に従った、第３２の態様または任意の他の態様のシステムまたは方法において、ｅＴｏｋｅｎ取引プロセッサは、取引を処理するために、支払いデータおよび取引データの少なくとも一部を支払いネットワークに送信する。

【0090】

第４０の態様に従った方法は、サーバ上でホストされているマーチャント・ウェブサイトでｉＦｒａｍｅを作成すること、マーチャント・ウェブサイトでの取引に対応する支払いデータをｉＦｒａｍｅから受信すること、受信した支払いデータに対応するｅＴｏｋｅｎを生成すること、ｅＴｏｋｅｎをサーバに送信すること、サーバから、取引に対応し且つｅＴｏｋｅｎおよび非機密性の支払いデータを含む取引データを受信すること、ｅＴｏｋｅｎを認証して、対応する受信した支払いデータを決定すること、受信した支払いデータを用いて、受信した取引データに基づいて取引を処理すること、を備える。

【0091】

第４１の態様に従った、第４０の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅは、第２のＨＴＭＬ文書内に埋め込まれた第１のＨＴＭＬ文書を含む。

【0092】

第４２の態様に従った、第４０の態様または任意の他の態様のシステムまたは方法において、受信した支払いデータは、クレジットカード番号、クレジットカード有効期限、クレジットカード照合値、銀行口座ルーティング番号、デビットカード番号、デビットカード有効期限、またはＰＩＮ番号のうちの少なくとも１つを含む。

【0093】

第４３の態様に従った、第４２の態様または任意の他の態様のシステムまたは方法において、支払いデータは、マーチャント・ウェブサイトまたはサーバによりアクセス可能ではない。

【0094】

第４４の態様に従った、第４０の態様または任意の他の態様のシステムまたは方法において、非機密性の支払いデータは、取引識別子、取引価格、および連絡先情報のうちの少なくとも１つを含む。

【0095】

第４５の態様に従った、第４０の態様または任意の他の態様のシステムまたは方法において、ｅＴｏｋｅｎをサーバに送信する前にｅＴｏｋｅｎを暗号化することをさらに備える。

【0096】

第４６の態様に従った、第４５の態様または任意の他の態様のシステムまたは方法において、ｅＴｏｋｅｎを認証する前にｅＴｏｋｅｎを復号化することをさらに備える。
第４７の態様に従った、第４０の態様または任意の他の態様のシステムまたは方法において、取引を処理することは、取引を処理するために、支払いデータおよび取引データの少なくとも一部を支払いネットワークに送信すること、をさらに含む。

【0097】

第４８の態様に従ったシステムは、サーバ上でホストされるウェブサイトであって、該ウェブサイトは、ｉＦｒａｍｅを含み、該ｉＦｒａｍｅは、ウェブサイト上での取引に対応する支払いデータを受信し、ｉＦｒａｍｅコントローラによって生成される、ウェブサイトと、サーバであって、ｉＦｒａｍｅコントローラから受信した支払いデータに対応するｅＴｏｋｅｎを受信すること、取引に対応し且つｅＴｏｋｅｎおよび非機密性の支払いデータを含む取引データを生成すること、取引を処理するために、取引データをｅＴｏｋｅｎ取引プロセッサに送信すること、ｅＴｏｋｅｎ取引プロセッサから少なくとも１つの処理結果を受信すること、を実行するサーバと、を備える。

【0098】

第４９の態様に従った、第４８の態様または任意の他の態様のシステムまたは方法において、ｉＦｒａｍｅは、第２のＨＴＭＬ文書内に埋め込まれた第１のＨＴＭＬ文書を含む。

【0099】

第５０の態様に従った、第４８の態様または任意の他の態様のシステムまたは方法において、受信した支払いデータは、クレジットカード番号、クレジットカード有効期限、クレジットカード照合値、銀行口座ルーティング番号、デビットカード番号、デビットカード有効期限、またはＰＩＮ番号のうちの少なくとも１つを含む。

【0100】

第５１の態様に従った、第５０の態様または任意の他の態様のシステムまたは方法において、支払いデータは、ウェブサイトまたはサーバによりアクセス可能ではない。
第５２の態様に従った、第４８の態様または任意の他の態様のシステムまたは方法において、非機密性の支払いデータは、取引識別子、取引価格、および連絡先情報のうちの少なくとも１つを含む。

【0101】

結論
種々の態様が好ましい実施形態に関連して説明されてきたが、特許請求の範囲に記載されたシステムの追加の態様、特徴、および方法は、当業者によって、本明細書の説明から容易に識別できるであろう。本明細書に記載されたもの以外の開示および特許請求の範囲に記載されたシステムの多くの実施形態および適応、ならびに多くの変形、改変、および同等の構成および方法は、特許請求の範囲の内容または範囲から逸脱することなく、本開示およびその前述の説明から明らかになるか、または本開示およびその説明によって合理的に示唆されるであろう。さらに、本明細書に記載され、特許請求の範囲に記載されている様々なプロセスの複数のステップの任意のシーケンスおよび／または時間的順序は、特許請求の範囲に記載されているシステムを実行するために考えられる最良のモードであると考えられるものである。様々なプロセスの複数のステップは、好ましいシーケンスまたは時間的順序であるとして示され、説明されてもよいが、そのようなプロセスの複数のステップは、特定の意図された結果を達成するためのそのような特定の指示がない限り、特定のシーケンスまたは順序で実行されることに限定されないことも理解されたい。多くの場合、そのようなプロセスの複数のステップは、様々な異なるシーケンスおよび順序で実施され得るが、依然として特許請求の範囲に記載されたシステムの範囲内にある。さらに、いくつかのステップは、同時に、同じ期間に、または他のステップと同期して実施されてもよい。

【0102】

当業者がシステム及び種々の実施形態を使用することを可能にするように、請求されたシステムの原理及びそれらの実際の用途を説明するために、実施形態を選んで記載し、種々の変更形態が、意図される特定の使用に適している。請求されたシステムの主旨及び範囲から逸脱することなく、システムが属する分野の当業者には代替的な実施形態が明らかであろう。したがって、請求されたシステムの範囲は、上記の記載及び上記の記載において記載されている例示的な実施形態ではなく、添付の特許請求の範囲によって規定される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】