Data sharing method, electronic equipment and storage medium

Abstract

The invention provides a method for sharing data among multiple service systems, electronic equipment and a computer storage medium, belongs to the technical field of data sharing, and can solve the problems of high cost and poor security of an existing centralized summarization platform. According to the method for sharing the data among the multiple service systems, the processes of mutual authentication, data encryption transmission, user unique identification and the like among the multiple service systems are realized by utilizing an innovative data circulation mode, multiple encryption, a tamper-resistant storage technology and the like, and meanwhile, shared records are uniformly stored to a server platform in a tamper-resistant mode; and a standard, efficient and traceable data sharing solution is formed.

Description

Data sharing method, electronic device and storage medium Technical Field

[0001] The present disclosure belongs to the technical field of data sharing, and in particular relates to a method, electronic device, and computer-readable storage medium for sharing data among multiple business systems. Background Art

[0002] With the rapid development of computer and information technology, enterprises and institutions have an increasing demand for data, with increasingly demanding and constantly changing requirements. Furthermore, enterprises and institutions often need to collaborate with each other, which necessitates data sharing. For example, Company A's data can be shared with Company B.

[0003] Existing data sharing technologies lack mutual authentication between two or more parties involved in the data sharing process, making it impossible to prevent data leaks caused by malicious intrusion and theft. Furthermore, storing all shareable data on a single server or in the cloud can make this "sharing center" complex and redundant in practice as data volumes increase, requiring a corresponding increase in network and server resources. Furthermore, the diverse data sources make subsequent operational integration and maintenance costs extremely high.

[0004] Summary of the Invention

[0005] The present invention aims to solve at least one of the technical problems existing in the prior art and provide a method, electronic device and computer-readable storage medium for data sharing among multiple business systems with low cost, high data timeliness and security.

[0006] In a first aspect, the technical solution adopted to solve the technical problem of the present invention is a method for data sharing between multiple business systems, wherein the business system that sends the user data request in the multiple business systems is a first business system, and the business system that receives the user data request is a second business system. The method is applied to a server platform and includes:

[0007] Receiving a user public key, a data request public key, and a user data request sent by the first business system;

[0008] Sending the user data request, user public key, data request public key, and server platform public key to the second business system based on the data request public key, so that the second business system performs a data query and encrypts the data in the order of the data request public key, the server platform public key, and the user public key to obtain second shared data, and sends the second shared data to the first business system;

[0009] Receive the third shared data sent by the first business system, decrypt the third shared data based on the server platform private key, and return it to the first business system; wherein,

[0010] The third shared data is obtained by the first business system decrypting the second shared data based on the data request private key.

[0011] In some embodiments, the method further comprises:

[0012] After sending the user data request, user public key, data request public key and server platform public key to the second business system, first relevant information of the user data request event is recorded.

[0013] In some embodiments, the method further comprises:

[0014] After decrypting the third shared data based on the server platform private key and returning it to the first business system, second relevant information of the user data request event is recorded.

[0015] In some embodiments, the method further comprises:

[0016] receiving an association request from the first business system;

[0017] A data request key pair for the first business system is created based on the association request and synchronized to the first business system, wherein the data request key pair includes a data request public key and a data request private key.

[0018] In some embodiments, the method further includes: recording basic information of the first business system, where the basic information of the first business system includes the name of the first business system and a data request public key and a data request private key.

[0019] In some embodiments, the method further comprises:

[0020] determining whether the first business system is associated with the server platform based on the data request public key;

[0021] If the first business system is associated with the server platform, the user data request, user public key, data request public key and server platform public key are sent to the second business system.

[0022] In some embodiments, the method further includes: generating a first transaction voucher by a hash algorithm based on the first relevant information; and / or

[0023] A second transaction voucher is generated based on the second relevant information through a hash algorithm.

[0024] In a second aspect, an embodiment of the present disclosure further provides a method for data sharing between multiple business systems, wherein the business system that sends the user data request in the multiple business systems is a first business system, and the business system that receives the user data request is a second business system. The method is applied to the first business system, and the method includes:

[0025] Sending the user data request, the user public key, and the data request public key to the server platform, so that the server platform sends the user data request, the user public key, the data request public key, and the server platform public key to the second business system;

[0026] receiving the second shared data sent by the second business system, performing a first-layer decryption on the second shared data based on the data request private key, and sending the decrypted data to the server platform, so that the server platform performs a second-layer decryption on the second shared data that has been decrypted by the first layer, wherein:

[0027] The second shared data is obtained by the second business system performing a data query based on the user data request and performing three-layer encryption in the order of the data request public key, the server platform public key, and the user public key;

[0028] The second shared data for second-layer decryption sent by the server platform is received, and the third-layer decryption is performed based on the user private key.

[0029] In some embodiments, the first business system stores a correspondence between a user's first business system account and a user key pair, the user key pair including a user public key and a user private key, and the method further includes:

[0030] Receive the user's first business system account;

[0031] Based on the first business system account of the user through the correspondence between the first business system account of the user and the user public key, the user public key of the user is determined and a user data request is generated.

[0032] In some embodiments, determining the user public key of the user and generating the user data request based on the first business system account of the user through the correspondence between the first business system account of the user and the user key pair includes:

[0033] Determine whether the user's first business system account has a corresponding user key pair,

[0034] If so, determining the user public key of the user and generating a user data request;

[0035] Otherwise, determine whether the second business system account of the user has a corresponding user key pair, obtain a first judgment result, determine the user public key of the user based on the first judgment result, and generate a user data request.

[0036] In some embodiments, determining the user public key of the user based on the first judgment result and generating the user data request includes:

[0037] If the second business system account of the user does not have a corresponding user key pair, create a user key pair corresponding to the first business system account, determine the user public key, and generate a user data request;

[0038] If the second business system account of the user has a corresponding user key pair, determining whether to associate the corresponding user key pair of the second business system account of the user with the first business system account, and obtaining a second determination result;

[0039] Based on the second judgment result, a user public key of the user is determined and a user data request is generated.

[0040] In some embodiments, when a corresponding user key pair exists for the user's first business system account, determining the user's public key and generating a user data request include:

[0041] Determining whether the user's private key is escrow or whether the user carries the user's private key;

[0042] When the user private key of the user is not escrowed and the user private key is not carried, determining whether the user carries a key pair corresponding to the second business system account, and obtaining a third determination result;

[0043] Based on the third judgment result, a user public key of the user is determined and a user data request is generated.

[0044] In some embodiments, determining the user public key of the user based on the third judgment result and generating the user data request includes:

[0045] If the user does not carry the user key pair corresponding to the second business system account, create a user key pair corresponding to the first business system account, determine the user public key, and generate a user data request;

[0046] If the user carries a user key pair corresponding to the second business system account, determining whether to associate the user key pair corresponding to the second business system account of the user with the first business system account to obtain a second determination result;

[0047] Based on the second judgment result, a user public key of the user is determined and a user data request is generated.

[0048] In some embodiments, determining the user public key of the user based on the second judgment result and generating the user data request includes:

[0049] If the user key pair corresponding to the second business system account of the user is not associated with the first business system account, create a user key pair corresponding to the first business system account, determine the user public key, and generate a user data request;

[0050] If the user key pair corresponding to the second business system account of the user is associated with the first business system account, the user public key is determined and a user data request is generated.

[0051] In some embodiments, if the user key pair corresponding to the second business system account of the user is associated with the first business system account, determining the user public key and generating a user data request include:

[0052] Determining whether the user carries the user public key corresponding to the second business system account;

[0053] If so, the user's public key is determined and a user data request is generated;

[0054] Otherwise, create a user key pair corresponding to the first business system account, determine the user public key, and generate a user data request.

[0055] In some embodiments, the method further comprises:

[0056] Based on the user's first instruction, modify the state of the user's private key;

[0057] Based on the modified state of the user private key, it is determined whether the user private key of the user is in escrow or whether the user carries the user private key.

[0058] In some embodiments, modifying the state of the user's private key based on the user's first instruction includes:

[0059] When the user's first instruction is to change the user's private key from "no escrow" to "escrow", determining whether the user carries the user's private key;

[0060] If yes, the current user private key status is modified, otherwise it cannot be modified.

[0061] In a third aspect, an embodiment of the present disclosure further provides a method for data sharing between multiple business systems, wherein the system sending the user data request in the multiple business systems is a first business system, and the business system receiving the user data request is a second business system. The method is applied to the second business system, and the method includes:

[0062] Receive user data request, user public key, data request public key and server platform public key sent by the server platform;

[0063] determining the identity of the user based on the user public key, and determining first shared data based on the user data request;

[0064] The first shared data is encrypted in three layers in the order of the data request public key, the server platform public key and the user public key to obtain the second shared data, and sent to the first business system; so that the first business system performs a first-layer decryption on the second shared data based on the data request private key, and sends it to the server platform, so that the server platform performs a second-layer decryption based on the server platform private key, and returns it to the first business system, so that the first business system performs a third-layer decryption based on the user private key.

[0065] In a fourth aspect, an embodiment of the present disclosure further provides an electronic device, comprising:

[0066] processor;

[0067] A memory for storing processor-executable instructions, wherein

[0068] The processor is configured to call the instructions stored in the memory to execute the method described in any embodiment of the first aspect, the second aspect and the third aspect.

[0069] In a fifth aspect, an embodiment of the present disclosure further provides a computer-readable storage medium on which is stored a computer program code for data sharing between multiple business systems. When the computer program code is executed by a processor, the method described in any one of the embodiments of the first, second and third aspects above is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] FIG1 is a schematic diagram of a shared alliance based on a multi-service system provided by an embodiment of the present disclosure;

[0071] FIG2 is a flow chart of data sharing between multiple business systems provided by an embodiment of the present disclosure;

[0072] FIG3 is a schematic diagram of binding various business systems to user public keys according to an embodiment of the present disclosure;

[0073] FIG4 is a schematic diagram of a corresponding relationship between a business system and a plug-in BA provided in an embodiment of the present disclosure;

[0074] FIG5 is a flowchart of another method of data sharing between multiple business systems provided by an embodiment of the present disclosure;

[0075] FIG6 is a flow chart of determining a user's public key according to an embodiment of the present disclosure;

[0076] FIG7 is a flow chart of modifying a user's private key according to an embodiment of the present disclosure;

[0077] FIG8 is a flowchart of another method of data sharing between multiple business systems provided by an embodiment of the present disclosure;

[0078] FIG9 is a flow chart of a method for sharing data between multiple business systems provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0079] In order to enable those skilled in the art to better understand the technical solution of the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0080] Unless otherwise defined, the technical or scientific terms used in this disclosure should have the usual meanings understood by people with ordinary skills in the field to which this disclosure belongs. The words "first", "second" and similar words used in this disclosure do not indicate any order, quantity or importance, but are only used to distinguish different components. Similarly, words such as "one", "an" or "the" do not indicate a quantity limitation, but rather indicate the existence of at least one. Words such as "include" or "comprise" mean that the elements or objects appearing before the word include the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Words such as "connect" or "connected" are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the object being described changes, the relative positional relationship may also change accordingly.

[0081] In real life, there are demands for integrating data from multiple business systems, such as viewing monthly online shopping and taxi spending limits and order details, or for doctors to view all patient visits or health records. These demands typically involve multiple applications (apps) or backend data from different entities. For reasons of business protection, data privacy, and security, it is generally difficult for entities to open up their data to each other. Even if data can be shared between entities, since user information may differ across multiple entities, technical difficulties such as identifying unique users across entities (connecting the primary indexes of each entity) remain, resulting in a significant workload.

[0082] FIG1 is a schematic diagram of a sharing alliance based on multiple business systems provided by an embodiment of the present disclosure. As shown in FIG1 , the sharing alliance includes multiple business systems and at least one server platform 30. Each business system in the multiple business systems can share data with other business systems in the sharing alliance in real time through the server platform 30. Each business system in the sharing alliance can act as a data requester to send data requests to one or more other business systems and enjoy the right to retrieve information from each other; similarly, each business system in the sharing alliance can also act as a data sharing party, with the obligation to maintain the high quality of the data of its own business system, and the obligation to provide high-quality data to one or more other business systems.

[0083] Compared with the centralized data aggregation platform, the shared alliance provided by the embodiment of the present disclosure allows each business system to have certain rights to access information as a rights holder, and at the same time, as an obligor, to provide the required data to other business systems, which gives them more motivation to maintain data quality.

[0084] FIG2 is a flowchart of a method for sharing data between multiple business systems according to an embodiment of the present disclosure. This method can be used in the sharing alliance shown in FIG1 . As shown in FIG2 , the present embodiment uses the business system that sends a user data request in the multiple business systems as the first business system 20, and the business system that receives the user data request as the second business system 20. The method is applied to a server platform 30 and includes:

[0085] S201: Receive a user public key, a data request public key, and a user data request sent by the first business system 10.

[0086] S202: Based on the data request public key, the user data request, user public key, data request public key and server platform public key are sent to the second business system 20, so that the second business system 20 performs data query and encrypts in the order of data request public key, server platform public key and user public key to obtain the second shared data and send it to the first business system 10.

[0087] S203 : Receive the third shared data sent by the first business system 10 , and decrypt the third shared data based on the server platform private key to obtain fourth shared data; and return the fourth shared data to the first business system 10 .

[0088] The third shared data is obtained by the first business system 10 decrypting the second shared data based on the data request private key.

[0089] Specifically, the user public key is used to confirm the unique identity of a user across multiple business systems (the first business system 10 and the second business system). The same user may use different personal information to register corresponding business system accounts in different business systems. For example, user A uses a mobile phone number to register an account in the first business system 10, and uses an ID number to register an account in the second business system 20. Or user A's username in the first business system 10 is a, and user A's username in the second business system 20 is b. To determine whether the users in the first business system 10 and the second business system 20 are the same user, each user is uniquely assigned a user public key, and the same user public key is used in each business system. Between users and business systems, business system accounts or usernames are used for mutual recognition, while between multiple business systems, user public keys are used to confirm the same user. Among them, the user's user public key can be created by any business system and bound to one or more other business systems. Between business systems to which the user public key is bound, the user public key can be used for mutual recognition between the business system and the user.

[0090] For example, a sharing alliance includes business systems A, B, C, D, E, and F. Business system A is the first business system 10, and the other business systems are the second business system 20. Business system A uses a user public key to bind to business systems A, B, C, and D. This allows business system A to share data with business systems A, B, C, and D, but not with business systems E and F, which have not been bound to user public keys. Specifically, based on user privacy requirements, the first business system 10 can be bound to one or more of the second business system 20 through user public key binding to enable data sharing between multiple business systems.

[0091] Figure 3 is a schematic diagram of binding various business systems to user public keys according to an embodiment of the present disclosure. As shown in Figure 3, user X uses the same user public key across various business systems.

[0092] It should be noted that a user can have multiple user public keys in a shared alliance. Business systems that use the same user public key for user public key binding can use the same user public key for mutual recognition between the business system and the user. In this way, different data information can be shared between different business systems based on user needs. For example, user A has user public key 1 and user public key 2, where the shared alliance includes business system A, business system a, business system b, business system c, business system d, business system e, and business system f. Among them, business system A is the first business system 10, and the other business systems are the second business system 20. Business system A uses user public key 1 to bind with business system a, business system b, business system c, and business system d to achieve data sharing of information 1; business system A uses user public key 2 to bind with business system a, business system c, business system e, and business system f to achieve data sharing of information 2.

[0093] In some embodiments, when the same user has multiple sets of user public keys, the first business system 10 selects the currently required user public key according to the user's instructions and sends the required user public key to the server platform 30 to achieve data sharing of the information required by the current user.

[0094] The data request public key is used to verify the identity of the first business system 10. The server platform 30 uses the data request public key to confirm whether the first business system 10 is a member of the shared alliance. Different business systems should have their own independent data request key pair and cannot be used interchangeably. This data request key pair plays a vital role in mutual recognition between the business system and the server platform 30, as well as in the data decryption process (data decryption will be discussed in detail below).

[0095] The server platform public key is used to confirm the identity of the server platform 30. Multiple server platforms 30 can exist simultaneously within a shared alliance, facilitating business expansion and regulatory oversight. Each server platform 30 corresponds to a server platform public key. During data sharing between the first business system 10 and the second business system 20, the server platform 30's identity is confirmed using the server platform public key.

[0096] User data request refers to the shared data required by the user, including but not limited to the indicators to be queried, time range, etc.

[0097] The entire process of data sharing between the first business system 10 and the second business system 20 is as follows:

[0098] The first business system 10 receives the user's personal information, which can be the user's first business system account number, the user's username in the first business system, or other personal information. Based on the user's personal information, the first business system 10 determines the user's public key, allowing the first business system 10 to confirm whether the user is a registered user in the first business system 10. The first business system 10 then generates a corresponding user data request based on the user's instructions. Finally, the first business system 10 sends the user's public key, data request public key, and user data request to the server platform 30.

[0099] After the server platform 30 receives the user public key, data request public key and user data request sent by the first business system 10, it first determines whether the first business system 10 has joined the shared system where the server platform 30 is located based on the data request public key. After determining the identity of the first business system 10, it sends the user data request, user public key, data request public key and server platform public key to the second business system 20.

[0100] The second business system 20 determines the identity of the user based on the user public key, and determines whether the user has corresponding personal information in the second business system 20, such as the second business system account or the user name corresponding to the second business system. If the user has corresponding personal information in the second business system 20, it means that the user has been registered in the second business system 20, and the user information exists in the second business system 20. Based on the user data request, a data query is performed to determine the first shared data, wherein the first shared data is the shared data corresponding to the user data request obtained by the second business system 20.

[0101] To ensure the security of shared data during transmission, during data transmission, the first shared data is encrypted using three layers of encryption, in the order of the data request public key, the server platform public key, and the user public key, to obtain the second shared data, which is then sent to the first business system 10. Furthermore, in the disclosed embodiment, the second business system 20 directly sends the second shared data to the first business system 10. Compared to the prior art, where the second business system 20, a centralized data aggregation platform, regularly updates or uploads data to the transaction center 30, and the first business system 10 then obtains the required data from the transaction center 30, the data sharing method in the disclosed embodiment is more timely and secure.

[0102] After receiving the second shared data sent by the second business system 20 , the first business system 10 first performs a first-layer decryption on the second shared data based on the data request private key to obtain third shared data, and then sends it to the server platform 30 .

[0103] After receiving the third shared data, the server platform 30 performs a second-layer decryption on the third shared data using the server platform private key to obtain fourth shared data, and then sends the fourth shared data to the first business system 10 .

[0104] The first business system performs a third-layer decryption on the fourth shared data using the user's private key, ultimately obtaining the fifth shared data that can be viewed by the user. This ensures unique decryption, allowing only the user to decrypt the final layer of data encryption using their private key, ensuring true ownership of their personal information.

[0105] It is understandable that the first shared data of the second business system 20 may be empty. That is, although the second business system 20 contains the user's information, there is no shared data corresponding to the user's data request. When the first shared data of the second business system 20 is empty, there is no need to encrypt the first shared data to obtain the second shared data, nor to send it to the first business system 10. Subsequently, neither the first business system 10 nor the server platform 30 needs to perform any decryption operations on the first shared data.

[0106] The method for data sharing between multiple business systems provided by the embodiment of the present disclosure is as follows: first, multiple business systems in the data sharing alliance jointly agree to enjoy the right to retrieve information from each other, and also have the obligation to maintain the high quality of data in their respective business systems. Compared with a centralized data aggregation platform, the business system itself benefits and is more motivated to maintain data quality; second, the first business system 10 and the second business system 20 confirm the identity of the same user through the user's public key, and there is no need to open up the master index of all business systems in the shared alliance and other complex development work, which reduces the difficulty. Third, the first business system 10 directly retrieves information from the current database of each business system in the second business system 20, and there is no problem of update or upload delay, and the required data is obtained in a timely manner. Compared with the centralized data aggregation platform through regular updates or uploads of data, timeliness can be better guaranteed; fourth, during the data transmission process, a three-layer encryption flow mechanism is used to achieve decryption uniqueness, and only the personal user's private key is allowed to decrypt the last layer of data encryption, so that the individual user truly has the ownership of personal information and ensures the security of the information.

[0107] In some embodiments, the data sharing method not only includes the above steps S201, S202 and S203, but also includes S2021: recording first relevant information of the user data request event after returning the fourth shared data to the first business system 10 in step S202.

[0108] In some embodiments, the data sharing method not only includes the above steps S201, S202, S2021 and S203, but also includes S2031: recording second relevant information of the user data request event after returning the fourth shared data to the first business system 10 in step S203.

[0109] Specifically, a user data request event refers to the process by which the first business system 10 sends a user's user data request to the second business system 20 via the server platform 30, ultimately obtaining the required shared data. The first relevant information refers to the request trace of the first business system 10 in this user data request event, including but not limited to one or more of the following: the name of the first business system 10, the time when the first business system 10 sent the user data request to the server platform 30, and the user's public key.

[0110] The second relevant information refers to traces of the second business system sharing data in this user data request event, including but not limited to the name of the second business system 20 and at least one of the time when the second business system 20 returns the second shared data to the first business system 10.

[0111] In the method of the embodiment of the present disclosure, the server platform 30 records the first relevant information and the second relevant information in the user data request event to form a standardized, efficient and traceable data sharing method.

[0112] In some embodiments, the data sharing method not only includes the above steps S201, S202, S2021, S203, and S2031, but also includes: generating a first transaction voucher through a hash algorithm based on the first relevant information; and / or generating a second transaction voucher through a hash algorithm based on the second relevant information.

[0113] Specifically, a hashing algorithm transforms an input of arbitrary length into an output of fixed length, known as a hash value. A hashing algorithm is used to construct a Merkle Tree, a tree-like data structure commonly used to verify the integrity and consistency of large datasets. Merkle trees are widely used in fields such as cryptography, distributed systems, and blockchains. In particular, in blockchains, they are used to verify the integrity of transactions and blocks, ensuring data is tamper-proof. A Merkle Tree is a binary tree in which each leaf node contains the hash value of a data block, while each non-leaf node contains a combination of the hash values ​​of its child nodes (typically a concatenation or hash of the child node hashes). This structure makes the Merkle Tree highly efficient, as only the hash values ​​of a small number of nodes need to be verified to verify the integrity of the entire dataset. The root node of a Merkle Tree is called the Merkle Root. It is the top-level node in the tree and contains the hash value of the entire dataset. Using the Merkle Root as a transaction credential ensures data immutability and forms a standardized, efficient, and traceable data sharing method. In some implementations, this data sharing approach can satisfy audit requirements.

[0114] In some embodiments, the data sharing method includes not only the above steps S201, S202, and S203, but also the following steps:

[0115] S204 : Receive an association request from the first business system 10 .

[0116] S205 . Create a data request key pair for the first business system 10 based on the association request, and synchronize it to the first business system 10 , wherein the data request key pair includes a data request public key and a data request private key.

[0117] Specifically, when a business system wishes to join a sharing alliance, it submits a request for association to the server platform 30. Upon receiving the association request, the server platform 30 creates a data request key pair for the business system and synchronizes it with the business system. When the business system, acting as the first business system 10, sends a user data request to the server platform 30, the server platform determines whether the first business system 10 is a member of the sharing alliance based on the first business system 10's data request public key. Only after the first business system 10 joins the sharing alliance can the first business system 19 share data with the second business system 20 in the sharing alliance.

[0118] In some embodiments, the data sharing method further includes: recording basic information of the first business system 10 , where the basic information of the first business system 10 includes the name of the first business system 10 and a data request public key and a data request private key.

[0119] Specifically, after the server platform 30 creates the data request key pair of the business system based on the business system's association request, it will also record the name of the business system and its data request public key and data request private key to form a correspondence between the name of the business system and its data request key pair, so that when the first business system 10 sends the data request public key and the user data request to the server platform 30, the server platform 30 determines whether the first business system 10 is a business system that has joined the sharing alliance based on the correspondence between the saved business system name and its data request key pair.

[0120] In some embodiments, the data sharing method further includes determining whether the first business system 10 is associated with the server platform 30 based on the data request public key. If the first business system 10 is associated with the server platform 30, the user data request, the user public key, and the data request public key are sent to the second business system 20. Otherwise, the user data request, the user public key, and the data request public key are not sent to the second business system 20, and the data request event ends.

[0121] Specifically, if the first business system 10 is associated with the server platform 30, it is determined that the first business system 10 is a business system that has joined the sharing alliance, and the required sharing number can be obtained from the second business system 20 through the server platform 30; if the first business system 10 is not associated with the server platform 30, it is determined that the first business system 10 has not joined the business system of the sharing alliance, and the data request event ends.

[0122] In the embodiment of the present disclosure, different business systems have independent data request key pairs, which cannot be mixed. This data request key pair plays an important role in the mutual recognition between the business system and the server platform 30.

[0123] In some embodiments, when a business system wishes to join the data sharing alliance, it submits a request for association to the alliance server platform 30. The server platform 30 records basic information such as the business system name, invites the business system to download the plug-in BA, creates and synchronizes the BA's data request public key, data request private key, and initial administrator account and password with the business system. After the business system authenticates with the data request public key and data request private key, it installs the plug-in BA and logs in with administrator privileges to perform operations such as account management and indicator maintenance.

[0124] FIG4 is a schematic diagram of a correspondence relationship between a business system and a plug-in BA provided in an embodiment of the present disclosure.

[0125] Each business system in the shared alliance has a plug-in called a BA installed, which is responsible for data connection with the business system. BAs installed in different business systems must have independent key pairs and cannot be mixed. This key pair plays a vital role in the mutual recognition and data decryption process between the business system BA and the server platform.

[0126] It should be noted that after each business system sends an association request to the server platform 30 and the server platform 30 creates a data request key pair corresponding to the business system, the server platform 30 can directly send the data request key pair and other information to the business system for storage. The business system stores the correspondence between the individual user's business system account and the key pair, issues data sharing requests, receives data sharing information, etc. Of course, the server platform 30 can also invite the business system to download a plug-in. After the business system authenticates according to the data request key pair created by the server platform, it installs the plug-in BA. The plug-in BA is embedded in the business system. The storage of the correspondence between the individual user's business system account and the key pair, the issuance of data sharing requests, the reception of data sharing information, etc. can all be performed by the plug-in BA embedded in the business system. This disclosure does not limit this.

[0127] In some embodiments, the plug-in may include two parts: a request block agent (RBA) and a data block agent (DAB). The request block agent (RBA) can create personal user key pairs, store the correspondence between personal user business system accounts and key pairs, issue data sharing requests, receive data sharing information, etc., and is operated by institutional users; the data block agent (DAB): in plug-in form, determines the personal user business system account to be shared, connects with the business system, and retrieves the user information.

[0128] In some embodiments, the data sharing method also includes: the server platform 30 creates standard indicators according to preset rules, such as national standards, and pushes them to each business system; each business system maintains its own indicators based on the standard indicators created by the server platform 30, and confirms the correspondence between its own indicators and the standard indicators.

[0129] In the embodiment of the present disclosure, the server platform 30 unifies the standards. Compared with the centralized data aggregation platform, each business system in the shared alliance communicates with each other using standard indicators, avoiding confusion such as multiple names for one indicator, and having strong standardization.

[0130] In some embodiments, the data sharing method further includes: the server platform 30 maintaining the standard indicator based on the user's instructions.

[0131] In some embodiments, the standard indicator is maintained based on user instructions, including: starting / deactivating an existing standard indicator, modifying the type name and name of an existing standard indicator, and adding a new standard indicator.

[0132] The embodiment of the present disclosure maintains the standard indicators through the server platform 30, and can timely update the standard indicators stored in the server platform 30 as needed, making it more convenient for users to query.

[0133] In some embodiments, the data sharing method can be applied to multiple scenarios such as education, business, and medical care. Taking medical care as an example, the first business system 10 and the second business system 20 can be hospital systems of various hospitals, and users can be medical staff or patients.

[0134] For example, a patient visits a hospital for a consultation / recheck, handled by a doctor. The current hospital system is the first business system, and all hospitals or medical institutions covered by the Medical Data Sharing Alliance are the second business system. The doctor enters the patient's first business system account number in the first business system. After the first business system (or a plug-in within the first business system) confirms the patient's user public key and user private key, the doctor sends a request for the patient's consultation / follow-up / daily monitoring records to the server platform. The server platform then sends the request to the business systems of all hospitals or medical institutions covered by the Medical Data Sharing Alliance. The business systems of all hospitals or medical institutions covered by the Medical Data Sharing Alliance retrieve the records related to the patient's consultation / follow-up / daily monitoring and encrypt them. The records are then returned to the first business system, the server platform for automatic decryption, and then returned to the first business system. Finally, the final data is decrypted using the user's private key, allowing the doctor to fully understand the patient's medical history, medications, and other information.

[0135] For another example, hospital operations staff may retrieve patient data for a custodial user's private key for research / statistical purposes, and the hospital operations staff will perform this operation as an administrator. The current hospital system is the first business system, and all hospitals or medical institutions covered by the medical data sharing alliance are the second business system. The hospital operations staff logs in to the administrator account of the first business system and sends a request for research / statistics related to the patient with the custodial user's private key to the server platform. The server platform then sends the request to the business systems of all hospitals or medical institutions covered by the medical data sharing alliance. The business systems of all hospitals or medical institutions covered by the medical data sharing alliance retrieve the data related to the research / statistics related to the patient with the custodial user's private key and encrypt it. The data is then returned to the first business system, the server platform, and the first business system in turn for decryption to obtain the final data, allowing the hospital operations staff to conduct research / statistics based on the patient data with the custodial user's private key.

[0136] Based on the same inventive concept, the present disclosure provides another method for sharing data between multiple business systems, which is applied to the first business system 10. Figure 5 shows another method for sharing data between multiple business systems provided by the present disclosure, which can be applied to the sharing alliance shown in Figure 1. The business system that sends the user data request in the multiple business systems is the first business system 10, and the business system that receives the user data request is the second business system 20. The method is applied to the first business system 10 and includes:

[0137] S501: Send the user data request, user public key and data request public key to the server platform, so that the server platform sends the user data request, user public key, data request public key and server platform public key to the second business system.

[0138] S502: Receive the second shared data sent by the second business system 20, and decrypt the second shared data based on the data request private key to obtain third shared data, and send the third shared data to the server platform 30 so that the server platform 30 decrypts the third shared data to obtain fourth shared data.

[0139] The second shared data is obtained by the second business system 20 performing data query based on the user data request and encrypting the data in the order of the data request public key, the server platform public key and the user public key.

[0140] S503: Receive the fourth shared data sent by the server platform 30, and decrypt the fourth shared data based on the user private key to obtain fifth shared data.

[0141] Specifically, the first business system 10 is responsible for issuing a user data request and receiving the second shared data corresponding to the user data request returned by the second business system 20. Among them, the second business system 20 first determines the identity of the user based on the received user public key, and then performs a data query based on the user data request to obtain the first shared data. Finally, the second business system 20 encrypts the first shared data in the order of the data request public key, the server platform public key and the user public key, obtains the second shared data and sends it to the first business system 10. The first business system 10 is also responsible for decrypting the encrypted second shared data using the data request private key and the user's user private key. The specific details in the disclosed embodiment are the same as those in the previous embodiment and will not be repeated here.

[0142] The data sharing method provided by the embodiment of the present disclosure is as follows: first, multiple business systems in the data sharing alliance jointly agree to enjoy the right to retrieve information from each other, and also have the obligation to maintain the high quality of data in their respective business systems. Compared with the centralized data aggregation platform, the business system itself benefits and is more motivated to maintain data quality; second, the first business system 10 and the second business system 20 confirm the identity of the same user through the user's public key, and there is no need to open up the master index of all business systems in the sharing alliance and other complex development work, which reduces the difficulty. Third, the first business system 10 directly retrieves information from the current database of each business system in the second business system 20, and there is no problem of update or upload delay, and the required data is obtained in time. Compared with the centralized data aggregation platform through regular updates or uploads of data, timeliness can be better guaranteed; fourth, during the data transmission process, a three-layer encryption flow mechanism is used to achieve decryption uniqueness, and only the personal user's private key is allowed to decrypt the last layer of data encryption, so that the individual user can truly master the ownership of personal information and ensure the security of the information.

[0143] In some embodiments, the first business system stores a correspondence between a user's first business system account and a user key pair, where the user key pair includes a user public key and a user private key. The data sharing method further includes:

[0144] S511: Receive the user's first business system account.

[0145] S512: Determine the user's public key and generate a user data request based on the user's first business system account through the correspondence between the user's first business system account and the user's public key.

[0146] Specifically, the user public key is used to confirm the unique identity of the user across multiple business systems (the first business system 10 and the second business system). The same user may use different personal information to register corresponding business system accounts in different business systems. Between the user and the business system, the business system account, username, or other user information is used for mutual recognition, while between multiple business systems, the user public key is used to confirm the same user. When the user logs in to the first business system using the first business system account, the first business system determines the user's public key based on the correspondence between the first business system account and the user public key. For other specific details, please refer to the previous embodiment section.

[0147] This disclosed embodiment matches the same user's account number in each business system of the shared alliance with the user's self-made key pair (user public key) to confirm the same identity. This eliminates the need for complex development work such as connecting the master index of all business systems in the shared alliance, thus reducing the difficulty.

[0148] In some embodiments, the step of determining the user's public key based on the user's first business system account through the correspondence between the user's first business system account and the user key pair can be performed by the first business system 10; when the server platform 30 invites the first business system 10 to download the plug-in, this step can also be performed by the plug-in embedded in the first business system 10, and this disclosure does not limit this.

[0149] FIG6 is a flow chart of determining a user's public key according to an embodiment of the present disclosure. As shown in FIG6 , based on the user's first business system account and the corresponding relationship between the user's first business system account and the user key pair, determining the user's public key and generating a user data request include:

[0150] S601: Login to the first business system 10. Specifically, the current user logs in to the first business system 10 using the first business system account.

[0151] S602: Check the current user. Specifically, the current user is synchronized with the user opened in the first business system 10.

[0152] S603: Determine whether the first business system account of the current user has a corresponding user key pair.

[0153] Specifically, the first business system 10 determines whether the current user's first business system account has a corresponding user key pair, in order to determine whether the current user is authenticated in the first business system 10 and confirm whether the current user is a registered user in the first business system 10 .

[0154] In step S603, if the first business system account of the current user does not have a corresponding user key pair, then step S605 is executed.

[0155] S605: Determine whether the second business system account of the current user has a corresponding user key pair.

[0156] Specifically, if the first business system account of the current user does not have a corresponding user key pair, it means that the current user has not registered the first business system account, and then it is further determined whether the current user has registered other business system accounts in other business systems in the sharing alliance.

[0157] In step S605 , if the second business system account of the current user has a corresponding user key pair, then step S607 is executed.

[0158] S607: Determine whether to associate the corresponding user key pair of the user's second business system account with the first business system account.

[0159] Specifically, if the current user's second business system account has a corresponding user key pair, it means that the current user has registered a second business system account in the second business system 20, and the user can share data between the second business systems. Furthermore, the user can determine whether to add the first business system 10 to the business system that the user already has shared based on data privacy or other considerations. That is, it is determined whether to bind the corresponding user key pair of the second business system account to the first business system account. Referring to the embodiment corresponding to Figure 3 above, after the user's user key pair is bound to the business system, the business system can share data with other business systems that contain the user's user key pair based on the user's user key pair.

[0160] In step S607, if the corresponding user key pair of the user's second business system account is associated with the first business system account, step S608 is executed.

[0161] S608: Determine whether the user carries the user public key corresponding to the second business system account.

[0162] If the user carries the user public key corresponding to the second business system account, step S612 is executed. S612: Determine the user public key, synchronize it to the user, and generate a user data request.

[0163] If the user does not carry the user public key corresponding to the second business system account, step S610 is executed.

[0164] S610: Create a user key pair corresponding to the first business system account, determine the user public key, and generate a user data request.

[0165] Specifically, if it is determined that the corresponding user key pair of the second business system account is associated with the first business system account, it is further necessary to determine whether the user carries the user public key. If the current user does not carry the user public key, the user public key cannot be bound to the first business system. Furthermore, the user will not be able to share data with other business systems in the first business system to obtain the required data. At this time, the user can register on the first business system side. In some embodiments, refer to the method in the embodiment corresponding to Figure 3 above, and then bind the user key pair to the second business system. The user can subsequently realize data sharing between the first business system and the second business system. If the current user carries the user public key, the user public key is bound to the first business system, and the user public key is synchronized to the user. The user can then share data information stored in other business systems in the first business system.

[0166] In step S605, if the user's second business system account does not have a corresponding user key pair; or in step S607, if the user's second business system account does not have a corresponding user key pair associated with the first business system account; then execute S610 and execute step S612.

[0167] S610: Create a user key pair corresponding to the first business system account, determine the user public key, and generate a user data request.

[0168] S612: Synchronize to the current user.

[0169] Specifically, if the user's second business system account does not have a corresponding user key pair, that is, if no business system in the entire sharing alliance has the user's information, the user can register on the first business system. In some embodiments, referring to the method described in the embodiment corresponding to FIG. 3 above, the user key pair is then bound to the second business system. The user can then share data between the first and second business systems.

[0170] In step S603, if the first business system account of the current user has a corresponding user key pair, then step S604 is executed.

[0171] Step S604: Determine whether the user's private key is in trust or whether the user carries the user's private key.

[0172] When the user's private key is not escrowed and the user's private key is not carried, step S609 is executed.

[0173] Step S609: Determine whether the user carries the key pair corresponding to the second business system account.

[0174] Specifically, although the user has registered an account in the first business system and has a corresponding user public key, if the user does not entrust the user private key or does not carry the user private key, then after the second business system returns the shared data to the first business system, the user will not be able to decrypt the shared data, and ultimately will not be able to obtain the final shared data. Therefore, it is necessary to further ensure that the user can decrypt the shared data returned by the second business system. If the user cannot obtain the user private key of the first business system, it can also be determined whether the user can obtain the user key pair of the user in the second business system. If the user key pair of the user in the second business system can be obtained, data sharing between the first business system and the second business system can be achieved by binding it to the first business system. Otherwise, the user can only recreate a new user key pair in the first business system.

[0175] If the user does not carry the user key pair corresponding to the second business system account, step S610 is executed.

[0176] If the user carries the user key pair corresponding to the second business system account, step S607 is executed.

[0177] For details, please refer to the description of step S610 and step S607 above, which will not be repeated here.

[0178] An example is given in which each business system is a hospital system of each hospital, the first business system is a system of hospital A that receives user requests, and the second business system is a hospital system of another hospital.

[0179] After the user logs in to the first business system with the first business system account, the A hospital system first determines whether the user's user key pair exists in the A hospital system to determine whether the user has registered an account in the A hospital system.

[0180] If the user has not registered an account for Hospital A system in Hospital A system, then determine whether the user has registered accounts for other hospital systems in other hospitals in the sharing alliance. If the user has registered accounts for other hospital systems in the hospital systems of other hospitals, then the user's user key pair must exist. And because the same user has the same user key pair in multiple business systems that share data. Continue to determine whether to bind the user key pair to the first business system account. After binding, the user will be able to obtain the user's data in other hospital systems in the A hospital system. If the user does not want to share the data in other hospital systems with the A hospital system, binding is not required. If the user still wants the data required by the A hospital system, he can create a new user key pair in the A hospital system.

[0181] If the user has registered an account for Hospital A system in Hospital A system, then determine whether the user's user private key is in escrow or whether the user private key is carried with the user to ensure that when other hospital systems subsequently return the required data to Hospital A system, the user can decrypt it. If the user's user private key is neither in escrow nor carried with the user private key, the subsequent user will not be able to decrypt the data returned by their hospital system to Hospital A system. At this time, it can be further determined whether the user carries a user key pair from other hospital systems. If so, continue to determine whether to bind the user key pair to the first business system account. After binding, the user will be able to obtain the user's data in other hospital systems on the Hospital A system side. If the user does not want to share the data in other hospital systems with Hospital A system, it is not necessary to bind. If the user still wants the data required by Hospital A system later, he can create a new user key pair in Hospital A system. At the same time, if the user does not carry a key pair from other hospital systems, if the user still wants the data required by Hospital A system later, he can also create a new user key pair in Hospital A system.

[0182] In some embodiments, the data sharing method not only includes steps S501, S502 and S503, but also includes: modifying the status of the user's private key based on the user's first instruction; and based on the modified status of the user's private key, determining whether the user's private key is hosted or whether the user carries the user's private key.

[0183] In some embodiments, when the user's first instruction is to change the user private key from non-custodial to custodial, it is determined whether the user carries the user private key; if the user carries the user private key, the current user private key status is modified, otherwise it cannot be modified.

[0184] Specifically, FIG7 is a flowchart of a method for modifying a user's private key provided by an embodiment of the present disclosure. As shown in FIG7 , the specific steps include:

[0185] S601: A user logs into the first business system.

[0186] S602: The first business system checks the current user.

[0187] S703: The first business system determines whether to modify the status of the user's private key according to the user's first instruction. If the status of the user's private key does not need to be modified, S711 is executed and the process ends directly.

[0188] If the status of the user's private key needs to be modified, and S704: the user's private key status is changed from managed to unmanaged, then execute S705: enter key maintenance and change the current user's private key status to unmanaged; S710: save the modified user's private key status and synchronize it to the user.

[0189] If the user's private key status needs to be modified, and S706: The user's private key status is changed from unmanaged to managed, then S709: Determine whether the user carries the user's private key. If the user does not carry the user's private key, the user's private key status cannot be modified, and S711 is executed, ending directly. If the user carries the user's private key, then S707: Enter key maintenance and change the current user's private key status to managed; S708: Confirm the user's private key; S710: Save the modified user's private key status and synchronize it with the user.

[0190] The disclosed embodiment can enable users to flexibly obtain user private keys by modifying the status of user private keys, making it more convenient for users to use.

[0191] In some embodiments, the data sharing method further includes: the first business system 10 maintaining indicators of each business system and / or matching indicators of the business systems.

[0192] In some embodiments, business system indicator maintenance includes but is not limited to starting / deactivating business system indicators, modifying the type name and label name of existing business system indicators, etc.

[0193] In some embodiments, the indicator matching of the business system includes but is not limited to modifying the correspondence between the indicators of the business system and the standard indicators, querying the indicators of the business system, and prompting when the indicators of the business system are not completely matched.

[0194] It should be noted that when the first business system deactivates the business system indicators, it is necessary to confirm whether the user's private key is hosted or whether the user carries the user private key. If the user's private key is not hosted and the user does not carry the user private key, the business system indicators cannot be deactivated.

[0195] Based on the same inventive concept, an embodiment of the present disclosure further provides a method for data sharing between multiple business systems, wherein the system that sends a user data request in the multiple business systems is a first business system 10, and the business system that receives the user data request is a second business system 20. The method is applied to the second business system 20. FIG8 is a flow chart of another method for data sharing between multiple business systems provided by an embodiment of the present disclosure. As shown in FIG8, the method includes:

[0196] S801: Receive a user data request, a user public key, a data request public key, and a server platform public key sent by the server platform 30.

[0197] S802: Determine the identity of the user based on the user public key, and determine first shared data based on the user data request.

[0198] S803: Encrypt the first shared data in the order of the data request public key, the server platform public key and the user public key to obtain the second shared data, and send it to the first business system 10; so that the first business system 10 decrypts the second shared data based on the data request private key to obtain the third shared data, and sends it to the server platform 30, so that the server platform 30 decrypts the third shared data based on the server platform private key to obtain the fourth shared data; and returns it to the first business system 10, so that the first business system 10 decrypts the fourth shared data based on the user private key to obtain the fifth shared data.

[0199] Other details in the embodiments of the present disclosure are the same as those in any of the above embodiments and will not be repeated here.

[0200] The data sharing method provided by the embodiment of the present disclosure is as follows: first, multiple business systems in the data sharing alliance jointly agree to enjoy the right to retrieve information from each other, and also have the obligation to maintain the high quality of data in their respective business systems. Compared with the centralized data aggregation platform, the business system itself benefits and is more motivated to maintain data quality; second, the first business system 10 and the second business system 20 confirm the identity of the same user through the user's public key, and there is no need to open up the master index of all business systems in the sharing alliance and other complex development work, which reduces the difficulty. Third, the first business system 10 directly retrieves information from the current database of each business system in the second business system 20, and there is no problem of update or upload delay, and the required data is obtained in time. Compared with the centralized data aggregation platform through regular updates or uploads of data, timeliness can be better guaranteed; fourth, during the data transmission process, a three-layer encryption flow mechanism is used to achieve decryption uniqueness, and only the personal user's private key is allowed to decrypt the last layer of data encryption, so that the individual user can truly master the ownership of personal information and ensure the security of the information.

[0201] FIG9 is a flow chart of a method for data sharing between multiple business systems provided by an embodiment of the present disclosure, in which the system that sends the user data request in the multiple business systems is the first business system, and the business system that receives the user data request is the second business system. As shown in FIG9 , the method is applied to the first business system, the server platform, and the second business system, and specifically includes: the user logs in to the first business system, enters the personal user management page, checks the current personal user authentication status (the current user is synchronized with the user opened in the business system), and confirms that there is no problem with the public and private key status of the personal user to be queried; the user selects the personal user's to-be-queried indicator, and the first business system sends a query request to the server platform, which must carry the personal user public key, the data request public key, the server platform public key, and the data callback interface URL; the server platform confirms the identity of the first business system through the data request public key, receives the data request, retrieves the business systems (business system a, business system b, business system c) that have currently joined the sharing alliance and sends a data request to them, while recording the request trace; the DBA of each business system receives the request and searches whether there is a business system account corresponding to the personal user public key. If it exists, the data information under the account is extracted, encrypted in the order of the user public key, server platform public key, and data request public key, and returned to the data callback interface URL; if it does not exist (for example, business system a in this embodiment), it will not be returned; the first business system receives the returned data, uses the data request private key to decrypt the first layer, and then sends it to the server platform; if the returned data is empty, no decryption is required and it is sent directly to the server platform; for information that needs to be decrypted, the server platform uses the server platform private key to decrypt the second layer, reads the business system name and return address, records it, hashes this record, generates a unique immutable mark, and sends other encrypted information to the return address; for information that does not need to be decrypted, directly reads the business system name, records it, and hashes this data. When all the query results of this round are returned, the entire record is hashed to ensure that the data is traceable and cannot be tampered with; individual users use their private keys to decrypt the third layer, filter the information of this query indicator, and display it in plain text.

[0202] It should be noted that when a plug-in is installed in the first business system, the steps of sending a user query request to the server platform and obtaining three-layer encrypted data and decrypting the first layer are performed by the plug-in in the first business system.

[0203] The data sharing methods in all embodiments of the present disclosure are suitable for scenarios in multiple fields such as education, commerce, and medical care. The users in all embodiments of the present disclosure can be individual users or institutional users.

[0204] Taking the medical scenario as an example, individual users are patients. Individual users can use applications (such as apps) to query their personal information on their own. Institutional users are doctors or hospital operators or data statisticians. Hospital operators or data statisticians can serve as administrators. Each business system is a hospital system for each hospital, and each hospital system can also include plug-ins installed in each hospital system. Specific application scenarios include but are not limited to:

[0205] Scenario 1: A patient goes to the hospital for a consultation / reexamination. The doctor retrieves the patient's consultation / follow-up / daily monitoring records from the business systems of all hospitals or medical institutions covered by the Medical Data Sharing Alliance to fully understand the patient's medical history, previous medications, and other information.

[0206] Scenario 2: Hospital operations staff retrieves patient data with a private key for scientific research / statistical purposes.

[0207] An embodiment of the present disclosure also provides an electronic device, comprising: a processor; and a memory for storing instructions for data sharing between multiple business systems, wherein the processor is configured to call the instructions stored in the memory to execute the data sharing method in any of the above embodiments.

[0208] An embodiment of the present disclosure further provides a computer-readable storage medium storing computer program code for data sharing among multiple business systems. When the computer program code is executed by a processor, the method for data sharing in any of the above embodiments is implemented.

[0209] It will be understood that the above embodiments are merely exemplary embodiments for illustrating the principles of the present invention, and the present invention is not limited thereto. Those skilled in the art will appreciate that various modifications and improvements can be made without departing from the spirit and substance of the present invention, and such modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. A method for data sharing between multi-service systems, wherein, In the multi-service system, the service system that sends the user data request is the first service system, and the service system that receives the user data request is the second service system. The method is applied to the server platform and includes: Receiving the user public key, data request public key, and user data request sent by the first service system; Sending the user data request, user public key, data request public key, and server platform public key to the second service system based on the data request public key, so that the second service system can perform data query and encrypt in the order of the data request public key, server platform public key, and user public key to obtain the second shared data, and then send it to the first service system; Receiving the third shared data sent by the first service system, decrypting the third shared data based on the server platform private key, and returning it to the first service system; where The third shared data is obtained by the first service system decrypting the second shared data based on the data request private key.

2. The method according to claim 1, wherein The step of receiving the user public key, data request public key, and user data request sent by the first service system specifically includes: Receiving the user public key, data request public key, and user data request sent by the plugin of the first service system.

3. The method according to claim 1, wherein, The method further includes: After sending the user data request, user public key, data request public key, and server platform public key to the second service system, recording the first relevant information of the user data request event.

4. The method according to claim 3, wherein, The method further includes: After decrypting the third shared data based on the server platform private key and returning it to the first service system, recording the second relevant information of the user data request event.

5. The method according to claim 1, wherein The method further includes: Receiving the association request from the first service system; Creating a data request key pair for the first service system based on the association request and synchronizing it to the first service system, where the data request key pair includes a data request public key and a data request private key.

6. The method according to claim 5, wherein The method further includes: recording the basic information of the first service system, where the basic information of the first service system includes the name of the first service system, data request public key, and data request private key.

7. The method according to claim 6, wherein, The method further includes: Judging whether the first service system is associated with the server platform based on the data request public key; If the first service system is associated with the server platform, sending the user data request, user public key, data request public key, and server platform public key to the second service system.

8. The method according to claim 4, wherein The method further includes: generating a first transaction voucher through a hashing algorithm based on the first relevant information; and / or Generating a second transaction voucher through a hashing algorithm based on the second relevant information.

9. A method for data sharing between multi-service systems, wherein, In the multi-service system, the service system that sends the user data request is the first service system, and the service system that receives the user data request is the second service system. The method is applied to the first service system and includes: Send the user data request, the user public key, and the data request public key to the server platform, so that the server platform sends the user data request, the user public key, the data request public key, and the server platform public key to the second service system; Receive the second shared data sent by the second service system, perform the first layer of decryption on the second shared data based on the data request private key, and send it to the server platform, so that the server platform performs the second layer of decryption on the second shared data that has been decrypted at the first layer, where The second shared data is obtained by the second service system querying data based on the user data request and performing three-layer encryption in the order of the data request public key, the server platform public key, and the user public key; Receive the second shared data that has been decrypted at the second layer sent by the server platform, and perform the third layer of decryption based on the user private key.

10. The method according to claim 9, wherein, In the first service system, there is a correspondence between the user's first service system account and the user key pair. The user key pair includes a user public key and a user private key. The method further includes: Receive the user's first service system account; Based on the correspondence between the user's first service system account and the user public key through the user's first service system account, determine the user's user public key and generate a user data request.

11. The method according to claim 10, wherein, The determining the user's user public key and generating a user data request based on the correspondence between the user's first service system account and the user key pair through the user's first service system account includes: Judge whether there is a corresponding user key pair for the user's first service system account, If it exists, determine the user's user public key and generate a user data request; Otherwise, judge whether there is a corresponding user key pair for the user's second service system account, obtain a first judgment result, and determine the user's user public key and generate a user data request based on the first judgment result.

12. The method according to claim 11, wherein, The determining the user's user public key and generating a user data request based on the first judgment result includes: If there is no corresponding user key pair for the user's second service system account, create a user key pair corresponding to the first service system account, determine the user public key, and generate a user data request; If there is a corresponding user key pair for the user's second service system account, judge whether to associate the existence of the corresponding user key pair for the user's second service system account with the first service system account, and obtain a second judgment result; Determine the user's user public key and generate a user data request based on the second judgment result.

13. The method according to claim 11, wherein, When there is a corresponding user key pair for the user's first service system account, determining the user's user public key and generating a user data request includes: Judge whether the user's user private key is escrowed or whether the user carries the user private key; When the user's user private key is not escrowed and the user does not carry the user private key, judge whether the user carries the key pair corresponding to the second service system account, and obtain a third judgment result; Determine the user's user public key and generate a user data request based on the third judgment result.

14. The method according to claim 13, wherein, Determining the user's public key and generating a user data request based on the third judgment result includes: If the user does not carry the user key pair corresponding to the second service system account, create the user key pair corresponding to the first service system account, determine the user public key, and generate a user data request; If the user carries the user key pair corresponding to the second service system account, determine whether to associate the user key pair corresponding to the user's second service system account with the first service system account to obtain a second judgment result; Determine the user's public key and generate a user data request based on the second judgment result.

15. The method according to claim 14, wherein, Determining the user's public key and generating a user data request based on the second judgment result includes: If the user key pair corresponding to the user's second service system account is not associated with the first service system account, create the user key pair corresponding to the first service system account, determine the user public key, and generate a user data request; If the user key pair corresponding to the user's second service system account is associated with the first service system account, determine the user public key and generate a user data request.

16. The method according to claim 15, wherein, The step of if the user key pair corresponding to the user's second service system account is associated with the first service system account, determine the user public key and generate a user data request includes: Determine whether the user carries the public key corresponding to the second service system account; If so, determine the user public key and generate a user data request; Otherwise, create the user key pair corresponding to the first service system account, determine the user public key, and generate a user data request.

17. The method according to claim 13, wherein, The method further includes: Modify the status of the user private key based on the user's first instruction; Based on the modified status of the user private key, determine whether the user's private key is escrowed or whether the user carries the private key.

18. The method according to claim 17, wherein, Modifying the status of the user private key based on the user's first instruction includes: When the user's first instruction is to change the user private key from non-escrow to escrow, determine whether the user carries the private key; If so, modify the current status of the user private key, otherwise, it cannot be modified.

19. A method for data sharing between multi-service systems, wherein, In the multi-service system, the system that sends the user data request is the first service system, and the service system that receives the user data request is the second service system. The method is applied to the second service system and includes: Receive the user data request, user public key, data request public key, and server platform public key sent by the server platform; Determine the user's identity based on the user public key and determine the first shared data based on the user data request; Encrypt the first shared data in three layers in the order of the data request public key, the server platform public key, and the user public key to obtain the second shared data, and send it to the first service system; so that the first service system decrypts the second shared data at the first layer based on the data request private key and sends it to the server platform, so that the server platform decrypts it at the second layer based on the server platform private key and returns it to the first service system, so that the first service system decrypts it at the third layer based on the user private key.

20. The method according to any one of claims 1-19, wherein, The user is a hospital patient, and each service system is each hospital system. Among them, the first service system is the hospital system that sends the user data request of the patient, and the second service system is the hospital system that receives the user data request of the patient.

21. An electronic device, wherein, It includes: A processor; A memory for storing instructions executable by the processor, where The processor is configured to call the instructions stored in the memory for executing the method according to any one of claims 1-19.

22. A computer-readable storage medium, on which computer program codes for data sharing among multiple service systems are stored, and when the computer program codes are run by a processor, the method according to any one of claims 1-19 is implemented.

Images