特許 6095106 支払い用の銀行カードの適応的選択のためのシステムと方法

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

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

(11)【特許番号】6095106

(24)【登録日】2017年2月24日

(45)【発行日】2017年4月12日

(54)【発明の名称】支払い用の銀行カードの適応的選択のためのシステムと方法

(51)【国際特許分類】

   G06Q 20/24 20120101AFI20170403BHJP

   G06Q 40/02 20120101ALI20170403BHJP

【ＦＩ】

   G06Q20/24

   G06Q40/02

【請求項の数】14

【全頁数】15

(21)【出願番号】特願2012-517521(P2012-517521)

(86)(22)【出願日】2010年4月28日

(65)【公表番号】特表2012-532368(P2012-532368A)

(43)【公表日】2012年12月13日

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

(87)【国際公開番号】WO2011002547

(87)【国際公開日】20110106

【審査請求日】2013年4月10日

【審判番号】不服2015-6203(P2015-6203/J1)

【審判請求日】2015年4月2日

(31)【優先権主張番号】200910159419.0

(32)【優先日】2009年7月3日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】510330264

【氏名又は名称】アリババ・グループ・ホールディング・リミテッド

【氏名又は名称原語表記】ＡＬＩＢＡＢＡ ＧＲＯＵＰ ＨＯＬＤＩＮＧ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】リウ チョンシェン

【合議体】

【審判長】 金子 幸一

【審判官】 手島 聖治

【審判官】 石川 正二

(56)【参考文献】

【文献】 特開２００２−１６３５８５（ＪＰ，Ａ）

【文献】 特開２００３−２９６６４１（ＪＰ，Ａ）

【文献】 特開２００８−１４６２４０（ＪＰ，Ａ）

【文献】 特開平１１−２５９５８８（ＪＰ，Ａ）

【文献】 特開２０００−１６３４９３（ＪＰ，Ａ）

【文献】 特開２００９−９３３８０（ＪＰ，Ａ）

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

G06Q10/00-50/34

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

【請求項1】

支払い用の銀行カードの適応的選択用の支払いプラットフォームシステムで、ユーザと受取人との間の支払い操作が支払いプラットフォームシステムを通じて行われ、その支払いプラットフォームシステムが、
ユーザの口座情報、支払いに使用する複数の銀行カードの情報、カード選択規則の情報、および支払い記録の情報を含む情報を格納するデータベースと、
データベースと通信できるよう接続され、カード選択規則の情報に基づいて複数の銀行カードから現在の支払い用の銀行カードを選択することができる規則エンジンユニットであって、前記規則エンジンユニットは規則エンジンサーバに組み込まれており、前記規則エンジンユニットが起動されるという条件で、前記規則エンジンサーバのメモリに格納されているカード選択規則は更新される、規則エンジンユニットと、
データベースと規則エンジンユニットに通信できるよう接続され、支払い要求をユーザのユーザクライアントから受信し、現在の支払い用の銀行カードを規則エンジンユニットから取得し、選択された銀行カードを使用して受取人に支払額を転送する支払い処理ユニットであって、前記支払い操作は、カード選択に関してユーザクライアントと通信することなく続けられ、前記支払い操作は、前記選択された銀行カードの情報が前記ユーザクライアントへ送信されることなく完了する、支払い処理ユニットと、
を備えた支払いプラットフォームシステム。

【請求項2】

支払い処理ユニットが支払いサーバに組み込まれている、請求項１に記載の支払いプラットフォームシステム。

【請求項3】

規則エンジンサーバは、
カード選択規則の情報を、規則エンジンソフトウェアが起動するたびに規則エンジンサーバのメモリにインポートするメモリ内規則インポートユニット
をさらに備えた、請求項２に記載の支払いプラットフォームシステム。

【請求項4】

規則エンジンサーバは、
新しいまたは更新されたカード選択規則をデータベースから取得し、カード選択規則に基づいて、現在メモリに格納されているカード選択規則を更新する規則更新ユニット
をさらに備えた、請求項３に記載の支払いプラットフォームシステム。

【請求項5】

データベースは、
ユーザの情報、対応する支払い口座の情報、支払いに使用する可能性のある複数の銀行カードが、支払い口座とペアになって格納されるユーザ情報格納ユニットと、
ユーザにより設定された複数の銀行カードのカード選択規則と、各種銀行カードの支払い限度を含むシステムのカード選択規則を格納する規則格納ユニットと、
支払い要求ごとの処理に関連付けられたそれぞれの結果の情報を格納する支払い記録格納ユニットと
を備えた、請求項１に記載の支払いプラットフォームシステム。

【請求項6】

ユーザに対応する新しいまたは修正したユーザのカード規則を受信し、そのカード選択規則をデータベースに格納するカード選択規則通信ユニット
をさらに備えた、請求項５に記載の支払いプラットフォームシステム。

【請求項7】

規則格納ユニットが表形式でデータベースに格納される、請求項６に記載の支払いプラットフォームシステム。

【請求項8】

支払い用の銀行カードの適応的選択用の支払いプラットフォームシステムによって実行される方法であって、ユーザと受取人との間の支払い操作が支払いプラットフォームを通じて行われ、前記方法は、
ユーザのユーザクライアントからの支払い要求を支払いサーバによって受信したことに応答して、規則エンジンサーバが、カード選択規則の情報に基づいて複数の銀行カードから現在の支払い用の銀行カードを選択することであって、規則エンジンソフトウェアが起動されるという条件で、前記規則エンジンサーバのメモリに格納されているカード選択規則は前記規則エンジンサーバによって更新される、ことと、
支払いサーバが、前記規則エンジンサーバによって選択された銀行カードを使用して、支払い額を受取人に移すことであって、前記支払い操作は、カード選択に関してユーザクライアントと通信することなく続けられ、前記支払い操作は、前記選択された銀行カードの情報が前記ユーザクライアントへ送信されることなく完了する、ことと
を備えた方法。

【請求項9】

前記カード選択規則は、
設定または修正済みのユーザ定義のカード選択規則を受信することと、
ユーザにより定義されたカード選択規則と、銀行カードの支払い限度を含むシステムのカード選択規則を統合して最終的なカード選択規則を得ることと
によって設定される、請求項８に記載の方法。

【請求項10】

結果として得られるカード選択規則をデータベースに格納すること
をさらに備える、請求項９に記載の方法。

【請求項11】

新しいまたは更新したカード選択規則を取得することと、
現在データベースに格納されているカード選択規則を更新することと
をさらに備える、請求項１０に記載の方法。

【請求項12】

規則エンジンサーバでカード選択処理のための操作を、支払いサーバで支払い要求処理のための操作を設定すること
をさらに備える、請求項８に記載の方法。

【請求項13】

複数の銀行カードから現在の支払い用の銀行カードを選択することは、
支払いサーバで、その支払い要求を受信すると要求された支払い額の情報と受取人のクライアントの情報を取得することと、
ユーザが複数の銀行カードを持っていることを支払いサーバが判別した際に、カード選択要求を規則エンジンサーバに送信することと、
規則エンジンサーバが、複数の銀行カードそれぞれがカード選択規則を満たしているかどうかを判別することと、
現在の支払い用の銀行カードにするためカード選択規則の要件を満たす銀行カードを選択することと
をさらに備える、請求項１２に記載の方法。

【請求項14】

選択された銀行カードを使用して支払い額を受取人に移すことは、
支払い記録に支払い処理状況を格納することと、
関係する銀行のサブシステムとの口座残高調整および決済の操作を完了することと
をさらに備える、請求項１３に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、中国特許出願番号２００９１０１５９４１９．０、２００９年７月３日に出願された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ａｄａｐｔｉｖｅ Ｓｅｌｅｃｔｉｏｎ Of Ｂａｎｋ Ｃａｒｄ ｆｏｒ Ｐａｙｍｅｎｔ」から優先権を主張し、其の全体をここに含有されている。

【0002】

本開示はネットワーキング技術に関する。特には、支払い用の銀行カードの適応的選択のシステムとその方法に関する。

【背景技術】

【0003】

過去数年間で、電子商取引は徐々に、インターネットでの経済開発の主な流れとなってきた。オンラインショッピングやオンライン支払いは、便利な生活様式となってきた。

【0004】

図１は、既存の技術下でのオンライン支払いの環境１００の概略図である。ユーザのユーザクライアント１１Ａは、支払いプラットフォーム１２を通じて受取人に支払いを行う。受取人は商人でも良い。受取人の、受取人クライアント１３は、ネットワーク経由で支払いプラットフォーム１２に接続しても良い。ユーザは、支払いプラットフォーム１２上に支払い口座を持って、銀行サブシステム１４上に銀行口座を開設しても良い。リスクを減らすため、ユーザは通常、支払い時にＷｅｂページ上で直接銀行カードの番号とパスワードを入力しない。カード番号とパスワードが漏えいした場合、ユーザによる経済的損失が簡単に起こり得る。

【0005】

このように、支払いプラットフォーム１２は、支払い口座と銀行口座を相関させる。ユーザが相関付けられている銀行カードを選択するだけで、支払いプラットフォーム１２が決済や銀行サブシステム１４との口座残高調整などのデータ操作を完了する。セキュリティの改善のため、支払いプラットフォーム１２はさらに、ユーザが銀行カードの仮名を設定できるようにする。支払い要求が支払いプラットフォーム１２に送信されると、ユーザクライアント１１はさらに、対象の銀行カードの仮名と支払い情報（受取人や支払額情報を含む）を送信する。支払いプラットフォーム１２は、支払い要求を処理し、支払額を受取人の口座に転送する。口座は、支払いプラットフォーム１２の受取人の受取口座でも、銀行の受取人の銀行口座でも良い。

【0006】

支払いプラットフォーム１２は、少なくとも、支払いサーバ２１、口座残高調整サーバ２２およびデータベース２３を含む。データベース２３は、支払いプラットフォーム１２を使用するユーザの情報、関連付けられた口座の情報、支払い処理に関する情報、およびさまざまな銀行サブシステム１４との決済および口座残高調整に関する情報を格納する。支払いサーバ２１は、主に、支払い要求処理の操作を完了するために使用される。口座残高調整サーバ２２は、主に、決済、口座残高調整、および銀行サブシステム１４とのデータ交換などの操作を完了するために使用される。

【0007】

最近では、ユーザは、支払いプラットフォーム１２での支払いに使用する可能性がある複数の銀行カードの情報を設定することができる。ユーザクライアント１１Ａまたは１１Ｂが支払いプラットフォーム１２にインターネット経由で接続する場合で、支払いプラットフォーム１２に現在の支払い用の銀行カード情報を持たない支払い要求を送信する場合、支払いプラットフォーム１２は、現在の支払い用の銀行カード情報を、ユーザクライアント１１Ａまたは１１Ｂと通信することで取得する必要がある。銀行カード情報は機密情報である。したがって、この手法が支払いサーバ２１のリソースの処理に占有されるだけでなく、この種の機密情報をインターネット経由で交換することに対するセキュリティも低い。さらに、ユーザには毎回使用する銀行カードの問い合わせが来るため、支払いの処理時間が長くなり、支払いサーバ２１とネットワークのリソースを占有する時間が長くなる。

【0008】

既存の技術では、支払いが電話またはＷＡＰ（ワイヤレスアプリケーションプロトコル）により行われる場合で、支払いプラットフォーム１２に送信される、関連付けられている支払い要求が現在の支払いで使用する銀行カードのいかなる情報を持っていない場合、支払いプラットフォーム１２はリソースの制約により、ユーザが銀行カードを選択できるインタラクティブなＷｅｂページを提供することができない場合がある。一般的に、支払いプラットフォーム１２は次に、支払いを完了させるため、ユーザが最も良く使用する銀行カードを選択する。支払いプラットフォーム１２が、ユーザが銀行カードを選択できるインタラクティブなＷｅｂページを提供できる場合、支払いプラットフォーム１２は、ＷＡＰネットワークを通じて携帯電話ユーザにインタラクティブなＷｅｂページを提供して、携帯電話ユーザとの通信を確立する。カード選択に関連するそれぞれのやり取りは、Ｗｅｂサーバ、ＷＡＰプロキシサーバ、無線通信ネットワークとの通信が必要である。したがって、カード選択にかかる時間は長引き、関連する支払いに対する処理が長引くことになる。さらに、エラーが関連するデバイスのいずれかで起こった場合、カード選択処理全体が終了し、支払い実行の成功率が下がる。

【0009】

支払いプラットフォームを通じて支払いを行う、既存の支払い処理は、通常、支払いプラットフォームがユーザに、支払いを完了するために特定の銀行カードを選択するためのインタラクティブなＷｅｂページを提供する必要がある。このような方法は、ネットワークリソースのみを占有するが、最も重要なことは、支払い処理の速度が低下し、支払いサーバ２１が関連処理操作を完了させるためのリソースと時間を消費することでもある。さらに、特定の用途のシナリオでは、支払いプラットフォーム１２は、特定の銀行カードを選択するためにユーザにインタラクティブなＷｅｂページを提供できなくても構わない。さらに、特定の銀行カードの選択での支払いプラットフォーム１２の自己相関にセキュリティの問題が存在する場合がある。

【発明の概要】

【発明が解決しようとする課題】

【0010】

本開示の目的は、既存のカード選択処理に存在する低いセキュリティ、長引く支払い処理時間およびリソース占有の技術的問題を解決するための支払い用銀行カードの適応的選択を行うためのシステムを提供することである。

【0011】

本開示の別の目的は、既存のカード選択処理に存在する低いセキュリティ、長引く支払い処理時間およびリソース占有の技術的問題を解決するための支払い用銀行カードの適応的選択を行うための方法を提供することである。

【課題を解決するための手段】

【0012】

一態様において、支払用の銀行カードを適応的に選択するシステムは、支払い操作をユーザと受取人との間で、支払いプラットフォームを通じて実行する。支払いプラットフォームには、
ユーザの口座情報、支払いに使用する複数の銀行カード、カード選択規則、および支払い記録を含む情報を格納するデータベースと、
データベースに通信できるよう接続され、現在の支払い用の銀行カードをカード選択規則に基づいて選択する規則エンジンユニットと、
データベースと規則エンジンユニットに通信できるよう接続され、支払い要求をユーザクライアントから受信し、現在の支払い用の銀行カードを規則エンジンユニットから取得し、その銀行カードを使用して受取人に支払額を移す支払い処理ユニット
とを備える。

【0013】

規則エンジンユニットと支払い処理ユニットは、規則エンジンサーバと支払いサーバにそれぞれ設置しても良い。

【0014】

支払用の銀行カードを適応的に選択し、支払い操作をユーザと受取人との間で、支払いプラットフォームを通じて実行する方法には、
（１）複数の銀行カードからの支払いカード選択に関連するカード選択規則を設定し、
（２）ユーザのユーザクライアントからの支払い要求を受信して、現在の支払い用の銀行カードを複数の銀行カードから、カード選択規則とユーザの支払い記録を基に選択し、
（３）その銀行カードを使用して、支払い額を受取人に転送すること
とを含む。

【0015】

既存の技術と比べ、開示したシステムおよび方法には次の利点がある。

【0016】

第１に、開示するシステムおよび方法は、あらかじめカード選択規則を確立しておくことができる。したがって、後に続く支払い操作は、カード選択に関連する通信がユーザクライアントとの間で確立され、ユーザがカードを選択するまで待つ必要がなく続けられる。支払い速度が改善されるだけでなく、ネットワークおよび支払いプラットフォームのリソースも占有されない。特に、ユーザが携帯電話を使用して、ＷＡＰプロトコルを介して支払い要求を支払いプラットフォームに開始した場合、さらなるカード選択の操作は必要としない。したがって、支払い処理全体の効率が向上し、支払いの成功度が大幅に改善される。

【0017】

第２に、支払いを行いカードを選択する操作は、支払いサーバと規則エンジンサーバの設置により、個別に行われる。したがって、既存の支払いサーバへの大幅な修正は必要ない。カード選択操作を完了するための追加の規則エンジンサーバを導入するこの設計により既存の支払いサーバのセキュリティとシステムの結合が改良できる。

【0018】

最後に、規則エンジンソフトウェアが起動するたびに、カード選択規則があらかじめサーバのメモリにインポートされる。さらに、メモリに格納されたカード選択規則は定期的に更新される。したがって、カード選択速度は、同時に保証されるカード選択の正確性により改善される。

【図面の簡単な説明】

【0019】

【図1】既存の技術下でのオンライン支払いの環境１００の概略図である。

【図2】本開示に従った支払い用銀行カードの適応的選択のためのシステム２００を示す概略図である。

【図3】本開示に従った支払いプラットフォーム３００のコンポーネントを示す概略図である。

【図4】本開示に従った支払い用銀行カードの適応的選択のための方法４００を示すフローチャートである。

【図5】本開示に従った支払い用銀行カードの適応的選択のためのシステム５００を示す概略組織図である。

【図6】本開示に従った支払いプラットフォーム６００のコンポーネントを示す概略組織図である。

【図7】本開示に従った支払い用銀行カードの適応的選択のための方法７００を示すフローチャートである。

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

【0020】

本開示は、添付の図面を使用して詳細を説明する。

【0021】

第１の実施形態例
図２および図３は、本開示に従った支払い用銀行カードの適応的選択のためのシステム２００の第１の例を示す概略図である。システム２００はユーザクライアント４１、支払いプラットフォーム４２、受取人クライアント４３、およびさまざまな銀行サブシステム４４を含む。ユーザクライアント４１は、支払いプラットフォーム４２にインターネットを経由して接続するネットワーククライアント、既存の固定回線システムを経由して支払いプラットフォーム４２と通信する電話装置、あるいはＷＡＰプロトコルを使用して、ワイヤレス通信ネットワークおよびインターネットを経由して支払いプラットフォーム４２と通信を確立する携帯電話でも良い。受取人は、支払いプラットフォーム４２に口座を設置するか、支払いプラットフォーム４２に接続されている銀行サブシステムに受取人口座を設置する。本実施形態例では、受取人は支払いプラットフォーム４２に受取人口座を設置し、ユーザは支払いプラットフォーム４２に支払い口座を設置する。実際は、受取人が設置した受取人口座と、ユーザが設置した支払い口座は、支払いプラットフォーム４２により均一に管理されるユーザ口座とみなされる。具体的には、受取人およびユーザは、両方とも支払いプラットフォーム４２のユーザである。受取人口座とユーザの支払い口座とは、単に別の言葉で言い換えたにすぎない。本来、これらはユーザの口座として管理される。

【0022】

支払いプラットフォーム４２は、データベース５１、支払いサーバ５２、規則エンジンサーバ５３、および口座残高調整サーバ５４を含んでも良い。

【0023】

データベース５１はユーザの口座情報を格納する。データベース５１に、ユーザは、支払いに使用する可能性がある複数の銀行カードの情報、カード選択規則に関する情報、および支払い記録を含む情報を格納する。図３はデータベース５１の概略組織図を示し、これには、
ユーザおよび対応する支払い口座の情報に加えて支払いに使用する可能性のある複数の銀行カードが、支払い口座とペアになって格納される情報格納ユニット５１１と、
支払い要求ごとの処理に関連付けられたそれぞれの結果の情報を格納する支払い記録格納ユニット５１２と、
ユーザにより設定された複数の銀行カードのカード選択規則と、各種銀行カードの支払い限度を含むシステムのカード選択規則を格納する規則格納ユニット５１３
とを含む。

【0024】

一般的に、ユーザ情報格納ユニット５１１および支払い記録格納ユニット５１２は、論理的観点から個別の機能にすることもできるが、すべての情報を格納するための広範テーブルを使用して、物理的に１つの実施形態に実装しても良い。たとえば、広範テーブルは、支払い口座を、口座に対応するアクセスパスワード、支払いパスワード、ユーザ情報、複数の銀行カード情報および支払い情報などの関連フィールドを有するストレージの一単位として見なしても良い。複数の銀行カードの情報には、銀行カード番号、仮名、対応する銀行カードの銀行情報、対応する銀行カードの本日の取引額、および本月の対応する合計取引額などが含まれる。支払い情報は、対応するユーザの口座の本日の取引額や本月の合計取引額を含んでも良い。支払いサーバ５２は、この広範テーブルの内容を定期的に更新しても良い。

【0025】

一実施形態では、規則ストレージユニット５１３は、システムカード選択規則格納サブユニット、ユーザカード選択規則格納サブユニット、およびルール格納サブユニットを含んでいても良い。システムカード選択規則格納サブユニットは、各種銀行カードの支払い限度を含むシステムのカード選択規則を格納することができる。カード選択規則は各種銀行カードに関連する制限要件を参照し、主に各種銀行カードの支払い限度に対する制限要件を参照する。一実施形態では、システムカード選択規則格納サブユニットは、カード選択規則を格納するために表形式で実装しても良い。たとえば、各種銀行カードは、対応する銀行カードの使用に対する制限要件を格納するためのユニットであると見なしても良い。ユーザカード選択規則格納サブユニットは、ユーザが定義したカード選択規則を格納する。一実施形態では、カード選択規則は、銀行カードごとに個別に格納された選択規則でも良い。別の実施形態では、１つまたは複数のカード選択規則を、すべてのカードに対し設定することもできる。この規則格納サブユニットは、ユーザが定義したカード選択規則と、システムのカード選択規則とを統合した上でユーザのカード選択規則の最終的な結果を決定することができる。一実施形態では、ユーザ選択規則格納サブユニットは、任意で省いても良い。ユーザが定義したカード選択規則を受信すると、システムのカード選択規則格納サブユニットに直接アクセスし、最終的なユーザのカード選択規則が決定され、規則格納サブユニットに格納される。

【0026】

たとえば、支払いプラットフォーム４２が受信したユーザ定義規則は、（１）１回の取引額が８００ドル未満の取引、（２）１日の合計額の限度が２０００ドル、（３）月の合計額が２０００ドル未満、（４）各月の使用期間が、１５日目から３１日目までの間、であることを含む銀行クレジットカードの支払い規則でも良い。このシステムカード選択規則内に格納されているこの銀行クレジットカードのカード選択規則には、（１）１回の取引額が５００ドル未満の取引、（２）１日の合計額の限度が１５００ドル、（３）月の合計額が２０００ドル未満、（４）各月の使用期間が、１５日目から３１日目までの間、であることを含んでいても良い。具体的に、これらの４つの制限要件は、カード選択規則に格納され、たとえば表１の形式で格納することができる。

【0027】

【表1】

【0028】

前述のデータベース５１内で説明した各種格納ユニットは、主に、論理的観点から説明したものであるが、物理的観点から説明したものではない。データベース５１は、物理的に複数のデータベースでも、単一のデータベースでも良い。

【0029】

規則エンジンサーバ５３は、データベース５１と接続して、カード選択規則に基づいて複数の銀行カードから現在の支払い用の銀行カードを選択することができる。本実施形態では、規則エンジンソフトウェア（本明細書では規則エンジンユニット５３１と省略する）は、カード選択操作を完了する前にあらかじめ設定される。規則エンジンユニット５３１は、一実施形態ではオープンソースＤｒｏｏｌｓを使用して実装しても良く、あるいは別の実施形態では自己構築ＤＦＡを使用して実装しても良い。本実施形態は、規則エンジンユニット５３１の実装にどのプログラミング言語を使用するかに制限はない。規則エンジンユニット５３１は主に、どの銀行カードが、表１に格納されている各種銀行カードの制限要件を満たしているかを決定するために広範テーブルのレコードにアクセスするために使用される。規則エンジンユニット５３１は、銀行カードをユニットとして見なし、広範テーブルのレコードにアクセスすることで、どの銀行カードが表１の要件を満たしているかを判別する。満たしている場合、その銀行カードが、現在の支払い用として提示される。満たしていない場合、別の銀行カードが選択され、表１の制限を満たしているかどうかがチェックされる。この処理は、現在の支払いに対する要件を満たす銀行カードが見つかるか、すべての銀行カードが要件を満たさないことが分かるまで行われる。一実施形態では、規則エンジンユニット５３１は、表１の要件を満たす銀行カードをすべて選択してから、事前に決定した選択順に従って現在の支払い用の銀行カードを決定することができる。一般に、規則エンジンユニット５３１はソフトウェアを使用して実装しても良い。ただし、本開示では、実装にハードウェアを使用する可能性は除外しない。本開示の規則エンジンユニット５３１は主に、規則エンジンソフトウェアをインストールしたプロセッサとする。

【0030】

規則エンジンユニット５３１のほかに、規則エンジンサーバ５３はさらに、
カード選択規則の情報を、規則エンジンソフトウェアが起動するたびにサーバのメモリにインポートするメモリ内規則インポートユニット５３２と、
新しいまたは更新されたカード選択規則をデータベース５１から取得し、これらのカード選択規則に基づいて、現在メモリに格納されているカード選択規則を更新する規則更新ユニット５３３
とを含んでいても良い。

【0031】

一実施形態では、規則更新ユニット５３３は、定期的にデータベース５１をチェックして、新しいまたは更新されたカード選択規則を取得する。更新日時のフィールドを表１に設定するための相対的に共通の実装を設定しても良く、これは、銀行カードのカード選択規則が更新された日時を格納するために使用される。この更新日時のフィールドに基づいて、規則更新ユニット５３３は、新しいまたは更新されたカード選択規則を取得できる。

【0032】

規則エンジンユニット５３１、メモリ内規則インポートユニット５３２、および規則更新ユニット５３３は、主に論理的観点から分割される。ただし、本開示はこの種の分割に限定しない。実際の実装では、規則エンジンユニット５３１、メモリ内規則インポートユニット５３２および規則更新ユニット５３３のすべての機能は、ソフトウェアを使用して実装しても良い。

【0033】

支払いサーバ５２は、カード選択規則通信ユニット５２１および支払い処理ユニット５２２を含んでも良い。一実施形態では、支払いサーバ５２はさらに、ユーザの新規口座の受信、ユーザおよび関連する口座情報の修正、およびユーザの支払い情報の表示などの機能を含んでも良い。これらの機能はすでに、既存の支払いサーバに存在するため、これ以上の説明は本開示では行わない。既存の支払いサーバとの違いは、本明細書で開示する、支払いサーバ５２のカード選択規則通信ユニット５２１と、支払い処理ユニット５２２である。

【0034】

カード選択規則通信ユニット５２１は、新しいまたは修正したユーザのカード規則を受信し、そのカード選択規則をデータベースに格納する。

【0035】

支払い処理ユニット５２２は、ユーザクライアント４１から支払い要求を受け取り、現在の支払い用の銀行カードを、規則エンジンユニット５３１から取得し、支払い額を受取人に、銀行カードを使用して転送する。ユーザクライアント４１から支払い要求を受信すると、支払い処理ユニット５２２は、ユーザ情報、受取人情報、および要求されている支払い額を解析する。対応する銀行カード情報が、ユーザ情報に従って広範テーブルで見つかり、複数の銀行カードの情報が見つかった場合、支払い処理ユニット５２２は、カード選択要求を規則エンジンサーバ５３に送信し、カード選択処理結果を規則エンジンサーバ５３から受信する。カード選択処理の結果には、特定のカードが現在の支払い用の銀行カードとして選択されるか、要件を満たす銀行カードが見つからなかったかの２種類の結果を含むことができる。

【0036】

特定のカードが、現在の支払い用の銀行カードとして選択されると、関連する支払いが、この銀行カードを使用して完了し、支払い処理結果がデータベース５１に格納される。要件を満たす銀行カードが見つからなかった場合、処理は終了し、対応する処理結果がユーザクライアント４１に返される。

【0037】

口座残高調整サーバ５４は、各種銀行カードの残高調整を、支払い記録格納ユニット５１２に格納されているそれぞれの支払い要求の処理結果の情報に基づいて完了する。

【0038】

一実施形態では、口座残高調整サーバ５４および支払いサーバ５２は、単一のサーバで実現しても良い。

【0039】

本実施形態では、支払いを行う操作およびカードの選択は、支払いサーバ５２と規則エンジンサーバ５３で個別に行われる。したがって、既存の支払いサーバへの大幅な修正は必要ない。カード選択操作を完了するための追加の規則エンジンサーバ５３を導入するこの設計により、既存の支払いサーバのセキュリティとシステムの結合が改良できる。

【0040】

本実施形態では、規則エンジンソフトウェアが起動するたびに、カード選択規則の情報があらかじめサーバ５３のメモリにインポートされる。さらに、メモリに格納されたカード選択規則は定期的に更新される。したがって、カード選択速度は、同時に保証されるカード選択の正確性により改善される。

【0041】

図４は、この例示した実施形態に従った銀行カードの適応的選択のための方法４００を示すフローチャートである。この方法は、ユーザと受取人との間で支払いプラットフォームを通じて支払い操作を行い、
Ｓ１１０：複数の銀行カードから支払いカードを選択するためのカード選択規則の情報を設定すること
を含む。

【0042】

最初に、支払いサーバ５２は、銀行カード選択規則を設定または修正するためのメンテナンスインターフェイスをユーザに提供する。

【0043】

次に、支払いサーバ５２は、メンテナンスインターフェイスで設定または修正されたユーザ定義カード選択規則を受信する。

【0044】

最後に、支払いサーバ５２は、ユーザ定義カード選択規則と各種銀行カードの支払い限度を含むカード選択規則とを統合して、次にデータベースの規則ストレージユニット５１３に格納される現在のユーザのカード選択規則（表１のように）とする。

【0045】

Ｓ１２０：ユーザクライアントの支払い要求を受信すると、支払いサーバ５２は、規則エンジンサーバ５３を使用して、現在の支払い用の銀行カードを、カード選択規則および支払い記録に基づいて複数の銀行カードから選択する。

【0046】

ユーザクライアントの支払い要求を受信すると、支払いサーバ５２は必要な支払額の情報および受取人クライアントの情報を取得する。

【0047】

ユーザが、複数の銀行カードを所有していることが分かった場合、支払いサーバ５２は規則エンジンサーバ５３にカード選択要求を送信する。

【0048】

規則エンジンサーバ５３は、複数の銀行カードのうちどの銀行カードがカード選択規則の要件を満たしているかを１枚ずつ判別し、現在の支払い用の銀行カードとなる、カード選択規則の要件を満たしているカードを１枚選択する。

【0049】

Ｓ１３０：支払いサーバ５２は選択された銀行カードを使用して、支払い額を受取人に転送する。

【0050】

支払いサーバ５２は、関連する支払い処理条件を支払い記録に格納し、口座残高調整および決済操作を、口座残高調整サーバ５４を介して銀行のサブシステムと共に完了する。

【0051】

本実施形態では、規則エンジンソフトウェアが起動するたびに、カード選択規則の情報があらかじめサーバ５３のメモリにインポートされる。さらに、新しいまたは更新されたカード選択規則が定期的にデータベースから取得される。これらのカード選択規則に基づいて、現在メモリに格納されている既存のカード選択規則が更新される。したがって、カード選択速度は、同時にカード選択の正確性を保証しながら改善される。

【0052】

第２の実施形態例
図５および図６は、本開示に従った支払い用銀行カードの適応的選択のためのシステム５００の第２の例を示す概略組織図である。システムは、支払いプラットフォーム６１、受取人クライアント６２、各種の銀行サブシステム６３、およびＷＡＰネットワーク６４を含む。ＷＡＰネットワーク６４は、Ｗｅｂサーバ６４１、ＷＡＰプロキシサーバ６４２および携帯電話端末６４３を含む。Ｗｅｂサーバ６４１は、ＨＴＭＬ Ｗｅｂページ形式でデータを送信する。Ｗｅｂサーバ６４１のＨＴＭＬフィルタは、このＷｅｂページをＷＭＬ（Ｗｉｒｅｌｅｓｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式に変換し、次にバイナリＷＭＬデータに処理されてユーザクライアント（携帯電話端末６４３）に、ＷＡＰプロキシサーバ６４２により送信される。ＷＡＰネットワーク６４は別の形式でも良い。これらのコンポーネントは、既存の技術を採用しているため、詳細は本明細書では繰り返して説明しない。本実施形態では、Ｗｅｂサーバ６４１、ＷＡＰプロキシサーバ６４２および携帯電話端末６４３は、説明のために使用しているにすぎない。本開示はこれに制限するものではない。

【0053】

図６を参照すると、支払いプラットフォーム６１はさらに、データベース７１およびサーバ７２を含んでも良い。データベース７１に格納されているデータは、第１の実施形態例のデータを同じ種類であっても良い。一実施形態では、サーバ７２は、規則エンジンユニット７２１、支払い処理ユニット７２２、および口座残高調整ユニット７２３を含んでも良い。

【0054】

規則エンジンユニット７２１は、データベース７１と通信できるよう接続され、カード選択規則に基づいて複数の銀行カードから現在の支払い用の銀行カードを選択することができる。

【0055】

支払い処理ユニット７２２は、データベース７１と規則エンジンユニット７２１に通信できるよう接続され、支払い要求をユーザクライアントから受信し、現在の支払い用の銀行カードを規則エンジンユニット７２１から取得し、その銀行カードを使用して受取人に支払額を移す。

【0056】

口座残高調整ユニット７２３は、各種の銀行サブシステムとの口座残高調整および決済操作を完了する。

【0057】

一実施形態では、第１の実施形態例の支払いサーバの機能、規則エンジンサーバおよび口座残高調整サーバはサーバ７２により実現される。この実装により、カードの選択および支払いの処理速度を改善できる。

【0058】

図７は、この第２の実施形態例に従った銀行カードの適応的選択用の方法７００を示すフローチャートである。この方法は、ユーザと受取人との間で支払いプラットフォーム通じて支払い操作を行い、
Ｓ２１０：サーバが複数の銀行カードから支払いカードを選択するためのカード選択規則の情報を設定すること
を含む。

【0059】

ユーザは、ネットワーキングクライアントを使用して支払いカード用のカード選択規則に関連する情報を設定することができる。または、携帯電話端末６４３を使用して支払いカード用のカード選択規則に関連する情報を設定することができる。

【0060】

基本的に、カード選択の処理には、サーバやユーザに、銀行カード選択規則を設定または修正するためのメンテナンスインターフェイスを提供することと、次にサーバが、メンテナンスインターフェイスを通じて設定または修正したユーザ定義カード選択規則を受信することと、サーバがユーザ定義のカード選択規則と、各種銀行カードの支払い限度を含むシステムのカード選択規則をカード選択規則に統合して、データベースに格納することとを含んでも良い。

【0061】

Ｓ２２０：ユーザクライアントの支払い要求を受信すると、サーバは現在の支払い用の銀行カードを、カード選択規則および支払い記録に基づいて、複数の銀行カードから選択する。

【0062】

ユーザクライアントの支払い要求を受信すると、サーバは必要な支払額の情報および受取人クライアントの情報を取得する。ユーザが、複数の銀行カードを所有していることが分かった場合、サーバは規則エンジンユニットカードに選択要求を送信する。規則エンジンユニットは、複数の銀行カードのうちどの銀行カードがカード選択規則の要件を満たしているかを１枚ずつ判別し、現在の支払い用の、カード選択規則の要件を満たしているカードを１枚選択する。

【0063】

Ｓ２３０：支払い額が、選択された銀行カードを使用して受取人に転送される。

【0064】

サーバは銀行カードを使用して支払い操作を完了し、続いて各種銀行のサブシステムと口座残高調整および決済を定期的に完了する。

【0065】

本実施形態では、カード選択規則はメモリまたはデータベースに格納することができる。さらに、サーバは新しいまたは更新されたカード選択規則をデータベースから定期的に取得し、これらの新しいまたは更新されたカード選択規則に基づいて、現在メモリに格納されているカード選択規則を更新しても良い。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】