Portable Access Point for Secure User Information Using Non-Fungible Tokens

Abstract

Embodiments use non-fungible tokens (NFTs) to grant scope-limited access to a user's secure information. A user can register with a secure information manager and control the scope to which the user's secure information is shared. For example, a user can grant a vetted entity access to the user's secure information via a portable access point. The user can select a scope definition that controls how the user's secure information is shared with the vetted entity. The vetted entity can scan the user's portable access point and request a credential. The credential can be an NFT that is assigned access privileges corresponding to the user's selection. The vetted entity can then issue a data access request using the credential. The secure information manager can grant the vetted entity scope-limited access to the user's secure information corresponding to the access privileges assigned to the NFT.

Description

[Technical Field]

[0001] Field Embodiments of the present disclosure generally relate to a secure storage system that uses non-fungible tokens to grant scope-limited access to users' secure information. [Background technology]

[0002] background The proliferation of computing and connected devices is generating vast amounts of data that require management. As data grows in size, the technical challenges associated with efficiently managing data become increasingly complex. For example, sharing secure data among multiple parties has been a long-standing problem in the data management field. Security techniques for users to manage secure information, such as authentication, verification, and permission workflows, can be cumbersome and impractical in some situations. In situations that create friction in traditional data sharing protocols, security protocols that enable practical and secure data sharing can provide considerable value. Summary of the Invention

[0003] overview

[0003] Embodiments of the present disclosure generally relate to a system and method for granting limited access to a user's secure information using credential authentication and user information verification. A credential request for one or more credentials granting access to the user's secure information can be received at a secure information manager, the request including a user identification, an entity identification, and a credential definition. The user identification and entity identification can be verified by the secure information manager. In response to the verification, a non-fungible token corresponding to the credential definition can be assigned to the entity, and the assignment of the non-fungible token is recorded on a private blockchain that manages the non-fungible tokens. In response to one or more access requests from the entity including the assigned non-fungible token, scope-limited access to the user's secure information corresponding to the access permissions of the non-fungible token can be granted.

[0004] The features and advantages of the embodiments will be set forth in or will be obvious from the description that follows, or may be learned by practice of the disclosure.

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

[0006] [Figure 1] FIG. 1 illustrates a system for granting scope-limited access to a user's secure information using non-fungible tokens according to an exemplary embodiment. [Figure 2] FIG. 1 is a block diagram of a computing device operatively coupled to a prediction system in accordance with an illustrative embodiment. [Figure 3] FIG. 1 illustrates a system for registering users for secure information management, according to an exemplary embodiment. [Figure 4A]FIG. 1 illustrates a system having a secure information manager that uses non-fungible tokens to grant scope-limited access to a user's secure information, according to an exemplary embodiment. [Figure 4B] FIG. 1 illustrates a system having a secure information manager that uses non-fungible tokens to grant scope-limited access to a user's secure information, according to an exemplary embodiment. [Figure 4C] FIG. 1 illustrates a system having a secure information manager that uses non-fungible tokens to grant scope-limited access to a user's secure information, according to an exemplary embodiment. [Figure 5] FIG. 1 illustrates a portable access point according to an exemplary embodiment. [Figure 6] FIG. 1 is a flow diagram for granting limited access to a user's secure information using credential authentication and user verification according to an example embodiment. [Figure 7] FIG. 10 is a flow diagram for retrieving scope-limited user information and logging access from a secure data store according to an example embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0007] Detailed Description Embodiments use non-fungible tokens to grant scope-limited access to a user's secure information. A user can register with a secure information manager and control the extent to which their secure information is shared. A user can grant vetted entities (e.g., service providers, healthcare providers, other individuals, etc.) access to their secure information via a portable access point. A user can also select a scope definition that controls how their secure information is shared with the vetted entities. A vetted entity can scan the user's portable access point and request a credential through the scan that grants access to the user's secure information. For example, the credential can be a non-fungible token (NFT), and the credential can be assigned access privileges corresponding to the user's selection.

[0008] The vetted entity can then issue one or more data access requests using the credential. The data access requests can be authenticated and verified by the secure information manager, which can grant the vetted entity scope-limited access to the user's secure information. The scope-limited access can correspond to access permissions assigned to the credential. The user can dynamically revoke the credential and / or the access permissions assigned to the vetted entity via the user's wireless device. The access permissions assigned to the credential can also include an expiration timer, after which the credential will no longer be authenticated by the secure information manager.

[0009] Embodiments provide efficient, secure, and fine-grained, user-controlled access to a user's secure information. A user can efficiently define sharing terms for the user's secure information via the user's portable access point. Furthermore, credentials issued from the user's portable access point and interaction with the secure information manager can reliably enforce the user's sharing terms. If the issued credentials are NFTs, blockchain-based management of the NFTs ensures the credentials are authentic and prevents fraudulent attempts to access the user's secure information.

[0010] An entity that can scan a user's portable access point and subsequently receive an issued credential can be an entity that has gone through a workflow. For example, the vetted entity can be an individual, an organization, a group of individuals, etc., and the vetted workflow can include one or more of identity verification, credential verification (e.g., government credential, medical credential, financial advisor credential, etc.), cybersecurity verification, and any other suitable vet. After going through the vetted workflow, the vetted entity can be issued a token wallet and / or an entity credential (e.g., a credential that verifies the request is from the vetted entity). By scanning the user's portable access point (via a computing system and a scanning component), the vetted entity can generate a credential request for a credential that includes authorization to access the user's secure information.

[0011] The portable access point may be a visual access point that, when scanned, may grant access to a user's secure information (e.g., stored and managed via a secure information manager). For example, the visual access point may consist of a visual representation of the user (e.g., a facial image) linked to the portable access point and coded information related to the range and / or permitted access of the user's secure information. The user may configure the portable access point and the coded information that is displayed.

[0012] For example, the portable access point may be displayed by an information management application running on a user's wireless device (e.g., a smartphone, tablet, etc.), and the user may interact with the information management application to select the scope of sharing of the user's secure information. The portable access point may be dynamic, such that user selections through the information management application generate different versions of the portable access point with different encoded information representations. For example, a user may define a sharing scope that identifies data points of the user's secure information that may be shared with a vetted entity through a portable access point scan. The user may also define a sharing scope for the period of time during which the user's secure information may be shared with a vetted entity through a portable access point scan.

[0013] One or more scanning elements of the vetted entity's computing system can scan the portable access point and generate a credential request using information from the portable access point. For example, the credential request can include one or more entity credentials, a user's identification information, a scope definition defining the requested credential's access rights to the user's secure information, and / or a credential version (e.g., a type of non-fungible token). The entity credentials can include credentials issued to the entity (e.g., issued to one or more users and / or identities associated with the entity) after the entity is vetted through a vetting workflow. Exemplary entity credentials include an access token (e.g., Security Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys or signatures, etc. The secure information manager can authenticate the entity credentials granted in the request before issuing an access credential (e.g., authorized to access the user's secure information) to the vetted entity.

[0014] The credential request from the vetted entity may include an information set that may include identifying information for the user, such as a user data set that identifies the user (e.g., full name, date of birth, hometown, state and / or zip code, physical appearance, etc.), an image of a government-issued document that identifies the user (e.g., driver's license, passport, etc.), biometric information (e.g., fingerprint, eye scan, DNA information, etc.), and other suitable identifying information for the user.

[0015] The credential request may also include a scope definition for the requested credentials. The scope definition may define the access permissions of the requested credentials to the user's secure information. In one example, the user's secure information may be electronic health data segmented based on parameters, and the scope definition may correspond to a limited portion of the user's electronic health data. Examples of parameters for segmenting the user's electronic health data include originating or attributing physician and / or medical institution (e.g., entity identifier), type of information (e.g., medications, tests and results, medical history, family history, biometrics, doctor-patient communications, doctor's notes, vaccine information, allergies, etc.), related medical practice (e.g., cardiology, primary care, neurology, oncology, etc.), information origination date, electronic health record format, other Health Level Seven (HL7) data parameters, or any other suitable medical data parameter. By providing parameter values ​​that define the scope, the user can define which portion of the user's electronic health data to share via the user's portable access point.

[0016] The credential request can be received by a secure information manager. The secure information manager can validate and authenticate the credential request and obtain the credential from the blockchain service in response to the request. For example, the secure information manager can send the obtained credential to a computing system of the vetted entity. The credential can be an NFT managed by the blockchain service, and the computing system of the vetted entity can include a token wallet associated with the vetted entity that stores the NFT.

[0017] After the credential is issued to the vetted entity, the vetted entity's computing system can issue a data access request using the credential. The data access request can include the issued credential, an identifier of the vetted entity issuing the request, and / or user identification information. The vetted entity's computing system can send the data access request to a secure information manager, which can verify and authenticate the data access request. After verifying and authenticating the data access request, the secure information manager can obtain scope-limited secure user information in response to the data access request and return the scope-limited secure user information to the vetted entity's computing system.

[0018] A data access request can define one or more data points of the 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 scope of the requested user's secure information. The secure information manager can retrieve secure user information corresponding to the requested data points included in the data access request. Sometimes, the secure information manager can retrieve secure user information corresponding 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 permission set of the vetted entity / provided credentials, the secure information manager can retrieve only the portion of the user data points covered by the scope permission set.

[0019] The secure information manager can manage any suitable user's secure information and manage data access requests from any suitable vetted entity. A given vetted entity can be any entity that performs services to a user, such as residential services (e.g., building or repairing a home), automotive services (e.g., repairing a user's car), medical services (e.g., medical services related to a doctor's office, hospital, emergency room, first responder, etc.), financial services (e.g., accounting, fiduciary services, financial advice, etc.), or technical 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 vetted entity can be a healthcare provider requesting 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 a credential (NFT) from the secure information manager and the blockchain service. Once the credential request from the healthcare provider is authenticated and verified, the blockchain service can issue the healthcare provider an NFT, i.e., a credential that provides the vetted entity with scope-limited access to the user's electronic health record.

[0020] A user can define which NFT to issue to a healthcare provider via an information management application running on the user's wireless device. For example, the user can select one of a first NFT (e.g., an ephemeral NFT), a second NFT (e.g., an episodic NFT), and / or a third NFT (e.g., a durable NFT), and the information management application can display a 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 NFT the user selected for the healthcare provider. The healthcare provider can scan the portable access point and issue a credential request to the secure information manager, and the credential request can include the NFT the user selected for the healthcare provider.

[0021] The user can also use the information management application to define access permissions for the NFTs requested through the scanning of the portable access point. For example, the user can select data points of the secure user information, segments of the data points, parameter values ​​used to group the data points, or any other suitable definition for dividing the user's secure information. A version of the user's portable access point generated in response to the user's selection can encode the access permissions for the NFTs that the user defines for the healthcare provider. The healthcare provider can scan the portable access point and issue a credential request to the secure information manager, where the credential request includes the access permissions that the user defined for the healthcare provider.

[0022] In response to the healthcare provider's credential request, the blockchain service and / or the secure information manager can issue an NFT to the healthcare provider that corresponds to the NFT selected by the user. The NFT can also be assigned access permissions defined by the user for the healthcare provider. When the healthcare provider's computing system receives the NFT, the system can issue a data access request to the secure information manager to access the user's electronic health record. To grant access, the secure information manager can authenticate the NFT through a smart contract call to the blockchain service. Once the NFT is authenticated, the secure information manager can grant the healthcare provider's system scoped access to the user's electronic health record, such as access limited to the permissions assigned to the NFT.

[0023] Access to a user's electronic health record by a healthcare provider using the issued NFT can be logged. For example, the blockchain service can log the history of accesses to a user's electronic health record on one or more private blockchains. The stored logs can support auditing of healthcare provider access to electronic health records.

[0024] Reference will now be made in detail to the embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth 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 may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. Where possible, the same reference numbers have been used to refer to the same elements.

[0025] 1 illustrates a system for granting scope-limited access to a user's secure information using non-fungible tokens according to an exemplary embodiment. Diagram 100 includes a user 102, a vetted entity 104, an authenticator and data controller 106, a credential service 108, and a secure data store 120. The vetted entity 104 can issue a request to the authenticator and validator 106 for access to the user's 102's secure information stored in the secure data store 108. The vetted entity 104 can be any suitable person, group of people, organization, company, or the like that goes through a vetted workflow.

[0026] The vetted entity 104 includes a computing system associated with the vetted entity. For example, an application in the computing system may allow a registered identity of the vetted entity 104 to log into the application. The vetted entity 104 and / or the entity's associated identities may be registered with one or more authorities. For example, the authenticator and data controller 106 may be a portion of a secure information manager that manages access to the secure data store 110, and the vetted entity 104 (and one or more registered identities of the vetted entity) may be registered with the authenticator and data controller 106.

[0027] The user 102 may be co-located (at the same physical location) with the computing system of the vetted entity 104, and the computing system of the vetted entity 104 may obtain user information from the user 102, such as by scanning the user's 102 portable access point. The portable access point may be a visual access point for the user's 102 secure information. For example, the portable access point may include a depiction of the user 102, such as a facial image, and encoded information, such as a QR code, a barcode, a symbol string (e.g., alphanumeric, hexadecimal, etc.), and any other suitable encoded information. The encoded information may represent the user's 102 identification information, a range definition corresponding to the user's 102 secure information, a time limit for access to the user's 102 secure information, and other suitable information.

[0028] The computing system of the vetted entity 104 can scan the user 102's portable access point and generate a credential request for access to the user's secure information stored in the secure data store 110. For example, the computing systems of the user 102 and the vetted entity 104 can be co-located, and the user's portable access point can be carried by the user 102 (e.g., displayed via an information management application running on the user's wireless device). In other examples, the user 102 and the vetted entity 104 can be remote from one another.

[0029] Upon scanning the user's 102 portable access point, the vetted entity's 104 computing system can issue a credential request to the authenticator and data controller 106 for a credential that grants access to the user's secure information stored in the secure data store 110. The credential request can include user identification information obtained by scanning the user's portable access point. The authenticator and data controller 106 can authenticate that the credential request originated through the user's 102 scanning the portable access point. For example, embedded information from the portable access point can be included in the request and authenticated by the authenticator and data controller 106. The authenticator and data controller 106 can further authenticate that the requesting system corresponds to a vetted entity, such as the vetted entity 104.

[0030] The credential request may also include a scope definition for the extent of the requested access (to the user's secure information). The embedded information from the portable access point may include these scope definitions. After authenticating the credential request, the authenticator and data controller 106 may request a credential from the credential service 108. The requested credential may be assigned access rights corresponding to the scope definition provided in the credential request.

[0031] The credential service 108 can issue a credential to the vetted entity 104. For example, the issued credential can be an NFT, and a private blockchain managed by the credential service 108 can record the issuance of the NFT (e.g., an identifier representing the vetted entity 104, such as a token wallet identifier) ​​to the vetted entity 104. The authenticator and data controller 106 can receive the credential from the credential service 108 and provide the credential to the vetted entity 104. In another example, the credential service 108 can provide the credential directly to the vetted entity 104.

[0032] After receiving the credential, the system of the vetted entity 104 can issue a data access request to the authenticator and data controller 106 for access to the secure information of the user 102 stored in the secure data store 110. The data access request can include the issued credential (e.g., an NFT), the identification information of the user 102 (e.g., identification information obtained via a portable access point, or any other suitable identification information), and an identifier of the vetted entity 104.

[0033] The authenticator and data controller 106 can authenticate the credentials included in the data access request and verify the user's identity. For example, the authenticator and data controller 106 can authenticate that the credentials in the data access request correspond to one or more credentials issued to the vetted entity 104. If the provided credentials are one or more NFTs, the authenticator and data controller 106 can verify the NFTs via the credential service 108. For example, the credential service 108 can include a private blockchain service that manages NFTs associated with the user 102 and access permissions to the user's 102's secure information stored in the secure data storage 110. The authenticator and data controller 106 can issue one or more application programming interface (API) calls (e.g., smart contract calls) to the credential service 108 to perform the authentication.

[0034] In response to these API calls, the credential service 108 can authenticate that the provided NFT is assigned to the vetted entity 104 and corresponds to the scope permissions defined for the secure information of the user 102. For example, a private blockchain managed by the credential service 108 can include an immutable ledger that records information about assigned NFTs. The private blockchain can record the identity of the user to whom the secure information is scoped by a given NFT (e.g., user 102), the scope definition corresponding to the given NFT, the entity to which the given NFT is assigned, entity assignment changes for the given NFT, etc.

[0035] The credential service 108 can authenticate the provided NFT against the private blockchain and verify that the NFT has been assigned to the vetted entity 104. In some implementations, the credential service 108 can also provide the authenticator and data controller 106 with a scope definition recorded on the private blockchain that corresponds to the NFT provided in the data access request. The scope definition can define the portions of the user's secure information that the provided NFT and the vetted entity 104 are allowed to access.

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

[0037] In response to the provided credentials and authentication of the vetted entity 104, as well as verification of the user 102's identity, the authenticator and data controller 106 can grant the vetted entity 104 range- and time-limited access to the user's secure information stored in the secure data store 110. For example, the range and time restrictions can be controlled by a range authorization granted to the provided credentials. The range authorization can be limited to the relationship between the vetted entity 104 and the user 102, or other suitable characteristics of the vetted entity 104. In another example, access can be limited to a period of time (e.g., days, weeks, months, etc.), after which the authenticator and data controller 106 will no longer grant access to the vetted entity 104 unless another request is issued that includes a credential authenticating via the credential service 108.

[0038] 2 is a block diagram of a computer server / system 210 according to an embodiment. As shown in FIG. 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 a memory 214. Additionally, a communication device 220 may enable connectivity between the processor 222 and other devices by encoding data transmitted 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.

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

[0040] Processor 222 may include one or more general-purpose or special-purpose processors for performing computational and control functions of system 210. Processor 222 may comprise a single integrated circuit, such as a microprocessing device, or may comprise multiple integrated circuit elements and / or circuit boards that cooperate to perform the functions of processor 222. Additionally, processor 222 may execute computer programs stored in memory 214, such as operating system 215, movement prediction component 216, and other applications 218.

[0041] The system 210 may include a memory 214 for storing information and instructions for execution by the processor 222. The memory 214 may include various components for acquiring, presenting, modifying, and storing data. For example, the memory 214 may store software modules that provide functionality when executed by the processor 222. The modules may include an operating system 215 that provides operating system functionality for the 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 operating system functionality for the system 210. The data access manager 216 may provide system functionality for granting scope-limited access to a user's secure information to vetted entities, or may further provide any other functionality of the present disclosure. In some cases, the data access manager 216 may be implemented as an in-memory configuration.

[0042] Non-transitory memory 214 may include various computer-readable media that can be accessed by processor 222. For example, 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-transitory computer-readable medium.

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

[0044] In some embodiments, system 210 may be part of a larger system. Accordingly, system 210 may include one or more additional functional modules 218 to include additional functionality. Other application modules 218 may include, for example, various modules of Oracle® Data Integrator, Oracle® Cloud Infrastructure, Oracle® Autonomous Database, Oracle® Cerner®, Oracle® Cerner® Millennium, Oracle® Cerner® HealtheIntent, Oracle® Cerner® Seamless Exchange, Oracle® Cerner® HealtheCare, Oracle® Blockchain, and Oracle® Cerner® HealtheLife, as well as representative products of the overall Oracle® Health & Artificial Intelligence platform. Database 217 is coupled to bus 212 to provide centralized storage for modules 216 and 218, storing, for example, enrollee verification information, vetted entity information, authentication and verification-related information, and the like. Database 217 may store data in an integrated collection of logically related records or files. Database 217 may be an operational database, an analytical database, a data warehouse, a distributed database, an end-user database, an external database, a navigational database, an in-memory database, a document-oriented database, a real-time database, a relational database, an object-oriented database, a Hadoop Distributed File System ("HFDS"), a disaster recovery database, a backup database, or any other database known in the art.

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

[0046] In one embodiment, system 210 may be separate from a device and may provide the functionality described for the device remotely. Furthermore, one or more components of system 210 may not be included. For example, for functionality as a user or consumer device, system 210 may be a smartphone or other wireless device that includes a processor, memory, and display, but does not include one or more other components shown in FIG. 2, and includes additional components not shown in FIG. 2.

[0047] Before a user's secure information is managed by the secure information manager, the user can register through a registration workflow. Once a user is registered with the secure information manager, the registered user can share the secure information via a portable access point that grants vetted entities scope-limited access to the registered user's secure information. Figure 3 illustrates a system for registering users for secure information management according to an exemplary embodiment.

[0048] Diagram 300 includes a user system 302, an application server 304, a broker 306, and a secure information service 308. User system 302 can be any suitable user client device, such as a smartphone, laptop, tablet, etc. Application server 304 can be any suitable computing device that hosts applications, such as applications displayed to a user via user system 302. For example, the applications can be web applications, native applications, any combination of these, or any other suitable applications.

[0049] A user can interact with the application and register an account through the user system 302. By creating a registered account, the user allows the secure information service 308 to store and manage the user's secure information. For example, registration can establish a user account that is linked to the user and the user's secure information that is stored and managed by the secure information service 308.

[0050] User system 302 may interact with application server 304 and / or broker 306 to execute the registration workflow, which in some embodiments may be separate from secure information service 308. Registering a user through a separate third-party entity (e.g., application server 304 and / or broker 306) may provide an increased level of integrity and reliability to the registration workflow.

[0051] In some examples, the user's secure information may include an electronic health record, and the third-party entity may be a government entity, a non-profit entity, a federated entity made up of multiple individual entities, or any other suitable entity that supports a transparent and trusted registration workflow that links electronic health records to users and supports secure storage of such electronic health records by secure information service 308. In these examples, the third-party entity may act as an intermediary that verifies user identity, the defined scope of the user's electronic health record that is to be stored by secure information service 308, and any other suitable aspects of the user's identity and secure information. The third-party entity may also support connections between different secure information services to ensure that the user's electronic health record is available for the user's examination and available to the user's healthcare provider.

[0052] To initiate the registration workflow, the application server 304 can generate a unique link or registration code for each user (e.g., delivered to the user system 302). Using the unique link or code, the user can access the application hosted by the application server 304 via the user system 302 and execute the registration workflow. In one example, 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 protect information. Any other suitable credentials (e.g., username and password, two-factor authentication address, shared secret, etc.) can be issued to the user.

[0053] To perform the registration workflow, the user provides user identification information, such as first name, middle name, last name, date of birth, home address, phone number, photograph (e.g., facial image), employment history, city of origin, social security number, user identifier for one or more electronic health records (e.g., identifier for a master patient index), gender, gender identity, ethnicity, and other suitable user information. The user may also provide biometric information (e.g., thumbprint or eye scan) via a biometric scanner to improve security measures and reliability of the registration workflow and the user's secure information management.

[0054] The broker 306 can verify the user's identity and associate a registration account created for the user with the user's verified identity. For example, the broker 306 can verify that the registration account is authorized to store electronic health records for the person verified as the user's identity. This verification can prevent fraudulent attempts to access another person's secure information.

[0055] Once the application server 304 and / or broker 306 perform the first portion of the registration workflow (e.g., receive user identification information and verify the user's identity), the secure information service 308 can create an account component for the user. The account component can include one or more portable access points for the user's secure information, the user's relationship definitions (e.g., defined relationships with other registered users or individuals), and any other suitable account components. The secure information service 308 can also aggregate the user's secure information as part of the registration workflow (or afterward). For example, the secure information service 308 can search, obtain, or otherwise aggregate secure information that the user has authorized the secure information service 308 to manage, for example, the user's electronic health record.

[0056] A user's registration account may also be tied to one or more portable access points. A portable access point may include a visual representation (e.g., an image) of the user and encoded information about the user's secure information, such as a range definition for sharing the user's secure information. Figure 5 illustrates 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 be an information management application that allows the user to define the scope for sharing the user's secure information through the generated portable access point. For example, the user can select one or more data points of the user's secure information, one or more default secure information data profiles, or define the scope for sharing the user's secure information in any other suitable manner.

[0058] The information management application can generate portable access points corresponding to the defined ranges and display the portable access points on the user system 302. A computing system of an external entity, such as a vetted entity, can scan for the portable access points and configure access to the user's secure information according to the defined ranges. Figures 4A, 4B, and 4C illustrate a system having a secure information manager that uses non-fungible tokens to grant range-limited access to the user's secure information, according to an example embodiment.

[0059] Diagram 400A includes a source 402, a requesting system 404, a secure information manager 406, secure user information 408, a scan 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 vetted entities, such as entities that have completed a vetting workflow with the secure information manager 406. The source 402 can include sources of user information, such as the user's body, a user identification document (e.g., driver's license, passport, etc.), the user's wireless device (e.g., smartphone), a portable access point for the user, and other suitable 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 for the user's portable access points. The user's portable access points can be displayed via the user's wireless device. For example, an information management application (e.g., a native application, a web application, etc.) running on the user's wireless device can allow the user to configure a portable access point for sharing the user's secure information. FIG. 5 illustrates a portable access point and the definition of range restrictions for the portable access point via the information management application, according to an embodiment. The user's portable access point can also be displayed by the user's wireless device on a lock screen (e.g., before entering a password), in the background of the wireless device, as an image stored in the wireless device's photo library, or via any other suitable display means.

[0061] The scanning module 410 may be a dedicated device configured to scan portable access points and obtain identifying user information for requests, such as a wireless device with an image capture component (e.g., a camera) and running an application configured to decipher portable access points. The scanning module 410 may obtain user identifying information from any other suitable element of the source 402.

[0062] In some examples, the source 402 may include a wireless device of a person who has a predefined relationship with the user. The user may be a registrant for whom the secure information manager 406 manages secure user information 408. The user may also register a predefined relationship with the secure information manager 406, such as a personal relationship (e.g., parent, spouse, child, friend, etc.), a business relationship (e.g., co-administrator of an enterprise application, etc.), or other suitable relationship. The person who has a predefined relationship with the user may own a wireless device that can provide the user's identification information to the requesting system 404. For example, any suitable user identification information provided by the user's wireless device (e.g., the user's portable access point) can be provided to the scan module 410 via the wireless device of the person who has the predefined relationship with the user. The participant's wireless device may be registered with the secure information manager 406 and equipped with an application that provides the user identification information.

[0063] In response to obtaining information from source 402, requesting system 404 and requester 412 can issue a credential request to secure information manager 406 for one or more access credentials that grant the user access to the secure information. For example, the requested credentials can be scoped to a user identified by user identification information (e.g., obtained via source 402). The requested credentials can grant requesting system 404 access to secure information 408 via secure information manager 406.

[0064] The credential request may further include user identifying information obtained via source 402 and scan module 412 (e.g., through a scan of the user's portable access point), as well as any other suitable information. The user identifying information may include full name, date of birth, social security number, local address and / or zip code, medical information (e.g., primary care physician, etc.), biometric information (e.g., fingerprint, eye scan, etc.), an identifier for the user's medical health record (e.g., master patient index identifier, medical record number, insurance claim identifier, etc.), make, model, and / or license plate, an image of government-issued identification (e.g., driver's license photo), an image of the user's face, etc. In some examples, the user identifying information may be an identifier (e.g., an alphanumeric string) decoded from the user's portable access point (e.g., by scan module 410) and any other suitable user identifying information obtained by a scan of the user's portable access point.

[0065] The credential request can also include a credential version. For example, a user (via an information management application running on the user's wireless device) can select a credential version (e.g., a type of NFT with a corresponding expiration timer), and the information management application can generate a portable access point that encodes the credential version. The scan module 410 can then decrypt the credential version, and the requester 412 can include the credential version in the credential request.

[0066] The user can provide a secure user code to complete the credential request. For example, the user may be prompted by the request system 404 to enter a username and password, a passcode, a key, a PIN, or any other suitable secure user code. During the registration workflow, the user may establish a username and password, a passcode, a key, a PIN, etc. The application of the request system 404 may be linked to a secure information manager 406, an honest broker, or any other suitable entity capable of verifying a user's username and password, passcode, key, PIN, etc. Once the application of the request system 404 verifies that the secure user code is valid, the application can authorize the request system 404 and the requester 412 to generate a credential request.

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

[0068] The secure information manager 406 may also verify the user identification information provided in the credential request. For example, the secure information manager 406 may verify that the credential request was generated by scanning the user's portable access point. Verification may include matching an identifier decrypted from the portable access point with a stored identifier for a registered user, verifying that additional user identification information provided in the request is verified against the stored user identification information of the matching registered user, verifying the credential version included in the credential request, and / or any other suitable verification.

[0069] Once the entity credentials are authenticated and the user identity is verified, the secure information manager 406 can issue a software call to the blockchain manager 414 for access credentials on behalf of the requesting system 404 (associated with the vetted entity). For example, the blockchain manager 414 can manage NFTs that serve as access credentials to the user's secure information.

[0070] The blockchain manager 414 can manage the blockchain 416 for the secure information manager 406. For example, the access credentials provided to a vetted entity (in response to an authenticated and verified credential request) can include an NFT managed by the blockchain manager 414. The NFT is linked to a user's secure information and can be assigned various levels of scope permissions to access the user's secure information. The blockchain 416 can include a blockchain ledger that records transactions of the NFT.

[0071] A blockchain is a list of records, each called a block, which can be cryptographically linked. In some blockchain implementations, each block contains a timestamp, a hash of the previous block, and transaction data. The timestamp proves that the block contained transaction data when it was added due to its hash. Because each block identifies its predecessor, a collection of blocks forms a chain, with each new block strengthening the collection of previous blocks in the chain. Therefore, blockchains are difficult to modify because once data is added to a blockchain, it cannot be changed without modifying subsequent blocks.

[0072] A non-fungible token (NFT) is a blockchain-backed identifier that designates a unique item. Assignment or ownership of these tokens can be tracked and verified through a distributed ledger (e.g., a blockchain). Such tokens may include an identifier for the unique item and / or a link to an image of the unique item (e.g., via a traditional URL or a distributed file system such as IPFS). The blockchain manager 418 manages the blockchain 416 and may include smart contracts 418 that execute in conjunction with the blockchain 416. The blockchain 416 can be a Hyperledger blockchain or any other suitable blockchain.

[0073] The blockchain manager 414 can manage different NFTs that grant various levels of access to a user's secure information. For example, a data access request from a vetted entity can be authenticated against the blockchain 416 via the blockchain manager 414 and smart contract 418 to verify that the NFT is an NFT managed by the blockchain manager 414, that the NFT was issued to the vetted entity that submitted the data access request, and / or that the NFT has not expired. Diagram 400B in FIG. 4B shows an example of a data access request 430 that includes an NFT issued by the blockchain manager 414.

[0074] The blockchain manager 414 may also include a minting component that mints NFTs that grant users varying levels of access to their secure information. Each minted NFT may include a unique long string identifier that individually identifies the NFT. The minted NFT may include information that links the NFT to the user whose secure information the NFT is authorized to access. The minted NFT may include any suitable user identification information described herein. The minted NFT may include non-fungible tokens, semi-fungible tokens, etc.

[0075] The blockchain manager 414 can issue one or more NFTs to a vetted entity in response to a smart contract call from the secure information manager 406. For example, a first NFT (e.g., a vanishing NFT) can provide access to a user's secure information for a limited period of time (e.g., a few hours, days, weeks, etc.). In this example, after the limited period of time has passed, the first NFT is no longer authenticated via the blockchain manager 414 and the blockchain 416. In some examples, a user can define an expiration timer (e.g., via an information management application running on the user's wireless device), and the definition can be included in the user's portable access point. This defined timer can be included in a credential request that the requesting system 404 issues through 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.

[0076] In another example, the second NFT (e.g., an episodic NFT) may provide access to the user's secure information for a predefined period of time (e.g., hours, days, weeks, etc.). In this example, after the predefined period of time, the second NFT is no longer authenticated via the blockchain manager 414 and the blockchain 416. In another example, the third NFT (e.g., a durable NFT) may provide access to the user's secure information permanently, or until the NFT is explicitly revoked.

[0077] In one example, the user's secure information may be an electronic health record, and the vetted entity may be a healthcare provider requesting access to the user's electronic health record. In this example, the healthcare provider may scan the user's portable access point (e.g., via the user's wireless device) and request a credential (NFT) from the blockchain manager 414. Once the credential request from the healthcare provider is authenticated and verified, the blockchain manager may issue the NFT to the healthcare provider.

[0078] A user can define which NFT to issue to a healthcare provider via the user's information management application running on the user's wireless device. For example, the user can select one of the first NFT, the second NFT, and / or the third NFT, and the information management application can display a 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 NFT the user selected for the healthcare provider. The healthcare provider can scan the portable access point and issue a credential request, which includes the NFT the user selected for the healthcare provider.

[0079] In this example, a user may select a first NFT (and define a timer) if the user anticipates that a healthcare provider will need limited access to the user's electronic health record for a short period of time, such as during an urgent care visit. In another example, the user may select a second NFT if the user anticipates that a healthcare provider will need access to the user's electronic health record for a medium period of time, such as during a surgery at a hospital the user does not visit frequently or during a specialist visit that the user does not anticipate returning to. In another example, the user may select a third NFT if the user anticipates that a healthcare provider will need access to the user's electronic health record for an extended period of time or indefinitely, such as when the healthcare provider is the user's primary care physician, a designated specialist for a long-term health issue, etc.

[0080] In other examples, the vetted entity can be another individual, such as an individual with a predefined relationship to the user (e.g., a family member, a close friend, etc.). The user can select a third NFT in such a case to ensure that the individual maintains access to the user's electronic health record. After the secure information manager 406 issues one or more smart contract calls, the blockchain manager 414 can issue one or more NFTs to the vetted entity based on the smart contract calls.

[0081] The blockchain manager 414 can mint NFTs on demand and / or store multiple pre-minted NFTs associated with a user. For example, an NFT can be minted on demand in response to a credential request consisting of user identification information, range authority corresponding to the credential request, timing restrictions and / or credential version (e.g., ephemeral, episodic, and / or durable), or any other suitable information from the credential request. The minted NFT can then be transferred to the vetted entity identifier from the credential request (e.g., the vetted entity's token wallet identifier), and this transfer can be recorded in the blockchain 416. An on-demand minted NFT can be created for the specific parameters of the credential request. For example, the credential request can be generated in response to a user selection in an information management application and / or a scan of the user's portable access point.

[0082] In another example, the blockchain manager 414 can assign a pre-minted NFT to the entity identified in the credential request. For example, the pre-minted NFT may include pre-defined range authorities, correspond to a particular NFT version (e.g., ephemeral, episodic, and / or durable), include user identification information that ties the NFT to a user, and / or include any other suitable information. The blockchain manager 414 can pre-mint multiple NFTs for a given user, each with a different combination of parameters. For example, multiple NFTs for each NFT version (e.g., ephemeral, episodic, and / or durable) can be pre-minted, and the multiple NFTs for a given NFT version can be assigned different pre-defined range authorities. Because pre-minted NFTs are not tailored to the specifications of a given credential request, many different versions of the pre-minted NFT can accommodate many different credential requests.

[0083] For example, the different pre-defined scope authorities may correspond to different scope templates defined by the user related to the user's secure information (e.g., pre-defined groupings or segments of the user's electronic health data), different templates based on feedback from the vetted entity regarding which portions of the user's secure information the entity needs, a global scope that allows broad access to the user's secure information, or any other suitable pre-defined scope authorities. The secure information manager 406 and / or blockchain manager 414 may match one of these pre-minted NFTs with the credential request and assign the matching pre-minted NFT to the vetted entity identified in the credential request.

[0084] The pre-minted entity can also include a blank set of range rights, and the secure information manager 406 can assign range rights to NFTs that match the credential request on demand. Thus, the pre-minted NFT can be matched to the credential request using the credential version, and the matching NFT can be assigned range rights specifically tailored to the credential request. The secure information manager 406 can communicate the rights assignments to the blockchain manager 414, which can append the rights assignments to the blockchain 416.

[0085] Some of the credential requests from the requesting system 404 can be generated by scanning a 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-minted NFTs. For example, the information management application can present the user with a set of limited range restrictions and / or limited timing constraints (e.g., credential versions), where each combination of range restrictions and timing constraints corresponds to one of the NFTs pre-minted by the blockchain manager 414. In this example, the secure information manager 406 and / or the blockchain manager 414 can match each credential request with the pre-minted NFT corresponding to that credential request.

[0086] Upon receiving the user's selection and displaying the portable access point to the user, the information management application on the user's wireless device may also provide the secure information manager 406 with an indicator identifying the particular portable access point (e.g., the particular combination of range and timing constraints) and the time the portable access point was displayed. The secure information manager 406 and / or the blockchain manager 414 may then mint an NFT corresponding to the portable access point definition on demand and / or select a pre-minted NFT that matches the portable access point definition. In this example, the secure information manager 406 has already selected an NFT for the portable access point definition before receiving the credential request from the requesting system 404. Upon receiving the credential request, the selected NFT may simply be forwarded to the vetted entity identified in the credential request.

[0087] In this example, any fraudulent use of this version of the user's portable access point at a later time can be traced back to the first time this version of the user's portable access point was displayed and to the vetted 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 fraud attempts may utilize a still image of the user's portable access point. A fraudster may take a photo of the user's portable access point and use the photo in a later attempt to request credentials that would provide access to the user's secure information. The version of the user's portable access point identifies the time and the vetted entity that scanned the portable access point, allowing fraudsters to be tracked and held accountable. In one embodiment, the version of the user's portable access point changes based on the time the version was generated, even if other access criteria remain the same. In this embodiment, a different version can be generated each time a user prepares their portable access point for a scan.

[0088] The vetted entity's requesting system 404 can receive the issued NFT via the blockchain manager 414. For example, the requesting system 404 can include an NFT wallet that stores the NFT (e.g., issued to the vetted entity upon completion of a vetted workflow). The requesting system 404 can receive the issued NFT from the secure information manager 406 or directly from the blockchain manager 414. Once received, the requesting system 404 can include the NFT in a data access request requesting access to the user's secure information.

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

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

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

[0092] In response to a credential request from a user's wireless device, the secure information manager 406 can provide the vetted entity's system with an access credential (e.g., an NFT, credential 432 in FIG. 4B ) corresponding to the credential request. For example, through interaction with the blockchain manager 414, the secure information manager 406 can provide a credential, such as one or more NFTs, with a range authorization corresponding to the credential request.

[0093] The blockchain manager 414 can mint an NFT in response to a credential request from a user's wireless device and provide the newly minted NFT to the vetted entity's computing system. In another example, the blockchain manager 414 can include an existing NFT (previously minted), and the blockchain manager 414 (and / or the secure information manager 406) can configure the existing NFT in response to the credential request. Configuring the existing NFT can include one or more of assigning the existing NFT to the vetted entity (e.g., to the vetted entity's token wallet), assigning range authority corresponding to the credential request to the existing NFT, etc.

[0094] Using the NFT issued to the vetted entity's computing system via the user's wireless device credential request as the requesting system 404, the vetted entity's computing system can issue one or more data access requests to the secure information manager 406. For example, the data access request may include the range of user secure information requested, the issued NFT, and / or any other suitable information.

[0095] Diagram 400B includes a requesting system 404, a secure information manager 406, secure user information 408, a blockchain manager 414, a blockchain 416, smart contacts 418, an audit log 424, a transaction log 426, an access request 430, and credentials 432. Similar to the example disclosed with reference to diagram 400A, requesting system 404 can be a system of a vetted entity, such as an entity that executed a vetted workflow with secure information manager 406.

[0096] Once the vetted entity is assigned a credential 432, such as an NFT, the user's wireless device may display, via the information management application, information identifying the vetted entity as the current owner of the NFT, which may grant the vetted entity access to the user's secure information in accordance with the access permissions associated with the NFT. In the same or another embodiment, the user's wireless device may display, via the information management application, a list of all vetted entities that own NFTs that grant access to the user's secure information, which may be grouped by the type, duration, and / or extent of access each of these vetted entities has with respect to the user's secure information.

[0097] Additionally, in some embodiments, a user may group and / or co-display NFT-managed data consumers (e.g., vetted entities) to which they have secure access along with non-NFT-managed data consumers to which they have secure access. For example, a user may manually update information about data consumers who have been manually granted access to certain secure user information, and those data consumers may be displayed along with information about NFT-managed data consumers. In one embodiment, the co-display includes an option to convert a non-NFT-managed data consumer to an NFT-managed data consumer using a clickable button on the user's wireless device via the information management application, which triggers the NFT management process described herein and transfers NFT ownership to the former non-NFT-managed data consumer. For example, a difference between an NFT-managed data consumer and a non-NFT-managed data consumer is that an NFT-managed data consumer can access (and in some embodiments, update) secure user information, such as an electronic health record, on an ongoing, periodic, or on-demand basis as new health data becomes available. While the user (or patient) can limit the scope or duration of this permission through the NFT, non-NFT-controlled data consumers can access and update health records to which the user or patient has manually granted permission. Typically, this is accomplished through a health data request form that the patient completes and faxes and / or emails (which remains the most common method at the time of filing) to the data producer for transmission to the data consumer.

[0098] The requesting system 404, i.e., the NFT management data consumer, can issue an access request 430 that includes credentials 432, which can be one or more NFTs issued to the requesting system 404 (and the vetted entity) by the blockchain manager 414. The access request 430 can include identifying information for the user, obtained by a scan of the user's portable access point and / or the user's full name, date of birth, social security number, local address and / or zip code, medical information (e.g., primary care physician, etc.), biometric information (e.g., fingerprint, eye scan, etc.), identifiers for the user's medical health record (e.g., master patient index identifier, medical record number, insurance claim identifier, etc.), make, model, and / or license plate, an image of government-issued identification (e.g., a driver's license photo), an image of the user's face, etc.

[0099] When access request 430 is received at secure information manager 406, credential authenticator 420 can authenticate credential 432 (e.g., an issued NFT) via one or more of smart contracts 418 of blockchain manager 418. Secure information manager 406 can also verify the user's identity against registered users to confirm that the request identifies a user matching the issued NFT. After credential 432 is authenticated and the user's identity is verified, data access controller 422 can issue one or more queries to secure user information 408 to obtain scope-limited secure user information.

[0100] The secure information manager 408 may log the request, the scope-limited information accessed via the request, a timestamp, and other suitable data related to the access request 430 and the scope-limited secure user information accessed. In some implementations, the secure information manager 408 may include an application log and / or an audit log. For example, the application log may log the transactions and activity of the application that grants scope-limited access in response to the data access request (e.g., access request 430). The audit log may log data similar to the application log that supports audits, such as user audits.

[0101] Access to a user's secure information may be logged in any suitable data structure. The blockchain manager 414 may store audit logs in a blockchain data structure to support auditing. The secure information manager 408 may invoke one or more smart contracts 418, which write log information to the audit log 424. For example, each request and / or instance of authorized access to a user's secure information may be logged as a block on the blockchain via a call to a smart contract 418. Application logs may also be stored by the blockchain manager 414 in the blockchain data structure.

[0102] The secure information manager 408 and / or the blockchain manager 414 can provide portions of the log in response to an audit request. A user (or any other suitable entity or person) can audit the user's access to secure information. Log information, including the request, the scope-limited information accessed via the request, a timestamp, and other suitable data related to the received request and the scope-limited data, can be provided to the user or other suitable auditing entity.

[0103] Diagram 400C of Figure 4C includes requesting system 404, secure information manager 406, secure user information 408, access request 430, credentials 432, data query 434, user information 436, scope-limited user information 438, and limited user information 440. Similar to the examples disclosed with reference to diagrams 400A and 400B, requesting system 404 can be a system of a screened entity, such as an entity that has executed a screening workflow with secure information manager 406.

[0104] 4B , the access request 430 and the credentials 432 can be authenticated and verified via the secure information manager 406. A data query 434 can be issued to obtain scope-limited secure user information from the secure user information 408, where such user information corresponds to the scope permissions of the credentials 432. The secure user information 408 can include secure information for multiple registrants, and the user information 436 can represent secure information stored about a user verified against the identification information included in the access request 430 and / or associated with the credentials 432. The secure information manager 406 can construct the data query 434 to obtain a portion of the user information 436.

[0105] User information 436 may consist of a set of data points for the user, and scope-limited user information 438 may consist of a subset of the data points. In one example where secure user information 408 includes electronic health record and user health data, the set of data points for user information 438 may consist of aggregated electronic health record data about the user, and the subset of data points for scope-limited user information 438 may consist of a portion of the aggregated electronic health data, such as metadata and / or summary data covering components of the aggregated electronic health record data, a predefined subset of the electronic health record (e.g., defined by the user, secure information manager 406, etc.), or any other suitable subset of data.

[0106] For example, scope-limited user information 438 can be predefined health data points designated by a user as accessible by any suitable vetted entity including authenticated credentials. In another example, scope-limited user information 438 can include health data points based on a predefined template, such as data points tailored for patient ingestion. Scope-limited user information 438 can include the user's blood type, pre-existing health conditions, previous surgeries, allergies, current medications, or any other suitable user health data. In one example where user information 436 is a segmented health record, the data points included in scope-limited user information 436 can be any suitable segments of the segmented health record.

[0107] The user information 436 can be electronic health data segmented based on parameters. For example, example parameters may include the originating physician and / or medical institution (e.g., entity identifier), the type of information (e.g., medications, tests and results, medical history, family history, biometrics, doctor-patient communication, doctor's notes, vaccine information, allergies, etc.), the associated medical procedure (e.g., cardiology, primary care, neurology, oncology, etc.), the information origination date, electronic health record format, other Health Level Seven (HL7) data parameters, or any other suitable medical data parameters. The user can define which portions of the user's electronic health data to share via the user's portable access point by providing parameter values ​​that define the scope. The permissions of the credentials 432 can then be scoped based on the user-defined parameters, and the secure information manager 406 can limit the data query 434 based on the permissions of the credentials 432.

[0108] In response to the authenticated and verified access request 430, the secure information manager 406 can issue a data query 434 to the secure user information 408. The secure information manager 406 can receive limited user information 440 from the secure user information 408, which may be scope-limited based on the range authority defined for the credential 432 (e.g., an NFT issued to the vetted entity / requesting system 404). The data query 434 can be generated in response to the data requested by the access request 430, and the secure information manager 406 can then limit the data query 434 based on the authority of the credential 432. In another example, the data requested by the access request 430 can be scope-limited according to the authority of the credential 432, and the data query 434 can be generated to obtain the scope-limited data. The limited user information 440 can be provided to the requesting system 404.

[0109] Role-based access control can also be applied to secure user information 408 to limit and restrict the scope of functionality and information for credentials 432 and the identities associated with the credentials (e.g., users, vetted entities, registered users of vetted entities, etc.). Each identity associated with credentials 432 can correspond to a role in the context of role-based access control. For example, an Administrator role may have full authority to view all information and perform any task, while a Clerk role can only view limited information about a particular consumer or patient where protected health information (PHI) or personal identifiable information (PII) attributes are hidden from that individual. In some implementations, role-based access control can be applied to data queries 434 such that limited user information 440 is retrieved by the query.

[0110] The vetted entity associated with credential 432 may include one or more enrollment identities. For example, the vetted entity may be an organization, and the enrollment identities may be people who are part of the organization. In some examples, the vetted entity may be a hospital, an emergency room organization, or a first responder organization, and the enrollment identities may be emergency room personnel and / or paramedics.

[0111] The request 430 may be issued with the registration ID of the vetted entity. For example, the request 430 may include an indicator of the vetted entity and the registration ID, such as credentials 432 that, when authenticated, identify the registration ID and the vetted entity. Any other suitable indicator may be included in the request 430.

[0112] The limited user information 440 can be scoped to the enrollment ID associated with the vetted entity issuing the request and / or the credentials 432 of the vetted entity or enrollment ID. For example, a paramedical enrollment ID may not provide the same level of care as an emergency room provider and, therefore, may require different levels of information depending on the care situation. Thus, a request from a paramedical enrollment ID may correspond to a first version of the limited user information 440, and a request from an emergency room personnel may correspond to a second version of the limited user information 440, where the first version differs from the second version. For example, the second version may include data points related to certain levels and activities of care that are not included in the first version.

[0113] Data access requests from vetted entities (e.g., requesting system 404) may vary in the registration ID issuing the request, the credentials included in the request, the scope of the user's secure information requested, and other suitable request parameters. For example, requesting system 404 may issue multiple requests over time to access the user's secure information using different credentials 432. As long as the credentials 432 have not expired, secure information manager 406 may authenticate the credentials and grant access to the user's secure information (limited in scope to the permissions of the credentials 432).

[0114] A user can edit the permissions assigned to a credential 432 via an information management application running on the user's wireless device. For example, the user's information management application, which controls the permission assignments for the user's portable access points and assigned credentials 432, can be linked to the secure information manager 406 and can edit the data points, secure user information segments, and / or parameter values ​​used to group the secure user information that the credential 432 is authorized to access. These edits can be stored in the secure information manager 406 and / or provided to the blockchain service via the smart contract 418. The blockchain service can add the edit permissions to the blockchain ledger, which defines the access permissions for the credential 432.

[0115] The editing can include revoking access rights assigned to the credential 432. When the credential 432 expires or its access rights are revoked, the requesting system 404 can send the credential back to the blockchain service that issued it, for example, for assignment to the same or another vetted entity. In some examples, the blockchain manager 414 can store multiple pre-minted NFTs, and credentials returned to the blockchain manager 414 after expiration and / or revocation can be returned to this pool of pre-minted NFTs (to await transfer to the next owner / vetted entity).

[0116] The vetted entity's token wallet that stores the credentials can be a dedicated token wallet that returns the credentials 432 to the blockchain manager 414 (or any other suitable issuing token wallet) when the credentials expire. For example, some of the credentials 432 can be NFTs with defined expiration times, and each token wallet can detect the expiration times and automatically return the expired credentials 432. Revocation of credentials 432 initiated by a user via an information management application on the user's wireless device can be processed at predetermined timing intervals (e.g., once daily, every 12 hours, every 6 hours, etc.). For example, the secure information manager 406 and / or the blockchain manager 414 can trigger revocation of credentials from the vetted entity's token wallet based on user-initiated revocation at each interval.

[0117] 5 illustrates a portable access point according to an example embodiment. Diagram 500 includes a wireless device 502, a portable access point 504, an image 506, and encoded information 508. An application running on wireless device 502 may display portable access point 504. For example, a system of a vetted entity may be configured to scan for portable access point 504 from wireless device 502. Wireless device 502 may display portable access point 504 in any other suitable manner.

[0118] The portable access point 504 may include an image 506, or a facial image of the user, and encoded information 508. The encoded information 508 may include a unique QR code or other suitable visual or symbolic (e.g., alphanumeric) code embedded relative to (e.g., on) the image 506. The QR code and / or symbolic code may utilize one or more of a holographic image, a raised holographic image, a pixelated code, a raised textured code, etc. For example, the encoded information 508 may be displayed on the image 506 as an embossed QR code having a unique encrypted long string identifier generated using an algorithm.

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

[0120] The unique encrypted long string identifier generated via the encrypted long string identifier algorithm can be dynamic, such that a new identifier is generated for each version of the portable access point 504 over a predefined period (e.g., every 2 hours, 4 hours, 6 hours, 12 hours, daily, etc.), or at any other suitable time. In this example, a secure information manager that manages the user's secure information can receive the dynamically generated identifier for the version of the portable access point. For example, the identifier can be dynamically generated via an information management application on the wireless device 502 that manages the user's portable access point, and the application can send the dynamically generated identifier 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 identifier to both the application that manages the user's portable access point and the secure information manager.

[0121] To prevent fraudulent attempts to request credentials through an older user's portable access point, the secure information manager can record one or more active long string identifiers for a given user. If the secure information manager receives a credential request that includes an inactive identifier, the request is rejected and the fraudulent attempt can be reported to support enhanced security measures.

[0122] The vetted entity's system can be configured to scan the portable access point 504, e.g., requesting system 404 and scanning module 410 of FIG. 4A. Once scanning module 410 scans the portable access point 504, requesting system 404 (e.g., an application configured to decrypt portable access point 504) can decrypt the encoded information 508 and / or image 506. For example, the application of requesting system 404 can decrypt a unique long string of digits (e.g., generated by a unique algorithm) and include the decrypted digits in the credential request, as described with reference to diagram 400A of FIG. 4A.

[0123] The user's secure user information bound to the portable access point 504 can be electronic health data segmented based on parameters. For example, parameters may include originating or attributing physician and / or medical institution (e.g., entity name or identifier), type of information (e.g., medications, tests and results, medical history, family history, biometrics, doctor-patient communication, doctor's notes, vaccine information, allergies, etc.), related medical procedure (e.g., cardiology, primary care, neurology, oncology, etc.), information origination date, electronic health record format, other Health Level Seven (HL7) data parameters, or any other suitable health data parameter. The user can define which portions of their electronic health data to share via the portable access point 504 by providing parameter values ​​that define ranges.

[0124] For example, through interaction with an application executing on the user's wireless device, the user may specify the following parameter values: originating physician and / or medical institution—ALL; type—medication, tests and results, medical history, family history, biometrics, vaccine information, and allergies; related medical procedures—cardiology, primary care physician, and neurology; information origination date—ALL; and electronic health record format—ALL. Other exemplary parameter values ​​related to the date of the information include the past two years, the past year, since age 18, a custom time range (e.g., January 1-31, 2023), etc. The user's electronic health data matching the parameter values ​​specified by the user may be scoped for sharing via the portable access point 504 and any issued credentials corresponding to the portable access point 504. The encoded information 508 may include encoded data parameter values ​​corresponding to the user's selections.

[0125] The wireless device 502 may display the portable access point 504 while the wireless device is offline, such as while the wireless device 502 lacks a connection to the Internet, a server hosting a component of an application that displays the portable access point 504, a cellular network and / or a wireless local area network, or any other suitable network connection. In this example, a component of an application executing locally on the wireless device 502 may display the portable access point 504.

[0126] The portable access point 504 may be displayed on an application's login screen, such as before a user logs into the application, thereby supporting display of the portable access point 504 without a network connection. A scanning component (e.g., the scanning module 410) of the screened entity may then scan the displayed portable access point 504, and the screened entity's system may leverage a network connection (e.g., a connection to the Internet) to perform the credential request and / or data access request.

[0127] 6 shows a flow diagram for granting limited access to a user's secure information using credential authentication and user verification, according to an example embodiment. In one embodiment, the functions of FIG. 6 (and FIG. 7 below) are implemented in software stored in memory or other computer-readable or tangible medium and executed by a processor. In other embodiments, the functions may be performed by hardware (e.g., through the use of application-specific integrated circuits ("ASICs"), programmable gate arrays ("PGAs"), field-programmable gate arrays ("FPGAs"), etc.), or any combination of hardware and software.

[0128] Process 600 may be performed by a requesting computing system, such as a computing system associated with a vetted entity that issues a request (e.g., a credential request and / or a data access request) to a secure information manager. Process 602 may be performed by a secure information manager (e.g., a cloud computing system or any other suitable computing system) that manages secure information for a user.

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

[0130] The portable access point may be a visual access point that, when scanned, may grant access to a user's secure information (e.g., stored and managed via a secure information manager). For example, the visual access point may consist of a visual representation of the user (e.g., a facial image) linked to the portable access point and coded information related to the scope and / or authorized access of the user's secure information. The requesting system and scanning component may be associated with a vetted entity, such as an entity that performed the vetted workflow. Examples of vetted entities may include a service provider (e.g., a system administrator, a healthcare provider, a hospital, etc.), a joint venture partner, a registrant in the secure information manager, or any other suitable vetted entity.

[0131] A user can configure the portable access point and the displayed coded information. For example, the portable access point can be displayed by an information management application running on the user's wireless device (e.g., a smartphone, tablet, etc.), and the user can interact with the information management application to select the scope of sharing of the user's secure information. The portable access point can be dynamic, such that user selections through the information management application generate different versions of the portable access point with different coded information displays. For example, a user can define a sharing scope that identifies data points of the user's secure information that can be shared with a vetted entity through a portable access point scan. The user can also define a sharing scope for the period of time that the user's secure information can be shared with a vetted entity through a portable access point scan.

[0132] At block 606, process 600 can generate a credential request in response to scanning the portable access point. For example, the requesting system can decrypt the user's portable access point and use the decrypted information to generate a request for one or more credentials. Encoded information displayed by the portable access point can be decrypted and included in the credential request. The information decrypted from the user's portable access point can 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, etc.), biometric information (e.g., fingerprint, eye scan, etc.), an identifier for the user's medical health record (e.g., master patient index identifier), make, model, and / or license plate, an image of government-issued identification (e.g., driver's license photo), an image of the user's face, etc.

[0133] The decrypted information from the user's portable access point may also include a range definition corresponding to the user's secure information. For example, the range definition may correspond to a credential version such as an ephemeral credential (limited time range), an episodic credential (predefined time range), or a durable credential (valid until revoked). In another example, the range definition may correspond to a limited range authority for the requested credential.

[0134] The user's secure information can be electronic health data segmented based on parameters, and limited scope permissions for requested credentials can correspond to limited portions of the user's electronic health data. For example, parameters can include the originating physician and / or medical institution (e.g., entity identifier), type of information (e.g., medications, tests and results, medical history, family history, biometrics, doctor-patient communication, doctor's notes, vaccine information, allergies, etc.), related medical practice (e.g., cardiology, primary care, neurology, oncology, etc.), information origination date, electronic health record format, other Health Level Seven (HL7) data parameters, or any other suitable medical data parameter. The user can define which portions of their electronic health data to share via their portable access point by providing parameter values ​​that define the scope.

[0135] At block 608, process 600 can send a credential request. For example, the requesting system can send a credential request to the secure information manager. The requesting system's credential request can be for a credential that grants the requesting system access to the user's secure information, which can be managed by the secure information manager. For example, the request details (e.g., user identification information, credential version, defined scope of secure user information permissions, etc.) can be provided by the user's portable access point. This allows the user to control how the user's secure information is shared with the requesting system.

[0136] The secure information manager can verify and authenticate the credential request and obtain the credential from the blockchain service in response to the request. The authentication and validation of the credential request and subsequent obtaining of the credential from the blockchain service are described with reference to blocks 618 and 620 of process 602. At block 610, process 600 can receive the credential. For example, the secure information manager can send the obtained credential to a requesting system. The credential can be an NFT managed by the blockchain service, and the requesting system can include a token wallet associated with the vetted entity that stores the NFT.

[0137] At block 612, process 600 may transmit a data access request including the received credentials. For example, the data access request including the received credentials, an identifier of the vetted entity issuing the request, and user identification information may be transmitted to a secure information manager. The secure information manager may verify and authenticate the data access request and obtain scope-limited secure user information in response to the data access request.

[0138] The data access request can define one or more data points of the 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 scope of the requested user's secure information. Additionally, the credentials issued to the vetted entity and provided in the data access request include scope authorization for the user's secure information. Authentication and validation of the data access request and subsequent retrieval of scope-limited secure user information are described with reference to blocks 626 and 628 of process 602.

[0139] At block 614, process 600 can receive scope-limited secure user information in response to the data access request. For example, the secure information manager can send the scope-limited user information to the requesting system. The received scope-limited user information can correspond to requested data points included in the data access request. In another example, the received scope-limited user information can correspond to requested portions of data points included in the data access request. If the data access request includes user data points outside the scope permission set of the vetted entity / provided credential, the secure information manager can retrieve and return only the portion of the user data points covered by the scope permission set.

[0140] Process 602 may be performed by a secure information manager receiving a request from a requesting system. At block 616, process 602 may receive a credential request. For example, as described with reference to block 608 of process 600, the secure information manager may receive the credential request from the requesting system. The credential request may include user identification information, a vetted entity's identifier and / or credentials, a credential version definition, a secure user information scope definition, and any other suitable information.

[0141] At block 618, the process 602 can authenticate and verify the credential request. For example, the credential request can include user identification information that the secure information manager verifies. The secure information manager can manage secure information for multiple registrants, and verification can match the user identification information provided in the credential request to one of the registrants.

[0142] The credential request may also include an identifier and / or identifying credentials for the vetted entity, and the secure information manager may authenticate the identifier and / or identifying credentials. For example, the identifier and / or identifying credentials included in the credential request (from a requesting system associated with the vetted entity) may include a unique identifier assigned to the vetted entity, a cryptographic key and / or digital signature generated via a cryptographic key assigned to the vetted entity, a unique token assigned to the vetted entity, or any other suitable data that can be used to authenticate the vetted entity.

[0143] At block 620, process 602 can obtain a credential corresponding to the credential request. User identity verification can match a registered user to the credential request, and identifier / credential authentication can match a vetted entity to the credential request. The secure information manager can then issue a software call to the blockchain service for a credential with scope permissions that grant the matching vetted entity scope-limited access to the secure information of the matching registered user. For example, the software call can include the registered user's identifier, the vetted entity's identifier, and the credential version included in the credential request from the requesting system.

[0144] The blockchain service can return the NFT to the secure information manager in response to the software call. For example, the blockchain service can host one or more blockchains that manage NFTs, where the NFTs are issued to vetted entities and serve as credentials that allow the vetted entities to access secure user information. The issued NFT can match the credential version included in the software call. The transaction issuing the NFT to the vetted entity can be added to the blockchain such that a record of the allocation is kept as an immutable ledger.

[0145] The software call by the secure manager can be a smart contract call, and the blockchain service can respond to the smart contract call by executing one or more smart contracts to return an NFT. For example, execution of the smart contract can issue an NFT to a token well identifier associated with the vetted entity and add the transaction to the governed blockchain. The added transaction can include additional information, such as an expiration timer for the issuance of the token to the vetted entity (e.g., as defined in the credential version), an identity of the vetted entity, identity information about the user, or any other suitable information.

[0146] The secure information manager can assign the range share authority (e.g., a range of secure user information data points) included in the credential request to the NFT. For example, data points, secure information segments, or other suitable portions of the user's secure information defined by the range share definition can be assigned as authorities for the NFT returned by the blockchain service, and the authority assignment can be stored by the secure information manager.

[0147] In another example, a software call from a secure information manager to a blockchain service for an NFT can include a range share definition, and the blockchain service can assign corresponding permissions to the NFT to access the user's secure information. For example, the blockchain service can add the range share definition (through execution of a smart contract) to the blockchain as part of a recorded transaction.

[0148] At block 622, the process 602 can transmit the credentials. For example, the secure information manager can transmit the obtained credentials to the requesting system. Alternatively, the blockchain service can transmit the credentials directly to the requesting system via another communication channel.

[0149] At block 624, process 602 may receive a data access request. For example, as described with reference to block 612 of process 600, the secure information manager may receive a data access request with one or more credentials from a requesting system. The data access request may include the credentials (e.g., an NFT), an identifier of the vetted entity issuing the request, user identification information, one or more requested data points of the user's secure information, and any other suitable information.

[0150] At block 626, process 602 can authenticate and verify the data access request. For example, the data access request can include credentials such as an NFT. The secure information manager can authenticate the NFT via a software call to a blockchain service. For example, the blockchain service can return trusted information about the NFT from a blockchain that records transactions related to the NFT, such as the vetted entity that assigned the NFT, the registered user to whom the NFT's permissions apply, the NFT's expiration date, the data points that the NFT is authorized to access, or any other transaction information that the blockchain stores. The secure information manager can authenticate the data access request if the expiration timer has not passed and the vetted entity that assigned the NFT matches the identifier of the vetted entity that issued the request.

[0151] The data access request may also include an identifier of the vetted entity that issued the request, and the secure information manager may verify that the identifier of the vetted entity included in the data access request matches the vetted entity returned by the blockchain service. Further, the data access request may include user identification information that identifies the user, and the secure information manager may verify that the user information matches one of the registrants managed by the secure information manager, a user associated with the NFT returned by the blockchain service, or any combination thereof.

[0152] At block 628, the process 602 can obtain scope-limited secure information in response to the data access request. For example, the secure information manager can query a secure data store that stores the user's secure information for the user information requested in the data access request.

[0153] The secure information manager can generate a data query to retrieve scope-limited secure user information from the secure data store in response to an authenticated and verified data access request. For example, the data query can be scope-limited based on scope permissions assigned to the authenticated credentials. Furthermore, the data query can be generated in response to data requested by the access request, and the secure information manager can then limit the data query based on the permissions of the provided credentials. In another example, the secure user information requested by the data access request can be scope-limited according to the permissions of the provided credentials, and the data query can be generated to retrieve the scope-limited data. The secure data store can return scope-limited secure user information in response to the data query.

[0154] In block 630, the process 602 can provide the scope-limited secure user information to the requesting system. The secure information manager can return the secure user information requested by the data access request or a scope-limited version of the secure user information requested by the data access request, for example, if the provided credentials do not have access to the entire secure user information requested by the data access request.

[0155] 7 shows a flow diagram for retrieving scope-limited user information from a secure data store and logging access, according to an example embodiment. Process 700 may be performed, for example, in response to a request from a computing system of the vetted entity by a secure information manager that authorized the vetted entity to access the user's secure information, one or more components of the secure data store, one or more components of a blockchain service, or any combination thereof.

[0156] At block 702, process 700 may query a secure data store for the user's secure information. For example, a vetted entity may request a set of data points for the user's secure information. A data store query (e.g., SQL, any other suitable database query) may be generated to query all or a portion of the vetted entity's requested data points of the user's secure information. For example, the data store query may be limited to the vetted entity's permissions (e.g., credentials assigned to the vetted entity).

[0157] At block 704, process 700 can receive scope-limited user information from the secure data store. For example, the scope-limited user information can be limited by a generated data store query or by the data store itself. The generated query can be limited to request a limited range of the user's secure information to which the vetted entity is permitted access. Additionally or alternatively, the data store can return scope-limited data points of the user's secure information that are limited to the data points to which the vetted entity is permitted access.

[0158] At block 706, process 700 can provide the scope-limited user information to the requesting system of the vetted entity. For example, the returned scope-limited data points of the user's secure information can be transmitted to the computing system of the vetted entity that issued the request.

[0159] At block 708, process 700 may log the request, the scope-limited information accessed through the request, a timestamp, and other suitable data related to the received request and scope-limited data. For example, access to a user's secure information may be logged in any suitable data structure. In some implementations, the storage structure comprises a blockchain, and each request and / or instance of authorized access to a user's secure information is logged as a block in the blockchain.

[0160] At block 710, process 700 may provide logged data in response to an audit request. For example, a user (or any other suitable entity or person) may be authorized to audit the user's access to secure information. Log information including the request, the scope-limited information accessed via the request, a timestamp, and other suitable data related to the received request and the scope-limited data may be provided to the user or other suitable auditing entity.

[0161] Embodiments use non-fungible tokens to grant scope-limited access to a user's secure information. A user can register with a secure information manager and control the extent to which their secure information is shared. A user can grant vetted entities (e.g., service providers, healthcare providers, other individuals, etc.) access to their secure information via a portable access point. A user can also select a scope definition that controls how their secure information is shared with the vetted entities. A vetted entity can scan the user's portable access point and request a credential through the scan that grants access to the user's secure information. For example, the credential can be a non-fungible token (NFT), and the credential can be assigned access privileges corresponding to the user's selection.

[0162] The vetted entity can then issue one or more data access requests using the credential. The data access requests can be authenticated and verified by the secure information manager, which can grant the vetted entity scope-limited access to the user's secure information. The scope-limited access can correspond to access permissions assigned to the credential. The user can dynamically revoke the credential and / or the access permissions assigned to the vetted entity via the user's wireless device. The access permissions assigned to the credential can also include an expiration timer, after which the credential will no longer be authenticated by the secure information manager.

[0163] Embodiments provide efficient, secure, and fine-grained, user-controlled access to a user's secure information. A user can efficiently define sharing terms for the user's secure information via the user's portable access point. Furthermore, credentials issued from the user's portable access point and interaction with the secure information manager can reliably enforce the user's sharing terms. If the issued credentials are NFTs, blockchain-based management of the NFTs ensures the credentials are authentic and prevents fraudulent attempts to access the user's secure information.

[0164] The features, structures, or characteristics of the present disclosure described throughout this specification can be combined in any suitable manner in one or more embodiments. For example, the use of "one embodiment," "some embodiments," "an embodiment," "a plurality of some embodiments," or other similar phrases throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases "one embodiment," "some embodiments," "a plurality of some embodiments," or other similar phrases throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0165] Those skilled in the art will readily appreciate that the above-described embodiments may be practiced with steps in a different order and / or elements in a different configuration than that disclosed. Accordingly, while this disclosure discusses general embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations will be apparent while remaining within the spirit and scope of the disclosure herein. Accordingly, reference should be made to the appended claims to determine the metes and bounds of the present disclosure.

Claims

1. 1. A method for granting limited access to a user's secure information, comprising: receiving, at a secure information manager, a credential request for one or more credentials that authorize access to the user's secure information; the request includes a user identification, an entity identification, and a credential definition; The method comprises: verifying the user identity and the entity identity with the secure information manager; and in response to the validation, assigning a blockchain credential to the entity corresponding to the credential definition; The assignment of the blockchain credential is recorded on a private blockchain that manages the blockchain credential; The method comprises: In response to one or more access requests from the entity including the assigned blockchain credential, the method further includes granting scope-limited access to the user's secure information corresponding to access permissions of the blockchain credential.

2. granting scope-limited access to the user's secure information; receiving the one or more access requests at a secure information manager, the access requests including unauthenticated credentials; authenticating the unauthenticated credentials as the non-fungible token assigned to the entity via the private blockchain; 2. The method of claim 1, further comprising: in response to the authentication, granting the scope-limited access to the user's secure information corresponding to access permissions of the non-fungible token.

3. The method of claim 1 , wherein the entity comprises a reviewed entity that is reviewed after execution of a review workflow.

4. 2. The method of claim 1, wherein the scope-limited access to the user's secure information includes access to scope-limited data points of the user's secure information, the scope-limited data points including a predefined correspondence to the access permissions to the non-fungible token assigned to the entity.

5. 2. The method of claim 1, wherein the scope-limited access to the user's secure information provided by the assigned non-fungible token includes access to the user's secure information for a limited time period, the limited time period corresponding to the access permissions of the non-fungible token assigned to the entity.

6. the credential request received at the secure information manager is transmitted by a computing system of the entity; the computing system of the entity generates the credential request by scanning the user's portable access point, which encodes at least a portion of the user identification information and a credential version; The method of claim 1 , wherein the portion of the user identification information and the credential definition are obtained by the computing system of the entity through a scan of the portable access point.

7. The method of claim 6 , wherein the user selects the credential definition via input on a wireless device, and the wireless device generates the portable access point in response to the selection of the credential definition.

8. 10. The method of claim 1, further comprising storing one or more logs of the scope-limited accesses to the user's secure information, the logs including one or more of an identifier of the entity, a portion of the request, the user's secure information accessed by the entity, a timestamp of the access of the user's secure information accessed, or any combination thereof, and the one or more logs are recorded as blocks in an immutable blockchain.

9. The method of claim 8 , further comprising providing at least a portion of the one or more stored logs in response to an audit request from the user.

10. A non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor, grant the processor limited access to a user's secure information, the instructions, when executed, causing the processor to: receiving, at a secure information manager, a credential request for one or more credentials that authorize access to the user's secure information, the request including a user identification, an entity identification, and a credential definition; verifying the user identity and the entity identity with the secure information manager; In response to the verification, assigning a non-fungible token corresponding to the credential definition to the entity, the assignment of the non-fungible token being recorded on a private blockchain that manages the non-fungible token; A non-transitory computer-readable medium that, in response to one or more access requests from the entity that includes the assigned non-fungible token, grants scope-limited access to the user's secure information corresponding to the access permissions of the non-fungible token.

11. granting scope-limited access to the user's secure information; receiving the one or more access requests at a secure information manager, the access requests including unauthenticated credentials; authenticating the unauthenticated credentials as the non-fungible token assigned to the entity via the private blockchain; 11. The non-transitory computer-readable medium of claim 10, further comprising: in response to the authentication, granting the scope-limited access to the user's secure information corresponding to access permissions of the non-fungible token.

12. The non-transitory computer-readable medium of claim 10 , wherein the entities include reviewed entities that are reviewed after execution of a review workflow.

13. 11. The non-transitory computer-readable medium of claim 10, wherein the scope-limited access to the user's secure information includes access to scope-limited data points of the user's secure information, the scope-limited data points including a predefined correspondence to the access permissions to the non-fungible token assigned to the entity.

14. 11. The non-transitory computer-readable medium of claim 10, wherein the scope-limited access to the user's secure information provided by the assigned non-fungible token comprises access to the user's secure information for a limited time period, the limited time period corresponding to the access permissions of the non-fungible token assigned to the entity.

15. the credential request received at the secure information manager is transmitted by a computing system of the entity; the computing system of the entity generates the credential request by scanning the user's portable access point, which encodes at least a portion of the user identification information and a credential version; The non-transitory computer-readable medium of claim 10 , wherein the portion of the user identification information and the credential definition are obtained by the computing system of the entity through a scan of the portable access point.

16. 16. The non-transitory computer-readable medium of claim 15, wherein the user selects the credential definition via input on a wireless device, and the wireless device generates the portable access point in response to the selection of the credential definition.

17. The instructions further cause the processor to:

11. The non-transitory computer-readable medium of claim 10, storing one or more logs of the scope-limited accesses to the user's secure information, the logs including one or more of an identifier of the entity, a portion of the request, the user's secure information accessed by the entity, a timestamp of the access of the user's secure information accessed, or any combination thereof, and the one or more logs recorded as blocks in an immutable blockchain.

18. The instructions further cause the processor to:

20. The non-transitory computer-readable medium of claim 17, wherein the non-transitory computer-readable medium provides at least a portion of the one or more stored logs in response to an audit request from the user.

19. 1. A system for granting limited access to a user's secure information, the system comprising: a processor; a memory storing instructions for execution by said processor, said instructions causing said processor to: receiving, at a secure information manager, a credential request for one or more credentials that authorize access to the user's secure information, the request including a user identification, an entity identification, and a credential definition; verifying the user identity and the entity identity with the secure information manager; In response to the verification, assigning a non-fungible token corresponding to the credential definition to the entity, the assignment of the non-fungible token being recorded on a private blockchain that manages the non-fungible token; In response to one or more access requests from the entity including the assigned non-fungible token, the system is configured to grant scope-limited access to the user's secure information corresponding to the access permissions of the non-fungible token.

20. granting scope-limited access to the user's secure information; receiving the one or more access requests at a secure information manager, the access requests including unauthenticated credentials; authenticating the unauthenticated credentials as the non-fungible token assigned to the entity via the private blockchain; 20. The system of claim 19, further comprising: in response to the authentication, granting the scope-limited access to the user's secure information corresponding to access permissions of the non-fungible token.

Images