DISTRIBUTED LEDGER SYSTEM FOR STANDBY GUARANTEE RESOURCES

BACKGROUND

In multiple party standby guarantee resource applications, submissions, and approvals each of the parties require accurate real-time notifications of the standby guarantee resource approval or distribution. Furthermore, authentication access to various specifics within the standby guarantee resource need to be monitored for appropriate access to information. As a result, there exists a need for an application, submission, and approval ledger with authentication key adaptability.

BRIEF SUMMARY

The following presents a simplified summary of one or more embodiments of the invention in order to provide a basic understanding of such embodiments. This summary is not an extensive overview of all contemplated embodiments, and is intended to neither identify key or critical elements of all embodiments, nor delineate the scope of any or all embodiments. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that is presented later.

The invention comprises a designed trade finance digital solution for the automation of standby guarantee resource utilizing block chain distributed ledger technology to provide full transactional transparency to all parties, enforcement of configurable rules and contractual terms via smart contracts, automated routing/business rules, integration to corporate and financial institution applicant/beneficiary directories, permissioning processing, entitlement, and authentication. The system provides full end to end transaction flows, the operational model for the distributed ledger, enhanced security and automation as well as interoperability between clouds and use of APIs and UIs to increase member adoption and includes foundational infrastructure for the addition of other trade finance instruments to the distributed ledger network.

Embodiments of the invention relate to systems, methods, and computer program products for standby guarantee resource generation and processing, the invention comprising: generating a block chain network for standby guarantee resource generation and processing; identifying one or more parties of a transaction and allow access to a distributed ledger associated with the standby guarantee resource generation and processing; identifying a request for the standby guarantee resource and generate one or more blocks on a distributed ledger based on the request; presenting the request to one or more parties on the block chain network based on authorization access; allowing processing of the standby guarantee resource via data distribution from the one or more parties; and providing real-time enforcement of configurable rules and contractual terms via distributive ledger visualization of the standby guarantee resource.

In some embodiments, the block chain network provides transparency for all parties of the transaction for real-time enforcement of configurable rules and contractual terms via smart contract and routing integration.

In some embodiments, allowing processing of the standby guarantee resource via data distribution from the one or more parties further comprises generation of an application for the standby guarantee resource from a resource distribution entity for applicant/beneficiary completion and matching information on the application to documentation generated from the applicant/beneficiary and distributed via the distributed ledger.

In some embodiments, the invention further comprises identifying an upcoming expiration of the standby guarantee resource and providing communication of an upcoming expiration for automatic extension generation via the distributed ledger.

In some embodiments, identifying one or more parties of a transaction and allow access to a distributed ledger further comprises onboarding and off boarding of parties, wherein parties are identified as entities required for processing and approving the standby guarantee resource or third parties associated with a transaction with an applicant/beneficiary wherein the transaction includes the standby guarantee resource.

In some embodiments, the standby guarantee resource further comprises a standby letter of credit for an entity.

The features, functions, and advantages that have been discussed may be achieved independently in various embodiments of the present invention or may be combined with yet other embodiments, further details of which can be seen with reference to the following description and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described embodiments of the invention in general terms, reference will now be made to the accompanying drawings, wherein:

FIG. 1A provides centralized database architecture environment, in accordance with one embodiment of the present invention;

FIG. 1B provides a high level block chain system environment architecture, in accordance with one embodiment of the present invention;

FIG. 2A provides a high level process flow illustrating node interaction within a block chain system environment architecture, in accordance with one embodiment of the present invention;

FIG. 2B provides a detailed process flow illustrating node interaction within a block chain system environment architecture, in accordance with one embodiment of the present invention;

FIG. 3A provides a high level process map illustrating high level process map illustrating standby guarantee resource request and deployment, in accordance with one embodiment of the present invention;

FIG. 3B provides a high level process map illustrating standby guarantee resource request and deployment, in accordance with one embodiment of the present invention;

FIG. 3C provides a high level process map illustrating components and blocks of network for standby guarantee resource request and deployment, in accordance with one embodiment of the present invention;

FIG. 4 provides a process map illustrating distributed ledger generation for standby guarantee resource generation, in accordance with one embodiment of the present invention;

FIG. 5 provides a detailed process map authentication for access to the distributed ledger data based on roles, in accordance with one embodiment of the present invention;

FIG. 6 provides a detailed process map illustrating standby guarantee resource generation and approval, in accordance with one embodiment of the present invention;

FIG. 7 provides a detailed process map illustrating standby guarantee resource amendments, in accordance with one embodiment of the present invention;

FIG. 8 provides a detailed process map illustrating standby guarantee resource renewal, in accordance with one embodiment of the present invention; and

FIG. 9 provides a standby guarantee resource system environment, in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to elements throughout. Where possible, any terms expressed in the singular form herein are meant to also include the plural form and vice versa, unless explicitly stated otherwise. Also, as used herein, the term “a” and/or “an” shall mean “one or more,” even though the phrase “one or more” is also used herein.

A “standby guarantee resource” as used herein may refer to a standby letter of credit. In some embodiments, the standby guarantee resource may include a guarantee or promise of resources issued by a resource distribution entity, such as a financial institution, on behalf of an applicant/beneficiary as a payment of last resort should the applicant/beneficiary desire the resources for fulfillment of a contractual commitment with a third party. The standby guarantee resource is a good faith business transaction sign for proof applicant/beneficiary credit quality requiring a review of applicant/beneficiary resource management by a resource distribution entity and generation of a letter for the third party. A member, as used herein, may include any party associated with the standby guarantee resource, this may include applicants, beneficiaries, issuing institutions, confirming institutions, operators, and the like associated with the standby guarantee resource.

Furthermore, as used herein the term “applicant/beneficiary device” or “mobile device” may refer to mobile phones, personal computing devices, tablet computers, wearable devices, and/or any portable electronic device capable of receiving and/or storing data therein. An “applicant/beneficiary” may be an individual or business requesting or applying for a standby guarantee resource, such as a buyer, supplier, or the like. A member may be any entity or individual associated with the standby guarantee resource transaction, this may include the applicant/beneficiary, issuing financial institution, advising financial institution, third party entities, or the like.

“Block chain” as used herein refers to a decentralized electronic ledger of data records which are authenticated by a federated consensus protocol. Multiple computer systems within the block chain, referred to herein as “nodes” or “compute nodes,” each comprise a copy of the entire ledger of records. Nodes may write a data “block” to the block chain, the block comprising data regarding a transaction. In some embodiments, only permissioned nodes may write transactions to the block chain. In other embodiments, all nodes have the ability to write to the block chain. In some embodiments, the block may further comprise a time stamp and a pointer to the previous block in the chain. In some embodiments, the block may further comprise metadata indicating the node that was the originator of the transaction. In this way, the entire record of transactions is not dependent on a single database which may serve as a single point of failure; the block chain will persist so long as the nodes on the block chain persist. A “private block chain” is a block chain in which only authorized nodes may access the block chain. In some embodiments, nodes must be authorized to write to the block chain. In some embodiments, nodes must also be authorized to read from the block chain. Once a transactional record is written to the block chain, it will be considered pending and awaiting authentication by the permissioned nodes in the block chain.

A “block” as used herein may refer to one or more records of a file with each record comprising data for transmission to a server. In some embodiments, the term record may be used interchangeably with the term block to refer to one or more transactions or data within a file being transmitted.

Embodiments of the present invention address these and/or other needs by providing an innovative system, method and computer program product for block chain based distributed ledger system for standby guarantee resource applications, submissions, and approvals utilizing private key and authentication for party visualization.

The invention includes members entering via APIs and UIs. Each member may be at a different level of access of data or different type of authentication based on the type of member. The types of members may include buyers, suppliers, issuing financial institutions, advising financial institutions, or the like. An applicant/beneficiary or applicant may apply for a standby guarantee resource which triggers the system for smart contract generation and deployment. The triggering event of submission of the application allows for members to access the private block chain via UI from entity legacy systems for completion of the necessary steps for the standby guarantee resource. The system may further onboard new members to the block chain network based on new applicant/beneficiary request, key generation, and installation of software packaging. The system then requires member approval for new member onboarding. Once the members log into the network and authenticate and authorize to the network, the system may allow for approval for submission to the ledger. The application may then be broadcasted to the other nodes on the ledger that, based on their level, need to see the application in its current status. In this way, at each step of the standby guarantee resource processing, only the nodes that need to perform a function at that processing point gain access to the documentation on the distributed ledger for completion of the task. After broadcasting a consensus of the members must be generated for the issuer to approve or deny the transaction.

Furthermore, the blocks within each file can only be transmitted to a select group of members depending on their role within the generation, completion, or utilization of the standby guarantee resource. As such, providing specific authentication and access to data based on the individual required role within the standby guarantee resource.

Embodiments of the invention also provide a system for distributing of transaction data associated with the requesting, generating, completing, and utilizing a standby guarantee resource within a private block chain. In some embodiments, each of the nodes on the private block chain are responsible for performing one or more functions to process the transaction. In particular, each node monitors the block chain for blocks that are critical to perform its task while being blocked from or otherwise not being able to visualize the blocks that are not relevant. Upon discovering a relevant block, the node performs its designated functions to process the transaction, i.e. the blocks within the block chain trigger the nodes to perform their functions. Once a block has been authenticated, a node may rely on the data record stored therein without utilizing a complex reconciliation system to confirm the data's integrity. By using the block chain to control the workflow of the transaction, the system may avoid data errors resulting from failure in communications amongst nodes and prevents the need for computing resource-intensive data reconciliation processes.

Embodiments of the invention also provide a system for authorizing block chain transactions by distributed ledger keys. In such an embodiment, each block comprises a transaction record and an authorization key, indicating the originating node (the sender) of the transaction. The nodes within the private block chain comprise a “white list,” comprising a list of authorized senders of the transaction. In this way, a receiving node will only process a transaction in the block chain if the sender is one of the authorized senders on the white list; otherwise, the node rejects the transaction, thereby increasing the security of transactions within the system. In some embodiments, the node may write a rejection block to the block chain.

FIG. 1A illustrates a centralized database architecture environment 300, in accordance with one embodiment of the present invention. The centralized database architecture comprises multiple nodes from one or more sources and converge into a centralized database. The system, in this embodiment, may generate a single centralized ledger for data received from the various nodes. The single centralized ledger for data provides a difficult avenue for allowing access and reviewing a block of a data as it moves through the various applications.

FIG. 1B provides a general block chain system environment architecture 400, in accordance with one embodiment of the present invention. Rather than utilizing a centralized database of data for instrument conversion, as discussed above in FIG. 1A, various embodiments of the invention may use a decentralized block chain configuration or architecture as shown in FIG. 1B in order to facilitate the validation or failure location identification for file transmission. Such a decentralized block chain configuration ensures accurate mapping and tagging of blocks within a files during or after the transmission. Accordingly, a block chain configuration may be used to maintain an accurate ledger of files and the processing of transmission of the files by generation of building of one or more blocks for each file of the transmission. In this way, building a traceable and trackable historic view of each file transmission for failure location identification.

A block chain is a distributed database that maintains a list of data blocks, such as real-time resource availability associated with one or more accounts or the like, the security of which is enhanced by the distributed nature of the block chain. A block chain typically includes several nodes, which may be one or more systems, machines, computers, databases, data stores or the like operably connected with one another. In some cases, each of the nodes or multiple nodes are maintained by different entities. A block chain typically works without a central repository or single administrator.

A block chain provides numerous advantages over traditional databases. A large number of nodes of a block chain may reach a consensus regarding the validity of a transaction contained on the transaction ledger. As such, the status of the instrument and the resources associated therewith can be validated and cleared by one participant.

The block chain system typically has two primary types of records. The first type is the transaction type, which consists of the actual data stored in the block chain. The second type is the block type, which are records that confirm when and in what sequence certain transactions became recorded as part of the block chain. Transactions are created by participants using the block chain in its normal course of business. In some embodiments, the block chain system is closed, as such the number of permissioned in the current system are known and the system comprises primary sponsors that generate and create the new blocks of the system. As such, any block may be worked on by a primary sponsor. Applicant/beneficiary of the block chain create transactions that are passed around to various nodes of the block chain. A “valid” transaction is one that can be validated based on a set of rules that are defined by the particular system implementing the block chain.

As mentioned above and referring to FIG. 1B, a block chain system 400 is typically decentralized—meaning that a distributed ledger 402 (i.e., a decentralized ledger) is maintained on multiple nodes 408 of the block chain 400. One node in the block chain may have a complete or partial copy of the entire ledger or set of transactions and/or blocks on the block chain. Transactions are initiated at a node of a block chain and communicated to the various nodes of the block chain. Any of the nodes can validate a transaction, add the transaction to its copy of the block chain, and/or broadcast the transaction, its validation (in the form of a block) and/or other data to other nodes. In some embodiments, the nodes 408 of the system might be financial institutions that function as gateways for other financial institutions. For example, a credit union might hold the account, but access the distributed system through a sponsor node.

Various other specific-purpose implementations of block chains have been developed. These include distributed domain name management, decentralized crowd-funding, synchronous/asynchronous communication, decentralized real-time ride sharing and even a general purpose deployment of decentralized applications.

FIG. 2A provides a high level process flow illustrating node interaction within a block chain system environment architecture 500, in accordance with one embodiment of the present invention. As illustrated and discussed above, the block chain system may comprise at least one or more nodes used to generate blocks within file transmission for transmission validation or failure location identification during file transfers across servers. FIG. 2A illustrates stacks for entities associated with the standby guarantee resources block chain network. As illustrated, these stacks may include an entity stack of a financial institution 502, entity stack for client 1504, entity stack for client 2506, where client 1 and client 2 may be trade clients. In some embodiments, a stack may include an entity stack for another financial institution 508 associated with the standby guarantee resource processing. The financial institutions may be an issuing institution, a confirming institution or the like. In some embodiments, an entity stack for a company 510 may also be on the block chain network, this may be an entity such as a beneficiary, applicant, operator, or the like.

Locally, within each entity stack, the system comprises a web user interface and/or and an application programming interface (API). On the cloud layer, each entity stack that is associated with the cloud also comprises an API.

Furthermore, each stack may comprise one or more ledger nodes based on the entity role within the standby guarantee resource processing. Three ledgers are displayed in FIG. 2A and are stacked vertically across each of the entity stacks. These ledgers include a trade finance ledger, payments ledger, and a loans ledger. The entity stack financial institution system 502 comprises a ledger node in each of the trade finance ledger, payments ledger, and the loans ledger. The entity stacks of client 1 and client 2504 and 506 comprise a ledger node in trade finance ledger and in the loans ledger for communication across the block chain. Finally, the entity stack associated with the financial institution 2508 and the company 510 comprise ledgers including the trade finance ledger and the payments ledger.

In some embodiments, the plurality of computer systems are in operative networked communication with one another through a network. The network may be a system specific distributive network receiving and distributing specific network feeds and identifying specific network associated triggers. The network may also be a global area network (GAN), such as the Internet, a wide area network (WAN), a local area network (LAN), or any other type of network or combination of networks. The network may provide for wireline, wireless, or a combination wireline and wireless communication between devices on the network.

In some embodiments, the computer systems represent the nodes of the private block chain. In such an embodiment, each of the computer systems comprise the private block chain, providing for decentralized access to the block chain as well as the ability to use a consensus mechanism to verify the integrity of the data therein. In some embodiments, an upstream system and a downstream system are further operatively connected to the computer systems and each other through the network. The upstream system further comprises a private ledger and the private block chain. The downstream system further comprises the private block chain and an internal ledger, which in turn comprises a copy of the private ledger.

In some embodiments, a copy of private block chain may be stored on a durable storage medium within the computer systems or the upstream system or the downstream system. In some embodiments, the durable storage medium may be RAM. In some embodiments, the durable storage medium may be a hard drive or flash drive within the system.

FIG. 2B provides a detailed process flow illustrating node interaction within a block chain system environment architecture 550, in accordance with one embodiment of the present invention. As illustrated an applicant, issuer, beneficiary, and advisor are present in this standby guarantee resource processing. FIG. 2B illustrates system workflow and the mapping of requirements to system design. As illustrated, the process 550 is initiated by the creation of a standby guarantee resource, as illustrated in block 552. Next, the standby guarantee resource is reviewed, as illustrated in block 554. The standby guarantee resource is then signed and submitted as illustrated in block 556. Via the members block chain nodes, all parties may visualize the processing of the standby guarantee resource via notifications and updates to the block chain. The signed and submitted standby guarantee resource may be posted to the block chain and be visible by the issuer, via the issuer block chain node 560. The issuer may verify the application, as illustrated in block 562. Next, as illustrated in block 564, the issuer may approve the application for standby guarantee resource. Subsequently the issuer may sign and submit the standby guarantee resource application, as illustrated in block 566. The standby guarantee resource may then be submitted to the advisor via the advisor block chain node 568. The beneficiary may also visualize and confirm the processing of the standby guarantee resource via the beneficiary block chain node 570.

FIG. 3A provides a high level process map illustrating high level process map illustrating standby guarantee resource request and deployment 120, in accordance with one embodiment of the present invention. As illustrated in block 122, the process 120 is initiated by receiving an application submission of request for standby resource guarantee. The invention comprises a designed trade finance digital solution for the automation of standby guarantee resource utilizing block chain distributed ledger technology to provide full transactional transparency to all parties, enforcement of configurable rules and contractual terms via smart contracts, automated routing/business rules, integration to corporate and financial institution applicant/beneficiary directories, permissioning processing, entitlement, and authentication. The system provides full end to end transaction flows, the operational model for the distributed ledger, enhanced security and automation as well as interoperability between clouds and use of APIs and UIs to increase member adoption and includes foundational infrastructure for the addition of other trade finance instruments to the distributed ledger network.

Next, as illustrated in block 123, the process 120 continues by further onboarding new members to the block chain network based on new applicant/beneficiary request, key generation, and installation of software packaging. Along with onboarding, the system may authenticate and/or authorize members into the block chain network. The members may be authenticated and control of access may be performed via verifying addresses of the members. Smart contracts can be written to check for access for every request, applicant/beneficiary credentials and addresses may be stored in a directory service. The system then requires member approval for new member onboarding, based on member consensus. Once the members log into the network and authenticate and authorize to the network, the system may allow for approval for submission to the ledger.

As illustrated in block 124, the process 120 continues by creating a member block chain distributed ledger with smart contracts for applicant standby guarantee resource processing. As illustrated in block 126, the system allows for member access to the distributed ledger via an applicant/beneficiary interfaces associated with entity legacy systems. In this way, the system allows for applicant/beneficiary access to the block chain network via legacy systems. As such, the system takes over a proton of legacy system coding for display and integration of the block chain network for member visualization of documentation on the block chain.

As illustrated in block 130, the process 120 continues by approving request for submission to distributed ledger and the application may then be broadcasted to the other nodes on the ledger that, based on their level, need to see the application in its current status. In this way, at each step of the standby guarantee resource processing, only the nodes that need to perform a function at that processing point gain access to the documentation on the distributed ledger for completion of the task. After broadcasting a consensus of the members must be generated for the issuer to approve or deny the transaction. Finally, as illustrated in block 132, the process 120 is finalized by processing the standby guarantee resource via member reviews and approvals via member consensus. Embodiments of the invention also provide a system for distributing of transaction data associated with the requesting, generating, completing, and utilizing a standby guarantee resource within a private block chain. In some embodiments, each of the nodes on the private block chain are responsible for performing one or more functions to process the transaction. In particular, each node monitors the block chain for blocks that are critical to perform its task while being blocked from or otherwise not being able to visualize the blocks that are not relevant. Upon discovering a relevant block, the node performs its designated functions to process the transaction, i.e. the blocks within the block chain trigger the nodes to perform their functions. Once a block has been authenticated, a node may rely on the data record stored therein without utilizing a complex reconciliation system to confirm the data's integrity. By using the block chain to control the workflow of the transaction, the system may avoid data errors resulting from failure in communications amongst nodes and prevents the need for computing resource-intensive data reconciliation processes.

FIG. 3B provides a high level process map illustrating standby guarantee resource request and deployment 100, in accordance with one embodiment of the present invention. As illustrated in block 102, the process 100 is initiated by generating a block chain network with distributed ledger for the applicant/beneficiary standby guarantee resource generation and completion. The block chain may be a private block chain with keyed access for specific data points and blocks within the distributed network.

Next, as illustrated in block 106, the process 100 continues to identify an applicant/beneficiary requesting a standby guarantee resource generation and the system may generate a block chain associated with the request. In this way, the applicant/beneficiary may be an individual or an entity, such as a business or the like that may transacting with another party. As good faith or part of the transaction, the applicant/beneficiary may require or desire to obtain a standby guarantee resource from a financial institution for the transaction. As such, the system may identify the applicant/beneficiary requesting the standby guarantee resource from a financial institution. Upon identification of the request, the system may generate a private block chain associated with the request and the development of the standby guarantee resource.

As illustrated in block 108, the process 100 continues by transmitting the request for the standby guarantee resource to the block chain network for the resource distribution entity for access to data for approval of the standby guarantee resource. This may include documents, account information, financial information, and the like associated with the applicant/beneficiary. This data may be posted to the block chain within the distributed network for financial institution server review for approval of the standby guarantee resource. As such, as illustrated in block 110, the process 100 continues by allowing the resource distribution entity to perform the process of approving or denying the standby guarantee resource. Upon approval, the system generates a block on the distributed ledger illustrating the approval or denial of the standby guarantee resource.

Finally, as illustrated in block 112, the process 100 is finalized by allowing the appropriate third parties to gain access to one or more blocks on the distributed ledger. The system may only allow access to specific data on the block chain network based on authentication. In this way, individuals may only have access to data on the block chain network associated with their role and/or the data that they are authorized to gain access.

FIG. 3C provides a high level process map illustrating components and blocks of network for standby guarantee resource request and deployment 150, in accordance with one embodiment of the present invention. As illustrated there are two members, member 2152 and member 1156. Each of the members of the network are designated a block chain node 154 and 158. The block chain nodes allow the members to access the network for standby guarantee resource applications and processing by authenticating and accessing through the application. The operator may comprise a centralized location of all responsibilities that can access through multiple locations. The operator module may include business logic and workflow applications 160 and notification engines 164. These applications may block and distribute data to the various members based on the member level. In some embodiments, each of the nodes on the private block chain are responsible for performing one or more functions to process the transaction. In particular, each node monitors the block chain for blocks that are critical to perform its task while being blocked from or otherwise not being able to visualize the blocks that are not relevant. Upon discovering a relevant block, the node performs its designated functions to process the transaction, i.e. the blocks within the block chain trigger the nodes to perform their functions. Once a block has been authenticated, a node may rely on the data record stored therein without utilizing a complex reconciliation system to confirm the data's integrity. By using the block chain to control the workflow of the transaction, the system may avoid data errors resulting from failure in communications amongst nodes and prevents the need for computing resource-intensive data reconciliation processes.

As illustrated the UI/APP application 168 allows the operator module to introduce the UI/APP into member legacy programs for member access to display documents for the standby guarantee resource for the applicant. The authentication and authorization application 162 approves member access to the network and authenticates the members for access to documents on the distributed ledger. The key management application 166 and the certificate management application 170 manages the keys and certificates for accessing the distributed network.

As further illustrated, the operator module may further include smart contract applications 172 for triggering of smart contract deployment for configurable rules compliance of the documents associated with the standby guarantee resource processing. The operator module may also comprise an application code application 174, key enclave application 182, certificate authority application 184. The operator module may further comprise software and hardware for running the block chain network. This may include network configurations 176, software 178, and developmental operations 180.

FIG. 4 provides a process map illustrating distributed ledger generation for standby guarantee resource generation 700, in accordance with one embodiment of the present invention. As illustrated, FIG. 4 includes an applicant/beneficiary, an issuing/confirming entity such as a resource distribution entity, and an operator. The applicant/beneficiary may be an entity or individual requesting the standby guarantee resource, the issuing/confirming entity may be a resource distribution entity such as a financial institution granting or approving the letter, and the operator may be transacting with the applicant/beneficiary for completion of one or more business transactions that may include the standby guarantee resource.

As illustrated in block 701, the process 700 is initiated by generation of a block chain network including a distributed ledger with an initial block chain node.

As illustrated in block 712, the process 700 includes allowing access to applicant/beneficiary, issuing/confirming entity, and third parties associated with the standby guarantee resource to the block chain. In this way, the system may allow, via authentication keys, access to one or more data points within the block chain. The portion of the data authorized for viewing from the individuals attempting to gain access is limited to only the data the individual may need based on his/her position and role with respect to the standby guarantee resource.

As illustrated in block 702, the process 700 is initiated by the applicant/beneficiary creating and reviewing a standby guarantee resource application. In this way, the applicant/beneficiary may be transacting with an operator and as a part of the transaction or in good faith, the applicant/beneficiary may desire a standby guarantee resource. The standby guarantee resource application may include compiling documents and other data including applicant/beneficiary resource data, applicant/beneficiary personal information, and the like. Once the applicant/beneficiary generates the appropriate documents and completes the application for the standby guarantee resource, the applicant/beneficiary may sign the standby guarantee resource application, as illustrated in block 703.

The created application and compiled data associated with the application may all be updated on the distributed ledger as an initial node on the block chain, as illustrated in block 704. In this way, the data and application are posted to the block chain for authorized entity visualization.

Using the information located on the distributed ledger, the issuing/confirming entity may process the application to determine approval or denial of the application. As illustrated in block 706, the issuing/confirming entity may verify and approve the standby guarantee resource. The issuing/confirming entity may continue by signing the standby guarantee resource application, as illustrated in block 707. Upon approval of the standby guarantee resource application by the issuing/confirming entity, the system may update the distributed ledger and add a block chain node to the block chain, as illustrated in block 708.

Next, the operator may gain access to the distributed ledger. As illustrated in block 710, the operator may be allowed authorized view of the approved standby guarantee resource. Upon review by the operator, the system may finalize the distributed ledger as illustrated in block 712.

The system operator system may comprise business logic and work flow, authentication and authorization, key management, notification engine, applications, certification management, and the like. Furthermore, in some embodiments, the system may comprise smart contracts allowing smart contractually generations between the applicant/beneficiary and third parties and application codes for generation and updating of code for the application in real-time. Furthermore, the system includes a network configuration, additional software, and development operations for real-time modifications or updates to the standby guarantee resource completion. In some embodiments, the smart contracts may be written for checking access for every request for data on the distributed networks. Furthermore, the authorization to the individuals to gain access to one or more portions of data on the distributed network may include a hierarchy authorization level determination with the smart contract role identification to provide authentication and access to the appropriate data.

FIG. 56 provides a detailed process map authentication for access to the distributed ledger data based on roles 800, in accordance with one embodiment of the present invention. As illustrated, the entities 801 associated with the standby guarantee resource generation and completion may include the applicant/beneficiary 802, the issuing/confirming entity 804, and one or more operators 806. As illustrated, each of the applicant/beneficiary 802, issuing/confirming entity 804, and operators 806 entities may include one or more individuals associated with each entity. Each individual within the various entities may have a specific role, as illustrated in block 808 the roles for completing one or more stages of the standby guarantee resource completion are outlined. The roles are outlined in block 808 for completion by various individuals within the entities. The roles of each individual are defined centrally by the system and implemented by a block chain operator. Individuals can extend roles to create additional sub-roles within the environment.

Based on the roles of each individual and/or the entity the individual is associated with, the system may authorize access to the data on the distributed ledger for the individual, as illustrated in block 810. The distributed ledger the individual may have access to is illustrated in block 812. In some embodiments, the data or messages on the network may be private. In other embodiments, the data or messages on the network may be visible to everyone. The visible messages are shared globally across the entire block chain, where a private key is owned by all individuals associated with the block chain. The private messages are generated and each node gets a copy of the message. However, only the nodes that need to view the message may be sent the private key for gaining access to the message.

In some embodiments, the system may dynamically add or remove nodes from the block chain. In some embodiments, for adding nodes to the block chain the system may review the additional node and transmit certificates for the additional node to join the block chain network. In some embodiments, a consensus is achieved for updating the block chain to include the additional node via voting to approve the new member to the node. In some embodiments, the system may remove current nodes from the block chain network based on need, fault tolerances, behavior, or the like.

FIG. 6 provides a detailed process map illustrating standby guarantee resource generation and approval 600, in accordance with one embodiment of the present invention. As illustrated in block 602, the process 600 is initiated by a beneficiary requesting a standby guarantee resource from an applicant. This request may be from an applicant/beneficiary to a resource distribution entity based on a transaction between an applicant/beneficiary and a third party.

As illustrated in block 604, the process 600 continues by submitting the request for the standby guarantee resource issuance. This may be requested to an issuer, such as a resource distribution entity, for example a financial institution. The beneficiary may review and approve the standby guarantee resource and the issuing financial institution may complete a review and approval process, as illustrated in block 606. In this way, the resource distribution entity may review an application, data associated with the applicant/beneficiary, accounts associated with the applicant/beneficiary, stocks associated with the applicant/beneficiary, assets associated with the applicant/beneficiary, and the like to determine an approval or denial for the standby guarantee resource. As illustrated in block 608, the beneficiary and/or the issuer may approve or deny the application for the standby guarantee resource. If the application is denied it may be returned with comments, as illustrated in block 610. In some embodiments, the resource distribution system may deny the approval of the application. In this way, the system notifies the applicant/beneficiary via the distributed network and allows the applicant/beneficiary an opportunity to re-submit the application including any documentation to the distributed network to fix any deficiencies in the application. The applicant may resubmit the standby guarantee resource with revisions, as illustrated in block 612, and the process 600 may continue back at block 604. If no resubmission is made in block 612, the process 600 is discontinued, as illustrated in block 614.

If approval is granted in block 608, the process 600 continues sending the standby guarantee resource to the beneficiary for documentation, as illustrated in block 616. Next, as illustrated in block 618, the process 600 continues to compare documents to the original submission. Upon approval of the application for the standby guarantee resource, the resource distribution entity may request additional documentation to confirm the data associated with the application. The resource distribution entity via the distributed network may post a request for additional documentation for comparison to the original application. The distributed network allows the resource distribution entity to review and compare the documentation to the original application to confirm the application. The system may confirm if the documents are the same, as illustrated in block 620. If the documents are not the same, the system may inform the issuing resource distribution and remediate the discrepancy, as illustrated in block 622. The system may revert the process back to block 618 for processing. If the documents are identified as the same in block 620, the process 600 continues by standby guarantee resource issuance completion, as illustrated in block 624. In this way, the resource distribution entity issues a compliance for the standby guarantee resource and transmits the authentication of the standby guarantee resource to the distributed network for visualization of the approval by the nodes of the block chain network.

As illustrated in block 626, the process 600 continues by notifying issuance to the application, beneficiary, and advising financial institutions, along with any other members associated with the standby guarantee resource. The system may authenticate the issuance, as illustrated in block 628. If the standby guarantee resource is not authenticated, it is reviewed and updated in block 634 and reverts back to block 606 for processing. Upon authentication, the system advises on the final issuance of the standby guarantee resource, as illustrated in block 630 and notification of the final issuance of the standby guarantee resource is provided via the distributed ledger, as illustrated in block 632.

FIG. 7 provides a detailed process map illustrating standby guarantee resource amendments 650, in accordance with one embodiment of the present invention. As illustrated in block 652, the process 650 is initiated by identifying that an amendment is needed. The applicant may then submit the amendment request to the issuing resource distribution entity via the distributed network, as illustrated in block 654. The beneficiary may review and approve the amendment to the standby guarantee resource and the issuing financial institution may complete a review and approval process as well, as illustrated in block 656 and block 658. Next, as illustrated in block 660, the beneficiary and/or the issuer may approve or deny the amendment to the standby guarantee resource. If the amendment is denied it may be returned with rejection comments, as illustrated in block 662. In this way, the system notifies the applicant/beneficiary via the distributed network and allows the applicant/beneficiary an opportunity to re-submit the amendment including any documentation to the distributed network to fix any deficiencies in the amendment. As illustrated in block, 664 the applicant may resubmit the standby guarantee resource amendment with revisions and the process 650 may continue back at block 654. If no resubmission is made in block 664, the process 650 is discontinued, as illustrated in block 666.

If approval of the amendment is granted in block 660, the process 650 continues sending the standby guarantee resource with the amendment to the beneficiary for documentation, as illustrated in block 668. Next, as illustrated in block 670, the process 650 continues to compare to the approved amendment. The system may confirm that the amendment and documents are the same, as illustrated in block 672. If the amendments are not the same, the system may inform the issuing resource distribution and remediate the discrepancy, as illustrated in block 674. The system may revert the process back to block 670 for processing. If the documents are identified as the same in block 672, the process 650 continues by completing issuance of the amendment to the standby guarantee resource, as illustrated in block 676.

As illustrated in block 678, the process 650 continues by notifying issuance of the amended standby guarantee resource to the application, beneficiary, and advising financial institutions, along with any other members associated with the standby guarantee resource. The system may authenticate the issuance of the amendment, as illustrated in block 680. If the standby guarantee resource amendment is not authenticated, it is reviewed and updated in block 686 and reverts back to block 654 for processing. Upon authentication, the system advises on the final issuance of the amended standby guarantee resource, as illustrated in block 682 and notification of the final issuance of the amended standby guarantee resource is provided via the distributed ledger, as illustrated in block 684.

FIG. 8 provides a detailed process map illustrating standby guarantee resource renewal 900, in accordance with one embodiment of the present invention. As illustrated in block 902, the process 900 is initiated by identifying an approaching standby guarantee resource expiration. In some standby guarantee resource agreements an auto extension of the standby guarantee resource built into the original transaction. If there is an automatic extension, as illustrated in block 906, the extension data is posed to the distributed ledger for viewing, as illustrated in block 908.

If there is no automatic extension, the system communicates via the distributed ledger to determine if an extension is needed, as illustrated in block 910. If no extension is needed, the system posts a termination to the distributed ledger allowing all parties notification and visualization of the termination of the standby guarantee resource, as illustrated in block 912. If an extension is needed or desired by the applicant/beneficiary or a third party in block 910, the process continues by allowing amending of the standby guarantee resource, as illustrated in block 914. The system may receive a submission request for amendment of the standby guarantee resource that is directed to the resource distribution entity, as illustrated in block 916. This request is posted to the distributed ledger and provided with an encryption key for access only by the resource distribution entity. Finally, the process 900 is completed by allowing processing of the approval/denial of the standby guarantee resource and submission of the outcome to the distributed ledger for visualization by the parties.

In some embodiments, the system may provide for standby guarantee resource member onboarding, in accordance with one embodiment of the present invention. In this way, the block chain operator module may be communicating with the various current members (such as Member 1, Member 2, and Member 3) via block chain nodes.

The new applicant/beneficiary requesting onboarding may submit a request for application to the network. The applicant/beneficiary may then generate a key and share the key via certificates. The applicant/beneficiary may then receive installation package and instructions from the block chain operator module and allow the applicant/beneficiary to perform configuration parameters for the network. In some embodiments, once the applicant/beneficiary sets up the infrastructure for being a node on the block chain network, the applicant/beneficiary may send certification attestation request to the block chain operation module. The block chain operator module may distribute the new member request to the members. The members may vote to approve the applicant/beneficiary as a new member into the network. Upon consensus being achieved for the new member, the system may update the configuration. The block chain operator module may generate a new distributed ledger/block chain node for the applicant/beneficiary.

FIG. 9 provides a unique system that includes specialized servers and system communicably linked across a distributive network of nodes required to perform the functions of requesting, generating, utilizing, and deploying standby guarantee resources via a distributed ledger within a block chain network.

FIG. 9 provides a standby guarantee resource system environment 200, in accordance with one embodiment of the present invention. As illustrated in FIG. 9, the block chain distributed network system 208 is operatively coupled, via a network 201 to the applicant/beneficiary system 204, receiving server 207, other party servers 209, and to the financial institution server system 206. In this way, the block chain distributed network system 208 can send information to and receive information from the applicant/beneficiary device/sending server 204, receiving server 207, other party servers 209, and the financial institution server system 206. FIG. 9 illustrates only one example of an embodiment of the system environment 200, and it will be appreciated that in other embodiments one or more of the systems, devices, or servers may be combined into a single system, device, or server, or be made up of multiple systems, devices, or servers.

The network 201 may be a system specific distributive network receiving and distributing specific network feeds and identifying specific network associated triggers. The network 201 may also be a global area network (GAN), such as the Internet, a wide area network (WAN), a local area network (LAN), or any other type of network or combination of networks. The network 201 may provide for wireline, wireless, or a combination wireline and wireless communication between devices on the network 201.

In some embodiments, the applicant/beneficiary 202 is an individual or entity that requests a standby guarantee resource for the applicant/beneficiary and/or for a third party the applicant/beneficiary may be transacting with where the transaction may require a good faith generation of a standby guarantee resource. In some embodiments, the applicant/beneficiary 202 has an applicant/beneficiary device, such as a mobile phone, tablet, or the like that may interact with and control the distribution of files from the sending server to the receiving server 207, financial institution server system 206, or the block chain distributed network system 208. FIG. 9 also illustrates an applicant/beneficiary system 204. The applicant/beneficiary device/sending server 204 may be, for example, a server or the like in connection with an applicant/beneficiary device, such as a desktop computer, laptop, tablet, cellular telephone, or the like. The applicant/beneficiary device/sending server 204 generally comprises a communication device 212, a processing device 214, and a memory device 216. The processing device 214 is operatively coupled to the communication device 212 and the memory device 216. The processing device 214 uses the communication device 212 to communicate with the network 201 and other devices on the network 201, such as, but not limited to the financial institution server system 206, the receiving server 207, other party servers 209, and the block chain distributed network system 208. As such, the communication device 212 generally comprises a modem, server, or other device for communicating with other devices on the network 201.

The applicant/beneficiary device/sending server 204 comprises computer-readable instructions 220 and data storage 218 stored in the memory device 216, which in one embodiment includes the computer-readable instructions 220 of an applicant/beneficiary application 222. In some embodiments, the applicant/beneficiary application 222 allows an applicant/beneficiary 202 to transmit files from one server to another for processing and generation of a standby guarantee resource.

The receiving server 207 comprises the same or similar features as the applicant/beneficiary device 204 and is the server receiving the files being transmitted. Including comprising computer-readable instructions and data storage stored in the memory device, which in one embodiment includes the computer-readable instructions for one or more applications. In some embodiments, the one or more applications allow for receiving of files or blocks from one or more servers.

The other party servers 209 comprises the same or similar features as the applicant/beneficiary device 204 and is the server receiving the files being transmitted. Including comprising computer-readable instructions and data storage stored in the memory device, which in one embodiment includes the computer-readable instructions for one or more applications. In some embodiments, the one or more applications allow for receiving of files or blocks from one or more servers.

As further illustrated in FIG. 9, the block chain distributed network system 208 generally comprises a communication device 246, a processing device 248, and a memory device 250. As used herein, the term “processing device” generally includes circuitry used for implementing the communication and/or logic functions of the particular system. For example, a processing device may include a digital signal processor device, a microprocessor device, and various analog-to-digital converters, digital-to-analog converters, and other support circuits and/or combinations of the foregoing. Control and signal processing functions of the system are allocated between these processing devices according to their respective capabilities. The processing device may include functionality to operate one or more software programs based on computer-readable instructions thereof, which may be stored in a memory device.

The processing device 248 is operatively coupled to the communication device 246 and the memory device 250. The processing device 248 uses the communication device 246 to communicate with the network 201 and other devices on the network 201, such as, but not limited to the financial institution server system 206, receiving server 207, other party servers 209, and the applicant/beneficiary system 204. As such, the communication device 246 generally comprises a modem, server, or other device for communicating with other devices on the network 201.

As further illustrated in FIG. 9, the block chain distributed network system 208 comprises computer-readable instructions 254 stored in the memory device 250, which in one embodiment includes the computer-readable instructions 254 of a resource application 258. In some embodiments, the memory device 250 includes data storage 252 for storing data related to the system environment.

Embodiments of the block chain distributed network system 208 may include multiple systems, servers, computers or the like maintained by one or many entities. FIG. 9 merely illustrates one of those systems that, typically, interacts with many other similar systems to form the block chain. In some embodiments, the financial institution server system 206 may be part of the block chain. Similarly, in some embodiments, the block chain distributed network system 208 is part of the financial institution server system 206. In other embodiments, the financial institution server system 206 is distinct from the block chain distributed network system 208.

In one embodiment of the block chain distributed network system 208 the memory device 250 stores, but is not limited to, a resource application 258 and a distributed ledger 260. In some embodiments, the distributed ledger 260 stores data including, but not limited to, the block chains for standby guarantee resource requesting, generating, and completing.

In one embodiment of the invention, both the resource application 258 and the distributed ledger 260 may associate with applications having computer-executable program code that instructs the processing device 248 to operate the network communication device 246 to perform certain communication functions involving described herein. In one embodiment, the computer-executable program code of an application associated with the distributed ledger 260 and resource application 258 may also instruct the processing device 248 to perform certain logic, data processing, and data storing functions of the application.

The processing device 248 is configured to use the communication device 246 to gather data, such as data corresponding to transactions, blocks or other updates to the distributed ledger 260 from various data sources such as other block chain network system. The processing device 248 stores the data that it receives in its copy of the distributed ledger 260 stored in the memory device 250.

As illustrated in FIG. 9, the financial institution server system 206 is connected to the block chain distributed network system 208 and is associated with a financial institution network. In this way, while only one financial institution server system 206 is illustrated in FIG. 9, it is understood that multiple network systems may make up the system environment 200. The financial institution server system 206 generally comprises a communication device 236, a processing device 238, and a memory device 240. The financial institution server system 206 comprises computer-readable instructions 242 stored in the memory device 240, which in one embodiment includes the computer-readable instructions 242 of an institution application 244. The financial institution server system 206 may communicate with the block chain distributed network system 208. While the block chain distributed network system 208 may communicate with the financial institution server system 206 via a secure connection generated for secure encrypted communications between the two systems. The financial institution server system 206 may be associated with a financial institution. In some embodiments as disclosed herein a financial institution may also be referred to as a resource distribution entity.

It is understood that the servers, systems, and devices described herein illustrate one embodiment of the invention. It is further understood that one or more of the servers, systems, and devices can be combined in other embodiments and still function in the same or similar way as the embodiments described herein.

As will be appreciated by one of ordinary skill in the art, the present invention may be embodied as an apparatus (including, for example, a system, a machine, a device, a computer program product, and/or the like), as a method (including, for example, a business process, a computer-implemented process, and/or the like), or as any combination of the foregoing. Accordingly, embodiments of the present invention may take the form of an entirely software embodiment (including firmware, resident software, micro-code, and the like), an entirely hardware embodiment, or an embodiment combining software and hardware aspects that may generally be referred to herein as a “system.” Furthermore, embodiments of the present invention may take the form of a computer program product that includes a computer-readable storage medium having computer-executable program code portions stored therein. As used herein, a processor may be “configured to” perform a certain function in a variety of ways, including, for example, by having one or more special-purpose circuits perform the functions by executing one or more computer-executable program code portions embodied in a computer-readable medium, and/or having one or more application-specific circuits perform the function. As such, once the software and/or hardware of the claimed invention is implemented the computer device and application-specific circuits associated therewith are deemed specialized computer devices capable of improving technology associated with the in authorization and instant integration of a new credit card to digital wallets.

It will be understood that any suitable computer-readable medium may be utilized. The computer-readable medium may include, but is not limited to, a non-transitory computer-readable medium, such as a tangible electronic, magnetic, optical, infrared, electromagnetic, and/or semiconductor system, apparatus, and/or device. For example, in some embodiments, the non-transitory computer-readable medium includes a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), and/or some other tangible optical and/or magnetic storage device. In other embodiments of the present invention, however, the computer-readable medium may be transitory, such as a propagation signal including computer-executable program code portions embodied therein.

It will also be understood that one or more computer-executable program code portions for carrying out the specialized operations of the present invention may be required on the specialized computer include object-oriented, scripted, and/or unscripted programming languages, such as, for example, Java, Perl, Smalltalk, C++, SAS, SQL, Python, Objective C, and/or the like. In some embodiments, the one or more computer-executable program code portions for carrying out operations of embodiments of the present invention are written in conventional procedural programming languages, such as the “C” programming languages and/or similar programming languages. The computer program code may alternatively or additionally be written in one or more multi-paradigm programming languages, such as, for example, F#.

It will further be understood that some embodiments of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of systems, methods, and/or computer program products. It will be understood that each block included in the flowchart illustrations and/or block diagrams, and combinations of blocks included in the flowchart illustrations and/or block diagrams, may be implemented by one or more computer-executable program code portions. These one or more computer-executable program code portions may be provided to a processor of a special purpose computer for the authorization and instant integration of credit cards to a digital wallet, and/or some other programmable data processing apparatus in order to produce a particular machine, such that the one or more computer-executable program code portions, which execute via the processor of the computer and/or other programmable data processing apparatus, create mechanisms for implementing the steps and/or functions represented by the flowchart(s) and/or block diagram block(s).

It will also be understood that the one or more computer-executable program code portions may be stored in a transitory or non-transitory computer-readable medium (e.g., a memory, and the like) that can direct a computer and/or other programmable data processing apparatus to function in a particular manner, such that the computer-executable program code portions stored in the computer-readable medium produce an article of manufacture, including instruction mechanisms which implement the steps and/or functions specified in the flowchart(s) and/or block diagram block(s).

The one or more computer-executable program code portions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus. In some embodiments, this produces a computer-implemented process such that the one or more computer-executable program code portions which execute on the computer and/or other programmable apparatus provide operational steps to implement the steps specified in the flowchart(s) and/or the functions specified in the block diagram block(s). Alternatively, computer-implemented steps may be combined with operator and/or human-implemented steps in order to carry out an embodiment of the present invention.

While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of, and not restrictive on, the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations and modifications of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.

DISTRIBUTED LEDGER SYSTEM FOR STANDBY GUARANTEE RESOURCES

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

CROSS-REFERENCE TO RELATED APPLICATION(S)

Provisional Applications (1)