JP2015528954A - オンライン決済のインタラクティブ処理方法およびオンライン決済のインタラクティブ処理システム - Google Patents

Abstract

オンライン決済のインタラクティブ処理方法およびシステムが提供される。この方法は、クライアントからのユーザアカウントに関連付けられた支払い要求を支払い処理サーバに送信するステップと、支払い処理サーバから支払い完了通知を受信するステップであって、支払い完了通知が支払い要求に関連付けられた固有の通知識別子を含む、ステップと、固有の通知識別子に基づく支払い検証要求を支払い処理サーバに送信するステップと、支払い処理サーバから支払い検証結果を受信するステップと、支払い検証結果内の情報に基づきユーザアカウントを更新するステップとを含む。本発明によれば、クライアント端末に関連付けられた鍵を取得する悪意のある目的をもつ人間が、通知IDを有さないが故に支払い完了通知を偽造することを防止する。これはインタラクティブ処理のセキュリティを大きく強化する。

Description

本願は、「インタラクティブ処理方法およびインタラクティブ処理システム」と題される、２０１２年７月１９日に出願された中国特許出願201210251023.0号に優先権を主張する国際出願PCT/CN2013/079128の国内移行であり、参照によりその全体が組み込まれる。

開示される実施形態は、一般にインタラクションセキュリティの分野に関し、特にオンライン決済のインタラクティブ処理方法およびインタラクティブ処理システムに関する。

技術の発展とともに、異なるコンピュータおよび異なるアプリケーションシステム間のインタラクションアプリケーションがより普及している。例として、オンラインショッピングを取り上げる。外出せずに多くの物理的および仮想的な商品を閲覧および購入することができるという特徴により、ネットワークショッピングの活用は、ますます普及している。ネットワークショッピングの活用において、鍵となる段階は支払い、つまりオンライン決済である。現在のオンライン決済技術では、商業ウェブサイトが支払い要求を支払いプラットフォームウェブサイトに対して開始し、支払要求に基づき、支払いプラットフォームウェブサイトは、関連するウェブページをユーザに提供してオンライン決済を行う。ユーザが支払いを完了した後、支払いプラットフォームは、注文(order)および支払い結果の関連情報を商業ウェブサイトに知らせる。注文および支払い結果の関連情報を受信した後、商業ウェブサイトは、支払いプラットフォームによって返された情報の信頼性を検証する。検証が成功した後、商業ウェブサイトは、注文および配送の状態を更新する等のその後の動作(action)を完了する。

現在のオンライ決済では、商業ウェブサイトと支払いプラットフォームウェブサイトとの間のインタラクションは、一般的にRSA(asymmetric cryptographic algorithm)およびメッセージダイジェストアルゴリズ5(MD5, 情報送信の完全性および整合性を保証するために使用される)に基づく。つまり、送信される情報は、MD5が付加された後に販売者の鍵を用いて暗号化され、その後暗号化された情報が送信されるか、または、送信される情報は、MD5が付加される前に販売者のカギを用いて暗号化され、その後暗号化された情報が送信される。MD5は、一般的に販売者の鍵をパラメータ文字列に関係付けることによって計算される。これは静的なコンピューティングモデルである。つまり、商業ウェブサイトと支払いプラットフォームウェブサイトとの間のインタラクションのセキュリティは、販売者の鍵のセキュリティに依存している。一旦販売者の鍵が漏れてしまえば、販売者のカギを取得する悪意のある目的をもつ人間が、支払いプラットフォームウェブサイトの名前で通知情報を偽造することができ、これはオンライン決済のセキュリティを深刻に脅かす。同様に、システムまたはウェブサイト間の他の種類のインタラクティブ操作(interactive operation)にとっても、インタラクションセキュリティが鍵の漏洩のために影響を受け得るということは危険である。

従って本発明の目的は、インタラクティブ操作におけるセキュリティの問題を解決するために、インタラクティブ処理においてセキュリティを確保することができる、オンライン決済のインタラクティブ処理方法およびインタラクティブ処理システムを提供することである。

上記の目的を達成するために、本発明は下記の技術的解決法を採用する。

オンライン決済のインタラクティブ処理方法であって、
要求エンドが、処理要求情報を処理エンドに送信するとともに、処理要求情報に基づき処理エンドによって返される通知識別子(ID)を受信するステップと、
要求エンドが、通知IDに基づき通知クエリ要求情報を処理エンドに送信するとともに、通知クエリ要求情報に基づき処理エンドによって返される、通知IDに対応する処理結果を受信するステップとを含む方法。

オンライン決済のインタラクティブ処理方法であって、
処理エンドが、要求エンドによって送信された処理要求情報を受信し、処理要求情報に基づき処理を行って処理結果に基づき通知IDを生成し、通知IDを要求エンドに送信するステップと、
処理エンドが、通知IDに基づき要求エンドによって送信された通知クエリ要求情報を受信し、通知クエリ要求情報に基づき、通知IDに対応する処理結果を要求エンドに送信するステップとを含む方法。

要求エンドを含むインタラクティブ処理システムであって、
要求エンドが、処理要求情報を処理エンドに送信し、処理要求情報に基づき処理エンドによって返される通知IDを受信し、通知IDに基づき通知クエリ要求情報を処理エンドに送信し、通知クエリ要求情報に基づき処理エンドによって返される、通知IDに対応する処理結果を受信するように構成される、システム。

処理エンドを含むインタラクティブ処理システムであって、
処理エンドが、要求エンドによって送信された処理要求情報を受信し、処理要求情報に基づき処理を行って処理結果に基づき通知IDを生成し、通知IDを要求エンドに送信し、通知IDに基づき要求エンドによって送信された通知クエリ要求情報を受信し、通知クエリ要求情報に基づき通知IDに対応する処理結果を要求エンドに送信するように構成される、システム。

プロセッサと、プロセッサによって実行される1または複数のプログラムを記録するためのメモリとを有する端末において実行されるオンライン決済の方法は、1または複数のプロセッサおよびメモリを有するクライアント端末において、サーバに支払い要求を送信するステップと、サーバから支払い完了通知を受信するステップと、支払い検証要求をサーバに送信するステップと、サーバから支払い検証結果を受信するとともに支払い検証結果内の情報に基づきアカウントを更新するステップとを含む。

プロセッサとプロセッサによって実行される1または複数のプログラムを記録するためのメモリとを有する端末において実行されるオンライン決済の方法は、1または複数のプロセッサおよびメモリを有するサーバにおいて、支払い要求を受信するステップと、支払い完了通知を生成しクライアント端末に送信するステップと、クライアント端末から支払い検証要求を受信するステップと、支払い検証結果を生成しクライアント端末に送信するステップを含む。

オンライン決済を処理するサーバは、1または複数のプロセッサと、メモリと、プロセッサによって実行される、メモリに記録された1または複数のプログラムとを備える。ここで、1または複数のプログラムは、支払い要求を受信し、支払い完了通知を生成しクライアント端末に送信し、クライアント端末によってランダムに生成された鍵とともにクライアント端末から支払い検証要求を受信し、支払い検証要求を生成しクライアント端末に送信するための命令を含む。ここで、支払い検証結果は前記鍵によって暗号化される。

オンライン決済を処理するサーバは、1または複数のプロセッサと、メモリと、プロセッサに実行され、メモリに記録される1または複数のプログラムとを備える。ここで、1または複数のプログラムは、クライアント端末からトランザクションについての支払い要求を受信し、トランザクションがある所定の基準に合致するか否かを判断し、トランザクションが前記ある所定の基準に合致しない場合に支払い完了通知を生成しクライアント端末に送信し、クライアント端末によってランダムに生成された鍵とともにクライアント端末から支払い検証要求を受信し、支払い検証結果を生成しクライアント端末に送信するための命令を含む。ここで、支払い検証結果は、前記鍵によって暗号化され、トランザクションが前記ある所定の基準に合致する場合には支払い完了結果を生成しクライアント端末に送信する。

いくつかの実施形態に基づき、オンライン決済の方法は、プロセッサとプロセッサによって実行される1または複数のプログラムを記録するためのメモリとを有するクライアント端末において実行される。この方法は、ユーザアカウントに関連付けられた支払い要求を支払い処理サーバに送信するステップと、支払い処理サーバから支払い完了通知を受信するステップであって、支払い完了通知が支払い要求に関連付けられた固有の通知識別子を含む、ステップと、固有の通知識別子に基づく支払い検証要求を支払い処理サーバに送信するステップと、支払い処理サーバから支払い検証結果を受信するステップと、支払い検証結果内の情報に基づきユーザアカウントを更新するステップとを含む。

いくつかの実施形態に基づき、オンライン決済の方法は、プロセッサとプロセッサによって実行される1または複数のプログラムを記録するためのメモリとを有する支払い処理サーバにおいて実行される。この方法は、クライアント端末から支払い要求を受信するステップであって、支払い要求がユーザアカウントに関連付けられた端末からのトランザクション要求に応答して生成される、ステップと、支払い完了通知を生成しクライアント端末に送信するステップであって、支払い完了通知が支払い要求に関連付けられた固有の通知識別子を含む、ステップと、クライアント端末から支払い検証要求を受信するステップと、固有の通知識別子を用いて支払い検証要求を検証するステップと、支払い検証結果をクライアント端末に送信するステップとを含む。

いくつかの実施形態に基づき、オンライン決済を処理するサーバは、1または複数のプロセッサと、メモリと、プロセッサによって実行されメモリに記録される1または複数のプログラムとを備える。1または複数のプログラムは、クライアント端末から支払い要求を受信するステップであって、支払い要求がユーザアカウントに関連付けられた端末からのトランザクション要求に応答して生成される、ステップと、支払い完了通知を生成しクライアント端末に送信するステップであって、支払い完了通知が支払い要求に関連付けられた固有の通知識別子を含む、ステップと、クライアント端末から支払い検証要求を受信するステップと、固有の通知識別子を用いて支払い検証要求を検証するステップと、支払い検証結果を生成しクライアント端末に送信するステップとを行うための命令を含む。

本発明の解決方法に基づき、要求エンドは処理要求情報を処理エンドに送信し、処理エンドは処理要求情報に基づき処理を行うとともに要求エンドに処理要求情報に基づく通知IDを返し、要求エンドはさらに、通知IDに基づき処理エンドから通知IDに対応する処理結果を取得する。要求エンドは、一般的に処理エンドのドメイン名やアドレス等の情報を保存し、保存された処理エンドのドメイン名やアドレス等の情報に基づき処理エンドに情報を送信する。要求エンドによって保存された処理エンドのドメイン名やアドレス等の情報を他人が変更することは困難である。この解決法に基づき、要求エンドの鍵を取得する悪意のある目的をもつ人間が処理エンドになりすますこと、または要求エンドから通知クエリ要求情報を受信することを防ぎ、通知IDに対応する処理結果の偽造を不可能にする。これは、インタラクティブ処理のセキュリティを大きく強化する。

追加の実施形態と同様に本発明の上記の実施形態は、図面と併用して本発明の様々な態様の下記の詳細な説明の結果、より明確に理解されるだろう。類似の符号は、複数の図面にわたって対応する部分を示す。

本発明のオンライン決済のインタラクティブ処理方法の実施形態1の概略的なフローチャートである。 本発明のオンライン決済のインタラクティブ処理方法の実施形態2の概略的なフローチャートである。 本発明のオンライン決済のインタラクティブ処理方法の実施形態3の概略的なフローチャートである。 要求エンドが商業ウェブサイトであり、処理エンドが支払いプラットフォームウェブサイトである特定の例におけるインタラクションの概略的な図である。 本発明のオンライン決済のインタラクティブ処理方法の実施形態4の概略的フローチャートである。 本発明のオンライン決済方法の実施形態の概略的なフローチャートである。 本発明のオンライン決済方法の実施形態の概略的なフローチャートである。 本発明のインタラクティブ処理システムの実施形態の概略的な構成図である。

例示的な実施形態を以下で参照しながら本発明の解決方法が詳細に説明される。以下の説明では、本発明のオンライン決済のインタラクティブ処理方法の実施形態が本発明のインタラクティブ処理システムの前に説明される。本発明の実施形態における全てのインタラクティブ処理方法/システムは、オンライン決済方法/システムに適用可能である。インタラクティブ処理方法/システムがオンライン決済に適用される場合、処理エンドはオンライン決済プラットフォームまたは銀行をサポートするサーバであってよく、要求エンドはサーバのクライアント端末であってよく、商業ウェブサイトとインタラクトすることができる。

図１は、本発明のオンライン決済のインタラクティブ処理方法の実施形態1の概略的なフローチャートである。実施形態1での要求エンドの処理手順は、説明ための例示として用いられる。

図１に示されるように、実施形態1でのオンライン決済のインタラクティブ処理方法は以下のステップを含む。

ステップS101：要求エンドは、処理要求情報を処理エンドに送信する。

ステップS102：要求エンドは、処理要求情報に基づき処理エンドによって返される、支払い完了通知である通知識別子(ID)を受信する。

ステップS103：要求エンドは、通知IDに基づき通知クエリ要求情報(通知された支払いのための支払い検証要求)を処理エンドに送信する。

ステップS104：要求エンドは、通知クエリ要求情報に基づき処理エンドによって返される、通知IDに対応する支払い結果(支払い検証結果)を受信する。

この実施形態における解決方法に基づき、要求エンドは処理要求情報を処理エンドに送信し、処理エンドは処理要求情報に基づき処理を行うとともに処理要求情報に基づく通知IDを要求エンドに返し、要求エンドはさらに通知IDに基づき処理エンドから通知IDに対応する処理結果を取得する。要求エンドは、一般的に処理エンドのドメイン名やアドレス等の情報を保存し、保存された処理エンドのドメイン名やアドレス等の情報に基づき処理エンドに情報を送信する。要求エンドによって保存される処理エンドのドメイン名やアドレス等の情報を他人が変更することは困難である。この解決方法に基づき、要求エンドの鍵を取得する悪意のある目的を有する人間が処理エンドになりすますこと、または要求エンドから通知クエリ要求情報を受信することを防ぎ、通知IDに対応する処理結果の偽造を不可能にする。これは、インタラクティブ処理のセキュリティを大きく強化する。

処理要求情報に基づき、通知IDを要求エンドに返すとき、処理エンドは、処理要求情報に基づく実行の処理結果も返してよい。つまり、要求エンドは処理要求情報に基づき処理エンドから返された処理結果も受信する。

従って、通知IDに加えて、要求エンドは処理要求情報についての処理結果も受信する。このような方法で、要求エンドは、通知クエリ要求情報を処理エンドに送信するとともに、処理結果を再度取得し検証または確認をさらに行うか否かを、条件に基づき判定することができる。特定の実施は、要求エンドの構成または要求エンドの操作者の条件に関連してもよい。通知クエリ要求情報が送信される必要がある場合、通知クエリ命令が発行されてよく、通知クエリ命令を受信した後に要求エンドは通知クエリ要求情報を処理エンドに送信する。通知クエリ要求が送信される必要があるか否かは、実際の要求に基づき、様々な可能な方法において決定されてよい。また、受信されたすべての通知IDに対しても通知クエリ要求情報が送信される必要があると設定してもよい。

特定の例では、要求エンドは、商業ウェブサイト、または商業ウェブサイトとインタラクトするコンピュータであってよく、対応して、処理エンドは、支払いプラットフォームウェブサイト、または支払いプラットフォームウェブサイトとインタラクトするサーバコンピュータであってよい。商業ウェブサイトでは、注文の支払い動作は、支払いプラットフォームウェブサイトまた銀行ウェブサイトによって処理されるように要求される。従って、支払いプラットフォームウェブサイトまたは銀行ウェブサイトによって返される、通知IDに対応する処理結果を受信した後、商業ウェブサイトは、処理結果に基づき注文の状態を更新することもできる。

図2は、本発明のオンライン決済のインタラクティブ処理方法の実施形態2の概略的なフローチャートである。実施形態2での処理エンドの処理手順は、説明のための例として用いられる。

図2に示されるように、実施形態2のオンライン決済のインタラクティブ処理方法は、以下のステップを含む。

ステップS201：処理エンドは、要求エンドによって送信された処理要求情報を受信するとともに、処理要求情報に基づき処理を行って処理結果を取得する。

ステップS202：処理エンドは、処理結果に基づき通知IDを生成するとともに通知IDを要求エンドに送信する。

ステップS203：処理エンドは、通知IDに基づく要求エンドによって送信された通知クエリ要求情報を受信するとともに、通知クエリ要求情報に基づき通知IDに対応する処理結果を要求エンドに送信する。

この実施形態における解決方法に基づき、処理エンドは、処理要求情報を受信し、処理要求情報に基づき処理を行って処理結果を取得し、処理要求情報に基づく通知IDを要求エンドに返し、通知IDに基づき要求エンドによって送信された通知クエリ要求情報を受信した後、通知IDに対応する処理結果を要求エンドに送信する。要求エンドは、一般的に処理エンドのドメイン名やアドレス等の情報を保存し、保存された処理エンドのドメイン名やアドレス等の情報に基づき処理エンドに情報を送信する。処理エンドのドメイン名やアドレス等の要求エンドによって保存された情報を他人が変更することは困難である。この解決方法に基づき、要求エンドの鍵を取得する悪意のある目的をもつ人間が処理エンドになりすますこと、または要求エンドから通知クエリ要求情報を受信することを防ぎ、通知IDに対応する処理結果の偽造を不可能にする。これは、インタラクティブ処理のセキュリティを大きく強化する。

この処理方法では、処理要求情報に基づき通知IDを要求エンドに返すとき、処理エンドは、処理要求情報に基づき実行の処理結果も返してよく、要求エンドは、通知IDに対応する処理結果を再度取得して、取得された処理結果のセキュリティを検証するか否かを決定する。

特定の例では、要求エンドは、商業ウェブサイトであってよく、対応して処理エンドは、支払いプラットフォームウェブサイトまたは銀行のウェブサイトであってよい。商業ウェブサイトでは、注文の支払い動作は、支払いプラットフォームウェブサイトまたは銀行のウェブサイトによって処理されるように要求される。従って、支払いプラットフォームウェブサイトまたは銀行のウェブサイトによって返される、通知IDに対応する処理結果を受信した後、商業ウェブサイトは、処理結果に基づき、注文の状態を更新することができる。

図3は、本発明のオンライン決済のインタラクティブ処理方法の実施形態３の概略的なフローチャートである。実施形態３では、処理要求情報を受信した後に処理エンドが常に通知IDのみを返す場合の要求エンドと処理エンドとの間のインタラクション処理が説明のために例として用いられる。

図3に示されるように、実施形態3のオンライン決済のインタラクション処理方法は以下のステップを含む。

ステップS301：要求エンドは、処理要求情報を処理エンドに送信する。

ステップS302：処理エンドは、要求エンドによって送信された処理要求情報を受信するとともに処理要求情報に基づき処理を行って処理結果を取得する。

ステップS303：処理エンドは処理結果に基づき通知IDを生成するとともに通知IDを要求エンドに送信する。

ステップS304：要求エンドは、処理要求情報に基づき処理エンドによって返された通知IDを受信するとともに、通知IDに基づき通知クエリ要求情報を処理エンドに送信する。

ステップS305：処理エンドは、通知IDに基づき要求エンドによって送信された通知クエリ要求情報を受信するとともに、通知クエリ要求情報に基づき通知IDに対応する処理結果を要求エンドに送信する。

ステップS306：要求エンドは、通知クエリ要求情報に基づき処理エンドによって返された、通知IDに対応する処理結果を受信する。

図4は、要求エンドが商業ウェブサイトであり、処理エンドが支払いプラットフォームウェブサイトである特定の例における支払い処理の概略的な図である。

実施形態3でのオンライン決済のインタラクティブ処理方法に基づき、図4に示される支払い処理が以下で説明される。

ユーザが関連する注文情報を入力し終わり(complete)、注文についての支払いを決定した後、商業ウェブサイトは支払いプラットフォームウェブサイトに対応する支払い要求を開始する。つまり、商業ウェブサイトは支払いプラットフォームウェブサイトに処理要求情報を送信する。

商業ウェブサイトによって送信された支払い要求を受信した後、支払いプラットフォームウェブサイトは、注文の支払いを完了する。注文の支払いは、いかなる可能な方法によって実施されてよい。支払いが完了した後、支払いプラットフォームウェブサイトは、注文の通知IDを生成するとともに注文と注文に関連する支払い状態とを識別する。通知IDを生成した後、支払いプラットフォームウェブサイトは、通知IDを商業ウェブサイトに送信する。

支払いプラットフォームウェブサイトによって返された通知IDを受信した後、商業ウェブサイトは、通知IDに基づき通知クエリ要求情報を支払いプラットフォームウェブサイトに送信する。ここで、通知クエリ要求情報は、通知IDを含む。

商業ウェブサイトによって送信された通知クエリ要求情報を受信した後、支払いプラットフォームウェブサイトは、通知クエリ要求情報内の通知IDに基づき対応する処理結果についてクエリを行う(query)。処理結果は、注文情報と注文に関連する処理結果情報とを含んでよい。当然、処理結果は実際の要求に基づいて構成されてよく、例えば、処理結果は注文の数および支払いが成功であるか否かについての情報等のみを含んでもよい。

商業ウェブサイトによって返された処理結果を受信した後、商業ウェブサイトは、処理結果に基づいて注文の状態を更新し、それに応じて、仮想的な商品または物理的な商品の配送のプロンプトのような後続の動作を完了する。

本発明でのオンライン決済のインタラクション処理の実施形態3の説明では、処理エンドが通知IDを要求エンドに送信するのみで、要求エンドが常に通知IDに基づき処理エンドからの処理結果についてクリエを行う必要がある例を用いた。その他の実施方法では、処理エンドが通知IDを生成するか否か判断し、通知IDを要求エンドに送信することも可能である。つまり、以下のステップがステップS302およびステップS303の間で行われ得る。

S3023：処理エンドは、通知IDを生成するか否かを判断し、YESの場合、ステップS303に進む。

つまり処理エンドは、通知IDを生成するか否かを判断する。通知IDを生成する必要があると決定された場合、処理エンドは、通知IDを生成する等の後続の処理を行う。通知IDを生成する必要がないと決定された場合、処理エンドは、処理結果を要求エンドに直接送信してよい。

処理エンドは、例えば、処理要求情報の種類ならびに要求エンドの種類および能力等に基づくなど、様々な可能な方法で通知IDを生成するか否かを判断する。全ての処理要求情報について通知IDを生成する必要があると設定することさえ可能であり、通知IDを生成する必要があるか否かを判断する特定の方法は、ここで説明されない。

この場合、図４での支払い処理を例として用い、特定の処理手順が以下で説明される。

ユーザが関連する注文情報を入力し終わり、注文についての支払いを決定した後、商業ウェブサイトは、対応する支払いプラットフォームウェブサイトに支払い要求を開始する。つまり、商業ウェブサイトは、支払い要求情報を支払いプラットフォームウェブサイトに送信する。

商業ウェブサイトによって送信された支払い要求を受信した後、支払いプラットフォームウェブサイトは、注文の支払いを完了する。注文の支払いはいかなる可能な方法で実施されてもよい。

支払いを完了した後、支払いプラットフォームウェブサイトは、注文の通知IDを生成する必要があるか否かを判断する。特定の判断条件が要求に基づいて設定されてよい。支払いプラットフォームウェブサイトにとって、通知IDを生成する必要があるか否かは、商業ウェブサイトの種類や規模、および注文における商品の特性(nature)などの要因に基づいて判断されてよい。例えば、通知IDが特定の商業ウェブサイトの支払い要求に基づき生成される必要があることや、商業ウェブサイトの規模が所定の閾値よりも小さい場合に、通知IDが商業ウェブサイトの支払い要求に基づき生成される必要があることや、もしくは注文における商品が仮想的な商品である場合に、通知IDが支払い要求に基づき生成される必要があることを支払いプラットフォームウェブサイトにおいて設定してもよいし、または支払いプラットフォームウェブサイトは、商業ウェブサイトの種類および規模、注文における商品の特性、ならびにその他の関連する要因を考慮することによって通知IDが生成される必要があるか否かを判断する。明らかなように、実際の要求に基づき、通知IDが生成される必要があるか否かを判断するためにいかなるその他の可能な方法が採用されてよく、特定の判断方法はここでは説明されない。

通知IDが生成される必要があることが決定された場合、支払いプラットフォームウェブサイトは、注文の通知IDを生成し、注文と注文に関連する支払い状態とを識別する。通知IDを生成した後、支払いプラットフォームウェブサイトは、通知IDを商業ウェブサイトに送信する。

支払いプラットフォームウェブサイトによって返された通知IDを受信した後、商業ウェブサイトは、通知IDに基づき通知クエリ要求情報を支払いプラットフォームウェブサイトに送信する。ここで通知クエリ要求情報は、通知IDを含む。

商業ウェブサイトによって送信された通知クエリ要求情報を受信した後、支払いプラットフォームウェブサイトは、通知クエリ要求情報内の通知IDに基づき対応する処理結果についてクエリを行う。処理結果は、注文情報と注文に関連する処理結果情報とを含んでよい。明らかなように、処理結果は実際の要求に基づいて構成されてもよく、例えば、支払い結果は、注文の数および支払いが成功であるか否かについての情報等のみを含んでもよい。

商業ウェブサイトによって返された処理結果を受信した後、商業ウェブサイトは、処理結果に基づき注文の状態を更新し、それに応じて、仮想的な商品または物理的な商品の配送のプロンプトなどの後続の動作を完了する。

図5は、本発明のオンライン決済のインタラクティブ処理方法の実施形態4のフローチャートである。実施形態4では、処理要求情報を受信した後に処理エンドが通知IDおよび処理結果を要求エンドに返し得る場合の要求エンドと処理エンドとの間のインタラクション処理が、説明のための例として用いられる。

図5に示されるように、実施形態4でのオンライン決済のインタラクティブ処理方法は、以下のステップを含む。

ステップS501：要求エンドは、処理要求情報を処理エンドに送信する。

ステップS502：処理エンドは、要求エンドによって送信された処理要求情報を受信するとともに、処理要求情報に基づき処理を行う。

ステップS503：処理エンドは、処理結果に基づき通知IDを生成するとともに、通知IDおよび処理結果を要求エンドに送信する。

ステップS504：要求エンドは、処理要求情報に基づき処理エンドに返された通知IDおよび処理結果を受信する。

ステップS505：要求エンドは、通知クエリ命令を受信するとともに、通知クエリ命令に基づき通知クエリ要求情報を処理エンドに送信する。ここで、通知クエリ要求情報は、通知IDを含む。

ステップS506：処理エンドは、通知IDに基づき要求エンドによって送信された通知クエリ要求情報を受信するとともに、通知クエリ要求情報に基づいて通知IDに対応する処理結果を要求エンドに送信する。

ステップS507：要求エンドは、通知クエリ要求情報に基づき処理エンドによって返される、通知IDに対応する処理結果を受信する。

この実施形態での解決方法に基づき、処理エンドは、通知IDおよび対応する処理結果を要求エンドに送信することができる。要求エンドが通知IDに基づき処理結果について再クエリが行われる必要があるか否かを判断することで、処理結果のセキュリティを確保することを可能にする。

実施形態4のオンライン決済のインタラクティブ処理方法に基づき、図4での支払い処理の概略的な図を参照しながら、要求エンドが商業ウェブサイトであり、処理エンドが支払いプラットフォームである例を用い、特定の支払い処理が以下で説明される。

ユーザが関連する注文情報を入力し終わり、注文に対する支払いを決定した後、商業ウェブサイトは、対応する支払いプラットフォームウェブサイトに支払い要求を開始する。つまり、商業ウェブサイトは、支払いプラットフォームウェブサイトに処理要求情報を送信する。

商業ウェブサイトによって送信された支払い要求を受信した後、支払いプラットフォームウェブサイトは、注文の支払いを完了する。注文の支払いは、いかなる可能な方法において実施されてよい。支払いが完了した後、支払いプラットフォームウェブサイトは、注文の通知IDを生成し、注文と注文に関連する支払い状態とを識別する。通知IDを生成した後、支払いプラットフォームウェブサイトは、処理結果および通知IDを商業ウェブサイトに送信する。

支払いプラットフォームウェブサイトによって返された処理結果および通知IDを受信した後、商業ウェブサイトは、通知IDに基づき支払いプラットフォームウェブサイトからの対応する処理結果が再クエリされる必要があるか否かを判断し、その結果処理結果を確認または検証することができる。特定の判断機構は、アプリケーションの要求に基づいて設定されてよい。例えば、注文に対応する商品が仮想的な商品である場合にクエリが作成される必要があること、注文に対応する商品が物理的な商品である場合にクエリが作成される必要があること、注文のトランザクションの量が閾値を超える場合にクエリが作成される必要があること、または、ここでは説明されない特定の条件の組を含むいかなる条件においてもクエリが作成される必要があることを設定してよい。

クエリが支払いプラットフォームウェブサイトに対して作成される必要がある場合、商業ウェブサイトは、通知IDに基づき通知クエリ要求情報を支払いプラットフォームウェブサイトに送信する。ここで、通知クエリ要求情報は、通知IDを含む。

商業ウェブサイトによって送信された通知クエリ要求情報を受信した後、支払いプラットフォームウェブサイトは、通知クエリ要求情報内の通知IDに基づき対応する処理結果についてクエリを行う。処理結果は、注文情報と注文に関連する処理結果情報とを含んでよい。明らかなように、処理結果は、実際の要求に基づいて構成されてもよく、例えば、処理結果は、注文の数および支払いが成功であるか否かについての情報等のみを含んでよい。

商業ウェブサイトによって返された処理結果を受信した後、商業ウェブサイトは、処理結果に基づき注文の状態を更新し、それに応じて、仮想的な商品または物理的な商品の配送のプロンプトなどの後続の動作を完了する。

本発明でのオンライン決済のインタラクティブ処理方法の実施形態4の説明では、処理エンドが処理結果および通知IDを要求エンドに送信し、要求エンドが処理エンドからの通知IDに基づき処理結果についてクエリされる必要があるか否かを判断する例が用いられた。その他の実施の方法では、処理エンドが通知IDを要求エンドに送信するために通知IDを生成するか否かを判断し、通知IDを生成することを決定した場合に、処理エンドが対応する通知IDを生成し、通知IDおよび処理結果を要求エンドに送信することも可能である。つまり、以下のステップが、ステップS502とステップとの間に行われてもよい。

S5023：処理エンドは、通知IDを生成するか否かを判断し、YESの場合ステップS503に進む。

つまり、処理エンドは、通知IDを生成するか否かを判断する。通知IDが生成される必要があると判断される場合、処理エンドは、通知IDを生成する等の後続の処理を行う。通知IDが生成される必要はないと判断された場合、処理エンドは処理結果を直接要求エンドに送信してもよい。

処理エンドは、例えば、処理要求情報の種類ならびに要求エンドの種類および能力等に基づくといような様々な可能な方法で通知IDを生成するか否かを判断することができる。通知IDは全ての処理要求情報に対して生成される必要があると設定されてさえよく、通知IDが生成される必要があるか否かを判断する特定の方法は、ここでは説明されない。

実施形態4でのその他の技術的特徴は、実施形態3のものと同様であってよく、それらについてはここで再度説明されない。

より良い理解のための本発明におけるオンライン決済のインタラクティブ処理方法の説明では、要求エンドが商業ウェブサイトであり、処理エンドが支払いプラットフォームである例を説明のために用いた。本発明の方法は、他のエンドとデータ送信を行う処理エンドの補助処理を要求し、システムインタラクションを介する処理を要求するいかなる分野にも適用可能であることが予想され得る。従って、商業ウェブサイトおよび支払いプラットフォームウェブサイトについて行ったこの例は、本発明の解決方法を限定するものではなく、本発明の解決方法の趣旨に基づいて、本発明の解決方法はシステムインタラクションを介する要求するいかなる分野にも適用可能である。

本発明のオンライン決済のインタラクティブ処理方法に基づき、本発明はインタラクティブ処理システムをさらに提供する。

本発明のインタラクティブ処理システムは、要求エンドまたは処理エンドのみを含んでもよいし、要求エンドおよび処理エンドの両方を含んでもよい。

図6は、本発明の実施形態によって提供されるさらなる他のオンライン決済のインタラクティブ処理方法のフローチャートである。

オンライン決済処理が、トランザクション要求を販売者に送信する顧客と開始する(ステップS601)。顧客は販売者のウェブサイトを閲覧していてよく、所望するいくつかの品物を見つける。顧客はその後、商業ウェブサイトとインタラクトしているコンピュータにトランザクション要求を送信するように、自身のコンピュータにおいて操作を行う。

顧客端末からトランザクション要求を受信した後、オンラインプラットフォームのクライアント端末である販売者のコンピュータは、サーバにオンライン決済要求を送信する(ステップS602)。コンピュータはウェブサイトのコンテンツを配信するものであってもよいし、またはウェブサイトのコンテンツを配信するコンピュータとインタラクトすることができてもよい。オンライン決済プラットフォームが支払い要求に応答した後、顧客は、オンライン決済プラットフォームによってサポートされるオンライン決済インターフェイスに向けられる(directed)。図6に示されるように、オンライン決済プラットフォームは、支払い認証要求を顧客端末に送信することができる(S600)。インターフェイスは、商業ウェブサイトの一部または独立したウェブサイトのどちらとしてでも表示されてよい。オンライン決済プラットフォームは、1つのアカウントから他のアカウントへお金を転送することが可能なシステムである。オンライン決済プラットフォームは、1または複数のサーバコンピュータによってサポートされる。

このインターフェイスを介して、顧客は、プラットフォームがある金額を自身のアカウントからオンライン決済プラットフォームへ転送することを認証する。顧客は、自身の顧客端末においてオンライン決済プラットフォームのサーバに支払い認証応答を送信するように操作することができる(ステップS603)。支払い認証応答は、顧客の識別子を検証するための、例えば、ユーザ名、パスワード、およびセキュリティの質問などの情報を含む。いくつかの実施形態では、顧客端末のユーザは、顧客端末の入力/出力デバイスによって固有の識別子(例えば、アルファベットおよび数字の文字列)を提供する。例えば、支払い認証要求は、顧客端末に表示されるランダムに生成された数字を含んでもよい。顧客端末のユーザは、ランダムに生成された数字またはその変形を繰り返し、それらは支払い認証応答の一部としてオンライン決済プラットフォームに返信される。インターフェイスは、販売者のコンピュータがオンライン決済要求を送信する前後どちらでも表示されてよい。支払い認証応答は、転送されることが意図される金額および、場合によっては支払いの目的に関する情報を含んでもよい。いくつかの実施形態では、支払い認証応答は、販売者のコンピュータを介して送信される。

ステップS604において、クライアント端末からの支払い要求および顧客端末からの支払い認証応答に基づき、サーバは、顧客からクライアントへの送金を処理することができる。いくつかの実施形態では、サーバは、銀行または資金管理エンティティのコンピュータと接続されており、銀行または資金管理エンティティにお金を転送するように命令する。

ステップS605は本発明のいくつかの実施形態において存在する。ステップS605では、サーバは、購入者/顧客と販売者/クライアントとの間のトランザクションが予め設定されたある基準を満たすか否かを判断する。いくつかの実施形態では、販売者は、あるトランザクションにはより安全な支払いの処理を望む一方で、その他のトランザクションにはより簡易な支払いの処理を望む。販売者は、トランザクションのリスクに基づき所定の基準を設定することができる。所定の基準は、トランザクションに関わる品物の種類、支払いの合計金額、顧客の種類、顧客の過去の履歴、および複数の要因を複合したものを含むことができる。例えば、仮想の品物は、有形の物よりもより高い詐欺のリスクを有すると認識されてよい。また長期の顧客は、初めての顧客よりもより安全であると認識されてよい。いくつかの実施形態では、基準は、サーバがそれらの基準に基づき判断を行えるようにサーバ内に保存される。いくつかの実施形態では、販売者のコンピュータ(クライアント端末)は、支払いのより安全な処理の望ましさについての決定を行うことができる。クライアント端末は、サーバに決定を送信することが可能であり、基準およびサーバの判断は、完全にクライアント端末の決定に基づく。

サーバが簡易な支払いの処理に従うことを決定した(トランザクションが所定の基準を満たす)場合、サーバは、支払い完了結果をクライアント端末に送信する。支払い完了結果は、クライアント端末がアカウントを更新することが必要であるという情報を含んでよい。例えば、支払い完了結果は、売られる商品の分類および量、支払金額、ならびに購入者の識別子等を含んでよい。

サーバがより安全な支払いの処理に従うことを決定した（トランザクションが所定の基準を満たさない）場合、サーバは、支払い完了通知をクライアント端末に送信する(ステップS606)。いくつかの実施形態では、支払い完了通知は、サーバによって生成された固有の通知識別子を含み(S612)、それはクライアント端末からの支払い要求と関連付けられる。例えば、固有の通知識別子は、少なくとも一部、支払い認証応答において顧客から提供される固有の識別子から導き出され得る。支払い完了通知がアカウントを更新するために使用されることはできない。いくつかの実施形態では、サーバは支払い完了結果のみを送信する。このトランザクションが簡易な支払い処理に入るか、または安全な支払い処理に入るかを決定するのはクライアント端末である。

ステップS607において、クライアント端末はその後、ランダムに鍵を生成する。一般的なランダム鍵生成アルゴリズムが使用され得る。ランダムに生成された鍵が、その後、アカウントが更新されるまでメモリに保存される。所望の安全性レベルに依存して、ステップS607は、いくつかの実施形態における支払いのプロセスから省略され得る。

ステップS608において、クライアント端末は、鍵とともに支払い検証要求をサーバに送信する。支払い検証要求の情報は部分的に、支払い完了通知(例えば、サーバ生成通知ID(server-generated notification identifier))からのものである。支払い検証要求は、支払い検証要求がどの支払いに関連するかをサーバが識別するための十分な情報を含む。いくつかの実施形態では、支払い検証要求は、支払い要求および支払い完了通知とは異なる方法で安全が確保される。例えば、支払い要求を暗号化するために使用された鍵は、検証要求を暗号化するために使用されたものと異なってよい。

サーバが検証要求を受信した後、サーバは、支払い検証要求に関連する支払いが発生したか否か、または支払い検証要求(例えば、通知ID)のいくつかの情報が正しいか否かを検証する(S613)。サーバが支払いの存在または検証要求の情報の正確さを確認した場合、サーバは、支払い検証結果を準備する。

ステップS609において、サーバは鍵を用いて支払い検証結果を暗号化し、それをクライアント端末に送信する。ステップS610において、クライアント端末は、鍵を用いて支払い検証結果を復号する。

ランダムに生成された鍵の１つの利点は、トランザクション以前に漏えいする可能性がないということである。ビジネストランザクションにおける潜在的なリスクは、何者かが偽造した支払い完了通知を作成することができることである。クライアント端末または販売者は、支払いが行われたという誤った考えに基づいて商品を配送するように命令する可能性がある。ランダムに生成された鍵は、このような偽造された支払い検証結果を受信することを効果的に防ぐことが可能である。

ステップS611において、クライアント端末は、復号化された支払い検証結果からの情報に基づきアカウントを更新する。販売者は、更新されたアカウントに基づき品物を配送するための準備を行うことができる。

図7は、本発明の実施形態によって提供されるさらなる他のオンライン決済方法のフローチャートである。

オンライン決済処理は、トランザクション要求を販売者に送信する顧客と開始する(ステップS7001)。顧客は、販売者のウェブサイトを閲覧していて、所望するいくつかの品物を見つけ得る。顧客はその後、商業ウェブサイトとインタラクトしているコンピュータにトランザクション要求を送信するように、自身のコンピュータを操作する。

トランザクション要求を顧客端末から受信した場合、オンラインプラットフォームのクライアント端末である販売者のコンピュータは、オンライン決済要求をサーバに送信する(ステップS7002)。コンピュータは、ウェブサイトのコンテンツを配信するものであってもよいし、またはウェブサイトのコンテンツを配信するコンピュータとインタラクトすることができてもよい。オンラインプラットフォームが支払い要求に応答した後、顧客は、オンライン決済プラットフォームによってサポートされるオンライン決済インターフェイスに向けられる。例えば、顧客端末は、品物の名前、金額、および数量などのトランザクションに関連付けられた情報を含む支払い認証要求を受信し得る(S7000)。インターフェイスは、商業ウェブサイトの一部または独立したウェブサイトのどちらとしてでも表示されてよい。オンライン決済プラットフォームは、1つのアカウントから他のアカウントへお金を転送することが可能なシステムである。オンライン決済プラットフォームは、1または複数のサーバコンピュータによってサポートされる。

このインターフェイスを介して、顧客は、プラットフォームがある金額を自身のアカウントからオンライン決済プラットフォームへ転送することを認証する。顧客は、自身の顧客端末においてオンライン決済プラットフォームのサーバに支払い認証応答を送信するように操作することができる(ステップS7003)。支払い認証応答は、顧客の識別子を検証するための、例えば、ユーザ名、パスワード、およびセキュリティの質問などの情報を含む。いくつかの実施形態では、支払い認証応答は、顧客端末のユーザによって選択された固有の識別子を含んでよく、それは、電子署名の形式を取ってもよい。インターフェイスは、販売者のコンピュータがオンライン決済要求を送信する前後どちらでも表示されてよい。支払い認証応答は、転送されることが意図される金額および、場合によっては支払いの目的に関する情報を含んでもよい。いくつかの実施形態では、支払い認証応答は、販売者のコンピュータを介して送信される。

ステップS7004において、クライアント端末からの支払い要求および顧客端末からの支払い認証応答に基づき、サーバは、顧客からクライアントへの送金を処理することができる。いくつかの実施形態では、サーバは、銀行または資金管理エンティティのコンピュータと接続されており、銀行または資金管理エンティティにお金を転送するように命令する。

ステップS7005は、本発明のいくつかの実施形態において存在する。ステップS7005において、サーバは、購入者/顧客と販売者/クライアントとの間のトランザクションが予め設定されたある基準を満たすか否かを判断する。いくつかの実施形態では、販売者は、あるトランザクションにはより安全な支払いの処理を望む一方で、その他のトランザクションにはより簡易な支払いの処理を望む。販売者は、トランザクションのリスクに基づき所定の基準を設定することができる。所定の基準は、関連する品物の種類、トランザクションの支払いの合計金額、顧客の過去の履歴、および複数の要因を複合したものを含むことができる。例えば、仮想の品物は、有形の物よりもより高い詐欺のリスクを有すると認識されてよい。また長期の顧客は、初めての顧客よりもより安全であると認識されてよい。いくつかの実施形態では、基準は、サーバがそれらの基準に基づき判断を行えるようにサーバ内に保存される。いくつかの実施形態では、販売者コンピュータ(クライアント端末)は、支払いのより安全な処理の望ましさについての決定を行うことができる。クライアント端末は、サーバに決定を送信することが可能であり、基準およびサーバの判断は、完全にクライアント端末の決定に基づく。

サーバが簡易な支払いの処理に従うことを決定した(トランザクションが所定の基準を満たす)場合、サーバは、支払い完了結果をクライアント端末に送信する(ステップS7106)。支払い完了結果は、クライアント端末がアカウントを更新することが必要であるという情報を含んでよい。

サーバがより安全な支払いの処理に従うことを決定した（トランザクションが所定の基準を満たさない）場合、サーバは、支払い完了通知をクライアント端末に送信する(ステップS7006)。いくつかの実施形態では、支払い完了通知は、支払い要求に関係付けられた固有の通知識別子を含む。固有の通知識別子は、顧客端末のユーザによって提供される支払い認証応答内の情報に少なくとも一部基づき生成され得る。支払い完了通知は、アカウントを更新するために使用されることはできない。いくつかの実施形態では、サーバは支払い完了結果のみを送信する。このトランザクションが簡易な支払い処理に入るか、または安全な支払い処理に入るかを決定するのはクライアント端末である。

ステップS7007において、クライアント端末はその後、ランダムに鍵を生成する。一般的なランダム鍵生成アルゴリズムが使用され得る。ランダムに生成された鍵が、その後、アカウントが更新されるまでメモリに保存される。所望の安全性レベルに依存して、ステップS7007は、いくつかの実施形態における支払いのプロセスから省略され得る。

ステップS7008において、クライアント端末は、鍵とともに支払い検証要求をサーバに送信する。支払い検証要求の情報は、部分的に、支払い完了通知からのものである。支払い検証要求は、支払い検証要求がどの支払いに関連するかをサーバが識別するための十分な情報を含む。いくつかの実施形態では、支払い検証要求は、支払い要求および支払い完了通知とは異なる方法で安全が確保される。例えば、支払い要求を暗号化するために使用された鍵は、検証要求を暗号化するために使用されたものと異なってよい。

サーバが検証要求を受信した後、サーバは、例えばサーバ生成通知識別子を使用して、支払い検証要求に関連する支払いが発生したか否か、または支払い検証要求のいくつかの情報が正しいか否かを検証する。サーバが支払いの存在または検証要求の情報の正確さを確認した場合、サーバは、支払い検証結果を準備する。

ステップS7009において、サーバは鍵を用いて支払い検証結果を暗号化し、それをクライアント端末に送信する。ステップS7010において、クライアント端末は、鍵を用いて支払い検証結果を復号する。いくつかの実施形態では、支払い検証結果は、売られる商品の分類および量、支払金額、ならびに購入者の識別子等を含む。このような情報は、クライアントがトランザクション記録の正確さを確かめることを手助けする。

ステップS7011において、クライアント端末は、暗号化された支払い検証結果からの情報に基づきアカウントを更新する。販売者は、更新されたアカウントに基づき品物の配送を準備することができる。

図8は、本発明のインタラクティブ処理システムの実施形態の概略的な構成図である。説明のしやすさから、要求エンドおよび処理エンドの両方が含まれる図8における例を用いる。

図8に示されるように、この例におけるインタラクティブ処理システムは、要求エンド801および処理エンド802を含む。
・要求エンド801は、処理要求情報を処理エンド802に送信し、処理要求情報に基づき処理エンド802によって返される通知IDを受信し、通知IDに基づき通知クエリ要求情報を処理エンド802に送信し、通知クエリ要求情報に基づき処理エンド802から返される、通知IDに対応する処理結果を受信するように構成される。
・処理エンド802は、要求エンド801によって送信される処理要求情報を受信し、処理要求情報に基づき処理を行って処理結果に基づき通知IDを送信し、通知IDを要求エンド801に送信し、通知IDに基づき要求エンド801によって送信される通知クエリ要求情報を受信し、通知クエリ要求情報に基づき通知IDに対応する処理結果を要求エンド801に送信するように構成される。

特定の例において、要求エンド801は特に以下を含む。
・処理要求情報および通知クエリ要求情報を生成するように構成される要求情報生成ユニット8011。
・処理要求情報および通知クエリ要求情報を処理エンド802に送信し、処理エンド802によって返される通知IDおよび通知IDに対応する処理結果を受信するように構成される要求エンド情報送受信器モジュール8012。

処理エンド802は、特に以下を含んでもよい。
・要求エンド801によって送信された処理要求情報および通知クエリ要求情報を受信し、処理モジュール8022によって取得された通知IDおよびクエリモジュール8023によるクエリを介して取得された処理結果を要求エンド801に送信するように構成される処理エンド情報送受信器モジュール。
・処理要求情報に基づき処理を行って処理結果を取得し、処理結果に基づき通知IDを生成するように構成される処理モジュール8022。
・通知クエリ要求情報に基づき通知IDに対応する処理結果を取得するように構成されるクエリモジュール8023。

他の特定の例では、処理エンド情報送受信器モジュール8021は、通知IDを要求エンド801に送信すると同時に、処理モジュール8022によって取得された処理結果を要求エンド801に送信するようにも構成される。

対応して、要求エンド情報送受信器モジュール8012は、処理要求情報に基づき処理エンド802によって返される処理結果を受信するようにも構成される。つまり、処理結果は処理モジュール8022によって取得され、処理エンド情報送受信器モジュール8021によって送信される。いくつかの実施形態では、情報送受信器モジュール8021は、支払い検証結果を復号するための能力があってもよい。

その他の特定の例では、要求エンド801は、通知クエリ命令を受信するように構成される命令受信ユニット8013をさらに含んでもよい。

対応して、要求情報生成ユニット8011は、命令受信ユニット8013によって受信された通知クエリ命令に基づき通知クエリ要求情報を生成するように構成されてもよい。要求情報生成ユニットは、図6および7で説明されたような支払い検証要求とともに送信されるランダムな鍵を生成するようにさらに構成されてもよい。

その他の特定の例では、処理エンドは、通知IDが生成される必要があるか否かを判断するように構成される分析判断ユニット8024をさらに含んでもよい。分析判断ユニット8024は、トランザクションがある基準を満たすか否かを判断するようにさらに構成される。

処理モジュール8022は、分析判断ユニット8024が、通知IDが生成される必要があることを決定した場合に、処理結果に基づき通知IDを生成する。処理モジュール8022は、支払い完了結果および支払い完了通知の両方を生成するように構成される。

クエリモジュール8023は、処理結果(支払い完了結果または支払い検証結果のいずれか一つ)を取得するように構成される。クエリモジュールは、売られる商品の分類および量、支払金額、ならびに購入者の識別子等の情報に関連するトランザクションを獲得するように構成される。クエリモジュールは、支払い検証結果内の情報に基づく情報に関連するトランザクションを獲得し、それを送受信器モジュールに送信することができる。

特定の応用では、要求エンド801が商業ウェブサイトであってよく、対応して処理エンド802は、支払いプラットフォームウェブサイトまたは銀行のウェブサイトであってよい。

商業ウェブサイトでは、注文の支払いは、支払いプラットフォームウェブサイトまたは銀行のウェブサイトによって処理されること要求される。従って、支払いプラットフォームウェブサイトまたは銀行のウェブサイトによって返される、通知IDに対応する処理結果を受信した後、商業ウェブサイトは、処理結果に基づき注文の状態を更新することができる。この場合、要求エンド801は、支払いプラットフォームウェブサイトによって返される、通知IDに対応する処理結果に基づき注文の状態を更新するように構成される更新モジュール8014を含んでもよい。

本発明のインタラクティブ処理システムのその他の技術的特徴は、本発明のオンライン決済のインタラクティブ処理方法のものと同様であり、ここで再び説明しない。

以上で説明された実施形態は、単に本発明のいくつかの実施方法を示すのみであって、その説明は具体的かつ詳細であるが、本発明の範囲を限定するように理解されるべきではない。当業者は、本発明の主旨から逸脱することのなく変更や改良を行うことが可能であり、それらの変更および改良の全ては本発明の保護範囲に入ることに注意されたい。従って、本発明の保護範囲は、添付の特許請求の範囲に基づくものである。

特定の実施形態が以上で説明されたが、このような説明は、本発明をこれら特定の実施形態に限定する意図はない。対照的に、本発明は、添付の特許請求の範囲の保護範囲内および趣旨内の代替物、変更物、および等価な物を含む。様々な特定の詳細が、本明細書で提供される主題の十分な理解を提供するために説明された。しかし、これらの特定の詳細なしに主題を実施可能であることは、当業者には明らかであろう。他の例では、周知の方法、手順、構成要素、および回路は、実施形態の態様を不必要に不明確にしないように、詳細には説明されなかった。

語句、第1および2等は、様々な要素を説明するためにここでは使用されたが、これらの要素はそれらの語句に限定されるべきではない。これらの語句は、1つの要素を他のものと区別するためだけに使用される。例えば本発明の請求の範囲から逸脱せずに、第1の順序基準は、第2の順序基準と呼ばれてもよく、同様に第2の順序基準は第1の順序基準と呼ばれてもよい。第1の順序基準および第2の順序基準は、両方とも順序基準であるが、同じ順序基準ではない。

ここにおいて本発明の説明で使用された専門用語は、特定の実施形態を説明するためだけのものであり、本発明の限定を意図するものではない。本発明の説明および添付の特許請求の範囲で使用されるように、単数形「a」、「an」、および「the」は、文脈上明らかにそうでない場合を示すときを除き、複数形を含むことが意図される。ここで使用された語句「および/または(and/or)」は、1または複数の関連する列挙された項目の全ての可能な組み合わせ示すとともに、包含する。この明細書において使用される場合の語句「含む(includes)」、「含んでいる(including)」、「含む/備える(comprises)」、および/または「含んでいる/備えている(comprising)」は、述べられた特徴の存在、操作、要素、および/または構成要素を特定するが、1または複数のその他の特徴、操作、要素、構成要素、および/またはそれらの組の存在または追加を排除しないことは、理解されるだろう。

ここで使用されたように、語句「の場合(if)」は、文脈に応じて、「ときに(when)」、「において(upon)」、「を決定することに応答して(in response to determining)」、「の決定に従って(in accordance with a determination)」、または、述べられた条件の先例(precedent)が真であること「を検出することに応答して(in response to detecting)」を意味すると解釈することが可能である。同様に、語句「(述べられた条件の先例が真であることが)決定された場合(if it is determined [that a stated condition precedent is true])」、「(述べられた条件の先例が真である)場合(if [a stated condition precedent is true])」、および「(述べられた条件の先例が真である)とき(when [a stated condition precedent is true])」は、文脈に応じて、述べられた条件の先例が真であること「を決定したことにおいて(upon determining)」、「を決定したことに応答して(in response to determining)」、「の決定に従って(in accordance with a determination)」、「を検出したことにおいて(upon detecting)」、または、「を検出したことに応答して(in response to detecting)」を意味する。

様々な図面のいくつかは、特定の順番での論理的な段階の数字を示したが、順番について依存しない段階は、順序を再び付け直すことが可能であり、その他の段階を組み合わせる、または切り離すことも可能である。いくつかの再順序付けやその他のグループ分けが特に説明されたが、その他のものも当業者にとっては明らかであり、代替物の包括的な列挙は提供しない。さらに、段階は、ハードウェア、フォームウェア、ソフトウェア、またはそれらの全ての組み合わせにおいて実施され得ることを認識されたい。

説明の目的のための以上の記述は、特定の実施を参照しながら説明されてきた。しかし、以上の図解的な議論は、包括的なものを意図するものではなく、また開示された正確な形態に本発明を限定する意図もない。様々な修正や変更が以上の教示から可能である。実施は、本発明の原理およびその実際の応用をできる限り説明するために選択され、説明されたものであり、これによって、当業者は、予期される特定の使用に合うような様々な修正を用いて本発明および様々な実施を利用することができる。実施は、添付の特許請求の範囲の保護範囲および趣旨内の代替物、修正物、および等価な物を含む。様々な特定の詳細が、ここで提供される主題の十分な理解を提供するために説明された。しかし、当業者がこれらの特定の詳細なしに主題を実施可能であることは、明らかであろう。他の例では、周知の方法、手順、構成要素、および回路は、実施形態の態様を不必要に不明確にしないように詳細が説明されなかった。

８０１ 要求エンド
８０２ 処理エンド
８０１１ 要求情報生成ユニット
８０１２ 要求エンド情報送受信器モジュール
８０１３ 命令受信ユニット
８０１４ 更新モジュール
８０２１ 情報送受信器モジュール
８０２１ 処理エンド情報送受信器モジュール
８０２２ 処理モジュール
８０２３ クエリモジュール
８０２４ 分析判断ユニット

Claims (22)

1. プロセッサと、前記プロセッサによって実行される1または複数のプログラムを記録するためのメモリとを有するクライアント端末において行われるオンライン決済の方法であって、
   ユーザアカウントに関連付けられた支払い要求を支払い処理サーバに送信するステップと、
   前記支払い処理サーバから支払い完了通知を受信するステップであって、前記支払い完了通知が前記支払い要求に関連付けられた固有の通知識別子を含む、ステップと、
   前記固有の通知識別子に基づく支払い検証要求を前記支払い処理サーバに送信するステップと、
   前記支払い処理サーバから支払い検証結果を受信するステップと、
   前記支払い検証結果内の情報に基づいてユーザアカウントを更新するステップとを含む方法。
2. 前記支払い検証結果が、前記クライアント端末内に予め記録された鍵を使用して、前記クライアント端末によって復号されるように構成される、請求項1に記載の方法。
3. 前記支払い検証結果が、前記支払い処理サーバ内に予め記録された鍵を使用して、前記支払い処理サーバによって暗号化されるように構成される、請求項2に記載の方法。
4. 前記支払い要求が前記支払い処理サーバに送信される前に、前記ユーザアカウントに関連付けられた端末からトランザクション要求を受信するステップであって、前記支払い要求が、前記トランザクション要求内の情報の少なくとも一部を含む、ステップをさらに含む、請求項1に記載の方法。
5. 前記支払い検証結果が、トランザクションの品物の分類および量に関連する情報を含む、請求項1に記載の方法。
6. 前記クライアント端末が、商業ウェブサイトと関連付けられる、請求項1記載の方法。
7. 前記支払い処理サーバが、前記支払い要求の受信に際して、支払いプラットフォームウェブサイトまたは銀行のウェブサイトとインタラクトするように構成される、請求項1に記載の方法。
8. プロセッサと前記プロセッサによって実行される1または複数のプログラムを記録するためのメモリとを有する支払い処理サーバにおいて行われるオンライン決済の方法であって、
   クライアント端末から支払い要求を受信するステップであって、前記支払い要求がユーザアカウントに関連付けられた端末からのトランザクション要求に応答して生成される、ステップと、
   支払い完了通知を生成し、前記クライアント端末に送信するステップであって、前記支払い完了通知が前記支払い要求に関連付けられた固有の通知識別子を含む、ステップと、
   前記クライアント端末から支払い検証要求を受信するステップと、
   前記固有の通知識別子を使用して前記支払い検証要求を検証するステップと、
   支払い検証結果を生成し、前記クライアント端末に送信するステップとを含む、方法。
9. 前記支払い検証結果が、トランザクションの品物の分類および量に関する情報を含む、請求項8に記載の方法。
10. 前記クライアント端末が、商業ウェブサイトに関連付けられる、請求項8に記載の方法。
11. 前記支払い処理サーバが、前記支払い要求の受信に際して、支払いプラットフォームウェブサイトまたは銀行のウェブサイトとインタラクトするように構成される、請求項8に記載の方法。
12. 前記支払い完了通知を生成し、前記クライアント端末に送信する前に、前記ユーザアカウントに関連付けられた前記端末に支払い認証要求を送信するとともに、前記ユーザアカウントに関連付けられた前記端末からの支払い認証応答を受信し処理するステップをさらに含む、請求項8に記載の方法。
13. 前記支払い認証応答が、前記ユーザアカウントに関連付けられた前記端末のユーザによって提供される固有の識別子を含み、前記固有の識別子が前記固有の通知識別子を生成するために使用される、請求項12に記載の方法。
14. オンライン決済を処理するサーバであって、
    1または複数のプロセッサと、
    メモリと、
    前記プロセッサによって実行され、前記メモリに記録される1または複数のプログラムとを備え、
    前記1または複数のプログラムは、
    クライアント端末から支払い要求を受信することであって、前記支払い要求がユーザアカウントに関連付けられた端末からのトランザクション要求に応答して生成される、ことと、
    支払い完了通知を生成し、前記クライアント端末に送信することであって、前記支払い完了通知が前記支払い要求に関連付けられた固有の通知識別子を含む、ことと、
    前記クライアント端末から支払い検証要求を受信することと、
    前記固有の通知識別子を使用して前記支払い検証要求を検証することと、
    支払い検証結果を生成し、前記クライアント端末に送信することとを行うための命令を含む、サーバ。
15. 前記1または複数のプログラムが、
    前記支払い完了通知を生成し、前記クライアント端末に送信する前に、前記ユーザアカウントに関連付けられた前記端末に支払い認証要求を送信するとともに、前記ユーザアカウントに関連付けられた前記端末からの支払い認証応答を受信し処理することを行うための命令をさらに含む、請求項14に記載のサーバ。
16. 前記支払い認証応答が、前記ユーザアカウントに関連付けられた前記端末のユーザによって提供される固有の識別子を含み、前記固有の識別子が、前記固有の通知識別子を生成するために使用される、請求項15に記載のサーバ。
17. 前記クライアント端末が、商業ウェブサイトによって関連付けられる、請求項14に記載のサーバ。
18. 前記1または複数のプログラムが、
    前記支払い完了通知を生成し、前記クライアント端末に送信する前に、前記支払い要求に関連付けられたトランザクションがある所定の基準を満たすか否かを判断することを行うための命令をさらに含む、請求項14に記載のサーバ。
19. 前記所定の基準が、前記トランザクションでの品物の種類に関連する、請求項18に記載のサーバ。
20. 前記所定の基準が、前記トランザクションでの顧客の種類に関連する、請求項18に記載のサーバ。
21. 前記支払い検証結果が、前記トランザクションの品物の分類および量に関連する情報を含む、請求項18に記載のサーバ。
22. 前記1または複数のプログラムが、前記支払い要求の受信に際して、支払いプラットフォームウェブサイトまたは銀行のウェブサイトとインタラクトすることを行うための命令をさらに含む、請求項14に記載のサーバ。

Images