Systems, methods, and interfaces for resource reservation using smart contracts

Abstract

A system and method for resource reservation using a smart contract is provided. The method can be performed at a permissioned blockchain network coupled to a client. The permissioned blockchain network can include a subscription service and a plurality of members. Each member can include (i) an endorsement peer node for endorsing transactions, and (ii) a committing peer node for validating and committing transactions. The method can include, at each member: (i) hosting a respective ledger, (ii) receiving, using an application programmer interface (API), a proposal from the client for reserving one or more resources through a graphical user interface, (iii) in response to receiving the reservation proposal, (a) executing a smart contract on the respective ledger to initiate a transaction for reserving the one or more resources, and (b) indicating, to the client through the graphical user interface, a successful reservation of the one or more resources or a rejection of the reservation.

Description

[0001] Related applications This application claims priority to U.S. Provisional Application Serial No. 63 / 615,361, filed December 28, 2023, entitled “System and Method for Appointment Booking Using Blockchain,” which is incorporated herein by reference in its entirety. Technical Field

[0002] This invention relates to systems, methods, and interfaces for resource reservation, and more specifically, but not in a limiting way, to techniques for resource reservation using smart contracts. Background Technology

[0003] Resource reservation systems can improve the utilization of staff, facilities, computing, storage, and network resources while reducing wait times. For example, in healthcare, appointment booking can improve the utilization of healthcare resources (including online systems). Multiple entities may require resource reservation assistance simultaneously. For routine systems, concurrent access to a resource reservation system can lead to bottlenecks and delays. Furthermore, resource reservation may require consideration of several factors, including service level agreements, cost reduction, increased satisfaction, reduced wait times, conflict resolution, and improved fairness. In some areas (such as healthcare), protecting sensitive information while reserving resources also presents challenges. Summary of the Invention

[0004] Therefore, tools, systems, methods, and interfaces are needed for resource reservation. Some embodiments use smart contracts to facilitate resource reservation, thereby notifying or informing only the parties involved in the decision-making process about the reservation. A third party (e.g., a caregiver) may act on behalf of the party requesting the reservation (e.g., a patient). Personal information or protected information (e.g., protected health information or PHI in the case of healthcare) may be shielded by the third party. Meanwhile, different entities may continue to have up-to-date information about available resources and resource reservations. Resource reservation can be facilitated through graphical user interfaces dedicated to each entity. Some embodiments provide application programmer interfaces (APIs) to interface with blockchain networks and their components and / or graphical user interfaces, thereby enabling the implementation of complex resource reservation systems. Some embodiments provide a blockchain-enabled appointment booking system that enables consumers such as patients, caregivers, payers, and / or providers to act as transaction peers and participate in appointment management transactions.

[0005] One or more embodiments of the present invention relate to improved systems and methods for resource reservation using smart contracts and / or smart interfaces. The methods can be performed at a system or server having one or more processors, memory, one or more displays, and one or more programs stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for performing the steps described herein.

[0006] The system may include a permissioned blockchain network coupled to one or more client devices. The permissioned blockchain network may include an ordering service with three orderer nodes and at least three members. Each member may include (i) an endorsement peer configured to endorse transactions, and (ii) a submission peer to verify and submit transactions. Each member may be configured to (i) host a corresponding ledger, (ii) receive a proposal from one of the one or more client devices for reserving one or more resources, and (iii) in response to receiving the reservation proposal, execute one of a plurality of smart contracts on the corresponding ledger to initiate a transaction for reserving the one or more resources. The system may also include a user interface component coupled to the permissioned blockchain network. The user interface component may be configured to provide multiple application programmer interfaces (APIs) to access multiple graphical user interfaces.

[0007] In some embodiments, the at least three members include a patient, a provider, and a caregiver.

[0008] In some embodiments, the plurality of smart contracts includes an appointment contract, a patient contract, a provider contract, and a caregiver contract.

[0009] In some embodiments, the appointment contract is configured to perform one or more operations selected from the group consisting of: creating appointments initiated by one or more patients, one or more providers, or one or more caregivers; listing appointments in response to a query for an appointment based on a patient identifier from the corresponding ledger; updating one or more appointments for the one or more patients, the one or more providers, or the one or more caregivers; referring appointments so that a provider refers an appointment to another provider; and querying all appointments based on a query pattern.

[0010] In some embodiments, the patient contract may be configured to perform one or more operations selected from the group consisting of: registering a new patient to the permissioned blockchain network; querying patient information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and updating patient information in response to requests from the one or more patients.

[0011] In some embodiments, the provider contract may be configured to perform one or more operations selected from the group consisting of: registering a new provider to the permissioned blockchain network; querying provider information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and updating provider information in response to requests from the one or more providers.

[0012] In some embodiments, the caregiver contract may be configured to perform operations selected from the group consisting of: registering a new caregiver to the permissioned blockchain network; querying caregiver information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; updating caregiver information in response to requests from the one or more caregivers; and controlling the scheduling of patient appointments.

[0013] In some embodiments, the plurality of graphical user interfaces may include one or more graphical user interfaces for client login and client subscription; a plurality of dashboards, each dashboard corresponding to a corresponding member type; an interface for a calendar view; an interface for reserving resources; an interface for accepting resource reservations; an interface for rejecting resource reservations; an interface for client profile management; and an interface for displaying the current user.

[0014] In some embodiments, the plurality of graphical user interfaces include a corresponding graphical user interface for patients, a corresponding interface for providers, and a corresponding interface for caregivers.

[0015] In some embodiments, the plurality of graphical user interfaces may include an interface having one or more revelations for a provider to refer an appointment to another provider.

[0016] In some embodiments, the permissioned blockchain network may be configured to receive a connection request from one of the one or more client devices at one of the at least three members. The permissioned blockchain network may also be configured, at a smart contract, to process the connection request to select (i) one of the plurality of graphical user interfaces (GUIs) based on the client device, and (ii) an API corresponding to the GUI; to provide the GUI to the client device via the API; to receive a selection of one of a plurality of resources from the client device via the GUI; and, in response to the selection of the resource, to perform one or more operations selected from the group consisting of the plurality of GUIs and / or the corresponding ledgers: client login, client signing up, and displaying (i) one or more dashboards, each corresponding to a corresponding member type, (ii) an interface for a calendar view, (iii) an interface for reserving resources, (iv) an interface for accepting resource reservations, (v) an interface for rejecting resource reservations, (v) an interface for client profile management, or (vi) an interface for displaying the current user.

[0017] On the other hand, a method for resource reservation using smart contracts and / or smart interfaces can be provided. The method can be executed at a permissioned blockchain network coupled to one or more client devices. The permissioned blockchain network may include an ordering service with three orderer nodes and at least three members. Each member may include (i) an endorsement peer node for conducting endorsement transactions, and (ii) a submission peer node for verifying and submitting transactions. The method may include, at each member: (i) hosting a corresponding ledger, (ii) receiving a proposal for reserving one or more resources from the one or more client devices using one or more application user interfaces (APIs) via one or more graphical user interfaces (GUIs), (iii) in response to receiving the reservation proposal, (a) executing one of a plurality of smart contracts on the corresponding ledger to initiate a transaction for reserving the one or more resources, and (b) indicating to the client device, via the one or more GUIs, a successful reservation of one or more resources or a rejection of the reservation.

[0018] In some embodiments, the at least three members may include a patient, a provider, and a caregiver.

[0019] In some embodiments, the plurality of smart contracts may include an appointment contract, a patient contract, a provider contract, and a caregiver contract.

[0020] In some embodiments, the appointment contract may include operations selected from the group consisting of: creating appointments initiated by one or more patients, one or more providers, or one or more caregivers; listing appointments in response to a query for an appointment based on a patient identifier from the corresponding ledger; updating one or more appointments for one or more patients, one or more providers, or one or more caregivers; referring appointments so that a provider refers an appointment to another provider; and querying all of the appointments based on a query pattern.

[0021] In some embodiments, the appointment contract may include operations selected from the group consisting of: registering a new patient to the permissioned blockchain network; querying patient information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and updating patient information in response to requests from the one or more patients.

[0022] In some embodiments, the provider contract may include operations selected from the group consisting of: registering a new provider to the permissioned blockchain network; retrieving provider information from the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and updating provider information in response to requests from the one or more providers.

[0023] In some embodiments, the caregiver contract may include operations selected from the group consisting of: registering a new caregiver to the permissioned blockchain network; retrieving caregiver information from the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; updating caregiver information in response to requests from the one or more caregivers; and controlling the scheduling of patient appointments.

[0024] In some embodiments, the plurality of graphical user interfaces may include one or more graphical user interfaces for client login and client subscription; a plurality of dashboards, each dashboard corresponding to a corresponding member type; an interface for a calendar view; an interface for reserving resources; an interface for accepting resource reservations; an interface for rejecting resource reservations; an interface for client profile management; and an interface for displaying the current user.

[0025] In some embodiments, the plurality of graphical user interfaces include a corresponding graphical user interface for patients, a corresponding interface for providers, and a corresponding interface for caregivers.

[0026] In some embodiments, the plurality of graphical user interfaces may include an interface having one or more revelations for a provider to refer an appointment to another provider.

[0027] In some embodiments, the method includes receiving a connection request from one of the one or more client devices at one of the at least three members. The method may further include, at a smart contract: processing the connection request to select (i) one of a plurality of graphical user interfaces (GUIs) based on the client device, and (ii) an API corresponding to the GUI; providing the GUI to the client device via the API; receiving a selection of one of a plurality of resources from the client device via the GUI; and, in response to the selection of the resource, performing one or more operations selected from the group consisting of the plurality of GUIs and / or the corresponding ledgers: client login, client subscription, and displaying (i) one or more dashboards, each corresponding to a corresponding member type, (ii) an interface for a calendar view, (iii) an interface for reserving resources, (iv) an interface for accepting resource reservations, (v) an interface for rejecting resource reservations, (v) an interface for client profile management, or (vi) an interface for displaying the current user.

[0028] In some embodiments, the computer system has one or more processors, memory, and a display. The one or more programs include instructions for performing any of the methods described herein.

[0029] In some embodiments, a non-transitory computer-readable storage medium stores one or more programs configured for execution by a computer system having one or more processors, memory, and a display. The one or more programs include instructions for performing any of the methods described herein.

[0030] This application discloses subject matter corresponding to the following numbered clauses: (A1) A system for reserving resources using smart contracts, the system comprising: a permissioned blockchain network coupled to one or more client devices, wherein the permissioned blockchain network includes a subscription service and at least three members, wherein each member is configured to (i) host a corresponding ledger, (ii) receive a proposal from one of the one or more client devices for reserving one or more resources, and (iii) in response to receiving the reservation proposal, execute one of a plurality of smart contracts on the corresponding ledger to initiate a transaction for reserving the one or more resources; and a user interface component coupled to the permissioned blockchain network, wherein the user interface component is configured to provide a plurality of application user interfaces (APIs) for accessing a plurality of graphical user interfaces.

[0031] (A2) The system described in Clause (A1), wherein the at least three members include a patient, a provider, and a caregiver.

[0032] (A3) The system pursuant to any one of the provisions (A1) to (A2), wherein the plurality of smart contracts includes an appointment contract, a patient contract, a provider contract and a caregiver contract.

[0033] (A4) The system according to clause (A3), wherein the appointment contract is configured to create appointments initiated by one or more patients, one or more providers, or one or more caregivers; list appointments in response to a query for an appointment based on a patient identifier from the corresponding ledger; update one or more appointments for the one or more patients, the one or more providers, or the one or more caregivers; refer appointments so that a provider refers an appointment to another provider; and query all of the appointments based on a query pattern.

[0034] (A5) The system according to clause (A3), wherein the patient contract is configured to register new patients to the permissioned blockchain network; query patient information in the corresponding ledger in response to queries from one or more patients, one or more providers or one or more caregivers; and update patient information in response to requests from the one or more patients.

[0035] (A6) The system according to clause (A3), wherein the provider contract is configured to register a new provider to the permissioned blockchain network; query provider information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and update provider information in response to requests from the one or more providers.

[0036] (A7) The system according to clause (A3), wherein the caregiver contract is configured to register new caregivers to the permissioned blockchain network; query caregiver information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; update caregiver information in response to requests from the one or more caregivers; and control the appointment of patient appointments.

[0037] (A8) The system according to any one of the clauses (A1) to (A7), wherein the plurality of graphical user interfaces includes one or more graphical user interfaces for client login and client subscription; a plurality of dashboards, each dashboard corresponding to a corresponding member type; an interface for a calendar view; an interface for reserving resources; an interface for accepting resource reservations; an interface for rejecting resource reservations; an interface for client profile management; and an interface for displaying the current user.

[0038] (A9) The system according to any one of the clauses (A1) to (A8), wherein the plurality of graphical user interfaces includes a corresponding graphical user interface for the patient, a corresponding interface for the provider, and a corresponding interface for the caregiver.

[0039] (A10) A system according to any one of the terms (A1) to (A9), wherein the plurality of graphical user interfaces includes an interface having one or more revelations for a provider to refer an appointment to another provider.

[0040] (A11) A system according to any one of the clauses (A1) to (A10), wherein the permissioned blockchain network is configured to: at one of the at least three members: receive a connection request from one of the one or more client devices; at a smart contract: process the connection request to select (i) one of the plurality of graphical user interfaces based on the client device, and (ii) an API corresponding to the graphical user interface; provide the graphical user interface to the client device via the API; receive a selection of one of a plurality of resources from the client device via the graphical user interface; and in response to the selection of the resource, perform one or more operations selected from the group consisting of the plurality of graphical user interfaces and / or the corresponding ledger: client login, client signing, and display (i) one or more dashboards, each dashboard corresponding to a corresponding member type, (ii) an interface for a calendar view, (iii) an interface for reserving resources, (iv) an interface for accepting resource reservations, (v) an interface for rejecting resource reservations, (v) an interface for client profile management, or (vi) an interface for displaying the current user.

[0041] (A12) A system pursuant to any one of the provisions (A1) to (A11), wherein each member comprises (i) an endorsement peer configured to perform endorsement transactions, and (ii) a submission peer for verifying and submitting transactions.

[0042] (B1) A method for reserving resources using smart contracts, the method comprising: at a permissioned blockchain network coupled to one or more client devices, wherein the permissioned blockchain network includes an ordering service having three orderer nodes and at least three members: at each member: (i) hosting a corresponding ledger, (ii) receiving, using one or more application user interfaces (APIs), via one or more graphical user interfaces (GUIs) from the one or more client devices, a proposal for reserving one or more resources, (iii) in response to receiving the reservation proposal, (a) executing one of a plurality of smart contracts on the corresponding ledger to initiate a transaction for reserving the one or more resources, and (b) indicating to the client device, via the one or more GUIs, a successful reservation of the one or more resources or a rejection of the reservation.

[0043] (B2) The method described in clause (B1), wherein the at least three members include the patient, the provider, and the caregiver.

[0044] (B3) The method according to any one of the terms (B1) to (B2), wherein the plurality of smart contracts includes an appointment contract, a patient contract, a provider contract and a caregiver contract.

[0045] (B4) The method according to clause (B3), wherein the appointment contract includes operations selected from the group consisting of: creating an appointment initiated by one or more patients, one or more providers, or one or more caregivers; listing the appointments in response to a query for the appointment based on a patient identifier from the corresponding ledger; updating one or more appointments for one or more patients, one or more providers, or one or more caregivers; referring the appointment to a provider so that the provider refers the appointment to another provider; and querying all the appointments based on a query pattern.

[0046] (B5) The method according to clause (B3), wherein the patient contract includes operations selected from the group consisting of: registering a new patient to the permissioned blockchain network; querying the patient information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and updating the patient information in response to requests from the one or more patients.

[0047] (B6) The method according to clause (B3), wherein the provider contract includes operations selected from the group consisting of: registering a new provider to the permissioned blockchain network; retrieving provider information from the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and updating provider information in response to requests from the one or more providers.

[0048] (B7) The method described in accordance with clause (B3), wherein the caregiver contract includes operations selected from the group consisting of: registering a new caregiver to the permissioned blockchain network; querying caregiver information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; updating caregiver information in response to requests from the one or more caregivers; and controlling appointments for patients.

[0049] (B8) The method according to any one of clauses (B1) to (B7), wherein before selecting the intervention communication data structure: a connection request is received from one of the one or more client devices; at the smart contract: the connection request is processed to select (i) one of the plurality of graphical user interfaces based on the client device, and (ii) an API corresponding to the graphical user interface; the graphical user interface is provided to the client device via the API; a selection of one of a plurality of resources is received from the client device via the graphical user interface; and in response to the selection of the resource, one or more operations selected from the group consisting of the plurality of graphical user interfaces and / or the corresponding ledger are performed using the plurality of graphical user interfaces and / or the corresponding ledger: client login, client signing up, and displaying (i) one or more dashboards, each dashboard corresponding to a corresponding member type, (ii) an interface for a calendar view, (iii) an interface for reserving resources, (iv) an interface for accepting resource reservations, (v) an interface for rejecting resource reservations, (v) an interface for client profile management, or (vi) an interface for displaying the current user. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of an example system for resource reservation using smart contracts and / or smart interfaces according to some embodiments; Figure 2A This is an example user interface for a provider login resource reservation system based on some embodiments; Figure 2B An example user interface of a caregiver login resource reservation system according to some embodiments is shown; Figure 2C An example user interface for a caregiver's dashboard, according to some embodiments, is shown; Figure 2D An example user interface for another dashboard for caregivers, according to some embodiments, is shown; Figure 2E An example user interface for a provider's dashboard, according to some embodiments, is shown; Figure 2FAn example user interface for a patient's dashboard, according to some embodiments, is shown; Figure 2G A sample user interface for a caregiver's calendar view is shown according to some embodiments; Figure 2H An example user interface for caregivers to schedule appointments is shown according to some embodiments; Figure 2I An example user interface for patient appointment booking is shown according to some embodiments; Figure 2J An example user interface for patient appointment refusal is shown according to some embodiments; Figure 2K A sample user interface for a caregiver to create a profile is shown according to some embodiments; Figure 2L An example user interface for a caregiver's dashboard, according to some embodiments, is shown; Figure 3A A flowchart illustrating an example method for a patient to book an appointment with a provider without a caregiver, according to some embodiments, is shown; Figure 3B A flowchart illustrating an example method of a patient booking an appointment with a provider when the patient has a caregiver, according to some embodiments, is shown. Figure 3C A flowchart illustrating an example method of a caregiver booking an appointment with a provider on behalf of a patient, according to some embodiments; Figure 3D A flowchart illustrating an example method for a provider and patient to book an appointment, according to some embodiments, is shown; Figure 3E A flowchart of an example method of a referral process according to some embodiments is shown. Detailed Implementation

[0051] The following description of embodiments of the present invention is exemplary and not restrictive, and many variations and modifications are within the scope and spirit of the invention. While numerous specific details are set forth to provide a thorough understanding of the invention, it will be apparent to those skilled in the art that embodiments of the invention can be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily obscuring the invention.

[0052] One or more embodiments of the present invention relate to improved methods and systems for reserving resources using smart contracts and / or smart interfaces.

[0053] Figure 1This is a schematic diagram of an example system 100 using smart contracts and / or smart interfaces for resource reservation according to some embodiments. System 100 may include a permissioned blockchain network 104 (e.g., Hyperledger Fabric), which may include orderer nodes 108 and members (sometimes referred to as organizations, e.g., patients 110, providers 112, and caregivers 114). Each member may include a peer-to-peer node, a clustered database that can be used on any number of servers or virtual machines (VMs), and / or a Certificate Authority (CA). Members may connect via one or more channels 106. For the purpose of conducting private and confidential transactions, a channel may be a private subnetwork for communication between members 110, 112, and / or 114 (and in alternative embodiments, more channels may exist). Channels may be defined by members, each member's anchor peer, a shared ledger, chaincode or smart contract applications, and / or orderer 108 (sometimes referred to as an ordering service node). Every transaction on the network may be executed on a channel (e.g., channel 106). Each party can be authenticated and authorized to transact on the channel. Each peer joining the channel can have its own identity provided by the service provider, which can authenticate each peer (for the channel) and the corresponding service.

[0054] For permissioned blockchain networks, Fabric, Quorum, Corda, or private Ethereum are example permissioned blockchain networks that can add security layers to allow only authorized participants within the network. To achieve consensus, Fabric follows Practical Byzantine Fault Tolerance (PBFT) or RAFT consensus, which is more fault-tolerant and performance-oriented compared to other blockchain networks using Proof-of-Stake (PoS) or Proof-of-Work (PoW) consensus and Corda using protocol consensus. Compared to Ethereum and Corda, Fabric is designed to be scalable and customizable. Some implementations can utilize Fabric features such as multiple channels, smart contracts as a service, cloud deployment, private transactions, event listeners, and / or customizable ledger data. Depending on the application, different permissioned blockchain frameworks can be used. For example, Fabric can be used for healthcare and supply chain, while another blockchain can be used for finance and supply chain-focused technologies.

[0055] System 100 may include one or more application programmer interfaces (APIs) 116 to interface with a permissioned blockchain network 104 and multiple graphical user interfaces (UIs) (e.g., patient UI 118, provider UI 120, caregiver UI 122, and / or browser UI 124). Each UI may be dedicated to a specific type of client or may be used for illustration, as further described below. The browser UI may include a Hyperledger browser configured with the blockchain network to provide views of the blockchain network's nodes, organizations, chaincode, transactions, channels, and blocks.

[0056] The permissioned blockchain network 104, API 116, and / or UI can be configured in the control plane 102 (e.g., the Kubernetes control plane) of the cloud service instance 128 (e.g., Amazon Web Services). The control plane 102 may include services that interact with the data plane. The cloud service instance 128 may be a management service that eliminates the need to install, operate, and maintain its own Kubernetes control plane. Kubernetes is an example open-source system that automates the management, scaling, and deployment of containerized applications.

[0057] System 100 may include an application load balancer 126 that interfaces with one or more applications (sometimes referred to as client devices, clients, or client applications).

[0058] Some embodiments employ an inclusive transaction scheme, whereby any member or party can act as the primary entity in any transaction. Network participants can belong to the same channel. The primary entity can be the entity that initiates and participates in the transaction. For example, (i) the patient and provider can act as the primary entity, while the caregiver, payer, and other providers can act as related entities; (ii) the caregiver and provider can act as the primary entity, while the patient, payer, and other providers can act as related entities; (iii) two providers can act as the primary entity, while the patient, caregiver, and payer can act as related entities; (iv) the payer and patient can act as the primary entity, while the caregiver and provider can act as related entities. Patient and caregiver nodes can be managed by the payer system (e.g., when each patient and caregiver cannot have their own private node).

[0059] Confirmation of resource reservations (e.g., appointments) can be driven by consensus and probate. A shared ledger and blockchain-managed appointment book ensure that directly or indirectly connected entities can access relevant, confirmed resource reservations. Digitally confirmed transactions and / or verified transactions or appointments improve service levels and the service experience for consumers. The appointment book can be maintained as part of a shared ledger that enables organizations within the blockchain network to have common and credible visibility into the entire appointment pool. Appointments can provide early insights into evolving patient-provider relationships (e.g., primary caregivers, providers, caregivers), healthcare needs, and patient actions. Blockchain can provide the ability to enable and utilize multi-organizational consensus to prevent the publication of undesirable transactions (e.g., duplicate or overlapping transactions) in the ecosystem, as more than two or a majority of organizations must agree on a transaction before it is published on the blockchain ledger. Blockchain can be used to establish a source of truth when dispute resolution is an established or operational process. The blockchain ledger can provide end-to-end visibility and traceability of transactions on the network. Payers, community, or public health organizations can gain insights by observing appointments.

[0060] Although the description uses an appointment booking system to explain the concept, the technology can be used to reserve any type of shared resources and / or in scenarios other than healthcare.

[0061] Figure 2A This is an example user interface 200 for a provider login resource reservation system according to some embodiments. Interface 200 can be used by a provider (e.g., a doctor) providing services to patients to reserve and / or manage resources (e.g., book appointments). Providers can use interface 200 to authenticate to the system.

[0062] Figure 2B An example user interface 202 for a caregiver login resource reservation system according to some embodiments is shown. Caregivers can use interface 202 to reserve and / or manage resources for patients (or multiple patients). Caregivers can use interface 202 to authenticate with the system.

[0063] Figure 2C An example user interface 204 for a caregiver's dashboard, according to some embodiments, is shown. The caregiver can view the dashboard after authenticating via user interface 202. The dashboard may include various areas. Area 210 may display the provider, area 212 may display the patient, area 214 may display scheduled appointments, area 216 may display pending appointments, area 218 may display appointments, area 220 may display monthly appointments with patients, area 222 may display upcoming appointments, and / or area 224 may display the monthly appointment status. As further described below, any of these areas can be updated in real time.

[0064] Figure 2D An example user interface 206 for another dashboard for caregivers, according to some embodiments, is shown. The dashboard may include various areas. Area 226 may display past appointments, area 228 may display upcoming appointments, area 230 may display confirmed appointments, area 232 may display pending appointments, area 234 may display an appointment dashboard calendar view, and / or area 236 may display a schedule. As further described below, any of these areas can be updated in real time.

[0065] Figure 2E An example user interface 208 for a provider's dashboard according to some embodiments is shown. The dashboard may include various areas. Area 238 may display past appointments, area 240 may display upcoming appointments, area 242 may display confirmed appointments, area 244 may display pending appointments, area 246 may display an appointment dashboard calendar view, and / or area 248 may display appointments referred (to another provider). As further described below, any of these areas can be updated in real time.

[0066] Figure 2F An example user interface 250 for a patient dashboard according to some embodiments is shown. The dashboard may include various areas. Area 264 may display past appointments, area 266 may display upcoming appointments, area 268 may display confirmed appointments, area 270 may display pending appointments, area 272 may display an appointment dashboard calendar view, and / or area 274 may display appointment details. As further described below, any of these areas can be updated in real time.

[0067] Figure 2G An example user interface 252 for a caregiver's calendar view is shown according to some embodiments. The view may include various areas. Area 276 may display past appointments, area 278 may display upcoming appointments, area 280 may display confirmed appointments, area 282 may display pending appointments, and / or area 284 may display a calendar of appointments with color coding (or appropriate patterning). Any of these areas can be updated in real time, as further described below.

[0068] Figure 2H An example user interface 254 for caregivers to schedule appointments is shown according to some embodiments. Area 286 of the UI can be highlighted (while other areas can be blurred). Area 286 allows caregivers to schedule appointments through the interface.

[0069] Figure 2IAn example user interface 256 for patient appointment acceptance is shown according to some embodiments. A pop-up window 288 may be displayed to the patient to accept the appointment.

[0070] Figure 2J An example user interface 258 for a patient refusing an appointment is shown according to some embodiments. A pop-up window 290 may be displayed to the patient to refuse the appointment.

[0071] Figure 2K An example user interface 260 for a caregiver creating a profile is shown according to some embodiments. Area 292 may show a summary of the profile (current status, such as username, location, date or time information, one or more updates to the profile, such as uploading an image), and / or area 294 may show details of the profile. As further described below, any of these areas can be updated in real time.

[0072] Figure 2L An example user interface 262 for a caregiver's dashboard, according to some embodiments, is shown. Area 296 may display users, area 297 may display caregivers, area 298 may display providers, and / or area 299 may display a list of users. As further described below, any of these areas can be updated in real time.

[0073] Figure 3A A flowchart of an example method 300 for a patient to book an appointment with a provider without a caregiver, according to some embodiments, is shown. The patient can book (302) an appointment, and the provider can confirm or decline (304). The patient can then be notified (306). In this scenario, the patient does not have a caregiver, so the patient books the appointment directly with the provider (without intermediaries). The result can be updated in the patient's calendar (e.g., a calendar similar to calendar view 234). Steps 302 and / or 306 can be performed via a patient UI 118, which can be similar to a caregiver UI 122, an example of which is referenced above. Figure 2B , 2C The 2D model is described, except that the patient has information about their own appointment, not that of a third party. Appointment booking and / or provider confirmation can be executed via chaincode or smart contracts in patient 110 and provider 112.

[0074] Figure 3BA flowchart of an example method 308 for a patient and provider to book an appointment when the patient has a caregiver, according to some embodiments, is shown. The patient can book (310) the appointment, and the caregiver can confirm or decline (312). Subsequently, the patient can be notified (314) of the caregiver's decline. If the caregiver confirms, the patient and provider can be notified (316) of the caregiver's acceptance. After the caregiver confirms the appointment, the request can be reflected in both the provider's calendar and the patient's calendar. After the provider confirms (318), the patient and caregiver can be notified (320). After the provider confirms, the appointment can be reflected in both the caregiver's calendar and the patient's calendar. Notifications and / or calendar updates can be made using the references above. Figure 1 and 2A -2E and / or its variants describe the UI. Appointment booking and / or provider confirmation can be executed via chaincode or smart contracts in patient 110, provider 112, and caregiver 114.

[0075] Figure 3C A flowchart of an example method 322, according to some embodiments, is shown. When the caregiver books (324) an appointment for the patient, the provider can confirm (326), in which case, notify both the patient and the caregiver (330); otherwise, the provider can notify the caregiver (328) that the appointment has been declined. Acceptance after provider confirmation can be reflected as an appointment in both the patient's and the caregiver's calendars. Notifications and / or calendar updates may be made using the references above. Figure 1 and 2A -2E and / or its variants describe the UI. Reservation and / or provider confirmation can be executed via chaincode or smart contracts in Provider 112 and Caregiver 114.

[0076] Figure 3D A flowchart of an example method 372 for a provider to book an appointment with a patient, according to some embodiments, is shown. When the provider books (332) an appointment for the patient, only the caregiver (334) may be notified. After the caregiver confirms (336), the provider (340) may be notified. If the caregiver declines the appointment, the provider may be notified of the decline (338). If the provider confirms (346), both the patient and the caregiver (346) may be notified. If the provider declines, only the caregiver (344) may be notified. Notifications and / or calendar updates may be made using the references above. Figure 1 and 2A -2E and / or its variants describe the UI. Reservation and / or provider confirmation can be executed via chaincode or smart contracts in Provider 112 and Caregiver 114.

[0077] Figure 3EA flowchart of an example method 348 of a referral process according to some embodiments is shown. Provider A can make an appointment with Provider B for the patient (350). Provider B can be notified (352). Provider B can confirm (354), in which case only the caregiver is notified (358); the patient may not be notified. If Provider B refuses, Provider A can be notified (356). In this case, Provider A can restart by referring to another provider. After Provider B confirms, A may not see the appointment in their calendar; in the UI described above, the option to automatically display the appointment can be enabled. If Provider B confirms (354), the request can be forwarded to a caregiver who can confirm (360). If the caregiver refuses, both Provider A and B are notified (362). If the caregiver confirms (360), Provider B may be notified again (364). Then Provider B confirms again (366). If Provider B refuses, Provider A and the caregiver can be notified (368). If Provider B confirms, the patient, the caregiver, and both providers are notified (370).

[0078] According to some embodiments, this document describes an example method for resource reservation using system 100. The method can be executed at a system or server (or a group of servers) having one or more processors, memory, one or more displays, and one or more programs stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for performing the steps described herein. System 100 may include a permissioned blockchain network (e.g., network 104) coupled to one or more client devices (e.g., client devices coupled via application load balancer 126, client devices connected to a graphical user interface, client devices connected to a website or web server). The permissioned blockchain network may include an ordering service (e.g., orderer 108) having three orderer nodes (or an odd number of orderer nodes for optimal performance) and at least three members (e.g., patient 110, provider 112, and caregiver 114). Each member may include (i) an endorsement peer node configured to endorse transactions, and (ii) a submission peer node that verifies and submits transactions. Each member can be configured to (i) host a corresponding ledger, (ii) receive a proposal from one of the one or more client devices for reserving one or more resources, and (iii) in response to receiving the reservation proposal, execute one of a plurality of smart contracts on the corresponding ledger to initiate a transaction for reserving the one or more resources. The system may also include a user interface component (e.g., a UI component including UIs 118, 120, 122, and / or 124) coupled to the permissioned blockchain network 104. The user interface component can be configured to provide multiple application programmer interfaces (APIs) to access multiple graphical user interfaces.

[0079] In some embodiments, at least three members may include a patient (e.g., patient 110), a provider (e.g., provider 112), and / or a caregiver (e.g., caregiver 114). Requests from clients (e.g., patients, providers, caregivers) may be processed by their respective blockchain nodes (smart contracts) via API calls. For example, a patient request may be processed by patient 110, a provider request by provider 112, and a caregiver request by caregiver 114.

[0080] In some embodiments, the plurality of smart contracts may include an appointment contract, a patient contract, a provider contract, and / or a caregiver contract. The patient contract may be executed on patient 110, the provider contract on provider 112, and / or the caregiver contract on caregiver 114. Participants in the blockchain network may have appointment contracts installed on their respective blockchain nodes.

[0081] In some embodiments, the appointment contract may be configured to perform one or more operations selected from the group consisting of: creating appointments initiated by one or more patients, one or more providers, or one or more caregivers; listing appointments in response to a query for an appointment based on a patient identifier from the corresponding ledger; updating one or more appointments for the one or more patients, the one or more providers, or the one or more caregivers; referring appointments so that a provider refers an appointment to another provider; and querying all appointments based on a query pattern.

[0082] In some embodiments, the patient contract may be configured to perform one or more operations selected from the group consisting of: registering a new patient to the permissioned blockchain network 104; querying patient information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and updating patient information in response to requests from the one or more patients.

[0083] In some embodiments, the provider contract may be configured to perform one or more operations selected from the group consisting of: registering a new provider to the permissioned blockchain network 104; querying provider information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and updating provider information in response to requests from the one or more providers.

[0084] In some embodiments, the caregiver contract may be configured to perform operations selected from the group consisting of: registering a new caregiver to the permissioned blockchain network 104; querying caregiver information in the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; updating caregiver information in response to requests from the one or more caregivers; and controlling the scheduling of patient appointments.

[0085] In some embodiments, the plurality of graphical user interfaces may include one or more graphical user interfaces for client login and client subscription; a plurality of dashboards, each dashboard corresponding to a corresponding member type; an interface for a calendar view; an interface for reserving resources; an interface for accepting resource reservations; an interface for rejecting resource reservations; an interface for client profile management; and an interface for displaying the current user. References above are made to some embodiments. Figure 1 and 2A -2E describes an instance of the UI.

[0086] In some embodiments, the plurality of graphical user interfaces may include a corresponding graphical user interface for patients (e.g., UI 118), a corresponding interface for providers (e.g., UI 120), and a corresponding interface for caregivers (e.g., UI 122).

[0087] In some embodiments, the plurality of graphical user interfaces may include an interface having one or more revelations for a provider to refer an appointment to another provider (see above). Figure 2E (Describes its instances).

[0088] In some embodiments, the permissioned blockchain network 104 may be configured to receive a connection request from one of one or more client devices at one of at least three members. The permissioned blockchain network 104 may also be configured at a smart contract to process the connection request to select (i) one of the plurality of graphical user interfaces (GUIs) based on the client (e.g., a patient UI 118 may show a connection from a patient, a provider UI 120 may show a connection request from a patient, and a caregiver UI 122 may show a connection request from a caregiver), and / or (ii) an API corresponding to the GUI (e.g., an API...). 116); providing the graphical user interface to the client via the API; receiving from the client device via the graphical user interface a selection of one of a variety of resources (e.g., a calendar showing available appointment dates where the user can select a specific date, a set of providers showing a set where the user can select a specific provider, selection of other providers showing a provider to refer a patient, a set of medical or computational resources showing a set where the user can select a resource to reserve, etc.); and in response to the selection of the resource, using the plurality of graphical user interfaces and / or the corresponding ledger, performing one or more operations selected from the group consisting of: client login, client signing up, and displaying (i) one or more dashboards, each corresponding to a corresponding member type, (ii) an interface for a calendar view, (iii) an interface for reserving resources, (iv) an interface for accepting resource reservations, (v) an interface for rejecting resource reservations, (v) an interface for client profile management, or (vi) an interface for displaying the current user.

[0089] In some embodiments, the application load balancer may target one or more APIs. The API may determine which smart contract needs to be executed based on requests received from a graphical user interface (e.g., selection via a user interface or screen on a client device, or a request triggered by the application). The backend API may handle this logic. Requests received from client devices may be handled by one or more graphical user interfaces, the application load balancer, and / or the API.

[0090] While embodiments and alternatives have been disclosed and discussed, the invention herein is not limited to the specific disclosed embodiments or alternatives, but rather covers the full breadth and scope of the invention (including equivalents), and is not limited except as set forth and covered in the full breadth and scope of the claims.

Claims

1. A system for reserving resources using smart contracts, the system comprising: A permissioned blockchain network coupled to one or more client devices, wherein the permissioned blockchain network includes a subscription service and at least three members, wherein each member is configured to (i) host a corresponding ledger, (ii) receive a proposal from one of the one or more client devices for reserving one or more resources, and (iii) in response to receiving the reservation proposal, execute one of a plurality of smart contracts on the corresponding ledger to initiate a transaction for reserving the one or more resources; and User interface components, coupled to the permissioned blockchain network, are configured to provide multiple application user interfaces (APIs) to access multiple graphical user interfaces.

2. The system of claim 1, wherein the at least three members include a patient, a provider, and a caregiver.

3. The system of claim 1, wherein the plurality of smart contracts includes an appointment contract, a patient contract, a provider contract, and a caregiver contract.

4. The system of claim 3, wherein the reservation contract is configured to: Create an appointment initiated by one or more patients, one or more providers, or one or more caregivers; The appointments are listed in response to a query for an appointment based on a patient identifier from the corresponding ledger; Update one or more appointments related to the one or more patients, the one or more providers, or the one or more caregivers; Referral appointments, enabling a provider to refer an appointment to another provider; and Use the query pattern to retrieve all the aforementioned appointments.

5. The system of claim 3, wherein the patient contract is configured to: Register new patients to the permissioned blockchain network; In response to queries from one or more patients, one or more providers, or one or more caregivers, the patient information in the corresponding ledger is retrieved; and Patient information is updated in response to requests from one or more of the patients.

6. The system of claim 3, wherein the provider contract is configured to: Register new providers to the permissioned blockchain network; In response to queries from one or more patients, one or more providers, or one or more caregivers, the provider information in the corresponding ledger is retrieved; and Update provider information in response to requests from one or more of the providers.

7. The system of claim 3, wherein the caregiver contract is configured to: Register new caregivers to the permissioned blockchain network; In response to queries from one or more patients, one or more providers, or one or more caregivers, the caregiver information in the corresponding ledger is retrieved; Update caregiver information in response to requests from one or more caregivers; and Controlling patient appointment scheduling.

8. The system of claim 1, wherein the plurality of graphical user interfaces includes one or more graphical user interfaces for client login and client subscription; a plurality of dashboards, each dashboard corresponding to a corresponding member type; an interface for a calendar view; an interface for reserving resources; an interface for accepting resource reservations; an interface for rejecting resource reservations; an interface for client profile management; and an interface for displaying the current user.

9. The system of claim 1, wherein the plurality of graphical user interfaces includes a corresponding graphical user interface for the patient, a corresponding interface for the provider, and a corresponding interface for the caregiver.

10. The system of claim 1, wherein the plurality of graphical user interfaces includes an interface having one or more revelations for a provider to refer an appointment to another provider.

11. The system of claim 1, wherein the permissioned blockchain network is configured to: At one of the at least three members: Receive a connection request from one of the one or more client devices; At the smart contract level: The connection request is processed to select (i) one of the plurality of graphical user interfaces based on the client device, and (ii) the API corresponding to the graphical user interface; The graphical user interface is provided to the client device through the API; Receive a selection of one of a variety of resources from the client device through the graphical user interface; and In response to the selection of the resource, one or more operations selected from the group consisting of the plurality of graphical user interfaces and / or the corresponding ledger are performed using the plurality of graphical user interfaces and / or the corresponding ledger: client login, client signing, and displaying (i) one or more dashboards, each dashboard corresponding to a corresponding member type, (ii) an interface for a calendar view, (iii) an interface for reserving resources, (iv) an interface for accepting resource reservations, (v) an interface for rejecting resource reservations, (v) an interface for client profile management, or (vi) an interface for displaying the current user.

12. The system of claim 1, wherein each member comprises (i) an endorsement peer configured to perform endorsement transactions, and (ii) a submission peer for verifying and submitting transactions.

13. A method for reserving resources using smart contracts, the method comprising: At a permissioned blockchain network coupled to one or more client devices, said permissioned blockchain network includes a subscription service with three subscriber nodes and at least three members: At each member: (i) hosts the corresponding ledger, (ii) uses one or more application user interfaces (APIs) to receive a proposal for reserving one or more resources from the one or more client devices via one or more graphical user interfaces, (iii) in response to receiving the reservation proposal, (a) executes one of a plurality of smart contracts on the corresponding ledger to initiate a transaction for reserving the one or more resources, and (b) indicates to the client device via the one or more graphical user interfaces the successful reservation of one or more resources or the rejection of the reservation.

14. The method of claim 13, wherein the at least three members include a patient, a provider, and a caregiver.

15. The method of claim 13, wherein the plurality of smart contracts comprises an appointment contract, a patient contract, a provider contract, and a caregiver contract.

16. The method of claim 15, wherein the reservation contract comprises operations selected from the group consisting of: Create an appointment initiated by one or more patients, one or more providers, or one or more caregivers; The appointments are listed in response to a query for an appointment based on a patient identifier from the corresponding ledger; Update one or more appointments for one or more patients, one or more providers, or one or more caregivers; Referral appointments, enabling a provider to refer an appointment to another provider; as well as Use the query pattern to retrieve all the aforementioned appointments.

17. The method of claim 15, wherein the patient contract comprises operations selected from the group consisting of: Register new patients to the permissioned blockchain network; Retrieving patient information from the corresponding ledger in response to queries from one or more patients, one or more providers, or one or more caregivers; and Patient information is updated in response to requests from one or more of the patients.

18. The method of claim 15, wherein the provider contract comprises operations selected from the group consisting of: Register new providers to the permissioned blockchain network; In response to queries from one or more patients, one or more providers, or one or more caregivers, the provider information in the corresponding ledger is retrieved; as well as Update provider information in response to requests from one or more of the providers.

19. The method of claim 15, wherein the caregiver contract comprises operations selected from the group consisting of: Register new caregivers to the permissioned blockchain network; In response to queries from one or more patients, one or more providers, or one or more caregivers, the caregiver information in the corresponding ledger is retrieved; Update caregiver information in response to requests from one or more caregivers; as well as Controlling patient appointment scheduling.

20. The method of claim 13, comprising: At one of the at least three members: Receive a connection request from one of the one or more client devices; At the smart contract level: The connection request is processed to select (i) one of the plurality of graphical user interfaces based on the client device, and (ii) the API corresponding to the graphical user interface; The graphical user interface is provided to the client device through the API; Receive a selection of one of a variety of resources from the client device through the graphical user interface; as well as In response to the selection of the resource, one or more operations selected from the group consisting of the plurality of graphical user interfaces and / or the corresponding ledger are performed using the plurality of graphical user interfaces and / or the corresponding ledger: client login, client signing, and displaying (i) one or more dashboards, each dashboard corresponding to a corresponding member type, (ii) an interface for a calendar view, (iii) an interface for reserving resources, (iv) an interface for accepting resource reservations, (v) an interface for rejecting resource reservations, (v) an interface for client profile management, or (vi) an interface for displaying the current user.

Images