JP6727352B2 - データ検証のためのウェブページ生成 - Google Patents

Description

本発明はコンピュータユーザへウェブコンテンツを伝送する方法に関する。特に、本発明はコンピュータユーザが第三者による検証のためにデータ提供するときにコンピュータユーザへウェブコンテンツを伝送することに関する。

コンピュータユーザが検証のためのウェブサイト提供者へデータを提供する必要がある例は多い。しかし検証は第三者によってどこで実行されるか。検証は、ユーザのアイデンティティが認証される認証処理の一部であってよいし、認証処理（ここでは人が認証されてなにか（例えばウェブサイトへのアクセス又はトランザクションの実行）を行うことができる）の一部であってよい。第三者を使用してデータを検証することは、ウェブサイト提供者が技術的又は商用的理由で、検証を外注したいからである。代替的に、データは機密的であってよいし、コンピュータユーザはそのデータをウェブサイト提供者と共有したくないかもしれない。例えば機密データ（例えばパスワード又は個人情報）は、使用限定のある状態でウェブサイトへアクセスすることを要求されてよい。その理由は例えば、そのウェブサイトのコンテンツの性質又は価値による。また、金融トランザクションをウェブサイト上で実行するには、支払が行われることが必要である。典型的には、これらのトランザクションは、販売者ではなく金融機関によって実装される。また、データは適切な金融機関へ提供されて、トランザクションの承認を許可し、次いでトランザクションを調整する必要がある。また、安全性の関係もある。というのもユーザは機密金融データを販売者へ開示したくないかもしれないからである。出願人にとって特に関心のあるものが本願である。下記の記述が本願に関する。しかし、本発明は金融トランザクションを承認する分野のみでの出願に限定されないことと、データ検証が要求される他の広い範囲の分野で使用されてもよいこととを理解されたい。

インターネット上で購入を行うとき、コンピュータユーザは販売者のウェブサイトを閲覧する。通常又は周知の通り、ユーザが商品又は役務を購入したいとき、ユーザは品目を選択する。それは「買い物かご」又は「ショッピングカート」に転送される。ユーザが商品又は役務の閲覧を完了すると、ユーザは通常、「決済」の選択肢を選択する。これが完了すると、販売者のサーバは決済ウェブページを提示する。ユーザが、表示された商品又は役務を購入したいことを確認すると、支払が調整される。一般にこれには、ユーザと金融機関との両方を代理してトランザクションの承認が要求される。金融機関はBarclays（登録商標）等の銀行、Mastercard（登録商標）等のカード提供者、又はPaypal（登録商標）等の支払サービス提供者であってよい。以下、金融機関は支払承認代理人として参照される。したがって販売者のサーバは支払承認代理人と相互作用して、支払が承認及び有効化されることを許可しなくてはならない。

支払が承認されるために、ユーザは機密の金融情報を支払承認代理人へ提供しなくてはならない。支払がデビットカード又はクレジットカードによるものであれば、この情報はカード番号、有効期限日及びCVV（カード検証値）に対応する。もし支払が銀行により移転されるなら、情報は種別コード及びアカウント番号に対応してよい。この情報は支払承認代理人に利用可能でなければならないし、異なる方法で実行されてよい。

最初のスキームでは、販売者のサーバはウェブページを提供してよい。ここではコンピュータユーザは、トランザクションを承認する方法によって自身の金融情報を提供しなければならず、トランザクションが支払承認代理人によって承認されることを可能にする。販売者のサーバは次いでユーザの金融情報を、支払承認代理人によってホストされるサーバへ渡してよい。支払承認代理人は次いでユーザの金融情報を検証してよい。もし検証が成功すれば、支払承認代理人は支払を承認し、関連する資金移転が実行されるよう調整する。このときユーザは十分な資金又は信用を有していると想定する。支払承認代理人のサーバは、支払が両当事者によって承認されたことの確認を販売者のサーバへ送信してよい。もし承認が失敗すれば、支払承認代理人のサーバは、失敗通知を販売者のサーバへ送信してよい。販売者のサーバが支払承認代理人のサーバから返信を受信すると、販売者のサーバは新たなウェブページをコンピュータユーザへ提示し、トランザクションが承認されたことを確認し、又はトランザクションが承認されなかったことを示す。

そのような構成は販売者によって有用である。販売者はウェブページに対する制御を維持するので、コンピュータユーザの閲覧体験を維持する。したがって販売者は望むとおりにウェブページを提示することができるし、例えば自身のブランドを提示し又は整った且つ論理的な方法で情報を提供することができる。これにより、コンピュータユーザの関与を維持することでき、ウェブページが信頼済みであることの安心感を提供することができる。また販売者はウェブページの機能を制御すること（例えばどのリンクを提供するか、どの制御要素を無効にするか、安全（セキュリティ）証明書を提示するか、等）ができる。しかし、そのような構成は、コンピュータユーザが販売者へ機密の金融情報を提供しなければないことを意味する。これは一般的には消費者に好まれない。消費者は自身の金融情報をなるべく少ない当事者にのみ共有したいことと、消費者はその情報を支払承認代理人のみに共有したいことが知られている。ユーザが情報を販売者に共有したくない理由は、安全リスクが増大しているという基礎的な信仰による。

別のスキームでは、販売者のサーバはコンピュータユーザを、支払承認代理人のサーバによってホストされるウェブサイトへリダイレクトする。次いで支払承認代理人のサーバはウェブページを提供し、ここではユーザの機密の金融情報が入力されてよい。第１のスキームにおいては、支払承認代理人のサーバは次いで、入力された金融情報を検証し、トランザクションを承認し、承認結果を販売者のサーバに通知してよい。支払承認代理人のサーバは次いで、コンピュータユーザを、販売者のサーバによってホストされるウェブサイトへ返す。第１のスキームにおいて、販売者のサーバは次いで新たなウェブページをコンピュータユーザへ提示し、トランザクションが承認されたことを確認し、又はトランザクションが承認されなかったことを示す。

この構成は、金融情報を支払承認代理人のみに共有したいという消費者の好みを充足する。というもも消費者は、支払承認代理人のサーバに接続されているときのみ、この情報を入力するからである。支払承認代理人によってウェブページを提示することは、ユーザ部分に対する高度の信頼を可能にする。更にユーザは支払承認代理人のウェブページの安全性証明書を確認してよい。しかし、この構成は販売者によって好まれない。というのも販売者は、金融情報が提供されるウェブページに対する全ての制御を失うからである。これは、閲覧体験を行っている消費者を維持する販売者のブランディングを提示することを含む。コンピュータユーザの観点から見れば、異なるウェブページ提示と状況変更とは、解放と、レイアウト（構成）の変更による情報発見の困難と、「スプーフィング」（すなわち、ウェブページが、接続されてない第三者によって金融情報を不正に取得するために提供された詐欺のようにみえる）に関する懸念とをもたらす。

第３のスキームは、上記の２つのスキームの間での折衷案として動作する。第３のスキームでは、販売者のサーバはコンピュータユーザに提示されるウェブページに対する制御を保持する。しかし、コンピュータユーザがクリックしてページを移動し自身の金融情報を入力するとき、販売者のウェブサイトは新たなページを提示する。これは、支払承認代理人によって提供されるコンテンツを有する。このコンテンツはiFrame（アイフレーム）として表示される。iFrameはhtmlブラウザによって使用されるフレーム種別である。概してフレームはブラウザのウィンドウが分割されることを可能にする。このとき各フレームは異なるコンテンツを提示する。iFrameは異なるサーバへのリンクを可能にする。すなわち、各iFrameのコンテンツは、異なるサーバ上申書に格納された文書によって提供される。iFrameはライトボックスのモーダルウィンドウ（lightboxmodalwindow）として提示されてよい。モーダルウィンドウは主ウィンドウに付随し、動作モード（ここでは、ユーザとの走行経路に関してモーダルウィンドウのみ有効であり、主ウィンドウは使用不可能である）を作成する。モーダルウィンドウはしばしば、ユーザに、要求された情報を提供するよう促すために使用される。このタスクに対する注意を引くために、モーダルウィンドウはしばしば「ライトボックス（lightbox）」として表示される。すなわち、モーダルウィンドウが照明されているかのように表示され、他のフレーム又は主ウィンドウはグレイアウトして背景に現れる。

iFrame機能は、ウェブページの主ウィンドウが販売者によって提供されることを可能にするために使用され、一方でiFrameは支払承認代理人によって提供される。コンピュータユーザはついで、自身の機密金融情報をiFrameに入力しトランザクションを承認する。この金融情報は、トランザクションを承認する支払承認代理人によって検証される。一旦承認されると、販売者のサーバは次のウェブページを提示し、トランザクションを確認し、又は支払が失敗したことを示す。

このスキームは販売者にとって有効である。というのも販売者はウェブページに対する制御を維持するので、コンピュータユーザに対してどう表示されるかを制御し、もってコンピュータユーザの関与を維持できるからである。金融情報がiFrameを介して支払承認代理人へ直接提供されるという点で、処理の安全性は改善される。しかし、この構成は折衷案に過ぎない。というのも安全性が依然として保証されないからである。販売者はウェブサイトに対する全体制御を保持し、販売者のサーバは概して攻撃（例えば悪意の鍵ロギングソフトウェアが挿入されて、コンピュータユーザによって入力される金融情報が記録される（いわゆる「クリックジャック攻撃」））を受けやすい。したがってコンピュータユーザについては安全性の問題が残る。コンピュータユーザはむしろ支払承認代理人がウェブサイトに対して制御を有していることを確認する。しかし、現在では、これを実現する唯一の方法は、上記の第２のスキームである。しかし、これは販売者のウェブページと連続した支払承認代理人のウェブページとの間の切断をもたらす。コンピュータユーザが詐欺のウェブページに悪意的にリダイレクトされうるという点で、この切断は、安全性の脆弱性をもたらす。これはコンピュータユーザにとって、識別困難である。というのも、信頼できる使用においてでさえも、真正な支払承認代理人のウェブページは販売者へ戻るいかなるリンクをも含まないからである。

どのように金融情報が収集されるかに加えて、買い物中に金融情報を提供するその行為に対する安全性について、消費者の懸念が増大している。安全性を改善するために、トークン化された支払スキームが実装されている。これはトランザクションが行われるたびに、機密の金融情報が提供される必要がない。

国際公開公報第WO2009/072977号パンフレットは、そのようなトークン化された支払スキーム（主にスマートフォンを用いてなされる店舗内購入について）を記述する。そのようなスキームにおいては、当初ユーザは信頼された支払承認代理人（例えば銀行）と、一度限りの登録処理を実行してよい。これにより支払承認代理人は次いでユーザの金融情報を保持する。アカウント詳細又はカード詳細が提供され、ニックネームが各アカウント又はカードに割り当てられてよい。

購入するとき、コンピュータユーザはトークン化された支払スキームを用いて支払うことを依頼する。販売者は次いでトランザクション詳細を、トークン化された支払スキーム提供者に送信し、ワンタイムトークンを要求する。トークン化された支払スキーム提供者はトークンを生成し、トークンに対しトランザクション詳細を保存し、そのトークンを販売者へ送信する。販売者は次いでトークンをユーザへ提供する。ユーザは自身のスマートフォン上でアプリ（これは支払承認代理人と接続される）を開き、ＰＩＮ又はパスワードを入力することで自身を認証し、キーボード入力又はスキャンによってトークンを入力する。ユーザのアプリは次いでトークンを支払承認代理人のサーバへ送信する。今度は支払承認代理人のサーバはトークンを、トークン化された支払スキーム提供者へ転送する。トークン化された支払スキーム提供者のサーバはトークンを用いてトランザクション詳細を検索し、それらを支払承認代理人へ送信する。支払承認代理人は今度はそれらをユーザに転送し、ユーザが、詳細が正しいことを確認できるようにする。ユーザはトランザクション詳細を視認して、トランザクションの承認として肯定的な応答を送信する。このとき、ニックネームを用いた、支払用アカウントの指示子がその応答に伴ってよい。もし資金又は信用があれば、支払承認代理人は次いでトランザクションを承認して、ユーザ及び販売者に、トランザクションが承認されたことを通知してよい。トランザクション中のいかなるときにも、ユーザの機密の金融情報は販売者へ渡されない。そのようなトークン化されたスキームをインターネットショッピングでの使用に適用することが提案される。

本発明はそのような構成を向上することを目的とする。

第１の観点によれば、本発明はコンピュータネットワークを介してウェブコンテンツを閲覧するコンピュータユーザによって入力されたデータを検証する方法にある。ネットワークは任意の種別のネットワーク（例えばローカルネットワーク、イントラネット及びインターネット）であってよい。本発明は、http又はhttps等の標準プロトコルによってインターネット上でワールドワイドウェブを閲覧するコンピュータユーザへ特に適用される。

本方法は、コンピュータユーザがコンピュータ上でブラウザを用いて、要求者によって提供された要求サーバから第１のウェブページにアクセスすることを含む。コンピュータはウェブ閲覧が可能な任意の種別のもの（例えばパソコン（デスクトップ又はラップトップ）、タブレット、ファブレトット若しくはスマートフォン等のモバイル装置）であってよい。任意の種別のブラウザが使用されてよい。それは例えばInternet Explorer（登録商標）、Google Chrome（登録商標）、Apple Safari（登録商標）、又はMozilla Firefox（登録商標）であってよい。

本方法は更に、コンピュータユーザが第１のウェブページによって提示される制御要素を選択して更なるウェブページを要求することを含んでよい。ここではコンピュータユーザは第三者による検証を要求するデータを入力可能である。検証は、認証の一部又は承認の一部であってよい。例えばコンピュータユーザはページを選択して、トランザクションのための支払が承認されるようにしてよい。したがって検証についての下記の記述は、認証又は承認についての参照であってよい。

次いで本方法は、要求サーバが、コンピュータユーザのブラウザを、検証者によって提供された検証サーバへリダイレクトすることを含む。検証サーバは次いでコンピュータユーザのブラウザへ、第２のウェブページを提供して、更なるウェブページについての要求を充足する。第２のウェブページは、背景フレーム上に位置付けられた前景ウィンドウとして提示される。前景ウィンドウはデータを入力するためのフィールドとともに提供される。特に、背景フレームのコンテンツは要求者によって提供される。

これは、コンピュータユーザが前景ウィンドウでデータを入力することを可能にする。このため、検証サーバはデータを検証可能である。検証サーバは要求サーバへ、検証が成功したか否かについての通知を送信する。

したがって本発明は、ウェブサイト内でその冒頭にウィンドウ及びフレーム構成を配置する通常の構成を変換する。すなわち、本発明に対する背景技術において記載された第３の構成のような従来のスキームでは、ウェブサイト提供者はウェブページを提供し、それに対してフレームを中央に且つ前景に位置付ける。したがってウェブサイト提供者は有効にウェブページを制御するが、背景のコンテンツを提供するだけである。というのも、前景フレームのコンテンツは第三者によって提供されるからである。

発明者は、この構成を変換することが可能であると理解し、そうする手段を開発した。すなわち、発明者は第三者によるコンテンツを有するフレームが操作されて、前景でなくむしろ背景に表示されてよいことを認識した。したがって第三者コンテンツは背景フレームとして提示され、ウェブサイト提供者は次いで、背景フレームの前に表示される前景ウィンドウを提供してよい。これは、データが前景ウィンドウ（これはウェブサイト提供者からの直接の制御下にある）へ入力されることを可能にする。

第２のウェブページをこの形式にて提供することは、上記の従来技術の問題に対処する。検証者は、データを検証する行為で信頼された当事者であるので、彼らは要求者に関する信頼当事者である。したがって本発明は、第２のウェブページが検証者によって提供されて欲しいというコンピュータユーザの要求を充足する。このため、検証者はそのウェブページと機能とに対する制御を保持する。これは、第２のウェブページについての安全性を向上する。ここでは、コンピュータユーザが自身のデータを入力しなければならない。更に安全性証明書が、コンピュータユーザによる検査のために、検証者によって提供されてよい。データは前景ウィンドウに入力される。これは、検証者に明確に関連付けられる。これは、ユーザの信頼性を促進する。

上記の通り、従来技術の問題は、第２のウェブページが検証者によって提供されたときに要求者のウェブページが切断されることであった。しかし、この問題は本発明によって克服された。なぜなら本発明は背景フレームを、要求者によって提供されたコンテンツを有する第２のウェブページに対して提供するからである。これは、要求者が第２のウェブページの一部に対する制御を有することを意味する。例えば要求者は背景フレームを自身の独自スタイルで且つ自身のブランドで提示することができる。このことは、コンピュータユーザが、第２のウェブページが第１のウェブページと接続されていることを確認することを可能にする。したがって、コンピュータユーザが解放されてしまい、又は、第２のウェブページの真正性を判定できないことにつながり得るような状況変化及び切断が無いので、「スプーフィング」の恐怖を静めることができる。したがって参加者の各々につき、システム全体の向上した安全性が保証される。更に権利請求される構成は、ユーザについての信頼レベルを向上し、どのように第２のウェブページが提示されるかについての制御を保持したいという要求サーバの要望を充足し、そして、検証者が、データがどのように入力されるかを制御することを可能にする。

方法は更に、検証サーバがコンピュータユーザのブラウザを要求サーバへリダイレクトすることを含み、要求サーバがコンピュータユーザのブラウザへ第３のウェブページ（これは検証が成功したか、又は上記の通り、承認又は認証が成功したか否かを確認する）を提供する。したがってコンピュータユーザのブラウザへ伝送される後続のウェブコンテンツについての責任を想定する制御が、要求サーバへ戻される。

要求サーバは、URLリダイレクトをコンピュータユーザのブラウザへ送信することによって、コンピュータユーザのブラウザを、検証サーバへリダイレクトしてよい。代替的に、URLリダイレクトは、要求サーバによってホストされるリソースへのURLを含む。これは、背景フレームに表示されるコンテンツを提供する。代替的に、要求者は、要求者によってホストされるリソースへのURLを提供する。これは、背景フレームに表示されるコンテンツをバックチャネルを介して提供する。バックチャネルを使用することは有効である。というのもそれは安全性を向上するからである。

前景ウィンドウと背景フレームとを第２のウェブページ内に提示する異なる方法も可能である。第２のウェブページを実装するためのいくつかの好適な且つ選択的な方法がここで記載される。前景ウィンドウは適切な大きさ且つ適切な位置のモーダルウィンドウとして提示されてよく、例えば、第２のウェブページ内の中央の位置を占めてよい。例えば背景フレームの色をグレイアウトすることによって、前景ウィンドウは背景フレームに関するライトボックスとして提示されてよい。背景フレームはiFrameとして提供されてよい。背景フレームは好適にはモードを有さない（modeless）ので、ユーザは背景フレームと相互作用できない。iFrameはインラインフレームの略であり、ウェブサイト上で他のHTML文書内に埋め込まれたHTML文書を指す。iFrameは伝送的には他のリソースからのコンテンツ（例えば広告）をウェブページの前景に挿入するために使用されてきた。本発明ではiFrameの伝統的使用は変換される。このため、iFrameは要求者によって提供されたコンテンツを、背景フレームに挿入するために使用される。

iFrameとモーダルウィンドウとは、HTML及びJavaを用いて実装されてよい。例えば本方法はHTML5を用いて実装されてよい。これは、HTML5によって提供されるsandbox機能のおかげで、本質的ではないものの有効である。例えば検証サーバは背景の機能全てを無効にし、それがモードレスであることを確保してよい。検証サーバは全てのスクリプトと全てのフォームと背景に関連付けられた全てのトップレベル閲覧アクセスと（又はこれらの任意の組み合わせと）を無効にしてよい。検証サーバはiFrameコンテンツが、ウィンドウとしてあたかも同じウェブサイトからのものであるかのように扱われることを防いでよい。スタイルシートが使用されて、例えばz軸の位置を特定することによって背景及び／又は前景ウィンドウを位置付けてよい。これにより、背景フレームは前景ウィンドウの後ろに表示される。

全てのウェブブラウザがHTML5をサポートするわけではないが、実際に、第２のウェブページを、要求者によって提供された背景フレーム上に提供される前景ウィンドウを用いて提示する汎用アイディアをサポートしないわけではない。これに対処するために、本方法は更に、コンピュータユーザのブラウザが第２のウェブページ（これは前景ウィンドウと背景フレームとを含む）を提示することと両立するか否かを確認することを含んでよく、もしそうでなければ、コンピュータユーザのブラウザを、データを入力するためのフィールドと共に提供される単一ウィンドウのウェブページへリダイレクトすることを含んでよい。すなわち、リダイレクトは、コンピュータユーザのブラウザが、副次的なウィンドウを有さない単一シートのウェブページ（例えばモーダルウィンドウ又はモードレスのウィンドウ）を表示するように使用されてよい。すなわち、データはウェブページ上で提供されるフィールドに入力されるだけである。したがってコンピュータユーザのブラウザが本発明の第２のウェブページをサポートしないとき、本方法は検証サーバへ全体ウェブページについての制御を渡す従来技術の方法へ戻ってよい。確認及びリダイレクトのステップは、要求サーバ又は検証サーバによって実行されてよい。

本発明は一般的な適用可能性を有するが、１つの熟考された適用方法は、オンライントランザクションを承認することである。例えばコンピュータユーザは消費者であってよい。要求者は販売者であってよく、検証サーバは支払承認代理人であってよい。消費者は、支払承認代理人によって支払が決済されることを要求する販売者から購入を行ってよい。この場合、データは消費者の金融アカウント又は支払カードに関する詳細であってよい。例えばカード支払については、データはカード番号、有効期限日及びCVVであってよい。金銭の移転については、データは種別コード及びアカウント番号であってよい。もしトークン化された支払が実行されれば、データはPIN、パスワード又は類似のものに対応してよい。

上記の全体的方法に加えて、本発明は検証サーバと要求サーバとによって実行される方法にある。

したがって第２の観点では、本発明はコンピュータネットワーク上のウェブコンテンツを閲覧するコンピュータユーザによって入力されたデータを検証する方法にある。本方法は次のステップを実行する検証サーバによって提供された検証サーバを含む。
・要求者によってホストされた要求サーバからの、コンピュータユーザのブラウザへのリダイレクトを受信する。
・背景フレーム上に位置付けられた前景ウィンドウとして提示されたウェブページをコンピュータユーザのブラウザに提供する。このとき、前景ウィンドウは検証されるデータを入力するフィールドと共に提供され、背景フレームは要求者によって提供されるコンテンツを含む。
・コンピュータユーザによって前景ウィンドウに入力されるデータを受信する。
・コンピュータユーザによって入力されるデータを検証する。
・検証が成功したか否かについての通知を要求サーバへ送信する。

本発明の第１の観点を支持する上記のコメント及び選択的特徴は、第２の観点にも等しく適用される。例えば要求サーバからのリダイレクトを受信することは、要求者（これは背景フレームに表示されるコンテンツを提供する）によってホストされたリソースへのURLを含むURLリダイレクトを受信することを含んでよいし、更に、要求者からバックチャネルを介して、要求者（これは背景フレームに表示されるコンテンツを提供する）によってホストされるリソースへのURLを受信することを含んでよい。

本方法はライトボックスモーダルウィンドウとして前景ウィンドウを提供することを含んでよい。本方法は背景フレームをiFrameとして提供することを含んでよく、選択的に、スタイルシートを用いて背景フレームを位置付けてよい（これはz軸座標を特定することによって実行されてよい。）。背景フレームはモードレスウィンドウとして提供されてよい。本方法は、全てのスクリプトとフォームと背景に関連付けられたトップレベル閲覧アクセスとを無効にすることによって背景の機能を無効にすることを含んでよい。このことはHTML5サンドボックスコマンドを用いて実行されてよい。

本方法は更に、コンピュータユーザのブラウザがウェブページ（これは前景ウィンドウと背景フレームとを含む）を提示することと両立するか否かを確認することを含んでよく、もしそうでなければ、コンピュータユーザのブラウザを、データを入力するためのフィールドと共に提供されるウェブページへリダイレクトすることを含んでよい。

選択的に、コンピュータユーザは消費者であってよい。要求者は販売者であってよく、検証者は支払承認代理人であってよい。消費者は、支払が支払承認代理人によって承認されることを要求する販売者から購入を行ってよい。データは消費者の金融アカウント又は支払カード、消費者のPIN若しくはパスワードに関する詳細であってよい。

本発明はまた、先行する段落のいずれかに記載される方法により動作するようプログラムされた検証サーバと、コンピュータプログラム（これは検証サーバによって実行されると、検証サーバが先行する段落のいずれかに記載される方法のいずれかにより動作する）と、コンピュータプログラム製品（これは上述のコンピュータプログラムを格納する）とに及ぶ。

第３の観点では、本発明はコンピュータネットワーク上でウェブコンテンツを閲覧するコンピュータユーザによって入力されたデータを検証する方法にある。本方法は次のステップを実行する要求サーバによって提供された要求サーバを含む。
・第１のウェブページをコンピュータユーザのブラウザに提供する。
・コンピュータユーザが第１のウェブページによって提示される制御要素を選択して更なるウェブページを要求することを示す信号を、コンピュータユーザのブラウザから受信する。ここではコンピュータユーザは第三者による検証を要求するデータを入力可能である。
・URLリダイレクトを送信して、コンピュータユーザのブラウザを、検証者によって提供された検証サーバへリダイレクトする。
・検証サーバへ、要求サーバによってホストされるリソースへのURLを送信する。これは、検証サーバによって表示されるコンテンツを提供する。
・検証が成功したか否かについての通知を検証サーバから受信する。

本発明の第１の観点を支持する上記のコメント及び選択的特徴は、第３の観点にも等しく適用される。例えば本方法は更に、検証サーバからコンピュータユーザのブラウザへ送信されたリダイレクトを受信することと、コンピュータユーザのブラウザを要求サーバへ第３のウェブページ（これは検証が成功したか否かを確認する）を提供することとを含む。本方法はURLリダイレクト内でURLを送信するこ、又は、URLをバックチャネルルを介して送信することとを含んでよい。選択的に、コンピュータユーザは消費者であってよい。要求者は販売者であってよく、検証者は支払承認代理人であってよい。消費者は、支払が支払承認代理人によって決済されることを要求する販売者から購入を行ってよい。データは消費者の金融アカウント又は支払カード、消費者のPIN番号若しくはパスワードに関する詳細であってよい。

本発明はまた、先行する段落のいずれかに記載される方法により動作するようプログラムされた要求サーバと、コンピュータプログラム（これは要求サーバによって実行されると、要求サーバが先行する段落のいずれかに記載される方法のいずれかにより動作する）と、コンピュータプログラム製品（これは上述のコンピュータプログラムを格納する）とに及ぶ。

本発明が一層容易に理解されるように、添付の図面を参照して、非限定目的のみで好適な実施形態が開示される。

図１は本発明の実施形態による方法の概略図を示す。 図２は本発明の他の実施形態による方法の概略図を示す。 図３は本発明の他の実施形態による方法の概略図を示す。 図４は本発明の実施形態の一部として提示されるウェブページを示す。 図５は本発明の他の実施形態による方法の概略図を示す。 図６は本発明の他の実施形態による方法の概略図を示す。

本発明の第１の実施形態が図１に示される。本方法は参照符号１０にて開始する。ここではコンピュータユーザがコンピューティング装置上で動作するブラウザソフトウェアを用いて第１のウェブページにアクセスする。コンピューティング装置はウェブ閲覧が可能な任意の種別のもの（例えばパソコン（デスクトップ又はラップトップ）、タブレット、ファブレトット若しくはスマートフォン等のモバイル装置）であってよい。コンピューティング装置はネットワーク（本実施形態ではインターネット）に接続され、コンテンツ（例えばhtmlを用いて提示されるウェブページ）がダウンロードされることを可能にする。ウェブ閲覧は周知であるので、詳細はここでは記載されない。また、ウェブコンテンツの伝送も周知であり十分理解されるものである。よって本発明に特別な関連性を有する観点のみが詳細に記載される。

コンピュータユーザは、例えばリンクを選択することによって又は第１のウェブページを指すURLを入力することによって、要求サーバから第１のウェブページを要求する。要求サーバは要求者によって操作され、ウェブコンテンツを提供する。第１のウェブページを閲覧しているとき、コンピュータユーザは第１の制御要素を選択して、自身が検証を要求するデータを入力したいことを示す。これは例えば、認証処理の一部又は承認処理の一部として行われる。制御要素の形式及び提示方法は個別のアプリケーションによって異なる。例えば制御ボタンは、オンラインのトランザクションが実行されているときに「商品を購入する」とラベル付けされてよい。又はあ安全なウェブサイトへのアクセスが要求される認証が要求される場合に「安全なログオン」と記述されるクリック可能リンクとしてテキストが提示されてよい。そのステップは図１の参照符号２０に示される。

検証が要求サーバによって実行されないが、代わりに、検証サーバを用いる第三者によって実行される。コンピュータユーザが制御要素をクリックして、自身が検証を要求するデータを入力したいことを示すとき、要求サーバはコンピュータユーザを第２のウェブページへリダイレクトする。これは、参照符号３０に示すように検証サーバによってホストされる。検証サーバは検証者によって提供される。リダイレクトによって検証サーバは第２のウェブページをコンピュータユーザのブラウザに提供する。これは参照符号４０に示される。

検証サーバは、第２のウェブページを、背景フレーム上に位置付けられた前景ウィンドウとして提示される。背景フレームのコンテンツは要求者によって提供される。第２のウェブページの前景ウィンドウは検証者によって提供されるコンテンツを有する。前景ウィンドウはデータを編集可能なフィールドを含む。ここではコンピュータユーザは検証されるべきデータを入力してよい（参照符号５０参照）。第２のウェブページが検証者によって提供されると、コンピュータユーザは第２のウェブページに関連付けられた安全性証明書を確認してよく、それらが検証者によって提供されることを視認する。

一旦データがコンピュータユーザによって入力されると、検証サーバはデータを検証してよい。例えばこれは、データベースに格納されたエントリに対してデータを確認することによって実行される。多くのアプリケーションでは、データは２つのエントリ（例えばコンピュータユーザの識別子とPINのパスワード）に対応する。検証サーバは次いでデータベースを確認し、エントリが共に登録されているか否かを判定する。エントリが共に検出されれば検証は成功とみなされる。さもなければ検証は失敗とみなされる。どのように検証が実行されようが、参照符号７０にて、検証サーバは要求サーバへ、データの検証が成功したか否かについての通知を送信する。

図２は本発明の更なる実施形態を示す。図２はコンピュータユーザ１５と要求者２５と検証者３５とによって果たされる役割を欄ごとに示す。多くのステップは図１に関して上記されたものに対応する。類似の参照符号は類似のステップを示す。共通のステップの記述は、簡便性のために繰り返されない。

参照符号１０にて、コンピュータユーザ１５は、例えばリンクを選択することによって又は第１のウェブページを指すURLを入力することによって、第１のウェブページを選択する。要求サーバ２６は第１のウェブページをコンピュータユーザのブラウザ１６に提供する。これは参照符号１２に示される。コンピュータユーザ１５は第１のウェブページによって提供される第１の制御要素をクリックして、検証を要求するデータを入力したいことを示す。これは参照符号２０に示される。

ユーザが制御要素をクリックすると、要求サーバ２６はコンピュータユーザ１５を第２のウェブページへリダイレクトする。これは、参照符号３０に示すように検証サーバ３６によってホストされる。リダイレクトは第２のウェブページのURLを含む。これは検証者３５によって提供され、URLリダイレクト内の埋込URLリンクをも含む。埋め込みURLリンクは要求者２５のリソースを示す。これは、第２のウェブページの背景フレームに含まれるコンテンツを定義する。リソースは要求サーバ２６によって提供されてよい。他のサーバは要求者２５によって提供されてよい。

参照符号４０に示すように、検証サーバ３６はリダイレクトを受信すると、第２のウェブページを構築するときに埋め込みURLを使用する。例えば検証サーバ３６はHTMLを用いて、iFrameとして表示される背景フレームと共に第２のウェブページを構築してよい。背景フレームのコンテンツは埋め込みURLを含むことによって、定義されてよい。背景フレームのコンテンツは好適にはhttpsを用いて伝送される。検証サーバ３６はまた、例えばライトボックスウィンドウとして前景ウィンドウを構築し、前景ウィンドウのコンテンツを定義する。背景フレームと前景ウィンドウとの相対位置はスタイルシートを用いて定義されてよい。選択的に中間ウィンドウが提供されて影効果を作成してよい。例えば中間ウィンドウは低い不透明度を有し（例えば５０％）、ライトボックスウィンドウの背景且つ背景フレームの前面に位置してよく、背景フレームにつき影効果を作成してよい。第２のウェブページがHTML定義として現在構築された状態で、第２のウェブページはコンピュータユーザのブラウザ１６に提供される。

背景フレームが第２のウェブページに対する単なる背景として機能するために、第２のウェブページは全ての機能がオフされた状態で伝送されてよい。すなわち、全てのスクリプトとフォームとトップレベル閲覧アクセスとは無効にされてよい。これは、HTML5のサンドボックス機能を用いて実装されてよい。要求者がクリックジャッキングソフトウェアの驚異に心配する必要がないという点で、上記のことは安全性を向上させる。というのも、コンテンツ提供対象の背景フレームが機能性を有さないからである。

コンピュータユーザ１５はウィンドウにて、検証されるデータを入力してよい。これは参照符号５０で示される。参照符号６５にて検証サーバ３６はデータを検証する（図１の参照符号６０に関して記載されたとおり）。一旦検証が実行されると、検証サーバ３６は、データ検証が成功したか否かについての通知を、安全バックチャネルを用いて要求サーバ２６に送信する。次いで検証サーバ３６はコンピュータユーザのブラウザ１６を要求サーバ２６によってホストされる第３のウェブページへリダイレクトする。代替的に、検証サーバ３６はコンピュータユーザのブラウザ１６を要求サーバ２６によってホストされる第３のウェブページへリダイレクトしてよい。このとき、データ検証が成功したか否かについての通知を含むリダイレクトが使用される。リダイレクトは要求サーバ２６によって受信される。通知は、どのように受信されようと、コンピュータユーザ１５へ提示される第３のウェブページを構築するときに使用される。したがって参照符号８０に示すように、要求サーバ２６は第３のウェブページを提供する。これはコンピュータユーザ１５に対して検証が成功したことを確認し、又は、コンピュータユーザ１５に検証が失敗したことを通知する。参照符号９０に示すように、コンピュータユーザ１５は第３のウェブページを視認し、次いで閲覧を継続する。

図３は、購入を行うための承認を要求するオンラインショッピングの状況での、本発明の更なる実施形態を示す。コンピュータユーザ１５は消費者であってよい。要求者２５は販売者であってよく、検証サーバ３５は支払承認代理人であってよい。検証されるデータは消費者１５から販売者２５への支払を承認することに関しており、品目の購入を有効化する。品目は商品又は役務であってよい。データは支払詳細であり、どのようにトランザクションが有効化されるかによって異なる。カードでの購入については、支払詳細は次のものの１以上に対応してよい。すなわち、カード上に印字されたカード番号、開始日、有効期限日、CVV、及びカード保有者の氏名である。金銭の移転については、支払詳細は次のものの１以上に対応してよい。すなわち、銀行名、他の金融機関名、アカウント番号及び種別コードである。上記のようなトークン化された支払については、支払詳細は次のものの１以上に対応してよい。すなわち、PIN、パスワード、コード若しくはトークン、及びニックネーム等のアカウント識別子である。

方法は参照符号８で開始する。消費者１５は販売者のウェブサイトを閲覧する。周知のように、消費者１５が購入用品目を選択する。これらの品目は仮想の買い物かご又はショッピングカートに追加される。消費者１５が購入物の閲覧を終了すると、消費者１５は、「決済に進む」と概してラベル付けされたボタン又はリンクを選択してよい。これは図３の参照符号１０に示される。

「決済に進む」を選択すると、販売者のサーバ２６は決済ウェブページを提示する（参照符号１２に示す）。この決済ウェブページは上記の第１のウェブページに対応する。決済ウェブページは購入用に選択された品目を提示し、消費者１５が品目を除去すること又は購入用に選択された各品目の数を増減することを可能にしてよい。決済ページ内の他の構成は周知である。したがって参照符号２０にて消費者１５は購入用に選択された品目を閲覧し、品目に対して任意の調整を行い、選択された品目に満足であれば「購入する」との選択肢を選択してよい。

参照符号３０にて、販売者のサーバ２６はコンピュータユーザ１５を、支払承認代理人のサーバ３６によってホストされる支払ウェブページへリダイレクトする。支払ウェブページは上記の第２のウェブページに対応する。リダイレクトは支払承認代理人３５によって提供される支払ウェブページのURLを含み、販売者サーバ２６によって提供されるリソースを指す埋め込みURLを含む。販売者サーバ２６は支払ウェブページの背景フレームに含まれるコンテンツを定義する。

消費者のブラウザ１６からリダイレクトを受信すると、支払承認代理人サーバ３６はブラウザ１６に問い合わせて、ウェブページを、前景ウィンドウ内のライトボックスウィンドウの背後のiFrame背景として提示する機能を有するか否かを判定する。このステップは参照符号３２で示される。この特定の実施形態では、支払承認代理人サーバ３６は消費者のブラウザ１６がHTML5と両立するか否かを問い合わせる。したがって支払承認代理人サーバ３６は消費者のブラウザ１６がHTML5と両立するか否かについての判定を参照符号３４で行う。

もし判定結果が否定的であれば、本方法は参照符号４２に進む。ここでは支払承認代理人サーバ３６は単一ウィンドウの支払ウェブページを構築する。すなわち、支払ウェブページは更なるウィンドウを有さない単一のウェブページ（例えばライトボックスウィンドウ又は他の種別のモーダルウィンドウ若しくはモードレスウィンドウ）である。背景フレームは存在しないので、販売者２５によって提供されるコンテンツはない。上記の発明セクションに対する背景技術で記載される方法で、支払ウェブページは支払承認代理人３５によって全体的に制御される。したがって改良版の機能が消費者のブラウザ１６において利用可能でないとき、本方法は単に従来技術の方法に戻る。したがって本方法は少なくとも従来技術の実行内容と一致する。現代のブラウザ（例えばHTML5をサポートするもの）が取り上げられることが増えるにつれて、本発明の有効性は一層多くの人によって享受される。

もし参照符号３４での判定結果が肯定的であれば、本方法は参照符号４０に進む。ここでは支払承認代理人サーバ３６は背景フレーム上に提示される前景ウィンドウを含む複合支払ウェブページを構築する。支払承認代理人サーバ３６は埋め込みURLを用いて、コンテンツを背景フレームに挿入する。これは、前景ウィンドウの後ろでiFrameとして表示される。上記のように背景フレームの全ての機能はオフである。支払承認代理人サーバ３６はまた、ライトボックスウィンドウとして前景ウィンドウを構築する。この支払ウェブページはコンピュータユーザのブラウザ１６によって表示される。そのような支払ウェブページの例は、図４に提供され、下記で記載される。

選択的に、支払承認代理人サーバ３６は、参照符号３４での肯定的な判定のあとに、更なる確認を行ってよい。具体的には支払ウェブページを構築するとき、支払承認代理人サーバ３６は、販売者２５によって供給される背景フレームにつきコンテンツを確認してよい。もし支払承認代理人サーバ３６がコンテンツは受け入れられると考えれば、本方法は前の通りに継続し、複合支払ウェブページが参照符号４０にて構築及び提供される。しかし、もしコンテンツが支払承認代理人サーバ３６によって受け入れられないとみなされれば（例えばコンテンツが安全性リスクを有するとみなされれば）、支払承認代理人サーバ３６は単一ページの支払ウェブページを構築することと、そのウェブページを提供することとに戻ってよい（参照符号４２）。

図４は、複合支払ウェブページ１００の一例を示す。支払ウェブページ１００は消費者のブラウザ１６によって提供される境界１０２内に提示される。これは、アドレスフィールド１０３とメニューバーとスクロールバーと他の案内制御要素等とを含む。アドレスフィールド１０３は南京錠アイコン１０４を含んでよく、支払承認代理人サーバ３６への安全接続を確認してよい。支払ウェブページ１００は背景フレーム１１０と前景ウィンドウ１２０とを含む。

背景フレーム１１０は販売者２５によって提供されるコンテンツ（例えばロゴ１１１と、小見出し等のブランド１１２と、販売者２５と概して関連付けられた色若しくは全体外観）を有する。

前景ウィンドウ１２０はライトボックスとして表示され、支払承認代理人３５によって提供されるブランド（例えば参照符号１２２に示される支払承認代理人のロゴ）を含んでよい。前景ウィンドウ１２０はまたテキストを含み（概して参照符号１２３に示される）、消費者１５に状態を提供する。例えばテキスト１２３は、消費者１５がトランザクションに関する支払詳細を提供するよう求められていることと、販売者のアイデンティティの確認を提供するよう求められていることとの確認を提供する。前景ウィンドウ１２０はまた多くの形式（フォーム）を含む。そのそれぞれは、ラベル１２４及びテキストフィールド１２６としてのテキストを含む。ここでは消費者１５は、要求された支払詳細を入力してよい。この例では、カード支払が行われる。要求される支払詳細はカード番号、有効期限日及びCVVであってよい。テキストフィールド１２６は自由テキスト入力を許可してよく、例えば消費者１５はカード番号を入力してよい。それらはドロップダウンメニューであってよく、例えば有効期限日の月はドロップダウンメニューから選択され、年については他のドロップダウンから選択されてよい。前景ウィンドウはまた「支払を提出する」ボタン１２８を含み、要求された全ての支払詳細が入力されたときに消費者１５が支払を承認することを可能にする。

単一ページの支払ウェブページはは図４に示すフォームと類似の構成を含むが、販売者２５によって提供されるような背景フレームが無い単一のウェブページにて提示される。

複合支払ウェブページが参照符号４０にて提供されようが、単一ページの支払ウェブページが参照符号４２で提供されようが、消費者１５は図３の参照符号５０で示されるように支払詳細を入力する。参照符号６０にて支払承認代理人サーバ３６は、承認処理の一部として支払詳細を検証する。したがって参照符号６２にて、支払詳細が真正であることの確認がなされる。真正であるとわかれば、支払承認代理人３５は消費者１５が十分な資金又は信用を有していることを確認し、トランザクションを清算する。そうであれば、支払承認代理人３５はトランザクションを承認する。

一旦支払が承認されれば、支払承認代理人３５は消費者１５から販売者２５へのトランザクションを調整し、参照符号７２へ進む。支払はまた、支払承認代理人３５によって有効化される。参照符号７２にて支払承認代理人サーバ３６は、トランザクションが無事に承認されたことの通知を販売者サーバ２６へ提供し、消費者のブラウザ１６を販売者サーバ２６によってホストされる確認ウェブページへリダイレクトする。確認ウェブページは上記の第３のウェブページに対応する。販売者サーバ２６によって受信された通知は、消費者１５へ提示される確認ウェブページを構築するときに使用される。よって参照符号８２に示されるように、販売者サーバ２６は、コンピュータユーザ１５へ承認が成功したことを確認する確認ウェブページを提供する。

もし支払詳細が真正でなければ、又は、もし支払承認代理人３５が、資金又は信用が不十分であることを理由にトランザクションを承認しなければ、支払承認代理人３５はトランザクションが無事に承認されなかったことの通知を販売者サーバ２６へ提供し、消費者のブラウザ１６を販売者サーバ２６によってホストされる確認ウェブページへリダイレクトする（参照符号７４に示すとおり）。販売者サーバ２６によって受信された通知は、消費者１５へ提示される確認ウェブページを構築するときに使用される。よって参照符号８４に示されるように、販売者サーバ２６は、消費者１５へ承認が失敗したことを通知する確認ウェブページを提供する。消費者は代替支払手段を選択する選択肢の提示を受けてよい。

図５は、トークン化された支払スキームを用いてなされるトランザクション状況での、本発明の更なる実施形態を示す。本実施形態ではトークン化された支払スキーム提供者３５は、支払承認代理人３５の役割を果たす。すなわち、トークン化された支払スキーム提供者３５は１以上の銀行に代わって行動する（特に図５に示す通り）。

トランザクションは、図３に関して上記したのと同一の方法で進む。したがって本方法は参照符号８で開始する。消費者１５は販売者のウェブサイトを閲覧する。結果的に消費者１５はボタン又はリンクを選択して、決済ウェブページに進む（図３の参照符号１０に示す通り）。販売者サーバ２６は次いで決済ウェブページを提示する（参照符号１２に示す）。これは、購入用に選択された品目を提示し、また、「支払を行う」選択肢を提示する。

消費者１５が支払を行う選択肢を選択すると、販売者２５は次いで図５に示すようにトランザクションの処理を開始する。販売者２５はトークン化された支払スキーム提供者に、ワンタイムトークンの要求を送信する（図５の参照符号２０１の通り）。この要求はまた、トランザクション詳細（例えば購入される品目、各品目の費用、及び合計費用）を含む。トークン化された支払スキーム提供者３５は要求を受信し、ワンタイムトークンを生成し、ワンタイムトークンと共にトランザクション詳細を格納し、そのワンタイムトークンを販売者２５へ送信する（参照符号２０２）。

この段階で、販売者サーバ２６は図３の参照符号３４を実行する（すなわち、消費者のブラウザ１６の機能を判定する）。以下の記載は、消費者のブラウザ１６がHTML5を実行可能であることを仮定する。もし不可能なら、本方法は図３に関して上記したものと類似する方法で（ただし単一のウェブページ）進む。

参照符号２０３にて、販売者サーバ２６は消費者１５へリダイレクトを送信する。リダイレクトには、支払ウェブページの背景フレームに含まれるコンテンツを定義する販売者サーバ２６によって提供されるリソースを示すURLと、ワンタイムトークンとが埋め込まれる。リダイレクトによって消費者のウェブブラウザ１６は、トークン化された支払スキーム提供者３５によってホストされるウェブサイトにリダイレクトされる（参照符号２０４に示す通り）。トークン化された支払スキーム提供者３５はリダイレクトに埋め込まれたトークンを受信し、ワンタイムトークンを使用し、以前に格納されたトランザクション情報を検索する。トークン化された支払スキーム提供者３５はまた、販売者のコンテンツにリンクする埋め込みリンクを視認する。トークン化された支払スキーム提供者３５はしたがって、消費者のブラウザ１６は複合ウェブページを表示可能であると想定する。あるいはトークン化された支払スキーム提供者３５は図３の参照符号３４にて示されるような確認を更に実行してよい。選択的には、トークン化された支払スキーム提供者３５は、販売者２５によって供給される背景フレームにつきコンテンツを更に確認してよい。もし支払承認代理人サーバ３６がコンテンツは受け入れられると考えれば、本方法は前の通りに継続し、複合支払ウェブページが構築及び提供される。しかし、もしコンテンツが支払承認代理人サーバ３６によって受け入れられないとみなされれば（例えばコンテンツが安全性リスクを有するとみなされれば）、支払承認代理人サーバ３６は単一ページの支払ウェブページを構築することと、そのウェブページを提供することとに戻ってよい。再び、下記の記載において、この確認を通って複合ウェブページが提供されることが想定される。

トークン化された支払スキーム提供者３５は次いで、消費者１５に、複合ウェブページを提供する（図３の参照符号４０に示す通り）。背景フレームは、リダイレクト内に埋め込まれたURLを介して検索された、販売者サーバ２６によって提供されるコンテンツを有する。トークン化された支払スキーム提供者３５は前景ウィンドウにトランザクション詳細を含める（参照符号２０５に示す通り）。

消費者１５は次いでトランザクション詳細を視認し、トランザクションを承認するか否かを決定してよい。トランザクション詳細は販売者のブランドを有する背景と共に表示される複合ウィンドウに表示される。トランザクション詳細はトークン化された支払スキーム提供者３５のブランドを有するライトボックスにおいて提供されてよい。したがって消費者１５はトランザクションが真正であると安心し、詐欺的なウェブサイトにリダイレクトされていないことを安心する。

消費者がトランザクションを承認したいとき、消費者１５は自身の一意のユーザアイデンティティとパスワード又はPINとを、前景ウィンドウ内のテキストフィールドに入力し、この情報をトークン化された支払スキーム提供者３５に提出する（参照符号２０６）。そうすることで消費者１５はトークン化された支払スキーム提供者３５に対し自身を有効に承認し、トランザクションを暗示的に承認する。この例示的実施形態では消費者１５によって入力された支払詳細は、自身のユーザアイデンティティとパスワードとに対応する。パスワードの代替手段（例えばPIN又は、指紋又は虹彩スキャン等の生体情報を含む他の一意の認証情報）が使用されてよい。

トークン化された支払スキーム提供者３５が参照符号２０６に示される承認を受信すると、トークン化された支払スキーム提供者３５はユーザアイデンティティとパスワードとを検証し、消費者１５が十分な資金又は信用を有していることを確認し、全てが正しければトランザクションを承認する。トークン化された支払スキーム提供者３５は次いで、販売者２５へ、トランザクションが安全バックチャネルを介して承認されたことの確認を送信する（参照符号２０７）。トークン化された支払スキーム提供者３５はまた、消費者のブラウザ１６へ、リダイレクトを送信する（参照符号２０８）。これにより消費者のブラウザ１６は、販売者サーバ２６によって提供されるウェブサイトへリダイレクトされる。それは、トランザクションが承認されたか否かについての通知を提供する（参照符号２０９）。

図６は、代替的なトークン化された支払スキームにおいて使用される、本発明の更なる実施形態を示す。本実施形態ではトークン化された支払スキーム提供者３５は、支払承認代理人３５として行動しない。というのもこの役割は消費者の銀行３５によって実現されるからである。したがってトークン化された支払スキーム提供者３５は単に、トランザクション承認のために、銀行３５へ、消費者１５をリダイレクトする中間物として行動する。

図５において記載及び示された以前の実施形態については、トランザクションは図３に関して上記したのと同一の方法で進む。図６に示す構成は消費者１５が「支払を行う」選択肢を選択するときに誘起（トリガ）される。この時点で、販売者２５はトークン化された支払スキーム提供者４５に、ワンタイムトークンの要求を送信する（参照符号３０１の通り）。この要求はまた、トランザクション詳細（例えば購入される品目、各品目の費用、及び合計費用）を含む。トークン化された支払スキーム提供者４５は要求を受信し、ワンタイムトークンを生成し、ワンタイムトークンと共にトランザクション詳細を格納し、そのワンタイムトークンを販売者２５へ送信する（参照符号３０２）。

本実施形態では、販売者サーバ２６は図３の参照符号３４を実行しない（すなわち、販売者サーバ２６は消費者のブラウザ１６の機能を判定しないが、複合ウェブページを表示可能であることを想定するだけである）。参照符号３０３にて、販売者サーバ２６は、支払ウェブページの背景フレームに含まれるコンテンツを定義する販売者サーバ２６によって提供されるリソースを示すURLと、ワンタイムトークンとを埋め込むリダイレクトを送信する。リダイレクトによって消費者のウェブブラウザ１６は、トークン化された支払スキーム提供者４５によってホストされるウェブサイトにリダイレクトされる（参照符号３０４に示す通り）。

トークン化された支払スキーム提供者４５は、トークン化された支払スキーム提供者４５と契約した銀行を表示するウェブページを提供する（参照符号３０５）。消費者１５は次いで自身の銀行を選択してよいし、もし１より多い銀行のアカウントを有していれば、トランザクションに使用したい銀行の１つを選択する。この選択はトークン化された支払スキーム提供者４５に提出される（参照符号３０６）。トークン化された支払スキーム提供者４５は次いで、消費者のブラウザ１６へリダイレクトを送信する（参照符号３０７）。このリダイレクトは、販売者サーバ２６によって提供されるリソースを示す埋め込みURLと、ワンタイムトークンとを含む。このリダイレクトによって消費者のブラウザ１６は、選択された銀行３５によってホストされる支払ウェブページにリダイレクトされる（参照符号３０８に示す通り）。

本実施形態では、銀行サーバ３６は図３の参照符号３４を実行する（すなわち、消費者のブラウザ１６の機能を判定する）。以下の記載は、消費者のブラウザ１６がHTML5を実行可能であることを仮定する。もし不可能なら、本方法は図３に関して上記したものと類似する方法で（ただし単一のウェブページ）進む。選択的には、銀行サーバ３６は、上記したように、販売者２５によって供給される背景フレームにつきコンテンツを更に確認してよい。

銀行３５は次いで消費者１５へ複合ウェブページを提供して、消費者１５が自身を認証することを可能にしてよい（参照符号３０９）。ウェブページは、リダイレクト内に埋め込まれたURLを介してアクセスされた、販売者サーバ２６によって提供されるコンテンツを有する背景フレームを含む。銀行サーバ３６は前景ウィンドウに、テキストフィールドへ認証情報を入力するよう促す指示を含める。したがって背景は販売者のブランドを含む。認証要求は銀行のブランドを有するライトボックスに表示される。したがって消費者１５はトランザクションが真正であると安心し、詐欺的なウェブサイトにリダイレクトされていないことを安心する。

消費者１５は次いで、自身の一意のユーザアイデンティティ及び他の一意のパスワード、PIN又は他の認証情報（これは指紋又は虹彩スキャン等の生体情報を含む）を提出することによって自身を認証する（参照符号３１０）。したがってこの例示的実施形態では消費者１５によって入力された支払詳細は、自身のユーザアイデンティティとパスワード又は代替物とに対応する。銀行３５が承認を受信すると（参照符号３１０）、銀行３５はユーザアイデンティティとパスワードとを検証する。

消費者１５がこの方法で検証されると、銀行サーバ３６はトランザクション詳細を検索する。具体的には銀行サーバ３６は消費者１５から受信されたリダイレクトから抽出されたトークンを、トークン化された支払スキーム提供者４５に送信する（参照符号３１１）。トークン化された支払スキーム提供者４５はトークンを用いてトランザクション詳細を検索する。参照符号３１２にて、トークン化された支払スキーム提供者４５はトランザクション詳細を銀行サーバ３６へ送信する。次いで銀行３５は消費者１５へ支払ページを提供する（参照符号３１３）。再度このウェブページは、URLを介して販売者２５によって提供されたコンテンツを有する背景フレームを有する複合ウェブページである。銀行サーバ３６は前景ウィンドウに、トランザクション詳細と、消費者が銀行３５に保持するアカウントのリストとを含める。

消費者１５は次いでトランザクション詳細を視認し、トランザクションを承認するか否かを決定してよい。トランザクション詳細とアカウントリストとは販売者のブランドを有する背景と共に表示される複合ウィンドウに表示される。トランザクション詳細とアカウントリストと銀行のブランドを有するライトボックスにおいて提供されてよい。したがって消費者１５はトランザクションが真正であると安心し、詐欺的なウェブサイトにリダイレクトされていないことを安心する。

消費者１５がトランザクションを承認したいとき、消費者１５はアカウントの１つを選択する（あるいはもし単一のアカウントだけが利用可能なら、それが自動的に選択される）。消費者１５は次いで「承認する」ボタンを選択し又は任意の類似の行動を行い、トランザクションを確認する。このステップではアカウント選択は、銀行３５によって検証される支払詳細に対応すしてよい。承認及びアカウント選択は、銀行サーバ３６に送信される（参照符号３１４）

銀行３５が参照符号３１４に示す承認とアカウント選択とを受信すると、銀行３５は、アカウントがトランザクションを充足するのに十分な資金又は信用を有していることを確認することによってアカウントを検証し、トランザクションを承認し、トランザクションを有効化する。銀行サーバ３６は次いで、トランザクションが承認されたことの確認を販売者２５へトークン化された支払スキーム提供者４５を介して送信する。このとき安全なバックチャネルが使用される（参照符号３１５）。銀行３５はまた、承認結果と共に、消費者のブラウザ１６へ、リダイレクトを送信する（参照符号３１６）。参照符号３１７に示すように、これにより消費者のブラウザ１６は、販売者サーバ２６によって提供されるウェブサイトへリダイレクトされる。それは、トランザクションが承認されたか否かについての通知を提供する。

当業者は、特許請求の範囲によって定義される本発明の範囲から逸脱すること無く上記実施形態に対して変形がなされてよいことを理解する。

上記実施形態では要求者２５によって供給されるコンテンツは、要求者のサーバ２５によって提供されるリダイレクト内に埋め込まれたURLを用いて検証者３５に対し利用可能となる。しかし、他の構成が可能である。例えば要求者２５はURLをバックチャネルを介して検証者３５へ提供してよい。

図３の実施形態では消費者１５は、購入用品目を確認したあと、「支払を行う」選択肢を決済ウェブページから選択する。この構成は変形されてよい。例えば更なる段階又はウェブページが含まれてよい。更なる詳細（例えば氏名、配送先住所等）が消費者１５から収集されてよい。この情報は決済ウェブページ上で収集されてよいし、更なるウェブページから収集されてよい。例えば消費者１５は決済ウェブページ後に配送先選択肢ウェブページを提示されてよい。消費者１５は配送先選択肢ウェブページから「支払を行う」を選択してよいし、配送先選択肢ウェブページ上の全てのフォームが入力完了したときに支払ウェブページに転送されてよい。追加的又は代替的に、消費者１５は自身を支払承認代理人３５に対して認証するよう要求されてよい。例えば支払承認代理人３５によって提供された当初のウェブページは、消費者１５に、ユーザアイデンティティ及びPIN又はパスワードを入力するよう要求してよい。参照符号４０にて提供された支払ウェブページにて入力されたデータは次いで、認証処理によって確立された消費者１５のアイデンティティに対して検証されてよい。

Claims (28)

1. コンピュータネットワークを介してウェブコンテンツを閲覧するコンピュータユーザによって入力されたデータを検証する方法において、
   前記コンピュータユーザはブラウザを用いて、要求者によって提供された要求サーバから第１のウェブページにアクセスし、
   前記コンピュータユーザは前記第１のウェブページによって提示された制御要素を選択して更なるウェブページを要求し、前記ウェブページでは前記コンピュータユーザは第三者による検証を要求するデータを入力可能であり、
   前記要求サーバは、前記コンピュータユーザのブラウザを、検証者によって提供された検証サーバへリダイレクトし、
   前記検証サーバは第２のウェブページを前記コンピュータユーザのブラウザに提供し、前記更なるウェブページの要求を充足し、前記第２のウェブページは背景フレーム上に位置付けられた前景ウィンドウとして提示され、前記前景ウィンドウは前記データを入力するフィールドと共に提供され、前記背景フレームは前記要求者によって提供され、
   前記コンピュータユーザは前記第２のウェブページの前記前景ウィンドウで前記データを入力し、
   前記検証サーバは前記コンピュータユーザによって入力された前記データを検証し、
   前記検証サーバは前記検証が成功したか否かについての通知を前記要求サーバに送信すし、
   前記要求サーバが前記コンピュータユーザのブラウザを前記検証サーバへリダイレクトすることは、前記要求サーバがURLリダイレクトを前記コンピュータユーザのブラウザへ送信することを含み、
   （ａ）前記URLリダイレクトは、前記要求者によってホストされるリソースへのURLを含み、前記要求者は、前記背景フレームに表示される前記コンテンツを提供し、又は、（ｂ）前記要求者は、バックチャネルを介して、前記要求者によってホストされるリソースへのURLを提供し、前記要求者は、前記背景フレームに表示される前記コンテンツを提供する、
   方法。
2. 請求項１に記載の方法において、ライトボックスウィンドウとして前記前景ウィンドウを提供することを含む、方法。
3. 請求項２に記載の方法において、前記背景フレームをiFrameとして提供することを含む、方法。
4. 請求項３に記載の方法において、スタイルシートを用いて前記背景フレーム及び／又は前記前景ウィンドウを位置付けることを含む、方法。
5. 請求項３又は４に記載の方法において、全てのスクリプト、フォーム、又は、前記背景フレームに関連付けられたトップレベル閲覧アクセスを無効にすることによって、前記背景フレームの全ての機能を無効にすることを含む、方法。
6. 請求項５に記載の方法において、HTML5サンドボックスコマンドを用いて前記背景フレームの全ての機能を無効にすることを含む、方法。
7. 請求項１乃至６のいずれか１項に記載の方法において、前記検証サーバが前記コンピュータユーザのブラウザを前記要求サーバへリダイレクトすることと、前記要求サーバが前記コンピュータユーザのブラウザへ、前記検証が成功したか否かを確認する第３のウェブページを提供することを含む、方法。
8. 請求項１乃至７のいずれか１項に記載の方法において、更に、前記コンピュータユーザのブラウザが、前記前景ウィンドウと前記背景フレームとを含む前記第２のウェブページを提示することと両立するか否かを確認することを含み、もし両立しなければ、前記コンピュータユーザのブラウザを、前記データを入力するためのフィールドと共に提供される単一ウィンドウのウェブページへリダイレクトすることを更に含む、方法。
9. 請求項１乃至８のいずれか１項に記載の方法において、前記コンピュータユーザは消費者であり、前記要求者は販売者であり、前記検証者は支払承認代理人であり、
   前記消費者は、前記支払承認代理人により支払が承認されることを要求する前記販売者から購入を行い、
   前記データは、前記消費者の金融アカウント若しくは支払カードに関する詳細であり、又は、前記消費者のPIN若しくはパスワードに関する詳細である、方法。
10. 請求項１乃至９のいずれか１項に記載の方法により動作するようプログラムされたコンピュータネットワークであって、
    前記コンピュータネットワークは前記要求サーバと前記検証サーバと前記コンピュータユーザに関連付けられ且つ前記ブラウザを提供するようプログラムされたコンピュータとを含む、コンピュータネットワーク。
11. コンピュータネットワークを介してウェブコンテンツを閲覧するコンピュータユーザによって入力されたデータを検証する方法において、検証者によって提供される検証サーバを含み、前記検証サーバは、
    要求者によってホストされた要求サーバからの、前記コンピュータユーザのブラウザへのリダイレクトを受信するステップと、
    背景フレーム上に位置付けられた前景ウィンドウとして提示されたウェブページを前記コンピュータユーザのブラウザに提供するステップであって、前記前景ウィンドウは検証されるデータを入力するフィールドと共に提供され、前記背景フレームは前記要求者によって提供される、ステップと、
    前記コンピュータユーザによって前記前景ウィンドウに入力されたデータを受信するステップと、
    前記コンピュータユーザによって入力された前記データを検証するステップと、
    前記検証が成功したか否かについての通知を前記要求サーバへ送信するステップと、を実行し、
    （ａ）前記要求サーバから前記リダイレクトを受信することは、前記背景フレームに表示される前記コンテンツを提供する前記要求者によってホストされるリソースへのURLを含むURLリダイレクトを受信することを含み、又は、（ｂ）バックチャネルを介して、前記要求者によってホストされるリソースへのURLを前記要求者から受信することを更に含み、前記要求者は、前記背景フレームに表示される前記コンテンツを提供する、
    方法。
12. 請求項１１に記載の方法において、ライトボックスウィンドウとして前記前景ウィンドウを提供することを含む、方法。
13. 請求項１２に記載の方法において、前記背景フレームをiFrameとして提供することを含む、方法。
14. 請求項１３に記載の方法において、スタイルシートを用いて前記背景フレーム及び／又は前記前景ウィンドウを位置付けることを含む、方法。
15. 請求項１３又は１４に記載の方法において、全てのスクリプト、フォーム、又は、前記背景フレームに関連付けられたトップレベル閲覧アクセスを無効にすることによって、前記背景フレームの全ての機能を無効にすることを含む、方法。
16. 請求項１５に記載の方法において、HTML5サンドボックスコマンドを用いて前記背景フレームの全ての機能を無効にすることを含む、方法。
17. 請求項１１乃至１６のいずれか１項に記載の方法において、更に、前記コンピュータユーザのブラウザが、前記前景ウィンドウと背景フレームとを含む前記ウェブページを提示することと両立するか否かを確認することを含み、もし両立しなければ、前記コンピュータユーザのブラウザを、前記データを入力するためのフィールドと共に提供される単一ウィンドウのウェブページへリダイレクトすることを含む、方法。
18. 請求項１１乃至１７のいずれか１項に記載の方法において、前記コンピュータユーザは消費者であり、前記要求者は販売者であり、前記検証者は支払承認代理人であり、前記消費者は、前記支払承認代理人によって支払が承認されることを要求する前記販売者から購入を行い、
    前記データは、前記消費者の金融アカウント若しくは支払カードに関する詳細であり、又は、前記消費者のPIN若しくはパスワードに関する詳細である、方法。
19. 請求項１１乃至１８のいずれか１項に記載の方法により動作するようプログラムされた検証サーバ。
20. 検証サーバによって実行されると、請求項１１乃至１８のいずれか１項に記載の方法により前記検証サーバを動作させるコンピュータプログラム。
21. 請求項２０に記載のコンピュータプログラムを格納する記録媒体。
22. コンピュータネットワークを介してウェブコンテンツを閲覧するコンピュータユーザによって入力されたデータを検証する方法において、要求者によって提供される要求サーバを含み、前記要求サーバは、
    第１のウェブページを前記コンピュータユーザのブラウザに提供するステップと、
    前記コンピュータユーザが前記第１のウェブページによって提示される制御要素を選択して更なるウェブページを要求したことを示す信号を、前記コンピュータユーザのブラウザから受信するステップであって、前記更なるウェブページでは前記コンピュータユーザは第三者による検証を要求するデータを入力可能である、ステップと、
    URLリダイレクトを送信して、前記コンピュータユーザのブラウザを、検証者によって提供された検証サーバへリダイレクトするステップと、
    前記検証サーバへ、前記要求サーバによってホストされるリソースへのURLを送信するステップであって、前記要求者は、前記検証サーバによって表示されるコンテンツを提供する、ステップと、
    前記検証が成功したか否かについての通知を前記検証サーバから受信するステップと、を含む方法。
23. 請求項２２に記載の方法において、前記検証サーバから前記コンピュータユーザのブラウザへ送信されたリダイレクトを受信するステップと、前記コンピュータユーザのブラウザへ、前記検証が成功したか否かを確認する第３のウェブページを提供するステップとを更に含む、方法。
24. 請求項２２又は２３に記載の方法において、前記URLリダイレクト内で前記URLを送信すること、又は、前記URLをバックチャネルを介して送信することを含む、方法。
25. 請求項２２乃至２４のいずれか１項に記載の方法において、前記コンピュータユーザは消費者であり、前記要求者は販売者であり、前記検証者は支払承認代理人であり、前記消費者は、前記支払承認代理人によって支払が清算されることを要求する前記販売者から購入を行い、
    前記データは、前記消費者の金融アカウント若しくは支払カードに関する詳細であり、又は、前記消費者のPIN若しくはパスワードに関する詳細である、方法。
26. 請求項２２乃至２５のいずれか１項に記載の方法により動作するようプログラムされた要求サーバ。
27. 要求サーバによって実行されると、請求項２２乃至２５のいずれか１項に記載の方法により前記要求サーバを動作させるコンピュータプログラム。
28. 請求項２７に記載のコンピュータプログラムを格納する記録媒体。
    

Images