特表 2024-541028 クライアントアプリのネットワークトラフィックを管理する方法及び装置

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-11-06

(54)【発明の名称】クライアントアプリのネットワークトラフィックを管理する方法及び装置

(51)【国際特許分類】

   H04L 67/025 20220101AFI20241029BHJP

   H04L 67/02 20220101ALI20241029BHJP

   H04L 67/14 20220101ALI20241029BHJP

   H04L 67/564 20220101ALI20241029BHJP

【ＦＩ】

H04L67/025

H04L67/02

H04L67/14

H04L67/564

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024525280

(86)(22)【出願日】2022-10-08

(85)【翻訳文提出日】2024-04-26

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

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

(87)【国際公開日】2023-05-04

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

(32)【優先日】2021-10-27

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

２．ＲＥＤＩＳ

３．ＩＯＳ

(71)【出願人】

【識別番号】520476341

【氏名又は名称】北京字節跳動網絡技術有限公司

【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ．

【住所又は居所原語表記】Ｒｏｏｍ Ｂ－００３５， ２／Ｆ， Ｎｏ．３ Ｂｕｉｌｄｉｎｇ， Ｎｏ．３０， Ｓｈｉｘｉｎｇ Ｒｏａｄ， Ｓｈｉｊｉｎｇｓｈａｎ Ｄｉｓｔｒｉｃｔ Ｂｅｉｊｉｎｇ １０００４１ Ｃｈｉｎａ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100229448

【弁理士】

【氏名又は名称】中槇 利明

(72)【発明者】

【氏名】ヤオ，シン

(72)【発明者】

【氏名】ファン，ジョンウェイ

(72)【発明者】

【氏名】ワン，レイ

(72)【発明者】

【氏名】シャン，チャオヤン

(72)【発明者】

【氏名】ドゥ，ジュンユィ

(72)【発明者】

【氏名】ダイ，ジュン

(57)【要約】

ここでは、クライアントアプリのネットワークトラフィックを管理する方法、装置、機器及び記憶媒体を提供する。ここで記述される方法は、ターゲットユーザに対する決定に基づいて、ターゲットユーザのユーザデータのクライアントアプリからサーバへのネットワーク伝送を検出することと、ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、ネットワーク伝送の異なる層でネットワークトラフィックを分析することと、ネットワークトラフィックがターゲットユーザに対応するデータ交換制約を満たすことを指示するとの分析に基づいて、ネットワークトラフィックをデータ交換制約によって限定されるサーバに送信することとを含む。この方式により、ネットワークトラフィックのタイプに基づいてネットワーク伝送の異なる層でネットワークトラフィックのうちのデータ交換制約を満たさないネットワークトラフィックを分析し制限することにより、ユーザデータが様々なタイプのネットワークトラフィックを経由して許容されていないサーバに伝送されることを効果的に防止することができる。

【特許請求の範囲】

【請求項1】

クライアントアプリのネットワークトラフィックを管理する方法であって、
ターゲットユーザに対する決定に基づいて、前記ターゲットユーザのユーザデータの前記クライアントアプリからサーバへのネットワーク伝送を検出することと、
前記ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析することと、
前記ネットワークトラフィックが前記ターゲットユーザに対応するデータ交換制約を満たすことを指示するとの前記分析に基づいて、前記ネットワークトラフィックを前記データ交換制約によって限定されるサーバに送信することとを含む、方法。

【請求項2】

ターゲットユーザに対する決定は、
前記ターゲットユーザのユーザ情報と、
前記ターゲットユーザに対応する機器情報との少なくとも一つに基づく、請求項１に記載の方法。

【請求項3】

前記ユーザ情報は、ユーザのアカウント情報、個人情報、及び／又は登録情報を含み、
前記機器情報は、ユーザ身分識別モジュールＳＩＭ情報、ＩＰアドレス、ネットワークサービスプロバイダ情報、機器のシステム設定情報、及び／又はアプリ設定情報を含む、請求項２に記載の方法。

【請求項4】

前記ターゲットユーザのユーザ情報又は対応する機器情報に基づいて、前記ターゲットユーザに対応するデータ交換制約を決定することをさらに含む、請求項２又は３に記載の方法。

【請求項5】

前記ネットワークトラフィックのタイプは、
ネイティブアプリに関連するネイティブタイプのネットワークトラフィックと、
アプリに内蔵されたブラウザに関連するウェブページビュータイプのネットワークトラフィックと、
サード・パーティソフトウェア開発キットＳＤＫに関連するサード・パーティＳＤＫタイプのネットワークトラフィックと
の少なくとも一つを含む、請求項１に記載の方法。

【請求項6】

前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析することは、
前記ネットワークトラフィックのタイプがネイティブタイプであるネットワークトラフィックに基づいて、ネットワーク層で前記ネットワークトラフィックを分析することを含む、請求項１に記載の方法。

【請求項7】

前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析することは、
前記ネットワークトラフィックのタイプがウェブページビュータイプであるネットワークトラフィックに基づいて、前記ウェブページビュータイプのネットワークトラフィックを前記クライアントアプリのネットワークインターフェースに遷移して前記クライアントアプリのネイティブネットワークモジュールによって管理されるようにすることと、
ネットワーク層で遷移されたネットワークトラフィックを分析することとを含む、請求項１に記載の方法。

【請求項8】

前記ウェブページビュータイプのネットワークトラフィックを前記モバイル端アプリのネットワークインターフェースに遷移することは、
ＪａｖａＳｃｒｉｐｔのフックメカニズムを利用して前記ウェブページビュータイプのネットワークトラフィックを遷移することを含む、請求項７に記載の方法。

【請求項9】

前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析することは、
前記ネットワークトラフィックのタイプがサード・パーティＳＤＫタイプであるネットワークトラフィックに基づいて、アプリケーションプログラミングインターフェースＡＰＩ層で前記ネットワークトラフィックを分析することを含む、請求項１に記載の方法。

【請求項10】

ＡＰＩ層で前記ネットワークトラフィックを分析することは、
サード・パーティＳＤＫのＡＰＩに前記データ交換制約に基づく判断ロジックを追加することによってラップＡＰＩを決定することと、
前記ラップＡＰＩを呼び出して前記判断ロジックを利用して前記ネットワークトラフィックを分析することとを含む、請求項９に記載の方法。

【請求項11】

クライアントアプリのネットワークトラフィックを管理するための装置であって、
ターゲットユーザに対する決定に基づいて、前記ターゲットユーザのユーザデータの前記クライアントアプリからサーバへのネットワーク伝送の検出を起動するように構成される起動モジュールと、
前記起動モジュールによるアクティブ化に応答し、前記ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析し、そして、前記ネットワークトラフィックが前記ターゲットユーザに対応するデータ交換制約を満たすことを指示するとの前記分析に基づいて、前記ネットワークトラフィックを前記データ交換制約によって限定されるサーバに送信するように構成される管理モジュールとを含む、装置。

【請求項12】

ターゲットユーザに対する決定は、
前記ターゲットユーザのユーザ情報と、
前記ターゲットユーザに対応する機器情報との少なくとも一つに基づく、請求項１１に記載の装置。

【請求項13】

前記ユーザ情報は、ユーザのアカウント情報、個人情報、及び／又は登録情報を含み、
前記機器情報は、ユーザ身分識別モジュールＳＩＭ情報、ＩＰアドレス、ネットワークサービスプロバイダ情報、機器のシステム設定情報、及び／又はアプリ設定情報を含む、請求項１２に記載の装置。

【請求項14】

前記ターゲットユーザのユーザ情報又は対応する機器情報に基づいて、前記ターゲットユーザに対応するデータ交換制約を決定するように構成される制約決定モジュールをさらに含む、請求項１２又は１３に記載の装置。

【請求項15】

前記ネットワークトラフィックのタイプは、
ネイティブアプリに関連するネイティブタイプのネットワークトラフィックと、
アプリに内蔵されたブラウザに関連するウェブページビュータイプのネットワークトラフィックと、
サード・パーティソフトウェア開発キットＳＤＫに関連するサード・パーティＳＤＫタイプのネットワークトラフィックと
の少なくとも一つを含む、請求項１１に記載の装置。

【請求項16】

前記管理モジュールは、
前記ネットワークトラフィックのタイプがネイティブタイプであるネットワークトラフィックに基づいて、ネットワーク層で前記ネットワークトラフィックを分析するように構成される第一管理モジュールを含む、請求項１１に記載の装置。

【請求項17】

前記管理モジュールは、
前記ネットワークトラフィックのタイプがウェブページビュータイプであるネットワークトラフィックに基づいて、前記ウェブページビュータイプのネットワークトラフィックを前記クライアントアプリのネットワークインターフェースに遷移して前記クライアントアプリのネイティブネットワークモジュールによって管理されるようにし、
ネットワーク層で遷移されたネットワークトラフィックを分析するように構成される第二管理モジュールを含む、請求項１１に記載の装置。

【請求項18】

前記ウェブページビュータイプのネットワークトラフィックを前記モバイル端アプリのネットワークインターフェースに遷移することは、
ＪａｖａＳｃｒｉｐｔのフックメカニズムを利用して前記ウェブページビュータイプのネットワークトラフィックを遷移することを含む、請求項１７に記載の装置。

【請求項19】

前記管理モジュールは、
前記ネットワークトラフィックのタイプがサード・パーティＳＤＫタイプであるネットワークトラフィックに基づいて、アプリケーションプログラミングインターフェースＡＰＩ層で前記ネットワークトラフィックを分析するように構成される第三管理モジュールを含む、請求項１１に記載の装置。

【請求項20】

ＡＰＩ層で前記ネットワークトラフィックを分析することは、
サード・パーティＳＤＫのＡＰＩに前記データ交換制約に基づく判断ロジックを追加することによってラップＡＰＩを決定することと、
前記ラップＡＰＩを呼び出して前記判断ロジックを利用して前記ネットワークトラフィックを分析することとを含む、請求項１９に記載の装置。

【請求項21】

前記起動モジュールにサンプリング信号を送信して前記起動モジュールをトリガーするように構成されるサンプリングモジュールをさらに含み、前記サンプリング信号は、前記ネットワークトラフィックをサンプリングするサンプリングレートを指示する、請求項１１に記載の装置。

【請求項22】

メモリとプロセッサとを含む電子機器であって、
前記メモリは、一つ又は複数のコンピュータ命令を記憶するために用いられ、前記一つ又は複数のコンピュータ命令は、前記プロセッサによって実行されて請求項１から１０のいずれか１項に記載の方法を実現させる、電子機器。

【請求項23】

一つ又は複数のコンピュータ命令が記憶されているコンピュータ可読記憶媒体であって、前記一つ又は複数のコンピュータ命令は、プロセッサによって実行されて請求項１から１０のいずれか１項に記載の方法を実現させる、コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の）参照
本出願は、２０２１年１０月２７日に中国国家知識産権局に提案され、出願番号が２０２１１１２５８２０４．１であり、出願名称が「クライアントアプリのネットワークトラフィックを管理する方法及び装置」である中国特許出願の優先権を主張しており、その内容のすべては、引用により本出願に取り込まれる。

【0002】

（技術分野）
本開示の各実現方式は、コンピュータ分野に関し、より具体的には、クライアントアプリの方法、装置、機器及びコンピュータ記憶媒体に関する。

【背景技術】

【0003】

インターネット技術の発展に伴い、様々なインターネットアプリは、すでに人々の生活における重要な部分となっている。このようなアプリは、毎日大規模のデータが発生し、それによってあらゆる面で、例えばデータ主権保護などのデータセキュリティ問題が発生している。例えば、いくつかの国では、特定のタイプのユーザデータが海外のサーバに送信されることを禁止している可能性がある。

【0004】

いくつかのグローバル化アプリにとって、このようなチャレンジがより顕著である。このようなグローバル化アプリは、同じ技術アーキテクチャに基づいて複数の異なる領域のユーザにサービスを提供する必要があるかもしれない。しかしながら、これらの領域は、まったく異なるデータセキュリティ制約、例えば特定のデータ主権保護要求を有する可能性があり、それによってデータセキュリティ保護の難易度がさらに大きくなる。

【発明の概要】

【0005】

本開示の第一態様は、クライアントアプリのネットワークトラフィックを管理する方法を提供する。この方法は、ターゲットユーザに対する決定に基づいて、ターゲットユーザのユーザデータのクライアントアプリからサーバへのネットワーク伝送を検出することと、ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、ネットワーク伝送の異なる層でネットワークトラフィックを分析することと、ネットワークトラフィックがターゲットユーザに対応するデータ交換制約を満たすことを指示するとの分析に基づいて、ネットワークトラフィックをデータ交換制約によって限定されるサーバに送信することとを含む。

【0006】

本開示の第二態様は、クライアントアプリのネットワークトラフィックを管理する装置を提供する。この装置は、ターゲットユーザに対する決定に基づいて、ターゲットユーザのユーザデータのクライアントアプリからサーバへのネットワーク伝送の検出を起動するように構成される起動モジュールを含む。装置は、起動モジュールによるアクティブ化に応答し、ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、ネットワーク伝送の異なる層でネットワークトラフィックを分析し、ネットワークトラフィックがターゲットユーザに対応するデータ交換制約を満たすことを指示するとの分析に基づいて、ネットワークト管理モジュールをさらに含むラフィックをデータ交換制約によって限定されるサーバに送信するように構成される。

【0007】

本開示の第三態様は、メモリとプロセッサとを含む電子機器を提供し、メモリは、一つ又は複数のコンピュータ命令を記憶するために用いられ、一つ又は複数のコンピュータ命令は、プロセッサによって実行されて本開示の第一態様による方法を実現させる。

【0008】

本開示の第四態様は、一つ又は複数のコンピュータ命令が記憶されているコンピュータ可読記憶媒体を提供し、一つ又は複数のコンピュータ命令は、プロセッサによって実行されて本開示の第一態様による方法を実現させる。

【0009】

本開示の第五態様は、一つ又は複数のコンピュータ命令を含むコンピュータプログラム製品を提供し、一つ又は複数のコンピュータ命令は、プロセッサによって実行されて本開示の第一態様による方法を実現させる。

【図面の簡単な説明】

【0010】

図面を結び付けながら、以下の詳細な説明を参照すると、本開示の各実施例の上記と他の特徴、利点及び態様は、より明らかになる。図面において、同じ又は類似する図面注記は、同じ又は類似する要素を表し、ここで、

【図1】本開示の実施例によるデータセキュリティ保護用のシステムの概略ブロック図を示した。

【図2】本開示のいくつかの実施例によるコンピューティングセキュリティサブシステムの概略ブロック図を示した。

【図3A】本開示のいくつかの実施例によるその中にデータ交換サブシステムをデプロイする例示的デプロイメント環境を示した。

【図3B】本開示のいくつかの実施例によるＴＴＰ側の内部データセンタ（ＩＤＣ）と非ＴＴＰが位置する海外内部データセンタ（ＲｏＷ ＩＤＣ）におけるＤＥＳの実現を示した。

【図3C】本開示のいくつかの実施例によるＤＥの例示的アーキテクチャのブロック図を示した。

【図3D】本開示のいくつかの実施例によるデータ交換プロセスのフローチャートを示した。

【図3E】本開示のいくつかの実施例によるＤＥＳにおいて実現される各種のデータ処理の例示的データストリームのフローチャートを示した。

【図3F】本開示のいくつかの実施例によるＭＱチャンネルに関するデータ交換アーキテクチャの概略ブロック図を示した。

【図3G】本開示のいくつかの実施例によるＨＤＦＳチャンネルに関するデータ交換アーキテクチャの概略ブロック図を示した。

【図3H】本開示のいくつかの実施例によるデータのＴＴＰ ＩＤＣから海外ＩＤＣへのコピーのターゲットオブジェクトストア（ＴＯＳ）チャンネルの概略図を示した。

【図3I】本開示のいくつかの実施例によるデータの海外ＩＤＣからＴＴＰ ＩＤＣへのコピーのＴＯＳチャンネルの概略図を示した。

【図3J】本開示のいくつかの実施例によるＴＯＳチャンネルにおけるメッセージシーケンス図を示した。

【図3K】本開示のいくつかの実施例によるサービス呼び出しチャンネルに関するデータ交換アーキテクチャの概略ブロック図を示した。

【図3L】本開示のいくつかの実施例によるサービス呼び出しチャンネルにおける非ＴＴＰからＴＴＰへのデータ交換例を示した。

【図3M】本開示のいくつかの実施例によるサービス呼び出しチャンネルにおけるＴＴＰから非ＴＴＰへのデータ交換例を示した。

【図4A】本開示のいくつかの実施例によるモバイル端アプリのネットワークトラフィックを管理する方法のフローチャートを示した。

【図4B】本開示のいくつかの実施例によるネイティブタイプのネットワークトラフィックに対する分析と遮蔽プロセスの概略図を示した。

【図4C】本開示のいくつかの実施例によるウェブページビュータイプのネットワークトラフィックに対する分析と遮蔽プロセスの概略図を示した。

【図4D】本開示のいくつかの実施例によるサード・パーティＳＤＫタイプのネットワークトラフィックに対する分析と遮蔽プロセスの概略図を示した。

【図4E】本開示のいくつかの実施例によるセキュリティサンドボックスサブシステムのモジュール図を示した。

【図5】本開示のいくつかの実施例による推薦ポリシーを管理する例示的プロセスのフローチャートを示した。

【図6】本開示のいくつかの実施例によるデータ交換のための装置の例示的ブロック図を示した。

【図7】本開示の実施例を実施するために使用可能な例示的機器のブロック図を示した。

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

【0011】

以下は、図面を参照して本開示の実施例をより詳細に記述する。図面において本開示のいくつかの実施例が表示されているが、理解すべきこととして、本開示は、様々な形式で実現することができ、そしてここで記載された実施例に限定されるものとして解釈されるべきではなく、逆に、これらの実施例は、本開示をより徹底的かつ完全に理解するために提供される。理解すべきこととして、本開示の図面及び実施例は、例示的な作用にのみ用いられ、本開示の保護範囲を制限するために用いられるものではない。

【0012】

本開示の実施例の記述において、用語である「含む」及びその類似用語は、開放的包含、即ち「を含むが、それらに限らない」と理解されるべきである。用語である「に基づいて」は、「少なくとも部分的に基づいて」と理解されるべきである。用語である「一つの実施例」又は「この実施例」は、「少なくとも一つの実施例」として理解されるべきである。用語である「第一」、「第二」などは、異なる又は同じオブジェクトを指してもよい。以下に、他の明確的な定義と暗黙的な定義を含む可能性もある。

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

ボックス３３０２において、ＤＥＳ １０４０は、生データのタイプに基づいて生データを処理して、このタイプに対応する統一フォーマットデータを得る。生データの処理（ここでの処理は、前処理と呼ばれてもよい）は、生データのタイプに基づいて決定されてもよい。生データのタイプは、例えばＭＱデータ、オフライン集約データ、ＴＯＳデータ又はサービス呼び出しデータなどを含んでもよい。さらに、いくつかの場合に、生データの処理は、データソースによって決定されてもよい。例えば、データソースに基づいて、生データは、国内ユーザデータ、海外ユーザデータ又はエンジニアリング技術データに分けられてもよい。異なるタイプのデータに対応するフォーマットが異なるとともに、異なる方式を応用して対応する統一フォーマットデータを発生させてもよい。

【0095】

いくつかの実施例では、データソースに使用される技術が異なるため、同一タイプのデータが異なるフォーマットで提供されることがあり、これは、技術処理の要求を増加させる。そのため、一つの統一フォーマットを指定してもよい。前処理段階では、フォーマット変換により生データのフォーマットをこのタイプで指定されたフォーマットに変換して、統一フォーマットデータを得てもよい。

【0096】

例えば、ＭＱデータに対して、異なるフォーマットのＭＱデータを解析することにより、異なるフォーマットによってカプセル化されたメッセージにおけるコンテンツの分析を容易にしてもよい。オフライン集約データとＴＯＳデータに対して、異なるフォーマットでのファイルシステム又はデータシステムからこれらのデータを呼び出す異なる要求に応答し、統一ＡＰＩによって実現されるファイル呼び出し要求に変換してもよい。サービス呼び出しに対して、異なるプロトコルで生成されたサービス呼び出し要求を統一プロトコルにおけるサービス呼び出し要求に変換してもよい。

【0097】

異なるタイプのデータの具体的な前処理方式について、以下では、より詳細に記述する。

【0098】

ボックス３３０３において、ＤＥＳ １０４０は、統一フォーマットデータからデータ交換制約が満たされているかどうかを決定する。例えば、ＤＥＳ １０４０におけるＤＥＳセンタ３０６５、特に対応するデータタイプのＤＥＳセンタ３０６５は、データ交換制約が満たされているかどうか検査を実行することができる。統一フォーマットの前処理により、ＤＥＳセンタ３０６５は、様々な異なる技術を応用して生データを解析する必要がなく、それによってルールを利用してデータ安全性とコンプライアンスの検査を実行することがより容易になる。

【0099】

ボックス３３０４において、統一フォーマットデータがデータ交換制約を満たしていると決定した場合、ＤＥＳ １０４０は、統一フォーマットデータを生データに変換する。データ交換制約を満たしている場合に、データをプラットフォームの間で同期することが許容される。データが正しく同期されることを確保するために、ＤＥＳ １０４０は、中間に生成された統一フォーマットデータ（即ち、後処理段階を実行する）をさらに処理して、統一フォーマットデータを元のフォーマットを有する生データに変換する。

【0100】

ボックス３３０５において、ＤＥＳ １０４０は、生データの第一プラットフォームと第二プラットフォームとの間での交換を実行する。それによって、安全性とコンプライアンスとを満たしている場合のデータ交換を実現することができる。

【0101】

いくつかの実施例では、上記で簡単に言及されたように、異なるプラットフォームの間で異なるタイプの生データにそれぞれ対応する複数のデータチャンネルを作成してもよく、異なるタイプの生データは、対応するデータチャンネルに渡されて処理される。各データチャンネルは、このタイプの生データを処理するのに適した前処理アセンブリと、後処理アセンブリと、データ交換制約に関する確認アセンブリとを含んでもよい。追加的に又は代替的に、各データチャンネルには、この特定のタイプの生データに応用されるデータ交換制約が登録されてもよい。このような方式により、異なるタイプのデータの前処理、データ交換制約の確認と後処理の方面での分離を実現することができる。

【0102】

異なるタイプのデータに対応するデータチャンネルは、柔軟に作成、更新及び削除されることができる。このように、データの前処理と後処理の方式が変化した場合、又はデータの特定のタイプに対するデータ交換制約を更新する必要がある場合も、他のデータチャンネルに影響を与えることなく、該当するデータチャンネルで実行することができる。なお、業務の必要に応じて、第一プラットフォームと第二プラットフォームとの間で新しいタイプの生データを交換する必要があり、この新しいタイプのデータもデータ主権保護に関する検査を実行する必要がある場合、第一プラットフォームと第二プラットフォームとの間で新しいタイプの生データを処理するための新たなデータチャンネルを柔軟に作成することができる。

【0103】

図３Ｅは、本開示のいくつかの実施例によるＤＥＳ １０４０において実現される各種のデータ処理の例示的データストリーム３００５のフローチャートを示した。データストリーム３００５は、コントロールプレーンのデータストリームとデータプレーンのデータストリームとに関する。

【0104】

コントロールプレーンでは、運用保守者は、ＤＥＳ １０４０において一つ又は複数のタイプのデータのチャンネルを構成してもよく、チャンネルに対する更新とメンテナンスなどを実現することができる。図３Ｅに示すように、国内の運用保守者は、ＤＥＳエントリ３０６２を経由して特定のデータタイプと特定のデータタイプを処理するためのチャンネルの構成を要求し、特定のデータタイプを指示するデータディレクトリ３０８１と特定のデータに類似するデータ定義３０８２をＤＥＳ登録センタ３０６６に登録してもよい。データ定義３０８２は、ＤＥＳ １０４０において異なるタイプのデータを処理するチャンネル情報に指定されてもよく、該当するタイプのデータに関する前処理方案、後処理方案などを含んでもよい。

【0105】

類似的に、海外の運用保守者は、ＤＥＳエントリ３０７２を経由して特定のデータタイプと特定のデータタイプを処理するためのチャンネルとの構成を要求してもよい。海外の運用保守者は、特定のデータタイプを指示するデータディレクトリ３０８４と特定のデータに類似するデータ定義３０８５とをＤＥＳ登録センタ３０６６に登録してもよい。データ定義３０８５は、ＤＥＳ １０４０において異なるタイプのデータを処理するチャンネル情報に指定されてもよく、該当するタイプのデータに関する前処理方案、後処理方案などを含んでもよい。

【0106】

データプレーンでは、異なるタイプのデータは、ＤＥＳ １０４０においてそれぞれのチャンネルを通過する。図３Ｅに示すように、サービス呼び出しデータに対して、ＴＴＰ ＩＤＣ側のクライアント又はサーバ３０８６と海外ＩＤＣ側のクライアント又はサーバ３０９０との間でサービス呼び出し要求を交換する。サービス呼び出し要求がデータ主権保護要求を満たすように、サービス呼び出し要求は、ＤＥＳ １０４０におけるサービス呼び出しチャンネルにおいて処理される。

【0107】

図３Ｅの例では、サービス呼び出しチャンネルは、少なくとも、ＤＥＳプロキシ３０６３における前処理モジュール３０８７と、ＤＥＳセンタ３０６５におけるＨＴＴＰプロキシ３０８８と、ＤＥＳプロキシ３０７３におけるルーティングモジュール３０８９とを含んでもよい。ＴＴＰ ＩＤＣ 側のクライアント又はサーバ３０８６からのサービス呼び出し要求は、前処理モジュール３０８７に配信される。前処理モジュール３０８７は、データ定義３０８２から規定されたデータ前処理方案を利用してサービス呼び出し要求を処理し、統一フォーマット後のサービス呼び出し要求をＨＴＴＰプロキシ３０８８に送信する。

【0108】

この例では、サービス呼び出し要求が統一プロトコル、即ちＨＴＴＰプロトコルに適合する要求に統一フォーマットされると仮定する。そのため、ＨＴＴＰプロキシ３０８８は、統一フォーマット後のサービス呼び出し要求がデータ交換制約を満たすと決定した後に、統一フォーマット後のサービス呼び出し要求を、ルーティングモジュール３０８９を介して他方側のクライアント又はサーバ３０９０に提供してもよい。クライアント又はサーバ３０９０に提供される前に、統一フォーマット後のサービス呼び出し要求は、元のプロトコルに適合するサービス呼び出し要求に変換される。

【0109】

ＭＱデータに対して、このタイプの生データは、ＤＥＳ １０４０におけるＭＱチャンネルにおいて処理される。図３Ｅの例では、ＭＱチャンネルは、少なくとも、ＤＥＳプロキシ３０６３における前処理モジュール３０９２と、ＤＥＳセンタ３０６５におけるＭＱ送信機３０９４と、ＤＥＳプロキシ３０７３におけるルーティングモジュール３０９７とを含んでもよい。

【0110】

ＭＱタイプに対する生データ３０９１は、前処理モジュール３０９２に配信される。前処理モジュール３０９２は、データ定義３０８２から規定されたデータ前処理方案を利用して生データ３０９１を処理し、統一フォーマットデータ３０９３を得る。統一フォーマットデータ３０９３は、ＭＱ送信機３０９４によって抽出され、例えばサード・パーティソフトウェア開発キット（ＳＤＫ）を経由して抽出される。データ交換制約の検査を経た後に、ＳＤＫは、ルールを満たす統一フォーマットデータ３０９６を海外ＩＤＣにプッシュする。データ交換制約を満たさない統一フォーマットデータ３０９５は、却下される。ルーティングモジュール３０９７は、ルールを満たす統一フォーマットデータ３０９６を対応する目的地にルーティングし、目的地に伝送される前に統一フォーマットデータ３０９３は、対応する生データ３０９８に変換される。

【0111】

オフライン集約データとＴＯＳデータとに対して、生データは、それぞれＤＥＳ １０４０におけるＨＤＦＳチャンネルとＴＯＳチャンネルとにおいて処理される。簡略化のため、図３Ｅは、一つのチャンネルの例を示したが、理解できるように、ＨＤＦＳチャンネルとＴＯＳチャンネルとは、図示されたアセンブリを含んでもよい。図３Ｅの例では、ＨＤＦＳチャンネル又はＴＯＳチャンネルは、少なくとも、ＤＥＳプロキシ３０６３における前処理モジュール３１００と、ＤＥＳセンタ３０６５におけるファイル送信機３１０３と、ＤＥＳプロキシ３０７３におけるルーティングモジュール３１０５とを含んでもよい。

【0112】

オフライン集約データタイプ又はＴＯＳタイプのデータがファイルシステム又は他の記憶システムに記憶されているため、前処理モジュール３１００は、ファイル配信マネージャ３１０２にファイル配信ＡＰＩを呼び出す要求を開始して、オフライン集約データタイプ又はＴＯＳタイプに対する生データ３０９９を得て前処理モジュール３１００に配信されてもよい。前処理モジュール３１００は、データ定義３０８２から規定されたデータ前処理方案を利用して生データ３０９９を処理し、統一フォーマットデータ３１０１を得てもよい。

【0113】

ＭＱタイプのデータ処理に類似しており、統一フォーマットデータ３１０１は、ファイル送信機３１０３によって抽出され、例えばＳＤＫを経由して抽出される。データ交換制約の検査を経た後に、ＳＤＫは、ルールを満たす統一フォーマットデータ３１０４を海外ＩＤＣにプッシュする。データ交換制約を満たさない統一フォーマットデータは、却下され、海外ＩＤＣに配信されることができない。ルーティングモジュール３１０５は、ルールを満たす統一フォーマットデータ３１０４を対応する目的地にルーティングし、目的地に伝送される前に統一フォーマットデータ３０９４は、対応する生データ３１０６に変換される。

【0114】

理解すべきこととして、図３Ｅは、ＤＥＳ １０４０におけるＴＴＰ ＩＤＣから海外ＩＤＣへの流出データの処理のみを示した。逆方向のデータストリームに対して、ＤＥＳ １０４０において類似するフローで処理してもよく、ＤＥＳ １０４０は、該当する処理をサポートするために、対応するアセンブリ、特にＤＥＳアダプタにおけるアセンブリをリザーブしてもよい。

【0115】

以下では、ＤＥＳ １０４０における異なるタイプのデータのいくつかの例示的実現について詳細に検討する。

【0116】

（ＭＱに対するデータ交換の例示的実現）
図３Ｆは、本開示のいくつかの実施例によるＭＱチャンネルに関するデータ交換アーキテクチャ３００６の概略ブロック図を示した。データ交換アーキテクチャ３００６は、ＭＱタイプのデータに対してデータセキュリティ保護を実行するために、ＤＥＳ １０４０に実現されてもよい。図３Ｆの例では、ＴＴＰ ＩＤＣから海外ＩＤＣ方向へのデータ交換を示した。

【0117】

図３Ｆに示すように、ＴＴＰ ＩＤＣにおけるソースデータベース３１１０には、配信されるＭＱデータのエンティティが発生する。ＭＱデータは、変更データ又は商業的にカスタマイズされたイベントなどのメッセージを含んでもよく、異なるメッセージは、異なるフォーマットを有してもよい。ソースデータベース３１１０によって発生したＭＱデータは、ソースメッセージキュー３１１２に入れられる。

【0118】

図３Ｆの例では、ＤＥＳアダプタ３０６１には、ＤＥＳエントリ３０６２に加えて、ＤＥＳフロントアダプタ３１２０がさらに含まれる。ＤＥＳフロントアダプタ３１２０は、ＴＴＰ ＩＤＣから海外ＩＤＣ方向へのＭＱデータを前処理するために、ＤＥＳプロキシ３０６３の一部として実現されてもよい。ＤＥＳフロントアダプタ３１２０は、異なるフォーマットのＭＱデータを、統一フォーマットを有する統一フォーマットＭＱデータとして処理し、統一フォーマットＭＱデータをＭＱ送信機３０９４に提供して、データ交換制約が満たされているかどうかに関する決定を実行するように構成されてもよい。

【0119】

ＭＱデータ（又はメッセージ）は、異なるプロトコルによって生成されるデータを含んでもよく、各プロトコルでのデータは、カスタムフォーマットを有するため、異なる前処理を必要とする。図３Ｆに示すように、ＤＥＳフロントアダプタ３１２０は、異なるタイプの生ＭＱデータを解析して、異なるタイプの生ＭＱデータを統一フォーマットの統一フォーマットＭＱデータに変換するように構成されるパーサ３１２２を含んでもよい。図３Ｆに示すように、ＤＥＳフロントアダプタ３１２０は、ＭｙＳＱＬ（登録商標）プロトコルによって生成されたデータ、例えば変更データキャプチャ（ＣＤＣ）データを解析するためのＭｙＳＱＬ（登録商標）パーサと、Ｒｅｄｉｓプロトコルによって生成されたデータ、例えばＣＤＣデータを解析するためのＲｅｄｉｓパーサと、ドキュメントデータベースにおけるデータ、特にＣＤＣデータを解析するためのドキュメントパーサと、グラフ（ｇｒａｐｈ）データベースのデータ、特にＣＤＣデータを解析するためのグラフ解析データと、メッセージキューによって送信された異なるタイプの業務イベントデータを解析するためのＭＱパーサとなどを含んでもよい。理解できるように、パーサ３１２２は、柔軟にスケーリング可能であり、ここで、該当するタイプのＭＱデータを解析するために、より多く、より少なく又は他のパーサを設置してもよい。

【0120】

解析後に得られた統一フォーマットＭＱデータは、メッセージキューの形式であってもよく、統一フォーマットメッセージのキュー３１２４に入れられてもよい。ＴＴＰ ＩＤＣのＶＰＣ２において、ＭＱデータを担当するＭＱ送信機３０９４は、ＳＤＫを介して統一フォーマットメッセージのキュー３１２４から解析後の統一フォーマットＭＱデータを抽出して、データ安全性とコンプライアンス検査に用いてもよい。データが満たさない統一フォーマットＭＱデータは、ＭＱ送信機３０９４によって却下され、却下ログ３１２６に記録される。データ交換制約を満たす統一フォーマットＭＱデータは、ＳＤＫを経由してＤＥＳアダプタ３０７０におけるＤＥＳリアアダプタ３１３０にプッシュされる。

【0121】

ＤＥＳリアアダプタ３１３０は、ＴＴＰ ＩＤＣから海外ＩＤＣ方向への統一フォーマットＭＱデータを後処理して、データを目的地に配信するために、ＤＥＳプロキシ３０７３の一部として実現されてもよい。データ交換制約を満たす統一フォーマットＭＱデータは、ＳＤＫを経由してＤＥＳリアアダプタ３１３０にプッシュされる。

【0122】

ＤＥＳリアアダプタ３１３０は、統一フォーマットＭＱデータの後処理を実行するためのデータ再生器３１３２を含んでもよい。具体的には、ＤＥＳリアアダプタ３１３０は、統一フォーマットＭＱデータを生ＭＱデータに変換するように構成されてもよい。そのため、ＤＥＳリアアダプタ３１３０は、統一フォーマットからそれぞれのカスタムフォーマットへの変換を実行するために、異なるタイプのＭＱデータに対応する再生器（ｒｅｐｌａｙｅｒ）を含んでもよい。図３Ｆに示すように、ＤＥＳリアアダプタ３１３０は、統一フォーマットＭＱデータをＭｙＳＱＬ（登録商標）プロトコルに適合するＭＱデータに変換するためのＭｙＳＱＬ（登録商標）再生器と、統一フォーマットＭＱデータをＲｅｄｉｓプロトコルに適合するＭＱデータに変換するためのＲｅｄｉｓ再生器と、統一フォーマットＭＱデータをグラフィックス式の生データに変換するためのドキュメント再生器と、統一フォーマットデータをＭＱプロトコルに適合する生データに変換するためのＭＱ再生器となどを含んでもよい。

【0123】

変換後の生ＭＱデータは、ＤＥＳリアアダプタ３１３０における統一フォーマットメッセージのキュー３１３４に入れられ、そこからターゲットメッセージキュー３１３５に同期されてもよい。ターゲットメッセージキュー３１３５は、ソースメッセージキュー３１１２からＤＥＳ １０４０を経由して間接的に同期されたＭＱデータを保管するために用いられる。ターゲットデータベース３１３６は、ターゲットメッセージキュー３１３５から期待するＭＱデータを得ることができる。

【0124】

図３Ｆには、ＴＴＰ ＩＤＣから海外ＩＤＣ方向へのデータ交換に関わるアセンブリのみが示された。図３Ｆの例では、海外ＩＤＣからＴＴＰ ＩＤＣ方向へのデータ交換を示しており、ＤＥＳ １０４０には、この方向のデータ交換を処理するための類似するアセンブリが含まれてもよく、例えばＤＥＳアダプタ３０７０は、ＤＥＳフロントアダプタ３１２０と類似する機能を有するＤＥＳフロントアダプタを含んでもよく、ＤＥＳアダプタ３０６１は、ＤＥＳリアアダプタ３１３０と類似する機能を有するＤＥＳリアアダプタを含んでもよい。簡略化の目的のため、この方向の処理は、詳細な展開を省略する。

【0125】

理解できるように、図３Ｆに示すＤＥＳにおいてＭＱデータ交換を処理するためのアセンブリは、一例に過ぎない。他の例では、必要に応じて、異なる機能モジュールは、他の方式で細分化、統合などされてもよく、より多くの、より少なくの又は異なる機能モジュールをさらに含んでもよい。

【0126】

（オフライン集約データに対するデータ交換の例示的実現）
図３Ｇは、本開示のいくつかの実施例によるＨＤＦＳチャンネルに関するデータ交換アーキテクチャ３５００の概略ブロック図を示した。データ交換アーキテクチャ３５００は、オフライン集約データに対してデータセキュリティ保護を実行するために、ＤＥＳ １０４０に実現されてもよい。図３Ｇの例では、ＴＴＰ ＩＤＣ側のＨＤＦＳ ３５０２と海外ＩＤＣ側のＨＤＦＳ ３５０４との間でのオフライン集約データ交換を示した。ＨＤＦＳ ３５０２とＨＤＦＳ ３５０４におけるいくつかのオフライン集約データは、互いに同期する必要があるかもしれない。

【0127】

図３Ｇに示すように、データ交換アーキテクチャ３５００において、ＴＴＰ ＩＤＣ側のデータ配信検出器３５１０は、ＨＤＦＳ ３５０２に、他方側のＨＤＦＳ ３５０４に配信される必要があるオフライン集約データが記憶されているかどうかを検出することを担当する。配信すべきオフライン集約データを発見した場合に、データ配信トランスミッタ３５２０は、ファイル送信機３５５０にデータ配信の要求を渡してもよい。ファイル送信機に渡される間に、データ前処理モジュール３５３０は、データの前処理を実行して、オフライン集約データを統一フォーマットデータとして処理するように構成される。

【0128】

ファイル送信機３５５０において、データ配信サーバ３５５６は、データ交換制約の利用に基づいてデータ配信サービスを制御するように構成される。データ配信サーバ３５５６は、ＨＤＦＳ ３５０２からの前処理後の統一フォーマットデータがデータ交換制約に適合していると決定した場合、配信ワーク３５５８を呼び出して、統一フォーマットデータを配信ワーク３５５８の下の配信タスク３５６２を介して海外ＩＤＣに配信してもよい。いくつかの実施例では、配信ワーク３５５８は、選択的にデータ検証タスク３５６０をさらに含んでもよく、それは、必要に応じてデータ検証を実行するように構成されてもよい。統一フォーマットデータは、ＨＤＦＳゲートウェイ３５６４を通過し、後処理が実行された後に、オリジナルのオフライン集約データを得て、ＨＤＦＳ ３５０４に記憶されてもよい。

【0129】

類似的に、データ交換アーキテクチャ３５００において、海外ＩＤＣ側のデータ配信検出器３５７０は、ＨＤＦＳ ３５０４に、ＴＴＰ ＩＤＣ側のＨＤＦＳ ３５０２に配信される必要があるオフライン集約データが記憶されているかどうかを検出することを担当する。配信すべきオフライン集約データを発見した場合に、データ配信トランスミッタ３５７２は、ファイル送信機３５５０にデータ配信の要求を渡してもよい。ファイル送信機に渡される前に、データ前処理モジュール３５７０は、データの前処理を実行して、オフライン集約データを統一フォーマットデータとして処理するように構成される。

【0130】

ファイル送信機３５５０において、データ配信サーバ３５５６は、ＨＤＦＳ ３５０４からの前処理後の統一フォーマットデータがデータ交換制約に適合していると決定した場合、配信ワーク３５５４を呼び出して、統一フォーマットデータを配信ワーク３５５４の下の配信タスク３５５２を介してＴＴＰ ＩＤＣに配信してもよい。統一フォーマットデータは、後処理を経た後に、オリジナルオフライン集約データを得て、ＨＤＦＳ ３５０２に記憶される。

【0131】

理解できるように、図３Ｇに示すＤＥＳにおいてオフライン集約データ交換を処理するためのアセンブリは、一例に過ぎない。他の例では、必要に応じて、異なる機能モジュールは、他の方式で細分化、統合などされてもよく、より多くの、より少なくの又は異なる機能モジュールをさらに含んでもよい。

【0132】

（オブジェクトストアに対するデータ交換の例示的実現）
全体として、ＴＯＳチャンネルは、オブジェクトファイルがデータ交換制約を満たすかどうかを決定し、制約を満たす場合にオブジェクトファイルをソースＩＤＣ（例えば、ＴＴＰ ＩＤＣ又は海外ＩＤＣ）から目的地ＩＤＣ（例えば、海外ＩＤＣ又はＴＴＰ ＩＤＣ）にコピーすることができる。オブジェクトファイルは、例えばビデオ、オーディオ、画像、ドキュメント、又は他のメディアファイルである。

【0133】

いくつかの実施例では、ＡＰＩを介してオブジェクトストアからオブジェクトファイルをコピーし、データ交換制約の決定を実行し、ＡＰＩを利用してオブジェクトファイルを目的地端のオブジェクトストアにプッシュしてもよい。オブジェクトファイルのデータ交換中に、オブジェクトファイルに対応するコピー要求によってデータ交換制約が満たされているかどうかを決定する。以下では、図３Ｈから図３Ｊを参照してＴＯＳチャンネルの詳細を記述する。

【0134】

図３Ｈは、本開示のいくつかの実施例によるデータのＴＴＰ ＩＤＣから海外ＩＤＣへのコピーのターゲットオブジェクトストア（ＴＯＳ）チャンネル３６００の概略図を示した。この例では、交換されるデータは、オブジェクトファイルであり、それは、ＴＴＰ ＩＤＣにおけるオブジェクトストア３６０６に記憶され、海外ＩＤＣのオブジェクトストア３６０７に交換されることを期待する。

【0135】

図３Ｈにおいて、ＴＴＰ ＩＤＣにおけるＡＰＩ ３６０５は、コピー要求をワークノード３６０５にプッシュし、ワークノード３６０５から他方側の海外ＩＤＣから交換されたコピー結果を受信するように構成される。図に示すように、データストリーム開始３６０１の時に、交換されるオブジェクトファイルに対するコピー要求は、ＡＰＩ（ＤＥＳ－ＴＯＳ ＡＰＩと呼ばれてもよい）３６０２によってワークノード３６０５に配信される。このコピー要求は、交換されるオブジェクトファイルに関連する情報、例えばオブジェクトファイルのフォーマット（ビデオ、オーディオ、テキストなど）、オブジェクトファイルの識別子、及び他のファイルメタデータなどを指示することができる。このコピー要求は、統一フォーマットを有する。

【0136】

信頼領域ＶＰＣ２内のワークノード３６０５は、オブジェクトファイルに対するコピー要求に応答し、データ交換制約に関する決定を実行するように構成される。具体的には、ワークノード３６０５は、統一フォーマットのコピー要求から交換されるオブジェクトファイルがデータ交換制約を満たすかどうかを決定することができる。

【0137】

いくつかの実施例では、ＴＴＰ ＩＤＣ側において、初期段階又は後続の必要な時にデータ交換制約の登録を開始してもよい。制約登録開始３６２２の時に、ＴＴＰ ＩＤＣにおけるＤＥＳエントリ３６２０を介して、ＴＴＰ信頼領域におけるＤＥＳ登録センタ３６２４に使用されるデータ交換制約を登録してもよい。データ交換制約の登録は、ＡＰＩ ３６０２を呼び出すことによって実現されてもよい。ワークノード３６０５は、ＤＥＳ登録センタ３６２４を介して現在使用されるデータ交換制約にアクセスしてもよい。

【0138】

いくつかの実施例では、データ交換制約は、交換が許容されるオブジェクトファイルのホワイトリスト又は交換が許容されないオブジェクトファイルのブラックリストを指示してもよく、各リストにおいてオブジェクトファイルのフォーマット、識別子などによって交換が許容されるか又は許容されないファイルオブジェクトを識別してもよい。

【0139】

データ交換制約を実行する際に、ワークノード３６０５は、データ交換制約を満たすコピー要求の実行を許容する。コピー要求の実行が許容される場合、ワークノード３６０５は、ＴＴＰ ＩＤＣにおけるオブジェクトストア３６０６にアクセスしてオブジェクトファイルを海外ＩＤＣにおけるオブジェクトストア３６０７にコピーする。不正な要求（即ちデータ交換制約を満たさないコピー要求）に対して、それらが拒否され、それによって実行されることができない。ワークノード３６０５は、コピーされたオブジェクトファイルを海外ＩＤＣにおけるＡＰＩ ３６１０を経由してオブジェクトストア３６０７に書き込んでもよい。このように、データストリーム終了３６１１になる。

【0140】

図３Ｉは、本開示のいくつかの実施例によるデータの海外ＩＤＣからＴＴＰ ＩＤＣへのコピーのＴＯＳチャンネル３６５０の概略図を示した。この例では、交換されるオブジェクトファイルは、海外ＴＴＰ ＩＤＣにおけるオブジェクトストア３６０７に記憶され、ＴＴＰ ＩＤＣのオブジェクトストア３６０６に交換されることを期待する。

【0141】

図３Ｉにおいて、海外ＩＤＣにおけるＡＰＩ ３６１０は、コピー要求をワークノード３６０５にプッシュし、ワークノード３６０５から他方側のＴＴＰ ＩＤＣから交換されたコピー結果を受信するように構成される。図３Ｉに示すように、データストリーム開始３６５１の時に、交換されるオブジェクトファイルに対するコピー要求は、ＡＰＩ ３６１０によってワークノード３６０５に配信される。このコピー要求は、交換されるオブジェクトファイルに関連する情報、例えばオブジェクトファイルのフォーマット（ビデオ、オーディオ、テキストなど）、オブジェクトファイルの識別子、及び他のファイルメタデータなどを指示することができる。このコピー要求は、統一フォーマットを有する。信頼領域ＶＰＣ２内のワークノード３６０５は、統一フォーマットのコピー要求から交換されるオブジェクトファイルがデータ交換制約を満たすかどうかを決定することができる。

【0142】

いくつかの実施例では、海外ＩＤＣ側において、初期段階又は後続の必要な時にデータ交換制約の登録を開始してもよい。制約登録開始３６３２の時に、海外ＩＤＣにおけるＤＥＳエントリ３６３０を介して、ＴＴＰ信頼領域におけるＤＥＳ登録センタ３６２４に使用されるデータ交換制約を登録してもよい。データ交換制約の登録は、ＡＰＩ ３６１０を呼び出すことによって実現されてもよい。ワークノード３６０５は、ＤＥＳ登録センタ３６２４を介して現在使用されるデータ交換制約にアクセスしてもよい。

【0143】

データ交換制約を実行する時に、ワークノード３６０５は、データ交換制約を満たすコピー要求の実行を許容する。コピー要求許容が実行される場合、ワークノード３６０５は、海外ＩＤＣにおけるオブジェクトストア３６０７にアクセスしてオブジェクトファイルをＴＴＰ ＩＤＣにおけるオブジェクトストア３６０６にコピーする。不正な要求（即ちデータ交換制約を満たさないコピー要求）に対して、それらが拒否され、それによって実行されることができない。ワークノード３６０５は、コピーされたオブジェクトファイルをＴＴＰ ＩＤＣにおけるＡＰＩ ３６０２を経由してオブジェクトストア３６０６に書き込んでもよい。このように、データストリーム終了３６５２になる。

【0144】

理解できるように、図３Ｈと図３Ｉに示すＤＥＳにおいてＴＯＳデータ交換を処理するためのアセンブリは、一例に過ぎない。他の例では、必要に応じて、異なる機能モジュールは、他の方式で細分化、統合などされてもよく、より多くの、より少なくの又は異なる機能モジュールをさらに含んでもよい。

【0145】

図３Ｊは、本開示のいくつかの実施例によるＴＯＳチャンネルにおけるメッセージシーケンス３０１２を示した。図３Ｊにおけるメッセージシーケンス３０１２は、ＴＴＰ ３７０１、運用保守者３７０２、プラットフォームスタッフ３７０３、ＤＥＳエントリ３７０４、ＡＰＩ ３７０５、ワークノード３６０５とオブジェクトストア３７０８に関する。

【0146】

データ交換の方向によって、図３ＪにおけるＤＥＳエントリ３７０４、ＡＰＩ ３７０５とオブジェクトストア３７０８は、図３Ｈと図３Ｉのうちのいずれか一つにおける対応するアセンブリであってもよい。例えば、図３Ｈに示すＴＴＰ ＩＤＣから海外ＩＤＣにコピーされるＴＯＳチャンネル３６００において、ＤＥＳエントリ３７０４は、図３Ｈに示すＤＥＳエントリ３６２０を含み、ＡＰＩ ３７０５は、図３ＨにおけるＡＰＩ ３６０２を含み、オブジェクトストア３７０８は、図３Ｈにおけるオブジェクトストア３６０６を含む。海外ＩＤＣからＴＴＰ ＩＤＣにコピーされるＴＯＳチャンネル３６５０において、ＤＥＳエントリ３７０４は、図３Ｉに示すＤＥＳエントリ３６３０を含み、ＡＰＩ ３７０５は、図３ＩにおけるＡＰＩ ３６１０を含み、オブジェクトストア３７０８は、図３Ｉにおけるオブジェクトストア３６０７を含む。

【0147】

メッセージシーケンス３０１２において、運用保守者３７０２は、オブジェクトファイルの異なるＩＤＣのオブジェクトストア３６０６と３６０７との間でのコピーを制約できるＤＥＳエントリ３７０４にデータ交換制約を登録する３７１１。登録が完了した後に、ＤＥＳエントリ３７０４は、運用保守者に応答を送信する３７１４ことができる。ＤＥＳエントリ３７０４は、ＡＰＩ ３７０５にデータ交換制約に関するコンテナ情報を登録し３７１２、登録が完了した後にＡＰＩ ３７０５は、ＤＥＳエントリ３７０４に応答を送信する３７１３ことができる。ＤＥＳエントリ３７０４を経由して登録されたルールは、ＡＰＩ ３７０５にキャッシュする３７１５ことができ、ワークノード３６０５にキャッシュされる３７１６こともできる。

【0148】

プラットフォームスタッフ３７０３は、ＡＰＩ ３７０５にオブジェクトファイルに対するコピー要求を開始する３７１７ことができる。ＡＰＩ ３７０５は、認証を実行する３７１８ことができる。ワークノード３６０５は、ＡＰＩ ３７０５からコピー要求をプルし３７１９、コピーされるオブジェクトファイルに対してデータ交換制約の決定を実行する３７２０ことができる。オブジェクトファイルのコピーが許容されている場合、ワークノード３６０５は、ファイルコピーを実行して３７２１、オブジェクトストア３７０６から対応するオブジェクトファイルをコピーする。無論、データ交換決定を満たさない結果にかかわらず、ワークノード３６０５は、ＡＰＩ ３７０５にフィードバックを返す３７２２。オブジェクトファイルのコピーが許容されている場合に、フィードバックは、コピーされたオブジェクトファイルを含む。オブジェクトファイルのコピーが許容されていない場合に、フィードバックは、コピー要求が拒否されたことを指示するために用いられる。

【0149】

いくつかの実施例では、プラットフォームスタッフ３７０３は、ＡＰＩ ３７０５をコールバックすることができ３７２３、ＡＰＩ ３７０５からプラットフォームスタッフ３７０３にコピー要求ＩＤを返す３７２４ことができる。いくつかの実施例では、ＴＴＰ ３７０１は、ＤＥＳエントリ３７０４を介してオブジェクトファイルコピーの履歴状況を見て３７２５、過去のある時間内にオブジェクトファイルの交換がデータ交換制約の要求に適合しているかどうかを確認することができる。ＤＥＳエントリ３７０４は、見るべき結果を返す３７２６ことができる。

【0150】

（サービス呼び出しに対するデータ交換保護の例示的実現）
図３Ｋは、本開示のいくつかの実施例によるサービス呼び出しチャンネルに関するデータ交換アーキテクチャ３８００の概略ブロック図を示した。データ交換アーキテクチャ３８００は、サービス呼び出しタイプのデータに対してデータセキュリティ保護を実行するために、ＤＥＳ １０４０に実現されてもよい。図３Ｌの例では、ＴＴＰ ＩＤＣ側のターゲットプラットフォームサービス３８０２と海外ＩＤＣ側の海外（非ＴＴＰ）プラットフォームサービス３８０４との間でのサービス呼び出しデータ交換を示した。例えば、ターゲットプラットフォームサービス３８０２上のサービスは、海外プラットフォームサービス３８０４上のサービスを呼び出す必要があるかもしれないが、逆に、海外プラットフォームサービス３８０４のサービスも、ターゲットプラットフォームサービス３８０２上のサービスを呼び出す必要があるかもしれない。

【0151】

異なるサービスプラットフォームは、様々な異なるサービス呼び出しプロトコル、例えばＨＴＴＰプロトコル又はＴｈｒｉｆｔ ＲＰＣプロトコルを応用する可能性がある。本開示のいくつかの実施例では、ＶＰＣ信頼領域においてデータ主権保護を実行する時に、統一フォーマットデータ、例えばＨＴＴＰプロトコルデータを処理できることを希望する。

【0152】

図３Ｋにおいて、コントロールプレーンでは、非ＴＴＰコントロールプレーンは、チャンネル登録、チャンネルアーキテクチャ更新、検出のために用いられ、ＴＴＰ／ＴＴＰコントロールプレーンは、チャンネル要求承認、チャンネル禁止、チャンネル検出などのために用いられる。データプレーンでは、ＨＴＴＰロードバランサ３８１０は、ＴＴＰ ＣｌｏｕｄからのＬ７等化製品であり、すべてのＤＥＳ－ＲＰＣチャンネルトラフィックがＶＰＣ信頼領域を通過することを確保する肝心なアセンブリである。ＨＴＴＰチャンネルは、ＤＥＳ－ＲＰＣチャンネルのうちのＨＴＴＰプロトコルをサポートするチャンネルである。Ｔｈｒｉｆｔ ＲＰＣチャンネルは、ＤＥＳ－ＲＰＣチャンネルのうちのＴｈｒｉｆｔ ＲＰＣプロトコルをサポートするチャンネルである。ＴＴＰのＨＴＴＰロードバランサに送信される前に、Ｔｈｒｉｆｔ ＲＰＣチャンネルは、ＨＴＴＰチャンネルにラップされる。

【0153】

チャンネル登録段階では、ＤＥＳ－ＲＰＣチャンネルは、チャンネル情報とデータ定義を利用してアナウンスされる。チャンネル情報は、チャンネルのタイプ、例えばＴｈｒｉｆｔ ＲＰＣ又はＨＴＴＰを含んでもよい。チャンネル情報は、ＲＰＣ呼び出しタプルをさらに含んでもよい。呼び出しタプルは、ｓｒｃ ｄｃ、ｓｒｃサービス、ｄｓｔ ｄｃ、ｄｓｔサービス、ｒｐｃ方法／ｈｔｔｐルートを含んでもよい。

【0154】

データ定義は、データの流れ方向に依存してもよい。非ＴＴＰからＴＴＰへのデータ流れについて、コンプライアンスコメント付きのＴｈｒｉｆｔ ＩＤＬで応答をアナウンスする。ＴＴＰから非ＴＴＰへのデータ流れについて、コンプライアンスコメント付きのＴｈｒｉｆｔ ＩＤＬで要求をアナウンスする。いくつかの実施例では、ＤＥＳ－ＲＰＣチャンネルがコンプライアンス登録に合格した場合にのみ、ＤＥＳ－ＲＰＣチャンネルは、利用可能である。

【0155】

理解できるように、図３Ｋに示すＤＥＳにおいてサービス呼び出しデータ交換を処理するためのアセンブリは、一例に過ぎない。他の例では、必要に応じて、異なる機能モジュールは、他の方式で細分化、統合などされてもよく、より多くの、より少なくの又は異なる機能モジュールをさらに含んでもよい。

【0156】

図３Ｌは、本開示のいくつかの実施例による図３Ｋに示すサービス呼び出しチャンネルにおける非ＴＴＰからＴＴＰへのデータ交換例を示した。図３Ｌに示すように、海外領域のサービスＡ ３９０１によって開始された呼び出しは、ＨＴＴＰプロキシ３９０２又はＴｈｒｉｆｔプロキシ３９０３によってＴＴＰのＨＴＴＰロードバランサ３９０５に転送される。サービスＡ ３９０１は、図３Ｋに示す海外プラットフォームサービスの一例であってもよい。ＨＴＴＰ要求に対して、呼び出しは、ＨＴＴＰプロキシ３９０２によってＨＴＴＰロードバランサ３９０５に転送される。Ｔｈｒｉｆｔ要求に対して、呼び出しは、Ｔｈｒｉｆｔプロキシ３９０３によってＨＴＴＰロードバランサ３９０５に転送される。

【0157】

海外ＩＤＣにおける対応するサービスプロキシ、例えばＨＴＴＰプロキシ３９０２又はＴｈｒｉｆｔプロキシ３９０３からＶＰＣ信頼領域ＨＴＴＰロードバランサ３９０５へのサービス発見は、ＤＮＳによって実現されることが提案され、対応する要求がＴＴＰ ＩＤＣ領域に転送されるプロキシのサービス発見は、カスタマイズ／汎用的なサービス発見を使用することが提案される。

【0158】

ＨＴＴＰロードバランサ３９０５は、コンプライアンスプラグイン３９０６を含んでもよい。不正な要求に対して、コンプライアンスプラグイン３９０６は、エラーを返す。Ｔｈｒｉｆｔ ｒｐｃ呼び出しに対して、要求は、ＨＴＴＰでラップされて新たなＨＴＴＰ要求が生成される。新たなＨＴＴＰ要求の本体は、Ｔｈｒｉｆｔバイナリファイルである。

【0159】

ＶＰＣ信頼領域において、ＴＴＰのＨＴＴＰロードバランサ３９０５は、ＴＴＰのＨＴＴＰプロキシ３９０７とＴｈｒｉｆｔプロキシ３９０８とに要求をそれぞれ転送し、そしてＨＴＴＰプロキシ３９０７とＴｈｒｉｆｔプロキシ３９０８とは、ターゲットサービスであるサービスＢ ３９０８とサービスＣ ３９１０とに要求をそれぞれ転送する。Ｔｈｒｉｆｔ ｒｐｃ呼び出しに対して、Ｔｈｒｉｆｔプロキシ３９０８は、要求を送信する前に生成された新たなＨＴＴＰ要求から元のＴｈｒｉｆｔ要求を回復する。

【0160】

ＴＴＰのＨＴＴＰプロキシ３９０７とＴｈｒｉｆｔプロキシ３９０８とは、ＴＴＰのＨＴＴＰロードバランサ３９０５に応答を送信する前に応答を検査する。コンプライアンス検査に合格しなかった応答に対して、エラーを返す。なお、Ｔｈｒｉｆｔ ｒｐｃ呼び出しに対して、Ｔｈｒｉｆｔ応答は、ＨＴＴＰでラップされて新たなＨＴＴＰ応答が生成される。新たなＨＴＴＰ応答の本体は、Ｔｈｒｉｆｔバイナリファイルである。

【0161】

図３Ｍは、本開示のいくつかの実施例による図３Ｋに示すサービス呼び出しチャンネルにおけるＴＴＰから非ＴＴＰへのデータ交換例を示した。図３Ｍに示すように、ＴＴＰのサービスＡ ３９５１によって開始された呼び出しは、ＴＴＰのＨＴＴＰプロキシ３９５２とＴｈｒｉｆｔプロキシ３９５３とによってＴＴＰのＨＴＴＰロードバランサ３９５５に転送される。ＨＴＴＰ要求に対して、呼び出しは、ＨＴＴＰプロキシ３９５２によってＨＴＴＰロードバランサ３９５５に転送される。Ｔｈｒｉｆｔ要求に対して、呼び出しは、Ｔｈｒｉｆｔプロキシ３９５３によってＨＴＴＰロードバランサ３９５５に転送される。

【0162】

不正な要求に対して、エラーを返す。コンプライアンス検査に合格しなかった応答に対して、エラーを返す。Ｔｈｒｉｆｔ ｒｐｃ呼び出しに対して、要求は、ＨＴＴＰでラップされて新たなＨＴＴＰ要求が生成される。新たなＨＴＴＰ要求の本体は、Ｔｈｒｉｆｔバイナリファイルである。

【0163】

ＴＴＰのＨＴＴＰロードバランサ３９５５は、要求を非ＴＴＰ（即ち、海外領域）のＨＴＴＰプロキシ３９５７とＴｈｒｉｆｔプロキシ３９５８とに転送する。そしてＨＴＴＰプロキシ３９５７とＴｈｒｉｆｔプロキシ３９５８とは、要求を海外領域のサービスＢ ３９５９とサービスＣ ３９６０とに転送する。

【0164】

Ｔｈｒｉｆｔ ｒｐｃ呼び出しに対して、Ｔｈｒｉｆｔプロキシは、送信する前に生成された新たなＨＴＴＰ要求から元のＴｈｒｉｆｔ要求を回復する。

【0165】

非ＴＴＰのＨＴＴＰプロキシ３９５７とＴｈｒｉｆｔプロキシ３９５８とは、ＴＴＰのＨＴＴＰロードバランサ３９５５に応答を送信する。Ｔｈｒｉｆｔ ｒｐｃ呼び出しに対して、Ｔｈｒｉｆｔ応答は、ＨＴＴＰでラップされて新たなＨＴＴＰ応答が生成される。新たなＨＴＴＰ応答の本体は、Ｔｈｒｉｆｔバイナリファイルである。

【0166】

（セキュリティサンドボックスサブシステム）
クライアントアプリは、データを伝送するためにサーバと通信する必要がある。クライアントアプリのネットワークトラフィックは、大量のユーザデータを伝送することができる。そのため、ユーザデータがクライアントアプリのネットワークトラフィックを経由して許容されないサーバに伝送されないように、クライアントアプリを管理できるネットワークトラフィックの方法を必要とする。例えば、データ主権保護のシナリオでは、この方法は、ユーザデータがデータ主権国以外のサーバに伝送されることを防止することができる。

【0167】

しかしながら、クライアントアプリのネットワークトラフィックのタイプは、非常に豊富である。クライアントアプリは、モバイル端アプリとコンピュータ（ＰＣ端）アプリとを含んでもよい。クライアントアプリのネットワークトラフィックは、ネイティブタイプのネットワークトラフィックとウェブページビュータイプのネットワークトラフィックなどを含んでもよい。なお、クライアントアプリのネットワークトラフィックが、すべてアプリの所有者によって管理と制御されるわけではない。例えば、クライアントアプリのネットワークトラフィックは、サード・パーティ広告主からのネットワークトラフィックを含んでもよい。そのため、クライアントアプリの様々なタイプのネットワークトラフィックを管理することは、非常に困難である。

【0168】

本開示の例示的実施例は、クライアントアプリのネットワークトラフィックを管理する方法を提案した。この方法は、ターゲットユーザに対する決定に基づいて、ターゲットユーザのユーザデータのクライアントアプリからサーバへのネットワーク伝送を検出することと、ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、ネットワーク伝送の異なる層でネットワークトラフィックを分析することと、ネットワークトラフィックがターゲットユーザに対応するデータ交換制約を満たすことを指示するとの分析に基づいて、ネットワークトラフィックをデータ交換制約によって限定されるサーバに送信することとを含む。

【0169】

この方式により、ネットワークトラフィックのタイプに基づいてネットワーク伝送の異なる層でネットワークトラフィックを分析し、データ交換制約を満たさないネットワークトラフィックの伝送を制限することによって、ユーザデータが様々なタイプのネットワークトラフィックを経由して許容されないサーバに伝送されることを効果的に防止することができる。

【0170】

以下では、図面を参照して本開示の実施例を具体的に技術する。以下では、モバイル端アプリを例にして本開示の方案を例示的に説明する。

【0171】

図４Ａは、本開示のいくつかの実施例によるモバイル端アプリのネットワークトラフィックを管理する例示的方法４１００のフローチャートを示した。この方法４１００は、例えば図１のセキュリティサンドボックスサブシステム１０９０において実施することができる。モバイル端アプリは、モバイル端のターゲットアプリ１０８０であってもよい。

【0172】

ボックス４１０２において、ターゲットユーザに対する決定に基づいて、ターゲットユーザのユーザデータのターゲットアプリ１０８０からサーバへのネットワーク伝送を検出する。言い換えれば、現在のユーザがターゲットユーザであると決定した場合、セキュリティサンドボックスサブシステム１０９０は、ターゲットユーザのユーザデータのネットワーク伝送を検出することができる。

【0173】

いくつかの実現では、セキュリティサンドボックスサブシステム１０９０がユーザデータのネットワーク伝送に対応するネットワークトラフィックを検出し分析することができるように、ターゲットユーザに対する決定に基づいてネットワークトラフィックをセキュリティサンドボックスサブシステム１０９０にルーティングしてもよい。セキュリティサンドボックスサブシステム１０９０は、ターゲットアプリ１０８０のネットワーク要求を分析し、データ交換制約に基づいて条件を満たさないネットワーク要求を制限することができる。

【0174】

データ交換制約は、データ主権に関する交換制約、例えばデータ主権保護ルールを含んでもよい。データ主権保護ルールは、各国又は領域の規定に基づいて決定されてもよい。データ主権保護ルールは、アプリの運営側によって決定されてもよい（例えば、ユーザデータ使用プロトコルに関する）。

【0175】

データ主権保護ルールは、具体的なシナリオに基づいて設定されてもよい。例えば、データ主権保護ルールは、データ主権国家のユーザデータがデータ主権国家以外の任意のサーバに伝送されることを許容しないことを規定してもよい。別のいくつかの実現では、データ主権保護ルールは、データ主権国家のプライバシーのユーザデータが登録されていない任意のサーバに伝送されることを許容しないことを規定してもよい。本開示の範囲は、これに対して制限しない。

【0176】

図１に示すように、ターゲットアプリ１０８０のネットワーク要求は、セキュリティサンドボックスサブシステム１０９０による分析と処理を経た後にアプリファイアウォールサブシステム１０２０に伝送される。セキュリティサンドボックスサブシステム１０９０の原理と詳細は、以下で詳細に記述する。

【0177】

ターゲットユーザとは、そのユーザデータの伝送が検出と管理される必要があるユーザである。ターゲットユーザは、データ主権国家の国籍を有するユーザであってもよい。代替的に又は追加的に、ターゲットユーザは、データ主権保護の具体的なルールに基づいて決定されたユーザであってもよい。例えば、ターゲットユーザは、データ主権国家の国籍を有し、現在地理的にこのデータ主権国家に位置しているユーザであってもよい。

【0178】

いくつかの実現では、ユーザ情報に基づいてターゲットユーザを決定してもよい。ユーザ情報は、ユーザのアカウント情報、個人情報、登録情報などを含んでもよい。代替的に又は追加的に、機器情報に基づいてターゲットユーザを決定してもよい。機器情報は、ユーザ身分識別モジュール（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ、ＳＩＭ）情報、ＩＰアドレス、ネットワークサービスプロバイダ情報、機器のシステム設定情報、アプリ設定情報などを含んでもよい。

【0179】

いくつかの実現では、様々な情報の組み合わせに基づいてターゲットユーザを決定してもよい。様々な情報は、異なる優先度を有してもよい。例えば、ＳＩＭ情報、ネットワークサービスプロバイダ情報の優先度は、ＩＰアドレス、システム設定情報、アプリ設定情報などよりも高くてもよい。

【0180】

いくつかの実現では、ターゲットユーザに対する決定は、ターゲットユーザが位置する地域に対する決定に基づいてもよい。上記ユーザ情報又は機器情報を利用してターゲットユーザが位置する地域を決定することによって、ターゲットユーザを決定してもよい。例えば、スマートフォンのシステム設定における地域設定を利用して現在のユーザが位置する地域を決定し、それによって現在のユーザがターゲットユーザであるかどうかを決定してもよい。また例えば、ＳＩＭカードの国コードを利用してターゲットユーザが位置する地域を決定し、それによってターゲットユーザを決定してもよい。

【0181】

いくつかの実現では、アプリを初回起動する時にターゲットユーザを決定してもよい。言い換えれば、アプリを初回起動する時に現在のユーザがターゲットユーザであるかどうかを決定してもよい。代替的に又は追加的に、ユーザ登録時に現在のユーザがターゲットユーザであるかどうかを決定してもよい。代替的に又は追加的に、ユーザがログインし、ログアウトし、アカウントを切り替える時に現在のユーザがターゲットユーザであるかどうかを決定してもよい。

【0182】

いくつかの実現では、決定結果をローカル又はサーバに記憶してもよい。ユーザがターゲットユーザであると１回目に決定した後に決定結果を記憶し、閾値時間帯内に記憶された決定結果を使用するように設定してもよい。このように、ユーザが再度登録する時に、ユーザを再度決定する必要がなくなる。

【0183】

ボックス４１０４において、ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、ネットワーク伝送の異なる層でネットワークトラフィックを分析する。

【0184】

ターゲットアプリ１０８０におけるネットワークトラフィックは、複数のタイプのネットワークトラフィック、例えばネイティブ（ｎａｔｉｖｅ）、ウェブページビュー（Ｗｅｂｖｉｅｗ）とサード・パーティソフトウェア開発キット（ＳＤＫ）タイプのネットワークトラフィックを含んでもよい。ネイティブタイプのネットワークトラフィックは、業務層におけるオペレーティングシステム（例えば、アンドロイド（登録商標）とＩＯＳ）コードによって発生され、処理される。ネイティブタイプのネットワークトラフィックは、ターゲットアプリ１０８０の所有者によって完全に制御されてもよい。

【0185】

サード・パーティＳＤＫタイプのネットワークトラフィックは、サード・パーティＳＤＫによって発生され、処理される。一般的には、ターゲットアプリ１０８０において、登録又は共有の機能を実現するために、サード・パーティＳＤＫにアクセスしてもよい。サード・パーティＳＤＫタイプのネットワークトラフィックは、これらのサード・パーティＳＤＫによって発生され、処理される。理解すべきこととして、サード・パーティＳＤＫタイプのネットワークトラフィックは、一般的にアプリの所有者によって完全に制御されるわけではない。

【0186】

ウェブページビュータイプのネットワークトラフィックは、アプリの所有者によって制御されるネットワークトラフィック、例えばアプリに内蔵されたブラウザがネイティブアプリのコードを呼び出すことによって発生したネットワークトラフィックを含んでもよい。ウェブページビュータイプのネットワークトラフィックは、サード・パーティによって制御されるネットワークトラフィック、例えば、サード・パーティ広告主によって発生され、制御されるネットワークトラフィックをさらに含んでもよい。

【0187】

ネットワークトラフィックのタイプに基づいて、セキュリティサンドボックスサブシステム１０９０は、該当する分析ポリシーを採用することによって、アプリにおけるユーザデータのネットワーク伝送をより良く管理することができる。

【0188】

ボックス４１０６において、ネットワークトラフィックがターゲットユーザに対応するデータ交換制約を満たすことを指示するとの分析に基づいて、ネットワークトラフィックをデータ交換制約によって限定されるサーバに送信する。異なるターゲットユーザに異なるデータ交換制約を設定してもよい。例えば、機密性がより高いターゲットユーザに対して、より厳しいデータ交換制約を設定してもよい。データ交換制約は、どれらのユーザデータがどれらのサーバに伝送されることができるかを限定してもよい。いくつかの実現では、ターゲットユーザのユーザ情報又は対応する機器情報に基づいてターゲットユーザに対応するデータ交換制約を決定してもよい。

【0189】

いくつかの実現では、セキュリティサンドボックスサブシステム１０９０は、異なるタイプのネットワークトラフィックに対する複数のサブモジュール、例えば、ネイティブタイプのネットワークトラフィックを管理するためのサブモジュールと、ウェブページビュータイプのネットワークトラフィックを管理するためのサブモジュールと、サード・パーティＳＤＫタイプのネットワークトラフィックを管理するためのサブモジュールとを含んでもよい。これらのサブモジュールは、該当するタイプのネットワークトラフィックを分析し、データ交換制約を満たさないネットワークトラフィックを制限又は遮断することができる。以下では、図４Ｂから図４Ｅを参照して異なるタイプのネットワークトラフィックの管理の詳細について詳細に記述する。

【0190】

図４Ｂは、本開示のいくつかの実施例によるネイティブタイプのネットワークトラフィックに対する分析及び制限プロセス４２００の概略図を示した。図４Ｂは、ネイティブタイプのネットワークトラフィックを分析及び制限するためのサブモジュール４２１０を示した。サブモジュール４２１０は、セキュリティサンドボックスサブシステム１０９０の一部であってもよく、セキュリティサンドボックスサブシステム１０９０の具体的な実現方式であってもよい。

【0191】

図４Ｂに示すように、業務ロジック層４２２０は、ネットワーク要求を下位ＯＳ ４２３０に発する。業務ロジック層４２２０は、図１に示すアプリサービスロジック１１００のネットワーク伝送に関する具体的な実現であってもよい。サブモジュール４２１０は、ブロッカーとしてネットワーク層でネットワーク要求を分析し制限することができる。サブモジュール４２１０は、エンドポイント、ネットワーク要求のパラメータ、又はスキーマ（ｓｃｈｅｍａ）を分析することによってネットワーク要求を制限することができる。例えば、ｓｃｈｅｍａがすでに登録されているかどうかに基づいてこのネットワーク要求を制限するかどうかを決定することができる。代替的に又は追加的に、ネットワーク要求で要求されるフィールドが機密情報に関するかどうかに基づいてこのネットワーク要求を制限するかどうかを決定することができる。

【0192】

いくつかの実現では、サブモジュール４２１０は、アンドロイド（登録商標）に対するブロッカーと、ＩＯＳに対するブロッカーとを含んでもよい。追加的に、サブモジュール４２１０は、Ｃ＋＋に対するブロッカーをさらに含んでもよい。この方式により、ネットワーク層でネットワーク要求を分析し制限することによって、ネットワーク要求のプロトコル情報に基づいてこのネットワーク要求が制限されるべきであるかどうかをより良く判断することができる。

【0193】

図４Ｃは、本開示のいくつかの実施例によるウェブページビュータイプのネットワークトラフィックに対する分析及び制限プロセス４３００の概略図を示した。図４Ｃは、ウェブページビュータイプのネットワークトラフィックを分析し制限するためのサブモジュール４３１０を示した。サブモジュール４３１０は、セキュリティサンドボックスサブシステム１０９０の一部であってもよく、セキュリティサンドボックスサブシステム１０９０の具体的な実現方式であってもよい。

【0194】

サブモジュール４３１０は、ウェブページビュータイプのネットワークトラフィックをネイティブのネットワークインターフェースに遷移して、ウェブページビュータイプのネットワークトラフィックがネイティブタイプのネットワークトラフィックに対するサブモジュール４２１０によって分析及び制限されるようにすることができる。いくつかの実現では、サブモジュール４３１０は、ＪａｖａＳｃｒｉｐｔ（ＪＳ）のフック（ｈｏｏｋ）メカニズムを利用してウェブページビュータイプのネットワークトラフィックをネイティブのネットワークインターフェースに遷移することができる。

【0195】

図４Ｃに示すように、サブモジュール４３１０は、スタータ４３１１と、ナビゲーションＵＲＬブロッカー４３１２と、内部要求ブロッカー４３１３とを含んでもよい。サブモジュール４３１０は、ウェブページビュータイプのネットワークトラフィックがサブモジュール４３１０によって管理と検出されることができるように、アプリに内蔵されたブラウザ４３２０と通信することができる。スタータ４３１１は、ウェブページビュータイプのネットワークトラフィックがｈｏｏｋメカニズムを利用してネイティブのネットワークインターフェースに遷移されることができるように、アプリに内蔵されたブラウザ４３２０が開いている（作成されている）時にＪＳインジェクションを行うことができる。ネイティブのネットワークインターフェースに遷移されたネットワークトラフィックは、ネイティブのネットワークモジュールによって引き継がれることができる。

【0196】

いくつかの実現では、以下のような方式でＪＳ ｈｏｏｋ技術を利用してネットワークトラフィックの遷移を行うことができる。

【0197】

ナビゲーションＵＲＬブロッカー４３１２は、メインページ（初期ページ）のＵＲＬを分析し制限することができる。例えば、ナビゲーションＵＲＬブロッカー４３１２は、ＵＲＬのｓｃｈｅｍａが登録されているかどうかに基づいてこのネットワーク要求を制限するかどうかを決定することができる。このネットワーク要求が制限されない場合、ブラウザ４３２０は、このメインページをロードすることができる。

【0198】

内部要求ブロッカー４３１３は、これらのネットワークトラフィックがサブモジュール４２１０によってネットワーク層で制限と分析されることができるように、メインページの静的リソースと動的リソースに関するネットワークトラフィックをネイティブのネットワークインターフェースに中継接続することができる。具体的な分析及び制限プロセスは、ネイティブタイプのネットワークトラフィックと類似しており、ここでこれ以上説明しない。

【0199】

いくつかの実現では、アプリの所有者によって制御されるウェブページビュータイプのネットワークトラフィックとサード・パーティによって制御されるウェブページビュータイプのネットワークトラフィックとに対して、サブモジュール４３１０は、異なる分析及び制限ポリシーを採用してもよい。例えば、サード・パーティによって制御されるウェブページビュータイプのネットワークトラフィックに対して、メインページの静的リソースと動的リソースをさらに分析する必要がなく、ナビゲーションＵＲＬブロッカー４３１２のみを利用してメインページのＵＲＬが登録されているかどうかを決定することによって関連するネットワークトラフィックを分析することができる。

【0200】

図４Ｄは、本開示のいくつかの実施例によるサード・パーティＳＤＫタイプのネットワークトラフィックに対する分析及び制限プロセス４４００の概略図を示した。図４Ｄは、サード・パーティＳＤＫタイプのネットワークトラフィックを分析し制限するためのサブモジュール４４１０を示した。サブモジュール４４１０は、セキュリティサンドボックスサブシステム１０９０の一部であってもよく、セキュリティサンドボックスサブシステム１０９０の具体的な実現方式であってもよい。

【0201】

サブモジュール４４１０は、アプリケーションプログラミングインターフェース（ＡＰＩ）層でサード・パーティＳＤＫタイプのネットワークトラフィックを分析し制限することができる。サブモジュール４４１０は、ＡＰＩ層でサード・パーティＳＤＫのＡＰＩによって要求されたデータがデータ交換制約を満たすかどうかを分析することによってサード・パーティＳＤＫタイプのネットワークトラフィックを制限することができる。

【0202】

いくつかの実現では、サブモジュール４４１０は、サード・パーティＳＤＫにおいてユーザデータを要求するＡＰＩをラップ（ｗｒａｐ）し、ラップにデータ交換制約に基づく判断ロジックを追加することができる。言い換えれば、サブモジュール４４１０は、サード・パーティＳＤＫのＡＰＩに判断ロジックを追加することによってラップＡＰＩを決定することができる。このように、業務ロジック層４２２０は、サード・パーティＳＤＫのＡＰＩを直接呼び出すのではなく、判断ロジックが追加されたラップＡＰＩを呼び出す。

【0203】

図４Ｄに示すように、サブモジュール４４１０は、それぞれ各サード・パーティＳＤＫに対するラップモジュール、例えば、ＳＤＫ ４４１１に対するラップモジュール４４１２と、ＳＤＫ ４４１３に対するラップモジュール４４１４と、ＳＤＫ ４４１５に対するラップモジュール４４１６を含んでもよい。ラップモジュール（例えば、ラップモジュール４４１２）は、対応するＳＤＫ（例えば、ＳＤＫ ４４１１）におけるＡＰＩをラップして、対応するラップＡＰＩを生成することができる。いくつかの実現では、サブモジュール４４１０は、ラップモジュールを動的に増加させてサード・パーティＳＤＫのＡＰＩをラップすることができる。

【0204】

いくつかの実現では、以下の方式でサード・パーティＳＤＫのＡＰＩをラップすることができる。ラップモジュール４４１２は、業務層に暴露された、ＳＤＫ ４４１１におけるＡＰＩと同じであるＡＰＩを定義することができる。ラップモジュール４４１２は、このＡＰＩを実現し、ＳＤＫ ４４１１データタイプのラップクラスを定義することができる。

【0205】

判断ロジックは、データ交換制約に基づいてラップされたサード・パーティＳＤＫのＡＰＩを呼び出すことができるかどうかを決定することができる。いくつかの実現では、判断ロジックは、ＳＤＫの名称、ＡＰＩの名称、ＡＰＩのパラメータの名称などに基づいてサード・パーティＳＤＫのＡＰＩが呼び出されることができるかどうかを分析することができる。判断結果がＹＥＳである場合、サード・パーティＳＤＫのＡＰＩが呼び出されることができ、業務層に値を返す。判断結果がＮＯである場合、サード・パーティＳＤＫのＡＰＩを呼び出さず、即ち、このＡＰＩに関連するネットワークトラフィックが制限される。理解すべきこととして、判断ロジックは、具体的なシナリオに基づいて変化することができる。例えば、判断ロジックは、サード・パーティＳＤＫにユーザのプライバシーデータを入力することを許容しないように設定されてもよい。

【0206】

この方式により、ＡＰＩ層で分析及び制限を行うことによって、サブモジュール４４１０は、サード・パーティＳＤＫの内部コードを知ることなくサード・パーティＳＤＫタイプのネットワークトラフィックを管理し検出することができる。

【0207】

図４Ｅは、本開示のいくつかの実施例によるセキュリティサンドボックスサブシステム１０９０のモジュール図を示した。図４Ｅに示すように、セキュリティサンドボックスサブシステム１０９０は、起動モジュール４５２０を含む。起動モジュール４５２０は、ターゲットユーザに対する決定に基づいて、ターゲットユーザのユーザデータのクライアントアプリからサーバへのネットワーク伝送に対する検出を起動するように構成される。起動モジュール４５２０は、管理モジュールをアクティブ化してユーザデータのネットワーク伝送に対応するネットワークトラフィックを検出、管理、分析、及び制限することができる。

【0208】

管理モジュールは、ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、ネットワーク伝送の異なる層でネットワークトラフィックを分析し、ネットワークトラフィックがターゲットユーザに対応するデータ交換制約を満たすことを指示するとの分析に基づいて、ネットワークトラフィックをデータ交換制約によって限定されるサーバに送信するように構成される。

【0209】

いくつかの実現では、管理モジュールは、サブモジュール（第一管理モジュールとも呼ばれる）４２１０と、サブモジュール（第二管理モジュールとも呼ばれる）４３１０と、サブモジュール（第三管理モジュールとも呼ばれる）４４１０とを含んでもよい。サブモジュール４２１０と、サブモジュール４３１０と、サブモジュール４４１０とは、クライアントアプリのネットワークトラフィックを分析し制限することができる。

【0210】

いくつかの実現では、サブモジュール４２１０は、ネットワークトラフィックのタイプがネイティブタイプであるネットワークトラフィックに基づいて、ネットワーク層でネットワークトラフィックを分析するように構成される。

【0211】

いくつかの実現では、サブモジュール４３１０は、ネットワークトラフィックのタイプがウェブページビュータイプであるネットワークトラフィックに基づいて、ウェブページビュータイプのネットワークトラフィックをクライアントアプリのネットワークインターフェースに遷移してクライアントアプリのネイティブネットワークモジュールによって管理され、ネットワーク層で遷移されたネットワークトラフィックを分析するように構成される。

【0212】

いくつかの実現では、ウェブページビュータイプのネットワークトラフィックをモバイル端アプリのネットワークインターフェースに遷移することは、ＪａｖａＳｃｒｉｐｔのフックメカニズムを利用してウェブページビュータイプのネットワークトラフィックを遷移することを含む。

【0213】

いくつかの実現では、サブモジュール４４１０は、ネットワークトラフィックのタイプがサード・パーティＳＤＫタイプであるネットワークトラフィックに基づいて、アプリケーションプログラミングインターフェースＡＰＩ層でネットワークトラフィックを分析するように構成される。

【0214】

いくつかの実現では、ＡＰＩ層で前記ネットワークトラフィックを分析することは、サード・パーティＳＤＫのＡＰＩに前記データ交換制約に基づく判断ロジックを追加することによってラップＡＰＩを決定することと、前記判断ロジックを利用して前記ネットワークトラフィックを分析するように前記ラップＡＰＩを呼び出すこととを含む。

【0215】

いくつかの実現では、起動モジュール４５２０は、ターゲットユーザに対する決定に基づいてサブモジュール４２１０、４３１０と４４１０をアクティブ化することができる。例えば、起動モジュール４５２０は、ユーザ登録時に現在のユーザがターゲットユーザであるかどうかを決定することができる。決定結果がＹＥＳである場合、起動モジュール４５２０は、サブモジュール４２１０、４３１０と４４１０をアクティブ化することができる。また例えば、起動モジュール４５２０は、ユーザ登録時にローカル又はサーバからこのユーザに対する決定結果を取得し、決定結果に基づいてサブモジュール４２１０、４３１０と４４１０をアクティブ化するかどうかを決定することができる。

【0216】

セキュリティサンドボックスサブシステム１０９０には、ネットワークトラフィックをサンプリングするためのサンプリングモジュール４５１０がさらに含まれてもよい。いくつかの実現では、サンプリングモジュール４５１０は、起動モジュール４５２０にサンプリング信号を送信して起動モジュール４５２０をトリガーすることができる。サンプリング信号は、ネットワークトラフィックをサンプリングするサンプリングレートを指示することができる。

【0217】

サンプリングモジュール４５１０は、データ交換制約に基づいてターゲットユーザと異なるタイプのネットワークトラフィックとをサンプリングすることができる。例えば、サンプリングモジュール４５１０は、異なるサンプリングレートで異なるタイプのネットワークトラフィックをサンプリングすることができる。サンプリングモジュール４５１０を利用することにより、ネットワークトラフィックの一部のみを分析し、それによってオーバヘッドを低減させ、アプリの安定性を維持することができる。

【0218】

理解すべきこととして、セキュリティサンドボックスサブシステム１０９０は、他のモジュールをさらに含んでもよく、又は図４Ｅに示す部分モジュールのみを含んでもよい。例えば、ターゲットアプリ１０８０がモバイル端のネイティブアプリのみである場合、セキュリティサンドボックスサブシステム１０９０は、ウェブページビュータイプのネットワークトラフィックに対するサブモジュール４３１０を含まなくてもよい。本開示の範囲は、これに対して制限しない。

【0219】

いくつかの実現では、ネットワークトラフィックのタイプに基づいて、ソケット（Ｓｏｃｋｅｔ）層でネットワークトラフィックを分析し制限してもよい。例えば、サード・パーティＳＤＫタイプのネットワーク要求を直接分析できるように、Ｓｏｃｋｅｔ層でサード・パーティＳＤＫタイプのネットワークトラフィックを中継接続してもよい。代替的に又は追加的に、Ｓｏｃｋｅｔ層でネイティブタイプのネットワークトラフィック及びウェブページビュータイプのネットワークトラフィックを分析し制限してもよい。

【0220】

いくつかの実現では、ターゲットアプリ１０８０上にプロキシとしてのローカルサーバを確立してもよい。ターゲットアプリ１０８０のネットワーク要求をローカルサーバに転送し、ローカルサーバでネットワークトラフィックを分析し制限することにより、ローカルサーバによって外部サーバに転送されたネットワーク要求を管理することができる。この方式により、プロトコル情報を考慮したうえで異なるタイプのネットワークトラフィックを分析し制限することができ、それによってアプリのネットワークトラフィックが許容されない外部サーバに伝送されないようにより良く管理する。

【0221】

以上、図４Ｂから図４Ｅを参照して異なるタイプのネットワークトラフィックの分析及び制限の原理と詳細について詳細に記述した。理解すべきこととして、上記制限ルール、判断ロジックとデータ交換制約は、例示的なものに過ぎず、本開示の範囲を制限するものではない。例えば、異なる国の法令要求に基づいて異なるデータ主権保護ルールを設定することができる。なお、コンピュータネットワークの層の定義に依存して、上記層に近い又は類似した層でネットワークトラフィックを分析し制限することができる。

【0222】

なお、上記の記述において、セキュリティサンドボックスサブシステム１０９０は、ターゲットアプリ１０８０におけるネットワークトラフィックを直接分析し、制限することができる。言い換えれば、セキュリティサンドボックスサブシステム１０９０によって制限されていないネットワークトラフィックのみは、伝送を継続することができる。代替的に又は追加的に、セキュリティサンドボックスサブシステム１０９０は、ネットワークトラフィックを直接制限せず、分析レポートのみを提供してもよい。このような場合に、ネットワーク要求を正常に伝送すると同時にセキュリティサンドボックスサブシステム１０９０にネットワーク要求のコピーを送信することができる。セキュリティサンドボックスサブシステム１０９０は、ネットワーク要求のコピーを分析し、分析レポートを提供することができる。

【0223】

いくつかの実現では、複数のデータ主権国家の場合、それぞれ各データ主権国家に対して処理するように、それに応じて複数のセキュリティサンドボックスサブシステム１０９０を設定してもよい。例えば、アプリにおけるユーザデータのネットワーク伝送が対応する国のデータ主権保護ルールに適合するように、ターゲットユーザが位置する地域に対する決定に基づいて、対応するセキュリティサンドボックスサブシステムを起動してネットワークトラフィックを分析し制限してもよい。

【0224】

（推薦管理サブシステム）
上記で検討されたように、ターゲットアプリは、例えば推薦メカニズムによってユーザに様々なコンテンツの推薦、例えば、マルチメディアコンテンツ推薦、ユーザ推薦、商品推薦などを提供することができる。このようなアプリでは、推薦ポリシーの公平性は、すでに多くの地域管理の重点となっている。例えば、いくつかのアプリは、推薦メカニズムによってユーザの習慣に関係のない特定のコンテンツに注目するようにユーザを誘導する可能性があり、このような推薦メカニズムは、不正となるおそれがある。

【0225】

一方では、一般的な推薦アルゴリズムは、往々して機械学習モデルに依存して実施され、例えばセキュリティコンピューティングサブシステム１０６０によって実行されるコードレベル承認は、推薦アルゴリズムの公平性を効果的に検出することができない可能性がある。他方では、推薦モデルの訓練と更新は、往々して実際のユーザデータと密接に関連しており、データコンプライアンスのリスクにつながる可能性があるため、人々は、検査中にユーザのプライバシーデータが暴露されることも期待しない。

【0226】

本開示の実施例は、推薦ポリシーを管理する方案をさらに提案した。図５は、推薦ポリシーを管理するプロセス５００のフローチャートを示した。このプロセス５００は、例えば推薦管理サブシステム１０５０によって実行されてもよい。

【0227】

図５に示すように、ボックス５０２において、推薦管理サブシステム１０５０は、ターゲットアプリにおける一組のオブジェクトに関連する一組のオブジェクト特徴を取得し、ここで、一組のオブジェクト特徴は、一組のオブジェクトの属性に基づいて変換して得られたものであり、一組のオブジェクト特徴は、一組のオブジェクトの属性を直接表現しない。

【0228】

いくつかの実施例では、推薦管理サブシステム１０５０は、ターゲットアプリによって提供されるアプリケーションプログラミングインターフェースＡＰＩを経由してこの組のオブジェクト特徴を取得してもよい。いくつかの実施例では、推薦管理サブシステム１０５０は、例えば専用ＡＰＩを経由してターゲットアプリプラットフォーム１０３０からターゲットアプリ１０８０における一組のオブジェクトに関連する一組のオブジェクト特徴を取得してもよい。

【0229】

いくつかの実施例では、この組のオブジェクト特徴は、例えば特徴抽出モデルがこの組のオブジェクトの属性に基づいて変換して得られたものであってもよい。このような方式に基づいて、推薦ポリシーの管理側又は他のサード・パーティがオブジェクト特徴に基づいてオブジェクトの元の属性情報を決定できないようにしてもよい。それによって、ターゲットアプリにおけるデータの安全性を保証することができる。

【0230】

ボックス５０４において、推薦管理サブシステム１０５０は、一組のオブジェクト特徴から第一オブジェクト特徴と第二オブジェクト特徴とを決定し、ここで、第一オブジェクト特徴と第二オブジェクト特徴との間の第一差異は、第一閾値よりも小さい。

【0231】

いくつかの実施例では、この組のオブジェクト特徴は、例えば複数のベクトルとして表されてもよい。さらに、推薦管理サブシステム１０５０は、例えばベクトルの間の差異に基づいて、この組のオブジェクト特徴から差異が第一閾値よりも小さい少なくとも１対のオブジェクト特徴を選択してもよい。

【0232】

ボックス５０６において、推薦管理サブシステム１０５０は、ターゲットアプリにおける推薦ポリシーに基づいて、第一オブジェクト特徴に対応する第一推薦結果と第二オブジェクト特徴に対応する第二推薦結果とを決定する。

【0233】

いくつかの実施例では、推薦管理サブシステム１０５０は、第一オブジェクト特徴を推薦ポリシーに関連する推薦モデルに提供して、第一推薦結果を決定し、第二オブジェクト特徴を推薦モデルに提供して、第二推薦結果を決定してもよい。

【0234】

いくつかの実施例では、推薦ポリシーの安全性を保証するために、推薦管理サブシステム１０５０は、定第一推薦結果と第二推薦結果とを決定するために、ターゲットアプリによって提供されるＡＰＩを経由して、選択して得られた第一オブジェクト特徴と第二オブジェクト特徴とをリモートで運行する推薦モデルに送信してもよい。例示的に、この推薦モデルは、例えばターゲットアプリのメンテナンス側によって運行されてもよい。

【0235】

いくつかの実施例では、第一推薦結果と第二推薦結果とを生成するプロセスは、ターゲットアプリに実際にデプロイされた推薦モデルに影響を与えない。

【0236】

いくつかの実施例では、第一推薦結果と第二推薦結果とは、推薦モデルによって出力されるベクトルで表されてもよい。それによって、推薦管理サブシステム１０５０は、第一推薦結果と第二推薦結果との語義を直接解読することができず、それによってターゲットアプリ内のデータの安全性をさらに向上させた。

【0237】

ボックス５０８において、推薦管理サブシステム１０５０は、第一推薦結果と第二推薦結果とに基づいて、推薦ポリシーを評価する。

【0238】

いくつかの実施例では、推薦管理サブシステム１０５０は、第一推薦結果と第二推薦結果との間の第二差異を決定し、第二差異と第二閾値との間の比較に基づいて、推薦ポリシーの公平性を決定してもよい。

【0239】

具体的には、合理的な推薦ポリシーにとって、二つの類似したオブジェクトに対して、その推薦結果は、類似すべきである。そのため、推薦管理サブシステム１０５０は、第二差異が第二閾値を超えたと決定した場合、推薦ポリシーが比較的悪い公平性を有すると決定してもよい。

【0240】

又は、推薦管理サブシステム１０５０は、例えば第二差異が第二閾値を超えたオブジェクト特徴ペアの割合に基づいて、推薦ポリシーの公平性を決定してもよい。例えば、推薦管理サブシステム１０５０は、例えば複数組のオブジェクト特徴ペアをランダムにサンプリングしてもよく、そのうち、第二差異が第二閾値を超えたオブジェクト特徴ペアの割合が閾値割合を超えた場合、推薦ポリシーが比較的悪い公平性を有すると決定してもよい。

【0241】

いくつかの実施例では、推薦管理サブシステム１０５０は、推薦モデルに入力されるためのオブジェクト特徴と履歴推薦結果との間の関連性に基づいて、推薦ポリシーの公平性を決定してもよい。具体的には、推薦管理サブシステム１０５０は、ターゲットアプリから第三オブジェクト特徴と第三オブジェクト特徴に対する履歴推薦結果とを取得してもよい。さらに、推薦管理サブシステム１０５０は、第三オブジェクト特徴と履歴推薦結果との間の関連性に基づいて、推薦ポリシーの公平性を決定する。例えば、推薦管理サブシステム１０５０は、オブジェクト特徴と履歴推薦結果の種別情報とがマッチングするかどうかの決定に基づいてもよい。

【0242】

いくつかの実施例では、推薦管理サブシステム１０５０は、第三オブジェクト特徴と履歴推薦結果とに対応するベクトル表現を決定し、二つのベクトル表現の間の差異に基づいて第三オブジェクト特徴と履歴推薦結果との間の関連性を決定してもよい。例えば、一つのオブジェクトとその履歴推薦結果とのベクトル差異が閾値よりも大きい場合、推薦管理サブシステム１０５０は、推薦ポリシーが比較的悪い公平性を有すると決定してもよい。

【0243】

いくつかの実施例では、上記に言及されたように、セキュリティコンピューティングサブシステム１０６０によって、例えば推薦ポリシーに関連するソースコードを検査してもよい。具体的には、セキュリティコンピューティングサブシステム１０６０は、例えば推薦ポリシーに対応するソースコードを取得し、ソースコード又はソースコードに対応する中間コードに基づいて推薦ポリシーを評価してもよい。

【0244】

いくつかの実施例では、推薦ポリシーは、例えばターゲットアプリ１０８０におけるユーザに少なくとも一つのマルチメディアコンテンツを推薦するために用いられてもよい。マルチメディアコンテンツの例は、例えば画像、ビデオ、音楽又はその組み合わせなどを含んでもよい。

【0245】

（例示的装置と機器）
本開示の実施例は、上記方法又はプロセスを実現するための該当する装置をさらに提供する。図６は、本開示のいくつかの実施例によるクライアントアプリのネットワークトラフィックを管理する装置６００の概略構造ブロック図を示した。

【0246】

図６に示すように、装置６００は、ターゲットユーザに対する決定に基づいて、ターゲットユーザのユーザデータのクライアントアプリからサーバへのネットワーク伝送を検出するように構成される検出ユニット６１０と、ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、ネットワーク伝送の異なる層でネットワークトラフィックを分析するように構成される分析ユニット６２０と、ネットワークトラフィックがターゲットユーザに対応するデータ交換制約を満たすことを指示するとの分析に基づいて、ネットワークトラフィックをデータ交換制約によって限定されるサーバに送信するように構成される送信ユニット６３０とを含む。

【0247】

図７は、本開示の内容の実施例を実施するために用いられ得る例示的機器７００の概略ブロック図を示した。例えば、本開示の実施例によるシステム１００及び／又はシステム４００は、機器７００によって実施されてもよい。図に示すように、機器７００は、中央処理ユニット（ＣＰＵ）７０１を含み、それは、リードオンリーメモリ（ＲＯＭ）７０２に記憶されているコンピュータプログラム命令又は記憶ユニット７０８からランダムアクセスメモリ（ＲＡＭ）７０３にロードされたコンピュータプログラム命令に基づいて、様々な適切な動作と処理を実行することができる。ＲＡＭ ７０３には、機器７００の操作に必要な様々なプログラムとデータが記憶されてもよい。ＣＰＵ ７０１、ＲＯＭ ７０２及びＲＡＭ ７０３は、バス７０４を介して互いに繋がる。入力／出力（Ｉ／Ｏ）インターフェース７０５もバス７０４に接続される。

【0248】

機器７００における複数の部材は、Ｉ／Ｏインターフェース７０５に接続され、入力ユニット７０６（例えばキーボード、マウスなど）と、出力ユニット７０７（例えば様々なタイプのディスプレイ、スピーカなど）と、記憶ユニット７０８（例えば磁気ディスク、光ディスクなど）と、通信ユニット７０９（例えばネットワークカード、モデム、無線通信送受信機など）とを含む。通信ユニット７０９は、機器７００が、例えばインターネットのコンピュータネットワーク及び／又は様々な電信ネットワークを介して他の機器と情報／データを交換することを許容する。

【0249】

上述した各プロセスと処理、例えばプロセス５００は、処理ユニット７０１によって実行されてもよい。例えば、いくつかの実施例では、プロセス５００は、コンピュータソフトウェアプログラムとして実現されてもよく、それは、機械可読媒体、例えば記憶ユニット７０８に有形的に含まれる。いくつかの実施例では、コンピュータプログラムの一部又はすべては、ＲＯＭ ７０２及び／又は通信ユニット７０９を経由して機器７００にロード及び／又はインストールされてもよい。コンピュータプログラムがＲＡＭ ７０３にロードされ、ＣＰＵ ７０１によって実行されると、上述したプロセス５００の一つ又は複数の動作を実行してもよい。

【0250】

本開示は、方法、装置、システム及び／又はコンピュータプログラム製品であってもよい。コンピュータプログラム製品は、コンピュータ可読記憶媒体を含んでもよく、その上には、本開示の各態様を実行するためのコンピュータ可読プログラム命令が記憶されている。

【0251】

コンピュータ可読記憶媒体は、命令実行機器によって使用される命令を保持し記憶できる有形機器であってもよい。コンピュータ可読記憶媒体は、例えば電気記憶機器、磁気記憶機器、光学記憶機器、電磁記憶機器、半導体記憶機器又は上記の任意の適切な組み合わせであってもよいが、それらに限らない。コンピュータ可読記憶媒体のより具体的な例（非網羅的リスト）は、携帯型コンピュータディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭ又はフラッシュメモリ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、携帯型コンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリスティック、フロッピーティック、機械符号化機器、例えばその上に命令が記憶されているパンチカード又はスロット内突起構造、及び上記の任意の適切な組み合わせを含む。ここで使用されるコンピュータ可読記憶媒体は、瞬時信号自体、例えば電波又は他の自由に伝播する電磁波、導波路又は他の伝送媒体を介して伝播する電磁波（例えば、光ファイバケーブルを介した光パルス）、又は電線を介して伝送される電気信号として解釈されない。

【0252】

ここで記述されたコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体から各コンピューティング／プロセッシングデバイスにダウンロードされ、又はネットワーク、例えばインターネット、ローカルエリアネットワーク、ワイドエリアネットワーク及び／又は無線ネットワークを介して外部コンピュータ又は外部記憶機器にダウンロードされてもよい。ネットワークは、銅伝送ケーブル、光ファイバ伝送、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ及び／又はエッジサーバを含んでもよい。各コンピューティング／プロセッシングデバイスにおけるネットワークアダプタカード又はネットワークインターフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、このコンピュータ可読プログラム命令を転送して、各コンピューティング／プロセッシングデバイスにおけるコンピュータ可読記憶媒体に記憶される。

【0253】

本開示の操作を実行するためのコンピュータプログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械関連命令、マイクロコード、ファームウェア命令、状態設定データ、又は一つ又は複数のプログラミング語言の任意の組み合わせで作成されたソースコード又はターゲットコードであってもよく、前記プログラミング語言は、オブジェクト指向のプログラミング語言－例えばＳｍａｌｌｔａｌｋ、Ｃ＋＋など、及び従来の手続き型プログラミング語言－例えば「Ｃ」語言又は類似するプログラミング語言を含む。コンピュータ可読プログラム命令は、ユーザコンピュータ上で完全に実行され、部分的にユーザコンピュータ上で実行され、一つの独立したソフトウェアパッケージとして実行され、部分的にユーザコンピュータ上で、部分的にリモートコンピュータ上で実行され、又はリモートコンピュータ又はサーバ上で完全に実行されてもよい。リモートコンピュータに関する場合、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）又はワイドエリアネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザコンピュータに接続されてもよく、又は、外部コンピュータに接続されてもよい（例えばインターネットサービスプロバイダを利用してインターネットを介して接続される）。いくつかの実施例では、コンピュータ可読プログラム命令の状態情報を利用して電子回路、例えばプログラマブルロジック回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又はプログラマブルロジックアレイ（ＰＬＡ）を個性化的にカスタマイズし、この電子回路は、コンピュータ可読プログラム命令を実行することができ、それによって本開示の各態様を実現する。

【0254】

ここで本開示の実施例による方法、装置（システム）とコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して本開示の各態様を記述した。理解すべきこととして、フローチャート及び／又はブロック図の各ブロック及びフローチャート及び／又はブロック図における各ブロックの組み合わせは、いずれもコンピュータ可読プログラム命令によって実現されてもよい。

【0255】

これらのコンピュータ可読プログラム命令は、汎用コンピュータ、専用コンピュータ又は他のプログラマブルデータ処理装置の処理ユニットに提供されてもよく、それによってマシンを生産して、これらの命令がコンピュータ又は他のプログラマブルデータ処理装置の処理ユニットによって実行されると、フローチャート及び／又はブロック図のその一つ又は複数のブロックに規定された機能／動作を実現させる装置が発生するようにする。これらのコンピュータ可読プログラム命令をコンピュータ可読記憶媒体に記憶してもよく、これらの命令によってコンピュータ、プログラマブルデータ処理装置及び／又は他の機器は、特定の方式で作動し、それによって、命令が記憶されたコンピュータ可読媒体は、フローチャート及び／又はブロック図のその一又は複数のブロックに規定された機能／動作の各態様を実現させる命令を含む一つの製造品を含む。

【0256】

コンピュータ、他のプログラマブルデータ処理装置又は他の機器上で一連の操作ステップを実行して、コンピュータによって実現されるプロセスが発生し、それによってコンピュータ、他のプログラマブルデータ処理装置、又は他の機器上で実行される命令がフローチャート及び／又はブロック図のその一又は複数のブロックに規定された機能／動作を実現させるように、コンピュータ可読プログラム命令をコンピュータ、他のプログラマブルデータ処理装置、又は他の機器にロードしてもよい。

【0257】

図面におけるフローチャートとブロック図は、本開示の複数の実施例によるシステム、方法とコンピュータプログラム製品の実現可能な系統アーキテクチャ、機能と操作を表示した。この点では、フローチャート又はブロック図における各ブロックは、一つのモジュール、プログラムセグメント又は命令の一部を代表してもよく、前記モジュール、プログラムセグメント又は命令の一部は、規定されるロジック機能を実現させるための一つ又は複数の実行可能命令を含む。置き換えとしてのいくつかの実現では、ブロックに付された機能は、図面に付されたものと異なる順序で発生してもよい。例えば、二つの連続したブロックは、実際に基本的に並列に実行されてもよく、関わる機能に応じて、逆の順序で実行されてもよいことがある。また注意すべきこととして、ブロック図及び／又はフローチャートにおける各ブロック、及びブロック図及び／又はフローチャートにおけるブロックの組み合わせは、規定された機能又は動作を実行する、ハードウェアに基づく専用のシステムによって実現されてもよく、又は専用ハードウェアとコンピュータ命令との組み合わせによって実現されてもよい。

【0258】

以上、本開示の各実施の形態を記述したが、上記の説明は、例示的なものであり、網羅的なものではなく、且つ開示された各実施の形態に限らない。説明された各実施の形態の範囲と精神から逸脱することなく、当業者にとって多くの修正と変更は、いずれも自明である。本明細書で使用される用語の選択は、各実施の形態の原理、実際の応用又は市場における技術の改良を最もよく解釈し、又は他の当業者が本明細書で開示された各実施の形態を理解できるようにすることを目指す。

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図3D】

【図3E】

【図3F】

【図3G】

【図3H】

【図3I】

【図3J】

【図3K】

【図3L】

【図3M】

【図4A】

【図4B】

【図4C】

【図4D】

【図4E】

【図5】

【図6】

【図7】

【手続補正書】

【提出日】2024-04-26

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

クライアントアプリのネットワークトラフィックを管理する方法であって、
ターゲットユーザに対する決定に基づいて、前記ターゲットユーザのユーザデータの前記クライアントアプリからサーバへのネットワーク伝送を検出することと、
前記ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析することと、
前記ネットワークトラフィックが前記ターゲットユーザに対応するデータ交換制約を満たすことを指示するとの前記分析に基づいて、前記ネットワークトラフィックを前記データ交換制約によって限定されるサーバに送信することと、を含む、
方法。

【請求項2】

ターゲットユーザに対する決定は、
前記ターゲットユーザのユーザ情報と、
前記ターゲットユーザに対応する機器情報と、の少なくとも一つに基づく、
請求項１に記載の方法。

【請求項3】

前記ユーザ情報は、ユーザのアカウント情報、個人情報、及び／又は登録情報を含み、
前記機器情報は、ユーザ身分識別モジュールＳＩＭ情報、ＩＰアドレス、ネットワークサービスプロバイダ情報、機器のシステム設定情報、及び／又はアプリ設定情報を含む、
請求項２に記載の方法。

【請求項4】

前記ターゲットユーザのユーザ情報又は対応する機器情報に基づいて、前記ターゲットユーザに対応するデータ交換制約を決定することをさらに含む、請求項２に記載の方法。

【請求項5】

前記ネットワークトラフィックのタイプは、
ネイティブアプリに関連するネイティブタイプのネットワークトラフィックと、
アプリに内蔵されたブラウザに関連するウェブページビュータイプのネットワークトラフィックと、
サード・パーティソフトウェア開発キットＳＤＫに関連するサード・パーティＳＤＫタイプのネットワークトラフィックと、の少なくとも一つを含む、
請求項１に記載の方法。

【請求項6】

前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析することは、
前記ネットワークトラフィックのタイプがネイティブタイプであるネットワークトラフィックに基づいて、ネットワーク層で前記ネットワークトラフィックを分析することを含む、
請求項１に記載の方法。

【請求項7】

前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析することは、
前記ネットワークトラフィックのタイプがウェブページビュータイプであるネットワークトラフィックに基づいて、前記ウェブページビュータイプのネットワークトラフィックを前記クライアントアプリのネットワークインターフェースに遷移して前記クライアントアプリのネイティブネットワークモジュールによって管理されるようにすることと、
ネットワーク層で遷移されたネットワークトラフィックを分析することと、を含む、
請求項１に記載の方法。

【請求項8】

前記ウェブページビュータイプのネットワークトラフィックをモバイル端アプリのネットワークインターフェースに遷移することは、
ＪａｖａＳｃｒｉｐｔのフックメカニズムを利用して前記ウェブページビュータイプのネットワークトラフィックを遷移することを含む、
請求項７に記載の方法。

【請求項9】

前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析することは、
前記ネットワークトラフィックのタイプがサード・パーティＳＤＫタイプであるネットワークトラフィックに基づいて、アプリケーションプログラミングインターフェースＡＰＩ層で前記ネットワークトラフィックを分析することを含む、
請求項１に記載の方法。

【請求項10】

ＡＰＩ層で前記ネットワークトラフィックを分析することは、
サード・パーティＳＤＫのＡＰＩに前記データ交換制約に基づく判断ロジックを追加することによってラップＡＰＩを決定することと、
前記ラップＡＰＩを呼び出して前記判断ロジックを利用して前記ネットワークトラフィックを分析することと、を含む、
請求項９に記載の方法。

【請求項11】

クライアントアプリのネットワークトラフィックを管理するための装置であって、
ターゲットユーザに対する決定に基づいて、前記ターゲットユーザのユーザデータの前記クライアントアプリからサーバへのネットワーク伝送の検出を起動するように構成される起動モジュールと、
前記起動モジュールによるアクティブ化に応答し、前記ネットワーク伝送に対応するネットワークトラフィックのタイプに基づいて、前記ネットワーク伝送の異なる層で前記ネットワークトラフィックを分析し、そして、前記ネットワークトラフィックが前記ターゲットユーザに対応するデータ交換制約を満たすことを指示するとの前記分析に基づいて、前記ネットワークトラフィックを前記データ交換制約によって限定されるサーバに送信するように構成される管理モジュールと、を含む、
装置。

【請求項12】

ターゲットユーザに対する決定は、
前記ターゲットユーザのユーザ情報と、
前記ターゲットユーザに対応する機器情報と、の少なくとも一つに基づく、
請求項１１に記載の装置。

【請求項13】

前記ユーザ情報は、ユーザのアカウント情報、個人情報、及び／又は登録情報を含み、
前記機器情報は、ユーザ身分識別モジュールＳＩＭ情報、ＩＰアドレス、ネットワークサービスプロバイダ情報、機器のシステム設定情報、及び／又はアプリ設定情報を含む、
請求項１２に記載の装置。

【請求項14】

前記ターゲットユーザのユーザ情報又は対応する機器情報に基づいて、前記ターゲットユーザに対応するデータ交換制約を決定するように構成される制約決定モジュールをさらに含む、請求項１２又は１３に記載の装置。

【請求項15】

前記ネットワークトラフィックのタイプは、
ネイティブアプリに関連するネイティブタイプのネットワークトラフィックと、
アプリに内蔵されたブラウザに関連するウェブページビュータイプのネットワークトラフィックと、
サード・パーティソフトウェア開発キットＳＤＫに関連するサード・パーティＳＤＫタイプのネットワークトラフィックと、の少なくとも一つを含む、
請求項１１に記載の装置。

【請求項16】

前記管理モジュールは、
前記ネットワークトラフィックのタイプがネイティブタイプであるネットワークトラフィックに基づいて、ネットワーク層で前記ネットワークトラフィックを分析するように構成される第一管理モジュールを含む、
請求項１１に記載の装置。

【請求項17】

前記管理モジュールは、
前記ネットワークトラフィックのタイプがウェブページビュータイプであるネットワークトラフィックに基づいて、前記ウェブページビュータイプのネットワークトラフィックを前記クライアントアプリのネットワークインターフェースに遷移して前記クライアントアプリのネイティブネットワークモジュールによって管理されるようにし、
ネットワーク層で遷移されたネットワークトラフィックを分析するように構成される、
第二管理モジュールを含む、
請求項１１に記載の装置。

【請求項18】

前記ウェブページビュータイプのネットワークトラフィックをモバイル端アプリのネットワークインターフェースに遷移することは、
ＪａｖａＳｃｒｉｐｔのフックメカニズムを利用して前記ウェブページビュータイプのネットワークトラフィックを遷移することを含む、
請求項１７に記載の装置。

【請求項19】

前記管理モジュールは、
前記ネットワークトラフィックのタイプがサード・パーティＳＤＫタイプであるネットワークトラフィックに基づいて、アプリケーションプログラミングインターフェースＡＰＩ層で前記ネットワークトラフィックを分析するように構成される第三管理モジュールを含む、
請求項１１に記載の装置。

【請求項20】

ＡＰＩ層で前記ネットワークトラフィックを分析することは、
サード・パーティＳＤＫのＡＰＩに前記データ交換制約に基づく判断ロジックを追加することによってラップＡＰＩを決定することと、
前記ラップＡＰＩを呼び出して前記判断ロジックを利用して前記ネットワークトラフィックを分析することと、を含む、
請求項１９に記載の装置。

【請求項21】

前記起動モジュールにサンプリング信号を送信して前記起動モジュールをトリガーするように構成されるサンプリングモジュールをさらに含み、前記サンプリング信号は、前記ネットワークトラフィックをサンプリングするサンプリングレートを指示する、請求項１１に記載の装置。

【請求項22】

メモリとプロセッサとを含む電子機器であって、
前記メモリは、一つ又は複数のコンピュータ命令を記憶するために用いられ、前記一つ又は複数のコンピュータ命令は、前記プロセッサによって実行されて請求項１から１０のいずれか１項に記載の方法を実現させる、
電子機器。

【請求項23】

一つ又は複数のコンピュータ命令が記憶されているコンピュータ可読記憶媒体であって、前記一つ又は複数のコンピュータ命令は、プロセッサによって実行されて請求項１から１０のいずれか１項に記載の方法を実現させる、コンピュータ可読記憶媒体。

【請求項24】

プロセッサによって実行されて請求項１から１０のいずれか１項に記載の方法を実現させる、一つ又は複数のコンピュータ命令を含む、プログラム。

【国際調査報告】