DETAILED ACTION
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 .
Status
This action is a non-final that will replace the previous non-final. Additional 112(b) rejections have been made to clarify the record. Claims 1-20 are pending.
Drawings
The drawings are objected to because many of the figures (Figure 1, 2, 4, 8, 12-14) are blurry and unreadable. 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. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. 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 Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. abstract idea) without anything significantly more.
Step 1: Claims 1-7 are directed to a system, claims 8-14 are directed to a computer program product, claims 15-20 are directed to a method. Therefore, claims 1-20 are directed to patent eligible categories of invention.
Step 2A, Prong 1: The claim(s) recite(s) (mathematical relationships/formulas, mental process or certain methods of organizing human activity). Specifically the independent claims recite:
mental process: as drafted, the claims recite the limitations of providing a dataflow studio and providing an endpoint catalog which is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting a “graphical user interface,” and other generic computer features nothing in the claim precludes the determining step from practically being performed in the human mind. For example, but for the “graphical user interface” language, the claim encompasses a user receiving data from a source, routing the data, and providing an endpoint catalog that the data could be sent to. The mere nominal recitation of a generic computing devices does not take the claim limitation out of the mental processes grouping. The applicant is merely collecting, organizing, storing, and transmitting information using a computer as a tool to perform the steps of the invention. This limitation is a mental process.
certain methods of organizing human activity: The claim as a whole recites a method of organizing human activity. The claimed invention is a method that allows for users to manage a business relationship between an operator and application providers which is tracking a business or legal Interactions. According to the 2019 PEG, “commercial interactions” or “legal interactions” include subject matter relating to agreements in the form of contracts a method of managing interactions between people. Thus, the claim recites an abstract idea.
Dependent claims 2-7, 9-14, 16-20 will be evaluated under Step 2A, Prong 2 below.
Step 2A, Prong 2: Independent claims 1, 8, 15, do not integrate the judicial exception into a practical application. Claim 1 is a system comprising “at least one processor… at least one memory… a dataflow studio comprising a no-code graphical user interface … EAM system and enterprise applications… an API…an endpoint catalog comprising a centralized registry of enterprise applications….” Claim 8 is computer program product comprising “one tangible, non-transitory computer-readable medium…an enterprise asset management (EAM) system with enterprise application… at least one processor… a dataflow studio comprising a no-code graphical user interface… EAM system and enterprise applications… an API… an endpoint catalog comprising a centralized registry of enterprise applications… .” Claim 15 is a method that comprises “a dataflow studio comprising a no-code graphical user interface… EAM system and enterprise applications… an API… an endpoint catalog comprising a centralized registry of enterprise applications.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to collect, organize, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Therefore, the additional elements of the independent claims, when considered both individually and in combination, are not sufficient to prove integration into a practical application.
Dependent claims 2, 9, 16 introduces the additional element of “causing display of a dialog box listing the tenant specific endpoint connections on a display device of a user computer; in response to receiving a user input of a selected tenant specific endpoint connection, mapping, by the dataflow studio, the selected tenant specific endpoint connection to a corresponding processor type, configuring the selected tenant specific endpoint connection using metadata values from the EAM system, and writing a UUID of the processor to the EAM system as endpoint metadata for reference; and updating endpoint metadata for the endpoint in the EAM system including querying the dataflow studio by the EAM system for a reference to the processor and updating the endpoint metadata based on the reference to the processor.” These limitations collect data (query), present data (display a dialog), receive a selection, and update records to reflect that selection. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Dependent claims 3, 10, 17, introduce the additional element of “enterprise applications internal to the EAM system; enterprise applications external to the EAM system; or IoT/sensor devices.” Merely further label/ name components. This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 4, 11, 18, introduce the additional element of “wherein at least one of: the ToEAM queue and the FromEAM queue are managed AWS SQS BOD queues; the API further includes a RESTful API; or the dataflow studio is configured to periodically query the FromEAM queue for records from the EAM system.” Merely further label/ name components. This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 5, 12, 19, introduce the additional element of “wherein the dataflow studio is configured to allow a user to build and configure a flow by linking processors that receive and process data from the EAM system for use by an enterprise application endpoint and/or receive and process data from the enterprise application endpoint for use by the EAM system, optionally wherein the dataflow studio comprises a drag-and-drop interface to build and configure the flow.” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h). Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Dependent claims 6, 13, introduce the additional element of “an integration component; a transformation component; and an analysis component.” Merely further label/ name components. This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h). Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Dependent claims 7, 14, 20, introduce the additional element of “a 360 transaction view component configured to integrate data events from the dataflow studio into a user-comprehensible flow to provide visibility into data and process flows both within the EAM system and within the dataflow studio, optionally wherein the 360 transaction view component allows a user to troubleshoot a message transaction utilizing an end-to-end view of messages between the EAM system and the dataflow studio.” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h). Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Therefore, the additional elements of the dependent claims, when considered both individually and in the context of the independent claims, are not sufficient to prove integration into a practical application.
Step 2B: Independent claims 1, 8, and 15 do not comprise anything significantly more than the judicial exception. As can be seen above with respect to Step 2A, Prong 2, claim 1 is a system comprising “at least one processor… at least one memory… a dataflow studio comprising a no-code graphical user interface … EAM system and enterprise applications… an API…an endpoint catalog comprising a centralized registry of enterprise applications….” Claim 8 is computer program product comprising “one tangible, non-transitory computer-readable medium…an enterprise asset management (EAM) system with enterprise application… at least one processor… a dataflow studio comprising a no-code graphical user interface… EAM system and enterprise applications… an API… an endpoint catalog comprising a centralized registry of enterprise applications… .” Claim 15 is a method that comprises “a dataflow studio comprising a no-code graphical user interface… EAM system and enterprise applications… an API… an endpoint catalog comprising a centralized registry of enterprise applications.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f).
The additional elements of the independent claims, when considered both individually and in combination, do not comprise anything significantly more than the judicial exception.
Dependent claims 2, 9, 16 introduces the additional element of “causing display of a dialog box listing the tenant specific endpoint connections on a display device of a user computer; in response to receiving a user input of a selected tenant specific endpoint connection, mapping, by the dataflow studio, the selected tenant specific endpoint connection to a corresponding processor type, configuring the selected tenant specific endpoint connection using metadata values from the EAM system, and writing a UUID of the processor to the EAM system as endpoint metadata for reference; and updating endpoint metadata for the endpoint in the EAM system including querying the dataflow studio by the EAM system for a reference to the processor and updating the endpoint metadata based on the reference to the processor.” These limitations collect data (query), present data (display a dialog), receive a selection, and update records to reflect that selection. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f).
Dependent claims 3, 10, 17, introduce the additional element of “enterprise applications internal to the EAM system; enterprise applications external to the EAM system; or IoT/sensor devices.” Merely further label/ name components” This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 4, 11, 18, introduce the additional element of “wherein at least one of: the ToEAM queue and the FromEAM queue are managed AWS SQS BOD queues; the API further includes a RESTful API; or the dataflow studio is configured to periodically query the FromEAM queue for records from the EAM system.” Merely further label/ name components. This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 5, 12, 19, introduce the additional element of “wherein the dataflow studio is configured to allow a user to build and configure a flow by linking processors that receive and process data from the EAM system for use by an enterprise application endpoint and/or receive and process data from the enterprise application endpoint for use by the EAM system, optionally wherein the dataflow studio comprises a drag-and-drop interface to build and configure the flow.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f). This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 6, 13, introduce the additional element of “an integration component; a transformation component; and an analysis component.” Merely further label/ name components. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f). This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 7, 14, 20, introduce the additional element of “a 360 transaction view component configured to integrate data events from the dataflow studio into a user-comprehensible flow to provide visibility into data and process flows both within the EAM system and within the dataflow studio, optionally wherein the 360 transaction view component allows a user to troubleshoot a message transaction utilizing an end-to-end view of messages between the EAM system and the dataflow studio.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f). This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
The additional elements of the dependent claims, when considered both individually and in the context of the independent claims, are not anything significantly more than the judicial exception.
Accordingly, claims 1-20 are rejected under 35 USC 101.
Therefore based on the above analysis as conducted based on MPEP 2106 from the United States Patent and Trademark Office the claims are viewed as a court recognized abstract idea, are viewed as a judicial exception, does not integrate the claims into a practical application, does not provide significantly more, and does not provide an inventive concept, therefore the claims are ineligible.
Claim Rejections - 35 USC § 112
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 4, 8, 11, 15, 18, the terms "ToEAM" and “FromEAM” renders the claim indefinite because they are neither a term of art in the field or a name recognized in any published standard, industry specification, or commercially available product predating the application. The claims are unclear, there are acronyms in the claims but each term (word) of the acronym is not defined. The applicant does not clearly define the terms in the claims or in the originally filed disclosure. A court will not find a patented claim indefinite unless the claim interpreted in light of the specification and the prosecution history fails to "inform those skilled in the art about the scope of the invention with reasonable certainty." Id. at 899, 110 USPQ2d at 1689. Even if the specification uses the same term of degree as in the claim, a rejection is proper if the scope of the term is not understood when read in light of the specification. While, as a general proposition, broadening modifiers are standard tools in claim drafting in order to avoid reliance on the doctrine of equivalents in infringement actions, when the scope of the claim is unclear a rejection under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph, is proper. See In re Wiggins, 488 F. 2d 538, 541, 179 USPQ 421, 423 (CCPA 1973). It is also unclear if "ToEAM" and “FromEAM” is a trademark. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). In that case the claim scope is uncertain since a trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Because "ToEAM" and “FromEAM” are applicant-coined labels used without definition in either the claims or the specification, a person of ordinary skill in the art cannot determine the metes and bounds of the claimed "ToEAM" and “FromEAM” with reasonable certainty. The claims are indefinite under 35 USC 112(b).
Regarding claims 2, 9, 16, the term "UUID” renders the claim indefinite because the neither are term of art in the field or a name recognized in any published standard, industry specification, or commercially available product predating the application. The claims are unclear, there are acronyms in the claims but each term (word) of the acronym is not defined. The applicant does not clearly define the term in the claims or in the originally filed disclosure. A court will not find a patented claim indefinite unless the claim interpreted in light of the specification and the prosecution history fails to "inform those skilled in the art about the scope of the invention with reasonable certainty." Id. at 899, 110 USPQ2d at 1689. Even if the specification uses the same term of degree as in the claim, a rejection is proper if the scope of the term is not understood when read in light of the specification. While, as a general proposition, broadening modifiers are standard tools in claim drafting in order to avoid reliance on the doctrine of equivalents in infringement actions, when the scope of the claim is unclear a rejection under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph, is proper. See In re Wiggins, 488 F. 2d 538, 541, 179 USPQ 421, 423 (CCPA 1973). Because "UUID” is an applicant-coined label used without definition in either the claims or the specification, a person of ordinary skill in the art cannot determine the metes and bounds of the claimed "UUID” with reasonable certainty. The claims are indefinite under 35 USC 112(b).
Regarding claims 3, 10, 17 the term "IoT/sensor devices” renders the claim indefinite because the neither are term of art in the field or a name recognized in any published standard, industry specification, or commercially available product predating the application. The claims are unclear, there are acronyms in the claims but each term (word) of the acronym is not defined. The applicant does not clearly define the term in the claims or in the originally filed disclosure. A court will not find a patented claim indefinite unless the claim interpreted in light of the specification and the prosecution history fails to "inform those skilled in the art about the scope of the invention with reasonable certainty." Id. at 899, 110 USPQ2d at 1689. Even if the specification uses the same term of degree as in the claim, a rejection is proper if the scope of the term is not understood when read in light of the specification. While, as a general proposition, broadening modifiers are standard tools in claim drafting in order to avoid reliance on the doctrine of equivalents in infringement actions, when the scope of the claim is unclear a rejection under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph, is proper. See In re Wiggins, 488 F. 2d 538, 541, 179 USPQ 421, 423 (CCPA 1973). Because "IoT/sensor devices” is an applicant-coined label used without definition in either the claims or the specification, a person of ordinary skill in the art cannot determine the metes and bounds of the claimed "IoT/sensor devices” with reasonable certainty. The claims are indefinite under 35 USC 112(b).
Claims 4, 11, 18, are indefinite. The claims appear to contain the trademark/trade name “AWS”, “SQS”, “BOD” queues. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe AWS (Amazon Web Services), SQS (Amazon Simple Que Service) accordingly, the identification/description is indefinite.
Regarding claims 4, 11, 18, the terms “AWS SQS BOD queues” renders the claim indefinite because although the terms appear to be directed to a trademark or trade name, the applicant does not clearly define the terms in the claims or in the originally filed disclosure, therefore the metes and bounds of the claims are not clear. The claims are unclear, there are acronyms in the claims but each term (word) of the acronym is not defined. A court will not find a patented claim indefinite unless the claim interpreted in light of the specification and the prosecution history fails to "inform those skilled in the art about the scope of the invention with reasonable certainty." Id. at 899, 110 USPQ2d at 1689. Even if the specification uses the same term of degree as in the claim, a rejection is proper if the scope of the term is not understood when read in light of the specification. While, as a general proposition, broadening modifiers are standard tools in claim drafting in order to avoid reliance on the doctrine of equivalents in infringement actions, when the scope of the claim is unclear a rejection under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph, is proper.
Regarding claims 4, 11, 18 the term "RESTful API” renders the claim indefinite because the neither are term of art in the field or a name recognized in any published standard, industry specification, or commercially available product predating the application. The claims are unclear, there are acronyms in the claims but each term (word) of the acronym is not defined. The applicant does not clearly define the term in the claims or in the originally filed disclosure. A court will not find a patented claim indefinite unless the claim interpreted in light of the specification and the prosecution history fails to "inform those skilled in the art about the scope of the invention with reasonable certainty." Id. at 899, 110 USPQ2d at 1689. Even if the specification uses the same term of degree as in the claim, a rejection is proper if the scope of the term is not understood when read in light of the specification. While, as a general proposition, broadening modifiers are standard tools in claim drafting in order to avoid reliance on the doctrine of equivalents in infringement actions, when the scope of the claim is unclear a rejection under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph, is proper. See In re Wiggins, 488 F. 2d 538, 541, 179 USPQ 421, 423 (CCPA 1973). Because "RESTful API” is an applicant-coined label used without definition in either the claims or the specification, a person of ordinary skill in the art cannot determine the metes and bounds of the claimed "RESTful API” with reasonable certainty. The claims are indefinite under 35 USC 112(b).
The dependent claims inherit the rejections of the claims from which the depend.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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, 3, 5, 6, 8, 10, 12, 13, 15, 17, 19, is/are rejected under 35 U.S.C. 103 as being unpatentable over Behnen et al. (US 20070214171 A1) in view of Panikkar et al. (US 20220391805 A1) in view of Varghese (US 20230067833 A1).
Regarding claim 1, Behnen teaches at least one processor and at least one memory comprising instructions which, when run on the at least one processor, implements computer processes comprising (¶ 41-45, disclose processor and memory, Fig. 1-2);
dataflow studio comprising a graphical user interface for building and configuring customized business-specific data and process flows … (¶ 57, discloses a dataflow warehouse that has a data flow graphical editor that allows users to build data flows. ¶ 111, 170),
wherein the dataflow studio integrates with the system via an interface including a queue for sending records to the system and a queue for receiving records from the system (¶ 50, 54, 68, discloses data integration and various queues for sending and receiving data. ¶ 93-94, Fig. 6);
and an endpoint catalog comprising a centralized registry of enterprise applications that are available to the dataflow studio as endpoints for creating and managing application connections (¶ 81-82, discloses resource references maintained as part of the system input including structured query language resources where the resource references includes information regarding each runtime engine. An operator may need to indicate the structured query language table exists in a particular database so the database resource reference associated is associate with the operator. ¶ 67).
Behnen does not specifically teach the term EAM. However, Panikkar discloses integrating an enterprise asset management (EAM) system with enterprise applications (¶ 38-40, 42-44, 46, disclose integrating an EAM with an enterprise application.);
the EAM system and enterprise applications (¶ 44-48, disclose process flows between the EAM system and other applications. ¶ 53);
wherein the dataflow studio integrates with the EAM system via an API including a ToEAM queue for sending records to the EAM system and a FromEAM queue for receiving records from the EAM system (abstract, ¶ 47-48, 39, 62, 68, discloses an API and sending records. Abstract, ¶ 4, 35-36, 39-40, disclose receiving records in from EAM system);
for data integrations between the EAM system and the enterprise applications (¶ 47-49, 53, 62, 66, show data integrations between the applications and the EAM system.).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform the EAM system, as taught/suggested by Panikkar. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Panikkar would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Panikkar to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such EAM features into similar systems. Further, applying EAM would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the centralizing and management of physical assets throughout their lifecycle.
Behnen does not specifically teach the term no-code. However, Varghese discloses a dataflow studio comprising a no-code graphical user interface for building and configuring customized business-specific data and process flows (¶ 15, 40, 41, 46, 60, no-code development including drag and drop.)
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform a no-code graphical user interface, as taught/suggested by Varghese. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow integration within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Varghese would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Varghese to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such no-code features into similar systems. Further, applying a no-code graphical user interface would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow allows users to build and configure applications through visual, drag‑and‑drop tools without writing any code.
Regarding claims 3, 10, 17, Behnen teaches wherein the enterprise applications include at least one of: enterprise applications internal to the system; enterprise applications external to the system; or IoT/sensor devices (¶ 50, 54, 56, 60, 68, discloses data integration and various queues for sending and receiving data. ¶ 93-94, 102, 104, 142, Fig. 6).
Behnen does not specifically teach EAM systems. However, Panikkar teaches an EAM system and the enterprise applications (¶ 47-49, 53, 62, 66, show data integrations between the applications and the EAM system.) or IoT/sensor devices (¶ 38, 40, 44-46, 56, discloses or IoT/sensor devices).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform the EAM system, as taught/suggested by Panikkar. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Panikkar would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Panikkar to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such EAM features into similar systems. Further, applying EAM would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the centralizing and management of physical assets throughout their lifecycle.
Regarding claims 5, 12, 19, Behnen teaches wherein the dataflow studio is configured to allow a user to build and configure a flow by linking processors that receive and process data from the system for use by an enterprise application endpoint and/or receive and process data from the enterprise application endpoint for use by the system (¶ 75-79, disclose extracting filtering, joining, loading a chain moving data in directions across regions. Fig. 4-6).
Behnen does not specifically teach EAM systems. However, Panikkar teaches an EAM system and the enterprise applications (¶ 47-49, 53, 62, 66, show data integrations between the applications and the EAM system.).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform the EAM system, as taught/suggested by Panikkar. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Panikkar would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Panikkar to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such EAM features into similar systems. Further, applying EAM would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the centralizing and management of physical assets throughout their lifecycle.
Behnen does not specifically teach the term no-code. However, Varghese discloses optionally wherein the dataflow studio comprises a drag-and-drop interface to build and configure the flow (¶ 15, 40, 41, 46, 60, no-code development including drag and drop.)
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform a no-code graphical user interface, as taught/suggested by Varghese. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow integration within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Varghese would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Varghese to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such no-code features into similar systems. Further, applying a no-code graphical user interface would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow users to build and configure applications through visual, drag‑and‑drop tools without writing any code.
Regarding claims 6, 13, Behnen teaches integration component; a transformation component; and an analysis component (¶ 5, 8, 50, 53-56, 60, 75, 80, 102, 111, disclose the various components).
Regarding claim 8, Behnen teaches a computer program product comprising at least one tangible, non-transitory computer-readable medium having embodied therein computer program instructions for integrating a system with enterprise applications (¶ 41-45, disclose processor and memory, Fig. 1-2);
dataflow studio comprising a graphical user interface for building and configuring customized business-specific data and process flows … (¶ 57, discloses a dataflow warehouse that has a data flow graphical editor that allows users to build data flows. ¶ 111, 170),
wherein the dataflow studio integrates with the system via an interface including a queue for sending records to the system and a queue for receiving records from the system (¶ 50, 54, 68, discloses data integration and various queues for sending and receiving data. ¶ 93-94, Fig. 6);
and an endpoint catalog comprising a centralized registry of enterprise applications that are available to the dataflow studio as endpoints for creating and managing application connections (¶ 81-82, discloses resource references maintained as part of the system input including structured query language resources where the resource references includes information regarding each runtime engine. An operator may need to indicate the structured query language table exists in a particular database so the database resource reference associated is associate with the operator. ¶ 67).
Behnen does not specifically teach the term EAM. However, Panikkar discloses integrating an enterprise asset management (EAM) system with enterprise applications (¶ 38-40, 42-44, 46, disclose integrating an EAM with an enterprise application.);
the EAM system and enterprise applications (¶ 44-48, disclose process flows between the EAM system and other applications. ¶ 53);
wherein the dataflow studio integrates with the EAM system via an API including a ToEAM queue for sending records to the EAM system and a FromEAM queue for receiving records from the EAM system (abstract, ¶ 47-48, 39, 62, 68, discloses an API and sending records. Abstract, ¶ 4, 35-36, 39-40, disclose receiving records in from EAM system);
for data integrations between the EAM system and the enterprise applications (¶ 47-49, 53, 62, 66, show data integrations between the applications and the EAM system.).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform the EAM system, as taught/suggested by Panikkar. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Panikkar would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Panikkar to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such EAM features into similar systems. Further, applying EAM would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the centralizing and management of physical assets throughout their lifecycle.
Behnen does not specifically teach the term no-code. However, Varghese discloses a dataflow studio comprising a no-code graphical user interface for building and configuring customized business-specific data and process flows (¶ 15, 40, 41, 46, 60, no-code development including drag and drop.)
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform a no-code graphical user interface, as taught/suggested by Varghese. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow integration within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Varghese would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Varghese to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such no-code features into similar systems. Further, applying a no-code graphical user interface would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow allows users to build and configure applications through visual, drag-and-drop tools without writing any code.
Regarding claim 15, Behnen teaches a method for integrating a system with enterprise applications (¶ 41-45, disclose processor and memory, Fig. 1-2);
providing a dataflow studio comprising a graphical user interface for building and configuring customized business-specific data and process flows … (¶ 57, discloses a dataflow warehouse that has a data flow graphical editor that allows users to build data flows. ¶ 111, 170),
wherein the dataflow studio integrates with the system via an interface including a queue for sending records to the system and a queue for receiving records from the system (¶ 50, 54, 68, discloses data integration and various queues for sending and receiving data. ¶ 93-94, Fig. 6);
providing an endpoint catalog comprising a centralized registry of enterprise applications that are available to the dataflow studio as endpoints for creating and managing application connections (¶ 81-82, discloses resource references maintained as part of the system input including structured query language resources where the resource references includes information regarding each runtime engine. An operator may need to indicate the structured query language table exists in a particular database so the database resource reference associated is associate with the operator. ¶ 67).
Behnen does not specifically teach the term EAM. However, Panikkar discloses integrating an enterprise asset management (EAM) system with enterprise applications (¶ 38-40, 42-44, 46, disclose integrating an EAM with an enterprise application.);
the EAM system and enterprise applications (¶ 44-48, disclose process flows between the EAM system and other applications. ¶ 53);
wherein the dataflow studio integrates with the EAM system via an API including a ToEAM queue for sending records to the EAM system and a FromEAM queue for receiving records from the EAM system (abstract, ¶ 47-48, 39, 62, 68, discloses an API and sending records. Abstract, ¶ 4, 35-36, 39-40, disclose receiving records in from EAM system);
for data integrations between the EAM system and the enterprise applications (¶ 47-49, 53, 62, 66, show data integrations between the applications and the EAM system.).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform the EAM system, as taught/suggested by Panikkar. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Panikkar would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Panikkar to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such EAM features into similar systems. Further, applying EAM would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the centralizing and management of physical assets throughout their lifecycle.
Behnen does not specifically teach the term no-code. However, Varghese discloses a dataflow studio comprising a no-code graphical user interface for building and configuring customized business-specific data and process flows (¶ 15, 40, 41, 46, 60, no-code development including drag and drop.)
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform a no-code graphical user interface, as taught/suggested by Varghese. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow integration within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Varghese would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Varghese to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such no-code features into similar systems. Further, applying a no-code graphical user interface would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow allows users to build and configure applications through visual, drag-and-drop tools without writing any code.
Claim(s) 2, 9, 16, is/are rejected under 35 U.S.C. 103 as being unpatentable over Behnen et al. (US 20070214171 A1) in view of Panikkar et al. (US 20220391805 A1) in view of Varghese (US 20230067833 A1) in further view of Volkerink et al. (US 20200265288 A1).
Regarding claims 2, 9, 16, Behnen teaches an endpoint catalog comprising a centralized registry of enterprise applications that are available to the dataflow studio as endpoints for creating and managing application connections (¶ 81-82, discloses resource references maintained as part of the system input including structured query language resources where the resource references includes information regarding each runtime engine. An operator may need to indicate the structured query language table exists in a particular database so the database resource reference associated is associate with the operator. ¶ 67-69);
querying the system by the dataflow studio for specific endpoint connections in the endpoint catalog (¶ 81, 67-68, discloses introducing a dataflow system with various resources, that each operator instance carries a resource reference identifying the runtime system. Each resource reference includes information regarding each runtime engine. The operator definition mechanism is consulted to determine a code generator and region apply to a given resource.);
causing display listing the specific endpoint connections on a display device of a user computer (¶ 57, discloses a graphical interactive user interface for a dataflow. Also discloses using a dataflow graphical editor that allows users to build dataflows. An interactive graphical user editor);
in response to receiving a user input of a selected specific endpoint connection, mapping, by the dataflow studio, the selected specific endpoint connection to a corresponding processor type (¶ 69, discloses mapping a selected operation to a processor type classification. This is a mapping selected resource operation to a corresponding processor type);
configuring the selected specific endpoint connection using metadata values from the system, and writing … to the system as endpoint metadata for reference (¶ 82-83, discloses an operator’s properties are configured using the metadata of a resource. ¶ 97, discloses generating a unique identifier for a created processing artifact and tracking that identifier as a referenceable attribute across the system.);
Behnen does not specifically teach EAM systems. However, Panikkar teaches an EAM system (¶ 47-49, 53, 66, show data integrations between the applications and the EAM system. ¶ 56-62, disclose asset data that external systems retrieve from and update via API integration. Fig. 5); endpoint connection using metadata values from the EAM system (¶ 62, 66, discloses making changes that are updated in the EAM); and updating endpoint metadata for the endpoint in the system including querying the dataflow studio by the system for a reference to the processor and updating the endpoint metadata based on the reference to the processor (¶ 60, 66, 68, discloses a device gateway from the IoT hub as data as confirmation of the meta data change. The changes are updated in the EAM via API integration. The device gateway will send reported properties back to the IoT Hub to confirm that the desired properties are reflected. Fig. 6).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform the EAM system, as taught/suggested by Panikkar. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Panikkar would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Panikkar to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such EAM features into similar systems. Further, applying EAM would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the centralizing and management of physical assets throughout their lifecycle.
Behnen does not specifically teach tenant specific endpoint connection. However, Varghese discloses tenant specific endpoint connection (¶ 12, discloses a dedicated tenant).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform tenant specific endpoint connection, as taught/suggested by Varghese. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow integration within application systems. One of ordinary skill in the art would have recognized that applying the known technique of Varghese would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Varghese to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such tenant features into similar systems. Further, applying tenant specific endpoint connection would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for additional security on the data sent.
Behnen does not specifically teach causing display of a dialog box or write a UUID. However, Volkerink discloses causing display of a dialog box (¶ 96, discloses display of a dialog box).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform display of a dialog box, as taught/suggested by Volkerink. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow/ workflow processing. One of ordinary skill in the art would have recognized that applying the known technique of Volkerink would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Volkerink to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such dialog box features into similar systems. Further, applying a dialog box would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for additional interaction between the user and the application.
Volkerink discloses writing a UUID of the processor to the system as endpoint metadata for reference (¶ 65, 94, 96, 104, discloses the use of UUIDs).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform a UUID of the processor to the system, as taught/suggested by Volkerink. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to data flow/ workflow processing. One of ordinary skill in the art would have recognized that applying the known technique of Volkerink would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Volkerink to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such UUID features into similar systems. Further, applying a UUID of the processor to the system would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for an additional layer of security.
Claim(s) 4, 11, 18, is/are rejected under 35 U.S.C. 103 as being unpatentable over Behnen et al. (US 20070214171 A1) in view of Panikkar et al. (US 20220391805 A1) in view of Varghese (US 20230067833 A1) in further view of Duggal et al. (US 20240370826 A1).
Regarding claims 4, 11, 18, the combination of Behnen and Panikkar teaches ToEAM and FromEAM queues. The combination does not specifically teach AWS SQS BOD queues. However, Duggal teaches wherein at least one of: the ToEAM queue and the FromEAM queue are managed AWS SQS BOD queues; the API further includes a RESTful API; or the dataflow studio is configured to periodically query the FromEAM queue for records from the EAM system (¶ 113, 132, 143, discloses managed AWS SQS BOD queues).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform a AWS SQS BOD queue, as taught/suggested by Duggal. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to generating events. One of ordinary skill in the art would have recognized that applying the known technique of Duggal would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Duggal to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such AWS SQS BOD queue features into similar systems. Further, applying AWS SQS BOD queues would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for message queuing service that enables message storage and retrieval.
Claim(s) 7, 14, 20, is/are rejected under 35 U.S.C. 103 as being unpatentable over Behnen et al. (US 20070214171 A1) in view of Panikkar et al. (US 20220391805 A1) in view of Varghese (US 20230067833 A1) in further view of Wang (US 20240370826 A1).
Regarding claims 7, 14, 20, the combination of Behnen and Panikkar teaches ToEAM and FromEAM queues. The combination does not specifically teach a 360 transaction view component configured to integrate data events from the dataflow studio. However, Wang teaches wherein the computer processes further comprise: a 360 transaction view component configured to integrate data events from the dataflow studio into a user-comprehensible flow to provide visibility into data and process flows both within the EAM system and within the dataflow studio, optionally wherein the 360 transaction view component allows a user to troubleshoot a message transaction utilizing an end-to-end view of messages between the EAM system and the dataflow studio (¶ 7-10, discloses creating complete picture dataflows. ¶ 23-33, 36, 38, 44-45, discloses the steps of creating the dataflow.).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Behnen to include/perform a 360 transaction view component configured to integrate data events from the dataflow studio, as taught/suggested by Wang. This known technique is applicable to the system of Behnen as they both share characteristics and capabilities, namely, they are directed to analyzing and manipulating data. One of ordinary skill in the art would have recognized that applying the known technique of Wang would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Wang to the teachings of Behnen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such a 360 transaction view component configured to integrate data events from the dataflow studio features into similar systems. Further, applying a 360 transaction view component configured to integrate data events from the dataflow studio would have been recognized by those of ordinary skill in the art as resulting in an improved system that would provide a unified, real-time source, eliminating redundant data entry.
Other pertinent prior art includes Andrews et al. (US 20260030860 A1) discloses RESTful API and AWS SQS BOD queues. Ma et al. (US 20190138299 A1) which discloses managing the software development lifecycle of an industrial-based software application. Spira et al. (US 20030172002 A1) which discloses providing a menu of services to the owners or operators of a plant for a variety of management and operation services.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMIE H AUSTIN whose telephone number is (571)272-7363. The examiner can normally be reached Monday, Tuesday, Thursday, Friday 7am-2pm.
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, Brian Epstein can be reached at (571) 270 5389. 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.
JAMIE H. AUSTIN
Examiner
Art Unit 3625
/JAMIE H AUSTIN/Primary Examiner, Art Unit 3625
Prosecution Insights