JP6721724B2 - 支払い主体の拡張を促進する方法およびデバイス - Google Patents

Description

本出願は、2016年６月28日に出願されると共に、「支払い主体の拡張を促進する方法およびデバイス」と称された中国特許出願第 20160496083.7 号の優先権を主張するものであり、その全体が言及したことにより本明細書中に援用される。

本出願は、インターネット技術の分野、特に、支払い主体（primary payment instrument）の拡張を促進する方法およびデバイスに関する。

インターネット技術の急速な発展と共に、電子的支払いは、その便利さおよび迅速さの利点の故に、次第に習用の支払い方法に代用されつつある。関連する技術において、電子的支払いの過程においてユーザの支払い情報の安全な送信を確実とするために、典型的には、銀行カード番号の如き支払い主体が暗号文の形式で送信される。リスク管理プラットフォーム、金融ゲートウェイなどの如き適切なプラットフォームは、前記暗号文を通して、対応する支払い主体を検索し得る。しかし、斯かる実現方式においては、支払い主体の拡張に伴い、支払い主体の本来的なモデルが、業務の需要を満足すべく継続的にアップグレードされねばならず、膨大な量の開発コストに帰着する。

上記に鑑み、本出願は、支払い主体の拡張を促進する方法およびデバイスを提供する。

たとえば、本出願は、
支払い主体の種類を決定する段階と、
前記種類に対応する主鍵生成規則を検索する段階と、
前記主鍵生成規則に従い、前記支払い主体に対する支払い主鍵を生成し、且つ、前記支払い主体とそれの支払い主鍵との間の対応関係を記憶する段階と、
を備えて成り、
前記主鍵生成規則は、前記支払い主鍵を生成するための支払い主体要素を指定し、且つ、複数の異なる種類の支払い主体に対応する夫々の主鍵生成規則は、夫々の支払い主鍵を生成する異なる支払い主体要素を指定する、
サーバ上で適用可能である、支払い主体の拡張を促進する方法、
により実現される。

選択的に、前記主鍵生成規則に従い、前記支払い主体に対する支払い主鍵を生成する前記段階は、
前記主鍵生成規則により指定された支払い主体要素を、主鍵生成要素として獲得する段階と、
前記主鍵生成規則により指定された順序に従い、各主鍵生成要素を整列処理する段階と、
事前設定アルゴリズムに従い、前記整列処理された主鍵生成要素の暗号文を、前記支払い主体に対して生成された前記支払い主鍵として算出する段階と、
を備えて成る。

選択的に、前記方法は、
リスク管理プラットフォームにより送信された目標支払い主鍵を担持する主鍵照会要求を受信すると同時に、前記目標支払い主鍵に対応する目標支払い主体を検索し、且つ、前記目標支払い主体の全ての目標支払い主体要素を前記リスク管理プラットフォームに対して返信する段階と、
前記リスク管理プラットフォームにより送信されたリスク管理要素を担持する要素照会要求を受信すると同時に、各リスク管理要素を含む支払い主体のリストを検索し、且つ、該支払い主体のリストを前記リスク管理プラットフォームに対して返信し、その場合に各リスク管理要素は、全ての目標支払い主体要素の部分集合である段階と、
を更に備えて成る。

選択的に、支払い主体の種類を決定する前記段階は、
支払い主体に対する登録要求を受信すると同時に、前記支払い主体の種類を決定する段階、
を備えて成る。

選択的に、前記方法は、
前記主鍵生成規則が更新されたとき、更新された主鍵生成規則に従い、前記支払い主体に対する別の支払い主鍵を再生成する段階と、
前記支払い主体とそれの本来的な支払い主鍵との間の対応関係の記憶に基づき、前記支払い主体と、それの再生成された支払い主鍵と、の間の対応関係を記憶する段階と、
を更に備えて成る。

支払い主体の種類を決定すべく構成された種類決定ユニットと、
前記種類に対応する主鍵生成規則を検索すべく構成された規則検索ユニットと、
前記主鍵生成規則に従い、前記支払い主体に対する支払い主鍵を生成し、且つ、前記支払い主体とそれの支払い主鍵との間の対応関係を記憶すべく構成された主鍵生成ユニットと、
を備えて成り、
前記主鍵生成規則は、前記支払い主鍵を生成するための支払い主体要素を指定し、且つ、複数の異なる種類の支払い主体に対応する夫々の主鍵生成規則は、夫々の支払い主鍵を生成する異なる支払い主体要素を指定する、
サーバ上で適用可能である、支払い主体の拡張を促進するデバイス。

選択的に、前記主鍵生成ユニットは、
前記主鍵生成規則により指定された支払い主体要素を、主鍵生成要素として獲得すべく構成された要素獲得下位ユニットと、
前記主鍵生成規則により指定された順序に従い、各主鍵生成要素を整列処理すべく構成された要素整列処理下位ユニットと、
事前設定アルゴリズムに従い、前記整列処理された主鍵生成要素の暗号文を、前記支払い主体に対して生成された前記支払い主鍵として算出すべく構成された主鍵生成下位ユニットと、
を備えて成る。

選択的に、前記デバイスは、
リスク管理プラットフォームにより送信された目標支払い主鍵を担持する主鍵照会要求を受信すると同時に、前記目標支払い主鍵に対応する目標支払い主体を検索し、且つ、前記目標支払い主体の全ての目標支払い主体要素を前記リスク管理プラットフォームに対して返信すべく構成された第１返信ユニットと、
前記リスク管理プラットフォームにより送信されたリスク管理要素を担持する要素照会要求を受信すると同時に、各リスク管理要素を含む支払い主体のリストを検索し、且つ、該支払い主体のリストを前記リスク管理プラットフォームに対して返信すべく構成された第2返信ユニットであって、その場合に各リスク管理要素は、全ての目標支払い主体要素の部分集合であるという第２返信ユニットと、
を更に備えて成る。

選択的に、前記種類決定ユニットは、支払い主体に対する登録要求を受信すると同時に、前記支払い主体の種類を決定すべく構成される。

選択的に、前記デバイスは、
前記主鍵生成規則が更新されたとき、更新された主鍵生成規則に従い、前記支払い主体に対する別の支払い主鍵を再生成すべく構成された規則更新ユニットと、
前記支払い主体とそれの本来的な支払い主鍵との間の対応関係の記憶に基づき、前記支払い主体と、それの再生成された支払い主鍵と、の間の対応関係を記憶すべく構成された規則記憶ユニットと、
を更に備えて成る。

上記説明からは、本出願に係る支払い主鍵生成解決策においては、支払い主体の種類に対応する主鍵生成規則に従い、支払い主体に対する支払い主鍵が生成され得ることが理解され得る。たとえば、新たな種類の支払い主体の付加、または、支払い主体に対する新たな支払い主体要素の付加などの、支払い主体の拡張時には、モデル全体を再開発する必要なしで主鍵生成規則が更新されることから、開発コストが相当に低減され得る。

本出願の幾つかの実施形態に係る、支払い主体の拡張を促進する代表的な方法のフローチャートである。 本出願の幾つかの実施形態に係る、支払い主体のための支払い主鍵を生成する代表的な方法のフローチャートである。 本出願の幾つかの実施形態に係る、リスク管理プラットフォームとサーバとの間における相互作用の代表的な方法の概略図である。 本出願の幾つかの実施形態に係る、リスク管理プラットフォームとサーバとの間の相互作用の代表的なネットワークの概略図である。 本出願の幾つかの実施形態に係る、支払い主体の拡張を促進する代表的なデバイスの概略的な構造図である。 本出願の幾つかの実施形態に係る、支払い主体の拡張を促進する代表的なデバイスの構造的ブロック図である。

以下においては、好適実施形態が記述されると共に、その実例は、添付図面中に示される。以下の記述が添付図面を伴うとき、別様に明示されるのでなければ、異なる図中における同一の番号は、同一もしくは同様の要素を表す。以下における実施方式は、本出願に一致する全ての実施方式を表してはいない。逆に、これらの実施方式は、添付の各請求項中に詳細に記述される本出願の幾つかの見地に一致するデバイスおよび方法の単なる実例にすぎない。

本出願において使用される語句は、本出願を限定する代わりに、幾つかの実施形態を記述することのみが意図される。本出願および添付の各請求項において使用される単数形の“ひとつの”、“上記の”および、“その”という語句は、文脈において他の意味が明確に示されるのでなければ、その複数形を包含することも意図される。本明細書中で使用される“および／または”という語句は、列挙されたひとつ以上の関連する対象物の任意のまたは全ての可能的な組み合わせを参照かつ包含することも理解されるべきである。

本出願において、第１、第２、第３などの語句は、種々の情報を記述すべく使用され得るが、その情報は、これらの語句に限定されるのでないことが理解されるべきである。これらの語句は、同一の形式の情報を区別するためにのみ使用される。たとえば、変更が本出願の有効範囲から逸脱しないのであれば、第１情報は第２情報とも称され得ると共に、同様に、第２情報は第１情報とも称され得る。文脈に依存し、本明細書中で使用される「もし〜ならば」という語句は、「〜ときに」、「ちょうど〜するころに」、または、「〜の決定に応じて」と解釈され得る。

関連技術の一例において、ユーザは、アリペイ・クライアントを使用して電子的支払いを行うと共に、アリペイ・クライアントの口座番号は携帯電話番号である。最初に、ユーザは、サード・パーティの支払いプラットフォーム、すなわちバイドゥ・ウォレットの口座番号をアリペイ・クライアント内にバンドルし、且つ、ユーザがアリペイ・クライアントを使用して電子的支払いを行うとき、サーバは、現在の主鍵生成モデルに基づき、ユーザの携帯電話番号と認証されたユーザの真の氏名とに従い、バイドゥ・ウォレットの暗号文を生成すると共に、該暗号文を返信し得る。引き続き、上記暗号文に従い、前記サーバは、ユーザのバンドルされた支払い主体、すなわちバイドゥ・ウォレットを検索して見出し得る。

別の例において、ユーザは更に、別のサード・パーティの支払いプラットフォーム、すなわち JD ペイの口座番号をバンドルする。上述の主鍵生成モデルに基づき、前記サーバは、ユーザの携帯電話番号と真の氏名とに従い、JD ペイの口座の暗号文も生成し得る。しかし、前記暗号文は、２つのサード・パーティの支払いプラットフォーム、すなわちバイドゥ・ウォレットおよび JD ペイの夫々の口座に対応する。次続的な相互作用プロセスにおいて、ユーザがバイドゥ・ウォレットを選択するのか JD ペイを選択するのかを決定することは不可能である。故に、上述の主鍵生成モデルは、もはや適用可能でない。新たなモデルが開発されるべきであり、相当の開発コストに帰着する。

上記に鑑み、本出願は、支払い主体に対する汎用モデルを提供し得る、支払い主体の拡張を促進するための解決策を提供する。

図１は、本出願の幾つかの実施形態に係る、支払い主体の拡張を促進する代表的な方法のフローチャートである。

図１を参照すると、支払い主体の拡張を促進する方法は、サーバ上に適用されると共に、以下の各ステップを備えて成り得る：

ステップ 101：支払い主体の種類を決定する段階。

本実施形態において、電子的支払いを行うとき、ユーザは典型的に、支払いを完了するために、銀行カード、サード・パーティの支払いプラットフォームの口座番号などの情報の使用を必要とする。これらのプロセスにおいて、銀行カードと、サード・パーティの支払いプラットフォームの口座番号と、が支払い主体である。

本実施形態において、支払い主体要素は、前記支払い主体の情報である。たとえば、支払い主体がクレディット・カードであるとすると、その支払い主体要素は典型的に、カード番号、有効期限、暗証番号、口座名義などを備えて成る。一例として、支払い主体がサード・パーティの支払いプラットフォームであるとすると、その支払い主体要素は典型的に、口座名義、プラットフォーム識別情報などを備えて成る。各支払い主体は、一意的な一群の支払い主体要素に対応する。換言すると、一群の支払い主体要素が、一意的な支払い主体を決定し得る。

本実施形態において、支払い主体の拡張を促進する方法を実施するサーバは、典型的には、支払い主体を記憶すべく電子的支払いサービス・プロバイダにより展開されるサーバである。一例として、電子的支払いサービス・プロバイダがアリペイであるとすると、サーバは、アリペイ・ユーザによりアリペイにバンドルされた銀行カード、アリペイ以外のサード・パーティの支払いプラットフォームの口座番号などの如き支払い主体を記憶すべく使用される。

本実施形態において、前記サーバは、支払い主体に対する登録要求の受信時に、支払い主体の種類を決定し得、その場合、前記登録要求は典型的にはユーザにより開始される。たとえば、ユーザが、新たに発行されたクレディット・カードをアリペイにバンドルすることを望むなら、ユーザは、アリペイ・クライアントにおいて、支払い主体に対する登録要求（すなわち、バンドル要求）を開始し得る。一例において、前記クライアントは、前記登録要求中に、ユーザにより入力されたクレディット・カードの情報、すなわち、クレディット・カードの支払い主体要素を含むと共に、該登録要求をサーバに対して送信し得る。前記登録要求の受信時に、サーバは、支払い主体の全ての支払い主体要素を記憶すると共に、該サーバはその後、各支払い主体要素に従って支払い主体の種類を決定し得る。実際に実現する際には、支払い主体の登録のプロセスにおいては、典型的に、本出願によっては詳述されない適切な技術に従い、ユーザの身分認証の如き操作が実施される必要がある。

本実施形態において、ひとつの種類の支払い主体は、各支払い主体の特徴に従って開発者により設定され得るという、全てのネットワークに適合する銀行カード、預金通帳、サード・パーティの支払いプラットフォームの口座番号などを備えて成り得る。一例において、前記サーバはまず、支払い主体の概略的カテゴリの識別情報に従い、支払い主体が属する概略的カテゴリを決定し得、その場合、支払い主体の概略的カテゴリは、ユーザにより入力され得る。たとえば、ユーザが支払い主体をバンドルするとき、クライアントは、ユーザが選択する支払い主体の概略的カテゴリの選択肢を提供し得る。たとえば、前記クライアントは、ユーザに対し、“銀行カードもしくは預金通帳をバンドルする”および“サード・パーティの支払いプラットフォームの口座番号をバンドルする”の如き選択肢を表示し得ると共に、ユーザは、支払い主体の種類に従い、選択を行い得る。前記サーバに対して登録要求を送信するとき、前記クライアントは、ユーザにより選択された概略的カテゴリの識別情報を、支払い主体要素としてサーバに対して送信し得る。支払い主体の種類を決定するとき、サーバはまず、各支払い主体要素における概略的カテゴリの識別情報に従い、支払い主体の概略的カテゴリを決定してから、具体的種類を決定し得る。

たとえば、支払い主体の概略的カテゴリが、銀行カードおよび預金通帳の如き金融機関により発行された支払い主体であると仮定すると、前記サーバは更に、支払い主体の具体的種類を決定するために、カード番号の桁数、所定の桁におけるキャラクタ、および、支払い主体要素における他の情報に従い、前記支払い主体が、全てのネットワークに適合する銀行カードであるか、預金通帳であるかを更に決定し得る。

ステップ 102：前記種類に対応する主鍵生成規則を検索する段階。

上述のステップ 101 に基づき、支払い主体の種類が決定された後、該種類に対応する主鍵生成規則が検索され得、その場合、典型的には、支払い主鍵を生成するための各支払い主体要素の如き情報、生成アルゴリズムなどを備えて成る主鍵生成規則は、支払い主体に対する支払い主鍵を生成する開発者により事前設定され得る。典型的に、複数の異なる種類の支払い主体に対応する夫々の主鍵生成規則は、夫々の支払い主鍵を生成する異なる支払い主体要素を指定する。

本実施形態において、支払い主鍵は、支払い主体に対応する識別情報である。ひとつの支払い主鍵は、一意的な支払い主体を決定し得る。支払い主鍵は、一意的な支払い主体を決定し得る一群の支払い主体要素に基づいて生成された暗号文と見做され得ると共に、電子的支払いの間において支払い主体の代わりに相互作用および送信のために使用されることで、ユーザの支払い主体の安全性を確実とし得る。

ステップ 103：前記主鍵生成規則に従い、支払い主体に対する支払い主鍵を生成し、且つ、支払い主体と、それの支払い主鍵と、の間の対応関係を記憶する段階。

本実施形態において、支払い主体とそれの支払い主鍵との間の対応関係が記憶された後、サーバは、支払い主鍵に対する要求、および、支払い主体に関する照会などに対するサービスを、他の関連する業務プラットフォームに対して提供し得る。

一例において、たとえば、新たな種類の支払い主体の追加、または、支払い主体に対する新たな支払い主体要素の追加などの、支払い主体の拡張時に、開発者は、主鍵生成規則を更新して、支払い主体モデル全体の更新を達成し得る。

たとえば、支払い主体として預金通帳を用いる電子的支払い業務が処理されつつあるときに、電子的支払いの間に預金通帳を決定する各支払い主体要素が、預金通帳形式の支払い主体に関し、一群の支払い主体要素に従って一意的な預金通帳が決定され得ることを確実とすべく拡張されると仮定する。口座番号、口座名義、および、取引銀行を含む本来的な支払い主体要素に対し、口座開設日が付加される。開発者は、たとえば、たとえば口座開設日などの支払い主体要素を、支払い主鍵を生成する預金通帳に対応する主鍵生成規則へと付加することにより、新たに付加された口座開設日に従い、主鍵生成規則を更新し得る。前記主鍵生成規則が更新された後、前記サーバは、新たな主鍵生成規則に従い、記憶された預金通帳の各々に対する新たな支払い主鍵を生成してから、従前の支払い主鍵を削除せずに、預金通帳とそれの新たな支払い主鍵との間の対応関係を記憶し得る。これは、次続的な払い戻しおよび顧客サービスが円滑に実施され得る如く、主鍵生成規則の更新に先立つ電子的支払い業務に関する払い戻し、顧客の苦情などの場合に、依然として、預金通帳の従前の支払い主鍵に基づいて預金通帳が見出され得るからである。

上記説明からは、本出願に係る支払い主鍵生成解決策において、支払い主鍵は、支払い主体の種類に対応する主鍵生成規則に従い、支払い主体に対して生成され得ることが理解され得る。たとえば、新たな種類の支払い主体の付加、または、支払い主体に対する新たな支払い主体要素の付加などの、支払い主体の拡張時には、モデル全体を再開発する必要なしで主鍵生成規則のみの更新が必要とされることから、開発コストが相当に低減される。

本出願の一例において、図２を参照すると、主鍵生成規則に従い、支払い主体に対する支払い主鍵を生成するプロセスは、以下の各ステップを備えて成り得る：

ステップ 201：各主鍵生成要素として、主鍵生成規則により指定された支払い主体要素を獲得する段階。

本実施形態において、対応する種類の支払い主体において一意的な支払い主体を決定し得る支払い主体要素は、主鍵生成規則により指定される。たとえば、主鍵生成規則に対応する支払い主体の種類が、全てのネットワークに適合する銀行カード、すなわち、Visa、Mastercard などの如き種類の銀行カードであると仮定すると、主鍵生成規則により指定される支払い主体要素は典型的に、カード番号、口座名義、および、有効期限を備えて成る。主鍵生成規則に対応する支払い主体の種類が預金通帳であると仮定すると、主鍵生成規則により指定される支払い主体要素は典型的に、預金通帳口座番号、口座名義、および、取引銀行を備えて成る。

本実施形態において、前記サーバは、記憶された支払い主体の全ての支払い主体要素の中から、主鍵生成規則により指定された支払い主体要素を獲得し得る。説明を容易とするため、主鍵生成規則により指定されて獲得された支払い主体要素は、主鍵生成要素と称され得る。

ステップ 202：主鍵生成規則により指定された順序に従い、各主鍵生成要素を整列処理する段階。

本実施形態において、前記主鍵生成規則は更に、支払い主鍵を生成するための各主鍵生成要素の順序、すなわち、支払い主鍵が生成されるときの各主鍵生成要素の順序を備えて成り得る。上述のステップ 201 に基づき、各主鍵生成要素が獲得された後、該主鍵生成要素は、前記順序に従って整列処理され得る。主鍵生成要素が、預金通帳口座番号（1234）、口座名義（張三）、および、取引銀行（招商銀行北京大運村支店）を備えて成ると共に、主鍵生成規則により指定された順序が、口座名義、預金通帳口座番号および取引銀行であると仮定すると、主鍵生成要素は、張三、1234、および、招商銀行北京大運村支店として整列処理され得る。

ステップ 203：事前設定アルゴリズムに従い、整列処理された主鍵生成要素の暗号文を、支払い主体に対して生成される支払い主鍵として算出する段階。

上述のステップ 202 に基づき、各主鍵生成要素が整列処理された後、整列処理された主鍵生成要素の暗号文が、事前設定アルゴリズムに従い算出され得る。前記暗号文は、支払い主体に対して生成された支払い主鍵である。此処で、前記事前設定アルゴリズムは開発者により設定され得ると共に、前記事前設定アルゴリズムは、異なる主鍵生成規則により使用される暗号文生成アルゴリズムが異なり得る如く、主鍵生成規則に含まれ得る。開発者はまた、主鍵生成規則の各々においてアルゴリズムを設定する必要がない様に、全ての主鍵生成規則に対して同一のアルゴリズムを設定し、且つ、そのアルゴリズムを事前設定位置に記憶し得る。前記事前設定アルゴリズムは、MD5（メッセージ・ダイジェスト・アルゴリズム５）、HASH アルゴリズムなどであり得、本出願においては限定されない。

故に、本出願に係る主鍵生成規則は、以下の式により表され得る：支払い主鍵＝事前設定アルゴリズム（主鍵生成要素１、主鍵生成要素２、…、主鍵生成要素Ｎ）、式中、Ｎは１以上の自然数である。

上記の主鍵生成式に基づき、たとえば、新たな主鍵生成要素の付加などの、支払い主体の拡張時に、新たに付加された主鍵生成要素は、最後に配置されることで、前記主鍵生成要素を付加するためのコード開発の作業負担が低減され得る。たとえば、たとえば上述のステップ 103 において預金通帳形式の支払い主体に対して銀行による口座開設日を付加するものとすると、預金通帳形式の支払い主体に対応する従前の主鍵生成規則は、支払い主鍵＝事前設定アルゴリズム（口座名義、預金通帳口座番号、取引銀行）であり、且つ、更新された主鍵生成規則は、支払い主鍵＝事前設定アルゴリズム（口座名義、預金通帳口座番号、取引銀行、口座開設日）である。

本実施形態において、上記の主鍵生成式を基準とすると、前記サーバは、上記式により指定された主鍵生成要素の順序に従って各主鍵生成要素を順次的に獲得することで、上述のステップ 202 における整列処理操作を省略することも可能であるが、これは本出願においては限定されない。

上記説明からは、支払い主鍵が生成されるときの主鍵生成要素の整列処理情報は、本出願に依れば主鍵生成規則により指定されることが理解され得る。たとえば、新たな主鍵生成要素の付加などの、支払い主体の拡張時に、新たに付加された主鍵生成要素は、最後に載置されることで、主鍵生成要素を付加するためのコード開発の作業負担を低減することにより開発コストを節約し得る。

本出願の別の例において、本出願に係る電子的支払いの安全性を達成する方法は、支払いリスクを認識かつ決定するリスク管理プラットフォームの効率を高め得る。図３を参照すると、図１に示された実施形態に基づき、前記リスク管理プラットフォームと前記サーバとの間の相互作用プロセスは以下の各ステップを備えて成り得る：

ステップ 301：リスク管理プラットフォームにより送信された目標支払い主鍵を担持する主鍵照会要求を受信すると同時に、目標支払い主鍵に対応する目標支払い主体を検索し、且つ、前記目標支払い主体の全ての目標支払い主体要素をリスク管理プラットフォームに対して返信する段階。

本実施形態において、前記リスク管理プラットフォームとは、電子的支払いプロセスの間においてリスク評価のために使用されるサーバまたはサーバ群を指している。電子的支払いの支払い主鍵を受信すると同時に、前記リスク管理プラットフォームは、リスク管理の目的で、前記支払い主鍵に対応する支払い主体に関する照会を要求するために、本出願において各支払い主体を記憶するサーバに対し、前記支払い主鍵を送信する。説明を容易とするため、前記リスク管理プラットフォームにより前記サーバに対して送信された支払い主鍵は、目標支払い主鍵と称される。

本実施形態において、前記リスク管理プラットフォームにより送信された主鍵照会要求を受信すると同時に、前記サーバは、前記目標支払い主鍵に対応する目標支払い主体を検索し、且つ、支払い主鍵を生成する各主鍵生成要素のみの代わりに、検索を通して見出された目標支払い主体の全ての目標支払い主体要素を、リスク管理プラットフォームに対して返信し得る。

ステップ 302：リスク管理プラットフォームにより送信されたリスク管理要素を担持する要素照会要求を受信すると同時に、各リスク管理要素を含む支払い主体のリストを検索し、且つ、該支払い主体のリストをリスク管理プラットフォームに対して返信する段階であって、各リスク管理要素は、全ての支払い主体要素の部分集合であるという段階。

上述のステップ 301 に基づき、前記サーバから返信された各目標支払い主体要素を受信した後、前記リスク管理プラットフォームは、事前設定方針に従い、全ての目標支払い主体要素から、リスク管理要素として、ひとつ以上の目標支払い主体要素を選択し得る。その後、リスク管理プラットフォームは要素照会要求をサーバに対して送信し、且つ、該要素照会要求は各リスク管理要素を担持している。要素照会要求を受信すると同時に、前記サーバは、各リスク管理要素を含む全ての支払い主体を検索し、その後、各支払い主体のリストを前記リスク管理プラットフォームに対して返信し、その場合、支払い主体のリストは、全ての支払い主体の全ての支払い主体要素を含んでいる。前記リスク管理プラットフォームは、前記支払い主体のリストに基づき、この電子的支払いのリスクを、更に包括的に且つ更に正確に評価し得る。

リスク評価のプロセスは、具体例を参照して以下に記述される。

図４を参照すると、比較的に単純な電子的支払いの状況展開として、ユーザ端末は、スマートフォン、タブレット・コンピュータ、および、PC の如きスマート端末デバイスであり得ると共に、該ユーザ端末には、電子的支払い機能を有するクライアント・ソフトウェアがインストールされている。支払いプラットフォーム、リスク管理プラットフォーム、カード・センターは全て、電子的支払いサービス・プロバイダにより展開されたサーバまたはサーバ群である。此処で、前記支払いプラットフォームは、クライアントから送信された支払い要求を受信すべく、且つ、支払い要求に従い電子的支払い命令を生成すべく使用される。前記カード・センターは、各ユーザによりバンドルされた支払い主体を記憶すべく使用される。前記リスク管理プラットフォームは、各ユーザにより開始された電子的支払い要求に関するリスク評価を実施すべく使用される。

再び図４を参照すると、電子的支払いプロセスにおけるリスク管理プロセスは以下の各段階を備えて成り得る：

(1) ユーザ端末は、支払い要求を支払いプラットフォームに対して送信する。

たとえば、クライアント・ソフトウェアがアリペイ・クライアントであるとすると、ユーザは、アリペイ・クライアントにおいて支払い要求を開始し、クライアントは支払い要求の幾つかの支払い情報を支払いプラットフォームに対して送信し、且つ、前記支払い情報は主として２つの形式を有する：支払い主体要素、および、取引情報。支払いのためにクレディット・カードを使用することを選択するユーザによる例として、支払い主体要素は典型的に、クレディット・カード番号、口座名義などを備えて成り、且つ、取引情報は典型的には、支払い金額、照合コードなどを備えて成る。

(2) 前記支払いプラットフォームは主鍵生成規則をカード・センターに対して送信し、且つ、主鍵生成規則はクライアントにより送信された各支払い主体要素を担持する。

このステップにおいて、前記支払いプラットフォームは、支払い要求中に担持された各支払い主体要素を、主鍵生成規則を介してカード・センターに対して送信することで、各支払い主体要素に対応する支払い主体のための次続的な相互作用に対して使用される支払い主鍵を生成することをカード・センターに対して要求する。

(3) カード・センターは、支払い主体の支払い主鍵を、支払いプラットフォームに対して返信する。

このステップにおいて、支払いプラットフォームにより送信された各支払い主体要素を受信した後、カード・センターは、記憶された全ての支払い主体において前記各支払い主体要素に適合する支払い主体を検索し、その後、該支払い主体の支払い主鍵を支払いプラットフォームに対して返信する。此処で、カード・センターが支払い主鍵を生成するプロセスに関しては、図１または図２に示された実施形態が参照され得、本明細書においては反復されない。

(4) 前記支払いプラットフォームは、リスク管理要求を前記リスク管理プラットフォームに対して送信する。

カード・センターにより返信された支払い主鍵を受信すると同時に、支払いプラットフォームは、ユーザにより開始された電子的支払いに対する前記支払い主鍵に従って電子的支払い命令を生成し得ると共に、その後、電子的支払い命令をリスク管理要求に含めてリスク管理プラットフォームに対して送信する。

(5) リスク管理プラットフォームは、主鍵照会要求をカード・センターに対して送信する。

電子的支払い命令に対するリスク管理要求を受信すると同時に、リスク管理プラットフォームは、電子的支払い命令から解析により支払い主鍵を獲得し得ると共に、その後、前記支払い主鍵を、該支払い主鍵に対応する支払い主体に関する照会として、カード・センターに対して送信する。

(6) カード・センターは、前記支払い主鍵に対応する支払い主体を、リスク管理プラットフォームに対して返信する。

リスク管理センターにより送信された主鍵照会要求を受信すると同時に、カード・センターは、支払い主鍵に対応する支払い主体を検索し、その後、見出された支払い主体の全ての支払い主体要素をリスク管理センターに対して返信する。

(7) リスク管理プラットフォームは、リスク管理要素照会要求をカード・センターに対して送信する。

カード・センターにより返信された支払い主体の全ての支払い主体要素を受信すると同時に、リスク管理プラットフォームは、事前設定方針に従い、各支払い主体要素から、リスク管理要素としてひとつ以上の支払い主体要素を選択し、その後、リスク管理要素照会要求をカード・センターに対して送信し、カード・センター内に記憶されて前記リスク管理要素を備えて成る全ての支払い主体を照会し得る。

たとえば、先のステップにおいてカード・センターにより返信された支払い主体に対応する各支払い主体要素は、クレディット・カード番号、口座名義、有効期限、取引銀行、ユーザ ID 番号、および、暗証番号を備えて成る。開発者により設定された方針により、ユーザ ID 番号がリスク管理要素として選択されてから、該ユーザ ID 番号は、リスク管理要素照会要求内に担持されてカード・センターに対して再び送信される。

(8) カード・センターは、前記リスク管理要素を備えて成る全ての支払い主体のリストを、リスク管理プラットフォームに対して返信する。

ユーザ ID 番号を担持すると共に前記リスク管理プラットフォームにより送信されたリスク管理要素照会要求を受信すると同時に、カード・センターは、各支払い主体要素内にユーザ ID 番号を備えて成る全ての支払い主体を検索してから、全ての支払い主体のリストをリスク管理プラットフォームに対して返信し得る。支払い主体のリストは、各支払い主体の夫々の支払い主体要素を含む。

先のステップの例において、カード・センターは、前記支払い主体要素（上記のユーザ ID 番号）を備えて成る全ての支払い主体を検索する。もしカード・センターが、前記 ID 番号であるユーザ ID 番号を有する２つの銀行カードを見出したなら、カード・センターは、両方の銀行カードの各支払い主体要素を、リスク管理プラットフォームに対して返信し得る。

(9) リスク管理プラットフォームは、支払い主体の前記リストに従い、リスク評価を実施すると共に、リスク評価の結果を支払いプラットフォームに対して返信する。

支払い主体の前記リストを受信すると同時に、リスク管理プラットフォームは、支払い主体の該リスト中における全ての支払い主体の履歴的な業務パラメータに従い、電子的支払いに関するリスク評価を実施すると共に、評価結果を支払いプラットフォームに対して返信し得る。評価結果が安全であるとき、支払いプラットフォームは、継続して電子的支払いプロセスを完了し得る。評価結果が高リスクであるとき、支払いプラットフォームは、リスク・プロンプトを前記クライアントに対して返信し得る。

カード・センターが、ユーザ ID 番号に対応する２つの銀行カードを見出すなら、該２つの銀行カードの情報（該２つの銀行カードの支払い主体要素）を受信すると同時に、リスク管理プラットフォームは、２つの銀行カードの履歴的な取引データに従い、電子的支払いに関するリスク評価を実施し得る。リスク管理プラットフォームは、前記電子的支払いを開始したユーザが、電子取引において、他の銀行のカードを用いて、不適合操作などの如きリスクのある行為を行ったか否かを見出すと共に、電子的支払いに関して更に総括的で正確なリスク評価を実施し得る。

上記説明からは、本出願に係る支払い主鍵生成解決策において、リスク管理プラットフォームは、２回の照会により、リスク評価において使用され得る支払い主体のリストを見出してから、電子的支払いに対する更に総括的で正確なリスク評価を提供し、且つ、電子的支払いのセキュリティを高め得ることが理解され得る。

支払い主体の拡張を促進する方法の上記実施形態に対応して、本出願は更に、支払い主体の拡張を促進するデバイスの実施形態を提供する。

本出願の支払い主体の拡張を促進するデバイスの実施形態は、サーバ上で適用され得る。デバイス実施形態は、ソフトウェア、ハードウェア、または、ソフトウェアとハードウェアとの組み合わせにより実施され得る。ソフトウェアで実現する例において、論理的な意味でのデバイスは、該デバイスが配設されるサーバにおけるプロセッサであって、不揮発性メモリから対応コンピュータ・プログラム命令を実行のためにメモリ内へと読み込むというプロセッサにより形成される。ハードウェアの観点から、図５は、本出願に係る支払い主体の拡張を促進するデバイスが配設されるサーバのハードウェア構造図である。図５に示されたプロセッサ、メモリ、ネットワーク・インタフェース、および、不揮発性メモリに加え、該実施形態においてデバイスが配設されるサーバは、典型的に、該サーバの実際の機能に従う他のハードウェアを更に備えて成るが、此処では反復されない。

図６は、本出願に係る、支払い主体の拡張を促進する代表的なデバイスの構造的ブロック図である。

図６を参照すると、支払い主体の拡張を促進するデバイス 500 は、図５に示されたサーバにおいて適用され得ると共に、種類決定ユニット 501、規則検索ユニット 502、主鍵生成ユニット 503、第１返信ユニット 504、第２返信ユニット 505、規則更新ユニット 506、および、規則記憶ユニット 507 を備えて成り得る。此処で、主鍵生成ユニット 503 は更に、要素獲得下位ユニット 5031、要素整列処理下位ユニット 5032、および、主鍵生成下位ユニット 5033 を備えて成り得る。

此処で、種類決定ユニット 501 は、支払い主体の種類を決定し、
規則検索ユニット 502 は、前記種類に対応する主鍵生成規則を検索し、且つ、
主鍵生成ユニット 503 は、前記主鍵生成規則に従い、支払い主体に対する支払い主鍵を生成し、且つ、支払い主体とそれの支払い主鍵との間の対応関係を記憶し、
前記主鍵生成規則は、支払い主鍵を生成するための支払い主体要素を指定し、且つ、複数の異なる種類の支払い主体に対応する夫々の主鍵生成規則は、夫々の支払い主鍵を生成する異なる支払い主体要素を指定する。

要素獲得下位ユニット 5031 は、前記主鍵生成規則により指定された支払い主体要素を、主鍵生成要素として獲得し、
要素整列処理下位ユニット 5032 は、前記主鍵生成規則により指定された順序に従って各主鍵生成要素を整列処理し、且つ、
主鍵生成下位ユニット 5033 は、事前設定アルゴリズムに従い、整列処理された主鍵生成要素の暗号文を、前記支払い主体に対して生成された支払い主鍵として算出する。

第１返信ユニット 504 は、リスク管理プラットフォームにより送信された目標支払い主鍵を担持する主鍵照会要求を受信すると同時に、目標支払い主鍵に対応する目標支払い主体を検索し、且つ、目標支払い主体の全ての目標支払い主体要素をリスク管理プラットフォームに対して返信し、且つ、
第２返信ユニット 505 は、リスク管理プラットフォームにより送信されたリスク管理要素を担持する要素照会要求を受信すると同時に、各リスク管理要素を含む支払い主体のリストを検索し、且つ、該支払い主体のリストをリスク管理プラットフォームに対して返信し、その場合に各リスク管理要素は、全ての目標支払い主体要素の部分集合である。

選択的に、種類決定ユニット 501 は、支払い主体に対する登録要求を受信すると同時に、支払い主体の種類を決定する。

主鍵生成規則が更新されたとき、規則更新ユニット 506 は、更新された主鍵生成規則に従い、支払い主体に対する別の支払い主鍵を再生成し、且つ、
規則記憶ユニット 507 は、支払い主体とそれの本来的な支払い主鍵との間の対応関係の記憶に基づき、支払い主体と、それの再生成された支払い主鍵との間の対応関係を記憶する。

前記デバイスの各ユニットの機能および役割の実現様式に関する詳細な情報に対しては、本明細書においては反復されない前記方法における対応ステップの実現様式が参照され得る。

デバイス実施形態は実質的に方法実施形態に対応することから、方法実施形態の説明における関連部分が参照され得る。上述されたデバイス実施形態は例示的であるにすぎず、別体的な部材として記述された各ユニットは、物理的に別体的とされてもされなくても良い。各ユニットとして示された部材は、物理的なユニットとされてもされなくても良く、すなわち、それらは、同一箇所に載置されるか、または、複数のネットワーク・ユニットに対して分散され得る。その幾つかまたは全てのモジュールは、必要に応じて、本出願の解決策の目的を達成すべく選択され得る。本出願は、創造の労力なしで当業者により理解かつ実施され得る。

上記においては本出願の好適実施形態のみが記述されると共に、各実施形態は本出願を限定するために使用されるのではない。本出願の精神および原理の範囲内において為される一切の改変、等価的な置換、および、改良は、本出願の有効範囲内に収まるものとする。

Claims (10)

1. サーバ上で適用可能である、支払い主体の拡張を促進する方法であって、
   支払い主体の種類を決定する段階と、
   前記種類に対応する主鍵生成規則を検索する段階と、
   前記主鍵生成規則に従い、前記支払い主体に対する支払い主鍵を生成し、且つ、前記支払い主体とそれの支払い主鍵との間の対応関係を記憶する段階であって、前記主鍵生成規則は、前記支払い主鍵を生成するための前記支払い主体の支払い主体要素を指定し、且つ、複数の異なる種類の支払い主体に対応する夫々の主鍵生成規則は、夫々の支払い主鍵を生成する異なる支払い主体要素を指定する、段階と、
   リスク管理プラットフォームからの目標支払い主鍵を担持する主鍵照会要求を受信すると同時に、前記目標支払い主鍵に対応する目標支払い主体を検索し、且つ、前記目標支払い主体の複数の目標支払い主体要素を前記リスク管理プラットフォームに対して返信する段階と、
   を備えて成る方法。
2. 前記主鍵生成規則に従い、前記支払い主体に対する支払い主鍵を生成する前記段階は、
   前記主鍵生成規則により指定された支払い主体要素を、主鍵生成要素として獲得する段階と、
   前記主鍵生成規則により指定された順序に従い、各主鍵生成要素を整列処理する段階と、
   事前設定アルゴリズムに従い、前記整列処理された主鍵生成要素の暗号文を、前記支払い主体に対して生成された前記支払い主鍵として算出する段階と、
   を備えて成る、請求項１に記載の方法。
3. 前記リスク管理プラットフォームからのひとつ以上のリスク管理要素を担持する要素照会要求を受信すると同時に、前記ひとつ以上のリスク管理要素を含む支払い主体のリストを検索し、且つ、該支払い主体のリストを前記リスク管理プラットフォームに対して返信し、その場合に前記ひとつ以上のリスク管理要素は、前記複数の目標支払い主体要素の部分集合である段階、
   を更に備えて成る、請求項１に記載の方法。
4. 支払い主体の種類を決定する前記段階は、
   支払い主体に対する登録要求を受信すると同時に、前記支払い主体の種類を決定する段階、
   を備えて成る、請求項１に記載の方法。
5. 前記主鍵生成規則が更新されたとき、更新された主鍵生成規則に従い、前記支払い主体に対する別の支払い主鍵を再生成する段階と、
   前記支払い主体とそれの本来的な支払い主鍵との間の対応関係の記憶に基づき、前記支払い主体と、それの再生成された支払い主鍵と、の間の対応関係を記憶する段階と、
   を更に備えて成る、請求項１に記載の方法。
6. サーバ上で適用可能である、支払い主体の拡張を促進するデバイスであって、
   支払い主体の種類を決定すべく構成された種類決定ユニットと、
   前記種類に対応する主鍵生成規則を検索すべく構成された規則検索ユニットと、
   前記主鍵生成規則に従い、前記支払い主体に対する支払い主鍵を生成し、且つ、前記支払い主体とそれの支払い主鍵との間の対応関係を記憶すべく構成された主鍵生成ユニットであって、前記主鍵生成規則は、前記支払い主鍵を生成するための前記支払い主体の支払い主体要素を指定し、且つ、複数の異なる種類の支払い主体に対応する夫々の主鍵生成規則は、夫々の支払い主鍵を生成する異なる支払い主体要素を指定する、主鍵生成ユニットと、
   リスク管理プラットフォームからの目標支払い主鍵を担持する主鍵照会要求を受信すると同時に、前記目標支払い主鍵に対応する目標支払い主体を検索し、且つ、前記目標支払い主体の複数の目標支払い主体要素を前記リスク管理プラットフォームに対して返信すべく構成された第１返信ユニットと、
   を備えて成るデバイス。
7. 前記主鍵生成ユニットは、
   前記主鍵生成規則により指定された支払い主体要素を、主鍵生成要素として獲得すべく構成された要素獲得下位ユニットと、
   前記主鍵生成規則により指定された順序に従い、各主鍵生成要素を整列処理すべく構成された要素整列処理下位ユニットと、
   事前設定アルゴリズムに従い、前記整列処理された主鍵生成要素の暗号文を、前記支払い主体に対して生成された前記支払い主鍵として算出すべく構成された主鍵生成下位ユニットと、
   を備えて成る、請求項６に記載のデバイス。
8. 前記リスク管理プラットフォームからのひとつ以上のリスク管理要素を担持する要素照会要求を受信すると同時に、前記ひとつ以上のリスク管理要素を含む支払い主体のリストを検索し、且つ、該支払い主体のリストを前記リスク管理プラットフォームに対して返信すべく構成された第２返信ユニットであって、その場合に前記ひとつ以上のリスク管理要素は、前記複数の目標支払い主体要素の部分集合であるという第２返信ユニット、
   を更に備えて成る、請求項６に記載のデバイス。
9. 前記種類決定ユニットは、支払い主体に対する登録要求を受信すると同時に、前記支払い主体の種類を決定すべく構成される、請求項６に記載のデバイス。
10. 前記主鍵生成規則が更新されたとき、更新された主鍵生成規則に従い、前記支払い主体に対する別の支払い主鍵を再生成すべく構成された規則更新ユニットと、
    前記支払い主体とそれの本来的な支払い主鍵との間の対応関係の記憶に基づき、前記支払い主体と、それの再生成された支払い主鍵と、の間の対応関係を記憶すべく構成された規則記憶ユニットと、
    を更に備えて成る、請求項６に記載のデバイス。