DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 29, 2025 has been entered.
Response to Amendment
The amendment filed on December 29, 2025 has been entered. Applicant has amended claims 1, 18 and 20. Claims 1-20 remain pending, have been examined and currently stand rejected.
Examiner note: The claim amendment filed on December 29, 2025 failed to properly identify all of the text that was deleted from claims 18 and 20. Specifically, amended claims 18 and 20 failed show the deleted text which recited “wherein the integration service layer comprising the single gateway module applies a token-based authentication and converts the set of artifacts shared between the at least two entities into a particular format.”
Applicant is reminded that all claims being currently amended in an amendment paper shall be presented in the claim listing, indicate a status of “currently amended,” and be submitted with markings to indicate the changes that have been made relative to the immediate prior version of the claims. The text of any added subject matter must be shown by underlining the added text. The text of any deleted matter must be shown by strike-through except that double brackets placed before and after the deleted characters may be used to show deletion of five or fewer consecutive characters. The text of any deleted subject matter must be shown by being placed within double brackets if strike-through cannot be easily perceived. Only claims having the status of “currently amended,” or “withdrawn” if also being amended, shall include markings. If a withdrawn claim is currently amended, its status in the claim listing may be identified as “withdrawn— currently amended.” See MPEP 714; 37 C.F.R. 1.121.
The Specification amendment filed on December 29, 2025 also failed to properly identify all of the text that was deleted from paragraph [0051]. Specifically, the last half of paragraph [0051] (i.e., the section starting with “In some embodiments, the rule engine 126 may identify the plurality of data breaks […]” and ending with “In certain embodiments, the post-submission controls 410 may modify the plurality of artifact request associated with the interaction constrain module 124.”) was inexplicably omitted/deleted from the December 29, 2025 Specification amendment. That is, the last half of paragraph [0051], which was present in the September 8, 2025 Specification amendment (i.e., the last entered Specification amendment), is now missing with no clear indication that it was intentionally deleted. This deleted text should have also been indicated with a strike-through. See MPEP 714; 37 C.F.R. 1.121.
It is unclear whether it was intentional to delete the last half of paragraph [0051] as applicant did not provide any remarks regarding the prior Specification objection and/or the Specification amendments. Examiner notes that the December 29, 2025 Specification amendment has been entered, accordingly any further amendments to paragraph [0051] (i.e., additions and/or deletions) should be based on this version of the Specification.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 September 8, 2025 remains objected to under 35 U.S.C. 132(a) because it introduced new matter into the disclosure. 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. Specifically, the original disclosure does not support the amendment reciting that the allocation recon tool 404 “can identify a plurality of artifacts associated with each entity, compare the plurality of artifacts of each entity with a different plurality of artifacts associated with a different entity, and determine one or more shared artifacts between the at least two entities.” The only section of Applicant’s disclosure that describes the allocation recon tool and its functionality recites “In some embodiments, 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. In some embodiments, the allocation recon tool 404 may communication with a rule engine 126.” Specification [0051]. Accordingly, the limited description about the allocation recon tool does not support the Specification amendment.
Applicant is required to cancel the new matter in the reply to this Office Action.
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 Interpretation
Intended Use/Result Language:
Independent claim 1 recites, in part, “utilizing, by the at least one processor, an integration service layer comprising a single gateway module to dynamically connect at least two entities based on a determination of a set of artifacts shared between the at least two entities.” Examiner contends that the phrase “to dynamically connect at least two entities based on a determination of a set of artifacts shared between the at least two entities” is merely a recited intended use/result of utilizing the integration service layer comprising a single gateway module. Applicant is not positively reciting a step, or steps, where at least two entities are dynamically connected based on a determination of a set of
artifacts shared between the at least two entities, rather Applicant is only positively reciting a step of “utilizing” the layer/module.
Independent claims 18 and 20 recite a substantially similar limitation, accordingly the claim interpretation applied above for claim 1 is also applicable to claims 18 and 20.
With respect to system claim 20, Examiner further notes that integration service layer is not part of the claimed system. Accordingly, any step(s)/action(s) performed by these components would be outside the scope of the claimed invention. While claim 20 recites that the system comprises software instructions, the claim fails to provide any indication that the integration service layer is part of the stored software instructions or the system.
35 U.S.C. 112(f):
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
the “integration services layer” predicts the likelihood of the successful transfer by dynamically predicting that each entity can meet requirements without modifying the plurality of protocols for subsequent artifact transfers, in claim 11;
at least one “trained machine learning module” to determining a particular data sleeve associated with each entity based on one or more preferences, in claim 14;
a “data workstation framework” to display a notification associated with the artifact transfer within the interaction session, in claim 17; and
at least one “trained machine learning module” to analyze a particular data sleeve associated with each entity, in claim 18;
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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-19 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-19: Claim 1 recites, in part, “receiving, by the at least one processor and via the single gateway module, connection requests from the at least two entities.” Examiner has reviewed applicant’s disclosure and is unable to find support for this amendment (i.e., the amendment introduces new matter). Specifically, applicant’s disclosure fails to describe receiving connection requests from the at least two entities. Applicant’s disclosure briefly describes tracking an age associated with a plurality of requests (Spec [0030]; [0051]), generating notices associated with requests (Spec [0030]), identifying at least one artifact transfer request (Spec [0039]), transmitting a plurality of updated requests for existing service (Spec [0048]), and comparing a plurality of requests to identify a plurality of data breaks (Spec [0051]). Applicant’s disclosure also indicates that entities may be dynamically connected based on a determination of artifacts shared by the entities (See e.g., Spec [0026]), however there is no indication in the disclosure that connection requests are received or that the dynamic connection is based on one or more requests.
Additionally, the disclosure fails to describe receiving any requests (e.g., connection requests) via a single gateway module. Applicant’s disclosure merely indicates that “the exemplary transfer orchestration module 118 may utilize the EISL to communicate with a single gateway, an API management module, a notification hub, a data translation layer, and at least one backbridge layer.” Specification [0031]. Accordingly, while the disclosure briefly mentions that the EISL may be used to communicate with a single gateway, the disclosure fails to provide any indication that the communication between the EISL and the single gateway comprises, or pertains to, receiving connection requests.
Claim 18 recites the same limitation as that found in claim 1, accordingly claim 18 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, and claim 19 is rejected under 35 U.S.C. 112(a) based on its dependency to claim 18.
Regarding Claims 1-19: Claim 1 recites, in part, “applying, by the at least one processor and via the single gateway module, a token-based authentication to each connection request.” Examiner has reviewed applicant’s disclosure and is unable to find support for this amendment (i.e., the amendment introduces new matter). Applicant’s disclosure broadly indicates that “a plurality of login authorization and/or entitlements associated with the data workstation framework may connect into an external data source to establish the interaction session” (Spec [0036]), however this broad description of a login authorization is not specific enough to support “applying, by the at least one processor and via the single gateway module, a token-based authentication to each connection request.” That is, the disclosure fails to specifically indicate that a token-based authentication is applied to each connection request. The disclosure also fails to provide any indication that the single gateway module is used to apply the token-based authentication.
Claim 18 recites the same limitation as that found in claim 1, accordingly claim 18 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, and claim 19 is rejected under 35 U.S.C. 112(a) based on its dependency to claim 18.
Regarding Claims 11-12, 14 and 18: The claim limitation identified in the 35 U.S.C. 112(f) Claim Interpretation section, seen above, invoke 35 U.S.C. 112(f), however applicant’s disclosure fails to disclose the corresponding structure, material, or acts for performing the entire claimed function(s).
The structure corresponding to the 35 U.S.C. 112(f) claim limitations that are computer-implemented specialized functions must include a general purpose computer or computer component along with the algorithms that the computer uses to perform each claimed specialized function.
With respect to the “integration services layer” which predicts the likelihood of the successful transfer by dynamically predicting that each entity can meet requirements without modifying the plurality of protocols for subsequent artifact transfers, in claim 11. Applicant’s disclosure fails to describe or mention an “integration services layer.” Applicant’s disclosure broadly mentions a “enterprise integration services layer module” (See e.g., Specification [0031-0032]; [0049]), however the disclosure fails to provide any corresponding structure for this module.
With respect to the at least one “trained machine learning module” which determines a particular data sleeve associated with each entity based on one or more preferences, in claim 14. Applicants disclosure indicates that “In some embodiments, the illustrative program engine 104 may be configured to instruct the processor 108 to execute one or more software modules such as, without limitation, an exemplary transfer orchestration module 118, a machine learning module 120, and/or a data output module 122.” Specification [0024]. Accordingly, the machine learning module appears to be software executed by a processor. However, the disclosure fails to provide any steps/algorithm describing how the machine learning module determines a particular data sleeve associated with each entity based on one or more preferences. Accordingly, the disclosure fails to describe sufficient correspond structure to implement this specialized function. With respect to the at least one “trained machine learning module” which analyzes a particular data sleeve associated with each entity, in claim 18. Applicants disclosure indicates that “In some embodiments, the illustrative program engine 104 may be configured to instruct the processor 108 to execute one or more software modules such as, without limitation, an exemplary transfer orchestration module 118, a machine learning module 120, and/or a data output module 122.” Specification [0024]. Accordingly, the machine learning module appears to be software executed by a processor. However, the disclosure fails to provide any steps/algorithm describing how the machine learning module analyzes a particular data sleeve associated with each entity. Accordingly, the disclosure fails to describe sufficient correspond structure to implement this specialized function. In view of the details provided above, Examiner contends that applicant’s disclosure fails to disclose the corresponding structure or material for performing the entire claimed function(s) and to clearly link the structure or material to the function(s). Accordingly, claims 11, 14 and 18 are rejected under 35 U.S.C. 112(a) because they fail to comply with the written description requirement. Claim 12 is also rejected under 35 U.S.C. 112(a) based on its dependency to claim 11.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 11-12, 14 and 18 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding Claims 11-12, 14 and 18: The claim limitations identified in the 35 U.S.C. 112(f) Claim Interpretation section, seen above, invoke 35 U.S.C. 112(f), however the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function(s) and to clearly link the structure, material, or acts to the function(s). It is noted that for computer-implemented means-plus-function limitations, the corresponding structure includes both the computer and the algorithm that performs the recited functions. That is, specialized functions must be supported in the specification by the computer and the algorithm that the computer uses to perform the claimed specialized function. However, a non-specialized function requires no more support in the specification than a general-purpose computer or a known computer component that is recognized by those of ordinary skill in the art as typically including structure and non-specialized programming to perform the claimed function. Generally, it is only in rare circumstances that an algorithm need not be disclosed. MPEP § 2181 (ll)(B). Rare circumstances are when functionality is coextensive with a microprocessor such as the functions of receiving, storing, or processing of data. Id.
With respect to the “integration services layer” which predicts the likelihood of the successful transfer by dynamically predicting that each entity can meet requirements without modifying the plurality of protocols for subsequent artifact transfers, in claim 11. Applicant’s disclosure fails to describe or mention an “integration services layer.” Applicant’s disclosure broadly mentions a “enterprise integration services layer module” (See e.g., Specification [0031-0032]; [0049]), however the disclosure fails to provide any corresponding structure for this module. Accordingly, it is unknown/unclear what structure corresponds to the integration services layer.
With respect to the at least one “trained machine learning module” which determines a particular data sleeve associated with each entity based on one or more preferences, in claim 14. Applicants disclosure indicates that “In some embodiments, the illustrative program engine 104 may be configured to instruct the processor 108 to execute one or more software modules such as, without limitation, an exemplary transfer orchestration module 118, a machine learning module 120, and/or a data output module 122.” Specification [0024]. Accordingly, the machine learning module appears to be software executed by a processor. However, the disclosure fails to provide any steps/algorithm describing how the machine learning module determines a particular data sleeve associated with each entity based on one or more preferences. Accordingly, the disclosure fails to describe sufficient correspond structure to implement this specialized function. Accordingly, it is unknown/unclear what structure corresponds to the trained machine learning module. With respect to the at least one “trained machine learning module” which analyzes a particular data sleeve associated with each entity, in claim 18. Applicants disclosure indicates that “In some embodiments, the illustrative program engine 104 may be configured to instruct the processor 108 to execute one or more software modules such as, without limitation, an exemplary transfer orchestration module 118, a machine learning module 120, and/or a data output module 122.” Specification [0024]. Accordingly, the machine learning module appears to be software executed by a processor. However, the disclosure fails to provide any steps/algorithm describing how the machine learning module analyzes a particular data sleeve associated with each entity. Accordingly, the disclosure fails to describe sufficient correspond structure to implement this specialized function. Accordingly, it is unknown/unclear what structure corresponds to the trained machine learning module.
Since the disclosure fails to disclose the corresponding structure (i.e., computer and algorithm), material, or acts for performing the entire claimed function(s) and to clearly link the structure, material, or acts to the various functions claims 11, 14 and 18 are determined to be indefinite and is therefore rejected under 35 U.S.C. 112(b). Claim 12 is also rejected under 35 U.S.C. 112(b) based on its dependency to claim 11.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 20 is rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Kavanagh (US 2022/0141101 A1).
Regarding Claim 20: Kavanagh discloses a system comprising:
a non-transient 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).);
utilize an integration service layer to dynamically connect at least two entities based on a determination of a set of artifacts shared between the at least two entities (See at least Kavanagh [0032]; [0062]; [0065]; [0088]. Kavanagh discloses utilizing an integration service layer (i.e., a portion of software comprising one or more algorithms, e.g., a match engine at a Market Segment Gateway (MSG)) to dynamically connect (e.g., during the matching) at least two entities (i.e., at least two customers/clients) based on a determination of a 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.).);
convert, via a single gateway module, the set of artifacts shared between the at least two entities into a normalized format used by the interaction session (See at least Kavanagh [0209]; [0213]. Kavanagh discloses converting, by the at least one processor and via the 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), which comprises a conversion component), the set of artifacts shared (i.e., request messages, e.g., matching request messages) between the at least two entities into a normalized format used by the interaction session (i.e., “into a message format that can be input into the pre-match queue”).);
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).).
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 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Kavanagh (US 2022/0141101 A1) in view of Vashisht et al. (US 2019/0297119 A1) (hereinafter “Vashisht”).
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).);
utilizing, by the at least one processor, an integration service layer comprising a single gateway module to dynamically connect at least two entities based on a determination of the set of artifacts shared between the at least two entities (See at least Kavanagh [0032]; [0062]; [0065]; [0088]. Kavanagh discloses utilizing, by the at least one processor, 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)) to dynamically connect (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.);
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).);
converting, by the at least one processor and via the single gateway module, the set of artifacts shared between the at least two entities into a normalized format used by the interaction session (See at least Kavanagh [0209]; [0213]. Kavanagh discloses converting, by the at least one processor and via the 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), which comprises a conversion component), the set of artifacts shared (i.e., request messages, e.g., matching request messages) between the at least two entities into a normalized format used by the interaction session (i.e., “into a message format that can be input into the pre-match queue”).);
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 further discloses the use of a user database which includes information identifying traders and other users of exchange computer system. Kavanagh indicates that the user database also includes information such as account numbers or identifiers, user names and passwords. Kavanagh [0087]. However, Kavanagh does not explicitly disclose: 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. Vashisht, on the other hand, teaches:
receiving, by the at least one processor and via the single gateway module, connection requests from the at least two entities (See at least Vashisht [0011]; [0020-0021]; [0051]; [0053]; Fig. 5 Steps 502, 504 and 506; Fig. 6 step 602. Vashisht teaches receiving, by the at least one processor (i.e., server) and via the single gateway module (i.e., via the communication interface), connection requests (i.e., direct connection requests/log-in requests for a collaboration session) from the at least two entities (i.e., from a plurality of devices, e.g., a first and second device).);
applying, by the at least one processor and via the single gateway module, a token-based authentication to each connection request (See at least Vashisht [0023]; [0026]; [0036]; [0051]; [0053]; [0065]. Vashisht teaches applying, by the at least one processor (i.e., server) and via the single gateway module (i.e., via the communication interface), a token-based authentication (i.e., a log-in/validation process which uses a password/token) to each connection request (i.e., to each connection/log-in request).);
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 teachings of Vashisht into Kavanagh’s method which stores identifying information, such as passwords, for users of the exchange computer system. One of ordinary skill in the art would have been motivated to include such features in order to establish a direct connection between two or more entities so that data can be shared directly without having to send that data through a server (Vashisht [0020]; [0052]).
Regarding Claim 2: The combination of Kavanagh and Vashisht 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 Vashisht 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 Vashisht 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 Vashisht discloses the method of claim 1. Kavanagh further discloses wherein the integration services 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 Vashisht 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 Vashisht 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 Vashisht 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 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 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 services layer.).
Regarding Claim 10: The combination of Kavanagh and Vashisht discloses the method of claim 1. Kavanagh further discloses wherein the integration services 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 Vashisht discloses the method of claim 9. Kavanagh further discloses wherein the integration services layer predicts the likelihood of the successful transfer by 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 the integration services layer predicts the likelihood of the successful transfer by 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 Vashisht 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 15: The combination of Kavanagh and Vashisht 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 an external database (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 an external database (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 Vashisht 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 Vashisht discloses the method of claim 1. Kavanagh further discloses displaying 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 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)).).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kavanagh in view of Vashisht, as applied above, and further in view of Chen (US 2018/0012225 A1).
Regarding Claim 8: The combination of Kavanagh and Vashisht 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 Vashisht, as applied above, and further in view of Seale et al. (US 2014/0289095 A1) (“Seale”).
Regarding Claim 12: The combination of Kavanagh and Vashisht 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 14, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kavanagh (US 2022/0141101 A1) in view of Vashisht et al. (US 2019/0297119 A1) (“Vashisht”) in view of Trevathan et al. (US 2021/0065294 A1) (“Trevathan”).
Regarding Claim 14: The combination of Kavanagh and Vashisht discloses the method of claim 1. Kavanagh further discloses: determining a particular data sleeve associated with each entity based on one or more preferences via at least one module, 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) via at least one module (e.g., a match engine module), 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).).
Kavanagh does not explicitly disclose that the determination is performed via at least one trained machine learning module. However, Trevathan teaches using at least one trained machine learning module to determine a particular data sleeve (See at least Trevathan [0147] “The machine learning 320 is the intelligent opportunity creator that continuously rates, ranks opportunities based on integration of various sentiments and other relevant data (using machine learning) from the data feeds 310, and uses this information to generate different trading recipes of the opportunities”. Trevathan discloses using at least one trained machine learning module (i.e., machine learning) to determine a particular data sleeve (i.e., opportunity).).
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 Trevathan into Kavanagh’s method of utilizing at least one module (e.g., a match engine module) to analyze a particular data sleeve (i.e., analyze a purchase/trade) associated with each entity. One of skill in the art would have been motivated to incorporate such features in order to make it possible for non-professionals to benefit from the advantages of a professional trading approach while eliminating research time and deep knowledge necessary for implementing complex trading strategies by generating opportunity recommendations (Trevathan [0026]).
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).);
utilizing, by the at least one processor, an integration service layer comprising a single gateway module to dynamically connect at least two entities based on a determination of a set of artifacts shared between the at least two entities (See at least Kavanagh [0032]; [0062]; [0065]; [0088]. Kavanagh discloses utilizing, by the at least one processor, 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)) to dynamically connect (e.g., during the matching) at least two entities (i.e., at least two customers/clients) based on a determination of a 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 via at least one module, 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 via at least one module (e.g., a match engine module), 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 further discloses the use of a user database which includes information identifying traders and other users of exchange computer system. Kavanagh indicates that the user database also includes information such as account numbers or identifiers, user names and passwords. Kavanagh [0087]. However, Kavanagh does not explicitly disclose: 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. Vashisht, on the other hand, teaches:
receiving, by the at least one processor and via the single gateway module, connection requests from the at least two entities (See at least Vashisht [0011]; [0020-0021]; [0051]; [0053]; Fig. 5 Steps 502, 504 and 506; Fig. 6 step 602. Vashisht teaches receiving, by the at least one processor (i.e., server) and via the single gateway module (i.e., via the communication interface), connection requests (i.e., direct connection requests/log-in requests for a collaboration session) from the at least two entities (i.e., from a plurality of devices, e.g., a first and second device).);
applying, by the at least one processor and via the single gateway module, a token-based authentication to each connection request (See at least Vashisht [0023]; [0026]; [0036]; [0051]; [0053]; [0065]. Vashisht teaches applying, by the at least one processor (i.e., server) and via the single gateway module (i.e., via the communication interface), a token-based authentication (i.e., a log-in/validation process which uses a password/token) to each connection request (i.e., to each connection/log-in request).);
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 teachings of Vashisht into Kavanagh’s method which stores identifying information, such as passwords, for users of the exchange computer system. One of ordinary skill in the art would have been motivated to include such features in order to establish a direct connection between two or more entities so that data can be shared directly without having to send that data through a server (Vashisht [0020]; [0052]).
Kavanagh does not explicitly disclose that the analyzing of the particular data sleeve is performed via at least one trained machine learning module. However, Trevathan teaches using at least one trained machine learning module to analyze the particular data sleeve (See at least Trevathan [0147] “The machine learning 320 is the intelligent opportunity creator that continuously rates, ranks opportunities based on integration of various sentiments and other relevant data (using machine learning) from the data feeds 310, and uses this information to generate different trading recipes of the opportunities”. Trevathan discloses using at least one trained machine learning module (i.e., machine learning) to analyze the particular data sleeve (i.e., opportunity).).
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 Trevathan into Kavanagh’s method of utilizing at least one module (e.g., a match engine module) to analyze a particular data sleeve (i.e., analyze a purchase/trade) associated with each entity. One of skill in the art would have been motivated to incorporate such features in order to make it possible for non-professionals to benefit from the advantages of a professional trading approach while eliminating research time and deep knowledge necessary for implementing complex trading strategies by generating opportunity recommendations (Trevathan [0026]).
Regarding Claim 19: The combination of Kavanagh, Vashisht and Trevathan 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 an external database (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 an external database (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
Specification Objection
Applicant did not make any remarks regarding the Specification Objection in the October 21, 2025 Final Office Action or the current Specification amendment (i.e., the December 29, 2025 Specification amendment submitted with this response). Examiner notes that the December 29, 2025 Specification amendment did remove some of the language which triggered the Specification Objection in the October 21, 2025 Final Office Action, however Examiner contends that paragraph [0051] of the Specification continues to recite new matter that was added to the Specification in the September 8, 2025 Specification amendment. Examiner has updated the Specification Objection to identify the remaining new matter found in the Specification.
Drawing Objection
Examiner notes that the drawing objection, seen above, has been reintroduced as a result of the December 29, 2025 Specification amendment. The September 8, 2025 Specification amendment temporary overcame this drawing objection, which was initially seen in the June 6, 2025 Office Action, by introducing new matter into the Specification explaining components/terms found in figure 4 associated with the drawing objection. The December 29, 2025 Specification amendment correctly deleted this new matter, however by deleting this new matter the drawing, and/or its corresponding description, once again has issues.
Based on the support provided by the disclosure, Examiner is unable to identify a correction that will overcome the drawing rejection.
Claim Rejections – 35 U.S.C. § 112
Claims 11-12, 14 and 18 were rejected under 35 USC § 112(a) and 35 USC § 112(b) for issues associated with invoking 35 USC § 112(f). Applicant indicates claims 1 and 18 have been amended to correct the cited issues. Amendment, p. 12. Applicant also indicates that “Applicant's Specification expressly discloses "the interaction constraint module 124 and rules engine 126," and details acts these components perform, namely receiving transfer-related inputs, comparing requests, identifying data breaks, capturing failed transfers, tracking age in a request repository and generating notices.” Id. Examiner notes that the 112(f) claim interpretation, and the corresponding 112(a) and 112(b) rejections, pertained to the "integration services layer" and the at least one "trained machine learning module", not the interaction constraint module or the rules engine. Additionally, the amendments to claims 1 and 18 have nothing to do with the "integration services layer" or the at least one "trained machine learning module", accordingly there is no apparent connection between the claim amendments and the prior 112(a) and 112(b) rejections. Examiner contends the 112(a) and the 112(b) rejections remain valid.
Claim Rejections – 35 U.S.C. § 103
Applicant argues that Kavanagh fails to disclose "receiving, by the at least one processor and via the single gateway module, connection requests from the at least two entities; applying, by the at least one processor and via the single gateway module, a token-based authentication to each connection request." Amendment, pp. 14-15. Examiner agrees. Examiner has added a new reference, Vashisht, to the prior art rejection to address these newly added features.
Applicant argues that Kavanagh is silent on the 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. 15. Examiner respectfully disagrees. Examiner contends that Kavanagh discloses converting, by the at least one processor and via the 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), which comprises a conversion component), the set of artifacts shared (i.e., request messages, e.g., matching request messages) between the at least two entities into a normalized format used by the interaction session (i.e., “into a message format that can be input into the pre-match queue”). Kavanagh [0209]; [0213].
Applicant argues that Singh fails to cure the alleged deficiencies of Kavanagh. Amendment, pp. 15-16. Examiner agrees, however it is noted that Singh is no longer being used in any of the prior art rejections.
Applicant indicates that claims 18 and 20 are also believed to be in condition for allowance for “at least the same reasons” as those identified with respect to claim 1. Amendment, p. 16. Examiner notes that while claims 18 and 20 have similarities to claim 1, claims 18 and 20 are both broader in scope than claim 1. Specifically, unlike claim 1, claim 18 fails to recite “converting, by the at least one processor and via the single gateway module, the set of artifacts shared between the at least two entities into a normalized format used by the interaction session.” Additionally, unlike claim 1, claim 20 fails to recite “receiving, by the at least one processor and via the single gateway module, connection requests from the at least two entities; and applying, by the at least one processor and via the single gateway module, a token-based authentication to each connection request.”
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].
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