System and method for contextual messaging and information routing in distributed ledger networks

Abstract

A system and method for contextual messaging and information routing in a distributed ledger network is disclosed. In one embodiment, the method includes a distributed application executed by a sending entity node of the distributed ledger network to receive a message or message from the sending entity, identify a context for the message or message, retrieve capabilities of other nodes of the distributed ledger network, identify potential recipient entities for the message or message based on the capabilities, retrieve routing preferences for the sending entity, apply the routing preferences for the sending entity to identify the recipient entity from among the potential recipient entities, and send the message or message to a receiving node for the recipient entity using the routing preferences, and the receiving node is configured to route the message or message to the recipient entity using the routing preferences for the receiving entity.

Description

Technical Field

[0001]

[0001] Embodiments relate to contextual messaging and information routing in a distributed ledger network.

Background Art

[0002]

[0002] Distributed ledger platforms such as the Liink by J.P.Morgan (service mark) platform provide ecosystems and networks that enable collaboration, access to new capabilities, messaging, and commercialization opportunities to participants including financial institutions, corporations, and fintechs.

Summary of the Invention

[0003]

[0003] A system and method for contextual messaging and information routing in a distributed ledger network are provided. According to one embodiment, the method for contextual messaging and information routing in a distributed ledger network includes: (1) a distributed application running on a sending entity node in the distributed ledger network receiving a message or communication from a sending entity; (2) the distributed application identifying the context of the message or communication; (3) the distributed application searching for the capabilities of other nodes in the distributed ledger network; (4) the distributed application identifying a likely receiving entity for the message or communication based on the capabilities; and (5) the distributed The application may include (6) searching for routing preferences for the sending entity, (7) applying the routing preferences for the sending entity to identify a receiving entity from the prospective receiving entity, and (8) using the routing preferences to send the message or communication to a receiving node for the receiving entity, the receiving node being configured to route the message or communication to the receiving entity using the routing preferences for the receiving entity.

[0004]

[0004] In the embodiment, both context and capability are used to identify a potential receiving entity. Routing preference can be used to identify one or more receiving entities from among the potential receiving entities (for example, if there is a use case to send to one or more receivers).

[0005]

[0005] In one embodiment, the context may include the subject and / or account from the message. Routing preferences with respect to the sending entity may be based on the subject and / or account in the message.

[0006]

[0006] In one embodiment, the receiving node can be configured to apply routing preferences with respect to the sending entity node to the message.

[0007]

[0007] In one embodiment, the message can be sent to a distributed application on the receiving node.

[0008]

[0008] In one embodiment, messages can be communicated by using a transmission control protocol (TCP) / remote procedure call (RCP) or by using an authorized access route.

[0009]

[0009] According to another embodiment, the system may include a distributed ledger network and a plurality of nodes in the distributed ledger network, each node running a distributed application. The distributed application on the sending node can receive a message or communication from a sending entity, can identify the context relating to the message or communication, can look up the capabilities of other nodes in the distributed ledger network, can identify a likely receiving entity for the message or communication based on the capabilities, can look up routing preferences relating to the sending entity, can apply the routing preferences relating to the sending entity to identify a receiving entity from among the likely receiving entities, and can use the routing preferences to send the message or communication to a receiving node for the receiving entity.

[0010]

[0010] In one embodiment, the context may include the subject and / or account from the message. Routing preferences with respect to the sending entity may be based on the subject and / or account in the message.

[0011]

[0011] In one embodiment, the message can be sent to a distributed application on the receiving node.

[0012]

[0012] In one embodiment, messages can be communicated by using a transmission control protocol (TCP) / remote procedure call (RCP) or by using an authorized access route.

[0013]

[0013] According to another embodiment, a non-temporary computer-readable storage medium may include instructions stored therein, which, when read and executed by one or more computer processors, cause the one or more computer processors to perform the steps of: receiving a message or communication statement from a sending entity; identifying a context relating to the message or communication statement; searching for the capabilities of other nodes in a distributed ledger network; identifying a likely receiving entity for the message or communication statement based on the capabilities; searching for routing preferences relating to the sending entity; applying the routing preferences relating to the sending entity to identify a receiving entity from among the likely receiving entities; and using the routing preferences to send the message or communication statement to a receiving node for the receiving entity.

[0014]

[0014] In one embodiment, messages can be communicated by using a transmission control protocol (TCP) / remote procedure call (RCP) or by using an authorized access route.

[0015]

[0015] To facilitate a full understanding of the present invention, the accompanying drawings are provided herein. The drawings should not be construed as limiting the present invention, but are intended solely to illustrate various configurations and embodiments. [Brief explanation of the drawing]

[0016] [Figure 1] Figure 1 shows a system for contextual messaging and information routing in a distributed ledger network according to an embodiment. [Figure 2]Figure 2 illustrates a method for contextual messaging and information routing in a distributed ledger network according to an embodiment. [Figure 3] Figure 3 shows a computing system as an example for implementing the configuration of the present disclosure. [Modes for carrying out the invention]

[0017]

[0019] A system and method for contextual messaging and information routing in a distributed ledger network are disclosed. The context-based messaging system can route messages, communications, etc., from the sender to the receiver based on the context of the message or communications, the preferences of the sending entity and the receiving entity, etc. Examples of context include the message content, the message subject, and the account number (one or greater) in the message. The routing can be dynamic and may change depending on the content, timing, etc.

[0018]

[0020] In one embodiment, a sending entity (e.g., an organization, an individual) can identify preferences on a contextual basis for routing a message or communication to a receiving entity. For example, the sending entity can identify the context (e.g., subject, content, account(s)) and identify the receiving entity for the message or communication.

[0019]

[0021] Routing can be determined at the sending node and / or receiving node. In one embodiment, the sending node identifies the receiving node from the context, and the receiving node can then apply routing rules that may be provided by the sender and / or destination to further route the message or communication to the receiving entity.

[0020]

[0022] In another embodiment, the receiving node can implicitly issue its destination context capability through network ID setup or explicitly through context capability self-identification. The sending node can apply rules to identify the destination based on the materialized context and the context coverage of the receiving node. Routing rules can be provided by the sender based on destination context alignment.

[0021]

[0023] Referring to Figure 1, a system for context-based messaging according to one embodiment is disclosed. System 100 may include a distributed ledger network 120 which has multiple nodes 110 (e.g., node 1101, node 1102, node 1103, node 1104, ..., node 110 N ) may include each node 110 has a distributed application (dApp) 112 (for example, dApp1121, dApp1122, dApp1123, dApp1124, ..., dApp112 N ) and configuration module 114 (for example, configuration module 1141, configuration module 1142, configuration module 1143, configuration module 1144, ..., configuration module 114 N ) and ability module 116 (for example, ability module 1161, ability module 1162, ability module 1163, ability module 1164, ..., ability module 116 N ) can be included.

[0022]

[0024] dApp112 can receive messages from the users of each node 110 and route it to the destination node (e.g., from node 1101 to node 1102). dApp112 can route the message based on the context of the message, such as subject, content, account (one or more), etc. In one embodiment, dApp112 can apply the user preferences in the setting module 114 to route the message.

[0023]

[0025] The capability module 116 can store the capabilities of the node 110. The capabilities can be based on, for example, the systems supported by the node (such as payment systems, processing systems, etc.). The supported systems can be related to products such as transaction categories. In one embodiment, an entity can self-report its capabilities at the node 110, and in another embodiment, the node 110 can learn the capabilities of the entity.

[0024]

[0026] dApp112 can route outgoing messages (e.g., messages sent from the first node 1101 to the second node 1102) and / or incoming messages (e.g., messages received from the second node 1102 at the first node 1101) according to the capabilities of the node 110 in the capability module 116 and the receiving-side setting module 114. In one embodiment, dApp112 can search for capabilities from the capability modules 116 of other nodes 110 to identify the nodes 110 that can receive the outgoing messages.

[0025]

[0027] In an embodiment, messages between nodes 110 can be permissioned, which means that a user of node 110 can only view information that the user is permitted to view. This can include queries for which the user of node 110 is a party. The data of the decentralized ledger network 120 can also be encrypted.

[0026]

[0028] Each user can decide which network participants on the decentralized ledger network 120 to employ (e.g., other nodes 110, or users of node 110). Encrypted information can only be shared between the requesting user and the receiving user through the decentralized ledger network 120. In one embodiment, a transaction hash without public information can be stored in the permissioned decentralized ledger network 120 and made available to all users.

[0027]

[0029] In an embodiment, both context and capabilities are used to identify potential receiving entities. Routing preferences can be used to identify one or more receiving entities from among the potential receiving entities (e.g., in the case where there is a use case of sending to more than one receiver).

[0028]

[0030] Examples of controls can include some or all of the fact that a data request can be systematically routed to the data owner, that data can be encrypted in transit and at rest, that separate private and permissioned databases can be provided, that permissioned nodes can restrict the information that a requester is permitted to view, that personally identifiable data can be held in a private database and only hash values can be shared in the decentralized ledger, and that data requests can be securely authenticated.

[0029]

[0031] In the embodiment, each participant's infrastructure can be configured and deployed in its own virtual local area network (VLAN) setup, using web production and disaster recovery instances, applications, databases, and virtual machines (VMs) physically residing in two separate hyper-converged managed devices. Node-to-node connectivity between participants in the network may be via Transmission Control Protocol (TCP) / Remote Procedure Call (RCP), and may be via specific secure IPs and ports configured and controlled through permitted access routes in the firewall between VLANs. Transactions may be committed only to the production nodes of the participant setup, and a separate replication process ensures node-pair replication to aid in recovery / recovery in the event of failover. Each participant's network IP may be placed on an approved list to enable access to applications. End-user access to the network participants' web interfaces may be via secure web services (HTTPS).

[0030]

[0032] Referring to Figure 2, a method for context-based messaging according to one embodiment is disclosed. In step 205, the sending entity can submit a message or communication to its node in the distributed ledger network. In one embodiment, a distributed application or "dApp" can receive a message submission from the sending entity.

[0031]

[0033] In one embodiment, a sending entity can communicate with its node or participate as a node in a distributed ledger network.

[0032]

[0034] In step 210, the sending entity node's dApp can identify context (e.g., subject, content, account(s)) from the message or communication text.

[0033]

[0035] In step 215, the dApp on the sending entity node can identify potential receiving entities based on the capabilities of other nodes. For example, the dApp on the sending entity node can look up the capabilities of other nodes and identify receiving entities that can process the message or communication.

[0034]

[0036] In step 220, the dApp of the sending entity node can retrieve and apply the sending entity's routing preferences to identify a recipient entity from among the likely recipient entities for a message or communication. In one embodiment, a sending entity (e.g., an organization, an individual) can identify preferences regarding the routing of a message or communication to a recipient entity based on the context in its configuration. For example, a sending entity can identify the context (e.g., subject, content, account(s)) and identify a recipient entity for a message or communication.

[0035]

[0037] In the embodiment, both context and capability are used to identify a potential receiving entity. Routing preference can be used to identify one or more receiving entities from a potential receiving entity (for example, if there is a use case to send to more than one receiver).

[0036]

[0038] In one embodiment, routing can be determined by the sending node and / or receiving node. For example, the sending node can identify the receiving node from the context, and the receiving node can then apply routing rules that may be provided by the sender and / or destination to further route the message or communication to the receiving entity.

[0037]

[0039] In one embodiment, a dApp can identify a receiving entity and associated receiving entity nodes, and can route messages or communications to those receiving entity nodes. The dApp of the receiving entity node can then apply preferences of the receiving entity in order to route messages or communications to the receiving entity.

[0038]

[0040] In step 225, the dApp on the sending entity node can send a communication or message to the receiving entity node.

[0039]

[0041] In step 230, the receiving entity node can receive the communication or message and, optionally, apply additional routing preferences to perform further routing of the communication or message, if desired.

[0040]

[0042] In step 235, the receiving entity node can route messages or communications to the receiving entity.

[0041]

[0043] Figure 3 shows an example computing system for implementing the configuration of the present disclosure. Figure 3 shows a computing device 300 as an example. The computing device 300 may represent the system components described herein. The computing device 300 may include a processor 305, which may be coupled to memory 310. Memory 310 may include volatile memory. The processor 305 may execute computer executable program code, such as a software program 315 stored in memory 310. The software program 315 may include one or more of the logical steps disclosed herein as program instructions that can be executed by the processor 305. Memory 310 may also include a data repository 320, which may be non-volatile memory for data persistence. The processor 305 and memory 310 may be coupled by a bus 330. The bus 330 may also be coupled to one or more network interface connectors 340, such as a wired network interface 342 and a wireless network interface 344. The computing device 300 may also have user interface components, which are screens, mice, keyboards, and / or other input / output components (not shown) for displaying a graphical user interface and receiving input from the user.

[0042]

[0044] Further details can be found in the attached appendix, and the disclosures therein are also incorporated herein by this reference in their entirety.

[0043]

[0045] The overall structure of the system and method implementation is described below.

[0044]

[0046] Embodiments of a system or part of a system can take the form of a “processing machine,” such as a general-purpose computer. The term “processing machine” as used herein is understood to include at least one processor using at least one memory. At least one memory stores a set of instructions. Instructions can be stored permanently or temporarily in one or more memories of the processing machine. The processor executes the instructions stored in one or more memories to process data. A set of instructions can include various instructions that perform a specific one or more tasks, such as the tasks described above. Such a set of instructions for performing a specific task can be characterized as a program, a software program, or simply software.

[0045]

[0047] In one embodiment, the processing machine can be a special-purpose processor.

[0046]

[0048] In one embodiment, the processing machine may be a cloud-based processing machine, a physical processing machine, or a combination thereof.

[0047]

[0049] As described above, a processing machine executes one or more instructions stored in memory to process data. This data processing may, for example, be in response to commands from one or more users of the processing machine, in response to previous processing, or in response to requests from other processing machines and / or any other inputs.

[0048]

[0050] As described above, the processing machine used to implement the embodiments may be a general-purpose computer. However, the processing machine may also use any of the other various technologies, which include application-specific computers and computer systems, which include, for example, microcomputers, minicomputers or mainframes, programmed microprocessors, microcontrollers, peripheral integrated circuit elements, CSICs (Customer-Specific Integrated Circuits) or ASICs (Application-Specific Integrated Circuits) or other integrated circuits, logic circuits, digital signal processors, programmable logic devices such as FPGAs (Field-Programmable Arrays), PLDs (Programmable Logic Devices), PLAs (Programmable Logic Arrays), and PALs (Programmable Array Logic), or any other devices or combinations of devices that can implement the processing steps disclosed herein.

[0049]

[0051] The processing machine used to implement the embodiment can use an appropriate operating system.

[0050]

[0052] It is understood that the processor and / or memory of a processing machine do not need to be located in the same geographical location in order to carry out the method of the above embodiment. That is, the processor and memory used by the processing machine can be located in different geographical locations and can be connected to communicate in any suitable manner. Furthermore, it is understood that the processor and / or memory can each consist of different physical parts of the equipment. Thus, the processor does not need to be one part of equipment in one location, nor does the memory need to be another part of equipment in another location. That is, the processor may be two parts of equipment in two different physical locations. The two different parts of the equipment can be connected in any suitable manner. Furthermore, the memory may include two or more parts of memory in two or more physical locations.

[0051]

[0053] To elaborate further, the above-described process is performed by various components and various types of memory. However, it is understood that the process performed by the two different components described above, according to further embodiments, can also be performed by a single component. Furthermore, the process performed by one individual component described above can also be performed by two individual components.

[0052]

[0054] Similarly, the memory storage performed by the two separate memory portions described above according to further embodiments can be performed by a single memory portion. Furthermore, the memory storage performed by the one separate memory portion described above can also be performed by two memory portions.

[0053]

[0055] Furthermore, various technologies can be used to provide communication between various processors and / or memories, and to enable processors and / or memories to communicate with any other entities, i.e., for example, to obtain further instructions, or to access and use remote memory stores. Such technologies used to provide such communication may include, for example, networks, the internet, intranets, extranets, LANs, Ethernet®, wireless communication over cell towers or satellites, or any client-server system that provides communication. Such communication technologies can use any suitable protocol, such as TCP / IP, UDP, OSI, etc.

[0054]

[0056] As described above, a set of instructions can be used in the processing of the embodiment. A set of instructions can be in the form of a program or software. The software can be, for example, system software or application software. The software can also be, for example, a collection of separate programs, a program module within a larger program, or a part of a program module. Furthermore, the software used can include modular programming in the form of object-oriented programming. The software tells the processing machine what to do using the data being processed.

[0055]

[0057] Furthermore, it is understood that the instructions or sets of instructions used in the implementation and operation of an embodiment are made into an appropriate form so that a processing machine can read them. For example, the instructions that make up a program can be in the form of an appropriate programming language that can be converted into machine code or object code, which allows one or more processors to read the instructions. That is, lines of programming code or source code written in a particular programming language are converted into machine code using a compiler, assembler, or interpreter. Machine code is a binary code of machine instructions that is specific to a particular type of processing machine, for example, specific to a particular type of computer. Computers understand machine code.

[0056]

[0058] Any suitable programming language can be used according to various embodiments. Furthermore, the instructions and / or data used in implementing the embodiments may utilize any compression or encryption techniques or algorithms, if desired. An encryption module can be used to encrypt data. Additionally, files and other data can be decrypted, for example, using a suitable decryption module.

[0057]

[0059] As described above, embodiments can be implemented as illustrated, for example, in the form of a processing machine including a computer or computer system including at least one memory. It is understood that a set of instructions, i.e., software that enables a computer operating system to perform the operations described above, can be contained in any one or more of the various media as described above. Furthermore, the data processed by a set of instructions can also be contained in any one or more of the various media. That is, a particular medium, i.e., the memory of a processing machine used to hold a set of instructions and / or data used in an embodiment, can be, for example, any form of various physical forms and transmissions. For example, the medium can be in the form of a compact disc, DVD, integrated circuit, hard disk, floppy disk, optical disc, magnetic tape, RAM, ROM, PROM, EPROM, wire, cable, fiber, communication channel, satellite transmission, memory card, SIM card, or other remote transmission, as well as any other medium or data source that can be read by the processor.

[0058]

[0060] Furthermore, the single or multiple memories used in the processing machine implementing the embodiment can be of any of various forms so as to enable the memory to hold instructions, data, or other information as desired. Thus, the memory can take the form of a database for holding data. The database can use any desired array of files, such as a flat file array or a relational database array.

[0059]

[0061] In systems and methods, various "user interfaces" can be used to enable interaction between a user and one or more processing machines used to implement the embodiments. The user interfaces used herein include any hardware, software, or combination of hardware and software used by the processing machine to enable the user to interact with the processing machine. A user interface may, for example, take the form of a dialog screen. A user interface may also include any of the following: a mouse, touchscreen, keyboard, keypad, voice reader, voice recognition device, dialog screen, menu box, list, check box, toggle switch, push button, or any other device that enables the user to receive information about the operation of the processing machine and / or provides information to the processing machine when the processing machine processes a set of instructions. Thus, a user interface is any device that provides communication between the user and the processing machine. Information provided by the user to the processing machine via the user interface may, for example, take the form of commands, data selections, or any other input.

[0060]

[0062] As described above, a user interface is used by a processing machine to execute a set of instructions, causing the processing machine to process data on behalf of the user. Typically, a user interface is used by a processing machine to interface with the user in order to carry or receive information from the user. However, according to some embodiments of the system and method, it is understood that there is no need for the user interface used by the processing machine to actually interact with the human user. Rather, it is understood that the user interface interacts not with the human user, but with another processing machine, i.e., to carry and receive information. Thus, other processing machines can be characterized as users. Furthermore, it is understood that the user interface used in the system and method partially interacts with one or more other processing machines, and also partially interacts with the human user.

[0061]

[0063] Those skilled in the art will readily understand that the embodiments have broad practical applicability and are applicable. Many other embodiments and modifications of the present invention, as well as many variations, alterations, and equivalent configurations, will be apparent from the foregoing description or proposed in reasonable terms thereto, without departing from the spirit or scope.

[0062]

[0064] Accordingly, although embodiments of the present invention have been described in detail herein in relation to exemplary embodiments, it should be understood that this disclosure is merely illustrative and illustrative of the present invention and is made to provide disclosures that enable the present invention. Accordingly, the foregoing disclosure is not intended to interpret or limit the present invention, nor is it intended to exclude any other such embodiments, modifications, variations, alterations, or equivalent configurations.

Claims

1. A method for contextual messaging and information routing in a distributed ledger network, A distributed application running on a sending entity node in a distributed ledger network, which receives messages or communications from the sending entity, The distributed application identifies the context of the message or communication statement, The distributed application retrieves the capabilities of each of the other nodes in the distributed ledger network from each of the other nodes in the distributed ledger network, The distributed application identifies a likely receiving entity for the message or communication based on the identified context and the retrieved capabilities, The distributed application retrieves routing preferences for the sending entity, The distributed application applies the routing preferences with respect to the sending entity in order to identify the receiving entity from the prospective receiving entity, The distributed application sends the message or communication statement to the receiving node for the receiving entity using the routing preference, wherein the message is communicated using the Transmission Control Protocol (TCP) / Remote Procedure Call (RCP), and the communication statement is sent. A method comprising the receiving node being configured to apply routing preferences with respect to the sending entity node to the message.

2. A method according to claim 1, wherein the context includes the subject and / or account from the message.

3. A method according to claim 2, wherein the routing preference with respect to the sending entity is based on the subject of the message.

4. A method according to claim 2, wherein the routing preference is based on the account in the message.

5. A method according to claim 1, wherein the message is sent to a distributed application on the receiving node.

6. A method according to claim 1, wherein the message is communicated using an authorized access route.

7. A method according to claim 1, wherein the receiving node is configured to route the message or communication statement to the receiving entity using routing preferences relating to the receiving entity.

8. It is a system, Distributed ledger networks and Multiple nodes in the aforementioned distributed ledger network, wherein each node runs on multiple nodes that execute distributed applications Includes, A distributed application on the sending node receives a message or communication from the sending entity. The distributed application on the sending node identifies the context of the message or the communication statement, The distributed application of the transmitting node retrieves the capabilities of each of the other nodes in the distributed ledger network from the other nodes in the distributed ledger network. The distributed application of the sending node identifies a likely receiving entity for the message or communication based on the identified context and the retrieved capabilities. The distributed application on the sending node retrieves routing preferences for the sending entity. The distributed application on the sending node applies the routing preference with respect to the sending entity in order to identify a receiving entity from the prospective receiving entity. The distributed application of the transmitting node uses the routing preference to send the message or communication statement to the receiving node for the receiving entity, and the message is communicated using the Transmission Control Protocol (TCP) / Remote Procedure Call (RCP). The receiving node is configured to route the message or communication statement to the receiving entity using routing preferences relating to the receiving entity. system.

9. The system according to claim 8, wherein the context includes the subject and / or account from the message.

10. The system according to claim 9, wherein the routing preference with respect to the sending entity is based on the subject of the message.

11. The system according to claim 9, wherein the routing preference with respect to the sending entity is based on the account in the message. system.

12. The system according to claim 8, wherein the message is sent to a distributed application on the receiving node.

13. The system according to claim 8, wherein the message is communicated using an authorized access route.

14. A non-temporary computer-readable storage medium containing stored instructions, wherein, when the instructions are read and executed by one or more computer processors, the one or more computer processors... The steps include receiving a message or communication from the sending entity, A step of identifying the context with respect to the message or communication statement, A step of searching for the capabilities of each of the other nodes in the distributed ledger network, Steps include identifying a likely receiving entity for the message or communication based on the identified context and the retrieved capabilities, The steps include searching for routing preferences with respect to the aforementioned sending entity, The steps include applying the routing preference with respect to the sending entity in order to identify a receiving entity from the aforementioned prospective receiving entity, A step of sending the message or communication statement to the receiving node for the receiving entity using the routing preference, wherein the message is communicated using the Transmission Control Protocol (TCP) / Remote Procedure Call (RCP), and a step of sending the communication statement. This involves performing a step that includes the following: The receiving node is configured to apply routing preferences relating to the sending entity node to the message. A non-temporary computer-readable storage medium.

15. A non-temporary computer-readable storage medium according to claim 14, wherein the message is communicated using an authorized access route.

Images