(57)【要約】  本発明は電子支払システムと方法を提供する。本発明は電子支払システム分野に関わる。電子支払システムはユーザーのデバイスを利用して簡素な方法で送金と金銭の受領を容易にする。同システムは統一支払インターフェース(UPI)を提供し、利用者が対象人物/法人口座から支払プッシュとプル/回収をできるようになる。本発明のシステムは相手の銀行情報と銀行アカウント詳細を必ずしも必要とせずに、支払者と支払受取人間の支払取引を可能にする。顧客のアカウント詳細の保存リスクを無くし、クレジットカード/デビットカードを持たない顧客でも利用できる。支払取引のプライバシーを提供し、マルチプルユーティリティー現金着払い、請求書共同負担、商取引支払、、送金を容易にする。本発明の電子支払システムは異なるインターフェースで機能し、ここに、支払要請をウェブインターフェースで生成して、モバイル インターフェース (アプリケーションツール)で許可することが可能となる。【選択図】図１
2019522833.tif 000002
【特許請求の範囲】
【請求項１】
複数ユーザー間の支払取引を容易にする電子支払システム(EPS) (1000)であって、前記のシステムは以下から構成される:
・所定ルールを記憶させるよう構成されたメインストレージ・デバイス(1002a)
・メインストレージ・デバイス(1002a)と共同で所定ルールを受信、処理してシステム操作コマンドを取得するように構成された処理プロセッサ(1002b)。
・ユーザー登録用に構成され、さらに前記のEPS (1000)に登録する構成された複数の支払サービスプロバイダー システム(PSPS)であって、各PSPS (1004)は以下から構成される:
・PSPS (1004)に登録した利用者関連のユーザー情報データを保存するよう構成したローカルストレージ・デバイス(1004a)
・顧客が入力するデータ、ユーザー情報データ、登録ユーザーを照合するように構成された少なくとも1つの検索表(1004b)
・PSPSサーバ (1004c)
・複数のユーザーのデバイスであって、その各ユーザーデバイスがユーザー情報データの一環として登録済みである前記の登録ユーザーの1人と関連づけられている
・支払サービスプロバイダー アプリケーション (PSPA)ツール、前記のEPS (1000)に登録されたPSPS (1004)のPSPSサーバ(1004c)と関連付けここにホスティングされている各PSPAツール(1008)であって、登録ユーザーがPSPAツール(1008)と関連付けられたPSPSに登録されているか否かに関わらず、登録ユーザーのデバイス(1006)にダウンロードして保存可能な要素を有し、 ここに各PSPAツール(1008)は前記の登録ユーザーによる支払要請関連の取引データ信号の生成と受領を可能にし、要請に基づいて前記登録ユーザーの口座に貸方記帳や借方記帳を行う。各PSPAツール (1008)の前記のダウンロードして保存可能な要素は以下から構成される:
・PSPAツール(1008)と一意対応に関連付けられた登録済みPSPS (1004)にユーザーデバイス(1006)を登録することを可能にするよう構成された登録モジュール(1008a)及び
・登録ユーザーは登録ユーザーが登録されているPSPSの識別を含む固有のVPAを作成することができるほか、ユーザーデバイス(1006)は登録ユーザーのユーザー情報データとして前記の固有VPAをユーザー登録してあるPSPS (1004)のローカルストレージ・デバイス(1004a)に送信することも可能にするように構成された仮想支払アドレス(VPA)生成モジュール(1008b)、 
さらに、
・PSPS (1004)をEPS (1000)に登録することを可能にし、さらに、PSPSが同じ又は異なる登録ユーザー間の支払を実行するための取引データ信号の転送制御をPSPS間で選択的に可能にするように構成された統一支払インターフェース(UPI) (100)であって、前期のUPI (100)は以下から構成される: 
・複数のPSPSと共同で定期的に借方と貸方取引残高を校合し、登録済みPSPS間の正味借方と貸方残高明細を生成するように構成された決済モジュール(100a)
【請求項２】
請求項1において請求されるEPS (1000)であって、ここに、前記のUPI (100)はさらに以下から構成される：
・登録ユーザー デバイスがPSPAツール経由で送った支払要請に関連する取引データ信号を受信するように構成されたレシーバー(100b)であって、ここに、各要請が第1登録ユーザーのVPA、第2登録ユーザーのVPA、取引額から構成される
・パース処理後の信号を取得するために取引データ信号をパースするように構成されたパーサー(100c)
・パース処理後の信号から第1登録ユーザーのPSPSと第2登録ユーザーのPSPSに関連する情報を抽出要素識別子で抽出して識別するように構成された抽出要素識別子(100d)
・取引データ信号を識別された対応するPSPSに転送し、パースしたデータ信号の内容に応じて第1登録ユーザーと第2登録ユーザーの口座間での貸方記帳ないし借方記帳を可能にするように構成された転送要素(100e)
【請求項３】
請求項1において請求されるEPS (1000)であって、ここに、各PSPS (1004)がさらに2要因認証を提供するように構成された認証モジュールであって、前記の認証モジュールが以下から構成される：
・登録前固有番号を受け取り、PSPS (1004)に登録された利用者を形成し、ローカルストレージ・デバイス (1004a)に保存された受諾済みの登録前固有番号と登録ユーザーのユーザー情報データを照合することで登録ユーザーを確認し、登録ユーザー デバイス(1006)と関連付け、この際第1要因認証を提供するように構成された第1要因認証要素
・登録ユーザーのUPI PINないし生体認証入力を受諾し、受諾済みUPI PINないし生体認証の入力とユーザー情報データを照合することによって登録ユーザーをを認証し、この際第2要因認証を提供するするように構成された第2要因認証要素。 
【請求項４】
請求項2において請求されるEPS (1000)であって、ここに、前記のUPI (100)がさらに、取引データ信号を処理する取引サーバ、登録ユーザーを認証する認証サーバ、登録済みPSPSを識別するための保存されたルールを処理するUPIサーバから構成される。
【請求項５】
複数ユーザー間の支払取引を容易にする電子支払方法であって、前記の方法を以下の手順で構成する:
・メインストレージ・デバイスへの保存、所定ルール
・処理用プロセッサによる処理、システム操作コマンドの取得用の前記所定ルール
・利用者を電子支払システム(EPS) (1000)に登録するように構成した複数の支払サービスプロバイダー システム(PSPS)に登録し、各PSPSは以下の手順で構成される: 
・前記のPSPSに登録済み利用者に関連するユーザー情報データをローカルストレージ・デバイスへに保存する
・少なくとも1つの検索表により顧客が入力するデータ、ユーザー情報データ、登録ユーザーの照合を可能にし、
・PSPSサーバに提供する
・複数のユーザーのデバイスの各ユーザーのデバイスをユーザー情報データの一環として登録する前記登録ユーザーの1人と関連付ける
・複数のPSPAツールの各支払サービスプロバイダー アプリケーション (PSPA)ツールを前記のEPSに登録済みであって、登録ユーザーが前記のPSPAツールと関連付けられたPSPSに登録されているか否かに関わらず登録ユーザーのデバイスにダウンロードして保存可能な要素を有し、さらに、各PSPAツールによって前記の登録ユーザーからの支払要請関連の取引データ信号生成と受領を可能にするPSPSのサーバに関連づけ、ホストし、前記の要請に基づく前記の登録ユーザーの口座に貸方記帳や借方記帳を行い、各PSPAツールの前記のダウンロードして保存可能な要素は以下の手順からなる:
・登録モジュールによって、PSPAツールと一意対応に関連付けられた登録済みPSPSにユーザーデバイスの登録を許可し
・仮想支払アドレス(VPA)生成モジュールによって登録ユーザーを登録してあるPSPSの識別を含む固有のVPAを登録ユーザーが生成することを可能にしり、さらに ユーザーデバイスがこのモジュールによって前記の固有のVPAをユーザーを登録してあるPSPSのローカルストレージ・デバイスに、登録ユーザーのユーザー情報データの一部として送信することも可能にし、 
さらに、
・統一支払インターフェース(UPI)によって、PSPSを前記のEPSに登録することを容易ならしめ、同一か異なるPSPSにおけるかを問わず取引データ信号の転送をPSPS間で選択的に制御して実行しやすくし、登録ユーザー間の支払を実行しやすくする。前記のUPIは以下の手順から構成される：
・前記の複数のPSPSと共同で定期的に貸方借方取引残高を校合し、前記の登録済みPSPS間の正味貸方借方残高明細を生成する決済モジュールを提供する。
【請求項６】
請求項5において請求される方法であって、ここに、前記のUPIがさらに以下から構成される：
・登録ユーザー デバイスがPSPAツール経由で送った支払要請に関連する取引データ信号をレシーバーが受信、ここに、各要請は第1登録ユーザーのVPA、第2登録ユーザーのVPA、取引額から構成する
・パーサーがパース処理後の信号を取得するために前記の取引データ信号をパースし、
・パース処理後の信号から第1登録ユーザーのPSPSと第2登録ユーザーのPSPSに関連する情報を抽出要素識別子で抽出して識別する 
・次に転送要素が前記の取引データ信号を識別された対応するPSPSに転送し、パースしたデータ信号の内容に応じて第1登録ユーザーと第2登録ユーザーの口座間での貸方記帳ないし借方記帳を可能にする。
【請求項７】
請求項5において請求される方法であって、ここに、各PSPSはさらに以下から構成される：
・認証モジュールによる2要因認証を提供する、 2要因認証を提供する前記のステップは以下の二段階である: 
・第1要因認証要素が、利用者が前記のPSPSに登録した登録前固有番号フォームを受け取り、前記のローカルストレージ・デバイスに保存された受諾済みの登録前固有番号と登録ユーザーのユーザー情報データを照合することで登録ユーザーを確認し、これによって登録ユーザー デバイスと関連付け、
・第2要因認証要素が登録ユーザーのPINないし生体認証入力を受諾し、受諾済みPINないし生体認証の入力と前記のユーザー情報データを照合することによって登録ユーザーをを認証し、これにより第2要因認証を提供する。 
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は電子支払システムに関する。
【０００２】
用語の定義 
本明細書においてこれ以降使用する「登録ユーザー」という用語は電子支払取引用の本発明の電子支払システム(EPS)を使用する者を意味する。登録ユーザーは支払者すなわち、EPSで送金/支払を望む者か、支払受取人すなわち、EPSで金銭を受領/回収する者であってよい。
【０００３】
本明細書においてこれ以降使用する「ユーザーのデバイス」という用語は登録ユーザーが使用するデバイスであって、ここにユーザーのデバイスには限定することなく携帯電話、ノートPC、タブレット、iPad、PDA、ノートブック、ネットブック、スマートデバイス、スマートフォン、パーソナルコンピュータ、ハンドヘルドデバイス類を含む。
【０００４】
本明細書においてこれ以降使用する「支払取引」という用語は金融取引と金融外取引を意味する。金融取引は回収/プル要請、支払/プッシュ要請、商用支払取引から成る。金融外取引は限定することなくモバイルバンキング登録, ワンタイムパスワード(OTP)の生成、残高照会、PIN設定や変更、苦情ログの作成、and 取引状況の確認を含む。
【０００５】
本明細書においてこれ以降使用する「支払サービスプロバイダー・システム(PSPS)」という用語は銀行、支払銀行や顧客を獲得して顧客（個人や法人）に支払（借方記帳/貸方記帳）サービスを行うことを認可されているその他中央ですなわち政府が規制する法人を意味する。PSPSは登録ユーザーがユーザーのデバイスからアクセスして支払の送金や引き落とし（プル）を行うことができる対応するアプリケーションツールを提供する。PSPSは金融および金融外取引の電子的処理用ツールを提供する。
【０００６】
本明細書においてこれ以降使用する「送信元」という用語は本発明のユーザーのデバイスで金銭の支払/送金（プッシュ）か回収/プル（引き落とし）要請を送る登録ユーザーを意味する。送信元は支払者や支払受取人でありうる。
【０００７】
本明細書においてこれ以降使用する「受信者」という用語は本発明のユーザーのデバイスでユーザーのデバイスで金銭の回収/プル（引き落とし）か支払/プッシュ（送金）の要請を受領する登録ユーザーを意味する。受信者は支払受取人か支払者でありうる。
【０００８】
本明細書においてこれ以降使用する「固有のID」又は「仮想支払アドレス(VPA)」という用語は登録ユーザーに関連付けられた固有の識別子を意味する。固有のIDまたは仮想支払アドレス(VPA)は支払取引を実行するために使用される。これは支払取引用に登録ユーザーが作成することができる。
【０００９】
本明細書においてこれ以降使用する「統一支払インターフェース(UPI)」という用語は、支払取引と決済を含む金融および金融外取引用PSPS間のインターフェースを提供するインターフェース システムを意味する。
【００１０】
本明細書においてこれ以降使用する「支払サービスプロバイダーアプリケーション(PSPA)」という用語はPSPSが提供するアプリケーションツールを指す。PSPAツールはUPIを通したPSPSとのインターフェースとなるウェブポータルやPlay Storeないしモバイルウェブ または他の方法が提供することが可能である。
【００１１】
本明細書においてこれ以降使用する「ユーザー情報データ」という用語は登録ユーザー」のVPA、アカウント詳細その他金融外の詳細を含む登録ユーザーに関連するデータを意味する。ユーザー情報データで登録ユーザーを認証する。
以上の定義は本分野における現在の用語に追加されるものである。
【背景技術】
【００１２】
発明技術の背景
近年では、金融取引はフィーチャーフォンやスマートフォンといったようなハンドヘルドデバイスを使ってますます実行されるようになっている。現在ではハンドヘルドデバイスを使った様々な支払方法を利用できる。これらの支払方法は支払受取人の口座番号と支払受取人の銀行に関する追加項目を知らないとできない。オンライン支払の場合は、支払者は取引先銀行のウェブポータルでインターネット・バンキングかモバイル・バンキングを利用して金融取引を実行せざるを得ない。今日まで、インターネット・バンキングやモバイル・バンキング用の銀行ウェブポータルが使いにくい、つまり操作しにくくデータ入力と認証のために時間を費やすので多くのユーザーがまだオンライン金融取引/電子取引を快適に利用できていない。
【００１３】
場合によっては、支払うために支払受取人の携帯電話番号を使用する。しかし、このような支払方法では、モバイル・バンキングはSIM番号に基づいているので、支払者が支払受取人の銀行詳細や携帯電話番号を知っていなければならない。こうした取引形態では例外なく、支払は支払者から支払受取人へのプッシュ形態となる。支払受取人は支払者に取引上全く依存しており、支払者は取引先銀行ウェブポータルの支払サービスに依存する。一部のユーザーは携帯や固定電話の番号を頻繁に変える場合があり、こうした場合には、支払者がこれらの変更についていけなくなる。さらに、場合によっては、支払者と支払受取人が自銀行の詳細や個人情報を相互に開示したくない場合もある。 
【００１４】
従って、上記の不利な点を制限して効率的かつ簡素化されたユーザーが使いやすい電子支払取引システムと方法を提供する必要性がある。 
【発明の概要】
【発明が解決しようとする課題】
【００１５】
発明の目的
本発明の目的の一部は少なくとも1つの実施例を本明細書において取り上げることでじゅうぶんであるが、以下のものである。
【００１６】
先行技術の持つ一つまたは複数の課題を改善するかまたは少なくとも有用な代替手段を提供することが本発明の目的である。
【００１７】
本発明の目的は使いやすい電子支払システムを提供することである。
【００１８】
本発明のもう一つの目的は統一支払インターフェース(UPI)を利用する電子支払システムを提供することである。
【００１９】
本発明のさらにもう一つの目的は対象法人が支払を許可した後ユーザーが相手先の口座から支払を引き落とす/回収することが可能な電子支払システムを提供することである。
【００２０】
本発明のさらにもう一つの目的は認証ステップを減らし、セキュリティ機能を増やすことにより支払者と支払受取人双方にとって電子支払システムを簡素化することである。
【００２１】
本発明のさらに別の目的は相手の銀行情報と銀行アカウント詳細を必ずしも必要とせずに支払者と支払受取人間の支払取引を可能にする電子支払システムを提供することである。
【００２２】
さらに、本発明の目的は仮想支払アドレスを経由して送金や金銭受取を可能にする電子支払システムを提供することである。
【００２３】
本発明のさらにもう一つの目的はインターネット用取引先銀行ウェブポータルやモバイル アプリケーションやモバイル・バンキングに依存せず、取引先銀行口座以外の支払取引のために異なる銀行ウェブポータルやモバイル アプリケーションを使うことを可能にする電子支払システムを提供することである。
【００２４】
本発明のその他の目的と優位性は本発明の範囲をこれに限定することは意図されていない次の悦明によってさらに明らかとなる。
【課題を解決するための手段】
【００２５】
発明の要約：
複数ユーザー間の支払取引を容易にする電子支払システム(EPS)と方法を提供する。システムはメインストレージ・デバイス、処理用プロセッサ、ユーザー登録用に構成され、さらにEPSへの登録用に構成された複数の支払サービスプロバイダーシステム(PSPS)、複数のユーザーのデバイス、支払サービスプロバイダー アプリケーションツール(PSPA)、統一支払インターフェース(UPI)から成る。メインストレージ・デバイスには処理プロセッサがシステム操作コマンドを取得するために必要とする所定ルールを記憶させておく。各PSPSはPSPSに登録しているユーザーに関連するユーザー情報データを保存するローカルストレージ・デバイス、顧客が入力したデータ、ユーザー情報データ、登録ユーザー、PSPSサーバの照合を容易にする少なくとも1つの検索表から成る。複数のユーザーのデバイスのうち各ユーザーのデバイスはユーザー情報データの一環として登録済みである登録ユーザーの1人と関連づけられている。各PSPAツールはEPSに登録済みのPSPSサーバにホストされこれと関連づけられ、登録ユーザーがPSPAツールと関連付けられたPSPSに登録されているか否かに関わらず、登録ユーザーのデバイスにダウンロードして保存可能な要素を有する。各PSPSツールは登録ユーザーからの支払要請に関連した取引データ信号の生成と受信を容易にし、要請に基づいて登録ユーザーの口座に借方/貸方記帳を行う。PSPAツールのダウンロードして保存可能な各要素は登録モジュールと仮想支払アドレス(VPA)生成モジュールから成る。登録モジュールはPSPAツールと一意対応に関連付けられた登録済みPSPSにユーザーデバイスの登録を許可する。VPA生成モジュールでは登録ユーザーを登録してあるPSPSの識別を含む固有のVPAを登録ユーザーが生成することが可能であり、さらにユーザー デバイスはこのモジュールによって固有のVPAをユーザーを登録してあるPSPSのローカルストレージ・デバイスに、登録ユーザーのユーザー情報データの一部として送信することもできる。UPIはPSPSをEPSに登録することを容易ならしめ、同一か異なるPSPSにおけるかを問わず取引データ信号の転送をPSPS間で選択的に制御して実行しやすくし、登録ユーザー間の支払を実行しやすくする。UPIは複数のPSPSと共同で定期的に貸方と借方の取引残高を校合し、登録済みPSPS間の正味貸方借方残高明細を生成する決済モジュールからなる。
【図面の簡単な説明】
【００２６】
本発明の電子支払システムとその方法を付帯図面を用いて説明する。図面は以下の通りである：
【００２７】
【図１】図1は本発明の実施形態による電子支払システム(EPS)のブロック図を示す。
【図２】図2Aは図1の実施形態に従うEPSを利用したユーザー間取引の流れ図を示す。図2Bは図1の実施形態に従うEPSを利用した別のユーザー間取引の流れ図を示す。
【図３】図3は図2AのEPSを利用した支払回収の場合の支払取引の流れ図を示す。
【図４】図4は図2BのEPSを利用した直接支払の場合の支払取引の流れ図を示す。
【図５】図5は図1のEPSを利用したタクシー運転手と乗客の間の支払取引の流れ図を示す。
【図６】図6は図1のEPSを利用した送金支払取引の流れ図を示す。
【図７】図7は図1の実施形態に従う、同じPSPSに登録した顧客と商人間の三者間商取引の流れ図を示す。
【図８】図8A、8B、8C、8D、8Eは図1のEPSのPSPAツールを利用した登録ユーザー デバイスに表示される異なる画面を表す。
【００２８】
説明と図面に使用する参照番号の凡例:
参照番号：  参照先
1000：  電子支払システム(EPS)
100, 500, 600, 700：  統一支払インターフェース(UPI)
100a：  決済モジュール
100b：  レシーバー
100c：  パーサー
100d：  抽出要素識別子
100e：  転送要素 
1002a：  メインストレージ・デバイス
1002b：  処理プロセッサ
1004：  支払サービスプロバイダー・システム(PSPS)
1004a：  ローカルストレージ・デバイス 
1004b：  少なくとも1つの検索表  
1004c：  PSPSサーバ 
1006：  ユーザーのデバイス
1008：  支払サービスプロバイダー アプリケーション(PSPA)ツール
1008a：  登録モジュール
1008b：  仮想支払アドレス(VPA)生成モジュール
102, 502, 702：  支払受取人のユーザーのデバイス
104, 504, 604：  支払者のユーザーのデバイス
106, 506, 606：  支払受取人のPSPS 
108, 508, 608：  支払者のPSPS 
110, 510, 610, 706：  送金者/発行人/ 支払者の銀行
112, 512, 612, 708：  受益者/受取人/支払受取人の銀行
704：  商人/顧客PSPS (共通PSPS)
710：  顧客
【発明を実施するための形態】
【００２９】
発明の詳細な説明
以下では本発明について発明の範囲と目的を説明するが制限はしない付帯実施形態を参照しつつ説明する。説明はあくまでも例示および図解のために行われる。
【００３０】
近年、銀行口座保有者はデビット/ATMカードを金銭取引のために口座保有者の銀行に属する銀行承認ATMでしか使用できなかった。銀行利用者、クライアント、顧客の要求事項が増大するにともない、銀行口座保有者はどの銀行のATMでも利用できるようにATMへのアクセスを各愛することで新たなモデルが提供された。今日では、特定銀行に関わらず世界でATMを利用できるようになった。このため取引当事者間の取引処理と資金決済を提供するように運用されている異なるネットワークを一貫して銀行ATMやデビット/ATMカード間の汎用相互運用性が円滑化された。
【００３１】
本発明は支払取引用バンキング モバイル アプリケーションや銀行のウェブポータルの相互運用性を解決する。本発明のシステム利用者や銀行顧客はその口座を置いている銀行のウェブポータルやモバイルウェブを利用するのみに限定されない。これとは反対に、利用者(支払と支払受取人)や顧客は相手先の銀行アカウント詳細を知らずとも、どの銀行のウェブポータルやモバイルウェブでも支払取引のために選択できる。利用者(支払者か支払受取人)は金融/電子支払取引を実行するために固有のIDや仮想支払アドレス(VPA)を知っているだけでよい。
【００３２】
付帯図面を参照すると、図1は複数ユーザー間の支払取引を容易にする電子支払システム(1000) (以下「EPS」と表記)の概念ブロック図を示す。支払取引には金融取引と金融外取引を含み、ここに金融取引は金融取引は回収/プル要請、支払/プッシュ要請、商用支払取引を含み、金融外取引はモバイルバンキング登録、ワンタイムパスワード(OTP)の生成、PIN設定や変更、取引状況の確認、苦情ログの作成やこの種の取引を含む。
【００３３】
EPS (1000)はメインストレージ・デバイス(1002a)、処理用プロセッサ (1002b)、複数の支払サービスプロバイダー システム(PSPS)、複数のユーザーのデバイス、支払サービスプロバイダー アプリケーション(PSPA)ツール、統一支払インターフェース (UPI) (100)からなる。
【００３４】
メインストレージ・デバイス(1002a)には所定ルールを記憶させるよう構成する。メインストレージ・デバイス(1002a)には、読出し専用メモリ (ROM)、消去可能プログラム可能ROM、フラッシュ メモリ、ハードディスク、光学式ディスク、磁気テープやクラウド上の保存領域（クラウドストレージ）などの、例えば、揮発性メモリ、静的ランダムアクセスメモリ (SRAM)、動的ランダムアクセス メモリ(DRAM)、及び/又は不揮発性メモリを含む当分野において既知のコンピュータが読出し可能な媒体を含むことができる。一実施形態において、メインストレージ・デバイス(1002a)は電子支払取引、支払要請の送信と受信やこの種の交信に関連する所定ルールを保存するよう構成されている。
【００３５】
処理プロセッサ(1002b)はメインストレージ・デバイス(1002a)と共同で所定ルールを受信、処理してシステム操作コマンドを取得するように構成されている。処理プロセッサ(1002b)は、一つまたは複数のマイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、中央演算デバイス、ステートマシン、論理回路、及び/又は演算命令に基づいて信号を操作する任意のデバイスとして実装することができる。その他の機能のなかでもとりわけ、処理プロセッサ (1002b) メインストレージ・デバイス(1002a)に保存された所定ルールをゲットして実行し、EPS 1000のモジュールを制御するように構成されています。
【００３６】
複数の支払サービスプロバイダー システム(PSPS)はEPS (1000)に登録し、利用者を登録するように構成されている。各PSPS (1004)はローカルストレージ・デバイス (1004a)、少なくとも1つの検索表 (1004b)、PSPSサーバ (1004c)から成る。ローカルストレージ・デバイス(1004a)はPSPS (1004)に登録した利用者関連のユーザー情報データを保存する。一実施形態において、ユーザーデータは仮想支払アドレス(VPA)、アカウント詳細、登録ユーザーに関するその他の金融外の詳細を含み、登録ユーザーを認証可能にする。少なくとも1つの検索表(1004b)により顧客が入力するデータ、ユーザー情報データ、登録ユーザーを照合する。
【００３７】
複数のユーザーのデバイスの各ユーザーデバイス(1006)は登録ユーザーと一意に対応しており、ユーザー情報データの一環として登録されている。各登録ユーザーは登録ユーザー デバイスを使用して支払要請関連の取引データ信号をPSPAツールによって生成する。
【００３８】
PSPAツールの各PSPAツール(1008)は前記のEPS (1000)に登録してある、PSPS (1004)のPSPSサーバ (1004c)と関連付けられており、このサーバにホストされ、登録ユーザーがPSPAツール(1008)と関連付けられたPSPSに登録されているか否かに関わらず、登録ユーザーのデバイス(1006)にダウンロードして保存可能な要素を有する。各PSPAツール(1008)は前記の登録ユーザーによる支払要請関連の取引データ信号の生成と受領を可能にし、要請に基づいて登録ユーザーの口座に貸方記帳や借方記帳を行う。ダウンロードして保存可能な要素各PSPAツール(1008)は登録モジュール(1008a)と仮想支払アドレス(VPA)生成モジュール(1008b)から成る。登録モジュール(1008a)はPSPAツール (1008)と一意対応に関連付けられた登録済みPSPS (1004)にユーザーデバイス (1006)を登録することを可能にする。VPA生成モジュール(1008b)により登録ユーザーは登録ユーザーが登録されているPSPSの識別を含む固有のVPAを作成することができるほか、ユーザーデバイス(1006)は登録ユーザーのユーザー情報データとして固有のVPAをユーザーを登録してあるPSPS (1004)のローカルストレージ・デバイス(1004a)に送信することも可能になる。
【００３９】
UPI (100)はPSPS (1004)をEPS (1000)に登録することを可能にし、さらに、PSPSが同じ又は異なる登録ユーザー間の支払を実行するための取引データ信号の転送制御をPSPS間で選択的に可能にする。 UPI (100)は複数のPSPSと共同して定期的に貸方借方取引残高を校合し、登録済みPSPS間の正味貸方借方残高明細を生成する決済モジュール(100a)から成る。一実施形態において、決済モジュール(100a)が決済サーバである。
【００４０】
取引データの転送制御を容易ならしめるために、UPI (100)はさらにレシーバー(100b)、パーサー(100c)、抽出要素(100d)、転送要素(100e)から成る。レシーバー(100b)はPSPAツールのいずれかを通して登録ユーザー デバイスから来る支払要請関連の取引データ信号を受信する。各支払要請は第1登録ユーザーのVPA、第2登録ユーザーのVPA、取引額から構成され、これらのVPAには第1登録ユーザーと第2登録ユーザーが登録してあるPSPSに関連する情報が含まれる。パーサー(100c)はパース処理後の信号を取得するために取引データ信号をパースする。次に第1登録ユーザーのPSPSと第2登録ユーザーのPSPS関連情報が抽出要素識別子(100d)によりパースされた信号から抽出され識別される。次に転送要素(100e)は取引データ信号を識別された対応するPSPSに転送し、パースしたデータ信号の内容に応じて第1登録ユーザーと第2登録ユーザーの口座間での貸方記帳ないし借方記帳を可能にする。
【００４１】
付帯図面の図2A、2Bは支払取引用UPI (100)を使用した二者間の取引の流れを表す概念図である。UPI (100)は複数のサーバを持つインターフェースである。
【００４２】
一実施形態において、UPI (100)は取引サーバ、認証サーバ、UPIサーバ、決済サーバを有する。取引サーバは取引データ信号を処理し、認証サーバは登録ユーザーを認証し、UPIサーバは登録済みPSPSを識別するための保存されたルールを処理しする。UPI (100)はPSPAツールを通して出されたPSPSからのコマンド/要請に基づいて銀行とのインターフェースとなる。UPI (100)は取引処理と決済を実行する。一実施形態において、取引処理は取引サーバを利用して実行される。  一日の最後に銀行とPSPS間の決済を決済サーバで行う。一実施形態において、PSPSサーバは登録ユーザーが利用して支払要請を発信するためのPSPAツールをホストする。支払要請は支払/プッシュ要請か回収/プル要請であってよい。
【００４３】
支払プル要請とは個人/法人が他の個人/法人から支払を回収するためのものである。支払プッシュ要請とは個人/法人が別の個人/法人に対して支払う必要があるものである。一実施形態において、ユーザーがプッシュかプル支払を行うことを可能にする手順は以下を含む;
【００４４】
ａ．PSPSに登録する
ｂ．モバイル・バンキングへの登録、取引用UPI PINの生成(未登録の場合)
ｃ．ユーザーのデバイスへのPSPSが提供するPSPAツールダウンロード、PSPAツールを使用したパスワード/ログインPINから成るアカウント詳細を提供することにより登録ユーザーのプロファイル作成
ｄ．PSPAツールを利用して固有のIDとしてVPAを作成し、この際VPAが本発明のシステムを利用して利用者の銀行口座詳細と関連付けられる
ｅ．プッシュかプル支払要請/取引データをPSPAツールによって転送する。
【００４５】
PSPSはPSPAツールを提供する銀行であり、UPI (100)を利用するためEPS (1000)に登録する。上記の「PSPS登録」のステップ「a」において、利用者は自分で選択する銀行に口座を開く。利用者が銀行口座をすでに保有している場合は、ユーザーデバイスを登録するための詳細を含む必要な詳細を提供することによりモバイル・バンキングに登録する。登録が済んだら、上のステップ「c」に説明されているようにPSPAツールをダウンロードする。利用者(例えば、支払者か支払受取人)はPSPAツールの提供銀行に口座の有無にかかわらず、自分のデバイスで自分が選ぶPSPAツールにアクセスする。ステップ「d」で、利用者はVPAを作成するように求められる。VPA作成画面を図8Aに示す。利用者は取引銀行に登録済みなので、口座詳細を記入すればPSPAツールを利用できる。利用者の口座番号は図8AのVPA作成画面に自動表示される。このようにして、利用者は自分のアカウント詳細を思い出すことが不要になる。次に、利用者は新規VPAを作成するか自分が登録したVPA (ＶPAが作成済みの場合)を要求される。一実施形態において、利用者が「xyz」銀行に口座を持っている場合、その人のVPAの末尾コードは「@xyz」になる。特定のPSPSについてのVPA末尾コードの決定ルールはUPI (100)やPSPSが決定し、これをUPIサーバやPSPSサーバに保存する。このためVPAは利用者が登録されているPSPSと関連付けられた末尾コードを持つ利用者が選ぶユーザー 名を持つ。従って、「abc@xyz」の場合は、利用者が自分で決めた「abc」は固有名/利用者名であり、「xyz」はユーザーのPSPS名である。別の例には固有名@HDFC、固有名@SBI、固有名@Corporation、固有名@PNB等を含む。次に、利用者のPSPSはPSPSのローカルストレージ・デバイス上でPSPAツールを使用して作成したその利用者のVPA詳細やその他金融外の詳細を保存する。一実施形態において、利用者は利用者の銀口座を識別して支払取引を実行するために必要なユーザーアカウント名、口座番号、Aadhaar番号、IFSCコード等類似の情報を含むアカウント詳細をPSPAツールで少なくとも1つの銀行に登録する。VPAが正常に作成されると、利用者はVPAを使用し、プッシュかプル支払要請/取引データをPSPAツールを使って送信する。さらに、利用者は口座番号をIFSC 、Aadhaar番号、Aadhaar番号 +IIN、携帯番号、MMID、または単にUPI (100)による支払用携帯番号 (含まれる場合)併用することもできる。
【００４６】
登録とVPA作成が完了すると、利用者(支払者と支払受取人)は対応するVPAを保有する。支払者または支払受取人は相手の銀行名や銀行アカウント詳細を知らずともVPA/固有のIDを使用して、支払取引を実行できる。全利用者のVPと銀行詳細は対応するローカルストレージ・デバイスが維持し、対応するPSPSサーバで処理され、UPI (100)とは共有しない。
【００４７】
支払取引は回収取引(回収要請)と支払取引(支払要請)を含む。PSPAツールはユーザーのデバイスの画面上で支払取引を実行するための登録ユーザーに各種選択肢を提供する（図8B）。利用者はVPAへの支払、VPAからの回収、QRコードを使った支払、IFSC口座番号を使った支払、Aadhaarへの支払、携帯番号への支払のどれでも選択して支払の授受が可能になる。PSPAツールを利用するUPI (100)で利用者はUPI取引履歴を追跡できる。また、利用者は自分のVPAを管理することもできる。利用者がそのVPAを管理しようとすれば、図8Bに表すような「管理」メニューを選択し、これに応えて図8Eの応答画面がPSPAツールにより利用者に対して表示される。次に、利用者はVPAの作成や変更または削除から選択する。
【００４８】
支払受取人が支払者（金銭プルまたは回収取引あるいは回収要請）から金銭を回収するつもりなら(図2A)、支払受取人は支払受取人のユーザーのデバイス(102)からPSPAツールにアクセスして操作し、支払者のVPA/固有のIDと支払受取人が支払者から回収したい金額を提供する(ステップ1)。支払受取人に対して表示される画面は、一実施形態においてこの場合の、図8Dに示す。この画面が 回収要請（すなわち、図8Bの「VPAから回収」)の開始時に表示される。VPAから回収において、利用者のVPA/支払受取人のVPAは登録済みなので自動で記入されている。次に、支払受取人は支払者VPA、回収金額、ある場合は備考を入力する。支払受取人は支払回収を即時または指定時刻に電子的に実行させるよう選択することもできる。回収要請を送信すると、支払受取人のPSPS (106)が有効化する。有効化された要請は支払受取人の登録銀行詳細と支払者のVPA/固有のIDととみにUPI (100)へ支払受取人のPSPS (106)経由で送られる(ステップ2)。UPI (100)は支払者のVPAの末尾コードに基づいて支払者のPSPS (108)を識別し、回収要請を支払者のPSPS (108)に送る(ステップ3)。支払者のPSPS (108)は支払者のユーザーのデバイス (104)からPSPAツール経由で回収要請を支払者へ伝達する。支払者は回収要請を受信し、回収要請に応えることに同意の場合は認証詳細を提供する、すなわち支払要請された金額を支払受取人へ支払ことに同意する。支払者が支払者のPSPS (108)で認証されると、認証手段（図示されていない）を利用した取引が実行される。認証とは、UPI PIN、生体認証、虹彩認識等を含む。認証情報の一つを支払者が入力して取引を続行する。支払者のユーザーのデバイス(104)から支払者PSPAツールと支払者のPSPS (108)によって登録した支払者の銀行詳細はUPI (100)サーバへ通信される(ステップ4)。以上で、UPI (100)は各自のVPAのID/固有のIDに基づいて支払者と支払受取人の銀行詳細をゲットした。UPI (100)は銀行詳細を使用して送金銀行(110) (すなわち、支払者の銀行)に連絡し、所要金額を借方記帳(ステップ5と6)し、次に受益者銀行(112) (すなわち、支払受取人の銀行)に連絡してこの金額を貸方記帳して取引を完了する(ステップ7と8)。取引の完了後、UPI (100)は取引完了情報を支払受取人のユーザーのデバイス(102)と支払者のユーザーのデバイス(104)がそれぞれアクセスしている支払受取人(ステップ9a、9b、10)と支払者のPSPAツールへ送り、ここに各自のPSPAツールを経由して取引詳細ポップアップが各ユーザーのデバイスに表示される。 
【００４９】
回収/プル要請の取引の流れは以下の手順からなる(図3):
ステップ301 - 支払受取人は支払受取人のユーザーのデバイス(102)でPSPAツールを利用して取引を開始する。
ステップ302 - 支払受取人のユーザーのデバイス(102が回収要請を支払受取人のPSPS (106)へ開始する。
ステップ303 - 支払受取人のPSPS (106)が支払受取人詳細を確認し、第1要因認証が正しいことを確認する。
ステップ304 - 支払受取人のPSPS (106)が回収要請をUPI (100)に送る。
ステップ305 - UPI (100)が支払者のアドレスを次の二段階で解決する:
ａ．アドレスにグローバル識別子(例えば、携帯番号、固有のID、口座番号等)がある場合は、PSPSがUPI (100)に携帯番号やAadhaar番号あるいは口座番号とIFSCに基づいてAPIを通して保留中メッセージを要請する。
ｂ．アドレスが支払者のPSPS (108)によって提供された仮想アドレスであれば、UPI (100)はアドレス変換を支払者のPSPS (108)に要請する。
ステップ306 - ステップ305bの場合は、支払者のPSPS (108)が支払者への通知を送り、支払者は自分の端末に設定したルールに基づいて要請を受諾か拒絶する。
ステップ307 - ステップ305bの場合は、回収要請を受諾すると、支払者のPSPS (108)が支払者のユーザーのデバイス(104)に認証情報を入力するように要請する。支払者は支払者のユーザーのデバイス(104)に認証情報を提供する。
ステップ308 - ステップ305bの場合は、支払者のPSPS (108)に支払者詳細が埋まり、UPI (100)に応答する。
ステップ309 - UPI (100)は借方記帳の要請を引落口座プロバイダー(110)に送る。
ステップ310 - 口座プロバイダーは提供された情報に基づいて支払者を認証する。
ステップ311 - 口座プロバイダーが支払者の口座から引き落とす。
ステップ312 - 口座プロバイダーがUPI (100)に引落応答を送る。
ステップ313 - UPI (100)が入金要請を入金口座プロバイダー(112)に送る。
ステップ314 - 口座プロバイダーが支払受取人の詳細に基づいてこの口座に貸方記帳する。
ステップ315 - 口座プロバイダーがUPI (100)へ入金の応答を送る。
ステップ316 - UPI (100)が支払者のPSPS (108)に確認応答を送る。
ステップ317 - UPI (100)が支払受取人のPSPS (106)に支払応答を送る。
ステップ318 - 支払受取人のPSPS (106)が支払受取人に通知する。
【００５０】
支払者が支払受取人に送信する場合(すなわち金銭プッシュか支払取引あるいはプッシュ要請) (図2B)、支払者は支払者のユーザーのデバイス(104)でPSPAツールしてにアクセスして 支払受取人の認証済みVPAを支払者が支払受取人へ入金すべき金額とともに提供するよう操作する(ステップ1)。この場合の一実施形態において支払者に対して表示される画面を図8Cに示す。この画面はプッシュ/支払要請(すなわち図8Bにおける「VPAに支払」)開始時点に表示される。VPAに支払では、利用者のVPA/支払者のVPAは、この人のPSPSの詳細がPSPAツールに登録済みなので自動で記入されている。次に、支払者は支払受取人のVPA、回収金額、ある場合は備考を入力する。支払要請が送信されると、支払者が支払者のPSPS (108)に認証され、認証手段を利用して取引を実行する。認証手段にはUPI PIN、生体認証、虹彩認識等が含まれる。認証情報の一つを支払者が入力する。支払者の認証は支払者の登録済み銀行詳細と支払受取人のVPAとともに、支払者のPSPS (108)を経由してUPI (100)へ送られる(ステップ2)。UPI (100)は支払受取人のVPAの末尾コードに基づいて支払受取人のPSPS (106)を識別し、要請を支払受取人のPSPS (106)に送る(ステップ3)。支払受取人のPSPS (106)は支払受取人のユーザーのデバイス (102)を経由して支払受取人のPSPS (106)にインストールされている支払受取人PSPAツールに登録済みの銀行詳細を認証し、銀行詳細をUPI (100)サーバへ返す(ステップ4)。以上で、UPI (100)は各自のVPAのID/固有のIDに基づいて支払者と支払受取人の銀行詳細をゲットした。UPI (100)は銀行詳細を使用して送金者の銀行(110) (すなわち、支払者の銀行)と通信し、必要金額(ステップ5、6)を借方記帳し、次に受益者銀行(112)(すなわち、支払受取人の銀行)と通信し、同額を貸方記帳して取引を完了する(ステップ7、8)。取引完了後は、UPI (100)が取引成功の情報を支払者(ステップ9a、9b、10)と支払受取人のPSPAツールに送る、このツールには支払者のユーザーのデバイス(104)と支払受取人のユーザーのデバイス(102)からアクセスされ、ここに取引詳細が対応するPSPAツールによりユーザーのデバイスのディスプレイにポップアップする。
【００５１】
UPI (100)は、 全金融および金融外取引が一日の最後に完了すると、EPS (1000)に登録されている全PSPSの間で実行された全支払取引を決済する。一実施形態において、支払者は支払受取人のPSPAツールと異なるPSPAツールを利用する。もう一つの実施形態において、支払者は支払受取人と同じPSPAツールを使用する。
【００５２】
支払/プッシュ要請の取引の流れは以下の手順を含む(図4):
ステップ401 - 支払者はユーザーのデバイス(104)にインストールしたPSPAツールで取引を開始する。
ステップ402 - 支払者は支払者のユーザーのデバイス(104)に認証情報を入力する。
ステップ403 - 支払者のユーザーのデバイス(104)は支払要請を支払者のPSPS(108)に対して開始する。
ステップ404 - 支払者のPSPS (108)は支払者詳細を確認し、第1要因認証を有効化する。
ステップ405 - 支払者のPSPS (108)は支払要請をUPI (100)に送る。
ステップ406 - UPI (100)は支払受取人のアドレスを二つの方法で解決する
ａ．アドレスにグローバル識別子(例えば、携帯番号、固有のID、口座番号等)が含まれる場合は、支払受取人のアドレスはUPI (100)のセントラル・マッパーで解決される。
ｂ．アドレスに支払受取人のPSPS (106)が提供した仮想アドレスが含まれる場合は、UPI (100)はアドレス変換要請を支払受取人のPSPS (106)に送る。
ステップ407 - 406bの場合は、支払受取人のPSPS (106)は自分の端末に設定したルールに基づいて要請を受諾か拒絶する。
ステップ408 - 406bの場合は、支払要請を受諾すると、支払受取人のPSPS (106)に支払受取人詳細が埋まり、UPI (100)に応答する。
ステップ409 - UPI (100)は借方記帳要請を引落口座プロバイダー(114)へ送る。
ステップ410 - 口座プロバイダーは提供された情報に基づいて支払者を認証する。
ステップ411 - 口座プロバイダーが支払者の口座から引き落とす。
ステップ412 - 口座プロバイダーがUPI (100)に引落応答を送る。
ステップ413 - UPI (100)が入金要請を入金口座プロバイダー(112)に送る。
ステップ414 - 口座プロバイダーが支払受取人の詳細に基づいてこの口座に貸方記帳する。
ステップ415 - 口座プロバイダーがUPI (100)へ入金の応答を送る。
ステップ416 - UPI (100)は支払受取人のPSPS (106)に確認応答を送る。
ステップ417 - UPI (100)は支払応答を支払者のPSPS (108)に送る。 
ステップ418 - 支払者のPSPS (108)が支払者に通知する。 
【００５３】
異なる認証方法をEPS (1000)が使用する。一実施形態において、EPS (1000)が下表1に示す1-クリック 2-要因認証方法を使用する: 
【００５４】
【表１】
2019522833.tif 000003
【００５５】
この実施形態に置いて、各PSPS (1004)は2要因認証用に構成された認証モジュール (図示されていない)から構成される。認証モジュールは第1要因認証要素と第2要因認証要素から成る。第1要因認証要素は登録前固有番号を受け取り、PSPS (1004)に登録された利用者を形成し、ローカルストレージ・デバイス(1004a)に保存された受諾済みの登録前固有番号と登録ユーザーのユーザー情報データを照合することで登録ユーザーを確認し、登録ユーザー デバイス(1006)と関連付け、この際第1要因認証を提供する。登録ユーザーのUPI PINないし生体認証入力を受諾するように構成された第2要因認証要素は、受諾済みUPI PINないし生体認証の入力とユーザー情報データを照合することによって登録ユーザーを認証し、この際第2要因認証を提供する。
【００５６】
表1を参照すると、第1要因認証に関しては、PSPAツールに登録する中に、暗号化SMSが利用者のデバイス/モバイルから開始され、利用者登録済みのPSPSに転送される。PSPSはユーザーのデバイス（この際固有番号は利用者登録中にPSPSにユーザー情報データとして事前登録されている)の固有番号(携帯番号かIMEI等)を確認し、固有番号とユーザーアカウントを結びつける。顧客がモバイル・バンキングに登録してあれば、自分のUPI PINか生体認証を第2要因認証で使用する。顧客がモバイル・バンキングに登録を希望する場合は、デビットカードの最後6桁とデビットカードの有効期限日、発行人が発行したOTPとともに使用してまたは他の同様の適切なプロセスを使用してUPI PINを設定するそれ以降の取引でデバイスの指紋をPSPSによる認証に使用可能である。第2要因認証中に、 UPI PINか生体認証は利用者を認証するためにその後の取引で発行人が認証する利用者に対して要請される。
【００５７】
付帯図面の図5はタクシー運転手と乗客の間の支払取引の流れ図を示す。例示的実施形態において、本発明のシステムをタクシー運転手が利用して乗客/顧客のために提供したサービスの運賃を回収する。タクシーが目的地点に着くと、タクシー運転手は(この場合、支払受取人)が自分のデバイス(502)を使用して本発明のシステムにより乗客から支払をプル/回収(タクシー運賃)する。乗客はタクシー運転手のユーザーのデバイス(502)にインストールした支払受取人のPSPAツールに回収要請とともにタクシー運転手が入力するVPAを呈示する。VPAとタクシー運転手のアカウント詳細がタクシー運転手の(支払受取人の)PSPS (506) によってUPI (500)に提供される(ステップ51)。UPI (500)はVPAに基づいて乗客の(支払者の) PSPS/銀行を識別し、回収要請を乗客のPSPS (508)に送る(ステップ52)。乗客のPSPS (508)は回収要請の通知を乗客のユーザーのデバイス(504)にインストールされたPSPAツールに送り(ステップ53)、この要請に基づいて乗客は認証情報を入力して回収要請(ステップ54)を受諾する。一実施形態において, 認証は乗客のユーザーのデバイス(504)にインストールしてあるPSPAツールを使用してUPI PINを入力することで行われる。乗客(支払受取人)の確認を受信すると、乗客のPSPS (508)が乗客詳細を有効にし、支払関連の詳細をUPI (500)に送り、乗客の(支払者の)銀行口座から引き落とす(ステップ55)。次に、引落要請が乗客のPSPS/銀行(送金者)(510)へ送られ、要請金額がUPI (500)によって乗客の銀行(送金者)(510)から引き落とされる(ステップ56、57)。次に、UPI (500)は入金要請をタクシー運転手のPSPS/銀行(受益者) (512)に送り、必要金額(ステップ58)を貸方記帳し、入金成功メッセージをタクシー運転手のPSPS/銀行(受益者) (512)から受信する(ステップ59)。次に、取引成功の確認はUPI (500)から乗客(支払者) (ステップ50a)とタクシー運転手(支払受取人) (50b)へ各自のPSPAツールによって伝達される。
【００５８】
本発明のEPS (1000)は配達人(食品配達、衣類配達等)が利用して配達時現金払い(COD)の問題を解消することが可能となる。ここでは1クリック2要因認証を提供するものであって、取引はUPI PINのみ入力することによって認証可能である。
【００５９】
図6は送信元(支払者)がプッシュ支払のために使用するEPS (1000)を利用した送金支払取引の流れ図である。送信元は自分の ユーザーデバイス(604)にレシーバーの(支払受取人の) VPAと発行銀行のUPI PIN、さらにレシーバーの銀行へプッシュする金額から成る支払要請を入力する(ステップ61)。次に、送信元のアカウント詳細、UPI PIN、レシーバーのVPAがPSPAツール(ステップ62)により送信元のPSPS (608)からUPI (600)へ送信される。UPI (600)はVPAに基づいて乗客の(支払者の) PSPS/銀行を識別し、回収要請を乗客のPSPS (606)に送る(ステップ63)。レシーバーのPSPS (606)は受益者アドレス(すなわち支払受取人の金融取引用アドレス)を返す(ステップ64)。この応答に基づいて、UPI (600)が送信元の(支払者の)アカウント詳細とPIN、引落要請を送信元のPSPS/銀行(610)へ送り(ステップ65)、成功した引落応答を受ける(ステップ66)。引落応答を受けると、UPI (600)が入金要請をレシーバーの/支払受取人のPSPS/銀行(612)へ送信し(ステップ67)、成功した入金の応答を受ける(ステップ68)。次に、取引成功確認がレシーバーの/支払受取人のPSPS (ステップ69)へ、さらに、送信元へ送信元のPSPS (608)とユーザーのデバイス (604)を通して送られる(ステップ60)。
【００６０】
支払者/送信元/商人と支払受取人/レシーバー/顧客は同じPSPSの利用者であってよい。図7は同じPSPSに登録した顧客と商人間の三者間商取引の流れ図を示す。顧客(710)は自分のデバイス(702)にインストールしたPSPAツールで本発明のシステムのUPI (700)に登録される。顧客と商人のPSPS (704)は同じなので、商人と顧客の仮想アドレスはPSPS (704)から利用可能である。PSPAツールから要請(プッシュかプル)されると、要請は（この場合は）商人と顧客に共通するPSPS (704)へ送られる(ステップ71)。一実施形態において、要請には参照ID (利用者のVPA)、金額、商人IDが含まれる。仮想アドレスはPSPS (704)において利用可能であるので、仮想アドレスの基準となっている金融取引アドレスがUPI (700)へPSPS (704)によって提供される(ステップ72)。次に、UPI (700)は引落要請を発行人/支払者のPSPS/銀行(706)へ送り(ステップ73)、プッシュかプル要請に基づく引落応答を受ける(ステップ74)。次に、UPI (700)は入金要請を受取人/支払受取人のPSPS/銀行(708)へ送り(ステップ75)、入金成功応答を受取人/支払受取人のPSPS/銀行(708)から受け取る(ステップ76)。UPI (700)は取引成功を利用者にユーザーのデバイス(702)からPSPS (704)を介して送る(ステップ77、78)。
【００６１】
本発明は複数ユーザー間の決済を容易にする電子支払方法を提供する。この方法は以下の手順から成る：
・メインストレージ・デバイスへの保存、所定ルール
・処理用プロセッサによる処理、システム操作コマンドの取得用所定ルール
・利用者を電子支払システム(EPS) (1000)に登録するように構成した複数の支払サービスプロバイダー システム(PSPS)に登録し、各PSPSは以下の手順で構成される: 
・PSPSに登録済み利用者に関連するユーザー情報データをローカルストレージ・デバイスへに保存する 
・少なくとも1つの検索表により顧客が入力するデータ、ユーザー情報データ、登録ユーザーの照合を可能にし、
・PSPSサーバに提供する
・複数のユーザーのデバイスの各ユーザーのデバイスをユーザー情報データの一環として登録する登録ユーザーの1人と関連付ける
・複数のPSPAツールの各支払サービスプロバイダー アプリケーション (PSPA)ツールをEPSに登録済みであって、登録ユーザーがPSPAツールと関連付けられたPSPSに登録されているか否かに関わらず登録ユーザーのデバイスにダウンロードして保存可能な要素を有し、さらに、各PSPAツールによって登録ユーザーからの支払要請関連の取引データ信号生成と受領を可能にするPSPSのサーバに関連づけ、ホストし、要請に基づく登録ユーザーの口座に貸方記帳や借方記帳を行い、各PSPAツールのダウンロードして保存可能な要素は以下の手順からなる:
・登録モジュールによって、PSPAツールと一意対応に関連付けられた登録済みPSPSにユーザーデバイスの登録を許可し 
・仮想支払アドレス(VPA)生成モジュールにより登録ユーザーは、登録ユーザーが登録されているPSPSの識別を含む固有のVPAを作成することができ、さらにユーザーデバイスが登録ユーザーのユーザー情報データの一環として固有のVPAをユーザーが登録済みのPSPSのローカルストレージ・デバイスに送信することを可能に 
し、
・統一支払インターフェース(UPI)によって、PSPSをEPSに登録することを容易ならしめ、同一か異なるPSPSにおけるかを問わず取引データ信号の転送をPSPS間で選択的に制御して実行しやすくし、登録ユーザー間の支払を実行しやすくする、ここにUPIは以下のステップから成る： 
・複数のPSPSと共同で定期的に貸方借方取引残高を校合し、登録済みPSPS間の正味貸方借方残高明細を生成する決済モジュール(100a)から成る。
【００６２】
この方法は以下の手順から成る：
・登録ユーザー デバイスがPSPAツール経由で送った支払要請に関連する取引データ信号をレシーバーが受信、ここに、各要請は第1登録ユーザーのVPA、第2登録ユーザーのVPA、取引額から構成する
・パーサーがパース処理後の信号を取得するために取引データ信号をパースする
・パース処理後の信号から第1登録ユーザーのPSPSと第2登録ユーザーのPSPSに関連する情報を抽出要素識別子で抽出して識別する 
・転送要素が取引データ信号を識別された対応するPSPSに転送し、パースしたデータ信号の内容に応じて第1登録ユーザーと第2登録ユーザーの口座間での貸方記帳ないし借方記帳を可能にする。
【００６３】
さらに、各PSPSは認証モジュールによる2要因認証ステップから成る。2要因認証の提供ステップは以下の手順で構成する: 
・第1要因認証要素が登録前固有番号を受け取り、PSPSに登録された利用者を形成し、ローカルストレージ・デバイスに保存された受諾済みの登録前固有番号と登録ユーザーのユーザー情報データを照合することで登録ユーザーを確認し、登録ユーザー デバイスと関連付け、この際第1要因認証を提供し、
・第2要因認証要素が登録ユーザーのUPI PINないし生体認証入力を受諾し、受諾済みUPI PINないし生体認証の入力とユーザー情報データを照合することによって登録ユーザーを認証し、これによって第2要因認証を提供する。
【００６４】
顧客と商人が同じPSPSを利用していても両者は対応するユーザーのデバイスにインストールされた複数の異なるPSPAツールを有することができる。一例において、PSPSソフトウェア 開発キット(SDK)が商人のPSPAツールに埋め込まれており、異なるPSPAツールを顧客が利用する。このような場合に、商人が意志表示/要請し、顧客のユーザーのデバイスにインストールされている全UPI PSPAツールが顧客に表示され、商人のものと同じPSPAツールを選択する。図7に示す通り、この例においても、商人と顧客ともに仮想アドレスがPSPSで利用可能であり、取引は前記の通りの方法で実行される。
【００６５】
本発明が提供するEPS (1000)は物理的店舗/商人が、野菜売店支払、生活用品支払、タクシー/自動車/バス/列車/航空運賃支払、食堂/商店/給油支払、教育機関への授業料支払、旅行中の道路使用料支払、牛乳販売店/新聞販売店への支払、信託/寺院/救済資金/NGOへの寄付、モールでの支払等を含む取引のために使用することが可能である。EPS (1000)を電気、水、電話等のユーティリティー、デビットカード等の支払、アパート維持費請求・支払、学費の請求・支払、保険料の支払、ローン分割支払、自動車ローン月賦等を含む支払に使用することも可能である。
【００６６】
さらに, オンライン商人はEPS (1000)をCOD支払、In-App支払、オンライントレード、「スキャン&支払」を利用した新聞広告からのモバイルリチャージ、 チェックアウト後のUPIによるEコマース(回収/プル) 支払、映画入場券の予約等を含むEコマース取引にも利用できる。さらに送金(プッシュとプル両方)用ピアツーピア取引、友人等への支払、友人との請求書共同負担、運転手の給与支払、Aadhaar/携帯番号を利用する別銀行口座への国内送金にも利用できる。
【００６７】
技術進歩
上記に説明された本発明は以下の電子支払システムの実現に限らずこれを含む数個の技術進歩を有する：
・ユーザーのデバイスを使用して簡単に送金や金銭の受取が可能
・統一支払インターフェース(UPI)を提供する
・利用者は対象人物/法人口座から支払プル/回収ができる
・支払者、支払受取人ともに簡単に使える
・相手の銀行情報と銀行アカウント詳細を必ずしも必要とせず、支払者と支払受取人間の支払取引を可能にする 
・利用者が仮想支払アドレスを利用して送金と金銭受取できる 
・一意の/固有識別子に基づくセキュア支払を提供する
・顧客の仮想アドレスをカード等に保存するリスクがなくなる
・クレジットカード/デビットカードを持たない顧客でも利用できる
・e-コマース、m-コマース用ともに適格
・COD回収の問題を解決する
・In-App支払(IAP)を提供する
・仮想アドレスのみを共有しその他の機密情報を共有する必要がないプライバシー
・マルチプルユーティリティー-現金着払い/請求書共同負担/商取引支払/送金を可能にする
・UPI PINか生体認証あるいはUIDまたは虹彩その他の手段のみの入力で取引を許可する
・各種インターフェースに対応する、ここに支払要請をウェブインターフェースで生成し、モバイル インターフェース(App)で許可可能。
【００６８】
本発明の実施例ならびに様々な特長および優位性の詳細を限定することのない実施例を参照することによって以下に説明する。確立している既存のコンポーネントならびに処理技術についての説明は省略し、本発明の実施例についての理解を不要に困難にしないようにした。本発明に使用されている例は単に本発明の実施例を実用化可能にする方法の理解を容易にし、この分野の技能を持つ者が本発明の実施例を実施することを可能にすることのみを目的としている。従って、例によって本発明の実施例の範囲を限定するものと解釈されてはならない。
【００６９】
前記の具体的実施例は本発明の実施例が持つ一般的性質をじゅうぶんに明らかにしているので、現状の知識を適用することにより、前記の一般的概念から乖離することなく く前記の具体的実施形態を異なる用途のために変更および/または適合することができ、従って、適合や変更は本発明の実施形態と同等の物としての意味およびその範囲で理解されることが意図されるべきであり、意図されている。本明細書に使用されている句節の用法や用語は説明目的のためであって限定するために使用されてはいない。従って、本明細書に記載された実施例は優先的実施例に基いて説明されていると同時に、同分野の技能を有する者は本明細書に記載された実施例が本明細書で説明された実施例の意図および範囲で変更しても実践可能であることが認められる。
【図１】
2019522833.tif 000004
【図２】
2019522833.tif 000005
【図３】
2019522833.tif 000006
【図４】
2019522833.tif 000007
【図５】
2019522833.tif 000008
【図６】
2019522833.tif 000009
【図７】
2019522833.tif 000010
【国際調査報告】
2019522833.tif 000011