Data processing method, apparatus, and computer-readable storage medium

Abstract

The application discloses a data processing method, device and computer readable storage medium, which can be applied to cloud technology and the like. Specifically, the data processing method can obtain business logic data of a target account in a target application; the business logic data is classified and processed to obtain classified business type data; a signature certificate of the target account is read, the signature certificate is obtained after a local terminal registers data signature authority to a server, and contains data signature authority of the target account in the local terminal; the business type data is signed according to the data signature authority in the signature certificate to obtain target logic data carrying target signature information; and the target logic data is uploaded to the server for storage. In this way, the data generated by the application program can be managed specifically, the willingness of a target object is met, the application business data used subsequently meets the demand of the target object, the safety and efficiency of data processing are ensured, and user experience is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically to a data processing method, apparatus, and computer-readable storage medium. Background Technology

[0002] An application (APP), as a functional program unit, carries corresponding business logic, enabling the business functions of various platforms to run on terminal devices. Data generated during application runtime can be used for subsequent business scenarios, such as feature mining and recommendation. To ensure the application's data can be used later, related technologies manage the data generated by the application, such as actively transmitting the application's data to a server, allowing the server to associate the data with the running application account for later use.

[0003] In the process of researching and practicing existing technologies, the inventors of this application discovered that when managing data generated by applications, existing technologies transmit all data generated by applications to servers for storage. This results in the management of application data deviating from the user's intentions, making the historical data of subsequent applications untargetable, difficult to quickly find the required business type of data, affecting the user experience, and having poor data processing security and efficiency. Summary of the Invention

[0004] This application provides a data processing method, apparatus, and computer-readable storage medium that can selectively manage data generated by applications so that the application business data used subsequently meets the needs of the target object, ensuring the security and efficiency of data processing and improving user experience.

[0005] This application provides a data processing method, including:

[0006] Obtain the business logic data of the target account in the target application;

[0007] The business logic data is categorized to obtain categorized business type data;

[0008] Read the signature certificate of the target account. The signature certificate is obtained by the local terminal after registering data signature permissions with the server. The signature certificate contains the data signature permissions of the target account on the local terminal.

[0009] According to the data signing permissions in the signature certificate, the business type data is signed to obtain target logical data carrying target signature information;

[0010] The target logical data is uploaded to the server for storage.

[0011] Accordingly, embodiments of this application provide a data processing apparatus, including:

[0012] The acquisition unit is used to acquire the business logic data of the target account in the target application.

[0013] The classification unit is used to classify the business logic data to obtain the classified business type data.

[0014] The reading unit is used to read the signature certificate of the target account. The signature certificate is obtained by the local terminal after registering data signature permissions with the server. The signature certificate contains the data signature permissions of the target account on the local terminal.

[0015] The signature unit is used to sign the business type data according to the data signature permissions in the signature certificate to obtain target logical data carrying target signature information.

[0016] The processing unit is used to upload the target logical data to the server for storage.

[0017] In some embodiments, the classification unit is further configured to:

[0018] Create abstract data corresponding to the business logic data;

[0019] Extract the target field corresponding to the business logic data from the abstract data, and assign a value to the target field according to the business logic data to obtain the target field value;

[0020] The business logic data is categorized based on the target field value to obtain categorized business type data.

[0021] In some embodiments, the signature unit is further configured to:

[0022] Based on the data signing permissions in the signing certificate, a signing permission list is determined, and the signing permission list contains the association between preset business types and signing permissions;

[0023] Determine the target business type corresponding to the business type data, and match the target business type with the signature permission list;

[0024] If a preset business type corresponding to the target business type is matched, the business type data is signed according to the signature permission associated with the preset business type to obtain target logical data carrying the target signature information.

[0025] In some implementations, the signing unit is further configured to: if no preset business type corresponding to the target business type is matched, stop signing the business type data and determine the business type data that has stopped signing as unsigned data;

[0026] The processing unit is further configured to: intercept the unsigned data uploaded to the server, and delete the intercepted unsigned data.

[0027] In some embodiments, the data processing apparatus further includes a registration unit for:

[0028] Identify the target account logged into the target application;

[0029] Request the server to register the data signature permission corresponding to the target account;

[0030] If the server returns a signature certificate corresponding to the data signature permission, the signature certificate is stored in the storage space associated with the target account on the local terminal.

[0031] In some embodiments, the registration unit is further configured to:

[0032] Request the data signature policy from the server;

[0033] Obtain historical business logic data selected for the target account in the target application, and sign the historical business logic data according to the data signature policy to obtain signature information;

[0034] The signature information is sent to the server, so that the server registers the data signature permission for the target account based on the signature information.

[0035] In some embodiments, the registration unit is further configured to:

[0036] Generate the account key corresponding to the target account according to the data signature strategy;

[0037] The historical business logic data is signed using the account key to obtain signature information.

[0038] In some embodiments, the data processing apparatus further includes an update unit for:

[0039] Identify the device permission type of the local terminal;

[0040] If the device permission type of the local terminal is detected to be primary device permission, a pre-set secondary device permission list is obtained, and when a secondary device identifier is detected in the secondary device permission list, the permission relationship of the signature information is updated according to the secondary device identifier to obtain the updated signature information;

[0041] The registration unit is also used to send the updated signature information to the server.

[0042] In some embodiments, the data processing apparatus further includes an identification unit for:

[0043] Obtain the data transmission queue corresponding to the target application in the local terminal;

[0044] Identify the number of data tasks to be executed in the data transmission queue;

[0045] The processing unit is further configured to upload the target logical data to the server for storage if it is found that the number of data tasks is less than a preset task number threshold.

[0046] In some embodiments, the data processing apparatus further includes a detection unit for:

[0047] Detect the business operation process of the target application;

[0048] Determine the current business operation logic timing of the target application based on the business operation process;

[0049] The acquisition unit is used to acquire the business logic data of the target account in the target application if it detects that the business operation logic time point has reached the preset data upload time point.

[0050] In some embodiments, the data processing apparatus further includes a data merging unit for:

[0051] If a startup request for the target application is detected, the target application is launched, and the running process of the launched target application is identified.

[0052] If the running process is detected to have reached a preset running process time point, the value of the attribution field in the real-time business logic data corresponding to the running process is obtained, and the server is requested to obtain the historical business logic data corresponding to the attribution field value.

[0053] If the historical business logic data and the real-time business logic data are found to have the same business type, the historical business logic data and the real-time business logic data are merged, and the merged target business logic data is displayed.

[0054] In some embodiments, the data processing apparatus further includes a push unit for:

[0055] If a startup request for the target application is detected, a business prompt request carrying the target account is sent to the server, so that the server determines the logical data to be pushed based on the data upload records of the target account on the local terminal.

[0056] If the server returns the logic data to be pushed, the target application is launched, and the business prompt label corresponding to the logic data to be pushed is displayed in the target application interface after launch.

[0057] Furthermore, embodiments of this application also provide a computer device, including a processor and a memory, wherein the memory stores a computer program, and the processor is used to run the computer program in the memory to implement the steps in any of the data processing methods provided in embodiments of this application.

[0058] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute steps in any of the data processing methods provided in embodiments of this application.

[0059] Furthermore, embodiments of this application also provide a computer program product, including computer instructions, which, when executed, implement the steps in any data processing method provided in embodiments of this application.

[0060] This application embodiment can acquire business logic data of a target account in a target application; classify the business logic data to obtain classified business type data; read the target account's signature certificate, which is obtained after the local terminal registers data signature permissions with the server, and the signature certificate contains the target account's data signature permissions on the local terminal; sign the business type data according to the data signature permissions in the signature certificate to obtain target logic data carrying target signature information; and upload the target logic data to the server for storage. Therefore, this solution can acquire business logic data generated by the target application during runtime, classify the business logic data to determine its business type; furthermore, it signs the classified business type data according to the data signature permissions in the target account's signature certificate, and determine the processing strategy for the business type data based on the signature, such as performing data upload after successful signing, thereby improving the security and efficiency of data processing. Thus, business data can be processed according to the target object's wishes to manage application-generated data in a targeted manner, ensuring that subsequent application business data meets user needs and improves user experience. Attached Figure Description

[0061] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0062] Figure 1 This is a schematic diagram of a data processing system provided in an embodiment of this application;

[0063] Figure 2 This is a flowchart illustrating the steps of the data processing method provided in the embodiments of this application;

[0064] Figure 3 This is a schematic flowchart of another step of the data processing method provided in the embodiments of this application;

[0065] Figure 4 This is a schematic diagram of the interface used by multiple terminals in the data processing method provided in the embodiments of this application;

[0066] Figure 5 A schematic diagram of the interface for device information management in the data processing method provided in the application embodiment;

[0067] Figure 6 A schematic diagram illustrating a scenario of registering data signature permissions in the data processing method provided in the application embodiment;

[0068] Figure 7 A block flowchart illustrating the data processing method provided in the embodiments of this application;

[0069] Figure 8 This is a schematic diagram of the structure of the data processing apparatus provided in the embodiments of this application;

[0070] Figure 9 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0071] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0072] This application provides a data processing method, apparatus, and computer-readable storage medium. Specifically, this application will describe the data processing apparatus from the perspective of the data processing apparatus, which can be integrated into a computer device, such as a server or a terminal. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, smart home appliance, vehicle terminal, smart voice interaction device, aircraft, etc., but is not limited to these.

[0073] It should be noted that, in the specific embodiments of this application, data related to user information, user behavior, business habits, and characteristics are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. Furthermore, in the embodiments of this application, the object data and business data related to the account are mainly applied to the operation of business functions related to that account within the application, falling within the scope of the operation of those business functions. The application of this related data is authorized by the user and complies with user privacy protection requirements.

[0074] The data processing method provided in this application can be applied to various scenarios, including but not limited to data processing scenarios such as cloud technology, artificial intelligence, smart transportation, and assisted driving. These scenarios are not limited to those implemented through cloud services, big data, etc., and are specifically illustrated through the following embodiments:

[0075] For example, see Figure 1 This is a schematic diagram of a data processing system provided in an embodiment of this application. The scenario includes a terminal and a server.

[0076] The terminal can obtain the business logic data of the target account in the target application; classify the business logic data to obtain the classified business type data; read the signature certificate of the target account, which is obtained by the local terminal after registering data signature permissions with the server, and the signature certificate contains the data signature permissions of the target account on the local terminal; sign the business type data according to the data signature permissions in the signature certificate to obtain the target logic data carrying the target signature information; and upload the target logic data to the server for storage.

[0077] The server can receive a request from the terminal to register data signing permissions for the target account in the target application, and complete the registration of data signing permissions for the target account in the target application; then, when it receives the target logical data signed by the target account in the target application sent by the terminal, it verifies the target signature information in the signed target logical data, and stores the target type data after the verification is successful.

[0078] Data processing can include: acquiring business logic data, classifying data, reading signature certificates, signing data, determining data processing strategies, and processing data in various ways.

[0079] The following sections provide detailed descriptions of each example. It should be noted that the order of the following embodiments is not intended to limit the preferred order of the embodiments.

[0080] In this embodiment, the description will be from the perspective of a data processing device, which can be specifically integrated into a computer device such as a terminal or server. See also Figure 2 , Figure 2 This is a flowchart illustrating the steps of a data processing method provided in an embodiment of this application. Taking an example where the data processing device is specifically integrated into a terminal, the specific process when the processor on the terminal executes the program instructions corresponding to the data processing method is as follows:

[0081] 101. Obtain the business logic data of the target account in the target application.

[0082] The target application can be a business-functional application / client installed on the local terminal, capable of interacting with other clients / servers. For example, taking a mobile phone as the local terminal, the target application could be a video application, map application, music application, shopping application, etc., installed on the phone. These are just examples; the target application can be any application.

[0083] The target account can be an account information that the target object has pre-registered with the server. This account information can be used to log in and use on clients of different terminal devices, as well as on different clients under the same terminal device, such as application clients or web clients. In other words, the target account can meet the scenarios of multiple people using it at the same time or in segments.

[0084] Specifically, this business logic data can be specific data generated within the application, providing access to related function calls for business data management. More specifically, this business logic data is essentially object data, specifically application data of the target object when requesting the execution of related business functions. It can influence the calling and execution of related functions during the operation of the business function program. For example, taking a video application as an example, according to business type, the types of business logic data are not limited to, including but not limited to, object data such as video playback records, playlist records, favorites records, and behavior logs.

[0085] For ease of understanding, the embodiments of this application describe business data and business logic data separately, as follows:

[0086] Business data refers to the data presented on the application interface after the relevant business functions in the application are running. Specifically, it is the representation of the business logic data of the relevant business functions in the display interface, that is, business data is business information. For example, taking a video application as the target application, the video application may include, but is not limited to, business function options such as video playback history, video favorites, and playlists. Then, the business data corresponding to the video playback history function can be the video playback name displayed / represented in the application interface as the logical data of the video playback history. Similarly, the business data corresponding to the video favorites function is the video favorite name displayed / represented in the application interface as the logical data of the video favorites.

[0087] This business logic data can be the logical data generated by the target application when executing / running program functions. It represents the underlying business logic of the relevant program function options in the target application and is used to influence the execution of related business logic. For example, taking the application's business guidance scenario as an example, when the target object opens the target application or runs a certain business function program within the application, the business logic data that can be guided can be determined based on the current process environment of the target application (such as business data, business logic data, external application data, etc.), and the guideable business logic data is presented in the application interface, such as displaying the business push label or business prompt label corresponding to the guideable business logic data in the application interface; then, when the target object selects the business prompt label in the application interface, the current process environment of the target application is switched to the situation corresponding to the business prompt label, such as stopping the execution of the current process's business logic data and executing the business logic data corresponding to the business prompt label.

[0088] It should be noted that the storage location of this business logic data can be a server. For example, the business logic data generated by the target application can be stored on the server corresponding to the target application for subsequent use. These subsequent uses may include, but are not limited to, feature mining and preference information recommendation of the target account within the target application, primarily based on the target object's authorization and preferences. However, when the target object uses the business program functions of the target application, for usage records under the same business program function, the target object may wish to store only a portion of the data, such as storing business logic data of the same type. For example, taking a video application as an example, the target object plays both regular long videos and short videos in the video application, but only wants to store the playback records of the regular long videos on the server, and not the playback records of the short videos. In this case, it is necessary to manage the business logic data corresponding to the video playback records, such as storing the business logic data for the regular long videos during playback and deleting the business logic data for the short videos during playback, so that the future needs of the target object can be met at the data application level.

[0089] In order to manage the business logic data corresponding to the target account in the target application, this embodiment of the application needs to obtain the data generated by the target application during runtime. Specifically, taking the data processing device integrated into a local terminal as an example, when the local terminal starts and runs the relevant business function program built into the target application, the target application will generate relevant business logic data. The local terminal needs to obtain the business logic data about the target account in the target application so that it can manage the business logic data according to the target object's wishes in the future.

[0090] In some implementations, business logic data can be uploaded in real time when managing it. However, the data upload process may affect the performance of the target application's current business functions and the user experience. Therefore, this application embodiment can also manage the business logic data generated by the target application by setting an appropriate time, such as acquiring the business logic data at an appropriate time. Specifically, before the step "acquiring the business logic data of the target account in the target application", the process may include: detecting the business operation process of the target application; determining the current business operation logic time point of the target application based on the business operation process; then the step "acquiring the business logic data of the target account in the target application" may include: if the business operation logic time point is detected to have reached a preset data upload time point, then acquiring the business logic data of the target account in the target application.

[0091] The business operation process can be the execution entity of the relevant business function program in the target application. The business operation process can reflect the running progress or running time of the business function program, and specifically it can represent the progress of the business operation logic of the business function program.

[0092] The business operation logic timing point can be the logical progress timing point when the local terminal is running the relevant business function program, which can reflect the running progress of the business function. For example, taking a music application as an example, the target object can generate the business operation logic of the music application's playback business function by pre-creating a music playlist to be played and setting the automatic playback time, stop playback time, pause playback mode, etc. of the music playlist. Such logic is as follows: "Identify time - play when time is up (automatic playback time) - pause playback and resume playback in other scenarios (pause playback mode) - stop playback (stop playback time)". From the above, it can be seen that "play when time is up", "pause playback in other scenarios", "resume playback" and "stop playback" can all be regarded as a business operation logic timing point. The above is only an example, and the embodiments of this application do not limit the business operation logic timing point.

[0093] The preset data upload time point can be the logical time point at which business logic data is uploaded to the server for storage. By presetting this logical data upload time point, the upload time of business logic data can be limited. For example, taking video or image applications as an example, when a target object captures video frames during video playback or saves images from an image application, after detecting that the relevant image has been saved to the local album, the logical time point at which the image is saved to the local album is set as a preset data upload time point. This allows the target object to obtain the application's business logic data when saving images from the application later, in order to execute the subsequent preparation upload process. It should be noted that the above is only an example and the embodiments of this application are not limited; furthermore, the data upload time points between different business function programs in the same application may be inconsistent, that is, the preset data upload time point can be set according to actual needs.

[0094] To manage the business logic data of a target application, this embodiment detects the business operation process of the target application. Specifically, it identifies the currently running business function program in the target application and locates the corresponding business operation process, such as by searching for the corresponding business operation process in the target application based on the identifier of the business function program. Then, it determines the business operation logic time point of the target application (specifically, the business function program) based on the business operation process. Furthermore, it compares the determined business operation logic time point with a preset data upload time point, and when the business operation logic time point is detected to have reached (or met) the preset data upload time point, it acquires the business logic data of the target account within the target application. Specifically, this can also be the business logic data of the target account while running the target business function program. In this way, the running progress of the currently running business function program in the target application can be known, and the business logic data can be acquired when the business operation process reaches a preset time point, facilitating subsequent management of the acquired data.

[0095] By using the above methods, when business logic data generated by the target application for the target account is detected, the business logic data can be obtained, so as to facilitate the subsequent management of the business logic data corresponding to the target account in the target application.

[0096] 102. Classify the business logic data to obtain the classified business type data.

[0097] Here, "business type data" refers to the categorized business logic data. Specifically, the target application may include multiple business function programs or various business type programs. Each business function program or business type program corresponds to a specific business type, meaning the business logic data differs between programs of different business types. For example, taking a video application as an example, business logic data can be categorized according to the account's membership type. Since different membership types may correspond to different business logics—for instance, a member account can adjust video playback progress, watch videos earlier, and adjust resolution—business logic data can be categorized based on membership type. Furthermore, it can be categorized according to video type. For example, when a target account watches videos, it may include business logic data for watching regular long videos (such as movies, individual episodes of TV series, etc.) and short videos (videos with shorter durations). Since the current short video business operates on a push-based model, which is not deterministic and cannot represent the target audience's interest in the pushed short videos, the relevant business logic data can be categorized based on video type when managing the data.

[0098] It should be noted that, after obtaining the business logic data of the target application for the target account, this embodiment of the application needs to classify the business logic data in order to facilitate subsequent signing and related processing of the classified data, thereby realizing the management of the business logic data.

[0099] In some implementations, during the classification process of business logic data, the business type corresponding to the business logic data can be determined based on relevant values ​​in the business logic data. For example, the step "classify the business logic data to obtain classified business type data" may include: creating abstract data corresponding to the business logic data; extracting the target field corresponding to the business logic data from the abstract data, and assigning values ​​to the target field according to the business logic data to obtain the target field value; classifying the business logic data according to the target field value to obtain the classified business type data.

[0100] Here, the abstract data refers to the abstract class data (baseData) corresponding to the business logic data. It can contain various category fields corresponding to the relevant data or values ​​in the business logic data. These fields can be understood as the attribute categories of the relevant values ​​in the business logic data, used to label or interpret the relevant values ​​in the business logic data. For example, assuming the business logic data includes business type values, data type values, application backend identifiers, etc., the created abstract data can include fields for business type, data type, and application backend identifiers, etc.

[0101] The target field can be a field required by the business logic data, used to identify relevant values ​​in the business logic data.

[0102] Specifically, in order to classify business logic data, this embodiment of the application, after obtaining the business logic data, can create abstract class data corresponding to the business logic data for subsequent annotation of relevant values ​​in the business logic data; then, select the target field required by the business logic data from the created abstract class data, specifically, identify the business type value in the business logic data, such as identifying the business type value in the business logic data according to a preset business type value format, and extract the target field corresponding to the business type value from the abstract class data; then, assign a value to the target field according to the relevant value in the business logic data (such as the business type value) to rewrite the type field and obtain the target field value corresponding to the business logic data; finally, based on the target field value of the business type in the business logic data, classify the business logic data, such as searching a preset business type value list according to the field value of the business type (target field value) to determine the target business type corresponding to the target field value, and then classify the business logic data according to the target business type to obtain the classified business type data.

[0103] By using the above methods, after obtaining the business logic data of the target application for the target account, the business logic data can be categorized and processed so that data that conforms to the business type can be signed and stored in the future, thereby realizing the management of business data. In this way, data disorder can be avoided from affecting the efficiency of subsequent data signing, the success rate of subsequent signing can be improved, and the efficiency of business data management can be ensured.

[0104] 103. Read the target account's signature certificate.

[0105] The signature certificate is obtained by the local terminal after registering data signature permissions with the server. The signature certificate contains the target account's data signature permissions on the local terminal, which may be the signature permissions for all or part of the business logic data. It is used to limit the business types and signature process of the logic data that can be signed.

[0106] Specifically, the data signature permission can be a signature permission for logical data, specifically a signature permission for some / all business type data set for the target account. In particular, the target object corresponding to the target account can, according to its own wishes, register data signature permissions for the target application on the local terminal (or related applications on the local terminal) with the server, and can also, according to its own wishes or the wishes of other users, register data signature permissions for the target application on other terminal devices.

[0107] The data signature permission includes the signature permission relationship of the target account in the target application of the corresponding terminal. This signature permission relationship can reflect the association between the data of the business type and the signature permission. That is, the terminal device can determine the data of the business type that the target account can sign in the target application of the terminal device based on the data signature permission.

[0108] It should be noted that the signature certificate in this application embodiment requires prior registration of data signature permissions. Specifically, the registrant of the target account can register data permissions through a main device. The main device can be understood as a terminal device with the highest management authority for the account, indicating that the target account has the highest authority when used in the target application on the main device. For example, taking a target account shared with multiple target objects as an example, the administrator of the target account (which may be the target object that initiated the account registration) can set the main device with the server through personal information authentication, such as setting the main device and changing the main device through a mobile phone verification code, other passwords, etc. The main device is usually the administrator's personal terminal device; and then request to register data signature permissions from the server through the main device. Specifically, this can be registering the data signature permissions of the target account on each terminal device and / or the client of the terminal device to obtain the signature certificate corresponding to the data signature permissions.

[0109] In some implementations, in order for the local terminal to subsequently sign the categorized business type data, this application embodiment requires pre-obtaining the target account's signature certificate on the local terminal device or other terminal devices. Therefore, before the step "reading the target account's signature certificate", the following may be included:

[0110] (103.1) Identify the target account logged in to the target application;

[0111] (103.2) Request the server to register the data signature permission corresponding to the target account;

[0112] (103.3) If the server returns a signature certificate corresponding to the data signature permission, the signature certificate is stored in the storage space associated with the target account in the local terminal.

[0113] In this embodiment, when pre-registering the signature certificate for the target account, a certificate acquisition request triggered by the account administrator can be used to request registration and certificate issuance from the server. Specifically, the local terminal detects the certificate registration instruction triggered by the target object in real time. When the certificate registration instruction is detected, the target account logged in to the target application on the local terminal is identified to determine the account information corresponding to the certificate registration instruction. Then, the local terminal generates a certificate registration request and requests the server to register the data signing permission corresponding to the target account through the certificate registration request. This allows the server to register the data signing permission for the target account and return the corresponding signature certificate to the local terminal after successful registration. Thus, when the local terminal receives the signature certificate corresponding to the data signing permission, it can store the signature certificate in the storage space associated with the target account on the local terminal. This allows the signature certificate in the storage space to be read and used to sign the business type data when it is necessary to sign business type data later.

[0114] It should be noted that, for situations where a target account is used by multiple target objects (different terminal devices), the main device can also register the signature certificates of the target application (and related web clients) on other devices. Then, after registering the signature certificates of other devices through the main device, the server will distribute the corresponding signature certificates of other devices to the corresponding other device terminals. For example, when the server detects that the target application on other devices is logged into the target account, it can actively distribute the registered relevant signature certificates to the device terminal, so that the device terminal stores the relevant signature certificates in the built-in storage space associated with the target account.

[0115] In some implementations, the registration process for the signature certificate may be the registration of data signing permissions. This registration process primarily includes registering signing permissions for business data types that can be signed. Specifically, step (103.2), "Requesting the server to register the data signing permissions corresponding to the target account," may include:

[0116] (103.2.1) Request the data signature policy from the server;

[0117] (103.2.2) Obtain the historical business logic data selected for the target account in the target application, and sign the historical business logic data according to the data signature policy to obtain the signature information;

[0118] (103.2.3) Send signature information to the server so that the server can register the target account's data signature permissions based on the signature information.

[0119] The data signature strategy can be a data authentication rule, which is not limited to verification rules for information (such as keys) authentication processes and authentication rules for data signature authentication processes. In this embodiment, the data signature strategy includes signature rules for the data signature permission registration process. These signature rules can define signature formats, signature elements, signature parameters, etc., and can be used to guide and standardize the data signature permission registration process.

[0120] The signature information can be data containing signature data, which can be a specific value, such as an MD5 value, used by the server to subsequently verify the signed logical data. Specifically, it can be used by the server to verify the signed logical data. It should be noted that when obtaining signature information, after determining the business type of the historical business logic data, the logical data of that business type can be signed according to the data signature policy to obtain signature information. Specifically, when determining the business type of the historical business logic data, it can be determined according to the business type management rules provided by the target application backend. For example, the target application backend may pre-set corresponding data field values ​​when managing each business function program, and the business type of the historical business logic data can be determined through these data field values.

[0121] It should be noted that after the signature information is verified by the server, it can be used as archived data for subsequent verification of the related logical data after signing.

[0122] To register data signing permissions for a target account within a target application on the server, this embodiment of the application can send a data permission registration request for the target account to the server after detecting a permission registration instruction input by the target object, in order to obtain the data signing policy of the application platform (server). Then, it identifies the historical business logic data selected by the target object for one or more business function programs in the target application, such as the logical data corresponding to historical playback records in the video playback records (business function programs) of a video application, and / or the logical data of other business function programs. After identifying the selected historical business logic data, it can obtain the historical business logic data selected for the target account in the target application, and sign the historical business logic data according to the data signing policy to obtain signature information. Finally, the signature information is sent to the server so that the server archives it after verifying the signature information and registers the data signing permissions for the target account based on the verified signature information.

[0123] In some implementations, step (103.2.2) "signing historical business logic data according to the data signature policy to obtain signature information" may include: generating an account key corresponding to the target account according to the data signature policy; and signing historical business logic data according to the account key to obtain signature information.

[0124] The account key serves as a signature element in the signature rules of the data signature policy. It can be limited by the data signature policy, such as limiting the key format and / or generation rules, but this is not limited here.

[0125] In this embodiment of the application, when signing historical business logic data, a key-based signing method can be used. Specifically, after obtaining the data signing policy, an account key corresponding to the target account is generated according to the relevant rules of the data signing policy and the target account information; then, the business logic data is signed using the account key according to the signing rules in the data signing policy to obtain signature information, which is then sent to the server for verification and registration of data signing permissions.

[0126] In some implementations, to achieve data management for target applications of a target account on other devices, the target account administrator can set signature permissions for the target application's related logical data on other devices through the main device. For example, after step (103.2.2), it may also include: identifying the device permission type of the local terminal; if the device permission type of the local terminal is detected as main device permission, then obtaining a pre-set list of secondary device permissions, and when a secondary device identifier is detected in the list of secondary device permissions, updating the permission relationship of the signature information according to the secondary device identifier to obtain the updated signature information; then step (103.2.3) "sending signature information to the server" may include: sending the updated signature information to the server.

[0127] Specifically, when identifying the device permission type of a local terminal, a device permission query request can be sent to the server to determine the device permission type of the local terminal based on the device permission information returned by the server. Alternatively, the device permission type of the local terminal can be determined through the device management information of the target application on the local terminal. Furthermore, when the device permission type of the local terminal is detected as primary device permission, a pre-set list of secondary device permissions can be obtained through the device management information of the target application. The secondary device identifiers in the secondary device permission list are then added to the device permission information in the signature information, thereby establishing a permission relationship between the target secondary device identifier and the signature information. This updates the device permission relationship of the corresponding logical data in the signature information, thus updating the signature information. Additionally, the primary device can sign data for the local target application and other target applications on other devices (secondary devices) independently, making the signature information of different terminal devices independent. The signing method is consistent with the implementation process of the signature in the embodiments of this application and will not be elaborated here. Finally, the updated signature information is sent to the server for verification. After successful verification, the signature permission of the target account for the business type data of the target application on the local terminal device and other devices is registered, i.e., data signature permission.

[0128] It should be noted that this device management information can be updated at any time through the target application on the main device. Specifically, taking the management of other devices as an example, when a device management command is detected from the device management interface of the target application on the main device, the device identification information (such as the device unique identifier, device serial number, etc.) selected / input by the target object is obtained, and the obtained device identification information is added to the secondary device permission list. The updated device identification information in the secondary device permission list can also be reported to the server in real time to update the device management information of the target account. Furthermore, the main device settings can also be set or changed through the interface corresponding to this device management information, specifically by setting or changing the main device via a mobile phone verification code, other passwords, etc.

[0129] The above methods can be used to read the pre-stored signature certificate in the local terminal, so that the signature control of business type data can be performed according to the data signature permissions in the signature certificate.

[0130] 104. Based on the data signing permissions in the signature certificate, sign the business type data to obtain the target logical data carrying the target signature information.

[0131] The target signature information can be signature data information or signature data value in the target logical data. The format of the target signature information can be a unique string or code in a specific format, determined by the signature elements involved in the signing process. Signature elements are not limited to account keys, strings, business type identifiers (field values), application identifiers, etc., but are not limited to account keys, specific strings, business type identifiers (field values), application identifiers, terminal identifier information (such as serial numbers), etc. For example, the format of the target signature information can be the format encrypted using the Message Digest Algorithm 5 (MD5). The above is only an example; the specific format can be determined according to the actual situation.

[0132] The target logical data can be the logical data of business type data after successful signing, which can be understood as encrypted logical data. This target logical data packet contains the target signature information after signing, which is used for data verification on the server side. For example, using the MD5 value as the target signature information, the server can compare the target signature information (MD5 value) with pre-archived signature data to complete the verification.

[0133] To sign business type data, this embodiment of the application, after obtaining the signature certificate of the target account in the target application on the local terminal, can sign the business type data according to the data signing permissions in the signature certificate to obtain target logical data carrying the target signature information. In this way, the signing permissions of business type data can be identified, and business type data with signing permissions can be signed, achieving initial management of business type data and ensuring the security of business type data during the management process through data signing.

[0134] In some implementations, to determine whether the business type data to be managed has signing permissions, the permission relationship of the business type data to be managed can be determined based on the data signing permissions in the signing certificate. For example, whether the data signing permissions in the signing certificate include the association relationship of the business type data. If the association relationship of the business type data is included, it means that the business type data has data signing permissions, and the signing can be completed. For example, the step "signing the business type data according to the data signing permissions in the signing certificate to obtain target logical data carrying target signature information" can include: determining a signing permission list according to the data signing permissions in the signing certificate, the signing permission list containing the association relationship between preset business types and signing permissions; determining the target business type corresponding to the business type data, and matching the target business type in the signing permission list; if a preset business type corresponding to the target business type is matched, then signing the business type data according to the signing permissions associated with the preset business type to obtain target logical data carrying target signature information.

[0135] Specifically, in the process of signing business type data, firstly, it is necessary to determine whether the business type data to be signed (managed) has signing permissions. For example, based on the data signing permissions in the signing certificate, the preset business types with signing permissions and the corresponding signing permission relationships are obtained. Then, a corresponding signing permission list is established based on the preset business types and their corresponding permission relationships, creating an association between the preset business types and signing permissions. Next, the target business type of the currently managed business type data is determined. This can be determined by the target field value in this embodiment, or by the business function program corresponding to the business type data. The determined target business type is then matched with the preset business types with signing permission relationships in the signing permission list to determine whether the business type data to be managed is a preset business type with signing permissions. Finally, if a preset business type matching the target business type is detected in the signing permission list, the business type data to be managed is signed according to the pre-built data signing strategy based on the signing permissions associated with that preset business type, resulting in target logical data carrying the target signature information.

[0136] On the other hand, after the step "matching the target business type in the signature permission list", it also includes: if a preset business type matching the target business type is detected in the signature permission list, then the signing of the business type data is stopped, and other data management strategies are executed subsequently, such as not uploading to the server, deleting, etc.

[0137] Using the above methods, business type data with permission relationships can be signed according to the data signing permissions in the signature certificate to obtain target logical data with target signature information. This facilitates the subsequent management of the target logical data and prevents data from being tampered with during the management process, such as preventing data from being tampered with or intruded on during the transmission of data to the server for storage, thereby improving data security.

[0138] 105. Upload the target logical data to the server for storage.

[0139] In this embodiment of the application, after completing the signing process of the business type data, the method may further include: determining the data processing strategy corresponding to the business type data based on the signing result, and processing the business type data according to the data processing strategy. Specifically, after completing the signing process of the business type data, a corresponding data processing strategy can be determined based on the signing status (signing result) of the business type data, and the business type data can be processed according to the data processing strategy.

[0140] It should be noted that, in managing business type data, this application embodiment can divide the processing into two methods based on the data signature situation: First, after the business type data is successfully signed, the signed data is uploaded to the server for storage; Second, when the business type data fails to be signed, the business type data is not uploaded to the server.

[0141] In this embodiment of the application, when the signature result is target logical data containing target signature information, the data processing strategy corresponding to the target logical data is determined to be a data upload strategy; then, according to the data upload strategy, the target logical data containing target signature information is uploaded to the server for storage.

[0142] In some implementations, to ensure the performance of network resources (such as bandwidth, signal strength, etc.), servers, local terminals, etc., and to ensure the stability of data transmission, when determining to upload target logical data, the current data upload request volume can be determined first, and the decision to continue uploading the target type of data can be evaluated based on the data upload request volume. For example, before "uploading the target logical data to the server for storage" in step (105.2), the process may include: obtaining the data transmission queue corresponding to the target application in the local terminal; identifying the number of data tasks to be executed in the data transmission queue; then, "uploading the target logical data to the server for storage" in step (105.2) may include: if the number of identified data tasks is less than a preset task number threshold, then the target logical data is uploaded to the server for storage.

[0143] On the other hand, if the number of identified data tasks is greater than or equal to a preset task quantity threshold, the current target time of the local terminal is identified, and the target upload time for the target logical data is determined based on the target time and a preset delay time value. When the target upload time is reached, a target upload task for the target logical data is created in the data transmission queue to upload the target logical data to the server for storage. Furthermore, the upload time for the target logical data can also be determined based on network resource usage. For example, data upload can be performed during periods of low bandwidth usage, ensuring data transmission stability and effectively avoiding network congestion, thus providing reliability.

[0144] In this embodiment of the application, after signing the business type data according to the data signing permission in the signing certificate, the method further includes: if no preset business type corresponding to the target business type is matched, then the signing of the business type data is stopped, and the business type data that has stopped signing is determined as unsigned data; the unsigned data uploaded to the server is intercepted, and the intercepted unsigned data is deleted.

[0145] Specifically, when the signature result is business type data that does not contain the target signature information, it indicates that the signature of the business type data failed. This means that the target object has not set the signature permission for this business type data, and therefore does not have the storage requirement for this business type data. In this case, to avoid confusion between this business type data and the logical data of the target account on the local terminal in the server, when managing this failed signature business type data, it is not necessary to upload this business type data.

[0146] In this embodiment, the management process for business logic data generated by the target application may include two parts. Specifically: First, when the local terminal detects business logic data generated by the target application for the target account, it categorizes and signs the business logic data, and uploads the successfully signed business logic data to the server for storage; thereby, it realizes the management of the logic data of the business function program according to the target object's business function behavior habits and data management intentions on the local terminal, such as uploading business data that conforms to the target object's intentions to the server for storage management. Secondly, the main focus is on the subsequent applications of the target logical data uploaded to the server. These applications include, but are not limited to, business function preference mining, feature mining, advertising push, information recommendation, big data querying, and business recommendation. For example, taking a business function within a target application as an example, the server side establishes a corresponding database table for each terminal device (main device and / or secondary device). Taking the main device as an example, any business logical data generated when the target application runs relevant business functions for the target account on the main device is categorized and signed by the main device, then uploaded to the server and stored in the database table after verification. All logical data stored in this database table can be used for subsequent related application scenarios, thereby enabling the management and use of the uploaded logical data. It should be noted that the above data can be managed in application aspects after authorization by the corresponding target account.

[0147] It should be noted that the management of logical data usage on the server can be combined with data signature permissions. For details, please refer to the example of signing business logic data on the terminal in this application embodiment; this application embodiment will not elaborate further. To facilitate understanding of the management of logical data usage after uploading to the server, this application embodiment will describe data usage management using the following methods.

[0148] In some implementations, for the business functions of a target object running through a target application on a local terminal, the corresponding business logic data is uploaded and managed according to the target account's permissions on the target application on the local terminal. The data uploaded to the server for storage can then be used for business recommendations within the target application on the local terminal. Therefore, after the step "upload the target logic data to the server for storage," the process may include: if a startup request for the target application is detected, starting the target application and identifying its running process; if the running process reaches a preset running time point, obtaining the attribution field value from the real-time business logic data corresponding to the running process, and requesting the server to obtain the historical business logic data corresponding to the attribution field value; if the business type is consistent between the historical business logic data and the real-time business logic data, merging the historical and real-time business logic data, and displaying the merged target business logic data.

[0149] The preset execution process point refers to a pre-defined logical point in time for the target application or its business function program. This point serves as a reference for comparing the progress of the business function program, ensuring that the target application subsequently runs to this preset execution process point for data management. For example, in a video application, the preset execution process point could be the logical point at which the target object opens the video playback record function in the video application, or it could be the logical point at which the target object opens the video recommendation option function in the video application, etc. These are just examples; the specific point can be set according to the actual situation.

[0150] In this embodiment, when the local terminal detects that the target application is running and starting, it can monitor the running process of the target application in real time and determine the current running status of the target application through the running process, such as whether the relevant business functions have been started and the current business logic point of the business function program of the target application, so that the running process of the target application can reach the preset running process point and the management server can request the stored logical data for the target account on the local terminal.

[0151] Specifically, after the target application starts, the current running logic time point of the target application is determined based on the running process of the target application. If the current running logic time point reaches the preset running process time point, it is identified whether the current process logic time point of the target application is at the preset logic time point. If it is at the preset logic time point, the attribution field value of the real-time business logic data of the target application at that time point is identified, so as to obtain the historical business logic data with the same attribution field value requested by the target account on the local terminal from the server. Then, when the number of historical business logic data with the same attribution field value is received, the target historical business logic data with the same business type as the real-time business logic data is selected, the target historical business logic data is merged with the real-time business logic data, and the merged target business logic data is displayed. For example, taking a video application as an example, when a target user clicks on the video recommendation function in the video application, the preset running time point corresponding to the video recommendation function is reached. At this time, the real-time business logic data selected by the target user in the video recommendation function of the target application is obtained, and the attribution field value of the real-time business logic data is determined to determine the data source of the corresponding recommended video (such as production company, author, editor, or copyright, etc.). Then, the historical business logic data corresponding to the same attribution field value is requested from the server, and the target historical business logic data belonging to the video recommendation function under the same attribution field value as the real-time business logic data is selected. After the data is merged, it is displayed in the video recommendation options. In this way, the scope of video recommendation for a certain data source is expanded, so as to increase the video recommendation intensity according to the target user's preferences and improve the target user's experience.

[0152] In some implementations, during the data usage management process, business prompts can also be provided based on historical business logic data of the target object's behavioral habits in the target application. Therefore, after the step "upload the target logic data to the server for storage," the process may include: if a startup request for the target application is detected, a business prompt request carrying the target account is sent to the server, causing the server to generate a business prompt label based on the target account's data upload records on the local terminal; if the server returns the business prompt label, the target application is launched, and the business prompt label is displayed in the launched target application interface.

[0153] Specifically, upon detecting the launch request of the target application, the current target time is determined, and a business prompt request is sent to the server. This causes the server to search for historical business logic data that occurs at the same time as the target account's data upload records from the local terminal. This historical business logic data is then identified as the data to be pushed and returned to the local terminal. The local terminal receives the data to be pushed from the server and displays the corresponding business prompt label on the target application's interface after the application launches. For example, taking a live video application as the target application, when the local terminal detects that the target object has opened the live video application, it determines that the current target time is 20:00. If the target object is accustomed to watching live sports broadcasts at the same time (20:00) in the historical time of the live video application, and the server stores the historical business logic data corresponding to the live sports broadcast, then the local terminal requests the historical business logic data corresponding to the live sports broadcast at that time from the server as the logic data to be pushed to the live video application. Then, after the live video application starts, the business prompt label corresponding to the logic data to be pushed is displayed on the interface of the live video application (such as the application homepage or any window interface) according to the logic data to be pushed.

[0154] In this embodiment, on the one hand, for the business logic data generated by the target account in the target application, the business logic data can be first classified to obtain business type data, thereby determining the business type corresponding to the business logic data; then, the signature certificate stored in the local terminal (or target application) is read, and the business type with signing authority is determined according to the data signing authority pre-registered by the target object in the signature certificate, and the business type data with signing authority is signed to obtain the target logic data after successful signing, and the target type data is uploaded to the server for verification and storage; in this way, the upload process of the target logic data is managed, and the signing method can prevent data tampering and improve data security. In addition, management operations such as deletion and modification can be performed on the business type data that fails to be signed, meeting the data management needs of the target object and improving the user experience of the target object. On the other hand, it can manage the application of historical business logic data stored on the server. Since the historical business logic data is stored after being signed according to the data signing permissions registered by the target object, it conforms to the target object's wishes. Therefore, when a request is made to apply the relevant historical business logic data in a relevant data application scenario, it can be searched from the historical business logic data stored in the target object's wishes. It is targeted and can improve the efficiency of finding the business logic data required for the application scenario and improve the experience of the target object.

[0155] As can be seen from the above, this application embodiment can obtain the business logic data of the target account in the target application; classify the business logic data to obtain classified business type data; read the target account's signature certificate, which is obtained after the local terminal registers data signature permissions with the server, and the signature certificate contains the target account's data signature permissions on the local terminal; sign the business type data according to the data signature permissions in the signature certificate to obtain target logic data carrying the target signature information; and upload the target logic data to the server for storage. Therefore, this solution can obtain the business logic data generated by the target application during runtime, classify the business logic data to determine the business type of the business logic data; furthermore, sign the classified business type data according to the data signature permissions in the target account's signature certificate, and determine the processing strategy for the business type data based on the signature, such as performing data upload after successful signing, thereby improving the security and efficiency of data processing. Thus, business data can be processed according to the target object's wishes to manage the data generated by the application in a targeted manner, ensuring that the application business data used subsequently meets the needs of the target object and improves the user experience.

[0156] Based on the method described in the above embodiments, the following examples will provide further detailed explanations.

[0157] This application takes data processing as an example to further describe the data processing method provided in this application embodiment.

[0158] Figure 3 This is a schematic flowchart of another step of the data processing method provided in the embodiments of this application. Figure 4 This is a schematic diagram of the interface used by multiple terminals in the data processing method provided in the embodiments of this application. Figure 5 This is a schematic diagram of the interface for device information management in the data processing method provided in the application embodiment. Figure 6 This is a schematic diagram illustrating a scenario of registering data signature permissions in the data processing method provided in the application embodiment. Figure 7 This is a block flowchart illustrating the data processing method provided in the embodiments of this application. For ease of understanding, the embodiments of this application are combined with... Figure 3-7 Describe it.

[0159] In this embodiment, the description will be from the perspective of a data processing device, which can be integrated into a computer device such as a terminal or server. For example, when the processor on the computer device executes a program corresponding to a data processing method, the specific flow of the data processing method is as follows:

[0160] 201. The terminal identifies the target account logged in to the target application and sends a data signature permission registration request for the target account to the server.

[0161] In this embodiment of the application, when the terminal detects a data signature permission registration instruction in the target application, it identifies the target account logged in in the target application, generates a data signature permission registration request for the target account, and sends it to the server.

[0162] 202. Based on the data signature permission registration request, the server returns the obtained data signature policy to the terminal.

[0163] The data signature strategy can be a data authentication rule, which may include verification rules for the information authentication process, authentication rules for the data authentication process, etc. For example, the data signature strategy includes signature rules for the data signature permission registration process. These signature rules can define signature format, signature elements, signature parameters, etc., and can be used to guide the data signature permission registration process and the standardization of the registration process.

[0164] 203. The terminal obtains the historical business logic data selected for the target account in the target application, signs the historical business logic data according to the data signature policy, and sends the obtained historical signature information to the server.

[0165] The historical business logic data can be the logical data of the target account when running the relevant business function program of the target application at a historical time. It is essentially object data, which can affect the calling and execution instructions of relevant functions during the operation of the business function program.

[0166] The historical signature information can be data information containing signature data, which is used by the server to verify the logical data of the signature in the future; for example, the historical signature information can be data information in MD5 value format.

[0167] In this embodiment, when obtaining signature information, firstly, the historical business logic data selected by the target object for one or more business function programs in the target application is identified. For example, the logical data corresponding to the historical playback records in the video playback records (business function programs) of a video application, and / or the logical data of other business function programs. After identifying the selected historical business logic data, the historical business logic data selected for the target account in the target application can be obtained. Furthermore, the business type of the historical business logic data can be determined according to the business type management rules provided by the target application backend. For example, the target application backend pre-sets corresponding data field values ​​when managing each business function program, and the business type of the historical business logic data can be determined through these data field values. Then, after determining the business type of the historical business logic data, the logical data of that business type is signed according to the data signature strategy to obtain the historical signature information corresponding to the historical business logic data.

[0168] It should be noted that, in order to achieve data management for target applications on other devices for a target account, the target account administrator can set signature permissions for the target account's logical data related to the target application on other devices through the main device. This main device is typically the administrator's personal terminal device, which can be set and changed by authenticating personal information to the server, such as through mobile phone verification codes or other passwords. Specifically, when identifying the device permission type of the local terminal, a device permission query request can be sent to the server to determine the local terminal's device permission type based on the device permission information returned by the server. Additionally, the device permission type of the local terminal can also be determined through the device management information of the target application on the local terminal. Furthermore, when the device permission type of the local terminal is detected as primary device permission, a pre-set secondary device permission list can be obtained through the device management information of the target application. The secondary device identifier from the secondary device permission list is then added to the device permission information in the signature information, thereby establishing a permission relationship between the target secondary device identifier and the signature information. This updates the device permission relationship of the corresponding logical data in the signature information, thus updating the signature information. In addition, the primary device can also sign data for the local target application and other target applications on other devices (secondary devices), making the signature information of different terminal devices independent. The signing method is consistent with the implementation process of the signature in the embodiments of this application, and will not be elaborated here. Finally, the updated signature information is sent to the server for verification.

[0169] Then, the historical signature information is sent to the server so that the target account can register data signature permissions based on the historical signature information.

[0170] 204. The server registers the target account's data signing permissions based on historical signature information, and after applying for the signature certificate corresponding to the data signing permissions, returns the signature certificate to the terminal for storage.

[0171] When registering data signature permissions for a target account, the server can simultaneously register data signature permissions for the target account on one or more terminals for the target application. It should be noted that the data signature permissions for the same target account may differ on different terminal devices.

[0172] Specifically, the registration process for this data signature permission can be as follows: the server verifies historical signature information and, upon successful verification, registers data signature permissions for the target account on one or more terminal devices. Simultaneously, the server uses the verified historical signature information as archived data for subsequent verification of the signed logical data. Furthermore, the server applies for a signature certificate for the target account on the terminal based on the verified historical signature information and returns the obtained signature certificate to the terminal for storage.

[0173] 205. When the terminal identifies the current business logic time point of the target application, if it detects that the business logic time point has reached the preset data upload time point, it will obtain the business logic data of the target account in the target application.

[0174] The business operation logic timing point can be the logical progress timing point when the local terminal is running the relevant business function program, which can reflect the running progress of the business function. For example, taking a music application as an example, the target object can generate the business operation logic of the music application's playback business function by pre-creating a music playlist to be played and setting the automatic playback time, stop playback time, pause playback mode, etc. of the music playlist. Such logic is as follows: "Identify time - play when time is up (automatic playback time) - pause playback and resume playback in other scenarios (pause playback mode) - stop playback (stop playback time)". From the above, it can be seen that "play when time is up", "pause playback in other scenarios", "resume playback" and "stop playback" can all be regarded as a business operation logic timing point. The above is only an example, and the embodiments of this application do not limit the business operation logic timing point.

[0175] The preset data upload time point can be the logical time point at which business logic data is uploaded to the server for storage. By presetting this logical data upload time point, the upload time of business logic data can be limited.

[0176] Specifically, the process involves identifying the currently running business function program within the target application and locating its corresponding business process, such as by using the program's identifier to find the corresponding process within the target application. Then, based on this process, the execution logic timing of the target application (which could be a business function program) is determined. Furthermore, this timing is compared with a preset data upload timing. When the execution logic timing reaches (or matches) the preset data upload timing, the business logic data for the target account within the target application is retrieved. Specifically, this could also refer to the business logic data of the target account while running the target business function program. In this way, the running progress of the currently running business function program within the target application can be determined, and the business logic data can be retrieved when the process reaches a preset time point, facilitating subsequent management of the retrieved data.

[0177] 206. The terminal classifies the business logic data to obtain the classified business type data.

[0178] Here, "business type data" refers to the reorganized business logic data. Specifically, the target application may include multiple business function programs or multiple business type programs, each business function program or business type program corresponding to a specific business type; that is, the business logic data is different between different business type programs.

[0179] Specifically, in order to classify business logic data, this embodiment of the application, after obtaining the business logic data, can create abstract class data corresponding to the business logic data for subsequent annotation of relevant values ​​in the business logic data; then, select the target field required by the business logic data from the created abstract class data, specifically, identify the business type value in the business logic data, such as identifying the business type value in the business logic data according to a preset business type value format, and extract the target field corresponding to the business type value from the abstract class data; then, assign a value to the target field according to the relevant value in the business logic data (such as the business type value) to rewrite the type field and obtain the target field value corresponding to the business logic data; finally, based on the target field value of the business type in the business logic data, classify the business logic data, such as searching a preset business type value list according to the field value of the business type (target field value) to determine the target business type corresponding to the target field value, and then classify the business logic data according to the target business type to obtain the classified business type data.

[0180] 207. The terminal reads the signature certificate of the target account and signs the business type data according to the data signature permissions in the signature certificate to obtain the signature result.

[0181] The signature certificate is obtained by the local terminal after registering data signature permissions with the server. The signature certificate contains the target account's data signature permissions on the local terminal, which may be the signature permissions for all or part of the business logic data. It is used to limit the business types and signature process of the logic data that can be signed.

[0182] In this embodiment, during the signing process of business type data, it is first necessary to determine whether the business type data to be signed (managed) has signing permissions. For example, based on the data signing permissions in the signing certificate, the preset business types with signing permissions and their corresponding signing permission relationships are obtained. Then, a corresponding signing permission list is established based on the preset business types and their corresponding permission relationships, creating an association between the preset business types and signing permissions. Next, the target business type of the currently managed business type data is determined. Specifically, this can be determined by the target field value in this embodiment, or by the business function program corresponding to the business type data. The determined target business type is then matched with the preset business types with signing permission relationships in the signing permission list to determine whether the business type data to be managed is a preset business type with signing permissions. Therefore, when checking whether the business type data to be managed has signing permissions, this embodiment can include two aspects, as follows:

[0183] On the one hand, if a preset business type corresponding to the target business type is matched, the data of the business type to be managed is signed according to the signature permissions associated with the preset business type and the pre-built data signature strategy. After successfully signing the business type data, if the signature result contains target logical data with the target signature information, then steps 208-209 are executed.

[0184] On the other hand, if no preset business type corresponding to the target business type is matched, the signing of the business type data is stopped, and the business type data whose signing is stopped is determined to be unsigned business logic data. At this time, the signing of the business logic data cannot be completed, and the signing result is unsigned business type data, so step 210 is executed.

[0185] 208. If the detected signature result is target logical data carrying target signature information, then upload the target logical data to the server for verification.

[0186] In this embodiment of the application, when the signature result is target logical data containing target signature information, the data processing strategy corresponding to the target logical data is determined to be a data upload strategy; then, according to the data upload strategy, the target logical data containing target signature information is uploaded to the server for verification.

[0187] 209. The server verifies the target logical data based on the historical signature information and stores the target logical data that has passed the verification.

[0188] Specifically, the server obtains a set of historical signature information associated with the target account, and selects historical signature information corresponding to the business type of the target logical data from the historical signature information. Then, it extracts the target signature information from the target logical data and compares it with the historical signature information to verify the information, thus completing the verification of the target logical data. Further, the server stores the verified target logical data, specifically in a database table on the local terminal.

[0189] It should be noted that the server side establishes a corresponding database table for each terminal device (main device and / or secondary device).

[0190] 210. If the signature result is detected as unsigned business type data, the upload of unsigned business type data to the server will be blocked, and the blocked unsigned data will be deleted.

[0191] The unsigned business type data is logical data that does not have target signature information, indicating that the target account does not have the permission to sign the logical data or store it on the server in the target application of the terminal.

[0192] Specifically, when the signature result is business type data that does not contain the target signature information, it indicates that the signature of the business type data failed. This means that the target object has not set the signature permission for this business type data, and therefore does not have the storage requirement for this business type data. In this case, to avoid confusion between this business type data and the logical data of the target account on the local terminal in the server, when managing this failed signature business type data, it is not necessary to upload this business type data.

[0193] To facilitate understanding of the embodiments of this application, specific application scenario examples will be used to describe the embodiments of this application. Specifically, by performing the above steps 201-210, and in conjunction with... Figure 4 , Figure 5 , Figure 6 and Figure 7 This section describes an example of the application scenario.

[0194] The application scenarios in this application are not limited to map applications, video applications, music applications, live media applications, news applications, etc. This application will use a video application as an example, which may involve multiple video business functions, such as, but not limited to, video playback records, video favorites, playlists, and behavior logs. The data corresponding to these video business functions are called core data (i.e., business logic data). For ease of understanding, the following description will use the video playback record function as an example in the video application scenario.

[0195] The video playback record example may include the use of an application account on multiple devices, such as the use of an application account on different clients on the same terminal device, and the use of the same application account on different clients on different terminal devices.

[0196] See Figure 4This example illustrates the product interface of an account used across multiple platforms, including the interfaces of video application A, video application B, and PC client C (such as a desktop client and / or web client). The example combines the interfaces of video application A and video application B to demonstrate that the same account retrieves the same playback records in different applications. Similarly, the example combines the interfaces of video application A or B with the interface of PC client C to demonstrate that the same account retrieves the same playback records on different terminals (including mobile and / or PC clients). As described above, playback records used by the same account on multiple platforms can be merged. However, if an account is used by multiple target objects, data management chaos can occur, leading to the merging of playback records between multiple target objects under the same account. This is detrimental to the data processing management of each target object and subsequent data application management. Therefore, to prevent this phenomenon, this video application scenario example manages core data (coreData, i.e., business logic data) by combining data signature permissions with terminal device information.

[0197] See Figure 5 This diagram illustrates the device information management interface in the data processing method. Each video application's settings page has a "Device Management" option. Through this option, users can view and set the target account's permissions and login records on various terminal devices. For example, the Device Management interface displays the interruption information and time for the logged-in account. It's worth noting that a primary terminal device can be designated for each application account (the primary device is determined by the target object's mobile verification code). The primary device can add, restrict, delete, and blacklist other terminal devices. Furthermore, the primary device can apply for data signing permissions for the local terminal and other terminal devices, respectively, to restrict the local terminal and other terminal devices from performing operations such as writing to the cache, reporting, and merging when generating coreData.

[0198] This video application scenario example includes the data signature permission registration process and the data processing process.

[0199] First, before processing core data (i.e., business logic data), it is necessary to register data signing permissions for the application account on the main terminal device and other terminal devices. This data signing permission registration can be obtained through Fast Identity Online (FIDO) on the main terminal device. The registration process for this data signing permission is described below:

[0200] See Figure 6The scenarios for registering data signature permissions include both terminal devices and servers. Terminal devices (the main device) include, but are not limited to, video applications, FIDO clients, and coreData data terminals; servers include, but are not limited to, video application backend services, FIDO authentication services, signature verification services (encryption verification), and certificate services (China Financial Certification Authority, CFCA / caching). It should be noted that the FIDO client and the video application interact via an interface, and the FIDO authentication service and the video application backend service interact via an interface. This allows the terminal device to access the FIDO client and FIDO authentication service when the video application interacts with its backend service. The data signature permission registration process is as follows: 1. The video application on the terminal device initiates registration by sending a registration service request to the video application backend service on the server; 2. The video application backend service calls the interface to access the FIDO authentication service; 3. The FIDO authentication service returns the data signature policy to the video application backend service through the interface; 4. The video application backend service generates a data signature permission registration request based on the data signature policy to request the terminal device to perform the relevant matters for registering data signature permissions; 5. The video application calls the interface to send the data signature policy to the FIDO client; 6. When the FIDO client recognizes business logic data generated by the coreData data terminal, it generates an account key and signs it according to the data signature policy. In addition, it can also combine the device key data for signing; 7. The FIDO client returns the signature information to the video application. The process is as follows: 8. The video application sends the signature information to the video application backend service on the server to request registration of data signature permissions; 9. The video application backend service calls the interface to send the signature information to the FIDO authentication service; 10. The FIDO authentication service requests verification of the signature information from the signature verification service, such as through encrypted comparison verification; 11. The signature verification service returns the verification result to the FIDO authentication service; 12. After recognizing that the verification structure is successful, the FIDO authentication service applies to the certificate service for the signature certificate corresponding to the verified signature information; 13. The FIDO authentication service calls the interface to return the signature certificate to the video application backend service; 14. The video application backend service returns the signature certificate to the terminal device, enabling the terminal device to store the signature certificate in the storage space associated with the application account, thereby completing the registration of data signature permissions.

[0201] Second, perform data processing on the business logic data. The specific data processing procedure is as follows:

[0202] 1. The terminal device detects the coreData data of the application account in the video application in real time, and retrieves the coreData data when it is detected.

[0203] 2. Create an abstract class (baseData) for the coreData data. This abstract class provides multiple fields, such as the business type field (type), the business field, and the remote service field (aid). The coreData data inherits from the fields in the abstract class and overrides the business type field (type) to assign corresponding business type values ​​to the coreData data. Then, the coreData data is categorized according to the business type field values. For example, in a video application, account VIP features include regular VIP (watching regular videos), sports membership (watching live sports events), diamond membership (watching advanced on-demand content), and screen mirroring membership (with TV viewing and screen mirroring functions). These features can be uniformly classified under the VIP type. Furthermore, for knowledge-based paid memberships (paying to watch certain knowledge-related tutorials) and vertical functions (watching comics, game live streams, anime, novels, etc.), the vipType field can be uniformly used after inheriting from baseData and overriding the type field.

[0204] 3. Management (upload and download) of categorized coreData data can be performed based on FIDO authentication. This coreData management primarily involves server-side and terminal devices (including master devices and other devices), and can be combined with... Figure 7 The descriptions of the server and terminal devices are as follows:

[0205] A. The server provides basic storage functions for coreData and exposes CRUD (Create, Read, Update, Delete) interfaces for each device terminal to call. Additionally, the server creates a database table named (tableDeviceID) for each terminal device, named aid, to store the signed coreData. This coreData is generated and signed by the application account on the terminal device for the video application and then uploaded to the server. Each terminal device connects to the corresponding database table on the server using its application account identifier to query the required coreData.

[0206] B. The master device can manage the uploading, downloading, synchronization, and merging of data from other devices, and has the authority to delete and add other devices. Specifically, the master device can be bound on the device management page of the video application to control the permissions of other devices to read specified business type fields (such as vipType). When vipType takes a specific value, it allows modification or deletion of coreData. For example, in playback records, when the vipType is "Live Streaming," playback records in the Live Streaming category can be deleted to avoid confusion during subsequent server data management.

[0207] The data upload example is as follows: After the video application generates historical coreData for the application account, the target object can use the video application to embed tracking points into the coreData at preset times. In practical applications, when the video playback business function reaches this time, for example, after the video playback business function finishes recording, switching the video application to the background is considered the preset time. Then, the terminal device calls the signature certificate issued by the server to sign the categorized coreData data; subsequently, it calls the server's CRUD interfaces to upload the coreData data to the server. It should be noted that a circuit breaker mechanism can also be set for the data upload process. When the number of network requests for upload reaches a certain threshold, subsequent upload operations will be blocked.

[0208] The data downlink process is as follows: When the video application on the main device / other devices reaches a similar timing point as mentioned above, it can call the server's interface to request the downlink of logical data. The server then uses the `business` identifier field related to the coreData data carried in the request to query the relevant dataset, determine the required coreData data, and send it down. Upon receiving the downlink coreData data, the video application determines whether it needs to be merged. If so, it provides an anonymous function to an external caller, which receives the merged result and displays the merged data on the video application interface.

[0209] Through the above application scenario examples, the following effects can be achieved: It is suitable for situations where an application account is used on multiple devices, and the data management process can regulate and process data according to the target audience's needs, current privacy policies, and laws and regulations, so as to achieve targeted data management and facilitate the subsequent use of the managed data; In addition, logical data is encapsulated based on FIDO authentication to improve the security of logical data in the management process and prevent privacy data from being captured or leaked.

[0210] As described above, this application embodiment can obtain business logic data generated by the target application during runtime, classify the business logic data to determine its business type, and then sign the classified business type data according to the data signing permissions in the target account's signature certificate. The processing strategy for the business type data is determined based on the signature, such as performing data upload after successful signing, thereby improving the security and efficiency of data processing. In this way, business data can be processed according to the target object's wishes, enabling targeted management of application-generated data, ensuring that subsequent application business data meets the target object's needs, and improving user experience.

[0211] To better implement the above methods, embodiments of this application also provide a data processing apparatus. For example, such as... Figure 8 As shown, the data processing device may include an acquisition unit 401, a classification unit 402, a reading unit 403, a signature unit 404, and a processing unit 405.

[0212] Acquisition unit 401 is used to acquire business logic data of the target account in the target application;

[0213] Classification unit 402 is used to classify business logic data to obtain classified business type data;

[0214] The reading unit 403 is used to read the signature certificate of the target account. The signature certificate is obtained by the local terminal after registering data signature permissions with the server. The signature certificate contains the data signature permissions of the target account on the local terminal.

[0215] The signature unit 404 is used to sign business type data according to the data signature permissions in the signature certificate to obtain target logical data carrying target signature information.

[0216] Processing unit 405 is used to upload target logical data to the server for storage.

[0217] In some implementations, the classification unit 402 is also used to: create abstract data corresponding to business logic data; extract target fields corresponding to business logic data from the abstract data, and assign values ​​to the target fields according to the business logic data to obtain target field values; classify the business logic data according to the target field values ​​to obtain classified business type data.

[0218] In some implementations, the signature unit 404 is further configured to: determine a signature permission list based on the data signature permissions in the signature certificate, the signature permission list containing the association between preset business types and signature permissions; determine the target business type corresponding to the business type data, and match the target business type in the signature permission list; if a preset business type corresponding to the target business type is matched, then sign the business type data according to the signature permissions associated with the preset business type to obtain target logical data carrying target signature information.

[0219] In some implementations, the signature unit 404 is further configured to: if no preset business type corresponding to the target business type is matched, stop signing the business type data and determine the business type data that has stopped signing as unsigned data;

[0220] The processing unit 405 is also used to intercept unsigned data uploaded to the server and delete the intercepted unsigned data.

[0221] In some implementations, the data processing apparatus further includes a registration unit, specifically used for: identifying the target account logged in to the target application; requesting the server to register the data signing permission corresponding to the target account; and if the server returns a signature certificate corresponding to the data signing permission, storing the signature certificate in the storage space associated with the target account in the local terminal.

[0222] In some implementations, the registration unit is further configured to: request the server to obtain a data signature policy; obtain historical business logic data selected for the target account in the target application, and sign the historical business logic data according to the data signature policy to obtain signature information; and send the signature information to the server so that the server registers the data signature permission of the target account according to the signature information.

[0223] In some implementations, the registration unit is further configured to: generate an account key corresponding to the target account according to the data signature policy; and sign historical business logic data according to the account key to obtain signature information.

[0224] In some embodiments, the data processing apparatus further includes an update unit, specifically configured to: identify the device permission type of the local terminal; if the device permission type of the local terminal is detected to be primary device permission, obtain a pre-set secondary device permission list, and when the secondary device permission list is found to contain a secondary device identifier, update the permission relationship of the signature information according to the secondary device identifier to obtain the updated signature information;

[0225] The registration unit is also used to send updated signature information to the server.

[0226] In some embodiments, the data processing apparatus further includes an identification unit, specifically used for: obtaining the data transmission queue corresponding to the target application in the local terminal; and identifying the number of data tasks to be executed in the data transmission queue.

[0227] The processing unit 405 is also used to upload the target logical data to the server for storage if the number of data tasks is found to be less than a preset task number threshold.

[0228] In some implementations, the data processing apparatus further includes a detection unit, specifically used for: detecting the business operation process of the target application; and determining the current business operation logic timing of the target application based on the business operation process.

[0229] The acquisition unit 401 is used to acquire the business logic data of the target account in the target application if the business operation logic time point is detected to reach the preset data upload time point.

[0230] In some embodiments, the data processing apparatus further includes a data merging unit, specifically used for:

[0231] If a startup request for the target application is detected, the target application is started, and the running process of the target application after startup is identified. If the running process is identified to have reached a preset running process time point, the value of the attribution field in the real-time business logic data corresponding to the running process is obtained, and the historical business logic data corresponding to the attribution field value is requested from the server. If the business type between the historical business logic data and the real-time business logic data is detected to be consistent, the historical business logic data and the real-time business logic data are merged, and the merged target business logic data is displayed.

[0232] In some embodiments, the data processing apparatus further includes a push unit, specifically used for:

[0233] If a startup request for the target application is detected, a business prompt request carrying the target account is sent to the server, so that the server determines the logic data to be pushed based on the data upload records of the target account on the local terminal; if the logic data to be pushed is received from the server, the target application is started, and the business prompt label corresponding to the logic data to be pushed is displayed in the interface of the target application after startup.

[0234] As can be seen from the above, the embodiments of this application can obtain the business logic data of the target account in the target application through the acquisition unit 401; classify the business logic data through the classification unit 402 to obtain the classified business type data; read the signature certificate of the target account through the reading unit 403, the signature certificate is obtained by the local terminal registering data signature permissions with the server, and the signature certificate contains the data signature permissions of the target account on the local terminal; sign the business type data according to the data signature permissions in the signature certificate through the signing unit 404 to obtain the target logic data carrying the target signature information; and upload the target logic data to the server for storage through the processing unit 405. Therefore, this solution can obtain the business logic data generated by the target application during runtime, classify the business logic data to determine the business type of the business logic data; furthermore, sign the classified business type data according to the data signature permissions in the signature certificate of the target account, so as to determine the processing strategy of the business type data according to the signature, such as performing data upload after successful signing, thereby improving the security and efficiency of data processing. In this way, business data can be processed according to the wishes of the target audience, so as to manage the data generated by the application in a targeted manner, and ensure that the application business data used subsequently meets the needs of the target audience, thereby improving the user experience.

[0235] This application also provides a computer device, such as... Figure 9 As shown, it illustrates a structural schematic diagram of the computer device involved in the embodiments of this application, specifically:

[0236] The computer device may include components such as a processor 501 with one or more processing cores, a memory 502 with one or more computer-readable storage media, a power supply 503, and an input unit 504. Those skilled in the art will understand that... Figure 9 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0237] The processor 501 is the control center of the computer device, connecting various parts of the computer device through various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 502, and by calling data stored in the memory 502. Optionally, the processor 501 may include one or more processing cores; preferably, the processor 501 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 501.

[0238] The memory 502 can be used to store software programs and modules. The processor 501 executes various functional applications and data processing by running the software programs and modules stored in the memory 502. The memory 502 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 502 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 502 may also include a memory controller to provide the processor 501 with access to the memory 502.

[0239] The computer equipment also includes a power supply 503 that supplies power to the various components. Preferably, the power supply 503 can be logically connected to the processor 501 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 503 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0240] The computer device may also include an input unit 504, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0241] Although not shown, the computer device may also include a display unit, etc., which will not be described in detail here. Specifically, in the embodiments of this application, the processor 501 in the computer device loads the executable files corresponding to the processes of one or more application programs into the memory 502 according to the following instructions, and the processor 501 runs the application programs stored in the memory 502 to realize various functions, as follows:

[0242] Obtain the business logic data of the target account in the target application; classify the business logic data to obtain the classified business type data; read the target account's signature certificate, which is obtained by the local terminal after registering data signature permissions with the server, and contains the target account's data signature permissions on the local terminal; sign the business type data according to the data signature permissions in the signature certificate to obtain the target logic data carrying the target signature information; upload the target logic data to the server for storage.

[0243] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0244] Therefore, this solution can acquire and categorize the business logic data generated by the target application during runtime to determine its business type. Then, based on the data signing permissions in the target account's signing certificate, it signs the categorized business type data. The processing strategy for this business type data is determined based on the signature, such as uploading the data after successful signing, thus improving data processing security and efficiency. In this way, business data can be processed according to the target's wishes, enabling targeted management of application-generated data and ensuring that subsequent application business data meets the target's needs, thereby improving user experience.

[0245] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0246] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the data processing methods provided in embodiments of this application. For example, the instructions can execute the following steps:

[0247] Obtain the business logic data of the target account in the target application; classify the business logic data to obtain the classified business type data; read the target account's signature certificate, which is obtained by the local terminal after registering data signature permissions with the server, and contains the target account's data signature permissions on the local terminal; sign the business type data according to the data signature permissions in the signature certificate to obtain the target logic data carrying the target signature information; upload the target logic data to the server for storage.

[0248] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0249] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0250] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the data processing methods provided in the embodiments of this application, the beneficial effects that any of the data processing methods provided in the embodiments of this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0251] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations of the above embodiments.

[0252] The data processing method, apparatus, and computer-readable storage medium provided in the embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data processing method, characterized in that, Applied to a local terminal, the method includes: Obtain the business logic data of the target account in the target application; The business logic data is categorized to obtain categorized business type data; The signature certificate of the target account on the local terminal is read from the local terminal. The signature certificate of the target account on the associated primary device and the signature certificate of the target account on the associated secondary device are obtained by the primary device associated with the target account after registering data signature permissions with the server. The signature certificate of the target account on the local terminal contains the data signature permissions of the target account on the local terminal. The local terminal is either the primary device or the associated secondary device of the target account. Based on the data signing permissions in the signature certificate of the target account on the local terminal, a signature permission list is determined, which includes the association between preset business types and signature permissions; Determine the target business type corresponding to the business type data, and match the target business type with the signature permission list; If a preset business type corresponding to the target business type is matched, the business type data is signed according to the signature permission associated with the preset business type to obtain target logical data carrying the target signature information. The target logical data is uploaded to the server for storage. The server includes a database table corresponding to each terminal device of the target account in the associated primary and secondary devices. The database table is used to store the target logical data uploaded by the corresponding terminal device. If no preset business type corresponding to the target business type is matched, the signing of the business type data is stopped, and the business type data that has stopped signing is determined as unsigned data; the unsigned data uploaded to the server is intercepted, and the intercepted unsigned data is deleted.

2. The method according to claim 1, characterized in that, The process of classifying the business logic data to obtain classified business type data includes: Create abstract data corresponding to the business logic data; Extract the target field corresponding to the business logic data from the abstract data, and assign a value to the target field according to the business logic data to obtain the target field value; The business logic data is categorized based on the target field value to obtain categorized business type data.

3. The method according to claim 1, characterized in that, Before reading the signature certificate of the target account on the local terminal from the local terminal, the method further includes: Identify the target account logged into the target application; Request the server to register the data signature permission corresponding to the target account; If the server returns a signature certificate corresponding to the data signature permission, the signature certificate is stored in the storage space associated with the target account on the local terminal.

4. The method according to claim 3, characterized in that, The step of requesting the server to register the data signature permission corresponding to the target account includes: Request the data signature policy from the server; Obtain historical business logic data selected for the target account in the target application, and sign the historical business logic data according to the data signature policy to obtain signature information; The signature information is sent to the server, so that the server registers the data signature permission for the target account based on the signature information.

5. The method according to claim 4, characterized in that, The step of signing the historical business logic data according to the data signature strategy to obtain signature information includes: Generate the account key corresponding to the target account according to the data signature strategy; The historical business logic data is signed using the account key to obtain signature information.

6. The method according to claim 4, characterized in that, After signing the historical business logic data according to the data signature strategy to obtain the signature information, the process further includes: Identify the device permission type of the local terminal; If the device permission type of the local terminal is detected to be primary device permission, a pre-set secondary device permission list is obtained, and when a secondary device identifier is detected in the secondary device permission list, the permission relationship of the signature information is updated according to the secondary device identifier to obtain the updated signature information; Sending the signature information to the server includes sending the updated signature information to the server.

7. The method according to claim 1, characterized in that, Before uploading the target logical data to the server for storage, the method further includes: Obtain the data transmission queue corresponding to the target application in the local terminal; Identify the number of data tasks to be executed in the data transmission queue; The step of uploading the target logical data to the server for storage includes: If the number of data tasks is found to be less than a preset task number threshold, the target logical data is uploaded to the server for storage.

8. The method according to claim 1, characterized in that, Before obtaining the business logic data of the target account in the target application, the process also includes: Detect the business operation process of the target application; Determine the current business operation logic timing of the target application based on the business operation process; The process of obtaining the business logic data of the target account in the target application includes: If the business logic execution time point is detected to reach the preset data upload time point, then the business logic data of the target account in the target application is obtained.

9. The method according to claim 1, characterized in that, After uploading the target logical data to the server for storage, the method further includes: If a startup request for the target application is detected, the target application is launched, and the running process of the launched target application is identified. If the running process is detected to have reached a preset running process time point, the value of the attribution field in the real-time business logic data corresponding to the running process is obtained, and the server is requested to obtain the historical business logic data corresponding to the attribution field value. If the historical business logic data and the real-time business logic data are found to have the same business type, the historical business logic data and the real-time business logic data are merged, and the merged target business logic data is displayed.

10. The method according to claim 1, characterized in that, After uploading the target logical data to the server for storage, the method further includes: If a startup request for the target application is detected, a business prompt request carrying the target account is sent to the server, so that the server determines the logical data to be pushed based on the data upload records of the target account on the local terminal. If the server returns the logic data to be pushed, the target application is launched, and the business prompt label corresponding to the logic data to be pushed is displayed in the target application interface after launch.

11. A data processing apparatus, characterized in that, include: The acquisition unit is used to acquire the business logic data of the target account in the target application. The classification unit is used to classify the business logic data to obtain the classified business type data. The reading unit is used to read the signature certificate of the target account on the local terminal from the local terminal. The signature certificate of the target account on the associated master device and the signature certificate of the target account on the associated secondary device are obtained by the master device associated with the target account after registering data signature permission with the server. The signature certificate of the target account on the local terminal contains the data signature permission of the target account on the local terminal. The local terminal is either the primary device or the secondary device associated with the target account; The signing unit is used to determine a signing permission list based on the data signing permissions in the signing certificate of the target account on the local terminal. The signing permission list contains the association between preset business types and signing permissions. It then determines the target business type corresponding to the business type data and matches the target business type in the signing permission list. If a preset business type corresponding to the target business type is matched, the business type data is signed according to the signing permissions associated with the preset business type to obtain target logical data carrying target signature information. The server includes a database table corresponding to each terminal device of the target account in the associated primary and secondary devices. The database table is used to store the target logical data uploaded by the corresponding terminal device. A processing unit is used to upload the target logical data to the server for storage; The signature unit is further configured to: if no preset business type corresponding to the target business type is matched, stop signing the business type data and determine the business type data that has stopped signing as unsigned data; The unsigned data uploaded to the server is intercepted, and the intercepted unsigned data is deleted.

12. The apparatus according to claim 11, characterized in that, The classification unit is also used for: Create abstract data corresponding to the business logic data; Extract the target field corresponding to the business logic data from the abstract data, and assign a value to the target field according to the business logic data to obtain the target field value; The business logic data is categorized based on the target field value to obtain categorized business type data.

13. The apparatus according to claim 11, characterized in that, The device further includes a registration unit for: identifying a target account logged into the target application; Request the server to register the data signature permission corresponding to the target account; If the server returns a signature certificate corresponding to the data signature permission, the signature certificate is stored in the storage space associated with the target account on the local terminal.

14. The apparatus according to claim 13, characterized in that, The registration unit is also used for: Request the data signature policy from the server; Obtain historical business logic data selected for the target account in the target application, and sign the historical business logic data according to the data signature policy to obtain signature information; The signature information is sent to the server, so that the server registers the data signature permission for the target account based on the signature information.

15. The apparatus according to claim 14, characterized in that, The registration unit is also used for: Generate the account key corresponding to the target account according to the data signature strategy; The historical business logic data is signed using the account key to obtain signature information.

16. The apparatus according to claim 14, characterized in that, The device further includes an updating unit for: Identify the device permission type of the local terminal; If the device permission type of the local terminal is detected to be primary device permission, a pre-set secondary device permission list is obtained, and when a secondary device identifier is detected in the secondary device permission list, the permission relationship of the signature information is updated according to the secondary device identifier to obtain the updated signature information; Then, the registration unit is further configured to: send the updated signature information to the server.

17. The apparatus according to claim 11, characterized in that, The device further includes an identification unit for: Obtain the data transmission queue corresponding to the target application in the local terminal; Identify the number of data tasks to be executed in the data transmission queue; Then, the processing unit is further configured to: if the number of data tasks is less than a preset task number threshold, upload the target logical data to the server for storage.

18. The apparatus according to claim 11, characterized in that, The device further includes a detection unit for: Detect the business operation process of the target application; Determine the current business operation logic timing of the target application based on the business operation process; Then, the acquisition unit is used to: if it is detected that the business operation logic time point reaches the preset data upload time point, then acquire the business logic data of the target account in the target application.

19. The apparatus according to claim 11, characterized in that, The device further includes a data merging unit for: If a startup request for the target application is detected, the target application is launched, and the running process of the launched target application is identified. If the running process is detected to have reached a preset running process time point, the value of the attribution field in the real-time business logic data corresponding to the running process is obtained, and the server is requested to obtain the historical business logic data corresponding to the attribution field value. If the historical business logic data and the real-time business logic data are found to have the same business type, the historical business logic data and the real-time business logic data are merged, and the merged target business logic data is displayed.

20. The apparatus according to claim 11, characterized in that, The device further includes a pushing unit for: If a startup request for the target application is detected, a business prompt request carrying the target account is sent to the server, so that the server determines the logical data to be pushed based on the data upload records of the target account on the local terminal. If the server returns the logic data to be pushed, the target application is launched, and the business prompt label corresponding to the logic data to be pushed is displayed in the target application interface after launch.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the data processing method according to any one of claims 1 to 10.

22. A computing device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and when the processor executes the computer program in the memory, it implements the method as described in any one of claims 1 to 10.

23. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 10.

Images