SYSTEMS AND METHODS FOR SMART CONTRACTS USING MULTIPLE DISTRIBUTED LEDGERS

Systems and methods for complex process flow approval using distributed ledgers are disclosed. The method may include generating a process initiation message based on input from a second service provider or a user. The method may include recording the process initiation message on a first distributed ledger. The method may include monitoring the first distributed ledger for an indication of an approval event. The method may include generating a settlement event based on the indication of the approval event. The method may include recording the settlement event on the first distributed ledger. The method may include communicating a settlement event message to a second distributed ledger. The method may include generating a virtual payment instrument associated with the settlement event message, the indication of the approval event, and the process initiation message.

RELATED APPLICATIONS

This application claims priority to Indian Patent Application No. 202111036056, filed Aug. 10, 2021, the disclosure of which is hereby incorporated, by reference, in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments are generally related to systems and methods for multiple ledger smart contracts.

2. Description of the Related Art

Processing complex approval processes between disparate entities involves the coordination of multiple parties and systems. For example, various process flow approvals, legal regulations, differing processing times, and delays for authentication requirements and fraud prevention. The sheer number of parties often causes processing delays and increases the timeframe for payment processing resolution.

SUMMARY OF THE INVENTION

Systems and methods for complex process flow approval using distributed ledgers are disclosed. According to one embodiment, a method for complex process flow approval may include generating, by a first service provider, a process initiation message based on input from a second service provider or a user. The method may further include recording, on a first distributed ledger, the process initiation message. The method may further include monitoring, by a smart contract, the first distributed ledger for an indication of an approval event associated with the process initiation message. The method may further include generating, by the first service provider, a settlement event based on the indication of the approval event. The method may further include recording, on the first distributed ledger, the settlement event. The method may further include communicating a settlement event message to a second distributed ledger. The method may further include generating, based on the settlement event message, a virtual payment instrument or instrument associated with the settlement event message, the indication of the approval event, and the process initiation message.

In some embodiments, the settlement event message comprises a process or workflow case (e.g., an insurance claim) identifier, a recipient, a value associated with the recipient, and a status indicator of the settlement event.

In some embodiments, the process initiation message comprises a beneficiary name, a beneficiary identification number, a counterparty account identifier, amount, a process identifier, a process status, and a creation date.

In some embodiments, generating the virtual payment instrument includes receiving, by a financial institution, the settlement event message. The financial institution may generate a virtual payment instrument based on the settlement event message. The financial institution may record, on the second distributed ledger, an identifier of the virtual payment instrument. The financial institution may assign a value to the virtual payment instrument/instrument based on the approval event.

In some embodiments, the method may include funding the virtual payment instrument based on the value assigned. The method may further include settling a transaction, using the virtual payment instrument, with one or more recipients based on the approval event, the settlement event.

In some embodiments, the method may include monitoring, the first distributed ledger for an indication of an business process and approval events. In some embodiments, the method may include polling the first distributed ledger by the smart contract. In some embodiments, the method may include detecting an entry written to the first distributed ledger that includes one or more approvals and a complete status identifier.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Embodiments are directed to systems and methods for complex process flow approval using distributed ledgers. For example, embodiments may leverage the use of distributed ledgers, smart contracts, and supporting technologies to initiate and complete complex process flows. Embodiments may address issues in processing a complex process flow and related settlement processing.

Referring now to the figures,FIG.1depicts a system for management of complex process approval flows using multiple distributed ledgers is disclosed according to certain embodiments of the present disclosure. System100may include first service provider102, second service provider104, third service provider106, a process ledger108, a settlement ledger110, and a financial institution112. As one of skill in the art will appreciate, whileFIG.1depicts three service providers, any number of service providers can be implemented without departing from the teachings of the present disclosure.

First service provider102may be an entity that interfaces with a user, such as by a mobile application executed on a mobile device. The first service provider102may provide the user with a service based on an agreement between the user and the first service provider102. The first service provider102may initiate an approval process on behalf of or at the request of the user based on the interaction of the first service provider102and the user. The first service provider102may communicate an initiation message to other components of system100including the process ledger108.

The second service provider104may be a different entity that interfaces with a user, such as by a mobile application executed on a mobile device (e.g., telemedicine application) or that in a physical interaction to provide medical care. The second service provider104may provide the user with a service based on an agreement between the user and the second service provider104. The second service provider104may generate an invoice or settlement request on behalf of user based on the interaction of the second service provider104and the user. The second service provider104may determine a value of the invoice or settlement based on a pre-determined or dynamic agreement according to the medical care provided. In one example, the second service provider104may generate an initiation message to the first service provider102including the amount of the invoice or the settlement.

The third service provider106may be a different entity that provides access to a medical facility for a user during a physical interaction with the second service provider104. The third service provider106may provide the user with access to a particular physical or electronic facility based on an agreement between the user and the third service provider106or an agreement between the second service provider104and the third service provider106. The third service provider106may generate an invoice or settlement request on behalf of user based on the facility accessed by the user. The third service provider106may determine a value of the invoice or settlement based on a pre-determined or dynamic agreement according to the medical facility accessed. In one example, the third service provider106may generate an initiation message to the first service provider102including the amount of the invoice or the settlement.

The process ledger108may be a distributed ledger such as Ethereum, Hyperledger Fabric, R3 Corda, or Quorum. The process ledger108may record transactions of a complex process flow from the first service provider102, second service provider104, or third service provider106. The process ledger108may be used to store information relating to the services provided by the first service provider102, second service provider104, or third service provider106. In one example, financial institution112may provision access to the process ledger108.

The settlement ledger110may be a distributed ledger such as Ethereum, Hyperledger Fabric, R3 Corda, or Quorum. The settlement ledger110may record transactions of a complex process flow from the first service provider102, second service provider104, or third service provider106, and the financial institution112. The settlement ledger110may be used to store information relating to the patient and transaction data associated with the complex process flow. In one example, financial institution112may provision access to the process ledger108. The financial institution may encrypt or deny access to particular blocks or information written to the second distributed ledger (e.g., personal identifiable information, patient medical care data, etc.).

In some embodiments, the financial institution112may send and receive communications from the first service provider102, second service provider104, third service provider106, process ledger108, or settlement ledger110. The financial institution112may include one or more integrated smart contracts to provide an immutable chain of process status, approval events, settlement events, and the like.

WhileFIG.1is described with service providers that communicate, it should be understood that the system ofFIG.1may be configured to have independent service providers such as a process management ledger with isolated service providers such that each may have independent processes such as an aviation process, a logistics process, a hospitality process, and the like.

FIG.2depicts a system for management of a healthcare claim approval process using multiple distributed ledgers is disclosed according to certain embodiments of the present disclosure. System200may include insurance provider202, healthcare provider204, medical facility provider206, a smart contract208, a card issuer210, a merchant service212, and a treasury service214.

The insurance provider202may be a company or application that interfaces with a user to provide insurance services. Examples of insurance services includes providing the user an interface, such as by a mobile application executed on a mobile device to send and receive information from the insurance provider202. The user may use the mobile application to initiate an insurance claim filing, receive notifications of status for the claim approval process, or respond to requests for information submitted to the insurance provider from other components of system200.

The healthcare provider204may be a company or application that interfaces with a user to provide healthcare services to the user. Examples of healthcare services includes providing the user with in-person medical treatment, telehealth treatment, or other medical procedures. In some cases, the healthcare services provided by healthcare provider204may be provided within a medical facility, such as a hospital, doctor's office, or the like. The healthcare provider204may provide the healthcare services to the user upon authentication of an insurance account, receipt of a deposit amount or deductible payment, or some other requirements imposed on the user by the healthcare provider204.

The medical facility provider206may be a company that provides the user access to a medical facility for receipt of healthcare services from healthcare provider204. Examples of medical facilities include hospitals, out-patient treatment centers, healthcare provider's office, or the like. The medical facility provider may provide medical facility access to the user upon authentication of an insurance account, receipt of a deposit amount or deductible payment, or some other requirements imposed on the user by the medical facility provider206.

The smart contract208may generate a self-executing approval process including insurance provider202, healthcare provider204, medical facility provider206, card issuer210, merchant service212, and treasury service214. The smart contract208provides trusted transactions to be carried out among the various entities of system200while reducing the processing times and approval process errors that exist in traditional approaches. The smart contract208may record approval process data on two separate distributed ledgers. The smart contract208may store service provider information on a process ledger while storing financial transaction information on a settlement ledger. The smart contract208may control access to the process ledger and the settlement ledger based on an access control policy determined by the financial institution providing the card issuer210, the merchant service212, or the treasury service214. WhileFIG.2depicts one smart contract, multiple smart contracts that are nested, or otherwise related in a complex approval process are possible. In one example implementing multiple smart contracts, each smart contract may read or record from multiple distributed ledgers and further provide an output to another smart contract or receive an output from another smart contract.

The card issuer210may provide one or more payment instruments for funding a transaction relating to the approval process. The payment instrument may include credit cards, debit cards, rewards points, loyalty points, etc. as well as access points to non-payment accounts for payment (e.g., lines of credit, such as a HELOC, mortgages, etc.), applications for secured and unsecured credit, etc. In one aspect, the card issuer may generate a virtual account based on information received during the approval process. The card issuer210may provide payment instrument information to the smart contract208.

The merchant service212may perform various functions to settle any financial transactions associated with a particular approval process. For instance, the merchant service212may authorize payment instruments, receive and process settlement of financial transactions, determining settlement values, or sending funding instructions to the smart contract208.

The treasury service214may receive funding information from the merchant services via the smart contract208and process a funds transfer from the payment instrument issued by card issuer210to one or more accounts of the insurance provider202, healthcare provider204, medical facility provider206, or a financial account associated with the user.

FIG.3depicts an example of a process for management of complex process approval flows using multiple distributed ledgers is disclosed according to certain embodiments of the present disclosure.

At step302, the process300involves generating, by a first service provider, a process initiation message based on input from a second service provider or a user. In an example, the first service provider may be an application that receives a claim filing submission from a user or from a healthcare provider that initiates a claim for medical services on behalf of the user. The first service provider may generate a process initiation message that includes metadata received from the user or the second service provider as well as metadata generated by the first service provider. For instance, the process initiation message may include details associated with the patient such as patient name, patient identification number, insurance account identifier, and claim amount. The process initiation message may further include a claim identifier, a claim status, and a creation date.

At step304, the process300involves recording, on a first distributed ledger, the process initiation message. Continuing with the previous example, the first service provider may communicate the process initiation message to the smart contract. The smart contract may record the process initiation message on the process ledger. The smart contract may assign an approval process to one or more approving entities as described with regard toFIGS.1-2. The smart contract may make available to the one or more approving entities, one or more blocks of the first distributed ledger that are associated with the process initiation message. In some embodiments, the first distributed ledger may be customizable based on a particular industry associated with the approval process, particular combination of approving entities, or a number of steps in the approval process. For instance, the first distributed ledger may be also called a process distributed ledger that is unique to the particular approval process associated with the first distributed ledger. In other embodiments, multiple instances of the first distributed ledger can provide multiple parallel approval processes.

At step306, the process300involves monitoring, by a smart contract, the first distributed ledger for an indication of an approval event associated with the process initiation message. The smart contract may notify the one or more approving entities of an approval task. After each of the one or more approving entities has completed the assigned approval task, the smart contract may update the status of the approval process on the first distributed ledger. Upon completion of all assigned tasks, the smart contract may determine that the approval process is complete. For instance, the smart contract may poll the entries that are written to the first distributed ledger or detect that a new entry is being written to the first distributed ledger.

At step308, the process300involves generating, by the first service provider, a settlement event based on the indication of the approval event. As described with regard to step306, the smart contract may determine that the approval process is completed by detecting that all assigned tasks as completed. The smart contract may notify the first service provider that the approval process is completed and a settlement event may be generated. The first service provider may generate a settlement event that includes the claim identifier, recipient, value associated with the recipient, and a status indicator. In one example, the smart contract may detect that all assigned tasks are completed by detecting that the number of pending assigned tasks is zero.

At step310, the process300involves recording, on the first distributed ledger, the settlement event. The first service provider may record the settlement associated with the approval event to the first distributed ledger and include settlement details as described above.

At step312, the process300involves communicating a settlement event message to a second distributed ledger. In one example, the smart contract may record the settlement event on the second distributed ledger and make the settlement event available to a card issuer, a merchant service, or a treasury service. The smart contract may copy the settlement event from the first distributed ledger to the second distributed ledger. In other examples, the smart contract may generate a settlement event that includes a portion of the settlement event from the first distributed ledger and additional settlement parameters such as financial institution, insurance account, settlement values, and the like. In some embodiments, the second distributed ledger may be shared by multiple industries associated with various approval processes, multiple types of approving entities, or the like. For instance, the second distributed ledger may be shared between multiple instances of smart contracts with a first distributed ledger. In these embodiments, the second distributed ledger may be called a settlement ledger for multiple process ledgers.

At step314, the process300involves generating, based on the settlement event message, a virtual payment instrument associated with the settlement event message, the indication of the approval event, and the process initiation message. The card issuer may provision a virtual payment instrument associated with a value of the settlement. The merchant service may authorize a transaction having a value that is associated with the settlement. The treasury service may provide a funding event to one or more recipient accounts associated with the insurance provider, the healthcare provider, or the medical facility provider.

FIG.4depicts an example of computing device400according to certain embodiments of the present disclosure. The implementation of computing device400could be used for one or more of financial institution112. The depicted example of the computing device400includes a processor403coupled to a memory406. The processor403executes computer-executable program code stored in memory406, such as software programs415and stores program-related information in data store403. The processor403and the memory406may be coupled by a bus409. In some examples, the bus409may also be coupled to one or more network interface devices (not shown).

Although several embodiments have been disclosed, it should be recognized that these embodiments are not exclusive to each other, and certain elements or features from one embodiment may be used with another.

Hereinafter, general embodiments of implementation of the systems and methods of the invention will be described.