Patent Description:
Bilateral trade negotiations also typically involve one-to-one communications and fragmented individual networks. Markets involving such negotiations can suffer from limited liquidity and lack of competitive pricing.

For the foregoing reasons, bilateral trade negotiations often exhibit fractured communication sequences. Audit requirements are thus a challenge. Making matters worse, a central authority for trade clearing (e.g., a clearing house) is not privy to the negotiation and trade matching processes occurring between these parties. As a result, brokers are forced to self-report the results of the negotiations to satisfy regulatory obligations. Unfortunately, reporting is also a fractured, manual process, with potential for gaps and non-compliance.

The self-reporting notwithstanding, the negotiations remain opaque to the clearing house and regulator. While some information and other data is captured in, for instance, chat logs, much of the negotiation data is not readily or at all available for an audit trail or other investigation (e.g., to scrutinize trade irregularities).

Background art document <NPL>: discloses a system and method for performing transactions stored in a sidechain that is pinned to the main chain.

Methods and systems for message data recordation and other processing of a sequence of communication events are described. The disclosed methods and systems may implement an iterative process for recordation and other processing of the sequence of communication events. The nature of the communication events may vary. In some cases, the communication events may be directed to, or otherwise involve, bilateral trade negotiations, matching, or other transactional procedures related to trading. In this context, the disclosed methods and systems are capable of expanding a participant's (e.g., a broker's) reach to further (e.g., all) liquidity providers. The disclosed methods and systems also remove the labor-intensive steps of tracking multiple negotiations manually, and eliminate, reduce, or minimize delays in reporting and compliance issues implicated by the negotiation process.

The message data recordation and processing of the sequence of communication events is configured to adjust visibility permissions for participants in their respective communication events. The permissions may thus address the visibility of the message data for each communication event. The visibility of the message data accordingly varies across the sequence of communication events.

The disclosed methods and systems employs blockchain data structures to provide for the recordation and reporting of the information or other data representative of the sequence of communication events in immutable fashion. Multiple chains are created to allow the visibility of message data to be adjusted. For instance, a subsidiary chain data structure may be created to support part of the sequence of communication events. The disclosed methods and systems are thus capable of providing privacy for those involved in an individual negotiation, while still binding the participants who ultimately finalize or complete the trade as part of an agreed upon transaction. As described below, the visibility permissioning provided by the disclosed methods and systems also supports informing the original group of participants (e.g., the rest of the market) that the transaction is completed while maintaining the privacy of the transaction details. Thus, any participant initially or otherwise solicited for a transaction has its market interest protected and receives a notification in the event that someone else completes (e.g., wins) the bidding process. With completed deals reported to the broader network immediately, regulatory and/or other reporting requirements are satisfied and market participants not party to the deal receive notice of the completed transactions more quickly, without being able to see any sensitive negotiation information.

Although described below in connection with bilateral transactions, the nature of the message data processed by the disclosed methods and systems need not involve negotiations, transactions or trading. A variety of different message types and contexts may be addressed by the disclosed methods and systems. Examples of other types of messaging include data indicative of allocations and claims of already-matched trades, transfers of open trading positions, average pricing of batched transactions, and other post-trade processes.

Although described below in connection with examples involving blockchain-based messaging, the disclosed methods and systems are well suited for use with a variety of communication platforms and media. In some cases, different platforms and media may be used by different participants in the same sequence of communication events. The disclosed methods and systems may use keywords to capture message data for each message or communication event. The keywords may be preceded or otherwise denoted with hashtags or other standardized or predetermined symbols or characters.

Although described herein in connection with bilateral trade negotiations, the disclosed embodiments are well suited for use with other types of negotiations, transactions and financial instruments. For example, transactions such as block trades, exchange for related positions (EFRPs), and other privately negotiated transactions (PNTs) may benefit from the message data recordation and visibility permissioning provided by the disclosed methods and systems.

The blockchains, replicated ledgers and other data structures created, managed, and used by the disclosed methods and systems may be configured, created, managed, and used as described in <CIT> ("Bilateral Assertion Model and Ledger Implementation Thereof") and <CIT> ("Selectively Replicated Trustless Persistent Store"), The blockchains and other data structures may use consensus rules, and the rules may be changed in accordance with the synchronization techniques described in <CIT> ("Systems and Methods for Blockchain Rule Synchronization"), The messages and communication events may be configured as, or otherwise incorporate hashtag and other features of the communication protocol, described in <CIT> ("Integration Application Utilizing a Communications Protocol").

In some cases, the disclosed methods and systems are implemented by a clearing house or exchange. For instance, a computer system of the clearing house or the exchange (i.e., an exchange computer system) may include one or more aspects of, or be configured as, the disclosed systems and/or be configured to implement one or more aspects of the disclosed methods. The clearing house may be an adjunct to an exchange responsible for settling trading accounts, clearing trades, collecting and maintaining performance bond funds, regulating delivery, and reporting trading data. Clearing is the procedure through which the clearing house becomes buyer to each seller of an instrument, and seller to each buyer, and assumes responsibility for protecting buyers and sellers from financial loss by assuring performance on each contract. This is effected through the clearing process.

The disclosed methods and systems may provide an exchange computer system or other trading-related computer system a new technique for recording the details of each negotiation and each transaction. The replication of the data structure establishes the irrefutable and immutable nature of the recorded details for enforcement by the exchange or clearing house.

<FIG> depicts an example of bilateral trade negotiation having a sequence of communication events for which message data is recorded in accordance with the disclosed methods and systems. In this example, a hedger directs a broker to issue a request for quote (RFQ). The RFQ is the originating message for an initial communication event of the sequence. The originating message includes message data that specifies an initial group of participants to which the originating message is to be visible. In this case, the originating message is sent to three speculators in a one-to-many fashion. A regulator and a clearing house may also be privy to the originating message in some cases. As described below, the message data for the originating message is stored in a main or primary data structure. In this example, the data structure is or includes a blockchain. The blockchain is replicated in a respective memory (e.g., storage) at each participant, with each participant having visibility permission for the originating message (i.e., the broker, the three speculators, the clearing house, and the regulator).

A subsidiary data structure is created in connection with a response to the originating message. In the example of <FIG>, Speculator <NUM> generates a responsive message (e.g., an offer). The responsive message includes the details of the offer as well as recipient data that establishes visibility permissions for the responsive message. In this example, the recipient data specifies that only the broker, Speculator <NUM>, and the regulator have visibility. To implement the visibility permission, a subsidiary data structure - in this case, a subsidiary blockchain of the main blockchain - is created. The message data for the responsive message, and any subsequent messages during the negotiations between the broker and Speculator <NUM>, are stored in the subsidiary blockchain. In the example of <FIG>, three additional messages are generated in sequence. In a first one of the additional messages, a counter offer from the broker is presented. The speculator accepts in a second one of the additional messages. In the third additional message, the broker acknowledges the acceptance. Each additional message has recipient data that maintains the visibility permission level or state such that no additional blockchains are created.

In the example of <FIG>, the communication sequence ends when the broker sends a message acknowledging an acceptance by Speculator <NUM>. As shown in <FIG>, further message or communication event data is stored in the main blockchain to indicate the completion of the sequence (e.g., trade or transaction). The further message or communication event data may merely indicate the fact of completion, rather than the details of the transaction (e.g., price, quantity, etc.). As described below, such anchoring of the subsidiary blockchain to the main blockchain maintains privacy of the private portions of the communication sequence, while making the broader group of participants aware of the completion. For instance, in some cases, a hash or Merkle root of the subsidiary blockchain may be used, e.g., incorporated into the blockchain for the completed (e.g., matched) trade.

The message data for each of the messages or communication events may be captured by parsing the messages to capture keywords or other predefined text strings. As described below, the keywords may be used to indicate bids and offers, solicit and respond to bids and offers, and identify the recipient data. Automating the message data capture using the keywords is capable of reducing or eliminating ambiguity, manual work, and opportunity for error. For these and other reasons, implementation of the disclosed methods and systems may automate the bidding, negotiation, and matching steps of bilateral trades and transactions, while scaling to any size network, and preserving the negotiation and execution steps for regulatory reporting in an immutable fashion.

<FIG> depicts a computer implemented method for message data recordation for a sequence of communication events, such as the communication sequence occurring in a bilateral trade negotiation. The acts of the method may be implemented by a communication processor at each participant, including a clearinghouse or other central party. The method may begin with receipt, via a network interface, of an originating message for an initial communication event of the sequence of communication events (block <NUM>). The originating message for the initial communication event is then parsed to extract message data for the initial communication event (block <NUM>). The extracted message data specifies a first group of participants to which the originating message for the initial commmunication event is visible. The extracted message data is stored in a data structure for the sequence of communication events (block <NUM>). The data structure may be a blockchain or other replicated or distributed ledger. The data structure is replicated by a respective communication processor of each participant of the first group of participants.

A responsive message to the originating message is generated or received (block <NUM>). In either case, the responsive message includes responsive message data that, in turn, includes recipient data that permissions a second group of participants to which the responsive message is visible. The second group differs from the first group. For instance, the second group may be a subset of the first group. Alternatively or additionally, the second group may include additional participants. In some cases, the responsive message is or includes an acknowledgement. For example, an exchange or other third party may generate an acknowledgement confirming that the third party has received an originating or other message, received a response from the other parties in the negotiation, or a match between two of the parties. An acknowledgement may alternatively be sent from the other parties in the negotiation.

A subsidiary data structure of the data structure is created in connection with the responsive message (block <NUM>). In this case, the subsidiary data structure is created to address and support the adjustment in visibility permissioning. The responsive message data is stored in the subsidiary data structure (block <NUM>). The recipient data for the responsive message data is also stored.

The responsive message is transmitted via the network interface to the second group of participants (block <NUM>). The receipt of the responsive message causes the subsidiary data structure to be replicated by the respective communication processor of each participant in the second group of participants.

A decision block <NUM> then determines whether the sequence is complete as a result of the responsive message. For example, the sequence may be complete if the responsive message has accepted an offer. The determination may include a detection of a keyword indicative of such acceptance. The determination may be made by a processor at the exchange or another third party and/or by processors at each party involved in the sequence. If the sequence is complete, control passes to a block <NUM> in which the subsidiary data structure is anchored or otherwise incorporated into the primary data structure for the originating message. For example, a hash or Merkle root of the subsidiary data structure may be incorporated into the primary data structure upon completion of the sequence of communication events. In the example of <FIG>, completion may also be reported via one or more messages. If the sequence is not complete, then control returns to the block <NUM> for further responsive message generation and reception.

<FIG> provides an example of the implementation of the method of <FIG> in connection with a communication sequence in which message data is provided and captured using hashtag based keywords. The example shows how the messaging and message data recordation techniques described herein allow brokers or commercial clients ("hedgers") to propose bilateral transactions in a one-to-many fashion, reaching any eligible participants of a given market. Participants ("speculators") would be enabled and encouraged to respond to the proposals, initiating a negotiation cycle visible to both parties, but kept private from the broader market, with bids/offers preserved for exchange or regulator review to satisfy reporting requirements. Agreement by one party to the other's bid/offer triggers an immutable transaction on the main ledger, visible to all participants and also satisfying existing reporting requirements.

The negotiation cycles in the example of <FIG> are triggered by hashtags or other unique keywords or identifiers or tags, which trigger their own ad hoc distributed ledger to meet requirements that negotiation details remain private while the completed negotiation is binding and visible on the main ledger.

These hashtags or keywords may be predefined as, for instance, part of a predefined protocol. The hashtags or keywords allow any participant receiving the initial bid invitation to respond in kind and enter an ad hoc, secure negotiation phase whose contents are preserved, but protected from others in the broader network. Because the messaging and data structures are implemented via distributed ledgers, other parties are capable of confirming that negotiations were taking place and untampered, but not see the parties, prices, or quantities involved.

With the hashtags acting as a "call and response", parties may solicit offers, respond with counter-offers, and ultimately accept a broker's terms. This accept message closes the negotiation phase, ending further entries on the sub-chain and returning the final value to the main ledger, where the broader network would be able to see the outcome. Regulators are then able to view both the finished transaction, and audit the intermediate steps leading up to it, without any additional work or trust required from brokers or other participants.

In the example of <FIG>, the originating message is based on a transaction request from Customer C1 to Broker B1. In accordance with that request, the Broker B1 generates the originating message, in which an offer to sell <NUM> barrels of June <NUM> Light Crude at a price above $<NUM> is presented. The offer (and others described herein) may be configured as a limit order, i.e., at a price at or above $<NUM>. In this example, the originating message presents that order and constituent message data as follows: #offer #CLM8 #<NUM>. Each keyword is denoted by a hashtag. In this case, Broker B1 decides not to specify include a keyword specifying a price, but a price may be specified in other cases. Other keywords, symbols or characters may be used. The originating message also specifies that Speculators S1, S2, and Hedger H1 are included in the group of participants having visibility of the offer. For example, Broker B1 may use specific user tags to direct the originating message to a limited group. Alternatively, the originating message may include a tag specifying a group, which may be limited (e.g., #GroupA) or broadcast market-wide (e.g., #Everyone). Each one of the specified participants receives the originating message, creates a replication of a main or primary data structure for the communication sequence, and stores the message data in the data structure.

In the example of <FIG>, Speculator S1 sends a responsive message, declining the offer as follows - #decline. In some cases, a subsidiary data structure is created for the responsive message.

Subsidiary data structures are created in connection with the responsive messages from Speculator S2 and Hedger H1, each of whom respond with a bid via a #bid keyword and the details as shown. The responsive messages also specify that only Broker B1 is permissioned to view the responsive messages. Respective subsidiary data structures are accordingly created for storing the ensuing message data for each negotiation. In this example, the negotiations end using a keyword #accept.

The example of <FIG> shows how three initial solicitations spawned two subsidiary blockchain negotiations, each of which concludes with a trade. Upon conclusion, and as described further below, data indicating that a transaction occurred, but without negotiation details, is reported back to the main blockchain (e.g., via anchoring). The data indicating that a transaction occurred is thus visible to all of the initial market participants, including other non-message generating participants, such as a clearing house and a regulator. The regulator may also be permissioned to view the data in each of the subsidiary blockchains.

The example of <FIG> shows how the disclosed methods and systems automates the bidding, negotiation, and matching steps of a transaction, while being capable of scaling to any size network. The permissioned, private distributed ledger of the disclosed methods and systems preserves the negotiation and execution steps (e.g., information) for regulatory reporting in an immutable fashion by means of a permissioned, private distributed ledger. Both proposed deals and finalized ones are immortalized in the ledger, with details kept private or shared publicly as specified and desired. The example of <FIG> also shows the manner in which a predefined, simplified vocabulary, participants supports the accurate solicitation and response to bids and offers, while reducing ambiguity and manual work.

With the disclosed methods and systems, deal initiators are capable of proposing bilateral transactions in a targeted broadcast, reaching any or all eligible participants of a given market. Speculators and other participants can respond to the proposals, initiating a negotiation cycle visible to both parties but kept private from the broader market, with bids/offers preserved for exchange or regulator review to satisfy reporting requirements. Agreement by one party to the other's bid/offer will trigger an immutable transaction on the public ledger, where visibility can be permissioned to all or a subset of the market, as well as regulators and the clearing house to satisfy existing reporting requirements.

In addition to the immutable features of a distributed ledger, the distributed ledger of the disclosed methods and systems allows the lineage of each transaction to be preserved, and non-repudiation of agreed upon transactions through the use of digital signatures on the chained transaction hashes. In other words, if a deal is questioned then the specifics of its bid/offer and response can be summoned. Should a regulator suspect irregularities, the entire negotiation sequence can be audited, as well as related interactions with other parties which can be linked by timestamp and tagging.

Permissioned private distributed ledgers allow selective replication (only transmitting data relevant to the parties) of transactions on bilateral or multilateral basis. The disclosed methods and systems alleviate the need for costly encryption solutions while improving security.

Additional transaction integrity guarantees may be achieved by the disclosed methods and systems if external anchors are used for completed transactions. As described herein, evidence of an attested transaction evidence may be written to an external source, which may be public, because the evidence itself does not contain any private data. In other words, the broader market may thus see that a deal has taken place without its details being revealed.

The permissioned distributed ledger of the disclosed methods and systems may be applied in other transaction workflows or communication sequences. For instance, the transaction workflow may be a one-to-one bilateral transaction. The permissioned ledger may be used to carve out a single private negotiation from broader market visibility, while providing the lineage associated with the negotiation to thereby ensure non-repudiation. Various multilateral (e.g., one-to-many) negotiations may be handled in which one party permissions multiple parties to the same request. Multiple private negotiations or a single public group negotiation may thus be recorded. The number of resulting transactions may vary.

The disclosed methods and systems are capable of expanding a participant's reach to more (e.g., all) liquidity providers, removing the labor-intensive steps of tracking multiple negotiations manually, and minimizing delays in reporting. The disclosed methods and systems also minimize compliance issues surrounding the negotiation process, by guaranteeing tamper-resistance and the lineage of each negotiation.

As described above, the ability to provide selective replication improves security and reduces the need for encryption. Additionally, leveraging external anchors provides a declaration of an event/trade without disclosing the details associated therewith. These aspects of the disclosed methods and systems allow any party solicited for a deal to have its market interest protected and receive notification should someone else complete the transaction process. Moreover, with completed deals distributed to the broader network immediately, reporting requirements are satisfied and market participants not party to the deal receive notice of those transactions more quickly, without being able to see any sensitive negotiation information.

With reference to <FIG>, where elements in common with other figures are indicated via common reference numerals, a system <NUM> for message data recordation for a sequence of communication events in accordance with one example is depicted. The system <NUM> may be used to implement any of the methods described herein. The system <NUM> may be for any one of the participants in the communication sequence, including central or other inactive parties, such as a regulator.

The system <NUM> includes a communication event processor <NUM>, which may correspond with any one of the processors referenced herein. The communication event processor <NUM> is configured to record message data for a sequence of communication events on a memory <NUM>. As described herein, the message data is recorded using an arrangement of multiple data structures <NUM>, including a primary or main data structure and a number of subsidiary data structures.

The system <NUM> includes a network interface <NUM> to support receipt and transmission of the messages of each communication event. The system <NUM> further includes a display or other user interface <NUM> to facilitate entry and viewing of message content.

In the example of <FIG>, the communication event processor <NUM> includes the following component processors: a network interface processor <NUM>; a data structure manager <NUM>; a message processor <NUM>; and, a message editor <NUM>. The component processors may be integrated with one another, and/or other components of the communication event processor <NUM>, to any desired extent.

The network interface processor <NUM> is configured to receive, via the network interface <NUM>, an originating message for an initial communication event of the sequence of communication events. The message processor <NUM> is configured to parse the originating message for the initial communication event to extract message data for the initial communication event, the extracted message data specifying a first group of participants to which the originating message for the initial commmunication event is visible. The data structure manager <NUM> is a data structure management processor configured to store the extracted message data in the data structure, the data structure being replicated by a respective communication processor of each participant of the first group of participants. The message processor <NUM> is further configured to generate a responsive message to the originating message, the responsive message including responsive message data, the responsive message data including recipient data, the recipient data permissioning a second group of participants to which the responsive message is visible, the second group differing from the first group. The data structure manager <NUM> is further configured to create, in the memory <NUM>, a subsidiary data structure of the data structure and store the responsive message data in the subsidiary data structure. The network interface processor <NUM> is further configured to transmit, via the network interface <NUM> to the second group of participants, the responsive message such that receipt of the responsive message causes the subsidiary data structure to be replicated by the respective communication processor of each participant in the second group of participants.

<FIG> depicts a system <NUM> for message data recordation for a sequence of communication events in accordance with another embodiment. The system <NUM> may be configured to implement any one or more of the methods described herein. The system <NUM> includes a processor <NUM>, which may correspond with or include any one or more of the above-described processors. The system <NUM> also includes a memory <NUM> coupled with the processor <NUM>. The configuration of the memory <NUM> may vary, such that the memory <NUM> may include any number or combination of storage devices, data stores, databases, and memories. The memory <NUM> is configured for non-transitory storage of data and/or instructions directed to message data recordation as described herein. The memory <NUM> may store such data and/or instructions in a volatile and/or non-volatile manner. Further details regarding examples of the processor <NUM> and the memory <NUM> are described below in connection with <FIG>.

The system <NUM> includes first logic <NUM> stored in the memory <NUM> and executable by the processor <NUM> to receive, via a network interface, an originating message for an initial communication event of the sequence of communication events, second logic <NUM>, stored in the memory <NUM> and executable by the processor <NUM> to parse, the originating message for the initial communication event to extract message data for the initial communication event, the extracted message data specifying a first group of participants to which the originating message for the initial communication event is visible, third logic <NUM>, stored in the memory <NUM> and executable by the processor <NUM> to store the extracted message data in a data structure for the sequence of communication events, the data structure being replicated by a respective communication processor of each participant of the first group of participants, fourth logic <NUM> stored in the memory <NUM> and executable by the processor <NUM> to generate or receive a responsive message to the originating message, the responsive message comprising responsive message data, the responsive message data comprising recipient data, the recipient data permissioning a second group of participants to which the responsive message is visible, the second group differing from the first group, fifth logic <NUM> stored in the memory <NUM> and executable by the processor <NUM>, to create a subsidiary data structure of the data structure, sixth logic <NUM> stored in the memory <NUM> and executable by the processor <NUM> to store the responsive message data in the subsidiary data structure, and seventh logic <NUM> stored in the memory <NUM> and executable by the processor <NUM> to transmit, via the network interface to the second group of participants, the responsive message such that receipt of the responsive message causes the subsidiary data structure to be replicated by the respective communication processor of each participant in the second group of participants.

Referring to <FIG>, an illustrative embodiment of a general computer system <NUM> is shown. The computer system <NUM> can include a set of instructions that can be executed to cause the computer system <NUM> to perform any one or more of the methods or computer based functions disclosed herein. The computer system <NUM> may operate as a standalone device or may be connected, e.g., using a network, to other computer systems or peripheral devices. Any of the components discussed above may be a computer system <NUM> or a component in the computer system <NUM>.

In a networked deployment, the computer system <NUM> may operate in the capacity of a server or as a client user computer in a client-server user network environment, or as a peer computer system in a peer-to-peer (or distributed) network environment. The computer system <NUM> can also be implemented as or incorporated into various devices, such as a personal computer (PC), a server computer, a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communications device, a wireless telephone, a land-line telephone, a control system, a camera, a scanner, a facsimile machine, a printer, a pager, a personal trusted device, a web appliance, a network router, switch or bridge, or any other machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. In a particular embodiment, the computer system <NUM> can be implemented using electronic devices that provide voice, video or data communication. Further, while a single computer system <NUM> is illustrated, the term "system" shall also be taken to include any collection of systems or sub-systems that individually or jointly execute a set, or multiple sets, of instructions to perform one or more computer functions.

As illustrated in <FIG>, the computer system <NUM> may include a processor <NUM>, e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both. The processor <NUM> may be a component in a variety of systems. For example, the processor <NUM> may be part of a standard personal computer or a workstation. The processor <NUM> may be one or more general processors, digital signal processors, application specific integrated circuits, field programmable gate arrays, servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analyzing and processing data. The processor <NUM> may implement a software program, such as code generated manually (i.e., programmed).

The computer system <NUM> may include a memory <NUM> that can communicate via a bus <NUM>. The memory <NUM> may be a main memory, a static memory, or a dynamic memory. The memory <NUM> may include, but is not limited to computer readable storage media such as various types of volatile and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one or more embodiments, the memory <NUM> includes a cache or random access memory for the processor <NUM>. In alternative embodiments, the memory <NUM> is separate from the processor <NUM>, such as a cache memory of a processor, the system memory, or other memory. The memory <NUM> may be an external storage device or database for storing data. Examples include a hard drive, compact disc ("CD"), digital versatile disc ("DVD"), memory card, memory stick, floppy disc, universal serial bus ("USB") memory device, or any other device operative to store data. The memory <NUM> is operable to store instructions executable by the processor <NUM>. The functions, acts or tasks illustrated in the figures or described herein may be performed by the programmed processor <NUM> executing the instructions <NUM> stored in the memory <NUM>. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firmware, microcode and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing and the like.

As shown, the computer system <NUM> may further include a display unit <NUM>, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid state display, a cathode ray tube (CRT), a projector, a printer or other now known or later developed display device for outputting determined information. The display <NUM> may act as an interface for the user to see the functioning of the processor <NUM>, or specifically as an interface with the software stored in the memory <NUM> or in the drive unit <NUM>.

Additionally, the computer system <NUM> may include an input device <NUM> configured to allow a user to interact with any of the components of system <NUM>. The input device <NUM> may be a number pad, a keyboard, or a cursor control device, such as a mouse, or a joystick, touch screen display, remote control or any other device operative to interact with the system <NUM>.

In a particular embodiment, as depicted in <FIG>, the computer system <NUM> may also include a disk or optical drive unit <NUM>. The disk drive unit <NUM> may include a computer-readable medium <NUM> in which one or more sets of instructions <NUM>, e.g. software, can be embedded. Further, the instructions <NUM> may embody one or more of the methods or logic as described herein. In a particular embodiment, the instructions <NUM> may reside completely, or at least partially, within the memory <NUM> and/or within the processor <NUM> during execution by the computer system <NUM>. The memory <NUM> and the processor <NUM> also may include computer-readable media as discussed above.

The present disclosure contemplates a computer-readable medium that includes instructions <NUM> or receives and executes instructions <NUM> responsive to a propagated signal, so that a device connected to a network <NUM> can communicate voice, video, audio, images or any other data over the network <NUM>. Further, the instructions <NUM> may be transmitted or received over the network <NUM> via a communication interface <NUM>. The communication interface <NUM> may be a part of the processor <NUM> or may be a separate component. The communication interface <NUM> may be created in software or may be a physical connection in hardware. The communication interface <NUM> is configured to connect with a network <NUM> , external media, the display <NUM>, or any other components in system <NUM>, or combinations thereof. The connection with the network <NUM> may be a physical connection, such as a wired Ethernet connection or may be established wirelessly as discussed below. Likewise, the additional connections with other components of the system <NUM> may be physical connections or may be established wirelessly.

The network <NUM> may include wired networks, wireless networks, or combinations thereof. The wireless network may be a cellular telephone network, an <NUM>, <NUM>, <NUM>, or WiMax network. Further, the network <NUM> may be a public network, such as the Internet, a private network, such as an intranet, or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to TCP/IP based networking protocols.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. While the computer-readable medium is shown to be a single medium, the term "computer-readable medium" includes a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term "computer-readable medium" shall also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the methods or operations disclosed herein. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a combination of one or more of them.

In a particular non-limiting, exemplary embodiment, the computer-readable medium can include a solid-state memory such as a memory card or other package that houses one or more non-volatile read-only memories. Further, the computer-readable medium can be a random access memory or other volatile re-writable memory. Additionally, the computer-readable medium can include a magneto-optical or optical medium, such as a disk or tapes or other storage device to capture carrier wave signals such as a signal communicated over a transmission medium. A digital file attachment to an e-mail or other self-contained information archive or set of archives may be considered a distribution medium that is a tangible storage medium. Accordingly, the disclosure is considered to include any one or more of a computer-readable medium or a distribution medium and other equivalents and successor media, in which data or instructions may be stored.

The disclosed computer programs (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages. The disclosed computer programs can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. Such computer programs do not necessarily correspond to a file in a file system. Such programs can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). Such computer programs can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and anyone or more processors of any kind of digital computer. Generally, a processor may receive instructions and data from a read only memory or a random access memory or both. Generally, a computer may also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few.

Referring now to <FIG>, there is shown a block diagram of an exemplary network <NUM> for supporting the above-described transactions. The network <NUM> couples market participants <NUM>, <NUM>, with a clearing house <NUM>, also referred to as a central counterparty or intermediary, via a communications network <NUM>, such as the Internet, an intranet or other public or private, secured or unsecured communications network or combinations thereof. The network <NUM> may also be part of, or alternatively coupled with a larger trading network, allowing market participants <NUM>, <NUM> to trade a variety of other products, via the clearing house <NUM>. It will be appreciated that the plurality of entities utilizing the disclosed embodiments, e.g. the market participants <NUM>, <NUM>, may be referred to as traders, trader-brokers, clearing members, clearing firms, or by other nomenclature reflecting the role that the particular entity is performing with respect to the disclosed embodiments and that a given entity may perform more than one role depending upon the implementation and the nature of the particular transaction being undertaken, as well as the entity's contractual and/or legal relationship with another market participant <NUM>, <NUM> and/or the clearing house <NUM>.

The clearing house <NUM> provides a system <NUM> that implements the functions of buy/sell <NUM> transactions, clearing <NUM> those transactions, settling <NUM> those transactions and managing risk <NUM> among the market participants <NUM>, <NUM> and between the market participants and the clearing house <NUM>, as well as administration functionality <NUM> for, e.g., administering transactions between delivery and redemption. In an alternate embodiment, collateral management <NUM> and/or request-for-quote functionality (not shown) or netting functionality (not shown) may also be provided, as is discussed in more detail below. The clearing house <NUM> may be include or be coupled with one or more database(s) <NUM> or other record keeping system which stores data related to orders.

While this specification contains many specifics, these should not be construed as limitations on the scope of the invention but rather as descriptions of features specific to particular embodiments of the invention.

Similarly, while operations are depicted in the drawings and described herein in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

It will be appreciated that one or more of the processors, memories, logic and/or components described above may be combined or further sub-divided into discrete components thereof, and that all such implementations, accomplishing the disclosed functionality, are contemplated. Further, operation of the above components/functions may be performed on a periodic or batch basis, such as at the close of trading, and/or in real-time continuously throughout the trading day or other window of time.

To clarify the use in the pending claims and to hereby provide notice to the public, the phrases "at least one of <A>, <B>,. and <N>" or "at least one of <A>, <B>,. <N>, or combinations thereof" are defined in the broadest sense, superseding any other implied definitions herebefore or hereinafter unless expressly asserted by the Applicant to the contrary, to mean one or more elements selected from the group comprising A, B,. and N, that is to say, any combination of one or more of the elements A, B,. or N including any one element alone or in combination with one or more of the other elements which may also include, in combination, additional elements not listed.

Claim 1:
A computer implemented method for message data recordation for a sequence of communication events, the computer implemented method comprising:
receiving (<NUM>), via a network interface, by a communication processor, an originating message for an initial communication event of the sequence of communication events;
parsing (<NUM>), by the communication processor, the originating message for the initial communication event to extract message data for the initial communication event, the extracted message data specifying a first group of participants to which the originating message for the initial communication event is visible;
storing (<NUM>), by the communication processor, the extracted message data in a blockchain data structure for the sequence of communication events, the blockchain data structure being replicated by a respective communication processor of each participant of the first group of participants in a respective memory coupled to the respective communication processor;
receiving (<NUM>), by the communication processor, a responsive message of a further communication event in the sequence of communication events in response to the originating message, the responsive message comprising responsive message data, the responsive message data comprising permissioning data, the permissioning data specifying a second group of participants to which the responsive message is visible, the second group differing from the first group;
creating (<NUM>), by the communication processor, a subsidiary blockchain data structure of the blockchain data structure to support privacy of the responsive message in accordance with the permissioning data;
storing (<NUM>), by the communication processor, the responsive message data in the subsidiary blockchain data structure;
determining (<NUM>), by the communication processor, whether the sequence of communication events is complete by detecting whether the responsive message data comprises a keyword indicative of completion;
if the sequence of communication events is complete, anchoring (<NUM>) the subsidiary blockchain data structure to the blockchain data structure; and
disseminating (<NUM>) a notification of a completion of the sequence of communication events to the first group of participants without disclosing message data stored in the subsidiary blockchain data structure.