A data sharing method and related apparatus

By using the first application credential to determine the shared tag in the subject group, the shared data of the target application is obtained and returned, which solves the security and convenience problems of application data sharing in the subject group and realizes the controllability and efficiency of data sharing.

CN117294699BActive Publication Date: 2026-07-03TENCENT TECHNOLOGY (SHENZHEN) CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
TENCENT TECHNOLOGY (SHENZHEN) CO LTD
Filing Date
2022-06-16
Publication Date
2026-07-03

AI Technical Summary

Technical Problem

In a group of entities, how can we achieve secure and convenient sharing of application data, especially addressing the difficulty of easily sharing application data shared by multiple entities across entities?

Method used

By obtaining the data retrieval request of the first subject, using the first application credential to determine the sharing tag of the second subject, obtaining and returning the range of data that the second subject is allowed to share in the target application, the controllable sharing of application data is achieved.

Benefits of technology

It enables secure and convenient application data sharing among subject groups, ensuring that subjects can set the sharing scope according to actual needs, protecting privacy, and improving the security and efficiency of data sharing.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117294699B_ABST
    Figure CN117294699B_ABST
Patent Text Reader

Abstract

The application discloses an application data sharing method and related device. In a subject group including a plurality of subjects, there are a first subject and a second subject, and a target application shared by the plurality of subjects. When the first subject needs to obtain application data of the second subject in the target application, a data retrieval request including a first application credential of the target application corresponding to the second subject is sent. According to the first application credential, a sharing tag of the second subject can be determined, which is used to identify an application data range allowed to be shared by the second subject through the target application. An application program interface is retrieved by the first application credential in the identity of the second subject, and application shared data in the application data range is obtained to return to the target application corresponding to the first subject. Thus, the subjects using the target application can set the shareable application data range based on actual needs, realizing controllability of application data sharing, so that safe and convenient application data sharing is realized on the basis of sharing applications.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to an information sharing method and related apparatus. Background Technology

[0002] With the development of internet social networking, social platforms can provide a group for entities such as enterprises and institutions, allowing multiple related entities to share business-related information within the group.

[0003] Multiple entities within a subject group can use various applications permitted by social platforms to assist in completing various business tasks. However, data generated by these applications or subject data that these applications require is difficult to share conveniently within the subject group.

[0004] Therefore, how to share application-related data in topic groups is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides an application data sharing method and related apparatus, which realizes the controllability of application data sharing, thereby achieving secure and convenient application data sharing based on shared applications.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] On one hand, embodiments of this application provide an application data sharing method, the method comprising:

[0008] Obtain a data retrieval request sent by a first subject, the data retrieval request including a first application credential of a target application corresponding to a second subject, the first subject and the second subject belonging to a subject group including multiple subjects, and the target application being an application shared and used by the multiple subjects in the subject group;

[0009] Based on the first application credential, a sharing tag set by the second subject for the target application is determined, and the sharing tag is used to identify the range of application data that the second subject is allowed to share through the target application;

[0010] By calling the application programming interface using the first application credential, the second subject obtains application-shared data that falls within the application data scope of the target application.

[0011] Return the application-shared data to the target application corresponding to the first entity.

[0012] On the other hand, embodiments of this application provide an application data sharing device, the device including an acquisition unit, a determination unit, and a return unit:

[0013] The acquisition unit is used to acquire a data retrieval request sent by a first subject. The data retrieval request includes a first application credential of a target application corresponding to a second subject. The first subject and the second subject belong to a subject group that includes multiple subjects. The target application is an application that is shared and used by the multiple subjects in the subject group.

[0014] The determining unit is configured to determine, based on the first application credential, a sharing tag set by the second subject for the target application, wherein the sharing tag is used to identify the range of application data that the second subject is allowed to share through the target application;

[0015] The acquisition unit is also used to call the application programming interface through the first application credential to acquire application shared data of the second subject that belongs to the application data range in the target application;

[0016] The return unit is used to return the application-shared data to the target application corresponding to the first subject.

[0017] On the other hand, embodiments of this application provide a computer device, the computer device including a processor and a memory:

[0018] The memory is used to store program code and transmit the program code to the processor;

[0019] The processor is configured to execute the methods described above according to instructions in the program code.

[0020] On the other hand, embodiments of this application provide a computer-readable storage medium for storing a computer program for performing the methods described above.

[0021] On the other hand, embodiments of this application provide a computer program product including instructions that, when run on a computer, cause the computer to perform the methods described above.

[0022] As can be seen from the above technical solution, in a subject group comprising multiple subjects, there are a first subject and a second subject. Within this subject group, the target application is shared by multiple subjects. When the first subject needs to obtain application data from the second subject within the target application, it can send a data retrieval request to the server, including the first application credential of the second subject corresponding to the target application. The server can determine the second subject's sharing tag based on the first application credential. This sharing tag identifies the range of application data that the second subject is allowed to share through the target application. Using the first application credential, the server, as the second subject, retrieves the application-shared data within the range identified by the sharing tag from the target application and returns this data to the target application corresponding to the first subject. Therefore, when sharing a target application within a subject group, to ensure more secure and reliable data sharing based on the target application, the subject using the target application can set the range of shareable application data according to actual needs. Application data that is not intended to be shared can be prevented from being obtained by other subjects, achieving controllability in application data sharing. This enables secure and convenient application data sharing based on shared applications. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0024] Figure 1 This is a schematic diagram of an application data sharing scenario provided in an embodiment of this application;

[0025] Figure 2 A flowchart illustrating an application data sharing method provided in this application embodiment;

[0026] Figure 3 A signaling interaction diagram of an application data sharing method provided in an embodiment of this application;

[0027] Figure 4 An illustration of an authorization process for a shared application provided in an embodiment of this application;

[0028] Figure 5 A schematic diagram of a module for an application data sharing scenario provided in an embodiment of this application;

[0029] Figure 6 This application provides a schematic diagram of the creation of an upstream and downstream group.

[0030] Figure 7A schematic diagram illustrating an invitation to join an upstream or downstream group, provided as an embodiment of this application;

[0031] Figure 8 A schematic diagram of member management in an upstream and downstream group is provided as an embodiment of this application;

[0032] Figure 9 A device structure diagram of an application data sharing device provided in an embodiment of this application;

[0033] Figure 10 A structural diagram of a terminal device provided in an embodiment of this application;

[0034] Figure 11 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0035] The embodiments of this application will now be described with reference to the accompanying drawings.

[0036] With the development of internet social networking, social platforms can provide entities such as enterprises and organizations with a subject group, allowing multiple related entities to share business-related information within the subject group. However, the existing technologies do not yet solve the technical problem of sharing application-related data within subject groups.

[0037] Therefore, this application provides an application data sharing method that achieves controllability in application data sharing, thereby enabling secure and convenient application data sharing based on shared applications.

[0038] The application data sharing method provided in this application embodiment can be implemented through a computer device, which can be a terminal device or a server. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Terminal devices include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, and in-vehicle terminals. Terminal devices and servers can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this connection.

[0039] It is understood that in the specific implementation of this application, user information such as subject identifiers and application shared data are involved. When the above embodiments of this application are applied to specific products or technologies, each item requires separate user permission or consent, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0040] Figure 1A schematic diagram of an application data sharing scenario is shown, in which server 100 is used as the aforementioned computer device for illustration.

[0041] The subject group 200 is maintained by the server 100 and includes multiple subjects, such as the first subject 201 and the second subject 202. In this embodiment, the subjects are non-personal entities, such as enterprises, companies, offices, groups, etc. The subject group is similar to a social group composed of individuals.

[0042] Social groups comprised of multiple personal accounts are a common form of social interaction, such as class groups, department groups, and friend groups. These groups have strong social attributes, facilitating large-scale social interactions among personal accounts. Subject groups, on the other hand, are similar to social groups composed of entities. Compared to social groups composed of multiple individuals, subject groups are more business-oriented and have fewer social attributes. In other words, the purpose of subject groups is to facilitate convenient, large-scale business interactions and information sharing among various entities.

[0043] In subject group 200, the target application (APP) is shared by multiple subjects. That is, through sharing, these multiple subjects can use the target application without purchasing it separately.

[0044] In a subject group scenario based on application sharing, when the first subject 201 in subject group 200 needs to obtain application data of the second subject 202 in a target application, it can send a data retrieval request, including the first application credential of the target application corresponding to the second subject 202, to the server 100 through the terminal device 210 corresponding to the first subject 201. The server 100 can determine the sharing tag of the second subject 202 based on the first application credential. This sharing tag is used to identify the range of application data that the second subject 202 is allowed to share through the target application, such as... Figure 1 In the scenario shown, the rectangular portion represents the application data involved by the second subject 202 through the target application, while the diagonal portion represents the application data range identified by the second subject through the shared tag.

[0045] Server 100 uses the first application credential to call the Application Programming Interface (API) as the second subject 202, retrieves the application shared data within the application data range identified by the shared tag in the target application, and returns the application shared data to the target application corresponding to the first subject 201 (installed in the terminal device 210).

[0046] Therefore, when sharing a target application within a group of entities, in order to achieve more secure and reliable data sharing based on the target application, the entities using the target application can set the scope of application data that can be shared based on actual needs. Application data that they do not want to be shared can be prevented from being obtained by other entities, thus achieving controllability of application data sharing. This enables secure and convenient application data sharing based on shared applications.

[0047] Figure 2 A flowchart of an application sharing method is provided for an embodiment of this application. In this embodiment, a server is used as the aforementioned computer device for description. The method includes:

[0048] S201: Obtain the data retrieval request sent by the first subject.

[0049] The scenario applied in this application embodiment is a subject group, which includes multiple subjects, such as a first subject and a second subject. In addition, it may also include a third or fourth entity, etc. This application does not limit this.

[0050] As mentioned above, in this embodiment, the subject is a non-personal entity, such as a company, office, or group. A subject group is essentially a social group composed of subjects, such as a business group or an upstream / downstream group. However, compared to social groups composed of individuals, subject groups are more business-oriented and have fewer social attributes. In other words, the purpose of subject groups is to facilitate convenient, large-scale business interactions and information sharing among various subjects.

[0051] In a subject group, multiple subjects, such as the first subject and the second subject, share a target application. Through sharing, these multiple subjects can use the target application without having to purchase it separately.

[0052] This application does not limit the relationships between the entities in a subject group. For example, based on business relationships, among multiple entities in a subject group, one entity, such as the first entity, can be an upstream entity of the other entities, and correspondingly, the other entities are downstream entities of the upstream entity. The definition of upstream and downstream can be determined based on the business chain relationship. Another example is that multiple entities in a subject group are at the same level under business relationships, such as being the same type of enterprise.

[0053] When a user uses a target application, it generates corresponding application data, including business data and user data. Business data includes things like transaction records and orders, while the target application also needs to access some of its own user data, such as the user's contact list and other enterprise information.

[0054] This business data can provide reference for other entities in the entity group and facilitate communication and understanding. However, there is currently no convenient sharing channel within the entity group. For example, in some related technologies, target applications are mainly provided by third-party service providers for sharing within the entity group. The application data involved by each entity in the entity group during the use of the target application is obtained by the third-party service provider, making it difficult to use for cross-entity data sharing within the entity group and hindering business collaboration between entities.

[0055] To better facilitate business collaboration among entities within a subject group by leveraging application data from a target application, a convenient and efficient method for sharing application data is needed, particularly in scenarios where multiple entities share the target application. Therefore, this application provides a method for obtaining shared application data using application credentials.

[0056] When the first entity needs to view the application data shared by the second entity through the target application, it can send a data retrieval request to the server, including the first application credentials of the target application corresponding to the second entity.

[0057] The first application credential can reflect the authentication relationship between the second subject and the target application when the second subject shares the target application through the subject group. The first application credential can represent the identity of the second subject in the subject group for the target application. When the first subject can provide the first application credential of the second subject, the server can determine that the first subject and the second subject have reached a consensus. The second subject allows the first subject to obtain the application data involved by the second subject in the subject group through the target application based on the second subject's own identity.

[0058] S202: Determine the shared tag set by the second subject for the target application based on the first application credential.

[0059] Application data used by a subject within a subject group can be shared with other subjects in that group. However, due to subject privacy and confidentiality requirements, different subjects may have different requirements regarding the scope of shared application data. If the scope of shared application data is not restricted, subjects using the target application may be unwilling to share application data due to security concerns, thus refusing to provide their application credentials to other subjects or even using the shared application.

[0060] To address this, this application provides a personalized setting function for the scope of shared data. Different entities can select the scope of shared application data and isolate the scope of data that is not allowed to be shared, based on their own security needs. Taking a second entity as an example, based on the second entity's settings for the scope of application data that is allowed to be shared, a corresponding sharing tag is generated. This sharing tag is used to identify the scope of application data that the second entity allows to be shared through the target application.

[0061] By setting sharing tags, different entities can set the sharing scope based on their own security needs. For different types of application data, they can be set to allow sharing, disallow sharing, or partially allow sharing.

[0062] Taking the enterprise address book in application data as an example, the second entity can set the enterprise address book as application data that is not allowed to be shared, or set the enterprise address book as application data that is allowed to be shared, or set the enterprise address book as partially allowed to be shared, and specify which parts are allowed to be shared, which departments are not allowed to be shared, and even which personnel in which departments are allowed to share, and which personnel are not allowed to share.

[0063] Because users of shared applications can control which application data is allowed to be shared and which is not by setting sharing tags, the information sharing security of the users in the group is effectively protected, and the possibility of privacy and secrets being leaked is avoided. This effectively increases the likelihood that users will agree to share application data when sharing the target application.

[0064] Because the first application credential can identify the second entity's identity in relation to the target application, the server can remember the shared tags associated with the second entity when the first application credential calls them. When the server determines that the first entity needs to obtain application data related to the target application for the second entity, it can determine the shared tags set by the second entity through the first application credential.

[0065] As the business of the second entity and other entities in the entity group progresses, or as its own business adjusts, the scope of application data that can be shared can also be adjusted accordingly. That is, the second entity can change the scope of application data that it allows to share at any time, so that the second entity can adapt to changes in the security of sharing and improve the security and stability of data sharing.

[0066] Therefore, in one possible implementation, the method further includes:

[0067] S11: Obtain the update notification from the second subject regarding the application data range, the update notification being used to indicate that the application data range be updated from the first range to the second range;

[0068] S12: Update the shared tag according to the second scope indicated by the update notification.

[0069] The second scope differs from the first scope. For example, the first scope may restrict the sharing of the company's address book, while the second scope may restrict the sharing of the company's address book.

[0070] This allows the second entity to adapt and adjust the scope of application data in response to changes in shared security, thereby improving the security and stability of data sharing.

[0071] It is important to note that the same entity can join different entity groups. Given that different entity groups include different entities, the business types and requirements involved in different entity groups may also differ. Therefore, even if the same target application is shared in different entity groups, the same entity's data sharing needs will differ in different entity groups. To accommodate the different sharing needs of the same entity for the same target application in different entity groups, in one possible implementation, S202 includes:

[0072] Based on the first application credential and the identifier of the subject group, a sharing tag set by the second subject for the target application in the subject group is determined. The sharing tag is used to identify the range of application data that the second subject is allowed to share in the subject group through the target application.

[0073] For example, the second entity belongs to two entity groups, namely entity group 1 and entity group 2, both of which share the same target application. The second entity can set a sharing tag 1 for the target application in entity group 1 and a sharing tag 2 for the target application in entity group 2. The application data range identified by sharing tag 1 and sharing tag 2 can be different. For example, sharing tag 1 indicates that the enterprise address book is not allowed to be shared, while sharing tag 2 indicates that the enterprise address book is allowed to be shared.

[0074] This allows the same entity to share application data of different scopes under different entity groups for the same target application, flexibly and conveniently adapting to the security needs of the entity.

[0075] S203: By calling the application programming interface through the first application credential, the second subject obtains application-shared data that belongs to the application data scope in the target application.

[0076] Application data used by each subject in the subject group during the use of the target application can be obtained by calling the corresponding API. When it is necessary to call the application data of a subject, such as a second subject, under the target application, the subject must have the application credentials for the target application in order to call the API corresponding to that subject.

[0077] Calling the API using the first application credential is equivalent to converting the identity of the first entity in the target application into that of the second entity to read application-shared data that the second entity is allowed to share through the target application. In other words, the first entity only needs to exchange its application credentials for those of the second entity to transform into a downstream enterprise identity and then read the second entity's application-shared data by calling the corresponding API. After obtaining the application credentials, calling the API is the same as for any ordinary application, resulting in extremely low modification costs to the entity platform of the corresponding entity group, which is highly conducive to the promotion of the data sharing method described in this application.

[0078] S204: Return the application-shared data to the target application corresponding to the first entity.

[0079] The server can return the application-shared data obtained through the API to the target application corresponding to the first entity. The first entity can view the application-shared data by logging into the target application, so that the first entity can more accurately understand the relevant business situation of the second entity based on the application-shared data, which will facilitate subsequent communication and collaboration.

[0080] It should be noted that the first subject can be any subject in the subject group. The above method enables any subject in the subject group to conveniently obtain application-shared data allowed by the second subject through the shared identifier.

[0081] To facilitate the sharing of application-shared data among subject groups, the first subject can also push the acquired application-shared data to other subjects in the subject group. This saves other subjects from having to obtain the application-shared data from the second subject, improving data sharing efficiency and achieving a two-way sharing effect.

[0082] Therefore, in one possible implementation, the method further includes:

[0083] S21: Obtain group-shared data sent by the first subject through the target application, wherein the group-shared data is determined based on application-shared data provided by the second subject;

[0084] S22: Push the group-shared data to the target application of the multiple entities.

[0085] In other words, when the first entity pushes group-shared data to the target applications of multiple entities, other entities in the entity group can directly view the application-shared data of the second entity without needing to separately call the API based on the first application's credentials to obtain the application-shared data. This improves the sharing efficiency of application-shared data and reduces the system's processing resource consumption. For example Figure 3 As shown, the first entity can push group-shared data to the second entity through the server. In addition, the first entity can also conduct data interaction with the second entity based on the target application through the server. Figure 3 (Not shown), no limitation is made here.

[0086] When the first subject is the subject sharing the target application, the first subject can obtain the application-shared data of all subjects in the subject group who agree to use the target application through the aforementioned method, and push it to each subject in the subject group after summarizing and organizing it, thereby achieving efficient two-way sharing of application-shared data.

[0087] In summary, within a subject group comprising multiple entities, there are a first entity and a second entity. The target application is shared by multiple entities within this group. When the first entity needs to access the second entity's application data within the target application, it can send a data retrieval request to the server, including the first application credential corresponding to the second entity's target application. The server, based on the first application credential, determines the second entity's sharing tag. This sharing tag identifies the range of application data that the second entity is allowed to share through the target application. Using the first application credential, the server, as the second entity, retrieves the application-shared data within the range identified by the sharing tag from the target application and returns this data to the first entity's target application. Therefore, when sharing a target application within a subject group, to ensure more secure and reliable data sharing based on the target application, entities using the target application can set the range of shareable application data according to their actual needs. They can prevent other entities from accessing application data they do not wish to share, thus achieving controllability in application data sharing. This enables secure and convenient application data sharing based on shared applications.

[0088] The following section explains the specific implementation method for sharing application data in the scenario of sharing target applications within a main group.

[0089] S31: Based on the identity authentication information of the first subject, return the second application credential corresponding to the target application to the first subject.

[0090] This identity authentication information can be generated when the first entity logs in, and it carries relevant information to prove the first entity's identity with respect to the target application, such as... Figure 3In the scenario shown, the authentication information may include, for example, the subject's identity identifier and password.

[0091] After the server determines the legitimate identity of the first subject relative to the target application through identity authentication information, it can return the second application credentials corresponding to the first subject in the subject group, for example... Figure 3 As shown, the second application credential is used to characterize the application identity of the first subject relative to the target application.

[0092] S32: Obtain the shared authentication request from the first subject.

[0093] The shared authentication request includes the second application credential and the second subject's subject identifier for the target application, for example... Figure 3 As shown. The second application credential, as previously described, is used to identify the legitimate identity of the first entity in relation to the target application. The entity identifier is used to identify the identity information of the second entity in relation to the target application; for example, it could be the enterprise identifier used by the second entity when registering the target application.

[0094] S33: When verifying that the first subject and the second subject are based on the target application shared by the subject group according to the second application credential and the subject identifier, the first application credential is sent to the first subject.

[0095] like Figure 3 As shown, by sharing the information in the authentication request, the server can verify the relationship between the first subject and the second subject based on the second application credential and the subject identifier, that is, whether the first subject and the second subject are in the same subject group, and whether the first subject and the second subject have both completed registration through the target application shared in the subject group.

[0096] When the server determines that the first entity and the second entity are in the same entity group and both are based on the target application shared by the entity group, it can be clearly understood that the first entity and the second entity have made prior negotiations. The second entity agrees that the first entity has the right to obtain its application shared data, or in other words, the first entity has the qualification to obtain the second entity's application shared data. The server will send the first entity a first application credential for obtaining the application shared data, which is the second entity's legitimate identity for the target application.

[0097] Among them, the subject identifier involved in S32 and the first application credential involved in S33 are obtained by the second subject through registration of the target application shared in the subject group.

[0098] In one possible implementation, the method further includes: determining the subject identifier and the corresponding first application credential based on the registration information generated by the second subject for the target application based on the subject group.

[0099] The registration information may include the corresponding enterprise identifier and password. The enterprise identifier can be used as the identity of the second entity. Based on successful registration, a first application credential corresponding to the second entity can be generated to identify the legitimate identity of the second entity for the target application.

[0100] Therefore, the security and reliability of the data sharing process are improved through the above multiple verifications.

[0101] In some related technologies, if multiple companies need to use the same application, each company has to purchase and install it independently, which is actually a redundant and unnecessary purchase and installation process, and is not conducive to the promotion of the application.

[0102] Therefore, this application provides a method for sharing a target application within a subject group, enabling a target application to be shared and used within the group. Aside from requiring purchase before sharing (if the application is provided by a third party), other subjects in the subject group do not need to make any additional purchases when sharing the application, which facilitates promotion of the application through the subject group.

[0103] Next, taking the first subject as an example, we will explain the process of the target application being shared in the subject group.

[0104] It should be noted that the target application used for sharing within the subject group can be an application created by the first subject, such as an application written by the first subject with application creation capabilities or an application outsourced to a third party. Alternatively, the target application can also be an application created by a third party outside the subject group. In this case, the first subject can obtain the right to use the target application through purchase or other means.

[0105] Furthermore, in order to ensure that when the first entity shares the target application within the entity group, other entities, such as the second entity, do not need to purchase the target application separately when using it, the first entity can set usage permissions for the target application within the entity group if the first entity creates the target application itself. If the first entity purchases the target application through a third party outside the entity group, the first entity can purchase the usage rights of multiple entity accounts for the target application at once, so that other entities in the entity group can directly use the shared target application during the sharing process.

[0106] It should also be noted that, regarding the first entity as the entity sharing the target application within the entity group, this application does not limit the relationships between the entities within the entity group. For example, based on business relationships, the first entity among multiple entities in the entity group can be an upstream entity of other entities, and correspondingly, the other entities are downstream entities of the upstream entities. As another example, if multiple entities in the entity group are at the same level under business relationships, such as being the same type of enterprise, in this scenario, the first entity can also share the target application for other entities at the same level.

[0107] S41: Share the target application provided by the first subject with the second subject in the subject group.

[0108] S42: When the sharing authorization message returned by the second subject is obtained, it is determined that the first subject and the second subject share the use of the target application in the subject group. The sharing authorization message is used to identify that the second subject agrees to accept the sharing of the first subject and use the target application.

[0109] The server will display the target application, application A, provided by the first entity in the main group, such as... Figure 4 Part a shows the application interface of the second subject, which displays the aforementioned application A shared by the first subject. The second subject can decide whether to accept the first subject's sharing of application A based on its own needs.

[0110] When a second subject agrees to use application A, a sharing authorization message can be generated. In one possible implementation, the second subject can approve the application data permissions required to use application A, for example... Figure 4 The example shows that a first subject pushes application A to a second subject through a "subject group" as a target application to be shared within the subject group. In order to agree to share application A, permission authorization is required, and there are two types of application data that need to be authorized: employee information and enterprise customer information.

[0111] like Figure 4 In part a, the second entity can be authorized uniformly, and the interface after unified authorization is as follows: Figure 4 As shown in part b, the second entity can also authorize these two data types to be authorized one by one, for example... Figure 4 In the interface shown in section c, the second entity has already separately authorized the enterprise customer data type.

[0112] After authorization, the second entity can use the target application by registration. The data range covered by the authorized data type is within the aforementioned shareable application data range. The second entity can also set and change the shareable application data range at any time based on its own allowed and disallowed shareable application data range. Based on the determination of the allowed and disallowed shareable application data range, the server will obtain the corresponding sharing tag and bind the sharing tag to the second entity and the entity group.

[0113] In one possible implementation, after the second entity completes the registration of the target application, it will generate a corresponding entity identifier. The server can send the entity identifier to the target application of the first entity, so that the first entity can obtain application-shared data within the scope of application data allowed by the second entity based on the target application and the entity identifier.

[0114] It's important to note that the second entity can selectively choose whether to use the target application shared by the first entity. When the second entity agrees to use the application, a sharing authorization message is generated; when the second entity disagrees, a sharing denial message is generated.

[0115] Therefore, in one possible implementation, the method further includes: when the server receives a sharing rejection message returned by the second subject, determining that the second subject refuses to use the target application provided by the first subject in the subject group.

[0116] It is evident that, as the second subject within the main group to which the target application is shared, the subject has a reasonable choice regarding whether to use the target application, thereby improving the applicability of application sharing within the main group.

[0117] Figure 5 This is a schematic diagram of a module for an application data sharing scenario provided in an embodiment of this application. Figure 5 The server is divided into a shared storage management module, a shared logical processing module, and an application storage management module based on its functions.

[0118] In scenarios where the subject groups have an upstream-downstream relationship, the shared storage management module can obtain sharing operations, cancellation operations, and operations to adjust the sharing scope sent by the upstream enterprise (e.g., the first subject) through a client and a management terminal, targeting the target application. The client can be used by an individual within the upstream enterprise, and the management terminal is used by an administrator within the upstream enterprise. Sharing operations are used to share the target application, cancellation operations are used to cancel sharing of the target application within the subject group, and operations to adjust the sharing scope can limit sharing to subjects within the subject group that are eligible to share. For example, the upstream enterprise may only allow three out of eight subjects in the subject group to accept sharing of the target application.

[0119] Downstream enterprise (e.g., a second entity) administrators can authorize data permissions for shared target applications via an H5 page, for example... Figure 4 The situation shown will not be repeated here.

[0120] The shared storage management module can read and write to the shared range storage and shared state storage in the database. The shared range storage records the range of application data that the subject of the shared target application is allowed to share, while the shared state storage records which application data of the subject of the shared target application is allowed to be shared and which is not. This data related to application data sharing can be obtained through the shared logic processing module.

[0121] When a subject in a subject group needs to install or delete a target application, or needs to modify the application scope or workbench name (e.g., application workbench), the server's shared storage management module can forward the above operations to the application storage management module through the shared logic processing module. The application storage management module then completes the response to the above operations by reading and writing to the application storage.

[0122] The application storage management module can also obtain application adjustment operations from upstream enterprise administrators through the application logic processing module, and respond to the application adjustments based on reading the application storage. The application storage management module can also obtain application retrieval operations from downstream enterprise administrators through the application logic processing module, and respond to the application retrieval based on reading the application storage.

[0123] The shared logic processing module can receive various notifications, such as notifications of updates to upstream and downstream address book groups (e.g., changes, additions, deletions, and modifications to groups), notifications of changes to the configuration scope of downstream enterprises in upstream and downstream relationships, notifications of name changes in upstream and downstream relationships, and notifications of disbanding upstream and downstream relationships. When the target application is provided by a third-party service provider, the shared logic processing module can forward these notifications to the third-party service provider processing module. The third-party service provider processing module can also authorize the third-party application (i.e., the target application) for entities within the subject group, such as the first entity.

[0124] The shared logic processing module can also forward notifications related to the target application to the upstream enterprise server through the message callback module.

[0125] Upstream enterprise servers can interact with downstream enterprises by calling their corresponding API modules, such as sending messages, creating meetings, and using Tianjian Calendar.

[0126] Upstream enterprise servers can use the application credentials of downstream enterprises to instruct the server to call the corresponding API module of the downstream enterprise, thereby obtaining application sharing data that the downstream enterprise is allowed to share. In addition, upstream enterprise servers can also push the organized group sharing data to downstream enterprises through the API module.

[0127] The following example uses upstream and downstream groups as examples of main groups in this application, with the upstream enterprise as the first entity, to illustrate the creation process of upstream and downstream groups. For example... Figure 6 As shown in section a, the first entity can initiate the creation of upstream and downstream groups by triggering the "Create Upstream and Downstream" control, after which the page will redirect to... Figure 6 In part b, the first entity can enter the group name of the upstream and downstream groups to be created, such as "Company A's Suppliers" (e.g., Figure 6 As shown in section c), after entering the group name, you can trigger the creation control to complete the creation of upstream and downstream groups, for example... Figure 6 As shown in part d.

[0128] After creating the upstream and downstream groups, the first entity can be based on the upstream and downstream relationship, for example, by triggering... Figure 6 The control in section d that invites upstream and downstream contacts allows users to invite downstream companies to join the upstream and downstream group, such as... Figure 7 Part A can be accessed through social media invitations, QR code invitations, or by importing existing upstream and downstream lists. Invitations via social media include... Figure 7 In part b, the social media chat interface of the second contact displays an icon inviting them to join the "Company A's Suppliers" upstream and downstream group. The contact can join this group by triggering this icon. For example... Figure 7 The c section shows the QR code invitation method.

[0129] When Company B, as the second entity, joins the upstream and downstream group of "Company A's suppliers," Company A, as the first entity, can... Figure 8 The page shown in section A displays group information, and then you will be redirected to... Figure 8 On the page shown in section b, Company A can view its members that can contact other companies, such as... Figure 8 As shown in section c, there are three individuals: Zhang, Wang, and Li, and two departments: the sales department and the finance department. Company A can manage its members in upstream and downstream groups, such as deleting and adding members. Figure 8 The page shown in section d removes Xiao Li from the list of members who can contact other companies by triggering the removal control.

[0130] By creating a subject group, the first subject can share the target application within the subject group. Other subjects in the subject group can share the target application with the first subject. Then, through the application data sharing method provided in this application embodiment, the application data involved in the target application can be shared quickly and conveniently within the subject group, greatly improving the business promotion capability of the subject group and facilitating the promotion of the subject group.

[0131] Based on the foregoing embodiments, Figure 9 This is a structural diagram of an application data sharing device 900 provided in an embodiment of this application. The application data sharing device 900 includes an acquisition unit 901, a determination unit 902, and a return unit 903.

[0132] The acquisition unit 901 is used to acquire a data retrieval request sent by a first subject. The data retrieval request includes a first application credential of a target application corresponding to a second subject. The first subject and the second subject belong to a subject group that includes multiple subjects. The target application is an application that is shared and used by the multiple subjects in the subject group.

[0133] The determining unit 902 is configured to determine, based on the first application credential, a sharing tag set by the second subject for the target application, wherein the sharing tag is used to identify the range of application data that the second subject is allowed to share through the target application.

[0134] The acquisition unit 901 is further configured to call the application programming interface through the first application credential to acquire application shared data of the second subject that belongs to the application data range in the target application;

[0135] The return unit 903 is used to return the application-shared data to the target application corresponding to the first subject.

[0136] In one possible implementation, the determining unit is further configured to:

[0137] Based on the first application credential and the identifier of the subject group, a sharing tag set by the second subject for the target application in the subject group is determined. The sharing tag is used to identify the range of application data that the second subject is allowed to share in the subject group through the target application.

[0138] In one possible implementation, the acquisition unit is further configured to:

[0139] Obtain an update notification from the second subject regarding the application data range, the update notification indicating that the application data range be updated from a first range to a second range;

[0140] The shared tag is updated according to the second scope indicated in the update notification.

[0141] In one possible implementation, the return unit is further configured to return a second application credential corresponding to the target application to the first subject based on the identity authentication information of the first subject;

[0142] The acquisition unit is further configured to acquire the shared authentication request of the first subject, the shared authentication request including the second application credential and the subject identifier of the second subject for the target application; when it is verified that the first subject and the second subject are sharing the target application based on the subject group according to the second application credential and the subject identifier, the first application credential is sent to the first subject.

[0143] In one possible implementation, the determining unit is further configured to determine the subject identifier and the corresponding first application credential based on the registration information generated by the second subject for the target application based on the subject group.

[0144] In one possible implementation, the device further includes a sharing unit for:

[0145] The target application provided by the first subject is shared with the second subject within the subject group;

[0146] When the sharing authorization message returned by the second subject is obtained, it is determined that the first subject and the second subject share the use of the target application in the subject group. The sharing authorization message is used to identify that the second subject agrees to accept the sharing of the first subject and use the target application.

[0147] In one possible implementation, the return unit is further configured to forward the subject identifier of the second subject for the target application to the target application of the first subject, wherein the subject identifier is determined by the second subject's registration of the target application.

[0148] In one possible implementation, the determining unit is further configured to determine, when the second subject returns a sharing rejection message, that the second subject refuses to use the target application provided by the first subject in the subject group.

[0149] In one possible implementation, the target application is an application created by the first subject, or an application created by a third party outside the subject group.

[0150] In one possible implementation, based on business relationships, the first entity in the group of entities is an upstream entity of the other entities.

[0151] In one possible implementation, the acquisition unit is further configured to acquire group-shared data sent by the first subject through the target application, the group-shared data being determined based on application-shared data provided by the second subject;

[0152] The return unit is also used to push the group-shared data to the target application of the multiple subjects.

[0153] Therefore, in a subject group comprising multiple entities, there are a first entity and a second entity. Within this subject group, the target application is shared by multiple entities. When the first entity needs to access the second entity's application data within the target application, it can send a data retrieval request to the server, including the second entity's first application credentials for the target application. The server, based on the first application credentials, can determine the second entity's sharing tag. This sharing tag identifies the range of application data that the second entity is allowed to share through the target application. Using the first application credentials, the server, as the second entity, retrieves the application-shared data within the range identified by the sharing tag from the target application and returns this data to the first entity's target application. Thus, when sharing a target application within a subject group, to ensure more secure and reliable data sharing based on the target application, entities using the target application can set the range of shareable application data according to their actual needs. They can prevent other entities from accessing application data they do not wish to share, achieving controllability in application data sharing. This enables secure and convenient application data sharing based on shared applications.

[0154] This application also provides a computer device, which is the computer device described above, and may include a terminal device or a server. The aforementioned application data sharing device may be configured in this computer device. The computer device will now be described in conjunction with the accompanying drawings.

[0155] If the computer device is a terminal device, please refer to Figure 10 As shown, this application provides a terminal device, taking a mobile phone as an example:

[0156] Figure 10 This diagram illustrates a partial structural representation of a mobile phone related to the terminal device provided in this embodiment. (Reference) Figure 10 The mobile phone includes components such as a radio frequency (RF) circuit 1410, a memory 1420, an input unit 1430, a display unit 1440, a sensor 1450, an audio circuit 1460, a Wi-Fi module 1470, a processor 1480, and a power supply 1490. Those skilled in the art will understand that... Figure 10The mobile phone structure shown does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0157] The following is combined Figure 10 A detailed introduction to each component of a mobile phone:

[0158] The RF circuit 1410 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 1480; in addition, it transmits uplink data to the base station.

[0159] The memory 1420 can be used to store software programs and modules. The processor 1480 executes various mobile phone functions and data processing by running the software programs and modules stored in the memory 1420. The memory 1420 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications 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 mobile phone (such as audio data, phonebook, etc.). In addition, the memory 1420 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.

[0160] The input unit 1430 can be used to receive input numeric or character information, and to generate key signal inputs related to user settings and function control of the mobile phone. Specifically, the input unit 1430 may include a touch panel 1431 and other input devices 1432.

[0161] The display unit 1440 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile phone. The display unit 1440 may include a display panel 1441.

[0162] The mobile phone may also include at least one sensor 1450, such as a light sensor, a motion sensor, and other sensors.

[0163] Audio circuitry 1460, speaker 1461, and microphone 1462 provide an audio interface between the user and the mobile phone.

[0164] WiFi is a short-range wireless transmission technology. Through the WiFi module 1470, mobile phones can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access.

[0165] The processor 1480 is the control center of the mobile phone. It connects to various parts of the mobile phone through various interfaces and lines. It performs various functions of the mobile phone and processes data by running or executing software programs and / or modules stored in the memory 1420 and calling data stored in the memory 1420.

[0166] The phone also includes a power supply 1490 (such as a battery) that powers the various components.

[0167] In this embodiment, the processor 1480 included in the terminal device also has the following functions:

[0168] Obtain a data retrieval request sent by a first subject, the data retrieval request including a first application credential of a target application corresponding to a second subject, the first subject and the second subject belonging to a subject group including multiple subjects, and the target application being an application shared and used by the multiple subjects in the subject group;

[0169] Based on the first application credential, a sharing tag set by the second subject for the target application is determined, and the sharing tag is used to identify the range of application data that the second subject is allowed to share through the target application;

[0170] By calling the application programming interface using the first application credential, the second subject obtains application-shared data that falls within the application data scope of the target application.

[0171] Return the application-shared data to the target application corresponding to the first entity.

[0172] If the computer device is a server, this application embodiment also provides a server; please refer to [link to relevant documentation]. Figure 11 As shown, Figure 11 This is a structural diagram of a server 1500 provided in an embodiment of this application. The server 1500 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 1522 (e.g., one or more processors) and memory 1532, and one or more storage media 1530 (e.g., one or more mass storage devices) for storing application programs 1542 or data 1544. The memory 1532 and storage media 1530 can be temporary or persistent storage. The program stored in the storage media 1530 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1522 may be configured to communicate with the storage media 1530 and execute the series of instruction operations in the storage media 1530 on the server 1500.

[0173] Server 1500 may also include one or more power supplies 1526, one or more wired or wireless network interfaces 1550, one or more input / output interfaces 1558, and / or one or more operating systems 1541, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0174] The steps performed by the server in the above embodiments can be based on Figure 11 The server structure shown.

[0175] In addition, this application embodiment also provides a storage medium for storing a computer program for executing the method provided in the above embodiment.

[0176] This application also provides a computer program product including instructions that, when run on a computer, cause the computer to perform the methods provided in the above embodiments.

[0177] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium can be at least one of the following media: read-only memory (ROM), RAM, magnetic disk or optical disk, and other media that can store program code.

[0178] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0179] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Moreover, based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An application data sharing method, characterized by, The method includes: Obtain a data retrieval request sent by a first subject, the data retrieval request including a first application credential of a target application corresponding to a second subject, the first subject and the second subject belonging to a subject group including multiple subjects, and the target application being an application shared and used by the multiple subjects in the subject group; Based on the first application credential, a sharing tag set by the second subject for the target application is determined, and the sharing tag is used to identify the range of application data that the second subject is allowed to share through the target application; By calling the application programming interface using the first application credential, the second subject obtains application-shared data that falls within the application data scope of the target application. Return the application-shared data to the target application corresponding to the first entity.

2. The method of claim 1, wherein, The step of determining the shared tag set by the second subject for the target application based on the first application credential includes: Based on the first application credential and the identifier of the subject group, a sharing tag set by the second subject for the target application in the subject group is determined. The sharing tag is used to identify the range of application data that the second subject is allowed to share in the subject group through the target application.

3. The method of claim 1, wherein, The method further includes: Obtain an update notification from the second subject regarding the application data range, the update notification indicating that the application data range be updated from a first range to a second range; The shared tag is updated according to the second scope indicated in the update notification.

4. The method according to claim 1, characterized in that, The method further includes: Based on the identity authentication information of the first entity, return the second application credential corresponding to the target application to the first entity; Obtain the shared authentication request of the first subject, wherein the shared authentication request includes the second application credential and the subject identifier of the second subject for the target application; When the first subject and the second subject are verified to be sharing the target application based on the subject group according to the second application credential and the subject identifier, the first application credential is sent to the first subject.

5. The method of claim 4, wherein, The method further includes: Based on the registration information generated by the second subject for the target application based on the subject group, the subject identifier and the corresponding first application credential are determined.

6. The method according to any one of claims 4-5, characterized in that, The method further includes: The target application provided by the first subject is shared with the second subject within the subject group; When the sharing authorization message returned by the second subject is obtained, it is determined that the first subject and the second subject share the use of the target application in the subject group. The sharing authorization message is used to identify that the second subject agrees to accept the sharing of the first subject and use the target application.

7. The method of claim 6, wherein, The method further includes: The second subject forwards the subject identifier for the target application to the first subject's target application, the subject identifier being determined through the second subject's registration with the target application.

8. The method of claim 6, wherein, The method further includes: When a sharing rejection message is received from the second subject, it is determined that the second subject refuses to use the target application provided by the first subject in the subject group.

9. The method of claim 6, wherein, The target application is an application created by the first subject, or an application created by a third party outside the subject group.

10. The method of claim 6, wherein, Based on business relationships, among the multiple entities in the entity group, the first entity is the upstream entity of the other entities.

11. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain group-shared data sent by the first subject through the target application, wherein the group-shared data is determined based on application-shared data provided by the second subject; The group-shared data is pushed to the target application of the multiple entities.

12. An application data sharing apparatus characterized by comprising: The device includes an acquisition unit, a determination unit, and a return unit: The acquisition unit is used to acquire a data retrieval request sent by a first subject. The data retrieval request includes a first application credential of a target application corresponding to a second subject. The first subject and the second subject belong to a subject group that includes multiple subjects. The target application is an application that is shared and used by the multiple subjects in the subject group. The determining unit is configured to determine, based on the first application credential, a sharing tag set by the second subject for the target application, wherein the sharing tag is used to identify the range of application data that the second subject is allowed to share through the target application; The acquisition unit is also used to call the application programming interface through the first application credential to acquire application shared data of the second subject that belongs to the application data range in the target application; The return unit is used to return the application-shared data to the target application corresponding to the first subject.

13. The apparatus of claim 12, wherein, The determining unit is specifically used for: Based on the first application credential and the identifier of the subject group, a sharing tag set by the second subject for the target application in the subject group is determined. The sharing tag is used to identify the range of application data that the second subject is allowed to share in the subject group through the target application.

14. The apparatus of claim 12, wherein, The acquisition unit is further configured to: Obtain an update notification from the second subject regarding the application data range, the update notification indicating that the application data range be updated from a first range to a second range; The shared tag is updated according to the second scope indicated in the update notification.

15. The apparatus of claim 12, wherein, The return unit is further configured to return a second application credential corresponding to the target application to the first subject based on the identity authentication information of the first subject; The acquisition unit is further configured to acquire the shared authentication request of the first subject, the shared authentication request including the second application credential and the subject identifier of the second subject for the target application; when it is verified that the first subject and the second subject are sharing the target application based on the subject group according to the second application credential and the subject identifier, the first application credential is sent to the first subject.

16. The apparatus of claim 15, wherein, The determining unit is further configured to determine the subject identifier and the corresponding first application credential based on the registration information generated by the second subject for the target application based on the subject group.

17. A computer device, comprising: The computer device includes a processor and memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the application data sharing method according to any one of claims 1-11 according to the instructions in the program code.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for executing the application data sharing method according to any one of claims 1-11.

19. A computer program product including instructions that, when run on a computer, cause the computer to perform the application data sharing method according to any one of claims 1-11.