Patent Description:
As the amount of data transmitted over networks by users continues to grow, the ability to maintain privacy of users' data and, in particular, to enforce privacy regulation over such data presents a challenge. For example, the General Data Protection Regulation (GDPR) has proposed a regulation called the "Right to be Forgotten" which allows a user to request to have the user's data deleted, for example from various public social media or other sites. However, existing networks do not provide efficient procedures or methodologies to handle such end user data deletion requests and/or to otherwise enforce data privacy rules. <CIT> discloses a system and method for authentication, authorization, and access management based on personally identifiable information and data sets pertaining to individual identity and its attributes within independent computer systems and digital networks.

Some embodiments advantageously provide methods and apparatuses for a privacy enforcer. Optional features are defined by the dependent claims.

According to one aspect of the present disclosure, a method implemented in a data protection broker node is provided. The method includes performing a bootstrap operation between a user and the data protection broker node, to initialize a blockchain; as a result of the bootstrap operation, obtaining a trusted temporary public identifier identifying the user; receiving a request for a new transaction associated with the user and joining the new transaction to the blockchain; and authorizing the user to use the trusted temporary public identifier to perform a user transaction to protect a privacy of the user's data.

In some embodiments of this aspect, the trusted temporary public identifier is a hashed value. In some embodiments of this aspect, the method further includes sending the trusted temporary public identifier to the user to anonymously register the user to at least one third-party service provider. In some embodiments of this aspect, the method further includes receiving an identifier from the at least one third-party service provider; and when the received identifier matches the trusted temporary public identifier, recording at least one activity of the user transaction involving the user's data in the blockchain. The method further includes adding a smart contract to the blockchain, the smart contract being associated to the trusted temporary public identifier; using the trusted temporary public identifier to map the smart contract to the user's data; and executing the smart contract to control access, by at least one third-party service provider, to at least part of the user's data during the user transaction and according to at least one term of the smart contract.

In some embodiments of this aspect, the at least one term of the smart contract includes at least one self-executing term to handle delivery of a product ordered during the user transaction to the user's physical mailing address. In some embodiments of this aspect, the at least one self-executing term includes: when a predetermined destination code is received from a third-party delivery service provider, providing the third-party delivery service provider with the user's physical mailing address, the destination code being different from the user's physical mailing address. Executing the smart contract further includes participating in the user transaction by communicating with at least one of at least one third-party service provider on behalf of the user according to the at least one term of the smart contract. In some embodiments of this aspect, the at least one term of the smart contract includes at least one of: at least one type of personal information; at least one third-party service provider; and at least one rule for electronic access to the at least one type of personal information by the at least one third-party service provider.

In some embodiments of this aspect, the at least one rule further includes restricting electronic access to at least one of the at least one type of personal information by one of the at least one third-party service provider; and permitting electronic access to at least another of the at least one type of personal information by the one of the at least one third-party service provider. In some embodiments of this aspect, the at least one term of the smart contract is set by the user to control access to the user's data by the at least one third-party service provider participating in the user transaction. In some embodiments of this aspect, the method further includes responsive to receiving a request from one of the at least one third-party service provider to verify a purchase amount for the user transaction, using the obtained trusted temporary public identifier to verify the purchase amount with a financial institution associated with the user.

In some embodiments of this aspect, the method further includes receiving, from one of the at least one third-party service provider, a request to receive at least part of the user's data, the request indicating the trusted temporary public identifier that is associated to the user's data; mapping the indicated trusted temporary public identifier to the user; determining whether the user consents to providing the at least the requested part of the user's data to the one of the at least one third-party service provider; and based at least in part on the determination of the user consent, one of providing and not providing the at least the requested part of the user's data to the one of the at least one third-party service provider. In some embodiments of this aspect, the user's data includes personal information of the user that is used during the user transaction. In some embodiments of this aspect, the personal information includes at least one of a first name, a last name, a physical address, an email address, a telephone number, a social security number, bank account information, credit card information, a driver's license number and a health insurance number.

According to another aspect of the present disclosure, a data protection broker node is provided. The data protection broker node includes processing circuitry. The processing circuitry is configured to cause the data protection broker node to perform a bootstrap operation between a user and the data protection broker node, to initialize a blockchain. The processing circuitry is configured to cause the data protection broker node to, as a result of the bootstrap operation, obtain a trusted temporary public identifier identifying the user. The processing circuitry is configured to cause the data protection broker node to receive a request for a new transaction associated with the user and join the new transaction to the blockchain. The processing circuitry is configured to cause the data protection broker node to authorize the user to use the trusted temporary public identifier to perform a user transaction to protect a privacy of the user's data.

In some embodiments of this aspect, the trusted temporary public identifier is a hashed value. In some embodiments of this aspect, the processing circuitry is further configured to cause the data protection broker node to send the trusted temporary public identifier to the user to anonymously register the user to at least one third-party service provider. In some embodiments of this aspect, the processing circuitry is further configured to cause the data protection broker node to receive an identifier from the at least one third-party service provider; and when the received identifier matches the trusted temporary public identifier, record at least one activity of the user transaction involving the user's data in the blockchain. The processing circuitry is further configured to cause the data protection broker node to add a smart contract to the blockchain, the smart contract being associated to the trusted temporary public identifier; use the trusted temporary public identifier to map the smart contract to the user's data; and execute the smart contract to control access, by at least one third-party service provider, to at least part of the user's data during the user transaction and according to at least one term of the smart contract.

In some embodiments of this aspect, the at least one term of the smart contract includes at least one self-executing term to handle delivery of a product ordered during the user transaction to the user's physical mailing address. In some embodiments of this aspect, the at least one self-executing term includes when a predetermined destination code is received from a third-party delivery service provider, provide the third-party delivery service provider with the user's physical mailing address, the destination code being different from the user's physical mailing address. The processing circuitry is configured to execute the smart contract by being configured to participate in the user transaction by communicating with at least one of at least one third-party service provider on behalf of the user according to the at least one term of the smart contract.

In some embodiments of this aspect, the at least one term of the smart contract includes at least one of: at least one type of personal information; at least one third-party service provider; and at least one rule for electronic access to the at least one type of personal information by the at least one third-party service provider. In some embodiments of this aspect, the at least one rule further includes restricting electronic access to at least one of the at least one type of personal information by one of the at least one third-party service provider; and permitting electronic access to at least another of the at least one type of personal information by the one of the at least one third-party service provider. In some embodiments of this aspect, the at least one term of the smart contract is set by the user to control access to the user's data by the at least one third-party service provider participating in the user transaction.

In some embodiments of this aspect, the processing circuitry is further configured to cause the data protection broker node to responsive to receiving a request from one of the at least one third-party service provider to verify a purchase amount for the user transaction, use the obtained trusted temporary public identifier to verify the purchase amount with a financial institution associated with the user. In some embodiments of this aspect, the processing circuitry is further configured to cause the data protection broker node to receive, from one of the at least one third-party service provider, a request to receive at least part of the user's data, the request indicating the trusted temporary public identifier that is associated to the user's data; map the indicated trusted temporary public identifier to the user; determine whether the user consents to providing the at least the requested part of the user's data to the one of the at least one third-party service provider; and based at least in part on the determination of the user consent, one of provide and not provide the at least the requested part of the user's data to the one of the at least one third-party service provider.

In some embodiments of this aspect, the user's data includes personal information of the user that is used during the user transaction. In some embodiments of this aspect, the personal information includes at least one of a first name, a last name, a physical address, an email address, a telephone number, a social security number, bank account information, credit card information, a driver's license number and a health insurance number.

Some embodiments of the present disclosure provide a solution that may be used for data privacy enforcement by e.g., GDPR authorities, which may ensure the end user's desire/option/preference to protect private data that has been determined by interactions between the end user and one or more service providers, i.e., an entity rendering a service e.g., bank, e-commerce/online shopping, delivery service, etc. to the user.

Some embodiments of the present disclosure may be implemented via a data protection broker node, e.g., GDPR data broker. The GDPR data broker may act as a bookkeeper that is configured to fulfill one or more of the following functions:.

In some embodiments, a system arranged to implement one or more embodiments of the present disclosure may include at least three actors:.

Some embodiments of the present disclosure may include a system configured to host and protect end users' private data from external entities that offer services, such as banking, online shopping, delivery services, retail stores, etc. Some embodiments of the present disclosure may be used by e.g., GDPR authorities (e.g., law enforcement, official third-party broker, an authorized financial institution, etc.) to enforce data privacy rules and/or regulations and/or to ensure that regulations allowing end users to protect their private personal information (e.g., regulations providing users with a right to have private data deleted after use), will be enforced.

In some embodiments, new functionality may be executed by a newly proposed node, which may be called a data protection broker node. The data protection broker node may act as a bookkeeper, data broker and/or guardian between the end user(s) and the service provider(s). The data protection broker node may be configured to protect and/or delete the user's data and create a log of every event of a user transaction. In some embodiments, the data protection broker node may require that new protocols and interfaces be proposed and agreed within the industry.

Some embodiments of the present disclosure may provide for only one location (e.g., at data protection node) in which the user's private data may be stored, and such location (e.g., data protection node) may be trusted by end users and service providers. In some embodiments, users may set-up their profile to allow or not allow the data protection node, also called 'GDPR Broker' to save the users' personal information using for example a SMART contract. The data protection node may provide for one unique identifier (ID) to be associated to each user and service.

Private data (e.g., personal information) associated with a user and that may be protected according to the arrangements in the present disclosure may include one or more of the following, which may be considered a non-limiting list of examples:.

Before describing in detail example embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to a privacy enforcer, such as, for example, a data protection broker. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

In some embodiments, the non-limiting term user equipment (UE) is used to designate an electronic device enabling a user to make an electronic transaction. The UE herein can be any type of user device, such as, for example, a wireless device (WD) capable of communicating with a network node or another UE over radio signals. The UE herein can by any type of communication device capable of communicating with a data protection broker node, a service provider node, another UE, an application server, a network node, a server, etc., via a wired connection and/or a wireless connection. The UE may also be a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), low-cost and/or low-complexity UE, a sensor equipped with UE, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (IoT) device, or a Narrowband IoT (NB-IOT) device etc..

In some embodiments, the term "node" is used herein and can be any kind of network node, such as, a data protection broker node, a service provider node, such as, for example, an e-commerce service provider node, a delivery provider node, a financial institution node, etc..

A node may include physical components, such as processors, allocated processing elements, or other computing hardware, computer memory, communication interfaces, and other supporting computing hardware. The node may use dedicated physical components, or the node may be allocated use of the physical components of another device, such as a computing device or resources of a datacenter, in which case the node is said to be virtualized. A node may be associated with multiple physical components that may be located either in one location, or may be distributed across multiple locations.

In some embodiments, the terms "user", "end user", and "user equipment" and "UE" are used interchangeably since the user's interaction in the arrangements disclosed herein may be via a user equipment associated with the user (e.g., the user's smartphone or other computing device) and which may be configured to communicate with one or more of the other nodes in the system over one or more communication networks, according to the embodiments of the present disclosure.

In some embodiments, the general term "bootstrap operation" may be used to indicate starting, initiating and/or initializing a blockchain.

In some embodiments, the term "trusted temporary public identifier" may be used to indicate a public identifier (e.g., a hashed value) associated to the user, which may be used to temporarily identify the user for a user transaction and which may be trusted by service providers. The trusted temporary public identifier is not a private personal identifier for the user (e.g., not the user's first and last name or social security number).

In some embodiments, the term "new transaction" may be used to indicate an instance of purchasing a product/service, or a series of interactions initiated by a user to receive services (e.g., products/services) which are provided by one or more service providers.

Any two or more embodiments described in this disclosure may be combined in any way with each other.

Note also that some embodiments of the present disclosure may be described in terms of support for regulation rules such as General Data Protection Regulation (GDPR) rules and/or other privacy legislation. That is, some embodiments of the description can be described to support enforcement of the privacy rules/legislation above. In addition, all the terms disclosed in the present document may be described by the above documents. It should be understood that the techniques disclosed herein may be used to enforce privacy rules, legislation, standards and/or privacy terms between parties, even those not expressly listed above.

Note further, that functions described herein as being performed by a data protection broker node or another node described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices.

Referring again to the drawing figures, in which like elements are referred to by like reference numerals, there is shown in <FIG> a schematic diagram of the communication system <NUM>, according to one embodiment, constructed in accordance with the principles of the present disclosure. The communication system <NUM> in <FIG> is a non-limiting example and other embodiments of the present disclosure may be implemented by one or more other systems and/or networks. Referring to <FIG>, system <NUM> includes a user equipment <NUM>, a data protection broker node <NUM> and a service provider node <NUM> in communication with one another over one or more wired and/or wireless network connections.

It should be understood that the system <NUM> may include numerous nodes of those shown in <FIG>, as well as, additional nodes not shown in <FIG>. In addition, the system <NUM> may include many more connections/interfaces than those shown in <FIG>.

The system <NUM> may include a data protection broker node <NUM> having a protector <NUM> which may be configured to one or more of: perform a bootstrap operation between a user and the data protection broker node, to initialize a blockchain; as a result of the bootstrap operation, obtain a trusted temporary public identifier identifying the user; receive a request for a new transaction associated with the user and join the new transaction to the blockchain; and authorize the user to use the trusted temporary public identifier to perform a user transaction to protect a privacy of the user's data.

Example implementations, in accordance with some embodiments, of user equipment <NUM>, data protection broker node <NUM> and service provider node <NUM>, discussed herein will now be described.

The UE includes a communication interface <NUM>, processing circuitry <NUM>, and memory <NUM>. The communication interface <NUM> may be configured to communicate with any of the nodes in the system <NUM> according to some embodiments of the present disclosure. In some embodiments, the communication interface <NUM> may be formed as or may include, for example, one or more radio frequency (RF) transmitters, one or more RF receivers, and/or one or more RF transceivers, and/or may be considered a radio interface. In some embodiments, the communication interface <NUM> may also include a wired interface.

The processing circuitry <NUM> may include one or more processors <NUM> and memory, such as, the memory <NUM>. In particular, in addition to a traditional processor and memory, the processing circuitry <NUM> may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions.

Thus, the UE <NUM> may further include software stored internally in, for example, memory <NUM>, or stored in external memory (e.g., database) accessible by the UE <NUM> via an external connection. The software may be executable by the processing circuitry <NUM>. The processing circuitry <NUM> may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., UE <NUM>. The memory <NUM> is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software may include instructions stored in memory <NUM> that, when executed by the processor <NUM> causes the processing circuitry <NUM> and/or configures the UE <NUM> to perform the processes described herein with respect to the user and/or the UE.

The data protection broker node <NUM> includes a communication interface <NUM>, processing circuitry <NUM>, and memory <NUM>. The communication interface <NUM> may be configured to communicate with the UE <NUM> and/or service provider node <NUM> and/or other nodes in the system <NUM> according to some embodiments of the present disclosure. In some embodiments, the communication interface <NUM> may be formed as or may include, for example, one or more radio frequency (RF) transmitters, one or more RF receivers, and/or one or more RF transceivers, and/or may be considered a radio interface. In some embodiments, the communication interface <NUM> may also include a wired interface.

Thus, the data protection broker node <NUM> may further include software stored internally in, for example, memory <NUM>, or stored in external memory (e.g., database) accessible by the data protection broker node <NUM> via an external connection. The software may be executable by the processing circuitry <NUM>. The processing circuitry <NUM> may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by the data protection broker node <NUM>. The memory <NUM> is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software may include instructions stored in memory <NUM> that, when executed by the processor <NUM> and/or protector <NUM>, causes the processing circuitry <NUM> and/or configures the data protection broker node <NUM> to perform the processes described herein with respect to the data protection broker node <NUM> (e.g., processes described with reference to <FIG> and/or the other figures).

The service provider node <NUM> includes a communication interface <NUM>, processing circuitry <NUM>, and memory <NUM>. The communication interface <NUM> may be configured to communicate with any of the nodes in the system <NUM> according to some embodiments of the present disclosure. In some embodiments, the communication interface <NUM> may be formed as or may include, for example, one or more radio frequency (RF) transmitters, one or more RF receivers, and/or one or more RF transceivers, and/or may be considered a radio interface. In some embodiments, the communication interface <NUM> may also include a wired interface.

Thus, the service provider node <NUM> may further include software stored internally in, for example, memory <NUM>, or stored in external memory (e.g., database) accessible by the service provider node <NUM> via an external connection. The software may be executable by the processing circuitry <NUM>. The processing circuitry <NUM> may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by the service provider node <NUM>. The memory <NUM> is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software may include instructions stored in memory <NUM> that, when executed by the processor <NUM>, causes the processing circuitry <NUM> and/or configures the service provider node <NUM> to perform the processes described herein with respect to the service provider node <NUM>.

In <FIG>, the connection between the devices, UE <NUM>, data protection broker node <NUM> and service provider node <NUM> is shown without explicit reference to any intermediary devices or connections. However, it should be understood that intermediary devices and/or connections may exist between these devices, although not explicitly shown.

Although <FIG> shows the protector <NUM>, as being within the processor <NUM> of data protection broker node <NUM>, it is contemplated that the protector <NUM> may be implemented such that a portion of the protector <NUM> is stored in a corresponding memory <NUM> within the processing circuitry <NUM>. In other words, the protector <NUM> may be implemented in hardware or in a combination of hardware and software within the processing circuitry <NUM>.

<FIG> is a flowchart of an example process in a data protection broker node (e.g., data protection broker node <NUM>) according to some embodiments of the present disclosure. One or more Blocks and/or functions and/or methods performed by the data protection broker node <NUM> may be performed by one or more elements of data protection broker node <NUM> such as by protector <NUM> in processing circuitry <NUM>, memory <NUM>, processor <NUM>, communication interface <NUM>, etc. according to the example process/method. The example process includes performing (Block S <NUM>), such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, a bootstrap operation between a user and the data protection broker node, to initialize a blockchain. The process includes, as a result of the bootstrap operation, obtaining (S <NUM>), such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, a trusted temporary public identifier identifying the user. The process includes receiving (S <NUM>), such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, from the user (e.g., via UE <NUM>) a request for a new transaction associated with the user and joining the new transaction to the blockchain. The process includes authorizing (S <NUM>), such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, the user to use the trusted temporary public identifier to perform a user transaction to protect a privacy of the user's data.

In some embodiments, the trusted temporary public identifier is a hashed value. In some embodiments, the method further includes sending, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, the trusted temporary public identifier to the user (e.g., via UE <NUM>) to anonymously register the user to at least one third-party service provider (e.g., service provider node <NUM>). In some embodiments, the method further includes receiving, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, an identifier from the at least one third-party service provider (e.g., service provider node <NUM>); and when the received identifier matches the trusted temporary public identifier, recording at least one activity of the user transaction involving the user's data in the blockchain.

In some embodiments, the method further includes adding, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, a smart contract to the blockchain, the smart contract being associated to the trusted temporary public identifier; using, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, the trusted temporary public identifier to map the smart contract to the user's data; and executing, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, the smart contract to control access, by at least one third-party service provider (e.g., service provider node <NUM>), to at least part of the user's data during the user transaction and according to at least one term of the smart contract.

In some embodiments, the at least one term of the smart contract includes at least one self-executing term to handle delivery of a product ordered during the user transaction to the user's physical mailing address. In some embodiments, the at least one self-executing term includes: when a predetermined destination code is received from a third-party delivery service provider, providing the third-party delivery service provider with the user's physical mailing address, the destination code being different from the user's physical mailing address. In some embodiments, executing the smart contract further includes participating, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, in the user transaction by communicating with at least one of at least one third-party service provider (e.g., service provider node <NUM>) on behalf of the user according to the at least one term of the smart contract.

In some embodiments, the at least one term of the smart contract includes at least one of: at least one type of personal information; at least one third-party service provider; and at least one rule for electronic access to the at least one type of personal information by the at least one third-party service provider. In some embodiments, the at least one rule further includes restricting, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, electronic access to at least one of the at least one type of personal information by one of the at least one third-party service provider (e.g., service provider node <NUM>); and permitting, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, electronic access to at least another of the at least one type of personal information by the one of the at least one third-party service provider (e.g., service provider node <NUM>).

In some embodiments, the at least one term of the smart contract is set by the user (e.g., via UE <NUM>) to control access to the user's data by the at least one third-party service provider (e.g., service provider node <NUM>) participating in the user transaction. In some embodiments, the method further includes responsive to receiving a request from one of the at least one third-party service provider (e.g., service provider node <NUM>) to verify a purchase amount for the user transaction, using the obtained trusted temporary public identifier to verify the purchase amount with a financial institution associated with the user.

In some embodiments, the method further includes receiving, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, from one of the at least one third-party service provider (e.g., service provider node <NUM>), a request to receive at least part of the user's data, the request indicating the trusted temporary public identifier that is associated to the user's data; mapping, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, the indicated trusted temporary public identifier to the user; determining, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, whether the user consents to providing the at least the requested part of the user's data to the one of the at least one third-party service provider; and based at least in part on the determination of the user consent, one of providing, such as via protector <NUM>, processing circuitry <NUM>, memory <NUM>, processor <NUM> and/or communication interface <NUM>, and not providing the at least the requested part of the user's data to the one of the at least one third-party service provider (e.g., service provider node <NUM>).

In some embodiments, the user's data includes personal information of the user that is used during the user transaction. In some embodiments, the personal information includes at least one of a first name, a last name, a physical address, an email address, a telephone number, a social security number, bank account information, credit card information, a driver's license number and a health insurance number.

Having generally described arrangements for privacy enforcement, a more detailed description of some of the embodiments are provided as follows with reference to <FIG>, and which may be implemented by UE <NUM>, data protection broker node <NUM> and/or service provider node <NUM>.

Some embodiments of the present disclosure may provide data privacy enforcement according to the user's selection of which types of personal information to restrict access to and/or which service providers are permitted access to certain types of the personal information. The following table, Table <NUM>, provides an example of a user's selection of which types of personal information to permit access to on a per service provider basis.

As can be seen in Table <NUM>, in the example, the user (e.g., via UE <NUM>) indicates in e.g., the user's profile with the data protection broker node <NUM>, that a particular service provider is permitted ('yes') to obtain access to the user's name, physical address, email address and telephone number, driver's license, health card number, health information and temporary ID; but, the user indicates (e.g., via UE <NUM>) that the service provider may not ('no') obtain access to the user's social security number (SSN) and bank card number. For the delivery service provider, the user (e.g., via UE <NUM>) has indicated that the delivery service provider is permitted ('yes') to obtain access to the user's name, physical address, email address and telephone number and temporary ID; but, the user indicates (e.g., via UE <NUM>) that the delivery service provider may not ('no') obtain access to any of the user's bank card numbers, drivers license number, health card number and health information. The data protection broker node <NUM> (e.g., GDPR broker) is permitted access to all of the user's personal information, as indicated in Table <NUM>. The financial institution/bank is permitted access only to the user's name, SSN and bank card number; but is not permitted to access any of the user's other personal information. In some embodiments, the user may indicate how the user desires to protect the user's data via e.g., a user registration/sign-up process, which is described in more detail below with reference to <FIG>.

Some embodiments of the present disclosure may use blockchain and/or smart contract technology, which is briefly described below.

Blockchain is based on a peer-to-peer (P2P) topology. Blockchains that utilize distributed ledger technology allow for contracts that are self-verifying, self-executing, and autonomous (i.e., smart contracts). Actors, such as UE <NUM>, data protection broker node <NUM> and service provider nodes <NUM> (e.g., e-commerce, delivery service, financial institution) can automatically and securely exchange terms, events and/or other information throughout the lifecycle of a transaction without relying on e.g., real world brokers or middlemen.

Blockchain may provide for transactional transparency - the ability to create secure, real-time communication networks with partners, domestic and international, to support supply chains, payment networks, etc..

A smart contract (also known as a digital contract) may be considered a program (software code) that is stored on a blockchain. A smart contract may hold all the information required to automatically execute the transaction according to the contract terms. Because a smart contract is stored on a blockchain, smart contracts are considered immutable and distributed. Smart contracts encode contractual agreements. Stated another way, a smart contract may be enforced by the software code itself, i.e., self-executing with the terms/instructions of the agreement/operation directly written into the lines of software code (e.g., if electronic payment is received of x amount, an authorization to deliver a product is transmitted to a delivery service).

Having generally described examples of personal information that may be protected according to the arrangements in the present disclosure, as well as, a general description of the blockchain and smart contract technologies which may be used in some embodiments, some example use cases are described below with reference to the flow diagrams depicted in <FIG>.

<FIG> is a flowchart illustrating an example process for initiating a privacy protection procedure for an e-commerce use case according to one embodiment. In some embodiments, <FIG> may represent an example of a user registering with a service provider to utilize the privacy protection service according to the techniques disclosed herein. The data protection broker node <NUM> may be configured to set-up a temporary blockchain including one or more of the entities participating in the e-commerce transaction (e.g., Amazon, bank, post office and user) and manage the life cycle of the transaction. For example, in step S108, the UE <NUM> initiates bootstrapping. In step S110, the data protection broker node <NUM> performs a bootstrap operation to initialize a temporary blockchain for the user's transaction and also assigns a temporary identifier (ID) (e.g., a hash value) to the user's transaction. The temporary ID may be considered a trusted temporary public identifier identifying the user. In step S112, the data protection broker node <NUM> sends a response message to the UE <NUM>. In some embodiments, the response message may include the temporary ID and/or a confirmation that the temporary blockchain has been successfully initialized. In step S114, after the UE <NUM> obtains the temporary ID, the UE <NUM> may initialize or initiate a registration request to a service provider node <NUM> (e.g., via e-commerce website). For example, the UE <NUM> may indicate to the service provider node <NUM> a request to conduct an e-commerce transaction that is privacy protected by the data protection broker node <NUM> (as opposed to e.g., a conventional e-commerce transaction without the data protection broker node <NUM>). As a result of the UE's <NUM> request, in step S116, the service provider node <NUM> may request to join the blockchain (that was initialized in step S110) and may further verify the user with the data protection broker node <NUM>. For example, the user's registration request to the service provider node <NUM> in step S114 may include an indication of the trusted, temporary public ID, which ID may be forwarded to the data protection broker node <NUM> by the service provider node <NUM> to verify the user and identify the temporary blockchain initialized for the user.

In step S118, the data protection broker node <NUM> inquires that the user is an authorized user of the data protection broker node <NUM>. The data protection broker node <NUM> may join the new transaction to the blockchain. In step S120, the service provider node <NUM> confirms that the transaction request is approved by e.g., a <NUM> OK message. In some embodiments, the signaling between the nodes (UE <NUM>, data protection broker node <NUM>, one or more service provider nodes <NUM>) is via session initiation protocol (SIP) messaging. In this example, SIP messaging is used; however, it is contemplated that the messaging between nodes may be via other communication protocols in other embodiments.

After the temporary blockchain has been initialized by the data protection broker node <NUM> and the new transaction joined to the blockchain, the user may conduct e-commerce activities with the service provider node <NUM>. For example, in step S122, the UE <NUM> may sign-up/register to the service provider node <NUM>, e.g., the user may sign-in to or register an account at the e-commerce website. In step S124, the service provider node <NUM> may confirm to the data protection broker node <NUM> that the user is signed-in/registered to his/her account. In step S126, the service provider node <NUM> may send a <NUM> OK message to the UE <NUM> to confirm to the user that the user has signed-in and/or registered to the user's account. In step S128, the data protection broker node <NUM> begins recording activities occurring during the user's transaction (e.g., use of the user's personal information, purchasing and browsing activities, delivery information, financial information, etc.). The user's activities may be recorded in the blockchain as part of the new transaction. In step S130, the user may continue with the e-commerce transaction, while the data protection broker node <NUM> records the user's activities.

<FIG> is a flowchart illustrating yet another example process for conducting a purchase transaction that is privacy protected and enforced according to one embodiment of the present disclosure. In step S132, after the user (via UE <NUM>) has signed-in to his/her account with the service provider node <NUM> (e.g., using the procedure described in <FIG>), the user may initiate a purchase of a product e.g., via an e-commerce website provided by the service provider node <NUM>. In step S134, the service provider node <NUM> sends a request to the data protection broker node <NUM> to check/verify the user's financial account for sufficient funds to cover the amount of the purchase. In step S136, the data protection broker node <NUM> sends a request to the financial institution node to check/verify the user's financial account for the amount. The request may include the user's financial information (e.g., bank account number and pin), which only the data protection broker node <NUM> has access to (not the service provider node <NUM>). The request may also include the temporary ID associated to the user. In step S138, the financial institution node joins the blockchain and, in step S140, indicates to the data protection broker node <NUM> that the user's financial account does indeed have sufficient funds to cover the purchase amount ('yes'). In step S142, the data protection broker node <NUM> authorizes the transaction to the service provider node <NUM> and, in step S144, the service provider node <NUM> uses the temporary ID to obtain the funds for the purchase. In step S146, the financial institution node transfers the funds to the service provider node <NUM>. In step S148, the financial institution node may also optionally, notify the UE <NUM> that the funds were transferred to the service provider.

In step S150, as a result of obtaining the funds for the purchase, the service provider node <NUM> may send a delivery information request to the data protection broker node <NUM>. The delivery information request may also include an indication of the delivery partner (e.g., FedEx) so that the delivery partner can be incorporated into the smart contract, as discussed in more detail below. In step S152, the data protection broker node <NUM> may forward the delivery information request to the UE <NUM>, as well as, the indication of the delivery partner. In step S154, the service provider node <NUM> may invite the delivery service provider to the blockchain ("chain"). In step S156, the UE <NUM> may provide and/or initiate a smart contract, which may include the delivery partner as a party to the smart contract. The data protection broker node <NUM> forwards the smart contract to the service provider node <NUM> in step S158. In step S160, the service provider node <NUM> may request product delivery to the delivery provider node per the terms of the smart contract. In step S162, the data protection broker node <NUM> may send the smart contract to the delivery provider node as well. In step S164, the delivery service provider node may open the smart contract and follow the instructions/terms of the smart contract, such as where to deliver the product.

The smart contract may include an indication as to a location to deliver the product packages to, as well as, the user's name, bar code, expiration date of the contract, etc. In some embodiments, the smart contract may include one or more of the following contract fields:.

The user may issue the smart contract (e.g., as in step S156), which may be joined to the blockchain (e.g., by data protection broker node <NUM>).

In some embodiments, the smart contract may facilitate delivery of the purchased good(s) according to a temporary address ID or local post office address if the user supplies the information to the delivery provider. For example, if the user supplies a trusted post office address (e.g., local post office) e.g., via the smart contract, a temporary address ID may be generated (e.g., by data protection broker node <NUM>) for the goods for this user transaction. The temporary address ID may be forwarded to the local post office. The user may then use the temporary address ID associated to the purchase in order to pick up the good(s) at the local post office. For example, in step S168, after the delivery vendor delivers the product to the local post office the delivery provider node may send a delivery notification to the data protection broker node <NUM>, in step S166. In step S168, the delivery notification may then be forwarded to the user's UE <NUM>. When the user physically obtains the goods, in step S170, the user may verify that the goods have been obtained (e.g., in step S172, UE <NUM> transmits a notification that the user picked up the goods at the pick-up location). The data protection broker node <NUM> may forward the notification to the service provider node <NUM> in step S174 and to the delivery provider node in step S176. In step S178, since the transaction is complete (e.g., payment submitted and verification of delivery), a subset or all of the temporary IDs (e.g., trusted temporary ID generated in step S110 and temporary address ID generated for the post office delivery, etc.) may be deleted and the blockchain associated to the transaction may be terminated and/or discarded.

Steps <NUM>-<NUM> may be repeated for consecutive transactions involving the same service provider node <NUM> when the user initiates additional transactions.

In an alternate embodiment, the user's trusted temporary ID generated in step S110 may be stored and/or maintained by the data protection broker node <NUM> in order to continue to permit the user to purchase products from the service provider node <NUM> using the temporary ID. In some embodiments, the data protection broker node <NUM> may maintain the records for this user's behavior or preference of shopping. The data protection broker node <NUM> may store the IDs for the user and for future use of the services.

In some embodiments, the smart contract may include a destination code (e.g., barcode). The destination code may be used to maintain the privacy of the user's geographic location from the service provider node <NUM>, while also permitting the delivery service provider to deliver the product(s) directly to the user's physical address. In one embodiment, the destination code may be provided to the service provider node <NUM> (e.g., via the smart contract) and the service provider node <NUM> may provide the destination code to its delivery vendor. The delivery provider node associated to the vendor may then send the destination code to the data protection broker node <NUM>. Per the terms of the smart contract, as a result of receiving the destination code from the vendor (e.g., as authorization/verification), the data protection broker node <NUM> may then send the user's actual physical mailing address to the delivery provider node so that the delivery driver can deliver the products to the user's home address. In the above examples, it can be seen that the smart contract may provide self-executing terms to handle e.g., delivery of a product to a user specified location, e.g., local post office or home address.

In some embodiments, because the data protection broker node <NUM> may have access to the user's personal information and/or may be configured to enforce privacy regulation at the user's request toward service providers (e.g., e-commerce, etc.), the data protection broker node <NUM> may be supervised and/or provided by a government entity, or an otherwise trusted third-party group. The data protection broker node <NUM> may maintain the end user's personal information. The following is a non-exhaustive list of functionality that may be provided by the data protection broker node <NUM>:.

In some embodiments of the present disclosure, service providers may be permitted to perform statistical analysis and track the behaviors of users with assistance from the data protection broker node <NUM>, and without compromising the user's preference for maintaining a privacy of the user's personal information. For example, the data protection broker node <NUM> may provide one or more of the following:.

<FIG> is a flowchart illustrating an example of providing statistical information to a service provider according to one embodiment of the present disclosure. In step S180, the service provider node <NUM> may request a history of a user's behavior. The request may include an identifier (ID), such as the temporary identifier (temp ID) identifying the user (e.g., temporary ID) in the ongoing user session. In step S182, the data protection broker node <NUM> may map the received ID to the user and determine whether the user has allowed access to the user's information. Depending on the user's preference, the process may proceed according to one of options A, B or C. In option A, the user has indicated permission to allow access to the user's information; thus, in step S184, the data protection broker node <NUM> may map each temp ID associated to the user and aggregate the history information. If the process proceeds to either of options A or B (the user has permitted history information to be released), the process may include mapping each temporary ID associated with the user. Such mapping may be performed by the data protection broker node <NUM> because each temp ID may be different every/each time the user logs into the service provider node <NUM> and/or data protection broker node <NUM> (e.g., each user session). The data protection broker node <NUM> maps the temp ID to the user profile every time there is a transaction. The data protection broker node <NUM> may map the current temp ID (e.g., the temp ID received in step S180 for the ongoing user session) to all previous temp IDs of the user (e.g., which may be stored by the data protection broker node <NUM>) and extracts all transaction history that is associated to all such temp IDs of the user. In step S186, the data protection broker node <NUM> may then package the extracted transaction histories for transmission to the requesting service provider node <NUM>. The data protection broker node <NUM> may package the user's information as anonymized data (e.g., remove personal information, providing only the user's history/behavior unassociated to any information that may personally identify the user) and then, in step S186, send the package to the service provider node <NUM>.

In option B, in step S188, the data protection broker node <NUM> determines that the user has not specified a preference. In step S190, the data protection broker node <NUM> sends an alert to the user's UE <NUM> to request that the user indicate if the user prefers to allow the service provider to obtain anonymized data of the user's behavior, or not. In step S192, the user answers with 'yes' and, in step S194, as a result of the yes indication, the data protection broker node <NUM> maps each temp ID associated to the user and aggregates the user's history information, as described above with respect to step S184 for option A and which will not be repeated here for brevity. As with option A, for option B the data protection broker node <NUM> packages the user's information as anonymized data (e.g., remove personal information, providing only the user's history/behavior unassociated to any information that may personally identify the user) and, in step S196, sends the package to the service provider node <NUM>.

After the data protection broker node <NUM> sends the package with the anonymized data to the service provider node <NUM> (step S186 for option A, or step S196 for option B), the process may proceed to step S198, where the service provider node <NUM> may, e.g., based on an analysis of the user's history information, determine a preference for a particular advertisement to be pushed to the user. In step S200, the service provider node <NUM> may push the determined advertisement to the user's UE <NUM>.

In option C, instead of indicating yes as with options B and C discussed above, in step S202, the user indicates no (i.e., permission is not granted). As a result of the no indication, the data protection broker node <NUM> sends a response to the service provider node <NUM> indicating that the request is not allowed in step S204. The process may terminate here.

As described in this disclosure, the data protection broker node <NUM> may be provided to initialize a temporary blockchain for a user's transaction and join the transaction to the blockchain. The data protection broker node <NUM> may also use a temporary ID to identify the user (to protect the user's personal identification) and/or the data protection broker node <NUM> may use a smart contract to process the transaction actions and/or enforce the user's privacy preferences. Even in the smart contract, there may not be any personal information stored. In some embodiments, the blockchain may be configured to have a life cycle that is as long as the user's transaction (e.g., from the user's initiation to a confirmed pick-up of the product). The data protection broker node <NUM> may be considered to be a trusted partner and may grant authentication and authorization to peer nodes in the blockchain. In some embodiments, the data protection broker node <NUM> may also provide anonymized data to service providers to permit statistical analysis of the user's behavior, without providing the user's personal information.

Claim 1:
A method implemented in a data protection broker node (<NUM>), the method comprising:
a. performing (S100) a bootstrap operation between a user and the data protection broker node (<NUM>), to initialize a blockchain;
b. as a result of the bootstrap operation, obtaining (S102) a trusted temporary public identifier identifying the user;
c. receiving (S104) a request for a new transaction associated with the user and joining the new transaction to the blockchain; and
d. authorizing (S106) the user to use the trusted temporary public identifier to perform a user transaction to protect a privacy of the user's data,
wherein the method further comprises:
adding a smart contract to the blockchain, the smart contract being associated to the trusted temporary public identifier;
using the trusted temporary public identifier to map the smart contract to the user's data; and
executing the smart contract to control access, by at least one third-party service provider, to at least part of the user's data during the user transaction and according to at least one term of the smart contract, wherein executing the smart contract comprises participating in the user transaction by communicating with the at least one third-party service provider on behalf of the user according to the at least one term of the smart contract.