特許 7118281 統合支払いのバックエンド構築方法、システム、コンピュータ機器及び記憶媒体

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

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

(11)【特許番号】

(24)【登録日】2022-08-04

(45)【発行日】2022-08-15

(54)【発明の名称】統合支払いのバックエンド構築方法、システム、コンピュータ機器及び記憶媒体

(51)【国際特許分類】

   G06Q 20/02 20120101AFI20220805BHJP

【ＦＩ】

G06Q20/02 310

【請求項の数】 9

(21)【出願番号】P 2021538273

(86)(22)【出願日】2019-11-20

(65)【公表番号】

(43)【公表日】2022-02-25

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

(87)【国際公開番号】W WO2020134738

(87)【国際公開日】2020-07-02

【審査請求日】2021-06-29

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

(32)【優先日】2018-12-29

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】320010240

【氏名又は名称】ビゴ テクノロジー ピーティーイー． リミテッド

【住所又は居所原語表記】３０ ＰＡＳＩＲ ＰＡＮＪＡＮＧ ＲＯＡＤ，＃１５－３１Ａ，ＭＡＰＬＥＴＲＥＥ ＢＵＳＩＮＥＳＳ ＣＩＴＹ，ＳＩＮＧＡＰＯＲＥ １１７４４０

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】侯 俊丞

(72)【発明者】

【氏名】▲楊▼ ▲凱▼星

【審査官】速水 雄太

(56)【参考文献】

【文献】特開２００３－６７５７０（ＪＰ，Ａ）

【文献】特表２０１３－５２２７７７（ＪＰ，Ａ）

【文献】特開２０１１－１５９０５３（ＪＰ，Ａ）

【文献】特表２０１４－５０２３９７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１６／００８６４５４（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０１７０１４９（ＵＳ，Ａ１）

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

Ｇ０６Ｑ １０／００－９９／００

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

【請求項1】

クライアントによって送信された取引情報を取得するステップであって、前記取引情報が前記クライアントの位置情報を含むステップと、
前記位置情報に基づいて、前記取引情報を前記位置情報に対して管理権限を有する取引ノードに割り当てるステップにおいて、同じクライアントの同じサービスタイプ要求を同じ取引ノードで処理するために、前記取引情報のサービスタイプに基づいて、割り当てリストにおいて割り当て規則をマッチングするステップ、前記割り当て規則に基づいて、マッチングした取引ノードの使用状態情報を取得するステップ、及び、前記取引ノードの使用状態が第１の所定条件を満たす場合、前記位置情報に基づいて前記取引情報を前記取引ノードに割り当てるステップを含み、前記取引ノードは、分散型取引システムにおける指定された地域内の取引センターであるステップと、
前記取引ノードに基づいて、前記取引ノードと接続関係を予め確立しているチャンネル接続層においてチャンネルゲートウェイをマッチングし、マッチングしたチャンネルゲートウェイを介して前記取引情報中の取引要求を取引相手に送信して処理させるステップと、
前記取引相手の処理結果を取得し、処理結果情報をクライアントに転送するステップとを含む、ことを特徴とする統合支払いのバックエンド構築方法。

【請求項2】

前記位置情報に基づいて、前記取引情報を前記位置情報に対して管理権限を有する取引ノードに割り当てる前記ステップの前に、
前記取引情報の認証情報を認証するステップであって、前記認証情報は暗号化通信プロトコルによって設定されるステップと、
認証に成功した前記取引情報を解析することによって、取引情報を送信した前記クライアントのアイデンティティ情報及びサービスタイプを取得するステップと、
解析された前記アイデンティティ情報及びサービスタイプに基づいて、アイデンティティ権限リストにおいてマッチングして権限認証を行うステップと、
権限認証に成功した取引情報を取引ノードに割り当てるステップとをさらに含む、ことを特徴とする請求項１に記載の統合支払いのバックエンド構築方法。

【請求項3】

権限認証に成功した取引情報を取引ノードに割り当てる前に、
第１の所定期間内に権限認証に成功した取引情報のトラフィック値を取得するステップと、
前記トラフィック値が第１の所定閾値以下の取引情報の割り当てを許可するステップとをさらに含む、ことを特徴とする請求項２に記載の統合支払いのバックエンド構築方法。

【請求項4】

前記取引ノードの使用状態が第１の所定条件を満たさない場合、割り当て規則を再びマッチングすることによって、取引ノードを再決定する、ことを特徴とする請求項１に記載の統合支払いのバックエンド構築方法。

【請求項5】

前記取引相手が前記取引要求を処理する方法は、
前記取引要求に基づいて、唯一な注文番号を作成するステップと、
通信インタフェースを呼び出すことにより、取引相手において前記注文番号に対応する取引要求を処理するステップと、
前記取引要求の処理プロセスデータを非同期タスクとして非同期タスクキューに書き込んでキャッシュするステップと、
処理プロセスにおいて、前記非同期タスクキュー内の非同期タスクに異常が生じた場合、再試行を行うステップと、
前記非同期タスクキュー内の全ての非同期タスクが完了すると、この非同期タスクキュー内のすべての非同期タスクを削除するステップとを含む、ことを特徴とする請求項１に記載の統合支払いのバックエンド構築方法。

【請求項6】

再試行の回数を取得するステップと、
前記再試行の回数が第２の閾値に達すると、前記非同期タスクを削除し、異常情報を前記クライアントにフィードバックするステップとをさらに含む、ことを特徴とする請求項５に記載の統合支払いのバックエンド構築方法。

【請求項7】

統合支払いのバックエンド構築システムであって、
クライアントによって送信された取引情報を取得するステップであって、前記取引情報は、前記クライアントの位置情報を含むステップを実行するアクセスフロントエンドと、
前記位置情報に基づいて、前記取引情報を前記位置情報に対して管理権限を有する取引ノードに割り当てるステップにおいて、同じクライアントの同じサービスタイプ要求を同じ取引ノードで処理するために、前記取引情報のサービスタイプに基づいて、割り当てリストにおいて割り当て規則をマッチングするステップ、前記割り当て規則に基づいて、マッチングした取引ノードの使用状態情報を取得するステップ、及び、前記取引ノードの使用状態が第１の所定条件を満たす場合、前記位置情報に基づいて前記取引情報を前記取引ノードに割り当てるステップを含み、前記取引ノードは、分散型取引システムにおける指定された地域内の取引センターであるステップを実行する中継転送サーバと、
前記取引ノードに基づいて、前記取引ノードと接続関係を予め確立しているチャンネル接続層においてチャンネルゲートウェイをマッチングし、マッチングしたチャンネルゲートウェイを介して前記取引情報中の取引要求を取引相手に送信して処理させ、前記取引相手の処理結果を取得し、処理結果情報をクライアントに転送する取引ノードとを含む、統合支払いのバックエンド構築システム。

【請求項8】

コンピュータ機器であって、メモリとプロセッサとを含み、前記メモリにはコンピュータ読み取り可能な命令が記憶され、
前記コンピュータ読み取り可能な命令が前記プロセッサによって実行されると、前記プロセッサに請求項１～請求項６のいずれかに記載の統合支払いのバックエンド構築方法のステップを実行させる、コンピュータ機器。

【請求項9】

コンピュータ読み取り可能な命令が記憶される不揮発性記憶媒体であって、
前記コンピュータ読み取り可能な命令が１つ又は複数のプロセッサによって実行されると、１つ又は複数のプロセッサに請求項１～請求項６のいずれかに記載の統合支払いのバックエンド構築方法のステップを実行させる、記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、コンピュータアプリケーションの技術分野に関し、具体的には、背景技術に関する。

【背景技術】

【0002】

モノのインターネット及びモバイルインターネットの急速な発展に伴い、近年、電子支払い業界も急速に発展し、中国国内では、銀行、銀聯などの決済機構、第三者支払い企業などは、異なる技術で実現される異なる種類のモバイル支払いサービスを提供する。また、客観的な需要の影響で、電子支払い技術は、様々な分野に浸透している。しかし、この背景において、各側のサービスは、統一的な基準及びインタフェースがなく、各種類の支払いツール及びプラットフォームは、完全な互換性を実現することが困難である。視野を全世界に広げると、各国は、それぞれ各自のチャンネル業者及びアクセス制限ルールを有するため、グローバル化サービスを有する企業は、アクセスコスト及びアクセス効率も非常に大きな影響を受ける。

【0003】

中国国内で使用されている第三者支払いチャンネルの数が多くなく、普通の企業は、ウィーチャット又はアリペイの２つにアクセスすれば、中国国内の９０％以上のオンライン支払いニーズをカバーすることができる。したがって、ほとんどの企業は、支払いチャンネルにアクセスするとき、第三者チャンネルに直接的に接続するが、様々な支払いチャンネル（例えばウィーチャット、アリペイ）の支払いプロセスは詳細に相違があるため、一般的にバックグラウンドで複数の支払いプロセスをサポートする必要がある。現在、中国国内のインターネット業界は、世界に広がっている一方、海外の支払いチャンネルの種類が多く、かつプロセスが異なり、従来の方法を採用して直接第三者支払いチャンネルに接続すると、当業者は、複数の支払いプロセスをメンテナンスする複雑なタスクに直面しなければならない。

【発明の概要】

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

【0004】

本願は、少なくとも上記の技術的欠陥の１つを解決できるために、第三者支払いを行うプロセスにおいて分離性が高く、ノードの結合度が低く、迅速にアクセスし、使用が柔軟的である統合支払いのバックエンド構築方法、システム、コンピュータ装置及び記憶媒体を開示することを目的とする。

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

【0005】

上記目的を実現するために、本願は、統合支払いのバックエンド構築方法を開示し、前記統合支払いのバックエンド構築方法は、クライアントによって送信された取引情報を取得するステップであって、前記取引情報は、前記クライアントの位置情報を含むステップと、前記位置情報に基づいて、前記取引情報を前記位置情報に対して管理権限を有する取引ノードに割り当てるステップであって、前記取引ノードは、分散型取引システムにおける指定された地域内の取引センターであるステップと、前記取引ノードに基づいて、前記取引ノードと接続関係を予め確立しているチャンネル接続層においてチャンネルゲートウェイをマッチングし、マッチングしたチャンネルゲートウェイを介して前記取引情報中の取引要求を取引相手に送信して処理させるステップと、
前記取引相手の処理結果を取得し、処理結果情報をクライアントに転送するステップとを含む。

【0006】

他の態様では、本願は、統合支払いのバックエンド構築システムを開示し、前記統合支払いのバックエンド構築システムは、
クライアントによって送信された取引情報を取得するステップであって、前記取引情報は、前記クライアントの位置情報を含むステップを実行するアクセスフロントエンドと、
前記位置情報に基づいて、前記取引情報を前記位置情報に対して管理権限を有する取引ノードに割り当て、前記取引ノードが、分散型取引システムにおける指定された地域内の取引センターである中継転送サーバと、
前記取引ノードに基づいて、前記取引ノードと接続関係を予め確立しているチャンネル接続層においてチャンネルゲートウェイをマッチングし、マッチングしたチャンネルゲートウェイを介して前記取引情報中の取引要求を前記取引相手に送信して処理させ、前記取引相手の処理結果を取得し、処理結果情報をクライアントに転送する取引ノードと、を含む。

【0007】

他の態様では、本願は、コンピュータ機器を開示し、前記コンピュータ機器は、メモリとプロセッサとを含み、前記メモリにはコンピュータ読み取り可能な命令が記憶され、前記コンピュータ読み取り可能な命令が前記プロセッサによって実行されると、前記プロセッサに上記に開示された統合支払いのバックエンド構築方法のステップを実行させる。

【0008】

他の態様では、本願は、コンピュータ読み取り可能な命令が記憶される不揮発性記憶媒体を開示し、前記コンピュータ読み取り可能な命令が１つ又は複数のプロセッサによって実行されると、１つ又は複数のプロセッサに上記に開示された統合支払いのバックエンド構築方法のステップを実行させる。

【発明の効果】

【0009】

本願の有益な効果は、以下のとおりである。

【0010】

取引情報中のクライアントの位置情報に基づいて、分散型処理を行うことによって、データの支払い処理がより迅速になり、且つ分散して配置された取引センターが互いに独立しており、統一化された通信インタフェースを介して取引相手に接続することで、各チャンネルの支払いプロセスの詳細な差異を隠し、また、クライアントに汎用的且つ統一化された支払いアクセスプロセスを提供し、クライアントである企業は、本統合支払いアーキテクチャとインタラクションする１つのプロセスをメンテナンスすれば、支払いアーキテクチャがサポートする全ての支払いチャンネルを使用することができ、データの分離性が高く、ノードの結合度が低く、耐攻撃能力が高く、クライアント間のサービスの結合性が低く、分散型構成に適し、且つシステムの使用可能性が高く、災害耐性が高く、統一化されたスケジューリングインタフェースによりシステムの拡張性が高い、機能反復によるオンラインサービスへの影響が低い。

【図面の簡単な説明】

【0011】

本願の上記の及び／又は付加的な態様及び利点は、以下に図面を参照した実施例についての説明から明瞭及び理解しやすくなる。

【0012】

【図1】図１は、本願の統合支払いのバックエンド構築方法のフローチャートである。

【図2】図２は、本願の取引情報の権限認証方法のフローチャートである。

【図3】図３は、本願の取引情報を取引ノードに割り当てる方法のフローチャートである。

【図4】図４は、本願の取引相手が取引要求を処理する方法のフローチャートである。

【図5】図５は、本願の非同期タスクキューの再試行方法のフローチャートである。

【図6】図６は、本願の統合支払いの全体フローチャートである。

【図7】図７は、本願の統合支払いの多層構造の模式図である。

【図8】図８は、本願の統合支払いの各モジュールが情報を受信するフローチャートである。

【図9】図９は、本願のコンピュータ機器の基本構造のブロック図である。

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

【0013】

具体的には、図１を参照すると、本願は、統合支払いのバックエンド構築方法を開示し、統合支払いは、第三者支払いに対するものである。統合支払いは、第三者支払いとは異なり、企業と銀行との間ではなく、企業と第三者支払い者との間のチャンネルである。統合支払いは、資金を決算したり、移したりせず、支払いプロセスの情報フロー及びデータフローを制御するものに過ぎない。統合は、第三者支払い機構により提供された支払い方式とは異なり、企業に、統一化された支払い及び決算のインタフェースを提供する。企業のアクセス難度及びコストを低減させ、運営速度及び効率を向上させるために、より高い柔軟性及び利便性を有する。

【0014】

本願では、統合支払いのバックエンド構築方法は、ステップＳ１０００～Ｓ４０００を含む。

【0015】

Ｓ１０００において、クライアントによって送信された取引情報を取得し、前記取引情報は、前記クライアントの位置情報を含む。

【0016】

クライアントは、実際に、企業端末を意味し、複数あり、複数のクライアントは、同時に要求命令を送信して分析することができる。要求命令は、クライアントアイデンティティ情報、要求内容が記載された関連するデータメッセージであり、このデータメッセージは、情報を交換するために、設定されたフォーマットに従って構成されたフィールド組み合わせであり、異なるクライアントを区別するために、このデータメッセージには、クライアントアイデンティティを表す企業番号情報、及び要求されたサービスタイプを表すサービス番号情報が含まれ、それにより、要求命令を送信したクライアントのアイデンティティ情報及び要求内容を確認する。

【0017】

取引情報は、クライアントによって送信された、第三者が処理することを要求する関連情報であり、取引情報は、クライアントの位置情報を含む。

【0018】

別の実施例では、前記取引情報は、取引情報が指す取引相手の位置情報をさらに含む。本願では、取引相手とは、取引クライアントが取引処理を要求する第三者であり、ここで、取引相手の位置情報とは、該第三者の位置情報である。第三者の情報は、支払いプラットフォームであり、支払いプラットフォームは、たくさんあり、例えば各大手銀行、ウィーチャット、アリペイなどの金融プラットフォームであり、これらの第三者プラットフォームは、対応するサーバ処理位置情報を有し、位置情報が国籍及び具体的な地域を含み、取引相手の位置情報を取得することで、該取引相手のサーバ位置情報を得ることができることが理解され得る。

【0019】

Ｓ２０００において、前記位置情報に基づいて、前記取引情報を前記位置情報に対して管理権限を有する取引ノードに割り当て、前記取引ノードは、分散型取引システムにおける指定された地域内の取引センターである。

【0020】

取引ノードとは、サービス処理を行うコア処理層に位置し、サービス注文書の作成及びサービス処理論理は、この層で実現される。この実施例では、位置情報がクライアントの位置情報であり、取引ノードは、分散型取引システムにおける指定された地域内の取引センターである。クライアントが全地球の各位置に分布する可能性があるため、支払い要求に迅速に応答するために、全地球の任意の場所に取引ノードを配置することができ、上記取得されたクライアントの位置情報によって、該位置情報に対して管理権限を有する取引ノードを選択して処理させる。

【0021】

別の実施例では、位置情報は、取引情報が指す取引相手の位置情報であり、すなわち、第三者取引プラットフォームの位置情報である。第三者取引プラットフォームは、全地球の任意の位置に位置できるため、本願の統合支払いのクライアントは、全地球の各地に分布する可能性がある。支払い要求に迅速に応答するために、第三者取引プラットフォームの地域位置に基づいて、複数の取引ノードがそれぞれ配置され、各取引ノードは、互いに独立しており、分離性を有し、そのうちの１つの取引ノードが異常した場合、その他の取引ノードの正常なサービス処理に影響を与えない。さらに、各取引ノードは、自己の管理範囲を有する。１つの新しい要求命令に対して、対応する取引相手の位置情報及びサービスタイプを識別すれば、対応する管理範囲の取引ノードに割り当てて処理させることができる。しかし、サービス処理の災害耐性をさらに向上させるために、対応する取引ノードに割り当てるとき、該取引ノードの状態が使用可能であるか否かを検出し、該取引ノードの状態が使用不可能であることを検出した場合、要求命令をその他の使用可能な取引ノードに割り当て、それにより、該取引情報要求の命令の正常処理を確保する。

【0022】

Ｓ３０００において、前記取引ノードに基づいて、前記取引ノードと接続関係を予め確立しているチャンネル接続層においてチャンネルゲートウェイをマッチングし、マッチングしたチャンネルゲートウェイを介して前記取引情報中の取引要求を前記取引相手に送信して処理させる。

【0023】

取引ノードが割り当てられると、取引ノードの情報に基づいて、該取引ノードと接続関係を確立しているチャンネル接続層においてチャンネルゲートウェイをマッチングする。チャンネル接続層には、異なる第三者取引相手に接続して通信する複数の異なるチャンネルゲートウェイが記憶され、
チャンネルゲートウェイは、スケジューリングインタフェースを介して取引ノードに接続して通信する。本願では、チャンネルゲートウェイは、第三者取引相手とのインタラクション論理を実現し、異なるチャンネルの間のインタラクション詳細が上の層に対して隠され、本願の各チャンネルゲートウェイのスケジューリングインタフェースが統一化されており、それにより、一致する取引プロセスをメンテナンスしやすく、チャンネルオブジェクトが変化しても、取引プロセスが変化しない。一方、チャンネルゲートウェイ層の各チャンネルは、論理的に独立しており、且つ注文書データを操作しないものであり、あるチャンネルが変化しても、その他のチャンネル及びメインプロセスにあまり影響を与えず、高速アクセス及び反復を容易に実現することができる。統一化されたスケジューリングインタフェースにより、新しいチャンネルがアクセスしやすく、対応するチャンネルゲートウェイノードを構築すればよく、第三者取引相手との具体的な差異及び詳細がチャンネルゲートウェイに隠される。

【0024】

支払いサービスでは、チャンネルゲートウェイは、異なる支払い第三者に接続されるアプリケーションインタフェース端末であり、異なる第三者支払いプラットフォームが異なるチャンネルゲートウェイを必要とするため、チャンネルゲートウェイ接続データベース、すなわち、チャンネル接続層が構築される。要求命令中の取引相手を識別することで、チャンネルゲートウェイ接続データベースにおいて異なるチャンネルゲートウェイをマッチングし、サービス処理を行うことができる。

【0025】

一実施例では、各チャンネルゲートウェイと第三者チャンネルとのインタラクションは、統一化されたスケジューリングインタフェースを用いるため、異なるチャンネルの間のインタラクション詳細が上の層に対して隠され、各チャンネルが接続して独立したサブモジュールを形成し、関連するサービス処理を行うとき、対応するインタフェースを直接呼び出すればよい。新しいチャンネルがアクセスすると、基準化されかつ統一化されたインタフェースを提供するチャンネルゲートウェイノードを構築すればよい。第三者と接続する具体的な差異及び詳細は、チャンネルゲートウェイに隠される。このようにすると、上のコアサービス層が統一化されたインタフェースを呼び出すことができ、一致する取引プロセスをメンテナンスし、チャンネルが変化しても、取引プロセスが変化しない。一方、チャンネルゲートウェイ層の各チャンネル論理は、いずれも独立しており、且つ注文書データを操作しないものであり、あるチャンネルが変化しても、その他のチャンネル及びメインプロセスにあまり影響を与えず、高速アクセス及び反復を容易に実現することができる。

【0026】

Ｓ４０００において、前記取引相手の処理結果を取得し、処理結果情報をクライアントに転送する。

【0027】

本願では、対応する通信インタフェースを呼び出すことで、前記取引情報中の取引要求を対応する取引相手に送信して処理させるとともに、取引相手によってフィードバックされた取引結果を取得し、取引結果情報をクライアントにフィードバックする。

【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】

別の実施例では、注文書番号を生成するには、クライアントのアイデンティティ情報、サービスタイプ及び取引相手情報を埋め込んでもよい。例えば、クライアントアイデンティティ情報を表すかしら文字又はＩＤ、サービスタイプの番号及び取引相手の番号に、時間軸の順に従って設定された配列番号からなる注文書番号を追加し、同じクライアントのアイデンティティ情報、同じサービスタイプ及び同じ取引相手情報を注文書番号により区別することができ、それにより、データ問い合わせ及び追跡が容易になる。

【0066】

さらに、注文書番号の安全性を確保するために、ランダムに生成されたチェックディジットを上記注文書番号に埋め込んでもよく、注文書の安全性を向上させる。

【0067】

さらに、注文書を生成した後、随時に呼び出すために、前記注文書番号及び取引情報から解析された関連データをデータベースに記憶する。

【0068】

Ｓ３２００において、前記通信インタフェースを呼び出すことで、取引相手において前記注文番号に対応する取引要求を処理する。

【0069】

取引ノード内には、複数のチャンネルゲートウェイがあり、取引ノードとチャンネルゲートウェイのスケジューリングインタフェースが統一化されており、異なるチャンネルゲートウェイが異なる取引相手の処理サーバに接続し、チャンネルゲートウェイ及びスケジューリングインタフェースは、通信インタフェースを構成し、取引情報から注文番号を生成した後、該注文番号を監視することで、対応する取引情報の処理プロセスを取得することができる。取引センターは、取引情報中の取引要求を通信インタフェースを介して取引相手のサーバに送信して処理させるとともに、取引情報を取引キューサーバに送信した時間、取引処理のプロセス状態、最終結果状態、合計時間などの処理のプロセス情報を受信する。

【0070】

Ｓ３３００において、前記取引要求の処理プロセスデータを非同期タスクとして非同期タスクキューに書き込んでキャッシュする。

【0071】

一実施例では、取引センターは、通信インタフェースから取得された取引の関連プロセスデータを非同期タスクキューに書込んでキャッシュし、非同期タスクキューには、データ処理のステップに従って、複数の異なる作動ノードが設けられる。１ステップの関連データの情報を受信する度に、該メッセージデータを該ノードに記憶することで、現在の処理プロセス及び処理状態を判断する。

【0072】

Ｓ３４００において、処理プロセスにおいて、前記非同期タスクキュー内の非同期タスクに異常が生じた場合、再試行を行う。

【0073】

一実施例では、非同期キュー内のいずれかの工程に異常が生じると、非同期タスクキューは、情報を取引ノードに自動的に送信することで、該工程を再試行させる。図５を参照すると、再試行の過程は、ステップＳ３４１０及びＳ３４２０を含む。

【0074】

Ｓ３４１０において、再試行の回数を取得する。

【0075】

一実施例では、時間を節約し、処理速度を制御するために、回数の最大値を設定し、第２の閾値と呼称する。従って、再試行工程に入ると、再試行動作を行う度に、現在の回数を記録し、該回数と第２の閾値とを比較する。

【0076】

第２の閾値回数の範囲内において再試行することで、異常現象が解決された場合、非同期タスクキュー内の後続の非同期タスクを続行する。

【0077】

Ｓ３４２０において、前記再試行の回数が第２の閾値に達した場合、前記非同期タスクを削除し、異常情報を前記クライアントにフィードバックする。

【0078】

前記再試行の回数が第２の閾値に達したが、異常現象が解決されない場合、情報を取引ノードに送信し、再試行を要求するための再試行タスクを送信させないとともに、該非同期タスクを削除し、該異常情報をクライアントにフィードバックする。フィードバック情報を同時にデータベースに保存して記憶する。

【0079】

Ｓ３５００において、前記非同期タスクキュー内の全ての非同期タスクが完了すると、この非同期タスクキュー内のすべての非同期タスクを削除する。

【0080】

再試行後、データ異常の状況が解決され、全ての非同期タスクが完了されるまで、非同期タスクキュー内の他の非同期タスクを続行する。非同期タスクキュー内の全ての非同期タスクが完了されると、現在の取引情報の処理が完了されたことが示され、この非同期タスクキュー内のすべての非同期タスクを削除し、データスペースをリリースする。

【0081】

本願の上記方法は、統合支払いシステムを構成し、図６を参照すると、完全な支払い取引要求では、クライアントは、支払い要求を含む取引情報を該統合支払いシステムに送信し、統合支払いシステムは、通信インタフェースを介して第三者取引相手に接続して通信し、第三者取引相手は、注文データを統合支払いシステムに戻し、統合支払いシステムは、この注文データに基づいて支払いリンクを抽出し、支払いリンクをクライアントに送信し、クライアントは、支払いリンクにアクセスして支払いを行い、第三者取引相手は、支払い結果を取得した後、コールバック支払い結果を統合支払いシステムに戻し、統合支払いシステムは、自己の通知規則に従って支払い結果通知を生成してクライアントに戻すことで、支払いの結果を提示する。

【0082】

一実施例では、図７を参照すると、統合支払いシステムは、サービスアクセス層と、コアサービス層と、チャンネル接続層とを含み、サービスアクセス層は、アクセスフロントエンドと中継転送サーバとを含み、コアサービス層は、取引ノードを含み、取引ノードは、データを記憶するデータベースと、非同期タスクキューのキャッシュ及び再試行を行う非同期モジュールと、取引ノードにおいて取得された関連データをクライアントに送信する支払い通知モジュールと、取引ノードのデータの処理プロセス全体を監視する支払い監視モジュールとを含み、取引ノードは、チャンネル接続層における各チャンネルゲートウェイに、統一化されたスケジューリングインタフェースを介して接続し、それにより、異なる第三者取引相手によって、異なる取引支払いプラットフォームに接続して取引処理を行う。

【0083】

具体的には、本願に開示された統合支払いのバックエンド構築システムは、
クライアントによって送信された取引情報を取得するステップであって、前記取引情報は、前記取引情報が指す取引相手の位置情報を含むステップを実行するアクセスフロントエンドと、
前記位置情報に基づいて、前記取引情報を前記位置情報に対して管理権限を有する取引ノードに割り当て、前記取引ノードが分散型取引システムにおける指定された地域内の取引センターである中継転送サーバと、
前記取引ノードに基づいて、前記取引相手と予め確立された通信インタフェースを介して前記取引情報中の取引要求を前記取引相手に送信して処理させ、前記取引相手の処理結果を取得し、処理結果情報をクライアントに転送する取引ノードとを含む。

【0084】

任意選択的には、アクセスフロントエンドは、
前記取引情報の認証情報を認証するステップであって、前記認証情報は暗号化通信プロトコルによって設定されるステップを実行するように構成されている認証モジュールと、
認証に成功した前記取引情報を解析することによって、取引情報を送信した前記クライアントのアイデンティティ情報及びサービスタイプを取得するステップを実行するように構成されているデータ解析モジュールと、
解析された前記アイデンティティ情報及びサービスタイプに基づいて、アイデンティティ権限リストにおいてマッチングして権限認証するステップと、権限認証に成功した取引情報を取引ノードに割り当てるステップとを実行するように構成されている権限認証モジュールとをさらに含む。

【0085】

任意選択的には、前記アクセスフロントエンドは、
第１の所定期間内に権限認証に成功した取引情報のトラフィック値を取得するステップを実行するように構成されているトラフィック識別モジュールと、
前記トラフィック値が第１の所定閾値以下の取引情報を割り当てることを許可するように構成されている選択モジュールとをさらに含む。

【0086】

任意選択的には、中継転送サーバは、
同じクライアントの同じサービスタイプ要求を同じ取引ノードで処理するために、前記取引情報のサービスタイプに基づいて、割り当てリストにおいて割り当て規則をマッチングするステップを実行するように構成されている割り当て規則マッチングモジュールと、
前記割り当て規則に基づいて、マッチングした取引ノードの使用状態情報を取得するステップを実行するように構成されている状態取得モジュールと、
前記取引ノードの使用状態が第１の所定条件を満たすか否かを判断するステップを実行するように構成されている判断モジュールと、
前記第１の所定条件を満たす場合、前記取引情報を前記取引ノードに割り当てるステップを実行するように構成されている割り当てモジュールとを含む。

【0087】

任意選択的には、中継転送サーバは、前記取引ノードの使用状態が第１の所定条件を満たさない場合、割り当て規則を再びマッチングすることによって、取引ノードを再決定するステップを実行するように構成されている再マッチングモジュールをさらに含む。

【0088】

任意選択的には、取引ノードは、
取引要求に基づいて唯一な注文番号を作成するステップを実行するように構成されている注文書生成モジュールと、
前記通信インタフェースを呼び出すことで、取引相手において前記注文番号に対応する取引要求を処理するステップを実行するように構成されている呼び出しモジュールと、
前記取引要求の処理プロセスデータを非同期タスクとして非同期タスクキューに書き込んでキャッシュするステップと、処理プロセスにおいて、前記非同期タスクキュー内の非同期タスクに異常が生じた場合、再試行を行うステップとを実行するように構成されている非同期モジュールと、
前記非同期タスクキュー内の全ての非同期タスクが完了すると、この非同期タスクキューにおける全ての非同期タスクを削除するステップを実行するように構成されている第１の削除モジュールとを含む。

【0089】

任意選択的には、取引ノードは、
再試行の回数を取得するステップを実行するように構成されている再試行計算モジュールと、
前記再試行の回数が第２の閾値に達すると、前記非同期タスクを削除し、異常情報を前記クライアントにフィードバックするステップを実行するように構成されている第２の削除モジュールとをさらに含む。

【0090】

一実施例では、図８を参照すると、上記に開示されたモジュールの具体的な作動ステップは、以下のステップを含む。クライアントは、取引情報を送信し、アクセスフロントエンドは、該取引情報を受信し、権限認証、フロー制御を行った後に中継転送サーバに送信し、中継転送サーバは、割り当て規則に基づいて、該取引情報を対応する取引ノードに割り当て、取引ノードは、関連する取引情報を受信した後に、注文書番号を作成し、関連データをデータベースに保存するとともに、上記分析された取引相手の関連情報に基づいて、関連するチャンネルゲートウェイの通信インタフェースを呼び出し、チャンネルゲートウェイは、第三者取引相手と通信し、取引相手は、注文データを戻し、チャンネルゲートウェイは、この注文データを受信し、このデータを取引ノードに転送し、取引ノードは、注文データ中の支払いリンクを抽出してクライアントに送信し、クライアントは、該支払いリンクにアクセスすることで、直接取引支払いを行い、取引相手は、取引に成功したことを識別した後、注文書コールバック通知をアクセスフロントエンドに送信し、アクセスフロントエンドは、関連データに対して権限認証を行った後に、この前に割り当てられた元の取引ノードに、中継転送サーバを介して割り当て規則に基づいて割り当て、取引ノードは、該コールバック通知の正当性を識別し、正当なコールバック通知である場合、支払い通知モジュールが支払い結果を生成して通知することを要求し、データメッセージを構築して該支払い結果通知を対応するクライアントに直接戻し、支払いの結果を提示する。

【0091】

本願の実施例は、コンピュータ機器の基本アーキテクチャのブロック図を提供し、図９を参照する。

【0092】

該コンピュータ機器は、システムバスを介して接続されるプロセッサと、不揮発性記憶媒体と、メモリと、ネットワークインタフェースとを含む。該コンピュータ機器の不揮発性記憶媒体にはオペレーティングシステム、データベース及びコンピュータ読み取り可能な命令が記憶され、データベースにはコントロール情報配列が記憶され、該コンピュータ読み取り可能な命令がプロセッサによって実行されると、プロセッサに統合支払いのバックエンド構築方法を実行させる。該コンピュータ機器のプロセッサは、計算及び制御能力を提供し、コンピュータ機器全体の運転をサポートする。該コンピュータ機器のメモリには、コンピュータ読み取り可能な命令が記憶され、該コンピュータ読み取り可能な命令がプロセッサによって実行されると、プロセッサに統合支払いのバックエンド構築方法を実行させる。該コンピュータ機器のネットワークインタフェースは、端末に接続して通信する。

【0093】

コンピュータ機器は、関連するクライアントによって送信された提示行為の状態情報、すなわち、関連端末が提示機能をオンにしている否か、及び、ユーザが該提示タスクを閉じたか否かを受信する。上記タスク条件が実現されたか否かを認証することによって、さらに関連端末に、対応する予め設定された命令を送信し、関連端末が該予め設定された命令に基づいて、対応する操作を実行することができ、それにより、関連端末を効果的に監視することを実現する。また、提示情報状態が予め設定された状態命令とは同じではない場合、サーバ端末は、関連端末が連続的に鳴るように制御し、関連端末の提示タスクが所定の時間実行した後に自動的に停止する問題を防止する。

【0094】

本願は、コンピュータ読み取り可能な命令が記憶される記憶媒体をさらに提供し、前記コンピュータ読み取り可能な命令が１つ又は複数のプロセッサによって実行されると、１つ又は複数のプロセッサに上記いずれかの実施例に記載の統合支払いのバックエンド構築方法を実行させる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】