Restrictions on the use of shared contact information

Abstract

The method comprises the steps of creating first contact information for contacting the first party (101) and transmitting the first contact information to the system of the second party (103). The first contact information is unique to the second party. The method further comprises the steps of deriving second contact information for contacting the first party from the first contact information in the system of the second party (107) and transmitting the second contact information to the system of the third party (109). The second contact information is unique to the third party and includes an identifier for the second party. The method further comprises the step of transmitting a message containing the second contact information to a system associated with the first party (111). The method further comprises the steps of obtaining a shared policy associated with the identifier (113) and establishing a communication relationship between the first party and the third party in accordance with the shared policy (115).

Description

Technical Field

[0001] The present invention relates to a method for creating and deriving contact information to establish a communication relationship, a method for deriving contact information, and a method for establishing a communication relationship. The present invention also relates to a computer program product that enables a system to execute the steps of such a method.

[0002] The present invention further relates to a system for deriving contact information and a system for establishing a communication relationship.

Background Art

[0003] Communication identifiers can be easily misused to violate a user's privacy. If a party shares their email address or phone number with another party, the other party may continue to harass that party via email or phone for a long time afterwards. Even worse, the other party may share the party's communication identifiers with a third party, and the third party may use them for spamming, phishing, and other privacy-violating acts. Furthermore, since the other party and the third party can use the party's contact information in correlation, it is possible to combine data about the party in a form disadvantageous to the party. For example, since Internet service providers (ISPs) rarely change their IP addresses, IP addresses can be easily correlated.

[0004] Techniques for enabling communication while reducing privacy-violating acts are known. An example of such a technique is decentralized ID (DID) communication. DID communication (DIDcomm) is a set of tools for realizing a permission-neutral and two-way communication channel between two entities that only recognize each other's DIDs. DIDcomm provides a method for mutual authentication between any two parties.

[0005] The DID Exchange Protocol 1.0 (Aries RFC0023, https: / / github.com / hyperledger / aries-rfcs / tree / main / features / 0023-did-exchange) is used to establish a DIDcomm relationship between two parties. The "requester" uses information from an invitation message to initiate the DID exchange protocol with the "responder". Once the protocol is successfully completed, each party can send simple DIDcomm messages to each other. These messages are encrypted and signed so that only the parties can send, receive, and read them. This means that a third party cannot eavesdrop or insert spam, phishing, etc.

[0006] Aries RFC0023 assumes that the DID exchange protocol precedes an out-of-band invitation message (using RFC 0434). This out-of-band invitation message can be shared with a third party, which can then use to initiate the DID exchange protocol with the responder. These invitation messages could be misused to harass the responder. If a communication channel from the responder to the requester does not yet exist, it is unclear how to establish / bootstrap the relationship without the loss of privacy associated with the sharing of contact information by a third party. [Overview of the project] [Problems that the invention aims to solve]

[0007] The first object of the present invention is to provide a method that can be used to reduce acts that infringe on privacy while establishing a communication relationship. A second object of the present invention is to provide a system that can be used to reduce acts that infringe on privacy while establishing a communication relationship. [Means for solving the problem]

[0008] In a first aspect of the present invention, a method for creating and deriving contact information to establish a communication relationship includes the steps of: creating first contact information for contacting a first party, wherein the first contact information is specific to a second party; transmitting the first contact information to the second party's system; deriving second contact information for contacting the first party from the first contact information in the second party's system, wherein the second contact information is specific to a third party and comprises an identifier of the second party; transmitting the second contact information from the second party's system to the third party's system; transmitting a message from the third party's system to a system associated with the first party, wherein the message includes the second contact information; obtaining a shared policy associated with the identifier of the second party; and establishing a communication relationship between the first party and the third party depending on the shared policy.

[0009] By including an identifier for the party deriving the contact information, i.e., the referrer / second party, in this contact information, this identifier can be used to determine whether to establish a communication relationship between the party wishing to have a relationship, i.e., the third party, and the party to which the contact information pertains, i.e., the first party. In this way, the first party, for example Bob, can determine the origin of the contact information used to contact him. Based on this origin, Bob can create a policy for processing incoming initial messages. For example, Bob can immediately read referrals from party A, ignore / block referrals from party B, and remember referrals from party C to read later.

[0010] This will allow Bob to have a more detailed understanding and control over who is contacting him and how those parties are contacting him. In particular, Bob will be able to block an entire category of spam / phishing messages that would result from a single leak of contact information. To ensure backward compatibility, this method may be used to extend the current communication identifier so that messages without this extension can still be received.

[0011] Therefore, it is considered perfectly legal to share contact information with a third party. Currently, most contact information is still received through referrals. Examples of such referrals include directories, email CCs, and the exchange of phone numbers. The problem is not the referral itself, but the fact that referrals are uncontrollable. Spam and phishing via phone, email, and other electronic means are examples of uncontrollable referrals. The above methods prevent a situation where Bob is unaware of how spammers / phishing scammers obtained his contact information.

[0012] The sharing policy may include a whitelist or a blacklist of party identifiers. If it is necessary to restrict the use of shared contact information by a second party, the second party may be added to the blacklist or removed from the whitelist. The second party may be, for example, an individual or a company. At the same time, it is also possible, though not required, to individually block the second party from communicating with the first party, for example via DIDcomm, after spam has been generated by a referral by the second party.

[0013] The method may further include a step of transmitting communication information to a third party, for example, by transmitting a response specified in the DID exchange protocol, or first and second encrypted information described in the patent application titled "Privacy Routing System" (European Patent Application EP22184205.77), if a communication relationship has been established. The method may further include a step of notifying the third party that a communication relationship could not be established, for example by transmitting a DIDcomm "request_not_accepted" rejection specified in the DID exchange protocol.

[0014] Second contact information can be derived from first contact information by applying a one-way encryption algorithm to at least a portion of the first contact information. This can be done to allow, for example, the first party to verify the validity of second contact information received from a third party based on the first contact information, while preventing a third party from obtaining first contact information based on second contact information. It can also prevent the second or third party from modifying or deleting the second party's identifier from second contact information.

[0015] The first and second contact information entries may be part of a contact information tree, with the first contact information being at a higher hierarchical level than the second contact information within the tree. The advantage of using a tree is that it provides scalability, allowing contact information to be derived for and by various stakeholders. Theoretically, the depth and width of the tree are unlimited. Contact information may have a tree structure similar to, for example, a hierarchical deterministic (HD) wallet.

[0016] The method may comprise the steps of: generating a root secret; determining a first contact by deriving first contact information from the root secret; and deriving a third contact for contacting the first party in the first party's system from the root secret, wherein the third contact information is unique to the fourth party, and the first contact information and the third contact information are at the same hierarchical level in the contact information tree. The root secret may be, for example, a random number. By enabling the validity of contact information based on the root secret, it may become easier to verify the validity of contact information items shared through different primary contacts of the first party. The HD wallet is also created from the root secret / seed.

[0017] The first contact information may comprise an index and a value within a contact information tree, the identifier of the second party may comprise an index and a sub-index of the index, and the second contact information may further comprise the result of applying a one-way encryption algorithm to both the value and the sub-index. The one-way encryption algorithm may comprise a hash function, and the value may comprise, for example, a hash value.

[0018] For example, a first party, such as Bob, can calculate what the hash will be based on the root secret and the index. If the received hash does not match the expected hash, Bob's system may ignore the message. If the received hash does match the expected hash, Bob's system has verified that the contact information is genuine / valid. Based on the sharing policy of a particular index, Bob's system may decide how to handle the message, for example, by presenting the message to Bob immediately, storing the message for later use, rejecting the message with a rejection message, rejecting the message without a rejection message, or forwarding the message. The purpose of a one-way algorithm is to prevent a second party, a third party, and multiple third parties from traversing the tree backward, thereby preventing them from using or deriving contact information they are not authorized to use or derive.

[0019] The first contact information may comprise the public key of the first party or the privacy routing service provider and encrypted information encrypted with the public key, the encrypted information comprising an index in the contact information tree, and the second contact information may comprise the result of encrypting the combination of the encrypted information and a subindex of the index with the public key, the result comprising the identifier of the second party in encrypted form, the identifier of the second party comprising an index and a subindex.

[0020] A public-key cryptography algorithm is used, and if, for example, the first party receives the message, the first party can decrypt it and unpeel the onion to verify the contact information. For example, if it matches the first party's root secret, the first party has verified that the contact information is valid / authentic, and the first party can apply a shared policy to the index whose details have not been verified. Each derivation involves an encryption step using this public key. The advantage of using public-key cryptography is that the depth of the contact information tree is hidden from anyone other than the first party. The public-key cryptography algorithm may be, for example, RSA, elliptic curve, or El-Gamal.

[0021] A shared policy can be obtained in the system of the first party or the system of the private routing service provider, and a communication relationship can be established. The first party may outsource the verification of incoming messages to the private routing service provider (PRSP) and provide the PRSP with primary contact information or a route secret. The PRSP can use this information to verify the first party's incoming messages. This eliminates the first party's work of inspecting incoming messages and saves bandwidth in the event that many messages are rejected.

[0022] If the first party wishes to block an index, the first party must notify the PRSP to update the shared policy associated with the first party with respect to that index. An example of a PRSP is described in a patent application titled "Privacy Routing System" (European Patent Application EP22184205.7). The first party may also outsource the creation of the first contact information and / or the generation of the root secret to the PRSP.

[0023] The first and second contact information may include the communication identifier of the first party or the communication identifier of the privacy routing service provider. This communication identifier identifies the system associated with the first party to which the third party sends the third party's message. If the first party uses PRSP, the PRSP's communication identifier may be included instead of the first party's own communication identifier. This may be signaled in the contact information. Once this is signaled, the PRSP may retrieve the root secrets or private keys of all customers and verify the contact information in the received message based on each customer's root secret or private key in order to determine which customer the message is addressed to.

[0024] By using PRSP communication identifiers, the first party's communication identifier can be kept private to prevent eavesdropping or to prevent a second or third party from bypassing the PRSP inspection system by directly sending messages to the first party. As mentioned above, when using PRSP public keys to encrypt both the value and the index, the first party's communication identifier can also be hidden / encrypted in the encrypted onion, making it visible only to PRSP. Unpeeling decryption to verify details needs to be performed only once per received message. There is no need to attempt to verify received contact information using different root secrets of different parties or different private keys of different parties.

[0025] The first contact information may have referral restrictions, where the referral restriction specifies the frequency at which contact information can be derived from the first contact information. Also, the method may further comprise, in the system of the second party, verifying that the referral restriction has not been reached before deriving the second contact information from the first contact information. For example, the first contact information may include "maxreferrals=3" to indicate that referrals from this contact information are only, for example, "x.1", "x.2", "x.3". There may also be restrictions associated with the depth of referrals. By refraining from unlimited referrals, potential abuse can be reduced. The number of referrals may be restricted per unit of time, for example, "maxreferralsperday=20".

[0026] After deriving the second contact information, the method may further comprise sending a notification from the system of the second party to the system associated with the first party, and sending the second contact information to the system of the third party. For example, an address book application may send this notification to the original contact each time the derived contact information is shared. The second contact information and the notification may be sent in one message using a new recipient field.

[0027] Whether such a notification is always sent, never sent, or should be decided on a case-by-case basis by the parties is configurable. The advantage of this notification is similar to the advantage of an email reception notification, where the first party knows that new contact information has been derived and that incoming messages from another party can be expected. This notification can also be used by the first party as a trigger to initiate preparatory measures for this, such as updating the sharing policy.

[0028] The second contact information may further include encrypted information related to the context from which the second contact information is derived. This information may include, for example, a timestamp, a GPS location, and / or a photograph. Thereby, when the second contact information is used by a third party to make a contact, a memento regarding the second party and regarding the context in which the first contact information was shared is provided to the first party.

[0029] In a second aspect of the present invention, a method of deriving contact information includes a step of deriving second contact information for contacting a first party from first contact information for contacting the first party, wherein the first contact information is unique to a second party, the second contact information is unique to a third party, and the second contact information includes an identifier of the second party; and a step of transmitting the second contact information to a system of the third party. This method may be executed by a system of the second party. This method may be executed, for example, by a terminal. This method may be executed, for example, by a directory service. An enterprise or organization providing a PRSP service may also provide such a directory service.

[0030] In a third aspect of the present invention, a method of establishing a communication relationship includes a step of receiving a message from a system of a third party, wherein the message includes second contact information for contacting a first party, the second contact information is derived from first contact information for contacting the first party, the first contact information is unique to a second party, the second contact information is unique to a third party, and the second contact information includes an identifier of the second party; a step of obtaining a sharing policy associated with the identifier of the second party; and a step of establishing a communication relationship between the first party and the third party depending on the sharing policy.

[0031] This method may be performed by a system associated with the first party, for example, the first party's system or PRSP. This method may further comprise the steps of creating first contact information and transmitting the first contact information to the second party's system.

[0032] In a fourth aspect of the present invention, a system for deriving contact information comprises at least one processor configured to derive second contact information for contacting a first party from first contact information for contacting a first party, wherein the first contact information is specific to the second party, the second contact information is specific to the third party and includes an identifier for the second party, and transmit the second contact information to the system of the third party.

[0033] In a fifth aspect of the present invention, a system for establishing a communication relationship includes at least one processor configured to receive a message from a system of a third party, wherein the message comprises second contact information for contacting a first party, the second contact information is derived from first contact information for contacting a first party, the first contact information is specific to the second party, the second contact information is specific to the third party, and comprises an identifier of the second party; obtain a shared policy associated with the identifier of the second party; and establish a communication relationship between the first party and the third party depending on the shared policy.

[0034] A sixth aspect of the present invention is a system for deriving contact information and establishing a communication relationship, the system comprising a system for deriving contact information and a system for establishing a communication relationship.

[0035] Furthermore, computer programs for performing the methods described herein, as well as non-temporary computer-readable storage media for storing the computer programs, are provided. For example, the computer programs may be downloaded or uploaded to existing devices, or stored at the time of manufacture of these systems.

[0036] A non-temporary computer-readable storage medium stores at least a first software code portion, which, when executed or processed by a computer, is configured to perform executable actions for deriving contact information.

[0037] The executable operation comprises the steps of: deriving second contact information for contacting a first party from first contact information for contacting a first party, wherein the first contact information is specific to the second party, the second contact information is specific to the third party and includes an identifier for the second party; and transmitting the second contact information to the third party's system.

[0038] A non-temporary computer-readable storage medium stores at least a second software code portion, which, when executed or processed by a computer, is configured to perform executable actions for establishing a communication relationship.

[0039] An executable action is to receive a message from the system of a third party, wherein the message comprises a second contact information for contacting the first party, the second contact information being derived from a first contact information for contacting the first party, the first contact information being specific to the second party, the second contact information being specific to the third party, and comprising an identifier for the second party; to obtain a shared policy associated with the identifier for the second party; and to establish a communication relationship between the first party and the third party depending on the shared policy.

[0040] As will be understood by those skilled in the art, aspects of the present invention may be embodied as devices, methods, or computer program products. Accordingly, aspects of the present invention may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware embodiments, which may collectively be referred to herein as “circuits,” “modules,” or “systems.” The functions described herein may be implemented as algorithms executed by a computer processor / microprocessor. Furthermore, aspects of the present invention may take the form of computer program products embodied in one or more computer-readable media, for example, stored, in which computer-readable program code is embodied.

[0041] Any combination of one or more computer-readable media may be used. The computer-readable media may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a suitable combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or a suitable combination thereof. In the context of the present invention, the computer-readable storage medium may be any tangible medium that contains or can store programs used by or in connection with an instruction execution system, apparatus, or device.

[0042] A computer-readable signal medium may include propagated data signals in which computer-readable program code is embedded, for example, in the baseband or as part of a carrier wave. Such propagated signals may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium that can communicate, propagate, or transfer programs used by or in connection with an instruction execution system, apparatus, or device, rather than a computer-readable storage medium.

[0043] Program code embodied in a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, cable, RF, or any suitable combination thereof. Computer program code for performing operations for aspects of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java®, Smalltalk, and C++, and conventional procedural programming languages ​​such as the C programming language or similar programming languages. The program code may run entirely on the user's computer, partially on the user's computer, run as a standalone software package, partially on the user's computer and partially on a remote computer, or run entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet service provider).

[0044] Hereinafter, aspects of the present invention will be described with reference to flowcharts, sequence diagrams, and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It will be understood that each block in a flowchart and / or block diagram, as well as combinations of blocks in a flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions may be provided to a processor, particularly a microprocessor or central processing unit (CPU) of a general-purpose computer, a dedicated computer, or other programmable data processing device, in order to generate a machine such that instructions executed via the computer's processor, other programmable data processing device, or other device create means for implementing a function / operation specified in one or more blocks of a flowchart and / or block diagram.

[0045] These computer program instructions may also be stored on a computer-readable medium that can instruct a computer, other programmable data processing device, or other device to function in a particular way, and as a result, the instructions stored on the computer-readable medium generate a product containing instructions that implement a specified function / operation in one or more blocks of a flowchart and / or block diagram.

[0046] Computer program instructions can be loaded into a computer, other programmable data processing device, or other device, and a series of operational steps can be executed on the computer, other programmable device, or other device to generate a computer implementation process, and the instructions executed on the computer or other programmable device can also provide a process for implementing a specified function / operation in one or more blocks of a flowchart and / or block diagram.

[0047] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code comprising one or more executable instructions for implementing a specified logical function.

[0048] Furthermore, it should be noted that in some alternative implementations, the functions described within a block may occur in a different order than that shown in the diagram. For example, two consecutively shown blocks may actually be executed almost simultaneously, or the blocks may be executed in reverse order depending on the related functions. Also, it should be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs a specified function or operation, or by a combination of dedicated hardware and computer instructions.

[0049] These and other aspects of the present invention will become apparent by reference to the drawings, and will be further described by reference to the drawings, for example. [Brief explanation of the drawing]

[0050] [Figure 1] This is a sequence diagram of a first embodiment of a method for creating and deriving contact information and establishing communication relationships. [Figure 2] This figure shows an embodiment of how a one-way encryption algorithm is used. [Figure 3] This figure shows the first example of a contact information tree. [Figure 4] This figure shows a second example of a contact information tree. [Figure 5] This figure shows an embodiment of how a hash function is used. [Figure 6]This figure shows an embodiment of how a public-key cryptography algorithm is used. [Figure 7] This is a flowchart of a second embodiment of a method for establishing a communication relationship. [Figure 8] This is a flowchart of a second embodiment of a method for deriving contact information. [Figure 9] This is a block diagram of the first embodiment of a system for deriving contact information and establishing communication relationships. [Figure 10] This is a block diagram of a second embodiment of a system for deriving contact information and establishing communication relationships. [Figure 11] This figure shows an embodiment of how hierarchical deterministic cryptography is applied. [Figure 12] This is a block diagram of an exemplary data processing system for performing steps of the method of the present invention. [Modes for carrying out the invention]

[0051] Corresponding elements in the drawing are indicated by the same reference number. A first embodiment of a method for creating and deriving contact information and establishing communication relationships is shown in Figure 1. In the embodiment of Figure 1, three roles are distinguished.

[0052] Alice wants to introduce her friend Carol to Bob. Bob wants to control the messages he receives from Alice's friends. Carol is Alice's friend and wants to send a message to Bob.

[0053] More generally, Bob is the first party, Alice is the second party, and Carol is the third party. In the embodiment of Figure 1, steps 101, 103, 127, 113, and 115 are performed by a system associated with the first party (Bob), for example, the first party's (Bob's) system, or the system of a privacy routing service provider (PRSP) that provides privacy routing as a service to the first party (Bob). In the embodiment of Figure 1, steps 105, 107, and 121 are performed by the second party's (Alice's) system, and steps 123 and 125 are performed by the third party's (Carol's) system.

[0054] Step 101 comprises creating a first contact information for contacting the first party (Bob) in a system associated with the first party (Bob). This first contact information is unique to the second party (Alice) because it was created specifically for the second party (Alice). Step 103 comprises transmitting the first contact information to the second party (Alice)'s system in a system associated with the first party (Bob).

[0055] Step 105 comprises receiving the first contact information in the system of the second party (Alice). Step 107 comprises deriving second contact information for contacting the first party (Bob) from the first contact information in the system of the second party (Alice). The second contact information is unique to the third party (Carol) and includes an identifier of the second party (Alice). The second contact information can be derived from the first contact information, for example, by applying a one-way encryption algorithm to at least a portion of the first contact information.

[0056] Step 109 comprises transmitting second contact information from the system of the second party (Alice) to the system of the third party (Carol). Step 109 comprises steps 121 and 123. Step 121 comprises transmitting second contact information from the system of the second party (Alice) to the system of the third party (Carol). Step 123 comprises receiving second contact information in the system of the third party (Carol).

[0057] Step 111 comprises sending a message from the system of the third party (Carol) to the system associated with the first party (Bob). The message includes second contact information. Step 111 comprises steps 125 and 127. Step 125 comprises sending a message from the system of the third party (Carol) to the system associated with the first party (Bob). Step 127 comprises receiving the second contact information in the system associated with the first party (Bob).

[0058] Step 113 includes obtaining a shared policy associated with the identifier of the second party (Alice) in a system associated with the first party (Bob). Step 115 includes establishing a communication relationship between the first party (Bob) and the third party (Carol) depending on the shared policy obtained in step 113.

[0059] By including an identifier for the party deriving the contact information, such as a second party, in this contact information, this identifier can be used to determine whether to establish a communication relationship between a party wishing to have a relationship, such as a third party, and the party to which the contact information pertains, i.e., the first party. In this way, the first party, such as Bob, can determine the source of the contact information used to contact him.

[0060] This allows Bob to have a more detailed understanding and control over who contacts him and how those parties contact him. In particular, Bob may be able to block an entire category of spam / phishing messages that result from a single leak of contact information. Therefore, while sharing contact information with a third party may be considered perfectly legal, the above method prevents a situation where Bob is unaware of how spammers / phishing scammers obtained his contact information.

[0061] The sharing policy may include, for example, a whitelist or a blacklist of party identifiers. If it is necessary to restrict the use of shared contact information by a second party, the second party may be added to the blacklist or removed from the whitelist. The second party may be, for example, an individual or a company. At the same time, it is also possible, though not required, to individually block the second party from communicating with the first party, for example via DIDcomm, after spam has been generated by a referral by the second party.

[0062] As mentioned earlier, Bob can outsource the verification of incoming messages to PRSP. PRSP then verifies Bob's incoming messages using the first contact information received from or generated for Bob. This saves Bob the task of inspecting incoming messages and bandwidth, even if many messages are rejected or blocked. If Bob blocks a party's identifier, he must notify PRSP to update the whitelist and / or blacklist.

[0063] In the embodiment of Figure 1, steps 101, 103, 127, 113, and 115 are performed by the same system. In an alternative embodiment, these steps are performed by multiple systems. For example, the system of the first party (Bob) may perform steps 101 and 103, and the PRSP's system may perform steps 127, 113, and 115. In this alternative embodiment, the system of the first party (Bob) provides information, such as first contact information, to the PRSP's system so that the PRSP can perform steps 113 and 115.

[0064] In the example in Figure 1, the first, second, and third parties are individuals. Alternatively, one or more of the parties may be legal entities. The second party could be, for example, a directory service. This directory service typically only accepts the party's contact information if it receives it directly from the party or their Personal Contact Listing Service (PSRP). Adding the use of a directory service to the method in Figure 1 allows the first party (Bob) to easily distinguish between directory referrals and friend referrals while still making himself publicly accessible. A company or organization providing a PRSP service could also provide such a directory service.

[0065] Contact information may be transmitted and encoded as, for example, W3C verifiable credentials, IRMA attribute-based credentials, Hyperledger Indy anonymous credentials (aka AnonCred), IETF Authentication Chain Data Container (ACDC), or other credential formats. Contact information may be serialized as, for example, JSON, JSON-LD, XML, JWT, RDF, TURTLE, or other data model syntax. Contact information may be shared as, for example, as part of a vCard (.vcf file) over the Internet, or via short-range digital communications such as QR, NFC, Bluetooth, WiFi, acoustic, or infrared.

[0066] Contact information may be attached to an email, for example, or may be part of a Gmail Plus address. Contact information may be attached to a phone call, for example, using DTMF signaling (analog), inter-user signaling (ISDN), or as an SDP attribute (SIP signaling for voice / video over IP). Contact information may be attached to a package, for example, as a scannable QR code® or barcode. Contact information may be included in an HTTP request and response, or other internet protocol, for example. Contact information may be added to a URL, for example, RESTful, or as a query string.

[0067] Contact information can also be included in a new message field, for example, a field called "cit_info". If a sender sends a message to multiple recipients, this message in this new message field may automatically include the contact information of multiple recipients. This can happen, for example, when the sender creates a new message or replies to another message. This allows multiple recipients to establish communication relationships with each other. For example, if Alice sends a message to Carol and David, this message may contain contact information for Carol, created by Alice specifically for David, and / or contact information for David, created by Alice specifically for Carol, in the "cit_info" field.

[0068] This is particularly useful when a message is sent to multiple recipients simultaneously, but the sender intends for only a few recipients to be contacted through this message. Based on this message, contact information for the person intended to be contacted can then be shared with all other recipients via the "cit_info" field.

[0069] The recipient's message server may be configured to delete contact information in the "cit_info" field that has not been specifically created for that recipient, or to hide this contact information from the recipient. This is particularly useful when there are more than two recipients of a message. For example, if Alice sends a message to Carol, David, and Frank, the "cit_info" field of this message may contain contact information for Carol created by Alice specifically for Frank, contact information for David created by Alice specifically for Frank, contact information for Carol created by Alice specifically for David, contact information for Frank created by Alice specifically for Frank, and contact information for David created by Alice specifically for Frank.

[0070] Next, Carol will only see the contact information created by Alice specifically for Carol to contact David, and the contact information created by Alice specifically for Carol to contact Frank. Next, David will only see the contact information created by Alice specifically for David to contact Carol, and the contact information created by Alice specifically for David to contact Frank. Next, Frank will only see the contact information created by Alice specifically for Frank to contact Carol, and the contact information created by Alice specifically for Frank to contact David.

[0071] If the recipient's message server is configured to hide contact information in the "cit_info" field of messages not specifically created for that recipient, this contact information may be retained in other messages sent by the recipient in reply to this message. Alternatively, the recipient may derive new contact information from the contact information contained in messages received by the recipient and include the derived contact information in the reply.

[0072] An address book application (e.g., an email client, a phone client, or a dedicated smartphone app) may store contact information shared with another party (e.g., first contact information, second contact information) associated with that other party, for example, as an additional field for that party / contact. This address book application may share the derived contact information, for example, as a newly generated .vcf vCard.

[0073] The method may further include a step of transmitting communication information to a third party (carroll) once a communication relationship has been established (for example, as part of step 115, or after step 115; not shown in Figure 1), such as transmitting a response specified in the DID exchange protocol, or first and second encrypted information described in the patent application titled "Privacy Routing System" (European Patent Application No. EP22184205.77).

[0074] In the latter case, the first encrypted information comprises a recipient identifier encrypted with an encryption key associated with the PRSP. This recipient identifier is associated with the first party (Bob) and may be created by the first party (Bob), or it may be created by a PRSP dedicated to the third party (Carol). The third party can then communicate with the first party (Bob) as usual by sending a message containing the third and fourth encrypted information to the PRSP. The third encrypted information comprises a recipient identifier encrypted with an encryption key associated with the PRSP. The fourth encrypted information is determined based on the second encrypted information.

[0075] Next, the PRSP can use an encryption key, or a further encryption key corresponding to the encryption key, to decrypt the recipient identifier from the third encrypted information, identify the first party (Bob) based on the decrypted recipient identifier, verify the fourth encrypted information, and forward the message to the first party (Bob) based on the verification result of the fourth encrypted information. The encryption key associated with the PRSP may be, for example, a public key.

[0076] Creating different encrypted recipient identifiers for different parties may prevent other parties from associating messages addressed to the same recipient. By having the first party (Bob) use a fourth encrypted piece of information received from the third party (Carol) to decide whether to forward a message from the first user, the first party (Bob) may block spam without enabling other parties to associate messages addressed to the same recipient.

[0077] The encryption information may comprise an encryption key, data encrypted with the encryption key, and / or other encryption information. The third encryption information may be the same as the first encryption information, but may be different, and may comprise, for example, a re-randomization of the received encrypted recipient identifier. If the third encryption information is different from the first encryption information, it must be derived from at least the first encryption information. Similarly, the fourth encryption information may be the same as the second encryption information, or it may be different.

[0078] This method may further include a step (not shown in Figure 1) of notifying a third party that a communication relationship cannot be established, for example, by sending a DIDcomm "request_not_accepted" rejection specified in the DID exchange protocol.

[0079] The method in Figure 1 may be extended to involve further parties and may include the creation and / or derivation of further contact information. For example, multiple fields of primary contact information may be created, multiple fields of secondary contact information may be derived, and higher-level contact information may be derived.

[0080] Figure 2 shows an embodiment of a method in which a one-way encryption algorithm is used. In this embodiment, in step 107, the one-way encryption algorithm 59 is applied to at least a portion of the primary contact information 51 to derive secondary contact information 52, for example, the second contact information in Figure 1, from the primary contact information 51, for example, the first contact information in Figure 1. In this embodiment, the one-way encryption algorithm 59 is applied to at least a portion of the secondary contact information 52 to derive tertiary contact information 53 from the secondary contact information 52, for example, the second contact information in Figure 1.

[0081] The purpose of the one-way algorithm is to prevent a third party (Carol) from obtaining the first contact information based on the second contact information, while allowing, for example, the first party (Bob) to verify the validity of the second contact information received from the third party (Carol) based on the first contact information. It also prevents the second party (Alice) or the third party (Carol) from modifying or deleting the second party's (Alice's) identifier from the second contact information.

[0082] In the example in Figure 2, the one-way encryption algorithm 59 is applied to the contact information or a portion of it, and to a sub-index. Each primary contact information 51 associated with the first party (Bob), created by the system and including the first contact information in Figure 1, is created by applying the one-way encryption algorithm 59 to a different index, for example, a different value of x. The created secondary contact information 52 may also be called CIx. The system may use index x=1 for Alice, for example.

[0083] Each secondary contact information 52, including the second contact information in Figure 1, derived from the primary contact information 51 (CIx) in the second party's (Alice's) system, is derived using different sub-indexes 56, for example, different values ​​of y. The current index (x) and sub-index 56 (y) jointly form a new index (xy). The derived secondary contact information 52 may also be called CIx.y. This system may use sub-index y=1 for Carol, for example.

[0084] The system of the third party (Carol) derives secondary contact information 52 (CIx.y), for example, each tertiary contact information 53 derived from the second contact information in Figure 1, by applying a one-way encryption algorithm 59 to different sub-indexes 57, for example, different values ​​of z. The current index (xy) and sub-index 57 (z) jointly form a new index (xyz). The derived tertiary contact information 53 may also be called CIx.yz. This system may use sub-index z=1 for Dave, for example. Furthermore, k-th-order contact information can also be derived in a similar manner.

[0085] Using indexes and sub-indexes provides versatility and flexibility when applying shared policies to individual parties or groups of parties. For example, Bob might block messages from Carol (e.g., index=1.3.2) without blocking Alice (e.g., index=1.3) or any of Alice's other friends (e.g., index=1.3.x, x≠2). Bob could also block an entire branch of the contact information tree (e.g., index=1.3.2.y) or accept only messages up to three levels deep.

[0086] A contact information tree can be formed by using the index and sub-index described in relation to Figure 2. Figure 3 shows a first example of such a contact information tree. Figure 3 shows a forest containing three contact information trees. The first contact information 61 and the second contact information 62 are part of the first contact information tree. The first contact information 61 is at a higher hierarchical level than the second contact information 62 within the contact information tree. The first contact information tree has four hierarchical levels 93 to 96. Hierarchical level 93 contains the primary contact information 51 in Figure 2. Hierarchical level 94 contains the secondary contact information 52 in Figure 2.

[0087] Figure 4 shows a second example of a contact information tree, a contact information tree 90. The root secret 91 is at the root of the contact information tree 90. The root secret may be generated in a system associated with the first party (Bob). The root secret may be, for example, a random number. The primary contact information is derived from the root secret. In the example in Figure 4, the primary contact information includes a first contact information 61, a third contact information 261 for contacting the first party, and a fourth contact information 271 for contacting the first party.

[0088] The third contact information 261 is specific to the fourth party, and the fourth contact information 271 is specific to the fifth party. The first contact information 61, the third contact information 261, and the fourth contact information 271 are at the same hierarchical level 93 in the contact information tree 90. Each primary contact information associated with the first party (Bob), created by the system, can be created by applying the one-way encryption algorithm 59 of Figure 2 to a different index, as described in relation to Figure 2.

[0089] HD wallets (see, for example, https: / / en.bitcoin.it / wiki / BIP_0032) are also created from a root secret / seed. An HD wallet contains cryptographic keys in a tree structure, where a parent key can generate child keys, child keys can generate grandchild keys, and so on, indefinitely. Cryptocurrency holders can use the tree structure to organize transactions by transaction type or by related entity, such as a department or subsidiary. HD wallets are created from a single master root seed. The advantage of this is that deposits are not related to the same entity and deposits can be tracked through a dedicated Bitcoin address for each invoice or payment request. Furthermore, HD wallets also offer the option to create sub-public keys without accessing the corresponding private key. This means that HD wallets can be used on insecure servers or in receive-only mode. A similar advanced configuration can also be used for contact information trees.

[0090] Figure 5 shows an embodiment of how the derivation operation 79 uses a hash function. The hash function is an embodiment of the one-way cryptographic algorithm 59 in Figure 2. In the embodiment shown in Figure 5, the first contact information 71 comprises an index 203 (value 1 in the example in Figure 5) and a hash value 205 in the contact information tree. The second contact information 72 derived by the second party's system comprises a second party identifier 207. The identifier 207 is a new index (1.2 in the example in Figure 5) created by adding a subindex 77 (value 2 in the example in Figure 5) to the original index 203, and includes a dot (".") as a delimiter, i.e., index = index&"."&subindex.

[0091] The second contact information 72 further comprises the result of applying a hash function to both the value 205 and the subindex 77. The hash function could be, for example, SHA-256, MD5, CRC-32, Keccak-512, or Shake-256. In an alternative embodiment, a different one-way cryptographic algorithm may be used. The new hash value 209 is calculated by performing the hash function of the original hash value 205 with the new subindex 77 added, i.e., hash=HASH(hash&subindex). The root of this algorithm, i.e., the root secret, may be a random number generated by the system and associated with the first party (Bob).

[0092] The first contact information 71 and the second contact information 72 further comprise the communication identifier 201 of the first party (Bob) or the communication identifier of the privacy routing service provider. In the example in Figure 5, the communication identifier 201 is Bob's email address (e.g., bob@kpn.com), which was copied in the derivation operation 79. Alternatively, the communication identifier could be a postal address, telephone number, IP address, domain name, TOR onion address, distributed identifier (DID), SIP address, etc. To ensure backward compatibility, the method may be used to extend the current communication identifier so that messages without this extension can still be received.

[0093] If the contact information includes the PRSP's communication identifier (e.g., "PRSP-service@kpn.com") instead of the first party's (Bob's) communication identifier, this can be signaled in the contact information. Based on this signaling, in order to determine which customer the message is intended for, the PRSP may obtain the root secrets of all customers and attempt to reconstruct the received hash value based on these root secrets and the received index. Since hash collisions are rare, a unique, anonymous customer identification is achieved. This has the advantage that the first party (Bob) can keep his own communication identifier private (no correlation by eavesdroppers).

[0094] Contact information can also signal that certain index values ​​(e.g., odd indexes) are leaves in the contact information tree and can only be used to contact the first party (Bob) and not for further derivation (e.g., "odd=leaf"). In this case, contact information can also signal that other index values ​​(e.g., even) can only be used for further derivation / branching (e.g., "even=branch_only"). Contact information can also signal whether the branching depth is limited or unlimited (e.g., "max_branching=5" or "max_branching=unlimited").

[0095] Figure 6 shows an embodiment of how a public-key cryptography algorithm is used. The public-key cryptography algorithm is an embodiment of the one-way encryption algorithm 59 in Figure 2. In the embodiment shown in Figure 6, the first contact information 81 comprises the public key 211 of the first party (Bob) or PRSP and encrypted information (enc) 213 encrypted with the public key 211. The encrypted information 213 comprises an index in the contact information tree (value 1 in the example in Figure 6). The second contact information 82 comprises the result 215 (enc) obtained by encrypting the combination of the encrypted information 213 and the subindex 87 of the index (value 2 in the example in Figure 6) with the public key 211 in the derivation operation 89, i.e., enc = ENC(enc&subindex). The result 215 comprises the identifier of the second party (Alice). The identifier of the second party (Alice) comprises an index and a subindex 87.

[0096] In the embodiment shown in Figure 6, each derivation includes an encryption step using this public key 211. These encryption steps are similar to layers of an onion. When a system associated with the first party (Bob) receives a message, it can decrypt it to verify that the received contact information is authentic and to examine the details. By decrypting the first encrypted information 213 from the result / further encrypted information 215 and decrypting the initial encrypted information, such as the root secret, from the first encrypted information 213, the system associated with the first party (Bob) can verify that the contact information is authentic and apply a shared policy associated with the identifier obtained by examining the details.

[0097] In the embodiment shown in Figure 6, the (initial) index is not updated, and the initial index and each of the one or more sub-indexes are stored in separate cryptographic steps / layers, rather than as a single index as in the embodiment shown in Figure 5. However, as in the embodiment of Figure 5, the initial index and each of the one or more sub-indexes (one sub-index if the derived contact information is secondary contact information) jointly form the identifier of the party that derived the contact information. The advantage of the embodiment shown in Figure 6 is that the depth of the contact information tree is hidden from the other parties, including Alice and Carol. The public key can be based on, for example, RSA, elliptic curve, or El-Gamal public-key cryptography.

[0098] The first contact information 81 and the second contact information 82 further comprise the communication identifier 201 of the first party (Bob) or the communication identifier of the PRSP. In the example in Figure 6, the communication identifier 201 is Bob's email address.

[0099] In another example, Bob outsourced the verification of incoming messages to PRSP. In this case, the public key mentioned above could be PRSP's public key. This hides Bob's communication identifier within the encrypted onion, making it viewable only by PRSP. This has the advantage that decryption needs to be performed only once per message, rather than for all of PRSP's customers, as in the embodiment shown in Figure 5 (using hashes).

[0100] If Bob outsources the verification of incoming messages to PRSP, a cryptographic accumulator may be used to allow PRSP to enforce whitelisting and / or blacklisting while keeping the contents of the whitelist and / or blacklist confidential. In this case, proof of being whitelisted and / or not being blacklisted may need to be provided. Such proof could be, for example, a zero-knowledge proof (ZKP).

[0101] A first embodiment of the method for creating and deriving contact information and establishing a communication relationship in Figure 1 comprises a first embodiment of the method for deriving contact information comprising steps 105, 107, and 121, and a first embodiment of the method for establishing a communication relationship comprising steps 101, 103, 127, 113, and 115.

[0102] A second embodiment of the method for establishing a communication relationship is shown in Figure 7. Step 151 comprises receiving a message from the system of a third party (Carol), for example, a message requesting that a communication relationship be established. The message comprises second contact information for contacting the first party (Bob). The second contact information is derived from the first contact information for contacting the first party (Bob). The first contact information is specific to the second party (Alice). The second contact information is specific to the third party (Carol) and comprises an identifier for the second party (Alice).

[0103] In the embodiment of Figure 7, step 151 comprises receiving the second contact information 72 of Figure 5. The second contact information 72 comprises a communication identifier 201, an index 207, and a hash value 209. Step 153 comprises executing a hash function to calculate the hash value based on the root secret of the first party (Bob) and the index 207. In an alternative embodiment, the root secret is not used, and the hash value is calculated based on an initial hash value associated with (and provided to) the party, in which the received contact information includes a number as the initial index (for example, the value of x in index xyz).

[0104] Step 155 comprises determining whether the hash value 209 received in step 151 matches the hash value calculated in step 153. If it is determined in step 155 that the two hash values ​​match, then step 113 is performed. If it is determined in step 155 that the two hash values ​​do not match, i.e., the received contact information is not genuine, then step 161 is performed. Step 161 comprises ignoring / deleting the message received in step 151 and optionally returning an error message to the third party's (Carol's) system.

[0105] Step 113 comprises obtaining a shared policy associated with the identifier of the second party (Alice), that is, an index included in the contact information received in step 151. Step 157 comprises checking the policy obtained in step 113.

[0106] If, in step 157, it is determined that the message received in step 151 needs to be accepted, step 163 is performed and the message is automatically accepted. If, in step 157, it is determined that the message received in step 151 needs to be stored, step 164 is performed and the message is stored. If the message is stored, the first party can later select the message and accept it manually. In either case, a communication relationship is established between the first party (Bob) and the third party (Carol).

[0107] If, in step 157, it is determined that the message received in step 151 should be blocked, then step 166 is performed and the message is blocked. If, in step 157, it is determined that the message received in step 151 should be rejected, then step 167 is performed and the message is rejected. For example, the first party (Bob) can immediately read the introduction from party A, ignore / block the introduction from party B, and remember the introduction from party C to read later. Step 167 comprises sending a rejection message to the third party's (Carol's) system. If step 166 is performed, no rejection message is sent. Step 166 may be similar to step 161.

[0108] Typically, the first party configures policies for direct contacts, whose primary contact information is created by the system associated with the first party, and for other contacts whose contact information is derived by the other party. Typically, the same policy is initially used for all other contacts, and then the first party modifies the policy of any of the other contacts based on received messages containing contact information derived by the other contacts.

[0109] Typically, the first party knows the direct contact's ID, so in the case of a direct contact, the first party can configure a policy before receiving a message containing contact information derived from that direct contact. For example, if Alice, Frank, and the directory service are all direct contacts, Bob can configure his policy to immediately read referrals from the trusted Alice, ignore / block referrals from the untrustworthy Frank, and remember the directory service referral to read later.

[0110] A second embodiment of the method for deriving contact information is shown in Figure 8. Step 171 comprises receiving contact information to contact a specific party, for example, a first party (Bob). The contact information is specific to the party receiving the contact information in step 171, for example, a second party (Alice). In the embodiment of Figure 8, the contact information includes referral restrictions that specify how often the contact information may be derived from the first referral information, i.e., the contact information created by a specific party. These referral restrictions limit potential abuse. For example, "maxreferrals=3" in the contact information indicates that only three referrals, "x.1", "x.2", and "x.3", are permitted from the first referral information.

[0111] The number of referrals may be limited per hour. For example, contact information may be specified as "maxreferralsperday=20". In an alternative embodiment, the contact information may further include metadata that restricts the means by which the derived contact information can be shared, for example, not sharing over the internet and limiting sharing to face-to-face via short-range digital communication.

[0112] Step 173 comprises verifying whether the referral limit specified in step 171 has been reached in the contact information received. This may be verified, for example, based on the number of sub-indexes in the received index (see, for example, the example in Figure 5), or based on the number of sub-indexes / encryption steps in the received encrypted information (see, for example, the example in Figure 6). If it is determined in step 173 that the referral limit has not been reached, step 107 is performed. This may be enforced, for example, using a secure hardware module. The integrity of this field may be protected, for example, by encryption.

[0113] Step 107 comprises deriving new contact information from the contact information received in Step 171 to contact a specific party, for example, a first party (Bob). The new contact information is specific to the party to whom the new contact information is sent, for example, a third party (Carol), and includes an identifier of the party deriving the new contact information, for example, a second party (Alice). The new contact information may be derived from the received contact information by applying a one-way encryption algorithm to at least a portion of the received contact information.

[0114] Step 121 comprises sending the new contact information to the system of the party from which the new contact information was derived in Step 107, for example, a third party (Carol). Step 175 comprises sending a notification to a system associated with a specific party, for example, a first party (Bob). This notification may be sent, for example, by the address book application of the party from which the new contact information was derived. Instead of sending individual notification messages, notifications may be sent using a new recipient field. For example, in addition to the conventional email recipient fields "to", "cc", and "bcc", a field "cit" may be introduced.

[0115] For example, if Alice wants to share the contact information she derived to contact Bob with Carol, Alice sends a message to Carol with the subject "to" Bob. Carol then receives a message from Alice containing the contact information she derived to contact Bob, while Bob receives a notification that Alice has introduced Carol. It is configurable whether such notifications are always sent, never sent, or determined on a case-by-case basis by the user. In alternative embodiments, step 175 may be omitted, and step 173 may be omitted. In the latter case, step 105 in Figure 5 does not need to be implemented by step 171.

[0116] The derived contact information may further comprise encrypted information related to the context in which the contact information was derived, such as a timestamp, GPS location, and / or photograph. The derived contact information may include additional metadata added by the party that derived the new contact information, for example, a second party (Alice) (e.g., "I derived this third contact information so that Carol could contact Bob"). This party may digitally sign the metadata using their private key and / or encrypt portions of their own metadata or the metadata of another party higher up in the contact information tree using their own public key or the public key of this other party, respectively.

[0117] Optionally, if sub-indexes are used in different iterations of step 107, as described in relation to Figures 4 through 6, the sub-indexes may not be generated sequentially, but rather randomly or deterministically, for example, based on the identifier of the party from which the new contact information is derived. This masks the time when the party obtained the new contact information, as well as the number of times the party derived new contact information from the received contact information. This may be done to provide anonymity to the party that derived the new contact information, for example, a second party (Alice). This may result in collisions, but the likelihood is low, and even if collisions occur, the impact will not be significant.

[0118] In an alternative embodiment, if sub-indexes are used in different iterations of step 107, as described in relation to Figures 4 to 6, the party receiving the contact information may, in an additional step, derive one or more items of new contact information from the received contact information for its own use. This party can then use this new contact information instead of the received contact information to establish a communication relationship. For example, instead of using CI1 to establish a communication relationship with Bob, Alice may derive and use CI1.3 and CI1.4.

[0119] In this alternative embodiment, or a different alternative embodiment, the party receiving the contact information may derive further new contact information from the new contact information, and further new contact information from the further new contact information, and so on. This may be done to mask the depth / path of the referral and give anonymity to the party receiving the contact information, for example, a second party (Alice). For example, Alice can refer to herself multiple times by repeatedly applying the contact information derivation process and optionally selecting a random index for each derivation step. The final new contact information may be derived for another party and sent to this other party, or it may be derived for the party's own use. As an example of the latter, Alice may generate a very high-order derivation, thereby masking how Alice is actually being referred to. This may be useful if Alice has received, or may have received, contact information from, for example, a criminal or a suspicious journalist.

[0120] A first embodiment of a system for establishing a communication relationship and a system for deriving contact information is shown in Figure 9. System 11 of the first party (Bob) establishes the communication relationship. System 1 of the second party (Alice) derives contact information. System 21 of the third party (Carol) uses the derived contact information to request System 1 to establish a communication relationship between the third party (Carol) and the first party (Bob). Systems 1, 11, and 21 are part of the communication system 10.

[0121] The first party's (Bob's) system 11 comprises a receiver 13, a transmitter 14, a processor 15, and a memory 17. The processor 15 is configured to receive messages from the third party's (Carol's) system 21. The messages include second contact information for contacting the first party (Bob). The second contact information is derived from the first contact information for contacting the first party (Bob). The first contact information is unique to the second party (Alice). The second contact information is unique to the third party (Carol) and includes an identifier for the second party (Alice).

[0122] The processor 15 is further configured to obtain a shared policy associated with the identifier of the second party (Alice) and to establish a communication relationship between the first party (Bob) and the third party (Carol) according to the shared policy. In the embodiment shown in Figure 9, the processor 15 is further configured to create first contact information and to transmit the first contact information to the system 1 of the second party (Alice).

[0123] The second party's (Alice's) system 1 comprises a receiver 3, a transmitter 4, a processor 5, and a memory 7. The processor 5 is configured to receive first contact information from the first party's (Bob's) system 11, derive second contact information for contacting the first party (Bob) from the first contact information, and transmit the second contact information to the third party's (Carol's) system 21. The second contact information is unique to the third party (Carol) and includes the identifier of the second party (Alice).

[0124] A second embodiment of the system for establishing a communication relationship is shown in Figure 10. In the embodiment of Figure 9, the shared policy is obtained and the communication relationship is established in the first party's (Bob's) system 11, whereas in the embodiment of Figure 10, the shared policy is obtained and the communication relationship is established in PRSP's system 31. System 31 is associated with at least the first party, i.e., it provides privacy routing services to at least the first party. PRSP's system 31 is different from the first party's (Bob's) system 41. Systems 1, 21, 31, and 41 are part of the communication system 40.

[0125] The PRSP system 31 comprises a receiver 33, a transmitter 34, a processor 35, and a memory 37. The processor 35 is configured to receive messages from the third party's (Carol's) system 21. The messages include second contact information for contacting the first party (Bob). The second contact information is derived from the first contact information for contacting the first party (Bob). The first contact information is specific to the second party (Alice). The second contact information is specific to the third party (Carol) and includes the identifier of the second party (Alice).

[0126] The processor 35 is further configured to obtain a shared policy associated with the identifier of the second party (Alice) and to establish a communication relationship between the first party (Bob) and the third party (Carol) in accordance with the shared policy. In the embodiment of Figure 10, the processor 35 is further configured to create first contact information and to transmit the first contact information to the system 1 of the second party (Alice). In an alternative embodiment, the system 41 of the first party (Bob) is configured to create first contact information.

[0127] The processor 5 of System 1 is configured to receive first contact information from the PRSP's System 31, derive second contact information for contacting the first party (Bob) from the first contact information, and transmit the second contact information to the third party's (Carol's) System 21. The second contact information is unique to the third party (Carol) and includes the identifier of the second party (Alice).

[0128] In the embodiments shown in Figures 9 and 10, systems 1, 11, and 31 each comprise one processor 5, one processor 15, and one processor 35, respectively. In alternative embodiments, one or more of systems 1, 11, and 31 comprise multiple processors. Processors 5, 15, and 35 may be general-purpose processors, such as ARM, Qualcomm, AMD, or Intel processors, or they may be application-specific processors. Processors 5, 15, and 35 may run, for example, Google Android, Apple iOS®, a Unix-based operating system, or Windows as their operating system.

[0129] The receivers 3, 13, and 33 and transmitters 4, 14, and 34 of systems 1, 11, and 31 may each use one or more wired or wireless communication technologies such as Ethernet, Wi-Fi, LTE, and / or 5G new radio to communicate with other devices on the internet via an access point / base station, or they may use face-to-face communication such as Bluetooth, Wi-Fi Direct, QR code, or dead-drop solution to communicate with other devices. The receivers and transmitters of the systems may be combined in a transceiver. Systems 1, 11, and 31 may also include other components typical of digital devices.

[0130] Figure 11 shows an embodiment of how hierarchical deterministic cryptography is applied to form a contact information tree. In this embodiment, a function can be used to create a public key p (in the space of public key P) from a secret key s (from the space of secret key S).

[0131]

number

[0132] function

[0133]

number

[0134]

number

[0135]

number

[0136]

number

[0137] Function f may be used in step 101 of Figure 1 to derive a new public key x1 from public key p. This new public key x1 is included in the first contact information 71 of Figure 5 instead of the hash value 205. Function f may be used in step 107 of Figure 1 to derive a new public key x2 from public key x1. This new public key x2 is included in the second contact information 72 of Figure 5 instead of the hash value 209.

[0138]

number

[0139]

number

[0140]

number

[0141]

number

[0142] Furthermore, the first party is function g and

[0143]

number

[0144] Figure 12 is a block diagram illustrating an exemplary data processing system capable of performing the methods described with reference to Figures 1, 7, and 8. As shown in Figure 12, the data processing system 300 may include at least one processor 302 coupled to the memory element 304 via a system bus 306. Thus, the data processing system may store program code within the memory element 304. Furthermore, the processor 302 may execute program code accessed from the memory element 304 via the system bus 306. In one embodiment, the data processing system may be implemented as a computer suitable for storing and / or executing program code. However, it should be understood that the data processing system 300 may be implemented in the form of any system including a processor and memory capable of performing the functions described herein.

[0145] The memory element 304 may include, for example, local memory 308 and one or more physical memory devices such as one or more bulk storage devices 310. Local memory may refer to random access memory or other non-persistent memory devices that are typically used during the actual execution of program code. Bulk storage devices may be implemented as hard drives or other persistent data storage devices. The processing system 300 may also include one or more cache memories (not shown) that provide temporary storage for at least some of the program code in order to reduce the number of times the program code must be retrieved from the bulk storage device 310 during execution.

[0146] The input / output (I / O) devices, indicated as input device 312 and output device 314, can optionally be coupled to a data processing system. Examples of input devices, but not limited to these, may include a keyboard, a pointing device such as a mouse, a camera, etc. Examples of output devices, but not limited to these, may include a monitor or display, speakers, etc. The input and / or output devices can be coupled to the data processing system directly or through an intermediary I / O controller.

[0147] In one embodiment, the input device and the output device may be implemented as a combined input / output device (shown in Figure 12 by a dashed line enclosing the input device 312 and the output device 314). An example of such a combined device is a touch-sensitive display, sometimes referred to as a “touchscreen display” or simply a “touchscreen.” In such embodiments, input to the device may be provided by the movement of a physical object, such as a stylus or the user’s finger, on or near the touchscreen display.

[0148] The network adapter 316 may also be coupled to the data processing system so that it can connect to other systems, computer systems, remote network devices, and / or remote storage devices through an intervening private or public network. The network adapter may comprise a data receiver for receiving data transmitted to the data processing system 300 by the systems, devices, and / or networks, and a data transmitter for transmitting data from the data processing system 300 to the systems, devices, and / or networks. Modems, cable modems, and Ethernet cards are examples of various types of network adapters that may be used by the data processing system 300.

[0149] The network adapter 316 enables the data processing system to connect to the internet, for example via Wi-Fi or Ethernet, or to connect directly to nearby devices, for example via Bluetooth, Wi-Fi-Direct, or ultrasound. Data can also be exchanged between the data processing system and other devices in other ways, for example by enabling the data processing system to scan a QR code displayed on another device, and / or enabling the data processing system to display a QR code for scanning by another device.

[0150] As shown in Figure 12, the memory element 304 can store the application 318. In various embodiments, the application 318 may be stored in local memory 308, one or more bulk storage devices 310, or separately from local memory and bulk storage devices. It should be understood that the data processing system 300 may further run an operating system (not shown in Figure 12) that facilitates the execution of the application 318. The application 318 is implemented in the form of executable program code and can be executed by the data processing system 300, for example, by the processor 302. In response to the execution of the application, the data processing system 300 may be configured to perform one or more operation or method steps described herein.

[0151] Various embodiments of the present invention may be implemented as a program product for use by a computer system, and the program product defines the function of the embodiment (including the method described herein). In one embodiment, the program may be contained in various non-temporary computer-readable storage media, and the expression “non-temporary computer-readable storage media” as used herein encompasses all computer-readable media, with the sole exception of temporary propagated signals. In another embodiment, the program may be contained in various temporary computer-readable storage media. Exemplary computer-readable storage media include, but are not limited to, (i) non-writable storage media in which information is stored permanently (e.g., read-only memory devices in a computer, such as CD-ROM disks, ROM chips, or any kind of solid-state non-volatile semiconductor memory readable by a CD-ROM drive), and (ii) writable storage media in which modifiable information is stored (e.g., flash memory, floppy disks in a diskette drive or hard disk drive, or any kind of solid-state random-access semiconductor memory). The computer program may run on the processor 302 described herein.

[0152] The terms used herein are for the sole purpose of describing specific embodiments and are not intended to limit the invention. The singular forms “a,” “an,” and “the” used herein are intended to include the plural form unless the context clearly indicates otherwise. Furthermore, as used herein, the terms “comprises” and / or “comprising” identify the presence of the described features, integers, steps, actions, elements, and / or components, but are not intended to exclude the presence or addition of one or more other features, integers, steps, actions, elements, components, and / or groups thereof.

[0153] All means or step-plus functional elements in the following claims are intended to include any structures, materials, or actions for performing a function in combination with any other claimed element specifically claimed. The description of embodiments of the present invention is presented for illustrative purposes only and is not intended to be exhaustive or to limit to any implementation of the disclosed forms. Many modifications and changes will be apparent to those skilled in the art without departing from the scope of the invention. These embodiments have been selected and described to best illustrate the principles of the invention and some practical applications, and to enable others skilled in the art to understand the invention in terms of various embodiments with various modifications suitable for specific intended uses.

Claims

1. A method for creating and deriving contact information and establishing a communication relationship, Step (101) of creating first contact information for contacting the first party, wherein the first contact information is unique to the second party, The steps include (103) transmitting the first contact information to the system of the second party, Step (107) of the system of the second party, wherein the second contact information for contacting the first party is derived from the first contact information, the second contact information being unique to the third party and comprising an identifier of the second party, Step (109) of transmitting the second contact information from the second party's system to the third party's system, Step (111) of sending a message from the system of the third party to a system associated with the first party, wherein the message includes the second contact information, The steps include obtaining the shared policy associated with the identifier of the second party (113), Step (115) of establishing the communication relationship between the first party and the third party in accordance with the shared policy. A method that includes [a certain feature].

2. The method according to claim 1, wherein the second contact information (52) is derived from the first contact information (51) by applying a one-way encryption algorithm (59) to at least a portion of the first contact information (51).

3. The method according to claim 1 or 2, wherein the first contact information (61) and the second contact information (62) are part of a contact information tree (90), and the first contact information (61) is at a higher hierarchical level (93) in the contact information tree (90) than the second contact information (62).

4. Step (91) to generate the root secret, The steps include determining the first contact information (61) by deriving the first contact information (61) from the root secret (91), A step in the system of the first party to derive a third contact information (261) for contacting the first party from the root secret (91), wherein the third contact information (261) is unique to the fourth party, and the first contact information (61) and the third contact information (261) are at the same hierarchical level (93) in the contact information tree (90). The method according to claim 3, further comprising:

5. The method according to claim 3 or 4, wherein the first contact information (71) comprises an index (203) and a value (205) in the contact information tree, the identifier (207) of the second party comprises the index (203) and a sub-index (77) of the index (203), and the second contact information (72) further comprises the result (209) of applying a one-way encryption algorithm to both the value (205) and the sub-index (77).

6. The method according to claim 3 or 4, wherein the first contact information (81) comprises a public key (211) of the first party or a privacy routing service provider and encrypted information (213) encrypted with the public key (211), the encrypted information comprises an index in the contact information tree, and the second contact information (82) comprises the result (215) of encrypting a combination of the encrypted information (213) and a sub-index (87) of the index with the public key (211), the result comprises the identifier of the second party in an encrypted form, and the identifier of the second party comprises the index and the sub-index (87).

7. The method according to any one of claims 1 to 6, wherein the shared policy is obtained in the system (11) of the first party or the system (31) of the privacy routing service provider, and the communication relationship is established.

8. The method according to any one of claims 1 to 7, wherein the first contact information and the second contact information comprise the communication identifier (201) of the first party or the communication identifier of the privacy routing service provider.

9. The method according to any one of claims 1 to 8, wherein the first contact information includes a referral limit, the referral limit specifies how often contact information can be derived from the first contact information, and the method further comprises the step (173) of verifying that the referral limit has not been reached before the system of the second party derives the second contact information from the first contact information (107).

10. The method according to any one of claims 1 to 9, further comprising the steps of deriving the second contact information (107), sending a notification from the system of the second party to the system associated with the first party (175), and sending the second contact information to the system of the third party (121).

11. The method according to any one of claims 1 to 10, wherein the second contact information further comprises encrypted information relating to the context in which the second contact information is derived.

12. A method for deriving contact information, Step (107) of deriving second contact information for contacting a first party from first contact information for contacting a first party, wherein the first contact information is unique to the second party, the second contact information is unique to the third party, and includes an identifier for the second party; The steps (121) include transmitting the second contact information to the third party's system and A method that includes [a certain feature].

13. A method for establishing a communication relationship, Step (127) of receiving a message from a third party's system, wherein the message comprises second contact information for contacting the first party, the second contact information is derived from first contact information for contacting the first party, the first contact information is unique to the second party, the second contact information is unique to the third party, and comprises an identifier of the second party. The steps include obtaining the shared policy associated with the identifier of the second party (113), Step (115) of establishing the communication relationship between the first party and the third party in accordance with the shared policy. A method that includes [a certain feature].

14. The first step of creating contact information (101), Step (103) of transmitting the first contact information to the system of the second party and The method according to claim 13, further comprising:

15. A computer program or a series of computer programs comprising at least one software code portion, or a computer program product that stores at least one software code portion, wherein the software code portion is configured to perform the method described in any one of claims 1 to 14 when executed on a computer system.

16. A system (1) for deriving contact information, Deriving second contact information for contacting a first party from first contact information for contacting a first party, wherein the first contact information is unique to the second party, the second contact information is unique to the third party, and includes an identifier for the second party. Transmitting the second contact information to the third party's system A system (1) comprising at least one processor (5) configured to perform the following.

17. A system for establishing communication relationships (11, 31), Receiving a message from a third party's system, wherein the message comprises second contact information for contacting the first party, the second contact information is derived from first contact information for contacting the first party, the first contact information is unique to the second party, the second contact information is unique to the third party, and comprises an identifier of the second party. Obtaining the shared policy associated with the identifier of the second party, To establish the communication relationship between the first party and the third party in accordance with the shared policy. A system comprising at least one processor (15, 35) configured to perform the following.

18. The at least one processor (15, 35) Creating the first contact information as described above, Transmitting the first contact information to the second party's system The system according to claim 17 (11, 31), further configured to perform the following:

19. A system (10, 40) for deriving contact information and establishing a communication relationship, comprising: the system (1) according to claim 16 for deriving contact information; and the system (11, 31) according to claim 17 or claim 18 for establishing a communication relationship.

Images