Method, system, device and apparatus for data exchange

Abstract

According to embodiments of the present disclosure, a method, system, apparatus, electronic device, storage medium, and program product for data exchange are provided. The method described herein includes: obtaining raw data to be exchanged between a first platform and a second platform by a target application; processing the raw data based on its type to obtain uniformly formatted data corresponding to the type; and determining, from the uniformly formatted data, whether data exchange constraints are satisfied. Based on this approach, embodiments of the present disclosure can simplify and facilitate the determination of data exchange constraints, accelerating the data exchange process.

Description

Technical Field

[0001] Implementations of the present disclosure relate to the field of computers, and more particularly, to methods, systems, devices, equipment, computer storage media, and computer program products for data exchange. Background Art

[0002] With the development of internet technology, a wide variety of internet applications have become an integral part of people's lives. These applications generate massive amounts of data daily, raising various data security issues, such as data sovereignty protection. For example, some countries may prohibit certain types of user data from being sent to overseas servers.

[0003] This challenge is even more pronounced for global applications. These applications may rely on the same technical architecture to serve users in multiple regions. However, these regions may have completely different data security constraints, such as specific data sovereignty requirements, further increasing the difficulty of data security protection. Summary of the Invention

[0004] In a first aspect of the present disclosure, a data exchange method is provided. The method includes: obtaining raw data to be exchanged between a first platform and a second platform by a target application; processing the raw data based on a type of the raw data to obtain unified formatted data corresponding to the type; and determining satisfaction of a data exchange constraint from the unified formatted data.

[0005] In a second aspect of the present disclosure, a data exchange system is provided. The data exchange system includes: a first data center configured to obtain raw data to be exchanged between a first platform and a second platform by a target application, and to process the raw data based on a type of the raw data to obtain unified formatted data corresponding to the type; and a second data center configured to obtain the unified formatted data from the first data center and determine satisfaction of data exchange constraints based on the unified formatted data.

[0006] In a third aspect of the present disclosure, a device for data exchange is provided. The device includes: an acquisition module configured to acquire raw data to be exchanged between a first platform and a second platform by a target application; a preprocessing module configured to process the raw data based on its type to obtain unified formatted data corresponding to the type; and a constraint satisfaction determination module configured to determine whether data exchange constraints are satisfied from the unified formatted data.

[0007] In a fourth aspect of the present disclosure, an electronic device is provided, comprising: a memory and a processor, wherein the memory is configured to store one or more computer instructions, and wherein the one or more computer instructions are executed by the processor to implement the method according to the first aspect of the present disclosure.

[0008] In a fifth aspect of the present disclosure, a computer-readable storage medium is provided, on which one or more computer instructions are stored, wherein the one or more computer instructions are executed by a processor to implement the method according to the first aspect of the present disclosure.

[0009] In a sixth aspect of the present disclosure, a computer program product is provided, comprising one or more computer instructions, wherein the one or more computer instructions are executed by a processor to implement the method according to the first aspect of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, wherein:

[0011] Figure 1 A schematic block diagram of a data security protection system according to an embodiment of the present disclosure is shown;

[0012] Figure 2 A schematic block diagram of a computing security subsystem according to some embodiments of the present disclosure is shown;

[0013] Figure 3A shows an example deployment environment in which a data exchange subsystem is deployed according to some embodiments of the present disclosure;

[0014] Figure 3B The implementation of DES in an internal data center (IDC) of a TTP party and an offshore internal data center (RoW IDC) where a non-TTP is located according to some embodiments of the present disclosure is shown;

[0015] Figure 3C A block diagram illustrating an example architecture of a DE according to some embodiments of the present disclosure;

[0016] Figure 3D A flow chart showing a data exchange process according to some embodiments of the present disclosure is shown;

[0017] Figure 3E A flowchart illustrating example data flows for various types of data processing implemented at a DES according to some embodiments of the present disclosure;

[0018] Figure 3F A schematic block diagram illustrating a data exchange architecture involving an MQ channel according to some embodiments of the present disclosure is shown;

[0019] Figure 3G A schematic block diagram of a data exchange architecture involving an HDFS channel according to some embodiments of the present disclosure is shown;

[0020] Figure 3H A schematic diagram illustrating a target object storage (TOS) channel for replicating data from a TTP IDC to an overseas IDC according to some embodiments of the present disclosure is shown;

[0021] Figure 3I A schematic diagram illustrating a TOS channel for copying data from an overseas IDC to a TTP IDC according to some embodiments of the present disclosure is shown;

[0022] Figure 3J shows a message sequence chart in a TOS channel according to some embodiments of the present disclosure;

[0023] Figure 3K A schematic block diagram illustrating a data exchange architecture involving a service call channel according to some embodiments of the present disclosure is shown;

[0024] Figure 3L An example of data exchange from a non-TTP to a TTP in a service call channel according to some embodiments of the present disclosure is shown;

[0025] Figure 3M An example of data exchange from a TTP to a non-TTP in a service call channel according to some embodiments of the present disclosure is shown;

[0026] Figure 4A A flowchart illustrating a method for managing network traffic of a mobile application according to some embodiments of the present disclosure is shown;

[0027] Figure 4B A schematic diagram illustrating a process of analyzing and limiting native network traffic according to some embodiments of the present disclosure is shown;

[0028] Figure 4C A schematic diagram illustrating a process of analyzing and limiting network traffic of a web page view type according to some embodiments of the present disclosure is shown;

[0029] Figure 4D A schematic diagram illustrating a process of analyzing and limiting network traffic of a third-party SDK type according to some embodiments of the present disclosure is shown;

[0030] Figure 4E A module diagram of a security sandbox system according to some embodiments of the present disclosure is shown;

[0031] Figure 5 A flowchart illustrating an example process for managing a recommendation strategy according to some embodiments of the present disclosure;

[0032] Figure 6 An example block diagram illustrating an apparatus for data exchange according to some embodiments of the present disclosure; and

[0033] Figure 7 A block diagram is shown of an example device that may be used to implement embodiments of the present disclosure. DETAILED DESCRIPTION

[0034] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0035] In the description of the embodiments of the present disclosure, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to." The term "based on" should be understood as "based at least in part on." The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment." The terms "first," "second," etc. may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0036] The basic principles and several example implementations of the present disclosure are explained below with reference to the accompanying drawings.

[0037] Overall architecture of the data security protection system

[0038] According to an embodiment of the present disclosure, a data security protection system is provided. Figure 1 FIG. 1 shows a schematic block diagram of a data security protection system 1000 according to an embodiment of the present disclosure. Figure 1 As shown, the data security protection system 1000 includes multiple subsystems for protecting the security of relevant data generated by users when using the target application from different dimensions.

[0039] Generally speaking, to support the operation of the target application, on the one hand, the user needs to be able to run the target application 1080 through, for example, an appropriate electronic device. On the other hand, it is also necessary to deploy the target application platform 1030 in an appropriate computing environment (e.g., a cloud computing environment) to, for example, run various types of services for supporting the normal operation of the target application 1080.

[0040] In some embodiments, the data security protection system 1000 can first ensure the security of the data generated by the target application 1090 during operation from the perspective of the security of the running code. Figure 1 As shown, the data security protection system 1000 may include a secure computing subsystem 1060 , which may be used to ensure the security of the code corresponding to the target application 1080 , and to ensure the security of the code corresponding to the target application platform 1030 .

[0041] The service execution file compiled by the computing subsystem 1060 can be deployed to the target application platform 1030, and the installation file (e.g., apk file) of the target application compiled by the computing subsystem 1060 can be published to the application store 1120. The specific implementation of the secure computing subsystem 1060 will be described below in conjunction with Figure 2 Discuss in detail.

[0042] In some embodiments, as Figure 1 As shown, secure computing subsystem 1060 may be based on cloud infrastructure 1070. In some embodiments, cloud infrastructure 1070 may be provided by, for example, a trusted partner. In this disclosure, a "trusted partner" may also be referred to as a Trusted Technology Partner (TTP), which may include, for example, any individual, enterprise, or organization that is technically trusted within a specific region (e.g., a specific country or jurisdiction).

[0043] In some embodiments, as Figure 1 As shown, the data security protection system 1000 may include a trusted security environment 1010 provided by the TTP. Unlike traditional application platform deployment, the target application platform 1030 may be deployed in the trusted security environment 1010 to improve the security of the data generated by the target application platform 1030, as well as the transparency and trustworthiness of its operating mechanism.

[0044] In some embodiments, the target application 1080 can provide content recommendation services to users through recommendation algorithms. Such content recommendations may include, but are not limited to, multimedia content recommendations, user recommendations, product recommendations, and so on. Given that more and more recommendation systems are leveraging machine learning to implement recommendation functions, it may be difficult to ensure fairness by managing recommendation mechanisms solely at the code level.

[0045] like Figure 1 As shown, the data security protection system 1000 may further include a recommendation management subsystem 1050, which can, for example, test the recommendation algorithm running on the target application platform 1030 to ensure the fairness of the recommendation mechanism in the target application 1080. The specific implementation of the recommendation management subsystem 1050 will be described in detail below.

[0046] In some embodiments, considering that the target application platform 1030 is running services to support the normal operation of the target application 1080, the target application platform 1030 may need to interact with applications or data centers (also called offshore applications or offshore data centers) outside the target area (e.g., a specific country or jurisdiction) in which it is currently deployed.

[0047] Typically, the target region will restrict the communication of data generated within the region with external parties through laws or regulations. Certain types of data generated within the target region may be prohibited from being transmitted overseas. To ensure compliance with the target application platform 1030's communications with external parties, the data security protection subsystem may include a data exchange subsystem 1040. Similarly, the data exchange subsystem 1040 can be deployed in the trusted security environment 1010 to ensure transparency and trustworthiness of its operations.

[0048] In some embodiments, as Figure 1 As shown, the data exchange subsystem 1040 may include multiple data channels for different types of data transmission. For example, multimedia data generated in the target application platform 1030 may be communicated with an overseas application 1140 and / or an overseas data center 1150 via corresponding data channels in the data exchange subsystem 1040 and via a content distribution network 1130 provided by a third party.

[0049] As another example, for some specific internal data generated in the target application platform 1030, it can communicate with the overseas data center 1150 and the overseas development department 1160 through corresponding data channels and, for example, through direct optical cables. The specific implementation of the data exchange subsystem 1040 will be described below in conjunction with Figures 3A to 3M Detailed description.

[0050] Furthermore, to ensure the security of egress and ingress communications of the target application platform 1030, in some embodiments, the data security subsystem 1000 may further include an application firewall subsystem 1020. The application firewall subsystem 1020 may be deployed, for example, in the trusted security environment 1010 and may be used to monitor data communications from the target application 1080 to the target application platform 1030, data communications from the target application platform 1030 to the target application 1080, and / or data communications from the target application platform 1030 to the third-party application 110.

[0051] In this way, the data security protection platform 1000 can not only ensure the security and compliance of data communications between the target application platform 1030 and overseas through the data exchange subsystem 1040, but also ensure the security and compliance of communications between the target application platform 1030 and various domestic objects (for example, the target application 1080 or third-party applications 1110, etc.) through the application firewall subsystem 1020.

[0052] In some embodiments, for the target application 1080, in order to ensure the compliance and trustworthiness of its operation, the data security protection system 1000 may further include a security sandbox system 1090, for example, managed by a TTP, which enables different types of network communications involved in the application business logic 1100 of the target application 1080 to be protected by the security sandbox system 1090. In this way, the data security protection system 1000 can prevent the target application 1080 from initiating non-compliant data communications, for example, through backdoor programs. The detailed implementation of the security sandbox system 1090 will be discussed below in conjunction with Figures 4A to 4E Detailed description.

[0053] Therefore, based on the data security protection system 1000 disclosed in the present invention, TTP can manage and monitor various aspects such as code security and data security during the entire life cycle from the development to the operation of the target application, thereby ensuring the security of the data associated with the target application and ensuring the compliance of its operation.

[0054] Secure computing subsystem

[0055] The following will refer to Figure 2 The secure computing subsystem 1060 is described in detail. Figure 2 FIG. 1 is a schematic block diagram of a secure computing subsystem 1060 according to an embodiment of the present disclosure.

[0056] like Figure 2 As shown, the secure computing subsystem 1060 may include, for example, a secure code environment 2010 , which may be provided by, for example, a TTP. The following will describe the working process of the secure computing subsystem 1060 in conjunction with submitting new development code 2140 .

[0057] like Figure 2 As shown, when a developer has new development code 2140 that needs to be deployed, he or she can submit the development code 2140 to the secure code environment 2010 through the synchronization gateway 2150 provided by the TTP. Accordingly, the development code 2140 will be synchronized to the code library 2160 in the secure code environment 2010.

[0058] In some embodiments, when a developer needs to use new development code 2140 for compilation, the developer may send a build request to the artifact build system 2080 through the synchronization gateway 2150 , for example.

[0059] Alternatively, when the code repository 2160 receives new development code 2140 , the code repository 2160 may also automatically send a code merge event to the artifact building system 2080 to trigger the artifact building system 2080 to start the artifact (eg, executable code) building process.

[0060] When the building process is started, the code pulling module 2090 can obtain the code files used for building from the code library 2160. In some embodiments, the code files used for building can be specified by the developer, or automatically determined by the artifact building system 2080.

[0061] Furthermore, the compilation module 2100 may compile the code pulled from the code repository 2160 by the code pulling module 2090 to, for example, compile the code into an intermediate code.

[0062] In some embodiments, considering that some third-party codes are often introduced during the code compilation process, the secure computing subsystem 1060 also needs to ensure the security of the introduced third-party codes.

[0063] like Figure 2 As shown, the secure computing subsystem 1060 may include a third-party independent gateway 2030 for checking and confirming the security of the third-party library 2020 that needs to be introduced. It should be understood that such a third-party library may also be a compiled link library or the source code itself.

[0064] The third-party library 2020 that passes the security check can be added to the product library 2040. Figure 2 As shown, during the product construction process, the compilation module 2100 can also obtain other products on which the compilation of the current product depends from the product library 2040, such as products that have been compiled and generated in the past, or products generated based on the third-party library 2020, etc.

[0065] Furthermore, the compilation module 2100 may, for example, compile the code pulled from the code library 2160 and the dependent artifacts obtained from the artifact library 2040 and compile them to generate intermediate code so that the security code scanning module 2110 can perform code security detection.

[0066] It should be understood that the secure code scanning module 2110 managed by the TTP can execute any appropriate code scanning process to perform security checks. Such scanning rules are unknown to developers, thereby ensuring the security of the code used to compile the final product.

[0067] In some embodiments, the upload module 2120 may perform corresponding uploads based on the results of the security code scanning module 2110. If the security code scanning module 2110 determines that the compiled intermediate code is safe, the upload module 2120 may upload the further compiled executable file to the artifact library 2040.

[0068] Furthermore, if the security code scanning module 2110 determines that the compiled intermediate code is safe, the upload module 2120 may also upload the signature information of the executable file to the product signature management module 2060 .

[0069] On the other hand, if the security code scanning module 2110 determines that the current intermediate code has corresponding risks, the upload module 2120 can upload the relevant risks to the issue tracking system 2070 to, for example, generate a risk analysis report. Accordingly, the compiled executable file will be prohibited from being uploaded to the artifact library 2040.

[0070] In some embodiments, the development code 2140 in the code base 2160 may also be provided in a trusted environment, for example, for manual review. If it is determined that the development code 2140 has a risk, the result may also be reported to the issue tracking system 2070.

[0071] In some embodiments, if the security code scanning module 2110 determines that the current intermediate code has corresponding risks, the upload module 2120 may also notify the callback module 2130 to mark the corresponding code as risky code in the code library 2160 .

[0072] In some embodiments, the issue tracking system 2070 maintained by the TTP may send the received risk reporting information to the developer or maintainer of the development code 2140 to remind them that the current development code 2140 fails the security check and therefore cannot be deployed.

[0073] In some embodiments, if the development code 2140 passes the security check, it may be compiled into an executable file and further added to the artifact repository 2040 to be deployed, for example, via the deployment gateway 2050 .

[0074] In some embodiments, before deploying an artifact (i.e., executable file) obtained from artifact library 2040, deployment gateway 2050 may verify the validity of the artifact's signature through artifact signature management system 2060. Once the artifact's signature validity is confirmed, deployment gateway 2050 may deploy the artifact generated based on development code 2140 to the network.

[0075] In some embodiments, the product may be, for example, an application program executed on a client device. Deployment gateway 2050 may, for example, publish the generated installation file (e.g., an .apk file) to a corresponding application store for user download. Thus, embodiments of the present disclosure ensure that the installation files that users can download and install are always published by secure code environment 2010 via deployment gateway 2050.

[0076] In some embodiments, an artifact may be, for example, a service program for deployment to the target application platform 1030. Specifically, the maintainer of the target application may initiate a request to the deployment platform to deploy a specific artifact to the target application platform 1030. Accordingly, after the request is reviewed, the target application platform 1030 may obtain the specific artifact to be deployed from the artifact library 2040 and authenticate the signature of the specific artifact. After the signature of the artifact is authenticated, the artifact may be deployed to the target application platform 1030, for example, via a virtual machine or container.

[0077] Thus, based on the secure computing subsystem discussed, embodiments of the present disclosure can effectively monitor the process of converting code into an actual deployed application or service program, from code uploading, code writing, code compilation, and third-party library references. In this way, embodiments of the present disclosure can effectively avoid various security vulnerabilities or compliance risks introduced in source code.

[0078] Data exchange subsystem

[0079] The operation of applications involves data interaction between application platforms under the jurisdiction of different countries and regions. Figure 1In the example shown, it is expected that data will be exchanged between the target application platform 1030 and the target application platform where the same application is running overseas to provide global data interaction of the application. As previously mentioned, the data exchange subsystem (DES) 1040 can support the synchronization of the public data of the target application and other data that meet the rules between different platforms, and ensure the security and compliance of the exchanged data. In general, the DES 1040 is configured to detect whether the data between different platforms meets the data exchange constraints. The data exchange constraints may include constraints set to meet national or regional laws and regulations, constraints that need to be set due to other requirements of enterprise, organization and / or user protection, and so on.

[0080] For example, in countries or regions with specific data sovereignty requirements, the TTP may be required to conduct data sovereignty checks. Therefore, in many cases involving cross-platform data exchange, ensuring the security and compliance of data exchange is crucial. In particular, after establishing a TTP data center, data exchange between the outside world and the TTP data center storage will be subject to constraints, requiring data intended to interact with the TTP to undergo data sovereignty checks. In such examples, data exchange constraints can include rules related to the data sovereignty requirements of a specific country or region.

[0081] This type of interaction data can be divided into two categories: interoperability data between platforms, and operational data such as platform operations and access to platforms by operators. Interoperability data is primarily used for synchronization between the two platforms to ensure application functional integrity. This data is subject to security and compliance checks by the DES system. Examples of interoperability data include online business data and offline data. Checking operational data ensures that operators' operations on the control plane are also compliant.

[0082] Figure 3A An example deployment environment 3001 is shown in which the DES 1040 is deployed according to some embodiments of the present disclosure.

[0083] exist Figure 3A In the example, TTP 3027 refers to an environment within a specific country or region that is subject to TTP oversight and constraints. TTP 3027 may include various components used to operate, manage, and maintain the target application, such as business systems 3028, operations platforms 3029, online storage 3030, and offline storage 3031. TTP 3027 also includes an operations and maintenance platform 3032, which operations and maintenance personnel will need to access to access, manage, and maintain the target application.

[0084] Similarly, non-TTP parties 3020 refer to environments in one or more other countries or regions outside of a specific country or region, and are not subject to the data exchange constraints of the country or region in which TTP party 3027 is located. Non-TTP parties 3020 may include various components used to operate, manage, and maintain target applications, such as business systems 3020, operation platforms 3021, online storage 3022, and offline storage 3023. Non-TTP parties 3020 also include operation and maintenance platforms 3024, which operations personnel will need to access to access, manage, and maintain local applications or application platforms.

[0085] Domestic user traffic will flow through some components of TTP party 3027, and overseas user traffic will flow through some components of non-TTP party 3020. For the purposes of this document, "domestic user traffic" refers to user traffic generated on application platforms governed by a specific country or region, while "overseas user traffic" refers to user traffic generated on application platforms governed by one or more other countries or regions outside of that specific country or region.

[0086] exist Figure 3A In this environment, interoperability data includes domestic and international user traffic exchanged between TTP and non-TTP parties. This interoperability data will be subject to DES 1040 for data security and compliance checks. Furthermore, an operations gateway 3026 can be configured to perform data security and compliance checks on operational data.

[0087] As will be discussed in detail below, in DES 1040, different data channels may be set according to the type of data so that checks on the data to be exchanged are performed in the corresponding channels. Figure 3A Some channels are schematically shown, including a target object storage (TOS) channel, a message queue (MQ) channel, an offline aggregated data channel, a log (LOG) channel, a service call channel, etc.

[0088] Both parties in data exchange may have their own DES to implement data protection, for example, to protect incoming data and / or outgoing data.

[0089] Figure 3B It further illustrates the implementation of DES 1040 in the internal data center (IDC) of the TTP party and the offshore internal data center (RoW IDC) where the non-TTP is located.

[0090] exist Figure 3BIn the TTP IDC 3056, it refers to the IDC for the target application running in a specific country or region, which is subject to the data protection detection of TTP. The overseas IDC 3059 refers to the IDC for the target application running in one or more other countries or regions outside the specific country or region, which may be subject to the data protection constraints of other countries or regions.

[0091] like Figure 3B As shown, DES 1040A is implemented in TTP IDC 3056 to detect external inbound and / or internal outbound data. DES 1040B is implemented in offshore IDC 3059 to detect external inbound and / or internal outbound data. DES 1040A and DES 1040B can be considered specific deployment examples of DES 1040.

[0092] From the perspective of TTP IDC 3056, data flowing in from the outside or out of the inside may include various types of data, which will be described below with examples.

[0093] like Figure 3B As shown, for TTP IDC 3056, externally flowing data may include user requests, such as active requests initiated by users within a specific country or region through a target application 3058 running within the country. As will be described elsewhere herein, in some embodiments, user requests may also be protected by security measures such as a mobile sandbox and / or a firewall gateway 3057 within TTP IDC 3056. User requests will then be processed by the domestic application platform 3041 within TTP IDC 3056. In some examples, the domestic application platform 3041 may include various services, a vendor gateway, storage, and other components. Furthermore, if the user request is to be transmitted to a data center outside of TTP IDC 3056, the user request will be passed to DES 1040A for data protection.

[0094] In some embodiments, for TTP IDC 3056, the data flowing in from outside may also include supplier requests initiated by supplier 3055, such as requesting specific services of a domestic application platform. For example, a third-party supplier may call an application programming interface (API), such as OpenAPI, of a domestic application platform. Since it cannot be confirmed whether the third-party supplier is a domestic user, the supplier request will be sent to the supplier gateway in the domestic application platform 3041 via the third-party gateway 3040 in TTP IDC 3056 for inspection to determine whether it is a domestic user. If the supplier initiating the request is a domestic user, the supplier request can be responded to normally. If the supplier initiating the request is an overseas user, the supplier request will be transmitted through DES 1040A.

[0095] In some embodiments, for TTP IDC 3056, the externally inflowing data may also include data synchronized from overseas IDC 3059 to TTP IDC 3056. For example, if a data security audit is required for the overseas inflowing data, the overseas inflowing data also needs to be processed by DES 1040A.

[0096] In some embodiments, for TTP IDC 3056, externally flowing data may also include operation and maintenance operations performed by operation and maintenance personnel on TTP IDC 3056, such as changes to TTP IDC 3056. Such operations may include code changes, configuration changes, log maintenance, etc. Code changes may include, for example, the launch of new functions, the release of bin files, etc. Code changes may be performed by domestic operation and maintenance personnel of the international or regional application platform. Configuration changes may include enabling or disabling certain settings of the target application, configuring scheduled traffic, etc. In some cases, for application platforms operating across borders, configuration changes may be performed by overseas platform operation and maintenance personnel. Of course, this depends solely on the management requirements of different applications. Log maintenance refers to the maintenance of logs 3044 in TTP IDC 3056.

[0097] In some embodiments, domestic or overseas operation and maintenance personnel can perform operation and maintenance operations on TTPIDC 3056 under network isolation conditions to further ensure data sovereignty protection. Figure 3B As shown, domestic operations personnel initiate operations under network isolation. These operations are distributed via load balancer 3045 to code 3042, operations platform 3043, or log 3044 in TTP IDC 3056. In addition to network isolation, operations performed by overseas operations personnel undergo further security checks via operations gateway 3046 before being distributed to code 3042, operations platform 3043, or log 3044 in TTP IDC 3056.

[0098] In some embodiments, for TTP IDC 3056, data flowing internally may include third-party requests initiated from domestic application platform 3041 during the operation of the application platform to request third-party services 3054, such as third-party services on the public network. Third-party requests also require data protection by DES 1040A.

[0099] In some embodiments, for TTP IDC 3056, the data flowing out internally may also include data synchronized from TTP IDC 3056 to overseas IDC 3059. For example, during the operation of the target application, user content stored in TTP IDC 3056 may need to be synchronized to overseas IDC 3059. According to some data sovereignty protection regulations, this type of data may be key data that needs to be reviewed by DES 1040A.

[0100] In some embodiments, for TTP IDC 3056, the data flowing out internally may also include code synchronization data. For example, in some cases, code review of the target application or application platform may be required due to data sovereignty protection and other inspection requirements. To prevent code leakage while meeting data sovereignty protection requirements, the code may be synchronized to a secure isolation environment 3051 for review. Secure isolation environment 3051 can be, for example, a physical environment such as an unconnected computer room, a monitored computer room, or a secure virtual computing environment.

[0101] From the perspective of the overseas IDC 3059, the DES 1040B deployed there also provides security protection for similar external inbound and internal outbound data. For example, user requests generated by target applications 3058 running overseas, after passing through load balancer 3047 and reaching the overseas application platform 3048 (which may include various services and storage), can also be protected by DES 1040B. Regarding operations and maintenance, overseas operations and maintenance personnel can also perform operations and maintenance operations on the overseas application platform 3048 through Crystal Gateway 3049 under network isolation. These operations and maintenance operations are also protected by DES 1040B.

[0102] For data protected in DES 1040A or 1040B, the scheme for implementing data sovereignty protection and the processing required to implement data sovereignty protection may also be different depending on the type.

[0103] In an embodiment of the present disclosure, in DES 1040 (e.g., DES 1040A or 1040B), data can be preprocessed according to data type to uniformly format the data, thereby simplifying and facilitating subsequent checks on data sovereignty protection and accelerating the data exchange process.

[0104] Therefore, DES 1040 can be divided into different processing sections based on data type. For example, based on data source, DES 1040A may include a domestic user data channel for processing data related to domestic users in a specific country or region; an overseas user data channel for processing data related to overseas users; and an engineering and technical data channel for processing engineering and operation and maintenance data, such as various R&D data and operation and maintenance data such as code and parameters. Furthermore, depending on the processing technology used for data generation, transmission, reception, and storage, the data in each channel can be further divided. As described below, based on technology, the data in different channels can be divided into one or more of message queue (MQ) data, offline aggregation data, target object store (TOS) data, service call data, or other types of data.

[0105] For data that has passed the data sovereignty protection review, it can be converted from the data in the uniform format back to the original format and provided to the corresponding destination. According to the scheme of the present disclosure, due to different data sources, different types of data are different in data format, processing technology, etc., and the complexity of the subsequent review stage of data sovereignty protection can be reduced through uniform formatting pre-processing and post-processing. In addition, with the update of data sources and technical expansion / changes, etc., only the pre-processing and post-processing of the data need to be changed, without making complex changes to the processing in the data exchange constraint determination stage. As a result, the data exchange architecture has great flexibility and scalability.

[0106] Some specific embodiments will be described in detail below with reference to the accompanying drawings.

[0107] The overall architecture and data flow of DES

[0108] Figure 3C FIG2 is a block diagram illustrating an example architecture of a DES 1040 according to some embodiments of the present disclosure. Figure 3C In the example, DES 1040 is shown as synchronizing data between the domestic application platform 3041 and the external application platform (collectively referred to as the overseas application platform 3048) for the target application and performing determination of data exchange constraints.

[0109] like Figure 3CAs shown, DES 1040 may include a DES adapter 3061, a DES center, and a DES adapter 3070. The DES center may include DES centers for different types of data channels, such as DES center 3065A for domestic user data, DES center 3065B for overseas user data, and DES center 3065C for engineering data. DES centers 3065A, 3065B, and 3065C have different synchronization capabilities. Hereinafter, for ease of description, DES centers 3065A, 3065B, and 3065C may be collectively referred to as DES center 3065.

[0110] DES adapter 3061 is connected to domestic application platform 3041 and is used to receive data to be synchronized and tested via DES 1040 from domestic application platform 3041, and to transmit data received from overseas application platform 3048 and tested via DES 1040 to domestic application platform 3041. DES adapter 3070 is connected to overseas application platform 3048 and is used to transmit data received from domestic application platform 3041 and tested via DES 1040 to overseas application platform 3048, and to receive data to be synchronized and tested via DES 1040 from overseas application platform 3048. DES adapter 3061 and DES adapter 3070 are both interconnected with DES center 3065 to transmit data to DES center 3065.

[0111] Each DES center 3065 is configured to use data exchange constraints to check data to ensure the security and compliance of data exchanged between the two application platforms. Generally, data that meets the data exchange constraints will be passed to the corresponding destination through DES 1040, while data that does not meet the data exchange constraints may be rejected by DES 1040.

[0112] The DES adapters 3061 and 3070 may be configured to perform pre-processing and post-processing on data to be passed into the DES center 3065 so that the DES center 3065 can determine whether data exchange constraints are satisfied based on the uniformly formatted data corresponding to each data type.

[0113] In some embodiments, the DES adapter 3061 and the DES center 3065 in the DES 1040 may be implemented in the TTP IDC 3056 together with the domestic application platform 3041 , and the DES adapter 3070 may be implemented in the overseas IDC 3059 together with the overseas application platform 3048 .

[0114] In some embodiments, different components in DES 1040 can be isolated to further ensure more effective data isolation. Such data isolation can be achieved by deploying different components in different data centers. In some embodiments, data isolation can be achieved by applying virtual private data center (VPC) technology. For example, Figure 3C As shown, DES adapter 3061 can be implemented in VPC1, each DES center can be implemented in VPC2, and DES adapter 3070 can be implemented in VPC3. The determination of data security and compliance in DES center 3065 can be performed by the TTP. In the case of data isolation, VPC1 and VPC3 do not have a direct communication connection, but VPC1 and VPC3 each have a direct communication connection with VPC2 and can communicate data / information with each other. Due to the data isolation brought by VPC technology, DES center 3065 deployed in VPC2 can be a TTP trusted area (referred to as a TTP trusted area).

[0115] In some embodiments, the DES adapter 3061 may include a DES portal 3062, which can implement control-plane processing, such as operations personnel applying to establish and manage data channels, registering rules, etc., and allowing the TTP to view data in the channel. The DES adapter 3061 may also include a DES proxy 3063, which can implement data-plane processing, such as data validation, data filtering, data conversion, data sampling, log detection, etc. Similarly, in some embodiments, the DES adapter 3070 may include a DES portal 3072 for the control plane and a DES proxy 3073 for the data plane.

[0116] In some embodiments, for domestic user data channels, the DES center 3065A may include a DES registration center for registering data exchange constraints, configuration data, and the like. The DES center 3065A may also include further subdivided channels, including a service call channel for service call data, an MQ channel for MQ data, an HDFS channel for offline aggregated data (HDFS is referred to as the Hadoop Distributed File System), and a TOS channel for TOS data. Offline aggregated data, for example, includes Highly Parallel Integrated Virtual Environment (HIVE)-type data.

[0117] Service call data may include, for example, data for remote service calls using various network protocols or call protocols, such as HTTP or RPC. MQ data may include data that supports the MQ protocol and similar protocols, such as data stored in various databases (e.g., MySQL, Redis database). Offline aggregated data may include data in file systems based on HDFS technology, as well as data in file systems based on other technologies. TOS data includes object files, such as video, audio, images, documents, and other media files.

[0118] In some embodiments, although Figure 3C Not shown, the DES center 3065B for overseas user data channels and the DES center 3065C for engineering technical data channels may also include components similar to the DES center 3065A.

[0119] Figure 3D A flow chart of a data exchange process 300 is shown according to some embodiments of the present disclosure. The process 3004 may be implemented in the DES 1040.

[0120] like Figure 3D As shown, at block 3301, DES 1040 obtains raw data to be exchanged between a first platform (e.g., domestic application platform 3041) and a second platform (e.g., overseas application platform 3048) by a target application. Depending on the direction of the exchange, the raw data may originate from the first platform and be received by DES adapter 3061 in DES 1040. Alternatively, the raw data may originate from the second platform and be received by DES adapter 3070 in DES 1040.

[0121] In block 3302, DES 1040 processes the raw data based on its type to obtain uniformly formatted data corresponding to that type. The processing of the raw data (processing herein may also be referred to as preprocessing) may be determined based on the type of the raw data. The types of raw data may include, for example, MQ data, offline aggregated data, TOS data, or service call data. Furthermore, in some cases, the processing of the raw data may also be determined based on the source of the data. For example, based on the source of the data, the raw data may be classified as domestic user data, overseas user data, or engineering and technical data. Different types of data correspond to different formats, and different methods may be applied to generate the corresponding uniformly formatted data.

[0122] In some embodiments, due to different technologies used by data sources, data of the same type may be provided in different formats, which increases the technical processing requirements. Therefore, a unified format can be specified. During the preprocessing stage, format conversion can be performed to convert the original data into the specified format for that type to obtain uniformly formatted data.

[0123] For example, MQ data in different formats can be parsed to analyze the content within messages encapsulated in different formats. Offline aggregated data and TOS data can be converted into file call requests implemented via a unified API in response to different requests from file systems or data systems in different formats. Service calls can be converted into service call requests generated under different protocols using a unified protocol.

[0124] The specific preprocessing methods for different types of data will be described in more detail below.

[0125] At block 3303, DES 1040 determines whether data exchange constraints are satisfied from the uniformly formatted data. For example, DES center 3065 within DES 1040, particularly the DES center 3065 corresponding to the data type, can perform checks to determine whether data exchange constraints are satisfied. Due to the uniformly formatted preprocessing, DES center 3065 does not need to apply various techniques to parse the raw data, making it easier to utilize rules to perform data security and compliance checks.

[0126] At block 3304, if the uniformly formatted data is determined to satisfy the data exchange constraints, the DES 1040 converts the uniformly formatted data into raw data. If the data exchange constraints are satisfied, the data is allowed to be synchronized between the platforms. To ensure proper data synchronization, the DES 1040 further processes the intermediately generated uniformly formatted data (i.e., performs a post-processing phase) to convert the uniformly formatted data into raw data having its original format.

[0127] In block 3305, the DES 1040 executes the exchange of original data between the first platform and the second platform, thereby achieving data exchange while satisfying security and compliance.

[0128] In some embodiments, as briefly mentioned above, multiple data channels corresponding to different types of raw data can be created between different platforms, and different types of raw data will be transferred to corresponding data channels for processing. Each data channel can include a pre-processing component, a post-processing component, and a confirmation component about data exchange constraints that are suitable for processing the raw data of that type. Additionally or alternatively, each data channel can be registered with a data exchange constraint that will be applied to the raw data of this particular type. In this way, the separation of the pre-processing of different types of data, the confirmation of data exchange constraints, and the post-processing can be achieved.

[0129] Data channels corresponding to different types of data can be flexibly created, updated, and deleted. This allows changes to be made to the data pre-processing and post-processing methods, or updates to the data exchange constraints for a specific type of data, to be performed in the corresponding data channel without affecting other data channels. Furthermore, based on business needs, if a new type of raw data is to be exchanged between the first and second platforms and this new type of data also requires data sovereignty protection checks, a new data channel can be flexibly created between the first and second platforms to process the new type of raw data.

[0130] Figure 3E A flow chart illustrating an example data flow 3005 of various types of data processing implemented at the DES 1040 according to some embodiments of the present disclosure is shown. The data flow 3005 involves data flow on the control plane and data flow on the data plane.

[0131] On the control plane, the operation and maintenance personnel can configure channels for one or more types of data in the DES 1040 and can update and maintain the channels. Figure 3E As shown, domestic operation and maintenance personnel can request the configuration of specific data types and channels for processing specific data types through DES portal 3062, and register data catalog 3081 indicating specific data types and data definitions 3082 similar to specific data with DES registration center 3066. Data definitions 3082 can specify channel information for processing different types of data in DES 1040, and can include pre-processing solutions, post-processing solutions, etc. for corresponding types of data.

[0132] Similarly, overseas operations and maintenance personnel can also request the configuration of specific data types and channels for processing specific data types through DES portal 3072. Overseas operations and maintenance personnel can also register data catalogs 3084 indicating specific data types and data definitions 3085 similar to the specific data with DES registration center 3066. Data definitions 3085 can specify channel information for processing different types of data in DES 1040 and can include pre-processing and post-processing solutions for the corresponding data types.

[0133] On the data plane, different types of data will pass through their own channels in DES 1040. Figure 3E As shown, for service call data, service call requests are exchanged between the client or server 3086 on the TTP IDC side and the client or server 3090 on the overseas IDC side. In order to ensure that the service call request meets the data sovereignty protection requirements, the service call request is processed in the service call channel in the DES 1040.

[0134] exist Figure 3E In the example of FIG, the service call channel may include at least a pre-processing module 3087 in the DES agent 3063, an HTTP agent 3088 in the DES center 3065, and a routing module 3089 in the DES agent 3073. A service call request from a client or server 3086 on the TTP IDC side is transmitted to the pre-processing module 3087. The pre-processing module 3087 processes the service call request using the data pre-processing solution specified in the data definition 3082 and sends the uniformly formatted service call request to the HTTP agent 3088.

[0135] In this example, it is assumed that service call requests are uniformly formatted to comply with a unified protocol, namely, HTTP. Therefore, after determining that the uniformly formatted service call request satisfies data exchange constraints, HTTP proxy 3088 can provide the uniformly formatted service call request to the client or server 3090 on the other side via routing module 3089. Before being provided to client or server 3090, the uniformly formatted service call request is converted back to a service call request that complies with the original protocol.

[0136] For MQ data, this type of raw data is processed in the MQ channel in DES 1040. Figure 3E In the example, the MQ channel may include at least a pre-processing module 3092 in the DES agent 3063 , an MQ transmitter 3094 in the DES center 3065 , and a routing module 3097 in the DES agent 3073 .

[0137] The raw data 3091 of the MQ type is transmitted to the preprocessing module 3092. The preprocessing module 3092 uses the data preprocessing scheme specified in the data definition 3082 to process the raw data 3091 to obtain uniformly formatted data 3093. The uniformly formatted data 3093 is extracted by the MQ transmitter 3094, for example, via a third-party software development kit (SDK). After checking the data exchange constraints, the SDK pushes the uniformly formatted data 3096 that meets the rules to the overseas IDC. The uniformly formatted data 3095 that does not meet the data exchange constraints is rejected. The routing module 3097 routes the uniformly formatted data 3096 that meets the rules to the corresponding destination. Before being transmitted to the destination, the uniformly formatted data 3093 is converted back to the corresponding raw data 3098.

[0138] For offline aggregated data and TOS data, the original data will be processed in the HDFS channel and TOS channel in DES 1040 respectively. Figure 3E An example of one channel is shown, but it is understood that the HDFS channel and the TOS channel may include the components shown. Figure 3E In the example, the HDFS channel or TOS channel may include at least a pre-processing module 3100 in the DES agent 3063, a file transmitter 3103 in the DES center 3065, and a routing module 3105 in the DES agent 3073.

[0139] Since data of the offline aggregate data type or TOS type is stored in a file system or other storage system, the pre-processing module 3100 may initiate a request to the file transfer manager 3102 to call a file transfer API to obtain raw data 3099 of the offline aggregate data type or TOS type to be transferred to the pre-processing module 3100. The pre-processing module 3100 may process the raw data 3099 using the data pre-processing solution specified in the data definition 3082 to obtain uniformly formatted data 3101.

[0140] Similar to MQ-type data processing, uniformly formatted data 3101 is extracted by a file transmitter 3103, for example, via an SDK. After checking the data exchange constraints, the SDK pushes the uniformly formatted data 3104 that meets the rules to the overseas IDC. Uniformly formatted data that does not meet the data exchange constraints is rejected and cannot be transmitted to the overseas IDC. The routing module 3105 routes the uniformly formatted data 3104 that meets the rules to the corresponding destination. Before being transmitted to the destination, the uniformly formatted data 3094 is converted back to the corresponding original data 3106.

[0141] It should be understood that Figure 3EOnly the processing of outgoing data from the TTP IDC to the overseas IDC in DES 1040 is shown. Data flows in the opposite direction can also be processed in DES 1040 through a similar process, and DES 1040 can also retain corresponding components to support corresponding processing, especially components in the DES adapter.

[0142] Some example implementations of different types of data in DES 1040 are discussed in detail below.

[0143] Sample implementation of data exchange for MQ

[0144] Figure 3F FIG2 shows a schematic block diagram of a data exchange architecture 3006 involving an MQ channel according to some embodiments of the present disclosure. The data exchange architecture 3006 may be implemented in the DES 1040 to perform data security protection for MQ type data. Figure 3F The example shows data exchange from the TTP IDC to the overseas IDC.

[0145] like Figure 3F As shown, the source database 3110 in the TTP IDC generates the entity of MQ data to be transmitted. The MQ data may include messages such as change data or business customization events, and different messages may have different formats. The MQ data generated by the source database 3110 is placed in the source message queue 3112.

[0146] exist Figure 3F In the example, in addition to the DES entry 3062, the DES adapter 3061 also includes a DES pre-adapter 3120. The DES pre-adapter 3120 can be implemented as part of the DES agent 3063 to pre-process MQ data from the TTP IDC to the overseas IDC. The DES pre-adapter 3120 can be configured to process MQ data of different formats into uniformly formatted MQ data and provide the uniformly formatted MQ data to the MQ transmitter 3094 to determine whether the data exchange constraints are satisfied.

[0147] MQ data (or messages) can also include data generated by different protocols, each of which has a custom format and therefore requires different preprocessing. Figure 3F As shown, the DES pre-adapter 3120 may include a parser 3122 configured to parse different types of original MQ data to convert the different types of original MQ data into unified formatted MQ data. Figure 3FAs shown, the pre-DES adapter 3120 may include a MySQL parser for parsing data generated via the MySQL protocol, such as change data capture (CDC) data; a Redis parser for parsing data generated via the Redis protocol, such as CDC data; a document parser for parsing data in a document database, particularly CDC data; a graph parser for parsing data in a graph database, particularly CDC data; an MQ parser for parsing different types of business event data sent via a message queue, etc. It will be appreciated that the parser 3122 is flexibly scalable, wherein more, fewer, or other parsers may be provided for parsing corresponding types of MQ data.

[0148] The uniformly formatted MQ data obtained after parsing can also be in the form of a message queue and can be placed in the uniformly formatted message queue 3124. In VPC2 of the TTP IDC, the MQ transmitter 3094 responsible for MQ data can extract the parsed uniformly formatted MQ data from the uniformly formatted message queue 3124 through the SDK for data security and compliance checks.

[0149] The unified formatted MQ data is rejected by the MQ transmitter 3094 and recorded in the rejection log 3126. The unified formatted MQ data that meets the data exchange constraints is pushed to the DES post-adapter 3130 in the DES adapter 3070 via the SDK.

[0150] The DES post-adapter 3130 can be implemented as part of the DES agent 3073 to post-process the uniformly formatted MQ data from the TTP IDC to the overseas IDC to transmit the data to the destination. The uniformly formatted MQ data that meets the data exchange constraints is pushed to the DES post-adapter 3130 via the SDK.

[0151] The DES post-adapter 3130 may include a data replayer 3132 for performing post-processing on the uniformly formatted MQ data. Specifically, the DES post-adapter 3130 may be configured to convert the uniformly formatted MQ data into raw MQ data. Therefore, the DES post-adapter 3130 may include replayers corresponding to different types of MQ data for performing conversion from the uniform format to respective customized formats. Figure 3FAs shown, the DES post-adapter 3130 may include a MySQL replayer for converting uniformly formatted MQ data into MQ data that complies with the MySQL protocol; a Redis replayer for converting uniformly formatted MQ data into MQ data that complies with the Redis protocol; a document replayer for converting uniformly formatted MQ data into raw data in graphical form; an MQ replayer for converting uniformly formatted data into raw data that complies with the MQ protocol, and so on.

[0152] The converted raw MQ data is placed in the uniformly formatted message queue 3134 in the DES post-adapter 3130, from which it can be synchronized to the target message queue 3135. The target message queue 3135 is used to store MQ data that is indirectly synchronized from the source message queue 3112 via the DES 1040. The target database 3136 can obtain the desired MQ data from the target message queue 3135.

[0153] Figure 3F Only the components involved in data exchange from TTP IDC to overseas IDC are shown. Figure 3F In the example shown, data exchange from an overseas IDC to a TTP IDC is shown. DES 1040 may include similar components for processing data exchange in this direction. For example, DES adapter 3070 may include a DES pre-adapter having similar functions to DES pre-adapter 3120, and DES adapter 3061 may include a DES post-adapter having similar functions to DES post-adapter 3130. For simplicity, the processing in this direction will not be further elaborated.

[0154] I understand. Figure 3F The components for processing MQ data exchange in DES shown in FIG are only examples. In other examples, different functional modules may also be subdivided, merged, etc. in other ways, depending on needs, and may also include more, fewer, or different functional modules.

[0155] Example implementation of data exchange for offline aggregated data

[0156] Figure 3G FIG2 shows a schematic block diagram of a data exchange architecture 3500 involving an HDFS channel according to some embodiments of the present disclosure. The data exchange architecture 3500 can be implemented in DES 1040 to perform data security protection for offline aggregated data. Figure 3G In the example shown, offline aggregated data exchange between HDFS 3502 on the TTP IDC side and HDFS 3504 on the overseas IDC side is shown. Some offline aggregated data in HDFS 3502 and HDFS 3504 may need to be synchronized with each other.

[0157] like Figure 3G As shown in the data exchange architecture 3500, the data transfer detector 3510 on the TTP IDC side is responsible for detecting whether offline aggregated data that needs to be transferred to the HDFS 3504 on the other side is stored in the HDFS 3502. If offline aggregated data to be transferred is found, the data transfer submitter 3520 can submit a data transfer request to the file transmitter 3550. Before being submitted to the file transmitter, the data pre-processing module 3530 is configured to perform pre-processing on the data to process the offline aggregated data into uniformly formatted data.

[0158] In the file transfer 3550, the data transfer server 3556 is configured to control the data transfer service based on the use of data exchange constraints. If the data transfer server 3556 determines that the pre-processed uniformly formatted data from HDFS 3502 meets the data exchange constraints, it can call the transfer job 3558 to transfer the uniformly formatted data to the overseas IDC via the transfer task 3562 under the transfer job 3558. In some embodiments, the transfer job 3558 can also optionally include a data validation task 3560, which can be configured to perform data validation as needed. The uniformly formatted data passes through the HDFS gateway 3564 and can be post-processed to obtain the original offline aggregated data and stored in HDFS 3504.

[0159] Similarly, in data exchange architecture 3500, data transfer detector 3570 on the overseas IDC side is responsible for detecting whether HDFS 3504 stores offline aggregated data that needs to be transferred to HDFS 3502 on the TTP IDC side. If offline aggregated data to be transferred is found, data transfer submitter 3572 can submit a data transfer request to file transmitter 3550. Before being submitted to the file transmitter, data preprocessing module 3570 is configured to preprocess the data to convert the offline aggregated data into uniformly formatted data.

[0160] In file transporter 3550, if data transport server 3556 determines that the pre-processed uniformly formatted data from HDFS 3504 meets the data exchange constraints, it can call transport job 3554 to transport the uniformly formatted data to the TTP IDC via transport task 3552 under transport job 3554. After post-processing, the uniformly formatted data is converted into raw offline aggregated data and stored in HDFS 3502.

[0161] I understand. Figure 3GThe components for processing offline aggregated data exchange in DES shown in FIG are only examples. In other examples, depending on needs, different functional modules can also be subdivided, merged, etc. in other ways, and can also include more, fewer or different functional modules.

[0162] Example implementation of data exchange for object storage

[0163] In general, the TOS channel can determine whether an object file satisfies data exchange constraints and, if so, copies the object file from a source IDC (e.g., a TTP IDC or an offshore IDC) to a destination IDC (e.g., an offshore IDC or a TTP IDC). Object files are, for example, video, audio, image, document, or other media files.

[0164] In some embodiments, an object file can be copied from an object storage via an API, a determination of data exchange constraints can be performed, and the object file can be pushed to the object storage at the destination end using the API. In the data exchange of the object file, the satisfaction of the data exchange constraints is determined by the copy request corresponding to the object file. Figures 3H to 3J To describe the details of the TOS channel.

[0165] Figure 3H A schematic diagram of a target object store (TOS) channel 3600 for replicating data from a TTP IDC to an offshore IDC according to some embodiments of the present disclosure is shown. In this example, the data to be exchanged is an object file, which is stored in an object store 3606 in the TTP IDC and is expected to be exchanged to an object store 3607 in the offshore IDC.

[0166] exist Figure 3H In the figure, API 3605 in the TTP IDC is configured to push replication requests to worker nodes 3605 and receive replication results exchanged from the overseas IDC on the other side. As shown in the figure, when the data flow begins 3601, a replication request for the object file to be exchanged is transmitted to worker nodes 3605 by API (also known as DES-TOS API) 3602. This replication request can indicate information related to the object file to be exchanged, such as the object file format (video, audio, text, etc.), the object file identifier, and other file metadata. This replication request has a unified format.

[0167] The worker node 3605 in the trusted region VPC2 is configured to perform a determination regarding data exchange constraints in response to a replication request for an object file. Specifically, the worker node 3605 can determine whether the object file to be exchanged satisfies the data exchange constraints from the uniformly formatted replication request.

[0168] In some embodiments, data exchange constraint registration can be initiated on the TTP IDC side, either initially or when needed. At constraint registration start 3622, the data exchange constraints to be used can be registered with the DES registration center 3624 in the TTP trusted zone via the DES entry 3620 in the TTP IDC. Data exchange constraint registration can be achieved by calling API 3602. Worker node 3605 can access the data exchange constraints currently in use via DES registration center 3624.

[0169] In some embodiments, the data exchange constraints may indicate a whitelist of object files allowed to be exchanged or a blacklist of object files not allowed to be exchanged. In each list, the file objects allowed or not allowed to be exchanged may be identified according to the format, identifier, etc. of the object file.

[0170] After executing the data exchange constraints, worker node 3605 allows execution of replication requests that meet the data exchange constraints. If the replication request is allowed, worker node 3605 accesses object storage 3606 in the TTP IDC to replicate the object file to object storage 3607 in the offshore IDC. Illegal requests (i.e., replication requests that do not meet the data exchange constraints) are rejected and thus cannot be executed. Worker node 3605 can write the replicated object file to object storage 3607 via API 3610 in the offshore IDC. Thus, the data flow ends 3611.

[0171] Figure 3I A schematic diagram of a TOS channel 3650 for replicating data from an offshore IDC to a TTP IDC according to some embodiments of the present disclosure is shown. In this example, the object files to be exchanged are stored in object storage 3607 in the offshore TTP IDC and are expected to be exchanged to object storage 3606 in the TTP IDC.

[0172] exist Figure 3I In the example, the API 3610 in the overseas IDC is configured to push the replication request to the work node 3605 and receive the replication result exchanged from the TTP IDC on the other side from the work node 3605. Figure 3I As shown, when the data flow starts 3651, a replication request for the object file to be exchanged is transmitted by API 3610 to worker node 3605. The replication request may indicate information related to the object file to be exchanged, such as the object file format (video, audio, text, etc.), the object file identifier, and other file metadata. The replication request has a unified format. Worker node 3605 in the trusted zone VPC2 can determine whether the object file to be exchanged meets the data exchange constraints based on the uniformly formatted replication request.

[0173] In some embodiments, data exchange constraint registration can be initiated on the overseas IDC side, either initially or as needed. At constraint registration start 3632, the data exchange constraints to be used can be registered with the DES registration center 3624 in the TTP trusted zone via the DES portal 3630 in the overseas IDC. Data exchange constraint registration can be accomplished by calling API 3610. Worker node 3605 can access the data exchange constraints currently in use through DES registration center 3624.

[0174] After executing the data exchange constraints, worker node 3605 allows execution of replication requests that meet the data exchange constraints. If the replication request is allowed, worker node 3605 accesses object storage 3607 in the offshore IDC to replicate the object file to object storage 3606 in the TTP IDC. Illegal requests (i.e., replication requests that do not meet the data exchange constraints) are rejected and thus cannot be executed. Worker node 3605 can write the replicated object file to object storage 3606 via API 3602 in the TTP IDC. Thus, the data flow ends 3652.

[0175] I understand. Figure 3H and Figure 3I The components for processing TOS data exchange in DES shown in FIG are only examples. In other examples, depending on needs, different functional modules can also be subdivided, merged, etc. in other ways, and can also include more, fewer or different functional modules.

[0176] Figure 3J Message sequence 3012 in a TOS channel is shown according to some embodiments of the present disclosure. Figure 3J The message sequence 3012 in involves TTP 3701, operation and maintenance personnel 3702, platform staff 3703, DES portal 3704, API 3705, working node 3605 and object storage 3708.

[0177] Depending on the direction of data exchange, Figure 3J The DES entry 3704, API 3705 and object storage 3708 in can be Figure 3H and Figure 3I For example, in Figure 3H As shown, in the TOS channel 3600 copied from the TTP IDC to the offshore IDC, the DES entry 3704 includes Figure 3H DES inlet 3620 shown, API 3705 includes Figure 3H API 3602, object storage 3708 includes Figure 3HIn the object storage 3606 in the TOS channel 3650 copied from the overseas IDC to the TTP IDC, the DES entry 3704 includes Figure 3I DES inlet 3630 shown, API 3705 includes Figure 3I API 3610, object storage 3708 includes Figure 3I Object storage in 3607.

[0178] In message sequence 3012, operator 3702 registers 3711 data exchange constraints with DES portal 3704, which may constrain the replication of object files between object stores 3606 and 3607 in different IDCs. After completing the registration, DES portal 3704 may send a response 3714 to the operator. DES portal 3704 registers 3712 container information regarding the data exchange constraints with API 3705, and after the registration is complete, API 3705 may send a response 3713 to DES portal 3704. Rules registered via DES portal 3704 may be cached 3715 in API 3705 and may also be cached 3716 in worker nodes 3605.

[0179] The platform worker 3703 may initiate 3717 a copy request for an object file to the API 3705. The API 3705 may perform authentication 3718. The worker node 3605 may pull 3719 the copy request from the API 3705 and perform 3720 a determination of data exchange constraints on the object file to be copied. If copying the object file is allowed, the worker node 3605 performs 3721 a file copy to copy the corresponding object file from the object storage 3706. Regardless of the result of the data exchange determination not being met, the worker node 3605 returns 3722 feedback to the API 3705. In the event that copying the object file is allowed, the feedback includes the copied object file. In the event that copying the object file is not allowed, the feedback is used to indicate that the copy request was denied.

[0180] In some embodiments, platform staff 3703 may call back 3723 API 3705, and API 3705 may return 3724 a replication request ID to platform staff 3703. In some embodiments, TTP 3701 may view 3725 historical object file replication status through DES entry 3704 to confirm whether object file exchanges over the past period of time meet data exchange constraints. DES entry 3704 may return 3726 the requested result.

[0181] Example implementation of data exchange protection for service calls

[0182] Figure 3KFIG1 shows a schematic block diagram of a data exchange architecture 3800 involving a service call channel according to some embodiments of the present disclosure. The data exchange architecture 3800 can be implemented in DES 1040 to perform data security protection for service call type data. Figure 3L The example in FIG. 3 shows service call data exchange between a target platform service 3802 on the TTP IDC side and an overseas (non-TTP) platform service 3804 on the overseas IDC side. For example, a service on the target platform service 3802 may need to call a service on the overseas platform service 3804, and vice versa, a service on the overseas platform service 3804 may also need to call a service on the target platform service 3802.

[0183] Different service platforms may use a variety of different service call protocols, such as HTTP or Thrift RPC. In some embodiments of the present disclosure, it is desirable to process uniformly formatted data, such as HTTP protocol data, when performing data sovereignty protection in a VPC trusted zone.

[0184] exist Figure 3K On the control plane, the non-TTP control plane is used for channel registration, channel architecture updates, and detection; the TTP / TTP control plane is used for channel request approval, channel prohibition, and channel detection. On the data plane, the HTTP load balancer 3810 is a Layer 7 balancing product from TTPCloud. It is a key component that ensures all DES-RPC channel traffic passes through the VPC trusted zone. The HTTP channel is the DES-RPC channel that supports the HTTP protocol. The Thrift RPC channel is the DES-RPC channel that supports the Thrift RPC protocol. Before being sent to the TTP HTTP load balancer, the Thrift RPC channel is wrapped in the HTTP channel.

[0185] During the channel registration phase, a DES-RPC channel is declared using channel information and data definitions. The channel information may include the channel type, such as Thrift RPC or HTTP. The channel information may also include an RPC call tuple. The call tuple may include the source directive, source service, destination directive, destination service, and the RPC method / HTTP path.

[0186] Data definitions can depend on the direction of data flow. For data flowing from a non-TTP to a TTP, responses are declared using Thrift IDL with compliance annotations. For data flowing from a TTP to a non-TTP, requests are declared using Thrift IDL with compliance annotations. In some embodiments, a DES-RPC channel is only available if it has been registered with compliance.

[0187] I understand. Figure 3K The components for processing service call data exchange in DES shown in FIG are merely examples. In other examples, different functional modules may also be subdivided, merged, etc. in other ways, depending on needs, and may also include more, fewer, or different functional modules.

[0188] Figure 3L According to some embodiments of the present disclosure, Figure 3K An example of data exchange from non-TTP to TTP in the service call channel shown in FIG. Figure 3L As shown, the call initiated by service A 3901 in the overseas region will be forwarded by HTTP proxy 3902 or Thrift proxy 3903 to the HTTP load balancer 3905 of TTP. Service A 3901 can be Figure 3K An example of an offshore platform service is shown. For HTTP requests, the call is forwarded by HTTP proxy 3902 to HTTP load balancer 3905. For Thrift requests, the call is forwarded by Thrift proxy 3903 to HTTP load balancer 3905.

[0189] For service proxies in overseas IDCs, such as HTTP proxy 3902 or Thrift proxy 3903, it is recommended to use DNS to discover services to the HTTP load balancer 3905 in the VPC trusted zone. For service discovery of proxies that forward requests to the TTP IDC area, it is recommended to use customized / generic service discovery.

[0190] HTTP load balancer 3905 may include a compliance plug-in 3906. For illegal requests, compliance plug-in 3906 will return an error. For Thrift RPC calls, the request will be HTTP wrapped to generate a new HTTP request. The body of the new HTTP request is a Thrift binary file.

[0191] In the VPC trusted zone, the TTP's HTTP load balancer 3905 forwards the request to the TTP's HTTP proxy 3907 and Thrift proxy 3908, respectively. HTTP proxy 3907 and Thrift proxy 3908 then forward the request to target services B 3908 and C 3910, respectively. For Thrift RPC calls, Thrift proxy 3908 recovers the original Thrift request from the generated new HTTP request before sending the request.

[0192] The TTP's HTTP proxy 3907 and Thrift proxy 3908 will check responses before sending them to the TTP's HTTP load balancer 3905. Responses that fail compliance checks will return an error. Furthermore, for Thriftrpc calls, the Thrift response will be HTTP wrapped to generate a new HTTP response. The body of the new HTTP response will be the Thrift binary file.

[0193] Figure 3M According to some embodiments of the present disclosure, Figure 3K An example of data exchange from TTP to non-TTP in the service call channel shown in FIG. Figure 3M As shown, the call initiated by TTP's service A 3951 will be forwarded by TTP's HTTP proxy 3952 and Thrift proxy 3953 to TTP's HTTP load balancer 3955. For HTTP requests, the call will be forwarded by HTTP proxy 3952 to HTTP load balancer 3955. For Thrift requests, the call will be forwarded by Thrift proxy 3953 to HTTP load balancer 3955.

[0194] An error is returned for illegal requests. An error is returned for responses that fail compliance checks. For Thrift RPC calls, the request is wrapped with HTTP to generate a new HTTP request. The body of the new HTTP request is the Thrift binary file.

[0195] The HTTP load balancer 3955 of the TTP forwards the request to the HTTP proxy 3957 and Thrift proxy 3958 of the non-TTP (i.e., overseas region). The HTTP proxy 3957 and Thrift proxy 3958 then forward the request to service B 3959 and service C 3960 of the overseas region.

[0196] For Thrift rpc calls, the Thrift proxy recovers the original Thrift request from the generated new HTTP request before sending it.

[0197] The non-TTP HTTP proxy 3957 and Thrift proxy 3958 will send responses to the TTP HTTP load balancer 3955. For Thrift RPC calls, the Thrift response will be HTTP wrapped to generate a new HTTP response. The body of the new HTTP response is the Thrift binary file.

[0198] Safe sandbox system

[0199] Client applications need to communicate with servers to transfer data. This client application network traffic can carry large amounts of user data. Therefore, a method is needed to manage client application network traffic to prevent user data from being transferred to unauthorized servers via client application network traffic. For example, in data sovereignty protection scenarios, this method can prevent user data from being transferred to servers in non-data sovereign countries.

[0200] However, the types of network traffic of client applications are very diverse. Client applications can include mobile applications and computer (PC) applications. The network traffic of client applications can include native type network traffic and web view type network traffic, etc. In addition, the network traffic of client applications is not always under the management and control of the application owner. For example, the network traffic of client applications can include network traffic from third-party advertisers. Therefore, it is very difficult to manage the various types of network traffic of client applications.

[0201] An exemplary embodiment of the present disclosure provides a method for managing network traffic of a client application. The method includes: detecting a network transmission of user data of the target user from the client application to a server based on a determination of a target user; analyzing the network traffic at different layers of the network transmission based on a type of network traffic corresponding to the network transmission; and, based on the analysis indicating that the network traffic satisfies a data exchange constraint corresponding to the target user, sending the network traffic to a server defined by the data exchange constraint.

[0202] In this way, by analyzing network traffic at different layers of network transmission based on the type of network traffic and limiting the transmission of network traffic that does not meet data exchange constraints, user data can be effectively prevented from being transmitted to unauthorized servers via various types of network traffic.

[0203] The embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. The solutions of the present disclosure will be exemplarily illustrated below using mobile terminal applications as an example.

[0204] Figure 4A A flowchart of an example method 4100 for managing network traffic of a mobile application according to some embodiments of the present disclosure is shown. Figure 1 The mobile application may be a target application 1080 on the mobile terminal.

[0205] At block 4102 , based on the determination of the target user, the network transmission of the target user's user data from the target application 1080 to the server is detected. In other words, if the current user is determined to be the target user, the security sandbox system 1090 may detect the network transmission of the target user's user data.

[0206] In some implementations, network traffic can be routed to the security sandbox system 1090 based on the determination of the target user, so that the security sandbox system 1090 can detect and analyze network traffic corresponding to network transmissions of user data. The security sandbox system 1090 can analyze network requests of the target application 1080 and restrict network requests that do not meet the conditions based on the data exchange constraints.

[0207] Data exchange constraints may include exchange constraints related to data sovereignty, such as data sovereignty protection rules. Data sovereignty protection rules can be determined based on the regulations of each country or region. Data sovereignty protection rules can also be determined by the operator of the application (for example, related to the user data usage agreement).

[0208] Data sovereignty protection rules can be set based on specific scenarios. For example, data sovereignty protection rules may stipulate that user data from a data sovereign country cannot be transferred to any server outside the data sovereign country. In other implementations, data sovereignty protection rules may stipulate that private user data from a data sovereign country cannot be transferred to any unregistered server. This is not limited to the scope of this disclosure.

[0209] like Figure 1 As shown, the network request of the target application 1080 is transmitted to the application firewall subsystem 1020 after being analyzed and processed by the security sandbox system 1090. The principles and details of the security sandbox system 1090 will be described in detail below.

[0210] A target user is a user whose user data transmission needs to be monitored and managed. A target user may be a user with nationality in a data sovereign country. Alternatively or additionally, a target user may be a user determined based on specific rules governing data sovereignty protection. For example, a target user may be a user with nationality in a data sovereign country and currently located in that data sovereign country.

[0211] In some implementations, the target user can be determined based on user information. User information can include user account information, personal information, registration information, etc. Alternatively or additionally, the target user can be determined based on device information. Device information can include Subscriber Identity Module (SIM) information, IP address, network service provider information, device system settings information, application settings information, etc.

[0212] In some implementations, the target user can be determined based on a combination of multiple types of information. The multiple types of information can have different priorities. For example, SIM card information and network service provider information can have a higher priority than IP address, system settings, application settings, etc.

[0213] In some implementations, the target user can be identified based on the target user's region. The target user's region can be determined using the aforementioned user information or device information, thereby identifying the target user. For example, the region setting in a smartphone's system settings can be used to determine the current user's region, and thus determine whether the current user is the target user. For another example, the target user's region can be determined using the SIM card's country code, and thus used to identify the target user.

[0214] In some implementations, the target user can be determined when the application is first launched. In other words, whether the current user is the target user can be determined when the application is first launched. Alternatively or additionally, whether the current user is the target user can be determined when the user registers. Alternatively or additionally, whether the current user is the target user can be determined when the user logs in, logs out, or switches accounts.

[0215] In some implementations, the determination results can be stored locally or on a server. After the user is first identified as a target user, the determination results can be stored and used within a threshold time period. This eliminates the need to re-identify the user when the user logs in again.

[0216] At block 4104 , the network traffic is analyzed at different layers of the network transmission based on the type of network traffic to which the network transmission corresponds.

[0217] The network traffic in the target application 1080 can include multiple types of network traffic, such as native, web view, and third-party software development kit (SDK) network traffic. Native network traffic is generated and processed by the operating system (e.g., Android and iOS) code in the business layer. Native network traffic can be fully controlled by the owner of the target application 1080.

[0218] Third-party SDK network traffic is generated and processed by the third-party SDK. Typically, target application 1080 can integrate a third-party SDK to implement login or sharing functionality. Third-party SDK network traffic is generated and processed by these third-party SDKs. It should be understood that third-party SDK network traffic is generally not fully controlled by the application owner.

[0219] Web view-type network traffic can include network traffic controlled by the app owner, such as network traffic generated by the app's built-in browser by calling native app code. Web view-type network traffic can also include network traffic controlled by a third party, such as network traffic generated and controlled by third-party advertisers.

[0220] Based on the type of network traffic, the security sandbox system 1090 can adopt corresponding analysis strategies to better manage the network transmission of user data in the application.

[0221] At block 4106, based on the analysis indicating that the network traffic satisfies the data exchange constraints corresponding to the target user, the network traffic is sent to a server defined by the data exchange constraints. Different data exchange constraints can be set for different target users. For example, stricter data exchange constraints can be set for target users with higher sensitivity levels. The data exchange constraints can define which user data can be transmitted to which servers. In some implementations, the data exchange constraints corresponding to the target user can be determined based on the target user's user information or corresponding device information.

[0222] In some implementations, the security sandbox system 1090 may include multiple submodules for different types of network traffic. For example, a submodule for managing native network traffic, a submodule for managing web view network traffic, and a submodule for managing third-party SDK network traffic. These submodules can analyze the corresponding type of network traffic and limit or intercept network traffic that does not meet the data exchange constraints. Figures 4B to 4E To describe in detail the details of managing different types of network traffic.

[0223] Figure 4B A schematic diagram of an analysis and restriction process 4200 for native type network traffic according to some embodiments of the present disclosure is shown. Figure 4B The submodule 4210 for analyzing and limiting native network traffic is shown. The submodule 4210 may be a part of the security sandbox system 1090 or a specific implementation of the security sandbox system 1090.

[0224] like Figure 4B As shown, the business logic layer 4220 sends the network request to the underlying OS 4230. The business logic layer 4220 can be Figure 1 A specific implementation of the application business logic 1100 in terms of network transmission is shown. Submodule 4210 can act as an interceptor to analyze and limit network requests at the network layer. Submodule 4210 can limit network requests by analyzing endpoints, parameters of network requests, or schemas. For example, whether to limit the network request can be determined based on whether the schema has been registered. Alternatively or additionally, whether to limit the network request can be determined based on whether the requested field in the network request involves sensitive information.

[0225] In some implementations, submodule 4210 may include an interceptor for Android and an interceptor for iOS. Additionally, submodule 4210 may also include an interceptor for C++. In this way, by analyzing and restricting network requests at the network layer, it is possible to better determine whether the network request should be restricted based on the protocol information of the network request.

[0226] Figure 4C A schematic diagram of a process 4300 for analyzing and limiting network traffic of a web view type according to some embodiments of the present disclosure is shown. Figure 4C The submodule 4310 for analyzing and limiting network traffic of the web page view type is shown. The submodule 4310 can be a part of the security sandbox system 1090 or a specific implementation of the security sandbox system 1090.

[0227] Submodule 4310 can divert web view type network traffic to the native network interface so that the web view type network traffic can be analyzed and restricted by submodule 4210 for native type network traffic. In some implementations, submodule 4310 can utilize a JavaScript (JS) hook mechanism to divert web view type network traffic to the native network interface.

[0228] like Figure 4C As shown, submodule 4310 may include a launcher 4311, a navigation URL interceptor 4312, and an internal request interceptor 4313. Submodule 4310 may communicate with the application's built-in browser 4320 so that web view type network traffic may be managed and detected by submodule 4310. Launcher 4311 may perform JS injection when the application's built-in browser 4320 is opened (created) so that web view type network traffic may be diverted to the native network interface using a hook mechanism. The network traffic diverted to the native network interface may be taken over by the native network module.

[0229] In some implementations, the following method can be used to utilize JS hook technology to divert network traffic.

[0230] Navigation URL interceptor 4312 can analyze and restrict the URL of the main page (initial page). For example, navigation URL interceptor 4312 can determine whether to restrict the network request based on whether the URL's schema is registered. If the network request is not restricted, browser 4320 can load the main page.

[0231] Internal request interceptor 4313 can forward network traffic related to static and dynamic resources on the main page to the native network interface, so that this network traffic can be restricted and analyzed at the network layer by submodule 4210. The specific analysis and restriction process is similar to that for native network traffic and will not be repeated here.

[0232] In some implementations, submodule 4310 may employ different analysis and restriction strategies for web view type network traffic controlled by the application owner and web view type network traffic controlled by a third party. For example, for web view type network traffic controlled by a third party, the navigation URL interceptor 4312 may be used to determine whether the main page URL is registered to analyze the related network traffic, without further analyzing the main page's static and dynamic resources.

[0233] Figure 4D A schematic diagram of a process 4400 for analyzing and limiting third-party SDK type network traffic according to some embodiments of the present disclosure is shown. Figure 4D The diagram shows a submodule 4410 for analyzing and limiting third-party SDK-type network traffic. The submodule 4410 may be a part of the security sandbox system 1090 or a specific implementation of the security sandbox system 1090.

[0234] Submodule 4410 can analyze and limit the network traffic of third-party SDK types at the application program interface (API) layer. Submodule 4410 can limit the network traffic of third-party SDK types by analyzing whether the data requested by the API of the third-party SDK meets the data exchange constraints at the API layer.

[0235] In some implementations, submodule 4410 can wrap the API in a third-party SDK that requests user data and add judgment logic based on data exchange constraints to the wrapper. In other words, submodule 4410 can determine the wrapped API by adding judgment logic to the third-party SDK's API. In this way, business logic layer 4220 does not directly call the third-party SDK's API, but instead calls the wrapped API with the added judgment logic.

[0236] like Figure 4DAs shown, submodule 4410 may include a wrapper module for each third-party SDK. For example, wrapper module 4412 for SDK 4411, wrapper module 4414 for SDK 4413, and wrapper module 4416 for SDK 4415. A wrapper module (e.g., wrapper module 4412) may wrap the API in the corresponding SDK (e.g., SDK 4411) to generate the corresponding wrapped API. In some implementations, submodule 4410 may dynamically add a wrapper module to wrap the API of the third-party SDK.

[0237] In some implementations, the API of a third-party SDK can be wrapped as follows: The wrapper module 4412 can define an API exposed to the business layer that is identical to the API in the SDK 4411. The wrapper module 4412 can implement the API and define wrapper classes for the SDK 4411 data types.

[0238] The judgment logic can determine whether the API of the wrapped third-party SDK can be called based on the data exchange constraints. In some implementations, the judgment logic can analyze whether the API of the third-party SDK can be called based on the name of the SDK, the name of the API, the name of the API parameter, etc. If the judgment result is yes, the API of the third-party SDK can be called and the value is returned to the business layer. If the judgment result is no, the API of the third-party SDK is not called, that is, the network traffic related to the API is restricted. It should be understood that the judgment logic can vary based on the specific scenario. For example, the judgment logic can be set to not allow the user's private data to be passed to the third-party SDK.

[0239] In this way, by performing analysis and restriction at the API layer, the submodule 4410 can manage and detect third-party SDK type network traffic without knowing the internal code of the third-party SDK.

[0240] Figure 4E FIG. 1 shows a module diagram of a security sandbox system 1090 according to some embodiments of the present disclosure. Figure 4E As shown, the security sandbox system 1090 includes a startup module 4520. The startup module 4520 is configured to initiate detection of network transmission of user data of the target user from the client application to the server based on the determination of the target user. The startup module 4520 can activate the management module to detect, manage, analyze, and limit network traffic corresponding to the network transmission of user data.

[0241] The management module is configured to analyze network traffic at different layers of network transmission based on the type of network traffic corresponding to the network transmission; and based on the analysis indicating that the network traffic meets the data exchange constraints corresponding to the target user, send the network traffic to the server defined by the data exchange constraints.

[0242] In some implementations, the management module may include a submodule (also referred to as a first management module) 4210, a submodule (also referred to as a second management module) 4310, and a submodule (also referred to as a third management module) 4410. Submodules 4210, 4310, and 4410 may analyze and limit network traffic of client applications.

[0243] In some implementations, the submodule 4210 is configured to analyze the network traffic at a network layer based on the type of the network traffic being native type of network traffic.

[0244] In some implementations, the submodule 4310 is configured to transfer the web view type network traffic to the network interface of the client application to be managed by the native network module of the client application based on the type of the network traffic being web view type network traffic; and to analyze the transferred network traffic at the network layer.

[0245] In some implementations, diverting the web view type of network traffic to the network interface of the mobile application includes: utilizing a JavaScript hook mechanism to divert the web view type of network traffic.

[0246] In some implementations, the submodule 4410 is configured to analyze the network traffic at the application programming interface (API) layer based on the type of the network traffic being third-party SDK type network traffic.

[0247] In some implementations, analyzing the network traffic at the API layer includes: determining a wrapper API by adding judgment logic based on the data exchange constraint to an API of a third-party SDK; and calling the wrapper API to analyze the network traffic using the judgment logic.

[0248] In some implementations, initiation module 4520 may activate submodules 4210, 4310, and 4410 based on the determination of the target user. For example, initiation module 4520 may determine whether the current user is the target user during user registration. If the determination is yes, initiation module 4520 may activate submodules 4210, 4310, and 4410. For another example, initiation module 4520 may obtain the determination result of the user from a local computer or a server when the user logs in, and determine whether to activate submodules 4210, 4310, and 4410 based on the determination result.

[0249] The security sandbox system 1090 may further include a sampling module 4510 for sampling network traffic. In some implementations, the sampling module 4510 may send a sampling signal to the initiation module 4520 to trigger the initiation module 4520. The sampling signal may indicate a sampling rate for sampling network traffic.

[0250] Sampling module 4510 can sample target users and different types of network traffic based on data exchange constraints. For example, sampling module 4510 can sample different types of network traffic at different sampling rates. Using sampling module 4510, only a portion of the network traffic can be analyzed, thereby reducing overhead and maintaining application stability.

[0251] It should be understood that the security sandbox system 1090 may also include other modules, or may only include Figure 4E For example, when the target application 1080 is only a native application on a mobile terminal, the security sandbox system 1090 may not include the submodule 4310 for network traffic of the web view type. The scope of the present disclosure is not limited to this.

[0252] In some implementations, network traffic can be analyzed and restricted at the socket layer based on the type of network traffic. For example, third-party SDK network traffic can be forwarded at the socket layer so that third-party SDK network requests can be directly analyzed. Alternatively or additionally, native network traffic and web view network traffic can also be analyzed and restricted at the socket layer.

[0253] In some implementations, a local server acting as a proxy can also be established on the target application 1080. By forwarding network requests from the target application 1080 to the local server and analyzing and limiting network traffic on the local server, network requests forwarded by the local server to external servers can be managed. In this way, different types of network traffic can be analyzed and limited while taking into account protocol information, thereby better managing the application's network traffic and preventing it from being transmitted to unauthorized external servers.

[0254] References Figures 4B to 4E The principles and details of analyzing and restricting different types of network traffic are described in detail. It should be understood that the above-mentioned restriction rules, judgment logic, and data exchange constraints are merely exemplary and do not limit the scope of this disclosure. For example, different data sovereignty protection rules can be set according to the laws and regulations of different countries. In addition, depending on the definition of the layers of the computer network, network traffic can be analyzed and restricted at layers close to or similar to the above-mentioned layers.

[0255] Furthermore, in the above description, the security sandbox system 1090 can directly analyze and restrict the network traffic in the target application 1080. In other words, only network traffic that is not restricted by the security sandbox system 1090 can continue to be transmitted. Alternatively or additionally, the security sandbox system 1090 may not directly restrict network traffic, but may only provide an analysis report. In this case, a copy of the network request can be sent to the security sandbox system 1090 while the network request is being transmitted normally. The security sandbox system 1090 can analyze the copy of the network request and provide an analysis report.

[0256] In some implementations, multiple security sandbox systems 1090 may be configured to handle data sovereignty issues in different countries. For example, based on the region of the target user, a corresponding security sandbox system may be activated to analyze and restrict network traffic, ensuring that network transmission of user data in the application complies with the data sovereignty protection rules of the corresponding country.

[0257] Recommendation management subsystem

[0258] As discussed above, target applications can, for example, use recommendation mechanisms to provide users with various content recommendations, such as multimedia content recommendations, user recommendations, and product recommendations. In such applications, the fairness of recommendation policies has become a key management priority in many regions. For example, some applications may use recommendation mechanisms to guide users to specific content that is unrelated to their habits, potentially making such recommendation mechanisms non-compliant.

[0259] On the other hand, typical recommendation algorithms often rely on machine learning models for implementation, and code-level verification, such as that performed by the secure computing subsystem 1060, may not be able to effectively detect the fairness of recommendation algorithms. Furthermore, the training and updating of recommendation models are often closely related to actual user data, and people do not want to expose user privacy data during the verification process, as this may pose a risk to data compliance.

[0260] The embodiments of the present disclosure further propose a solution for managing recommendation strategies. Figure 5 A flow chart of a process 500 for managing a recommendation strategy is shown. The process 500 may be performed by the recommendation management subsystem 1050, for example.

[0261] like Figure 5 As shown, in box 502, the recommendation management subsystem 1050 obtains a set of object features associated with a set of objects in the target application, wherein the set of object features is converted based on the attributes of the set of objects, and the set of object features does not directly express the attributes of the set of objects.

[0262] In some embodiments, the recommendation management subsystem 1050 may obtain the set of object features via an application programming interface (API) provided by the target application. In some embodiments, the recommendation management subsystem 1050 may obtain a set of object features associated with a set of objects in the target application 1080 from the target application platform 1030 via a dedicated API, for example.

[0263] In some embodiments, the set of object features can be, for example, converted by a feature extraction model based on the attributes of the set of objects. This approach prevents the administrator of the recommendation policy or other third parties from determining the original attribute information of the objects based on the object features. This ensures the security of data in the target application.

[0264] At block 504 , the recommendation management subsystem 1050 determines a first object feature and a second object feature from a set of object features, wherein a first difference between the first object feature and the second object feature is less than a first threshold.

[0265] In some embodiments, the set of object features may be represented as multiple vectors. Furthermore, the recommendation management subsystem 1050 may select at least one pair of object features whose difference is less than a first threshold from the set of object features based on the difference between the vectors.

[0266] In block 506 , the recommendation management subsystem 1050 determines a first recommendation result corresponding to the first object feature and a second recommendation result corresponding to the second object feature based on the recommendation strategy in the target application.

[0267] In some embodiments, the recommendation management subsystem 1050 may provide the first object feature to a recommendation model associated with the recommendation strategy to determine a first recommendation result, and provide the second object feature to the recommendation model to determine a second recommendation result.

[0268] In some embodiments, to ensure the security of the recommendation strategy, the recommendation management subsystem 1050 can send the selected first and second object features to a remotely running recommendation model via an API provided by the target application to determine the first and second recommendation results. For example, the recommendation model can be run by the maintainer of the target application.

[0269] In some embodiments, the process of generating the first recommendation result and the second recommendation result will not affect the recommendation model actually deployed in the target application.

[0270] In some embodiments, the first and second recommendation results can be vector representations output by the recommendation model. As a result, the recommendation management subsystem 1050 cannot directly interpret the semantics of the first and second recommendation results, thereby further improving the security of the data within the target application.

[0271] At block 508 , the recommendation management subsystem 1050 evaluates a recommendation strategy based on the first recommendation result and the second recommendation result.

[0272] In some embodiments, the recommendation management subsystem 1050 may determine a second difference between the first recommendation result and the second recommendation result, and determine the fairness of the recommendation strategy based on a comparison between the second difference and a second threshold.

[0273] Specifically, for a reasonable recommendation strategy, the recommendation results for two similar objects should be similar. Therefore, if the recommendation management subsystem 1050 determines that the second difference exceeds the second threshold, it can be determined that the recommendation strategy has poor fairness.

[0274] Alternatively, the recommendation management subsystem 1050 may determine the fairness of the recommendation strategy based on, for example, the proportion of object feature pairs whose second difference exceeds a second threshold. For example, the recommendation management subsystem 1050 may randomly sample multiple sets of object feature pairs and determine that the recommendation strategy has poor fairness if the proportion of object feature pairs whose second difference exceeds the second threshold exceeds a threshold proportion.

[0275] In some embodiments, the recommendation management subsystem 1050 may also determine the fairness of the recommendation strategy based on the correlation between the object features used to input into the recommendation model and the historical recommendation results. Specifically, the recommendation management subsystem 1050 may also obtain a third object feature and historical recommendation results for the third object feature from the target application. Further, the recommendation management subsystem 1050 may determine the fairness of the recommendation strategy based on the correlation between the third object feature and the historical recommendation results. For example, the recommendation management subsystem 1050 may determine whether the object feature matches the category information of the historical recommendation results.

[0276] In some embodiments, the recommendation management subsystem 1050 may determine a vector representation corresponding to the third object feature and the historical recommendation results, and determine the correlation between the third object feature and the historical recommendation results based on the difference between the two vector representations. For example, if the difference between the vector representation of an object and its historical recommendation results is greater than a threshold, the recommendation management subsystem 1050 may determine that the recommendation strategy has poor fairness.

[0277] In some embodiments, as mentioned above, the secure computing subsystem 1060 may also examine the source code associated with the recommended policy. Specifically, the secure computing subsystem 1060 may obtain the source code corresponding to the recommended policy and evaluate the recommended policy based on the source code or intermediate code corresponding to the source code.

[0278] In some embodiments, the recommendation strategy may be used to recommend at least one multimedia content to a user in the target application 1080. Examples of multimedia content may include images, videos, music, or a combination thereof.

[0279] Example devices and equipment

[0280] The embodiments of the present disclosure also provide corresponding devices for implementing the above methods or processes. Figure 6 An example block diagram of an apparatus 600 for data exchange according to some embodiments of the present disclosure is shown.

[0281] like Figure 6 As shown, apparatus 600 includes an acquisition module 610 configured to acquire raw data to be exchanged between a first platform and a second platform by a target application. Apparatus 600 also includes a preprocessing module 620 configured to process the raw data based on its type to obtain uniformly formatted data corresponding to the type. Apparatus 600 also includes a constraint satisfaction determination module 630 configured to determine satisfaction of data exchange constraints from the uniformly formatted data.

[0282] In some embodiments, the first platform is a target application platform under the jurisdiction of a specific country or region, and the second platform is a target application platform under the jurisdiction of another country or region.

[0283] In some embodiments, the apparatus 600 further includes: a conversion module configured to convert the unified formatted data into original data if it is determined that the unified formatted data satisfies the data exchange constraint; and an interaction execution module configured to execute the exchange of original data between the first platform and the second platform.

[0284] In some embodiments, the type of the original data is selected from the group consisting of: a message queue (MQ) type, an offline aggregate data type, a target object store (TOS) type, and a service call type.

[0285] In some embodiments, the preprocessing module 620 is configured to: detect the format of the original data, where the data type includes multiple formats; and convert the format of the original data into a specified format among the multiple data formats through format conversion to obtain uniformly formatted data.

[0286] In some embodiments, multiple data channels corresponding to multiple types of raw data are created between the first platform and the second platform. In some embodiments, the pre-processing module 620 is configured to: select a data channel corresponding to the type of raw data from the multiple data channels based on the type of the raw data; and provide the raw data to the selected data channel for processing.

[0287] In some embodiments, the data exchange constraints include a specific type of data exchange constraint associated with the type of the original data, and the specific type of data exchange constraint is registered in the selected data channel. In some embodiments, the constraint satisfaction determination module 630 is configured to determine satisfaction of the specific type of data exchange constraint from the uniformly formatted data in the selected data channel.

[0288] In some embodiments, the apparatus 600 further includes: a channel creation module configured to, if a new type of original data is to be exchanged between the first platform and the second platform, create another data channel between the first platform and the second platform corresponding to the new type of original data, and a constraint registration module configured to register a specific type of data exchange constraint associated with the new type in the other data channel.

[0289] In some embodiments, the pre-processing module 620 is implemented and executed in a first data center, the constraint satisfaction determination module 630 is implemented and executed in a second data center, and the conversion module is implemented in a third data center. In some embodiments, the first data center and the third data center do not have a direct communication connection, and the first data center and the second data center each have a direct communication connection with the second data center.

[0290] In some embodiments, the first data center, the second data center, and the third data center are respectively implemented by virtual private data centers (VPCs).

[0291] Figure 7 Shown is a schematic block diagram of an example device 700 that can be used to implement an embodiment of the present disclosure. For example, system 100 and / or system 400 according to an embodiment of the present disclosure can be implemented by device 700. As shown in the figure, device 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to the computer program instructions stored in a read-only memory (ROM) 702 or the computer program instructions loaded into a random access memory (RAM) 703 from a storage unit 708. In RAM 703, various programs and data required for the operation of device 700 can also be stored. CPU 701, ROM 702 and RAM 703 are connected to each other by bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0292] Various components in device 700 are connected to I / O interface 705, including an input unit 706, such as a keyboard, mouse, etc.; an output unit 707, such as various types of displays, speakers, etc.; a storage unit 708, such as a magnetic disk, optical disk, etc.; and a communication unit 709, such as a network card, modem, wireless communication transceiver, etc. The communication unit 709 allows device 700 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0293] The various processes and processing described above, such as process 500, may be performed by processing unit 701. For example, in some embodiments, process 500 may be implemented as a computer software program that is tangibly embodied in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed onto device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by CPU 701, one or more actions of process 500 described above may be performed.

[0294] The present disclosure may be a method, an apparatus, a system and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for executing various aspects of the present disclosure.

[0295] Computer-readable storage medium can be a tangible device that can keep and store the instructions used by the instruction execution device.Computer-readable storage medium can be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device or any suitable combination thereof.More specific examples (non-exhaustive list) of computer-readable storage medium include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, for example, a punch card or a convex structure in a groove having instructions stored thereon, and any suitable combination thereof.Computer-readable storage medium used herein is not interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (for example, light pulses by fiber optic cables), or electrical signals transmitted by wires.

[0296] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in the computer-readable storage medium in each computing / processing device.

[0297] The computer program instructions for performing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, and conventional procedural programming languages such as "C" language or similar programming languages. Computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., utilizing an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be personalized by utilizing the state information of the computer-readable program instructions. The electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present disclosure.

[0298] Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0299] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine such that when these instructions are executed by the processing unit of the computer or other programmable data processing device, a device is generated that implements the functions / actions specified in one or more blocks in the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0300] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operational steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0301] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems, methods and computer program products according to multiple embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and the part of the module, program segment or instruction contains one or more executable instructions for realizing the prescribed logical function. In some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the prescribed function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0302] The embodiments of the present disclosure have been described above. The above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons skilled in the art to understand the embodiments disclosed herein.

Claims

1. A data exchange method, comprising: Acquire original data to be exchanged between the first platform and the second platform by the target application; Processing the raw data based on a type of the raw data to obtain uniformly formatted data corresponding to the type, wherein a plurality of data channels corresponding to the plurality of types of raw data are created between the first platform and the second platform, and processing the raw data includes: Based on the type of the original data, selecting a data channel corresponding to the type from the plurality of data channels; and providing the raw data to the selected data channel for processing; and determining satisfaction of data exchange constraints from the uniformly formatted data, wherein the data exchange constraints include data exchange constraints of a specific type associated with the type of the raw data, the data exchange constraints of the specific type being registered in the selected data channel.

2. The method according to claim 1, wherein the first platform is a target application platform under the jurisdiction of a specific country or region, and the second platform is a target application platform under the jurisdiction of another country or region.

3. The method according to claim 1, further comprising: If it is determined that the unified formatted data satisfies the data exchange constraint, converting the unified formatted data into the original data; as well as The original data is exchanged between the first platform and the second platform.

4. The method according to claim 1, wherein the type of the original data is selected from the group consisting of: a message queue (MQ) type, an offline aggregate data type, a target object store (TOS) type, and a service call type.

5. The method of claim 1 , wherein processing the raw data comprises: detecting a format of the original data, where the data type includes multiple formats; as well as The format of the original data is converted into a specified format among the multiple data formats through format conversion to obtain the unified formatted data.

6. The method of claim 1 , wherein determining satisfaction of a data exchange constraint comprises: In the selected data channel, satisfaction of the data exchange constraint of the specific type is determined from the uniformly formatted data.

7. The method according to claim 1, further comprising: If a new type of raw data is to be exchanged between the first platform and the second platform, another data channel corresponding to the new type of raw data is created between the first platform and the second platform; as well as A data exchange constraint of a specific type associated with the new type is registered in the other data channel.

8. The method of claim 3, wherein the processing of the raw data is performed in a first data center, the determination of satisfaction of the data exchange constraint is performed in a second data center, and the conversion of the uniformly formatted data into the raw data is performed in a third data center. The first data center has no direct communication connection with the third data center, and the first data center and the second data center have direct communication connections with the second data center respectively. 9 . The method according to claim 8 , wherein the first data center, the second data center, and the third data center are respectively implemented by virtual private data centers (VPCs).

10. A data exchange system comprising: a first data center configured to acquire raw data to be exchanged between a first target application platform and a second external platform of the target application, and process the raw data based on a type of the raw data to obtain uniformly formatted data corresponding to the type, wherein the data exchange system is divided into a plurality of data channels corresponding to a plurality of data types, respectively, and an exchange of data of a corresponding type is performed in each data channel, and wherein the first data center is configured to process the raw data by: selecting a data channel corresponding to the type from the plurality of data channels based on the type of the raw data, and providing the raw data to the selected data channel for processing; as well as The second data center is configured to obtain the unified formatted data from the first data center and determine satisfaction of data exchange constraints based on the unified formatted data, wherein the data exchange constraints include a specific type of data exchange constraints associated with the type of the original data, and the specific type of data exchange constraints is registered in the selected data channel.

11. The data exchange system according to claim 10, further comprising a third data center, If the second data center determines that the unified formatted data satisfies the data exchange constraint, the unified formatted data is provided to the third data center. The third data center is configured to convert the uniformly formatted data into the original data; and execute exchange of the original data between the first platform and the second platform. 12 . The data exchange system according to claim 11 , wherein the first data center has no direct communication connection with the third data center, and the first data center and the second data center each have a direct communication connection with the second data center. 13 . The data exchange system according to claim 11 , wherein the first data center, the second data center, and the third data center are respectively implemented by virtual private data centers (VPCs).

14. A device for data exchange, comprising: an acquisition module, configured to acquire original data to be exchanged between the first platform and the second platform by the target application; a preprocessing module configured to process the raw data based on a type of the raw data to obtain uniformly formatted data corresponding to the type, wherein a plurality of data channels corresponding to the plurality of types of raw data are respectively created between the first platform and the second platform, and the preprocessing module is further configured to: Based on the type of the original data, selecting a data channel corresponding to the type from the multiple data channels; as well as Providing the raw data to the selected data channel for processing; and a constraint satisfaction determination module configured to determine satisfaction of data exchange constraints from the uniformly formatted data, wherein the data exchange constraints include a specific type of data exchange constraints associated with the type of the original data, and the specific type of data exchange constraints is registered in the selected data channel.

15. An electronic device comprising: memory and processor; The memory is configured to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method according to any one of claims 1 to 9. 16 . A computer-readable storage medium having one or more computer instructions stored thereon, wherein the one or more computer instructions are executed by a processor to implement the method according to claim 1 .

17. A computer program product comprising one or more computer instructions, wherein the one or more computer instructions are executed by a processor to implement the method according to any one of claims 1 to 9.

Images