WO2018140860A1 - Système et procédés de partage et d'échange de données et de préférences d'utilisateurs entre des programmes informatiques et d'autres entités tout en préservant la confidentialité des utilisateurs - Google Patents

Système et procédés de partage et d'échange de données et de préférences d'utilisateurs entre des programmes informatiques et d'autres entités tout en préservant la confidentialité des utilisateurs Download PDF

Info

Publication number
WO2018140860A1
WO2018140860A1 PCT/US2018/015696 US2018015696W WO2018140860A1 WO 2018140860 A1 WO2018140860 A1 WO 2018140860A1 US 2018015696 W US2018015696 W US 2018015696W WO 2018140860 A1 WO2018140860 A1 WO 2018140860A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
cryptographic
data
proof
computing device
Prior art date
Application number
PCT/US2018/015696
Other languages
English (en)
Inventor
Shamim A. Naqvi
Original Assignee
Sensoriant, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sensoriant, Inc. filed Critical Sensoriant, Inc.
Publication of WO2018140860A1 publication Critical patent/WO2018140860A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/18—Network protocols supporting networked applications, e.g. including control of end-device applications over a network
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/20—Information technology specific aspects, e.g. CAD, simulation, modelling, system security

Definitions

  • User information is collected and used by almost every website and Internet enterprise. User information is also shared between enterprises, mostly through bilateral agreements in which users whose information is being shared play no part. Thus, one commercial entity may sell its historical customer usage data to another entity. Some enterprises even use selling of customer profiles and data as their primary business model. Several Internet companies are racing to build computer programs and devices that contain (embedded) computer programs such as digital assistants and robots. Several enterprises have suffered user data breaches and such incidents seem to be increasing in number and ferocity of attacks. Thus, a data sharing mechanism that is both efficient and preserves user privacy will be of significant social and commercial benefit.
  • systems and methods are described herein which allow computer programs or other entities to share user data and information so that users may be authenticated and their preferences shared among entities in networked environments and machines.
  • the sharing method provides and maintains several properties that may be desirable to both users and businesses.
  • a salient feature of the sharing technology is that the user is always in control of, and integral to, the sharing protocol.
  • the methods and systems described herein may be viewed as an operating system for the environment, the operating system being imbued with concerns addressing the privacy of user data.
  • data and heuristic knowledge inferred by computing entities and machines are encapsulated in forms that allow them to be treated as tradable units of commerce.
  • FIG. 1 shows a computing device controlling the exchange of data between two entities.
  • FIG. 2 illustrates the data exchange mechanism using cryptographic objects.
  • FIG. 3 shows one example of an operating environment in which aspects of the subject matter described herein may be practiced to generate and use
  • FIG. 4A is a functional block diagram illustrating the operation of a Key Generating Engine (KGE) that generates cryptographic keys and objects.
  • KGE Key Generating Engine
  • FIG. 4B is a functional block diagram illustrating the operation of a Proof Generating Engine (PGE) that generates a cryptographic proof.
  • PGE Proof Generating Engine
  • FIG. 4C is a functional block diagram illustrating the operation of a Proof Verifying Engine (PVE) that verifies the accuracy of the cryptographic credential.
  • PVE Proof Verifying Engine
  • FIG. 4D summaries the manner in which the KGE, PGE and VGE are used.
  • FIG. 5 A is a sequence diagram illustrating one example of the process of generating and verifying cryptographic authentication credentials and the exchange of messages containing logic, cryptographic keys and objects between a service provider, computing device, and a vendor with whom the computing device interacts.
  • FIG. 5B illustrates one example of the steps performed to authenticate a user using the cryptographic authentication credentials described herein.
  • FIG. 6 shows one example of an operating environment in which aspects of the subject matter described herein may be practiced to generate and use
  • FIG. 7 illustrates one example of the steps performed to create and use the cryptographic preference credentials described herein.
  • FIG. 8 illustrates an encoded object containing a user specified preference.
  • FIG. 9 illustrates a wallet app with cryptographic preference credentials.
  • FIG. 10 illustrates one category of cryptographic preference credentials that may be stored in a wallet app.
  • FIG. 11 illustrates an example of a cryptographic preference credential that may be stored in a wallet app.
  • FIG. 12 shows an example architecture for a device such as the computing device or any of the sub-units (e.g., the cryptographic credential issue, the storage system and the verifier) of the service provider described herein which are capable of executing the various components described herein for implementing aspects of the content dissemination techniques described herein.
  • a device such as the computing device or any of the sub-units (e.g., the cryptographic credential issue, the storage system and the verifier) of the service provider described herein which are capable of executing the various components described herein for implementing aspects of the content dissemination techniques described herein.
  • FIGs. 13A, 13B, 13C and 13D show illustrative components that are inputted to and outputted by KGE.
  • FIG. 14A and 14B show illustrative components that are inputted to and outputted by PGE.
  • FIG. 15 shows an illustrative working of the PVE.
  • smart programs a class of computer programs, i.e., smart programs
  • exemplary smart programs include programs referred to as Assistants, Voice-Activated Assistants, Robots, AI (Artificial Intelligence) programs, chatbots, and smart programs embedded in devices such as self-driving cars, mobile autonomous vehicles and robots, etc.
  • Assistants e.g., Voice-Activated Assistants
  • Robots e.g., Robots
  • AI Artificial Intelligence
  • chatbots e.g., chatbots, and smart programs embedded in devices such as self-driving cars, mobile autonomous vehicles and robots, etc.
  • smart programs embedded in devices such as self-driving cars, mobile autonomous vehicles and robots, etc.
  • voice-activated computer program that accepts input in spoken English from a user and responds in English, the responses including suggestions and recommendations.
  • such a program may recommend a recipe for a Chicken dish, even though the user's input to the program ("What is a good dish to cook today") may not have explicitly specified Chicken as an ingredient, i.e., the computer program infers that the user "likes" chicken.
  • the smart program may have access to historical user data collected over time by the entity that has created the smart program.
  • a third-party entity may provide the data under a business agreement to the latter entity. That is, we may imagine a process of data acquisition in which a first entity establishes a (possibly real-time) interface with a second entity by way of which a smart program may interface and request data from the latter entity.
  • chatbot is a smart computer program that "listens in” on an ongoing chat or instant messaging session between two users and interjects with suggestions.
  • chatbot "listening in” on this conversation, may interject and suggest a restaurant and offer to make a reservation.
  • smart computer programs or entities incorporating smart computer programs receiving data or preferences about a user need to ensure the integrity of the data, the authenticity of its occupants, etc.
  • a user of a smart car may not want the smart car software logic to get erroneous or malicious data from an external entity. For instance, it has been reported that computers installed in cars have been hijacked by hackers. A smart car whose software logic gets hacked may prove to be physically dangerous to its occupants.
  • the subject matter described herein is concerned with answering the question, how do we tell an entity such as a smart computer program or a device in which such a smart computer program is embedded who we are, what we like and how do we permit that entity to provide selected portions of our information to other entities?
  • biometric information has been used as credentials to authenticate a user to a service provider.
  • mobile or smart phones may use fingerprint data from a user to authenticate him to one or more websites.
  • smart phones keep the fingerprint data in a local memory of the smartphone itself and use a token that is recognized by participating service providers.
  • these service providers need to have software, called an "app", resident on the smart phone that accepts the token from (the operating system of) the smart phone and transmits it (or a representation) to the participating service provider.
  • apps software, called an "app” resident on the smart phone that accepts the token from (the operating system of) the smart phone and transmits it (or a representation) to the participating service provider.
  • Such a method begets a closed system of service providers, all participating in the acceptance of a common set of tokens (or representations of such generated by their apps).
  • a user can authenticate himself to his e.g., smart phone using his biometric data, the smart phone, in turn provides a token whose validity is then accepted by other service providers.
  • the user is permitted access to a participating service provider's system due to the service provider trusting the operating system of the smart phone.
  • the subject matter described herein allows the trust placed in a token from an enterprise to be replaced with a method, i.e., a sequence of steps or actions carried out by one or more (possibly distributed) computing entities manipulating cryptographic objects. Such a method can then be verified
  • the verification may thus be carried out in a device and platform independent manner.
  • independence is crucial in its security implications.
  • a trust model that relies on a single enterprise is inherently unsafe and susceptible to attack because it is a single point of failure.
  • different entities may check other entities and the method, as a whole, may continue to perform its functions even if some parts are under attack.
  • IP source and destination
  • telecommunications networks often use distributed computing entities to achieve desired levels of reliability.
  • data centers distribute their data in geographically separated entities.
  • two enterprises may enter bilateral business agreements to share user data and define one or more Application Programming Interfaces (API) to effectuate the data sharing.
  • API Application Programming Interfaces
  • Smart devices are being installed in many physical environments such as homes, restaurants and retail stores. Smart devices include devices containing one or more processors, one or more network interfaces and one or more sensors to sense environmental indicia from their surroundings. In some instances, smart devices may transmit or broadcast data to other devices in their environment. The goal is to create a computational component to "geography" by which a user may be provided services such as rendering a user's favorite music or playlist or controlling various aspects of the physical world, e.g., regulating temperature in a room.
  • FIG. 1 shows one example of an operating environment in which aspects of the subject matter described herein may be employed.
  • a user computing device 100 controls the data exchange between entities 200 and 300, the data pertaining to the user of the computing device 100, wherein the interfaces 201 and 301 may facilitate the control messages and the data itself may use the interface 101. In certain embodiments, the data may be relayed via the control interfaces also.
  • Illustrative examples of user computing device 100 includes, without limitation, mobile communication devices (e.g., cellular phones, smart phones), personal computers, laptops, tablet computers, personal digital assistants (PDAs) and devices and systems in which such user computing devices are embedded or otherwise incorporated.
  • mobile communication devices e.g., cellular phones, smart phones
  • PDAs personal digital assistants
  • control interfaces may be used to authenticate the user of the computing device 100, the latter may contain data that may be used in the authentication.
  • the computing device 100 may contain information that may be used to select and specify elements of the user data that can be shared between the two entities.
  • the entities 200 and 300 may be computer programs, websites, smart programs, robots, or other entities in which computer programs or the like may be embedded.
  • the interfaces 101, 201 and 301 may be wired or wireless technologies, with or without use of cloud computing resources, or other intermediary resources.
  • one aspect of the subject matter described herein involves the use of methods, i.e., sequences of steps carried out by one or more computing entities, that manipulate cryptographic (digital) objects.
  • the methods generally, result in producing cryptographic (digital) objects that can be verified using computational functions (software) in a device and platform independent manner.
  • the data contained within such cryptographic objects may relate to a user's biometric data, e.g., finger print data, or one or more of his preferences, e.g., user prefers classical music.
  • a cryptographic object containing a user's biometric data may be used to authenticate the user;
  • a cryptographic object containing a user's musical preference may be used to determine the type of music a user prefers.
  • cryptographic digital objects may be derived, using the methods discussed herein, which may authenticate a user or encapsulate his preferences. That is, such objects may be viewed as cryptographic credentials referring to his identity or his preferences.
  • FIG. 2 depicts the elements used by the user computing device to control the data sharing.
  • User computing device 100 acquires various cryptographic objects that may be interpreted using only methods described herein. The details of the acquisition process are given below.
  • the cryptographic credentials are encapsulated into physical objects called "authentication cards” or “preference cards”. Such cards may then be used much as conventional cards, e.g., credit/debit cards used in financial transactions, the purchase of goods, etc.
  • the data encapsulated in such cards allows manipulation and processing by the methods of the present invention.
  • cryptographic cards may be produced by a user utilizing his user computing device and one or more computer programs obtained from a third party.
  • the user also produces the necessary verification (software) tools. Users may then provide the verification tools to a third party that may be contacted by a vendor wishing to authenticate the user.
  • cryptographic cards may be produced by the user who may also (optionally) produce the necessary verification tools. It is thus seen that the technology described in the subject matter herein engenders new methods that are distinct from those used with conventional cards.
  • Certain conventional physical credit/debit cards now contain processor(s) and programmed circuitry. These may be used, as an example, by a vendor to verify a card that has been presented to it. The verification typically involves using a special device that activates the programmed circuitry in the card, which, in turn, may interact with one or more servers of the card issuing entity (or the point of sale terminal).
  • the present invention creates cryptographic credentials that in some cases are encapsulated in cards that may be used to verify the identity or preference of a user by any entity operating the methods of the present invention, not necessarily the card issuing entity.
  • the cryptographic credentials described herein may fall into one of two main categories distinguished by their most common, but not exclusive, use.
  • the first category is referred to as authentication cryptographic credentials (300, cf. FIG. 2) that may be used to authenticate a user.
  • authentication is described as the process by which a user establishes his identity.
  • the second category is referred to as preference (or authorization)
  • Prior art describes authorization as the process by which access rights to resources may be specified, viz., "to authorize” is to specify an access policy to resources.
  • authorization the process by which access rights to resources may be specified, viz., "to authorize” is to specify an access policy to resources.
  • authentication and authorization consider, by way of example, a user who logs in to a website by using his user name and password. This action may comprise user authentication. Having been authenticated, the website may enforce a policy by which the user may be granted access to certain data or based on the user's preferences. The latter action refers to authorization. Two different users who successfully authenticate themselves to the website may be granted entirely different data access policies based on their preferences.
  • authorization/preference credentials are based on either a user stated preference, e.g., John likes classical music, or based on analyzing user data. That is, an entity may analyze a user's data that leads it to conclude that the user likes classical music.
  • a cryptographic credential authorizing the sharing of user preferences referred to herein as a preference cryptographic credential, when presented to an entity, allows that entity to make use of the user preference data.
  • a preference cryptographic credential that includes a user's musical preferences may allow an entity to play background music in a geographical area that is consistent with the user's musical preferences as expressed by his preference credential.
  • a vendor may process a user's purchase data to infer or derive the user's likes.
  • the vendor in the above example, may process a user's music purchase data to infer that the user in question likes classical music.
  • Such inferences and derivations may use artificial and machine intelligence and heuristic techniques that are well- known in prior art.
  • a vendor that has made the effort to process user data to arrive at heuristic refinements pertaining to one or more users, may offer "preference credentials" and respond to requests from users or other computing entities for such credentials. For example, it may send out offers to various users that it is willing to provide them with music preference credentials.
  • a computer program may request a broker (another computer program) to provide it addresses of preference credential providers for given users. For example, consider a user who enters a smart home where a smart program, wishing to regulate the temperature of the house, requests the user's smart device to provide it a temperature preference credential. (We may assume the program controlling the temperature seeks authorized requests for its own record keeping requirements.) Assuming the user's smart device does not possess such a credential, it may, in turn, ask a broker to provide it the address of such a preference credential provider.
  • the user may be asked to state such a preference directly but we seek to automate such tasks to reduce the demand on users; moreover, in more complicated scenarios, users may not know what they prefer. For example, blind tests often reveal preferences that surprise users.)
  • the user's smart device may then present the received credential to the smart program controlling the temperature of the home.
  • the above described phenomenon may engender a new business model wherein heuristically acquired knowledge becomes an instrument of trade.
  • a networking environment may be envisaged in which computer programs engage in trading heuristically acquired knowledge. Note that such trading in heuristically acquired knowledge may require certain assurances, guarantees or estimates of accuracy and confidence so that trading parties may be protected and use the knowledge appropriately.
  • the trading in heuristically acquired knowledge is supported and facilitated by tools utilizing methods that operate on cryptographic objects and which preserve certain crucial properties such as data accuracy, data verification and user privacy.
  • FIG. 3 shows a general architecture of one example of an operating system
  • User computing device 100 may contain one or more processors, one or more network interfaces and one or more sensors to sense various environmental indicia such as Geo-Positioning Satellite (GPS) signals, temperature, motion, etc.
  • GPS Geo-Positioning Satellite
  • Examples of computing devices are smart phones, personal digital assistants (PDA), tablet computers, laptops, smart cars, autonomous mobile robots, etc.
  • Computer 175 is a conventional computer or server with one or more network interfaces. Examples of computers, without limitation, are desktop computers with one or more processing units, laptops, server machines, collections of computers, etc.
  • the fingerprint reader 150 is a physical unit that facilitates capture and processing of a user's fingerprint data and is assumed to be mostly conventional.
  • device 150 may be attached as a peripheral device to computer 175, while in other embodiments it may be integrated into 100 or 175.
  • computing device 100, fingerprint reader 150 and computer 175 may be integrated into a single computing device 1000. Modern smart phones represent one example of the integrated computing device 1000.
  • device 1000 we use the term "device 1000" to denote an integrated device as disclosed above or one or more of the various components 100, 150 and 175, relying on context to disambiguate the usage.
  • the fingerprint device 150 is one example of a device that facilitates capture and use of a user's biometric data.
  • user's biometric data such as retina scans, camera sensors that capture facial features, voice signature imprint, etc.
  • the use of the fingerprint biometric data in the present invention is purely exemplary and is not intended to limit the invention in any way.
  • the user's fingerprint data is captured by the fingerprint reader 150 and sent using computer 175 to the computing device 100.
  • the facial features of a user may be captured as data by a camera sensor and sent to the user computing device 100.
  • computing device 100 and computer 175 may use a Wi-Fi or Bluetooth radio connection to transmit and receive the fingerprint data.
  • devices 150, 175 and 100 may be arranged to enable computing device 100 to come into possession of the fingerprint or other biometric data of a user.
  • a service provider 2000 is a server complex, i.e., a collection of one or more servers, in network connection with device 1000 using wired or wireless technologies 101.
  • Device 1000 may use connection 101 to transmit requests and biometric data (fingerprint data for exemplary purposes) that has been suitably encoded and encrypted as discussed below.
  • Connection 101 may be further assumed to be made secure by using one of several well-known protocols such as secure http.
  • the service provider 2000 comprises sub-units that perform certain functions.
  • FIG. 3 shows the functional sub-units Card Issuer 200, Storage System 600, and Verifier 400.
  • the sub-units may represent individual enterprises.
  • the storage unit 600 uses a blockchain ledger system 250 (cf. FIG. 3) for storing and recording data and transactions.
  • the storage unit 600 may use conventional (distributed) database technology such as relational databases.) That is, the card issuer is assumed to use the blocks of a distributed ledger to access and store data. (As is well-known in prior art, new blocks may get added to the ledger and previous blocks may be accessed to retrieve historical records.)
  • FIG. 3 An example of the kind of data that is stored on the ledger is shown as 275 (cf. FIG. 3).
  • the card issuer 200 creates (as disclosed later) a cryptographic object called an encoded fingerprint record El (275, FIG. 3) corresponding to (and "associated" with, in a sense disclosed later) the fingerprint data of the user.
  • an encoded fingerprint record El 275, FIG. 3
  • Blockchain System 250 by Issuer 200 is proposed without limiting the present invention in any manner.
  • Network connections 101 and 201 are wired and/or wireless connections that may be used by device 1000 to request, send and receive data from the various components of the server complex 2000.
  • Network connection 301 is a wired and/or wireless connection that may be used by device 1000 to present data to a vendor 300.
  • vendor 300 may be a computer program, a robot, smart assistant, a chatbot, autonomous computing entity, a website, etc.
  • Network connection 401 is a wired or wireless connection that may be used by vendors to request verification of data from the verifier, 400.
  • proofs We will have occasion to use the term "proof in subsequent discussions. We now disclose the general method by which certain cryptographic objects, called “proofs”, are created from datasets, such as a user's fingerprint data.
  • KGE Key Generating Engine
  • PGE Proof Generating Engine
  • PVE Proof Verifying Engine
  • KGE (111, cf. FIG. 4 A) accepts as input a computer program (service logic L, 100) and a dataset 200 (e.g., user data such as biometric data e.g., fingerprint data). It produces two cryptographic keys, PK 300 and VK 400 called the proving key and the verifying key, respectively. It also produces an encoded object (EO) 500 based on the input dataset 200.
  • the EO may represent features extracted from the fingerprint data. Examples of such features may be the ridges and whorls detected in a user's fingerprint.
  • EO, PK and VK produced by the KGE are a function of the input dataset and the input software logic. Any changes to either the software logic or the input dataset engenders a different PK, VK and EO to be produced. Furthermore, the complementarity of PK and VK is dependent on the inputted dataset and software logic.
  • cryptographic key refers to digital data objects that satisfy the following properties.
  • the data comprising the keys, if rendered on a display screen may appear as a random sequence of binary (hexadecimal) digits.
  • PGE (222, FIG. 4B) accepts the encoded object EO 500 (produced by KGE as an output) and the proving key PK 300 (produced by KGE) and produces a cryptographic object called the proof, P (555) and a new dataset Data-2 550 that is a function of the input EO 500.
  • the object "P 555" satisfies the property that, if displayed, it appears as a random collection of (hexadecimal) digits.
  • PVE (333, FIG. 4C) accepts as input a verifying key, VK (400), produced by the KGE, a proof object P (555) produced by the PGE, and Data-2 (550) and outputs either “true” or "false". It produces the response "true” if and only if all the following conditions are true; otherwise it produces the response "false”.
  • KGE, PGE and PVE are to be viewed as a sequence of inter-connected operations.
  • a computer program (equivalently, service or software logic) 41 and dataset 31 are fed as input to KGE 51 that produces encoded dataset 81, PK 71 and VK 61 as output.
  • PK 71 and data 81 are fed as input to PGE 91.
  • PGE 91 produces a proof object 101 and encoded-dataset 82.
  • engines KGE, PGE and PVE may be freely available from one or more service providers as special software packages that can be downloaded and run on general purpose computers, computing devices, smart devices, etc.
  • a user's fingerprint data when captured by fingerprint sensors/scanners may be represented as a matrix of data, typically a 1000x1000 matrix (see, for example, "Using Chebyshev's inequality to determine sample size in Biometric evaluation of fingerprint data" by J. Chu et al., National Institute of Standards and Technology, Gaithersburg, Maryland).
  • a dataset with 9 samples i.e., a square 3x3 matrix as shown in FIG. 13 A.
  • user's facial data may also be captured as datasets; understandably, facial datasets are larger in size than fingerprint datasets.
  • FIG. 13 A shows the exemplary dataset for a fingerprint data of a user as a 3x3 matrix.
  • the cells of the matrix are numbered one through nine using roman numerals (i, ii, etc.); the cell values are shown as integers 37, 42, etc.
  • FIG. 13B we map each cell value and its position as a pair to one of the integers 1, 2 or 3 as shown. The pairs represent the cell number and the cell value, thus (i,37) means the sample value 37 in cell "i" of the matrix, etc.
  • the Sudoku Puzzle was chosen to be of order (i.e., dimensions) 3x3 and the input dataset was also assumed to be a matrix of order 3x3, this is merely coincidental.
  • the order of a Sudoku Puzzle is related to its computational intractability. Thus, engineers may wish to determine the order accordingly.
  • the data represented by FIG. 13 A and 13B will always be stored in the user computing device and not transmitted to any other entity.
  • Embodiments of the present invention will use the dataset represented by instances of the dataset shown in FIG. 13 C.
  • the private data of the user is always kept in the user computing device and, as such, is private; the credentials themselves that are generated and verified are based on (irreversible) representations of the private data.
  • KGE KGE
  • the engine KGE produces an encryption key representing the computer program "L” and a corresponding decryption key (FIG. 13D).
  • Prior art describes how encryption and decryption keys may be produced. We refer to the two keys as the proving and verifying keys, respectively. Note, that the encryption and decryption keys may be used to detect any changes to the logic "L" as is known in prior art.
  • FIG. 14A and 14B Taking the output dataset of FIG. 13C, we split it into two parts shown as FIG. 14A and 14B. Clearly, the two parts may be combined to yield the original dataset of FIG. 13C.
  • solving a Sudoku problem is "hard” for computer programs. For example, it has been estimated that a 9x9 Sudoku puzzle has tens of trillions of possible solutions (6,670,903,752,021,072,936,960).
  • the term "hard” is well-known in computer science as characterizing problems that are difficult to solve using computers because of the enormous number of possibilities (combinations) that need to be tried.
  • PGE may be described as an engine that takes as input a completed Sudoku, such as shown in FIG. 13C and a proving (encryption) key and produces as output two (split) pieces of the input Sudoku (as shown in FIG. 14A and 14B). Furthermore, PGE encapsulates one of the two split pieces along with the Sudoku constraints, viz., the sum of each row and column must be equal, in an encrypted object (using the encryption key) called the "proof and the second split piece of the Sudoku in the clear as a dataset "data-2".
  • FIG. 14A is the proof and FIG. 14B is the output dataset "data-2" of PGE.
  • PVE may be explained as an engine that takes as input a decryption (verifying) key, a proof object representing one encrypted piece of the Sudoku puzzle and its constraints, and a corresponding second piece of the Sudoku Puzzle.
  • the engine combines the two pieces of the Sudoku Puzzle and verifies its correctness with respect to the (decrypted) constraints in the proof object. If the constraints are satisfied, PVE outputs "true”; else it outputs "false”.
  • an entity that has the decryption key and the two pieces of the puzzle may combine them with a relatively small computational effort.
  • step 1 (computing) device requests a specific service logic (a computer program) from a service provider (cryptographic credential issuer unit).
  • step 2 the computing device receives the requested logic, LI, and the engines KGE and PGE. Steps 1 and 2 may be considered as comprising a service provisioning phase.
  • the computing device having received KGE and the logic LI may now utilize them to process the user's fingerprint data.
  • Prior art teaches that service logic may be constructed that processes fingerprint data to extract feature sets that may result in an encoded object (EO).
  • the computing device may possess PK1, VK1, the datasets EO-1 and EO-2, and a proof object PI .
  • the computing device may now send EO-2 to the service provider who provided it the logic LI, PGE and KGE and request it to act as a verifier as follows.
  • the computing device may now provide PI and VK to a vendor as its authentication credentials.
  • the vendor may transmit the PI and VK to the service provider (acting as a verifier) who may use it as input to PVE (we are assuming that the service provider possesses PVE -this is a reasonable assumption since it provided the associated KGE and PGE to the computing device in step 2 above), along with the previously received EO-2 and respond to the vendor's request positively or negatively depending on the output of PVE. (There is an additional aspect of this verification that we will discuss in more detail below.)
  • the computing device converts its fingerprint data to a group of cryptographic objects, namely, a proof object, an encoded dataset, a proving key and a verifying key.
  • a credential We may provide a service provider, referred to as a Verifier, the proving key. If we now present the credential object to a vendor, the latter may contact the Verifier and request it to verify the presented credential.
  • the Verifier may use the engine PVE with inputs comprising the credential and the verifying key to respond correspondingly.
  • the credential object may be formed by encapsulating the verifying key and the proof object, or by encapsulating the verifying key with the encoded object, etc. That is, different combinations of the three components (verifying key, encoded dataset, proof object) may be distributed between the computing device and the Verifier.
  • the user acquires from a service provider the systems KGE, PGE and software logic that processes biometric datasets.
  • the user inputs his biometric dataset and the software logic to KGE to produce a processed dataset and the keys PK and VK as per FIG. 4A.
  • the above processed dataset and PK are input to PGE to produce a proof object and an encoded dataset as per FIG. 4B.
  • the user possesses his proving key PK, his original biometric dataset, the processed dataset, the encoded dataset, verifying key VK and the proof object.
  • We may refer to the encoded dataset and the proof object taken together as the authentication credentials.
  • the user now sends the verifying key to a service provider (including possibly the one who provided him the KGE, PGE and software logic in the above steps) who may now act as a verifying authority, described as follows.
  • the user presents his authentication credentials to a vendor and the vendor may send them to be verified by the verifying authority.
  • the verifying authority obtains the PVE system in a, possibly a priori, out-of-band process from a service provider and uses it to verify the presented credentials and the previously received VK from the user as per FIG. 4C. If PVE responds positively (outputs true) to the input credentials (proof and the encoded dataset) and the received VK, the vendor is informed that the credentials are authenticated. If the PVE responds negatively (outputs false), the vendor is informed that the credentials are not valid, i.e., the vendor may decline to accept the presented credentials.
  • a user may receive software logic, the KGE and PGE systems and use them with his biometric dataset to produce a set of authentication credentials and a verifying mechanism that can be utilized to verify the credentials by one or more third party entities.
  • the trust model in the verification entails that the KGE, PGE and PVE systems are deemed cryptographically secure.
  • the service provider may comprise multiple sub-units (Credential Issuer 200, Storage System 600, Verifier 400) or the sub-units may be independent business entities.
  • the units processing and storing the objects distributed by the user computing device and performing the verification functions may need internal record keeping for information received and requests verified. Therefore, the need arises to explain the internal working of the various units of the service provider entity 2000 (cf. FIG. 3).
  • the service provider may not have any of the sub- units described herein and thus there may only be a single set of keys PK, VK and a single cryptographic proof.
  • step 3 the proof object PI, dataset EO-2, and verifying key VKl are packaged into a request to the credential issuer for a new credential.
  • the credential issuer unit processes the received request.
  • the issuer may also use the engines KGE and PGE because it may wish to use modified service logic L2 that is different from LI, i.e., the logic that was provided to the requesting computing device.
  • modified service logic L2 is different from LI, i.e., the logic that was provided to the requesting computing device.
  • An example of the need to use such modified logic is that the issuer may wish to record the time and date of receipt of the request for the credential as a part of the received encoded dataset EO-2, thereby producing an "augmented dataset EO-2".
  • step 4 proof P2, encoded dataset EO-3, and VK2 are sent to the Storage system, which may augment the received dataset EO-2, by adding local data such as time/date of request to get "augmented EO-3". Additionally, the storage system may use its own version of logic, L3, and provide L3 and "augmented EO-3" to KGE and PGE respectively to get PK3, VK3, EO-4 and proof P3.
  • step 5 the key VK3 is sent to the verifying unit.
  • step 6 the proof P3 and encoded dataset EO-4 are encapsulated into an object called a "credential" and sent to the requesting (user) computing device. The credential is now deemed ready for use by the (user) computing device.
  • steps 5 and 6 may use different combinations of the three components— proof object, verifying key and encoded object— and distribute the same amongst the computing device and the Verifier.
  • proof object verifying key and encoded object
  • step 7 the device may present the credential to a vendor.
  • step 6 the credential is ready to be used by the computing device.
  • step 7 the computing device initiates the process of using the credential.
  • a malicious entity may intervene between steps 6 and 7, gain access to the credential, and present it maliciously to a vendor.
  • steps 6 and 7 be implemented as "atomic" operations.
  • Prior art teaches the combining of one or more operations into a single "indivisible" unit such that either all or none of the individual components of the unit are executed.
  • storage system 600, cf. FIG. 3
  • atomic operations comprise basic and fundamental operations in storage systems such as databases and block-chain systems.
  • step 8 the vendor forwards the presented credential to the verifier unit.
  • the presented credential contains the proof P3 and the dataset EO-4.
  • step 9 the verifier verifies the credential using P3, EO-4 and previously received VK3 as input to the engine PVE, obtaining a true/false output and responds to vendor accordingly.
  • the credential received by the computing device may be stored and used later by the computing device.
  • an app such as a wallet app may be used to store the credential and later present it to a vendor for authentication.
  • Modified steps 6 and 7 of the alternative embodiment are presented below (all other steps of the previous embodiment remain unchanged).
  • step 6 Credential is received and stored by computing device (e.g., in a wallet app).
  • step 7 We assume the user computing device has acquired software, say "S”, in a provisioning step that allows it to compute and compare (match) feature recognition sets from fingerprint data. Next, in a
  • the user computing device uses “S” to derive a fingerprint dataset of the user referred to as dataset "Dl”.
  • step 7 user initiates a process on his computing device to present his credential to a vendor.
  • the computing device requests the user to provide a new set of fingerprint data and, uses the logic "S” to derive a new fingerprint dataset "D2" from the user.
  • the software "S” matches the datasets "Dl” and "D2" and upon successful match, the user computing device may proceed to present the user's stored credentials to the vendor. If the two datasets Dl and D2 do not match, the computing device may not allow the credential to be presented to the vendor.
  • FIG. 5B summarizes the above method of FIG. 5 A.
  • a computing device creates a fingerprint dataset of a user and requests service provider for KGE, PGE and logic LI .
  • step 1 having received KGE, PGE and LI from a service provider, the computing device provides KGE with the logic LI and its fingerprint dataset as inputs to produce a new dataset EO-1 and the keys PK1 and VK1.
  • the computing device uses EO-1, PK1 and VK1 as input to PGE, the computing device produces a proof object PI and encoded dataset EO-2.
  • Computing device sends PI, VK1 and EO-2 to the service provider.
  • the service provider receives PI, VK1 and EO-2. It may add local data to EO-2. It may also use its own (proprietary) version of service logic, L2, different from LI provided to the computing device.
  • L2 and (modified) EO-2 as inputs to KGE produce PK2, VK2 and EO-3. The latter three components are provided as input to PGE to generate the proof object P2 and the encoded dataset EO-3. Proof P2, EO-3 and VK2 are sent to the storage system.
  • step 3 the storage system may add local data to Data-2 to get a modified dataset. It may also use its own version of logic, L3. Using L3 and the modified dataset as input to KGE, it produces PK3, VK3 and EO-4. The latter three
  • the storage system encapsulates P3 and EO-4 into an object called a credential and sends it to the requesting user. It may then send VK3 to the Verifier.
  • the computing device receives the requested credential and in step 5 presents it to a vendor. The steps numbered 4 and 5 are executed atomically.
  • step 6 the vendor requests the verifier to verify the presented credential that uses PVE to respond accordingly in step 7.
  • Alternative embodiments discussed above may package and distribute the three components— proving key, verifying key and proof object— in various combinations between the device and the verifier.
  • the computing device stores the requested credential for later use
  • the use of atomicity in steps 4 and 5 is obviated.
  • the credentials so obtained may be stored in one or more applications, e.g. a wallet app.
  • the stored credentials may then be presented to a vendor based on following the methods provided by the wallet app.
  • the app may request the user to authenticate himself to the app before the app may present a credential to a vendor.
  • a system may glean a user's preferences in many ways. Two such avenues are as follows.
  • the user states his preference to the system, e.g., John states that he likes classical music.
  • a system in possession of user data, analyzes the data to derive or infer the preferences of a user. For example, a user's purchase history at an online bookstore may indicate the types of books he likes. The system may then use the derived preferences or may share them with another computer program.
  • a user entering a smart home may desire the temperature to be set to his preference by a smart temperature controlling thermostat, for the lights to be turned off (or on) in certain rooms by a smart light actuator, etc.
  • no single computer program may possess all the user data that it needs to provide services to the user. As described above, the situation may become particularly acute for smart programs. A user entering a rented smart car or other vehicle may wish the car to acquire his preferences from a smart car that he owns (or the manufacturer's computer system) that knows his preferences. A user entering a retail store may wish to hear his preferred music in the background while he is shopping.
  • the smart device that receives a user's preference (from the user or a service provider), it may also wish to record the receipt of the preference. It may wish to ascertain that the user is authenticated. For example, a smart car may wish to ensure that the occupant of the car is the same person who rented the car. Thus, from the smart device's perspective, the user may need to be authenticated and his preferences may need to be authorized.
  • the present invention proposes a data sharing paradigm between computers that requires that the sharing between the respective computer programs be mediated by the user, e.g., his computing device (cf. FIG. 1).
  • a user's preferences may be encapsulated as cryptographic preference credentials, along lines similar to the above described authentication credentials. Whereas the latter were based on biometric data of the user, the former may be based on a user's statement or directive; they may also be based on user data such as a user's purchase history.
  • FIG. 6 shows the general system architecture for generating and verifying preference credentials.
  • the system architecture is similar to the architecture shown in FIG. 3. We highlight the differences below.
  • computing device 100 may contain or be in direct connection with components that are capable of capturing a user's biometric data. The computing device may then subsequently be assumed to have acquired authentication credentials. That is, the computing device 100 in FIG. 6 acts according to the arrangement shown as device 1000 in FIG. 3. • In an alternative embodiment, the computing device 100 FIG. 6 may not possess authentication credentials.
  • Preference provider 99 is a service provider in possession of user data who may have processed it to derive one or more user preferences.
  • preference provider 99 may be a vendor who has acquired purchase data of various users over time whose user preferences may then be inferred.
  • Provider 99 may advertise his willingness to provide such derived preferences in response to user requests.
  • Broker 29 is a computer program that provides network addresses of
  • FIG. 7 shows the general method of creating preference credentials and their verification. The method is similar to FIG. 5B. We highlight the differences below.
  • step 1 the data provider possessing user data may process it to create heuristic knowledge about the user.
  • the data provider offers (preference) credentials to prospective users.
  • Step 2 (FIG. 7) discusses three possible embodiments.
  • the user states preferences to the computing device and the preferences may be encapsulated as a dataset and used by the computing device to generate the preference credentials.
  • the computing device requests a preference provider to provide it user preferences. Again, the computing device may encapsulate the provided preference data as a dataset to be used to generate preference credentials.
  • the computing device may request an entity called the broker to provide it a network address of a preference provider who may provide it user preferences. It uses the provided address to request the preference provider for the user's preference data and encapsulates it as a dataset to be used to create preference credentials.
  • step 3 the computing device requests and receives logic LI, KGE and PGE. As described above, these may be used, along with the user preference dataset as input, to produce EO-2, PK1, VK1 and PI . That is, step 3 of FIG. 7 is identical to step 1 of FIG. 5B except that the input dataset is the user's preference data and not the user's biometric data.
  • the unencrypted user preference data may be incorporated into the preference credential in any of a number of ways that in part may depend on the party that is creating the preference credential. For instance, in one embodiment, if the user computing device generates the preference credential, the user computing device itself may add the user preference data to the preference credential as follows.
  • the logic LI then takes the user stated preference as input and encapsulates it in the output dataset.
  • the input to LI comprises the user stated preference only, i.e., there is no other user data.
  • the logic LI may be configured in such cases to produce a "default" Sudoku Puzzle of a certain order.
  • the encoded dataset outputted by KGE was a Sudoku puzzle shown in FIG. 13C.
  • FIG. 8 the default Sudoku Puzzle is a 3x3 puzzle on the integers 1, 2 and 3.
  • the added "special" cell with its user stated preference as cell value does not alter the working of the Sudoku puzzle or the methods based on the puzzle.
  • a service provider encodes a user's previous historical usage dataset and provides it as input to the software logic "LI" (using a predetermined format) that is configured to process it and produce a corresponding Sudoku Puzzle as explained above.
  • the logic LI may be further configured to obtain input from the user.
  • the main difference between a preference credential and an authentication credential lies in the underlying data used as a basis for generating the respective credentials and whether that underlying data is incorporated in the clear as part of that credential.
  • the dataset comprises user (historical) data (or user stated preference) whereas in the case of the
  • the dataset comprises user's biometric data. Moreover, in the case of the preference credential the preference data is incorporated into the credential whereas in the case of the authentication credential, user data is not incorporated into the credential.
  • chatbots that "listen in" to on-going chats and their service logic may make contextual suggestions, such as restaurant recommendations.
  • the chatbot is configured to make restaurant suggestions to the user based on the context of the on-going chat session.
  • the chatbot is configured to obtain restaurant choices from a third-party website such as Open Table.
  • Open Table a third-party website
  • the chatbot decides to make a restaurant recommendation. Hence, it needs to ask Open Table to tell it a restaurant that the user may like.
  • the chatbot session needs to authenticate the user to Open Table and present a restaurant preference credential to it to obtain the name and address of a restaurant. The following sequence of steps may be undertaken.
  • the chatbot requests the user computing device for an authentication
  • the user computing device acquires and presents an authentication credential as described above (cf. FIG. 5A).
  • the chatbot presents the authentication credential to Open Table who may request third-party verification. Having received a positive acknowledgement, Open Table informs the chatbot that the user has been authenticated.
  • the chatbot now requests the user computing device for a restaurant
  • the computing device may possess such a preference credential in which case it may present it.
  • the computing device may request a new preference credential (cf. FIG. 6 and 7).
  • the chatbot presents the preference credential to Open Table.
  • Open Table requests and receives verification of the preference credential. It replies accordingly to the chatbot.
  • temperature preference credential ii.
  • the computing device contacts a broker to locate the address of a provider of preference credentials. It then requests the preference provider for a credential (cf. FIG. 7) and presents the resulting credential to Rl .
  • the preference provider may anticipate the user requests and may place a user's preference dataset on the blockchain, a priori, to receiving user requests for preference credentials.
  • Customization of services and computer controlled devices and environments A user enters a home whose temperature is controlled by a smart thermostatic device (containing specialized software logic). The computing device of the user is queried by the smart thermostatic device and obtains the user's relevant credentials
  • a user enters a smart car whose music system is controlled by a device (containing specialized software logic).
  • the computing device of the user is controlled by a device (containing specialized software logic).
  • the preferential credentials may be stored in a physical device much like a credit card that may then be physically presented to a vendor by the user who may then use a Point of Sale (POS) terminal to accept the presented card.
  • the credential may be stored in an application of the user computing device, e.g., a wallet app, and rendered on a display of the computing device of the user from whence it may be scanned by a POS terminal, etc.
  • Near field communications and other practices known in prior art may be used to present the credential to a vendor who may then use many previously known methods and technologies to transmit the presented credential for verification.
  • the age-related preference credential may be encapsulated in a physical card or in an app such as a wallet app where it may be rendered on the user's display device.
  • the user may now present the credential as a physical card to a vendor who may verify it as above using special verification-supporting POS terminals.
  • the vendor may be presented the rendering of the credential on the user's display device. Note that the advantage to the user is that the only information he provides to the vendor is that his age is greater than 21 and there is no need for him to reveal any other personal data such as his name or date of birth.
  • FIG. 9-11 show exemplary implementations of a wallet app.
  • FIG. 9 shows the wallet app having different categories of credentials.
  • FIG. 10 shows an expanded list of preference credentials rendered in the wallet app of the user's computing device.
  • FIG. 10 shows a rendering of one credential, viz., the "Spotify Category Chopin" credential.
  • the cryptographic data of the credential is represented as the sequence of hexadecimal digits [0,1, A-F] and also as the QR code that may be scanned.
  • FIG. 12 shows an example architecture 800 for a device such as the computing device or any of the sub-units (e.g., the cryptographic credential issue, the storage system and the verifier) of the service provider described herein which are capable of executing the various components described herein for implementing aspects of the content dissemination techniques described herein.
  • the architecture 800 illustrated in FIG. 12 shows an architecture that may be adapted for a server computer, server complex, mobile phone, a PDA, a smartphone, a desktop computer, a netbook computer, a tablet computer, GPS device, gaming console, and/or a laptop computer.
  • the architecture 800 may be utilized to execute any aspect of the components presented herein.
  • the architecture 800 illustrated in FIG.12 includes a CPU (Central Processing Unit) 802, a system memory 804, including a RAM 806 and a ROM 808, and a system bus 810 that couples the memory 804 to the CPU 802.
  • the architecture 800 further includes a mass storage device 812 for storing software code or other computer-executed code that is utilized to implement applications, the file system, and the operating system.
  • the mass storage device 812 is connected to the CPU 802 through a mass storage controller (not shown) connected to the bus 810.
  • the mass storage device 812 and its associated computer-readable storage media provide non-volatile storage for the architecture 800.
  • computer-readable storage media can be any available storage media that can be accessed by the architecture 800.
  • computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data.
  • computer-readable media includes, but is not limited to, RAM, ROM, EPROM (erasable programmable read only memory, ) , EEPROM (electrically erasable programmable read only memory, ) , Flash memory or other solid state memory technology, CD-ROM, DVDs, FID-DVD (High Definition DVD), Blu-ray, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the architecture 800.
  • the architecture 800 may operate in a networked environment using logical connections to remote computers through a network.
  • the architecture 800 may connect to the network through a network interface unit 816 connected to the bus 810. It should be appreciated that the network interface unit 816 also may be utilized to connect to other types of networks and remote computer systems.
  • the architecture 800 also may include an input/output controller 818 for receiving and processing input from a number of other devices, including a keyboard, mouse, or electronic stylus (not shown in FIG. 12). Similarly, the input/output controller 818 may provide output to a display screen, a printer, or other type of output device (also not shown in FIG. 12).
  • the software components described herein may, when loaded into the CPU 802 and executed, transform the CPU 802 and the overall architecture 800 from a general -purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein.
  • the CPU 802 may be constructed from any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the CPU 802 may operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the CPU 802 by specifying how the CPU 802 transitions between states, thereby transforming the transistors or other discrete hardware elements constituting the CPU 802.
  • Encoding the software modules presented herein also may transform the physical structure of the computer-readable storage media presented herein.
  • the specific transformation of physical structure may depend on various factors, in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable storage media, whether the computer-readable storage media is characterized as primary or secondary storage, and the like.
  • the computer-readable storage media is implemented as semiconductor-based memory
  • the software disclosed herein may be encoded on the computer-readable storage media by transforming the physical state of the semiconductor memory.
  • the software may transform the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory.
  • the software also may transform the physical state of such components in order to store data thereupon.
  • the computer-readable storage media disclosed herein may be implemented using magnetic or optical technology.
  • the software presented herein may transform the physical state of magnetic or optical media, when the software is encoded therein. These transformations may include altering the magnetic characteristics of particular locations within given magnetic media. These transformations also may include altering the physical features or characteristics of particular locations within given optical media to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne des systèmes et des procédés qui permettent à des programmes informatiques ou à d'autres entités de partager des données et des informations d'utilisateurs de telle façon que les utilisateurs puissent être authentifiés et que leurs préférences puissent être partagées entre des entités dans des environnements et machines mis en réseau. Des justificatifs cryptographiques sont générés à ces fins. Bien que les justificatifs puissent être partagés pour fournir des données d'authentification et de préférences d'utilisateurs à des entités, une caractéristique remarquable de la technologie de partage est que l'utilisateur conserve toujours la maîtrise du protocole de partage, et en fait partie intégrante. En outre, le partage préserve la confidentialité des données des utilisateurs.
PCT/US2018/015696 2017-01-27 2018-01-29 Système et procédés de partage et d'échange de données et de préférences d'utilisateurs entre des programmes informatiques et d'autres entités tout en préservant la confidentialité des utilisateurs WO2018140860A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762451253P 2017-01-27 2017-01-27
US62/451,253 2017-01-27

Publications (1)

Publication Number Publication Date
WO2018140860A1 true WO2018140860A1 (fr) 2018-08-02

Family

ID=62979584

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/015696 WO2018140860A1 (fr) 2017-01-27 2018-01-29 Système et procédés de partage et d'échange de données et de préférences d'utilisateurs entre des programmes informatiques et d'autres entités tout en préservant la confidentialité des utilisateurs

Country Status (1)

Country Link
WO (1) WO2018140860A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020186838A1 (en) * 2001-03-09 2002-12-12 Pascal Brandys System and method of user and data verification
US20050114662A1 (en) * 2001-03-12 2005-05-26 Bernd Meyer Method for authentication
US20120324231A1 (en) * 2008-08-28 2012-12-20 International Business Machines Corporation Attributes in cryptographic credentials
US20150372814A1 (en) * 2014-06-20 2015-12-24 Gemalto Inc. Method to manage modification of encryption credentials
WO2016083618A1 (fr) * 2014-11-28 2016-06-02 Katholieke Universiteit Leuven Procédé et dispositif d'authentification

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020186838A1 (en) * 2001-03-09 2002-12-12 Pascal Brandys System and method of user and data verification
US20050114662A1 (en) * 2001-03-12 2005-05-26 Bernd Meyer Method for authentication
US20120324231A1 (en) * 2008-08-28 2012-12-20 International Business Machines Corporation Attributes in cryptographic credentials
US20150372814A1 (en) * 2014-06-20 2015-12-24 Gemalto Inc. Method to manage modification of encryption credentials
WO2016083618A1 (fr) * 2014-11-28 2016-06-02 Katholieke Universiteit Leuven Procédé et dispositif d'authentification

Similar Documents

Publication Publication Date Title
US10320781B2 (en) System and methods for sharing and trading user data and preferences between computer programs and other entities while preserving user privacy
US10735407B2 (en) System and method for temporary password management
KR102624700B1 (ko) IoT 장치와 애플리케이션 간의 생체 식별 및 검증
US11271926B2 (en) System and method for temporary password management
US11388174B2 (en) System and method for securing a communication channel
US9491155B1 (en) Account generation based on external credentials
US11539526B2 (en) Method and apparatus for managing user authentication in a blockchain network
US20170374046A1 (en) Short range secure data communication
US20230033192A1 (en) Data management systems and methods
US20170372310A1 (en) Secure key based trust chain among user devices
CN110768968A (zh) 基于可验证声明的授权方法、装置、设备及系统
CN106664291A (zh) 用于对本地网络设备提供安全访问的系统和方法
US20190268319A1 (en) Authentication and Approval Control System for Distributed Ledger Platform
US11824850B2 (en) Systems and methods for securing login access
Ghaffari et al. Identity and access management using distributed ledger technology: A survey
CN106296154B (zh) 事务处理方法和系统
Arias-Cabarcos et al. Blended identity: Pervasive idm for continuous authentication
US10313339B1 (en) Secure activation of authentication devices based on communications received via designated communication channels
KR20190114182A (ko) 경력 정보를 인증하는 방법, 경력 정보 인증을 수행하는 서버 및 컴퓨터 프로그램
US20190354659A1 (en) Authentication of users based on snapshots thereof taken in corresponding acquisition conditions
Shakshuki et al. An agent-based approach to security service
JP6622900B2 (ja) デバイス通知を介した多要素認証クレデンシャルの提供
WO2018140860A1 (fr) Système et procédés de partage et d'échange de données et de préférences d'utilisateurs entre des programmes informatiques et d'autres entités tout en préservant la confidentialité des utilisateurs
US20240022561A1 (en) Accessing a virtual sub-environment in a virtual environment
US20240005011A1 (en) Data security in virtual-world systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18744239

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 25/10/2019)

122 Ep: pct application non-entry in european phase

Ref document number: 18744239

Country of ref document: EP

Kind code of ref document: A1