Data query method, device, equipment, storage medium and program product

Abstract

The present application provides a data query method, device, equipment, storage medium and program product, the method comprising: a coordinator generates a public key for encryption and a private key for decryption; determines at least two target participants according to at least two features to be queried, and determines a query request corresponding to each target participant, each target participant stores feature data of some features to be queried; sends the public key and the query request corresponding to each target participant to the corresponding target participant; receives the ciphertext query result sent by each target participant, the ciphertext query result is determined by each target participant based on the public key and the query request received by each target participant; determines the target data according to the private key and the ciphertext query result sent by each target participant. Under the premise of ensuring that the data does not leave the local area of ​​each participant, cross-table query of data is realized, which can not only protect data privacy and prevent data leakage, but also will not affect the availability of the queried target data.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence technology, and relates to but is not limited to a data query method, device, equipment, storage medium and program product. Background Art

[0002] In the information society, databases are used in almost every industry to fully and effectively manage and utilize various information resources. Database query is a commonly used database technology. Generally speaking, current database storage is saved in the form of (keyword key, value value) pairs. Database query refers to the user using the key value to find the value corresponding to the key in the database. Multi-table query means that data is distributed in multiple database tables and multiple database tables need to be combined for query. Common connection methods include: inner join, left join, right join and full join.

[0003] When multiple tables are distributed in different institutions or clients, these tables cannot be directly shared because of the need to prevent privacy data leakage. In related technologies, the data in the table is first desensitized, anonymized, differentially private, or homomorphically encrypted, and then multiple tables are brought together for connection to achieve multi-table query. Although related technologies can prevent data leakage through encryption or anonymization technology, it will reduce the availability of data and violate the restrictions on data out of the domain in the privacy protection law. How to realize cross-table connection query by combining multi-party data without leaving the local area is one of the problems that need to be solved urgently. Summary of the invention

[0004] The embodiments of the present application provide a data query method, apparatus, device, computer-readable storage medium, and computer program product, which can implement cross-table connection query under the premise of ensuring that data does not leave the local area and protecting data privacy.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] The present application embodiment provides a data query method, which is applied to a coordinator of federated learning, and includes:

[0007] Generate a public key for encryption and a private key for decryption;

[0008] According to at least two features to be queried, at least two target participants are determined from multiple participants of federated learning, and a query request corresponding to each target participant is determined, where each target participant stores feature data of part of the features to be queried;

[0009] Sending the public key and the query request corresponding to each target participant to the corresponding target participant;

[0010] Receiving the ciphertext query results sent by the target participants, the ciphertext query results are determined by the target participants based on the public key and the query requests received by each of them;

[0011] The target data is determined based on the private key and the ciphertext query results sent by each target participant.

[0012] The present application embodiment provides a data query method, which is applied to a target participant of federated learning, wherein the target participant is a participant storing part of the data to be queried, and the method includes:

[0013] Receive the public key and query request sent by the coordinator;

[0014] Parsing the query request to obtain the query condition carried by the query request;

[0015] Searching in its own storage space based on the query condition to obtain a plaintext query result;

[0016] Encrypting the plaintext query result using the public key to obtain a ciphertext query result;

[0017] The ciphertext query result is sent to the coordinator.

[0018] The present application embodiment provides a data query device, which is applied to a coordinator of federated learning, and includes:

[0019] A generation module, used for generating a public key for encryption and a private key for decryption;

[0020] A first determination module is used for at least two features to be queried, and determines at least two target participants from multiple participants in federated learning, each target participant storing feature data of part of the features to be queried;

[0021] A second determination module is used to determine the query request corresponding to each target participant;

[0022] A first sending module, used for sending the public key and the query request corresponding to each target participant to the corresponding target participant;

[0023] A first receiving module, used to receive the ciphertext query results sent by each target participant, wherein the ciphertext query results are determined by each target participant based on the public key and the query request received by each target participant;

[0024] The third determination module is used to determine the target data according to the private key and the ciphertext query results sent by each target participant.

[0025] The present application embodiment provides a data query device, which is applied to a target participant of federated learning, wherein the target participant is a participant storing part of the data to be queried, and the device includes:

[0026] A second receiving module, used to receive the public key and query request sent by the coordinator;

[0027] A parsing module, used to parse the query request to obtain the query condition carried by the query request;

[0028] A query module, used to search in its own storage space based on the query conditions to obtain a plaintext query result;

[0029] An encryption module, used to encrypt the plaintext query result using the public key to obtain a ciphertext query result;

[0030] The second sending module is used to send the ciphertext query result to the coordinator.

[0031] The present application provides a data query device, the device comprising:

[0032] A memory for storing executable instructions;

[0033] The processor is used to implement the method provided in the embodiment of the present application when executing the executable instructions stored in the memory.

[0034] An embodiment of the present application provides a computer-readable storage medium, on which executable instructions are stored, for causing a processor to execute and implement the method provided in the embodiment of the present application.

[0035] An embodiment of the present application provides a computer program product, including a computer program, and when the computer program is executed by a processor, the method provided by the embodiment of the present application is implemented.

[0036] The embodiments of the present application have the following beneficial effects:

[0037] In the data query method provided in the embodiment of the present application, the coordinator determines at least two target participants from multiple participants in federated learning based on at least two features to be queried, and determines the query request corresponding to each target participant, and then sends the pre-generated public key and the query request corresponding to each target participant to the corresponding target participant. After receiving the query request, each target participant queries its own data table respectively to obtain a plaintext query result, and then uses the public key to encrypt the plaintext query result to obtain a ciphertext query result. The coordinator receives the ciphertext query results sent by each target participant, and determines the target data based on the private key and the ciphertext query results sent by each target participant. In this way, under the premise of ensuring that the data of each participant does not leave the local area of ​​each participant, cross-table query of data is realized, which can not only protect data privacy and prevent data leakage, but also does not perform anonymization and other processing on the data, and will not affect the availability of the queried target data. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 A schematic diagram of a network architecture of a data query method provided in an embodiment of the present application;

[0039] Figure 2 It is a schematic diagram of the structure of the data query device provided in the embodiment of the present application;

[0040] Figure 3 A schematic diagram of an implementation flow of a data query method provided in an embodiment of the present application;

[0041] Figure 4 A schematic diagram of another implementation flow of the data query method provided in an embodiment of the present application;

[0042] Figure 5 A schematic diagram of another implementation flow of the data query method provided in the embodiment of the present application;

[0043] Figure 6 A schematic diagram of the database table distribution provided in the embodiment of the present application;

[0044] Figure 7 A schematic diagram of an implementation flow of a data query method for implementing inner connections in federated learning provided in an embodiment of the present application;

[0045] Figure 8 A schematic diagram of an implementation flow of a data query method for implementing left join in federated learning provided in an embodiment of the present application;

[0046] Fig. 9 A schematic diagram of an implementation flow of a data query method for implementing right join using federated learning provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0048] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0049] In the following description, the terms "first\second\third" involved are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0050] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0051] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0052] 1) Federated Learning, an emerging basic AI technology, is designed to carry out efficient machine learning among multiple parties or computing nodes while ensuring information security during big data exchange, protecting terminal data and personal data privacy, and ensuring legality and compliance.

[0053] 2) Join query is the most important query in relational databases, mainly including inner join, outer join and cross join, etc. Multiple table queries can be realized through the join operator.

[0054] 3) Homomorphic Encryption: Homomorphic encryption is a cryptographic technique based on the computational complexity theory of mathematical problems. The data that has been homomorphically encrypted is processed to obtain an output, and the output is decrypted, and the result is the same as the output obtained by processing the unencrypted original data in the same way.

[0055] The following describes an exemplary application of the apparatus for implementing the embodiment of the present application. The apparatus provided in the embodiment of the present application can be implemented as a terminal device. The following describes an exemplary application of the terminal device when the apparatus is implemented as a terminal device.

[0056] Figure 1 A schematic diagram of the network architecture of the data query method provided in the embodiment of the present application is shown in FIG. Figure 1 As shown, the network architecture includes a coordinator 100, at least two target participants (respectively denoted as target participant 200-1 and target participant 200-2, for distinction, and more target participants may be included in actual implementation) and a network 300. To support an exemplary application, the coordinator 100 may be a service terminal of federated learning, such as a server, etc. The coordinator 100 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server based on cloud technology, which is used to query the user's feature data stored in the client terminals of each bank or hospital without leaking privacy. The target participants (including target participants 200-1 and target participants 200-2) may be client terminals of federated learning, such as participant devices of banks or hospitals that store the user's feature data, and the client terminals may be laptops, tablet computers, and desktop computers. The coordinator 100 connects the target participant 200-1 and the target participant 200-2 via the network 300. The network 300 may be a wide area network or a local area network, or a combination of the two, and uses a wireless or wired link to achieve data transmission.

[0057] In the application scenario of this network architecture, the coordinator 100 first determines the target participant 200-1 and the target participant 200-2 from multiple participants according to the characteristics to be queried, and then determines the query request corresponding to the target participant 200-1 and the target participant 200-2 according to the characteristics to be queried, and then distributes the pre-generated public key and the query request to the corresponding target participant 200-1 and the target participant 200-2. The target participant 200-1 and the target participant 200-2 respectively determine the ciphertext query result according to the public key and the query request, and then return the ciphertext query result to the coordinator 100. After the coordinator 100 receives the ciphertext query result returned by the target participant 200-1 and the target participant 200-2, it determines the target data according to the pre-generated private key and each ciphertext query result. In this way, under the premise of ensuring that the data does not leave the local, the cross-table query of data is realized, which can not only protect data privacy and prevent data leakage, but also will not affect the availability of the queried target data.

[0058] The device provided in the embodiments of the present application may be implemented in the form of hardware or a combination of hardware and software. Various exemplary implementations of the device provided in the embodiments of the present application are described below.

[0059] according to Figure 2 The exemplary structure of the data query device is shown. Here, the data query device is shown by taking the coordinator 100 as an example. Other exemplary structures of the data query device can be foreseen, so the structure described here should not be regarded as limiting. For example, some components described below can be omitted, or components not described below can be added to meet the special needs of certain applications.

[0060] Figure 2 The data query device 10 shown includes: at least one processor 110, a memory 140, at least one network interface 120 and a user interface 130. Each component in the data query device 10 is coupled together via a bus system 150. It is understood that the bus system 150 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 150 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 150 is not described in detail. Figure 2 Various buses are labeled as bus system 150 .

[0061] The user interface 130 may include a display, a keyboard, a mouse, a touch pad, a touch screen, and the like.

[0062] The memory 140 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM). The volatile memory may be a random access memory (RAM). The memory 140 described in the embodiments of the present application is intended to include any suitable type of memory.

[0063] The memory 140 in the embodiment of the present application can store data to support the operation of the data query device 10. Examples of such data include: any computer program for operating on the data query device 10, such as an operating system and an application program. Among them, the operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., which are used to implement various basic services and process hardware-based tasks. The application program can include various application programs.

[0064] As an example of the method provided in the embodiment of the present application being implemented by software, the method provided in the embodiment of the present application can be directly embodied as a combination of software modules executed by the processor 110. The software module can be located in a storage medium, and the storage medium is located in the memory 140. The processor 110 reads the executable instructions included in the software module in the memory 140, and completes the method provided in the embodiment of the present application in combination with the necessary hardware (for example, including the processor 110 and other components connected to the bus 150).

[0065] As an example, the processor 110 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0066] The data query method provided in the embodiment of the present application will be explained in combination with the exemplary application and implementation of the device provided in the embodiment of the present application.

[0067] Figure 3 A schematic diagram of an implementation flow of a data query method provided in an embodiment of the present application, which is applied to Figure 1 The coordinator of the network architecture shown will combine Figure 3 The steps shown are explained.

[0068] Step S301, generating a public key for encryption and a private key for decryption.

[0069] In the embodiment of the present application, when the coordinator performs data query under federated learning, the coordinator generates a public key for encryption and a private key for decryption. Through the public key, each participant does not need to send the user feature data stored by itself to the other party or the coordinator, which can protect the privacy of the data of each participant.

[0070] In one implementation, the public key generated by the coordinator can be a public key for homomorphic encryption, and the private key generated can be a private key for homomorphic decryption. Homomorphic encryption is a cryptographic technology based on the computational complexity theory of mathematical problems. The data that has been homomorphically encrypted is processed to obtain an output, and this output is decrypted, and the result is the same as the output result obtained by processing the unencrypted original data in the same way. The generated public key can be used for any of the homomorphic encryptions including additive homomorphic encryption, multiplicative homomorphic encryption, hybrid multiplicative homomorphic encryption, subtractive homomorphic encryption, division homomorphic encryption, algebraic homomorphic encryption (also known as full homomorphic encryption) and arithmetic homomorphic encryption. Full homomorphic encryption here means that the encryption function satisfies both additive homomorphism and multiplicative homomorphism.

[0071] In some embodiments, the public key generated by the coordinator can be used for additive homomorphic encryption, and the generated private key can be used for additive homomorphic decryption, or the public key generated by the coordinator can be used for multiplicative homomorphic encryption, and the generated private key can be used for multiplicative homomorphic decryption, or the public key generated by the coordinator can be used for fully homomorphic encryption, and the generated private key can be used for fully homomorphic decryption. Compared with using fully homomorphic encryption and decryption, using additive homomorphic encryption and decryption during encryption and decryption can improve computing efficiency.

[0072] Step S302: determining at least two target participants from multiple participants in federated learning according to at least two features to be queried.

[0073] Here, each target participant stores feature data of some features to be queried.

[0074] In combination with the application scenario of the embodiment of the present application, if the feature data of the feature to be queried is only stored in one participant, there is no need to perform a connection query, so there are at least two features to be queried, and the feature data of the at least two features to be queried are stored in different participants. Based on this, before the query, it is necessary to determine in which participant the feature data of each feature to be queried is stored based on the at least two features to be queried, that is, it is necessary to determine at least two target participants from multiple participants in federated learning, and each target participant stores the feature data of some features to be queried.

[0075] For example, there are two features to be queried, namely feature A and feature C. There are three federated learning participants: the first participant, the second participant, and the third participant. Among them, the data table of the first participant (represented as Table1) stores the feature data of feature A and feature B, the data table of the second participant (represented as Table2) stores the feature data of feature C and feature D, and the data table of the third participant (represented as Table3) stores the feature data of feature E and feature F. The characteristic data of each participant is kept confidential to other participants and the coordinator, but the table attributes of the data table do not need to be kept confidential, that is, the coordinator can obtain the table attributes of the data table of each participant from each participant. Specifically, the table attributes obtained from the first participant are (Table1; ID, A, B), the table attributes obtained from the second participant are (Table2; ID, C, D), and the table attributes obtained from the third participant are (Table3; ID, E, F). Among the obtained table attributes, Table1, Table2, and Table3 are table names, ID is an identifier that distinguishes different users (such as an ID number that can distinguish different users), and A, B, C, D, E, and F are features. Based on the features to be queried and the table attributes of the data tables stored by each participant, the coordinator can determine that the characteristic data of the feature A to be queried is stored in Table1 of the first participant, and the characteristic data of the feature C to be queried is stored in Table2 of the second participant, thereby determining that the target participants are the first participant and the second participant.

[0076] Step S303, determining the query request corresponding to each target participant.

[0077] In step S302, the table name and characteristics of the data table corresponding to each feature to be queried have been determined, based on which the query conditions corresponding to each target participant can be determined, and the query request to be sent to each target participant is determined by the query conditions.

[0078] Still using the above example to illustrate, since it is necessary to determine whether the feature data of feature A and the feature data of feature C are from the same user, when querying the feature data of feature A, it is necessary to simultaneously query the identification ID corresponding to each feature data, and determine which feature data belong to the same user based on the identification ID.

[0079] In one implementation, the characteristic data of each target participant may be queried separately first, and then a connection query may be performed.

[0080] In this implementation, after determining that the feature data of feature A to be queried is stored in Table 1 of the first participant, the query condition is obtained: query the IDs of all users in Table 1 and the feature data of feature A, which is recorded as: SELECT a.ID, aA from Table 1 a, where a is another name for Table 1. A first query request is generated and sent to the first participant according to the query condition.

[0081] Similarly, after determining that the feature data of feature C to be queried is stored in Table 2 of the second participant, the query condition is obtained: query the IDs of all users in Table 2 and the feature data of feature C, which is recorded as: SELECT b.ID, bC from Table 2 b, where b is another name for Table 2. A second query request is generated and sent to the second participant according to the query condition.

[0082] In another implementation method, you can first query all users of a feature in the corresponding target participant and the feature data of the feature; then, based on the user identifier in the previous query result, determine the user features that need to be queried in the next query. That is, this implementation method determines the current query conditions based on the previous query results, and then generates various query requests that are sent to each participant.

[0083] In this implementation, after determining that the feature data of feature A to be queried is stored in Table 1 of the first participant, the query condition is obtained: query the IDs of all users in Table 1 and the feature data of feature A, recorded as: SELECTa.ID,aA from Table 1 a. A first query request sent to the first participant is generated according to the query condition.

[0084] The first query request is sent to the first participant, and the first participant queries its own data table, obtains and returns the first query result to the coordinator. The coordinator extracts the user identification set S1 = {s1, s2, s3} from the first query result; the query is continued, and after determining that the feature data of the feature C to be queried is stored in Table2 of the second participant, the query condition is obtained: query the user ID and feature data of feature C belonging to S1 in Table2, recorded as: SELECT b.ID, bC fromTable2 b where b.ID in S1. The second query request sent to the second participant is generated according to the query condition.

[0085] In another implementation, all users of each target participant may be queried separately first, a connection query may be performed on the users of each target participant to determine the common users, and then the characteristic data of the common users may be queried separately.

[0086] In this implementation, after determining that the feature data of feature A to be queried is stored in Table 1 of the first participant, the query condition is obtained: query the IDs of all users in Table 1, recorded as: SELECT a.ID from Table 1 a. After determining that the feature data of feature C to be queried is stored in Table 2 of the second participant, the query condition is obtained: query the IDs of all users in Table 2, recorded as: SELECT b.ID from Table 1 b. Then, the common user is determined based on the two query results, and the user identification set of the common user is recorded as S2 = {s1, s2}.

[0087] After the common user is determined, the query condition of the first participant is determined as: querying the feature data of feature A belonging to the user S2 in Table1, recorded as: SELECT a.ID, aA from Table1 a where a.ID in S2. A first query request sent to the first participant is generated according to the query condition.

[0088] Similarly, after determining the common user, the query condition of the second participant is determined as: querying the feature data of feature C belonging to user S2 in Table2, recorded as: SELECT b.ID, bC from Table1 b where b.ID in S2. A second query request sent to the second participant is generated according to the query condition.

[0089] The above-mentioned implementation methods can all determine the query request sent to each target participant. In the first implementation method, the coordinator and each target participant only need to interact once. The advantages are that the number of interactions is small, the interactions between the coordinator and each target participant are independent of each other, and concurrent queries can be performed. The disadvantage is that each interaction requires the transmission of feature data of all users of the to-be-queried features held by each target participant, which is a large amount of data transmission, slow transmission speed, and consumption of network resources. In the second implementation method, the coordinator and each target participant only need to interact once. The advantages are that the number of interactions is small and the amount of data transmitted is moderate. The disadvantage is that the next query needs to be based on the last query result, and concurrent queries cannot be performed, which affects the query speed. In the third implementation method, the coordinator and each target participant need to interact twice. The advantages are that the amount of data transmitted is small, and concurrent queries can be performed after determining the common user. The disadvantage is that the coordinator needs to interact with each target participant twice, and the number of interactions is large. In actual applications, one of the implementation methods can be selected based on the actual situation such as the amount of data to be queried and the connection method.

[0090] Step S304: Send the public key and the query request corresponding to each target participant to the corresponding target participant.

[0091] Step S305, receiving the ciphertext query results sent by each target participant.

[0092] The ciphertext query result is determined by each target participant based on the public key and the query request received by each party.

[0093] The coordinator sends the public key and the first query request to the first participant. The first participant responds to the first query request and queries the data table Table1 held by itself to obtain the first plaintext query result. In order to ensure that the data is not leaked, the first plaintext query result is encrypted using the public key to obtain the first ciphertext query result. The first participant returns the first ciphertext query to the coordinator.

[0094] Similarly, the coordinator sends the public key and the second query request to the second participant. The second participant responds to the second query request and queries the data table Table2 held by itself to obtain the second plaintext query result. The second plaintext query result is encrypted using the public key to obtain the second ciphertext query result. The second participant returns the second ciphertext query to the coordinator.

[0095] Step S306, determining the target data based on the private key and the ciphertext query results sent by each target participant.

[0096] After receiving the first ciphertext query result of the first participant and the second ciphertext query result of the second participant, the coordinator performs a cross-table connection query on the first ciphertext query result and the second ciphertext query result according to a predefined connection method to obtain the result of the connection query, which is ciphertext data. The coordinator then uses the private key to decrypt the ciphertext data to obtain the target data. In this way, cross-table data query is realized under the premise of ensuring that the data does not leave the local area of ​​each participant, which can not only protect data privacy and prevent data leakage, but also will not affect the availability of the queried target data.

[0097] In the embodiment of the present application, the private key is only held by the coordinating party. Even if other participating parties intercept the ciphertext query results, they cannot decrypt the ciphertext query results to obtain the plaintext query results because they cannot know the private key. In this way, cross-table connection query of user feature data is realized under the premise of protecting the privacy data of each participating party.

[0098] The data query method provided by the embodiment of the present application is that the coordinator generates a public key for encryption and a private key for decryption; according to at least two features to be queried, at least two target participants are determined from multiple participants of federated learning, and the query request corresponding to each target participant is determined, and each target participant stores the characteristic data of some features to be queried; the public key and the query request corresponding to each target participant are sent to the corresponding target participant; the ciphertext query result sent by each target participant is received, and the ciphertext query result is determined by each target participant based on the public key and the query request received by each target participant; the target data is determined according to the private key and the ciphertext query result sent by each target participant. Under the premise of ensuring that the data does not leave the local area of ​​each participant, cross-table query of data is realized, which can not only protect data privacy and prevent data leakage, but also will not affect the availability of the queried target data.

[0099] In some embodiments, the above Figure 3 In the illustrated embodiment, step S302 “determining at least two target participants from multiple participants in federated learning according to at least two features to be queried” can be implemented by the following steps:

[0100] Step S3021, obtaining table attributes of the data table stored by each participant from multiple participants in federated learning.

[0101] The method provided in the embodiment of the present application can be applied to any number of two or more features to be queried. It should be noted that the feature data of the at least two features to be queried are stored in two different parties. The following example is taken as an example with two features to be queried. The two features to be queried are recorded as feature A and feature C.

[0102] The coordinator obtains the table attributes of all participants from all participants in the federated learning in advance. The table attributes here include the table name and characteristics of the data table. For example, there are 3 participants in the federated learning: the first participant, the second participant, and the third participant.

[0103] The data table of the first participant is shown in Table 1 below, the data table of the second participant is shown in Table 2 below, and the data table of the third participant is shown in Table 3 below

[0104] Table 1 Data table of the first participant Table 1

[0105] ID A B 1 a1 b1 2 a2 b2 3 a3 b3 4 a4 b4

[0106] Table 2 Data table of the second participant Table 2

[0107] ID C D 2 c2 d2 4 c4 d4 5 c5 d5 6 c6 d6

[0108] Table 3 Data table of the third party

[0109] ID E F 2 e2 f2 5 e5 f5 7 e7 f7 8 e8 f8

[0110] The characteristic data of each participant, such as (1, 2, 3, 4, a1, a2, a3, a4, b1, b2, b3, b4) of the first participant, is confidential to other participants and the coordinator, but the table attributes of the data table, such as (Table1; ID, A, B) of the first participant, do not need to be confidential, so the coordinator can obtain the table attributes of the data table of each participant from each participant. For example, the coordinator can obtain the table attributes of the data table stored by each participant from the above three tables: the table attributes obtained from the first participant are (Table1; ID, A, B), the table attributes obtained from the second participant are (Table2; ID, C, D), and the table attributes obtained from the third participant are (Table3; ID, E, F), where Table1, Table2 and Table3 are table names, ID is an identifier to distinguish different users (such as an ID number that can distinguish different users), and A, B, C, D, E and F are features.

[0111] Step S3022: Determine the data table corresponding to each feature to be queried according to at least two features to be queried and table attributes of the data table stored by each participant.

[0112] The feature data of the at least two features to be queried are stored in different participants of the federated learning.

[0113] The coordinator determines that the data table corresponding to the feature A to be queried is Table1, and the data table corresponding to the feature C to be queried is Table2 based on the feature A to be queried, the feature C to be queried and the obtained table attributes (Table1; ID, A, B), (Table2; ID, C, D) and (Table3; ID, E, F).

[0114] Step S3023, determining the participants corresponding to each data table as target participants.

[0115] The participant corresponding to the data table is the participant storing the data table. The participant corresponding to Table1 is the first participant, and the participant corresponding to Table2 is the second participant, thereby determining the first participant and the second participant as the target participants.

[0116] In the embodiment of the present application, after receiving the query instruction, the coordinator obtains the table attributes of each participant that do not need to be kept confidential from each participant in the federated learning, and the table attributes can characterize the features stored by each participant, and then determines the target participant that stores the feature data of the feature to be queried based on the feature to be queried and the table attributes of the data table stored by each participant. By obtaining the table attributes that do not need to be kept confidential from each participant, the target participant corresponding to each feature to be queried can be determined, which makes it possible to realize cross-table connection query under the premise of protecting data privacy.

[0117] In some embodiments, the above Figure 3 In the illustrated embodiment, step S303 "determining the query request corresponding to each target participant" can be implemented by the following steps:

[0118] Step S3031, determining the query conditions corresponding to each target participant according to each feature to be queried and the data table corresponding to each feature to be queried.

[0119] When determining the query conditions, it can be implemented based on the following three different implementation methods:

[0120] The first implementation method is: sorting each feature to be queried to determine the query order; determining the feature to be queried this time according to the query order; and determining the query conditions of the target participant corresponding to this query based on the feature to be queried this time and the data table corresponding to the feature to be queried this time.

[0121] This implementation method can be applied to application scenarios where the connection methods are inner join, left join, right join and full join. The purpose of determining the query order is to ensure that each target participant has interacted. In actual implementation, if it can be ensured that each target participant can be interacted with, the query can be performed in a non-query order.

[0122] During implementation, after determining that the feature data of feature A to be queried is stored in Table 1 of the first participant, the query condition is obtained as follows: query the IDs of all users in Table 1 and the feature data of feature A, recorded as: SELECT a.ID, a.A from Table 1 a.

[0123] Similarly, after determining that the feature data of feature C to be queried is stored in Table2 of the second participant, the query condition is obtained: query the IDs of all users in Table2 and the feature data of feature C, recorded as: SELECT b.ID,bC fromTable2 b.

[0124] In this implementation, the coordinator and each target participant only need to interact once. The advantages are that the number of interactions is small, the interactions between the coordinator and each target participant are independent of each other, and concurrent queries can be performed. The disadvantage is that each interaction requires sending the feature data of all users of the features to be queried held by each target participant, which requires the transmission of large amounts of data, slow transmission speed, and consumption of network resources.

[0125] The second implementation method is: sorting each feature to be queried to determine the query order; determining the feature to be queried this time according to the query order; when this query is the first query, determining the query condition of the target participant corresponding to the first query based on the first feature to be queried and the data table corresponding to the first feature to be queried; when this query is not the first query, extracting the ciphertext identifier of the last ciphertext query result based on the ciphertext query result obtained in the last query; determining the query condition of the target participant corresponding to this query based on the ciphertext identifier of the last ciphertext query result, the feature to be queried this time and the data table corresponding to the feature to be queried this time.

[0126] This implementation can be applied to application scenarios where the connection mode is inner join, left join, and right join. When the connection mode is inner join, the purpose of determining the query order is to determine that each target participant has interacted. When the connection mode is left join or right join, the purpose of determining the query order is not only to determine that each target participant has interacted, but also to ensure that each result is queried. When the connection mode is left join, the table for left join needs to precede other tables, so that the feature data of all users of the left join table can be queried. When the connection mode is right join, the table for right join needs to precede other tables, so that the feature data of all users of the right join table can be queried. This implementation is not applicable to application scenarios where the connection mode is full join query.

[0127] In implementation, if the query order is determined as: query feature A to be queried first, then query feature C to be queried. After determining that the feature data of feature A to be queried is stored in Table 1 of the first participant, the first query condition is obtained: query the feature data of feature A and all users' IDs in Table 1, recorded as: SELECT a.ID, aA from Table 1 a.

[0128] When determining the query condition for querying the feature C to be queried, the coordinator needs to first obtain the first query result of the feature A to be queried, and determine the query condition of the feature C to be queried based on the first query result. The implementation steps are: the coordinator generates a first query request sent to the first participant according to the first query condition. The first query request is sent to the first participant, and the first participant queries its own data table to obtain the first plaintext query result, encrypts the first plaintext query result with the public key, obtains and returns the first ciphertext query result to the coordinator. The coordinator extracts the user identification set S1={s1, s2, s3} from the first ciphertext query result, where s1, s2, s3 are encrypted user identifications. After determining that the feature data of the feature C to be queried is stored in Table2 of the second participant, the second query condition is determined to be: query the user ID and feature data of feature C belonging to S1 in Table2, recorded as: SELECT b.ID, bC from Table2 b where b.ID in S1.

[0129] In this implementation, the coordinator and each target participant only need to interact once. The advantages are small number of interactions and moderate amount of data transmission. The disadvantage is that the next query needs to be based on the results of the previous query, and concurrent queries are not possible, which affects the query speed.

[0130] The third implementation method is: sort the features to be queried to determine the query order; obtain the target ciphertext identifier of each target participant; determine the features to be queried this time according to the query order; determine the query conditions of the target participants corresponding to this query based on the features to be queried this time, the target ciphertext identifier and the data table corresponding to the features to be queried this time.

[0131] This implementation can be applied to application scenarios where the connection mode is inner connection and full connection. When the connection mode is inner connection, the target ciphertext identifier is the intersection of the ciphertext identifiers of each target participant; when the connection mode is full connection, the target ciphertext identifier is the union of the ciphertext identifiers of each target participant. The purpose of determining the query order is to ensure that each target participant has interacted. In actual implementation, if it can be ensured that each target participant can be interacted with, the query can be performed in a non-query order.

[0132] When implementing, you can first query all users of each target participant separately, and connect the users of each target participant according to the connection method to determine the target user. For example, if it is determined that the feature data of feature A to be queried is stored in Table1 of the first participant, the query condition is: query the IDs of all users in Table1, recorded as: SELECT a.ID fromTable1 a. If it is determined that the feature data of feature C to be queried is stored in Table2 of the second participant, the query condition is: query the IDs of all users in Table2, recorded as: SELECT b.ID from Table1 b. Then determine the target user based on the results of the two ciphertext queries, and record the user ID set of the target user as S2 = {s1, s2}, where s1 and s2 are encrypted user IDs.

[0133] After the target user is determined, query requests are sent to each target participant to query the target user's feature data. The first query condition for determining the first participant is: query the feature data of feature A of the user belonging to S2 in Table1, recorded as: SELECT a.ID, aA from Table1 a where a.ID in S2. Similarly, the second query condition for determining the second participant is: query the feature data of feature C of the user belonging to S2 in Table2, recorded as: SELECT b.ID, bC from Table1 b where b.ID in S2.

[0134] Step S3032: Based on the query conditions corresponding to each target participant, generate a query request corresponding to each target participant.

[0135] The method provided in the embodiment of the present application determines the query conditions corresponding to each target participant based on each feature to be queried and the data table corresponding to each feature to be queried, and then generates a corresponding query request, and sends the corresponding query request to the corresponding target participant to realize data query for each target participant.

[0136] In some embodiments, the above Figure 3 In the illustrated embodiment, step S306 "determining target data according to the private key and the ciphertext query results sent by each target participant" can be implemented by the following steps:

[0137] Step S3061, connecting the ciphertext query results sent by each target participant according to a predefined connection method to obtain ciphertext data.

[0138] Here, the connection modes include inner connection, left connection, right connection and full connection.

[0139] In the embodiment of the present application, when the connection mode is an inner connection, the query condition is determined by taking the data table provided in the above step S3021 and combining it with the first implementation mode in step S3031 as an example.

[0140] The first query condition carried in the first query request sent by the coordinator to the first participant is SELECTa.ID,aA from Table1 a. The first participant searches Table1 according to the first query condition and obtains the first plaintext query result as shown in Table 4:

[0141] Table 4 The first plaintext query result obtained by inner connection

[0142] ID A 1 a1 2 a2 3 a3 4 a4

[0143] The first participant encrypts the first plaintext query result using the public key to obtain a first ciphertext query result. In the embodiment of the present application, “[[]]” is used to represent encryption. The obtained first ciphertext query result is shown in Table 5:

[0144] Table 5 The first ciphertext query results obtained by inner connection

[0145] ID A [[1]] [[a1]] [[2]] [[a2]] [[3]] [[a3]] [[4]] [[a4]]

[0146] The second query condition carried in the second query request sent by the coordinator to the second participant is SELECTb.ID,bC from Table2 b. The second participant searches Table2 according to the second query condition and obtains the second plaintext query result as shown in Table 6:

[0147] Table 6 The second plaintext query result obtained by inner connection

[0148] ID C 2 c2 4 c4 5 c5 6 c6

[0149] The second participant uses the public key to encrypt the second plaintext query result, and the obtained second ciphertext query result is shown in Table 7:

[0150] Table 7 The second ciphertext query results obtained by inner connection

[0151] ID C [[2]] [[c2]] [[4]] [[c4]] [[5]] [[c5]] [[6]] [[c6]]

[0152] The coordinator receives the first ciphertext query result shown in Table 5 from the first participant, and receives the second ciphertext query result shown in Table 7 from the second participant. The first ciphertext query result and the second ciphertext query result are inner-connected, and the ciphertext data obtained are shown in Table 8:

[0153] Table 8: Ciphertext data obtained by internal connection

[0154] ID A C [[2]] [[a2]] [[c2]] [[4]] [[a4]] [[c4]]

[0155] In the embodiment of the present application, when the connection mode is left connection, the query order is to first query the feature A to be queried, and then query the feature C to be queried. The data table provided in the above step S3021 is combined with the second implementation mode in step S3031 to determine the query condition for example.

[0156] The first query condition carried in the first query request sent by the coordinator to the first participant is SELECTa.ID,aA from Table1 a. The first participant searches Table1 according to the first query condition and obtains the first plaintext query result as shown in Table 9:

[0157] Table 9 The first plaintext query result obtained by left join

[0158] ID A 1 a1 2 a2 3 a3 4 a4

[0159] The first participant encrypts the first plaintext query result using the public key, and the obtained first ciphertext query result is shown in Table 10:

[0160] Table 10 The first ciphertext query result obtained by left join

[0161] ID A [[1]] [[a1]] [[2]] [[a2]] [[3]] [[a3]] [[4]] [[a4]]

[0162] The coordinator receives the first ciphertext query result shown in Table 10 from the first participant, and extracts the ciphertext identifier set S1 = {[[1]], [[2]], [[3]], [[4]]} from the first ciphertext query result. The second query condition corresponding to the feature C to be queried is determined to be: SELECT b.ID, bC from Table2 b where b.ID in S1. The second participant queries Table2 according to the second query condition and obtains the second plaintext query result as shown in Table 11:

[0163] Table 11 The second plaintext query result obtained by left join

[0164] ID C 2 c2 4 c4

[0165] The second participant uses the public key to encrypt the second plaintext query result. The obtained second ciphertext query result is shown in Table 12:

[0166] Table 12 The second ciphertext query results obtained by left join

[0167] ID C [[2]] [[c2]] [[4]] [[c4]]

[0168] The coordinator receives the first ciphertext query result shown in Table 10 from the first participant, and receives the second ciphertext query result shown in Table 12 from the second participant. The first ciphertext query result and the second ciphertext query result are left-connected, and the ciphertext data obtained is shown in Table 13:

[0169] Table 13 ciphertext data obtained by left connection

[0170]

[0171]

[0172] It should be noted here that since the second ciphertext query result does not contain feature data with IDs [[1]] and [[3]], it is empty, represented by NULL.

[0173] In the embodiment of the present application, when the connection mode is a full connection, the query condition is determined by taking the data table provided in the above step S3021 and combining it with the third implementation mode in step S3031 as an example.

[0174] The coordinator first queries all users of each target participant separately, and connects the users of each target participant in a full-connection manner to determine the target user.

[0175] The coordination direction sends a query request with the query condition SELECT a.ID from Table1 a to the first participant, and obtains the ciphertext identifier set Sa = {[[1]], [[2]], [[3]], [[4]]}; the coordination direction sends a query request with the query condition SELECT b.ID from Table1 b to the second participant, and obtains the ciphertext identifier set Sb = {[[2]], [[4]], [[5]], [[6]]}. Sa and Sb are fully connected to obtain the target user S2 = {[[1]], [[2]], [[3]], [[4]], [[5]], [[6]]}.

[0176] The first query condition carried in the first query request sent by the coordinator to the first participant is SELECTa.ID,aA from Table1 a where a.ID in S2. The first participant searches Table1 according to the first query condition and obtains the first plaintext query result as shown in Table 14:

[0177] Table 14 The first plaintext query result obtained by full connection

[0178] ID A [[1]] a1 [[2]] a2 [[3]] a3 [[4]] a4 [[5]] NULL [[6]] NULL

[0179] The first participant encrypts the first plaintext query result using the public key, and the obtained first ciphertext query result is shown in Table 15:

[0180] Table 15 The first ciphertext query results obtained by full connection

[0181] ID A [[1]] [[a1]] [[2]] [[a2]] [[3]] [[a3]] [[4]] [[a4]] [[5]] NULL [[6]] NULL

[0182] The second query condition carried in the second query request sent by the coordinator to the second participant is SELECT b.ID, bC from Table1 b where b.ID in S2. The second participant searches Table2 according to the second query condition and obtains the second plaintext query result as shown in Table 16:

[0183] Table 16 The second plaintext query results obtained by full connection

[0184] ID C [[1]] NULL [[2]] c2 [[3]] NULL [[4]] c4 [[5]] c5 [[6]] c6

[0185] The second participant uses the public key to encrypt the second plaintext query result. The obtained second ciphertext query result is shown in Table 17:

[0186] Table 17 Second ciphertext query results obtained by full connection

[0187] ID C [[1]] NULL [[2]] [[c2]] [[3]] NULL [[4]] [[c4]] [[5]] [[c5]] [[6]] [[c6]]

[0188] The coordinator receives the first ciphertext query result shown in Table 15 from the first participant, and receives the second ciphertext query result shown in Table 17 from the second participant. The first ciphertext query result and the second ciphertext query result are fully connected, and the ciphertext data obtained are shown in Table 18:

[0189] Table 18 Encrypted data obtained by full connection

[0190] ID A C [[1]] [[a1]] NULL [[2]] [[a2]] [[c2]] [[3]] [[a3]] NULL [[4]] [[a4]] [[c4]] [[5]] NULL [[c5]] [[6]] NULL [[c6]]

[0191] Step S3062, use the private key to decrypt the ciphertext data to obtain the target data.

[0192] The coordinator uses the pre-generated private key to decrypt the ciphertext data obtained in step S3061 to obtain the target data. For example, the ciphertext data shown in Table 8, Table 13 and Table 18 in step S3061 are decrypted to obtain the corresponding target data as shown in Table 19, Table 20 and Table 21 respectively:

[0193] Table 19 Target data obtained by inner connection

[0194] ID A C 2 a2 c2 4 a4 c4

[0195] Table 20 Target data obtained by left connection

[0196] ID A C 1 a1 NULL 2 a2 c2 3 a3 NULL 4 a4 c4

[0197] Table 21 Target data obtained by full connection

[0198]

[0199]

[0200] In an embodiment of the present application, the coordinator can perform homomorphic decryption on the ciphertext data according to a pre-generated private key to obtain the target data, which is the feature data of the feature to be queried.

[0201] The method provided in the embodiment of the present application is that the coordinator connects the ciphertext query results sent by each target participant in a corresponding connection mode according to a predefined connection mode to obtain the ciphertext data, and then uses the private key to decrypt it to obtain the target data to obtain the feature data of the feature to be queried. Under the premise of ensuring that the data does not leave the local area, cross-table query of data is realized, and the availability of the queried target data will not be affected.

[0202] Based on the above embodiments, the present application further provides a data query method. Figure 4 Another implementation flow diagram of the data query method provided in the embodiment of the present application is applied to Figure 1 The target participants in the network architecture shown are Figure 4 As shown, the data query method includes the following steps:

[0203] Step S401: receiving a public key and a query request sent by a coordinator.

[0204] When performing cross-table data queries, the coordinator generates a public key for encryption and a private key for decryption, and then sends the public key to each target participant, so that each target participant can use the public key to perform cross-table data queries while ensuring the privacy of their own data.

[0205] Step S402: parse the query request to obtain the query conditions carried in the query request.

[0206] After receiving the query request, the target participant parses it to obtain the query condition carried in the query request. Still using the above example for explanation, when the target participant is the first participant, the first query request is parsed to obtain the first query condition.

[0207] The query conditions in the embodiment of the present application are determined by the coordinator according to the features to be queried and the data table corresponding to the features to be queried. The implementation method of determining the query conditions can refer to the detailed description of step S3031.

[0208] Step S403, searching in its own storage space based on the query condition to obtain a plain text query result.

[0209] For example, the target participant is the first participant, whose data table Table1 is shown in Table 1, and the first query condition carried in the first query request sent by the coordinator to the first participant is SELECT a.ID, aA from Table1 a. The first participant searches Table1 shown in Table 1 according to the first query condition, and the first plaintext query result obtained is shown in Table 4.

[0210] Step S404: encrypt the plaintext query result using the public key to obtain a ciphertext query result.

[0211] The first participant uses the public key to encrypt the first plaintext query result, and the obtained first ciphertext query result is shown in Table 5.

[0212] Step S405: Send the ciphertext query result to the coordinator.

[0213] The data query method provided in the embodiment of the present application is applied to the target participant of federated learning. The target participant is a participant that stores some data to be queried. The method includes: receiving the public key and query request sent by the coordinator; parsing the query request to obtain the query conditions carried by the query request; searching in its own storage space based on the query conditions to obtain the plaintext query results; encrypting the plaintext query results with the public key to obtain the ciphertext query results; and sending the ciphertext query results to the coordinator. In this way, cross-table query of data is realized under the premise of ensuring that the data does not leave the local area of ​​the participant, which can not only protect data privacy and prevent data leakage, but also will not affect the availability of the queried target data.

[0214] Based on the above embodiments, the present application further provides a data query method. Figure 5 A schematic diagram of another implementation flow of the data query method provided in the embodiment of the present application, which is applied to Figure 1 The network architecture shown in Figure 5 As shown, the data query method includes the following steps:

[0215] Step S501: The coordinator generates a public key for encryption and a private key for decryption.

[0216] In the embodiment of the present application, when the coordinator performs data query under federated learning, the coordinator generates a public key for encryption and a private key for decryption. Through the public key, each participant does not need to send the user feature data stored by itself to the other party or the coordinator, which can protect the privacy of the data of each participant.

[0217] In one implementation, the public key generated by the coordinator may be a public key used for homomorphic encryption, and the generated private key may be a private key used for homomorphic decryption.

[0218] Step S502: The coordinator obtains table attributes of data tables stored by each of the multiple participants in the federated learning.

[0219] The coordinator obtains the table attributes of the data tables stored by each participant: the table attributes obtained from the first participant are (Table1; ID, A, B), the table attributes obtained from the second participant are (Table2; ID, C, D), and the table attributes obtained from the third participant are (Table3; ID, E, F). Among the obtained table attributes, Table1, Table2, and Table3 are table names, ID is an identifier to distinguish different users (such as an ID number that can distinguish different users), and A, B, C, D, E, and F are features.

[0220] Step S503: The coordinator determines the data table corresponding to each feature to be queried according to at least two features to be queried and table attributes of the data table stored by each participant.

[0221] The coordinator determines that the data table corresponding to the feature A to be queried is Table1, and the data table corresponding to the feature C to be queried is Table2 based on the feature A to be queried, the feature C to be queried and the obtained table attributes (Table1; ID, A, B), (Table2; ID, C, D) and (Table3; ID, E, F).

[0222] Step S504: The coordinator determines the participants corresponding to each data table as target participants.

[0223] Here, each target participant stores feature data of some features to be queried.

[0224] The participant corresponding to the data table is the participant storing the data table. The participant corresponding to Table1 is the first participant, and the participant corresponding to Table2 is the second participant, thereby determining the first participant and the second participant as the target participants.

[0225] Step S505: The coordinator determines the query conditions corresponding to each target participant according to each feature to be queried and the data table corresponding to each feature to be queried.

[0226] When determining the query conditions, it can be implemented based on the following three different implementation methods:

[0227] The first implementation method is: sorting each feature to be queried to determine the query order; determining the feature to be queried this time according to the query order; and determining the query conditions of the target participant corresponding to this query based on the feature to be queried this time and the data table corresponding to the feature to be queried this time.

[0228] The second implementation method is: sorting each feature to be queried to determine the query order; determining the feature to be queried this time according to the query order; when this query is the first query, determining the query condition of the target participant corresponding to the first query based on the first feature to be queried and the data table corresponding to the first feature to be queried; when this query is not the first query, extracting the ciphertext identifier of the last ciphertext query result based on the ciphertext query result obtained in the last query; determining the query condition of the target participant corresponding to this query based on the ciphertext identifier of the last ciphertext query result, the feature to be queried this time and the data table corresponding to the feature to be queried this time.

[0229] The third implementation method is: sort the features to be queried to determine the query order; obtain the target ciphertext identifier of each target participant; determine the features to be queried this time according to the query order; determine the query conditions of the target participants corresponding to this query based on the features to be queried this time, the target ciphertext identifier and the data table corresponding to the features to be queried this time.

[0230] Step S506: The coordinator generates a query request corresponding to each target participant based on the query condition corresponding to each target participant.

[0231] Step S507: The coordinator sends the public key and the query request corresponding to each target participant to the corresponding target participant.

[0232] Step S508: The target participant parses the query request to obtain the query conditions carried in the query request.

[0233] In the embodiment of the present application, the target participants are shown as the first participant and the second participant. After receiving the first query request, the first participant parses it to obtain the first query condition carried by the first query request; after receiving the second query request, the second participant parses it to obtain the second query condition carried by the second query request.

[0234] Step S509: The target participant searches its own storage space based on the query conditions to obtain a plaintext query result.

[0235] The first participant searches the data table Table1 with the first query condition and obtains the first plaintext query result; the second participant searches the data table Table2 with the second query condition and obtains the second plaintext query result.

[0236] Step S510: The target party encrypts the plaintext query result using the public key to obtain a ciphertext query result.

[0237] The first participant uses the public key to homomorphically encrypt the first plaintext query result to obtain a first ciphertext query result; the second participant uses the public key to homomorphically encrypt the second plaintext query result to obtain a second ciphertext query result.

[0238] Step S511: The target participant sends the ciphertext query result to the coordinator.

[0239] The first participant sends the first ciphertext query result to the coordinator; the second participant sends the second ciphertext query result to the coordinator.

[0240] Step S512: The coordinator connects the ciphertext query results sent by each target participant according to a predefined connection method to obtain ciphertext data.

[0241] Here, the connection modes include inner connection, left connection, right connection and full connection.

[0242] Step S513: The coordinator uses the private key to decrypt the ciphertext data to obtain the target data.

[0243] In an embodiment of the present application, the coordinator can perform homomorphic decryption on the ciphertext data according to a pre-generated private key to obtain the target data, which is the feature data of the feature to be queried.

[0244] In the data query method provided in the embodiment of the present application, the coordinator determines at least two target participants from multiple participants in federated learning based on at least two features to be queried, and determines the query request corresponding to each target participant, and then sends the pre-generated public key and the query request corresponding to each target participant to the corresponding target participant. After receiving the query request, each target participant queries its own data table respectively to obtain a plaintext query result, and then uses the public key to encrypt the plaintext query result to obtain a ciphertext query result. The coordinator receives the ciphertext query results sent by each target participant, and determines the target data based on the private key and the ciphertext query results sent by each target participant. In this way, under the premise of ensuring that the data of each participant does not leave the local area of ​​each participant, cross-table query of data is realized, which can not only protect data privacy and prevent data leakage, but also does not perform anonymization and other processing on the data, which will not affect the availability of the queried target data.

[0245] The following is an explanation of an exemplary application of the embodiments of the present application in a practical application scenario.

[0246] Database query is a commonly used database technology. Generally speaking, current database storage is saved in the form of (key, value) pairs consisting of keywords (i.e., identifiers in the above text) and values ​​(i.e., feature data in the above text). Database query means that users use key values ​​to find the value corresponding to a key in the database.

[0247] Multi-table query means that data is distributed in multiple database tables and needs to be queried by joining multiple database tables. The typical methods are inner join, left join, and right join. When multiple tables are distributed in different institutions or clients, we cannot directly share these tables to prevent privacy data leakage. So how can we effectively query the connection results without sharing data?

[0248] Current privacy query technologies either bring multiple tables together or use encryption or anonymization technology to prevent leakage, but this will reduce the availability of data. The embodiment of the present application introduces a database cross-table connection query technology using federated learning.

[0249] Current database privacy protection query technologies include data desensitization, anonymization, differential privacy, and homomorphic encryption. However, these solutions either bring multiple tables together, violating the restrictions on data out of the domain in the privacy protection law; or use encryption or anonymization technology to prevent data leakage, but this will reduce the availability of data.

[0250] The present application embodiment proposes a method of using federated learning technology to implement cross-table connection query. If each database table is distributed in different clients, data is not allowed to leave the local client. Figure 6 , Figure 6 A schematic diagram of database table distribution provided for an embodiment of the present application, wherein databases 1 to database n are distributed in different clients 1 to client n under a server 2, and database k is distributed in client k, where k is an integer between 1 and n.

[0251] For the convenience of explanation and without loss of generality, the following takes the join query of two tables as an example. The two tables are shown as follows, where Table22 is distributed in client A and Table23 is distributed in client B.

[0252] Table 22 Database in client A Table 22

[0253] ID A B 1 a1 b1 2 a2 b2 3 a3 b3 4 a4 b4

[0254] Table 23 Database in client B Table 23

[0255] ID C D 2 c2 d2 4 c4 d4 5 c5 d5 6 c6 d6

[0256] Federated learning implements inner joins:

[0257] Inner join definition: Returns rows where the join fields in two tables are equal. Its syntax is as follows:

[0258] SELECT a.ID,aA,bC from Table22 a JOIN Table23 b;

[0259] Here, Table22 refers to Table 22 in client A, and Table23 refers to Table 23 in client B. The returned result value is:

[0260] Table 24 Inner join result of Table 22 of client A and Table 23 of client B

[0261] ID A C 2 a2 c2 4 a4 c4

[0262] Figure 7 A schematic diagram of an implementation flow of a data query method for implementing inner joins in federated learning provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the data query method includes the following steps:

[0263] Step S701: The server sends public keys for encryption to client A and client B respectively.

[0264] Step S702: The server sends a first SQL statement to client A.

[0265] The first SQL statement is: SELECT a.ID from Table22 a.

[0266] Step S703: Client A receives the first SQL statement, executes it locally, obtains all ID values, encrypts them with the public key, and returns them to the server.

[0267] Step S704: The server extracts all encrypted IDs returned by client A, obtains encrypted ID set S1, and sends S1 and the second AQL statement to client B.

[0268] Among them, the encrypted ID set S1 = {[[1]], [[2]], [[3]], [[4]]} extracted from the search results sent by client A, and the second SQL statement is: SELECT b.ID,bC from Table23 b where b.ID in S1.

[0269] Step S705: Client B encrypts its own data table, executes the second SQL statement, obtains the search result in an encrypted state, and sends the search result back to the server.

[0270] Client B uses the public key to encrypt its own data table. In the encrypted state, it executes the second SQL statement and obtains the search results shown in Table 25:

[0271] Table 25 Search results obtained by client B executing the second SQL statement in an encrypted state

[0272] ID C [[2]] [[c2]] [[4]] [[c4]]

[0273] Step S706: The server extracts the ID value of the search result sent by client B, obtains the encrypted ID set S2, and sends S2 and the third SQL statement to client A.

[0274] Among them, the encrypted ID set S2 = {[[2]], [[4]]} extracted from the search results sent by client B, and the third SQL statement is: SELECT a.ID, aA from Table22 a where a.ID in S2.

[0275] Step S707: Client A executes the third SQL statement, obtains the search result, and returns the search result to the server.

[0276] Client A uses the public key to encrypt its own data table. In the encrypted state, it executes the third SQL statement and obtains the search results shown in Table 26:

[0277] Table 26 Search results obtained by client A executing the third SQL statement in encrypted state

[0278] ID A [[2]] [[a2]] [[4]] [[a4]]

[0279] Step S708: In an encrypted state, the server combines the search result obtained by the client executing the second SQL statement with the search result obtained by client A executing the third SQL statement, performs an inner join operation on the server side to obtain ciphertext data, and decrypts the ciphertext data to obtain the target data.

[0280] The SQL statement for performing the inner join operation on the server side is: SELECT a.ID, aA, bC from Table 25a JOIN Table26 b, and the results are shown in Table 27 below.

[0281] Table 27 Encrypted data obtained by the server performing the inner connection operation

[0282] ID A C [[2]] [[a2]] [[c2]] [[4]] [[a4]] [[c4]]

[0283] After decrypting it, the final result is shown in Table 24.

[0284] Federated learning implements left join:

[0285] Left join definition: also known as left outer join, when executing left join, all data in the left table will be retained, and data in the right table that can match will be correctly retained, and fields that cannot match other tables will be set to NULL. Taking Table 22 and Table 23 as examples, Table 22 is the left table and Table 23 is the right table, and the sql statement syntax is as follows:

[0286] SELECT a.ID,aA,bC from Table22 a left JOIN Table23 b;

[0287] The execution results are shown in Table 28 below:

[0288] Table 28 Left join result of Table22 of client A and Table23 of client B

[0289] ID A C 1 a1 NULL 2 a2 c2 3 a3 NULL 4 a4 c4

[0290] Figure 8 A schematic diagram of an implementation flow of a data query method for left join using federated learning provided in an embodiment of the present application is shown in FIG. Figure 8 As shown, the data query method includes the following steps:

[0291] Step S801: The server sends a public key for encryption to client A and client B.

[0292] Step S802: The server sends a first SQL statement to client A.

[0293] The first SQL statement is: SELECT a.ID,aA from Table22 a.

[0294] Step S803: Client A receives the first SQL statement, executes it locally, obtains the plaintext query result, encrypts the plaintext query result, obtains the search result, and sends the search result back to the server.

[0295] Client A uses the public key to encrypt the plaintext query result of the first SQL statement, and the obtained search result is shown in Table 29:

[0296] Table 29 Search results obtained by client A by encrypting the results obtained by executing the first SQL statement

[0297] ID A [[1]] [[a1]] [[2]] [[a2]] [[3]] [[a3]] [[4]] [[a4]]

[0298] Step S804: The server extracts all encrypted IDs from the search results returned by client A, obtains encrypted ID set S1, and sends S1 and the second SQL statement to client B.

[0299] Among them, the encrypted ID set S1 = {[[1]], [[2]], [[3]], [[4]]} extracted from the search results sent by client A, and the second SQL statement is: SELECT b.ID,bC from Table23 b where b.ID in S1.

[0300] Step S805: Client B encrypts its own data table, executes the second SQL statement, obtains the search result in an encrypted state, and sends the search result back to the server.

[0301] Client B uses the public key to encrypt its own data table. In the encrypted state, it executes the second SQL statement and obtains the search results shown in Table 30:

[0302] Table 30 The search results obtained by client B executing the second SQL statement in the encrypted state

[0303] ID C [[2]] [[c2]] [[4]] [[c4]]

[0304] Step S806: The server combines the search result returned by client A with the search result returned by client B, performs a left join operation on the server to obtain ciphertext data, and decrypts the ciphertext data to obtain the target data.

[0305] The SQL statement for performing the left join operation on the server side is: SELECT a.ID, aA, bC from Table29 aleft JOIN Table30 b, and the results are shown in Table 31 below.

[0306] Table 31 Encrypted data obtained by the server performing a left join operation

[0307] ID A C [[1]] [[a1]] NULL [[2]] [[a2]] [[c2]] [[3]] [[a3]] NULL [[4]] [[a4]] [[c4]]

[0308] After decrypting it, the final result is shown in Table 28.

[0309] Federated learning implements right join:

[0310] Right join definition: also known as right outer join, when a right join is executed, all data in the right table will be retained, and data in the left table that can be matched will be correctly retained, and fields that cannot be matched in other tables will be set to NULL. Taking Table 22 and Table 23 as examples, Table 22 is the left table and Table 23 is the right table, and the sql statement syntax is as follows:

[0311] SELECT b.ID,aA,bC from Table22 a right JOIN Table23 b;

[0312] The execution results are shown in Table 32 below:

[0313] Table 32 Right join result of Table22 of client A and Table23 of client B

[0314] ID A C 2 a2 c2 4 a4 c4 5 NULL c5 6 NULL c6

[0315] Fig. 9 A schematic diagram of an implementation flow of a data query method for implementing right join in federated learning provided in an embodiment of the present application, such as Fig. 9 As shown, the data query method includes the following steps:

[0316] Step S901: The server sends a public key for encryption to client A and client B.

[0317] Step S902: The server sends a first SQL statement to client B.

[0318] The first SQL statement is: SELECT b.ID,bC from Table23 b

[0319] Step S903: Client B receives the first SQL statement, executes it locally, obtains the plaintext query result, encrypts the plaintext query result, obtains the search result, and sends the search result back to the server.

[0320] Client B uses the public key to encrypt the plaintext query result of the first SQL statement, and the obtained search result is shown in Table 33:

[0321] Table 33 Search results obtained by client B by encrypting the results obtained by executing the first SQL statement

[0322] ID C [[2]] [[c2]] [[4]] [[c4]] [[5]] [[c5]] [[6]] [[c6]]

[0323] Step S904: The server extracts all encrypted IDs from the search results returned by client B, obtains an encrypted ID set S1, and sends S1 and the second SQL statement to client A.

[0324] Among them, the encrypted ID set S1 = {[[2]], [[4]], [[5]], [[6]]} extracted from the search results sent by client B, and the second SQL statement is: SELECT a.ID, aA from Table22 a where a.ID in S1.

[0325] Step S905: Client A encrypts its own data table, executes the second SQL statement, obtains the search result in an encrypted state, and sends the search result back to the server.

[0326] Client B uses the public key to encrypt its own data table. In the encrypted state, it executes the second SQL statement and obtains the search results shown in Table 30:

[0327] Table 34 Search results obtained by client B executing the second SQL statement in an encrypted state

[0328] ID A [[2]] [[a2]] [[4]] [[a4]]

[0329] Step S906: The server combines the search result returned by client B with the search result returned by client A, performs a right join operation on the server to obtain ciphertext data, and decrypts the ciphertext data to obtain the target data.

[0330] The SQL statement for performing the right join operation on the server side is: SELECT a.ID,bA,aC from Table33 aleft JOIN Table34 b, and the results are shown in Table 35 below.

[0331] Table 35 Ciphertext data obtained by the server performing the right join operation

[0332] ID A C [[2]] [[a2]] [[c2]] [[4]] [[a4]] [[c4]] [[5]] NULL [[c5]] [[6]] NULL [[c6]]

[0333] After decrypting it, the final result is shown in Table 32.

[0334] The method provided in the embodiment of the present application can realize cross-table connection query of data under the premise of ensuring that the data does not leave the local area, which can not only protect data privacy and prevent data leakage, but also will not affect the availability of the queried target data.

[0335] The following is a description of an exemplary structure of a data query device provided in an embodiment of the present application implemented as a software module. In some embodiments, Figure 2 As shown, the data query device 90 stored in the memory 140 is applied to the coordinator of the federated learning, and the software modules in the data query device 90 may include:

[0336] A generating module 91, used to generate a public key for encryption and a private key for decryption;

[0337] A first determination module 92, for determining at least two target participants from multiple participants in federated learning for at least two features to be queried, each target participant storing feature data of part of the features to be queried;

[0338] A second determination module 93, used to determine the query request corresponding to each target participant;

[0339] A first sending module 94, configured to send the public key and a query request corresponding to each target participant to the corresponding target participant;

[0340] A first receiving module 95, configured to receive the ciphertext query result sent by each target participant, wherein the ciphertext query result is determined by each target participant based on the public key and the query request received by each target participant;

[0341] The third determination module 96 is used to determine the target data according to the private key and the ciphertext query results sent by each target participant.

[0342] In some embodiments, the first determining module 92 is further configured to:

[0343] Obtain table attributes of data tables stored by each of the multiple participants in federated learning;

[0344] Determine a data table corresponding to each feature to be queried according to the at least two features to be queried and table attributes of the data table stored by each participant, wherein the feature data of the at least two features to be queried are stored in different participants of the federated learning;

[0345] The participants corresponding to each data table are determined as target participants.

[0346] In some embodiments, the second determining module 93 is further configured to:

[0347] Determine the query conditions corresponding to each target participant according to each of the features to be queried and the data tables corresponding to each of the features to be queried;

[0348] Based on the query conditions corresponding to each target participant, a query request corresponding to each target participant is generated.

[0349] In some embodiments, the second determining module 93 is further configured to:

[0350] Sorting the features to be queried to determine a query order;

[0351] Determine the features to be queried this time according to the query order;

[0352] According to the features to be queried this time and the data table corresponding to the features to be queried this time, the query conditions of the target participants corresponding to this query are determined.

[0353] In some embodiments, the second determining module 93 is further configured to:

[0354] Sorting the features to be queried to determine a query order;

[0355] Determine the features to be queried this time according to the query order;

[0356] When this query is the first query, the query condition of the target participant corresponding to the first query is determined according to the first feature to be queried and the data table corresponding to the first feature to be queried;

[0357] When this query is not the first query, the ciphertext identifier of the previous ciphertext query result is extracted according to the ciphertext query result obtained from the previous query; based on the ciphertext identifier of the previous ciphertext query result, the features to be queried this time and the data table corresponding to the features to be queried this time, the query conditions of the target participant corresponding to this query are determined.

[0358] In some embodiments, the third determining module 96 is further configured to:

[0359] Connecting the ciphertext query results sent by each target participant according to a predefined connection method to obtain ciphertext data, wherein the connection method includes inner connection, left connection, right connection and full connection;

[0360] The ciphertext data is decrypted using the private key to obtain the target data.

[0361] Based on the foregoing embodiments, the present application further provides a data query device, which is applied to a target participant of federated learning. The target participant is a participant that stores some data to be queried. The software module in the data query device may include:

[0362] A second receiving module, used to receive the public key and query request sent by the coordinator;

[0363] A parsing module, used to parse the query request to obtain the query condition carried by the query request;

[0364] A query module, used to search in its own storage space based on the query conditions to obtain a plaintext query result;

[0365] An encryption module, used to encrypt the plaintext query result using the public key to obtain a ciphertext query result;

[0366] The second sending module is used to send the ciphertext query result to the coordinator.

[0367] It should be noted here that the description of the above data query device embodiment is similar to the above method description and has the same beneficial effects as the method embodiment. For technical details not disclosed in the data query device embodiment of this application, those skilled in the art should refer to the description of the method embodiment of this application for understanding.

[0368] The embodiment of the present application provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the data query method described above in the embodiment of the present application.

[0369] The present application embodiment provides a storage medium storing executable instructions, wherein the executable instructions are stored. When the executable instructions are executed by a processor, the processor will execute the method provided by the present application embodiment, for example, Figure 3 The method shown.

[0370] In some embodiments, the storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or various devices including one or any combination of the above memories.

[0371] In some embodiments, executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0372] As an example, executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions).

[0373] By way of example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices located at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0374] The above is only an embodiment of the present application and is not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A data query method, characterized in that: The method is applied to a coordinator of federated learning, and the method includes: Generate a public key for encryption and a private key for decryption; According to at least two features to be queried, at least two target participants are determined from multiple participants of federated learning, and a query request corresponding to each target participant is determined, wherein each target participant stores feature data of part of the features to be queried; Sending the public key and the query request corresponding to each target participant to the corresponding target participant; Receiving the ciphertext query results sent by the target participants, the ciphertext query results are determined by the target participants based on the public key and the query requests received by each of them; Determine the target data according to the private key and the ciphertext query results sent by each target participant; The step of determining at least two target participants from multiple participants in federated learning according to at least two features to be queried includes: Acquire table attributes of a data table stored by each participant from multiple participants in federated learning, wherein the table attributes include a table name and features of the data table; Determine a data table corresponding to each feature to be queried according to the at least two features to be queried and table attributes of the data table stored by each participant, wherein the feature data of the at least two features to be queried are stored in different participants of the federated learning; Determine the participants corresponding to each data table as target participants; The determining of the query request corresponding to each target participant includes: Determine the query conditions corresponding to each target participant according to each of the features to be queried and the data tables corresponding to each of the features to be queried; Based on the query conditions corresponding to the target participants, generate query requests corresponding to the target participants; The determining of the query conditions corresponding to each target participant according to each to-be-queried feature and the data table corresponding to each to-be-queried feature includes: Sorting the features to be queried to determine a query order; Determine the features to be queried this time according to the query order; When this query is the first query, the query condition of the target participant corresponding to the first query is determined according to the first feature to be queried and the data table corresponding to the first feature to be queried; When this query is not the first query, the ciphertext identifier of the previous ciphertext query result is extracted according to the ciphertext query result obtained from the previous query; based on the ciphertext identifier of the previous ciphertext query result, the features to be queried this time and the data table corresponding to the features to be queried this time, the query conditions of the target participant corresponding to this query are determined.

2. The method according to claim 1, characterized in that The determining of the query conditions corresponding to each target participant according to each to-be-queried feature and the data table corresponding to each to-be-queried feature includes: Sorting the features to be queried to determine a query order; Determine the features to be queried this time according to the query order; According to the features to be queried this time and the data table corresponding to the features to be queried this time, the query conditions of the target participants corresponding to this query are determined.

3. The method according to claim 1, characterized in that Determining target data according to the private key and the ciphertext query results sent by each target participant includes: Connecting the ciphertext query results sent by each target participant according to a predefined connection method to obtain ciphertext data, wherein the connection method includes inner connection, left connection, right connection and full connection; The ciphertext data is decrypted using the private key to obtain the target data.

4. A data query method, characterized in that: The method is applied to a target participant of federated learning, wherein the target participant is a participant storing part of the data to be queried, and the target participant is determined according to at least two features to be queried and table attributes of a data table stored by each participant, wherein the table attributes include a table name and features of the data table; The method comprises: Receive the public key and query request sent by the coordinator; Parsing the query request to obtain the query condition carried by the query request; Searching in its own storage space based on the query condition to obtain a plaintext query result; Encrypting the plaintext query result using the public key to obtain a ciphertext query result; Sending the ciphertext query result to the coordinator; The query request of the target participant determines the query conditions corresponding to each target participant according to each feature to be queried and the data table corresponding to each feature to be queried, and generates based on the query conditions corresponding to each target participant; The determining of the query conditions corresponding to each target participant according to each to-be-queried feature and the data table corresponding to each to-be-queried feature includes: Sorting the features to be queried to determine a query order; Determine the features to be queried this time according to the query order; When this query is the first query, the query condition of the target participant corresponding to the first query is determined according to the first feature to be queried and the data table corresponding to the first feature to be queried; When this query is not the first query, the ciphertext identifier of the previous ciphertext query result is extracted according to the ciphertext query result obtained from the previous query; based on the ciphertext identifier of the previous ciphertext query result, the features to be queried this time and the data table corresponding to the features to be queried this time, the query conditions of the target participant corresponding to this query are determined.

5. A data query device, characterized in that: The device is applied to the coordinator of federated learning, and the device includes: A generation module, used for generating a public key for encryption and a private key for decryption; A first determination module is used for at least two features to be queried, and determines at least two target participants from multiple participants in federated learning, each target participant storing feature data of part of the features to be queried; A second determination module is used to determine the query request corresponding to each target participant; A first sending module, used for sending the public key and the query request corresponding to each target participant to the corresponding target participant; A first receiving module, used to receive the ciphertext query results sent by each target participant, wherein the ciphertext query results are determined by each target participant based on the public key and the query request received by each target participant; A third determination module, used to determine the target data according to the private key and the ciphertext query results sent by each target participant; The first determination module is further used for: Acquire table attributes of a data table stored by each participant from multiple participants in federated learning, wherein the table attributes include a table name and features of the data table; Determine a data table corresponding to each feature to be queried according to the at least two features to be queried and table attributes of the data table stored by each participant, wherein the feature data of the at least two features to be queried are stored in different participants of the federated learning; Determine the participants corresponding to each data table as target participants; The second determination module is further used for: Determine the query conditions corresponding to each target participant according to each of the features to be queried and the data tables corresponding to each of the features to be queried; Based on the query conditions corresponding to the target participants, generate query requests corresponding to the target participants; The second determination module is further used for: Sorting the features to be queried to determine a query order; Determine the features to be queried this time according to the query order; When this query is the first query, the query condition of the target participant corresponding to the first query is determined according to the first feature to be queried and the data table corresponding to the first feature to be queried; When this query is not the first query, the ciphertext identifier of the previous ciphertext query result is extracted according to the ciphertext query result obtained from the previous query; based on the ciphertext identifier of the previous ciphertext query result, the features to be queried this time and the data table corresponding to the features to be queried this time, the query conditions of the target participant corresponding to this query are determined.

6. A data query device, characterized in that: The device is applied to a target participant of federated learning, the target participant is a participant storing part of the data to be queried, the target participant is determined according to at least two features to be queried and table attributes of a data table stored by each participant, the table attributes including a table name and features of the data table; The device comprises: A second receiving module, used to receive the public key and query request sent by the coordinator; A parsing module, configured to parse the query request to obtain the query condition carried by the query request, wherein the query request of the target participant determines the query condition corresponding to each target participant according to each feature to be queried and the data table corresponding to each feature to be queried, and generates based on the query condition corresponding to each target participant; The determining of the query conditions corresponding to each target participant according to each to-be-queried feature and the data table corresponding to each to-be-queried feature includes: Sorting the features to be queried to determine a query order; Determine the features to be queried this time according to the query order; When this query is the first query, the query condition of the target participant corresponding to the first query is determined according to the first feature to be queried and the data table corresponding to the first feature to be queried; When this query is not the first query, the ciphertext identifier of the last ciphertext query result is extracted according to the ciphertext query result obtained in the last query; based on the ciphertext identifier of the last ciphertext query result, the feature to be queried this time and the data table corresponding to the feature to be queried this time, the query condition of the target participant corresponding to this query is determined; A query module, used to search in its own storage space based on the query conditions to obtain a plaintext query result; An encryption module, used to encrypt the plaintext query result using the public key to obtain a ciphertext query result; The second sending module is used to send the ciphertext query result to the coordinator.

7. A data query device, characterized in that: The device comprises: A memory for storing executable instructions; A processor, configured to implement the method of any one of claims 1 to 3 or claim 4 when executing the executable instructions stored in the memory.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores executable instructions for causing a processor to execute the method according to any one of claims 1 to 3 or claim 4.

9. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 3 or claim 4 is implemented.

Images