Access manager using authentication and verification to limit access to user information

Abstract

Embodiments use credential authentication and user information verification to allow range-limited access of security information to a user. Certain information sharing protocols may require an unambiguous grant to share the user's security information with the requesting entity. In some scenarios, such an explicit grant may be impractical, such as when a user cannot provide such an explicit grant. Embodiments of a security information manager can allow a reviewed entity to range and time limited access to security information of a user in such scenarios, such as when the reviewed entity provides an assertion that the user cannot provide an explicit grant. For example, in one or more scenarios with an emergency situation, the security information manager can allow a reviewed entity to access a limited range of user information corresponding to a relationship of the reviewed entity to a user, a role in a workflow, or other suitable characteristics of the reviewed entity.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to a secure storage system(s) that uses credential authentication and user information verification to allow limited access to a user's secure information. BACKGROUND

[0002] The proliferation of computing and connected devices has generated a large amount of data that requires management. As the size of data grows, 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. Security technologies that allow users to manage secure information, such as authentication, verification, and explicit permission workflows, can be cumbersome and, in some scenarios, impractical. In scenarios that cause friction for traditional data sharing protocols, a security protocol that enables practical secure data sharing can provide significant value. SUMMARY

[0003] Embodiments of the present disclosure generally relate to a system and method that uses credential authentication and user information verification to allow limited access to a user's secure information. A request to access a user's secure information can be received at a secure information manager from a computing system of a vetted entity, the request including identifying information of the user and one or more credentials issued to the vetted entity. The identifying information of the user can be verified to match a pre-registered person at the secure information manager, where the identifying information of the user includes one or more of: user information obtained via scanning a personalized portable access point of the user, biometric information sensed from the user, a representation of an identification document including an image of the user, an image of the user's face, or an image of the user's eyes, or any combination thereof. The one or more credentials and the vetted entity can be authenticated, where the authenticated one or more credentials allow the vetted entity limited access to the user's secure information for a limited duration of time. In response to the verification and authentication, the computing system associated with the vetted entity can be allowed limited access to the user's secure information for the limited duration of time.

[0004] The features and advantages of the embodiments will be apparent from the following description, the embodiments will be described, by way of example only. BRIEF DESCRIPTION OF DRAWINGS

[0005] Further embodiments, details, advantages, and modifications will become apparent from the following detailed description, the detailed description referring to the accompanying drawings.

[0006] Figure 1 FIG. illustrates a system that uses credential authentication and user verification to allow limited access to a user's secure information, according to example embodiments.

[0007] Figure 2 FIG. illustrates a block diagram of a computing device operating in conjunction with a prediction system, according to example embodiments.

[0008] Figure 3A and Figure 3B FIG. illustrates a system with a secure information manager that allows limited access to secure user information, according to example embodiments.

[0009] Figure 4 FIG. illustrates a flow diagram of using credential authentication and user verification to allow limited access to a user’s secure information, according to example embodiments.

[0010] Figure 5 FIG. illustrates a flow diagram of retrieving limited-scope user information from a secure data store and logging the access, according to example embodiments. DETAILED DESCRIPTION

[0011] Embodiments use credential authentication and user information verification to allow limited access to a user’s secure information. Certain information sharing protocols can require explicit consent to share a user’s secure information with a requesting computing system and / or entity. However, in some scenarios, such explicit consent can be impractical and / or impossible, such as when a user is unconscious or otherwise unable to provide such explicit consent. Embodiments of a secure information manager can allow vetted entities to have limited access to a user’s secure information in such scenarios, for example when the vetted entity provides an assertion that the user is unable to provide explicit consent. For example, in an emergency scenario or any other suitable scenario with an emergency, the secure information manager can allow a vetted entity to access limited-scope user information corresponding to the vetted entity’s relationship to the user, role in a workflow, or other suitable characteristic of the vetted entity.

[0012] The vetted entity can go through a vetting workflow that allows the entity to have access specific to such scenarios. For example, the vetted entity can be an individual, an organization, a group of individuals, etc., and the vetting workflow can include one or more of: identity verification, credential verification (e.g., government credentials, medical credentials, financial advisor credentials, etc.), cyber-security verification, and any other suitable vetting. In some implementations, a computing system associated with the vetted entity can transmit a request to the secure information manager for the user’s secure information, for example when an urgent scenario is encountered and the user is unable to explicitly consent to the access.

[0013] In some implementations, the request includes one or more entity credentials, identifying information of the user, and / or assertions related to the user and / or the scenario. The entity credential(s) can include credentials issued to the entity (e.g., issued to one or more users and / or identities associated with the entity) after the entity is reviewed through a review workflow. Example entity credential(s) include a blockchain-supported non-fungible token (NFT), an access token (e.g., security assertion markup language (SAML), open authorization (OAuth), etc.), one or more cryptographic keys or signatures, etc. In some implementations, the security information manager can authenticate the entity credentials provided in the request before allowing access to the secure user information.

[0014] In some implementations, the identifying information of the user included in the request can include one or more of a set 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 identifying a government-issued document of the user (e.g., driver’s license, passport, etc.), biometric information (e.g., fingerprint, eye scan, DNA information, etc.), and other suitable identifying information of the user. For example, the request can be transmitted from a computing system associated with the reviewed entity, and the user identifying information can be obtained from the user himself / herself, a photo identification of the user, a wireless device of the user, a wireless device of another person associated with the user, etc.

[0015] In some implementations, the scanning element(s) of the computing system associated with the reviewed entity can obtain biometric information from the user, such as by scanning the user’s fingerprint(s) via a fingerprint reader or any suitable scanning device, scanning the user’s retina(s) via an eye scanner or any suitable eye scanning device, etc. In some implementations, the scanning element(s) of the computing system associated with the reviewed entity can scan other suitable identifying information of the user, such as the user’s driver’s license or other suitable photo identification, one or more visual depictions from a wireless device of the user or an additional user having a predefined relationship with the user (e.g., a user-specific portable access point for obtaining user information), etc.

[0016] For example, the user’s wireless device (e.g., a management application executing at the wireless device) can display a user-specific portable access point including a visual code, such as a QR code, an alphanumeric code, or any other suitable code. In some implementations, the code can be embedded in an image of the user. One or more scanning elements in the computing system(s) of the reviewed entity can scan the portable access point and obtain the identifying user information for the request.

[0017] In some implementations, the reviewed entity may include any suitable entity performing services for the user, such as home services (e.g., home construction, repair, etc.), automotive services (e.g., repairing the user's car), medical services (e.g., medical services related to doctor's offices, hospitals, emergency rooms, first responders, etc.), financial services (e.g., accounting, trusteeship, financial advisory, etc.), and technical services (e.g., system administrator services, web hosting, etc.). In this example, after executing one or more review workflows, the relationship between the reviewed entity and the user is predefined at the security information manager. Accordingly, the scope of the user's security information can be limited so that, in response to a request, only the reviewed entity is provided with information corresponding to the relationship between the reviewed entity and the user and relevant to the emergency scenario.

[0018] For example, an vetted entity acting as a technology service provider may be limited to certain network information, network security information, cryptographic key information, etc., so that the technology service provider can access user-related systems and perform any urgent upgrades and / or patches. In another example, an vetted entity acting as a hospital, emergency room entity, and / or first responder may be limited to certain data points in the user's electronic health record, such as blood type, medication list, allergy history, past health conditions, recent diagnostic test results (e.g., blood pressure, blood sugar, cholesterol, etc.), or other user health information relevant to an emergency scenario.

[0019] In some implementations, the security information manager may grant limited access to a user's information for a restricted period of time. For example, in an emergency scenario, providing some of the user's information to a vetted entity may be urgent, such as before the user is able to explicitly grant access, but after a period of time, the user becomes able to make such a grant. Accordingly, after a period of time, if no explicit consent is received from the user for continued access to the user's security information, the implementation may revoke access to the user's security information.

[0020] In some implementations, vetted entities are granted limited access to a user's security information, which corresponds to one or more qualifications, registrations, or other suitable public credentials. For example, a technical system administrator may possess qualifications from one or more accrediting organizations, and a vetted entity may be permitted limited access corresponding to those qualifications when the qualifications(s) are valid and reputable. In another example, emergency room personnel and / or first responders may be accredited by various accrediting committees and / or organizations, and a vetted entity may be permitted limited access corresponding to those qualifications(s) (e.g., health record data points associated with an emergency room visit or first responder scenario) when the qualifications(s) are valid and reputable.

[0021] In some implementations, a request for access to a user's security information from an audited entity may also include one or more assertions relating to the user or scenario. Example assertions include a user being incapacitated, unconscious, or otherwise unable to provide explicit access. In some implementations, the assertions provide descriptors and / or categories of an emergency scenario. In an example where the audited entity is a system administrator, the descriptor / category may include website downtime, managed software application downtime, network security vulnerability, or other suitable descriptors or categories.

[0022] In some implementations, one or more predefined categories may correspond to different ranges of (one or more) of the user's security information. In an example where the reviewed entity includes emergency room personnel and / or first responders, a category of health event may be included in the request. Predefined categories of health events may include: loss of consciousness without obvious signs of trauma, gunshot wound, stab wound, car accident, loss of consciousness with undetermined signs of trauma, etc. These different predefined categories may map to different data points in the user's electronic health record. For example, a first request from a reviewed entity asserting that the user is unconscious may map to a first range of the user's security information (e.g., electronic health record), while a second request from a reviewed entity asserting that the user is unconscious and has signs of physical trauma may map to a second range of the user's security information, which is different from the first range.

[0023] The predetermined scope definition can also be mapped to the role of the reviewed entity relative to the user. For example, when the reviewed entity is a healthcare provider, the role of the reviewed entity can include the type of healthcare provider (e.g., emergency room, nurse, emergency care, etc.), the type of medical service provided by the healthcare provider (e.g., surgery, non-surgical emergency care, etc.), or any other suitable role definition. For example, a first request from the reviewed entity including a first role can be mapped to a first scope of the user's security information (e.g., electronic health record), while a second request from the reviewed entity including a second role (different from the first role) can be mapped to a second scope of the user's security information, which is different from the first scope. Similarly, a first request from the reviewed entity including a first role can be mapped to a first duration for which access to the user's security information is permitted, while a second request from the reviewed entity including a second role (different from the first role) can be mapped to a second duration for which access to the user's security information is permitted, which is different from the first duration.

[0024] Users can define predetermined scopes and / or durations mapped to a given role, and in some examples, assign roles to one or more vetted entities. Users can generate / define roles and scope / duration definitions for each role via an information management application (e.g., a web application, a native application, etc.) (such as via a user's wireless device). Once a user has defined a given role and its corresponding scope / duration, the user can assign known vetted entities to that role. For example, known vetted entities may include healthcare providers that the user has previously visited; those located near the user's physical location, such as the user's home and / or work address; those explicitly selected by the user through input at the information management application; and so on.

[0025] Users can assign roles and corresponding scope definitions / durations to any known, verified entity. Authenticated access requests from known, verified entities (e.g., including credentials(s) and assertions of user incapacity) can allow the verified entity access for the defined duration corresponding to the scope definition defined for the assigned role to that known, verified entity. Users can also define roles and corresponding scope definitions / durations for unknown, verified entities, and access requests(s) from unknown, verified entities (e.g., including credentials(s) and assertions of user incapacity(s)) can allow the verified entity access for the defined duration corresponding to the scope definition defined for that unknown, verified entity.

[0026] In some implementations, healthcare providers and / or vetted entities may comply with standard procedures for accessing users’ secure information. Additional technologies described in this disclosure may enhance, supplement, and / or improve these standard procedures, for example, in scenarios where: a) there is an incapacitated user who has not previously registered / enrolled as a patient with a healthcare provider; b) the healthcare provider requests emergency access to view the user’s electronic health records; or c) or any other suitable scenario.

[0027] In some implementations, the limited access granted by the Security Information Manager to an accredited entity can be logged for auditing purposes, such as by the user, one or more accreditation organizations and / or one or more committees, or any other suitable body. For example, the scope of information accessed by the accredited entity can be logged, and the user can examine which data points of security information the accredited entity requested, which data points the Security Information Manager provided to the accredited entity, and the timestamps of the information access. In some implementations, the accredited entity also provides one or more assertions in the submitted request(s), and these assertions can be logged in association with the scope of the requested / accessed information. For example, if a user enters the emergency room in an incapacitated state, the user can audit the emergency access granted to emergency room personnel by the Security Information Manager after the user receives treatment, recovers, and is discharged.

[0028] In some implementations, users can compare submitted assertions(s) with the user's health status and healthcare. For example, if a user's medical treatment clearly indicates that the user has not experienced any trauma, but an emergency room information request includes an assertion that "the user has lost capacity and has undefined signs of trauma," then the user can report the inconsistency or take other appropriate remedial action. Furthermore, users can determine when the user regains consciousness, thereby determining when the user regains the ability to provide explicit authorization for information access (e.g., when the emergency scenario is no longer applicable). In this example, the user can compare the timestamp of an emergency request for user information with a known timeline of the user's recovery and report any inconsistencies (e.g., a request with an assertion that the user was unconscious during the recovery period when the user regained consciousness).

[0029] In some implementations, users can report such violations or inconsistencies to a security information manager, which can then reconsider the vetted status of the emergency room and / or emergency room personnel. In another example, users can report such violations to a accreditation organization and / or committee for consideration when granting accreditation to the emergency room and / or emergency room personnel. In some implementations, the logged requests, security information accesses, and / or assertions of vetted entities can be maintained by a blockchain service.

[0030] Reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure can be practiced without these specific details. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. Similar reference numerals will be used to denote similar elements wherever possible.

[0031] Figure 1 The illustration depicts a system for allowing limited access to a user's security information according to an example embodiment. Figure 100 includes a user 102, a vetted entity 104, an authenticator and verifier 106, and a secure data repository 108. In some embodiments, the vetted entity 104 may request urgent access to the security information of the user 102 stored in the secure data repository 108 from the authenticator and verifier 106. The vetted entity 104 can be any suitable individual, group, organization, or company that has undergone a vetted workflow.

[0032] In some implementations, the audited entity 104 includes one or more computing systems associated with the audited entity. For example, an application at one or more computing systems may allow the audited entity 104's registered identity to log in to that application. In some implementations, the audited entity 104 and one or more registered identities of the audited entity may register with an authenticator and verifier 106. For example, the authenticator and verifier 106 may be part of a security information manager that manages access to the secure data repository 108.

[0033] In some implementations, user 102 may be co-located (located in the same physical location) with one or more computing systems of the vetted entity 104. For example, one or more computing systems may have access to user information from user 102, such as biometric information, scanned versions of photographic identification, etc. In this example, user 102 may be incapacitated, and therefore may not be able to explicitly grant permission to the vetted entity 104 to access the user's security information. In other examples, user 102 and the vetted entity 104's computing systems may be geographically distant.

[0034] Then, the audited entity 104's computing system(s) can send a request to the authenticator and verifier 106 to access the user's security information stored in the secure data repository 108. For example, the request may include credentials issued to the audited entity (e.g., one or more NFTs, one or more access tokens, one or more cryptographic signatures, etc.), the user 102's identification information (e.g., obtained from the user, stored in the audited entity's database, a scanned version of the user's photographic identity document, etc.), and one or more assertions describing the user's condition (e.g., an assertion that the user cannot provide an explicit grant of access).

[0035] The authenticator and verifier 106 can authenticate one or more credentials included in the request and verify the user's identification information. For example, the authenticator and verifier 106 can authenticate that one or more requested credentials correspond to one or more credentials issued to the vetted entity 104. The authenticator and verifier 106 can also verify that the user's identification information corresponds to a registered person whose security information is stored at the security data repository 108. For example, user 102 can register with a managed security information service, such that user 102's security information is stored at the security data repository 108. Based on this registration, the authenticator and verifier 106 can store verification information about user 102, such as 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., fingerprints, eye scans, etc.), vehicle brand, model and / or license plate, representation of government-issued identification (e.g., driver's license photo), image of the user's face, etc.

[0036] In some implementations, the security data repository 108 may store security information for multiple registrants (e.g., hundreds, thousands, hundreds of thousands, millions, etc.), and the authenticator and verifier 106 may store confirmation information for these registrants. The authenticator and verifier 106 may compare the user identification information included in the request with the confirmation information of these registrants to find a match.

[0037] When the user identification information provided in the request matches the verification information of the managed person, the authenticator and verifier 106 can verify that the request corresponds to the identified person whose security information is stored in the secure data repository 108. In some implementations, the authenticator and verifier 106 can generate a confidence score for the match. For example, the request may include the user's full name, date of birth, and the geographic location from which the request was initiated. In this example, the authenticator and verifier 106 may match the user's full name and date of birth with the registered person, but the postal code from which the request was initiated may not match the registered person's local postal code. Such a match may generate a confidence score that does not meet the verification criteria.

[0038] In some implementations, the confidence score for a match can be based on the quantity and quality of information in the request that matches the verification information of the managed person. For example, in the presence of a mismatched postal code, a matching full name, date of birth, and additional information (e.g., biometric information, photographic identification, etc.) can generate a confidence score that meets the verification criteria and allow limited access to the registered person's secure information.

[0039] In some implementations, the vetted entity 104 may include a hospital, emergency room, first responder group, emergency care facility, or any other suitable healthcare entity providing urgent medical care. In this example, user 102 may be unconscious, and the request for access to security information may be related to providing urgent medical care to user 102. Because the security information of user 102 sought by the vetted entity 104 is closely related to user 102's health, the implementations of the authenticator and verifier 106 are configured to provide a fast and reliable match between the user information in the request and a dataset of verification information stored for registered individuals.

[0040] In some implementations, the authenticator and verifier 106 can use a portion of the received request to limit the scope of the dataset of verification information stored for the registered person during a search for a match. For example, the initial scope of the dataset of verification information can be limited first using location parameters of the request (e.g., a group of co-located postal codes, cities, etc.), and then the limited dataset can be searched for matches of other parameters (e.g., full name and date of birth). In this example, the registered person could provide location parameters (e.g., within 50 miles of a postal code) to limit the scope of the dataset of verification information. In some implementations, the location in the request can include the location where the request originated, the location of user 102 (e.g., the address and / or postal code on the user's driver's license), or any other suitable location. The initial scope of the dataset of verification information stored for the registered person can be limited using one or more other suitable parameters corresponding to the request.

[0041] In some implementations, multiple potential matches may be found based on the user's identification information provided in the request. For example, the request may include a postal code, the user's full name, and one or more facial images of the user. Multiple registered individuals may match the requested user's full name and postal code. In such scenarios, the user's facial image(s) in the request can be used to select from multiple registered individuals.

[0042] For example, one or more facial images of a user can be compared with one or more potentially matching facial images (which are part of a dataset of verification information for registered individuals). This comparison can be performed by one or more computer vision models, such as one or more convolutional neural networks configured and trained to compare the facial images and output confidence scores for the matches. When a matching facial image that meets the confidence score criteria is found, the authenticator and validator 106 can verify that the user's identification information matches the verification information for this registered individual.

[0043] In some implementations, the authenticator and verifier 106 may include a master patient index that aggregates data from multiple sources, such as electronic health records, hospital systems, physician offices, etc. For example, a dataset of verification information for registered individuals may include data aggregated using one or more master patient indices. In some implementations, each registered individual may grant the authenticator and verifier 106 permission to aggregate user information from these sources. The data in the dataset of verification information may be aggregated from any other suitable source, such as the state Department of Motor Vehicles, other government entities, public records, etc.

[0044] In some implementations, once the authenticator and verifier 106 authenticates the requested credentials(s) and verifies that the user's identification information matches the verified information of the managed person, the authenticator and verifier 106 may allow the vetted entity 104 to access the user's security information stored in the secure data repository 108 with limited scope and time. For example, the scope of the user's security information may be limited to the relationship between the vetted entity 104 and the user 102, or other suitable characteristics of the vetted entity 104. In another example, access may be limited to a period of time (e.g., 12 hours, 24 hours, etc.), after which the authenticator and verifier 106 will no longer allow the vetted entity 104 to access the information unless another authenticated and verified request is issued.

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

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

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

[0048] System 210 may include memory 214 for storing information and instructions executed by processor 222. Memory 214 may contain various components for retrieving, presenting, modifying, and storing data. For example, memory 214 may store software modules that provide functionality when executed by processor 222. Modules may include operating system 215, which provides operating system functionality to system 210. Modules may include operating system 215, data access manager 216, and other application modules 218. Operating system 215 provides operating system functionality to system 210. Data access manager 216 may provide system functionality for allowing vetted entities limited access to a user's secure information, or may provide any other functionality disclosed herein. In some cases, data access manager 216 may be implemented as an in-memory configuration.

[0049] Nontransitory memory 214 may include a variety of computer-readable media that can be accessed by processor 222. For example, memory 214 may include random access memory (“RAM”), dynamic RAM (“DRAM”), static RAM (“SRAM”), read-only memory (“ROM”), flash memory, cache memory, and / or any other combination of nontransitory computer-readable media.

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

[0051] In some embodiments, system 210 may be part of a larger system. Therefore, system 210 may include one or more additional functional modules 218 to include additional functionality. Other application modules 218 may include, for example... Data Integrator

[0052] Cloud Infrastructure Autonomous Database Millennium HealtheIntent Seamless Exchange HealtheCare's various modules, and A representative product on the Health & Artificial Intelligence platform. Database 217 is coupled to bus 212 to provide centralized storage for modules 216 and 218 and to store, for example, registrant verification information, audited entity information, authentication and verification related information, etc. Database 217 can store data in an integrated collection of logically related records or files. Database 217 can be an operational database, analytical database, data warehouse, distributed database, end-user database, external database, navigation database, in-memory database, document-oriented database, real-time database, relational database, object-oriented database, Hadoop Distributed File System (“HFDS”), or any other database known in the art.

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

[0054] In this embodiment, system 210 may be decoupled from the device and may remotely provide the described functionality to the device. Additionally, one or more components of system 210 may not be included. For example, for functionality as a user or consumer device, system 210 may include a processor, memory, and a display, but exclude... Figure 2 One or more other components shown and including Figure 2 Smartphones or other wireless devices with additional components not shown.

[0055] Figure 3A and Figure 3B The illustration depicts a system with a security information manager according to an example embodiment, which allows for limited access to secure user information. Figure 300A includes source information 302, a requesting system 304, a security information manager 306, secure user information 308, a scanning module 310, a requester 312, an authenticator 314, a verifier 316, and a blockchain manager 318. The requesting system 304 may be implemented as a system of an audited entity, such as an entity that has performed an audit workflow through the security information manager 306. Source 302 may include sources of user information, such as the user's physical body, user identification documents (e.g., driver's license, passport, etc.), the user's wireless device (e.g., smartphone), and one or more other suitable sources of user information.

[0056] The requesting system 304 can obtain user information from the source 302. For example, the scanning module 310 of the requesting system 304 can scan biometric information from the user's body, such as fingerprint scanning, eye scanning, etc. In another example, the scanning module 310 can scan user identification documents, such as the user's driver's license, passport, etc.

[0057] In some implementations, scanning module 310 may scan the display of a user's wireless device, such as a visual code displayed via an application running on the user's wireless device. In some implementations, the visual code may be a portable access point containing the user's security information. For example, the user's wireless device (e.g., an application running on the wireless device) may display a user-specific portable access point containing a visual code, such as a QR code, alphanumeric code, or any other suitable code. In some implementations, the code may be embedded in the user's image. Scanning module 310 may be a dedicated device configured to scan portable access points and request information identifying the user, such as a wireless device including an image capture component (e.g., a camera) and running an application capable of decrypting the portable access point. In some implementations, the visual portable access point may be displayed by the user's wireless device on a lock screen (e.g., before entering a password), in the background of the wireless device, as an image stored in the wireless device's photo library, or via any other suitable display means.

[0058] In some implementations, a user's wireless device can grant restricted access to a secondary individual (e.g., a person with limited access to the user's wireless device) in emergency situations, such as using facial recognition, biometric data, and / or a login / password corresponding to the restricted access. Restricted access may allow the secondary individual to access the user interface displaying the user's visual portable access point, applications that allow the sharing of user identification information via wireless communication, etc.

[0059] In some implementations, the scanning module 310 may receive user identification information via an application running on the user's wireless device, which transmits such information via near-field communication, Bluetooth communication, or any other suitable wireless communication. For example, any suitable identification information stored on the user's wireless device may be transmitted / received, such as full name, date of birth, user image, portable access point image and / or information, user identifiers for one or more electronic health records (e.g., identifiers for the master patient index, identifiers interoperable with multiple electronic health record systems, etc.).

[0060] A user's wireless device can provide user identification information (e.g., displaying a visual code, transmitting identification information wirelessly, etc.) when the wireless device is offline (e.g., when the wireless device lacks a connection to the Internet, cellular network, and / or wireless LAN or any other suitable network connection). In this example, a component of a management application running locally on the wireless device can provide user identification information. For example, once the scanning module 310 receives / obtains user identification information from the user's wireless device, the requesting system 304 can fully utilize the network connection to communicate with the security information manager 306.

[0061] In some implementations, source 302 may include a wireless device containing a person with a predefined relationship to the user. For example, the user may be a person for whom the security information manager 306 manages the registration of security user information 308. The user may also register one or more predefined relationships with the security information manager 306, such as personal relationships (e.g., parent, spouse, child, friend, etc.), professional relationships (e.g., co-manager of enterprise applications, etc.), or any other suitable relationship.

[0062] In some implementations, one or more persons with a predefined relationship to the user may possess one or more wireless devices capable of providing the user's identification information to the requesting system 304. For example, any suitable user identification information provided by the user's wireless device can be transmitted to the scanning module 310 via the wireless device of the person with the predefined relationship to the user. In some implementations, the wireless devices of the one or more related persons include applications that have registered with the security information manager 306 and provide user identification information.

[0063] The requester 312 may transmit a request to the security information manager 306 for access to the secure user information 308. Figures 300B and Request 330 also depict the request transmitted by the requester 312 to the security information manager 306. For example, the transmitted request may include one or more credentials issued to an vetted entity associated with the requesting system 304, user identification information (e.g., obtained via source 302 and scanning module 310), and one or more assertions associated with the user.

[0064] In some implementations, the security information manager 306 can verify one or more credentials included in the request and verify user identification information included in the request. For example, the authenticator 314 can authenticate the provided credentials against an audited entity and the credentials issued to the audited entity. The authenticator 316 can verify that the user identification information provided in the request corresponds to the security user information 308 (e.g., a person who has registered with the security information manager 306, such that the person's security information is part of the security user information 308).

[0065] Blockchain Manager 318 can manage one or more blockchains for Security Information Manager 306. For example, credentials(s) issued to audited entities(s) may include(s) nonfungible tokens(s) or other suitable credentials(s) managed by Blockchain Manager 318. In another example, log data related to information accessed from Security User Information 308 may be stored on one or more blockchains managed by Blockchain Manager 318, such as for auditing functions.

[0066] A blockchain is a list of records linked together using cryptography, each record called a block. In some blockchain implementations, each block includes a timestamp, a hash of the previous block, and transaction data. The timestamp proves that the transaction data was included when the block was added, allowing us to obtain its hash. Because each block identifies the blocks preceding it, the set of blocks forms a chain, and each new block strengthens the set of blocks preceding it in the chain. Therefore, a blockchain can be difficult to modify because once data is added to the blockchain, it cannot be changed without altering subsequent blocks.

[0067] Non-fungible tokens (NFTs) are blockchain-based identifiers used to designate unique items. The assignment or ownership of these tokens can be tracked and verified through a distributed ledger (e.g., a blockchain). Such tokens may include an identifier for a unique item and / or a link to a representation of that unique item (e.g., via a traditional URL or a distributed file system such as IPFS).

[0068] The blockchain managed by blockchain manager 318 may include one or more blockchain data structures and smart contracts executed in conjunction with the blockchain data structures(s). For example, blockchain manager 318 may log data that records requests and accesses to user security information 308(s) by vetted entities. In another example, blockchain manager 318 may manage credentials(s) issued to vetted entities, such as NFTs corresponding to access levels of user security information 308. In some implementations, the credentials(s) managed by blockchain manager 318 may include access tokens (e.g., Security Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys, or signatures, etc.

[0069] Figure 300B includes a request-issuing system 304, a security information manager 306, secure user information 308, a request 330, identification information 332, one or more credentials 334, one or more assertions 336, a data query 338, user information 340, scope-restricted user information 342, and restricted user information 344. Similar to Figure 300A, the implementation of the request-issuing system 304 can be a system for reviewed entities (such as entities whose review workflow has been performed by the security information manager 306).

[0070] In some implementations, the system 304 issuing the request may interact with the user to generate the request 330, such as scanning parts of the user's body, scanning the user's identification documents, or communicating with the user's wireless device. The request 330 issued to the security information manager 306 may include user identification information 332, one or more credentials 334, and one or more assertions 336.

[0071] 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., fingerprints, eye scans, etc.), vehicle brand, model and / or license plate, representation of government-issued identity (e.g., driver's license photo), image of the user's face, etc. One or more credentials 334 may include blockchain-backed non-fungible tokens (NFTs), access tokens (e.g., Secure Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys or signatures, etc.

[0072] One or more assertions 336 can be asserted statements from a reviewed entity relating to the user and / or scenario. Example assertions are explicit grants of access to provide safety information about a user who is incapacitated, unconscious, or otherwise unavailable for such purposes. In some implementations, the assertion provides a descriptor and / or category of the emergency scenario.

[0073] In some implementations, one or more predefined categories may correspond to different ranges of access to a user's security information. In an example where the reviewed entity includes emergency room personnel and / or a first responder, the request may include a category of health event. Predefined categories of health events may include: loss of consciousness without obvious signs of trauma, gunshot wound, stab wound, car accident, loss of consciousness with undetermined signs of trauma, etc. These different predefined categories may map to different data points in the user's electronic health record. For example, a first request from a reviewed entity asserting that the user is unconscious may map to a first range of the user's security information (e.g., electronic health record), while a second request from a reviewed entity asserting that the user is unconscious and has signs of physical trauma may map to a second range of the user's security information, which is different from the first range.

[0074] The secure user information manager 306 can authenticate one or more credentials 334 and verify identification information 332. For example, the secure user information manager 306 can authenticate that one or more credentials 334 are credentials issued to an vetted entity associated with the requesting system 304. Examples of one or more credentials 334 include access tokens, cryptographic keys or other suitable cryptographic data (e.g., digital signatures), NFTs, or any other suitable credentials managed by a blockchain. The secure user information manager 306 can also verify that the identification information 332 corresponds to a registered person whose security information is stored as part of the secure user information 308.

[0075] In some implementations, secure user information 308 may include security information for multiple registered individuals. User information 340 may represent stored security information for a user verified against identification information 332. In some implementations, user information 340 may include a set of data points for a user, while scope-limited user information 342 may include a subset of those data points. In the example where secure user information 308 includes electronic health records and user health data, the set of data points for user information 340 may include an aggregation of the user's electronic health record data, while the subset of data points for scope-limited user information 342 may include metadata and / or summary data covering components of the aggregated electronic health record data.

[0076] For example, the scope-restricted user information 342 could be a predefined health data point that the user has pre-designated to be accessible in an emergency scenario or by a suitable, vetted entity including one or more authenticated credentials. In another example, the scope-restricted user information 342 could include health data points based on predefined templates, such as data points tailored for emergency room personnel and / or first responders. Example scope-restricted user information 342 includes the user's blood type, past health conditions, past surgeries, allergy history, current medications, or any other suitable user health data. In some implementations, user information 340 could be a segmented health record, while the data points included in the scope-restricted user information 342 could be any suitable fragment of that segmented health record.

[0077] In some implementations, user information 340 may be electronic health data segmented based on parameters. For example, parameters may include: the source or affiliation of a physician 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, physician and patient communications, physician notes, vaccine information, allergies, etc.), relevant health practices (e.g., cardiology, primary care, neurology, oncology, etc.), the date the information was initiated, the electronic health record format, other health information exchange standards Layer 7 (HL7) protocols, Faster Healthcare Interoperability Resources (FHIR) and / or FHIR-based Alternative Healthcare Applications and Reusable Technologies (SMART) data parameters, or any other suitable health data parameters. Scope-limited user information 342 may include user-defined portions of user information 340 (e.g., defined using parameters and / or parameter values) and / or predefined portions of user information 340 configured to provide sufficient health data to address emergency scenarios (e.g., custom templates).

[0078] In some implementations, in response to an authentication and verification request, the security information manager 306 may issue a data query 338 to the security user information 308. In response, the security information manager 306 may receive restricted user information 344, the scope of which may be limited based on the audited entity, the relationship between the audited entity and the user, one or more assertions included in the request, or any other suitable parameters. The security user information 344 may then be provided to the requesting system 304.

[0079] In some implementations, the vetted entity may include one or more registered identities. For example, the vetted entity may be an organization, and the registered identities may be some members of that organization. In some implementations, the vetted entity is a hospital, emergency room organization, or first responder organization, and the registered identities are emergency room personnel and / or nursing staff.

[0080] In some implementations, request 330 may be issued by the registered identity of an audited entity. For example, request 330 may include an indicator of the audited entity and the registered identity, such as one or more credentials 334, which, upon authentication, identify the registered identity and the audited entity. Any other suitable indicator may be included in request 330.

[0081] The scope of the restricted user information 344 can be limited to the registered identity associated with the verified entity making the request, and / or one or more credentials 334 of the verified entity or registered identity. For example, a registered nurse identity may not be able to perform certain surgeries that emergency room personnel can perform. Accordingly, a request from a registered nurse identity may correspond to a first version of the restricted user information 342, while a request from an emergency room personnel may correspond to a second version of the restricted user information 342, where the first version differs from the second version. For example, the second version may include data points related to certain surgeries not included in the first version.

[0082] In some implementations, the security information manager 306 may access a schedule of registered identities for an audited entity, and may further restrict access to user information to specific times within that schedule. The schedule may be a “on-call” schedule defining when a registered identity is active in a particular identity (such as in a role corresponding to the audited entity). For example, the audited entity may be a hospital, and the registered identity may be an emergency responder as part of the hospital’s emergency response services. The schedule accessible to the security information manager 306 may include the time when the registered identity is actively working as an emergency responder.

[0083] In some implementations, the security information manager 306 may communicatively link to the requesting system 304 to determine whether the registered identity of the vetted entity is "logged in" and "active" relative to the requesting system 304. For example, an emergency responder may log in to an emergency service provider's computing system (e.g., the requesting system 304) by, for example, at the start of a work shift, by entering a username and password in an application running on a mobile device or other computing device; by scanning a work badge at a scanning device linked to the emergency service provider's system; by scanning a token or device (e.g., an RFID token, a wireless device scanned via near-field communication, etc.) at a scanning device linked to the emergency service provider's system; or any combination thereof. In this example, when the registered identity is "active" and / or "logged in" relative to the requesting system 304, the security information manager 306 may, in response to a request from a registered entity associated with the vetted entity, allow limited access to the user's security information.

[0084] In some implementations, an vetted entity may be granted access to the security information of an incapacitated user via designated secondary contacts (e.g., emergency contacts). For example, a user may predefine one or more people as emergency contacts (e.g., predefine relationships with these individuals, specifying that these individuals are authorized to grant access to the user's security information in an emergency scenario) via a management application that manages the user's security information. These predefined relationships may include the user's name, contact information (e.g., phone number, email address, etc.), and a definition of the relationship relative to the user (e.g., spouse, friend, sibling, parent, child, etc.).

[0085] Once defined, one or more emergency contacts can receive an indication that the user has identified them as an emergency contact, such as via a message sent to a phone number (e.g., SMS, push notification, etc.) or email. In some implementations, one or more emergency contacts may be prompted to complete a workflow to register as a user's emergency contact. For example, a link (e.g., sent to a phone number or email address) may be sent to one or more emergency contacts, who can use the link to register on a security information manager, such as via a website, local application, web application, etc. Once one or more emergency contacts complete the workflow, they can be authorized to grant restricted access to the user's security information in an emergency situation.

[0086] In some implementations, a user can define one or more portions of a user's security information corresponding to each emergency contact. These portions defined for each emergency contact can be portions of the user's security information that are accessible when a specific emergency contact grants access. For example, a spouse or family member may be allowed to grant most or all access to the user's security information, while a friend or colleague may be allowed to grant a limited amount of access to the user's security information.

[0087] In response to a request for access to a user's security information received from a vetted entity in an emergency scenario (e.g., when a user is incapacitated), an implementation of the security information manager may contact one or more of the user's registered emergency contacts to obtain authorization. For example, the contact method may be a message sent to a registered phone or email address sent to one or more emergency contacts, a message via an application loaded on a registered smartphone (e.g., a message prominently displayed on the smartphone display and including a button that can be used to grant access), a phone call, or any other suitable contact method. When a specific emergency contact grants access, the vetted entity may be granted access to one or more portions of the user's security information corresponding to that specific emergency contact (e.g., portions of the user's security information defined for authorization from a specific emergency contact).

[0088] One or more workflows that grant access through one or more of the user's emergency contacts can be combined with Figure 3A and Figure 3B The functionality is executed in combination. For example, an vetted entity may be granted initial emergency access to a user's security information, while granting or denying access from one or more of the user's emergency contacts can confirm, restrict, and / or revoke access. In some scenarios, an vetted entity may not be granted access to a user's security information prior to receiving authorization from an emergency contact.

[0089] In some implementations, the user identification information received at the security information manager and / or the user profile stored at the security information manager may include an identifier in the master patient index and / or a cross-platform identifier that links to electronic health records across different record types, platforms, and / or electronic health record service providers. For example, the cross-platform identifier may link to a user's electronic health record implemented by a third-party platform or otherwise located outside the security information manager. The security information manager can use the cross-platform identifier to retrieve a user's security information to selectively allow access to vetted entities. In some implementations, the cross-platform identifier may be a portion of the user's user identifier (e.g., a prefix, suffix, etc.) stored at the security information manager. Accordingly, the cross-platform identifier may be derived from an existing user identifier.

[0090] The implementation shows a portable access point for a user, which can be scanned by a vetted entity to obtain user identification information. The portable access point may include an image (such as an image of the user's face) and encoded information. The encoded information may include a unique QR code or other suitable visual or symbolic (e.g., alphanumeric) code embedded in the image. In some implementations, the QR code and / or symbolic code may take full advantage of one or more of the following: holographic images, raised holographic images, pixelated codes, raised textured codes, etc. For example, the encoded information may be displayed as an embossed QR code on top of an image, for example, using a unique, encrypted long string identifier generated using an algorithm.

[0091] In some implementations, the encoded information may include a unique encrypted long string identifier generated via an encrypted long string identifier algorithm. The encrypted long string identifier may be unique, at least due to the algorithm that generated it. For example, if a fraudulent version of a portable access point attempts to copy the unique encrypted long string identifier, then the scanning of the image and encoded information will not match due to the unique algorithm used.

[0092] The unique encrypted long string identifier generated by the encrypted long string identifier algorithm can be dynamic, allowing new identifiers to be generated for each version of the portable access point, 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, the security information manager, which manages the user's security information, can receive dynamically generated identifiers for different versions of the portable access point. For example, the identifier can be dynamically generated via an information management application loaded on the user's wireless device that manages the user's portable access point, and this application can transmit the dynamically generated identifier to the security information manager. In another example, the identifier can be dynamically generated via a cloud service, and this cloud service can transmit the dynamically generated identifier to both the application managing the user's portable access point and the security information manager.

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

[0094] The audited entity system can be configured to scan users' portable access points, such as Figure 3AThe system comprises a scanning module 310 and a requesting system 304. Once the scanning module 310 scans the portable access point, the requesting system 304 (e.g., an application configured to decrypt the portable access point) can decrypt the encoded information and / or image of the portable access point. For example, the application at the requesting system 304 can decrypt a unique long numeric string (e.g., generated by a unique algorithm), user identification information, and other suitable decrypted data, and include the decrypted information in the access request sent to the security information manager 306. In some embodiments, the user identifier obtained from the portable access point via scanning can correspond to a user registered at the security information manager 306, and the identifier can be used to retrieve the user identification information of the registered user stored at the security information manager. In some embodiments, the user identification information itself can be obtained from the portable access point via scanning, and the requesting system 304 can provide the obtained user identification information to the security information manager 306 in the access request. Example user identification information encoded by a portable access point may include one or more of the following: full name, date of birth, social security number, local address and / or postal code, medical information (e.g., primary care physician, etc.), representation of biometric information (e.g., fingerprint, eye scan, etc.), vehicle brand, model and / or license plate, representation of government-issued identification (e.g., driver's license photo), representation of an image of the user's face, etc.

[0095] Figure 4 The diagram illustrates a flowchart, according to an example embodiment, for allowing restricted access to a user's security information using credential authentication and user verification. In one embodiment, Figure 4 (and below) Figure 5 The functionality is implemented by software stored in memory or other computer-readable or tangible media and executed by a processor. In other embodiments, each functionality may be implemented by hardware (e.g., by using an application-specific integrated circuit (“ASIC”), a programmable gate array (“PGA”), a field-programmable gate array (“FPGA”), etc.) or any combination of hardware and software.

[0096] At block 402, process 400 may receive a request to access a user's security information. For example, the request may be received from the vetted entity's computing system at a security information manager, and the request may include the user's identification information and one or more credentials issued to the vetted entity. In some implementations, the request may also include assertions(s) from the vetted entity, such as assertions related to the user, the scenario (e.g., an emergency situation related to the user), etc.

[0097] At box 404, processing 400 can verify the user's identification information. For example, one or more individuals may pre-register to manage their security information at a secure data repository. Verification may include matching the user's identification information in the request with the pre-registered individuals at the security information manager.

[0098] In some implementations, a user's identification information may be compared with verification information of a registered person to determine a match. Example identification information of the user in the request may include one or more of the following: user information obtained via scanning a user's personalized portable access point, biometric information sensed from the user (e.g., fingerprints, eye scans, etc.), a representation of an identification document including an image of the user (e.g., a photograph of a driver's license), an image of the user's face or the user's eyes, or any combination thereof.

[0099] At box 406, process 400 may authenticate one or more credentials included in the request. For example, one or more credentials may include tokens issued to an audited entity after an audit workflow has been executed. This authentication confirms that the request originates from an entity that has undergone the audit workflow. Tokens may include non-fungible tokens, access tokens, digital signatures generated using cryptographic keys issued to the audited entity, or any combination thereof. In some implementations, one or more credentials may be managed by a blockchain service capable of authenticating one or more credentials. In some implementations, the authenticated one or more credentials allow an audited entity limited access to a user's secure information for a limited duration.

[0100] At box 408, process 400 may transmit a supplemental access permission request to an additional user with a predefined relationship to the user. For example, a request from an audited entity may include one or more assertions that the user cannot provide explicit authorization to access the user's security information. As an additional safeguard for the user's security information, a predefined information guardian relationship may be established with one or more additional users. As an information guardian, the supplemental access permission request may be transmitted to the additional user's wireless device to prevent unauthorized access to the user's security information.

[0101] In some implementations, a supplemental access permission request is transmitted to one or more wireless devices of an additional user, and an explicit grant of the supplemental access permission request is received from said one or more wireless devices. In some implementations, the supplemental access request is displayed as a priority notification to at least one of the additional users via at least one of the wireless devices, which overrides the display of the wireless devices. For example, an application with overriding permission can be loaded onto the wireless devices of the additional users, and in response to receiving the supplemental access permission request, the application can override the display of the wireless devices with the supplemental access request. In some implementations, the overriding of the display can persist until input of a grant or deny request (from the additional user) is received.

[0102] In some implementations, a supplemental access request is displayed to at least one of the additional users via at least one of the wireless devices as an expiration notification with an expiration timer, and the at least one wireless device is configured to transmit an explicit grant of the supplemental access permission request in response to input prior to the expiration timer expiring. For example, the supplemental access request may be an overlay, panel, or other suitable display message that describes the purpose of the supplemental access request (e.g., allowing or denying access to the user's security information) and includes one or more buttons for explicitly granting or denying the request. In some implementations, the request may display language describing the relationship between the user and the additional users, such as "You have been designated as the guardian of [[Full Name]]'s security information."

[0103] At block 410, process 400 may, in response to verification and authentication, allow a limited-scoped access to a user's security information by a computing system associated with an audited entity for a limited duration. For example, the user's limited-scoped security information may be provided to the audited entity's computing system that issued the request. In some implementations, the audited entity's computing system is allowed access for a limited duration (e.g., 1 hour, several hours, 1 day, 2 days, 1 week, etc.), after which the access expires. For example, further access may be allowed in response to additional requests (after authentication and verification of the additional requests).

[0104] In some implementations, in response to verification, authentication, and one or more responses to a supplemental access permission request, a computing system associated with an audited entity may be allowed limited access to a user's security information for a limited duration. For example, computing system access may be allowed based on at least one response to a supplemental access permission request. In some implementations, computing system access may be allowed when no response to a supplemental access permission request is received. In some implementations, access to the computing system is denied when at least one response to a supplemental access permission request denies access.

[0105] In some implementations, the access request includes an assertion from an audited entity claiming that the user lacks the capacity or ability to explicitly authorize access to the user's security information, and granting limited access to the user's security information in response to the assertion. In some implementations, limited access to the user's security information includes access to limited data points within the user's security information, which include predefined correspondences to the assertion from the audited entity. In some implementations, the audited entity includes a predefined role relative to the user, and limited access to the user's security information includes access to limited data points of the user's security information corresponding to that predefined role.

[0106] At box 412, process 400 can terminate restricted access after the expiration criteria are met. In some implementations, the audited entity's computing system is allowed access for a limited duration, after which access is terminated. In some implementations, access to a user's security information can be controlled by the user's situation and emergency scenario. For example, if the audited entity is a hospital and the scenario is a user incapacitated in the emergency room, the user's status as a patient in the emergency room can control the audited entity's access to the user's security information.

[0107] In some implementations, when a user is discharged, the user's status in the audited entity's computing system can be updated (e.g., the Health Information Exchange Standard Layer 7 (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or FHIR-based SMART code / status indicating discharge status can be updated). In some implementations, such an update to the user's status can trigger the audited entity's computing system to terminate access to the user's security information upon request. In this scenario, the audited entity can regain access to the user's security information through other means, such as through explicit access granted by the user if the user is no longer incapacitated. In some implementations, the audited entity's access to the user's security information upon request can persist until the user's status indicates discharge. For example, a status update (e.g., HL7, FHIR, and / or FHIR-based SMART status) can indicate transfer to another medical department and / or medical organization within the hospital, and the audited entity's access to the user's security information can persist even when the user's status is a transfer rather than discharge.

[0108] In some implementations, a wireless device associated with a user receives an access request that explicitly grants an audited entity access to the user's security information. However, because the user may be incapacitated or unresponsive, they may not respond to the request. Access to the user's security information may be granted to the audited entity without explicit authorization from the user, relying on assertions from one or more of the audited entity. In some implementations, a response to the access request may be received from the user's wireless device, denying access and / or indicating that the user is not in an emergency situation. This can occur if the audited entity's computing system misidentifies the user and / or the security information manager incorrectly authenticates the user. In this example, access to the user's security information may be denied, and the audited entity's computing system may be warned that the user, identified by the user identification information included in the request, is not in an emergency situation. This indication can help correctly identify a user in an emergency situation.

[0109] In some implementations, in response to verification and authentication, before receiving a response to a supplemental access permission request transmitted to an additional user with a predefined relationship to the user (as described in reference block 408), process 400 may allow limited access to the scope of the user's security information by the computing system associated with the audited entity for a limited duration (as described in reference block 410). In this example, limited access may be allowed while awaiting a response to the supplemental access permission request because the user's health may be at risk.

[0110] By responding to access requests sent to a user (e.g., the user's mobile device) and / or additional users, and by responding to supplemental access requests sent to additional users (e.g., the additional user's mobile device), a user can revoke an audited entity's access to their secure user information. For example, the user and / or additional users can respond to the access request or supplemental access request with a DISALLOW response, which terminates the audited entity's access to the user's secure user information. In this example, the Security Information Manager can initiate reports to authorities regarding the audited entity's access requests and assertions. For example, revoked access could indicate that the audited entity fraudulently accessed the user's secure user information. The Security Information Manager can initiate reports to law enforcement and / or federal regulatory agencies, including identifying information about the audited entity (e.g., name, business address, etc.) and identifying information about the affected user (e.g., full name, etc.).

[0111] Figure 5The illustration depicts a flowchart, according to an example embodiment, for retrieving scoped user information from a secure data repository and logging access. In some implementations, process 500 may be performed by a security information manager that has granted vetted entities access to the user's security information, for example, in response to a request from a vetted entity's computing system. In another example, process 500 may be performed by one or more components of the secure data repository.

[0112] At box 502, process 500 can query a security data repository to obtain a user's security information. For example, an audited entity can request a set of data points to obtain a user's security information. A data repository query (e.g., SQL, any other suitable database query) can be generated to retrieve all or part of the data points requested by the audited entity to obtain the user's security information.

[0113] At block 504, process 500 may receive scope-restricted user information from a secure data repository. For example, scope-restricted user information may be queried from a designated data repository or restricted by the data repository itself. In some implementations, the generated query is restricted to a limited scope of the user's security information for which an vetted entity is permitted access. In some implementations, the data repository returns scope-restricted data points of the user's security information, which are restricted to data points for which an vetted entity is permitted access.

[0114] At box 506, process 500 may provide limited-scope user information to the requesting system of the vetted entity. For example, limited-scope data points of the returned user's security information may be transmitted to the computing system of the vetted entity that made the request.

[0115] At block 508, processing 500 may log one or more requests, scope-restricted information accessed via one or more requests, timestamps, and other suitable data related to the received requests and scope-restricted data. For example, access to a user's security information may be logged in any suitable data structure. In some implementations, the storage structure includes a blockchain, and each request and / or instance of permitted access to a user's security information is logged as a block in the blockchain.

[0116] At block 510, process 500 may provide logged data in response to an audit request. The implementation may allow a user (or any other suitable entity or person) to audit access to a user's security information. Logged information (including one or more requests, scoped information accessed via one or more requests, timestamps, and other suitable data relating to the received requests and scoped data) may be provided to the user or other suitable audit entity.

[0117] Implementations using credential authentication and user information verification allow for limited access to a user's security information. Some information-sharing protocols may require explicit authorization to share a user's security information with the requesting computing system and / or entity. However, in some scenarios, such explicit authorization may be impractical and / or impossible, such as when the user is unconscious or unable to provide such explicit authorization. Implementations of a security information manager may allow vetted entities to have limited access to a user's security information in such scenarios, for example, when a vetted entity provides an assertion that the user cannot provide explicit authorization. For example, in emergency scenarios or any other suitable scenario with an emergency, the security information manager may allow vetted entities to access a limited scope of user information corresponding to the vetted entity's relationship with the user, its role in the workflow, or other suitable characteristics of the vetted entity.

[0118] The features, structures, or characteristics of this 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 terms such as "one embodiment," "some embodiments," "a particular embodiment," "certain embodiments," or other similar language refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this disclosure. Therefore, the phrases "one embodiment," "some embodiments," "a particular embodiment," "certain embodiments," or other similar language appearing throughout this specification do not necessarily 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.

[0119] It will be readily understood by those skilled in the art that the embodiments discussed above can be practiced with steps in a different order and / or with elements in a configuration different from those disclosed. Therefore, while this disclosure contemplates the outlined embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be readily apparent while remaining within the spirit and scope of this disclosure. Therefore, reference should be made to the appended claims in order to determine the scope and limits of this disclosure.

Claims

1. A method for allowing restricted access to a user's security information, the method comprising: The Security Information Manager receives a request to access a user's security information from the audited entity's computing system. The request includes the user's identification information and one or more credentials issued to the audited entity. Verify that the user's identification information matches a person pre-registered at the security information manager, wherein the user's identification information includes one or more of the following: user information obtained by scanning the user's personalized portable access point, biometric information sensed from the user, a representation of an identification file including an image of the user, an image of the user's face or the user's eyes, or any combination thereof; Authentication is performed on the one or more credentials and the audited entity, wherein the authenticated one or more credentials allow the audited entity limited access to a range of the user's security information for a limited duration. as well as In response to verification and authentication, a limited range of access to a user's security information is permitted by the computing system associated with the audited entity for the limited duration.

2. The method of claim 1, wherein the one or more credentials include tokens issued to the audited entity after the audit workflow is executed.

3. The method of claim 2, wherein the token comprises one or more of the following: blockchain-managed nonfungible tokens, access tokens, electronic signatures generated using cryptographic keys issued to vetted entities, or any combination thereof.

4. The method of claim 2, wherein the access request includes an assertion from a vetted entity that the user is incapacitated or cannot be explicitly permitted access to the user's security information, and in response to the assertion, limited access to the user's security information is permitted.

5. The method of claim 4, wherein scope-restricted access to the user's security information includes access to scope-restricted data points of the user's security information, the scope-restricted data points including predefined correspondences with assertions from an audited entity.

6. The method of claim 1, wherein the reviewed entity includes a predefined role relative to the user, and scope-restricted access to the user's security information includes access to data points of the user's security information corresponding to the predefined role.

7. The method of claim 1, further comprising: In response to a request to access a user's security information, a supplementary access permission request is transmitted to one or more additional users with a predefined relationship to the user, wherein restricted access is permitted in response to the explicit granting of the supplementary access permission request.

8. The method of claim 7, wherein the predefined relationship assigns the user to be the guardian of the user's security information.

9. The method of claim 7, wherein a supplemental access permission request is transmitted to one or more wireless devices of the one or more additional users, and an explicit grant of the supplemental access permission request is received from the one or more wireless devices.

10. The method of claim 9, wherein the supplementary access request is displayed to at least one of the additional users as a priority notification overlaying the display of the one wireless device via at least one of the wireless devices.

11. The method of claim 9, wherein the supplementary access request is displayed to at least one of the additional users as an expiration notification with an expiration timer via at least one of the wireless devices, and the at least one wireless device is configured to transmit an explicit grant of the supplementary access permission request in response to input prior to the expiration timer expiring.

12. The method of claim 1, further comprising: One or more logs storing restricted access to a user’s security information, the logs including one or more of the following: an audited entity, a requested portion, the user’s security information accessed by the audited entity’s computing system, a timestamp of the accessed user’s security information, or any combination thereof.

13. The method of claim 12, wherein the one or more logs are recorded as blocks of an immutable blockchain.

14. The method of claim 12, further comprising: In response to an audit request from a user, at least a portion of the logs stored in the one or more locations is provided.

15. The method of claim 1, further comprising: In response to a request to access a user's security information, an access permission request is transmitted to the user, and one or more supplementary access permission requests are transmitted to one or more additional users who have a predefined relationship with the user.

16. The method of claim 15, wherein an access permission request is transmitted to the user's wireless device, and a supplementary access permission request is transmitted to one or more wireless devices of the one or more additional users.

17. The method of claim 16, wherein, Allow limited access to the user's security information until a response to the access permission request or supplemental access permission request is received. Receive one or more responses to an access permission request or a supplemental access permission request, wherein the one or more responses do not allow limited access to the user's security information. Based on the one or more responses mentioned above, restricted access to the user's security information will be terminated.

18. A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by a processor, causing the processor to grant restricted access to security information of a user, wherein the instructions, when executed, cause the processor to: The Security Information Manager receives a request to access a user's security information from the audited entity's computing system. The request includes the user's identification information and one or more credentials issued to the audited entity. Verify that the user's identification information matches a person pre-registered at the security information manager, wherein the user's identification information includes one or more of the following: user information obtained by scanning the user's personalized portable access point, biometric information sensed from the user, a representation of an identification file including an image of the user, an image of the user's face or the user's eyes, or any combination thereof; Authenticating the one or more credentials and the audited entity, wherein the authenticated one or more credentials allow the audited entity limited access to a range of the user's security information for a limited duration; and In response to verification and authentication, a limited range of access to a user's security information is permitted by the computing system associated with the audited entity for the limited duration.

19. The non-transitory computer-readable medium of claim 18, wherein the one or more credentials include tokens issued to the audited entity after the audit workflow is executed.

20. A system that allows restricted access to a user's security information, the system comprising: processor; as well as The memory stores instructions that are executed by the processor, the instructions configuring the processor to: The Security Information Manager receives a request to access a user's security information from the audited entity's computing system. The request includes the user's identification information and one or more credentials issued to the audited entity. Verify that the user's identification information matches a person pre-registered at the security information manager, wherein the user's identification information includes one or more of the following: user information obtained by scanning the user's personalized portable access point, biometric information sensed from the user, a representation of an identification file including an image of the user, an image of the user's face or the user's eyes, or any combination thereof; Authentication is performed on the one or more credentials and the audited entity, wherein the authenticated one or more credentials allow the audited entity limited access to a range of the user's security information for a limited duration. as well as In response to verification and authentication, a limited range of access to a user's security information is permitted by the computing system associated with the audited entity for the limited duration.

Images