ホーム > 特許ランキング > ＯＢＯＯＫ Ｉｎｃ．
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2023-12-01
(45)【発行日】2023-12-11
(54)【発明の名称】マルチチャンネル決済方法及びシステム
(51)【国際特許分類】
G06Q 20/22 20120101AFI20231204BHJP
【ＦＩ】
G06Q20/22
【請求項の数】
40
(21)【出願番号】P 2022192715
(22)【出願日】2022-12-01
【審査請求日】2022-12-01
(31)【優先権主張番号】111142512
(32)【優先日】2022-11-08
(33)【優先権主張国・地域又は機関】TW
(73)【特許権者】
【識別番号】520173565
【氏名又は名称】オーブック・インコーポレイテッド
【氏名又は名称原語表記】ＯＢＯＯＫ Ｉｎｃ．
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】王 俊凱
(72)【発明者】
【氏名】謝 宗翰
(72)【発明者】
【氏名】陳 俊仁
(72)【発明者】
【氏名】林 柏樺
(72)【発明者】
【氏名】林 維▲徳▼
(72)【発明者】
【氏名】翁 培軒
(72)【発明者】
【氏名】王 美淑
(72)【発明者】
【氏名】林 易蓁
(72)【発明者】
【氏名】陳 振▲うぇい▼
【審査官】福田 正悟
(56)【参考文献】
【文献】国際公開第２０１９／１９４８０３（ＷＯ，Ａ１）
【文献】国際公開第２０１６／１０３３７３（ＷＯ，Ａ１）
【文献】特表２０１２－５１７０６０（ＪＰ，Ａ）
【文献】特開２０２０－３０６３１（ＪＰ，Ａ）
【文献】米国特許出願公開第２００６／０２８７９５３（ＵＳ，Ａ１）
【文献】国際公開第２０２０／２４７７７９（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
マルチチャンネル決済システムであって、当該マルチチャンネル決済システムは、国内送金、国境を越える送金、仮想クレジットカード及びデジタル通貨送金を提供するための複数の決済ゲートウェイサービスを統合し、当該マルチチャンネル決済システムは、複数の拡張機能によってモジュール化され、支払人／受取人によって発注された支払指図に従って、該支払人から該受取人への支払を実行するためのユーザインターフェイスモジュールであって、
各単一の拡張機能は、前記複数の決済ゲートウェイサービスからの決済アプリケーションプログラミングインターフェイス（ＡＰＩ）の必須情報を定義するＡＰＩ通信プロトコルを介して、前記複数の決済ゲートウェイサービスのうちの１つに接続される決済チャンネルを表し、
各拡張機能は、前記支払人／前記受取人の身元が確認されている場合に、前記支払人／前記受取人によって選択的に有効にされ、前記拡張機能は、支払請求を開始するために、前記支払人／前記受取人によって発注された前記支払指図を生成し、
前記ＡＰＩ通信プロトコルは、前記複数の決済ゲートウェイサービスの決済ＡＰＩと当該マルチチャンネル決済システムとの間で通信を行い、前記ＡＰＩ通信プロトコルは、前記決済ゲートウェイサービスと通信するために認証トークンを検証し、前記支払指図の支払送金を許可する、
ユーザインターフェイスモジュールと、
前記ユーザインターフェイスモジュールにデータを供給し、予測送金手数料、為替レート及び指定された決済ゲートウェイサービスからの前記支払指図の予測送金時間、過去の支払指図記録及びリアルタイム為替レートプロバイダのうちの少なくとも１つを特定するための手数料予測モジュールと、
前記ユーザインターフェイスモジュールと通信し、各拡張機能を最初に適用する間に、ＫＹＣ（Know Your Customer）検証サービスにより検証された前記支払人／前記受取人の身元を確認し、マネーロンダリング防止（ＡＭＬ）検証サービスにより検証された前記支払指図を確認するためのコンプライアンスモジュールと、
前記コンプライアンスモジュールから前記支払指図を受信し、前記支払指図を確認するか、拒否するか又は許可するための多重監査モジュールと、
ユーザログイン情報、前記支払人／前記受取人の身元、各拡張機能によって生成された前記支払指図及び前記多重監査モジュールによって前記支払指図が許可された場合の支払結果を記憶するデータ記憶モジュールと、
前記ユーザインターフェイスモジュール及び前記データ記憶モジュールとやりとりし、前記指定された決済ゲートウェイサービスから前記支払指図の状態を受信し、前記ユーザインターフェイスモジュールにより前記支払結果を示すための取引検証モジュールと、
を含む、マルチチャンネル決済システム。
【請求項2】
前記各拡張機能は前記マルチチャンネル決済システムに統合されており、前記決済チャンネルは、対応する拡張機能が有効にされた場合にオンにされ、前記ユーザインターフェイスモジュールは、前記各拡張機能が前記支払人／前記受取人により有効にされた場合に、該拡張機能を前記マルチチャンネル決済システムに実際にインストールすることなく、該拡張機能が処理されていることを示すために、視覚的なダミーインストールを示す、請求項１に記載のマルチチャンネル決済システム。
【請求項3】
前記各拡張機能は、その決済チャンネルをオン又はオフにする有効スイッチを有する、請求項２に記載のマルチチャンネル決済システム。
【請求項4】
前記ユーザインターフェイスモジュールは、前記複数の拡張機能を受信し、カスタマイズするためのフローティングボタンを有し、前記支払人／前記受取人は、優先決済チャンネルに対応する拡張機能を前記フローティングボタンに統合できる、請求項１に記載のマルチチャンネル決済システム。
【請求項5】
前記各拡張機能は、過去の支払指図記録、過去の支払指図の数、過去の支払指図記録の合計額、リアルタイム為替レート及び前記各拡張機能によって生成された支払指図からの送金完了通知のうちの少なくとも１つを示す短い表示ブロックを有する、請求項１に記載のマルチチャンネル決済システム。
【請求項6】
前記マルチチャンネル決済システムは、前記多重監査モジュールに配備される監査人の少なくとも１人が、前記受取人／前記支払人の財務部門の構成に対応する、リニア監査プロセス、リング署名監査プロセス又はグループ会議監査プロセスを行うことができるようにし、前記多重監査モジュールは、前記支払指図が許可されている場合に、二要素認証（２ＦＡ）又は多要素認証（ＭＦＡ）検証を有する、請求項１に記載のマルチチャンネル決済システム。
【請求項7】
前記多重監査モジュールによって行われる前記グループ会議監査プロセスは、前記支払指図及び前記予測送金手数料を確認する間に、前記多重監査モジュールを介して、監査意見を伝達及び交換するために、複数の監査人のうちのいずれにより、該複数の監査人のうちの別の監査人を指定することと、
前記多重監査モジュールを介して前記支払指図及び前記予測送金手数料を確認した後で、前記複数の監査人により、投票を行い、投票結果を得ることと、
前記複数の監査人のうちの監督監査人により、前記支払指図、前記予測送金手数料及び前記投票結果を確認した後に、前記グループ会議監査プロセスを終了するために、前記支払指図を許可するかどうかを決定することと、
を含む、請求項６に記載のマルチチャンネル決済システム。
【請求項8】
前記ユーザインターフェイスモジュール及び前記手数料予測モジュールに接続された決済推奨モジュールを含み、該決済推奨モジュールは、少なくとも１つの利用可能な支払チャンネルを、前記支払人及び前記受取人のＩＰアドレスに基づいて国籍情報を検出することと、
前記国籍情報に従って、前記少なくとも１つの利用可能な決済チャンネルを特定することと、
取引コスト又は費やされた時間に従って、前記少なくとも１つの利用可能な決済チャンネルをソートすることと、
前記ユーザインターフェイスモジュールに、前記少なくとも１つの利用可能な決済チャンネルのソート結果を前記拡張機能上に表示を許可することと、
により前記支払人／前記受取人に推奨する、請求項１に記載のマルチチャンネル決済システム。
【請求項9】
前記少なくとも１つの利用可能な決済チャンネルを特定するステップは、前記少なくとも１つの利用可能な決済チャンネルを、重み付けが異なる支配的変数及び潜在的変数に基づいて、人工知能（ＡＩ）又は機械学習（ＭＬ）アルゴリズムにより特定することを含み、前記支配的変数は国の規制、資産レベル、リスク許容度及び個人／企業の信用のうちの少なくとも１つを含み、前記潜在的変数は、ユーザの過去の選好、業界の選好及び支払目的のうちの少なくとも１つを含む、請求項８に記載のマルチチャンネル決済システム。
【請求項10】
前記支払指図は、支払人情報、受取人情報、支払額及び前記拡張機能によって表される前記決済チャンネルを含み、前記支払人情報は支払人銀行口座又は支払人電子ウォレットアドレスを含み、前記受取人情報は受取人銀行口座又は受取人電子ウォレットアドレスを含む、請求項１に記載のマルチチャンネル決済システム。
【請求項11】
前記支払請求を開始した前記支払人又は前記受取人のうちの一方は、前記指定された決済ゲートウェイサービスに対応する決済チャンネルを有効にするためのインビテーションを他方に送信する、請求項１に記載のマルチチャンネル決済システム。
【請求項12】
前記取引検証モジュールによって受信された前記支払結果は、最終為替レート、前記指定された決済ゲートウェイサービスの送金手数料、送金時間、到着時間及び前記支払指図が失敗した場合は支払失敗の原因を含む、請求項１に記載のマルチチャンネル決済システム。
【請求項13】
前記指定された決済ゲートウェイサービスは仮想クレジットカードサービスであり、前記ユーザインターフェイスモジュールの対応する拡張機能は、仮想クレジットカード番号、有効期限及びクレジット限度額を含む前記支払指図を生成し、前記取引検証モジュールは、前記仮想クレジットカードサービスから、購入時間、クレジットカード手数料、クレジットカード明細及び残高を受信する、請求項１に記載のマルチチャンネル決済システム。
【請求項14】
前記指定された決済ゲートウェイサービスがデジタル通貨決済サービスの場合、前記ユーザインターフェイスモジュールは、前記デジタル通貨決済サービスに対応する拡張機能にデジタル通貨を預け入れるか又はデジタル通貨を受け取るための電子ウォレットアドオンをさらに提供する、請求項１に記載のマルチチャンネル決済システム。
【請求項15】
前記電子ウォレットアドオンは、前記支払人／前記受取人の身元が前記コンプライアンスモジュールによって確認されている場合又は前記マルチチャンネル決済システムのシングルサインオン（ＳＳＯ）認証によって確認されている場合、前記マルチチャンネル決済システムで有効にされる、請求項１４に記載のマルチチャンネル決済システム。
【請求項16】
前記多重監査モジュールは、二要素認証（２ＦＡ）又は多要素認証（ＭＦＡ）検証をチェックすることにより、前記電子ウォレットアドオンから前記デジタル通貨決済サービスに対応する拡張機能への支払指図を許可する、請求項１４に記載のマルチチャンネル決済システム。
【請求項17】
前記指定された決済ゲートウェイサービスは、中央銀行デジタル通貨（ＣＢＤＣ）をサポートするデジタル通貨決済サービスであり、前記ユーザインターフェイスモジュールは、前記デジタル通貨決済サービスに対応する拡張機能にＣＢＤＣを預け入れるか又はＣＢＤＣを受け取るためのＣＢＤＣ電子ウォレットアドオンをさらに提供する、請求項１に記載のマルチチャンネル決済システム。
【請求項18】
前記指定された決済ゲートウェイサービスは、中央銀行デジタル通貨（ＣＢＤＣ）をサポートするデジタル通貨決済サービスであり、前記ユーザインターフェイスモジュールの対応する拡張機能は、仮想ＣＤＢＣカードを用いて、仮想カード番号、ＣＢＤＣ限度額及びＣＢＤＣセキュリティコードを含む支払指図を生成する、請求項１に記載のマルチチャンネル決済システム。
【請求項19】
前記ＡＰＩ通信プロトコルは、前記ユーザインターフェイスモジュールの拡張機能を前記複数の決済ゲートウェイサービスのうちの対応する１つにマッピングするための拡張可能なデータ形式を定義する、請求項１に記載のマルチチャンネル決済システム。
【請求項20】
前記各拡張機能は、前記ＫＹＣ検証サービスによる前記支払人／前記受取人の身元の確認が失敗した場合にダミーのエラーページを表示し、前記ＡＭＬ検証サービスによる前記支払指図の検証が失敗した場合に取引失敗情報を表示する、請求項１のマルチチャンネル決済システム。
【請求項21】
マルチチャンネル決済方法であって、当該マルチチャンネル決済方法は、国内送金、国境を越える送金、仮想クレジットカード及びデジタル通貨送金を提供するための複数の決済ゲートウェイサービスを統合し、当該マルチチャンネル決済方法は、複数の拡張機能によってモジュール化されるユーザインターフェイスモジュールにより、支払人／受取人によって発注された支払指図に従って、該支払人から該受取人への支払を実行することであって、
各単一の拡張機能は、前記複数の決済ゲートウェイサービスからの決済アプリケーションプログラミングインターフェイス（ＡＰＩ）の必須情報を定義するＡＰＩ通信プロトコルを介して、前記複数の決済ゲートウェイサービスのうちの１つに接続される決済チャンネルを表し、
各拡張機能は、前記支払人／前記受取人の身元が確認されている場合に、前記支払人／前記受取人によって選択的に有効にされ、前記拡張機能は、支払請求を開始するために、前記支払人／前記受取人によって発注された前記支払指図を生成し、
前記ＡＰＩ通信プロトコルは、前記複数の決済ゲートウェイサービスの決済ＡＰＩと前記複数の拡張機能との間で通信を行い、前記ＡＰＩ通信プロトコルは、前記決済ゲートウェイサービスと通信するために認証トークンを検証し、前記支払指図の支払送金を許可する、
ことと、
予測送金手数料、為替レート及び指定された決済ゲートウェイサービスからの前記支払指図の予測送金時間、過去の支払指図記録及びリアルタイム為替レートプロバイダのうちの少なくとも１つを特定するために、手数料予測モジュールにより、前記ユーザインターフェイスモジュールにデータを供給することと、
前記ユーザインターフェイスモジュールと通信するコンプライアンスモジュールにより、各拡張機能を最初に適用する間に、ＫＹＣ（Know Your Customer）検証サービスにより検証された前記支払人／前記受取人の身元を確認し、マネーロンダリング防止（ＡＭＬ）検証サービスにより検証された前記支払指図を確認することと、
前記支払指図を確認するか、拒否するか又は許可するために、多重監査モジュールにより、前記コンプライアンスモジュールから前記支払指図を受信することと、
データ記憶モジュールにより、ユーザログイン情報、前記支払人／前記受取人の身元、各拡張機能によって生成された前記支払指図及び前記多重監査モジュールによって前記支払指図が許可された場合の支払結果を記憶することと、
前記指定された決済ゲートウェイサービスから前記支払指図の状態を受信し、前記ユーザインターフェイスモジュールにより前記支払結果を示すために、取引検証モジュールにより、前記ユーザインターフェイスモジュール及び前記データ記憶モジュールとやりとりすることと、
を含む、マルチチャンネル決済方法。
【請求項22】
前記各拡張機能は前記ユーザインターフェイスモジュールに統合されており、前記決済チャンネルは、対応する拡張機能が有効にされた場合にオンにされ、前記ユーザインターフェイスモジュールは、前記各拡張機能が前記支払人／前記受取人により有効にされた場合に、該拡張機能を実際にインストールすることなく、該拡張機能が処理されていることを示すために、視覚的なダミーインストールを示す、請求項２１に記載のマルチチャンネル決済方法。
【請求項23】
前記各拡張機能は、その決済チャンネルをオン又はオフにする有効スイッチを有する、請求項２２に記載のマルチチャンネル決済方法。
【請求項24】
前記ユーザインターフェイスモジュールは、前記複数の拡張機能を受信し、カスタマイズするためのフローティングボタンを有し、前記支払人／前記受取人は、優先決済チャンネルに対応する拡張機能を前記フローティングボタンに統合できる、請求項２１に記載のマルチチャンネル決済方法。
【請求項25】
前記各拡張機能は、過去の支払指図記録、過去の支払指図の数、過去の支払指図記録の合計額、リアルタイム為替レート及び前記各拡張機能によって生成された支払指図からの送金完了通知のうちの少なくとも１つを示す短い表示ブロックを有する、請求項２１に記載のマルチチャンネル決済方法。
【請求項26】
前記マルチチャンネル決済方法は、前記多重監査モジュールに配備される監査人の少なくとも１人が、前記受取人／前記支払人の財務部門の構成に対応する、リニア監査プロセス、リング署名監査プロセス又はグループ会議監査プロセスを行うことができるようにし、前記多重監査モジュールは、前記支払指図が許可されている場合に、二要素認証（２ＦＡ）又は多要素認証（ＭＦＡ）検証を有する、請求項２１に記載のマルチチャンネル決済方法。
【請求項27】
前記多重監査モジュールによって行われる前記グループ会議監査プロセスは、前記支払指図及び前記予測送金手数料を確認する間に、前記多重監査モジュールを介して、監査意見を伝達及び交換するために、複数の監査人のうちのいずれにより、該複数の監査人のうちの別の監査人を指定することと、
前記支払指図及び前記予測送金手数料を確認した後で、前記複数の監査人により、投票を行い、投票結果を得ることと、
前記複数の監査人のうちの監督監査人により、前記支払指図、前記予測送金手数料及び前記投票結果を確認した後に、前記グループ会議監査プロセスを終了するために、前記支払指図を許可するかどうかを決定することと、
を含む、請求項２６に記載のマルチチャンネル決済方法。
【請求項28】
決済推奨モジュールにより、少なくとも１つの利用可能な支払チャンネルを、前記支払人及び前記受取人のＩＰアドレスに基づいて国籍情報を検出することと、
前記国籍情報に従って、前記少なくとも１つの利用可能な決済チャンネルを特定することと、
取引コスト又は費やされた時間に従って、前記少なくとも１つの利用可能な決済チャンネルをソートすることと、
前記ユーザインターフェイスモジュールに、前記少なくとも１つの利用可能な決済チャンネルのソート結果を表示することを許可することと、
により、前記支払人／前記受取人に推奨することをさらに含む、請求項２１に記載のマルチチャンネル決済方法。
【請求項29】
前記少なくとも１つの利用可能な決済チャンネルを特定するステップは、前記少なくとも１つの利用可能な決済チャンネルを、重み付けが異なる支配的変数及び潜在的変数に基づいて、人工知能（ＡＩ）又は機械学習（ＭＬ）アルゴリズムにより特定することを含み、前記支配的変数は国の規制、資産レベル、リスク許容度及び個人／企業の信用のうちの少なくとも１つを含み、前記潜在的変数は、ユーザの過去の選好、業界の選好及び支払目的のうちの少なくとも１つを含む、請求項２８に記載のマルチチャンネル決済方法。
【請求項30】
前記支払指図は、支払人情報、受取人情報、支払額及び前記拡張機能によって表される前記決済チャンネルを含み、前記支払人情報は支払人銀行口座又は支払人電子ウォレットアドレスを含み、前記受取人情報は受取人銀行口座又は受取人電子ウォレットアドレスを含む、請求項２１に記載のマルチチャンネル決済方法。
【請求項31】
前記支払請求を開始した前記支払人又は前記受取人のうちの一方は、前記指定された決済ゲートウェイサービスに対応する決済チャンネルを有効にするためのインビテーションを他方に送信する、請求項２１に記載のマルチチャンネル決済方法。
【請求項32】
前記取引検証モジュールによって受信された前記支払結果は、最終為替レート、前記指定された決済ゲートウェイサービスの送金手数料、送金時間、到着時間及び前記支払指図が失敗した場合は支払失敗の原因を含む、請求項２１に記載のマルチチャンネル決済方法。
【請求項33】
前記指定された決済ゲートウェイサービスは仮想クレジットカードサービスであり、前記ユーザインターフェイスモジュールの対応する拡張機能は、仮想クレジットカード番号、有効期限及びクレジット限度額を含む前記支払指図を生成し、前記取引検証モジュールは、前記仮想クレジットカードサービスから、購入時間、クレジットカード手数料、クレジットカード明細及び残高を受信する、請求項２１に記載のマルチチャンネル決済方法。
【請求項34】
前記指定された決済ゲートウェイサービスがデジタル通貨決済サービスの場合、前記ユーザインターフェイスモジュールは、前記デジタル通貨決済サービスに対応する拡張機能にデジタル通貨を預け入れるか又はデジタル通貨を受け取るための電子ウォレットアドオンをさらに提供する、請求項２１に記載のマルチチャンネル決済方法。
【請求項35】
前記電子ウォレットアドオンは、前記支払人／前記受取人の身元が前記コンプライアンスモジュールによって確認されている場合又はマルチチャンネル決済システムのシングルサインオン（ＳＳＯ）認証によって確認されている場合、前記ユーザインターフェイスモジュールで有効にされる、請求項３４に記載のマルチチャンネル決済方法。
【請求項36】
前記多重監査モジュールは、二要素認証（２ＦＡ）又は多要素認証（ＭＦＡ）検証をチェックすることにより、前記電子ウォレットアドオンから前記デジタル通貨決済サービスに対応する拡張機能への支払指図を許可する、請求項３４に記載のマルチチャンネル決済方法。
【請求項37】
前記指定された決済ゲートウェイサービスは、中央銀行デジタル通貨（ＣＢＤＣ）をサポートするデジタル通貨決済サービスであり、前記ユーザインターフェイスモジュールは、前記デジタル通貨決済サービスに対応する拡張機能にＣＢＤＣを預け入れるか又はＣＢＤＣを受け取るためのＣＢＤＣ電子ウォレットアドオンをさらに提供する、請求項２１に記載のマルチチャンネル決済方法。
【請求項38】
前記指定された決済ゲートウェイサービスは、中央銀行デジタル通貨（ＣＢＤＣ）をサポートするデジタル通貨決済サービスであり、前記ユーザインターフェイスモジュールの対応する拡張機能は、仮想ＣＤＢＣカードを用いて、仮想カード番号、ＣＢＤＣ限度額及びＣＢＤＣセキュリティコードを含む支払指図を生成する、請求項２１に記載のマルチチャンネル決済方法。
【請求項39】
前記ＡＰＩ通信プロトコルは、前記ユーザインターフェイスモジュールの拡張機能を前記複数の決済ゲートウェイサービスのうちの対応する１つにマッピングするための拡張可能なデータ形式を定義する、請求項２１に記載のマルチチャンネル決済方法。
【請求項40】
前記各拡張機能は、前記ＫＹＣ検証サービスによる前記支払人／前記受取人の身元の確認が失敗した場合にダミーのエラーページを表示し、前記ＡＭＬ検証サービスによる前記支払指図の検証が失敗した場合に取引失敗情報を表示する、請求項２１のマルチチャンネル決済方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、マルチチャンネル決済方法及びシステムに関し、より具体的には、注文生成、注文監査及び異種決済ゲートウェイを統合可能なマルチチャンネル決済方法及びシステムに関する。
【背景技術】
【0002】
社会経済の発展、取引形態の変化及び国境を越えた取引の普及に伴って、決済方法も急速に変化し、決済に用いられる内容もますます多様化している。消費者、商人及び供給者は多くの新しい課題に直面する必要がある。例えば、決済方法は、従来の銀行振込又はクレジットカード決済から、仮想クレジットカード、電子決済、サードパーティー決済等に変化している。決済に用いられるコンテンツは様々な国の法定通貨だけでなく、ステーブルコイン、中央銀行デジタル通貨（ＣＢＤＣ）又は他の暗号通貨も含む。
【0003】
一般に、商人は決済を行う間に、異なるプラットフォームを介して異なるサプライヤに支払う必要があり得る。国境を越えた取引を行う場合、商人は異なる決済の種類によって必要とされる異なる為替レート及び異なる手数料、取引に費やされる時間及びセキュリティの問題を考慮する必要がある。加えて、過去には、注文の審査及び実際の決済の執行のために別々のシステムがあった。同じ注文を異なるシステムに繰り返しログオンしたり、異なる監査人と財務担当者との間で紙媒体で転送したりする必要があるため、決済作業が冗長で複雑なものになる。加えて、一般的な決済プラットフォームでは、多くの場合、支払人が一方的に決済を行うこと（プッシュペイメント）しかできないか又は受取人が一方的に決済請求を行うこと（プルペイメント）しかできず、決済手続きが柔軟ではない。
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記に鑑み、煩雑な決済内容やセキュリティ上の懸念に対処することなく、ユーザが円滑に決済業務を行えるようにするために、既存の決済システムを改善する必要がある。
【0005】
したがって、本発明は、新たな決済ゲートウェイを統合する技術的な閾値を下げ、拡張機能を介して利用利便性を改善するためのマルチチャンネル決済方法及びシステムを提供する。加えて、本発明のマルチチャンネル決済方法及びシステムは、決済業務の高度な統合性、柔軟性及び安全性を有しており、従来技術の欠点を改善する。
【課題を解決するための手段】
【0006】
本発明は、マルチチャンネル決済システムを開示し、当該マルチチャンネル決済システムは、国内送金、国境を越える送金、仮想クレジットカード及びデジタル通貨送金を提供するための複数の決済ゲートウェイサービスを統合する。マルチチャンネル決済システムは、複数の拡張機能（extensions）によってモジュール化され、支払人／受取人によって発注された支払指図に従って、該支払人から該受取人への支払を実行するためのユーザインターフェイスモジュールであって、各単一の拡張機能は、前記複数の決済ゲートウェイサービスからの決済アプリケーションプログラミングインターフェイス（ＡＰＩ）の必須情報を定義するＡＰＩ通信プロトコルを介して、前記複数の決済ゲートウェイサービスのうちの１つに接続される決済チャンネルを表し、各拡張機能は、前記支払人／前記受取人の身元が確認されている場合に、前記支払人／前記受取人によって選択的に有効にされ、前記拡張機能は、支払請求を開始するために、前記支払人／前記受取人によって発注された前記支払指図を生成し、前記ＡＰＩ通信プロトコルは、前記複数の決済ゲートウェイサービスの決済ＡＰＩと当該マルチチャンネル決済システムとの間で通信するために用いられ、前記ＡＰＩ通信プロトコルは、前記決済ゲートウェイサービスと通信するために認証トークンを検証し、前記支払指図の支払送金を許可する、ユーザインターフェイスモジュールと、前記ユーザインターフェイスモジュールにデータを供給し、予測送金手数料、為替レート又は指定された決済ゲートウェイサービスからの前記支払指図の予測送金時間、過去の支払指図記録及びリアルタイム為替レートプロバイダを特定するための手数料予測モジュールと、前記ユーザインターフェイスモジュールと通信し、各拡張機能を最初に適用する間に、ＫＹＣ（Know Your Customer）検証サービスにより検証された前記支払人／前記受取人の身元を確認し、マネーロンダリング防止（ＡＭＬ）検証サービスにより検証された前記支払指図を確認するためのコンプライアンスモジュールと、前記コンプライアンスモジュールから前記支払指図を受信し、前記支払指図を確認するか、拒否するか又は許可するための多重監査モジュールと、ユーザログイン情報、前記支払人／前記受取人の身元、各拡張機能によって生成された前記支払指図及び前記多重監査モジュールによって前記支払指図が許可された場合の支払結果を記憶するデータ記憶モジュールと、前記ユーザインターフェイスモジュール及び前記データ記憶モジュールとやりとりし、前記指定された決済ゲートウェイサービスから前記支払指図の状態を受信し、前記ユーザインターフェイスモジュールにより前記支払結果を示すための取引検証モジュールと、を含む。
【0007】
本発明はマルチチャンネル決済方法をさらに開示し、当該マルチチャンネル決済方法は、国内送金、国境を越える送金、仮想クレジットカード及びデジタル通貨送金を提供するための複数の決済ゲートウェイサービスを統合する。当該マルチチャンネル決済方法は、複数の拡張機能によってモジュール化されるユーザインターフェイスモジュールにより、支払人／受取人によって発注された支払指図に従って、該支払人から該受取人への支払を実行することであって、各単一の拡張機能は、前記複数の決済ゲートウェイサービスからの決済アプリケーションプログラミングインターフェイス（ＡＰＩ）の必須情報を定義するＡＰＩ通信プロトコルを介して、前記複数の決済ゲートウェイサービスのうちの１つに接続される決済チャンネルを表し、各拡張機能は、前記支払人／前記受取人の身元が確認されている場合にのみ、前記支払人／前記受取人によって選択的に起動され且つ有効にされ、前記拡張機能は、支払請求を開始するために、前記支払人／前記受取人によって発注された前記支払指図を生成し、前記ＡＰＩ通信プロトコルは、前記複数の決済ゲートウェイサービスの決済ＡＰＩと前記複数の拡張機能との間で通信のために用いられ、前記ＡＰＩ通信プロトコルは、前記決済ゲートウェイサービスと通信するために認証トークンを検証し、前記支払指図の支払送金を許可する、ことと、予測送金手数料、為替レート又は指定された決済ゲートウェイサービスからの前記支払指図の予測送金時間、過去の支払指図記録及びリアルタイム為替レートプロバイダを特定するために、手数料予測モジュールにより、前記ユーザインターフェイスモジュールにデータを供給することと、前記ユーザインターフェイスモジュールと通信するコンプライアンスモジュールにより、各拡張機能を最初に適用する間に、ＫＹＣ（Know Your Customer）検証サービスにより検証された前記支払人／前記受取人の身元を確認し、マネーロンダリング防止（ＡＭＬ）検証サービスにより検証された前記支払指図を確認することと、前記支払指図を確認するか、拒否するか又は許可するために、多重監査モジュールにより、前記コンプライアンスモジュールから前記支払指図を受信することと、データ記憶モジュールにより、ユーザログイン情報、前記支払人／前記受取人の身元、各拡張機能によって生成された前記支払指図及び前記多重監査モジュールによって前記支払指図が許可された場合の支払結果を記憶することと、前記指定された決済ゲートウェイサービスから前記支払指図の状態を受信し、前記ユーザインターフェイスモジュールにより前記支払結果を示すために、取引検証モジュールにより、前記ユーザインターフェイスモジュール及び前記データ記憶モジュールとやりとりすることと、を含む。
【0008】
本発明のこれらの目的及びその他の目的は、様々な図及び図面に示されている好ましい実施形態に関する以下の詳細な説明を読むと、当業者にとって明らかになるに違いない。
【図面の簡単な説明】
【0009】
【発明を実施するための形態】
【0010】
説明及び下記の特許請求の範囲において特定のコンポーネントに言及するために特定の用語を用いる。ハードウェア製造業者はコンポーネントを異なる名前で呼ぶ得ることを当業者であれば理解するであろう。本願は、機能ではなく名前が異なるコンポーネントを区別することを意図していない。以下の説明及び特許請求の範囲において、「含む」及び「含まれる」という用語はオープンエンドな意味合いで用いられるため、「限定されないが含む」を意味するものと解釈すべきである。
【0011】
本発明の一実施形態に係るマルチチャンネル決済システム１の概略図である図１を参照されたい。図１に示すように、支払人１０又は受取人１２は、電子装置１４又は電子装置１６を用いて、ネットワーク接続を介してマルチチャンネル決済システム１にログインする。支払請求を開始した後で、支払人１０は、マルチチャンネル決済システム１を介して、受取人１２への支払請求に対応する支払操作を行う。電子装置１４及び電子装置１６は、それぞれパソコン、ノートパソコン、タブレットコンピュータ、携帯電話又はインターネットにアクセス可能な他の装置であり得るが、これらに限定されない。マルチチャンネル決済システム１、様々な異種の決済ゲートウェイを統合し得る。例えば、国内取引では地元の銀行間の送金業務を行い、国境を越えた取引では電信送金（電信送金）、仮想クレジットカード（ＶＣＣ）、デジタル送金に加えて、国際決済ゲートウェイサービス、暗号通貨決済サービス等の他のサードパーティー決済サービスプロバイダを用いり得る。加えて、マルチチャンネル決済システム１は、法定通貨だけでなく、ステーブルコイン（ＵＳＤコイン、ＥＵＲＯコイン、テザー、テラクラシックＵＳＤ）、中央銀行デジタル通貨（ＣＢＤＣ）等の様々なデジタルマネーの決済業務もサポートし得る。
【0012】
本発明の一実施形態に係るマルチチャンネル決済システム１のアーキテクチャの概略図である図２を参照されたい。図２に示すように、マルチチャンネル決済システム１は、ユーザインターフェイスモジュール２０、手数料予測モジュール２１、コンプライアンスモジュール２２、多重監査モジュール２３、データ記憶モジュール２４、取引検証モジュール２５及び決済推奨モジュール２６を含む。ユーザインターフェイスモジュール２０は、手数料予測モジュール２１、コンプライアンスモジュール２２、決済推奨モジュール２６及び取引検証モジュール２５に接続され、複数の拡張モジュール２００によってモジュール化され、注文の生成及び決済の実行を行う。手数料予測モジュール２１は、ユーザインターフェイスモジュール２０及び決済推奨モジュール２６に接続され、少なくとも１つの予測送金手数料、為替レート及び注文にかかる予測時間を特定するために用いられる。コンプライアンスモジュール２２は、ユーザインターフェイスモジュール２０及び多重監査モジュール２３に接続され、支払人１０又は受取人１２の身元確認のため及び注文の検証のために用いられる。多重監査モジュール２３は、コンプライアンスモジュール２２及びデータ記憶モジュール２４に接続され、注文の確認及び許可のために用いられる。データ記憶モジュール２４は、多重監査モジュール２３、取引検証モジュール２５及び決済推奨モジュール２６に接続され、マルチチャンネル決済システム１の各モジュールによって生成又は受信されたデータを記憶するために用いられる。取引検証モジュール２５は、ユーザインターフェイスモジュール２０及びデータ記憶モジュール２４に接続され、決済結果を検証するために用いられる。決済推奨モジュール２６は、手数料予測モジュール２１、ユーザインターフェイスモジュール２０及びデータ記憶モジュール２４に接続され、支払人１０又は受取人１２に決済サービスを推奨するために用いられる。この実施形態では、各モジュールは１つ以上のプログラム／アプリケーションであり得るか又はプログラム／アプリケーションの一部であってもよく、それらは同じ又は複数のプロセッサによって実行され得る。なお、図２に示す各モジュールのアーキテクチャ構成は、本発明の精神を説明するために用いられており、当業者であれば、プラットフォーム、開発ツール及び実際の状況の異なる要件に従って、マルチチャンネル決済システム１を実施するための適切な設計パターン及びアーキテクチャを採用し得る。
【0013】
本発明の実施形態では、マルチチャンネル決済システム１は、マルチチャンネル決済方法を実施し得る。例えば、支払人１０は能動的に支払請求を開始し、マルチチャンネル決済システム１を介して受取人１２に直接支払い得る。あるいは、受取人１２が支払請求を開始し、支払請求を受け取った支払人１０が支払請求を受け入れることを決し、支払を行い得るか又は支払請求を拒否して支払請求を受取人１２に返し得る。具体的には、マルチチャンネル決済システム１は図３に示すプロセス３に要約され得る。プロセス３は以下のステップを含む。
【0014】
ステップ３００：開始
【0015】
ステップ３０２：支払請求を開始した支払人１０又は受取人１２がマルチチャンネル決済システム１にログインする。
【0016】
ステップ３０４：支払請求を開始した支払人１０又は受取人１２は、マルチチャンネル決済システム１で注文を行い、該注文は指定された決済ゲートウェイを含む。
【0017】
ステップ３０６：マルチチャンネル決済システム１は、指定された決済ゲートウェイ、過去の注文記録及び支払人１０又は受取人１２の参考のためにリアルタイム為替レートに従って、注文の予測される手数料を特定する。
【0018】
ステップ３０８：マルチチャンネル決済システム１は、注文のマネーロンダリング防止（ＡＭＬ）検証を行う。
【0019】
ステップ３１０：支払人１０は、多重監査プロセスを通じて注文及び予測される手数料を確認する。
【0020】
ステップ３１２：マルチチャンネル決済システム１は、注文及び指定された決済ゲートウェイに従って、支払人１０から受取人１２への支払を実行し、注文の支払詳細を記憶する。
【0021】
ステップ３１４：終了
【0022】
プロセス３では、マルチチャンネル決済システム１のユーザ（すなわち、支払人１０又は受取人１２）は、マルチチャンネル決済システム１にログインする必要があり（ステップ３０２）、この前提でのみ支払請求を開始できる。実行されたログインが初めての場合、ユーザはアカウントを作成し、支払請求を開始する前に少なくとも１つの決済ゲートウェイを有効にする必要があり得る。各決済ゲートウェイサービスでの決済ゲートウェイの有効化には、ユーザが個人情報及び商人情報を入力する必要がある場合があり、そのような情報はＫＹＣ（Know Your Customer）検証によって検証され得る。具体的には、ユーザが金融犯罪行為に関与した場合には金融監督委員会に知らせる必要があり得る。ユーザインターフェイスモジュール２０は、ユーザの個人情報がＫＹＣ検証に合格しなかった場合には、疑わしいユーザに警告することなく、ダミーのサーバエラーページを表示し得る。支払人１０又は受取人１２によって支払請求が開始され得る。取引相手（支払人１０によって支払請求が開始した場合、取引相手は受取人１２であり、受取人１２によって支払請求が開始された場合、取引相手は支払人１０である）がマルチチャンネル決済システム１に登録されたアカウントを持っていない場合、ユーザはマルチチャンネル決済システム１を介して取引相手にアカウント作成するためのインビテーションを送付し得る。ユーザは注文を行い、決済ゲートウェイを指定することにより支払請求を開始し（ステップ３０４）、マルチチャンネル決済システム１は、指定された決済ゲートウェイ、過去の注文記録及び支払人１０又は受取人１２のリアルタイム為替レートを参考にして、注文の予測手数料を特定する（ステップ３０６）。受取人１２によって支払請求が開始される場合、マルチチャンネル決済システム１は支払人１０に支払請求を送信する。支払人１０が支払請求を受信した後に、マルチチャンネル決済システム１は、様々な国の法令に従って、注文に対してマネーロンダリング防止（ＡＭＬ）検証を行う（ステップ３０８）。ＡＭＬ検証は、リスク及び不正リストのデータベースを維持する一部の外部コンプライアンスソリューションプロバイダによって通常行われる。ＡＭＬ検証に合格した注文は多重監査プロセスに入り、ＡＭＬ検証に合格しなかった注文及びこの注文を開始したユーザはブロックされ得る。具体的には、注文がＡＭＬ検証に合格しなかった場合、ユーザインターフェイスモジュール２０は取引失敗情報ページを表示し得る。多重監査プロセスでは、複数の審査担当者が共同で支払いのための注文を許可するかどうかを判断する（ステップ３１０）。多重監査プロセスの後に、マルチチャンネル決済システム１は、注文内容及び指定された決済ゲートウェイに従って支払送金操作を行い、決済結果を支払明細として記憶する。支払明細には、支払が成功した場合には支払為替レート及び関連手数料を記録され、支払失敗の場合には原因が記憶される（ステップ３１２）。
【0023】
したがって、マルチチャンネル決済システム１がプッシュペイメント方法及びプルペイメント方法の両方のために用いられ得るため、支払人又は受取人によって支払請求が柔軟なに開始され得る。さらに、マルチチャンネル決済システム１は、決済業務の柔軟性を改善するために様々な異種の決済モードを統合し、決済の安定性及び安全性を確保するための強固な検証及び監査メカニズムを提供する。
【0024】
具体的には、ステップ３０２で、ユーザはマルチチャンネル決済システム１にログインする必要がある。ユーザは、シングルサインオン（ＳＳＯ）サービスを介して又は最初のログインのためにアカウントを作成することによりログインし得る。最初のログインのために、ユーザは、ユーザインターフェイスモジュール２０によって提供されるユーザインターフェイスにユーザ情報を入力する必要がある。ユーザ情報は、少なくとも国籍情報又は会社の所在地情報を含む必要がある。ユーザが個人ユーザの場合、ユーザ情報は、初めて決済ゲートウェイサービスを有効にする間に本人確認に関する情報を含む必要がある。ユーザが企業の場合、ユーザ情報は、最初に決済ゲートウェイサービスを有効にする間に、企業の検証に関連する情報を含む必要がある。ユーザがマルチチャンネル決済システム１に登録した後、ユーザは後続の決済プロセスのために少なくとも１つの決済ゲートウェイを有効にするために選択する必要がある。このプロセスの間、決済推奨モジュール２６は、マルチチャンネル決済システム１にログインしたユーザのインターネットプロトコルアドレス（ＩＰアドレス）からの国籍情報に従って、ユーザが選択して有効にするために利用可能な少なくとも１つの決済ゲートウェイを提供し、コンプライアンスモジュール２２はユーザ情報に対して身元検証を行う。この実施形態では、本人確認はＫＹＣ（Know Your Customer）検証を採用しているが、これに限定されない。一実施形態では、決済ゲートウェイサービスは、ブロックチェーンシステムのノードとして考えることができ、決済推奨モジュール２６は、接続可能な全てのノード（決済ゲートウェイサービス）に決済起動ｐｉｎｇをブロードキャストし、ユーザが支払要求を開始した時点で、ユーザへの決済起動コールに返答する最も速い応答を有するノードを推奨し得る。別の実施形態では、決済推奨モジュール２６は、最も短い使用時間内に送金を実行し完了する決済ゲートウェイサービスも推奨し得る。全ての登録ユーザは、決済ゲートウェイサービスを有効にするためのＫＹＣ検証に準拠する必要がある。加えて、取引相手がマルチチャンネル決済システム１にアカウントを有していない場合、アカウントの開設するインビテーションがマルチチャンネル決済システム１を介して送信され得る。アカウント作成のインビテーションの送付形態は、電子メール、ショートメッセージサービス（ＳＭＳ）、ＱＲコード（登録商標）（Quick Response Code）等を介したインターネットハイパーリンク付きのメッセージであり得るが、これに限定されるものではない。
【0025】
ユーザが選択して有効にするために利用可能な少なくとも１つの決済ゲートウェイを提供するために、マルチチャンネル決済システム１のユーザインターフェイス４０の概略図である図４Ａ及び図４Ｆを参照されたい。ユーザインターフェイス４０は、電子装置１４又は電子装置１６上のウェブブラウザを介して表示され得るか又はユーザ装置上のアプリケーションとして提示され得る。ユーザインターフェイス４０は、複数の決済ゲートウェイに対応する一連のプラグイン（plugin）、アドイン（addin）、アドオン（addon）、ウィジェット（widget）又は拡張機能の形態で構成される。一連のプラグイン、アドイン、アドオン、ウィジェット又は拡張機能のそれぞれは、決済チャンネルのアプリケーションプログラミングインターフェイス（ＡＰＩ）を実施／カプセル化し、各決済チャンネルは、対応する決済ゲートウェイを提供する決済サービスを表す。決済ゲートウェイは、限定されないが、国内銀行、国際決済サービス、ＶＣＣ等であってもよく、決済推奨モジュール２６によって推奨され得る。さらに、ユーザインターフェイスモジュール２０は、デジタル通貨決済サービス用の電子ウォレットアドオン及びＣＢＤＣをサポートするデジタル通貨決済サービス用のＣＢＤＣ電子ウォレットアドオン等のアドオンをさらに提供する。デジタル通貨は、価格を資産に固定又はペッグ可能な暗号通貨であるステーブルコインであり得る。一般的に、ステーブルコインは、米ドル又はユーロ等の法定通貨にペッグされており、法定通貨に対して価値が安定していることを保証するために、法定通貨の裏付けの価値に基づく。市場流動性のために、ステーブルコインはそのブロックチェーンに対応する様々なスマートコントラクトに基づき得る。電子ウォレットアドオンは、デジタル通貨の入出金に用いられ、デジタル通貨決済サービスに対応した拡張機能と連携する。電子ウォレットアドオンには、管理型ウォレット及び非管理型ウォレットを含むことができる。管理型ウォレットと非管理型ウォレットとの違いは、電子ウォレットアドオンから資金を移す権限を与える秘密鍵を誰が持つかの点である。管理型ウォレットの秘密鍵は、電子ウォレットアドオンのセキュリティ、バックアップ及び回復機能を課金するサードパーティーによって管理される。非管理型ウォレットの秘密鍵はユーザによって保持されるため、ユーザは秘密鍵のセキュリティ及びバックアップを管理する必要がある。また、非管理型ウォレットは、ユーザが秘密鍵を紛失した場合に回復されないことがある。電子ウォレットアドオンは、Ｅｔｈｅｒｅｕｍ ＥＲＣ－２０、Ａｌｇｏｒａｎｄ ＡＳＡ、Ａｖａｌａｎｃｈｅ ＥＲＣ－２０、Ｆｌｏｗ ＦＴ、Ｈｅｄｅｒａ ＳＤＫ、Ｓｏｌａｎａ ＳＰＬ、Ｓｔｅｌｌａｒアセット、Ｐｏｌｙｇｏｎ ＥＲC-２０／ＰｏＳ及びＴＲＯＮ ＴＲＣ－２０をサポートする。例えば、支払人は、支払人の電子ウォレットアドオンからデジタル通貨決済ゲートウェイの拡張機能に１０００米ドルのステーブルコインを入金し、拡張機能を通じて５００米ドルのステーブルコインを送金する支払指図を生成することができ、前述のように、支払指図はコンプライアンスモジュール２２によって検証され、任意で、送金の前に支払指図を許可するために多重監査モジュール２３によって許可される。ブロックチェーンがどこにあっても、マルチチャンネル決済システム１上の電子ウォレットアドオン間のステーブルコインの取引は、ブロックチェーンが電子ウォレットアドオンによってサポートされていれば、電子ウォレットアドオンのブロックチェーンアドレスによって認識されるため、支払人又は受取人は、正しいスマートコントラクトを選択することなく、デジタル資産を相互に送金できる。
【0026】
プログラム可能なデジタル通貨であり、必ずしもブロックチェーンに基づくものではない中央銀行デジタル通貨（ＣＢＤＣ）について、ＣＢＤＣの形式は発行銀行に依存する。ＣＢＤＣは、ＣＢＤＣベースの仮想カード又は特定のブロックチェーンで利用可能なデジタル通貨であり得る。ＣＢＤＣウォレットアドオンは、ＣＢＤＣのデジタル通貨の入金、使用及び引き出しに用いられ、ＣＢＤＣサービスに対応する拡張機能と連携するＣＢＤＣ電子ウォレットアドオン又はＣＢＤＣ仮想カードであり得る。なお、電子ウォレットアドオン及びＣＢＤＣウォレットアドオンは、コンプライアンスモジュール２２によってユーザの身元が確認されている場合にも有効にされ得る。
【0027】
図４Ａに示すように、ユーザインターフェイス４０は、拡張機能によって表される決済ゲートウェイ４１、４２を含む。決済推奨モジュール２６は、マルチチャンネル決済システム１にログインするユーザの国籍情報及びＩＰアドレスに従って、利用可能な決済ゲートウェイ４１及び４２を提供する。ユーザは、決済ゲートウェイに対応する拡張機能をインストール／有効にするために「参加」をクリックし得る。ユーザが決済ゲートウェイ４２を選択して有効にする場合を例にとると、ユーザは参加ボタン４２０をクリックして手順を開始する。図４Ｂに示すように、決済ゲートウェイ４２は、インストール手順を促すプログレスバー４２２を表示する。実際には、各拡張機能は、既にマルチチャンネル決済システム１に統合されている。プログレスバー４２２は、拡張機能を実際にインストールすることなく、視覚的なダミーのインストール手順をユーザに示すだけである。視覚的なダミーのインストール手順が完了すると、図４Ｃに示すように、決済ゲートウェイ４２は、有効スイッチ４２４、優先ボタン４２６及び設定ボタン４２８を示す。決済ゲートウェイ４２が有効にされていない場合、ユーザインターフェイス４０は優先ボタン４２６及び設定ボタン４２８を無効にし、ユーザは決済ゲートウェイ４２を有効にするために有効スイッチ４２４をクリックする必要があり得る。次に、決済ゲートウェイ４２を有効にした後、ユーザインターフェイス４０は、図４Ｄに示すように、設定ボタン４２８を有効にする。ユーザは、有効にされた決済ゲートウェイ４２の設定ボタン４２８をクリックして、ＫＹＣ検証を進めるための銀行口座、電子ウォレット等の設定といった、決済ゲートウェイサービスの起動操作を行い得る。図４Ｅに示すように、ＫＹＣ検証に合格し、決済ゲートウェイ４２が起動されると、ユーザインターフェイス４０の優先ボタン４２６が有効になり、これは決済ゲートウェイの決済操作を行うための優先設定であり、ユーザは優先的な支払い順序を設定し得る。さらに、決済ゲートウェイ４２（拡張機能）は、過去の注文記録、過去の注文の数量、過去の注文記録の合計額、リアルタイムの為替レート、支払い完了の通知等の情報を表示するための簡単な表示ブロック４３０をさらに含む。決済ゲートウェイ４２が有効になった後、ユーザは図４Ｆに示すように、有効スイッチ４２４を介していつでも決済ゲートウェイ４２を再び無効にし得る。なお、有効スイッチ４２４をスライダーボタンの一形態として図示しているが、トグルボタン、チェックボタン等の任意の種類のスイッチも本発明に適している。
【0028】
決済ゲートウェイの起動操作は、金融口座（例えば、銀行口座、クレジットカード情報、電子ウォレット等）の設定、デジタル証明書／認証のインポート、検証手順の実行、決済ゲートウェイに対応する使用通貨の設定等を伴い、決済チャンネル毎に設定の詳細が異なる。本発明の実施形態では、ユーザインターフェイスモジュール２０は、各決済サービスプロバイダによって提供される決済ゲートウェイのアプリケーションプログラミングインターフェイス（ＡＰＩ）を独立した拡張機能に統合するためのアプリケーションプログラミングインターフェイス通信プロトコル（API communication Protocol）を含む。ＡＰＩ通信プロトコル８０は、複数の決済ゲートウェイサービスの決済ＡＰＩとマルチチャンネル決済システムの拡張機能との間での通信のための決済ＡＰＩの必須情報を定義する。ＡＰＩ通信プロトコル８０は、支払指図に従って支払送金を承認するために、指定された決済ゲートウェイサービスからユーザが取得する認証トークンを検証する。したがって、図４Ａ～図４Ｆに示すように、ユーザは都合よく決済ゲートウェイを有効にし、必要に応じて決済ゲートウェイを有効／無効にし得る。
【0029】
さらに、ユーザインターフェイスモジュール２０は、決済ゲートウェイに素早くアクセスするためのフローティングボタンを含む。ユーザインターフェイス１００の概略図である図１０Ａ及び図１０Ｂを参照されたい。ユーザインターフェイス１００は、電子装置１４又は電子装置１６上のウェブブラウザを介して表示され得るか又はユーザ装置上のアプリケーションとして提示され得る。ユーザインターフェイス１００は、フローティングボタン１０２と、ユーザのよって制御されるカーソル１０１とを含む。カーソル１０１はフローティングボタン１０２から離れているが、フローティングボタン１０２はアイコンの形態であり、ユーザインターフェイス１００の隅に位置する。カーソル１０１がフローティングボタン１０２の上を動かされる間、フローティングボタン１０２はフローティングボタン１０３～１０６を示すために展開する。フローティングボタン１０３～１０６のそれぞれは、図４Ａ～図４Ｆに示す決済ゲートウェイ４１、４２等の決済ゲートウェイに接続されている。ユーザは、限定されないが、フローティングボタン１０３及び１０４に優先拡張機能（決済ゲートウェイ）、フローティングボタン１０５に一般的に用いられる決済ゲートウェイ、フローティングボタン１０６のためにマルチチャンネル決済システムによって推奨される決済ゲートウェイを設定し得る。フローティングボタン１０２を介して、ユーザは決済ゲートウェイを設定するか又は新たな注文を効率的に開始し得る。
【0030】
プロセス３によれば、ステップ３０４で、支払人１０又は受取人１２は、マルチチャンネル決済システム１で支払請求を開始し得る。例えば、支払人１０（例えば、商人）は、受取人１２（例えば、サプライヤ）への支払いを事前に行うために注文を生成し、あるいは、受取人１２は、支払人１０に支払いを要求するための注文を生成し得る。マルチチャンネル決済システム１にログインした後、ユーザはユーザインターフェイスモジュール２０を介して支払請求を開始し得る。支払請求を開始するには、ユーザは決済ゲートウェイの指定及び優先支払い注文セットを要求する。決済ゲートウェイは、決済推奨モジュール２６からの推奨に従って指定され得る。注文は、支払人情報、受取人情報、支払額及び決済ゲートウェイ（拡張機能によって実施／カプセル化される）によって提供される支払チャンネルを少なくとも含む。支払人及び受取人情報は、決済ゲートウェイサービスに関連する。例えば、決済ゲートウェイサービスが仮想カードサービスの場合、注文内容は仮想クレジットカード番号、有効期限及び与信限度額を含む。加えて、取引検証モジュール２５によって仮想カードサービスから受信された決済結果は、購入時間、クレジットカード手数料、クレジットカード明細及び仮想カードサービスからの残高を含む。決済ゲートウェイサービスがデジタル通貨決済サービスの場合、注文内容は支払人及び受取人の電子ウォレットアドレス、支払額及び取引手数料（ガス料金）を含む。決済ゲートウェイサービスが国内又は国境を超えた送金サービスの場合、注文内容は、支払人及び受取人の銀行口座、支払額及び（受取人の現地銀行の法律に基づいて必要な場合）送金目的を含む。決済ゲートウェイサービスがＣＢＤＣをサポートするデジタル通貨支払サービスの場合、注文内容は、支払人及び受取人のＣＢＤＣ電子ウォレットアドレス、支払人及び受取人のＣＢＤＣサポート銀行口座及び支払額を含み得る。さらに、ＣＢＤＣの支払が仮想ＣＢＤＣカードの形式の場合、注文は仮想カード番号、ＣＢＤＣ限度額、有効期限及びＣＢＤＣセキュリティコードを含み得る。
【0031】
すべての取引の支払人及び受取人は、コンプライアンスモジュール２２のＫＹＣ検証によって検証される必要がある。取引相手が指定された決済ゲートウェイを有効にしていない場合、取引を開始した側は、マルチチャンネル決済システム１を介して、指定された決済ゲートウェイを有効にするためのインビテーションを取引相手の他方に送信し得る。指定された決済ゲートウェイを有効にするためのインビテーションは、限定されないが、電子メール、ＳＭＳ、アプリケーションのプッシュ通知等を介して送信されるインターネットハイパーリンク付のメッセージであり得る。
【0032】
一実施形態では、決済推奨モジュール２６は、現在利用可能な決済ゲートウェイ（拡張機能の形式）を特定するために、マルチチャンネル決済システム１にログインする支払人１０及び受取人１２の国籍情報及び支払人１０と受取人１２のＩＰアドレスにしたがって、決済ゲートウェイを推奨する。一実施形態では、決済推奨モジュール２６は、人工知能（ＡＩ）アルゴリズムにしたがって利用可能な決済ゲートウェイを推奨するＡＩモデル２６０又は機械学習（ＭＬ）モデルをさらに含む。データ記憶モジュール２４の先行注文記録及び取引詳細にアクセスすることにより、ＡＩモデル２６０は、支払目的、ユーザの過去の選好及び支払の成否の理由等の情報を取得し得る。加えて、ＡＩアルゴリズムは、重みが異なる支配的変数及び潜在的変数に基づいて推奨をさらに決定し得る。支配的変数は、国の規制、資産レベル、リスク許容度及び個人／企業の信用のうちの少なくとも１つを含み、潜在的変数は、ユーザの過去の選好、業界の選好及び支払目的のうちの少なくとも１つを含む。支配的変数及び潜在的変数は、決済ゲートウェイを推奨するためのＡＩモデルの訓練機能として用いられる。一実施形態では、決済推奨モジュール２６は、手数料予測モジュール２１を介して各決済ゲートウェイの予測された手数料をさらに取得し、それにしたがって決済ゲートウェイを推奨し得る。別の実施形態では、決済推奨モジュール２６は、各決済ゲートウェイが支払を完了する推定所要時間を、手数料予測モジュール２１を介してさらに取得し、それにしたがって決済ゲートウェイを推奨し得る。決済推奨モジュール２６は、限定されないが、取引コスト又は所要時間をソートの基準として推奨される決済ゲートウェイをソートする。決済推奨モジュール２６は、ユーザがマルチチャンネル決済システム１にログインしたとき又は新たな支払指図が開始された場合、推奨される決済ゲートウェイのソートされた結果を表示する許可をユーザインターフェイスモジュール２０に与える。
【0033】
プロセス３によれば、ステップ３０６で、マルチチャンネル決済システム１は、参考として、指定された決済ゲートウェイ、過去の注文記録及び注文を開始したユーザのリアルタイム為替レートに基づいて、注文の予測手数料を特定する。具体的には、データ記憶モジュール２４は、支払額、為替レート及び手数料等の取引関連情報を含む、過去の全ての注文及び支払明細を記憶する。手数料予測モジュール２１は、指定された決済ゲートウェイを提供する決済サービスプロバイダからリアルタイム為替レートを取得し、データ記憶モジュール２４の関連する注文記録及びリアルタイム為替レートにしたがって、注文の手数料を予測する。最後に、予測された手数料が参考としてユーザに提示される。
【0034】
一実施形態では、手数料予測モジュール２１は、各決済ゲートウェイのサービスプロバイダからリアルタイム為替レート情報を一定間隔で取得し得る。例えば、各決済ゲートウェイのサービスプロバイダのサーバにクエリコマンドを１５分毎に送信され、取得した為替レートが記憶され得る。手数料を予測する場合、手数料予測モジュール２１は、最後のクエリから得られた為替レートに従って手数料を予測し得る。別の実施形態では、手数料予測モジュール２１は、手数料予測モジュール２１が手数料予測を行う場合に、指定された決済ゲートウェイのサービスプロバイダのサーバにクエリコマンドを送信し得る。当業者であれば、ビジネス要件にしたがって、為替レートを得るためのモード及び頻度を調整し得る。
【0035】
一実施形態では、マルチチャンネル決済システム１は、支払請求を送信すること決定する場合、検証プロセスをさらに行い得る。具体的には、マルチチャンネル決済システム１は、二要素認証（２ＦＡ）、多要素認証（ＭＦＡ）又はセキュリティを確保するための他の検証方法を通じて、注文の発信者を検証し得る。ユーザは、高額な支払い又は重大な決定に関連する注文に不正利用される恐れがないことを確実にするため、支払額の閾値、取引相手、支払タイプ等、マルチチャンネル決済システム１において検証されるべき注文の基準を設定し得る。
【0036】
プロセス３によれば、ステップ３０８で、マルチチャンネル決済システム１はＡＭＬ検証を行う必要がある。具体的には、コンプライアンスモジュール２２は、指定された決済ゲートウェイに関連する支払人１０及び受取人１２の金融口座及び取引挙動に従ってＡＭＬ検証を行う。ＡＭＬ検証は、支払請求が正規の会社であるかどうかを確認するために用いられ、様々な国の法規に準拠し、支払いを行う前に行われるべきものである。ＡＭＬ検証に合格した注文のみが多重監査プロセスに入ることが許される。
【0037】
ステップ３１０で、マルチチャンネル決済システム１は、ＡＭＬ検証に合格した注文のために多重監査プロセスを開始し得る。具体的には、一実施形態では、多重監査モジュール２３はユーザインターフェイスを提供し、ユーザは、ユーザインターフェイスを介して注文内容、指定された決済ゲートウェイ及び予測される手数料を確認し得る。本発明の実施形態では、マルチチャンネル決済システム１は、監査権限と、様々な企業組織の財務担当者に適応し、財務担当者が迅速に展開且つ使用するのに便利な監査プロセスとを設定する柔軟性を提供する。加えて、一実施形態では、ユーザがマルチチャンネル決済システム１を介した自動支払の基準を設定してもよく、該基準を満たす注文はステップ３１２に直接進み、監査なしで支払を実行することが許可される。自動支払のための基準は、限定されないが、支払額、取引相手、支払の種類等のための閾値であり得る。具体的には、マルチチャンネル決済システム１のユーザカウントは複数のサブアカウントを含んでもよく、企業は、サブアカウントごとに異なる権限を設定して、異なるレベルの監査を行ってもよい。さらに、各企業の異なる要件に応じて、注文に対する監査プロセスは、リニア監査プロセス、グループ会議監査プロセス又はリング署名監査プロセスの方法で行われ得る。一実施形態では、商人又はサプライヤは、多重監査人のために複数のサブアカウントを作成してもよい。図５～図７に示すように、注文５２は、監査人５０＿１、５０＿２、５０＿３及び監督監査人５０＿４によって共同で審査され、多重監査プロセスに合格した場合にのみ注文５２の実行が許可される。本発明の実施形態では、３人の一般監査人及び１人監督監査人を含む４人の監査人を一例として用いるが、これに限定されない。なお、本発明の実施形態における多重監査プロセスは、支払人１０及び受取人１２の両方に対して同時に用いられ得る。例えば、受取人によって開始された支払請求が支払人に送信される前に、支払人１０の関連する監査担当者が第１の多重監査プロセスを行って、それを送信するかどうか判断し得る。他方で、支払請求を受信した支払人は、受取人１２の関連する監査担当者による第２の多重監査プロセスを介して支払を行うかどうか判断し得る。さらに、一実施形態では、電子ウォレットアドオン及びＣＢＤＣウォレットアドオンは、２ＦＡ又はＭＦＡ検証を有し得るか又はその使用を管理するためにシングルサインオン（ＳＳＯ）サービスの認証によって検証される必要があり得る。多重監査モジュール２３は、電子ウォレットアドオン及びＣＢＤＣウォレットアドオンに接続して、注文を許可する間に２ＦＡ又はＭＦＡ検証を介してその使用を制御し得る。
【0038】
一実施形態では、商人又はサプライヤは、図５に示すように、多重監査モジュール２３を介してリニア監査プロセス（多人数シングルラインプロセス）を行い得る。注文元５４が注文５２を行った後、注文５２は先ずＡＭＬ検証を受ける必要がある。正常に検証された注文５２は、注文５２を許可するか拒否するかを検討及び決定するために監査人５０＿１に送信される。２ＦＡ又はＭＦＡ検証に通すことにより監査人５０＿１が注文５２を許可した場合、注文５２はマルチチャンネル決済システム１を介して次の監査人５０＿２に送信される。許可されなかった場合、注文５２はマルチチャンネル決済システム１を介して注文元５４に返される。監査人５０＿１から注文５２を受信した後、監査人５０＿２は注文５２を確認し、許可するかどうか判断する。許可するの場合、注文５２は次の監査人５０＿３に送信され、許可されない場合、注文５２は監査人５０＿１に返される。同様に、監査人５０＿２から注文５２を受信した後、監査人５０＿３は注文５２を確認し、許可するかどうかを判断する。許可する場合、注文５２は監督監査人５０＿４に送信され、許可されない場合、注文５２は監査人５０＿２に返される。最後に、監督監査人５０＿４が注文５２をチェックし、許可するかどうかを判断する。許可する場合、マルチチャンネル決済システム１は、注文５２が監査プロセスに合格したと判断し、指定された決済ゲートウェイに従って支払を実行する。合格しなかった場合、注文５２は監査人５０＿３に返される。この実施形態では、注文５２は、注文５２を許可するかどうかを判断する監査人５０＿１、監査人５０＿２、監査人５０＿３、監督監査人５０＿４によって順番に確認される。
【0039】
別の実施形態では、商人又はサプライヤは、図６に示すように、多重監査モジュール２３を介してグループ会議監査プロセス（多人数マルチラインプロセス）を行い得る。注文元５４が注文５２を行った後、注文５２は先ずＡＭＬ検証を受ける必要がある。検証に成功した注文５２は、監査人５０＿１、監査人５０＿２及び監査人５０＿３に同時に送られ、その後、監査人５０＿１、監査人５０＿２及び監査人５０＿３が注文５２をチェックし、マルチチャンネル決済システム１を介して投票する。投票前及び投票の間に、多重監査モジュールを介して監査意見の伝達及び交換のために、監査人５０＿１～５０＿４のいずれかは、別の監査意見を表明するために別の人を指名できる。注文５２及び投票結果５６は共に監督監査人５０＿４に送られる。監督監査人５０＿４は注文５２及び投票結果を確認し、それに従ってグループ会議監査プロセスを終了するための最終的な確認を行う。監督監査人５０＿４が注文５２を許可した場合、マルチチャンネル決済システム１は、注文５２が監査プロセスに合格したと判断し、指定された決済ゲートウェイに従って支払を実行する（２ＦＡ又はＭＦＡの検証後）。合格しなかった場合、注文５２は注文元５４に返される。
【0040】
さらに、多重監査モジュール２３は、オンラインでの監査意見の交換のためのユーザインターフェイスを提供する。図７に示すように、監査人５０＿１、監査人５０＿２、監査人５０＿３及び監督監査人５０＿４のうちのいずれかが、注文５２の内容に懸念がある場合、マルチチャンネル決済システム１を介して意見交換が行われ得る。意見交換は、１対１、１対多、多対多等の形式で行われてもよく、どの監査人も監査意見を述べるよう他の監査人を指名できるため、適応性が高く厳格な監査プロセスが提供される。したがって、多重監査モジュール２３は、商人／サプライヤの会社の財務部門の構成に応じて柔軟に調整され、監査プロセスは、限定されないが、リニア監査プロセス、グループ会議監査プロセス又はリング署名監査プロセスであり得る。
【0041】
プロセス３によれば、ステップ３１２で、マルチチャンネル決済システム１は、注文及び指定された決済ゲートウェイに従って支払人１０から受取人１２への支払を実行し、注文の支払明細を記憶する。具体的には、注文が許可された後、マルチチャンネル決済システム１は支払プロセスに入り得る。拡張機能２００は、注文内容及び指定された決済ゲートウェイに従って支払操作を実行し、取引検証モジュール２５は支払操作の結果を検証する。具体的には、取引検証モジュール２５は、ユーザインターフェイスモジュール２０の拡張機能２００及びデータ記憶モジュール２４とやりとりすることにより、指定された決済ゲートウェイサービスのサービスプロバイダから支払の状態を受信する。取引検証モジュール２５は、決済操作の実行結果を支払詳細に記憶し、ユーザインターフェイスモジュール２０により支払結果を表示する。支払プロセスには、例えば、支払人１０の銀行口座の残高が不足していたり、決済ゲートウェイを提供するサービスプロバイダが正常に機能していなかったり（ネットワーク問題等）等、支払操作が失敗する原因となる多くの要因がある。拡張機能がデジタル通貨決済の場合、ブロックチェーンノードのエラー、ガス価格の不足、特定の期間における頻繁な取引、ブロックの欠落又はブロックチェーンフォーク等、多くの理由で取引が失敗することがあり、支払結果を取引検証モジュール２５に転送する必要があり、（支払人によって承認された）取引がやり直され得る。取引検証モジュール２５は、送金手数料、最終為替レート、（送金時間及び到着時間を含む）所要時間等の支払操作の詳細を記録するだけでなく、決済失敗の要因を詳細に記録し、データ記憶モジュール２４にそれを記憶する。手数料予測モジュール２１は、関連する注文記録、支払手数料、為替レート等、データ記憶モジュール２４によって提供されるデータと、指定された決済ゲートウェイのサービスプロバイダによって提供されるリアルタイム為替レートとに従って、後続の注文の手数料を予測し得る。決済推奨モジュール２６は、手数料、為替レート及び支払失敗の理由等の支払明細を含む、データ記憶モジュール２４によって提供される関連する注文記録に従って、後続の注文のための決済ゲートウェイを推奨し得る。
【0042】
ユーザインターフェイスモジュール２０の動作に関して、実際には、図８に示すように、ＡＰＩ通信プロトコル８０が提供され得る。マルチチャンネル決済システム１は、ＡＰＩ通信プロトコル８０を介して、国内送金８２＿１、ＶＣＣ取引８２＿２、ステーブル取引８２＿３及びサードパーティー決済サービス８２＿４等の様々な異種の決済ゲートウェイを統合する。図８に示すように、ＡＰＩプロトコル８０は、下記の表１に示すＡＰＩを定義することにより、各決済ゲートウェイのサービスプロバイダによって提供されるサービスＡＰＩを統合するために抽象化層を確立し、それにより各決済ゲートウェイを独立した拡張機能としてラップ／カプセル化する。つまり、ＡＰＩ通信プロトコル８０は、サービスＡＰＩをユーザインターフェイスモジュール２０の拡張機能にマッピングするために不可欠なデータ形式を定義する。ＡＰＩ通信プロトコル８０によって定義されるデータ形式は、同様の決済ゲートウェイサービスのＡＰＩに合う柔軟性があり、新たな種類のサービスをスケールアウトするために拡張できる。ＡＰＩ通信プロトコル８０は、受領及び支払取引を許可するために決済ゲートウェイサービスからの認証トークンを検証するため、多重監査モジュール２３は、金融機関の間の支払操作を行うために、ＡＰＩ通信プロトコル８０を用いることにより支払指図を許可する。このように、開発者が新たな決済ゲートウェイを統合する場合、新たな決済ゲートウェイはマルチチャンネル決済システム１にモジュール方式で統合され、マルチチャンネル決済システム１のユーザは、図４Ａ～図４Ｆに示すように、各決済ゲートウェイに素早く参加し、選択し、有効又は無効にし得る。なお、表１に示すＡＰＩ関数は、本発明の概念を説明するためにのみに用いられ、詳細なパラメータ、戻り値及び関連データ構造は、実際の要件に従って定義すべきものである。さらに、ＡＰＩは様々な決済ゲートウェイの基本機能を含む必要がある。様々な異種の決済ゲートウェイ間の大きな違いに対応して、ＡＰＩの定義を実態に合わせて拡張する必要がある。
【0043】
【表1】
【0044】
したがって、本発明は、決済関連サービス、とりわけ、性質が全く異なる決済サービスを高度に統合する。マルチチャンネル決済システム１は、注文の実施、身元確認、料金関連予測、ゲートウェイ推奨、注文確認、決済実行等の機能を集約して、ユーザに円滑な利用体験を提供する。加えて、マルチチャンネル決済システム１は、国内銀行、国境を越えた送金、暗号通貨の送金、仮想クレジットカード及び多くの他の決済サービスを、完全に異なる利用シナリオと統合する。ユーザは、決済チャンネル又は通貨を、自身のニーズに従って都合よく選択し得る。本発明のマルチチャンネル決済システム１では、支払人又は受取人は、異種の決済ゲートウェイに基づいて様々な異なる支払指図のバッチを容易に開始し、異なる国とのバッチでの支払を、全て本発明のマルチチャンネル決済システム１で容易に管理することができるため、支払人/受取人は単一の金融システムを用いて様々な請求サイクルの支払に対処できる。さらに、決済サービスはＡＰＩ通信プロトコルを介してパッケージ化され、現在及び将来の取引モードの急速な変化及び発展に対応して、新たな決済サービスを統合する柔軟性を提供する。
【0045】
実施については、本発明の一実施形態に係る装置９の概略図である図９を参照されたい。装置９は、マルチチャンネル決済システム１又はそのモジュールのいずれか１つを実施するために用いられてもよく、処理ユニット９０、記憶ユニット９２及び通信インターフェイスユニット９４を含む。処理ユニット９０は、マイクロプロセッサ又は特定用途向け集積回路（ＡＳＩＣ）であり得る。記憶ユニット９２は、プログラムコード９２０を記憶する任意の種類のデータ記憶装置であってもよく、プログラムコード９２０は処理ユニット９０によって読み出され、実行される。記憶ユニット９２は、限定されないが、リードオンリーメモリ（ＲＯＭ）、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ）、ハードディスク、光データ記憶装置、不揮発性記憶装置等であり得る。通信インターフェイスユニット９４は、有線又は無線通信を介して他の装置又はユーザとメッセージを送信するために用いられ得る。
【0046】
装置９は、本発明の実施形態を実施するために必要な構成要素を表すために用いられ、それにしたがって、当業者は様々な変更及び調整を行ってもよく、これに限定されない。例えば、マルチチャンネル決済システム１を実施するために装置９が適用される場合、プロセス３はプログラムコード９２０にコンパイルされ、記憶ユニット９２に記憶され、処理ユニット９０によって実行される。また、通信インターフェイスユニット９４を介して、情報が他の装置に伝送される。データ記憶モジュール２４を実施するために装置９を適用する場合、データ記憶はデータベース又はブロックチェーン方式で実施され得る。具体的には、注文、ユーザ情報等に関連するデータを記憶ユニット９２に記憶し、データアクセス方法がプログラムコード９２０にコンパイルされ、記憶ユニット９２に記憶され得る。データアクセス方法は処理ユニット９０によって実行され、情報は通信インターフェイスユニット９４を介して他のモジュールに伝送される。なお、図９は本発明の概念を説明するためにのみ用いられている。装置又はモジュール間の通信方法の詳細、データストレージのデータ構造等は、実際の要件に従って当業者によって調整され得るため、ここでは繰り返さない。
【0047】
要約すると、本発明は高度に統合されたマルチチャンネル決済システムを提供する。マルチチャンネル決済システムは、プッシュペイメント方法及びプルペイメント方法の両方のために用いられ、支払人及び受取人の双方が柔軟に支払請求を開始でき得る。マルチチャンネル決済システムは、複数の通貨で国内又は国境を越えた支払をサポートし、モジュール化された決済ゲートウェインターフェイスを提供し、決済ゲートウェイを効率的に統合して利用の利便性を改善する。さらに、支払の確認のための監査プロセスを簡素化するために、多重監査方法が提供される。本発明によって提供されるマルチチャンネル決済システムは、複雑な決済内容に対処することなく、またセキュリティ上の懸念もなく、スムーズに決済操作を行うことができる。
【0048】
当業者であれば、発明の教示を保持しながら、装置及び方法の多数の修正及び変更が行われ得ることを容易に理解するであろう。したがって、上記の開示は、添付の特許請求項の範囲によってのみ制限されると解釈すべきである。
【要約】
【課題】 異種の決済ゲートウェイを統合可能なマルチチャンネル決済システムを提供すること。
【解決手段】 マルチチャンネル決済システムのためのマルチチャンネル決済方法は、支払請求を開始した支払人又は受取人がマルチチャンネル決済システムにログインすることと、支払請求を開始した支払人又は受取人がマルチチャンネル決済システムで注文を行うことであって、注文は指定された決済ゲートウェイを含む、ことと、マルチチャンネル決済システムが、指定された決済ゲートウェイ、過去の注文記録及びリアルタイム為替レートに従って注文の予測手数料を特定することと、マルチチャンネル決済システムが注文のマネーロンダリング防止検証を行うことと、支払人が、多重監査方法を介して注文及び予測手数料を確認することと、マルチチャンネル決済システムが注文及び指定された決済ゲートウェイに従って支払人から受取人への支払を実行し、注文の支払明細を記憶すること、を含む。
【選択図】 図３
【解決手段】 マルチチャンネル決済システムのためのマルチチャンネル決済方法は、支払請求を開始した支払人又は受取人がマルチチャンネル決済システムにログインすることと、支払請求を開始した支払人又は受取人がマルチチャンネル決済システムで注文を行うことであって、注文は指定された決済ゲートウェイを含む、ことと、マルチチャンネル決済システムが、指定された決済ゲートウェイ、過去の注文記録及びリアルタイム為替レートに従って注文の予測手数料を特定することと、マルチチャンネル決済システムが注文のマネーロンダリング防止検証を行うことと、支払人が、多重監査方法を介して注文及び予測手数料を確認することと、マルチチャンネル決済システムが注文及び指定された決済ゲートウェイに従って支払人から受取人への支払を実行し、注文の支払明細を記憶すること、を含む。
【選択図】 図３
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図4C】
【図4D】
【図4E】
【図4F】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10A】
【図10B】
