DETAILED ACTION
Response to Amendment
The amendment filed on June 5, 2026, has been entered. Applicant has amended claims 1, 5, 9-11, 14-15, and 17-20. Claims 1-20 remain pending, have been examined and currently stand rejected.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Specification
The amendment to the Specification filed June 5, 2026, is acceptable and has been entered.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “404” has been used to designate both a “Trade Processing/Aggregator/reporting Tool”, as seen in Figure 4, and a “allocation recon tool”, as described in reference to Figure 4 in paragraph [0051] of the Specification.
It is unclear what relationship, if any, the “Trade Processing/Aggregator/reporting Tool” has with the “allocation recon tool” described in the Specification. Examiner notes that the “Trade Processing/Aggregator/reporting Tool”, which is depicted in Figure 4, is not described, nor mentioned, with respect to Figure 4 (See Specification [0051]). In fact, the Specification fails to explicitly recite a “Trade Processing/Aggregator/reporting Tool.” The disclosure recites a “trade processing reporting tool” (Specification [0028]), however this term is only recited one time in the entire disclosure, and the disclosure fails to provide any nexus between the “trade processing reporting tool” and Figure 4. Furthermore, paragraph [0051] of the Specification, which describes Figure 4, describes the use of an “interaction constraint module 124” and an “allocation recon tool 404”, however neither of these items are illustrated in Figure 4.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claims 2 and 20 are objected to for the following informalities:
Claims 2 and 20 recite the limitation “the allocation recon tool” as in “wherein the standardized schema is generated based on artifact comparison results provided by the allocation recon tool communicating with the interaction constraint module.” There is insufficient antecedent basis for this limitation in the claim(s). In order to further prosecution, the limitation “the allocation recon tool” has been interpreted as reciting “an allocation recon tool.”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-17 and 20 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor at the time the application was filed, had possession of the claimed invention.
Regarding Claims 1 and 20: Claim 1 recites, in part, “normalizing, by the at least one processor and via the single gateway module, data associated with an artifact subject to transfer between the at least two entities into a format compatible with the interaction session, wherein the normalization comprises converting the artifact data into a standardized schema for processing by the interaction constraint module, […].” Examiner has reviewed applicant’s disclosure and is unable to find support for the newly added limitation reciting “wherein the normalization comprises converting the artifact data into a standardized schema for processing by the interaction constraint module” (i.e., the amendment introduces new matter). Applicant’s disclosure provides very limited details pertaining to the “normalization” process. In fact, the disclosure only recites/describes normalization in a single sentence, where the disclosure indicates that “the single data gateway tool may normalize the data associated with the artifact subject to the transfer between the entities.” Specification [0033]. Applicant’s disclosure also describes displaying data associated with data schemas (Specification [0034]) and defining schemas in a database management system (DBMS) (Specification [0061]). While the disclosure broadly describes the limited use of schemas, the disclosure fails to associate the use of schemas with the normalization process (e.g., wherein the normalization comprises converting the artifact data into a standardized schema). Additionally, the disclosure fails to provide any apparent connection between the normalization process, schemas (e.g., standardized schemas) and subsequent processing by the interaction constraint module. Accordingly, the disclosure fails to show that applicant had support/possession for the limitation reciting “wherein the normalization comprises converting the artifact data into a standardized schema for processing by the interaction constraint module.”
Claim 20 recites the same limitation as that found in claim 1, accordingly claim 20 is also rejected under 35 U.S.C. 112(a) for the same reasons and rational described above. Claims 2-17 are also rejected under 35 U.S.C. 112(a) based on their dependency to claim 1.
Regarding Claims 1 and 20: Claim 1 recites, in part, ““normalizing, by the at least one processor and via the single gateway module, data associated with an artifact subject to transfer between the at least two entities into a format compatible with the interaction session, wherein the normalization comprises converting the artifact data into a standardized schema for processing by the interaction constraint module, wherein the standardized schema is generated based on artifact comparison results provided by the allocation recon tool communicating with the interaction constraint module.” Examiner has reviewed applicant’s disclosure and is unable to find support for the newly added limitation reciting “wherein the standardized schema is generated based on artifact comparison results provided by the allocation recon tool communicating with the interaction constraint module” (i.e., the amendment introduces new matter). As indicated above, Applicant’s disclosure only recites/describes normalization in a single sentence, where the disclosure indicates that “the single data gateway tool may normalize the data associated with the artifact subject to the transfer between the entities.” Specification [0033]. Applicant’s disclosure also describes displaying data associated with data schemas (Specification [0034]) and defining schemas in a database management system (DBMS) (Specification [0061]). While the disclosure broadly describes the limited use of schemas, the disclosure fails to provide any indication that the standardized schema is generated based on artifact comparison results (e.g., results provided by the allocation recon tool communication with the interaction constraint module). Additionally, while the disclosure indicates that “the interaction constraint module 400 may utilize the plurality of trading related inputs 402 to compare artifact transfers associated with the inputs and any transfers associated with an interaction session” and “the interaction constraint module 124 may communicate with an allocation recon tool 404 that may be capable of comparing a plurality of requests to identify a plurality of data breaks,” there is no nexus in the disclosure between these comparisons and generating a standardized schema. Furthermore, the disclosure is completely silent with respect to the terminology “standardized schema”, “artifact comparison results”, and “comparison results,” and Examiner is unable to locate any related terminology or description associated with comparisons and the generation of a schema. Accordingly, the disclosure fails to show that applicant had support/possession for the limitation reciting “wherein the standardized schema is generated based on artifact comparison results provided by the allocation recon tool communicating with the interaction constraint module.”
Claim 20 recites the same limitation as that found in claim 1, accordingly claim 20 is also rejected under 35 U.S.C. 112(a) for the same reasons and rational described above. Claims 2-17 are also rejected under 35 U.S.C. 112(a) based on their dependency to claim 1.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7, 9-11, 13-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kavanagh (US 2022/0141101 A1) in view of Mohanty et al. (US 2023/0067084 A1) (hereinafter “Mohanty”).
Regarding Claim 1: Kavanagh discloses a computer-implemented method comprising:
identifying, by at least one processor, a plurality of entities seeking to interact with each other (See at least Kavanagh [0032]; Fig. 2. Kavanagh discloses identifying, by at least one processor, a plurality of entities (i.e., customers/clients) seeking to interact with each other while matching transaction request messages.);
determining, by the at least one processor, a set of artifacts associated with each entity of the plurality of entities based on a result of an interaction constraint module (See at least Kavanagh [0032]; [0065]; [0071]. Kavanagh discloses determining, by the at least one processor, a set of artifacts (i.e., data objects) associated with each entity of the plurality of entities (i.e., associated with each customer/client of the plurality of customers/clients) based on a result of an interaction constraint module (i.e., of a portion of software, e.g., a match engine).);
dynamically connecting, by the at least one processor, at least two entities using an integration service layer comprising a single gateway module based on a determination of the set of artifacts shared between the at least two entities (See at least Kavanagh [0032]; [0062]; [0065]; [0088]; [0207]. Kavanagh discloses dynamically connecting (e.g., during the matching), by the at least one processor, at least two entities (i.e., at least two customers/clients) using an integration service layer comprising a single gateway module (i.e., a portion of software comprising one or more algorithms, e.g., a match engine at a Market Segment Gateway (MSG)) based on a determination of the set of artifacts shared (i.e., based on request messages for the same one of the data items or objects matching) between the at least two entities.);
dynamically integrating, by the at least one processor and in response to connecting the at least two entities, a plurality of protocols into an interaction session associated with the at least two entities, wherein the plurality of protocols associated with the interaction session comprise requirements to connect received from each entity of the plurality of entities (See at least Kavanagh [0032]; [0071]; [0130]; [0148]; [0156]. Kavanagh discloses dynamically integrating, by the at least one processor and in response to connecting (i.e., in response to connecting during the matching) the at least two entities, a plurality of protocols (i.e., transaction matching parameters, e.g., a buy and a sell parameter) into an interaction session (i.e., a trade session) associated with the at least two entities, wherein the plurality of protocols (i.e., transaction matching parameters) associated with the interaction session comprise requirements to connect (i.e., transaction requirements, e.g., identifying the product, the quantity, a price, the direction of the order) received from each entity of the plurality of entities (i.e., received from each customer/client, e.g., a trader).);
normalizing, by the at least one processor and via the single gateway module, data associated with an artifact subject to transfer between the at least two entities into a format compatible with the interaction session (See at least Kavanagh [0209]; [0213]. Kavanagh discloses normalizing (i.e., by converting into a message format), by the at least one processor and via the single gateway module (i.e., by a portion of software comprising one or more algorithms, e.g., a match engine at a Market Segment Gateway (MSG), which comprises a conversion component), data associated with an artifact subject (i.e., data associated with a data object, e.g., a message associated with a data object) to transfer between the at least two entities into a format compatible with the interaction session (i.e., “into a message format that can be input into the pre-match queue”).);
wherein the normalization comprises converting the artifact data into a standardized schema for processing by the interaction constraint module (See at least Kavanagh [0209]; [0213-0215]. Kavanagh discloses wherein the normalization (i.e., converting into a message format) comprises converting the artifact data (i.e., converting the data associated with the data object, e.g., converting the message associated with the data object) into a standardized schema (i.e., into a message format) for processing by the interaction constraint module (i.e., for processing by a portion of software, e.g., the match engine/component).);
verifying, by the at least one processor, the plurality of protocols associated with the interaction session, wherein verifying the plurality of protocols comprising ensuring a number of shared requirements from the plurality of entities exceed a predetermined threshold (See at least Kavanagh [0068]; [0153]; Kavanagh Claim 11. Kavanagh discloses verifying, by the at least one processor, the plurality of protocols (i.e., transaction matching parameters) associated with the interaction session (i.e., associated with the trade session), wherein verifying the plurality of protocols comprising ensuring a number of shared requirements from the plurality of entities exceed a predetermined threshold (i.e., by matching the opposite transactions based on a same or better price, the same quantity, minimum quantities, etc.).);
initiating, by the at least one processor, the interaction session between at least two entities based on the plurality of protocols and the set of artifacts (See at least Kavanagh [0071]; [0130]. Kavanagh discloses initiating (i.e., enacting), by the at least one processor, the interaction session (i.e., trading session) between at least two entities (i.e., traders) based on the plurality of protocols (i.e., transaction matching parameters) and the set of artifacts (i.e., data objects, e.g., products, financial instruments, order books).); and
automatically modifying, by the at least one processor, the interaction session to orchestrate a transfer of at least one artifact of the set of artifacts shared between the at least two entities (See at least Kavanagh [0041]; [0043]; [0071]. Kavanagh discloses automatically modifying, by the at least one processor, the interaction session (e.g., by sending one or more messages regarding the match) to orchestrate a transfer (i.e., trade) of at least one artifact (i.e., of at least one data object, e.g., product, financial instrument, order book) of the set of artifacts shared between the at least two entities (i.e., traders).).
Kavanagh does not explicitly disclose wherein the integration service layer communicates with the single gateway module, an API management module, a notification hub, a data translation layer, and at least one backbridge layer. However, Kavanagh teaches that the disclosed mechanisms may be implemented at any logical and/or physical point(s), or combinations thereof, at which the relevant information/data (e.g., message traffic and responses thereto) may be monitored or flows or is otherwise accessible or measurable, including one or more gateway devices, modems, the computers or terminals of one or more market participants, e.g., client computers, etc. Kavanagh [0099]. Kavanagh further teaches that modules may be implemented as software code, firmware code, specifically configured hardware or processors, and/or a combination of the aforementioned. Kavanagh [0100]. Kavanagh indicates that the modules may be embodied as part of an exchange for financial instruments, and that the disclosed embodiments may be implemented as a different or separate module of the exchange computer system, or a separate computer system coupled with the exchange computer system so as to have access to margin account record, pricing, and/or other data. Kavanagh [0100]. Kavanagh states that the disclosed embodiments may be implemented as a centrally accessible system or as a distributed system, e.g., where some of the disclosed functions are performed by the computer systems of the market participants. Kavanagh [0100]. Kavanagh further states that 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, firm-ware, microcode and the like, operating alone or in combination. Kavanagh [0111]. Accordingly, Kavanagh teaches that it was known in the art to have various pieces of hardware and/or software communicate with each other in order to accomplish specific tasks.
In view of the teachings provided by Kavanagh, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein the integration service layer communicates with the single gateway module, an API management module, a notification hub, a data translation layer, and at least one backbridge layer. One of ordinary skill in the art would have been motivated to include such features in order to provide one or more modules, computer software, computer firmware and/or computer hardware needed to implement the functional operations described by Kavanagh (Kavanagh [0117]). It is also noted that the mere fact that the integration service layer communicates with these computing modules/hubs/layers has no direct impact on how any of the positively recited steps are performed. For example, the at least two entities are not dynamically connected in a different/specific manner simply because the integration service layer may communicate at some point with another module/hub/layer.
As indicated above, Kavanagh discloses normalizing (i.e., by converting into a message format) data associated with an artifact subject (i.e., data associated with a data object, e.g., a message associated with a data object) to transfer between the at least two entities into a format compatible with the interaction session (i.e., “into a message format that can be input into the pre-match queue”), wherein the normalization (i.e., converting into a message format) comprises converting the artifact data (i.e., converting the data associated with the data object, e.g., converting the message associated with the data object) into a standardized schema (i.e., into a message format) for processing by the interaction constraint module (i.e., for processing by a portion of software, e.g., the match engine/component). Kavanagh [0209]; [0213-0215]. Kavanagh also indicates that exchanged data/messages could be formatted, arranged, configured and/or packaged based on one or more protocols. Kavanagh [0128]. However, Kavanagh also fails to explicitly disclose wherein the standardized schema is generated based on artifact comparison results provided by the allocation recon tool communicating with the interaction constraint module.
Mohanty, on the other hand, who is also concerned with the standardization of data, teaches wherein the standardized schema is generated based on artifact comparison results provided by the allocation recon tool communicating with the interaction constraint module (See at least Mohanty [0087-0089]. Mohanty discloses wherein the standardized schema (i.e., standard data format) is generated based on artifact comparison results (i.e., based on a set of standard data formats associated with the identified set of entities) provided by the allocation recon tool communicating with the interaction constraint module (i.e., provided by the data collector communicating with the entity categorizer).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mohanty into Kavanagh’s method of converting messages into a standard format. One of ordinary skill in the art would have been motivated to include such features in order to standardize information/data based on formats associated with the entities involved (Mohanty [0088]).
Regarding Claim 2: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses wherein each entity is a server computing device associated with a financial institution (See at least Kavanagh [0032]; [0109] “the computer system 200 may operate in the capacity of a server”. Kavanagh discloses wherein each entity (i.e., trader) is a server computing device (i.e., a trader/customer/user computer, which may operate as a server) associated with a financial institution (i.e., this is indicated by the fact that the computer is used to buy/sell financial instruments).).
Regarding Claim 3: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses wherein the artifact comprises a digitally transferable data item (See at least Kavanagh [0032]; [0034]. Kavanagh discloses wherein the artifact (i.e., object) comprises a digitally transferable data item (e.g., product, financial instrument, order book).).
Regarding Claim 4: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses wherein the determination of the set of artifacts comprises utilizing the interaction constraint module to analyze any shared artifacts between the at least two entities (See at least Kavanagh [0032]; [0042-0043]; [0067]; [0070-0071]. Kavanagh discloses wherein the determination of the set of artifacts (i.e., data objects, e.g., products, financial instruments, order books) comprises analyzing any shared artifacts between the at least two entities (e.g., by matching the same items/objects/instruments) based on one or more data breaks (i.e., resting orders) associated with each artifact via the interaction constraint module. Note that Applicant’s disclosure (Specification [0028]) indicates that “data breaks may refer to a time of non-action associated with each artifact”, accordingly Kavanaghs resting orders reads on the claimed data break.).
Regarding Claim 5: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses wherein the integration service layer comprises a digital network capable of facilitating a digital interaction between a plurality of computing devices (See at least Kavanagh [0085] “An exemplary trading network environment for implementing trading systems and methods is shown in FIG. 1. An exchange computer system 100 receives messages that include orders and transmits market data related to orders and trades to users, such as via wide area network 162 and/or local area network 160 and computer devices 150, 152, 154, 156 and 158, as described herein, coupled with the exchange computer system 100.”; Fig. 1.).
Regarding Claim 6: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses wherein the dynamic integration of the plurality of protocols comprises utilizing a rules engine to identify data breaks in the set of artifacts for subsequent comparison with a plurality of artifact requests (See at least Kavanagh [0042] “an electronic order book may be understood to be an electronic collection of the outstanding or resting orders for a financial instrument”; [0043]; [0070-0071] “A match event may occur, for example, when an aggressing order matches with a resting order”. Kavanagh discloses wherein the dynamic integration of the plurality of protocols comprises utilizing a rules engine (i.e., a match engine, which determines a match event has occurred if a resting order matches a new order) to identify data breaks (i.e., resting orders) in the set of artifacts (i.e., in the set of data objects, e.g., products, financial instruments, order books) for subsequent comparison with a plurality of artifact requests. Note that Applicant’s disclosure (Specification [0028]) indicates that “data breaks may refer to a time of non-action associated with each artifact”, accordingly Kavanaghs resting orders reads on the claimed data break.).
Regarding Claim 7: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses wherein the interaction session comprises a secure digital marketplace that allows an entity to exchange the artifact for data (See at least Kavanagh [0033-0034] “one exemplary environment where the disclosed embodiments may be desirable is in financial markets, and in particular, electronic financial exchanges, such as a futures exchange, such as the Chicago Mercantile Exchange Inc. (CME).”. Kavanagh discloses wherein the interaction session comprises a secure digital marketplace (i.e., an exchange) that allows an entity (i.e., trader) to exchange (i.e., trade) the artifact (i.e., data object, e.g., product, financial instrument, order book) for data (e.g., a price/amount).).
Regarding Claim 9: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses predicting a likelihood associated with a successful transfer of a particular artifact between the at least two entities based on a result of the integration service layer (See at least Kavanagh [0090] “A risk management module 114 may be included to compute and determine a user's risk utilization in relation to the user's defined risk thresholds. The risk management module 114 may also be configured to determine risk assessments or exposure levels in connection with positions held by a market participant”; [0160]. Kavanagh discloses predicting a likelihood associated with a successful transfer of a particular artifact between the at least two entities (i.e., to determine risk assessments or exposure levels in connection with positions held by a market participants, which imply the likely hood of a successful transfer) based on a result (e.g., an assessment) of the integration service layer.).
Regarding Claim 10: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses wherein the integration service layer comprises:
an API management module (See at least Kavanagh [0129] “disclosed message management system may be implemented using an open message standard implementation, such as FIX, FIX Binary, FIX/FAST, or by an exchange-provided API”. Note that the message management system may be implemented by an exchange provided API.);
a data workstation framework (See at least Kavanagh [0101] “The trading network environment shown in FIG. 1 includes exemplary computer devices 150, 152, 154, 156 and 158 which depict different exemplary methods or media by which a computer device may be coupled with the exchange computer system 100 or by which a user may communicate, e.g., send and receive, trade or other information therewith”. Where computer devices 150, 152, 154, 156 and 158 = a data workstation framework);
a data translation layer (See at least Kavanagh [0013] “monitoring processing of messages in a data transaction processing system by logging information, i.e., tracer entries, about those messages as they are processed through the data transaction processing system. In particular, the disclosed monitoring system assigns reusable identifiers to in-flight messages and minimizes the amount of information that is collected”. Monitoring system = data translation layer); and
at least one backbridge layer (See at least Kavanagh [0209] “Match engine module 106 may include a conversion component 402”; [0213] “The conversion component 402 converts or extracts a message received from a trader via the Market Segment Gateway or MSG into a message format that can be input into the pre-match queue 404”. Where the conversion component = at least one backbridge layer since it converts or extracts a message into a particular message format.).
Regarding Claim 11: The combination of Kavanagh and Mohanty discloses the method of claim 9. Kavanagh further discloses wherein predicting the likelihood of the successful transfer comprises dynamically predicting that each entity can meet requirements without modifying the plurality of protocols for subsequent artifact transfers (See at least Kavanagh [0068] “either order specifies a condition that it must be entirely filled”; [0071] “two orders match because one order includes instructions for or specifies buying a quantity of a particular instrument at a particular price, and the other order includes instructions for or specifies selling a ( different or same) quantity of the instrument at a same or better price”. Kavanagh discloses wherein predicting the likelihood of the successful transfer comprises dynamically predicting that each entity can meet requirements (i.e., that each trader can meet the buying/selling parameters) without modifying the plurality of protocols for subsequent artifact transfers (i.e., indicated by the fact that the order can be entirely filled, thus the order is not modified).).
Regarding Claim 13: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses:
systemically capturing at least one predicted artifact transfer of a particular artifact that fails to match the verified plurality of protocols (See at least Kavanagh [0069] “Previously received but unsatisfied orders, i.e., orders which either did not match with a counter order when they were received or their quantity was only partially satisfied, referred to as a partial fill, are maintained by the electronic trading system in an order book database/data structure to await the subsequent arrival of matching orders or the occurrence of other conditions which may cause the order to be modified or otherwise removed from the order book”. Kavanagh discloses systemically capturing at least one predicted artifact transfer of a particular artifact that fails to match the verified plurality of protocols when it maintains an unmatched order.); and
generating a plurality of systematic reports associated with a plurality of predicted artifact transfers and requests for artifact transfers that are automatically verified within the predetermined period of time (See at least Kavanagh [0032] “The specifically configured matching processors may additionally generate information indicative of a state of an environment (e.g., the state of the order book) based on the processing, and report this information to data recipient computing systems via outbound messages published via one or more data feeds”; [0036] “An exchange may provide for a centralized "clearing house" through which trades made must be confirmed, matched, and settled each day until offset or delivered. The clearing house may be an adjunct to an exchange, and may be an operating division of an exchange, which is responsible for settling trading accounts, clearing trades, collecting and maintaining performance bond funds, regulating delivery, and reporting trading data”. Kavanagh discloses generating a plurality of systematic reports (i.e., generating information/reporting trading data) associated with a plurality of predicted artifact transfers (i.e., trades) and requests for artifact transfers (i.e., orders) that are automatically verified within the predetermined period of time (e.g., each day).).
Regarding Claim 14: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses: determining a particular data sleeve associated with each entity based on one or more preferences, wherein the particular data sleeve contains protocol preferences and predetermined artifact transfer rules (See at least Kavanagh [0032] “the electronic data transaction request messages may include, for example, transaction matching parameters, such as instructions and/or values, for processing the data transaction request messages within the data transaction processing system. The instructions may be to perform transactions, e.g., buy or sell a quantity of a product at a range of values defined equations”; [0078] “The clearing house establishes clearing level performance bonds (margins) for all products of the exchange and establishes minimum performance bond requirements for customers of such products. A performance bond, also referred to as a margin requirement, corresponds with the funds that must be deposited by a customer with his or her broker, by a broker with a clearing member or by a clearing member with the clearing house, for the purpose of insuring the broker or clearing house against loss on open futures or options contracts. This is not a part payment on a purchase. The performance bond helps to ensure the financial integrity of brokers, clearing members and the exchange as a whole. The performance bond refers to the minimum dollar deposit required by the clearing house from clearing members in accordance with their positions.”; [0218]. Kavanagh discloses determining a particular data sleeve (i.e., a purchase/trade) associated with each entity based on one or more preferences (e.g., transaction matching parameters), wherein the particular data sleeve contains protocol preferences (i.e., transaction matching parameters) and predetermined artifact transfer rules (i.e., a performance bond/margin requirement, which requires a customer to keep certain amount of funds with the broker based on the products purchased).).
Regarding Claim 15: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses:
receiving the plurality of artifact transfers related inputs (See at least Kavanagh [0040] “Financial messages communicated to the electronic trading system, also referred to as "inbound" messages, may include associated actions that characterize the messages, such as trader orders, order modifications, order cancellations and the like, as well as other message types”; [0065]; [0071]. Kavanagh discloses receiving the plurality of artifact transfers related inputs (i.e., inbound messages).);
comparing the plurality of artifact transfers to a plurality of transfer related inputs to determine additional inputs and common artifacts transfers associated with the interaction session (See at least Kavanagh [0070] “If the match engine identifies one or more suitable previously received but unsatisfied counter orders, they, and the incoming order, are matched to execute a trade there between to at least partially satisfy the quantities of one or both the incoming order or the identified orders. If there remains any residual unsatisfied quantity of the identified one or more orders, those orders are left on the order book with their remaining quantity to await a subsequent suitable counter order, i.e., to rest. If the match engine does not identify a suitable previously received but unsatisfied counter order, or the one or more identified suitable previously received but unsatisfied counter orders are for a lesser quantity than the incoming order, the incoming order is placed on the order book, referred to as "resting'', with original or remaining unsatisfied quantity, to await a subsequently received suitable order counter thereto. The match engine then generates match event data reflecting the result of this matching process”; [0088] “A match engine module 106 may be included to match bid and offer prices and may be implemented with software that executes one or more algorithms for matching bids and offers”. Kavanagh discloses comparing the plurality of artifact transfers (i.e., previously received, unsatisfied orders) to a plurality of transfer related inputs (i.e., to a current order) to determine additional inputs and common artifacts transfers associated with the interaction session (i.e., to determine residual unsatisfied quantities of one or more orders associated with the trading session).);
identifying a plurality of data breaks associated with a comparison of the plurality of artifact transfers to the plurality of transfer related inputs (See at least Kavanagh [0040]; [0042] “an electronic order book may be understood to be an electronic collection of the outstanding or resting orders for a financial instrument”; [0043] “a request to place a trade may result in a response indicative of the trade either being matched with, or being rested on an order book to await, a suitable counter-order”; [0071] “A match event may occur, for example, when an aggressing order matches with a resting order”. Kavanagh discloses identifying a plurality of data breaks (i.e., resting orders) associated with a comparison of the plurality of artifact transfers (i.e., previously received, unsatisfied orders) to the plurality of transfer related inputs (i.e., to a current/new order).);
automatically tracing an age associated with each request of the plurality of artifact transfers within a request repository (See at least Kavanagh [0013] “The disclosed embodiments generally relate to methods and systems for monitoring processing of messages in a data transaction processing system by logging information, i.e., tracer entries, about those messages as they are processed through the data transaction processing system […] The monitoring system also includes a parser that parses, e.g., during post-processing, or after a message has been processed by the application, the data structure to determine tracer entries associated with the same message for performance analysis of the progress of the message through the code”; [0016] “The data store may be separate from the messages that are processed by the data transaction processing system, such that as tracer entries associated with a message are accumulated and stored in the data store”; [0040] “Financial messages communicated to the electronic trading system, also referred to as "inbound" messages, may include associated actions that characterize the messages, such as trader orders, order modifications, order cancellations and the like, as well as other message types”; [0247] “Each tracer entry may include data based on [...] (ii) a checkpoint in the application 512 traversed by the message, such as checkpoints 412 and 414, and (iii) timestamp information about a current timestamp, or a time when the message traversed the checkpoint”. Kavanagh discloses automatically tracing an age associated with each request (i.e., a time when the message traversed the checkpoint) of the plurality of artifact transfers within a request repository (i.e., within a data store).); and
generating a plurality of systemic notices to ensure the plurality of artifact transfers are submitted within a predetermined period of time (See at least Kavanagh [0032] “The specifically configured matching processors may additionally generate information indicative of a state of an environment ( e.g., the state of the order book) based on the processing, and report this information to data recipient computing systems via outbound messages published via one or more data feeds”; [0036] “An exchange may provide for a centralized "clearing house" through which trades made must be confirmed, matched, and settled each day until offset or delivered. The clearing house may be an adjunct to an exchange, and may be an operating division of an exchange, which is responsible for settling trading accounts, clearing trades, collecting and maintaining performance bond funds, regulating delivery, and reporting trading data”. Kavanagh discloses generating a plurality of systemic notices (i.e., reporting trading data) to ensure the plurality of artifact transfers are submitted within a predetermined period of time (i.e., each day).).
Regarding Claim 16: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses initiating a secure interaction session between the at least two entities based on a result of the interaction constraint module (See at least Kavanagh [0070-0071]; [0092] “The message management module 116 may also be configured to detect characteristics of an order for a transaction to be undertaken in an electronic marketplace”; [0121] “standards for Internet and other packet switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP, HTTPS) represent examples of the state of the art. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same or similar functions as those disclosed herein are considered equivalents thereof”; [0130] “The embodiments described herein utilize trade related electronic messages such as mass quote messages, individual order messages, modification messages, cancellation messages, etc., so as to enact trading activity in an electronic market. The trading entity and/or market participant may have one or multiple trading terminals associated with the session”. Kavanagh discloses initiating a secure interaction session (i.e., an HTTPS session) between the at least two entities based on a result (e.g., a match) of the interaction constraint module (i.e., of the portion of software, e.g., the match engine).).
Regarding Claim 17: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses displaying, by the at least one processor, a notification associated with the artifact transfer within the interaction session via a data workstation framework (See at least Kavanagh [0032] “The specifically configured matching processors may additionally generate information indicative of a state of an environment (e.g., the state of the order book) based on the processing, and report this information to data recipient computing systems via outbound messages published via one or more data feeds”; [0041] “Financial messages communicated from the electronic trading system, referred to as "outbound" messages, may include messages responsive to inbound messages, such as confirmation messages, or other messages such as market update messages, quote messages, and the like. Outbound messages may be disseminated via data feeds”. Kavanagh discloses displaying, by the at least one processor, a notification (i.e., message) associated with the artifact transfer (i.e., trade) within the interaction session (e.g., via a data feed) via a data workstation framework (i.e., computing system(s)).).
Regarding Claim 20: Kavanagh discloses a system comprising:
a non-transitory computer memory, storing software instructions (See at least Kavanagh [0100] “one or more modules described herein may be implemented using, among other things, a tangible computer-readable medium comprising computer-executable instructions (e.g., executable software code”; [0111]);
at least one processor of a computing device associated with an entity (See at least Kavanagh [0101] “The trading network environment shown in FIG. 1 includes exemplary computer devices 150, 152, 154, 156 and 158 [...] Each computer device, which may comprise a computer 200 described in more detail with respect to FIG. 2, may include a central processor”; [0110]);
wherein, when the at least one processor executes the software instructions, the computing device is programmed to (See at least Kavanagh [0110] “As illustrated in FIG. 2, the computer system 200 may include a processor 202 ... The processor 202 may implement a software program, such as code generated manually (i.e., programmed)”; [0111] “the functions, acts or tasks illustrated in the figures or described herein may be performed by the programmed processor 202 executing the instructions 212 stored in the memory 204”):
identify a plurality of entities seeking to interact with each other (See at least Kavanagh [0032]; Fig. 2. Kavanagh discloses identifying a plurality of entities (i.e., customers/clients) seeking to interact with each other while matching transaction request messages.);
determine a set of artifacts associated with each entity of the plurality of entities (See at least Kavanagh [0032]. Kavanagh discloses determining a set of artifacts (i.e., data objects) associated with each entity of the plurality of entities (i.e., associated with each customer/client of the plurality of customers/clients).);
dynamically connect at least two entities using an integration service layer comprising a single gateway module based on a determination of a set of artifacts shared between the at least two entities (See at least Kavanagh [0032]; [0062]; [0065]; [0088]; [0207]. Kavanagh discloses dynamically connecting (e.g., during the matching) at least two entities (i.e., at least two customers/clients) using an integration service layer comprising a single gateway module (i.e., a portion of software comprising one or more algorithms, e.g., a match engine at a Market Segment Gateway (MSG)) based on a determination of the set of artifacts shared (i.e., based on request messages for the same one of the data items or objects matching) between the at least two entities.);
dynamically integrate, and in response to connecting the at least two entities, a plurality of protocols into an interaction session associated with the at least two entities, wherein the plurality of protocols associated with the interaction session comprise requirements to connect received from each entity of the plurality of entities (See at least Kavanagh [0032]; [0071]; [0130]; [0148]; [0156]. Kavanagh discloses dynamically integrating, and in response to connecting (i.e., in response to connecting during the matching) the at least two entities, a plurality of protocols (i.e., transaction matching parameters, e.g., a buy and a sell parameter) into an interaction session (i.e., a trade session) associated with the at least two entities, wherein the plurality of protocols (i.e., transaction matching parameters) associated with the interaction session comprise requirements to connect (i.e., transaction requirements, e.g., identifying the product, the quantity, a price, the direction of the order) received from each entity of the plurality of entities (i.e., received from each customer/client, e.g., a trader).);
verify the plurality of protocols associated with the interaction session, wherein a verification of the plurality of protocols comprising ensuring a number of shared requirements from the plurality of entities exceed a predetermined threshold (See at least Kavanagh [0068]; [0153]; Kavanagh Claim 11. Kavanagh discloses verifying the plurality of protocols (i.e., transaction matching parameters) associated with the interaction session (i.e., associated with the trade session), wherein verifying the plurality of protocols comprising ensuring a number of shared requirements from the plurality of entities exceed a predetermined threshold (i.e., by matching the opposite transactions based on a same or better price, the same quantity, minimum quantities, etc.).);
normalize, via the single gateway module, data associated with an artifact subject to transfer between the at least two entities into a format compatible with the interaction session (See at least Kavanagh [0209]; [0213]. Kavanagh discloses normalizing (i.e., by converting into a message format), via the single gateway module (i.e., by a portion of software comprising one or more algorithms, e.g., a match engine at a Market Segment Gateway (MSG), which comprises a conversion component), data associated with an artifact subject (i.e., data associated with a data object, e.g., a message associated with a data object) to transfer between the at least two entities into a format compatible with the interaction session (i.e., “into a message format that can be input into the pre-match queue”).);
wherein the normalization comprises converting the artifact data into a standardized schema for processing by the interaction constraint module (See at least Kavanagh [0209]; [0213-0215]. Kavanagh discloses wherein the normalization (i.e., converting into a message format) comprises converting the artifact data (i.e., converting the data associated with the data object, e.g., converting the message associated with the data object) into a standardized schema (i.e., into a message format) for processing by the interaction constraint module (i.e., for processing by a portion of software, e.g., the match engine/component).);
initiate the interaction session between at least two entities based on the plurality of protocols and the set of artifacts (See at least Kavanagh [0071]; [0130]. Kavanagh discloses initiating (i.e., enacting) the interaction session (i.e., trading session) between at least two entities (i.e., traders) based on the plurality of protocols (i.e., transaction matching parameters) and the set of artifacts (i.e., data objects, e.g., products, financial instruments, order books).); and
automatically modify the interaction session to orchestrate a transfer of at least one artifact of the set of artifacts between the at least two entities (See at least Kavanagh [0041]; [0043]; [0071]. Kavanagh discloses automatically modifying the interaction session (e.g., by sending one or more messages regarding the match) to orchestrate a transfer (i.e., trade) of at least one artifact (i.e., of at least one data object, e.g., product, financial instrument, order book) of the set of artifacts between the at least two entities (i.e., traders).).
Kavanagh does not explicitly disclose wherein the integration service layer communicates with the single gateway module, an API management module, a notification hub, a data translation layer, and at least one backbridge layer. However, Kavanagh teaches that the disclosed mechanisms may be implemented at any logical and/or physical point(s), or combinations thereof, at which the relevant information/data (e.g., message traffic and responses thereto) may be monitored or flows or is otherwise accessible or measurable, including one or more gateway devices, modems, the computers or terminals of one or more market participants, e.g., client computers, etc. Kavanagh [0099]. Kavanagh further teaches that modules may be implemented as software code, firmware code, specifically configured hardware or processors, and/or a combination of the aforementioned. Kavanagh [0100]. Kavanagh indicates that the modules may be embodied as part of an exchange for financial instruments, and that the disclosed embodiments may be implemented as a different or separate module of the exchange computer system, or a separate computer system coupled with the exchange computer system so as to have access to margin account record, pricing, and/or other data. Kavanagh [0100]. Kavanagh states that the disclosed embodiments may be implemented as a centrally accessible system or as a distributed system, e.g., where some of the disclosed functions are performed by the computer systems of the market participants. Kavanagh [0100]. Kavanagh further states that 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, firm-ware, microcode and the like, operating alone or in combination. Kavanagh [0111]. Accordingly, Kavanagh teaches that it was known in the art to have various pieces of hardware and/or software communicate with each other in order to accomplish specific tasks.
In view of the teachings provided by Kavanagh, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein the integration service layer communicates with the single gateway module, an API management module, a notification hub, a data translation layer, and at least one backbridge layer. One of ordinary skill in the art would have been motivated to include such features in order to provide one or more modules, computer software, computer firmware and/or computer hardware needed to implement the functional operations described by Kavanagh (Kavanagh [0117]). It is also noted that the mere fact that the integration service layer communicates with these computing modules/hubs/layers has no direct impact on how any of the positively recited steps are performed. For example, the at least two entities are not dynamically connected in a different/specific manner simply because the integration service layer may communicate at some point with another module/hub/layer. Furthermore, the claimed system does not comprise the integration service layer, the single gateway module, the API module, the notification hub, the data translation layer or the at least one backbridge layer, accordingly any details describing how these components communicate is outside the scope of the claimed invention.
As indicated above, Kavanagh discloses normalizing (i.e., by converting into a message format) data associated with an artifact subject (i.e., data associated with a data object, e.g., a message associated with a data object) to transfer between the at least two entities into a format compatible with the interaction session (i.e., “into a message format that can be input into the pre-match queue”), wherein the normalization (i.e., converting into a message format) comprises converting the artifact data (i.e., converting the data associated with the data object, e.g., converting the message associated with the data object) into a standardized schema (i.e., into a message format) for processing by the interaction constraint module (i.e., for processing by a portion of software, e.g., the match engine/component). Kavanagh [0209]; [0213-0215]. Kavanagh also indicates that exchanged data/messages could be formatted, arranged, configured and/or packaged based on one or more protocols. Kavanagh [0128]. However, Kavanagh also fails to explicitly disclose wherein the standardized schema is generated based on artifact comparison results provided by the allocation recon tool communicating with the interaction constraint module.
Mohanty, on the other hand, who is also concerned with the standardization of data, teaches wherein the standardized schema is generated based on artifact comparison results provided by the allocation recon tool communicating with the interaction constraint module (See at least Mohanty [0087-0089]. Mohanty discloses wherein the standardized schema (i.e., standard data format) is generated based on artifact comparison results (i.e., based on a set of standard data formats associated with the identified set of entities) provided by the allocation recon tool communicating with the interaction constraint module (i.e., provided by the data collector communicating with the entity categorizer).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mohanty into Kavanagh’s method of converting messages into a standard format. One of ordinary skill in the art would have been motivated to include such features in order to standardize information/data based on formats associated with the entities involved (Mohanty [0088]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kavanagh in view of Mohanty, as applied above, and further in view of Chen (US 2018/0012225 A1).
Regarding Claim 8: The combination of Kavanagh and Mohanty discloses the method of claim 1. Kavanagh further discloses the use of a user database to store usernames and passwords and an account data module to process account information during trades. Kavanagh [0087]. However, Kavanagh fails to explicitly disclose wherein the automatic modifying of the interaction session comprises reducing one or more authentication steps required to orchestrate the transfer of the artifact between the at least two entities. Chen, who is in the field of risk prevention, teaches wherein the automatic modifying of the interaction session comprises reducing one or more authentication steps required to orchestrate the transfer of the artifact between the at least two entities (See at least Chen [0003]; [0006] “a data transmission between a sender and a receiver can be performed without authenticating the sender or the receiver if an amount of data to be transmitted is lower than a threshold determined based on data transmission histories of the sender and the receiver”; [0029-0030]; [0043] “The request can indicate an amount of funds to be transferred and the payee's identity. The server can determine a direct confidence level between the payer and the payee based on records of prior fund transfers between the payer and the payee. The server can also determine if a third party had prior fund transfers with both the payee and the payer. Based on this determination, the server can determine an indirect confidence level based on records of prior fund transfers between the third party and the payee and between the third party and the payer. An overall confidence level between the payer and the payee can be determined based on the direct and indirect confidence levels. If the amount of funds to be transferred is less than the overall confidence level, the fund transfer can be performed without authenticating the payer and the payee. Otherwise, the fund transfer is performed after authenticating the payer and/or the payee. For example, consider an overall confidence level between the payer and the payee to be $1,000. If the amount of funds to be transferred is $100, then no authentication is performed for fund transfer. However, if the amount of funds to be transferred is $2,000, authentication is performed for the payer, the payee, or both the payer and the payee before the fund transfer”. Chen teaches wherein the automatic modifying of the interaction session comprises reducing one or more authentication steps (i.e., reducing authentication requirements, e.g., no authentication is required) required to orchestrate the transfer of the artifact (i.e., fund transfer) between the at least two entities (i.e., between the sender and receiver).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features taught by Chen into Kavanagh’s method using a user database to store usernames and passwords which are used during trades. One of skill in the art would have been motivated to incorporate such features in order to save computing network resources by reducing the need for authentication messages (Chen [0006]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Kavanagh in view of Mohanty, as applied above, and further in view of Seale et al. (US 2014/0289095 A1) (“Seale”).
Regarding Claim 12: The combination of Kavanagh and Mohanty discloses the method of claim 11. Kavanagh does not explicitly disclose wherein the dynamically predicting that each entity can meet the requirements without modification comprises utilizing a rules engine to collate any transfer information for any derived attributes associated with a particular artifact and a particular entity to build a plurality of derivations and provide the attributes needed for the plurality of derivations as part of the requirement associated with the plurality of protocols.
However Seale, in the analogous art of exchange traded funds, teaches wherein the dynamically predicting that each entity can meet the requirements without modification comprises utilizing a rules engine to collate any transfer information for any derived attributes associated with a particular artifact and a particular entity to build a plurality of derivations and provide the attributes needed for the plurality of derivations as part of the requirement associated with the plurality of protocols (See at least Seale [0042] “the proposed Bullish ETF utilizes various financial instruments, including derivatives, in addition to equity securities in managing the portfolio exposure and to capture a movement proportional to the targeted leverage”; [0049] “In step 330, the current total net assets are calculated by adding the total values of the equities, the gains or losses from the derivatives (swaps, futures, etc.) and net other assets (including cash)”; [0084] “the present invention uses "All-Cash Payment" procedures to account for the value of the derivatives. Because the Bullish and Bearish ETFs are the only domestic ETFs which provide leverage or short exposures through the use of derivatives, the creation and redemption process for units of the Bullish and Bearish ETFs employ a unique technique not used with conventional ETFs. That is, the Balancing Amount or All-Cash Payment in the Bullish and Bearish ETFs include the accumulated gains/losses from the derivative positions. This feature provides the advantage that it facilitates the orderly creations and redemptions in the ETF marketplace.”. Seale teaches wherein the dynamically predicting that each entity can meet the requirements without modification comprises utilizing a rules engine to collate any transfer information for any derived attributes associated with a particular artifact and a particular entity (i.e., by calculating a current net total for assets) to build a plurality of derivations (i.e., derivatives) and provide the attributes needed for the plurality of derivations as part of the requirement associated with the plurality of protocols (e.g., by providing the balancing amount or all-cash payment).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features taught by Seale into Kavanagh’s method of dynamically predicting that each entity can meet requirements (i.e., that each trader can meet the buying/selling parameters) without modifying the plurality of protocols for subsequent artifact transfers (i.e., indicated by the fact that the order can be entirely filled, thus the order is not modified). One of skill in the art would have been motivated to incorporate such features in order to provide detailed information about a derivatives positions and all other information that is necessary for the accurate calculations (Seale [0044]).
Claims 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kavanagh (US 2022/0141101 A1).
Regarding Claim 18: Kavanagh discloses a computer-implemented method comprising:
identifying, by at least one processor, a plurality of entities seeking to interact with each other (See at least Kavanagh [0032]; Fig. 2. Kavanagh discloses identifying, by at least one processor, a plurality of entities (i.e., customers/clients) seeking to interact with each other while matching transaction request messages.);
determining, by the at least one processor, a set of artifacts associated with each entity of the plurality of entities (See at least Kavanagh [0032]. Kavanagh discloses determining, by the at least one processor, a set of artifacts (i.e., data objects) associated with each entity of the plurality of entities (i.e., associated with each customer/client of the plurality of customers/clients).);
dynamically connecting, by the at least one processor, at least two entities using an integration service layer comprising a single gateway module based on a determination of the set of artifacts shared between the at least two entities (See at least Kavanagh [0032]; [0062]; [0065]; [0088]; [0207]. Kavanagh discloses dynamically connecting (e.g., during the matching), by the at least one processor, at least two entities (i.e., at least two customers/clients) using an integration service layer comprising a single gateway module (i.e., a portion of software comprising one or more algorithms, e.g., a match engine at a Market Segment Gateway (MSG)) based on a determination of the set of artifacts shared (i.e., based on request messages for the same one of the data items or objects matching) between the at least two entities.);
dynamically integrating, by the at least one processor and in response to connecting the at least two entities, a plurality of protocols into an interaction session associated with the at least two entities, wherein the plurality of protocols associated with the interaction session comprise requirements to connect received from each entity of the plurality of entities (See at least Kavanagh [0032]; [0071]; [0130]; [0148]; [0156]. Kavanagh discloses dynamically integrating, by the at least one processor and in response to connecting (i.e., in response to connecting during the matching) the at least two entities, a plurality of protocols (i.e., transaction matching parameters, e.g., a buy and a sell parameter) into an interaction session (i.e., a trade session) associated with the at least two entities, wherein the plurality of protocols (i.e., transaction matching parameters) associated with the interaction session comprise requirements to connect (i.e., transaction requirements, e.g., identifying the product, the quantity, a price, the direction of the order) received from each entity of the plurality of entities (i.e., received from each customer/client, e.g., a trader).);
analyzing, by the at least one processor, a particular data sleeve associated with each entity, wherein the particular data sleeve contains protocol preferences and predetermined artifact transfer rules associated with each entity (See at least Kavanagh [0032] “the electronic data transaction request messages may include, for example, transaction matching parameters, such as instructions and/or values, for processing the data transaction request messages within the data transaction processing system. The instructions may be to perform transactions, e.g., buy or sell a quantity of a product at a range of values defined equations”; [0078] “The clearing house establishes clearing level performance bonds (margins) for all products of the exchange and establishes minimum performance bond requirements for customers of such products. A performance bond, also referred to as a margin requirement, corresponds with the funds that must be deposited by a customer with his or her broker, by a broker with a clearing member or by a clearing member with the clearing house, for the purpose of insuring the broker or clearing house against loss on open futures or options contracts. This is not a part payment on a purchase. The performance bond helps to ensure the financial integrity of brokers, clearing members and the exchange as a whole. The performance bond refers to the minimum dollar deposit required by the clearing house from clearing members in accordance with their positions.”; [0218]. Kavanagh discloses analyzing a particular data sleeve (i.e., analyze a purchase/trade) associated with each entity, wherein the particular data sleeve contains protocol preferences (i.e., transaction matching parameters) and predetermined artifact transfer rules (i.e., a performance bond/margin requirement, which requires a customer to keep certain amount of funds with the broker based on the products purchased) associated with each entity.);
verifying, by the at least one processor, the plurality of protocols associated with the interaction session, wherein verifying the plurality of protocols comprising ensuring a number of shared requirements from the plurality of entities exceed a predetermined threshold (See at least Kavanagh [0068]; [0153]; Kavanagh Claim 11. Kavanagh discloses verifying, by the at least one processor, the plurality of protocols (i.e., transaction matching parameters) associated with the interaction session (i.e., associated with the trade session), wherein verifying the plurality of protocols comprising ensuring a number of shared requirements from the plurality of entities exceed a predetermined threshold (i.e., by matching the opposite transactions based on a same or better price, the same quantity, minimum quantities, etc.).);
initiating, by the at least one processor, the interaction session between at least two entities based on the plurality of protocols and the set of artifacts (See at least Kavanagh [0071]; [0130]. Kavanagh discloses initiating (i.e., enacting), by the at least one processor, the interaction session (i.e., trading session) between at least two entities (i.e., traders) based on the plurality of protocols (i.e., transaction matching parameters) and the set of artifacts (i.e., data objects, e.g., products, financial instruments, order books).);
dynamically predicting, by the at least one processor, a likelihood associated with a successful transfer of a particular artifact between the at least two entities based on a result of the integration services layer (See at least Kavanagh [0090] “A risk management module 114 may be included to compute and determine a user's risk utilization in relation to the user's defined risk thresholds. The risk management module 114 may also be configured to determine risk assessments or exposure levels in connection with positions held by a market participant”; [0160]. Kavanagh discloses dynamically predicting, by the at least one processor, a likelihood associated with a successful transfer of a particular artifact between the at least two entities (i.e., to determine risk assessments or exposure levels in connection with positions held by a market participants, which imply the likely hood of a successful transfer) based on a result (e.g., an assessment) of the integration services layer.);
automatically modifying, by the at least one processor, the interaction session to orchestrate a transfer of at least one artifact of the set of artifacts between the at least two entities (See at least Kavanagh [0041]; [0043]; [0071]. Kavanagh discloses automatically modifying, by the at least one processor, the interaction session (e.g., by sending one or more messages regarding the match) to orchestrate a transfer (i.e., trade) of at least one artifact (i.e., of at least one data object, e.g., product, financial instrument, order book) of the set of artifacts between the at least two entities (i.e., traders).); and
systemically capturing at least one predicted artifact transfer of a particular artifact that fails to match the verified plurality of protocols (See at least Kavanagh [0069] “Previously received but unsatisfied orders, i.e., orders which either did not match with a counter order when they were received or their quantity was only partially satisfied, referred to as a partial fill, are maintained by the electronic trading system in an order book database/data structure to await the subsequent arrival of matching orders or the occurrence of other conditions which may cause the order to be modified or otherwise removed from the order book”. Kavanagh discloses systemically capturing at least one predicted artifact transfer of a particular artifact that fails to match the verified plurality of protocols when it maintains an unmatched order.); and
generating a plurality of systematic reports associated with a plurality of predicted artifact transfers and requests for artifact transfers that are automatically verified within the predetermined period of time (See at least Kavanagh [0032] “The specifically configured matching processors may additionally generate information indicative of a state of an environment (e.g., the state of the order book) based on the processing, and report this information to data recipient computing systems via outbound messages published via one or more data feeds”; [0036] “An exchange may provide for a centralized "clearing house" through which trades made must be confirmed, matched, and settled each day until offset or delivered. The clearing house may be an adjunct to an exchange, and may be an operating division of an exchange, which is responsible for settling trading accounts, clearing trades, collecting and maintaining performance bond funds, regulating delivery, and reporting trading data”. Kavanagh discloses generating a plurality of systematic reports (i.e., generating information/reporting trading data) associated with a plurality of predicted artifact transfers (i.e., trades) and requests for artifact transfers (i.e., orders) that are automatically verified within the predetermined period of time (e.g., each day).).
Kavanagh does not explicitly disclose wherein the integration service layer communicates with the single gateway module, an API management module, a notification hub, a data translation layer, and at least one backbridge layer. However, Kavanagh teaches that the disclosed mechanisms may be implemented at any logical and/or physical point(s), or combinations thereof, at which the relevant information/data (e.g., message traffic and responses thereto) may be monitored or flows or is otherwise accessible or measurable, including one or more gateway devices, modems, the computers or terminals of one or more market participants, e.g., client computers, etc. Kavanagh [0099]. Kavanagh further teaches that modules may be implemented as software code, firmware code, specifically configured hardware or processors, and/or a combination of the aforementioned. Kavanagh [0100]. Kavanagh indicates that the modules may be embodied as part of an exchange for financial instruments, and that the disclosed embodiments may be implemented as a different or separate module of the exchange computer system, or a separate computer system coupled with the exchange computer system so as to have access to margin account record, pricing, and/or other data. Kavanagh [0100]. Kavanagh states that the disclosed embodiments may be implemented as a centrally accessible system or as a distributed system, e.g., where some of the disclosed functions are performed by the computer systems of the market participants. Kavanagh [0100]. Kavanagh further states that 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, firm-ware, microcode and the like, operating alone or in combination. Kavanagh [0111]. Accordingly, Kavanagh teaches that it was known in the art to have various pieces of hardware and/or software communicate with each other in order to accomplish specific tasks.
In view of the teachings provided by Kavanagh, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein the integration service layer communicates with the single gateway module, an API management module, a notification hub, a data translation layer, and at least one backbridge layer. One of ordinary skill in the art would have been motivated to include such features in order to provide one or more modules, computer software, computer firmware and/or computer hardware needed to implement the functional operations described by Kavanagh (Kavanagh [0117]). It is also noted that the mere fact that the integration service layer communicates with these computing modules/hubs/layers has no direct impact on how any of the positively recited steps are performed. For example, the at least two entities are not dynamically connected in a different/specific manner simply because the integration service layer may communicate at some point with another module/hub/layer.
Regarding Claim 19: Kavanagh, as modified, discloses the method of claim 18. Kavanagh further discloses:
receiving the plurality of artifact transfers related inputs (See at least Kavanagh [0040] “Financial messages communicated to the electronic trading system, also referred to as "inbound" messages, may include associated actions that characterize the messages, such as trader orders, order modifications, order cancellations and the like, as well as other message types”; [0065]; [0071]. Kavanagh discloses receiving the plurality of artifact transfers related inputs (i.e., inbound messages).);
comparing the plurality of artifact transfers to a plurality of transfer related inputs to determine additional inputs and common artifacts transfers associated with the interaction session (See at least Kavanagh [0070] “If the match engine identifies one or more suitable previously received but unsatisfied counter orders, they, and the incoming order, are matched to execute a trade there between to at least partially satisfy the quantities of one or both the incoming order or the identified orders. If there remains any residual unsatisfied quantity of the identified one or more orders, those orders are left on the order book with their remaining quantity to await a subsequent suitable counter order, i.e., to rest. If the match engine does not identify a suitable previously received but unsatisfied counter order, or the one or more identified suitable previously received but unsatisfied counter orders are for a lesser quantity than the incoming order, the incoming order is placed on the order book, referred to as "resting'', with original or remaining unsatisfied quantity, to await a subsequently received suitable order counter thereto. The match engine then generates match event data reflecting the result of this matching process”; [0088] “A match engine module 106 may be included to match bid and offer prices and may be implemented with software that executes one or more algorithms for matching bids and offers”. Kavanagh discloses comparing the plurality of artifact transfers (i.e., previously received, unsatisfied orders) to a plurality of transfer related inputs (i.e., to a current order) to determine additional inputs and common artifacts transfers associated with the interaction session (i.e., to determine residual unsatisfied quantities of one or more orders associated with the trading session).);
identifying a plurality of data breaks associated with a comparison of the plurality of artifact transfers to the plurality of transfer related inputs (See at least Kavanagh [0040]; [0042] “an electronic order book may be understood to be an electronic collection of the outstanding or resting orders for a financial instrument”; [0043] “a request to place a trade may result in a response indicative of the trade either being matched with, or being rested on an order book to await, a suitable counter-order”; [0071] “A match event may occur, for example, when an aggressing order matches with a resting order”. Kavanagh discloses identifying a plurality of data breaks (i.e., resting orders) associated with a comparison of the plurality of artifact transfers (i.e., previously received, unsatisfied orders) to the plurality of transfer related inputs (i.e., to a current/new order).);
automatically tracing an age associated with each request of the plurality of artifact transfers within a request repository (See at least Kavanagh [0013] “The disclosed embodiments generally relate to methods and systems for monitoring processing of messages in a data transaction processing system by logging information, i.e., tracer entries, about those messages as they are processed through the data transaction processing system […] The monitoring system also includes a parser that parses, e.g., during post-processing, or after a message has been processed by the application, the data structure to determine tracer entries associated with the same message for performance analysis of the progress of the message through the code”; [0016] “The data store may be separate from the messages that are processed by the data transaction processing system, such that as tracer entries associated with a message are accumulated and stored in the data store”; [0040] “Financial messages communicated to the electronic trading system, also referred to as "inbound" messages, may include associated actions that characterize the messages, such as trader orders, order modifications, order cancellations and the like, as well as other message types”; [0247] “Each tracer entry may include data based on [...] (ii) a checkpoint in the application 512 traversed by the message, such as checkpoints 412 and 414, and (iii) timestamp information about a current timestamp, or a time when the message traversed the checkpoint”. Kavanagh discloses automatically tracing an age associated with each request (i.e., a time when the message traversed the checkpoint) of the plurality of artifact transfers within a request repository (i.e., within a data store).); and
generating a plurality of systemic notices to ensure the plurality of artifact transfers are submitted within a predetermined period of time (See at least Kavanagh [0032] “The specifically configured matching processors may additionally generate information indicative of a state of an environment ( e.g., the state of the order book) based on the processing, and report this information to data recipient computing systems via outbound messages published via one or more data feeds”; [0036] “An exchange may provide for a centralized "clearing house" through which trades made must be confirmed, matched, and settled each day until offset or delivered. The clearing house may be an adjunct to an exchange, and may be an operating division of an exchange, which is responsible for settling trading accounts, clearing trades, collecting and maintaining performance bond funds, regulating delivery, and reporting trading data”. Kavanagh discloses generating a plurality of systemic notices (i.e., reporting trading data) to ensure the plurality of artifact transfers are submitted within a predetermined period of time (i.e., each day).).
Response to Arguments
Drawing Objection
Applicant did not make any remarks or amendments pertaining to the drawing objection. Examiner contends that the drawing objection remains valid, accordingly the drawing objection is being maintained.
Claim Rejections – 35 U.S.C. § 112
Applicant indicates that claims 1, 5, 9-11, 14-15, and 17-20 have been amended to address the prior 35 USC § 112(a) and 35 USC § 112(b) rejections. Amendment, p. 14. Examiner agrees. In view of the current claim amendments, the prior 35 USC § 112(a) and 35 USC § 112(b) rejections are withdrawn.
Examiner also notes that claims 11, 14, 17 and 18 are no longer being interpreted under 35 USC § 112(f) based on the current claim amendments.
Claim Rejections – 35 U.S.C. § 102
Applicant submits that Kavanagh does not disclose or teach all limitations recited by amended claim 20. Amendment, pp. 15-16. Specifically, Applicant alleges that Kavanagh fails to disclose, teach, or suggest "normalize, via a single gateway module, data associated with an artifact subject to transfer between the at least two entities into a format compatible with the interaction session, wherein the normalization comprises converting the artifact data into a standardized schema for processing by the interaction constraint module, wherein the standardized schema is generated based on artifact comparison results provide by the allocation recon tool communicating with the interaction constraint module." (Emphasis Added by Applicant). Id. Examiner agrees in part. Examiner contends that Kavanagh discloses normalizing (i.e., by converting into a message format), via the single gateway module (i.e., by a portion of software comprising one or more algorithms, e.g., a match engine at a Market Segment Gateway (MSG), which comprises a conversion component), data associated with an artifact subject (i.e., data associated with a data object, e.g., a message associated with a data object) to transfer between the at least two entities into a format compatible with the interaction session (i.e., “into a message format that can be input into the pre-match queue”). Kavanagh [0209]; [0213]. Kavanagh also discloses wherein the normalization (i.e., converting into a message format) comprises converting the artifact data (i.e., converting the data associated with the data object, e.g., converting the message associated with the data object) into a standardized schema (i.e., into a message format) for processing by the interaction constraint module (i.e., for processing by a portion of software, e.g., the match engine/component). Kavanagh [0209]; [0213-0215].
Examiner agrees that Kavanagh does not explicitly disclose wherein the standardized schema is generated based on artifact comparison results provided by the allocation recon tool communicating with the interaction constraint module. Accordingly, Examiner has added an additional reference, Mohanty, to the prior art rejection of claim 20. Examiner contends that Mohanty discloses wherein the standardized schema (i.e., standard data format) is generated based on artifact comparison results (i.e., based on a set of standard data formats associated with the identified set of entities) provided by the allocation recon tool communicating with the interaction constraint module (i.e., provided by the data collector communicating with the entity categorizer). Mohanty [0087-0089]. Accordingly, the combination of Kavanagh and Mohanty renders claim 20 obvious in view of the prior art.
Applicant argues that claim 20 differs from Kavanagh because claim 20 is “directed to initiating a secure interaction session between two entities seeking to trade data objects based on a plurality of shared parameters, where these parameters are tokenized and quantified to provide predictable results and repeatable interaction sessions.” Amendment, p. 16. This argument is unpersuasive because Kavanagh also discloses dynamically connecting (e.g., during the matching) at least two entities (i.e., at least two customers/clients) based on a determination of the set of artifacts shared (i.e., based on request messages for the same one of the data items or objects matching) between the at least two entities. Kavanagh [0032]; [0062]; [0065]; [0088]; [0207]. As per the tokenizing and quantifying of parameters, Examiner notes that these features are not found in claim 20, nor any of the claims.
Applicant argues that Kavanagh is silent on the application of a token-based authentication process and/or a conversion of a shared set of artifacts to a particular format (i.e., quantified format) prior to an integration of a plurality of protocols to provide a secure interaction session between the at least two entities seeking to exchange one or more data artifacts. Amendment, p. 17. This argument is unpersuasive. The most recent claim amendment removed these features from claim 20 since they were not supported by applicant’s disclosure. Accordingly, the features described by applicant are no longer found in the claim(s).
Claim Rejections – 35 U.S.C. § 103
Applicant’s arguments pertaining to Vashisht (Amendment, pp. 17-19)) have been considered but are moot in view of the current claim amendments. As indicated in applicant’s remarks (Amendment, p. 17), amended claim 1 no longer recites "receiving, by the at least one processor and via the single gateway module, connection requests from the at least two entities" or "applying, by the at least one processor and via the single gateway module, a token-based authentication to each connection request." These were the only limitations which relied on a teaching from Vashisht. Since these features/limitations were removed, Vashisht is no longer being used in any of the prior art rejections.
For the above reasons, and for those set forth in the 35 U.S.C. § 103 rejection seen above, all claims remain rejected under 35 U.S.C. § 103.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure is cited in the Notice of References Cited (PTO-892). The additional cited art further establishes the state of the art prior to the effective filling date of Applicant’s claimed invention.
Jakobsson et al. (US 2023/0385815 A1) discloses a method which receives a request from a requesting party, wherein the request includes: information about a transaction to be performed, a reference to a token corresponding to the transaction, and an address of a receiving party corresponding to the transaction. The method recovers, from a smart contract associated with the token, at least one address list, wherein: the at least one address list comprises a token banlist, and the token banlist comprises at least one address banned from receiving the token. The method determines whether the address of the receiving party is listed on the token banlist. When the address of the receiving party is listed on the token banlist, the method transmits a transaction rejection to the requesting party. Jakobsson Abstract; [0004].
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON FENSTERMACHER whose telephone number is (571)270-3511. The examiner can normally be reached Monday - Friday 9:00 AM to 5:30 PM ET, Alternate Fridays Off.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.F./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights