IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 百度(中国)有限公司の特許一覧

特表2023-501850ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム
<>
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図1
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図2
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図3
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図4
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図5
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図6
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図7
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図8
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図9
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図10
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図11
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図12
  • 特表-ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム 図13
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-01-20
(54)【発明の名称】ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム
(51)【国際特許分類】
   H04L 67/55 20220101AFI20230113BHJP
   H04L 67/562 20220101ALI20230113BHJP
   G06F 15/00 20060101ALI20230113BHJP
【FI】
H04L67/55
H04L67/562
G06F15/00 430
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2021578248
(86)(22)【出願日】2021-06-03
(85)【翻訳文提出日】2021-12-28
(86)【国際出願番号】 CN2021098031
(87)【国際公開番号】W WO2022073354
(87)【国際公開日】2022-04-14
(31)【優先権主張番号】202011081246.8
(32)【優先日】2020-10-10
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
(71)【出願人】
【識別番号】522001943
【氏名又は名称】百度(中国)有限公司
【氏名又は名称原語表記】Baidu (China) Co., Ltd.
【住所又は居所原語表記】Room 9506, Bld.6, 498 Guoshoujing Rd., Zhangjiang High Tech Park, Pudong New Area, Shanghai 200041, China
(74)【代理人】
【識別番号】100101454
【弁理士】
【氏名又は名称】山田 卓二
(74)【代理人】
【識別番号】100189555
【弁理士】
【氏名又は名称】徳山 英浩
(72)【発明者】
【氏名】劉 源旭
(72)【発明者】
【氏名】張 昊
(72)【発明者】
【氏名】喩 聡
(72)【発明者】
【氏名】陶 柯
(57)【要約】
本願は、ビジネス監査報知方法を提供し、コンピュータ分野に関し、具体的にクラウドコンピューティング及びクラウドプラットフォーム技術分野に関する。具体的な実現技術案は、ユーザ端末の操作要求に応答して、監査プラットフォームにビジネス監査要求を送信し、前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成し、前記監査報知メッセージを前記ユーザ端末にプッシュする。この方法は、汎用性があり、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上することができる。本願は、ゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラムをさらに提供した。
【特許請求の範囲】
【請求項1】
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することと、
前記監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成することと、
取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することと、
前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
ことを特徴とするビジネス監査報知方法。
【請求項2】
前記ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することは、
前記操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得することと、
前記ユーザ身元識別子及び前記ミニアプリ識別子に基づいて、ユーザ身元を検証することと、
前記ユーザ身元の検証が成功した場合、前記監査プラットフォームにビジネス監査要求を送信することと、を含む、
ことを特徴とする請求項1に記載の方法。
【請求項3】
前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成することは、
前記操作要求の操作タイプに基づいて、報知テンプレートライブラリから前記操作タイプに整合する監査報知テンプレートを取得することと、
前記監査報知テンプレート及び前記監査任務識別子に基づいて、報知待ちメッセージを生成することと、を含む、
ことを特徴とする請求項1に記載の方法。
【請求項4】
前記監査報知テンプレートに基づいて、報知待ちメッセージを生成した後、前記方法は、
前記報知待ちメッセージを報知待ちメッセージライブラリに記憶することをさらに含む、
ことを特徴とする請求項3に記載の方法。
【請求項5】
前記監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することは、
前記監査任務識別子に基づいて、前記報知待ちメッセージライブラリから前記監査任務識別子に対応する前記報知待ちメッセージを取得することと、
前記監査結果と前記報知待ちメッセージとを組み合わせて、前記監査報知メッセージを生成することと、を含む、
ことを特徴とする請求項4に記載の方法。
【請求項6】
前記報知待ちメッセージに係るフィールドは、監査任務識別子、ユーザ身元識別子、操作パラメータ、前記ビジネス監査要求を提出する時間、前記操作タイプに整合するテンプレートである監査報知テンプレート及び前記監査結果を書き込むためのフィールドである監査結果メッセージ項目を含む、
ことを特徴とする請求項1に記載の方法。
【請求項7】
前記監査結果は、前記監査結果を記憶するための行列であるメッセージキューから取得される、
ことを特徴とする請求項1に記載の方法。
【請求項8】
前記監査報知メッセージを前記ユーザ端末にプッシュすることは、
プッシュアドレスライブラリから前記ユーザ端末のプッシュアドレスを取得することと、
前記プッシュアドレスに従って、前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
ことを特徴とする請求項1に記載の方法。
【請求項9】
前記監査報知メッセージを前記ユーザ端末にプッシュすることは、
所定のプッシュ回数及び所定の時間間隔に従って、前記ユーザ端末に前記監査報知メッセージをプッシュすることを含む、
ことを特徴とする請求項1に記載の方法。
【請求項10】
ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージであるビジネス監査要求を受信することと、
監査結果を取得して記憶することで、前記ゲートウェイが、前記監査結果と、ゲートウェイが前記ビジネス監査要求に対して生成したメッセージである報知待ちメッセージとに基づいて、監査報知メッセージを生成することに供することと、を含む、
ことを特徴とするビジネス監査報知方法。
【請求項11】
前記監査結果を取得して記憶することは、
前記監査結果を受信して、前記監査結果をメッセージキューに記憶することを含む、
ことを特徴とする請求項10に記載の方法。
【請求項12】
前記ビジネス監査要求を受信した後、前記方法は、
ゲートウェイに、監査任務の唯一の識別子である監査任務識別子を返送することをさらに含む、
ことを特徴とする請求項10に記載の方法。
【請求項13】
ユーザ端末の操作要求に応答して、監査プラットフォームにビジネス監査要求を送信し、前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている提出モジュールと、
取得された監査結果及び前記報知待ちメッセージに基づいて監査報知メッセージを生成し、前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュモジュールと、を含む、
ことを特徴とするゲートウェイ。
【請求項14】
前記提出モジュールは、
監査プラットフォームにビジネス監査要求を送信するように配置されている監査提出手段と、
前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている第1の生成手段と、を含む、
ことを特徴とする請求項13に記載のゲートウェイ。
【請求項15】
前記提出モジュールは、
前記操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得するように配置されている解析手段と、
前記ユーザ身元識別子及び前記ミニアプリ識別子に基づいてユーザ身元を検証するように配置されている検証手段と、を含む、
ことを特徴とする請求項14に記載のゲートウェイ。
【請求項16】
前記プッシュモジュールは、
取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成するように配置されている第2の生成手段と、
前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュ手段と、を含む、
ことを特徴とする請求項13に記載のゲートウェイ。
【請求項17】
前記プッシュモジュールは、
監査結果を記憶するための行列であるメッセージキューから前記監査結果を申し込み、前記監査結果を前記第2の生成手段に伝送するように配置されている申し込み手段をさらに含む、
ことを特徴とする請求項16に記載のゲートウェイ。
【請求項18】
前記操作要求のタイプに対応する監査報知テンプレートを記憶するように配置されている報知テンプレートライブラリと、
ユーザにより予め配置された報知を受信するアドレスである、前記ユーザ端末のプッシュアドレスを記憶するように配置されているプッシュアドレスライブラリと、さらに含む、
ことを特徴とする請求項13に記載のゲートウェイ。
【請求項19】
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサと通信接続するメモリとを含む電子機器であって、
前記メモリに、前記少なくとも1つのプロセッサによって実行され得るコマンドが記憶されており、前記コマンドが前記少なくとも1つのプロセッサによって実行されることで、前記少なくとも1つのプロセッサが請求項1~9、10~12のいずれか一項に記載の方法を実行することができる、
ことを特徴とする電子機器。
【請求項20】
コンピュータに請求項1~9、10~12のいずれか一項に記載の方法を実行させるためのコンピュータコマンドを記憶している、
ことを特徴とする非一時的なコンピュータ読取可能な記憶媒体。
【請求項21】
プロセッサによって実行されることで、請求項1~9、10~12のいずれか一項に記載の方法を実現するコンピュータプログラムを含むコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、本願はコンピュータ技術分野に関し、具体的にクラウドコンピューティング及びクラウドプラットフォーム技術に関し、特にビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体に関する。
【背景技術】
【0002】
ミニアプリは、ダウンロードや、インストールを必要とせずに使用可能なアプリケーションとして、ユーザの時間コスト及び携帯電話の内部メモリ容量を節約するとともに、開発者の開発コスト及び普及コストを大幅に低減することができる。
【0003】
ミニアプリ開発者及び第三者の事業者は、例えばミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリの能力を豊富にするために、様々なアクセス使用方式を提供しており、プラットフォームインターフェースを介して操作することをサポートしてもよく、プラットフォームが提供したオープンアプリケーションプログラミングインターフェース(Application Programming Interface,API)を呼び出すことで能力を使用してもよい。
【発明の概要】
【0004】
第1の局面によれば、
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することと、
前記監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成することと、
取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することと、
前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
ビジネス監査報知方法を提供した。
【0005】
第2の局面によれば、
ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージであるビジネス監査要求を受信することと、
監査結果を取得して記憶することで、前記ゲートウェイが、前記監査結果と、ゲートウェイが前記ビジネス監査要求に対して生成したメッセージである報知待ちメッセージとに基づいて、監査報知メッセージを生成することに供することと、を含む、
ビジネス監査報知方法を提供した。
【0006】
第3の局面によれば、
ユーザ端末の操作要求に応答して、監査プラットフォームにビジネス監査要求を送信し、前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている提出モジュールと、
取得された監査結果及び前記報知待ちメッセージに基づいて監査報知メッセージを生成し、前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュモジュールと、を含む、
ゲートウェイを提供した。
【0007】
第4の局面によれば、
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサと通信接続するメモリとを含む電子機器であって、
前記メモリに、前記少なくとも1つのプロセッサによって実行され得るコマンドが記憶されており、前記コマンドが前記少なくとも1つのプロセッサによって実行されることで、前記少なくとも1つのプロセッサがビジネス監査報知方法のいずれか一項に記載の方法を実行することができる、
電子機器を提供した。
【0008】
第5の局面によれば、コンピュータに上述したいずれかのビジネス監査報知方法を実行させるためのコンピュータコマンドを記憶している非一時的なコンピュータ読取可能な記憶媒体を提供した。
【0009】
第6の局面によれば、プロセッサによって実行されることで、上記分散記憶方法のいずれか一項に記載のビジネス監査報知方法を実現するコンピュータプログラムを含むコンピュータプログラム製品を提供した。
【0010】
本願が提供したビジネス監査報知方法は、ユーザ端末により発された操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、監査結果及び報知待ちメッセージに基づいて、監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。この方法は、汎用性があり、任意のタイプのビジネス監査(例えば、ミニアプリ能力の監査)をサポートするとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上することができる。
【0011】
この部分で説明した内容は、本開示の実施例の肝心な又は重要な特徴を表記するためのものでもなく、本開示の範囲を限定するためのものでもないと理解すべきである。本開示の他の特徴は、以下の明細書によって理解し易くなるであろう。
【図面の簡単な説明】
【0012】
図面は、本技術案がよりよく理解されるためのものであり、本願に対する限定を構成しない。
図1】本願の実施例が提供したビジネス監査報知方法の適用場面模式図である。
図2】本願の実施例が提供したビジネス監査報知方法のフローチャートである。
図3】本願の実施例が提供したユーザの操作要求に応答して監査プラットフォームにビジネス監査要求を送信するフローチャートである。
図4】本願の実施例が提供した監査報知メッセージをユーザ端末にプッシュするフローチャートである。
図5】本願の実施例が提供したビジネス監査報知方法のフローチャートである。
図6】本願の実施例が提供したゲートウェイの原理ブロック図である。
図7】本願の実施例が提供した提出モジュールの原理ブロック図である。
図8】本願の実施例が提供した認証手段の原理ブロック図である。
図9】本願の実施例が提供したプッシュモジュールの原理ブロック図である。
図10】本願の実施例が提供した別のプッシュモジュールの原理ブロック図である。
図11】本願の実施例が提供した監査プラットフォームの原理ブロック図である。
図12】本実施例が提供したビジネス監査報知方法のフローチャートである。
図13】本願の実施例のビジネス監査報知方法を実現するための電子機器のブロック図である。
【発明を実施するための形態】
【0013】
以下、図面に合わせて本願の例示的な実施例について説明する。その中、理解に役立つように本願の実施例の各詳細を含み、これらはあくまで例示的なものであると理解すべきである。そのため、当業者は、本願の範囲及び趣旨から逸脱せずに、ただし説明した実施例に対して、様々な変更や、修正をなし得ることを認識すべきである。同様に、明確及び簡明のために、以下の説明において公知の機能及び構成に対する説明を省略している。
【0014】
衝突しない場合、本願の各実施例及び実施例における各特徴は互いに組み合わせることができる。
【0015】
本明細書で使用されるような「及び/又は」という用語は、一つ又は複数の関連列挙アイテムの任意及び全ての組み合わせを含む。
【0016】
本明細書で使用される用語は、特定の実施例を説明するためのものに過ぎず、本願を限定することを意図しない。文脈から別途明らかに指摘しない限り、本明細書で使用されるような「一つ」及び「この」という単数形は、複数形も含むことを意図する。さらに理解すべきことは、本明細書において「含む」及び/又は「・・・で製作される」という用語を使用する場合、前記特徴、全体、ステップ、操作、素子及び/又はアセンブリが存在することを指定するが、一つ又は複数の他の特徴、全体、ステップ、操作、素子、アセンブリ及び/又はそのグループが存在すること、又は追加することを除外しない。
【0017】
本願の実施例が指すミニアプリとは、ダウンロードや、インストールを必要とせずにリアルタイム通信アプリケーション上で実行され得るアプリケーションプログラムであり、一般的に第三者のアプリケーションにロードされる。ミニアプリに対する修正又は操作行為は、監査プラットフォームの人工監査を経る必要があることが多いため、ミニアプリ開発者又は第三者の事業者は、オープンAPIゲートウェイを呼び出す時に監査結果を即時に取得することができず、非同期報知メカニズムにより監査結果を報知する必要がある。
【0018】
しかしながら、現在のオープンAPIゲートウェイは、非同期報知メカニズムをサポートできないため、ミニアプリ能力の開発過程において、監査に係る操作場面ごとに、非同期報知機能をカスタマイズして開発する必要があり、これは開発人力をかかるだけでなく、コード冗長をもたらし、全体のサービス端のアーキテクチャのメンテナンス性を影響した。そして、異なる開発者が開発した非同期報知コードは、報知メッセージが必ず到着することを保証する統一のメカニズムがないため、報知メッセージのプッシュ漏れの状況が存在する可能性があり、ミニアプリ開発者又は第三者の事業者によるミニアプリ能力の使用を影響した。
【0019】
オープンAPIゲートウェイに存在する上記問題に対して、本願はビジネス監査報知方法を提供して、APIゲートウェイの呼び出し及び非同期報知の機能閉ループを実現し、開発者の人力コストを低減し、コード冗長性を低下させ、ビジネスコードのメンテナンス性を向上させるために用いられる。
【0020】
例示的に、図1は本願の実施例が提供したビジネス監査報知方法の適用場面模式図である。図1に示すように、この適用場面は、少なくとも一つのユーザ端末11、ゲートウェイ12及び監査プラットフォーム13を含んでもよく、ユーザ端末11、ゲートウェイ12及び監査プラットフォーム13は、ネットワークを介して通信する。ただし、ユーザ端末11は、ミニアプリ開発者又は第三者の事業者が使用する端末であってもよい。ミニアプリ開発者及び第三者の事業者は、ユーザ端末11で一つ又は複数のミニアプリを開発してもよく、既に存在しているミニアプリを修正してもよい。
【0021】
一部の実施例において、ミニアプリ開発者及び第三者の事業者は、ミニアプリ開発プラットフォームを介してミニアプリ能力を修正することができる。ミニアプリ開発プラットフォームは、ミニアプリを搭載するアプリケーションプログラム(Application,APP)運営者が独立して運営するプラットフォームであってもよく、ミニアプリを搭載するAPPの運営者と連携関係を有する第三者のミニアプリ開発プラットフォームであってもよい。選択的に、このミニアプリ開発プラットフォームは、ミニアプリ開発者ツールとも呼ばれ、ミニアプリを生産し、修正するためのツールである。ミニアプリ開発プラットフォームの具体的な体現形式について、本願はそれを限定しない。
【0022】
ゲートウェイ12は、例えば、ミニアプリパッケージのリリース、ミニアプリ名称の修正などの、ユーザ端末11により提出されたミニアプリ能力に対する操作要求を受信し、操作要求に基づいて監査プラットフォームにビジネス監査要求を送信して、ミニアプリの操作要求が関連規定に合致するか否かを監査し、同時に報知待ちメッセージを生成することで、監査結果を取得した後に監査報知メッセージを生成する。
【0023】
監査プラットフォーム13は、ビジネス監査要求の具体的な内容に応じて、ミニアプリ能力が正当であるか否かを監査し、監査結果をメッセージキューに記憶する。実際の応用において、この監査プラットフォーム13は、クラウドサーバであってもよい。本願の実施例は、監査プラットフォームの具体的な形式を限定せず、それは実際のニーズに応じて確定することができ、ただしは説明を繰り返さない。
【0024】
ゲートウェイ11は、メッセージキューから監査結果を取得し、監査結果と報知待ちメッセージとを組み合わせて監査報知メッセージを取得し、さらに、監査報知メッセージをユーザ端末に送信し、ユーザはユーザ端末から監査結果を知ることができる。
【0025】
以降、具体的な実施例によって本願の技術案を詳細に説明する。説明しておくことは、以下の幾つかの具体的な実施例は、互いに組み合わせてもよく、同じ又は類似な概念又は過程について、幾つかの実施例において説明を繰り返さない可能性がある。
【0026】
第1の態様において、本願の実施例は、ゲートウェイに用いられるビジネス監査報知方法を提供し、このゲートウェイは、APIゲートウェイであってもよく、信号を伝送するために用いられる他のゲートウェイであってもよい。
【0027】
図2は、本願の実施例が提供したビジネス監査報知方法のフローチャートである。図2を参照して、本願の実施例が提供したビジネス監査報知方法は、
ユーザ端末により発された操作要求に応答して、監査プラットフォームにビジネス監査要求を送信するステップ201を含む。
【0028】
ただし、ユーザは、使用しているユーザ端末により操作要求を発する。操作要求は、ミニアプリビジネスに対する要求であってもよく、他のアプリケーションプログラムに対する要求であってもよい。
【0029】
一部の実施例において、操作要求は、ミニアプリの基本情報(例えば、名称、アバター、プロファイル、業界カテゴリなど)の修正、ミニアプリパッケージのリリース、配信材料の提出(検索・推奨feed)及び支払いサービスの開通などを含むが、これらに限られない。
【0030】
説明の便利上、本願の実施例は、ユーザがユーザ端末により操作要求を発すことを、ユーザ端末が操作要求を発すこととして表現する。ただし、ユーザ端末は、携帯電話、携帯情報端末、パーソナルコンピュータ(Personal Computer,PC)、複合機などの、通信機能を有する端末であってよい。
【0031】
一部の実施例において、ユーザは、ミニアプリ開発者であってもよく、第3者の事業者であってもよい。ただし、ミニアプリ開発者は、ミニアプリの所有者又は管理者である。第3者の事業者は、ミニアプリ開発者が承認した第3者の事業者、又は管理者が承認した第3者の事業者である。ミニアプリ開発者又は管理者は、第3者の事業者に対してすべての使用権限を承認してもよく、一部の使用権限のみを承認してもよい。第3者の事業者は、ミニアプリ開発者又は管理者の承認権限内でミニアプリ能力を管理する。
【0032】
一部の実施例において、ミニアプリ開発者又は管理者は、ミニアプリ能力を開発し、修正する開発過程において、監査プラットフォームがミニアプリ能力の正当性を監査するように、監査プラットフォームに監査を要求する必要がある。
【0033】
一部の実施例において、ミニアプリプラットフォームは、例えば、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリ能力を豊富にするために、様々なアクセス使用方式を提供しており、ミニアプリプラットフォームインターフェースを介して操作してもよく、ミニアプリプラットフォームが提供したオープンAPIを呼び出すことで能力を使用してもよい。
【0034】
一部の実施例において、ユーザはゲートウェイに操作要求を発し、ただし、操作要求はミニアプリの基本情報(例えば、名称、アバター、プロファイル、業界カテゴリなど)の修正、ミニアプリパッケージのリリース、配信材料の提出(検索・推奨feed)及び支払いサービスの開通などを含むが、これらに限られない。操作要求には、ユーザ身元識別子及びアプリケーションプログラム識別子が付けられている。本実施例において、アプリケーションプログラム識別子は、任意の形式のミニアプリ識別子であってよい。
【0035】
ただし、ユーザ身元識別子はユーザ身元を識別するための識別子であり、ミニアプリ識別子はミニアプリ身元を識別するための識別子である。操作タイプは、ミニアプリパッケージ、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス及びメッセージサービスを含むが、これらに限られない。操作パラメータは、操作タイプに関連しており、それぞれの操作タイプが異なるパラメータに対応する。例えば、ミニアプリパッケージをリリースする場合、ミニアプリパッケージ識別子(package_id)及びミニアプリパッケージバージョン(package_version)パラメータを提供する必要があり、ミニアプリ名称を修正する場合、ミニアプリ名称(app_name)パラメータを提供する必要がある。
【0036】
一部の実施例において、ゲートウェイは、ユーザ端末により発された操作要求を受信した後に、監査プラットフォームにビジネス監査要求を送信する。監査プラットフォームは、人工、又は、機器と人工とを組合せる監査方式によって、ミニアプリを監査することができる。
【0037】
ただし、監査要求と操作要求とは対応している。一部の実施例において、監査要求のタイプは、ミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、(推奨・検索)材料監査、支払いアカウント監査などを含むが、これらに限られない。
【0038】
ステップ202において、監査プラットフォームが返送した監査任務識別子に基づいて報知待ちメッセージを生成する。
【0039】
ただし、監査任務識別子は、監査プラットフォームがビジネス監査要求に対して割り当てる識別子である。
【0040】
一部の実施例において、監査プラットフォームは、ゲートウェイのビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送する。ゲートウェイは、監査任務識別子を受信した後、報知待ちメッセージを生成する。
【0041】
一部の実施例において、報知待ちメッセージが報知待ちメッセージライブラリに記憶されており、報知待ちメッセージに係るフィールドは、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目を含む。
【0042】
ただし、監査報知テンプレートは、事前に配置されてもよく、操作タイプごとに監査報知テンプレートが個別に配置される。それぞれの監査報知テンプレートは、監査通過サブテンプレート及び監査拒絶サブテンプレートを含んでもよい。
【0043】
一部の実施例において、監査報知テンプレートは、json構成を採用してもよく、例えば、ミニアプリパッケージの監査拒絶サブテンプレートは、以下のフォーマットを採用してもよい。
【0044】
【0045】
ただし、${…}のような形の文字列は、書き込み対象フィールドを表す。書き込み対象フィールドは、提出された要求パラメータ及び監査結果メッセージから、対応するフィールド値を抽出して書き込むことができる。例えば、app_idは、ミニアプリ識別子IDを表し、developer_id及びtp_developer_idは、それぞれ開発者識別子ID及び第3者の事業者識別子IDを表し、reasonフィールドは、監査失敗原因を表し、package_id及びpackage_versionは、それぞれミニアプリパッケージ識別子ID及びミニアプリパッケージバージョンを表す。
【0046】
ステップ203において、取得された監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成する。
【0047】
ただし、監査結果は、監査通過及び監査拒絶を含む。例えば、監査プラットフォームは、ミニアプリ能力が設定された要求に合致すると認定した場合、監査結果が監査通過になる。監査プラットフォームは、ミニアプリ能力が設定された要求に合致しないと認定した場合、監査結果は監査拒絶になる。
【0048】
一部の実施例において、監査プラットフォームは監査員により監査プラットフォームのページ上で人工監査を行う。監査員はミニアプリ能力が設定された要求を満たすと認定した場合、監査結果が監査通過になる。監査員はミニアプリ能力が設定された要求を満たさないと認定した場合、監査結果が監査拒絶になる。
【0049】
一部の実施例において、ゲートウェイは、監査結果と報知待ちメッセージとを組み合わせて、監査報知メッセージを生成する。例えば、ゲートウェイは、監査結果を取得した後、監査結果を報知待ちメッセージの対応するフィールドに加えて、監査報知メッセージを取得する。
【0050】
例えば、監査報知メッセージは、以下のようなフォーマットを採用することができる。
【0051】
ただし、ミニアプリの識別子は「1452365」であり、開発者識別子は「17328232」であり、監査提出時間は「2019-01-14 12:45:10」であり、監査のタイプは「PACKAGE_AUDIT_FAIL」であり、監査失敗の原因は「名称と実際に開いた後の名称とが一致していない」であり、ミニアプリパッケージの識別子は「745815」であり、ミニアプリパッケージのバージョンは「1.3.46」である。
【0052】
ステップ204において、監査報知メッセージをユーザ端末にプッシュする。
【0053】
ゲートウェイは、監査報知メッセージを生成した後、監査報知メッセージをユーザ端末にプッシュして、ユーザがユーザ端末により監査結果を見る。
【0054】
一部の実施例において、図3に示すように、ユーザの操作要求に応答して監査プラットフォームにビジネス監査要求を送信することは、操作要求を解析してユーザ身元識別子及びミニアプリ識別子を取得するステップ301を含む。
【0055】
一部の実施例において、ゲートウェイは、操作要求を受信した後、操作要求を解析して、ユーザ身元、ミニアプリ識別子、操作タイプ及び操作パラメータを取得する。
【0056】
ただし、操作タイプは、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス及びメッセージサービスを含むが、これらに限られない。操作パラメータは、操作タイプに関連しており、それぞれの操作タイプが異なるパラメータに対応する。
【0057】
例えば、ユーザ端末が発した操作要求は、ミニアプリ名称を修正する要求であれば、操作要求にユーザ身元識別子、ミニアプリ識別子、操作タイプ(名称修正)及び名称パラメータ(ミニアプリの新しい名称)が含まれる。
【0058】
一部の実施例において、操作パラメータは、第3者の事業者に対する承認時間を標記するためのタイムスタンプをさらに含み、即ち、第3者の事業者は承認時間内でミニアプリを開発、修正することができる。
【0059】
ステップ302において、ユーザ身元識別子及びミニアプリ識別子に基づいてユーザ身元を検証する。
【0060】
一部の実施例において、ユーザ身元識別子及びミニアプリ識別子に基づいてユーザ身元を認証する。例えば、ゲートウェイは、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っていない場合、直接にユーザ端末に無権限メッセージを返送する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っている場合、後続操作を行う。
【0061】
ステップ303において、ユーザ身元に対する検証が成功した場合、監査プラットフォームにビジネス監査要求を送信する。
【0062】
ユーザ身元に対する検証が成功した場合、ゲートウェイは、監査プラットフォームにビジネス監査要求を送信する。ビジネス監査要求には、ミニアプリ識別子、操作タイプ(名称修正)及び名称パラメータ(ミニアプリの新しい名称)が含まれる。
【0063】
一部の実施例において、監査プラットフォームは、ビジネス監査要求を受信した後、ゲートウェイに監査任務識別子IDを返送し、ゲートウェイが監査任務識別子を受信した後、報知テンプレートライブラリから操作タイプに対応する監査報知テンプレートを取得し、監査報知テンプレート、監査任務識別子に基づいて、報知待ちメッセージを生成し、報知待ちメッセージを報知待ちメッセージライブラリに記憶する。ただし、報知待ちメッセージは、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目を含む。
【0064】
一部の実施例において、監査報知テンプレートは、報知テンプレートライブラリに予め設置され、記憶されているテンプレートである。ただし、それぞれの操作タイプは、1つの監査報知テンプレートに対応する。監査報知テンプレートは、操作タイプに応じて特定されたテンプレートであり、汎用性がある。監査報知テンプレートを報知テンプレートライブラリに記憶して、必要な時に監査報知テンプレートを随時に抽出することで、報知待ちメッセージの生成の効率を向上することでき、そして、エラーの確率を低減することができる。
【0065】
ゲートウェイは、操作要求を受信した後、操作要求のタイプに基づいて、監査報知テンプレートライブラリを照会して、それと整合する監査報知テンプレートを取得し、さらに監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。
【0066】
一部の実施例において、監査プラットフォームは、ビジネス監査要求における監査待ち内容を監査した後、監査結果をメッセージキューに送信する。ただし、メッセージキューは、監査結果を記憶するための行列であり、メッセージキューにおける各メッセージは、いずれも監査任務識別子及び監査結果を含む。
【0067】
一部の実施例において、同一監査結果は、1回でマルチプッシュされることがあり得る。例えば、ミニアプリ開発者と第3者の事業者との両方は、監査結果を取得する必要がある場合、この監査結果がミニアプリの開発者に送信されるだけではなく、第3者の事業者に送信されてもよい。メッセージキューを利用してゲートウェイと監査プラットフォームとを隔離し、1回の監査結果を多方向にプッシュして消費する目的を実現することができる。
【0068】
一部の実施例において、ゲートウェイは、メッセージキューから監査結果を申し込んで、監査結果及び報知待ちメッセージを組み合わせて監査報知メッセージを取得する。
【0069】
例えば、ゲートウェイは、監査任務識別子に従ってメッセージキューから監査結果を取得し、報知待ちメッセージライブラリから報知待ちメッセージを取得し、監査結果を報知待ちメッセージにおける監査結果メッセージ項目に組み込むことで、監査報知メッセージを取得する。
【0070】
実際の応用において、監査報知メッセージを失った状況が現れると、ユーザ端末に監査報知メッセージを再度プッシュする必要がある。監査結果をメッセージキューに記憶することで、ゲートウェイは、メッセージキューから監査結果を複数回申し込んで、ユーザ端末に監査報知メッセージを複数回プッシュすることを実現し、プッシュ漏れの問題を効果的に回避することができる。
【0071】
一部の実施例において、ユーザ端末は、ネットワーク故障などの原因で監査報知メッセージを受信できないことがあるため、ゲートウェイは、所定の時間間隔、所定のプッシュ回数に従ってユーザ端末に監査報知メッセージを複数回プッシュすることができる。例えば、所定の最大プッシュ回数は5回であり、所定の時間間隔は1分、5分、15分、1時間又は6時間である。ゲートウェイは、ユーザ端末に監査報知メッセージを初回にプッシュした後、1分の間隔で第1回の補足プッシュを行い、第1回の補足プッシュを完了した後、5分の間隔で第2回の補足プッシュを行い、第2回の補足プッシュを完了した後、15分の間隔で第3回の補足プッシュを行い、第3回の補足プッシュを完了した後、1時間の間隔で第4回の補足プッシュを行い、第4回の補足プッシュを完了した後、6時間の間隔で第5回の補足プッシュを行う。プッシュ回数及びプッシュ時間間隔を設定することで、プッシュの成功率を向上することができる。
【0072】
一部の実施例において、図4に示すように、監査報知メッセージをユーザ端末にプッシュすることは、
プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得するステップ401を含む。
【0073】
ただし、プッシュアドレスライブラリは、プッシュアドレスを記憶するデータベースである。ユーザ端末のアドレスは、プッシュアドレスライブラリ内に記憶されていることで、ゲートウェイがプッシュアドレスに従ってユーザ端末に監査報知メッセージをプッシュしやすくなる。
【0074】
一部の実施例において、ユーザは、ユーザ端末により自分のアドレスをプッシュアドレスライブラリに予め記憶して、ゲートウェイにより必要な時にプッシュアドレスライブラリから呼び出されることに供する。
【0075】
ステップ402において、プッシュアドレスに従って監査報知メッセージをユーザ端末にプッシュする。
【0076】
ゲートウェイは、監査任務識別子に従ってメッセージキューから対応する監査結果を申し込み、監査任務識別子に従って報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、この監査任務識別子に対応する監査結果及び報知待ちメッセージを組み合わせて、監査報知メッセージを取得する。ゲートウェイは、プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得し、プッシュアドレスに従って監査報知メッセージをユーザ端末に送信する。
【0077】
一部の実施例において、ゲートウェイは、プッシュアドレスに従ってユーザ端末に監査報知メッセージを複数回プッシュして、プッシュの成功率を向上することができる。
【0078】
一部の実施例において、報知待ちメッセージライブラリにおける報知待ちメッセージが長い時間にわたって監査結果の記録がない場合、ゲートウェイは、直接に監査プラットフォームを照会して、監査結果を取得し、監査結果と報知待ちメッセージとを組み合わせてからユーザ端末にプッシュし、それによりメッセージのプッシュ漏れを回避する。
【0079】
本実施例が提供したビジネス監査報知方法は、ユーザ端末が発した操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームが返送した監査任務識別子に基づいて報知待ちメッセージを生成し、監査結果を取得して、監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。この方法は、任意のミニアプリ能力の非同期報知メカニズムをサポートできるとともに、開発者の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上した。
【0080】
第2の態様において、本願の実施例は、ビジネス監査報知方法を提供し、この方法が監査プラットフォームに適用される。
【0081】
図5は、本願の実施例が提供したビジネス監査報知方法のフローチャートである。図5を参照して、本願の実施例は、ビジネス監査報知方法を提供し、
ビジネス監査要求を受信するステップ501を含む。
【0082】
ただし、ビジネス監査要求は、ゲートウェイがユーザ端末により発された操作要求に応答して送信した要求である。
【0083】
一部の実施例において、ゲートウェイは、ユーザ端末より発された操作要求を受信した後、監査プラットフォームにビジネス監査要求を発す。ただし、操作要求は、ミニアプリの基本情報(例えば、名称、アバター、プロファイル、業界カテゴリなど)の修正、ミニアプリパッケージのリリース、配信材料提出(検索・推奨feed)及び支払いサービス開通などを含むが、これらに限られない。ビジネス監査要求は操作要求に基づき、即ち、ビジネス監査要求は操作要求に対応しており、ビジネス監査要求のタイプはミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、(feed・検索)材料監査及び支払いアカウント監査などを含む。
【0084】
ステップ502において、監査結果を取得して記憶して、ゲートウェイが監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成するために供する。
【0085】
ただし、報知待ちメッセージは、ゲートウェイがビジネス監査要求に対して生成したメッセージである。
【0086】
一部の実施例において、監査プラットフォームは、監査人員によって監査するため、監査プラットフォームがビジネス監査要求を受信した後、表示装置によって監査人員にビジネス監査要求を表示することができる。監査人員は、ビジネス監査要求における監査タイプを監査して、関連規定に合致する監査タイプに対して監査通過を下し、関連規定に合致しない監査タイプに対して監査拒絶を下す。
【0087】
一部の実施例において、監査プラットフォームは、監査人員の監査結果を取得した後、監査結果をメッセージキューに送信して、ゲートウェイが必要な時に監査結果を取得し、又はメッセージキューが主動的に監査結果をゲートウェイにプッシュすることに供する。
【0088】
一部の実施例において、監査プラットフォームは、ビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送し、ただし、監査任務識別子は監査任務の唯一の識別子であり、後続のステップにおいて、ゲートウェイが監査任務識別子で報知待ちメッセージ及び監査結果を取得する。
【0089】
例えば、ゲートウェイは、監査任務識別子に従ってメッセージキューから対応する監査結果を申し込み、監査任務識別子に従って報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、監査結果と報知待ちメッセージとを組み合わせて、監査報知メッセージを取得する。
【0090】
本実施例が提供したビジネス監査報知方法は、ビジネス監査要求を受信し、監査結果を受信し、監査結果を記憶して、ゲートウェイが監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成することに供し、監査報知メッセージをユーザ端末にプッシュする。この方法は、任意のビジネス監査の非同期報知メカニズムをサポートできるとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、ビジネスコードのメンテナンス性を向上した。
【0091】
第3の態様において、本願の実施例は、ゲートウェイを提供した。図6は、本願の実施例が提供したゲートウェイの原理ブロック図である。
【0092】
図6を参照して、本願の実施例が提供したゲートウェイは、
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成するように配置されている提出モジュール601と、
取得された監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュするように配置されているプッシュモジュール602とを含む。
【0093】
一部の実施例において、監査結果がメッセージキューから取得される。監査プラットフォームは、監査結果を取得した後、監査結果をメッセージキューに格納して、メッセージキューが監査結果を受信した後、監査結果をプッシュモジュール602に伝送する。或いは、プッシュ手段602は、所定の条件に従って主動的にメッセージキューから監査結果を抽出してもよい。例えば、抽出の時間を毎日8:00~18:00に予め設置して、抽出の時間間隔が30分であり、プッシュ手段602は、この所定時間及び時間間隔に従って監査結果を抽出する。
【0094】
一部の実施例において、図7に示すように、提出モジュール700は、
監査プラットフォームにビジネス監査要求を送信するように配置されている監査提出手段701を含む。
【0095】
一部の実施例において、監査提出手段701は、ユーザ端末により発された操作要求に基づいて監査プラットフォームにビジネス監査要求を送信する。
【0096】
ただし、ユーザ端末は、ミニアプリ開発者又は第3者の事業者が使用するミニアプリを開発する端末である。ユーザは、例えば、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリ能力を豊富にするために、ミニアプリを開発し、或いは修正する。すべての開発及び修正は、監査プラットフォームを介して監査される必要がある。
【0097】
ただし、操作要求は、ミニアプリの基本情報(例えば、名称、アバター、プロファイル、業界カテゴリなど)の修正、ミニアプリパッケージのリリース、配信材料の提出(検索・推奨feed)及び支払いサービスの開通などを含むが、これらに限られない。
【0098】
ただし、ビジネス監査要求は、操作要求に対するものであり、操作要求に応じて、異なる操作要求は、異なるビジネス監査要求に対応している。ビジネス監査要求は、ミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、(推奨・検索)材料監査、支払いアカウント監査などを含むが、これらに限られない。
【0099】
第1の生成手段702は、監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成するように配置されている。
【0100】
一部の実施例において、監査プラットフォームは、ゲートウェイのビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送する。ただし、監査任務識別子は、監査プラットフォームがビジネス監査要求のために割り当てる識別子である。ゲートウェイが監査任務識別子を受信した後、第1の生成手段702が報知待ちメッセージを生成する。
【0101】
一部の実施例において、第1の生成手段702は、操作要求のタイプに基づいて監査報知テンプレートを取得し、ユーザ身元識別子、監査任務識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。
【0102】
ただし、ユーザ身元識別子は、ユーザ身元を示す唯一の識別子である。ビジネス監査提出時間は、監査提出手段が監査プラットフォームに監査任務を提出する時間である。監査報知テンプレートは、事前に配置されてもよく、各種の操作タイプは、報知テンプレートを個別に配置する。各種の報知テンプレートは、監査通過サブテンプレート及び監査拒絶サブテンプレートを含んでもよい。操作パラメータは、操作要求における要求内容であり、操作タイプによって操作パラメータが異なる。例えば、ミニアプリパッケージをリリースする場合、ミニアプリパッケージ識別子(package_id)及びミニアプリパッケージバージョン(package_version)パラメータを提供する必要があり、ミニアプリ名称を修正する場合、ミニアプリ名称(app_name)パラメータを提供する必要がある。監査結果メッセージ項目は、監査結果を書き込むための項目である。第1の生成手段702により生成された報知待ちメッセージのうち、監査結果メッセージ項目は空きである。
【0103】
一部の実施例において、提出モジュール601は、ユーザ端末の身元を認証するように配置されている認証手段をさらに含む。
【0104】
図8に示すように、認証手段800は、
操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得するように配置されている解析サブ手段801を含む。
【0105】
一部の実施例において、操作要求には、ユーザ身元識別子及びミニアプリ識別子が含まれており、解析サブ手段801は、操作要求を解析することで、ユーザ身元識別子及びミニアプリ識別子を取得することができる。
【0106】
検証サブ手段802は、ユーザ身元識別子及びミニアプリ識別子に基づいて、ユーザ身元を検証するように配置されている。
【0107】
一部の実施例において、検証サブ手段802は、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っていない場合、ユーザ端末に無権限メッセージを直接返送し、このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っている場合、後続の操作を行う。
【0108】
図9に示すように、プッシュモジュール900は、
取得された監査結果及び報知待ちメッセージに基づいて、監査報知メッセージを生成するように配置されている第2の生成手段901を含む。
【0109】
ただし、監査結果は、監査通過及び監査拒絶を含む。監査標準に合致する場合、監査プラットフォームは監査通過の監査結果を得て、監査標準に合致しない場合、監査プラットフォームは監査拒絶の監査結果を得る。
【0110】
一部の実施例において、第2の生成手段901は、監査結果を取得した後、監査結果を報知待ちメッセージにおける監査報知メッセージ項目に書き込み、監査報知メッセージを生成する。
【0111】
プッシュ手段902は、監査報知メッセージをユーザ端末にプッシュするように配置されている。
【0112】
一部の実施例において、プッシュ手段902は、プッシュアドレスライブラリから開発者又は第3者の事業者のアドレスを取得し、監査報知メッセージを開発者又は第3者の事業者にプッシュする。
【0113】
一部の実施例において、図10に示すように、プッシュモジュール1000は、第2の生成手段1001、プッシュ手段1002及び申し込み手段1003を含み、ただし、第2の生成手段1001及びプッシュ手段1002の原理及び機能は、第2の生成手段901及びプッシュ手段902と同様であり、ただし説明を繰り返さない。
【0114】
申し込み手段1003は、メッセージキューから監査結果を申し込み、監査結果を第2の生成手段に伝送するように配置されている。
【0115】
説明しておくことは、メッセージキューが監査結果を記憶するための行列である。メッセージキューは、監査プラットフォームに設置されてもよく、ゲートウェイに設置されてもよく、監査プラットフォーム及びゲートウェイから独立して設置されてもよい。メッセージキューを利用して監査プラットフォームとゲートウェイとをデカップリングすることで、1回のプッシュで複数の箇所で消費される目的を実現する。
【0116】
一部の実施例において、ゲートウェイは、監査報知テンプレートを記憶するように配置されている報知テンプレートライブラリ1004をさらに含む。監査報知テンプレートは、報知テンプレートライブラリ1004に予め配置されて記憶されていてもよい。監査報知テンプレートは、操作要求のタイプと整合し、そして、それぞれの操作タイプは、2つの監査報知テンプレート、即ち、監査通過テンプレート及び監査拒絶テンプレートに対応する。監査通過テンプレート及び監査拒絶テンプレートの設置形式は、本願の方法部分で言及されており、ただし説明を繰り返さない。
【0117】
説明しておくことは、報知テンプレートライブラリ1004は、ゲートウェイに設置されてもよく、ゲートウェイから独立した他の手段又はモジュールに設置されてもよく、報知テンプレートを記憶でき、かつ提出モジュール及びプッシュモジュールがこの報知テンプレートライブラリにアクセスできるようにすればよい。
【0118】
プッシュアドレスライブラリ1005は、ユーザ端末のプッシュアドレスを記憶するように配置されている。ただし、プッシュアドレスは、ユーザにより予め配置される報知を受信するアドレスである。
【0119】
一部の実施例において、ミニアプリ開発者及び第3者の事業者は、それぞれのアドレスをプッシュアドレスライブラリに予め設置してもよく、それにより、プッシュモジュールが必要な場合に、ミニアプリ開発者又は第3者の事業者のアドレスを取得しやすくなる。
【0120】
説明しておくことは、プッシュアドレスライブラリ1005は、ゲートウェイに設置されてもよく、ゲートウェイから独立した他の手段又はモジュールに設置されてもよく、アドレスを記憶でき、かつ提出モジュール及びプッシュモジュールがこのプッシュアドレスライブラリにアクセスできるようにすればよい。
【0121】
本実施例が提供したゲートウェイは、提出モジュールを利用して、ユーザ端末の操作要求を受信した場合、監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、プッシュモジュールにより取得された監査結果及び報知待ちメッセージを利用して、監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。このゲートウェイは、汎用性があり、任意タイプのビジネス監査(例えば、ミニアプリ能力の監査)をサポートできるとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上した。
【0122】
第4の態様において、本願の実施例は、監査プラットフォームを提供し、この監査プラットフォームは、アプリケーションプログラムのビジネス、例えば、ミニアプリのビジネスを監査することができる。
【0123】
図11は、本願の実施例が提供した監査プラットフォームの原理ブロック図である。図11に示すように、監査プラットフォーム1100は、
ビジネス監査要求を受信するように配置されている受信モジュール1101を含む。
【0124】
ただし、ビジネス監査要求は、ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージである。
【0125】
取得モジュール1102は、監査結果を取得するように配置されている。
【0126】
一部の実施例において、監査プラットフォームは、監査人員によって人工監査を行う。監査結果は、監査人員が監査要求を監査した結果である。例えば、監査プラットフォームは、監査人員に監査要求、即ち、監査要求における監査事項を表示し、監査人員は、監査事項を監査し、監査結果を得て、この監査結果を監査プラットフォームに伝送する。
【0127】
一部の実施例において、監査プラットフォームは、他の態様によって監査してもよく、例えば、人工と機器とを結合する態様によって監査してもよい。
【0128】
記憶モジュール1103は、監査結果を記憶するように配置されている。
【0129】
一部の実施例において、記憶モジュール1103は、メッセージキューの形で監査結果を記憶する。記憶モジュール1103は、監査プラットフォームに設置されてもよく、監査プラットフォームから独立した他のモジュール又は手段に設置されてもよい。
【0130】
一部の実施例において、監査プラットフォームは、さらに、
ゲートウェイに監査任務識別子を返送するように配置されている任務識別子生成モジュールを含む。ただし、監査任務識別子は、監査任務の唯一の識別子である。
【0131】
本願の実施例が提供した監査プラットフォームは、受信モジュールを利用してビジネス監査要求を受信し、取得モジュールを利用して監査結果を取得し、記憶モジュールを利用して監査結果を記憶する。この監査プラットフォームは、任意タイプのビジネスを監査してもよく、そして、ゲートウェイ開発人員の人力コストを低減し、コード冗長性を低減させ、かつビジネスコードのメンテナンス性を向上することができる。
【0132】
本願の実施例が提供したビジネス監査報知方法がよりよく理解されるために、以下、ユーザ端末、ゲートウェイ及び監査プラットフォームを合わせて、ビジネス監査報知方法をさらに紹介する。
【0133】
図12は、本実施例が提供したビジネス監査報知方法のフローチャートである。図12に示すように、ビジネス監査報知方法は、
ユーザ端末がゲートウェイの提出モジュールに操作要求を送信するステップ1201を含む。
【0134】
ただし、操作要求は、ユーザ身元識別子、ミニアプリ識別子、操作タイプ(名称修正)及び名称パラメータ(ミニアプリの新しい名称)を含む。
【0135】
ステップ1202において、ゲートウェイは、ユーザ身元を認証する。
【0136】
本実施例において、ゲートウェイは、操作要求からユーザ身元識別子、ミニアプリ識別子を解析し、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。ユーザ身元識別子が操作権限を持っていない場合、ユーザ端末に検証失敗メッセージを返送する。ユーザ身元識別子が操作権限を持っている場合、ユーザ端末に検証成功メッセージを返送し、後続のステップを実行し、又は、ユーザ端末に検証成功メッセージを返送せずに、直接に後続のステップを実行する。
【0137】
ステップ1203において、ゲートウェイの監査提出手段は、監査プラットフォームにビジネス監査任務を送信する。
【0138】
ビジネス監査任務は、ゲートウェイが操作要求に基づいて得られた監査任務である。ビジネス監査任務は、ミニアプリ識別子、操作タイプ(名称修正)及び名称パラメータを含む。ユーザ身元に対する検証が成功した場合、ゲートウェイは、監査プラットフォームにビジネス監査要求を送信する。
【0139】
ステップ1204において、監査プラットフォームは、ゲートウェイに監査任務識別子を返送する。
【0140】
本実施例において、監査プラットフォームは、ビジネス監査任務を受信した後、このビジネス監査任務のために1つの唯一の識別子を割り当てって、後続のフローで使用されることに供する。
【0141】
ステップ1205において、ゲートウェイは、報知テンプレートライブラリから監査報知テンプレートを取得する。
【0142】
本実施例において、監査報知テンプレートは、開発者又は第3者の事業者により予め設定され、報知テンプレートライブラリに記憶されているテンプレートである。
【0143】
ステップ1206において、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。
【0144】
本実施例において、ゲートウェイは、監査プラットフォームより返送された監査任務識別子に基づいて、報知テンプレートライブラリから監査報知テンプレートを取得し、ユーザ端末により送信されたユーザ身元識別子、ビジネス監査提出時間及び操作パラメータ、並びに監査結果メッセージ項目を合わせて、報知待ちメッセージを生成する。
【0145】
ステップ1207において、監査プラットフォームは、監査人員の監査結果を受信する。
【0146】
本実施例において、監査プラットフォームは、監査人員に操作パラメータを表示し、監査人員は、操作パラメータに従ってビジネス監査要求を監査し、監査結果を監査プラットフォームに伝送する。
【0147】
ステップ1208において、監査プラットフォームは、監査結果をメッセージキューに記憶する。
【0148】
ステップ1209において、ゲートウェイは、メッセージキューから監査結果を取得する。
【0149】
ステップ1210において、ゲートウェイは、監査任務識別子に基づいて、報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、監査結果及び報知待ちメッセージを組み合わせて、報知メッセージを取得する。
【0150】
ステップ1211において、ゲートウェイは、プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得する。
【0151】
本実施例において、ユーザ端末のプッシュアドレスは、ユーザによりプッシュアドレスライブラリに予め配置されたものである。
【0152】
ステップ1212において、ゲートウェイは、報知メッセージをプッシュアドレスに従ってユーザ端末にプッシュする。
【0153】
本願の実施例によれば、本願は、電子機器及び読取可能な記憶媒体をさらに提供した。
【0154】
図13は、本願の実施例によるビジネス監査報知の方法の電子機器のブロック図である。図13に示すように、電子機器とは、様々な形式のデジタルコンピュータ、例えば、ラップトップ型コンピュータと、デスクトップコンピュータと、ワークステーションと、パーソナル・デジタル・アシスタントと、サーバと、ブレードサーバと、大型コンピュータと、他の適宜なコンピュータとを表す旨である。電子機器は、様々な形式の移動装置、例えば、パーソナル・デジタル・アシスタントと、セルラー電話と、スマートフォンと、ウェアラブル機器と、他の類似する計算装置とを表してもよい。本明細書に示す部品と、それらの接続及び関係と、それらの機能とは単に例示であり、本明細書で説明した及び/又は要求した本願の実現を限定することを意図しない。
【0155】
図13に示すように、この電子機器は、1つ又は複数のプロセッサ1301、メモリ1302、及び各部品を接続するための、高速インターフェース及び低速インターフェースを含むインターフェースを備える。各部品は、異なるバスで互いに接続され、且つ共通のメインボード上に実装されてもよく、又は必要に応じて他の方式で実装されてもよい。プロセッサは、電子機器内で実行されるコマンドを処理することができ、メモリに記憶されて、外部入力・出力装置(例えば、インターフェースに結合する表示機器)上に図形ユーザインターフェース(Graphical User Interface,GUI)の図形情報を表示するコマンドを含む。他の実施形態においては、必要に応じて、複数のプロセッサ及び/又は複数のバスを複数のメモリと一緒に使用してもよい。同様に、複数の電子機器を接続して、各機器が一部の必要な操作を提供してもよい(例えば、サーバアレー、一組のブレードサーバ、又はマルチプロセッサシステムとする)。図13においては、1つのプロセッサ1301を例とする。
【0156】
メモリ1302は、本願が提供した非一時的なコンピュータ読取可能な記憶媒体である。ただし、前記メモリには少なくとも1つのプロセッサにより実行され得るコマンドが記憶されており、前記少なくとも1つのプロセッサに本願が提供したビジネス監査報知の方法を実行させる。本願の非一時的なコンピュータ読取可能な記憶媒体は、コンピュータコマンドを記憶しており、このコンピュータコマンドは、コンピュータに本願が提供したビジネス監査報知の方法を実行させるものである。
【0157】
メモリ1302は、非一時的なコンピュータ読取可能な記憶媒体として、非一時的なソフトウェアプログラム、非一時的なコンピュータ実行可能なプログラム及びモジュール、例えば本願の実施例におけるビジネス監査報知の方法に対応するプログラムコマンド・モジュールを記憶するものである。プロセッサ1301は、メモリ1302に記憶されている非一時的なソフトウェアプログラム、コマンド及びモジュールを実行することで、サーバの各種の機能アプリケーション及びデータ処理を実行し、即ち上記方法実施例におけるビジネス監査報知の方法を実現する。
【0158】
メモリ1302は、プログラム記憶領域及びデータ記憶領域を含んでもよく、ただし、プログラム記憶領域は、オペレーティングシステム、少なくとも1つの機能に必要なアプリケーションプログラムを記憶してもよく、データ記憶領域は、ビジネス監査報知による電子機器の使用により生成されたデータなどを記憶してもよい。また、メモリ1302は、高速ランダムアクセスメモリを含んでもよく、非一時なメモリ、例えば少なくとも1つの磁気ディスク記憶デバイス、フラッシュメモリデバイス、又は他の非一時的なソリッド記憶デバイスを含んでもよい。一部の実施例において、メモリ1302は選択的にプロセッサ1301に対して遠隔に設置されたメモリを含み、これらの遠隔メモリが、ネットワークを介して電子機器に接続されてもよい。上記ネットワークの例示は、インターネット、イントラネット、ローカルエリアネットワーク、移動通信ネットワーク及びそれらの組合を含むが、これらに限られない。
【0159】
ビジネス監査報知の方法の電子機器は、入力装置1303及び出力装置1304をさらに含んでもよい。プロセッサ1301、メモリ1302、入力装置1303及び出力装置1304は、バス又は他の方式で接続されてもよく、図13においてバスを介して接続されることを例とする。
【0160】
入力装置1303は、入力されたデジタル又はキャラクター情報を受信し、ビジネス監査報知方法の電子機器のユーザ設置及び機能制御に関わるキー信号入力を発生してもよく、例えば、タッチスクリーン、キーパッド、マウス、トラックパッド、タッチパッド、インジケーターロッド、1つ又は複数のマウスボタン、トラックボール、レバーなどの入力装置である。出力装置1304は、表示デバイスと、補助照明装置(例えば、LED)と、触覚フィードバック装置(例えば、振動モーター)などを含んでもよい。この表示デバイスは、液晶ディスプレー(LCD)と、発光ダイオード(LED)ディスプレーと、プラズマディスプレーとを含むが、これらに限られない。一部の実施形態において、表示デバイスはタッチスクリーンであってもよい。
【0161】
ただし説明したシステム及び技術の各実施形態は、デジタル電子回路システム、集積回路システム、専用ASIC(専用集積回路)、コンピュータハードウェア、ファームウェア、ソフトウェア、及び/又はそれらの組合せで実現されてもよい。これらの各実施形態は、1つ又は複数のコンピュータプログラムで実施されることを含んでもよく、この1つまたは複数のコンピュータプログラムが、少なくとも1つのプログラマブルプロセッサを含むプログラマブルシステム上で実行及び/又は解釈されてもよく、このプログラマブルプロセッサは、専用又は共通のプログラマブルプロセッサであってもよく、記憶システムと、少なくとも1つの入力装置と、少なくとも1つの出力装置とからデータと命令とを受信し、データと命令とをこの記憶システムと、この少なくとも1つの入力装置と、この少なくとも1つの出力装置とに伝送してもよい。
【0162】
これらの計算プログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、又はコードとも称する)は、プログラマブルプロセッサの機械命令を含み、高級プロセス及び/又はオブジェクト指向のプログラミング言語、及び/又はアセンブリ・機械言語によってこれらの計算プログラムを実施してもよい。本明細書で使用した術語「機械読取可能な媒体」及び「コンピュータ読取可能な媒体」とは、機械命令及び/又はデータをプログラマブルプロセッサに提供するための任意のコンピュータプログラム製品、機器、及び/又は装置(例えば、磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス(PLD))を意味しており、機械読取可能な信号である機械命令を受ける機械読取可能な媒体を含む。術語「機械読取可能な信号」とは、機械命令及び/又はデータをプログラマブルプロセッサに提供するための任意の信号を意味している。
【0163】
ユーザとのインタラクションを提供するために、コンピュータでただし説明したシステム及び技術を実施してもよく、このコンピュータは、ユーザに情報を表示するための表示装置(例えば、CRT(陰極線管)又はLCD(液晶ディスプレー)モニタ)と、キーボード及び指向装置(例えば、マウス又はトラックボール)とを有し、ユーザは、このキーボード及びこの指向装置によって、入力をコンピュータに提供することができる。他の種類の装置は、ユーザとのインタラクションを提供するためのものであってもよく、例えば、ユーザに提供するフィードバックは、任意の形式のセンサーフィードバック(例えば、視覚フィードバック、聴覚フィードバック、又は触覚フィードバック)であってもよく、任意の形式(声入力、語音入力、又は触覚入力を含む)でユーザからの入力を受信してもよい。
【0164】
ただし説明したシステム及び技術は、バックグラウンド部品を含む計算システム(例えば、データサーバとする)、又はミドルウェア部品を含む計算システム(例えば、アプリケーションサーバ)、又はフロントエンド部品を含む計算システム(例えば、グラフィカル・ユーザー・インターフェース又はネットワークブラウザを有するユーザコンピュータ、ユーザはこのグラフィカル・ユーザー・インターフェース又はこのネットワークブラウザを介してただし説明したシステム及び技術の実施形態とインタラクトすることができる)、又はこのようなバックグラウンド部品、ミドルウェア部品、或いはフロントエンド部品の任意の組合せを含む計算システムで実施されてもよい。任意の形式又は媒体のデジタルデータ通信(例えば、通信ネットワーク)を介してシステムの部品を相互に接続してもよい。通信ネットワークの例示は、ローカルエリアネットワーク(LAN)と、広域ネットワーク(WAN)と、インターネットとを含む。
【0165】
コンピュータシステムは、クライアントとサーバとを含んでもよい。クライアントとサーバとは、一般的に互いに離れて、且つ通常に通信ネットワークを介してインタラクトする。相応するコンピュータで実行されるとともに、互いにクライアント-サーバの関係を有するコンピュータプログラムによって、クライアントとサーバとの関係を形成する。
【0166】
本願の実施例は、プロセッサによって実行される際に、上記いずれかのビジネス監査報知方法を実現するコンピュータプログラムを記憶しているコンピュータ読取可能な媒体を提供した。
【0167】
上記に示した様々な形式のフローを利用して、ステップを並び替え、追加又は削除することができると理解すべきである。例えば、本願に記載された各ステップは、並行に実行されてもよいし、順に実行されてもよいし、異なる順序で実行されてもよく、本願が開示した技術案が所望する結果を実現できる限り、本文はただし限定しない。
【0168】
上述した具体的な実施形態は、本願の保護範囲に対する限定を構成しない。当業者は、設計要求や他の要因に応じて、さまざまな修正、組合、サブ組合及び置換を行うことができると理解すべきである。本願の趣旨及び原則の範囲内になされた任意の修正、等価な置換、改進などは、いずれも本願の保護範囲内に含まれるべきである。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
【手続補正書】
【提出日】2021-12-28
【手続補正1】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、本願はコンピュータ技術分野に関し、具体的にクラウドコンピューティング及びクラウドプラットフォーム技術に関し、特にビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラムに関する。
【背景技術】
【0002】
ミニアプリは、ダウンロードや、インストールを必要とせずに使用可能なアプリケーションとして、ユーザの時間コスト及び携帯電話の内部メモリ容量を節約するとともに、開発者の開発コスト及び普及コストを大幅に低減することができる。
【0003】
ミニアプリ開発者及び第三者の事業者は、例えばミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリの能力を豊富にするために、様々なアクセス使用方式を提供しており、プラットフォームインターフェースを介して操作することをサポートしてもよく、プラットフォームが提供したオープンアプリケーションプログラミングインターフェース(Application Programming Interface,API)を呼び出すことで能力を使用してもよい。
【発明の概要】
【0004】
第1の局面によれば、
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することと、
前記監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成することと、
取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することと、
前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
ビジネス監査報知方法を提供した。
【0005】
第2の局面によれば、
ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージであるビジネス監査要求を受信することと、
監査結果を取得して記憶することで、前記ゲートウェイが、前記監査結果と、ゲートウェイが前記ビジネス監査要求に対して生成したメッセージである報知待ちメッセージとに基づいて、監査報知メッセージを生成することに供することと、を含む、
ビジネス監査報知方法を提供した。
【0006】
第3の局面によれば、
ユーザ端末の操作要求に応答して、監査プラットフォームにビジネス監査要求を送信し、前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている提出モジュールと、
取得された監査結果及び前記報知待ちメッセージに基づいて監査報知メッセージを生成し、前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュモジュールと、を含む、
ゲートウェイを提供した。
【0007】
第4の局面によれば、
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサと通信接続するメモリとを含む電子機器であって、
前記メモリに、前記少なくとも1つのプロセッサによって実行され得るコマンドが記憶されており、前記コマンドが前記少なくとも1つのプロセッサによって実行されることで、前記少なくとも1つのプロセッサがビジネス監査報知方法のいずれか一項に記載の方法を実行することができる、
電子機器を提供した。
【0008】
第5の局面によれば、コンピュータに上述したいずれかのビジネス監査報知方法を実行させるためのコンピュータコマンドを記憶している非一時的なコンピュータ読取可能な記憶媒体を提供した。
【0009】
第6の局面によれば、プロセッサによって実行されることで、上記分散記憶方法のいずれか一項に記載のビジネス監査報知方法を実現するコンピュータプログラムを提供した。
【0010】
本願が提供したビジネス監査報知方法は、ユーザ端末により発された操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、監査結果及び報知待ちメッセージに基づいて、監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。この方法は、汎用性があり、任意のタイプのビジネス監査(例えば、ミニアプリ能力の監査)をサポートするとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上することができる。
【0011】
この部分で説明した内容は、本開示の実施例の肝心な又は重要な特徴を表記するためのものでもなく、本開示の範囲を限定するためのものでもないと理解すべきである。本開示の他の特徴は、以下の明細書によって理解し易くなるであろう。
【図面の簡単な説明】
【0012】
図面は、本技術案がよりよく理解されるためのものであり、本願に対する限定を構成しない。
図1】本願の実施例が提供したビジネス監査報知方法の適用場面模式図である。
図2】本願の実施例が提供したビジネス監査報知方法のフローチャートである。
図3】本願の実施例が提供したユーザの操作要求に応答して監査プラットフォームにビジネス監査要求を送信するフローチャートである。
図4】本願の実施例が提供した監査報知メッセージをユーザ端末にプッシュするフローチャートである。
図5】本願の実施例が提供したビジネス監査報知方法のフローチャートである。
図6】本願の実施例が提供したゲートウェイの原理ブロック図である。
図7】本願の実施例が提供した提出モジュールの原理ブロック図である。
図8】本願の実施例が提供した認証手段の原理ブロック図である。
図9】本願の実施例が提供したプッシュモジュールの原理ブロック図である。
図10】本願の実施例が提供した別のプッシュモジュールの原理ブロック図である。
図11】本願の実施例が提供した監査プラットフォームの原理ブロック図である。
図12】本実施例が提供したビジネス監査報知方法のフローチャートである。
図13】本願の実施例のビジネス監査報知方法を実現するための電子機器のブロック図である。
【発明を実施するための形態】
【0013】
以下、図面に合わせて本願の例示的な実施例について説明する。その中、理解に役立つように本願の実施例の各詳細を含み、これらはあくまで例示的なものであると理解すべきである。そのため、当業者は、本願の範囲及び趣旨から逸脱せずに、ただし説明した実施例に対して、様々な変更や、修正をなし得ることを認識すべきである。同様に、明確及び簡明のために、以下の説明において公知の機能及び構成に対する説明を省略している。
【0014】
衝突しない場合、本願の各実施例及び実施例における各特徴は互いに組み合わせることができる。
【0015】
本明細書で使用されるような「及び/又は」という用語は、一つ又は複数の関連列挙アイテムの任意及び全ての組み合わせを含む。
【0016】
本明細書で使用される用語は、特定の実施例を説明するためのものに過ぎず、本願を限定することを意図しない。文脈から別途明らかに指摘しない限り、本明細書で使用されるような「一つ」及び「この」という単数形は、複数形も含むことを意図する。さらに理解すべきことは、本明細書において「含む」及び/又は「・・・で製作される」という用語を使用する場合、前記特徴、全体、ステップ、操作、素子及び/又はアセンブリが存在することを指定するが、一つ又は複数の他の特徴、全体、ステップ、操作、素子、アセンブリ及び/又はそのグループが存在すること、又は追加することを除外しない。
【0017】
本願の実施例が指すミニアプリとは、ダウンロードや、インストールを必要とせずにリアルタイム通信アプリケーション上で実行され得るアプリケーションプログラムであり、一般的に第三者のアプリケーションにロードされる。ミニアプリに対する修正又は操作行為は、監査プラットフォームの人工監査を経る必要があることが多いため、ミニアプリ開発者又は第三者の事業者は、オープンAPIゲートウェイを呼び出す時に監査結果を即時に取得することができず、非同期報知メカニズムにより監査結果を報知する必要がある。
【0018】
しかしながら、現在のオープンAPIゲートウェイは、非同期報知メカニズムをサポートできないため、ミニアプリ能力の開発過程において、監査に係る操作場面ごとに、非同期報知機能をカスタマイズして開発する必要があり、これは開発人力をかかるだけでなく、コード冗長をもたらし、全体のサービス端のアーキテクチャのメンテナンス性を影響した。そして、異なる開発者が開発した非同期報知コードは、報知メッセージが必ず到着することを保証する統一のメカニズムがないため、報知メッセージのプッシュ漏れの状況が存在する可能性があり、ミニアプリ開発者又は第三者の事業者によるミニアプリ能力の使用を影響した。
【0019】
オープンAPIゲートウェイに存在する上記問題に対して、本願はビジネス監査報知方法を提供して、APIゲートウェイの呼び出し及び非同期報知の機能閉ループを実現し、開発者の人力コストを低減し、コード冗長性を低下させ、ビジネスコードのメンテナンス性を向上させるために用いられる。
【0020】
例示的に、図1は本願の実施例が提供したビジネス監査報知方法の適用場面模式図である。図1に示すように、この適用場面は、少なくとも一つのユーザ端末11、ゲートウェイ12及び監査プラットフォーム13を含んでもよく、ユーザ端末11、ゲートウェイ12及び監査プラットフォーム13は、ネットワークを介して通信する。ただし、ユーザ端末11は、ミニアプリ開発者又は第三者の事業者が使用する端末であってもよい。ミニアプリ開発者及び第三者の事業者は、ユーザ端末11で一つ又は複数のミニアプリを開発してもよく、既に存在しているミニアプリを修正してもよい。
【0021】
一部の実施例において、ミニアプリ開発者及び第三者の事業者は、ミニアプリ開発プラットフォームを介してミニアプリ能力を修正することができる。ミニアプリ開発プラットフォームは、ミニアプリを搭載するアプリケーションプログラム(Application,APP)運営者が独立して運営するプラットフォームであってもよく、ミニアプリを搭載するAPPの運営者と連携関係を有する第三者のミニアプリ開発プラットフォームであってもよい。選択的に、このミニアプリ開発プラットフォームは、ミニアプリ開発者ツールとも呼ばれ、ミニアプリを生産し、修正するためのツールである。ミニアプリ開発プラットフォームの具体的な体現形式について、本願はそれを限定しない。
【0022】
ゲートウェイ12は、例えば、ミニアプリパッケージのリリース、ミニアプリ名称の修正などの、ユーザ端末11により提出されたミニアプリ能力に対する操作要求を受信し、操作要求に基づいて監査プラットフォームにビジネス監査要求を送信して、ミニアプリの操作要求が関連規定に合致するか否かを監査し、同時に報知待ちメッセージを生成することで、監査結果を取得した後に監査報知メッセージを生成する。
【0023】
監査プラットフォーム13は、ビジネス監査要求の具体的な内容に応じて、ミニアプリ能力が正当であるか否かを監査し、監査結果をメッセージキューに記憶する。実際の応用において、この監査プラットフォーム13は、クラウドサーバであってもよい。本願の実施例は、監査プラットフォームの具体的な形式を限定せず、それは実際のニーズに応じて確定することができ、ただしは説明を繰り返さない。
【0024】
ゲートウェイ11は、メッセージキューから監査結果を取得し、監査結果と報知待ちメッセージとを組み合わせて監査報知メッセージを取得し、さらに、監査報知メッセージをユーザ端末に送信し、ユーザはユーザ端末から監査結果を知ることができる。
【0025】
以降、具体的な実施例によって本願の技術案を詳細に説明する。説明しておくことは、以下の幾つかの具体的な実施例は、互いに組み合わせてもよく、同じ又は類似な概念又は過程について、幾つかの実施例において説明を繰り返さない可能性がある。
【0026】
第1の態様において、本願の実施例は、ゲートウェイに用いられるビジネス監査報知方法を提供し、このゲートウェイは、APIゲートウェイであってもよく、信号を伝送するために用いられる他のゲートウェイであってもよい。
【0027】
図2は、本願の実施例が提供したビジネス監査報知方法のフローチャートである。図2を参照して、本願の実施例が提供したビジネス監査報知方法は、
ユーザ端末により発された操作要求に応答して、監査プラットフォームにビジネス監査要求を送信するステップ201を含む。
【0028】
ただし、ユーザは、使用しているユーザ端末により操作要求を発する。操作要求は、ミニアプリビジネスに対する要求であってもよく、他のアプリケーションプログラムに対する要求であってもよい。
【0029】
一部の実施例において、操作要求は、ミニアプリの基本情報(例えば、名称、アバター、プロファイル、業界カテゴリなど)の修正、ミニアプリパッケージのリリース、配信材料の提出(検索・推奨feed)及び支払いサービスの開通などを含むが、これらに限られない。
【0030】
説明の便利上、本願の実施例は、ユーザがユーザ端末により操作要求を発すことを、ユーザ端末が操作要求を発すこととして表現する。ただし、ユーザ端末は、携帯電話、携帯情報端末、パーソナルコンピュータ(Personal Computer,PC)、複合機などの、通信機能を有する端末であってよい。
【0031】
一部の実施例において、ユーザは、ミニアプリ開発者であってもよく、第3者の事業者であってもよい。ただし、ミニアプリ開発者は、ミニアプリの所有者又は管理者である。第3者の事業者は、ミニアプリ開発者が承認した第3者の事業者、又は管理者が承認した第3者の事業者である。ミニアプリ開発者又は管理者は、第3者の事業者に対してすべての使用権限を承認してもよく、一部の使用権限のみを承認してもよい。第3者の事業者は、ミニアプリ開発者又は管理者の承認権限内でミニアプリ能力を管理する。
【0032】
一部の実施例において、ミニアプリ開発者又は管理者は、ミニアプリ能力を開発し、修正する開発過程において、監査プラットフォームがミニアプリ能力の正当性を監査するように、監査プラットフォームに監査を要求する必要がある。
【0033】
一部の実施例において、ミニアプリプラットフォームは、例えば、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリ能力を豊富にするために、様々なアクセス使用方式を提供しており、ミニアプリプラットフォームインターフェースを介して操作してもよく、ミニアプリプラットフォームが提供したオープンAPIを呼び出すことで能力を使用してもよい。
【0034】
一部の実施例において、ユーザはゲートウェイに操作要求を発し、ただし、操作要求はミニアプリの基本情報(例えば、名称、アバター、プロファイル、業界カテゴリなど)の修正、ミニアプリパッケージのリリース、配信材料の提出(検索・推奨feed)及び支払いサービスの開通などを含むが、これらに限られない。操作要求には、ユーザ身元識別子及びアプリケーションプログラム識別子が付けられている。本実施例において、アプリケーションプログラム識別子は、任意の形式のミニアプリ識別子であってよい。
【0035】
ただし、ユーザ身元識別子はユーザ身元を識別するための識別子であり、ミニアプリ識別子はミニアプリ身元を識別するための識別子である。操作タイプは、ミニアプリパッケージ、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス及びメッセージサービスを含むが、これらに限られない。操作パラメータは、操作タイプに関連しており、それぞれの操作タイプが異なるパラメータに対応する。例えば、ミニアプリパッケージをリリースする場合、ミニアプリパッケージ識別子(package_id)及びミニアプリパッケージバージョン(package_version)パラメータを提供する必要があり、ミニアプリ名称を修正する場合、ミニアプリ名称(app_name)パラメータを提供する必要がある。
【0036】
一部の実施例において、ゲートウェイは、ユーザ端末により発された操作要求を受信した後に、監査プラットフォームにビジネス監査要求を送信する。監査プラットフォームは、人工、又は、機器と人工とを組合せる監査方式によって、ミニアプリを監査することができる。
【0037】
ただし、監査要求と操作要求とは対応している。一部の実施例において、監査要求のタイプは、ミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、(推奨・検索)材料監査、支払いアカウント監査などを含むが、これらに限られない。
【0038】
ステップ202において、監査プラットフォームが返送した監査任務識別子に基づいて報知待ちメッセージを生成する。
【0039】
ただし、監査任務識別子は、監査プラットフォームがビジネス監査要求に対して割り当てる識別子である。
【0040】
一部の実施例において、監査プラットフォームは、ゲートウェイのビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送する。ゲートウェイは、監査任務識別子を受信した後、報知待ちメッセージを生成する。
【0041】
一部の実施例において、報知待ちメッセージが報知待ちメッセージライブラリに記憶されており、報知待ちメッセージに係るフィールドは、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目を含む。
【0042】
ただし、監査報知テンプレートは、事前に配置されてもよく、操作タイプごとに監査報知テンプレートが個別に配置される。それぞれの監査報知テンプレートは、監査通過サブテンプレート及び監査拒絶サブテンプレートを含んでもよい。
【0043】
一部の実施例において、監査報知テンプレートは、json構成を採用してもよく、例えば、ミニアプリパッケージの監査拒絶サブテンプレートは、以下のフォーマットを採用してもよい。
【0044】
【0045】
ただし、${…}のような形の文字列は、書き込み対象フィールドを表す。書き込み対象フィールドは、提出された要求パラメータ及び監査結果メッセージから、対応するフィールド値を抽出して書き込むことができる。例えば、app_idは、ミニアプリ識別子IDを表し、developer_id及びtp_developer_idは、それぞれ開発者識別子ID及び第3者の事業者識別子IDを表し、reasonフィールドは、監査失敗原因を表し、package_id及びpackage_versionは、それぞれミニアプリパッケージ識別子ID及びミニアプリパッケージバージョンを表す。
【0046】
ステップ203において、取得された監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成する。
【0047】
ただし、監査結果は、監査通過及び監査拒絶を含む。例えば、監査プラットフォームは、ミニアプリ能力が設定された要求に合致すると認定した場合、監査結果が監査通過になる。監査プラットフォームは、ミニアプリ能力が設定された要求に合致しないと認定した場合、監査結果は監査拒絶になる。
【0048】
一部の実施例において、監査プラットフォームは監査員により監査プラットフォームのページ上で人工監査を行う。監査員はミニアプリ能力が設定された要求を満たすと認定した場合、監査結果が監査通過になる。監査員はミニアプリ能力が設定された要求を満たさないと認定した場合、監査結果が監査拒絶になる。
【0049】
一部の実施例において、ゲートウェイは、監査結果と報知待ちメッセージとを組み合わせて、監査報知メッセージを生成する。例えば、ゲートウェイは、監査結果を取得した後、監査結果を報知待ちメッセージの対応するフィールドに加えて、監査報知メッセージを取得する。
【0050】
例えば、監査報知メッセージは、以下のようなフォーマットを採用することができる。
【0051】
ただし、ミニアプリの識別子は「1452365」であり、開発者識別子は「17328232」であり、監査提出時間は「2019-01-14 12:45:10」であり、監査のタイプは「PACKAGE_AUDIT_FAIL」であり、監査失敗の原因は「名称と実際に開いた後の名称とが一致していない」であり、ミニアプリパッケージの識別子は「745815」であり、ミニアプリパッケージのバージョンは「1.3.46」である。
【0052】
ステップ204において、監査報知メッセージをユーザ端末にプッシュする。
【0053】
ゲートウェイは、監査報知メッセージを生成した後、監査報知メッセージをユーザ端末にプッシュして、ユーザがユーザ端末により監査結果を見る。
【0054】
一部の実施例において、図3に示すように、ユーザの操作要求に応答して監査プラットフォームにビジネス監査要求を送信することは、操作要求を解析してユーザ身元識別子及びミニアプリ識別子を取得するステップ301を含む。
【0055】
一部の実施例において、ゲートウェイは、操作要求を受信した後、操作要求を解析して、ユーザ身元、ミニアプリ識別子、操作タイプ及び操作パラメータを取得する。
【0056】
ただし、操作タイプは、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス及びメッセージサービスを含むが、これらに限られない。操作パラメータは、操作タイプに関連しており、それぞれの操作タイプが異なるパラメータに対応する。
【0057】
例えば、ユーザ端末が発した操作要求は、ミニアプリ名称を修正する要求であれば、操作要求にユーザ身元識別子、ミニアプリ識別子、操作タイプ(名称修正)及び名称パラメータ(ミニアプリの新しい名称)が含まれる。
【0058】
一部の実施例において、操作パラメータは、第3者の事業者に対する承認時間を標記するためのタイムスタンプをさらに含み、即ち、第3者の事業者は承認時間内でミニアプリを開発、修正することができる。
【0059】
ステップ302において、ユーザ身元識別子及びミニアプリ識別子に基づいてユーザ身元を検証する。
【0060】
一部の実施例において、ユーザ身元識別子及びミニアプリ識別子に基づいてユーザ身元を認証する。例えば、ゲートウェイは、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っていない場合、直接にユーザ端末に無権限メッセージを返送する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っている場合、後続操作を行う。
【0061】
ステップ303において、ユーザ身元に対する検証が成功した場合、監査プラットフォームにビジネス監査要求を送信する。
【0062】
ユーザ身元に対する検証が成功した場合、ゲートウェイは、監査プラットフォームにビジネス監査要求を送信する。ビジネス監査要求には、ミニアプリ識別子、操作タイプ(名称修正)及び名称パラメータ(ミニアプリの新しい名称)が含まれる。
【0063】
一部の実施例において、監査プラットフォームは、ビジネス監査要求を受信した後、ゲートウェイに監査任務識別子IDを返送し、ゲートウェイが監査任務識別子を受信した後、報知テンプレートライブラリから操作タイプに対応する監査報知テンプレートを取得し、監査報知テンプレート、監査任務識別子に基づいて、報知待ちメッセージを生成し、報知待ちメッセージを報知待ちメッセージライブラリに記憶する。ただし、報知待ちメッセージは、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目を含む。
【0064】
一部の実施例において、監査報知テンプレートは、報知テンプレートライブラリに予め設置され、記憶されているテンプレートである。ただし、それぞれの操作タイプは、1つの監査報知テンプレートに対応する。監査報知テンプレートは、操作タイプに応じて特定されたテンプレートであり、汎用性がある。監査報知テンプレートを報知テンプレートライブラリに記憶して、必要な時に監査報知テンプレートを随時に抽出することで、報知待ちメッセージの生成の効率を向上することでき、そして、エラーの確率を低減することができる。
【0065】
ゲートウェイは、操作要求を受信した後、操作要求のタイプに基づいて、監査報知テンプレートライブラリを照会して、それと整合する監査報知テンプレートを取得し、さらに監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。
【0066】
一部の実施例において、監査プラットフォームは、ビジネス監査要求における監査待ち内容を監査した後、監査結果をメッセージキューに送信する。ただし、メッセージキューは、監査結果を記憶するための行列であり、メッセージキューにおける各メッセージは、いずれも監査任務識別子及び監査結果を含む。
【0067】
一部の実施例において、同一監査結果は、1回でマルチプッシュされることがあり得る。例えば、ミニアプリ開発者と第3者の事業者との両方は、監査結果を取得する必要がある場合、この監査結果がミニアプリの開発者に送信されるだけではなく、第3者の事業者に送信されてもよい。メッセージキューを利用してゲートウェイと監査プラットフォームとを隔離し、1回の監査結果を多方向にプッシュして消費する目的を実現することができる。
【0068】
一部の実施例において、ゲートウェイは、メッセージキューから監査結果を申し込んで、監査結果及び報知待ちメッセージを組み合わせて監査報知メッセージを取得する。
【0069】
例えば、ゲートウェイは、監査任務識別子に従ってメッセージキューから監査結果を取得し、報知待ちメッセージライブラリから報知待ちメッセージを取得し、監査結果を報知待ちメッセージにおける監査結果メッセージ項目に組み込むことで、監査報知メッセージを取得する。
【0070】
実際の応用において、監査報知メッセージを失った状況が現れると、ユーザ端末に監査報知メッセージを再度プッシュする必要がある。監査結果をメッセージキューに記憶することで、ゲートウェイは、メッセージキューから監査結果を複数回申し込んで、ユーザ端末に監査報知メッセージを複数回プッシュすることを実現し、プッシュ漏れの問題を効果的に回避することができる。
【0071】
一部の実施例において、ユーザ端末は、ネットワーク故障などの原因で監査報知メッセージを受信できないことがあるため、ゲートウェイは、所定の時間間隔、所定のプッシュ回数に従ってユーザ端末に監査報知メッセージを複数回プッシュすることができる。例えば、所定の最大プッシュ回数は5回であり、所定の時間間隔は1分、5分、15分、1時間又は6時間である。ゲートウェイは、ユーザ端末に監査報知メッセージを初回にプッシュした後、1分の間隔で第1回の補足プッシュを行い、第1回の補足プッシュを完了した後、5分の間隔で第2回の補足プッシュを行い、第2回の補足プッシュを完了した後、15分の間隔で第3回の補足プッシュを行い、第3回の補足プッシュを完了した後、1時間の間隔で第4回の補足プッシュを行い、第4回の補足プッシュを完了した後、6時間の間隔で第5回の補足プッシュを行う。プッシュ回数及びプッシュ時間間隔を設定することで、プッシュの成功率を向上することができる。
【0072】
一部の実施例において、図4に示すように、監査報知メッセージをユーザ端末にプッシュすることは、
プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得するステップ401を含む。
【0073】
ただし、プッシュアドレスライブラリは、プッシュアドレスを記憶するデータベースである。ユーザ端末のアドレスは、プッシュアドレスライブラリ内に記憶されていることで、ゲートウェイがプッシュアドレスに従ってユーザ端末に監査報知メッセージをプッシュしやすくなる。
【0074】
一部の実施例において、ユーザは、ユーザ端末により自分のアドレスをプッシュアドレスライブラリに予め記憶して、ゲートウェイにより必要な時にプッシュアドレスライブラリから呼び出されることに供する。
【0075】
ステップ402において、プッシュアドレスに従って監査報知メッセージをユーザ端末にプッシュする。
【0076】
ゲートウェイは、監査任務識別子に従ってメッセージキューから対応する監査結果を申し込み、監査任務識別子に従って報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、この監査任務識別子に対応する監査結果及び報知待ちメッセージを組み合わせて、監査報知メッセージを取得する。ゲートウェイは、プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得し、プッシュアドレスに従って監査報知メッセージをユーザ端末に送信する。
【0077】
一部の実施例において、ゲートウェイは、プッシュアドレスに従ってユーザ端末に監査報知メッセージを複数回プッシュして、プッシュの成功率を向上することができる。
【0078】
一部の実施例において、報知待ちメッセージライブラリにおける報知待ちメッセージが長い時間にわたって監査結果の記録がない場合、ゲートウェイは、直接に監査プラットフォームを照会して、監査結果を取得し、監査結果と報知待ちメッセージとを組み合わせてからユーザ端末にプッシュし、それによりメッセージのプッシュ漏れを回避する。
【0079】
本実施例が提供したビジネス監査報知方法は、ユーザ端末が発した操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームが返送した監査任務識別子に基づいて報知待ちメッセージを生成し、監査結果を取得して、監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。この方法は、任意のミニアプリ能力の非同期報知メカニズムをサポートできるとともに、開発者の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上した。
【0080】
第2の態様において、本願の実施例は、ビジネス監査報知方法を提供し、この方法が監査プラットフォームに適用される。
【0081】
図5は、本願の実施例が提供したビジネス監査報知方法のフローチャートである。図5を参照して、本願の実施例は、ビジネス監査報知方法を提供し、
ビジネス監査要求を受信するステップ501を含む。
【0082】
ただし、ビジネス監査要求は、ゲートウェイがユーザ端末により発された操作要求に応答して送信した要求である。
【0083】
一部の実施例において、ゲートウェイは、ユーザ端末より発された操作要求を受信した後、監査プラットフォームにビジネス監査要求を発す。ただし、操作要求は、ミニアプリの基本情報(例えば、名称、アバター、プロファイル、業界カテゴリなど)の修正、ミニアプリパッケージのリリース、配信材料提出(検索・推奨feed)及び支払いサービス開通などを含むが、これらに限られない。ビジネス監査要求は操作要求に基づき、即ち、ビジネス監査要求は操作要求に対応しており、ビジネス監査要求のタイプはミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、(feed・検索)材料監査及び支払いアカウント監査などを含む。
【0084】
ステップ502において、監査結果を取得して記憶して、ゲートウェイが監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成するために供する。
【0085】
ただし、報知待ちメッセージは、ゲートウェイがビジネス監査要求に対して生成したメッセージである。
【0086】
一部の実施例において、監査プラットフォームは、監査人員によって監査するため、監査プラットフォームがビジネス監査要求を受信した後、表示装置によって監査人員にビジネス監査要求を表示することができる。監査人員は、ビジネス監査要求における監査タイプを監査して、関連規定に合致する監査タイプに対して監査通過を下し、関連規定に合致しない監査タイプに対して監査拒絶を下す。
【0087】
一部の実施例において、監査プラットフォームは、監査人員の監査結果を取得した後、監査結果をメッセージキューに送信して、ゲートウェイが必要な時に監査結果を取得し、又はメッセージキューが主動的に監査結果をゲートウェイにプッシュすることに供する。
【0088】
一部の実施例において、監査プラットフォームは、ビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送し、ただし、監査任務識別子は監査任務の唯一の識別子であり、後続のステップにおいて、ゲートウェイが監査任務識別子で報知待ちメッセージ及び監査結果を取得する。
【0089】
例えば、ゲートウェイは、監査任務識別子に従ってメッセージキューから対応する監査結果を申し込み、監査任務識別子に従って報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、監査結果と報知待ちメッセージとを組み合わせて、監査報知メッセージを取得する。
【0090】
本実施例が提供したビジネス監査報知方法は、ビジネス監査要求を受信し、監査結果を受信し、監査結果を記憶して、ゲートウェイが監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成することに供し、監査報知メッセージをユーザ端末にプッシュする。この方法は、任意のビジネス監査の非同期報知メカニズムをサポートできるとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、ビジネスコードのメンテナンス性を向上した。
【0091】
第3の態様において、本願の実施例は、ゲートウェイを提供した。図6は、本願の実施例が提供したゲートウェイの原理ブロック図である。
【0092】
図6を参照して、本願の実施例が提供したゲートウェイは、
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成するように配置されている提出モジュール601と、
取得された監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュするように配置されているプッシュモジュール602とを含む。
【0093】
一部の実施例において、監査結果がメッセージキューから取得される。監査プラットフォームは、監査結果を取得した後、監査結果をメッセージキューに格納して、メッセージキューが監査結果を受信した後、監査結果をプッシュモジュール602に伝送する。或いは、プッシュ手段602は、所定の条件に従って主動的にメッセージキューから監査結果を抽出してもよい。例えば、抽出の時間を毎日8:00~18:00に予め設置して、抽出の時間間隔が30分であり、プッシュ手段602は、この所定時間及び時間間隔に従って監査結果を抽出する。
【0094】
一部の実施例において、図7に示すように、提出モジュール700は、
監査プラットフォームにビジネス監査要求を送信するように配置されている監査提出手段701を含む。
【0095】
一部の実施例において、監査提出手段701は、ユーザ端末により発された操作要求に基づいて監査プラットフォームにビジネス監査要求を送信する。
【0096】
ただし、ユーザ端末は、ミニアプリ開発者又は第3者の事業者が使用するミニアプリを開発する端末である。ユーザは、例えば、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリ能力を豊富にするために、ミニアプリを開発し、或いは修正する。すべての開発及び修正は、監査プラットフォームを介して監査される必要がある。
【0097】
ただし、操作要求は、ミニアプリの基本情報(例えば、名称、アバター、プロファイル、業界カテゴリなど)の修正、ミニアプリパッケージのリリース、配信材料の提出(検索・推奨feed)及び支払いサービスの開通などを含むが、これらに限られない。
【0098】
ただし、ビジネス監査要求は、操作要求に対するものであり、操作要求に応じて、異なる操作要求は、異なるビジネス監査要求に対応している。ビジネス監査要求は、ミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、(推奨・検索)材料監査、支払いアカウント監査などを含むが、これらに限られない。
【0099】
第1の生成手段702は、監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成するように配置されている。
【0100】
一部の実施例において、監査プラットフォームは、ゲートウェイのビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送する。ただし、監査任務識別子は、監査プラットフォームがビジネス監査要求のために割り当てる識別子である。ゲートウェイが監査任務識別子を受信した後、第1の生成手段702が報知待ちメッセージを生成する。
【0101】
一部の実施例において、第1の生成手段702は、操作要求のタイプに基づいて監査報知テンプレートを取得し、ユーザ身元識別子、監査任務識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。
【0102】
ただし、ユーザ身元識別子は、ユーザ身元を示す唯一の識別子である。ビジネス監査提出時間は、監査提出手段が監査プラットフォームに監査任務を提出する時間である。監査報知テンプレートは、事前に配置されてもよく、各種の操作タイプは、報知テンプレートを個別に配置する。各種の報知テンプレートは、監査通過サブテンプレート及び監査拒絶サブテンプレートを含んでもよい。操作パラメータは、操作要求における要求内容であり、操作タイプによって操作パラメータが異なる。例えば、ミニアプリパッケージをリリースする場合、ミニアプリパッケージ識別子(package_id)及びミニアプリパッケージバージョン(package_version)パラメータを提供する必要があり、ミニアプリ名称を修正する場合、ミニアプリ名称(app_name)パラメータを提供する必要がある。監査結果メッセージ項目は、監査結果を書き込むための項目である。第1の生成手段702により生成された報知待ちメッセージのうち、監査結果メッセージ項目は空きである。
【0103】
一部の実施例において、提出モジュール601は、ユーザ端末の身元を認証するように配置されている認証手段をさらに含む。
【0104】
図8に示すように、認証手段800は、
操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得するように配置されている解析サブ手段801を含む。
【0105】
一部の実施例において、操作要求には、ユーザ身元識別子及びミニアプリ識別子が含まれており、解析サブ手段801は、操作要求を解析することで、ユーザ身元識別子及びミニアプリ識別子を取得することができる。
【0106】
検証サブ手段802は、ユーザ身元識別子及びミニアプリ識別子に基づいて、ユーザ身元を検証するように配置されている。
【0107】
一部の実施例において、検証サブ手段802は、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っていない場合、ユーザ端末に無権限メッセージを直接返送し、このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っている場合、後続の操作を行う。
【0108】
図9に示すように、プッシュモジュール900は、
取得された監査結果及び報知待ちメッセージに基づいて、監査報知メッセージを生成するように配置されている第2の生成手段901を含む。
【0109】
ただし、監査結果は、監査通過及び監査拒絶を含む。監査標準に合致する場合、監査プラットフォームは監査通過の監査結果を得て、監査標準に合致しない場合、監査プラットフォームは監査拒絶の監査結果を得る。
【0110】
一部の実施例において、第2の生成手段901は、監査結果を取得した後、監査結果を報知待ちメッセージにおける監査報知メッセージ項目に書き込み、監査報知メッセージを生成する。
【0111】
プッシュ手段902は、監査報知メッセージをユーザ端末にプッシュするように配置されている。
【0112】
一部の実施例において、プッシュ手段902は、プッシュアドレスライブラリから開発者又は第3者の事業者のアドレスを取得し、監査報知メッセージを開発者又は第3者の事業者にプッシュする。
【0113】
一部の実施例において、図10に示すように、プッシュモジュール1000は、第2の生成手段1001、プッシュ手段1002及び申し込み手段1003を含み、ただし、第2の生成手段1001及びプッシュ手段1002の原理及び機能は、第2の生成手段901及びプッシュ手段902と同様であり、ただし説明を繰り返さない。
【0114】
申し込み手段1003は、メッセージキューから監査結果を申し込み、監査結果を第2の生成手段に伝送するように配置されている。
【0115】
説明しておくことは、メッセージキューが監査結果を記憶するための行列である。メッセージキューは、監査プラットフォームに設置されてもよく、ゲートウェイに設置されてもよく、監査プラットフォーム及びゲートウェイから独立して設置されてもよい。メッセージキューを利用して監査プラットフォームとゲートウェイとをデカップリングすることで、1回のプッシュで複数の箇所で消費される目的を実現する。
【0116】
一部の実施例において、ゲートウェイは、監査報知テンプレートを記憶するように配置されている報知テンプレートライブラリ1004をさらに含む。監査報知テンプレートは、報知テンプレートライブラリ1004に予め配置されて記憶されていてもよい。監査報知テンプレートは、操作要求のタイプと整合し、そして、それぞれの操作タイプは、2つの監査報知テンプレート、即ち、監査通過テンプレート及び監査拒絶テンプレートに対応する。監査通過テンプレート及び監査拒絶テンプレートの設置形式は、本願の方法部分で言及されており、ただし説明を繰り返さない。
【0117】
説明しておくことは、報知テンプレートライブラリ1004は、ゲートウェイに設置されてもよく、ゲートウェイから独立した他の手段又はモジュールに設置されてもよく、報知テンプレートを記憶でき、かつ提出モジュール及びプッシュモジュールがこの報知テンプレートライブラリにアクセスできるようにすればよい。
【0118】
プッシュアドレスライブラリ1005は、ユーザ端末のプッシュアドレスを記憶するように配置されている。ただし、プッシュアドレスは、ユーザにより予め配置される報知を受信するアドレスである。
【0119】
一部の実施例において、ミニアプリ開発者及び第3者の事業者は、それぞれのアドレスをプッシュアドレスライブラリに予め設置してもよく、それにより、プッシュモジュールが必要な場合に、ミニアプリ開発者又は第3者の事業者のアドレスを取得しやすくなる。
【0120】
説明しておくことは、プッシュアドレスライブラリ1005は、ゲートウェイに設置されてもよく、ゲートウェイから独立した他の手段又はモジュールに設置されてもよく、アドレスを記憶でき、かつ提出モジュール及びプッシュモジュールがこのプッシュアドレスライブラリにアクセスできるようにすればよい。
【0121】
本実施例が提供したゲートウェイは、提出モジュールを利用して、ユーザ端末の操作要求を受信した場合、監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、プッシュモジュールにより取得された監査結果及び報知待ちメッセージを利用して、監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。このゲートウェイは、汎用性があり、任意タイプのビジネス監査(例えば、ミニアプリ能力の監査)をサポートできるとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上した。
【0122】
第4の態様において、本願の実施例は、監査プラットフォームを提供し、この監査プラットフォームは、アプリケーションプログラムのビジネス、例えば、ミニアプリのビジネスを監査することができる。
【0123】
図11は、本願の実施例が提供した監査プラットフォームの原理ブロック図である。図11に示すように、監査プラットフォーム1100は、
ビジネス監査要求を受信するように配置されている受信モジュール1101を含む。
【0124】
ただし、ビジネス監査要求は、ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージである。
【0125】
取得モジュール1102は、監査結果を取得するように配置されている。
【0126】
一部の実施例において、監査プラットフォームは、監査人員によって人工監査を行う。監査結果は、監査人員が監査要求を監査した結果である。例えば、監査プラットフォームは、監査人員に監査要求、即ち、監査要求における監査事項を表示し、監査人員は、監査事項を監査し、監査結果を得て、この監査結果を監査プラットフォームに伝送する。
【0127】
一部の実施例において、監査プラットフォームは、他の態様によって監査してもよく、例えば、人工と機器とを結合する態様によって監査してもよい。
【0128】
記憶モジュール1103は、監査結果を記憶するように配置されている。
【0129】
一部の実施例において、記憶モジュール1103は、メッセージキューの形で監査結果を記憶する。記憶モジュール1103は、監査プラットフォームに設置されてもよく、監査プラットフォームから独立した他のモジュール又は手段に設置されてもよい。
【0130】
一部の実施例において、監査プラットフォームは、さらに、
ゲートウェイに監査任務識別子を返送するように配置されている任務識別子生成モジュールを含む。ただし、監査任務識別子は、監査任務の唯一の識別子である。
【0131】
本願の実施例が提供した監査プラットフォームは、受信モジュールを利用してビジネス監査要求を受信し、取得モジュールを利用して監査結果を取得し、記憶モジュールを利用して監査結果を記憶する。この監査プラットフォームは、任意タイプのビジネスを監査してもよく、そして、ゲートウェイ開発人員の人力コストを低減し、コード冗長性を低減させ、かつビジネスコードのメンテナンス性を向上することができる。
【0132】
本願の実施例が提供したビジネス監査報知方法がよりよく理解されるために、以下、ユーザ端末、ゲートウェイ及び監査プラットフォームを合わせて、ビジネス監査報知方法をさらに紹介する。
【0133】
図12は、本実施例が提供したビジネス監査報知方法のフローチャートである。図12に示すように、ビジネス監査報知方法は、
ユーザ端末がゲートウェイの提出モジュールに操作要求を送信するステップ1201を含む。
【0134】
ただし、操作要求は、ユーザ身元識別子、ミニアプリ識別子、操作タイプ(名称修正)及び名称パラメータ(ミニアプリの新しい名称)を含む。
【0135】
ステップ1202において、ゲートウェイは、ユーザ身元を認証する。
【0136】
本実施例において、ゲートウェイは、操作要求からユーザ身元識別子、ミニアプリ識別子を解析し、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。ユーザ身元識別子が操作権限を持っていない場合、ユーザ端末に検証失敗メッセージを返送する。ユーザ身元識別子が操作権限を持っている場合、ユーザ端末に検証成功メッセージを返送し、後続のステップを実行し、又は、ユーザ端末に検証成功メッセージを返送せずに、直接に後続のステップを実行する。
【0137】
ステップ1203において、ゲートウェイの監査提出手段は、監査プラットフォームにビジネス監査任務を送信する。
【0138】
ビジネス監査任務は、ゲートウェイが操作要求に基づいて得られた監査任務である。ビジネス監査任務は、ミニアプリ識別子、操作タイプ(名称修正)及び名称パラメータを含む。ユーザ身元に対する検証が成功した場合、ゲートウェイは、監査プラットフォームにビジネス監査要求を送信する。
【0139】
ステップ1204において、監査プラットフォームは、ゲートウェイに監査任務識別子を返送する。
【0140】
本実施例において、監査プラットフォームは、ビジネス監査任務を受信した後、このビジネス監査任務のために1つの唯一の識別子を割り当てって、後続のフローで使用されることに供する。
【0141】
ステップ1205において、ゲートウェイは、報知テンプレートライブラリから監査報知テンプレートを取得する。
【0142】
本実施例において、監査報知テンプレートは、開発者又は第3者の事業者により予め設定され、報知テンプレートライブラリに記憶されているテンプレートである。
【0143】
ステップ1206において、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。
【0144】
本実施例において、ゲートウェイは、監査プラットフォームより返送された監査任務識別子に基づいて、報知テンプレートライブラリから監査報知テンプレートを取得し、ユーザ端末により送信されたユーザ身元識別子、ビジネス監査提出時間及び操作パラメータ、並びに監査結果メッセージ項目を合わせて、報知待ちメッセージを生成する。
【0145】
ステップ1207において、監査プラットフォームは、監査人員の監査結果を受信する。
【0146】
本実施例において、監査プラットフォームは、監査人員に操作パラメータを表示し、監査人員は、操作パラメータに従ってビジネス監査要求を監査し、監査結果を監査プラットフォームに伝送する。
【0147】
ステップ1208において、監査プラットフォームは、監査結果をメッセージキューに記憶する。
【0148】
ステップ1209において、ゲートウェイは、メッセージキューから監査結果を取得する。
【0149】
ステップ1210において、ゲートウェイは、監査任務識別子に基づいて、報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、監査結果及び報知待ちメッセージを組み合わせて、報知メッセージを取得する。
【0150】
ステップ1211において、ゲートウェイは、プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得する。
【0151】
本実施例において、ユーザ端末のプッシュアドレスは、ユーザによりプッシュアドレスライブラリに予め配置されたものである。
【0152】
ステップ1212において、ゲートウェイは、報知メッセージをプッシュアドレスに従ってユーザ端末にプッシュする。
【0153】
本願の実施例によれば、本願は、電子機器及び読取可能な記憶媒体をさらに提供した。
【0154】
図13は、本願の実施例によるビジネス監査報知の方法の電子機器のブロック図である。図13に示すように、電子機器とは、様々な形式のデジタルコンピュータ、例えば、ラップトップ型コンピュータと、デスクトップコンピュータと、ワークステーションと、パーソナル・デジタル・アシスタントと、サーバと、ブレードサーバと、大型コンピュータと、他の適宜なコンピュータとを表す旨である。電子機器は、様々な形式の移動装置、例えば、パーソナル・デジタル・アシスタントと、セルラー電話と、スマートフォンと、ウェアラブル機器と、他の類似する計算装置とを表してもよい。本明細書に示す部品と、それらの接続及び関係と、それらの機能とは単に例示であり、本明細書で説明した及び/又は要求した本願の実現を限定することを意図しない。
【0155】
図13に示すように、この電子機器は、1つ又は複数のプロセッサ1301、メモリ1302、及び各部品を接続するための、高速インターフェース及び低速インターフェースを含むインターフェースを備える。各部品は、異なるバスで互いに接続され、且つ共通のメインボード上に実装されてもよく、又は必要に応じて他の方式で実装されてもよい。プロセッサは、電子機器内で実行されるコマンドを処理することができ、メモリに記憶されて、外部入力・出力装置(例えば、インターフェースに結合する表示機器)上に図形ユーザインターフェース(Graphical User Interface,GUI)の図形情報を表示するコマンドを含む。他の実施形態においては、必要に応じて、複数のプロセッサ及び/又は複数のバスを複数のメモリと一緒に使用してもよい。同様に、複数の電子機器を接続して、各機器が一部の必要な操作を提供してもよい(例えば、サーバアレー、一組のブレードサーバ、又はマルチプロセッサシステムとする)。図13においては、1つのプロセッサ1301を例とする。
【0156】
メモリ1302は、本願が提供した非一時的なコンピュータ読取可能な記憶媒体である。ただし、前記メモリには少なくとも1つのプロセッサにより実行され得るコマンドが記憶されており、前記少なくとも1つのプロセッサに本願が提供したビジネス監査報知の方法を実行させる。本願の非一時的なコンピュータ読取可能な記憶媒体は、コンピュータコマンドを記憶しており、このコンピュータコマンドは、コンピュータに本願が提供したビジネス監査報知の方法を実行させるものである。
【0157】
メモリ1302は、非一時的なコンピュータ読取可能な記憶媒体として、非一時的なソフトウェアプログラム、非一時的なコンピュータ実行可能なプログラム及びモジュール、例えば本願の実施例におけるビジネス監査報知の方法に対応するプログラムコマンド・モジュールを記憶するものである。プロセッサ1301は、メモリ1302に記憶されている非一時的なソフトウェアプログラム、コマンド及びモジュールを実行することで、サーバの各種の機能アプリケーション及びデータ処理を実行し、即ち上記方法実施例におけるビジネス監査報知の方法を実現する。
【0158】
メモリ1302は、プログラム記憶領域及びデータ記憶領域を含んでもよく、ただし、プログラム記憶領域は、オペレーティングシステム、少なくとも1つの機能に必要なアプリケーションプログラムを記憶してもよく、データ記憶領域は、ビジネス監査報知による電子機器の使用により生成されたデータなどを記憶してもよい。また、メモリ1302は、高速ランダムアクセスメモリを含んでもよく、非一時なメモリ、例えば少なくとも1つの磁気ディスク記憶デバイス、フラッシュメモリデバイス、又は他の非一時的なソリッド記憶デバイスを含んでもよい。一部の実施例において、メモリ1302は選択的にプロセッサ1301に対して遠隔に設置されたメモリを含み、これらの遠隔メモリが、ネットワークを介して電子機器に接続されてもよい。上記ネットワークの例示は、インターネット、イントラネット、ローカルエリアネットワーク、移動通信ネットワーク及びそれらの組合を含むが、これらに限られない。
【0159】
ビジネス監査報知の方法の電子機器は、入力装置1303及び出力装置1304をさらに含んでもよい。プロセッサ1301、メモリ1302、入力装置1303及び出力装置1304は、バス又は他の方式で接続されてもよく、図13においてバスを介して接続されることを例とする。
【0160】
入力装置1303は、入力されたデジタル又はキャラクター情報を受信し、ビジネス監査報知方法の電子機器のユーザ設置及び機能制御に関わるキー信号入力を発生してもよく、例えば、タッチスクリーン、キーパッド、マウス、トラックパッド、タッチパッド、インジケーターロッド、1つ又は複数のマウスボタン、トラックボール、レバーなどの入力装置である。出力装置1304は、表示デバイスと、補助照明装置(例えば、LED)と、触覚フィードバック装置(例えば、振動モーター)などを含んでもよい。この表示デバイスは、液晶ディスプレー(LCD)と、発光ダイオード(LED)ディスプレーと、プラズマディスプレーとを含むが、これらに限られない。一部の実施形態において、表示デバイスはタッチスクリーンであってもよい。
【0161】
ただし説明したシステム及び技術の各実施形態は、デジタル電子回路システム、集積回路システム、専用ASIC(専用集積回路)、コンピュータハードウェア、ファームウェア、ソフトウェア、及び/又はそれらの組合せで実現されてもよい。これらの各実施形態は、1つ又は複数のコンピュータプログラムで実施されることを含んでもよく、この1つまたは複数のコンピュータプログラムが、少なくとも1つのプログラマブルプロセッサを含むプログラマブルシステム上で実行及び/又は解釈されてもよく、このプログラマブルプロセッサは、専用又は共通のプログラマブルプロセッサであってもよく、記憶システムと、少なくとも1つの入力装置と、少なくとも1つの出力装置とからデータと命令とを受信し、データと命令とをこの記憶システムと、この少なくとも1つの入力装置と、この少なくとも1つの出力装置とに伝送してもよい。
【0162】
これらの計算プログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、又はコードとも称する)は、プログラマブルプロセッサの機械命令を含み、高級プロセス及び/又はオブジェクト指向のプログラミング言語、及び/又はアセンブリ・機械言語によってこれらの計算プログラムを実施してもよい。本明細書で使用した術語「機械読取可能な媒体」及び「コンピュータ読取可能な媒体」とは、機械命令及び/又はデータをプログラマブルプロセッサに提供するための任意のコンピュータプログラム製品、機器、及び/又は装置(例えば、磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス(PLD))を意味しており、機械読取可能な信号である機械命令を受ける機械読取可能な媒体を含む。術語「機械読取可能な信号」とは、機械命令及び/又はデータをプログラマブルプロセッサに提供するための任意の信号を意味している。
【0163】
ユーザとのインタラクションを提供するために、コンピュータでただし説明したシステム及び技術を実施してもよく、このコンピュータは、ユーザに情報を表示するための表示装置(例えば、CRT(陰極線管)又はLCD(液晶ディスプレー)モニタ)と、キーボード及び指向装置(例えば、マウス又はトラックボール)とを有し、ユーザは、このキーボード及びこの指向装置によって、入力をコンピュータに提供することができる。他の種類の装置は、ユーザとのインタラクションを提供するためのものであってもよく、例えば、ユーザに提供するフィードバックは、任意の形式のセンサーフィードバック(例えば、視覚フィードバック、聴覚フィードバック、又は触覚フィードバック)であってもよく、任意の形式(声入力、語音入力、又は触覚入力を含む)でユーザからの入力を受信してもよい。
【0164】
ただし説明したシステム及び技術は、バックグラウンド部品を含む計算システム(例えば、データサーバとする)、又はミドルウェア部品を含む計算システム(例えば、アプリケーションサーバ)、又はフロントエンド部品を含む計算システム(例えば、グラフィカル・ユーザー・インターフェース又はネットワークブラウザを有するユーザコンピュータ、ユーザはこのグラフィカル・ユーザー・インターフェース又はこのネットワークブラウザを介してただし説明したシステム及び技術の実施形態とインタラクトすることができる)、又はこのようなバックグラウンド部品、ミドルウェア部品、或いはフロントエンド部品の任意の組合せを含む計算システムで実施されてもよい。任意の形式又は媒体のデジタルデータ通信(例えば、通信ネットワーク)を介してシステムの部品を相互に接続してもよい。通信ネットワークの例示は、ローカルエリアネットワーク(LAN)と、広域ネットワーク(WAN)と、インターネットとを含む。
【0165】
コンピュータシステムは、クライアントとサーバとを含んでもよい。クライアントとサーバとは、一般的に互いに離れて、且つ通常に通信ネットワークを介してインタラクトする。相応するコンピュータで実行されるとともに、互いにクライアント-サーバの関係を有するコンピュータプログラムによって、クライアントとサーバとの関係を形成する。
【0166】
本願の実施例は、プロセッサによって実行される際に、上記いずれかのビジネス監査報知方法を実現するコンピュータプログラムを記憶しているコンピュータ読取可能な媒体を提供した。
【0167】
上記に示した様々な形式のフローを利用して、ステップを並び替え、追加又は削除することができると理解すべきである。例えば、本願に記載された各ステップは、並行に実行されてもよいし、順に実行されてもよいし、異なる順序で実行されてもよく、本願が開示した技術案が所望する結果を実現できる限り、本文はただし限定しない。
【0168】
上述した具体的な実施形態は、本願の保護範囲に対する限定を構成しない。当業者は、設計要求や他の要因に応じて、さまざまな修正、組合、サブ組合及び置換を行うことができると理解すべきである。本願の趣旨及び原則の範囲内になされた任意の修正、等価な置換、改進などは、いずれも本願の保護範囲内に含まれるべきである。
【手続補正2】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することと、
前記監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成することと、
取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することと、
前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
ことを特徴とするビジネス監査報知方法。
【請求項2】
前記ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することは、
前記操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得することと、
前記ユーザ身元識別子及び前記ミニアプリ識別子に基づいて、ユーザ身元を検証することと、
前記ユーザ身元の検証が成功した場合、前記監査プラットフォームにビジネス監査要求を送信することと、を含む、
ことを特徴とする請求項1に記載の方法。
【請求項3】
前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成することは、
前記操作要求の操作タイプに基づいて、報知テンプレートライブラリから前記操作タイプに整合する監査報知テンプレートを取得することと、
前記監査報知テンプレート及び前記監査任務識別子に基づいて、報知待ちメッセージを生成することと、を含む、
ことを特徴とする請求項1に記載の方法。
【請求項4】
前記監査報知テンプレートに基づいて、報知待ちメッセージを生成した後、前記方法は、
前記報知待ちメッセージを報知待ちメッセージライブラリに記憶することをさらに含む、
ことを特徴とする請求項3に記載の方法。
【請求項5】
前記監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することは、
前記監査任務識別子に基づいて、前記報知待ちメッセージライブラリから前記監査任務識別子に対応する前記報知待ちメッセージを取得することと、
前記監査結果と前記報知待ちメッセージとを組み合わせて、前記監査報知メッセージを生成することと、を含む、
ことを特徴とする請求項4に記載の方法。
【請求項6】
前記報知待ちメッセージに係るフィールドは、監査任務識別子、ユーザ身元識別子、操作パラメータ、前記ビジネス監査要求を提出する時間、前記操作タイプに整合するテンプレートである監査報知テンプレート及び前記監査結果を書き込むためのフィールドである監査結果メッセージ項目を含む、
ことを特徴とする請求項1に記載の方法。
【請求項7】
前記監査結果は、前記監査結果を記憶するための行列であるメッセージキューから取得される、
ことを特徴とする請求項1に記載の方法。
【請求項8】
前記監査報知メッセージを前記ユーザ端末にプッシュすることは、
プッシュアドレスライブラリから前記ユーザ端末のプッシュアドレスを取得することと、
前記プッシュアドレスに従って、前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
ことを特徴とする請求項1に記載の方法。
【請求項9】
前記監査報知メッセージを前記ユーザ端末にプッシュすることは、
所定のプッシュ回数及び所定の時間間隔に従って、前記ユーザ端末に前記監査報知メッセージをプッシュすることを含む、
ことを特徴とする請求項1に記載の方法。
【請求項10】
ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージであるビジネス監査要求を受信することと、
監査結果を取得して記憶することで、前記ゲートウェイが、前記監査結果と、ゲートウェイが前記ビジネス監査要求に対して生成したメッセージである報知待ちメッセージとに基づいて、監査報知メッセージを生成することに供することと、を含む、
ことを特徴とするビジネス監査報知方法。
【請求項11】
前記監査結果を取得して記憶することは、
前記監査結果を受信して、前記監査結果をメッセージキューに記憶することを含む、
ことを特徴とする請求項10に記載の方法。
【請求項12】
前記ビジネス監査要求を受信した後、前記方法は、
ゲートウェイに、監査任務の唯一の識別子である監査任務識別子を返送することをさらに含む、
ことを特徴とする請求項10に記載の方法。
【請求項13】
ユーザ端末の操作要求に応答して、監査プラットフォームにビジネス監査要求を送信し、前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている提出モジュールと、
取得された監査結果及び前記報知待ちメッセージに基づいて監査報知メッセージを生成し、前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュモジュールと、を含む、
ことを特徴とするゲートウェイ。
【請求項14】
前記提出モジュールは、
監査プラットフォームにビジネス監査要求を送信するように配置されている監査提出手段と、
前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている第1の生成手段と、を含む、
ことを特徴とする請求項13に記載のゲートウェイ。
【請求項15】
前記提出モジュールは、
前記操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得するように配置されている解析手段と、
前記ユーザ身元識別子及び前記ミニアプリ識別子に基づいてユーザ身元を検証するように配置されている検証手段と、を含む、
ことを特徴とする請求項14に記載のゲートウェイ。
【請求項16】
前記プッシュモジュールは、
取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成するように配置されている第2の生成手段と、
前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュ手段と、を含む、
ことを特徴とする請求項13に記載のゲートウェイ。
【請求項17】
前記プッシュモジュールは、
監査結果を記憶するための行列であるメッセージキューから前記監査結果を申し込み、前記監査結果を前記第2の生成手段に伝送するように配置されている申し込み手段をさらに含む、
ことを特徴とする請求項16に記載のゲートウェイ。
【請求項18】
前記操作要求のタイプに対応する監査報知テンプレートを記憶するように配置されている報知テンプレートライブラリと、
ユーザにより予め配置された報知を受信するアドレスである、前記ユーザ端末のプッシュアドレスを記憶するように配置されているプッシュアドレスライブラリと、さらに含む、
ことを特徴とする請求項13に記載のゲートウェイ。
【請求項19】
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサと通信接続するメモリとを含む電子機器であって、
前記メモリに、前記少なくとも1つのプロセッサによって実行され得るコマンドが記憶されており、前記コマンドが前記少なくとも1つのプロセッサによって実行されることで、前記少なくとも1つのプロセッサが請求項1~9、10~12のいずれか一項に記載の方法を実行することができる、
ことを特徴とする電子機器。
【請求項20】
コンピュータに請求項1~9、10~12のいずれか一項に記載の方法を実行させるためのコンピュータコマンドを記憶している、
ことを特徴とする非一時的なコンピュータ読取可能な記憶媒体。
【請求項21】
プロセッサによって実行されることで、請求項1~9、10~12のいずれか一項に記載の方法を実現するコンピュータプログラム。
【国際調査報告】