Access manager that restricts access to user information using authentication and verification.

Abstract

The embodiment uses credential authentication and user information verification to grant limited scope access to a user's secure information. Some information sharing protocols may require explicit authorization to share a user's secure information with a requesting entity. In some situations, such explicit authorization may be impractical, such as when a user is unable to provide it. In such situations, an embodiment of the Secure Information Manager may grant the authorized entity limited scope and time access to the user's secure information, for example, if the authorized entity provides an assertion that the user is unable to provide explicit authorization. For example, in an emergency situation, the Secure Information Manager may allow the authorized entity to access limited scope user information corresponding to the authorized entity's relationship to the user, its role in the workflow, or other preferred characteristics of the authorized entity.

Description

Technical Field

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

Background Art

[0002] Background With the explosion of computing devices and connected devices, an enormous amount of data that requires management is being generated. As the size of data grows, the technical challenges related to the efficient management of data are becoming increasingly complex. For example, sharing secure data among multiple stakeholders has been a long-standing problem in the field of data management. Security technologies for users to manage secure information, such as authentication, verification, and explicit permission workflows, are cumbersome and may be impractical depending on the situation. In situations that cause friction in conventional data sharing protocols, a security protocol that realizes practical and secure data sharing can provide sufficient value.

Summary of the Invention

[0003] Summary Embodiments of this disclosure generally pertain to systems and methods for granting limited access to a user's secure information using credential authentication and user information verification. A request for access to a user's secure information may be received by a secure information manager from a computing system of an authorized entity, and this request may include the user's identification information and one or more credentials issued to the authorized entity. The user's identification information may then be verified to match a person pre-registered with the secure information manager. The user's identification information may include one or more of the following: user information obtained by scanning the user's individual portable access points, biometric information detected from the user's person, a display of an identification document including an image of the user, an image of the user's face or eyes, or any combination thereof. One or more credentials and the authorized entity may then be authenticated, and these authenticated one or more credentials may grant the authorized entity limited access to the user's secure information for a limited period of time. In response to verification and authentication, the computing system associated with the authorized entity may be granted limited access to the user's secure information for a limited period of time.

[0004] Features and advantages of the embodiments are described below, become apparent from this description, or may be ascertained through the implementation of this disclosure.

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

[0006] [Figure 1] This figure shows a system for granting limited access to a user's secure information using credential authentication and user verification, according to an exemplary embodiment. [Figure 2]This is a block diagram of a computing device operably coupled to a prediction system, according to one exemplary embodiment. [Figure 3A] This figure shows a system having a secure information manager that allows limited access to secure user information, according to one exemplary embodiment. [Figure 3B] This figure shows a system having a secure information manager that allows limited access to secure user information, according to one exemplary embodiment. [Figure 4] This is a flowchart illustrating an exemplary embodiment of granting limited access to a user's secure information using credential authentication and user verification. [Figure 5] This is a flowchart illustrating an exemplary embodiment of reading scope-limited user information from a secure data store and recording access. [Modes for carrying out the invention]

[0007] Detailed explanation The embodiment uses credential authentication and user information verification to grant limited access to a user's secure information. Certain information sharing protocols may require explicit authorization to share a user's secure information with the requesting computing system and / or entity. However, in some situations, such explicit authorization may be impractical and / or impossible, such as when the user is unaware of or unqualified to provide such authorization. The Secure Information Manager embodiment may, in such situations, grant a certified entity limited access to the user's secure information, for example, if the certified entity provides an assertion that the user is unable to provide explicit authorization. For example, in an unexpected situation or any other suitable emergency situation, the Secure Information Manager may allow a certified entity to access limited user information corresponding to the certified entity's relationship to the user, its role in the workflow, or other suitable characteristics of the certified entity.

[0008] A certified entity may undergo a certification workflow that grants it specific access in such situations. For example, a certified entity could be an individual, an organization, a group of individuals, etc., and the certification workflow may include one or more of the following: identity verification, credential verification (e.g., government credentials, medical credentials, financial advisor credentials, etc.), cybersecurity verification, and any other suitable review. In some embodiments, for example, in an emergency situation where a user cannot explicitly authorize access, the computing system associated with the certified entity may send a request for the user's secure information to a secure information manager.

[0009] In some embodiments, the request includes one or more entity credentials, user identification information, and / or assertions associated with the user and / or circumstances. Entity credentials may include credentials issued to an entity (e.g., issued to one or more users and / or identities associated with the entity) after the entity has been reviewed by an authentication workflow. Exemplary entity credentials include blockchain-backed non-fungible tokens (NFTs), access tokens (e.g., SAML (Security Assertion Markup Language), OAuth (Open Authorization)), one or more cryptographic keys, or signatures. In some embodiments, a secure information manager may authenticate the entity credentials provided in the request prior to granting access to secure user information.

[0010] In some embodiments, user identification information included in a request may include one or more of the following: a user dataset that identifies the user (e.g., name, date of birth, place of origin, state, and / or zip code, physical appearance, etc.), an image of a government-issued document that identifies the user (e.g., driver's license, passport, etc.), biometric information (e.g., fingerprints, eye scan, DNA information, etc.), and other preferred identification information of the user. For example, a request may be sent from a computing system associated with an authorized entity, and user identification information may be obtained from the user's person, the user's photo ID, the user's wireless device, another individual's wireless device associated with the user, etc.

[0011] In some embodiments, biometric information can be obtained from a user's person by a scanning element of a computing system associated with a certified entity, such as scanning the user's fingerprints with a fingerprint reader or an optionally suitable scanning device, or scanning the user's retina with an eye scanner or an optionally suitable eye scanning device. In some embodiments, the scanning element of a computing system associated with a certified entity can scan other suitable identifying information of the user, such as the user's driver's license or other suitable photo ID, the user's wireless device (e.g., a user-specific portable access point for user information), or one or more visual depictions from an additional user's wireless device having a predetermined relationship with the user.

[0012] For example, a user's wireless device (e.g., a management application running on the wireless device) may display a user-specific portable access point containing a visual code such as a QR code®, an alphanumeric code, or any other preferred code. In some embodiments, the code may be embedded in the user's image. One or more scanning elements of a certified entity's computing system may scan the portable access point to obtain user identification information in response to a request.

[0013] In some embodiments, certified entities may include any suitable entities that perform 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 clinics, hospitals, emergency rooms, first responders, etc.), financial services (e.g., accounting, property management services, financial advice, etc.), and technical services (e.g., system administration services, web hosting, etc.). In this example, after the execution of the certification workflow, the relationship between the certified entities and the user is predefined in the secure information manager. Therefore, the user's secure information may be scoped so that, in response to requests, only information related to the relationship between the certified entities and the user, and relevant to the sudden situation, is provided to the certified entities.

[0014] For example, a certified entity that is a technical service provider may be scoped with respect to certain network information, cybersecurity information, cryptographic key information, etc., so that it can access the user and associated systems to perform any emergency upgrades and / or patches. In another example, a certified entity that is a hospital, an emergency room entity, and / or a first responder may be scoped with respect to certain data points in the user's electronic medical record, such as blood type, medication list, allergies, medical history, recent diagnostic test results (e.g., blood pressure, blood sugar, cholesterol, etc.), or other suitable user health information related to the sudden situation.

[0015] In some embodiments, the secure information manager may authorize limited access to a user's information for a limited period. For example, in unforeseen circumstances, it may be urgent to provide some of the user's information to an authorized entity before the user is able to explicitly authorize access. However, after a certain period, the user may be able to provide this authorization. Therefore, in embodiments, if explicit consent authorizing continued access to the user's secure information has not been received from the user, the user's access to the secure information may be revoked after a certain period.

[0016] In some embodiments, a certified entity is granted limited access to secure user information corresponding to one or more certifications, registrations, or other suitable public credentials. For example, a technical system administrator may hold certifications from one or more certification bodies, and the certified entity may be granted limited access corresponding to valid and well-established certifications. In another example, emergency room staff and / or first responders may be certified by various certification committees and / or bodies, and the certified entity may be granted limited access corresponding to valid and well-established certifications (e.g., medical record data points related to the status of an emergency room outpatient or first responder).

[0017] In some embodiments, a request from an authorized entity to access a user's secure information includes one or more assertions related to the user or situation. An exemplary assertion is that the user is ineligible, unaware, or unavailable in providing explicit access authorization. In some embodiments, the assertion provides a descriptor and / or category of the unexpected situation. In one example where the authorized entity is a system administrator, this descriptor / category may include a website downtime, a managed software application downtime, a cybersecurity breach, or other suitable descriptors or categories.

[0018] In some embodiments, one or more predetermined categories may correspond to different scopes of access to the user's secure information. For example, in a case where the certified entity includes emergency room staff and / or first responders, a category of health events may be included in the request. A predetermined category of health events may include unconsciousness without visual signs of trauma, gunshot wounds, stab wounds, vehicle accidents, unconsciousness with signs of unspecified trauma, etc. These various predetermined categories can be mapped to various data points in the user's electronic medical record. For example, a first request from a certified entity that includes an assertion that the user is unconscious can be mapped to a first scope of the user's secure information (e.g., electronic medical record). On the other hand, a second request from a certified entity that includes an assertion that the user is unconscious with signs of physical trauma can be mapped to a second scope (different from the first scope) of the user's secure information.

[0019] Furthermore, a given scope definition can also be mapped to the role of a certified entity for a user. For example, if the certified entity is a healthcare provider, the role of the certified entity may include the type of healthcare provider (e.g., emergency room, paramedic, emergency medical care, etc.), the type of medical services provided by the healthcare provider (e.g., surgery, non-surgical life support, etc.), or any other suitable role definition. For example, a first request from a certified entity that includes a first role can be mapped to a first scope of the user's secure information (e.g., electronic medical records). On the other hand, a second request from a certified entity that includes a second role (different from the first role) can be mapped to a second scope (different from the first scope) of the user's secure information. Similarly, a first request from a certified entity that includes a first role can be mapped to a first period during which the user is permitted to access their secure information. On the other hand, a second request from a certified entity that includes a second role (different from the first role) can be mapped to a second period (different from the first period) during which the user is permitted to access their secure information.

[0020] The user can define a predetermined scope and / or period mapped to a given role, and in some examples, assign the role to one or more of the authenticated entities. The user can generate / stipulate the role and the scope definition / period for each role via an information management application such as the user's wireless device (e.g., web application, native application, etc.). Once the user has stipulated a given role and the corresponding scope definition / period for that role, the user can assign a known authenticated entity to the role. For example, the known authenticated entities can include medical providers the user has visited in the past, the user's home address and / or work address, medical providers close to the user's physical location, medical providers explicitly selected by the user through input in the information management application, etc.

[0021] The user can assign a role and the corresponding scope definition / period to any known authenticated entity. According to an authenticated access request from a known authenticated entity (e.g., including credentials and an assertion that the user is unqualified), access corresponding to the scope definition stipulated for the role assigned to the known authenticated entity can be permitted to the known authenticated entity for a stipulated period. Also, the user can stipulate the role and the corresponding scope definition / period for an unknown authenticated entity, and according to an access request from the unknown authenticated entity (e.g., including credentials and an assertion that the user is unqualified), access corresponding to the scope definition stipulated for the unknown authenticated entity can be permitted to the known authenticated entity for a stipulated period.

[0022] In some embodiments, healthcare providers and / or staff of an accredited entity may follow standard procedures to access a user's secure information. In the additional techniques described in this disclosure, for example, in situations where a) there are unqualified users but these users have not been registered / entered as patients with a healthcare provider in the past, b) a healthcare provider requires an emergency access route to view a user's electronic medical record, or c) any other suitable situation, extensions, additions, and / or improvements to the standard procedures are possible.

[0023] In some embodiments, the secure information manager may record the limited-scope access permitted to an accredited entity for auditing purposes (e.g., auditing by a user, an accreditation body, and / or a committee, or any other suitable authority). For example, the scope of information accessed by the accredited entity is recorded, and the user can scrutinize the data points of the secure information requested by the accredited entity, the data points provided by the secure information manager to the accredited entity, and the time stamps of the information access. Also, in some embodiments, the accredited entity provides one or more assertions along with the presentation request, and these assertions can be recorded in association with the scope of information for which the request / access was made. For example, if a user enters the emergency room in an unqualified state, the user can audit the emergency access approved by the secure information manager for the emergency room staff after treatment, recovery, and discharge.

[0024] In some embodiments, a user can compare a presented assertion with their health status and medical condition. For example, if medical procedures clearly indicate that a user has not suffered trauma, but an emergency room information request includes an assertion that the user is "ineligible due to signs of unspecified trauma," the user can report the inconsistency or take other appropriate corrective action. The user can also determine when they regained consciousness and, consequently, when they regained the ability to give explicit authorization for access to information (e.g., when the emergency situation no longer applies). In this example, the user can compare the timestamp of the emergency request for user information with a known timeline of the user's recovery and report any inconsistencies (e.g., a request containing an assertion that the user was unconscious at the time of recovery when the user regained consciousness).

[0025] In some embodiments, a user can report such anomalies or inconsistencies to a secure information manager, which can then review the certification status of the emergency room and / or emergency room staff. In another embodiment, a user can report such anomalies to a certification body and / or committee to request a review of the certification of the emergency room and / or emergency room staff. In some embodiments, recorded requests, secure information access, and / or assertions by certified entities may be maintained by a blockchain service.

[0026] Embodiments of the present disclosure are described in detail here, examples of which are shown in the accompanying drawings. Many specific details are included in the following detailed description to enable a full understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure can be carried out without these specific details. Where else, known methods, procedures, components, and circuits are not described in detail so as not to unnecessarily obscure aspects of the embodiments. Where possible, the same reference numerals are used for the same elements.

[0027] Figure 1 shows a system for granting limited access to a user's secure information according to one exemplary embodiment. Figure 100 includes a user 102, an authorized entity 104, an authenticator and verifier 106, and a secure data store 108. In some embodiments, the authorized entity 104 can issue a request to the authenticator and verifier 106 for urgent access to the user's secure information stored in the secure data store 108. The authorized entity 104 can be any suitable person, group of people, organization, or company undergoing the authorization workflow.

[0028] In some embodiments, a certified entity 104 is associated with a computing system. For example, an application in the computing system may allow login to the application using the registered ID of the certified entity 104. In some embodiments, the certified entity 104 and one or more registered IDs of the certified entity may be registered with an authenticator and verifier 106. For example, the authenticator and verifier 106 may be part of a secure information manager that manages access to the secure data store 108.

[0029] In some embodiments, user 102 may be located (in the same physical location) alongside the computing system of the authorized entity 104. For example, the computing system may obtain user information from user 102, such as biometric information or scans of a photo ID. In this example, user 102, being unauthorized, may not be able to explicitly authorize a request to authorize the authorized entity 104 to access the user's secure information. In other examples, the computing systems of user 102 and the authorized entity 104 may be located separately from each other.

[0030] The computing system of the certified entity 104 can then issue requests to the authenticator and verifier 106 for access to the user's secure information stored in the secure data store 108. For example, the request may include credentials issued to the certified entity (e.g., NFT, access token, cryptographic signature, etc.), user 102 identification information (e.g., obtained from the user, stored in the certified entity's database, scanned from the user's photo ID, etc.), and an assertion describing the user's status (e.g., an assertion that the user is unable to provide explicit authorization for access).

[0031] The authenticator and verifier 106 can authenticate the credentials included in the request and verify the user's identification information. For example, the authenticator and verifier 106 can authenticate that the credentials in the request correspond to one or more credentials issued to the authorized entity 104. The authenticator and verifier 106 can also verify that the user's identification information corresponds to a registered person who has secure information stored in the secure data store 108. For example, when user 102 registers with a managed secure information service, user 102's secure information may be stored in the secure data store 108. Based on the registration, verification information about user 102 may be stored by the authenticator and verifier 106, such as name, date of birth, social security number, home address and / or postal code, medical information (e.g., primary care physician), biometric information (e.g., fingerprints, eye scan, etc.), vehicle manufacturer, vehicle type and / or license plate, display of government-issued identification (e.g., photo on driver's license), and an image of the user's face.

[0032] In some embodiments, the secure data store 108 can store secure information for many registered individuals (e.g., hundreds, thousands, hundreds of thousands, millions, etc.), and the authenticator and verifier 106 can store verification information for these registered individuals. The authenticator and verifier 106 can compare the user identification information included in a request with the verification information for these registered individuals to find a match.

[0033] If the user identification information provided in the request matches the verification information of a managed person, the authenticator and verifier 106 can verify that the request corresponds to an identified person whose secure information is stored in the secure data store 108. In some embodiments, the authenticator and verifier 106 can generate a confidence score for this match. For example, a request may include the user's name, date of birth, and geographical location from which the request originates. In this example, the authenticator and verifier 106 may be able to match the user's name and date of birth with the registered person, but the postal code from which the request originates may not match the postal code of the registered person. Such a match may generate a confidence score that does not meet the verification criteria.

[0034] In some embodiments, the confidence score of a match may be based on both the quantity and quality of the information originating from the request that matches the verification information of the managed person. For example, even if the postal code does not match, if the name, date of birth, and additional information (e.g., biometric information, photo ID, etc.) match, a confidence score that satisfies the verification criteria may be generated, and limited access to the registered person's secure information may be permitted.

[0035] In some embodiments, the certified entity 104 may include a hospital, emergency room, first responder group, emergency medical facility, or any other suitable medical service entity that provides emergency medical care. In this example, user 102 may be unconscious, and the request to access secure information may relate to the provision of emergency medical care to user 102. Since the secure information of user 102 requested by the certified entity 104 is important to user 102's health, embodiments of the authenticator and verifier 106 are configured to provide a rapid and reliable match between the user information in the request and a dataset of verification information stored for the registered person.

[0036] In some embodiments, the authenticator and verifier 106 can define the dataset of verification information stored for a registered person by using a portion of the incoming request when searching for a match. For example, the dataset of verification information can be defined initially using location parameters of the request (e.g., a group of zip codes, cities, etc., of the same location), and then matches for other parameters (e.g., name and date of birth) can be searched for within the defined dataset. In this example, the registered person can provide location parameters (e.g., within 50 miles of a zip code) that can define the dataset of verification information. In some embodiments, the location from which the request originates may include the location from which the request originates, the location of user 102 (e.g., the address and / or zip code as stated on the user's driver's license), or any other preferred location. The initial definition of the dataset of verification information stored for a registered person can also be done by using any other preferred parameters corresponding to the request.

[0037] In some embodiments, multiple potential matches may be found based on the user identification information provided in the request. For example, the request may include a postal code, the user's name, and one or more facial images of the user. Multiple registered individuals may match the user's name and postal code in this request. In such a situation, the use of the user's facial images in the request allows for selection from multiple registered individuals.

[0038] For example, a user's face image may be compared against a potential matching face image (the face image is part of a dataset of registered person verification information). This comparison may be performed by a computer vision model, such as a convolutional neural network, configured and trained to compare face images and output a confidence score for the match. If a matching face image is found and meets the confidence score criteria, the authenticator and verifier 106 can verify that the user's identification information matches this registered person verification information.

[0039] In some embodiments, the authenticator and verifier 106 may include a master patient index that aggregates data from multiple sources (e.g., electronic medical records, hospital systems, clinics, etc.). For example, the dataset of verification information for registered individuals may include data aggregated using one or more master patient indexes. In some embodiments, each registered individual may grant the authenticator and verifier 106 permission to aggregate user information from these sources. Data for the verification information dataset may also be aggregated from any other suitable sources (e.g., state motor services, other government agencies, public records, etc.).

[0040] In some embodiments, the authenticator and verifier 106 authenticate the request credentials and, once they have verified that the user's identification information matches the verification information of the managed person, may grant the authorized entity 104 limited-scope and time-limited access to the user's secure information stored in the secure data store 108. For example, the scope of the user's secure information may be limited to the relationship between the authorized entity 104 and the user 102 or other preferred characteristics of the authorized entity 104. In another example, access may be limited to a certain period (e.g., 12 hours, 24 hours, etc.). Thereafter, the authenticator and verifier 106 will not grant access to the authorized entity 104 unless another request for authentication and verification is issued.

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

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

[0043] The processor 222 may include one or more general-purpose or dedicated processors that perform the arithmetic and control functions of the system 210. The processor 222 may comprise a single integrated circuit, such as a microprocessing device, or it may comprise multiple integrated circuit devices and / or circuit boards that cooperate to perform the functions of the processor 222. Furthermore, the processor 222 may execute computer programs such as an operating system 215, a motion prediction component 216, and other applications 218 stored in memory 214.

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

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

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

[0047] In some embodiments, system 210 can be part of a larger system. Therefore, system 210 may include additional functionality by comprising one or more additional functional modules 218. Other application modules 218 may include, for example, modules of Oracle® Data Integrator, Oracle® Cloud Infrastructure, Oracle® Autonomous Database, Oracle® Cerner®, Oracle® Cerner® Millennium, Oracle® Cerner® HealtheIntent, Oracle® Cerner® Seamless Exchange, Oracle® Cerner® HealtheCare, and various modules of representative products across the entire Oracle® Health & Artificial Intelligence platform. A database 217 is coupled to bus 212, providing centralized storage for modules 216 and 218, and storing, for example, registered person verification information, certified entity information, authentication and verification-related information, etc. The database 217 can store data as an integrated collection of logically related records or files. Database 217 may be an operational database, an analytical database, a data warehouse, a distributed database, an end-user database, an external database, a navigational database, an in-memory database, a document-oriented database, a real-time database, a relational database, an object-oriented database, a Hadoop distributed file system ("HFDS"), or any other database known in the art.

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

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

[0050] Figures 3A and 3B illustrate a system having a secure information manager that allows limited access to secure user information, according to an exemplary embodiment. Figure 300A includes a source 302, a request system 304, a secure 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. Embodiments of the request system 304 may include a system of certified entities, such as entities that have performed an authentication workflow by the secure information manager 306. The source 302 may include user sources 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 other suitable sources of user information.

[0051] The request system 304 can obtain user information from the information source 302. For example, the scanning module 310 or the request system 304 can scan biometric information such as fingerprints or eyeballs from the user's body. In another example, the scanning module 310 can scan user identification documents such as the user's driver's license or passport.

[0052] In some embodiments, the scanning module 310 can scan the display of the user's wireless device, such as a visual code display, via an application running on the user's wireless device. In some embodiments, the visual code can be a portable access point to the user's secure information. For example, the user's wireless device (e.g., an application running on the wireless device) can display a user-specific portable access point that includes a visual code such as a QR code, an alphanumeric code, or any other preferred code. In some embodiments, the code can be embedded in the user's image. The scanning module 310 can be a dedicated device configured to scan a portable access point and obtain user identification information in response to a request, such as a wireless device that includes an image capture component (e.g., a camera) and runs an application capable of deciphering the portable access point. In some embodiments, the visual portable access point can be displayed by the user's wireless device as a display on the lock screen (e.g., prior to password entry), as an image stored in the wireless device's photo library as the background of the wireless device, or via any other preferred display means.

[0053] In some embodiments, a user's wireless device may grant limited access to a secondary individual (e.g., a person whose access to the user's wireless device is restricted) in emergency situations such as the use of facial recognition, biometric data, and / or login / passwords corresponding to limited access rights. Limited access may allow the secondary individual to access a user interface that displays the user's visual portable access point, or an application that allows the sharing of user identification information over wireless communication.

[0054] In some embodiments, the scanning module 310 can receive user identification information via an application running on the user's wireless device, which transmits such information by 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 name, date of birth, user image, portable access point image and / or information, user identifiers from one or more electronic medical records (e.g., a master patient index identifier, an identifier usable across multiple electronic medical record systems, etc.).

[0055] The user's wireless device can provide user identification information (e.g., by displaying a visual code, transmitting identification information wirelessly) while offline, such as when it loses connectivity to the Internet, a cellular network, and / or a wireless local area network, or any other suitable network connection. In this example, components of a management application running locally on the wireless device can provide user identification information. For example, once the scanning module 310 receives / acquires user identification information from the user's wireless device, the requesting system 304 can communicate with the secure information manager 306 using the network connection.

[0056] In some embodiments, the information source 302 may include a wireless device of a person having a predetermined relationship with the user. For example, the user could be a registered person whose secure user information 308 is managed by the secure information manager 306. The user may also register predetermined relationships with the secure information manager 306, such as personal relationships (e.g., parents, spouse, children, friends, etc.), work relationships (e.g., co-administrator of a corporate application, etc.), or other suitable relationships.

[0057] In some embodiments, a person having a predetermined relationship with the user may possess a wireless device capable of providing the user's identification information to the request system 304. For example, any suitable user identification information provided by the user's wireless device may be transmitted to the scanning module 310 via the wireless device of the person having a predetermined relationship with the user. In some embodiments, this related person's wireless device is registered with the secure information manager 306 and includes an application that provides user identification information.

[0058] Requester 312 can send a request to secure information manager 306 to access secure user information 308. Diagram 300B and request 330 further describe the request that requester 312 sends to secure information manager 306. For example, the request to send may include one or more credentials issued to an authorized entity associated with requesting system 304, user identification information (e.g., obtained via source 302 and scanning module 310), and one or more assertions related to the user.

[0059] In some embodiments, the secure information manager 306 can verify the credentials included in the request, as well as the user identification information included in the request. For example, the authenticator 314 can authenticate the provided credentials against an authorized entity and credentials issued to an authorized entity. The verifier 316 can verify that the user identification information provided in the request corresponds to secure user information 308 (for example, a person registered with the secure information manager 306 such that the secure information is part of the secure user information 308).

[0060] The blockchain manager 318 can manage one or more blockchains for the secure information manager 306. For example, credentials issued to an authorized entity may include non-fungible tokens or other suitable credentials managed by the blockchain manager 318. In another example, one or more blockchains managed by the blockchain manager 318 may store information accessed by the secure user information 308 and related record data, such as for auditing functionality.

[0061] A blockchain is a list of records, each called a block, that can be linked together by encryption. In some embodiments of blockchain, each block contains a timestamp, a hash of the preceding block, and transaction data. The timestamp proves that transaction data was included when the block was added, in order to obtain its hash. Since each block identifies its preceding block, a set of blocks forms a chain, and each new block reinforces the set of preceding blocks in the chain. Therefore, modifying a blockchain is difficult because data added to the blockchain cannot be changed unless subsequent blocks are modified.

[0062] Non-fungible tokens (NFTs) are blockchain-backed identifiers that designate a unique item. A distributed ledger (e.g., a blockchain) can track and verify the allocation or ownership of these tokens. Such tokens may contain an identifier for a unique item and / or a link to a display of that unique item (e.g., via a traditional URL or a distributed file system such as IPFS).

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

[0064] Figure 300B includes a request system 304, a secure information manager 306, secure user information 308, a request 330, identification information 332, credentials 334, assertion 336, data query 338, user information 340, scope-limited user information 342, and limited user information 344. Similar to Figure 300A, an embodiment of the request system 304 can be a system of certified entities, such as entities that have executed a certification workflow by the secure information manager 306.

[0065] In some embodiments, the request system 304 can generate a request 330 through interaction with the user, such as scanning a part of the user's body, scanning the user's identification document, or communicating with the user's wireless device. The request 330 issued to the secure information manager 306 may include user identification information 332, credentials 334, and assertions 336.

[0066] User identification information may include name, date of birth, social security number, home address and / or postal code, medical information (e.g., primary care physician), biometric information (e.g., fingerprints, eye scans, etc.), vehicle manufacturer, vehicle type and / or license plate number, display of government-issued identification (e.g., driver's license photo), and an image of the user's face. Credential 334 may include blockchain-backed non-fungible tokens (NFTs), access tokens (e.g., SAML (Security Assertion Markup Language), OAuth (Open Authorization), etc.), one or more cryptographic keys, or signatures.

[0067] Assertion 336 can be a statement asserted by an authorized entity, which relates to a user and / or situation. An exemplary assertion is that a user is unqualified, unaware, or unavailable regarding the provision of explicit authorization for access to secure information. In some embodiments, the assertion provides a descriptor and / or category of the situation.

[0068] In some embodiments, one or more predetermined categories may correspond to different scopes of access to the user's secure information. For example, in a case where the certified entity includes emergency room staff and / or first responders, a category of health events may be included in the request. A predetermined category of health events may include unconsciousness without visual signs of trauma, gunshot wounds, stab wounds, vehicle accidents, unconsciousness with signs of unspecified trauma, etc. These various predetermined categories can be mapped to various data points in the user's electronic medical record. For example, a first request from a certified entity that includes an assertion that the user is unconscious can be mapped to a first scope of the user's secure information (e.g., electronic medical record). On the other hand, a second request from a certified entity that includes an assertion that the user is unconscious with signs of physical trauma can be mapped to a second scope (different from the first scope) of the user's secure information.

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

[0070] In some embodiments, secure user information 308 may include secure information for many registered individuals. User information 340 may represent secure information stored for a user verified against identification information 332. In some embodiments, user information 340 may include a set of user data points, and scope-limited user information 342 may include a subset of data points. In one example where secure user information 308 includes electronic medical records and user health data, the set of data points in user information 340 may include a set of user electronic medical record data, and the subset of data points in scope-limited user information 342 may include metadata and / or summary data encompassing the components of the aggregated electronic medical record data.

[0071] For example, scope-limited user information 342 could be a predetermined health data point designated by the user as accessible in an emergency situation, or a predetermined health data point designated by an optional preferred authorized entity with authentication credentials. In another example, scope-limited user information 342 could include health data points based on a predetermined template, such as data points tailored for emergency room staff and / or first responders. Exemplary scope-limited user information 342 could include the user's blood type, medical history, past surgeries, allergies, current medications, or other optional preferred user health data. In some embodiments, user information 340 could be a segmented medical record, and the data points included in scope-limited user information 342 could be any preferred segment of the segmented medical record.

[0072] In some embodiments, user information 340 can be electronic health data segmented based on parameters. For example, parameters may include the originating or issuing physician and / or healthcare institution (e.g., entity name or identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's notes, vaccine information, allergies, etc.), relevant health practices (e.g., cardiology, primary care, neurology, oncology, etc.), information origination date, electronic medical record format, other HL7 (Health Level Seven), FHIR (Fast Healthcare Interoperability Resource), and / or FHIR-related SMART (Substitute Medial Applications and Reusable Technologies) 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 predetermined portions of user information 340 (e.g., customized templates), configured to provide sufficient health data for emergency situations.

[0073] In some embodiments, in response to the authentication and verification of a request, the secure information manager 306 may issue a data query 338 for secure user information 308. In response, the secure information manager 306 may receive limited user information 344, which may be limited in scope based on the authorized entity, the relationship between the authorized entity and the user, the assertion included in the request, or any other preferred parameter. The secure user information 344 may then be provided to the requesting system 304.

[0074] In some embodiments, a certified entity may include one or more registration IDs. For example, a certified entity may be an organization, and a registration ID may be a person who is part of the organization. In some embodiments, a certified entity may be a hospital, an emergency room organization, or an organization of first responders, and a registration ID may be an emergency room staff member and / or paramedic.

[0075] In some embodiments, request 330 may be issued by the registration ID of the certified entity. For example, request 330 may include indicators of the certified entity and registration ID, such as credentials 334 which, once authenticated, identify the registration ID and the certified entity. Request 330 may also include any other preferred indicators.

[0076] The limited user information 344 may be limited to the registration ID associated with the certified entity that issued the request, and / or the credentials 334 of the certified entity or registration ID. For example, a paramedic's registration ID cannot perform a certain surgery that emergency room staff can perform. Therefore, a request from a paramedic's registration ID may correspond to the first version of the limited user information 342. On the other hand, a request from emergency room staff may correspond to the second version of the limited user information 342, the first version being different from the second version. For example, for a certain surgery not included in the first version, the second version may include data points related to that surgery.

[0077] In some embodiments, the Secure Information Manager 306 may have access to the schedule of the registered ID of a certified entity, and scoped access to the user's information may be further limited to certain times in the registered ID's schedule. The schedule may be a "task-based" schedule that defines when the registered ID becomes active in a particular role, such as when it becomes active in a role corresponding to a certified entity. For example, the certified entity could be a hospital, and the registered ID could be an emergency responder who is part of the hospital's emergency response service. The schedule that the Secure Information Manager 306 can access may include the time when the registered ID is actively working as an emergency responder.

[0078] In some embodiments, the secure information manager 306 can determine whether the registration ID of an authorized entity is "logged in" and "valid" to the request system 304 by establishing a communication link to the request system 304. For example, an emergency responder may log in to the emergency service provider's computing system (e.g., the request system 304) at the start of a work shift, for example, by entering a username and password into an application running on a mobile device or other computing device, scanning a badge on a scanning device connected to the emergency service provider's system, scanning a token or device (e.g., a radio frequency ID token, a radio device scanned via near-field communication, etc.) on a scanning device connected to the emergency service provider's system, or any combination thereof. In this example, the secure information manager 306 may, in response to a request from the registered entity, grant limited access to the user's secure information if the registration ID associated with the authorized entity is "valid" and / or "logged in" to the request system 304.

[0079] In some embodiments, an authorized entity may authorize access to an unauthorized user's secure information through a designated secondary contact (e.g., an emergency contact). For example, a user may pre-designate a person as an emergency contact (e.g., pre-designate a relationship with a person to authorize access to the user's secure information in an emergency situation) through an administrative application that manages the user's secure information. These designated relationships may include the user's name, contact information (e.g., phone number, email address, etc.), and a relationship definition to the user (e.g., spouse, friend, sibling, parent, child, etc.).

[0080] After the designation, the emergency contact may receive an indication that they have been identified as an emergency contact by the user, for example, through a message to their phone number (e.g., text message, push message, etc.) or email. In some embodiments, the emergency contact may be prompted to complete a workflow to complete the user's registration as an emergency contact. For example, the emergency contact may be sent (e.g., to their phone number or email address) a link that they can use to sign up for a secure information manager via a website, local application, web application, etc. Once the emergency contact completes the workflow, they may be granted the authority to authorize limited access to the user's secure information in emergency situations.

[0081] In some embodiments, a user can specify portions of their secure information that correspond to each emergency contact. These specified portions may include parts of the user's secure information that can only be accessed if the specific emergency contact authorizes access. For example, a spouse or family member may be granted access to most or all of the user's secure information, while a friend or colleague may be granted access to a limited portion of it.

[0082] In response to an authorized entity receiving a request from an authorized entity to access a user's secure information in an emergency situation (for example, while the user is unauthorized), an embodiment of the secure information manager may contact the user's registered emergency contact to obtain authorization. For example, such communication may include a message to the emergency contact's registered phone number or email address, a message via an application loaded on the registered smartphone (e.g., a message that overrides the smartphone display and includes a button that can be used to authorize access), a phone call, or any other preferred method of communication. If a specific emergency contact authorizes access, the authorized entity may be granted access to the portion of the user's secure information corresponding to that specific emergency contact (e.g., the portion of the user's secure information specified in relation to authorization from that specific emergency contact).

[0083] One or more workflows for obtaining access authorization through the user's emergency contact may be performed in combination with the functionality shown in Figures 3A and 3B. For example, an authorized entity may be granted initial emergency access to the user's secure information, but access can be confirmed, restricted, and / or revoked based on approval or denial from the user's emergency contact. In some situations, an authorized entity may not be granted access to the user's secure information until approval is obtained from the emergency contact.

[0084] In some embodiments, the user identification information received by the Secure Information Manager and / or the user profile of the user stored in the Secure Information Manager may include identifiers in the master patient index, and / or cross-platform identifiers that link electronic medical records between different record types, platforms, and / or electronic medical record service providers. For example, the cross-platform identifier can be linked to the user's electronic medical record implemented by a third-party platform or to the user's electronic medical record outside the Secure Information Manager. The Secure Information Manager can selectively grant access to authorized entities by retrieving the user's secure information using the cross-platform identifier. In some embodiments, the cross-platform identifier can be a part of the user identifier stored in the Secure Information Manager for the user (e.g., prefix, suffix, etc.). Thus, the cross-platform identifier may be derived from an existing user identifier.

[0085] In one embodiment, a user's portable access point is displayed, from which a certified entity can obtain user identification information by scanning. The portable access point may include an image, such as a user's facial image, and encoded information. The encoded information may include a unique QR code or other preferred visual or symbolic code (e.g., alphanumeric) embedded in the image. In some embodiments, the QR code and / or symbolic code may be one or more of the following: a holographic image, a stereoscopic holographic image, a pixelated code, a stereoscopic textured code, etc. For example, the encoded information may be displayed on the image as an embossed QR code having, for example, a unique encrypted long string identifier, generated using an algorithm.

[0086] In some embodiments, the encoded information may include a unique encrypted long string identifier generated by an encrypted long string identifier algorithm. Since the encrypted long string identifier is generated by at least an encrypted long string identifier algorithm, it can be unique. For example, even if a rogue version of a portable access point attempts to replicate a unique encrypted long string identifier, the scan of images and encoded information will not result in a match because a unique algorithm is used.

[0087] The unique encrypted long string identifier generated by the encrypted long string identifier algorithm can be dynamic, generating a new identifier for each version of the portable access point, at predetermined intervals (e.g., every 2 hours, 4 hours, 6 hours, 12 hours, daily, etc.), or at any other convenient time. In this example, a secure information manager managing a user's secure information can receive the dynamically generated identifier for that version of the portable access point. For example, the identifier may be dynamically generated via an information management application loaded on the user's wireless device that manages the user's portable access point. This application can then send the dynamically generated identifier to the secure information manager. In another example, the identifier may be dynamically generated via a cloud service. This cloud service can then send the dynamically generated identifier to both the application managing the user's portable access point and the secure information manager.

[0088] To mitigate malicious attempts to access a user's secure information through an older version of the user's portable access point, the Secure Information Manager can record one or more valid long string identifiers for a given user. Access requests containing invalid identifiers are rejected upon receipt by the Secure Information Manager, and such malicious attempts may be reported to support enhanced security measures.

[0089] The certified entity system can be configured to scan a user's portable access point, such as the scanning module 310 and request system 304 shown in Figure 3A. Once the scanning module 310 has scanned the portable access point, the request system 304 (e.g., an application configured to decode the portable access point) can decode the encoded information and / or image of the portable access point. For example, the application in the request system 304 can decode a unique long string of digits (e.g., generated by a unique algorithm), user identification information, and other suitable data to decode, and include the decoded information in an access request sent to the secure information manager 306. In some embodiments, the user identifier obtained from the portable access point by scanning may correspond to a user registered in the secure information manager 306. This identifier can then be used to retrieve user identification information stored in the secure information manager for the registered user. In some embodiments, the user identification information itself may be obtained from the portable access point by scanning, and the request system 304 can provide the obtained user identification information to the secure information manager 306 in an access request. Examples of user identification information encoded by a portable access point include one or more of the following: name, date of birth, social security number, home address and / or postal code, medical information (e.g., primary care physician), biometric information (e.g., fingerprints, eye scans, etc.), vehicle manufacturer, vehicle type and / or license plate number, display of government-issued identification (e.g., driver's license photo), and display of an image of the user's face.

[0090] Figure 4 is a flowchart illustrating an exemplary embodiment of granting limited access to a user's secure information using credential authentication and user verification. In one embodiment, the functions in Figure 4 (and Figure 5 below) are implemented by software stored in memory or other computer-readable or tangible media and executed by a processor. In other embodiments, each function may be performed by hardware (e.g., the use of application-specific integrated circuits ("ASICs"), programmable gate arrays ("PGAs"), field-programmable gate arrays ("FPGAs"), etc.) or any combination of hardware and software.

[0091] In block 402, process 400 can receive requests to access a user's secure information. For example, a request may be received by the secure information manager from the computing system of an authorized entity, and this request may include the user's identification information and one or more credentials issued to the authorized entity. In some embodiments, the request may also include assertions from the authorized entity, such as assertions related to the user, a situation (e.g., an unexpected situation associated with the user), etc.

[0092] In block 404, process 400 can verify the user's identity. For example, one or more individuals may pre-register their secure information and have it managed in the secure data store. Verification may include the secure information manager matching the user's identity originating from the request with that of the pre-registered individuals.

[0093] In some embodiments, user identification information may be compared with registered person verification information to determine a match. Exemplary user identification information originating from a request includes user information obtained by scanning the user's individual portable access point, biometric information detected from the user (e.g., fingerprints, eye scans, etc.), a display of an identification document containing an image of the user (e.g., a driver's license photo), an image of the user's face or eyes, or any combination thereof.

[0094] In block 406, process 400 can authenticate the credentials included in the request. For example, one or more credentials may include tokens issued to the authenticated entity after the execution of the authentication workflow. Authentication can verify that the request originates from the entity that underwent the authentication workflow. Tokens may include non-fungible tokens, access tokens, digital signatures generated using cryptographic keys issued to the authenticated entity, or any combination thereof. In some embodiments, the credentials may be managed by a blockchain service capable of authenticating those credentials. In some embodiments, one or more authenticated credentials grant the authenticated entity limited access to the user's secure information for a limited period of time.

[0095] In block 408, process 400 may send supplemental access permission requests to additional users who have a predetermined relationship with the user. For example, a request from an authorized entity may include one or more assertions that the user is unable to provide explicit authorization to access the user's secure information. As an additional safeguard for the user's secure information, information guardian relationships with one or more additional users may be pre-defined. As information guardians, protection against inappropriate access to the user's secure information is possible by sending supplemental access permission requests to the additional users' wireless devices.

[0096] In some embodiments, a supplemental access permission request is sent to one or more wireless devices of an additional user, and an explicit acceptance of the supplemental access permission request is received from one or more wireless devices. In some embodiments, the supplemental access request is displayed to at least one of the additional users via the wireless devices as a priority notification that overrides the display of at least one of the wireless devices. For example, if an application with override permission is loaded on an additional user's wireless device, and in response to receiving a supplemental access permission request, the application can override the display of the wireless device with the supplemental access request. In some embodiments, the display override may be maintained until an input (from the additional user) is received to accept or reject the request.

[0097] In some embodiments, 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 at least one of the wireless devices is configured to send an explicit acknowledgment of the supplemental access permission request in response to input prior to the expiration of the expiration timer. For example, a supplemental access request can be an overlay, panel, or other preferred display message that describes the purpose of the supplemental access request (e.g., granting or denying access to the user's secure information) and includes one or more buttons for explicitly approving or denying the request. In some embodiments, the request may display a statement describing the relationship between the user and the additional user, such as "You are designated as the guardian of [[Name]]'s secure information."

[0098] In block 410, process 400 may, in response to verification and authentication, grant a computing system associated with the authorized entity limited access to the user's secure information for a limited period of time. For example, the user's limited secure information may be provided to the computing system of the authorized entity that issued the request. In some embodiments, the computing system of the authorized entity is granted access for a limited period of time (e.g., one hour, several hours, one day, two days, one week, etc.), after which the access expires. For example, in response to an additional request, separate access may be granted (after authentication and verification of the additional request).

[0099] In some embodiments, a computing system associated with an authorized entity may be granted limited access to a user's secure information for a limited period in response to one or more responses to verification, authentication, and supplemental access permission requests. For example, access may be granted based on at least one response to a supplemental access permission request. In some embodiments, access may be granted if no response is received to a supplemental access permission request. In some embodiments, access may be denied if at least one response to a supplemental access permission request denies access.

[0100] In some embodiments, an access request includes an assertion from a certified entity that the user is not authorized or capable of explicitly granting access to the user's secure information, and limited access to the user's secure information is granted in response to the assertion. In some embodiments, limited access to the user's secure information includes access to a limited data point of the user's secure information, the limited data point includes a predetermined correspondence to the assertion from the certified entity. In some embodiments, the certified entity includes a predetermined role for the user, and limited access to the user's secure information includes access to a limited data point of the user's secure information corresponding to the predetermined role.

[0101] In block 412, process 400 may terminate limited access after the expiration criteria are met. In some embodiments, the computing system of the certified entity is granted access for a limited period, after which the access terminates. In some embodiments, access to the user's secure information may be controlled by the user's circumstances and unforeseen events. For example, if the certified entity is a hospital and the user is not qualified in the emergency room, the certified entity's access to the user's secure information may be controlled by the user's status as a patient in the emergency room.

[0102] In some embodiments, when a user is discharged from a hospital, the user's status in the authorized entity's computing system may be updated (for example, HL7 (Health Level 7), FHIR (Fast Healthcare Interoperability Resource), and / or FHIR-related SMART (Substitute Medial Applications and Reusable Technologies) codes / statuses indicating discharge status may be updated). In some embodiments, such an update of the user's status may trigger the termination of the authorized entity's computing system's access to the user's secure information upon request. In this situation, the authorized entity can then request access to the user's secure information through other channels, such as explicit access authorization from the user, since the user is no longer ineligible. In some embodiments, the authorized entity's access to the user's secure information upon request may be maintained until the user's status indicates the user's discharge. For example, a status update (e.g., HL7, FHIR, and / or FHIR-related SMART status) may indicate a user's transfer to another department and / or healthcare facility within the hospital, and authorized entities may retain access to the user's secure information if the user's status is transfer rather than discharge.

[0103] In some embodiments, a wireless device associated with a user is issued an access request that explicitly authorizes an authorized entity to access the user's secure information. However, the user may be unable to respond to the request due to being unqualified or unavailable. An assertion by the authorized entity may be relied upon to authorize the authorized entity's access to the user's secure information without explicit authorization from the user. In some embodiments, the user's wireless device may receive a response to the access request indicating denial of access and / or that the user is not in an emergency situation. This can occur due to a misidentification of the user by the authorized entity's computing system and / or a misvalidation of the user by the secure information manager. In this example, access to the user's secure information may be denied, and the authorized entity's computing system may warn that the user identified by the user identification information included in the request is not in an emergency situation. Such indicators can help correctly identify users in emergency situations.

[0104] In some embodiments, in response to verification and authentication, process 400 may grant (as described above with reference to block 410) limited-scope access to the user's secure information for a limited period of time to a computing system associated with an authorized entity, prior to receiving a response to a supplemental access permission request sent to an additional user having a predetermined relationship with the user (as described above with reference to block 408). In this example, limited access may be granted while waiting for a response to a supplemental access permission request, given that the user's health may be at risk.

[0105] A user can disable an authorized entity's access to their secure user information by responding to an access request issued to them (e.g., their mobile device) and / or an additional user, or by responding to a supplementary access request issued to an additional user (e.g., the additional user's mobile device). For example, a user and / or an additional user can respond to an access request or supplementary access request with a "deny" response that terminates the authorized entity's access to the user's secure user information. In this example, the Secure Information Manager can initiate reporting to authorities regarding the authorized entity's access requests and assertions. For example, disabled access may indicate that the authorized entity has gained unauthorized access to the user's secure user information. The Secure Information Manager can initiate reporting to law enforcement and / or federal regulatory authorities, including the authorized entity's identification information (e.g., name, business address, etc.) and the affected user's identification information (e.g., name, etc.).

[0106] Figure 5 is a flowchart illustrating an exemplary embodiment for reading scope-limited user information from a secure data store and recording access. In some embodiments, process 500 may be executed by a secure information manager authorized to access a user's secure information by an authorized entity, for example, in response to a request from the authorized entity's computing system. In another example, process 500 may be executed by one or more components of the secure data store.

[0107] In block 502, process 500 can query the secure data store for the user's secure information. For example, an authorized entity may request a set of data points relating to the user's secure information. A data store query (e.g., SQL, or any other suitable database query) may then be generated to query all or some of the data points requested by the authorized entity regarding the user's secure information.

[0108] In block 504, process 500 can receive scope-limited user information from the secure data store. For example, scope-limited user information may be limited by the created data store query or the data store itself. In some embodiments, the generated query is restricted to request a scope of secure information for users who are allowed access by the authorized entity. In some embodiments, the data store returns scope-limited data points of secure information for users limited to data points that are allowed access by the authorized entity.

[0109] In block 506, process 500 can provide scope-limited user information to the request system of the authorized entity. For example, scope-limited data points returned from the user's secure information may be sent to the computing system of the authorized entity that issued the request.

[0110] In block 508, process 500 may record the request, the scope-limited information accessed by the request, a timestamp, and other suitable data associated with the received request and scope-limited data. For example, a user's access to secure information may be recorded in an optional data structure. In some embodiments, the storage structure includes a blockchain, and each request and / or instance relating to a user's access permission to secure information is recorded as a block on the blockchain.

[0111] In block 510, process 500 may provide recorded data in response to an audit request. In an embodiment, a user (or any other suitable entity or person) may be permitted to audit access to secure information. Recorded information, including the request, the scope information accessed by the request, a timestamp, and other suitable data associated with the received request and scope data, may be provided to the user or other suitable audit entity.

[0112] The embodiment uses credential authentication and user information verification to grant limited access to a user's secure information. Certain information sharing protocols may require explicit authorization to share a user's secure information with the requesting computing system and / or entity. However, in some situations, such explicit authorization may be impractical and / or impossible, such as when the user is unaware of or unqualified to provide such authorization. In such situations, an embodiment of the Secure Information Manager may grant the authorized entity limited access to the user's secure information, for example, if the authorized entity provides an assertion that the user is unable to provide explicit authorization. For example, in an unexpected situation or any other suitable emergency situation, the Secure Information Manager may allow the authorized entity to access limited user information corresponding to the authorized entity's relationship to the user, its role in the workflow, or other suitable characteristics of the authorized entity.

[0113] The features, structures, or characteristics described throughout this Specification may be optionally combined in one or more embodiments. For example, the use of “one embodiment,” “some embodiments,” “certain embodiment,” “certain embodiments,” or other similar expressions throughout this Specification indicates that certain features, structures, or characteristics described in relation to embodiments may be included in at least one embodiment of this Disclosure. Therefore, throughout this Specification, the appearance of the expressions “one embodiment,” “some embodiments,” “certain embodiment,” “certain embodiments,” or other similar expressions does not necessarily mean that all of them represent the same group of embodiments, and the described features, structures, or characteristics may be optionally combined in one or more embodiments.

[0114] Those skilled in the art will readily understand that the embodiments described above may be implemented in a different order of steps and / or with different configurations than those disclosed. Therefore, although embodiments are discussed conceptually in this disclosure, as will be obvious to those skilled in the art, some improvements, modifications, and alternative configurations will become apparent without departing from the spirit and scope of this disclosure. Accordingly, the appended claims shall be used to determine the scope and bounds of this disclosure.

Claims

1. A method for granting limited access to a user's secure information, This includes receiving requests from the computing systems of certified entities in the Secure Information Manager to access the user's secure information, The request includes the user's identification information and one or more credentials issued to the authorized entity, The aforementioned method, The process further includes verifying that the user's identification information matches a person pre-registered in the secure information manager. The user's identification information includes user information obtained by scanning the user's individual portable access point, biometric information detected from the user's person, a display of an identification document including the user's image, an image of the user's face or eyes, or any combination thereof, one or more of these. The aforementioned method, Further includes authenticating one or more of the aforementioned credentials and the aforementioned authorized entities, The one or more authenticated credentials grant the authorized entity limited access to the user's secure information for a limited period of time. The aforementioned method, A method further comprising, in response to the verification and authentication, granting the computing system associated with the authorized entity the limited-scope access to the user's secure information for the limited period of time.

2. The method according to claim 1, wherein the one or more credentials include a token issued to the certified entity after the execution of the certification workflow.

3. The method according to claim 2, wherein the token includes one or more of the following: a blockchain-managed nonfungible token, an access token, a digital signature generated using a cryptographic key issued to the accredited entity, or any combination thereof.

4. The method according to claim 2, wherein the access request includes an assertion from the authorized entity that the user is not authorized or capable of explicitly granting access to the user's secure information, and the limited access to the user's secure information is granted in response to the assertion.

5. The method according to claim 4, wherein the limited access to the user's secure information includes access to a limited data point of the user's secure information, the limited data point includes a predetermined correspondence to the assertion from the certified entity.

6. The method according to claim 1, wherein the certified entity includes a predetermined role for the user, and the limited access to the user's secure information includes access to a limited data point of the user's secure information corresponding to the predetermined role.

7. The method according to claim 1, further comprising sending a request for access to the secure information of the user to one or more additional users having a predetermined relationship with the user, wherein the limited access is granted in response to an explicit acceptance of the request for access to the secure information of the user, the method according to claim 1.

8. The method according to claim 7, wherein the predetermined relationship designates the additional user as the guardian of the user's secure information.

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

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

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

12. The further includes storing one or more logs of the scope-limited access to the user's secure information, The method according to claim 1, wherein the log includes one or more of the following: the certified entity, a portion of the request, the secure information of the user accessed by the computing system of the certified entity, a timestamp of access to the secure information of the user being accessed, or any combination thereof.

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

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

15. The method according to claim 1, further comprising sending an access permission request to the user in response to the request to access the user's secure information, and sending one or more supplemental access permission requests to one or more additional users having a predetermined relationship with the user.

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

17. The limited access to the user's secure information is granted prior to receiving the response to the access permission request or the supplemental access permission request. One or more responses are received to the access permission request or supplemental access permission request that prohibit the scope-limited access to the user's secure information. The method according to claim 16, wherein the limited access to the user's secure information is terminated based on one or more responses.

18. A non-temporary computer-readable medium that, when executed by a processor, stores instructions that grant the processor limited access to the user's secure information, When executed, the instruction is: The processor is instructed to receive a request from the computing system of an authorized entity to access the user's secure information in the secure information manager. The request includes the user's identification information and one or more credentials issued to the authorized entity, The aforementioned instruction is, The processor is further instructed to verify that the user's identification information matches a person pre-registered in the secure information manager. The user's identification information includes user information obtained by scanning the user's individual portable access point, biometric information detected from the user's person, a display of an identification document including the user's image, an image of the user's face or eyes, or any combination thereof, one or more of these. The aforementioned instruction is, The processor is further instructed to authenticate one or more of the aforementioned credentials and the aforementioned authorized entities. The one or more authenticated credentials grant the authorized entity limited access to the user's secure information for a limited period of time. The aforementioned instruction is, A non-temporary computer-readable medium that, in response to the verification and authentication, further causes the processor to grant the computing system associated with the authorized entity the limited-scope access to the user's secure information for the limited period of time.

19. The non-temporary computer-readable medium according to claim 18, wherein the one or more credentials include a token issued to the certified entity after the execution of the certification workflow.

20. A system for granting limited access to a user's secure information, Processor and A memory for storing instructions to be executed by the aforementioned processor, Equipped with, The aforementioned instruction is, The processor is configured to receive requests from the computing system of an authorized entity to access the user's secure information in the secure information manager. The request includes the user's identification information and one or more credentials issued to the authorized entity, The aforementioned instruction is, The processor is further configured to verify that the user's identification information matches a person pre-registered in the secure information manager. The user's identification information includes user information obtained by scanning the user's individual portable access point, biometric information detected from the user's person, a display of an identification document including the user's image, an image of the user's face or eyes, or any combination thereof, one or more of these. The aforementioned instruction is, The processor is further configured to authenticate one or more of the aforementioned credentials and the aforementioned authorized entities, The one or more authenticated credentials grant the authorized entity limited access to the user's secure information for a limited period of time. The aforementioned instruction is, A system that, in response to the verification and authentication, further configures the processor to grant the computing system associated with the authorized entity the limited-scope access to the user's secure information for the limited period of time.

Images