Portable access point for secure user information using blockchain-backed authentication credentials

Abstract

The embodiment allows restricted access to a user's secure information using blockchain-backed credentials. Users can register with a secure information manager and control the scope to which their secure information is shared. For example, a user can allow an authorized entity to access their secure information via a portable access point. Users can select scope definitions that control how their secure information is shared with authorized entities. Authorized entities can scan the user's portable access point and request credentials. The credentials can be blockchain-backed credentials that are assigned access privileges corresponding to the user's selection. Authorized entities can then use the credentials to issue data access requests. The secure information manager can grant authorized entities restricted access to a user's secure information corresponding to the access privileges assigned to the credentials.

Description

Technical Field

[0001] Field Embodiments of the present disclosure generally relate to a secure storage system that permits limited access to a user's secure information using authentication information backed by a blockchain.

Background Art

[0002] Background The rapid increase in connected computing devices has generated a vast amount of data that requires management. As the size of data grows, the technical challenges associated with efficiently managing data are becoming increasingly complex. For example, sharing secure data among multiple parties has been an age-old problem in the field of data management. Security techniques that enable users to manage secure information, such as authentication, verification, and authorization workflows, can be cumbersome and, in some situations, may be difficult to implement. A security protocol that achieves practical secure data sharing in situations that cause friction with conventional data sharing protocols can provide considerable value.

Summary of the Invention

[0003] Summary Embodiments of this disclosure generally relate to a system and method for granting a user restricted access to secure information using authentication of credentials and verification of user information. An authentication request for one or more credentials that grants access to a user's secure information may be received in a secure information manager from a requesting system, the authentication request including user identification information, entity identification information, and a scope definition, and the requesting system generates the authentication request in response to scanning the user's portable access point. The user identification information and entity identification information may be verified in the secure information manager. Blockchain credentials with access privileges corresponding to the scope definition may be assigned to an entity in response to verification, and the blockchain credentials assignment is recorded on a private blockchain managing blockchain credentials. In response to one or more access requests from an entity containing the assigned blockchain credentials, access to the user's secure information may be granted, restricted to the access privileges of the blockchain credentials.

[0004] Features and advantages of the embodiments are described in the following description, or become apparent from the description, or can be learned by practicing the present disclosure.

[0005] Further embodiments, details, advantages, and modifications will become apparent from the following detailed description of preferred embodiments, which are taken into account in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0006] [Figure 1] This figure shows a system for granting limited access to a user's secure information using a non-fungible token according to an exemplary embodiment. [Figure 2] This is a block diagram of computing devices operably coupled to a predictive system according to an exemplary embodiment. [Figure 3]This figure shows a system for registering users for secure information management according to an exemplary embodiment. [Figure 4A] This figure shows a system having a secure information manager that allows limited access to a user's secure information using blockchain authentication information according to an exemplary embodiment. [Figure 4B] This figure shows a system having a secure information manager that allows limited access to a user's secure information using blockchain authentication information according to an exemplary embodiment. [Figure 4C] This figure shows a system having a secure information manager that allows limited access to a user's secure information using blockchain authentication information according to an exemplary embodiment. [Figure 5] This figure shows a portable access point according to an exemplary embodiment. [Figure 6] This flowchart illustrates how to allow limited access to a user's secure information using user authentication information authentication and user verification according to an exemplary embodiment. [Figure 7] This is a flowchart for defining access restrictions for sharing user-secure information according to an exemplary embodiment. [Figure 8] This flowchart illustrates an exemplary embodiment for retrieving scope-limited user information from a secure data store and logging access. [Modes for carrying out the invention]

[0007] Detailed explanation The embodiment allows restricted access to a user's secure information using blockchain-backed credentials. Users can register with a secure information manager and control the scope to which their secure information is shared. For example, a user can allow authorized entities (e.g., service providers, healthcare providers, other individuals) to access their secure information via a portable access point. Users can select scope definitions that control how their secure information is shared with authorized entities. Authorized entities can scan the user's portable access point and request credentials to grant access to the user's secure information through the scan. For example, the credentials can be blockchain-backed credentials that are assigned access privileges corresponding to the user's selection.

[0008] Subsequently, the authorized entity can issue one or more data access requests using the credentials. For example, data access requests can be authenticated and verified by the Secure Information Manager. The Secure Information Manager can grant the authorized entity limited access to the user's secure information corresponding to the access privileges assigned to the credentials (based on the authenticated and verified data access requests). The user can revoke the credentials and / or the access privileges assigned to the authorized entity at any time. The access privileges assigned to the credentials may include an expiration timer, after which the credentials are no longer authenticated by the Secure Information Manager.

[0009] The embodiments achieve efficient and secure, granular user-controlled access to a user's secure information. For example, a user's portable access point is configured to efficiently define the conditions for sharing the user's secure information. In addition, issued credentials and a secure information manager enforce the user's sharing conditions in a trusted manner. In embodiments where credentials are blockchain-backed, blockchain-based management ensures that the credentials are authentic and mitigates fraudulent attempts to access the user's secure information.

[0010] Blockchain-backed credentials can be issued to certified entities. For example, certified entities can be individuals, organizations, or groups of individuals. Certified entities can undergo a certification workflow, after which they can receive credentials to access users' secure information. The certification workflow can include one or more of the following: identity verification, credential verification (e.g., government credentials, medical credentials, financial advisor credentials), cybersecurity verification, and any other appropriate certifications. Certified entities can generate credential requests seeking access to users' secure information by scanning users' portable access points (via computing systems and scanning components).

[0011] A portable access point can be a visual access point that, when scanned, can grant access to a user's secure information (e.g., stored and managed via a secure information manager). For example, a visual access point may include a user's visual representation (e.g., a facial image) linked to a portable access point, which encodes information related to the user's secure information and / or the scope of permitted access.

[0012] Users can configure portable access points and the encoded information they display. For example, a portable access point can be displayed via an application running on a user's wireless device (e.g., a smartphone, tablet, etc.), and the user can interact with the application and select the scope of sharing their secure information. Embodiments of the portable access point are dynamic such that user selections via the application generate different versions of the portable access point with different encoded information displays. For example, a user can define a sharing scope that identifies data points of their secure information that can be shared with authorized entities via scanning the portable access point. The user can also define a sharing scope of time periods during which their secure information can be shared with authorized entities via scanning the portable access point.

[0013] One or more traversal elements of an authorized entity can traverse a portable access point and use information from the portable access point to generate a credential request. For example, a credential request may include one or more entity credentials, user identification information, a scope definition defining access privileges for the requested credentials regarding the user's secure information, and / or credential types. Entity credentials may include credentials issued to an entity after the entity has been authorized by an authorization workflow (e.g., issued to one or more users and / or identities associated with the entity). Exemplary entity credentials may include an access token (e.g., Security Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys, or a signature. The Secure Information Manager can authenticate the entity credentials provided in the request before issuing access credentials to the authorized entity.

[0014] Authentication information requests may also include user identification information. Exemplary user identification information may include one or more of the following: user data that identifies the user (e.g., full name, date of birth, city, state, and / or zip code, physical appearance, etc.), images of government-issued documents that identify the user (e.g., driver's license, passport, etc.), biometric information (e.g., fingerprints, eye scans, DNA information, etc.), and other appropriate identifying information of the user.

[0015] An embodiment of user secure information can be electronic health data segmented based on parameters, and scope definitions defining access privileges to requested authentication information relating to the user's secure information can correspond to restricted portions of the user's electronic health data. For example, parameters may include the issuing physician and / or healthcare institution (e.g., entity identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), date and time of information generation, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. By providing scope-defining parameter values, users can define which portions of their electronic health data are shared via their portable access point.

[0016] A secure information manager can verify and authenticate authentication requests and retrieve authentication information from a blockchain service in response to the request. For example, the secure information manager can send the retrieved authentication information to the computing system of an authorized entity. The authentication information can be an NFT managed by a blockchain service, and the computing system of the authorized entity can include a token wallet belonging to the authorized entity that stores the NFT. In other examples, the authentication information can be any other suitable blockchain-based authentication information and can be stored in any suitable storage location by the computing system of the authorized entity. Exemplary blockchain-backed authentication information can include access tokens managed via the blockchain (e.g., Security Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys managed via the blockchain, etc.

[0017] After authentication credentials are issued to an authorized entity, the authorized entity's computing system can use the credentials to issue data access requests. For example, a data access request containing the issued credentials, the identifier of the authorized entity that issued the request, and user identification information can be sent to a secure information manager. The secure information manager can verify and authenticate the data access request, retrieve scope-limited secure user information in response to the data access request, and return the scope-limited secure user information to the authorized entity's computing system.

[0018] A data access request can define one or more data points of a user's secure information. For example, the user's secure information can be electronic health data segmented based on parameters. The data access request can include specific parameter values that define the range of the requested user's secure information. The secure information manager can retrieve the secure user information corresponding to the requested data points included in the data access request. For example, the secure information manager can retrieve the secure user information corresponding to a portion of the requested data points included in the data access request. When the data access request includes user data points outside the scope of privileges of the set of authenticated entity / provided authentication information, the secure information manager can retrieve only the portion of the user data points covered by the set of scope privileges.

[0019] An authenticated entity can include any suitable entity that performs services for a user, such as home services (e.g., home construction, repair, etc.), automotive services (e.g., repair of the user's vehicle), medical services (e.g., medical services related to a doctor's clinic, hospital, emergency treatment room, first responders, etc.), financial services (e.g., accounting, trust services, financial advice, etc.), technology services (e.g., system administrator services, web hosting, etc.). In one example, the user's secure information can be an electronic health record, and the authenticated entity can be a healthcare provider that requests access to the user's electronic health record. In this example, the healthcare provider can scan the user's portable access point (e.g., via the user's wireless device) and request authentication information from the secure information manager and the blockchain service. When the authentication information request from the healthcare provider is authenticated and verified, the blockchain service can issue to the healthcare provider the authentication information that provides the authenticated entity with a restricted-range access to the user's electronic health record.

[0020] The user can define the type of authentication information to be issued to a healthcare provider via the user's application running on the user's wireless device. For example, the user can select one of the first authentication information (e.g., ephemeral authentication information), the second authentication information (e.g., episodic authentication information), and / or the third authentication information (e.g., persistent authentication information), and the application can display the version of the user's portable access point in response to the selection. The version of the user's portable access point can encode the type of authentication information selected by the user for the healthcare provider. The healthcare provider can scan the portable access point and issue an authentication information request, where the authentication information request includes the type of authentication information selected by the user for the healthcare provider.

[0021] The user can also define the access privileges for the authentication information requested via scanning of the portable access point using the application. For example, the user can select a secure user information data point, a segment of the data point, a parameter value used to group the data points, or any other suitable definition for dividing the user's secure information. The version of the user's portable access point can encode the access privileges for the authentication information defined by the user for the healthcare provider. The healthcare provider can scan the portable access point and issue an authentication information request, where the authentication information request includes the access privileges defined by the user for the healthcare provider.

[0022] The blockchain service and / or secure information manager can then issue blockchain-backed credentials to the healthcare provider, corresponding to the user-selected credential type and / or including user-defined access privileges. Upon receiving the issued credentials, the healthcare provider's computing system can issue a data access request to the secure information manager to access the user's electronic health records. To grant access, the secure information manager can authenticate the credentials via a smart contract call to the blockchain service. Once the credentials are authenticated, the secure information manager can grant the healthcare provider's system limited access to the user's electronic health records, such as access restricted to the privileges assigned to the credentials.

[0023] Access by healthcare providers using authentication credentials issued to them can be logged. For example, a blockchain service can log a user's access history to their electronic health records across one or more private blockchains. Through these private blockchains that store the logs, healthcare providers' access to electronic health records can be audited.

[0024] Herein, we refer in detail to embodiments of the present disclosure, which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are given in order to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure can be put into practice without these specific details. In other instances, well-known methods, procedures, components, and circuits are not described in detail so as not to unnecessarily obscure the aspects of the embodiments. Wherever possible, similar reference numerals are used for similar elements.

[0025] Figure 1 illustrates a system for granting limited access to a user's secure information using a non-fungible token according to an exemplary embodiment. Figure 100 includes a user 102, an authorized entity 104, an authenticator and data controller 106, an authentication information service 108, and a secure data store 120. The authorized entity 104 can issue a request to the authenticator and verifier 106 for access to the user's secure information stored in the secure data store 108. The authorized entity 104 can be any appropriate person, group of people, institution or company that undergoes the authorization workflow.

[0026] The certified entity 104 includes a computing system associated with the certified entity. For example, an application on the computing system may authorize the registered identity of the certified entity 104 to log in to the application. The certified entity 104 and one or more registered identities of the certified entity can be registered with the authenticator and data controller 106. For example, the authenticator and data controller 106 may be part of a secure information manager that manages access to the secure data store 110.

[0027] User 102 may be in the same location (at the same physical location) as the computing system of the certified entity 104. For example, the computing system may obtain user information from user 102 by scanning user 102's portable access point. The portable access point may be a visual access point for user 102's secure information. For example, the portable access point may include a depiction of user 102, such as a facial image, as well as encoded information such as a QR code®, barcode, a series of symbols (e.g., alphanumeric characters, hexadecimal, etc.), and any other appropriate encoded information. The encoded information may represent user 102's identification information, a range definition corresponding to user 102's secure information, a time limit for user 102's access to the secure information, and other appropriate information.

[0028] The authorized entity 104 can scan user 102's portable access point to generate authentication information requests for accessing the user's secure information stored in the secure data store 110. For example, user 102 and authorized entity 104 (e.g., the authorized entity's computing system) may be in the same location, and the user's portable access point may be carried by user 102 (e.g., accessible via the user's wireless device). In other examples, user 102 and authorized entity 104 may be located far apart from each other.

[0029] When user 102's portable access point is scanned, the computing system of the certified entity 104 can issue an authentication request to the authenticator and data controller 106 for authentication credentials that will grant access to the user's secure information stored in the secure data store 110. For example, the authentication request may include user identification information obtained from scanning the user's portable access point. The authenticator and data controller 106 can authenticate that the authentication request is being issued via scanning user 102's portable access point. For example, embedded information from the portable access point may be included in the request and authenticated by the authenticator and data controller 106. The authenticator and data controller 106 can also authenticate that the requesting system corresponds to a certified entity, such as certified entity 104.

[0030] The authentication information request may also include a scope definition of the scope of the requested access (to the user's secure information). For example, embedded information from a portable access point may include these scope definitions. After authenticating the authentication information request, the authenticator and data controller 106 may request authentication information from the authentication information service 108. The requested authentication information may be assigned access privileges corresponding to the scope definitions provided in the authentication information request. The authentication information service 108 may issue authentication information to the certified entity 104, such as authentication information backed by a private blockchain managed by the authentication information service 108. The private blockchain may record the issuance of authentication information to the certified entity 104 (e.g., an identifier representing the certified entity 104). The authenticator and data controller 106 may receive authentication information from the authentication information service 108 and provide the authentication information to the certified entity 104.

[0031] After receiving authentication information, the system of the authorized entity 104 can issue a data access request to the authenticator and data controller 106 to access the secure information of user 102 stored in the secure data store 110. For example, the data access request may include the issued authentication information, the user 102's identification information (e.g., obtained via a portable access point, or any other appropriate identification information), and the identifier of the authorized entity 104.

[0032] The authenticator and data controller 106 can authenticate the authentication information contained in the data access request and verify the user's identity. For example, the authenticator and data controller 106 can authenticate that the data access request corresponds to one or more pieces of authentication information issued to the authorized entity 104. The authenticator and data controller 106 can verify the authentication information via the authentication information service 108. For example, the authentication information service 108 may include a private blockchain service that manages permissions for access to authentication information associated with user 102 and secure information of user 102 stored in the secure data store 110. The authenticator and data controller 106 can issue one or more application programming interface (API) calls (e.g., smart contract calls) to the authentication information service 108.

[0033] In response to these API calls, the credential information service 108 can authenticate that the provided credential information is assigned to an authorized entity 104 and corresponds to a defined range of permissions for user 102's secure information. A private blockchain managed by the credential information service 108 may include a tamper-proof ledger that records information about the assigned credential information. For example, the private blockchain may record the identification information of a user (e.g., user 102) whose secure information is scoped by a given credential, the range definition corresponding to the given credential, the entity to which the given credential is assigned, and changes to the entity assignment of the given credential.

[0034] The authentication information service 108 can authenticate the provided authentication information against the private blockchain to confirm that the authorized entity 104 has been assigned the authentication information. The authentication information service 108 can also provide the authenticator and data controller 106 with a range definition recorded on the private blockchain that corresponds to the authentication information provided in the data access request. For example, the range definition may define the portion of the user's secure information that the provided authentication information and the authorized entity 104 are authorized to access.

[0035] The authenticator and data controller 106 can also verify that the user's identification information from a data access request corresponds to a registered person who has secure information stored in the secure data store 108. For example, a user can register with the authenticator and data controller 106, and the secure information of a registered user may be stored in the secure data store 110. An application service can provide a portable access point for a registered user, and as a result, an authorized entity 104 can scan the portable access point to request access to the secure information of a registered user stored in the secure data store 110.

[0036] In response to the authentication of the provided credentials and the authentication of the authorized entity 104 and the verification of the user's identity, the authenticator and data controller 106 may grant the authorized entity 104 limited scope and time access to the user's secure information stored in the secure data store 110. For example, the scope and time limitations may be controlled by the scope permission granted to the provided credentials. The scope of the user's secure information may be limited to the relationship between the authorized entity 104 and the user 102, or to other appropriate characteristics of the authorized entity 104. In another example, access may be limited to a certain duration (e.g., several days, several weeks, several months), after which the authenticator and data controller 106 will no longer grant access to the authorized entity 104 unless another request containing credentials to be authenticated via the credentials service 108 is issued.

[0037] Figure 2 is a block diagram of a computer server / system 210 according to an embodiment. As shown in Figure 2, the system 210 may include a bus device 212 and / or other communication mechanisms configured to communicate information between various components of the system 210, such as a processor 222 and memory 214. In addition, a communication device 220 may enable connectivity between the processor 222 and other devices by encoding data to be sent from the processor 222 to another device over a network (not shown) and decoding data received from another system over the network for the processor 222.

[0038] For example, the communication device 220 may include a network interface card configured to provide wireless network communication. Various wireless communication techniques may be used, including infrared, radio, Bluetooth®, Wi-Fi®, and / or cellular communication. Alternatively, the communication device 220 may be configured to provide a wired network connection, such as an Ethernet® connection.

[0039] The processor 222 may include one or more general-purpose or dedicated processors for performing calculations and controlling the functions of the system 210. The processor 222 may include a single integrated circuit, such as a microprocessing device, or it may include multiple integrated circuit devices and / or circuit boards that work together to achieve the functions of the processor 222. In addition, the processor 222 may run computer programs, such as an operating system 215, a motion prediction component 216, and other applications 218, which are stored in memory 214.

[0040] System 210 may include memory 214 for storing information and instructions for execution by processor 222. Memory 214 may contain various components for retrieving, presenting, modifying, and storing data. For example, memory 214 may store software modules that provide functionality when executed by processor 222. The modules may include an operating system 215 that provides the operating system functionality of system 210. The modules may include the operating system 215, a data access manager 216, and other application modules 218. The operating system 215 provides the operating system functionality of system 210. The data access manager 216 may provide system functionality for granting authorized entities limited access to a user's secure information, or it may further provide any other functionality of this disclosure. In some cases, the data access manager 216 may be implemented as an in-memory configuration.

[0041] The non-temporary memory 214 may include various computer-readable media that can be accessed by the processor 222. For example, the memory 214 may include any combination of random access memory ("RAM"), dynamic RAM ("DRAM"), static RAM ("SRAM"), read-only memory ("ROM"), flash memory, cache memory, and / or any other type of non-temporary computer-readable media.

[0042] The processor 222 is further coupled to a display 224, such as a liquid crystal display ("LCD"), via a bus 212. A cursor control device 228, such as a keyboard 226 and a computer mouse, is further coupled to a communication device 212 to allow the user to interface with the system 210.

[0043] In some embodiments, system 210 can be part of a larger system. Therefore, system 210 may include one or more additional functional modules 218 to include additional functionality. Other application modules 218 may include, for example, Oracle® Health, Oracle® Data Integrator, Oracle® Cloud Infrastructure, Oracle® Autonomous Database, Oracle® Cerner®, Oracle® Cerner® Millennium, Oracle® Cerner® HealththeIntent, Oracle® Cerner® Seamless Exchange, Oracle® Cerner® HealththeCare, Oracle® Blockchain and Oracle® Cerner® HealththeLife and representative products across the Oracle® Health & Artificial Intelligence platform. Database 217 provides centralized storage for modules 216 and 218 and is coupled to bus 212 to store, for example, verification information for registered persons, certified entity information, authentication and verification-related information, etc. Database 217 can store data in an integrated collection of logically related records or files. Database 217 can be an operational database, analytical database, data warehouse, distributed database, end-user database, external database, navigational database, in-memory database, document-oriented database, real-time database, relational database, object-oriented database, Hadoop Distributed File System ("HFDS"), disaster recovery database, backup database, or any other database known in the industry.

[0044] Although presented as a single system, the functions of system 210 may be implemented as a distributed system. For example, memory 214 and processor 222 may be distributed across multiple different computers that collectively represent system 210. In one embodiment, system 210 may be part of a device (e.g., a smartphone, tablet, or computer).

[0045] In one embodiment, system 210 may be separate from the device and may remotely provide the described functions of the device. Furthermore, one or more components of system 210 may be omitted. For example, to function as a user or consumer device, system 210 may include a processor, memory, and a display, but may not include one or more of the other components shown in Figure 2, and may include additional components not shown in Figure 2, such as a smartphone or other wireless device.

[0046] Users can perform a registration workflow for secure information management. For example, a user can register with the secure information manager. Registered users can share their secure information via a portable access point that grants authorized entities limited access to the registered user's secure information. Figure 3 shows a system for registering users for secure information management according to an exemplary embodiment.

[0047] Figure 300 includes a user system 302, an application server 304, a broker 306, and a secure information service 308. The user system 302 can be any suitable user client device, such as a smartphone, laptop, or tablet. The application server 304 can be any suitable computing device that hosts applications, such as applications displayed to the user via the user system 302. The applications can be web applications, native applications, any combination thereof, or any other suitable applications.

[0048] Users can interact with the application to register an account via the user system 302. By creating a registered account, the user authorizes the secure information service 308 to store and manage the user's secure information. For example, registration can constitute a user account linked to the user, as well as the user's secure information to be stored and managed by the secure information service 308.

[0049] The user system 302 can interact with the application server 304 and / or the broker 306 to carry out the registration workflow. For example, the application server 304 and / or the broker 306 can be separated from the secure information service 308 in some embodiments. User registration through a separate third-party entity (e.g., the application server 304 and / or the broker 306) can increase the level of integrity and reliability of the registration workflow.

[0050] User secure information may include electronic health records. In this example, the third-party entity could be a government entity, a non-profit entity, a coalition entity consisting of several individual entities, or any other suitable entity that links electronic health records to users and supports a transparent and reliable registration workflow that supports the secure storage of such electronic health records by Secure Information Service 308. In these examples, the third-party entity can act as an intermediary to verify the user's identity, the defined scope of the user's electronic health records stored by Secure Information Service 308, and any other suitable aspects of the user's identity and secure information. The third-party entity can also support connections between multiple different Secure Information Services to ensure that the user's electronic health records are available for user examinations and available to the user's healthcare providers.

[0051] The application server 304 can generate a unique link or registration code for each user (for example, delivered to the user system 302). Using the unique link or code, the user can access applications hosted by the application server 304 via the user system 302 and perform the registration workflow. The user system 302 can receive a public key for registering the user's account. The registration workflow may include the user generating a private key. For example, the private key can be used to manage the user's account and secure information. Any other appropriate authentication information (e.g., username and password, two-factor authentication address, shared secret, etc.) can be issued to the user.

[0052] The registration workflow may include providing user identification information such as first name, middle name, last name, date of birth, home address, telephone number, photograph (e.g., facial image), work history, city of birth, social security number, user identifier for one or more electronic health records (e.g., master patient index identifier), social gender, social gender identity, ethnicity, and other appropriate user information. Users may also provide their biometric information (e.g., thumbprint, eye scan) via a biometric scanner to improve the security measures and reliability of the registration workflow and the management of user secure information.

[0053] Broker 306 can verify user identification information and link registered accounts created for the user to the user's verified identity. For example, Broker 306 can verify that a registered account is authorized to store the electronic health records of a person verified as the user identity. This verification can prevent malicious attempts to access another person's secure information.

[0054] Once the application server 304 and / or broker 306 have performed the first part of the registration workflow (e.g., receiving user identification information and verifying the user's identity), the secure information service 308 can generate the user's account components. The account components may include one or more portable access points for the user's secure information, user relationship definitions (e.g., defined relationships with other registered users or individuals), and any other appropriate account components.

[0055] The secure information service 308 can aggregate user secure information as part of (or after) the registration workflow. For example, the secure information service 308 can retrieve, acquire, or otherwise aggregate secure information that the user has authorized the secure information service 308 to manage, such as the user's electronic health record.

[0056] A user's registered account can correspond to one or more portable access points. For example, a portable access point may include a visual representation of the user (e.g., an image) and encoded information relating to the user's secure information, such as a scope definition for sharing the user's secure information. Figure 5 shows a portable access point according to an embodiment.

[0057] Once the registration workflow is complete, the user can log in to the generated account via the user system 302 and the application server 304. The application can allow the user to define the scope for sharing their secure information via the generated portable access point. For example, the user can select one or more data points of their secure information, one or more default secure information data profiles, or define the scope for sharing their secure information in any other appropriate format.

[0058] The application can generate portable access points corresponding to a defined scope and display these portable access points in the user system 302. A computing system for an external entity, such as an authorized entity, can scan the portable access points to configure access to the user's secure information according to the defined scope. Figures 4A, 4B, and 4C illustrate a system having a secure information manager that allows restricted scope access to the user's secure information using non-fungible tokens according to an exemplary embodiment.

[0059] Figure 400A includes a source 402, a requesting system 404, a secure information manager 406, secure user information 408, a scanning module 410, a requester 412, a blockchain manager 414, a blockchain 416, and a smart contract 418. The requesting system 404 can be a system of certified entities, such as entities that have performed a certified workflow by the secure information manager 406. The source 402 may include sources of user information, such as the user's physical body, user identification documents (e.g., driver's license, passport, etc.), the user's wireless device (e.g., smartphone), the user's portable access point, and other appropriate sources of user information.

[0060] The requesting system 404 can obtain user information from the source 402. For example, the scanning module 410 of the requesting system 404 can scan the user's portable access point. The user's portable access point can be displayed via the user's wireless device. For example, an application running on the user's wireless device (e.g., a native application, a web application, etc.) may allow the user to configure the portable access point to share the user's secure information. Figure 5 shows the definition of a portable access point and the scope limitation of the portable access point via an application according to an embodiment. The user's portable access point can be displayed by the user's wireless device on the lock screen (e.g., before entering a password), within the background of the wireless device, as a stored image in the wireless device's photo library, or via any other suitable display means.

[0061] The scanning module 410 can be a dedicated device configured to scan a portable access point and obtain user identification information for a request, such as a wireless device running an application configured to decode the portable access point and include an image capture component (e.g., a camera). The scanning module 410 can obtain user identification information from any other suitable element of source 402.

[0062] Source 402 may include a person's wireless device that includes a predetermined relationship with the user. For example, a user may be a registered person whose secure user information 408 is managed by the secure information manager 406. The user may also register predetermined relationships with the secure information manager 406, such as personal relationships (e.g., parent, spouse, child, friend, etc.), work relationships (e.g., co-administrator of a corporate application), or other appropriate relationships.

[0063] A person with a predetermined relationship to the user may possess a wireless device that can provide the user's identification information to the requesting system 404. For example, any appropriate user identification information provided by the user's wireless device (e.g., the user's portable access point) can be provided to the scanning module 410 via the wireless device of the person with a predetermined relationship to the user. The wireless device of the related person is registered with the secure information manager 406 and includes an application that provides user identification information.

[0064] After scanning source 402, the requesting system 404 and requester 412 can issue an authentication request to the secure information manager 406 for one or more access authentication credentials that will grant access to the user's secure information. For example, the requested authentication credentials may be limited to users identified by user identification information (e.g., obtained via source 402). The requested authentication credentials can then grant the requesting system 404 access to the secure information 408 via the secure information manager 406.

[0065] The authentication information request may also include user identification information obtained via the scanning module 412 (e.g., via scanning the user's portable access point), and any other appropriate information. User identification information may include full name, date of birth, social security number, local address and / or postal code, medical information (e.g., attending physician), biometric information (e.g., fingerprint, eye scan, etc.), identifiers of the user's medical health record (e.g., master patient index identifier, medical record number, insurance claim identifier, etc.), vehicle manufacturer, model, and / or license plate, representation of government-issued identification information (e.g., driver's license photo), and an image of the user's face.

[0066] User identification information can be an identifier (e.g., an alphanumeric string) decoded from the user's portable access point (e.g., by the scanning module 410), and any other appropriate user identification information obtained by scanning the user's portable access point. An authentication request can include an authentication type. For example, a user can select an authentication type (e.g., an authentication type including a corresponding expiration timer) (via an application running on the user's wireless device), and the application can generate a portable access point encoding the authentication type. The scanning module 410 can then decode the authentication type, and the requester 412 can include the authentication type in the authentication request.

[0067] In some embodiments, the user may be prompted by the requesting system 404 to enter a username and password, passcode, key, PIN, or any other appropriate secure user code in order for the requesting system 404 and the requester 412 to generate an authentication information request. For example, during a registration workflow, the user may establish a username and password, passcode, key, PIN, etc. An application in the requesting system 404 may be linked to a secure information manager 406, an honest broker, or any other appropriate entity that can verify the user's username and password, passcode, key, PIN, etc. Once the application in the requesting system 404 has confirmed that the secure user code is valid, the application may authorize the requesting system 404 and the requester 412 to generate an authentication information request.

[0068] To approve an authentication credentials request from the requesting system 404, the secure information manager 406 can authenticate that the requesting system 404 contains an authorized entity. For example, an authentication credentials request from requester 412 may include one or more entity credentials issued to an authorized entity associated with the requesting system 404. Entity credentials may include an access token (e.g., Security Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys, or a signature. The secure information manager 406 can authenticate the entity credentials included in the authentication credentials request and verify the user identification information included in the authentication credentials request. For example, the secure information manager 406 can authenticate that the entity credentials from the request are authenticated as credentials issued to an authorized entity.

[0069] The secure information manager 406 can verify the user identification information provided in the authentication information request. For example, the secure information manager 406 can verify that the authentication information request was generated by scanning the user's portable access point. Verification may include matching the identifier decoded from the portable access point with the stored identifier of the registered user, verifying that the additional user identification information provided in the request is valid against the stored user identification information for the matched registered user, verifying the type of authentication information included in the authentication information request, and / or any other appropriate verification.

[0070] Once entity authentication information is authenticated and user identification information is verified, the secure information manager 406 can issue a software call to the blockchain manager 414 on behalf of the requesting system 404 (associated with the authenticated entity) to request access authentication information. For example, the blockchain manager 414 can manage authentication information that includes access privileges to the user's secure information.

[0071] Blockchain manager 414 can manage blockchain 416 for secure information manager 406. For example, access credentials provided to authorized entities (in response to authenticated and verified credential requests) may include credentials managed by blockchain manager 414. Credentials may be linked to a user's secure information and may be assigned varying levels of scope permissions to access the user's secure information. Blockchain 416 may include a blockchain ledger that records credential transactions.

[0072] A blockchain is a list of records, each called a block, which can be linked through cryptography. In some blockchain embodiments, each block contains a timestamp, the hash of the preceding block, and transaction data. The timestamp verifies that the transaction data was present when the block was added to obtain its hash. Each block designates the block that precedes it, so a set of blocks forms a chain, and each new block augments the set of blocks that precede it in the chain. Therefore, a blockchain can be difficult to alter because data, once added to the blockchain, cannot be altered without altering subsequent blocks.

[0073] The credentials managed by the blockchain manager 414 may include blockchain-backed identifiers that specify unique or non-unique items containing access privileges to a user's secure information. The assignment or ownership of the credentials can be tracked and verified through a distributed ledger (e.g., a blockchain). The blockchain manager 418 may include smart contracts 418 that manage and run in conjunction with blockchain 416. Blockchain 416 can be a hyperledger blockchain or any other suitable blockchain.

[0074] The blockchain manager 414 can manage multiple different credentials that grant varying levels of access privileges to a user's secure information. For example, to ensure that the credentials are managed by the blockchain manager 414, that the credentials are issued to the authorized entity that submitted the data access request, and / or that the credentials have not expired, a data access request from an authorized entity may be authenticated to the blockchain 416 via the blockchain manager 414 and the smart contract 418. Diagram 400B of Figure 4B includes an exemplary data access request 430 that includes credentials issued by the blockchain manager 414.

[0075] The blockchain manager 414 may include a generating component that generates credentials that grant varying levels of access privileges to a user's secure information. Each generated credential includes a unique or non-unique long string identifier that identifies the credential. The generated credential may include information that links the credential to the secure information of the user to whom the access privileges to the credential are assigned. The generated credential may include any appropriate user identification information described herein. Some exemplary credentials include blockchain-based tokens such as non-fungible tokens, semi-fungible tokens, tokens that can be made into several copies, non-unique tokens, or any other appropriate credentials.

[0076] The blockchain manager 414 can issue one or more credentials to an authorized entity in response to a smart contract call from the secure information manager 406. For example, a first credential (e.g., an expiring credential) may provide access to a user's secure information for a limited duration (e.g., several hours, several days, several weeks, etc.). In this example, once the limited duration expires, the first credential no longer authenticates through the blockchain manager 414 and blockchain 416. A user can define an expiration timer (e.g., via an application loaded on the user's wireless device), and this definition may be included in the user's portable access point. This defined timer may be included in a credential request issued by the requesting system 404 via a scan of the user's portable access point. The secure information manager 406 can then include the defined timer in a smart contract call to the blockchain manager 414.

[0077] In another example, a second set of credentials (e.g., episodic credentials) may provide access to a user's secure information for a predetermined duration (e.g., several hours, several days, several weeks, etc.). In this example, once the predetermined duration has expired, the second set of credentials no longer authenticates through the blockchain manager 414 and blockchain 416. In yet another example, a third set of credentials (e.g., persistent credentials) may provide access to a user's secure information permanently or until the credentials are explicitly revoked.

[0078] For example, a user's secure information could be an electronic health record, and an authorized entity could be a healthcare provider requesting access to the user's electronic health record. In this example, the healthcare provider could scan the user's portable access point (e.g., via the user's wireless device) and request authentication credentials from the blockchain manager 414. Once the authentication credentials request from the healthcare provider is authenticated and verified, the blockchain manager can issue authentication credentials to the healthcare provider.

[0079] A user can define authentication credentials to issue to a healthcare provider through their application running on their wireless device. For example, a user can select one of a first, second, and / or third set of credentials, and the application can display a version of the user's portable access point corresponding to the selection. The version of the user's portable access point can encode the authentication credentials selected by the user for the healthcare provider. The healthcare provider can scan the portable access point and issue an authentication request, which includes the authentication credentials selected by the user for the healthcare provider.

[0080] In this example, the user may choose a first set of credentials (and define a timer) when the user anticipates that a healthcare provider will need limited access to the user's electronic health record for a short period, such as when the user visits an emergency medical facility. In another example, the user may choose a second set of credentials when the user anticipates that a healthcare provider will need access to the user's electronic health record for a moderate period, such as during surgery at a hospital the user does not frequently visit, or during a specialist appointment the user anticipates will not return to. In yet another example, the user may choose a third set of credentials when the user anticipates that a healthcare provider will need access to the user's electronic health record for a long period or an indefinite period, such as when the healthcare provider is the user's primary care physician or a specialist designated for a long-term health problem.

[0081] The above example describes a certified entity that is a healthcare provider, but the certified entity could be another individual, such as an individual with a predetermined relationship to the user (e.g., a family member, a close friend, etc.). In this example, the user may select a third set of credentials to ensure that the individual retains access to the user's electronic health records. After the secure information manager 406 issues one or more smart contract calls, the blockchain manager 414 may issue one or more sets of credentials to the certified entity in response to the smart contract calls.

[0082] The blockchain manager 414 can generate authentication credentials on request and / or store multiple pre-generated authentication credentials related to a user. For example, authentication credentials may be generated on request in response to an authentication request that includes user identification information, range privileges corresponding to the authentication request, timing constraints and / or authentication credentials versions (e.g., extinct, episodic, and / or persistent), or any other appropriate information from the authentication request. The generated authentication credentials may then be assigned to an authorized entity identifier from the authentication request, and this assignment may be recorded in the blockchain 416. Authentication credentials generated on request may be created to match specific parameters of the authentication request. For example, an authentication request may be generated in response to user selection and / or scanning of a user's portable access point in an information management application.

[0083] In another example, the blockchain manager 414 can assign pre-generated credentials to entities identified in a credential request. For example, pre-generated credentials may include predetermined scope privileges, correspond to specific credential versions (e.g., extinct, episodic, and / or persistent), include user identification information linking the credentials to a user, and / or include any other appropriate information. The blockchain manager 414 can pre-generate multiple credentials for a given user, each having different combinations of parameters. For example, multiple credentials for each credential version (e.g., extinct, episodic, and / or persistent) can be pre-generated, where different predetermined scope privileges can be assigned to the multiple credentials for a given credential version. Since pre-generated credentials are not tailored to the details of a given credential request, many different versions of pre-generated credentials may correspond to many different credential requests.

[0084] For example, different predetermined scope privileges may correspond to different scope templates defined by the user for the user's secure information (e.g., predetermined groupings or segments of the user's electronic health data), different templates based on feedback from certified entities regarding which parts of the user's secure information the entity needs, a global scope that grants broad access to the user's secure information, or any other appropriate predetermined scope privilege. The secure information manager 406 and / or blockchain manager 414 can match these pre-generated credentials with credential requests and assign matching pre-generated credentials to the certified entities identified in the credential requests.

[0085] The pre-generated authentication credentials may also include a blank set of range privileges, and the secure information manager 406 can, upon request, assign range privileges to authentication credentials that match the authentication credentials request. Thus, the pre-generated authentication credentials can be matched against the authentication credentials request using the authentication credentials version, and the matching authentication credentials may be assigned range privileges that are specifically tailored to the authentication credentials request. The secure information manager 406 can communicate the privilege assignment to the blockchain manager 414, and the blockchain manager 414 can append the privilege assignment to the blockchain 416.

[0086] Several authentication information requests from the requesting system 404 may be generated by scanning the user's portable access points, such as portable access points controlled by an information management application on the user's wireless device. The information management application can generate portable access points corresponding to pre-generated authentication information. For example, the information management application may present the user with a limited set of range restrictions and / or a limited set of timing constraints (e.g., authentication information versions), where each combination of range restrictions and timing constraints corresponds to one of the pre-generated authentication information in the blockchain manager 414. In this example, the secure information manager 406 and / or the blockchain manager 414 can match each authentication information request against the pre-generated authentication information corresponding to the authentication information request.

[0087] Upon receiving a user selection and displaying the user's portable access point, the information management application on the user's wireless device may also provide the Secure Information Manager 406 with indicators that identify a specific portable access point (e.g., a particular combination of range and timing constraints) and the point in time when the portable access point was displayed. The Secure Information Manager 406 and / or Blockchain Manager 414 can then generate credentials corresponding to the portable access point definition on request and / or select pre-generated credentials that match the portable access point definition. In this example, the Secure Information Manager 406 has already selected credentials for the portable access point definition before receiving the credentials request from the requesting system 404. Once the credentials request is received, the selected credentials can simply be assigned to the authorized entity identified in the credentials request.

[0088] In this example, any misuse of this version of the user's portable access point at a later point in time can be traced back to the time this version of the user's portable access point was first displayed, and to the authorized entity that scanned this version of the user's portable access point (and subsequently requested credentials using information decrypted from this version of the user's portable access point). Such a misuse attempt could exploit a still image of the user's portable access point. A misuser could take a photograph of the user's portable access point and use that photograph to later attempt to request credentials that would provide access to the user's secure information. The version of the user's portable access point can identify the time when the portable access point was scanned and the authorized entity, allowing for the tracking and holding of the misuser accountable.

[0089] In another example, the requesting system 404 may be a user's wireless device, while the source information 402 may relate to a certified entity. The certified entity may display the source information 402 via any suitable display means such as a computing system (e.g., a wireless device, computer monitor, television, etc.), printed on a physical item (e.g., paper, wood, cardboard, etc.), or via any other suitable display. The source information 402 may include an access point of the certified entity, such as a QR code or other suitable visual code related to the certified entity. The access point of the certified entity may be similar to a user's portable access point, such as the portable access point disclosed in Figure 5.

[0090] In this example, the access point of the certified entity may contain encoded information about the certified entity, and the user's wireless device, as the requesting system 404, can scan the certified entity's portable access point to decrypt the information. An information management application on the user's wireless device, which the user interacts with to select the scope of the requested credentials, the timing of the requested credentials, and / or the version of the credentials, can be configured to decrypt the certified entity's portable access point. For example, the information management application can act as a scanning module 410. The encoded information of the certified entity may include an identifier that identifies the certified entity to the secure information manager 406, encoded information representing identity credentials issued to the certified entity (e.g., a signature using an encryption key), or other appropriate certified entity identification information. Using the certified entity information decrypted from the certified entity's access point, the user's wireless device can generate a credential request and send the credential request to the secure information manager 406.

[0091] For example, an authentication request generated by a user's wireless device as the requesting system 404 may include user identification information (e.g., stored on the user's wireless device), scope definition information for the requested authentication information (e.g., selected via an information management application), timing and / or version of the requested authentication information (e.g., selected via an information management application), certified entity identification information decoded from the entity's access point, and other appropriate authentication request information.

[0092] In response to an authentication request from a user's wireless device, the secure information manager 406 can provide access authentication information corresponding to the authentication request to the system of the authorized entity. For example, through interaction with the blockchain manager 414, the secure information manager 406 can provide authentication information with scope authorization corresponding to the authentication request.

[0093] The blockchain manager 414 can generate credentials in response to a credential request from a user's wireless device, and these generated credentials can be provided to the computing system of an authorized entity. In another example, the blockchain manager 414 may include existing credentials, and the blockchain manager 414 (and / or secure information manager 406) can configure these existing credentials in response to a credential request. Configuring existing credentials may include one or more of the following: assigning the existing credentials to an authorized entity (e.g., the authorized entity's token wallet), or assigning range privileges to the existing credentials in response to a credential request.

[0094] Using the authentication credentials issued to the authorized entity's computing system via the user's wireless device authentication credentials request as the requesting system 404, the authorized entity's computing system can issue one or more data access requests to the secure information manager 406. For example, a data access request may include the scope of the user secure information being requested, the authentication credentials to be issued, and / or any other appropriate information.

[0095] When the requesting system 404 receives authentication information issued via the blockchain manager 414, the requesting system 404 can issue a data request to the secure information manager 406 requesting access to the user's secure information using the issued authentication information. Diagram 400B includes the requesting system 404, the secure information manager 406, secure user information 408, the blockchain manager 414, the blockchain 416, the smart contract 418, the audit log 424, the transaction log 426, the access request 430, and the authentication information 432. Similar to Diagram 400A, an embodiment of the requesting system 404 can be a system of certified entities, such as entities that have performed a certification workflow by the secure information manager 406.

[0096] The requesting system 404 may issue an access request 430 containing authentication credentials 432, which may be one or more authentication credentials issued to the requesting system 404 (and authorized entities) by the blockchain manager 414. The access request 430 may include identification information obtained through scanning the user's portable access point, as well as user identification information such as the user's full name, date of birth, social security number, local address and / or postal code, medical information (e.g., primary care physician), biometric information (e.g., fingerprints, eye scans, etc.), identifiers for the user's medical health records (e.g., master patient index identifier, medical record number, insurance claim identifier, etc.), vehicle manufacturer, model, and / or license plate, representation of government-issued identification information (e.g., driver's license photo), and an image of the user's face.

[0097] When an access request 430 is received by the secure information manager 406, the authentication information authenticator 420 can authenticate the authentication information 432 via one or more smart contracts 418 of the blockchain manager 418. The secure information manager 406 can also verify the user's identity against registered users to confirm that the request identifies a user that matches the authentication information for which it was issued. Once the authentication information 432 is authenticated and the user's identity is verified, the data access controller 422 can issue one or more queries to secure the user information 408 in order to retrieve secure user information with a limited scope.

[0098] The secure information manager 408 can log requests, restricted-scope information accessed through the requests, timestamps, and other appropriate data related to the access request 430 and the restricted-scope secure user information accessed. The secure information manager 408 may include application logs and / or audit logs. For example, an application log may log application transactions and activities that grant restricted-scope access in response to data access requests (e.g., access request 430). An audit log may log similar data to the application log, for example, to support audits such as user audits.

[0099] User access to secure information can be logged in any appropriate data structure. The blockchain manager 414 can also store audit logs in a blockchain data structure to support auditing. For example, the secure information manager 408 can invoke one or more smart contracts 418 to write log information to the audit log 424. Each instance of a user's request for and / or authorized access to secure information can be logged as a block on the blockchain. The blockchain manager 414 can also store application logs within the blockchain data structure.

[0100] The Secure Information Manager 408 and / or Blockchain Manager 414 may provide a portion of the log in response to an audit request. A user (or any other appropriate entity or person) may be permitted to audit the user's access to Secure Information. Logged information, including the request, the scope of information accessed through the request, the timestamp, and other appropriate data related to the received request and scope of data, may be provided to the user or other appropriate auditing entity.

[0101] Figure 4C's diagram 400C includes the requesting system 404, the secure information manager 406, the secure user information 408, the access request 430, the authentication information 432, the data query 434, the user information 436, the scope-restricted user information 438, and the restricted user information 440. Similar to diagrams 400A and 400B, the requesting system 404 can be a system of certified entities, such as entities that have performed a certified workflow by the secure information manager 406.

[0102] The access request 430 and authentication information 432 can be authenticated and verified via the secure information manager 406. A data query 434 can be issued to retrieve scope-restricted secure user information, such as user information corresponding to the scope privileges of the authentication information 432. The secure user information 408 may contain secure information for multiple registered individuals, and the user information 436 may represent stored secure information for users verified against the identification information contained in the access request 430 and / or users linked to the authentication information 432. The secure information manager 406 can structure a data query 434 to retrieve portions of the user information 436.

[0103] User information 436 may include a set of user data points, and scope-restricted user information 438 may include a subset of data points. In an example where secure user information 408 includes electronic health records and user health data, the set of data points in user information 438 may include an aggregation of the user's electronic health record data, and the subset of data points in scope-restricted user information 438 may include a portion of the aggregated electronic health data, such as components of the aggregated electronic health record data, a predetermined subset of the electronic health record (defined, for example, by the user, the secure information manager 406, etc.), or metadata and / or summary data covering any other appropriate subset of the data.

[0104] For example, scope-restricted user information 438 may be a predetermined health data point designated by the user as accessible by any appropriate authorized entity, including authenticated credentials. In another example, scope-restricted user information 438 may include health data points based on a predetermined template, such as data points coordinated for patient registration. Exemplary scope-restricted user information 438 may include the user's blood type, medical history, previous surgical history, allergies, medications currently being taken, or any other appropriate user health data.

[0105] User information 436 may be a segmented health record, and the data points included by the scope-limited user information 436 can be any appropriate segment of the segmented health record. For example, user information 436 may be electronic health data segmented based on parameters. Exemplary parameters may include the issuing physician and / or healthcare institution (e.g., entity identifier), the type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), the relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), the date and time the information was generated, the electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. Users can define which parts of their electronic health data are shared via their portable access point by providing parameter values ​​that define the scope. In this case, the privileges for authentication information 432 can be defined by range based on user-defined parameters, and the secure information manager 406 can restrict data queries 434 based on the privileges for authentication information 432.

[0106] In response to an authenticated and verified access request 430, the secure information manager 406 may issue a data query 434 to secure user information 408. The secure information manager 406 may then receive restricted user information 440, which may be scope-restricted based on the scope privileges defined for the authentication information 432. The data query 434 may be generated in response to the data requested by the access request 430, and the secure information manager 406 may then restrict the data query 434 based on the privileges of the authentication information 432. In another example, the data requested by the access request 430 may be scope-restricted according to the privileges of the authentication information 432, and the data query 434 may be generated to retrieve the scope-restricted data. The restricted user information 440 may then be provided to the requesting system 404.

[0107] Role-based access control can also be applied to secure user information 408 to limit and restrict the functionality and scope of information for authentication credentials 432 and identities associated with authentication credentials (e.g., users, authorized entities, registered users of authorized entities, etc.). Each identity associated with authentication credentials 432 can correspond to a role in the context of role-based access control. For example, an administrator role may have full permission to view all information and perform all tasks, while a general clerk role may only be able to view limited information about a particular consumer or patient, in which case attributes of protected medical information (PHI) or personally identifiable information (PII) would be hidden from that individual. Role-based access control can also be applied to data queries 434 so that restricted user information 440 can be retrieved by queries.

[0108] Role-based access control can be applied to one or more registered identities of an authorized entity. For example, the authorized entity may be an organization, and the registered identities may be individuals who are members of that organization. In some embodiments, the authorized entity may be a hospital, an emergency room organization, or a first-responder organization, and the registered identities may be emergency room personnel and / or paramedics.

[0109] Request 430 may be issued by the registered identity of the authorized entity. For example, Request 430 may include indicators of the authorized and registered entities, such as credentials 432 that identify the registered identity and the authorized entity when authenticated. Any other appropriate indicators may be included in Request 430.

[0110] The restricted user information 440 may be scope-defined for a registered identity associated with the authenticated identity that issued the request, and / or for the authentication information 432 of the authenticated entity or registered identity. For example, the registered identity of an emergency medical technician may not provide the same level of care as an emergency room provider, and therefore different levels of information may be required depending on the circumstances of the care. Thus, a request from the registered identity of an emergency medical technician may correspond to a first version of the restricted user information 440, while a request from an emergency room personnel may correspond to a second version of the restricted user information 440, the first version being different from the second version. For example, the second version may include data points relevant to a particular level and care activities not included in the first version.

[0111] The requesting system 404 can issue multiple requests over time to access the user's secure information using the authentication information 432. For example, as long as the authentication information 432 has not expired and / or been revoked, the secure information manager 406 can authenticate the authentication information and grant access to the user's secure information (limited in scope to the privileges of the authentication information 432).

[0112] A user can edit the privileges assigned to the credentials 432 via an application running on the user's wireless device. For example, the application can link to the secure information manager 406 and edit data points, secure user information segments, and / or parameter values ​​used to group the secure user information that the credentials 432 is permitted to access. These edits can be stored in the secure information manager 406 and / or provided to the blockchain service via a software call. The blockchain service can add privilege edits to the blockchain ledger that defines the access privileges for the credentials 432. Edits may include revoking the access privileges assigned to the credentials 432. If the credentials 432 expire or the access privileges for the credentials are revoked, the requesting system 404 can send the credentials back to the blockchain service that issued them, for example, to be assigned to the same or another authorized entity.

[0113] Figure 5 shows a portable access point according to an exemplary embodiment. Figure 500 includes a wireless device 502, a portable access point 504, an image 506, encoded information 508, and an encoded range sequence 510. An application operating on the wireless device 502 can display the portable access point 504. For example, a certified entity's system can be configured to scan the portable access point 504 from the wireless device 502. The wireless device 502 can display the portable access point 504 in any other suitable format.

[0114] The portable access point 504 may include an image 506, or a user's facial image, and encoded information 508. The encoded information 508 may include a unique QR code or other appropriate visual or symbolic (e.g., alphanumeric) code embedded in (e.g., on top of) the image 506, such as an encoded range sequence 510. In some embodiments, the QR and / or symbolic code may utilize one or more of the following: a holographic image, a stereoscopic holographic image, a pixelated code, a stereoscopic textured code, etc. For example, the encoded information 508 may be displayed on top of the image 506 as an embossed QR code having a unique encrypted length string identifier generated using an algorithm.

[0115] The encoded information 508 may include a unique encrypted string identifier generated via an encrypted string identifier algorithm. The encrypted string identifier may be unique at least due to the encrypted string identifier algorithm that generates it. For example, if a rogue version of the portable access point 504 attempts to replicate the unique encrypted string identifier, the scan of image 506 and the encoded information 508 will not match due to the unique algorithm used.

[0116] The unique encrypted string identifiers generated via the encrypted string identifier algorithm may be dynamic, such that a new identifier is generated for each version of the portable access point 504, or over a predetermined period (e.g., every two hours, every four hours, every six hours, every twelve hours, daily, etc.), or at any other appropriate time. In this example, a secure information manager that manages a user's secure information can receive the dynamically generated identifiers for that version of the portable access point. For example, the identifier can be dynamically generated via an information management application on a wireless device 502 that manages the user's portable access point, and the application can send the dynamically generated identifiers to the secure information manager. In another example, the identifier can be dynamically generated via a cloud service, and the cloud service can send the dynamically generated identifiers to both the application that manages the user's portable access point and the secure information manager.

[0117] To mitigate malicious attempts to request credentials through older versions of a user's portable access point, the Secure Information Manager can record one or more active long-string identifiers for a given user. When the Secure Information Manager receives a credential request containing an inactive identifier, the request may be rejected, and the malicious attempt may be reported to support enhanced security measures.

[0118] A system of a certified entity, such as the scanning module 410 and the requesting system 404 in Figure 4A, can be configured to scan the portable access point 504. When the scanning module 410 scans the portable access point 504, the requesting system 404 (e.g., an application configured to decode the portable access point 504) can decode the coded information 508, the coded range sequence 510, and / or the image 506. For example, an application in the requesting system 404 can decode a unique long sequence of digits (e.g., generated by a unique algorithm), as described with reference to diagram 400A in Figure 4A, and can include the decoded number in the authentication information request.

[0119] The wireless device 502 can also display the portable access point 504 while the wireless device is offline, such as when the wireless device 502 lacks a connection to the Internet, a server hosting application components that display the portable access point 504, a cellular network and / or a wireless local area network, or any other suitable network connection. In this example, application components operating locally on the wireless device 502 can display the portable access point 504. The portable access point 504 can be displayed on the application's login screen, for example, before a user logs into the application. This can support the display of the portable access point 504 without a network connection. A scanning component of an authorized entity (e.g., scanning module 410) can then scan the displayed portable access point 504, and the authorized entity's system can use a network connection (e.g., a connection to the Internet) to perform authentication information requests and / or data access requests.

[0120] The encoded range sequence 510 can be an encoded string that maps to a portion of the user's secure information. For example, a user can define which portions of their secure information should be shared through interaction with the wireless device 502 and the launched application, and the launched application can generate an encoded range sequence 510 that represents an encoded version of the user-defined portion. In some embodiments, a predefined mapping can map that portion of the user's secure information to the encoded range sequence 510.

[0121] Secure user information of a user linked to the portable access point 504 can be electronic health data segmented based on parameters. For example, parameters may include the issuing or affiliated physician and / or healthcare institution (e.g., entity name or identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), date and time of information generation, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. Users can define which parts of their electronic health data are shared via the portable access point 504 by providing parameter values ​​that define the range.

[0122] For example, through interaction with an application running on the user's wireless device, the user can specify the following parameter values: namely, the issuing physician and / or medical institution - ALL; type - medication, tests and results, medical history, family history, biometrics, vaccine information, and allergies; relevant medical field - cardiology, primary care physician, and neurology; date of information occurrence - ALL; and electronic health record format - ALL. Other exemplary parameter values ​​for the date of information include the past two years, last year, since age 18, and a custom time range (e.g., January 1-31, 2023). The user's electronic health data matching the parameter values ​​specified by the user can be scope-defined for sharing via the portable access point 504 and any issued credentials corresponding to the portable access point 504.

[0123] A predefined mapping allows a user's health data segment to be mapped to an encoded range sequence 510. In one example, the sequence formatting can define which strings map to parameters and which strings map to the values ​​of those parameters. A sample encoded range sequence 510 includes [A:XYX, C:1C3B, X:1456, etc.]. In the exemplary predefined mapping, the first symbol of the encoded range sequence can be mapped to one of the electronic health data segments (e.g., the issuing or affiliated physician and / or healthcare institution, the type of information, the relevant medical practice, the date the information was generated, the electronic health record format, etc.). In the predefined mapping in this example, the symbols after the ":" value can be mapped to parameter values.

[0124] In an example where the letter "A" maps to the date of information origin in a predefined mapping, the symbol "XYX" can map to the parameter value "Information from the past 5 years." Other symbols can map to other parameter values ​​for the date of information origin, such as "ALL," "18 years or older," or a custom date range. In an example where the letter "C" maps to the type of information in a predefined mapping, the symbol "1C3B" can map to a subset of information types (e.g., medication, tests and results, medical history, family history, biometrics, vaccine information, and allergies). Other symbols can map to other subsets of information types.

[0125] In an example where the letter "X" maps to a relevant medical practice in a predefined mapping, the symbol "1456" can map to a subset of medical practices (e.g., cardiology, primary care, neurology, and oncology). Other symbols can map to other subsets of medical practices. In this example, the coded range sequence 510 can define parameters of a user's electronic health data and the values ​​of those parameters. When the portable access point 504 is scanned by an authorized entity such as the scanning module 410 and the requesting system 404 in Figure 4A, the requesting system 404 (e.g., an application configured to decode the portable access point 504) can decode the coded range sequence 510. For example, an application in the requesting system 404 can decode the coded range sequence 510 as described with reference to diagram 400A in Figure 4A and include the decoded symbol sequence (e.g., [A:XYX, C:1C3B, X:1456, etc.]) in an authentication information request.

[0126] The secure information manager can issue authentication information with privileges corresponding to a sequence of symbols to the requesting system 404 (via the blockchain service). For example, the secure information manager 406 and the blockchain manager 414 in Figure 4A can communicate to issue blockchain-backed authentication information that includes privileges defined by the sequence of symbols. The secure information manager 406 can store the privileges, and / or the blockchain manager 414 can store the privileges for the issued authentication information as part of the blockchain 416.

[0127] The secure information manager 406 may also receive data access requests containing authentication information issued from the requesting system 404, which include a requested segment of the user's electronic health record. For example, the requesting system 404 may issue an access request 430 containing authentication information 432, as shown in Figure 4B. The access request 430 may also include a range of requested data, such as a defined portion of the user's electronic health record (e.g., segments and parameter values). The range of requested data can be defined using a symbol sequence corresponding to a predefined mapping (similar to the coded range sequence 510). For example, the secure information manager 406 may interpret the symbol sequence using a predefined mapping to determine the requested portion of the user's electronic health data (e.g., a segment limited by parameter values).

[0128] The secure information manager 406 can compare the access privileges of the authentication information 432 (e.g., a sequence of symbols interpreted through a predefined mapping) with the range of data being requested (e.g., another sequence of symbols interpreted through the same or different predefined mapping) to determine which segments of the user's electronic health data and which parts of each segment (defined by parameter values) to retrieve for the access request 430. For example, the access privileges of the authentication information 432 may only grant access to a subset of the range of data being requested.

[0129] The audit log 424 of the blockchain manager 414 may establish one or more predefined mappings in the private blockchain of blockchain 416 that map symbol sequences to segments of a user's electronic health record and the parameter values ​​of those segments. For example, the secure information manager 406 may access the established predefined mappings to interpret authentication privileges and / or data access requests. In another example, an application loaded on a user's wireless device that manages the user's portable access point may access the established predefined mappings to encode the user's portable access point.

[0130] Predefined mappings can be updated, for example, based on a change in the format of the electronic health record, a change in the user's electronic health record, or any other appropriate reason. The blockchain manager 414 can append a new block to the private blockchain storing the predefined mappings so that the updated mapping is stored as the latest block and the historical mapping is stored as the previous block. In this example, the computer systems involved can access the current predefined mappings via the latest block.

[0131] In addition, the audit log 424 can store one or more symbolic sequences for the data access request, including the data access request itself, the scope of the data being requested, the privileges of the authentication credentials used to access the user's electronic health record, and the actual electronic health record segment accessed via the data access request.

[0132] Figure 6 shows a flowchart for granting limited access to a user's secure information using user authentication information authentication and user verification according to an exemplary embodiment. In one embodiment, the functions in Figure 6 (and below in Figures 7 and 8) are implemented by software stored in memory or other computer-readable or tangible media and executed by a processor. In other embodiments, each function may be implemented by hardware (for example, through the use of application-specific integrated circuits ("ASICs"), programmable gate arrays ("PGAs"), field-programmable gate arrays ("FPGAs"), or by any combination of hardware and software.

[0133] Process 600 can be performed by a requesting computing system, such as a computing system associated with an authorized entity that issues requests (e.g., authentication information requests and / or data access requests) to a secure information manager. Process 602 can be performed by a secure information manager (e.g., a cloud computing system or any other suitable computing system) that manages the user's secure information.

[0134] In block 604, process 600 can scan a portable access point. For example, the requesting system may include a scanning component configured to scan and decode a user's portable access point. The scanning component may be a portable device comprising a camera and software configured to decode user identification information from the user's portable access point.

[0135] A portable access point can be a visual access point that, when scanned, can grant access to a user's secure information (e.g., stored and managed via a secure information manager). For example, a visual access point may include a visual representation of the user linked to the portable access point (e.g., a facial image), as well as encoded information related to the user's secure information and / or the scope of permitted access. The requesting system and scanning components may be associated with certified entities, such as entities that have performed a certified workflow. Exemplary certified entities may include service providers (e.g., system administrators, healthcare providers, hospitals, etc.), joint venture partners, individuals registered with a secure information manager, or any other appropriate certified entities.

[0136] The user can configure the portable access point and the encoded information it displays. For example, the portable access point can be displayed via an application running on the user's wireless device (e.g., a smartphone, tablet, etc.), and the user can interact with the application and select the scope of sharing of their secure information. The portable access point can be dynamic so that the user's selection via the application generates different versions of the portable access point with different encoded information displays. For example, the user can define a sharing scope that identifies data points of their secure information that can be shared with authorized entities via scanning the portable access point. The user can also define a sharing scope of time periods during which their secure information can be shared with authorized entities via scanning the portable access point. Process 700 in Figure 7 further describes the user interaction for defining timing and range parameters for configuring the portable access point.

[0137] In block 606, process 600 can generate an authentication credentials request in response to scanning a portable access point. For example, a requesting system can decode a user's portable access point and use the decoded information to generate a request for one or more authentication credentials. Encoded information displayed by the portable access point can be decoded and included in the authentication credentials request. Information decoded from a user's portable access point may include user identification information such as full name, date of birth, social security number, local address and / or zip code, medical information (e.g., primary care physician), biometric information (e.g., fingerprints, eye scans, etc.), identifier of the user's medical health record (e.g., master patient index identifier), vehicle manufacturer, model, and / or license plate, representation of government-issued identification information (e.g., driver's license photo), and an image of the user's face.

[0138] The decrypted information from the user's portable access point may also include scope definitions corresponding to the user's secure information. For example, the scope definitions may correspond to credential types such as expiring credentials (limited time range), episodic credentials (predetermined time range), or persistent credentials (valid until revoked). In another example, the scope definitions may correspond to restricted scope privileges for the requested credentials.

[0139] User secure information can be segmented electronic health data based on parameters, and the restricted scope privileges of the requested authentication information can correspond to restricted portions of the user's electronic health data. For example, parameters may include the issuing physician and / or healthcare institution (e.g., entity identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), date and time of information generation, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. Users can define which portions of their electronic health data are shared via their portable access point by providing parameter values ​​that define the scope.

[0140] In block 608, process 600 can send an authentication request. For example, a requesting system can send an authentication request to a secure information manager. The authentication request from the requesting system may be for authentication credentials that grant the requesting system access to the user's secure information, which can be managed by the secure information manager. For example, the details of the request (e.g., user identification information, authentication credentials type, secure user information privileges with defined scope) may be provided by the user's portable access point, which allows the user to control how their secure information is shared with the requesting system.

[0141] The secure information manager can verify and authenticate authentication information requests and retrieve authentication information from blockchain services in response to requests. The authentication and verification of authentication information requests, as well as subsequent retrieval, are described with reference to blocks 618 and 620 of process 602. In block 610, process 600 can receive the authentication information. For example, the secure information manager can send the retrieved authentication information to the requesting system.

[0142] In block 612, process 600 can send a data access request containing the received authentication information. For example, a data access request containing the received authentication information, the identifier of the authorized entity that issued the request, and user identification information can be sent to the secure information manager. The secure information manager can verify and authenticate the data access request and retrieve limited scope secure user information in response to the data access request.

[0143] A data access request can define one or more data points of a user's secure information. For example, a user's secure information may be electronic health data segmented based on parameters. A data access request may include specific parameter values ​​that define the scope of the user's secure information being requested. In some embodiments, the authentication information issued to an authorized entity and provided in the data access request includes scope privileges over the user's secure information. Authentication and verification of the data access request and the subsequent retrieval of scope-restricted secure user information are described with reference to blocks 626 and 628 of process 602.

[0144] In block 614, process 600 can receive scope-restricted secure user information in response to a data access request. For example, the secure information manager can send scope-restricted user information to the requesting system. The received scope-restricted user information can correspond to the requested data points included in the data access request. The received scope-restricted user information can also correspond to a portion of the requested data points included in the data access request. For example, if the data access request includes user data points outside the scope privilege set of the authorized entity / provided credentials, the secure information manager can retrieve and return only the portion of the user data points covered by the scope privilege set.

[0145] In block 616, process 602 can receive an authentication information request. For example, the secure information manager can receive an authentication information request from the requesting system, as described with reference to block 608 of process 600. The authentication information request may include user identification information, an identifier and / or authentication information of an authorized entity, an authentication information type definition, a scope definition for secure user information, and any other appropriate information.

[0146] The Secure Information Manager can verify user identification information and authenticate certified entity identifiers / credentials. In this example, the Secure Information Manager can obtain credentials that grant a user restricted access to a range of certified entities to secure information (e.g., from a blockchain service). The obtained credentials can correspond to the credential type definition from the credential request, and the access privileges assigned to the obtained credentials can correspond to the range definition from the credential request.

[0147] In block 618, process 602 can authenticate and verify an authentication information request. For example, an authentication information request may include user identification information that the secure information manager verifies. The secure information manager can manage the secure information of multiple registered individuals. Verification can compare the user identification information provided in the authentication information request with that of one of the registered individuals.

[0148] A credentials request may include an identifier and / or identifying credentials of an authorized entity, and the secure information manager can authenticate such identifier and / or identifying credentials. For example, the identifier and / or identifying credentials included in a credentials request (from a requesting system related to an authorized entity) may include a unique identifier assigned to the authorized entity, a cryptographic key assigned to the authorized entity and / or a digital signature generated via the cryptographic key, a unique token assigned to the authorized entity, or any other suitable data that can be used to authenticate the authorized entity.

[0149] In block 620, process 602 can obtain the credentials corresponding to the credentials request. User identity verification can match registered users against the credentials request, and identifier / credential authentication can match authorized entities against the credentials request. The secure information manager can then issue a software call to the blockchain service for credentials with scope privileges that grant restricted access to the secure information of the matching registered user within the scope of the matching authorized entity. For example, the software call may include the identifier of the registered user, the identifier of the authorized entity, and the credentials type included in the credentials request from the requesting system.

[0150] A blockchain service can respond to a software call by returning blockchain-backed credentials to a secure information manager. For example, a blockchain service can host one or more blockchains that manage credentials and issue credentials to authorized entities to serve as credentials that grant authorized entities access to secure user information. The issued credentials can match the credentials type included in the software call. Transactions issuing credentials to authorized entities can be appended to the blockchain so that the assignment record is maintained as an immutable ledger.

[0151] A software call by the secure manager can be a smart contract call, and a blockchain service can execute one or more smart contracts to return authentication credentials in response to a smart contract call. For example, a smart contract execution can issue authentication credentials to a token well identifier (or any other appropriate entity identifier) ​​associated with a certified entity, and that transaction can be attached to the blockchain managing it. The attached transaction may include additional information such as an expiration timer for issuing tokens to the certified entity (defined by the authentication credentials type), identification information about the certified entity, identification information about the user, or any other appropriate information.

[0152] The secure information manager can assign scope-sharing privileges included in the authentication credentials request (e.g., a range of secure user information data points) to the credentials. For example, data points, secure information segments, or other appropriate parts of a user's secure information defined via a scope-sharing definition can be assigned as privileges to the credentials returned by the blockchain service, and these privilege assignments can be stored by the secure information manager.

[0153] A software call from a secure information manager for authentication credentials to a blockchain service may include a scope sharing definition, and the blockchain service may assign corresponding privileges to the credentials for accessing the user's secure information. For example, the blockchain service may attach the scope sharing definition to the blockchain as part of a recorded transaction (via the execution of a smart contract).

[0154] In block 622, process 602 can send an authentication information request. For example, a secure information manager can send the acquired authentication information to the requesting system. The blockchain service can also send the authentication information directly to the requesting system via a separate communication channel.

[0155] In block 624, process 602 can receive a data access request. For example, the secure information manager can receive a data access request from a requesting system having one or more authentication credentials, as described with reference to block 612 of process 600. The data access request may include authentication credentials, an identifier of the authorized entity that issued the request, user identification information, one or more requested data points of the user's secure information, and any other appropriate information.

[0156] In block 626, process 602 can authenticate and verify a data access request. For example, a data access request may include authentication credentials. The secure information manager can authenticate the authentication credentials via a software call to a blockchain service. For example, the blockchain service may return reliable information about the credentials from the blockchain that records the transaction of the credentials, such as the authorized entity to which the credentials have been assigned, the registered user to whom the credentials privileges apply, the expiration time of the credentials, the data points to which the credentials are granted privileges to access, or any other transaction information stored by the blockchain. The secure information manager can authenticate a data access request if the expiration timer has not expired and the authorized entity to which the credentials have been assigned matches the identifier of the authorized entity that issued the request.

[0157] A data access request may include an identifier of the authorized entity that issued the request, and the secure information manager can verify that the identifier of the authorized entity included in the data access request matches an authorized entity returned by the blockchain service. A data access request may also include user identification information that identifies a user, and the secure information manager can verify that the user information matches one of the registered persons managed by the secure information manager, a user associated with the authentication information returned by the blockchain service, or any combination thereof.

[0158] In block 628, process 602 can retrieve limited scope secure information in response to a data access request. For example, a secure information manager can query a secure data store that stores a user's secure information regarding the user information requested in the data access request.

[0159] In response to authenticated and verified data access requests, a secure information manager can generate data queries to retrieve scope-restricted secure user information from a secure data store. For example, a data query may be scope-restricted based on the scope privileges assigned to the authenticated credentials. In some embodiments, a data query may be generated in response to the data requested by the access request, and the secure information manager can then restrict the data query based on the privileges of the provided credentials. In another example, the secure user information requested by the data access request may be scope-restricted according to the privileges of the provided credentials, and a data query may be generated to retrieve scope-restricted data. The secure data store can then return scope-restricted secure user information in response to the data query.

[0160] In block 630, process 602 can provide the requesting system with restricted scope secure user information. For example, the secure information manager can return the secure user information requested by the data access request, or, if the provided credentials do not have access privileges to the entirety of the secure user information requested by the data access request, it can return a further restricted version of the secure user information requested by the data access request.

[0161] Figure 7 shows a flowchart for defining access restrictions for sharing user secure information according to an exemplary embodiment. Process 700 can be performed by a user system, such as a wireless device (e.g., a smartphone, tablet, etc.). Process 702 can be performed by a requesting system, such as a system of an authorized entity that issues an authentication information request to a secure information manager. Process 700 may be triggered when a user launches an information management application in a user system that manages the scope definition for sharing user secure information. Process 702 may be triggered when a requesting system scans the user system's display, such as a portable access point displayed through the user system.

[0162] In block 704, process 700 can receive timing parameters for sharing user secure information. For example, a user can provide timing parameters through a user system and applications launched within that user system. Users can define timing parameters by selecting the type of authentication information, such as perishable, episodic, and / or persistent, which corresponds to the type of timing parameter each user has. Users can define any other appropriate timing parameters.

[0163] In block 706, process 700 can receive range parameters for sharing user secure information. For example, a user can provide range parameters through a user system and an information management application launched within the user system. The range parameters can define portions of the user's secure information. The user's secure information may include electronic health records, and the range parameters can define parameters and parameter values ​​of the user's electronic health records.

[0164] For example, parameters for segmenting a user's electronic health record may include the issuing physician and / or healthcare institution (e.g., entity identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), date and time the information was generated, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. One or more of these electronic health record parameters may be further scope-defined according to parameter values ​​(e.g., date, subset of information type, subset of relevant medical practice, etc.). By providing scope-defining parameter values, users can define which portions of their electronic health data are shared through the information management application.

[0165] In block 708, process 700 can generate encoded information based on timing parameters and range parameters. For example, the encoded information can encode the authentication information type (representing the timing of the authentication information) and the range parameter (representing a portion of the user's secure information). Predefined mappings can map user health data segments (e.g., parameters and parameter values) to encoded character / symbol sequences. In one example, sequence formatting can define which strings map to parameters and which strings map to the values ​​of those parameters.

[0166] In block 710, process 700 can display a portable access point containing encoded information. For example, the displayed portable access point may include a user image, user identification information (some or all of which can be encoded), and generated encoded information representing authentication information type and range parameters.

[0167] In block 712, process 702 can scan a portable access point. For example, a scanning module of a requesting system (e.g., a computing system having an application configured to decode a camera and a portable access point) can scan a portable access point displayed via a user system. In block 714, process 702 can decode encoded information from a portable access point. For example, a scanning module of a requesting system can be configured to decode a portable access point, such as by extracting information displayed by the portable access point and / or decode the encoded information displayed by the portable access point. The decoded information may include timing parameters and range parameters defined by the user via an information management application.

[0168] In block 716, process 702 can generate an authentication credentials request using the extracted and / or decoded information. For example, an authentication credentials request may request credentials related to one or more pieces of information extracted and / or decoded from scanning a portable access point. An authentication credentials request may include user identification information, authentication credentials type and / or timing parameters, range parameters (e.g., a string of characters / symbols to map to a portion of the user's electronic health record), and other appropriate information (e.g., entity identification information).

[0169] In block 718, process 702 can send an authentication request to a secure information manager that manages the user's secure information. For example, the secure information manager can authenticate and / or verify the authentication request and, in response to the authentication request, issue authentication credentials to the requesting system (via interaction with the blockchain service).

[0170] Figure 8 shows a flowchart for retrieving scope-restricted user information from a secure data store and logging access, according to an exemplary embodiment. Process 800 can be performed, for example, by a secure information manager that, in response to a request from the computing system of an authorized entity, grants the authorized entity access to the user's secure information. Process 800 can be performed by one or more components of the secure data store. In another example, process 800 can be performed by one or more components of a blockchain service. In various embodiments, process 800 can be performed in a secure information manager, a secure data store, a blockchain service, or any combination thereof.

[0171] In block 802, process 800 can query the secure data store for user secure information. For example, an authorized entity may request a set of data points for its user secure information. The authorized entity can generate a data store query (e.g., SQL, or any other appropriate database query) to query all or part of the requested data points for the user's secure information. For example, the data store query may be restricted to the privileges of the authorized entity (e.g., the credentials assigned to the authorized entity).

[0172] In block 804, process 800 can receive scope-restricted user information from the secure datastore. For example, scope-restricted user information can be restricted by a formulated datastore query or by the datastore itself. The generated query is restricted to request secure information of a restricted range of users to which the authorized entity is permitted access. The datastore can return scope-restricted data points of secure information for users restricted to data points to which the authorized entity is permitted access.

[0173] In block 806, process 800 can provide scope-limited user information to the requesting system of the authorized entity. For example, the scope-limited data points of the user's secure information returned can be sent to the computing system of the authorized entity that issued the request.

[0174] In block 808, process 800 may log the request, authentication information, the scope of information accessed through the request, a timestamp, and other appropriate data related to the received request and scope of data. For example, a user's access to secure information may be logged in any appropriate data structure. The storage structure may be a blockchain, and each instance of a request and / or authorized access to a user's secure information is logged as a block in the blockchain. Exemplary logged information may include the scope of the requested data access (e.g., parameters relating to the user's secure information requested and their parameter values, character / symbol sequences representing such parameters and parameter values, etc.), authentication information and authorization provided (e.g., timing parameters, scope parameters, e.g., secure information parameters and parameter values, and / or character / symbol sequences representing such parameters and parameter values, etc.), a timestamp, an entity identifier (and, optionally, an identifier of a person associated with that entity), user identification information, secure user information provided in response to the request (e.g., parameters and parameter values ​​defining the portion of the accessed data), and any other appropriate information.

[0175] One or more predefined mappings may be associated with data access request logs. For example, a predefined mapping could map character / symbol sequences to parts of a user's secure information (e.g., parameters and parameter values ​​of electronic health data). A predefined mapping can be exposed to a private blockchain so that the mapping can be used to interpret credential privileges and / or data access requests that include the character / symbol sequences associated with the mapping.

[0176] Predefined mappings can be updated, for example, based on changes to user secure information (e.g., a change in the format of a user's electronic health record, a new user electronic health record, etc.). In response to the update, a new block can be appended to the private blockchain storing the predefined mappings, such that the updated mapping is stored as the latest block and the historical mapping is stored as the previous block. In this example, the computer systems involved can access the current predefined mappings via the latest block.

[0177] In block 810, process 800 may provide logged data in response to an audit request. A user (or any other appropriate entity or person) may be permitted to audit the user's access to secure information. Logged information, including the request, the limited scope of information accessed through the request, timestamps, and other appropriate data related to the received request and limited scope of data, may be provided to the user or other appropriate audit entity.

[0178] In an example where logged data for an access request includes a string of characters / symbols, a private blockchain managing a predefined mapping may be accessed to interpret the string. Once interpreted, the portion of the user's secure information represented by the string (e.g., parameters and parameter values ​​of the user's electronic health data) may be provided in response to an audit request. For example, a given access request's timestamp can be used to determine a given predefined mapping that was active during the given access request. This determined predefined mapping may be accessed via the private blockchain to interpret any string of characters / symbols logged for a given access request.

[0179] (With respect to a determined predefined mapping) the portion of a user's secure information represented by a string of characters / symbols may be provided in response to an audit request covering a given access request. For example, logged data provided for a given access request in response to an audit may include the scope of the requested data access (e.g., parameters and parameter values ​​relating to the requested user's secure information), provided credentials and permissions (e.g., timing parameters, scope parameters, e.g., secure information parameters and parameter values), timestamps, entity identifiers (and, if applicable, identifiers of persons associated with that entity), user identification information, secure user information provided upon request (e.g., parameters and parameter values ​​defining the portion of data accessed), and any other appropriate information.

[0180] User auditing of logged access to a user's secure user information via a secure information manager can be achieved using an information management application (e.g., a smartphone application, a web application, etc.). For example, the information management application can sort and display logged access by authorized entity, access date and time, etc. The information management application can list "instances" of access by date, etc., and the user can select an instance of access to expand on specific details of the access (e.g., authorized entity / registered identity, scope of access, etc.). In some embodiments, the information management application can log instances / versions of a user's portable access point and associate a given instance / version of the portable access point with each logged access by an authorized entity. This can assist in user inspection for unauthorized access attempts.

[0181] Privacy enforcement entities can also audit logs for individual users, individual certified entities, groups of users, or groups of certified entities. For example, a secure information manager (or any other privacy enforcement entity) can periodically review logged access by certified entities to a user's secure user information. If a user reports unauthorized access by a given certified entity, the privacy enforcement entity can audit the certified entity's access across multiple users to uncover other instances of unauthorized access by that entity. For example, if a pattern of unauthorized access is detected, the secure information manager can revoke the "certified" status of a certified entity.

[0182] The embodiment allows restricted access to a user's secure information using blockchain-backed credentials. Users can register with a secure information manager and control the scope to which their secure information is shared. For example, a user can allow authorized entities (e.g., service providers, healthcare providers, other individuals) to access their secure information via a portable access point. Users can select scope definitions that control how their secure information is shared with authorized entities. Authorized entities can scan the user's portable access point and request credentials to grant access to the user's secure information through the scan. For example, the credentials can be blockchain-backed credentials that are assigned access privileges corresponding to the user's selection.

[0183] Subsequently, the authorized entity can issue one or more data access requests using the credentials. For example, data access requests can be authenticated and verified by the Secure Information Manager. The Secure Information Manager can grant the authorized entity limited access to the user's secure information corresponding to the access privileges assigned to the credentials (based on the authenticated and verified data access requests). The user can revoke the credentials and / or the access privileges assigned to the authorized entity at any time. The access privileges assigned to the credentials may include an expiration timer, after which the credentials are no longer authenticated by the Secure Information Manager.

[0184] The embodiments achieve efficient and secure, granular user-controlled access to a user's secure information. For example, a user's portable access point is configured to efficiently define the conditions for sharing the user's secure information. In addition, issued credentials and a secure information manager enforce the user's sharing conditions in a trusted manner. In embodiments where credentials are blockchain-backed, blockchain-based management ensures that the credentials are authentic and mitigates fraudulent attempts to access the user's secure information.

[0185] The features, structures, or characteristics described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the use of “one embodiment,” “several embodiments,” “a particular embodiment,” “a number of particular embodiments,” or other similar phrases throughout this specification refers to the fact that a particular feature, structure, or characteristic described in relation to that embodiment may be included in at least one embodiment of this disclosure. Thus, the occurrence of the phrases “one embodiment,” “several embodiments,” “a particular embodiment,” “a number of particular embodiments,” or other similar phrases throughout this specification does not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0186] It will be readily apparent to those skilled in the art that the embodiments described above may be implemented by steps in a different order and / or by elements of a configuration different from those disclosed. Therefore, while this disclosure considers the embodiments outlined, it will be apparent to those skilled in the art that certain modifications, variations, and alternative structures will become apparent while remaining within the spirit and scope of this disclosure. Accordingly, the appended claims should be referenced to determine the scope and boundaries of this disclosure.

Claims

1. A method for allowing restricted access to a user's secure information, The secure information manager includes receiving an authentication request from the requesting system for one or more authentication credentials that authorize access to the user's secure information. The authentication information request includes user identification information, entity identification information, and a scope definition, and the requesting system generates the authentication information request in response to the scanning of the user's portable access point. The aforementioned method, The secure information manager verifies the user identification information and the entity identification information, Assigning blockchain authentication information having access privileges corresponding to the scope definition to the entity in response to the verification, It further includes, The aforementioned blockchain authentication information assignment is recorded on a private blockchain that manages the aforementioned blockchain authentication information. The aforementioned method, A method further comprising, in response to one or more access requests from the entity containing the assigned blockchain authentication information, granting access to the user's secure information, limited to the access privileges of the blockchain authentication information.

2. The user's portable access point includes encoded information, The method according to claim 1, wherein, in response to scanning of the portable access point, the requesting system is configured to decode the user identification information and range definition from the encoded information.

3. The user provides a selection via input on a portable device. The portable device is configured to generate the portable access point in response to the user selection. The method according to claim 2, wherein the requesting system scans the portable access point from the portable device.

4. The user selection corresponds to a segment identifier that defines a segment of the user's secure information selected by the user for sharing with the entity, The encoded information of the portable access point includes an encoded representation of the segment identifier, The requesting system is configured to decode the encoded representation of the segment identifier in response to scanning the portable access point. The method according to claim 3, wherein the range definition provided in the authentication information request includes the decoded segment identifier.

5. The method according to claim 4, further comprising mapping the range definition, which includes the decoded segment identifier, to a segment of the user's secure information using a predefined mapping, wherein the access privilege of the assigned blockchain authentication grants the entity access to the mapped segment of the user's secure information.

6. The method according to claim 5, further comprising using one or more blockchains of a blockchain manager to store one or more logs of the restricted access to the user's secure information, the logs comprising one or more of the identifier of the entity, the portion of the access request, the segment identifier of the user's secure information accessed by the entity, the timestamp of the access to the user's secure information, or any combination thereof, the one or more logs being recorded as blocks of the one or more blockchains.

7. The method according to claim 6, further comprising using the one or more blockchains of the blockchain manager to store the predefined mappings, wherein the predefined mappings include active mappings from among a plurality of predefined mappings recorded as blocks of the one or more blockchains.

8. The method according to claim 7, further comprising providing, in response to an audit request, audit information describing the scope-restricted access of the user to secure information over a period of time, wherein the audit information is generated by accessing the logs of the scope-restricted access of the user to secure information over the period of time and the stored predefined mappings, and by translating the mapped segment identifiers from the accessed logs using the stored predefined mappings.

9. The method according to claim 1, wherein the entity includes a certified entity that is certified after the execution of the certification workflow.

10. Allowing the aforementioned user to access secure information with limited scope is: In the secure information manager, receiving one or more access requests containing unauthenticated authentication information, The process involves authenticating the unauthenticated authentication information as the blockchain authentication information assigned to the entity via the private blockchain, In response to the authentication, grant access to the user's secure information, which is restricted to the access privileges of the blockchain authentication information. The method according to claim 1, further comprising:

11. A non-temporary computer-readable medium storing instructions, wherein, when executed by a processor, the instructions cause the processor to grant the processor restricted access to the user's secure information, and when executed, the instructions cause the processor to The secure information manager receives authentication requests from the requesting system for one or more authentication credentials that authorize access to the user's secure information. The authentication information request includes user identification information, entity identification information, and a scope definition, and the requesting system generates the authentication information request in response to the scanning of the user's portable access point. The aforementioned instruction further instructs the processor, The secure information manager verifies the user identification information and the entity identification information, Assigning blockchain authentication information having access privileges corresponding to the scope definition to the entity in response to the verification, Have them do it, The aforementioned blockchain authentication information assignment is recorded on a private blockchain that manages the aforementioned blockchain authentication information. The aforementioned instruction further instructs the processor, A non-temporary computer-readable medium that, in response to one or more access requests from the entity containing the assigned blockchain authentication information, allows access to the user's secure information, limited to the access privileges of the blockchain authentication information.

12. The user's portable access point includes encoded information, The non-temporary computer-readable medium according to claim 11, wherein the requesting system is configured to decode the user identification information and range definition from the encoded information in response to scanning of the portable access point.

13. The user provides a selection via input on a portable device. The portable device is configured to generate the portable access point in response to the user selection. The requesting system scans the portable access point from the portable device for the non-temporary computer-readable medium according to claim 12.

14. The user selection corresponds to a segment identifier that defines a segment of the user's secure information selected by the user for sharing with the entity, The encoded information of the portable access point includes an encoded representation of the segment identifier, The requesting system is configured to decode the encoded representation of the segment identifier in response to scanning the portable access point. The non-temporary computer-readable medium according to claim 13, wherein the range definition provided in the authentication information request includes the decoded segment identifier.

15. The aforementioned instruction further instructs the processor, The non-temporary computer-readable medium according to claim 14, wherein a predefined mapping is used to map the range definition, which includes the decoded segment identifier, to a segment of the user's secure information, and the access privilege of the assigned blockchain authentication information permits the entity to access the mapped segment of the user's secure information.

16. The aforementioned instruction further instructs the processor, A non-temporary computer-readable medium according to claim 15, wherein one or more blockchains of a blockchain manager are used to store one or more logs of restricted access to the user's secure information, the logs comprising one or more of the identifier of the entity, the portion of the access request, the segment identifier of the user's secure information accessed by the entity, the timestamp of the access to the user's secure information, or any combination thereof, and the one or more logs are recorded as blocks of the one or more blockchains.

17. The aforementioned instruction further instructs the processor, The non-temporary computer-readable medium according to claim 16, wherein the blockchain manager uses one or more blockchains to store the predefined mappings, the predefined mappings include an active mapping from a plurality of predefined mappings recorded as blocks of the one or more blockchains.

18. The aforementioned instruction further instructs the processor, The non-temporary computer-readable medium according to claim 17, which, in response to an audit request, provides audit information describing the user's restricted access to secure information over a certain period of time, wherein the audit information is generated by accessing the log of the restricted access to the user's secure information over the period of time and the stored predefined mappings, and by using the stored predefined mappings to convert mapped segment identifiers from the accessed log.

19. The non-temporary computer-readable medium according to claim 11, wherein the entities include certified entities that are certified after the execution of the certification workflow.

20. A system for allowing users restricted access to secure information, Processor and A memory for storing instructions to be executed by the aforementioned processor, Equipped with, The aforementioned instruction causes the processor to The secure information manager is configured to receive authentication information requests from the requesting system for one or more authentication credentials that authorize access to the user's secure information. The authentication information request includes user identification information, entity identification information, and a scope definition, and the requesting system generates the authentication information request in response to the scanning of the user's portable access point. The aforementioned instruction further causes the processor to The secure information manager verifies the user identification information and the entity identification information, Assigning blockchain authentication information having access privileges corresponding to the scope definition to the entity in response to the verification, Configure it to do the following: The aforementioned blockchain authentication information assignment is recorded on a private blockchain that manages the aforementioned blockchain authentication information. The aforementioned instruction further causes the processor to A system configured to respond to one or more access requests from the entity containing the assigned blockchain authentication information by granting access to the user's secure information, limited to the access privileges of the blockchain authentication information.

Images