Patent Publication Number: US-2022231847-A1

Title: Collaborative architecture for secure data sharing

Description:
TECHNICAL FIELD 
     The present disclosure relates generally to data security and data sharing, more specifically to a collaborative architecture for secure data sharing. 
     BACKGROUND 
     An entity, such as a company, may receive requests from clients or customers to render a service. In some cases, the requests should be validated before a corresponding service is rendered by the entity. Often the entity lacks sufficient information for performing such validation and therefore contacts external parties or request further information from clients or customers to proceed with validation. 
     SUMMARY 
     In one embodiment, a device configured to participate in a cyclical collaboration system includes a network interface. The network interface is configured to communicate with a multiple party encryption subsystem, a downstream device, and an upstream device. The device includes a processor configured to receive a request from a third party. A first request value is determined that is associated with the request. A first random number is determined based on the first request value. The first random number is provided to the downstream device. A second random number is received that is generated by the upstream device. A first encrypted request value is determined based on the first request value, the first random number, and the second random number. The first encrypted request value is provided to the multiple party encryption subsystem. Encrypted request values generated by other participants of the cyclical collaboration system are received from the multiple party encryption subsystem. A validation score is determined based on the first encrypted request values and the encrypted request values received from the multiple party encryption subsystem. 
     As described above, a service-providing entity may lack access to sufficient information for validating a request received form a third party. For instance, before a party is granted access to protected information, the service-providing entity may wish to validate the identity of the party and the access rights of the party. As another example, before a requested financial transaction is rendered (e.g., such an approval of requested financing), an entity may wish to review financial records of the third party, such as a record of financing already provided to this third party. Obtaining the requisite information to validate such requests using previous technology can be an inefficient and laborious process for the both the service-providing entity and the requesting third party. As such, previous technology may result in delayed and unreliable validation decisions. 
     This disclosure recognizes that such validations may be improved by allowing multiple service-providing entities to operate collaboratively, such that information for a given third party that may interact with multiple entities can be shared. However, previous technology fails to provide secure and efficient tools for such collaboration. 
     For example, previous technology may reveal protected information associated with the collaborating entities and/or the requesting third party. For instance, if multiple entities share financial information associated with a request for financing from a third party, previous technology may reveal the amount of financing provided to the third party by each entity. This disclosure recognizes a need for improved technology for collaboration without revealing protected information from each entity. 
     Certain embodiments of this disclosure solve technical problems of previous technology used for multi-entity collaboration by providing a collaboration architecture that facilitates the efficient determination of validation decisions without having protected information revealed to other participating entities. For example, the disclosed system provides several technical advantages over previous technology, which include: (1) the ability to determine validation decisions with fewer communications between collaborating devices than was possible using previous technology (e.g., with a number of network calls that scales linearly, or approximately linearly, with the number of collaborating devices); (2) the implementation of multiparty encryption such that results of multi-entity validation assessments are only available to participating entities; and (3) the ability to adjust communications used for multi-entity collaboration and/or validation assessments to further improve information security in cases where one or more of the participating entities is determined to be a less trusted entity (e.g., if one entity determines that further security measures should be implemented to further obscure information from another participating entity). 
     As such, this disclosure may improve the function of computer systems used to share data and/or validate requests. The collaborative validation system described in this disclosure may help ensure requests are validated (or denied if appropriate) in a timely manner, thereby reducing or eliminating delays or bottlenecks imposed by previous technology. This disclosure may particularly be integrated into a practical application of a collaborative validation system which includes a plurality of service provider devices, where each service provider device is configured to participate in the collaboration architecture. The rapid and secure validation of requests, which is uniquely facilitated by this disclosure, may be particularly beneficial for entities receiving large numbers of requests in a relatively short span of time, such that services can be rendered in a timely manner. Since each service provider device is configured to communicate with devices directly upstream and downstream in the unique cyclical collaboration network of this disclosure, the number of communications transmitted for collaborative validation decisions scales approximately linearly with the number of service provider devices in the system. In some situations, a small number of additional communications may be transmitted in cases where a less trusted entity is included in the collaborative validation system, thus providing a significant further increase in security at a relatively small cost in terms of the additional network communication and processing resources consumed. 
     Certain embodiments of this disclosure may include some, all, or none of these advantages. These advantages and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts. 
         FIG. 1  is a schematic diagram of an example system configured for secure multi-entity collaboration; 
         FIG. 2  is a flowchart of a method of secure multi-entity collaboration using the system of  FIG. 1 ; and 
         FIG. 3  is a diagram of an example device configured to implement various components of the system of  FIG. 1 . 
     
    
    
     DETAILED DESCRIPTION 
     As described above, previous technology lacks tools for efficiently and reliably allowing multiple entities to collaborate to make decisions whether a third party should be validated to obtain a requested service. For instance, if a third party, such as a company or person, requests financing, a number of finance-providing entities may already have relevant information (e.g., financial records of the third party, knowledge of existing financing) for determining whether a request for financing should be validated. The multi-entity collaboration system of this disclosure uniquely facilitates the secure determination of validation decisions for such scenarios without revealing protected information from each entity to the other entities. The multi-entity collaboration system includes a plurality of devices that communicate in a unique circular sequence that facilitates the efficient and reliable determination of validation decisions with minimal communication amongst entities and without revealing information from the participating entities. As such, this disclosure facilitates more secure, efficient, and rapid validation (or denial, if appropriate) of requests (e.g., for information access, financing, or the like) than was possible using previous technology. 
     Multi-Entity Collaboration System 
       FIG. 1  is a schematic diagram of an example system  100  for multi-entity collaboration. The system  100  includes a user device  102 , entity devices  108   a - e , and a multiple party (multiparty) encryption subsystem  132 . The entity devices  108   a - e  are generally configured to operate in a collaborative architecture via communication amongst the entity device  108   a - e  and the encryption subsystem  132 , such that each entity device  108   a - e  may determine a validation score (VS)  136  for a request  106  for some service (e.g., for access to information, financing, or the like) from a third party  104 . Each of the entity devices  108   a - e  may operate as a node of a cyclical network for the collaborative determination of the validation score  136 . The number of communications (e.g., network calls to provide random numbers  114   a - e ,  138 ,  142 , described in greater detail below) between entity devices  108   a - e  in order to determine the validation score  136  is relatively small and scales approximately linearly with the number of entity devices  108   a - e . In some cases, a small number of additional communications (e.g., network calls for sending supplemental random numbers  138 ,  142 , described further below) may be sent to provide additional information security (e.g., based on the identification of less trusted entity devices  108   a - e ). The validation score  136  may be shared with the entity devices  108   a - e  using the multi-party encryption subsystem  132  such that the validation results are securely and rapidly available to entity devices  108   a - e  participating in the collaboration system  100 . The entity operating each entity device  108   a - e  may be a provider of a service. 
     The user device  102  may be any device operable to receive an input from a third party  104  corresponding to the request  106 . For example, a user device  102  may be a personal computer or a mobile device operated by the third party  104 . Each user device  102  may include the processor, memory, and/or interface of the device  300  described below with respect to  FIG. 3 . The user device  102  is in communication with at least one of the entity devices  108   a - e . A request  106  generally includes an identification of a requested service (e.g., for creation of an account, access to information, receipt of financing, or the like) and an identification of the requesting third party  104  (e.g., a name or other identifier of the third party  104 ). 
     Each of the entity devices  108   a - e  is generally any device or collection of devices (e.g., a collection of devices implemented as a server, a virtual server, or the like) operable to participate in the collaboration system  100 . Each entity device  108   a - e  is operable to communicate with at least two other entity devices  108   a - e  (i.e., an entity device  108   a - e  upstream and another entity device  108   a - e  downstream from a given entity device  108   a - e ) and the encryption subsystem  132 . Each entity device  108   a - e  may include the processor, memory, and/or interface of the device  300  described below with respect to  FIG. 3 . Each entity device  108   a - e  includes resources for orchestrating the cyclical communication between the entity devices  108   a - e  illustrated in  FIG. 1 , such that a validation score  136  can be determined without exposing protected information  112   a - e  from each entity device  108   a - e . The example of  FIG. 1  shows five entity devices  108   a - e  operating in a collaboration network. However, it should be understood that the collaboration network could include any number of entity devices  108   a - e . For instance, in some cases, the system  100  may include tens, hundreds, or more of entity devices  108   a - e.    
     Each entity device  108   a - e  includes a random number generator  110   a - e , network node sequencer  116   a - e , a trusted node identifier  118   a - e , and a message composer  120   a - e . The random number generator  110   a - e  generally determines a random number  114   a - e  for a protected value  112   a - e  associated with a request  106  received by at least one of the entity devices  108 a-e. For example, the first entity device  108   a,  upon receiving the request  106 , may determine a value  112   a - e  that is associated with this request  106 . For instance, if the request  106  is for financing, the determined value  112   a - e  may be an amount of financing already provided to the third party  104  by the entity operating device  108   a,  or an “exposure” of the entity to financing to the third party  104 . In this example, the random number generator  110   a  generates random number  114   a  based on this exposure value  112   a.  The random number  114   a - e  may be the sum of a randomly generated number and the protected value  112   a - e . The randomly generated number used to generate random number  114   a - e  may be generated using any approach, including, for example, a pseudo random number generator. 
     The network node sequencer  116   a - e  generally monitors information received from the other entity devices  108   a - e  and determines the next entity device  108   a - e  (e.g., node in the collaboration network) to which the random number  114   a - e  should be transmitted. The network node sequencer  116   a - e  ensures that the entity devices  108   a - e  communicate in a linear network, as illustrated in  FIG. 1 , and that each entity device  108   a - e  participating in the collaboration system  100  receives a random number  126   a - e.    
     The trusted node identifier  118   a - e  generally determines whether the next entity device  108   a - e  identified by the network node sequencer  116   a - e  is trusted to be the recipient of information from the entity device  108   a - e . This approach may significantly reduce the number of network calls sent to achieve the validation score  136 , as described further below. For instance, rather than sending a network call to send a message  122   a - e  to every participating entity device  108   a - e , such calls are limited to the next entity device  108   a - e  in the collaboration network. As described in greater detail below, in some cases, additional random numbers  138 ,  142  may be determined and transmitted (e.g., via corresponding additional messages  140 ,  144 ) to additional entity devices  108   a - e  to further improve information security, as described in greater detail below. For instance, in the example of  FIG. 1 , entity device  108   c  generates an additional random number  138  and provides this number  138  to entity device  108   e  using message  140 . 
     The message composer  120   a - e  then generates a message  122   a - e  that is provided to the next entity device  108   a - e  in the collaboration system  100 . The message  122   a  includes at least the request  106  (e.g., or information extracted from the request  106 , such as an invoice identifier), an identifier  124  of the requesting party  104  (e.g., an identifying name or number of the third party  104 ), and the random number  114   a - e . The message  122   a - e  may also include information about the entity devices  108   a - e  participating in the collaboration network. A request repository  126   a - e  may store a record of requests  106  received by the entity devices  108   a,e  and other corresponding information, such as received messages  122   a - e ,  140 ,  144 , transmitted messages  122   a - e ,  140 ,  144 , validation scores  136 , and the like. 
     The cryptographic broadcaster  128   a - e  determines an encrypted validation value  130   a - e  for the entity device  108   a - e . The encrypted validation value  130   a - e  may be determined as the protected value  112   a - e  plus the sum of all input random numbers  114   a - e ,  138 ,  142  for the entity device  108   a - e  minus the sum of output random numbers  114   a - e ,  138 ,  142  for the entity device  108   a - e , as illustrated in the example of  FIG. 1 . 
     The encrypted value  130   a - e  is provided to the multiparty encryption subsystem  132 . For example, the encrypted value  130   a - e  may be published using a gossip protocol and secured by the multiparty encryption subsystem  132  to prevent non-participating entities or other unauthorized users from accessing the individual values  130   a - e . The multiparty encryption subsystem  132  is described in greater detail below. 
     A validation evaluator  134   a - e  receives information from the encryption subsystem  132  and determines a validation score  136  from this information. In the example of  FIG. 1 , the validation evaluator  134   a - e  receives all of the encrypted values  130   a - e  that were determined by the entity devices  108   a - e  and provided to the encryption subsystem  132 . As an example, the validation score  136  may be determined as the sum of all of the encrypted values  130   a - e . In this example, the sum of all of the encrypted values  130   a - e  corresponds to the sum of all of the protected values  112   a - e  stored by the entity devices  108   a - e . As such, the collaboration system  100  allows determination of the sum of these protected values  112   a - e , which may represent financing provided to, or owed by, the third party  104  or exposure of each entity to this financing, without any of the individual protected values  112   a - e  being exposed to the other entity devices  108   a - e . The validation evaluator  134   a - e  may compare the validation score  136  to a threshold value, and if the score  136  is less than the threshold value, the request  106  may be validated. The entity device  108   a - e  may automatically process the request or the entity device  108   a - e  may provide a report indicating the request is validated to an appropriate party for processing the request  106 . 
     The multiparty encryption subsystem  132  is generally any device or collection of devices (e.g., a collection of devices implemented as a server, a virtual server, or the like) operable to receive encrypted values  130   a - e  and store these values in a secure, encrypted format. As an example, the multiparty encryption subsystem  132  may employ a blockchain to ensure data security among the collaborating entities. An example of such an encryption subsystem  132  is described in U.S. patent application Ser. No. 15/869,513 filed Jan. 12, 2018, by Prabakar Rangarajan et al., and titled “System for executing, securing, and non-repudiation of pooled conditional smart contracts over distributed blockchain network,” now U.S. Pat. No. 10,817,852 issued Oct. 27, 2020, the entirety of which is incorporated herein by reference. 
     As described above, in some cases, the trusted node identifier  118   a - e  determines that an additional random number  138 ,  142  should be used in the collaborative determination of the validation score  136  in order to further improve information security. For example, the trusted node identifier  118   a - e  may determine that one or both of the entity devices  108   a - e  that are sending or receiving information (e.g., messages  122   a - e ) to the entity device  108   a - e  is a less trusted device. In such cases, the trusted node identifier  118   a - e  identifies an additional trusted entity device  108   a - e  and returns to the random number generator  110   a - e  to generate an additional random number  138 ,  142  to provide to an additional device  108   a - e . A supplemental message  140 ,  144  containing the supplemental random number  138 ,  142  is then provided to another of the entity devices  108   a - e.    
     For example,  FIG. 1  illustrates a scenario in which the trusted node identifier of the third entity device  108   c  (not shown for conciseness) determines that the fourth device  108   d  is a less trusted device. For example, the trusted node identifier may determine that the entity operating the fourth entity device  108   d  is an entity on a list of less trusted entities (e.g., using the trusted node record  312  of  FIG. 3 ). In this case, the random number generator  110   c  generates a supplemental random number  138  (e.g., as the sum of the protected value  112   c  and a randomly generated number), and the message composer  120   c  generates a supplemental message  140  that includes the supplemental random number  138 . The supplemental message  140  is provided to the fifth device  108   e  in the cyclical collaboration network shown in  FIG. 1 . Since the third entity device  108   c  has output the supplemental random number  138 , the supplemental random number  138  is used for determining the encrypted value  130   c,  as shown in  FIG. 1 . Similarly, the fifth entity device  108   e  also uses the supplemental random number  138  in the determination of encrypted value  130   e,  as shown in  FIG. 1 . 
       FIG. 1  also illustrates a scenario in which the fourth entity device  108   d  determines that a supplemental random number  142  should be generated (e.g., because the entity of one or both of the downstream device  108   e  and the upstream device  108   c  relative to device  108   d  is a less trusted device). In this scenario, the entity device  108   d  generates a supplemental random number  142  and a corresponding supplemental message  144  that includes the additional random number  142 . The message  144  is provided to the second entity device  108   b.  Since the fourth entity device  108   d  has output the supplemental random number  142 , the supplemental random number  142  is used in determining the encrypted value  130   d,  as shown in  FIG. 1 . Similarly, the second entity device  108   b  also uses the supplemental random number  142  in the determination of encrypted value  130   b,  as shown in  FIG. 1 . This approach helps provide additional data security (e.g., to protect value  112   d  from being exposed to a less trusted entity). 
     In an example operation of the system  100 , the request  106  is an invoice requesting that financing be provided to the third party  104 . In some cases, an individual or company may inappropriately provide the same invoice to multiple finance-providing entities in an attempt to obtain the same financing from multiple entities. To protect against such cases, the entity device  108   a  receiving the request  106  may need to determine whether the same invoice was already financed by another entity before financing is approved. Previous technology relies heavily on disclosures of such actions from the third party  104  providing the request  106  and a lengthy back-and-forth between the entity, the third party  104 , and other institutions to obtain all information to determine if the request  106  is valid. This disclosure recognizes that this validation may be performed more rapidly and reliably if information were shared between entities that would receive such requests  106 . However, previous technology used for information sharing would reveal protected information  112   a - e  (e.g., the amount financed to the third party  104  by each entity in this example) to each entity participating in the sharing. The system  100  described in this disclosure overcomes this and other technical problems of previous technology by facilitating information sharing in a manner that allows the validation score  136  to be determined without revealing the individual protected values  112   a - e.    
     In this example operation, the first entity device  108   a  receives the request  106  and determines the protected value  112   a  associated with the request  106 . For example, for the request  106  for financing, the protected value  112   a  may be an amount already financed to the third party  104  by the entity operating device  108   a.  In order to determine whether the request  106  for financing should be validated, the entity device needs to calculate a validation score  136  that corresponds to a total amount of financing being provided to the third party  104  (e.g., to the cumulative exposure of the participating entities associated with devices  108   a - e ). This validation score  136  can be used to access whether financing should be provided to the third party  104 . 
     The first entity device  108   a  generates a first random number  114   a  based on the protected value  112   a,  as described above with respect to the random number generator  110   a  and provides this random number  114   a  to the downstream device  108   b  (e.g., as part of message  122 a). The first entity device  108   a  also receives a fifth random number  114   e  generated by the fifth entity device  108   e  (generated as described below). The first entity device  108   a  determines a first encrypted request value  130   a  based on the protected value  112   a,  the first random number  114   a,  and the fifth random number  114   e , as shown in  FIG. 1 . The encrypted value  130   a  is provided to the multiparty encryption subsystem  132 . The first entity device  108   a  receives the other encrypted values  130   b - e  from the multiparty encryption subsystem  132  and uses these values  130   a - e  to determine the validation score  136  (e.g., as a sum of the encrypted values  130   a - e ). The validation score  136  is used to determine whether the request  106  is validated (e.g., if the validation score  136  is less than a threshold value). 
     The second entity device  108   b  receives the message  122   a  that includes random number  114   a  from device  108   a.  The second entity device  108   b  identifies the protected value  112   b  associated with the request  106 . For example, the protected value  112   b  may be an exposure of the entity operating the second entity device  108   b  to financing provided to the third party  104 . The second entity device  108   b  generates a second random number  114   b  based on the protected value  112   b,  as described above with respect to the random number generator  110   b.  The second random number  114   b  is provided to the next device  108   c  downstream of the second entity device  108   b  (e.g., as part of message  122   b ). In this example, the second entity device  108   b  also receives a random number  142  generated by the fourth entity device  108   d  (e.g., as part of message  144 ). The second entity device  108   b  determines a second encrypted request value  130   b  based on the protected value  112   b,  the first random number  114   a,  the second random number  114   b,  and the supplemental random number  142 , as shown in  FIG. 1 . The encrypted value  130   b  is provided to the multiparty encryption subsystem  132 . The second entity device  108   b  receives the other encrypted values  130   a,c - e  from the multiparty encryption subsystem  132  and uses these values  130   a - e  to determine the validation score  136  (e.g., as a sum of the encrypted values  130   a - e ). The validation score  136  may be used to determine whether the request  106  would be validated by the second entity device  108   b  (e.g., if the validation score  136  is less than a threshold value). 
     The third entity device  108   c  receives the message  122   b  that includes random number  114   b  from device  108   b.  The third entity device  108   c  identifies the protected value  112   c  associated with the request  106 . For example, the protected value  112   c  may be an exposure of the entity operating the third entity device  108   c  to financing provided to the third party  104 . The third entity device  108   c  generates a third random number  114   c  based on the protected value  112   c,  as described above with respect to the random number generator  110   c.  The third random number  114   c  is provided to the next device  108   d  downstream of the third entity device  108   c  (e.g., as part of message  122   c ). In this example, the third entity device  108   c  also determines a supplemental random number  138  (e.g., because the downstream device  108   d  is associated with a less trusted entity). In this example, the supplemental random number  138  is provided to the fifth entity device  108   e  as part of message  140 . The third entity device  108   c  determines a third encrypted request value  130   c  based on the protected value  112   c,  the second random number  114   b,  the third random number  114   c,  and the supplemental random number  138 , as shown in  FIG. 1 . The encrypted value  130   c  is provided to the multiparty encryption subsystem  132 . The third entity device  108   c  receives the other encrypted values  130   a,b,d,e  from the multiparty encryption subsystem  132  and uses these values  130   a - e  to determine the validation score  136  (e.g., as a sum of the encrypted values  130   a - e ). The validation score  136  may be used to determine whether the request  106  would be validated by the third entity device  108   c  (e.g., if the validation score  136  is less than a threshold value). 
     The fourth entity device  108   d  receives the message  122   c  that includes random number  114   c  from device  108   c.  The fourth entity device  108   d  identifies the protected value  112   d  associated with the request  106 . For example, the protected value  112   d  may be an exposure of the entity operating the fourth entity device  108   d  to financing provided to the third party  104 . The fourth entity device  108   d  generates a fourth random number  114   d  based on the protected value  112   d,  as described above with respect to the random number generator  110   d.  The fourth random number  114   d  is provided to the next device  108   e  downstream of the fourth entity device  108   d  (e.g., as part of message  122   d ). In this example, the fourth entity device  108   d  also determines a supplemental random number  142  (e.g., because the upstream device  108   c  is associated with a less trusted entity). In this example, the supplemental random number  142  is provided to the second entity device  108   b  as part of message  144 ). The fourth entity device  108   d  determines a fourth encrypted request value  130   d  based on the protected value  112   d,  the third random number  114   c,  the fourth random number  114   d , and the supplemental random number  142 , as shown in  FIG. 1 . The encrypted value  130   d  is provided to the multiparty encryption subsystem  132 . The third entity device  108   c  receives the other encrypted values  130   a - c,e  from the multiparty encryption subsystem  132  and uses these values  130   a - e  to determine the validation score  136  (e.g., as a sum of the encrypted values  130   a - e ). The validation score  136  may be used to determine whether the request  106  would be validated by the fourth entity device  108   d  (e.g., if the validation score  136  is less than a threshold value). 
     The fifth entity device  108   e  receives the message  122   d  that includes random number  114   d  from device  108   d.  The fifth entity device  108   e  identifies the protected value  112   e  associated with the request  106 . For example, the protected value  112   e  may be an exposure of the entity operating the fifth entity device  108   e  to financing provided to the third party  104 . The fifth entity device  108   e  generates a fifth random number  114   e  based on the protected value  112   e,  as described above with respect to the random number generator  110   e.  The fifth random number  114   e  is provided to the next device  108   a  downstream of the fifth entity device  108   e  (e.g., as part of message  122   e ). In this example, the fifth entity device  108   e  also receives a random number  138  generated by the third entity device  108   c  (e.g., as part of message  140 ). The fifth entity device  108   e  determines a fifth encrypted request value  130   e  based on the protected value  112   e,  the fifth random number  114   e,  the fourth random number  114   d,  and the supplemental random number  138 , as shown in  FIG. 1 . The encrypted value  130   e  is provided to the multiparty encryption subsystem  132 . The fifth entity device  108   e  receives the other encrypted values  130 a-d from the multiparty encryption subsystem  132  and uses these values  130   a - e  to determine the validation score  136  (e.g., as a sum of the encrypted values  130   a - e ). The validation score  136  may be used to determine whether the request  106  would be validated by the fifth entity device  108   e  (e.g., if the validation score  136  is less than a threshold value). 
     Example Method of Operation 
       FIG. 2  illustrates a method  200  for operating the collaboration system  100  described with respect to  FIG. 1  above. The method  200  may begin at step  202  where an entity device  108   a - e  receives a request  106 . The request  106  may be for some service such as for creation of an account, access to information, the provision of financing, or the like. 
     At step  204 , the entity device  108   a - e  determines a value  112   a - e  associated with the request  106 . For example, the determined value  112   a - e  may be private or protected information that the operator of the entity device  108   a - e  does not wish to expose to others. For instance, the protected value  112   a - e  may be an amount of money already provided through financing to the third party  104  that submitted the request  106  received at step  202 , and the entity operating the device  108   a - e  may be barred from sharing this information with others. 
     At step  206 , the entity device  108   a - e  determines a random number  114   a - e  using the value  112   a - e  determined at step  204 . For example, the random number  114   a - e  may be determined by summing the value  112   a - e  from step  204  with a randomly generated value, as described with respect to the random number generator  110   a - e  of  FIG. 1 . In other words, the random number  114   a - e  may be the protected value  112   a - e  plus a randomly generated value. 
     At step  208 , the entity device  108   a - e  provides the random number  114   a - e  to the next device  108   a - e  in the cyclical collaboration network illustrated in  FIG. 1  (i.e., the device  108   a - e  downstream from the current device  108   a - e ). For instance, the network node sequencer  116   a - e  may determine the next entity device  108   a - e  in the cyclical network to which the random number  114   a - e  should be provided. The random number  114   a - e  may be included in a message  122   a - e  generated by the message composer  120   a - e , as described above with respect to  FIG. 1 , and this message  122   a - e  may be provided to the downstream device  108   a - e.    
     At step  210 , the entity device  108   a - e  determines whether the downstream device receiving the random number  114   a - e  is a trusted device. For example, the entity device  108   a - e  (e.g., using the trusted node identifier  118   a - e ) may determine that the entity operating the downstream entity device  108   a - e  is an entity on a list of less trusted entities (e.g., using the trusted node record  312  of  FIG. 3 ). If the entity device  108   a - e  determines that the downstream device  108   a - e  is a less trusted device  108   a - e , the entity device  108   a - e  proceeds to step  212 . Otherwise, if the next device  108   a - e  is a trusted device  108 a-e, the entity device  108   a - e  proceeds to step  216 . 
     At step  212 , the entity device  108   a - e  generates a supplemental random number  138 ,  142 . The supplemental random number  138 ,  142  may be generated using the same approach described above with respect to step  206 . For instance, the supplemental random number  138 ,  142  may be the protected value  112   a - e  plus a randomly generated value. At step  214 , the supplemental random number  138 ,  142  is provide to another device  108   a - e  (i.e., in addition to the device  108   a - e  downstream of the current entity device  108   a - e ). For example, as shown in the example of  FIG. 1 , entity device  108   c  provides a supplemental random number  138  as part of message  140  to device  108   e.    
     At step  216 , the entity device  108   a - e  receives the random number  114   a - e  generated by the upstream device  108   a - e . For example, in the example of  FIG. 1 , entity device  108   a  receives random number  114   e  generated by the upstream device  108   e.  At step  218 , the entity device  108   a - e  may receive one or more supplemental random numbers  138 ,  142  (e.g., as part of a message  140 ,  144 ). For example, in the example of  FIG. 1 , entity device  108   b  receives supplemental random number  142  as part of message  144  from device  108   d,  which is not directly upstream of device  108   b.    
     At step  220 , the entity device  108   a - e  determines an encrypted value  130   a - e  using the protected value  112   a - e  (see step  204 ), the generated random number  114   a - e  (see step  206 ), and all received random numbers  114   a - e ,  138 ,  142  (see steps  216 ,  218 ). 
     For example, as illustrated in the example of  FIG. 1 , the encrypted value  130   a  may be the protected value minus the sum of all sent/output random numbers  114   a - e ,  138 ,  142  plus the sum of all received/input random numbers  114   a - e ,  138 ,  142 . 
     At step  222 , the entity device  108   a - e  provides the encrypted value  130   a - e  to the multiparty encryption subsystem  132 . For example, the entity device  108   a - e  may provide the encrypted value  130   a - e  along with any other appropriate encryption information (e.g., a key or the like) in a network call to the encryption subsystem  132 . At step  224 , the entity device  108   a - e  receives the encrypted values  130   a - e  determined by other participating entity devices  108 a-e. At step  226 , the entity device  108   a - e  determines the validation score  136  based on the received encrypted values  136 . In the example of  FIG. 1 , this summation of the encrypted values  130   a - e  results in a determination of the sum of the protected values  112   a - e  stored by all of the entity devices  108   a - e , such that this total value can be determined without revealing any of the individual protected values  112   a - e.    
     Example Device for API integration 
       FIG. 3  illustrates an embodiment of a device  300  configured to implement various components of the system  100 . One or more devices  300  may be used to implement the user device  102 , entity devices  108   a - e , and multiparty encryption subsystem  132  of  FIG. 1 . The device  300  includes a processor  302 , a memory  304 , and a network interface  306 . The device  300  may be configured as shown or in any other suitable configuration. 
     The processor  302  comprises one or more processors operably coupled to the memory  304 . The processor  302  is any electronic circuitry including, but not limited to, state machines, one or more central processing unit (CPU) chips, logic units, cores (e.g. a multi-core processor), field-programmable gate array (FPGAs), application specific integrated circuits (ASICs), or digital signal processors (DSPs). The processor  302  may be a programmable logic device, a microcontroller, a microprocessor, or any suitable combination of the preceding. The processor  302  is communicatively coupled to and in signal communication with the memory  304  and the network interface  306 . The one or more processors are configured to process data and may be implemented in hardware or software. For example, the processor  302  may be 8-bit, 16-bit, 32-bit, 64-bit or of any other suitable architecture. The processor  302  may include an arithmetic logic unit (ALU) for performing arithmetic and logic operations, processor registers that supply operands to the ALU and store the results of ALU operations, and a control unit that fetches instructions from memory and executes them by directing the coordinated operations of the ALU, registers and other components. The one or more processors are configured to implement various instructions. For example, the one or more processors are configured to execute instructions to implement the function disclosed herein, such as some or all of those described with respect to  FIGS. 1 and 2 . In some embodiments, the function described herein is implemented using logic units, FPGAs, ASICs, DSPs, or any other suitable hardware or electronic circuitry. 
     The memory  304  is operable to store any of the information described above with respect to  FIGS. 1 and 2  along with any other data, instructions, logic, rules, or code operable to execute the function described herein. For example, the memory  304  may store random number generation instructions  308 , which include any logic, code, and/or rules for implementing functions of the random number generator  110   a - e , described above with respect to  FIGS. 1 and 2  (see steps  206 ,  212  of  FIG. 2 ). The memory  304  may also store node sequencing instructions  310 , which include any logic, code, and/or rules for implementing the functions of the node sequencer  116   a - e , described above with respect to  FIGS. 1 and 2 . The memory  304  may also store a trusted node record  312  which may include information and/or instructions used to perform functions of the trusted node identifier  118   a - e , described above with respect to  FIGS. 1 and 2 . The memory  304  may also store message composition instructions  314 , which include any logic, code, and/or rules for implementing functions of the message composer  120   a - e , described above with respect to  FIGS. 1 and 2 . The memory  304  may also store requests  316 , which includes the request  106  described above with respect to  FIGS. 1 and 2 . The memory  304  may also store random numbers  318 , which include the random numbers  114   a - b ,  138 ,  142 , described above with respect to FIGS.  1  and  2 . The memory  304  may also store request values  320 , which include the protected values  112   a - e , described above with respect to  FIGS. 1 and 2 . The memory  304  may also store encrypted values  322 , which include the encrypted values  130   a - e , described above with respect to  FIGS. 1 and 2 . The memory  304  may also store validation scores  324 , which include the validation score  136 , described above with respect to  FIGS. 1 and 2 . The memory  304  may be volatile or non-volatile and may comprise read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), dynamic random-access memory (DRAM), and static random-access memory (SRAM). 
     The network interface  306  is configured to enable wired and/or wireless communications. The network interface  306  is configured to communicate data between the device  300  and other network devices, systems, or domain(s). For example, the network interface  306  may comprise a WIFI interface, a local area network (LAN) interface, a wide area network (WAN) interface, a modem, a switch, or a router. The processor  302  is configured to send and receive data using the network interface  306 . 
     The network interface  306  may be configured to use any suitable type of communication protocol as would be appreciated by one of ordinary skill in the art. 
     While several embodiments have been provided in this disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of this disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented. 
     In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of this disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein. 
     To aid the Patent Office, and any readers of any patent issued on this application in interpreting the claims appended hereto, applicants note that they do not intend any of the appended claims to invoke 35 U.S.C. § 112(f) as it exists on the date of filing hereof unless the words “means for” or “step for” are explicitly used in the particular claim.