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 .
DETAILED ACTION
1. This action is in response to the application filed on 05/08/2025.
Claims 1-20 are presently pending for examination.
Information Disclosure Statement
2. The information disclosure statement (IDS) submitted on 05/08/2025 has being considered by the examiner.
Claim Rejections - 35 USC § 112
3. The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 13 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. The claim repeats same limitations that is already recited in claim 9 without further limiting (see claim 9 lines 13-14). Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Double Patenting
4. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12323485. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are directed to system for providing cross-application protocols describing integration dependencies in order to efficiently synchronize customer data. It would have obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the patented claims into instant claims in order to further filter system landscape based on integration requirements and to seek broader patent protection of the previously patented claims.
For example:
Instant Application 19/202575
Patent No: 12323485
1. A computer-implemented method comprising: receiving, by one or more processors, a request to synchronize customer data from a plurality of system instances, one or more of the plurality of system instances comprising one or more application programming interfaces (APIs);generating, by the one or more processors, a semantic description of an integration process configured to synchronize the customer data from the plurality of system instances, the semantic description of the integration process defining integration dependencies between the plurality of system instances, the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances, the integration dependencies indicating scenarios to which the one or more APIs belong to, and identifying integration targets comprising compatible target resources; filtering, by the one or more processors, a system landscape for one or more suitable integration targets of the integration targets based on integration requirements; and executing, by the one or more processors, the integration process, using the one or more suitable integration targets, to generate synchronized customer data.
________________________________
9. A computer-implemented system comprising: memory storing application programming interface (API) information; and a server performing operations comprising: receiving a request to synchronize customer data from a plurality of system instances, one or more of the plurality of system instances comprising one or more APIs; generating a semantic description of an integration process configured to synchronize the customer data from the plurality of system instances, the semantic description of the integration process defining integration dependencies between the plurality of system instances, the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances, the integration dependencies indicating scenarios to which the one or more APIs belong to, and identifying integration targets comprising compatible target resources; filtering a system landscape for suitable one or more integration targets of the integration targets based on integration requirements; and executing the integration process, using the one or more suitable integration targets, to generate synchronized customer data.
17. A non-transitory computer-readable media encoded with a computer program, the computer program comprising instructions that when executed by one or more computers cause the one or more computers to perform operations comprising: receiving a request to synchronize customer data from a plurality of system instances, one or more of the plurality of system instances comprising one or more application programming interfaces (APIs);generating a semantic description of an integration process configured to synchronize the customer data from the plurality of system instances, the semantic description of the integration process defining integration dependencies between the plurality of system instances, the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances, the integration dependencies indicating scenarios to which the one or more APIs belong to, and identifying integration targets comprising compatible target resources; filtering a system landscape for suitable one or more integration targets of the integration targets based on integration requirements; and executing the integration process, using the one or more suitable integration targets, to generate synchronized customer data.
1. A computer-implemented method comprising: receiving, by one or more processors, a request to synchronize customer data from a plurality of system instances, one or more of the plurality of system instances comprising one or more application programming interfaces (API); generating, by the one or more processors, a semantic description of an integration process configured to synchronize the customer data from the plurality of system instances, the semantic description of the integration process defining integration dependencies between the plurality of system instances, the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances, the integration dependencies indicating scenarios to which the APIs belong to, and identifying integration targets comprising compatible target resources; executing, by the one or more processors, the integration process to synchronize the customer data from the plurality of system instances to generate synchronized customer data; and providing, by the one or more processors, the synchronized customer data.
9. A computer-implemented system comprising: memory storing application programming interface (API) information; and a server performing operations comprising: receiving a request to synchronize customer data from a plurality of system instances, one or more of the plurality of system instances comprising one or more API; generating a semantic description of an integration process configured to synchronize the customer data from the plurality of system instances, the semantic description of the integration process defining integration dependencies between the plurality of system instances, the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances, the integration dependencies indicating scenarios to which the APIs belong to, and identifying integration targets comprising compatible target resources; executing the integration process to synchronize the customer data from the plurality of system instances to generate synchronized customer data; and providing the synchronized customer data.
17. A non-transitory computer-readable media encoded with a computer program, the computer program comprising instructions that when executed by one or more computers cause the one or more computers to perform operations comprising: receiving a request to synchronize customer data from a plurality of system instances, one or more of the plurality of system instances comprising one or more application programming interfaces (API); generating a semantic description of an integration process configured to synchronize the customer data from the plurality of system instances, the semantic description of the integration process defining integration dependencies between the plurality of system instances, the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances, the integration dependencies indicating scenarios to which the APIs belong to, and identifying integration targets comprising compatible target resources; executing the integration process to synchronize the customer data from the plurality of system instances to generate synchronized customer data; and providing the synchronized customer data.
Claim Rejections - 35 USC § 103
5. 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.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Houston, U. S. Patent Publication No. 2023/0090977 in view of Littlejohn et al., U. S. Patent Publication No. 2017/0118098 and further in view of Palanisamy, U. S. Patent Publication No. 2009/0024561.
Regarding claim 1, Houston discloses a computer-implemented method comprising: receiving, by one or more processors, a request to synchronize customer data from a plurality of system instances, one or more of the plurality of system instances comprising one or more application programming interfaces (API) (see Houston, ¶ [0009]; data synchronization request is received); generating, by the one or more processors, a semantic description of an integration process configured to synchronize the customer data from the plurality of system instances, the semantic description of the integration process between the plurality of system instances (see Houston, ¶ [0010]-[0011]; integration process of the customer data is performed); filtering, by the one or more processors, a system landscape for suitable integration targets of the integration process based on integration requirements (see Houston, ¶ [0039] and Littlejohn, ¶ [0025]; suitable integration targets are filtered); executing, by the one or more processors, the integration process to synchronize the customer data from the plurality of system instances to generate synchronized customer data (see Houston, ¶ [0039]-[0040]; data is synchronized); and providing, by the one or more processors, the synchronized customer data (see Houston, ¶ [0013] and [0026]; synchronized data is provided).
Although Houston discloses the invention substantially as claimed, it does not explicitly disclose defining integration dependencies.
Littlejohn teaches defining integration dependencies (see Littlejohn, ¶ [0018], [0025] and [0049]). It would have been obvious to one of ordinary skill in the art before the effective filling of the invention to incorporate the teachings of Littlejohn with that of Houston in order to efficiently and effectively eliminate any inconsistencies among the synchronized data.
Although Houston-Littlejohn disclose the invention substantially as claimed, they do not explicitly disclose the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances and identifying integration targets comprising compatible target resources.
Palanisamy teaches the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances and identifying integration targets comprising compatible target resources (see Palanisamy, ¶ [0036], [0041] - [0042] and [0045]). It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to incorporate the teachings of Palanisamy with that of Houston-Littlejohn in order to efficiently integrate and synchronize dependencies data into standard format across plurality of applications.
Regarding claim 2, Houston-Littlejohn-Palanisamy teaches wherein executing, by the one or more processors, the integration process comprises execution of the APIs and events according to integration dependencies between the plurality of system instances (see Houston, ¶ [0041] and Littlejohn, ¶ [0025 and [0079]).
Regarding claim 3, Houston-Littlejohn-Palanisamy teaches wherein the integration requirements comprise references to one or more system instances described as the integration targets. (see Houston, ¶ [0029], [0039] and Littlejohn, ¶ [0025]).
Regarding claim 4, Houston-Littlejohn-Palanisamy teaches wherein one or more of the plurality of system instances comprises dependencies expressing semantically different data inputs (see Houston, ¶ [0089] and Littlejohn, ¶ [0025]).
Regarding claim 5, Houston-Littlejohn-Palanisamy teaches wherein the scenarios to which the one or more APIs belong to comprise a definition of one or more target types. (see Houston, ¶ [0039] and Littlejohn, ¶ [0018],[0025]).
Regarding claim 6, Houston-Littlejohn-Palanisamy teaches further comprising: identifying, by the one or more processors, from the suitable integration targets, one or more system instances compliant with the integration process (see Houston, ¶ [0026] and [0037]).
Regarding claim 7, Houston-Littlejohn-Palanisamy teaches wherein the suitable integration targets comprise external files (see Houston, ¶ [0035] and Littlejohn, ¶ [0049]).
Regarding claim 8, Houston-Littlejohn-Palanisamy teaches wherein the synchronized customer data comprises code defining calls to user-selected API and event information, wherein the code is in a format of an API provider (see Houston, ¶ [0042] and [0082]).
Regarding claim 9, Houston discloses a computer-implemented system comprising: memory storing application programming interface (API) information; and a server performing operations comprising: receiving a request to synchronize customer data from a plurality of system instances, one or more of the plurality of system instances comprising one or more application programming interfaces (API) (see Houston, ¶ [0009]; data synchronization request is received); generating a semantic description of an integration process configured to synchronize the customer data from the plurality of system instances, the semantic description of the integration process between the plurality of system instances (see Houston, ¶ [0010]-[0011]; integration process of the customer data is performed); filtering, by the one or more processors, a system landscape for suitable integration targets of the integration process based on integration requirements (see Houston, ¶ [0039] and Littlejohn, ¶ [0025]; suitable integration targets are filtered); executing the integration process to synchronize the customer data from the plurality of system instances to generate synchronized customer data (see Houston, ¶ [0039]-[0040]; data is synchronized); and providing the synchronized customer data (see Houston, ¶ [0013] and [0026]; synchronized data is provided).
Although Houston discloses the invention substantially as claimed, it does not explicitly disclose defining integration dependencies.
Littlejohn teaches defining integration dependencies (see Littlejohn, ¶ [0018], [0025] and [0049]). It would have been obvious to one of ordinary skill in the art before the effective filling of the invention to incorporate the teachings of Littlejohn with that of Houston in order to efficiently and effectively eliminate any inconsistencies among the synchronized data.
Although Houston-Littlejohn disclose the invention substantially as claimed, they do not explicitly disclose the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances and identifying integration targets comprising compatible target resources.
Palanisamy teaches the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances and identifying integration targets comprising compatible target resources (see Palanisamy, ¶ [0036], [0041] - [0042] and [0045]). It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to incorporate the teachings of Palanisamy with that of Houston-Littlejohn in order to efficiently integrate and synchronize dependencies data into standard format across plurality of applications.
Regarding claim 10, Houston-Littlejohn-Palanisamy teaches wherein executing the integration process comprises execution of the APIs and events according to integration dependencies between the plurality of system instances (see Houston, ¶ [0041] and Littlejohn, ¶ [0025 and [0079]).
Regarding claim 11, Houston-Littlejohn-Palanisamy teaches wherein the integration requirements comprise references to one or more system instances described as the integration targets. (see Houston, ¶ [0029], [0039] and Littlejohn, ¶ [0025]).
Regarding claim 12, Houston-Littlejohn-Palanisamy teaches wherein one or more of the plurality of system instances comprises dependencies expressing semantically different data inputs (see Houston, ¶ [0089] and Littlejohn, ¶ [0025]).
Regarding claim 13, Houston-Littlejohn-Palanisamy teaches wherein the operations further comprise: filtering a system landscape for suitable integration targets of the integration process based on integration requirements (see Houston, ¶ [0039] and Littlejohn, ¶ [0025]).
Regarding claim 14, Houston-Littlejohn-Palanisamy teaches wherein the operations further comprise: identifying from the suitable integration targets, one or more system instances compliant with the integration process (see Houston, ¶ [0026] and [0037]).
Regarding claim 15, Houston-Littlejohn-Palanisamy teaches wherein the suitable integration targets comprise external files (see Houston, ¶ [0035] and Littlejohn, ¶ [0049]).
Regarding claim 16, Houston-Littlejohn-Palanisamy teaches wherein the synchronized customer data comprises code defining calls to user-selected API and event information, wherein the code is in a format of an API provider (see Houston, ¶ [0042] and [0082]).
Regarding claim 17, Houston discloses a non-transitory computer-readable media encoded with a computer program, the computer program comprising instructions that when executed by one or more computers cause the one or more computers to perform operations comprising: receiving a request to synchronize customer data from a plurality of system instances, one or more of the plurality of system instances comprising one or more application programming interfaces (API) (see Houston, ¶ [0009]; data synchronization request is received); generating a semantic description of an integration process configured to synchronize the customer data from the plurality of system instances, the semantic description of the integration process between the plurality of system instances (see Houston, ¶ [0010]-[0011]; integration process of the customer data is performed); filtering, by the one or more processors, a system landscape for suitable integration targets of the integration process based on integration requirements (see Houston, ¶ [0039] and Littlejohn, ¶ [0025]; suitable integration targets are filtered); executing the integration process to synchronize the customer data from the plurality of system instances to generate synchronized customer data (see Houston, ¶ [0039]-[0040]; data is synchronized); and providing the synchronized customer data (see Houston, ¶ [0013] and [0026]; synchronized data is provided).
Although Houston discloses the invention substantially as claimed, it does not explicitly disclose defining integration dependencies.
Littlejohn teaches defining integration dependencies (see Littlejohn, ¶ [0018], [0025] and [0049]). It would have been obvious to one of ordinary skill in the art before the effective filling of the invention to incorporate the teachings of Littlejohn with that of Houston in order to efficiently and effectively eliminate any inconsistencies among the synchronized data.
Although Houston-Littlejohn disclose the invention substantially as claimed, they do not explicitly disclose the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances and identifying integration targets comprising compatible target resources.
Palanisamy teaches the integration dependencies being defined by information presented in a standard format characterizing disparate APIs of the plurality of system instances and identifying integration targets comprising compatible target resources (see Palanisamy, ¶ [0036], [0041] - [0042] and [0045]). It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to incorporate the teachings of Palanisamy with that of Houston-Littlejohn in order to efficiently integrate and synchronize dependencies data into standard format across plurality of applications.
Regarding claim 18, Houston-Littlejohn-Palanisamy teaches wherein executing the integration process comprises execution of the APIs and events according to integration dependencies between the plurality of system instances (see Houston, ¶ [0041] and Littlejohn, ¶ [0025 and [0079]).
Regarding claim 19, Houston-Littlejohn-Palanisamy teaches wherein the integration requirements comprise references to one or more system instances described as the integration targets. (see Houston, ¶ [0029], [0039] and Littlejohn, ¶ [0025]).
Regarding claim 20, Houston-Littlejohn-Palanisamy teaches wherein one or more of the plurality of system instances comprises dependencies expressing semantically different data inputs (see Houston, ¶ [0089] and Littlejohn, ¶ [0025]).
Prior Art of Record
6. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Please refer to form PTO-892 (Notice of Reference Cited) for a list of relevant prior art.
a. US 20240169980 A1 is directed to a method and system that converts a procedure document into a smart procedure system capable of voice interfacing. The system of the present invention may include a conversion module that converts the BPMN process model of a procedure expressed in XML, automatically generated via NLP-based technology, into a smart procedure system capable of voice interfacing. The conversion module may be configured as a client-server architecture composed of a mobile application client on a smart device and a server system providing backend services.
b. US 20240037429 A1 is directed to a method for manipulating an intermediate representation of a modular packet-processing program is provided. The method includes receiving a plurality of modules configured to be conditionally executed, the plurality of modules including at least two parsers, ordering, topologically, at least two extracted header instances in a state of each of the at least two parsers, mapping the at least two header instances to use a common memory block, constructing a common parser directed-acyclic-graph (DAG), synthesizing a bitwise operation on a header instance validity bit and a packet validity bit of a common state in the common parser DAG, and outputting the common parser DAG into the intermediate representation.
c. US 20160034318 A1 is directed to a method and system for staging in a cloud environment defines a default stage for integration flows. An integration flow is defined by (a) stages including (i) a live stage to follow the default stage, (ii) additional stages between the default and live stages, and (b) endpoint definitions for the live and additional stages. In response to an instruction to promote the integration flow, the integration flow is load balanced by allocating each stage to execution environment(s). Then, the integration flow is run in the execution environment(s). The load balancing includes, for each stage, (i) retrieving a list of execution environments which are available for execution of stages, (ii) selecting execution environment(s) on which to execute the stage and updating the list of available execution environments to indicate that the selected execution environment(s) is allocated, and (iii) storing the selected execution environment(s) as specific to the stage.
Conclusion
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMED IBRAHIM whose telephone number is (571)270-1132. The examiner can normally be reached on Monday through Friday from 9:30AM to 6:00PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohamed Ibrahim/
Primary Examiner, Art Unit 2444
Prior Art of Record
6. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Please refer to form PTO-892 (Notice of Reference Cited) for a list of relevant prior art.
Conclusion
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMED IBRAHIM whose telephone number is (571)270-1132. The examiner can normally be reached on Monday through Friday from 9:30AM to 6:00PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohamed Ibrahim/
Primary Examiner, Art Unit 2444
Prosecution Insights