Portable access point for secure user information using non-homogenized token

Abstract

Embodiments allow for range-limited access to security information of a user using non-homogenous token (NFT). A user is able to register with a security information manager and control a range in which security information of the user is shared. For example, a user can allow a reviewed entity to access security information of the user via a portable access point. The user can select a range definition that controls how the user's security information is shared with the reviewed entity. A reviewed entity can scan a user's portable access point and request credentials. The credential can be an NFT assigned an access privilege corresponding to the user's selection. The reviewed entity can then issue the data access request (s) using the credentials. The security information manager can allow a reviewed entity to make a limited range of access to the security information of the user corresponding to the access privileges assigned to the NFT.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to one or more secure storage systems that allow limited access to a user's security information using one or more non-fungible tokens. Background Art

[0002] The proliferation of computing devices and connected devices has generated a large amount of data that requires management. As the scale of data has grown, the technical challenges associated with efficiently managing data have become increasingly complex. For example, sharing secure data among multiple parties has been a long-standing problem in the field of data management. Secure technologies that allow users to manage security information, such as authentication, verification, and authorization workflows, can be cumbersome and impractical in some scenarios. In scenarios where there is friction with traditional data sharing protocols, security protocols that enable practical secure data sharing can provide great value. Summary of the Invention

[0003] Embodiments of the present disclosure generally relate to systems and methods for allowing limited access to a user's security information using credential authentication and user information verification. A credential request for one or more credentials to allow access to the user's security information can be received at a security information manager, the request including user identification information, entity identification information, and a credential definition. The user identification information and the entity identification information can be verified by the security information manager. In response to the verification, a non-fungible token corresponding to the credential definition can be assigned to the entity, where the non-fungible token assignment is recorded on a private blockchain that manages non-fungible tokens. In response to one or more access requests from the entity including the assigned non-fungible token, limited access corresponding to the access permission of the non-fungible token can be allowed to the user's security information.

[0004] The features and advantages of the embodiments are set forth in the following description, or will be apparent from the description, or may be learned through the practice of the present disclosure. Brief Description of the Drawings

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

[0006] Figure 1 Illustrates a system for allowing limited access to a user's security information using non-fungible tokens according to an example embodiment.

[0007] Figure 2 Illustrates a block diagram of a computing device operationally coupled to a prediction system according to an example embodiment.

[0008] Figure 3Illustrates a user registration system for security information management according to an exemplary embodiment.

[0009] Figure 4A 、 Figure 4B and Figure 4C Illustrates a system with a security information manager according to an exemplary embodiment, which allows limited access to a user's security information using non-fungible tokens.

[0010] Figure 5 Illustrates a portable access point according to an exemplary embodiment.

[0011] Figure 6 Illustrates a flowchart for allowing limited access to a user's security information using credential authentication and user verification according to an exemplary embodiment.

[0012] Figure 7 Illustrates a flowchart for retrieving limited user information from a security data repository and logging the access according to an exemplary embodiment. Detailed Description

[0013] The embodiment allows limited access to a user's security information using non-fungible tokens. A user can register with the security information manager and control the scope of sharing the user's security information. The user can allow vetted entities (e.g., service providers, healthcare providers, other individuals, etc.) to access the user's security information via a portable access point. The user can also select a scope definition that controls how the user's security information is shared with the vetted entity. The vetted entity can scan the user's portable access point and request a credential to allow access to the user's security information via the scan. For example, the credential can be a non-fungible token (NFT), and access privileges corresponding to the user's selection can be assigned to the credential.

[0014] Then, the vetted entity can issue one or more data access requests using the credential. The (one or more) data access requests can be authenticated and verified by the security information manager, and the security information manager can allow the vetted entity to have limited access to the user's security information. The limited access can correspond to the access privileges assigned to the credential. The user can dynamically revoke the access privileges assigned to the credential and / or the vetted entity via the user's wireless device. The access privileges assigned to the credential can also include an expiration timer, after which the credential will no longer be authenticated by the security information manager.

[0015] The implementation realizes fine-grained user control access to the user's security information, and such access is efficient and secure. Via the user's portable access point, the user can efficiently define the sharing conditions of the user's security information. In addition, the (one or more) credentials issued by interacting with the user's portable access point and the security information manager can enforce the user's sharing conditions in a trustworthy manner. When the issued (one or more) credentials are (one or more) NFTs, the blockchain-based management of the (one or more) NFTs ensures that the credentials are authentic and mitigates fraudulent attempts to access the user's security information.

[0016] The entity that can scan the user's portable access point and receive the subsequently issued credentials can be an entity that has gone through a workflow. For example, the entity that has been reviewed can be an individual, an organization, a group of individuals, etc., and the review workflow can include one or more of the following: identity verification, credential verification (e.g., government credentials, medical credentials, financial advisor credentials, etc.), network security verification, and any other appropriate review. After going through the review workflow, a token wallet and / or (one or more) entity credentials (e.g., credentials confirming that the request comes from the reviewed entity) can be issued to the reviewed entity. The reviewed entity can generate a credential request for a credential that includes the privilege of accessing the user's security information by scanning (via a computing system and a scanning component) the user's portable access point.

[0017] The portable access point can be a visual access point, which can allow access to the user's security information (e.g., stored and managed via the security information manager) when scanned. For example, the visual access point can include a visual representation of the user associated with the portable access point (e.g., a facial image) and encoded information related to the scope of the user's security information and / or the permitted access. The user can configure the portable access point and the displayed encoded information.

[0018] For example, the portable access point can be displayed via an information management application executed on the user's wireless device (e.g., a smart phone, a tablet, etc.), and the user can interact with the information management application and select the sharing scope of the user's security information. The portable access point can be dynamic, such that different versions of the portable access point with different encoded information displays are generated by the user's selection via the information management application. For example, the user can define a sharing scope that identifies the data points of the user's security information that can be shared with the reviewed entity via the scanning of the portable access point. The user can also define the sharing scope for a time period during which the user's security information can be shared with the reviewed entity via the scanning of the portable access point.

[0019] One or more scanning elements of a (one or more) computing system of a vetted entity may scan a portable access point and generate a credential request using information from the portable access point. For example, the credential request may include: one or more entity credentials; identification information of a user; a scope definition defining access privileges of the requested credentials relative to the user's security information; and / or a credential version (e.g., type of non-fungible token). The (one or more) entity credentials may include credentials issued to the entity after the entity has been vetted through a vetting workflow (e.g., issued to one or more users and / or identities associated with the entity). The (one or more) example entity credentials include access tokens (e.g., Security Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys or signatures, etc. A security information manager may authenticate the entity credentials provided in the request before issuing access credentials (e.g., having the privilege to access the user's security information) to the vetted entity.

[0020] A credential request from a vetted entity may include a collection of information. The collection of information may include identification information of a user, such as: a collection of user data identifying the user (e.g., full name, date of birth, city of residence, state, and / or zip code, appearance, etc.), an image of a government-issued document identifying the user (e.g., driver's license, passport, etc.), biometric information (e.g., fingerprint, eye scan, DNA information, etc.), and other suitable identification information of the user.

[0021] The credential request may also include a scope definition of the requested credentials. The scope definition may define the access privileges of the requested credentials relative to the user's security information. In an example, the user's security 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. Example parameters for segmenting the user's electronic health data include: the originating or affiliated doctor and / or healthcare facility (e.g., (one or more) entity identifiers), the type of information (e.g., medications, tests and results, medical history, family history, biometrics, doctor-patient communications, doctor notes, vaccine information, allergies, etc.), the relevant health practice (e.g., cardiology, primary care, neurology, oncology, etc.), the date the information was originated, the electronic health record format, other Health Level Seven (HL7) data parameters, or any other suitable health data parameters. The user may define which portions of the user's electronic health data are to be shared via the user's portable access point by providing parameter values defining the scope.

[0022] A credential request can be received at a security information manager. The security information manager can verify and authenticate the credential request and obtain a credential from a blockchain service in response to the request. For example, the security information manager can transmit the obtained credential to the computing system(s) of the vetted entity. The credential can be an NFT managed by the blockchain service, and the computing system(s) of the vetted entity can include a token wallet affiliated with the vetted entity storing the NFT.

[0023] After issuing the credential to the vetted entity, the computing system(s) of the vetted entity can use the credential to issue a data access request(s). The data access request can include the issued credential, an identifier of the vetted entity issuing the request, and / or user identification information. The computing system(s) of the vetted entity can transmit the data access request to the security information manager, and the security information manager can verify and authenticate the data access request. After verifying and authenticating the data access request, the security information manager can retrieve limited-scope security user information in response to the data access request and return the limited-scope security user information to the computing system(s) of the vetted entity.

[0024] Some data access request(s) can define one or more data points of a user's security information. For example, the user's security information can be electronic health data segmented based on parameters. The data access request can include specific parameter values defining the scope of the requested user's security information. The security information manager can retrieve the security user information corresponding to the requested data point(s) included in the data access request. Sometimes, the security information manager can retrieve the security user information corresponding to a part of the requested data point(s) included in the data access request. For example, when the data access request includes user data points outside the set of scope privileges of the vetted entity / provided credential(s), the security information manager can retrieve only the part of the user data points covered by the set of scope privileges.

[0025] A security information manager can manage security information for any suitable user and manage data access requests from any suitable vetted entity. A given vetted entity can be any entity that performs a service for a user, where the service is such as a home service (e.g., home construction, repair, etc.), an automotive service (e.g., repairing the user's car), a medical service (e.g., medical services related to a doctor's office, hospital, emergency room, first responders, etc.), a financial service (e.g., accounting, fiduciary services, financial advice, etc.), a technical service (e.g., system administrator services, web hosting, etc.), and so on. In an example, the user's security information can be an electronic health record, and the vetted entity can be a healthcare provider that requests access to the user's electronic health record. In this example, the healthcare provider can scan the user's portable access point (e.g., via the user's wireless device) and request one or more credentials (NFTs) from the security information manager and the blockchain service. Once the credential request from the healthcare provider is authenticated and verified, the blockchain service can issue an NFT to the healthcare provider or provide a credential for the vetted entity to have limited access to the user's electronic health record.

[0026] The user can define which NFT to issue to the healthcare provider via an information management application executed on the user's wireless device. For example, the user can select one of a first NFT (e.g., a temporary NFT), a second NFT (a phased NFT), and / or a third NFT (e.g., a persistent NFT), and the information management application can display the version of the user's portable access point in response to that selection. The version of the user's portable access point can encode the NFT selected by the user for the healthcare provider. The healthcare provider can scan the portable access point and issue a credential request to the security information manager, and the credential request can include the NFT selected by the user for the healthcare provider.

[0027] The user can also use the information management application to define the access privileges of the requested NFT via the scanning of the portable access point. For example, the user can select a security user information data point, a fragment of the data point, a parameter value for grouping the data points, or any other suitable definition for partitioning the user's security information. The version of the user's portable access point generated in response to the user's selection can encode the access privileges of the NFT defined by the user for the healthcare provider. The healthcare provider can scan the portable access point and issue a credential request to the security information manager, and the credential request can include the access privileges defined by the user for the healthcare provider.

[0028] In response to a credential request from a healthcare provider, the blockchain service and / or the security information manager can issue an NFT corresponding to the NFT selected by the user to the healthcare provider. Access privileges defined by the user for the healthcare provider can also be assigned to the NFT. Once the healthcare provider computing system receives the NFT, the system can issue a data access request to the security information manager to access the user's electronic health record. To allow access, the security information manager can authenticate the NFT via (one or more) smart contract calls to the blockchain service. When the NFT is authenticated, the security information manager can allow the healthcare provider's system to have limited access to the user's electronic health record, such as access limited to the privileges assigned to the NFT.

[0029] The access by the healthcare provider to the user's electronic health record using the issued (one or more) NFTs can be logged. For example, the blockchain service can log the historical access to the user's electronic health record on one or more private blockchains. The stored logs can support the (one or more) audits of the healthcare provider's access to the electronic health record.

[0030] Reference will now be made in detail to 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 one of ordinary skill 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. Whenever possible, like reference numerals will be used to refer to like elements.

[0031] Figure 1 A system for allowing limited access to a user's security information using non-fungible tokens according to an example embodiment is illustrated. FIG. 100 includes a user 102, a vetted entity 104, an authenticator and data controller 106, a credential service 108, and a secure data repository 120. The vetted entity 104 can issue a request to the authenticator and validator 106 to access the security information of the user 102 stored in the secure data repository 108. The vetted entity 104 can be any suitable person, group, organization, company, etc. that has undergone a vetting workflow.

[0032] The vetted entity 104 includes the (one or more) computing systems associated with the vetted entity. For example, an application on the (one or more) computing systems may allow the registered identity of the vetted entity 104 to log in to the application. The vetted entity 104 and / or the affiliated identities of the entity may register with one or more institutions. For example, the authenticator and data controller 106 may be part of a security information manager that manages access to the secure data repository 110, and the vetted entity 104 (and one or more registered identities of the vetted entity) may register with the authenticator and data controller 106.

[0033] The user 102 may be collocated (in the same physical location) with the (one or more) computing systems of the vetted entity 104, and the (one or more) computing systems of the vetted entity 104 may obtain user information from the user 102, such as via scanning a portable access point of the user 102. The portable access point may be a visual access point to the security information of the user 102. For example, the portable access point may include a depiction of the user 102 (such as a facial image), as well as encoded information (such as a QR code, a barcode, a sequence of symbols (e.g., alphanumeric, hexadecimal, etc.), and any other suitable encoded information). The encoded information may represent: identification information of the user 102; a range definition corresponding to the security information of the user 102; a time limit for accessing the security information of the user 102; and other suitable information.

[0034] The (one or more) computing systems of the vetted entity 104 may scan the portable access point of the user 102 to generate a credential request to access the security information of the user stored in the secure data repository 110. For example, the user 102 and the (one or more) computing systems of the vetted entity 104 may be collocated, and the portable access point of the user may be carried by the user 102 (e.g., displayed via an information management application executed on the user's wireless device). In other examples, the user 102 and the vetted entity 104 may be remote from each other.

[0035] After scanning the portable access point of user 102, the (one or more) computing systems of the vetted entity 104 can issue a credential request to the authenticator and data controller 106 for (one or more) credentials that permit access to the user's security information stored in the secure data repository 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 from scanning the portable access point of user 102. 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 also authenticate that the system issuing the request corresponds to a vetted entity such as vetted entity 104.

[0036] The credential request can also include a scope definition of the scope of the requested access (to the user's security information). Embedded information from the portable access point can include these scope definitions. After authenticating the credential request, the authenticator and data controller 106 can request (one or more) credentials from the credential service 108. Access privileges corresponding to the scope definition provided in the credential request can be assigned to the requested (one or more) credentials.

[0037] The credential service 108 can issue (one or more) credentials to the vetted entity 104. For example, the issued (one or more) credentials can be (one or more) NFTs, and a private blockchain managed at the credential service 108 can record the issuance of the (one or more) NFTs to the vetted entity 104 (e.g., indicating an identifier of the vetted entity 104 such as a token wallet identifier). The authenticator and data controller 106 can receive the (one or more) credentials from the credential service 108 and provide the (one or more) credentials to the vetted entity 104. In another example, the credential service 108 can directly provide the (one or more) credentials to the vetted entity 104.

[0038] After receiving the (one or more) credentials, the (one or more) systems of the vetted entity 104 can issue a data access request to the authenticator and data controller 106 to access the security information of user 102 stored in the secure data repository 110. The data access request can include the issued (one or more) credentials (e.g., NFTs), identification information of user 102 (e.g., obtained via the portable access point, or any other suitable identification information), and an identifier of the vetted entity 104.

[0039] The authenticator and data controller 106 can authenticate the credential(s) included in the data access request and verify the user's identification information. For example, the authenticator and data controller 106 can authenticate that the credential(s) for the data access request correspond to one or more credentials issued to the vetted entity 104. When the provided credential(s) are one or more NFTs, the authenticator and data controller 106 can verify the NFT(s) via the credential service 108. For example, the credential service 108 can include a private blockchain service that manages the NFT(s) associated with the user 102 and the permission to access the security information of the user 102 stored in the secure data repository 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.

[0040] In response to these API call(s), the credential service 108 can authenticate the provided NFT(s): assigned to the vetted entity 104; and corresponding to the defined scope permission for the security information of the user 102. For example, the private blockchain managed by the credential service 108 can include an immutable ledger that records information for the assigned NFT(s). The private blockchain can record the identification information of the user (e.g., user 102) whose security information is scoped by a given NFT, the scope definition corresponding to the given NFT, the entity to which the given NFT is assigned, changes to the entity assignment of the given NFT, etc.

[0041] The credential service 108 can authenticate the provided NFT(s) against the private blockchain to confirm that the vetted entity 104 is assigned the NFT(s). In some embodiments, the credential service 108 can also provide the scope definitions for the authenticator and data controller 106 recorded on the private blockchain that correspond to the NFT(s) provided in the data access request. The scope definitions can define the (one or more) parts of the security information of the user that the provided NFT(s) and the vetted entity 104 are authorized to access.

[0042] The authenticator and data controller 106 can also verify that the identification information of the user in the data access request corresponds to a registered person whose security information is stored in the secure data repository 108. For example, a user can register with the authenticator and data controller 106, and the security information of the registered user can be stored in the secure data repository 110. The information management application service can provide the registered user with one or more portable access points so that the vetted entity 104 can scan the one or more portable access points to request access to the security information of the registered user stored in the secure data repository 110.

[0043] In response to the authentication of the provided one or more credentials and the vetted entity 104 and the verification of the identification information of the user 102, the authenticator and data controller 106 can allow the vetted entity 104 to have limited access, in scope and time, to the security information of the user stored in the secure data repository 110. For example, the scope and time limitations can be controlled by the scope permissions granted for the provided one or more credentials. The scope permissions 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, the 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 allow the vetted entity 104 to access unless another request is issued that includes one or more credentials authenticated via the credential service 108.

[0044] Figure 2 is a block diagram of a computer server / system 210 according to an embodiment. As Figure 2 shown, the system 210 can include a bus device 212 and / or one or more other communication mechanisms that are configured to transfer information between the various components of the system 210, such as the processor 222 and the memory 214. Additionally, the communication device 220 can enable connectivity between the processor 222 and other devices by encoding data to be sent from the processor 222 to another device via a network (not shown) and by decoding data received by the processor 222 from another system via the network.

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

[0046] The processor 222 may include one or more general-purpose or special-purpose processors to perform the computing and control functions of the system 210. The processor 222 may include a single integrated circuit such as a microprocessing device, or may include multiple integrated circuit devices and / or circuit boards that work together to perform the functions of the processor 222. In addition, the processor 222 may execute computer programs stored in the memory 214, such as the operating system 215, the migration prediction component 216, and other applications 218.

[0047] The system 210 may include a memory 214 for storing information and instructions executed by the processor 222. The memory 214 may include various components for retrieving, 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, the 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 allowing a vetted entity to have limited access to a user's security information, or may also provide any other functionality of the present disclosure. In some cases, the data access manager 216 may be implemented as a configuration within the memory.

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

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

[0050] In some embodiments, the system 210 may be part of a larger system. Thus, the system 210 may include one or more additional functional modules 218 to include additional functionality. Other application modules 218 may include, for example Data Integrator, Cloud Infrastructure, Autonomous Database, Millennium, HealtheIntent, Seamless Exchange, HealtheCare, Blockchain and HealtheLife and various modules of representative products on the Health & Artificial Intelligence platform. The database 217 is coupled to the bus 212 to provide centralized storage for modules 216 and 218 and store, for example, registered personnel verification information, vetted entity information, authentication and verification related information, etc. The database 217 can store data in an integrated collection of logically related records or files. The database 217 can be an operational database, an analytical database, a data warehouse, a distributed database, an end-user database, an external database, a navigation 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.

[0051] Although shown as a single system, the functionality of system 210 can be implemented as a distributed system. For example, the memory 214 and the processor 222 can be distributed across multiple different computers that together represent system 210. In one embodiment, system 210 can be part of a device (e.g., a smart phone, a tablet, a computer, etc.).

[0052] In an embodiment, system 210 can be separate from the device and can remotely provide the described functionality to the device. Additionally, one or more components of system 210 can be excluded. For example, for the functionality of a user or consumer device, system 210 can be a smart phone or other wireless device that includes a processor, a memory, and a display, excludes one or more of the other components shown in Figure 2 and includes additional components not shown in Figure 2

[0053] Before a user's security information is managed by the security information manager, the user can register via a registration workflow. Once the user registers with the security information manager, the registered user can share the security information via one or more portable access points that allow vetted entities to have limited access to the registered user's security information. Figure 3 Illustrated is a system for registering a user for security information management according to an example embodiment.

[0054] The schematic diagram 300 includes a user system 302, an application server 304, a proxy 306, and a security information service 308. The user system 302 can be any suitable user client device, such as a smart phone, a laptop computer, a tablet computer, etc. The application server 304 can be any suitable computing device that hosts applications (such as applications displayed to the user via the user system 302). For example, the application can be a web application, a native application, any combination of these, or any other suitable application.

[0055] The user can interact with the application via the user system 302 to register an account. By generating a registered account, the user allows the security information service 308 to store and manage the user's security information. For example, the registration can configure a link to the user's user account and the security information service 308 stores and manages the user's security information.

[0056] The user system 302 can interact with the application server 304 and / or the proxy 306 to perform a registration workflow. In some embodiments, the application server 304 and / or the proxy 306 can be separated from the security information service 308. Performing the registration of the user(s) via a separate third-party entity (e.g., the application server 304 and / or the proxy 306) can add a certain degree of integrity and trust to the registration workflow.

[0057] In some examples, the user's security information can include electronic health records, and the third-party entity can be a government entity, a non-profit entity, a coalition entity composed of several individual entities, or any other suitable entity that supports a transparent and trustworthy registration workflow that links the electronic health records to the user and supports the security information service 308 to securely store such electronic health records. In these examples, the third-party entity can act as an intermediary that verifies the user's identity, the defined scope of the user's electronic health records stored by the security information service 308, and any other suitable aspects of the user's identity and security information. The third-party entity can also support the connection between different security information services to ensure that the user's electronic health records are available for the user to check and for the user's healthcare providers to use.

[0058] 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 perform the registration workflow. In an example, the user system 302 can receive a public key to register the user's account. The registration workflow can include the user generating a private key. For example, the private key can be used to manage the user's account and security information. Any other suitable credentials (e.g., username and password, two-factor authentication address, shared key, etc.) can be issued to the user.

[0059] 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, photo (e.g., facial image), employment history, city of user's birth, social security number, user identifiers of one or more electronic health records (e.g., identifier of a master patient index), gender, gender identity, race, and other suitable user information. The user can also provide biometric information (e.g., thumbprint or eye scan) via a biometric scanner to enhance security measures and credibility in the management of the registration workflow and the user's security information.

[0060] Agent 306 can verify the user's identification information and link the registration account created for the user to the user's verified identity. For example, agent 306 can verify that the registration account is permitted to store electronic health records of the person verified as the user's identity. Such verification can prevent fraudulent attempts to access the security information of others.

[0061] Once the application server 304 and / or agent 306 execute the first part of the registration workflow (e.g., receive user identification information and verify the user's identity), the security information service 308 can generate account components for the user. The account components can include one or more portable access points for the user's security information, the user's relationship definitions (e.g., defined relationships with other registered users or individuals), and any other suitable account components. The security information service 308 can also aggregate the user's security information as part of (or after) the registration workflow. For example, the security information service 308 can retrieve, obtain, or otherwise aggregate the security information that the user authorizes the security information service 308 to manage, such as the user's electronic health records.

[0062] The user's registration account can also be linked to one or more portable access points. The (one or more) portable access points can include a visual representation of the user (e.g., an image) and encoded information about the user's security information, such as a scope definition for sharing the user's security information. Figure 5 Illustrated is a (one or more) portable access point according to an embodiment.

[0063] 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 of sharing the user's security information via the generated portable access points. For example, the user can select one or more data points of the user's security information, one or more default security information data profiles, or define the scope for sharing the user's security information in any other suitable manner.

[0064] An information management application can generate a portable access point corresponding to a defined scope and display the portable access point on a user system 302. A computing system for an external entity (such as a vetted entity) can scan the portable access point to configure access to the user's security information according to the defined scope. Figure 4A , Figure 4B and Figure 4C illustrate a system with a security information manager according to an example embodiment that allows for limited - scope access to a user's security information using non - fungible tokens.

[0065] The schematic diagram 400A includes a source 402, a requesting system 404, a security information manager 406, secure user information 408, a scanning module 410, a requester 412, a blockchain manager 414, one or more blockchains 416, and one or more smart contracts 418. The requesting system 404 can be a system of a vetted entity (such as an entity for which the security information manager 406 completes a vetting workflow). The source 402 can include sources of user information, such as a user's body, a user identification document (e.g., driver's license, passport, etc.), the user's wireless device (e.g., smartphone), the user's portable access point, and any other suitable source(s) of user information.

[0066] The requesting system 404 can obtain user information from the source 402. For example, the scanning module 410 of the requesting system 404 can scan the user's portable access point. The user's portable access point can be displayed via the user's wireless device. For example, an information management application (e.g., a native application, a web application, etc.) executed on the user's wireless device can allow the user to configure the portable access point to share the user's security information. Figure 5 illustrate one or more portable access points according to an embodiment and define scope limitations for the one or more portable access points via an information management application. 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 gallery, or via any other suitable display means.

[0067] The scanning module 410 can be a specialized device configured to scan the portable access point and obtain the requested identifying user information, such as a wireless device that includes an image capture component (e.g., a camera) and executes an application configured to decrypt the portable access point. The scanning module 410 can obtain user identification information from any other suitable element of the source 402.

[0068] In some examples, the source 402 may include the wireless device of a person having a predefined relationship with the user. The user may be an enrolled person for whom the security information manager 406 manages security user information 408. The user may also register with the security information manager 406 one or more predefined relationships, such as personal relationships (e.g., parent, spouse, child, friend, etc.), professional relationships (e.g., co-managers of a business application, etc.), or other suitable relationships. The person (or persons) having a predefined relationship with the user may possess a wireless device that can provide the identification information of the user to the requesting system 404 that issues the request. For example, any suitable user identification information provided by the user's wireless device (e.g., the user's portable access point) may be provided to the scanning module 410 via the wireless device of the person (or persons) having a predefined relationship with the user. The wireless device (or devices) of the relevant person (or persons) may also include an application that registers with and provides user identification information to the security information manager 406.

[0069] In response to retrieving information from the source 402, the requesting system 404 and the requester 412 may issue a credential request to the security information manager 406 for one or more access credentials that permit access to the user's security information. For example, the scope of the requested credential(s) may be restricted to the user identified by the user identification information (e.g., obtained via the source 402). The requested credential(s) may permit the requesting system 404 to access the security information 408 via the security information manager 406.

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

[0071] The credential request may also include a credential version. For example, a user may select (via an information management application executing on the user's wireless device) a credential version (e.g., a type of NFT having a corresponding expiration timer), and the information management application may generate a portable access point encoding the credential version. The scanning module 410 may then decrypt the credential version, and the requester 412 may include the credential version in the credential request.

[0072] The user may provide a secure user code to complete the credential request. For example, the requesting system 404 may prompt the user to enter a username and password, a numeric password, a key, a PIN, or any other suitable secure user code. During the registration workflow, the user may establish a username and password, a numeric password, a key, a PIN, etc. The application at the requesting system 404 may link to a secure information manager 406, an honest broker, or any other suitable entity that can verify the user's username and password, numeric password, key, PIN, etc. Once the application at the requesting system 404 confirms that the secure user code is valid, the application may allow the requesting system 404 and the requester 412 to generate a credential request.

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

[0074] 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. The verification may include: matching the identifier decrypted from the portable access point with the stored identifier of the registered user; verifying additional user identification information provided in the request against the user identification information stored for the matched registered user; verifying the credential version included in the credential request; and / or any other suitable verification.

[0075] When the (one or more) entity credentials are authenticated and the user identification information is verified, the security information manager 406 may issue a software call for access credentials to the blockchain manager 414 on behalf of the requesting system 404 (associated with the vetted entity). For example, the blockchain manager 414 may manage NFTs that serve as access credentials for a user's security information.

[0076] The blockchain manager 414 may manage the (one or more) blockchains 416 for the security information manager 406. For example, the (one or more) access credentials provided to the vetted entity (in response to an authenticated and verified credentials request) may include the (one or more) NFTs managed by the blockchain manager 414. The (one or more) NFTs may be linked to the user's security information and may be assigned different levels of scope permissions to access the user's security information. The (one or more) blockchains 416 may include the (one or more) blockchain ledgers that record NFT transactions.

[0077] A blockchain is a list of records, each record being called a block, and the blocks can be linked together by cryptographic techniques. In some blockchain implementations, each block includes a timestamp, the hash of the previous block, and transaction data. The timestamp attests that the transaction data was included when the block was added in order to obtain its hash. Since each block designates its previous block, the collection of blocks forms a chain, and each new block strengthens the collection of blocks that preceded it in the chain. Thus, a blockchain can be difficult to modify because once data is added to the blockchain, it cannot be changed without changing subsequent blocks.

[0078] A non-fungible token (NFT) is a blockchain-supported identifier for specifying a unique item. Through a distributed ledger (e.g., a blockchain), the assignment or ownership of these tokens can be tracked and verified. Such tokens may include an identifier of the unique item and / or a link to a representation of the unique item (e.g., via a traditional URL or a distributed file system such as IPFS). The blockchain manager 418 may manage the (one or more) blockchains 416 and include the (one or more) smart contracts 418 that execute in combination with the (one or more) blockchains 416. The (one or more) blockchains 416 may be the (one or more) Hyperledger blockchains, or may be the (one or more) any other suitable blockchains.

[0079] The blockchain manager 414 may manage different NFTs that permit different levels of access privileges to a user's security information. For example, a data access request from a vetted entity may be authenticated against one or more blockchains 416 via the blockchain manager 414 and one or more smart contracts 418 to ensure that: the NFT is an NFT managed by the blockchain manager 414, the NFT has been issued to the vetted entity that sent the data access request, and / or the NFT has not expired. Figure 4B The schematic diagram 400B illustrates an example data access request 430 that includes an NFT issued by the blockchain manager 414.

[0080] The blockchain manager 414 may also include a mint component that mints NFTs that permit different levels of access privileges to a user's security 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 to whom the NFT has been assigned the privilege of accessing the user's security information. The minted NFT may include any suitable user identification information described herein. The minted NFT may include non-fungible tokens, semi-fungible tokens, and the like.

[0081] The blockchain manager 414 may issue one or more NFTs to a vetted entity in response to a smart contract call from the security information manager 406. For example, a first NFT (e.g., a temporary NFT) may provide access to a user's security information for a limited duration (e.g., a few hours, days, weeks, etc.). In this example, once the limited duration expires, the first NFT will no longer be authenticated via the blockchain manager 414 and one or more blockchains 416. In some examples, the user may define an expiration timer (e.g., via an information management application executed on the user's wireless device), and this definition may be included in the user's portable access point. This defined timer may be included in a credential request sent by the requesting system 404 via a scan of the user's portable access point. The security information manager 406 may then include the defined timer in the smart contract call to the blockchain manager 414.

[0082] In another example, a second NFT (e.g., a periodic NFT) may provide access to a user's security information for a predefined duration (e.g., a few hours, days, weeks, etc.). In this example, once the predefined duration expires, the second NFT will no longer be authenticated via the blockchain manager 414 and one or more blockchains 416. In another example, a third NFT (e.g., a persistent NFT) may provide access to a user's security information permanently or until the NFT is explicitly revoked.

[0083] In an example, the user's security 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 one or more credentials (NFTs) from the blockchain manager 414. Once the credential request from the healthcare provider is authenticated and verified, the blockchain manager can issue an NFT to the healthcare provider.

[0084] The user can define which NFT to issue to the healthcare provider via the user's information management application executed on the user's wireless device. For example, the user can select one of a first NFT, a second NFT, and / or a third NFT, and the information management application can display the version of the user's portable access point in response to the selection. The version of the user's portable access point can encode the NFT selected by the user for the healthcare provider. The healthcare provider can scan the portable access point and issue a credential request, which then includes the NFT selected by the user for the healthcare provider.

[0085] In this example, when the user anticipates that the healthcare provider needs limited access to the user's electronic health record in a short period of time (such as emergency care facility access), the user can select the first NFT (and define a timer). In another example, when the user anticipates that the healthcare provider needs access to the user's electronic health record for a moderate period of time, the user can select the second NFT, such as for surgery at a hospital where the user does not frequently go, an expert visit that the user anticipates will not occur again, etc. In another example, when the user anticipates that the healthcare provider needs access to the user's electronic health record for a long or indefinite period of time, the user can select the third NFT, such as when the healthcare provider is the user's primary care physician, a designated expert for a long-term health problem, etc.

[0086] In other examples, the vetted entity can be another individual, such as an individual having a predefined relationship with the user (e.g., a family member, a close friend, etc.). In such cases, the user can select the third NFT to ensure that the individual maintains access to the user's electronic health record. After the security 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 one or more smart contract calls.

[0087] The blockchain manager 414 can mint NFTs on demand and / or store multiple pre-minted NFTs belonging to a user. For example, an NFT can be minted on demand in response to a credential request that includes: user identification information, scope privileges corresponding to the credential request, timing restrictions, and / or a credential version (e.g., temporary, periodic, and / or persistent), or any other suitable information from the credential request. The minted NFT can then be transferred to a vetted entity identifier in the credential request (e.g., the token wallet identifier of the vetted entity), and the transfer can be recorded on the blockchain(s) 416. The on-demand minted NFT can be created for specific parameters of the credential request. For example, a 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.

[0088] 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(s) can: include predefined scope privileges; correspond to a specific NFT version (e.g., temporary, periodic, and / or persistent); include user identification information linking the NFT to the user; and / or include any other suitable information. The blockchain manager 414 can pre-mint multiple NFTs with different combinations of parameters for a given user. For example, multiple NFTs of each NFT version (e.g., temporary, periodic, and / or persistent) can be pre-minted, where different predefined scope privileges can be assigned to the multiple NFTs of a given NFT version. Since the pre-minted NFTs are not customized for the details of a given credential request, many different versions of the pre-minted NFTs can accommodate many different credential requests.

[0089] For example, different predefined scope privileges can correspond to: different scope templates defined by the user with respect to the user's security information (e.g., predefined groupings or segments of the user's electronic health data); different templates based on feedback from a vetted entity regarding which part(s) of the user's security information the entity requires; a global scope that allows mass access to the user's security information; or any other suitable predefined scope privileges. The security information manager 406 and / or the blockchain manager 414 can match one of these pre-minted NFTs to the credential request and assign the matched pre-minted NFT to the vetted entity identified in the credential request.

[0090] The pre-fabricated entity may also include a blank set of scope privileges, and the security information manager 406 may assign scope privileges to the NFTs that match the credential requests as needed. Thus, the pre-fabricated NFTs can be matched with the credential requests using the credential versions, and scope privileges customized specifically for the credential requests can be assigned to the matching NFTs. The security information manager 406 may transmit the privilege assignment to the blockchain manager 414, and the blockchain manager 414 may attach the privilege assignment to the blockchain(s) 416.

[0091] Some credential requests from the requesting system 404 may be generated by scanning a user's portable access point (such as a portable access point controlled by an information management application on the user's wireless device). The information management application may generate a portable access point corresponding to the pre-fabricated NFT. For example, the information management application may present the user with a limited set of scope restrictions and / or a limited set of timing constraints (such as credential versions), where each combination of scope restrictions and timing constraints corresponds to one of the pre-fabricated NFTs at the blockchain manager 414. In this example, the security information manager 406 and / or the blockchain manager 414 may match each credential request with the pre-fabricated NFT corresponding to the credential request.

[0092] After receiving the user selection and displaying the portable access point for the user, the information management application on the user's wireless device may also provide an indicator to the security information manager 406 that identifies the specific portable access point (e.g., a specific combination of scope restrictions and timing constraints) and the time the portable access point was displayed. Then, the security information manager 406 and / or the blockchain manager 414 may fabricate the NFT corresponding to the portable access point definition as needed and / or select the pre-fabricated NFT that matches the portable access point definition. In this example, the security information manager 406 has selected an NFT for the portable access point definition before receiving the credential request from the requesting system 404. When the credential request is received, the selected NFT can simply be transferred to the vetted entity identified in the credential request.

[0093] In this example, fraudulent use of this version of the user's portable access point at a later time point can be traced back to the initial time when this version of the user's portable access point was shown and the vetted entity that scanned this version of the user's portable access point (and subsequently used the information decrypted from this version of the user's portable access point to request credentials). Such fraudulent attempts can utilize a static image of the user's portable access point. A fraudster can take a photo of the user's portable access point and use the photo to subsequently attempt to request credentials for access to the user's security information. Since the version of the user's portable access point identifies the time and the vetted entity that scanned the portable access point, the fraudster can be traced and held accountable. In one embodiment, even if other access criteria are the same, the version of the user's portable access point changes based on the time when the version was generated. In this embodiment, a different version can be generated each time the user prepares the user's portable access point for scanning.

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

[0095] In another example, the requesting system 404 can be the user's wireless device, and the source information 402 can be affiliated with the vetted entity. The vetted entity can display the 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 it on a physical item (e.g., paper, wood, cardboard, etc.), or display it via any other suitable display. The source information 402 can include an access point for the vetted entity, such as a QR code or other suitable visual code affiliated with the vetted entity. The access point of the vetted entity can be similar to the user's portable access point, such as Figure 5 the portable access point disclosed in

[0096] In this example, the access point of the vetted entity can include encoded information about the vetted entity, and the user's wireless device (as the requesting system 404) can scan the portable access point of the vetted entity to decrypt the information. The information management application on the user's wireless device (with which the user interacts to select scope permissions for the requested credentials, timing for the requested credentials, and / or credential versions) can be configured to decrypt the portable access point of the vetted entity. For example, the information management application can function as the scanning module 410. The encoded information of the vetted entity can include an identifier that identifies the vetted entity to the security information manager 406, encoded information representing the identity credentials issued to the vetted entity (e.g., a signature using a cryptographic key), or other suitable vetted entity identification information. Using the vetted entity information decrypted from the access point of the vetted entity, the user's wireless device can generate a credential request and transmit the credential request to the security information manager 406.

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

[0098] In response to the credential request from the user's wireless device, the security information manager 406 can provide the (one or more) access credentials corresponding to the credential request (e.g., NFT, Figure 4B of the (one or more) credentials 432) to the system of the vetted entity. For example, via interaction with the blockchain manager 414, the security information manager 406 can provide the (one or more) credentials (such as one or more NFTs) with scope permissions corresponding to the credential request.

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

[0100] Using the (one or more) NFTs issued to the computing system of the vetted entity via a credential request from the user's wireless device (as the requesting system 404), the computing system of the vetted entity can issue one or more data access requests to the security information manager 406. For example, the data access request may include: the scope of the requested user security information; the issued (one or more) NFTs; and / or any other suitable information.

[0101] The schematic diagram 400B includes a requesting system 404, a security information manager 406, secure user information 408, a blockchain manager 414, the (one or more) blockchains 416, the (one or more) smart contracts 418, an audit log 424, a transaction log 426, an access request 430, and the (one or more) credentials 432. Similar to the example disclosed in the reference schematic diagram 400A, the requesting system 404 can be the system of a vetted entity (such as an entity for which the security information manager 406 performs a vetting workflow).

[0102] Once the (one or more) credentials 432 (such as NFTs) have been assigned to the vetted entity, the user's wireless device can display, via the information management application, information identifying the vetted entity as the current owner of the NFT, which grants the vetted entity permission to access the user's security information according to the access permissions associated with the NFT. In the described or another embodiment, the user's wireless device can display, via the information management application, a list of all vetted entities that own NFTs allowing access to the user's security information, and these vetted entities can be grouped by the type, duration, and / or extent of their access to the user's security information for each vetted entity.

[0103] Some embodiments also allow a user to group and / or concurrently display data consumers with secure access to NFT management (e.g., vetted entities) and data consumers with secure access to non-NFT management. For example, a user can manually update information about data consumers who have been manually granted access to certain secure user information, and these data consumers can be displayed together with information about data consumers of NFT management. In one embodiment, the concurrent display includes an option to convert a non-NFT management data consumer into an NFT management data consumer via a clickable button on the user's wireless device via an information management application, which option triggers the NFT management process described herein to transfer NFT ownership to the previously non-NFT management data consumer. For example, the difference between an NFT management data consumer and a non-NFT management data consumer is that an NFT management data consumer can access (and in some embodiments update) secure user information, such as electronic health records, continuously, periodically, or on demand as new health data becomes available. The user (or patient) can retain the ability to restrict the scope or duration of this privilege via the NFT; while a non-NFT management data consumer can access and update health records if the user or patient has been manually granted permission for the non-NFT management data consumer to do so. Typically, this is achieved by the patient filling out a health data request form and concurrently faxing and / or emailing (as of the time of submission, this is still the most common practice) it to the data producer for sending to the data consumer.

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

[0105] Once access request 430 is received at security information manager 406, credential authenticator 420 may authenticate one or more credentials 432 (e.g., issued NFTs) via one or more smart contracts 418 of blockchain manager 418. Security information manager 406 may also verify the identification information of the user against the registered users to confirm that the requesting identification matches the user to whom the NFT was issued. After the one or more credentials 432 are authenticated and the identification information of the user is verified, data access controller 422 may issue one or more queries to secure user information 408 to retrieve a limited scope of secure user information.

[0106] Security information manager 408 may log the one or more requests, the limited scope of information accessed via the one or more requests, the timestamp, and other suitable data related to access request 430 and the limited scope of secure user information accessed. In some embodiments, security information manager 408 may include an application log and / or an audit log. For example, the application log may log the transactions and activities of an application that permits limited access in response to a data access request (e.g., access request 430). The audit log may log data similar to the application log that supports auditing (e.g., user auditing).

[0107] Access to the user's security information may be logged in any suitable data structure. Blockchain manager 414 may store the audit log in a blockchain data structure to support auditing. Security information manager 408 may call one or more smart contracts 418 that write the log information to audit log 424. For example, each request and / or instance of permitted access to the user's security information may be logged as a block of the blockchain via a call to the one or more smart contracts 418. Blockchain manager 414 may also store the one or more application logs in the blockchain data structure.

[0108] Security information manager 408 and / or blockchain manager 414 may provide portions of the one or more logs in response to an audit request. A user (or any other suitable entity or person) may audit access to the user's security information. The logged information (including the one or more requests, the limited scope of information accessed via the one or more requests, the timestamp, and other suitable data related to the received one or more requests and the limited scope of data) may be provided to the user or other suitable audit entity.

[0109] Figure 4CThe schematic diagram 400C includes a requesting system 404, a security information manager 406, secure user information 408, an access request 430, one or more credentials 432, a data query 434, user information 436, limited-scope user information 438, and limited user information 440. Similar to the examples disclosed in reference schematic diagrams 400A and 400B, the requesting system 404 can be a system of an entity (such as an entity that executes a review workflow through the security information manager 406) that has been reviewed.

[0110] As referenced Figure 4B As disclosed, the access request 430 and one or more credentials 432 can be authenticated and verified via the security information manager 406. A data query 434 can be issued to retrieve limited-scope secure user information from the secure user information 408, such user information corresponding to the scope privileges of one or more credentials 432. The secure user information 408 can include security information for multiple registered individuals, and the user information 436 can represent the security information stored for a user verified against the identification information included in the access request 430 and / or linked to one or more credentials 432. The security information manager 406 can construct the data query 434 to retrieve a portion of the user information 436.

[0111] The user information 436 can include a set of data points for the user, and the limited-scope user information 438 can include a subset of the data points. In an example where the secure user information 408 includes electronic health records and user health data, the set of data points of the user information 438 can include the set of electronic health record data for the user, and the subset of data points of the limited-scope user information 438 can include 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 records (e.g., defined by the user, the security information manager 406, etc.), or any other suitable subset of the data.

[0112] For example, the limited-scope user information 438 can be predefined health data points specified by the user that can be accessed by any suitable reviewed entity including one or more authenticated credentials. In another example, the limited-scope user information 438 can include health data points based on a predefined template, such as data points customized for a patient intake. The limited-scope user information 438 can include the user's blood type, past health conditions, previous surgeries, allergies, current medications, or any other suitable user health data. In an example where the user information 436 is a segmented health record, the data points included in the limited-scope user information 436 can be any suitable segment of the segmented health record.

[0113] The user information 436 can be electronic health data segmented based on parameters. For example, the parameters can include: the originating doctor and / or medical organization (e.g., (one or more) entity identifiers), the type of information (e.g., medications, tests and results, medical history, family history, biometrics, doctor-patient communications, doctor notes, vaccine information, allergies, etc.), the relevant health practice (e.g., cardiology, primary care, neurology, oncology, etc.), the date the information was originated, the electronic health record format, other Health Level 7 (HL7) data parameters, or any other suitable health data parameters. The user can define which portions of the user's electronic health data are to be shared via the user's portable access point by providing parameter values that define a range. The scope of the privileges for the (one or more) credentials 432 can then be determined based on the user-defined parameters, and the security information manager 406 can restrict the data query 434 based on the privileges for the (one or more) credentials 432.

[0114] In response to an authenticated and verified access request 430, the security information manager 406 can issue a data query 434 to the secure user information 408. The security information manager 406 can receive limited user information 440 from the secure user information 408, and the limited user information 440 can be scope-restricted based on the scope privileges defined for the (one or more) credentials 432 (e.g., (one or more) NFTs 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 then the security information manager 406 can restrict the data query 434 based on the privileges for the (one or more) credentials 432. In another example, the data requested by the access request 430 can be scope-restricted according to the privileges for the (one or more) credentials 432, and a data query 434 can be generated to retrieve the limited-scope data. The limited user information 440 can then be provided to the requesting system 404.

[0115] Role-based access control can also be applied to secure user information 408 to limit and restrict the functionality and scope of information associated with the credential(s) 432 and the identity (e.g., user, vetted entity, registered user of a vetted entity, etc.) affiliated with the credential(s). Each identity affiliated with the credential(s) 432 can correspond to a role in the context of role-based access control. For example, an administrator role may have full permission to view all information and perform all tasks, while a clerk role may only be able to view limited information about a particular consumer or patient, where protected health information (PHI) or personally identifiable information (PII) attributes will be hidden from that individual. In some embodiments, role-based access control can be applied to data queries 434 such that limited user information 440 is retrieved via the query.

[0116] The vetted entity affiliated with the credential(s) 432 can include one or more registered identities. For example, the vetted entity can be an organization, and the registered identity can be a person who is part of that organization. In some examples, the vetted entity can be a hospital, an emergency room organization, or a first responder organization, and the registered identity can be emergency room personnel and / or paramedics.

[0117] The request 430 can be issued by a registered identity of a vetted entity. For example, the request 430 can include an indicator of the vetted entity and the registered identity, such as the credential(s) 432, which, when authenticated, can identify the registered identity and the vetted entity. Any other suitable indicator can be included in the request 430.

[0118] The scope of the limited user information 440 can be limited to the registered identity associated with the vetted entity that issued the request, and / or the credential(s) 432 of the vetted entity or the registered identity. For example, a paramedic registered identity may not be able to provide the same level of care as an emergency room provider, so different levels of information may be required based on the care situation. Accordingly, a request from a paramedic registered identity can correspond to a first version of the limited user information 440, while a request from emergency room personnel can correspond to a second version of the limited user information 440, where the first version is different from the second version. For example, the second version can include data points related to certain levels of care and activities not included in the first version.

[0119] Data access requests from a vetted entity (e.g., the requesting system 404) can vary in terms of the requesting registered identity, the (one or more) credentials included in the request, the scope of the security information of the requested user, and other suitable request parameters. For example, the requesting system 404 can issue multiple requests over time to access the user's security information using (one or more) different credentials 432. As long as the (one or more) credentials 432 are not expired, the security information manager 406 can verify the (one or more) credentials and allow access to the user's security information (limited to the privileges of the (one or more) credentials 432).

[0120] The user can edit the privileges assigned to the (one or more) credentials 432 via an information management application executed on the user's wireless device. For example, an information management application that controls the user's portable access point and the privilege assignment for the assigned (one or more) credentials 432 can be linked to the security information manager 406 and can edit the data points, security user information fragments, and / or parameter values used to group the security user information that the (one or more) credentials 432 are permitted to access. These edits can be stored in the security information manager 406 and / or provided to the blockchain service via the (one or more) smart contracts 418. The blockchain service can append the privilege edits to the (one or more) blockchain ledgers that define the access privileges for the (one or more) credentials 432.

[0121] The edits can include revoking the access privileges assigned to the (one or more) credentials 432. When the (one or more) credentials 432 expire or the access privileges of the (one or more) credentials are revoked, the requesting system 404 can transmit the (one or more) credentials back to the blockchain service that issued the (one or more) credentials, e.g., assigned to the same or another vetted entity. In some examples, the blockchain manager 414 can store multiple pre-fabricated NFTs, and the (one or more) credentials returned to the blockchain manager 414 after expiration and / or revocation can be returned to this pool of pre-fabricated NFTs (awaiting transfer to the next owner / vetted entity).

[0122] The token wallet of the vetted entity storing the credential(s) can be a dedicated token wallet(s), which returns the credential(s) 432 to the blockchain manager 414 (or any other suitable original token wallet) when the credential(s) expire. For example, some of the credential(s) 432 can be NFTs that define an expiration time, and each token wallet can detect the expiration time and automatically return any expired credential(s) 432. The revocation of the credential(s) 432 initiated by the user via the information management application on the user's wireless device can be processed at predetermined intervals (e.g., once a day, once every 12 hours, once every 6 hours, etc.). For example, the security information manager 406 and / or the blockchain manager 414 can trigger the revocation of the credential(s) from the vetted entity token wallet(s) based on the user-initiated revocation at each interval timing.

[0123] Figure 5 Illustrated is a portable access point according to an example embodiment. The schematic diagram 500 includes a wireless device 502, a portable access point 504, an image 506, and encoded information 508. An application running on the wireless device 502 can display the portable access point 504. For example, the system(s) of the vetted entity can be configured to scan the portable access point 504 from the wireless device 502. The wireless device 502 can display the portable access point 504 in any other suitable manner.

[0124] The portable access point 504 can include an image 506 or an image of the user's face, and encoded information 508. The encoded information 508 can include a unique QR code or other suitable visual or symbolic (e.g., alphanumeric) code embedded relative to the image 506 (e.g., at the top of the image 506). The QR and / or symbolic code can utilize one or more of holographic images, raised holographic images, pixelated codes, raised textured codes, etc. For example, the encoded information 508 can be displayed at the top of the image 506 as an embossed QR code with a unique encrypted long string identifier generated using an algorithm.

[0125] 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 generates it. For example, if a fraudulent version of the portable access point 504 attempts to copy 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.

[0126] The unique encrypted long string identifier generated via an encrypted long string identifier algorithm can be dynamic, such that new identifiers are generated: for each version of the portable access point 504, within a predefined time period (e.g., every 2 hours, 4 hours, 6 hours, 12 hours, daily, etc.) or via any other suitable timing. In this example, a security information manager that manages the security information of a user can receive a dynamically generated identifier for a version of the portable access point. For example, an identifier can be dynamically generated via an information management application on a wireless device 502 of the user's portable access point, and the application can transmit the dynamically generated identifier to the security information manager. In another example, an identifier can be dynamically generated via a cloud service, and the cloud service can transmit the dynamically generated identifier to both the application that manages the user's portable access point and the security information manager.

[0127] To mitigate fraudulent attempts to request one or more credentials via an older version of a user's portable access point, the security information manager can record one or more active long string identifiers for a given user. When the security information manager receives a credentials request that includes an inactive identifier, the request can be rejected and the fraudulent attempt can be reported to support enhanced security measures.

[0128] The vetted entity system can be configured to scan the portable access point 504, such as Figure 4A the requesting system 404 and the scanning module 410 that issue requests. Once the scanning module 410 scans the portable access point 504, the requesting system 404 (e.g., an application configured to decrypt the portable access point 504) can decrypt the encoded information 508 and / or the image 506. For example, an application at the requesting system 404 can decrypt a unique long string of numbers (e.g., generated by a unique algorithm) and include the decrypted numbers in a credentials request, as described in the schematic diagram 400A of Figure 4A reference.

[0129] The secure user information of a user linked to the portable access point 504 can be parameter-segmented electronic health data. For example, the parameters can include: the initiating or affiliated doctor and / or medical organization (e.g., entity name or (one or more) identifiers), the type of information (e.g., medications, tests and results, medical history, family history, biometrics, doctor-patient communications, doctor notes, vaccine information, allergies, etc.), the related health practice (e.g., cardiology, primary care, neurology, oncology, etc.), the date the information was initiated, the electronic health record format, other Health Level 7 (HL7) data parameters, or any other suitable health data parameters. The user can define which portions of the user's electronic health data are shared via the portable access point 504 by providing parameter values that define a range.

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

[0131] The wireless device 502 can display the portable access point 504 when the wireless device is offline, such as when the wireless device 502 lacks a connection to the following: the Internet, a server hosting components of the 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, components of an application running locally on the wireless device 502 can display the portable access point 504.

[0132] The portable access point 504 can be displayed on the login screen of the application, such as before the user logs in to the application. This can support the display of the portable access point 504 without a network connection. Then, a scanning component of the vetted entity (e.g., the scanning module 410) can scan the displayed portable access point 504, and the system of the vetted entity can utilize a network connection (e.g., a connection to the Internet) to perform (one or more) credential requests and / or (one or more) data access requests.

[0133] Figure 6 A flowchart is illustrated for using credential authentication and user verification to permit limited access to a user's security information according to an example embodiment. In one embodiment, Figure 6 (and the following Figure 7 ) functionality is implemented by software stored in a memory or other computer-readable or tangible medium and executed by a processor. In other embodiments, each functionality can be performed by hardware (e.g., by using an application specific integrated circuit (“ASIC”), programmable gate array (“PGA”), field programmable gate array (“FPGA”), etc.) or any combination of hardware and software.

[0134] The processing 600 can be performed by a computing system that issues a request, such as a computing system affiliated with a vetted entity that issues a request (e.g., a credential request and / or a data access request) to the security information manager. The processing 602 can be performed by a security information manager that manages security information for one or more users (e.g., a cloud computing system or any other suitable computing system).

[0135] At block 604, the processing 600 can scan a portable access point. For example, the system that issues the request can include a scanning component configured to scan and decrypt the user's portable access point. The scanning component can be a portable device that includes a camera and software configured to decrypt user identification information from the user's portable access point.

[0136] The portable access point can be a visual access point that, when scanned, can allow access to the user's security information (e.g., stored and managed via the security information manager). For example, the visual access point can include a visual representation of the user linked to the portable access point (e.g., a facial image) and encoded information related to the scope of the user's security information and / or the permitted access. The system that issues the request and the scanning component can be affiliated with a vetted entity, such as an entity that performs a vetting workflow. Example vetted entities can include service providers (e.g., system administrators, healthcare providers, hospitals, etc.), partners in a joint venture, entities that register individuals with the security information manager, or any other suitable vetted entity.

[0137] The user can configure the portable access point and the displayed encoded information. For example, the portable access point can be displayed via an information management application executed on the user's wireless device (e.g., a smart phone, a tablet, etc.), and the user can interact with the information management application and select the scope of sharing of the user's security information. The portable access point can be dynamic such that the user's selection via the information management application generates different versions of the portable access point with different encoded information displayed. For example, the user can define a sharing scope that identifies data points of the user's security information that can be shared with a vetted entity via the scanning of the portable access point. The user can also define a time period for the sharing scope during which the user's security information can be shared with a vetted entity via the scanning of the portable access point.

[0138] At block 606, process 600 can generate a credential request in response to scanning a 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. The encoded information displayed by the portable access point can be decrypted and included in the credential request. The decrypted information 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), vehicle make, model, and / or license plate, a representation of a government-issued identification (e.g., driver's license photo), an image of the user's face, etc.

[0139] The decrypted information from the user's portable access point can also include a scope definition corresponding to the user's security information. For example, the scope definition can correspond to a credential version such as a temporary credential (limited time frame), a periodic credential (predefined time frame), or a persistent credential (valid until revoked). In another example, the scope definition can correspond to limited scope privileges for the requested credentials.

[0140] The user's security information can be electronic health data segmented based on parameters, and the limited scope privileges for the requested credentials can correspond to a limited portion of the user's electronic health data. For example, the parameters can include: the originating physician and / or medical organization (e.g., (one or more) entity identifiers), the type of information (e.g., medications, tests and results, medical history, family history, biometrics, physician and patient communications, physician notes, vaccine information, allergies, etc.), the relevant health practice (e.g., cardiology, primary care, neurology, oncology, etc.), the date the information was originated, the electronic health record format, other Health Level 7 (HL7) data parameters, or any other suitable health data parameters. The user can define which portions of the user's electronic health data are shared via the user's portable access point by providing parameter values that define the scope.

[0141] At block 608, process 600 can transmit the credential request. For example, the requesting system can transmit the credential request to a security information manager. The credential request from the requesting system can be for (one or more) credentials that allow the requesting system to access the user's security information, which can be managed by the security information manager. For example, the details of the request (e.g., user identification information, credential version, defined scope security user information privileges, etc.) can be provided by the user's portable access point. This allows the user to control how the user's security information is shared with the requesting system.

[0142] The security information manager can verify and authenticate a credential request and obtain a credential from a blockchain service in response to the request. The authentication and verification of the credential request and the subsequent retrieval of the credential from the blockchain service are described with reference to block 618 and block 620 of process 602. At block 610, process 600 can receive one or more credentials. For example, the security information manager can transmit the obtained credential to the requesting system. The credential can be an NFT managed by the blockchain service, and the requesting system can include a token wallet affiliated with a vetted entity storing the NFT.

[0143] At block 612, process 600 can transmit a data access request including the received one or more credentials. For example, a data access request including the received credential, the identifier of the requesting vetted entity, and user identification information can be transmitted to the security information manager. The security information manager can verify and authenticate the data access request and retrieve limited-scope security user information in response to the data access request.

[0144] The data access request can define one or more data points of the user's security information. For example, the user's security information can be electronic health data segmented based on parameters. The data access request can include specific parameter values defining the scope of the requested user's security information. Additionally, the credential issued to the vetted entity and provided in the data access request includes scope privileges with respect to the user's security information. The authentication and verification of the data access request and the subsequent retrieval of limited-scope security user information are described with reference to block 626 and block 628 of process 602.

[0145] At block 614, process 600 can receive limited-scope security user information in response to the data access request. For example, the security information manager can transmit the limited-scope user information to the requesting system. The received limited-scope user information can correspond to the requested one or more data points included in the data access request. In another example, the received limited-scope user information can correspond to a part of the requested one or more data points included in the data access request. When the data access request includes one or more user data points outside the set of scope privileges of the vetted entity / provided one or more credentials, the security information manager can only retrieve and return a part of the one or more user data points covered by the set of scope privileges.

[0146] Processing 602 may be performed by a security information manager that receives (one or more) requests from a requesting system. At block 616, processing 602 may receive a credential request. For example, the security information manager may receive a credential request from the requesting system, as described with reference to block 608 of processing 600. The credential request may include user identification information, an identifier and / or credentials of a vetted entity, a credential version definition, a scope definition of security user information, and any other suitable information.

[0147] At block 618, processing 602 may authenticate and verify the credential request. For example, the credential request may include user identification information that is verified by the security information manager. The security information manager may manage security information for multiple registered persons, and the verification may match the user identification information provided in the credential request to one of the registered persons.

[0148] The credential request may also include an identifier and / or identification credentials of a vetted entity, and the security information manager may authenticate the identifier and / or identification credentials. For example, the identifier and / or identification credentials included in the credential request (from a requesting system affiliated with a 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 may be used to authenticate the vetted entity.

[0149] At block 620, processing 602 may obtain the (one or more) credentials corresponding to the credential request. Verification of the user identification information may match the registered user to the credential request, and authentication of the identifier / credentials may match the vetted entity to the credential request. The security information manager may then issue a software call to a blockchain service to obtain a credential with scope privileges that allow the matched vetted entity to have limited access to the security information of the matched registered user. For example, the software call may include the identifier of the registered user, the identifier of the vetted entity, and the credential version included in the credential request from the requesting system.

[0150] The blockchain service may return an NFT to the security information manager in response to the software call. For example, the blockchain service may host one or more blockchains that manage the NFT, and the NFT may be issued to the vetted entity to be used as a credential to allow the vetted entity to access the security user information. The issued NFT may match the credential version included in the software call. The transaction of issuing the NFT to the vetted entity may be appended to the (one or more) blockchains such that the assigned record is maintained as an immutable ledger.

[0151] The software calls made by the security manager can be smart contract calls, and the blockchain service can execute one or more smart contracts to return NFTs in response to the smart contract calls. For example, the smart contract execution can issue an NFT to a token well identifier associated with a vetted entity and attach a transaction to the managed blockchain(s). The attached transaction can include additional information such as an expiration timer for issuing a token to the vetted entity (e.g., defined by a credential version), identification information about the vetted entity, identification information about the user, or any other suitable information.

[0152] The security information manager can assign scope sharing privileges (e.g., a scope of one or more security user information data points) included in a credential request to an NFT. For example, data points, security information segments, or other suitable portions of the security information that define a user via scope sharing definitions can be assigned as privileges to the NFT returned by the blockchain service, and the one or more privilege assignments can be stored by the security information manager.

[0153] In another example, the software call from the security information manager to the blockchain service for an NFT can include a scope sharing definition, and the blockchain service can assign corresponding privileges to the NFT to access the user's security information. For example, the blockchain service can attach the scope sharing definition (via the execution of one or more smart contracts) to the blockchain(s) as part of the recorded transaction(s).

[0154] At block 622, process 602 can transmit the credential(s). For example, the security information manager can send the obtained credential(s) to the requesting system. Alternatively, the blockchain service can directly transmit the credential(s) to the requesting system via a separate communication channel.

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

[0156] At block 626, process 602 can authenticate and verify a data access request. For example, the data access request can include credentials such as an NFT. The security 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 the (one or more) blockchains that record transactions for the NFT, such as: the vetted entity to which the NFT is assigned, the registered users to whom the NFT privileges apply, the expiration time of the NFT, the data points to which the NFT has privileged access, or any other transaction information stored by the (one or more) blockchains. When the expiration timer has not expired and the vetted entity to which the NFT is assigned matches the identifier of the vetted entity issuing the request, the security information manager can authenticate the data access request.

[0157] The data access request can also include the identifier of the vetted entity issuing the request, and the security information manager can verify whether the identifier of the vetted entity included in the data access request matches the vetted entity returned by the blockchain service. Additionally, the data access request can include user identification information identifying the user, and the security information manager can verify whether the user information matches one of the registered persons managed by the security information manager, a user affiliated with the NFT returned by the blockchain service, or any combination thereof.

[0158] At block 628, process 602 can retrieve a limited scope of security information in response to the data access request. For example, the security information manager can query a security data repository storing the security information of the user to obtain the user information requested in the data access request.

[0159] The security information manager can generate a data query in response to the authenticated and verified data access request that retrieves a limited scope of security user information from the security data repository. For example, the data query can be scoped based on the scope privileges assigned to the authenticated credentials. Additionally, a data query can be generated in response to the data requested by the access request, and then the security information manager can limit the data query based on the privileges of the provided credentials. In another example, the security user information requested by the data access request can be scoped based on the privileges of the provided credentials, and a data query can be generated to retrieve the limited scope of data. Then the security data repository can return the limited scope of security user information in response to the data query.

[0160] At block 630, process 602 can provide a limited scope of secure user information to the requesting system. For example, the secure information manager can return the secure user information requested by the data access request or a limited scope version of the secure user information requested by the data access request, such as when the provided credentials do not have access privileges to all of the secure user information requested by the data access request.

[0161] Figure 7 Illustrated is a flowchart for retrieving limited scope user information from a secure data repository and logging the access according to an example embodiment. Process 700 can be performed by: a secure information manager that allows a vetted entity to access a user's secure information, such as in response to a request from a computing system of the vetted entity; one or more components of the secure data repository; one or more components of the blockchain service; or any combination thereof.

[0162] At block 702, process 700 can query the secure data repository for the user's secure information. For example, a vetted entity can request a set of data points of the user's secure information. A data repository query (e.g., SQL, any other suitable database query) can be generated that queries all or a portion of the data points of the user's secure information requested by the vetted entity. For example, the data repository query can be restricted to the privileges of the vetted entity (e.g., the credentials assigned to the vetted entity).

[0163] At block 704, process 700 can receive limited scope user information from the secure data repository. For example, the limited scope user information can be restricted by the formulated data repository query or the data repository itself. The generated query can be restricted to a limited scope of the user's secure information that the request allows the vetted entity to access. Additionally, or alternatively, the data repository can return limited scope data points of the user's secure information that are restricted to the data points that the vetted entity is allowed to access.

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

[0165] At block 708, process 700 may log the request(s), the limited information accessed via the request(s), the timestamp, and other suitable data related to the received request(s) and the limited data. For example, access to a user's security information may be logged in any suitable data structure. In some embodiments, the storage structure includes a blockchain, and each request and / or instance of permitted access to the user's security information is logged as a block of the blockchain.

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

[0167] The embodiments allow for limited access to a user's security information using non-fungible tokens. The user may register with the security information manager and control the scope of sharing the user's security information. The user may allow vetted entities (e.g., service providers, healthcare providers, other individuals, etc.) to access the user's security information via a portable access point. The user may also select a scope definition that controls how the user's security information is shared with the vetted entity. The vetted entity may scan the user's portable access point and request credentials to permit access to the user's security information via the scan. For example, the credentials may be non-fungible tokens (NFTs), and access privileges corresponding to the user's selection may be assigned to the credentials.

[0168] Then, the vetted entity may use the credentials to issue one or more data access requests. The request(s) may be authenticated and verified by the security information manager, and the security information manager may permit the vetted entity to have limited access to the user's security information. The limited access may correspond to the access privileges assigned to the credentials. The user may dynamically revoke the access privileges assigned to the credentials and / or the vetted entity via the user's wireless device. The access privileges assigned to the credentials may also include an expiration timer, after which the credentials will no longer be authenticated by the security information manager.

[0169] The implementation realizes fine-grained user control access to the user's security information, which is efficient and secure. The user can efficiently define the sharing conditions of the user's security information via the user's portable access point. In addition, the (one or more) credentials issued by interacting with the user's portable access point and the security information manager can enforce the user's sharing conditions in a trustworthy manner. When the issued (one or more) credentials are (one or more) NFTs, the blockchain-based management of the (one or more) NFTs ensures that the credentials are authentic and mitigates fraudulent attempts to access the user's security information.

[0170] The features, structures, or characteristics of the present disclosure described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrases "one embodiment", "some embodiments", "an embodiment", "certain embodiments", or other similar language means that the particular features, structures, or characteristics described in connection with the embodiments may be included in at least one embodiment of the present disclosure. Thus, the phrases "one embodiment", "some embodiments", "an embodiment", "certain embodiments", or other similar language that appear throughout this specification do not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0171] Those of ordinary skill in the art will readily understand that the embodiments discussed above may be practiced with steps in a different order and / or with elements different from those disclosed in the configuration. Thus, while the present disclosure contemplates the embodiments outlined, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be obvious while remaining within the spirit and scope of the present disclosure. Therefore, reference should be made to the appended claims to determine the scope and bounds of the present disclosure.

Claims

1. A method for allowing limited access to a user's security information, the method include: receiving, at a security information manager, a credential request for one or more credentials that allow access to a user's security information, the request including user identification information, entity identification information, and a credential definition; verifying the user identification information and the entity identification information at the security information manager; assigning a blockchain credential corresponding to the credential definition to the entity in response to the validation, wherein the blockchain credential assignment is recorded on a private blockchain that manages the blockchain credential; and In response to one or more access requests from an entity that include the assigned blockchain credentials, limited-scope access to the user's secure information is permitted corresponding to the access permissions of the blockchain credentials.

2. The method of claim 1, wherein the method further comprises: allowing limited access to the user's security information; include: receiving, at a security information manager, the one or more access requests, the access requests including unauthenticated credentials; Authenticating unauthenticated credentials as non-fungible tokens assigned to entities via a private blockchain; and In response to the authentication, limited access to the user's secure information is allowed corresponding to the non-fungible token access permission.

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

4. A method as claimed in claim 1, wherein the limited scope access to the user's security information includes access to limited scope data points of the user's security information, and the limited scope data points include a predefined correspondence with the access permission of the non-fungible token assigned to the entity.

5. A method as claimed in claim 1, wherein the limited scope access to the user's security information provided by the assigned non-fungible token includes access to the user's security information for a limited duration, the limited duration corresponding to the access permissions of the non-fungible token assigned to the entity.

6. The method according to claim 1, in, The credential request received at the security information manager is transmitted by a computing system of the entity, The computing system of the entity generates a credential request by scanning a portable access point of the user, the credential request encoding at least a portion of the user identification information and a credential version, and The portion of the user identification information and the credential definition are obtained by the entity's computing system via scanning of the portable access point.

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

8. The method of claim 1, further comprising: include: Storing one or more logs of limited-scope access to secure information of a user, the logs comprising one or more of: an identifier of an entity, a portion of a request, secure information of the user accessed by the entity, a timestamp for accessing the accessed secure information of the user, or any combination thereof, wherein the one or more logs are recorded as blocks of an immutable blockchain.

9. The method according to claim 8, further comprising: include: In response to an audit request from a user, at least a portion of the one or more stored logs is provided.

10. A non-transitory computer readable medium having stored thereon instructions which, when executed by a processor, cause the processor to allow limited access to a user's secure information, in, When executed, the instructions cause the processor to: receiving, at a security information manager, a credential request for one or more credentials that allow access to a user's security information, the request including user identification information, entity identification information, and a credential definition; verifying the user identification information and the entity identification information at the security information manager; assigning a non-fungible token corresponding to the credential definition to the entity in response to the verification, wherein the non-fungible token assignment is recorded on a private blockchain that manages the non-fungible token; and In response to one or more access requests from an entity that include an assigned non-fungible token, limited access to the user's secure information corresponding to the access permissions of the non-fungible token is allowed.

11. The non-transitory computer readable medium of claim 10, wherein allowing limited access to the user's security information is also include: receiving, at a security information manager, the one or more access requests, the access requests including unauthenticated credentials; Authenticating unauthenticated credentials as non-fungible tokens assigned to entities via a private blockchain; and In response to the authentication, limited access to the user's secure information is allowed corresponding to the non-fungible token access permission.

12. The non-transitory computer readable medium of claim 10, wherein the entity comprises a reviewed entity that is reviewed after executing a review workflow.

13. A non-transitory computer-readable medium as described in claim 10, wherein the limited scope access to the user's security information includes access to limited scope data points of the user's security information, and the limited scope data points include a predefined correspondence with access permissions assigned to the non-fungible token of the entity.

14. A non-transitory computer-readable medium as described in claim 10, wherein the limited-scope access to the user's security information provided by the assigned non-fungible token includes access to the user's security information for a limited duration, the limited duration corresponding to the access permissions of the non-fungible token assigned to the entity.

15. The non-transitory computer readable medium of claim 10, in, The credential request received at the security information manager is transmitted by a computing system of the entity, The computing system of the entity generates a credential request by scanning a portable access point of the user, the credential request encoding at least a portion of the user identification information and a credential version, and The portion of the user identification information and the credential definition are obtained by the entity's computing system via scanning of the portable access point.

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

17. The non-transitory computer readable medium of claim 10, wherein the instructions further cause the processor to: Storing one or more logs of limited-scope access to secure information of a user, the logs comprising one or more of: an identifier of an entity, a portion of a request, secure information of the user accessed by the entity, a timestamp for accessing the accessed secure information of the user, or any combination thereof, wherein the one or more logs are recorded as blocks of an immutable blockchain.

18. The non-transitory computer readable medium of claim 17, wherein the instructions further cause the processor to: In response to an audit request from a user, at least a portion of the one or more stored logs is provided.

19. A system for allowing limited access to a user's secure information, the system include: processor; as well as a memory storing instructions executed by the processor, the instructions configuring the processor to: receiving, at a security information manager, a credential request for one or more credentials that allow access to a user's security information, the request including user identification information, entity identification information, and a credential definition; verifying the user identification information and the entity identification information at the security information manager; assigning a non-fungible token corresponding to the credential definition to the entity in response to the verification, wherein the non-fungible token assignment is recorded on a private blockchain that manages the non-fungible token; and In response to one or more access requests from an entity that include an assigned non-fungible token, limited access to the user's secure information corresponding to the access permissions of the non-fungible token is allowed.

20. The system of claim 19, wherein limited access to the user's security information is permitted. include: receiving, at a security information manager, the one or more access requests, the access requests including unauthenticated credentials; Authenticating unauthenticated credentials as non-fungible tokens assigned to entities via a private blockchain; and In response to the authentication, limited access to the user's secure information is allowed corresponding to the non-fungible token access permission.

Images