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 of the Claims
Claims 1-7 and 15-20 were previously pending and subject to a office action mailed 02/10/2026. Claims 1, 15 and 17 were amended; no claim was cancelled, or added in a reply filed 05/11/2026. Therefore claims 1-7 and 15-20 are currently pending and subject to the final office action below.
Response to Arguments
Applicant's arguments filed 05/11/2026 in regards to section 101 rejection have been fully considered but they are not persuasive.
Applicant argues “claim 1 has been amended to recite monitoring, by a Real-Time Data Mesh (RTDM), real-time data changes across a plurality of transactional systems including ERP systems and CRM systems; capturing the real-time data changes using one or more Change Data Capture (CDC) mechanisms; processing and standardizing the captured data for storage in a data layer comprising a data mesh and a plurality of Purposive Datastores (PDSes),… These limitations integrate any alleged commercial concept into a practical application. The amended claim uses a specific RTDM data architecture to solve a data-integration problem in CTO processing, namely that current inventory, product, customer, pricing, and transaction data from ERP and CRM systems must be captured, standardized, stored, and retrieved in a form usable by the CTO process…This does not merely apply a business practice on a generic computer. The claimed method recites how data changes are captured, standardized, stored, retrieved, and used in a recursive BOM generation and CRM-linked deal-registration process.” (remarks p. 7-9).
Examiner respectfully disagrees. While Applicant has amended claim 1 to include additional technical terminology, including “real time data mesh (RTDM)”, “change data capture (CDC) mechanism”, “data mesh” and “purposive datastores (PDSes), the mere recitation of these labels does not transform the underlying abstract idea into a practical application under step 2A, prong 2 of the USPTO’s 2019 revised guidance.
Under MPEP 2106.04(d), a claim that recites a judicial exception is considered to integrate the exception into a practical application only when the additional elements impose a meaningful limit on the judicial exception as a whole. MPEP 2106.04(d) identifies specific considerations for determining whether such integration exists, including whether the additional elements “reflect an improvement in the functioning of a computer or to any other technology or technical field” The Examiner finds that no such improvement has been identified by Applicant. The recitation of “real time data mesh (RTDM), “change data capture (CDC) mechanism” and “purposive datastores (PDSes) are each functional labels that describe what those components accomplish, monitor, capture, standardize, store, without specifying how they do so in a technically distinct or improved manner relative to conventional data integration systems.
MPEP 2106.05(f) further provides that courts have held that additional elements of collecting information, analyzing it, displaying the results, when claimed in the context of abstract ideas, does not amount to significantly more than the abstract idea itself. the amended claim’s core data pipeline, monitoring data changes, capturing them, standardizing and storing them, and making them available for downstream processing is precisely the type of collect, analyze, store, retrieve sequence that MPEP 2106.05(f) identifies as insufficient to provide significantly more than the underlying abstract idea.
Furthermore, MPEP 2106.04(d) provides that a claim integrates a judicial exception into a practical application when, among other things, it applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Applicant has identified a business domain problem, coordinating supply chain data across ERP and CRM systems for CTO processing, rather than a specific improvement to computer functionality. MPEP 2106.04(a)(2) identifies certain methods of organizing human activity, including managing commercial transactions and commercial interactions, as abstract idea. The problem of integrating data across enterprise systems to facilitate a commercial quoting and ordering process falls squarely within this category.
For practical application finding, Applicant must identify a specific technical improvement to how a computer stores, retrieves, or processes data, not merely a commercial benefit from having access to integrated data (please see MPEP 2106.04(d)).
MPEP 2106.05(f) also instructs that additional elements which merely recite the words “apply it” (or an equivalent) or add a step of “storing” results using a computer are not sufficient to provide significantly more than the abstract idea. Each step of the amended claim 1 recites a functional result without specifying the technical mechanism by which it is achieved. For example, “capturing the real time data change using one or more change data capture (CDC) mechanisms”, identifies a category of technique without specifying a particular CDC mechanism; “generating a hierarchical bill of materials (GOM using a recursive algorithm that traverses parent child component relationships”, identifies a category of algorithm without specifying a particular algorithmic implementation.
Under MPEP 2106.05(d) additional elements that represent “well understood, routine, conventional activity cannot supply the significantly more required to transform a judicial exception into a patent eligible subject matter.
Applicant argues “The specification describes the technical context for these amended limitations. Paragraphs [0121]-[0129] describe RTDM module 600 as a data mesh and change capture component configured to provide real-time data management and standardization, including integration layer 610 for enterprise systems and data layer 620 including a data mesh and PDSes for customer data, product data, and inventory data. Paragraphs [0143]-[0147] describe CTO Module 720 interacting with RTDM 710 and SPoG UI 705, Configuration Builder 720.1 fetching real-time data from RTDM 710, BOM Generator 720.2 matching BOM information against real-time inventory data from RTDM 710 using RESTful APIs or similar data connectors and using a recursive algorithm to list parts and components in a multi-level hierarchy, and Deal Registration Handler 720.3 connecting to CRM systems via APIs, checking account-based customizations or restrictions through SQL or similar database calls, and using OAuth 2.0 for secure API calls to CRM systems. The amended claim language is therefore tied to disclosed computer architecture and data processing operations.” (remarks p. 9-10).
Examiner respectfully disagrees. Under MPEP 2106.04(a), the eligibility analysis is applied to the claims as written. The specification may be used to understand what the claims are directed to, but cannot add limitations that do not appear in the claims themselves. Claim 1 recites “secure API calls or database queries” which is language that broadly encompasses any API call or database query in any computing environment, regardless of the specific OAuth 2.0 and SQL implementation described in the specification. The claim does not recite OAuth 2.0, does not recite SQL, and does not recite any other specific technical mechanism that would distinguish the claimed implementation from a conventional API-based data retrieval system.
Moreover, even if the specific technical details of the specification were imported into the claims, MPEP 2106.05(d) provides that well-understood, routine, conventional techniques, including RESTful APIs, SQL queries, and OAuth 2.0 authentication, cannot supply the significantly more required for patent eligibility.
Applicant argues “Amended independent claim 15 is patent eligible for the same reasons. Claim 15 no longer recites only a generic RTDM that aggregates and disseminates data, a generic SPoG UI, and generic CTO/QTO modules. Instead, claim 15 recites a system architecture comprising an RTDM configured to monitor real-time data changes across ERP and CRM systems, capture those changes using CDC mechanisms, process and standardize the captured data for storage in a data layer comprising a data mesh and PDSes, and retrieve current supply-chain data from those PDSes. Claim 15 also recites a CTO Module comprising a BOM Generator configured to generate a hierarchical BOM using a recursive algorithm and match the BOM against RTDM real-time inventory data using RESTful APIs or data connectors, and a Deal Registration Handler configured to connect to CRM systems through APIs, log transactions, check account- based customization restrictions, and retrieve CRM data through the RTDM using secure API calls or database queries.” (remarks p. 10).
Examiner respectfully disagrees. The 101 analysis applies equally to system and method claims, the form of the claim does not change the analysis. Under MPEP 2106.05(d), a generic computer component that performs a generic computer function does not provide significantly more than the abstract idea itself. Claim 15 components, “RTDM configured to monitor”, “BOM generator configured to generate”, “Deal registration Handler configured to connect”, are each defined solely by the function they perform. No structural feature is recited that distinguishes these components from a generic processor executing software to perform those named functions. The “configured to” language does not provide structural specificity beyond the functional description of the abstract idea.
Applicant’s arguments in support of claim 15 are the same as those advanced for claim 1. For the reasons set forth above with respect to claim 1, those arguments are equally unpersuasive with respect to claim 15. The rejection of claim 1-7 and 15-20 under 35 USC 101 is maintained.
Applicant’s arguments with respect to 103 rejection have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's arguments filed 05/11/2026 in regards to 112(f) interpretation have been fully considered but they are not persuasive. Applicant argues “The claims as amended recite sufficient structure and acts for the claimed computer- implemented functions. For example, amended claim 1 recites an RTDM configured to monitor real-time data changes, capture the changes using CDC mechanisms, process and standardize captured data, store the data in a data layer comprising a data mesh and PDSes, and retrieve current supply-chain data for use in the CTO process. Claim 1 further recites a CTO Module, SPoG UI, Deal Registration Handler, RESTful APIs or data connectors, secure API calls, database queries, and specific operations performed by those components. Similarly, amended claim 15 recites specific system components and their operative relationships, including an RTDM, SPoG UI, AAML Module, CTO Module, BOM Generator, Deal Registration Handler, and QTO Module. These components are not generic placeholders divorced from structure. The claims recite how the components interact and what data-processing operations they perform.” (remarks p. 13).
Examiner respectfully disagrees. MPEP 2181(I) states that “A claim limitation is presumed to invoke 35 U.S.C. 112(f) when it explicitly uses the term "means" or "step" and includes functional language. The presumption that 35 U.S.C. 112(f) applies is overcome when the limitation further includes the structure, material or acts necessary to perform the recited function. See TriMed, Inc. v. Stryker Corp., 514 F.3d 1256, 1259-60, 85 USPQ2d 1787, 1789 (Fed. Cir. 2008) ("Sufficient structure exists when the claim language specifies the exact structure that performs the function in question without need to resort to other portions of the specification or extrinsic evidence for an adequate understanding of the structure.")…The presumption that 35 U.S.C. 112(f) does not apply to a claim limitation that does not use the term "means" is overcome when "the claim term fails to 'recite sufficiently definite structure' or else recites 'function without reciting sufficient structure for performing that function.' in claim 15, “AAML module, CTO module and QTO module” do not recite any structure that performs the function in question without need to resort to other portions of the specification to determine what a “module” is and what is represents as structure. Claim 15 also recite the functions of the module without attribute or modifying “module” with any structure. Therefore, these limitations invoke 112(f).
Applicant’s arguments, see remarks p. 14, filed 05/11/2026, with respect to claim objections have been fully considered and are persuasive. The objection to claim 17 has been withdrawn.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: AAML module, CTO module, a Bill of Materials (BOM) generator and a deal registration handler in claim 15.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 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-7 and 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim “monitoring real-time data changes; capturing the real-time data changes; processing and standardizing the captured data; retrieving current supply-chain data for use in the CTO process, the current supply-chain data comprising inventory data, product data, customer data, pricing data, or transaction data; executing, the CTO process by receiving a user-generated product- configuration request [by] fetching real-time inventory data and available customization options; generating a hierarchical bill of materials (BOM) using a recursive algorithm that traverses parent-child component relationships; matching the generated BOM against real-time inventory data; log a transaction and check account-based customizations or restrictions; and retrieving, current CRM data comprising customization restrictions or previously negotiated pricing conditions using secure API calls or database queries;”
The limitations above, as drafted, is a process that, under its broadest reasonable interpretation, covers a method of executing a CTO which is a certain method of organizing a human activity, mental processes and mathematical concepts. That is, the method allows commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions, processes done in the human mind and processes that reflect mathematical relationships/formula.
This judicial exception is not integrated into a practical application. In particular, the claim recites a Real-Time Data Mesh (RTDM), a plurality of transactional systems including ERP systems and CRM systems; one or more Change Data Capture (CDC) mechanisms; a data layer comprising a data mesh and a plurality of Purposive Datastores (PDSes), wherein each PDS is configured to store and retrieve a specific type of supply-chain data; a CTO Module in communication with the RTDM and a Single Pane of Glass User Interface (SPoG UI), RESTful APIs or data connectors; connecting a Deal Registration Handler to one or more CRM systems via APIs. Each of the additional limitations is no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, alone or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements, alone or in combination, are nothing more than mere instructions to apply the exception on a general computer. In addition, the specification of the application as filed (paragraphs 51-77) does not provide any indication that the additional elements descried above are anything other than generic, off the shelf computer components, and MPEP 2106.05(d)(II) indicate that mere collection or receipt and transmission of data over a network and accessing a memory is a well-understood, routine and conventional function when it is claimed in a merely generic manner (as it is here). Accordingly, a conclusion that the sending and accessing steps are well-understood, routine, and conventional activity is supported under Berkheimer.
Dependent claim 2/3/4/5/6/7 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application (BOM database in claim 4, vendor system in claim 6 and notification in claim 7 are recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim “monitor real-time data changes, capture the real- time data changes, process and standardize the captured data for storage, and retrieve current supply-chain data, the current supply-chain data comprising inventory data, product data, customer data, pricing data, or transaction data ”
The limitations above, as drafted, is a process that, under its broadest reasonable interpretation, covers a method of organizing a human activity and mental processes. That is, the method allows commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) and processes done in the human mind.
This judicial exception is not integrated into a practical application. In particular, the claim recites a Real-Time Data Mesh (RTDM); a plurality of transactional systems including ERP systems and CRM systems; one or more Change Data Capture (CDC) mechanisms; a data layer comprising a data mesh and a plurality of Purposive Datastores (PDSes); a Single Pane of Glass User Interface (SPoG UI); an Advanced Analytics and Machine Learning (AAML) Module; machine-learning algorithms; a Configuration to Order (CTO) Module interacting with the SPoG UI and the Real-Time Data Mesh; a Bill of Materials (BOM) Generator; RESTful APIs or data connectors; and a Deal Registration Handler configured to connect to one or more CRM systems via APIs; secure API calls or database queries; and a Quote to Order (QTO) Module in communication with the RTDM and the SPoG UI, the QTO Module. Each of the additional limitations is recited at a high level of generality and is no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, alone or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements, alone or in combination, are nothing more than mere instructions to apply the exception on a general computer.
Dependent claim 16/17/18/19/20 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 15 without successfully integrating the exception into a practical application (CTO module further comprises a logging mechanism to track all configuration changes for auditing purposes in claim 16, the CTO Module and the QTO Module integrated with the AAML Module in claim 17, SPoG UI is accessible from a variety of devices, including desktops, laptops, tablets and smartphones in claim 18, Real-Time Data Mesh is configured to standardize data into a uniform format suitable for consumption by the SPoG UI and other system modules in claim 19, machine learning models integrated into the CTO Module and the QTO Module, said models configured to optimize and refine processes within each module over time based on past transactions and evolving data patterns in claim 20, are recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Claim Rejections - 35 USC § 103
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hochheiser (US 20200126013) in view of Makhija (US 202000279200), Hwang (US 20140156329), Pinheiro (US 20220114509).
As per claim 15/1, Hochheiser discloses a system for automating Configure to Order (CTO) and Quote to Order (QTO) processes, comprising:
A plurality of transaction systems including ERP systems and CRM systems (paragraph 14, “0014] The systems, apparatuses, devices, and methods disclosed herein generally relate to real-time process integration between a various systems, such as a customer relationship management (CRM) system and an enterprise resource planning (ERP) system, thereby allowing for rapid integration of data presented from both systems and bi-directional data movement along a business process flow. “)
receive a user-generated product-configuration request and display real-time data (0022] When creating a CPQ quote, the Salesforce Primary Account Data can be used as the default. A user can optionally change the CPQ Header Data as defined in the CPQ template using a real-time function “Sales Org Picker” call to fetch sales organization data from the SAP system to update the CPQ Quotation Header, as shown by the process 400 in FIG. 4. This approach utilizes a real-time API call to the ERP system to provide real-time data, as opposed to relying on potentially out of date data that is provided by a data sync. [0023] Similarly, when creating a CPQ quote line, Salesforce Primary Product Data can be used as the default. A user can change the CPQ Line Item Data as defined in CPQ template using real-time function “SAP Plant Picker” call to fetch available plants from the SAP system to update the CPQ Quotation Line Item, as shown by the process 500 in FIG. 5. Thus, real-time plant availability can be brought from the ERP system into the CRM system.);
store and execute rule based or machine learning algorithms for calculating optimized pricing incentives ([0034] At 958-972, a price simulation process can be performed. A customized Salesforce CPQ quote calculator plugin in accordance with the present disclosure, referred to as an opportunity pricing smart business object in FIGS. 9A-C, can be utilized to calculate pricing per the SAP Configuration. SAP Customer ID, Sales Area Data (Sales Organization, Distribution Channel, Division), Material ID, and Plant can be submitted to the opportunity pricing SBO which, in turn, calls the standard SAP BAPI to simulate the creations of an SAP document. The pricing data can then be returned from SAP via the framework described herein and stored on the Salesforce CPQ Quote Line Item.)
a Configuration to Order (CTO) module interacting with microcomponents ([0020] For the purposes of illustration, one example embodiment is described below in the context of a “Configure, Price, Quote” (CPQ) business workflow, as may be implemented through a CRM system, such as Salesforce, or implemented through other types of software platforms, such as cloud-based CPQ software offerings. As is to be appreciated, however, the approach described below can be readily usable for other workflows available through a CRM system. For instance, while the microcomponents described below are focused on performing tasks associated with the CPQ workflow, other CRM workflows can utilize other microcomponents, as may be required.);
a Configuration to Order (CTO) Module interacting with the SPoG UI and the data storage to execute Configure to Order tasks including deal registration, and pricing application ([0018] In accordance with various embodiments, the present disclosure utilizes real-time microcomponents that are schematically shown in FIG. 1. Such microcomponents 100A-F can focus on very specific tasks of creating, processing, and retrieving particular data and transactions from a customer relationship management system 102. The real-time microcomponents in accordance with the present disclosure, can operate independently or together utilizing workflows 104 associated with the associated CRM system 102 thereby allowing flexibility. Without limitations, example real-time microcomponents 100 A-F can be bounded to any CRM transactions or processes, such as related to opportunity, quotation, sales order, invoice, case, and so forth. Moreover, in some embodiments the CPQ functionality is provided by the CRM system 102. In other embodiments, the CPQ functionality is provided through a specialized software platform, such as a CPQ system. Beneficially, in accordance with some embodiments, such real-time microcomponents can be configurable by an administrator of the CRM system, thereby minimizing complex coding. Moreover, since real-time microcomponents 100A-F can be independent of each other, functional and technical upgrades can be minimally evasive, as one component can be upgraded or patched without necessarily affecting the others…[0034] At 958-972, a price simulation process can be performed. A customized Salesforce CPQ quote calculator plugin in accordance with the present disclosure, referred to as an opportunity pricing smart business object in FIGS. 9A-C, can be utilized to calculate pricing per the SAP Configuration. SAP Customer ID, Sales Area Data (Sales Organization, Distribution Channel, Division), Material ID, and Plant can be submitted to the opportunity pricing SBO which, in turn, calls the standard SAP BAPI to simulate the creations of an SAP document. The pricing data can then be returned from SAP via the framework described herein and stored on the Salesforce CPQ Quote Line Item.” Functionally, deal registration is logging or creating an opportunity/deal/quote/sales transaction in CRM. The system teaches creating opportunities quotations, and sales order related CRM transactions through microcomponents, which is the functional equivalent of deal registration.);
retrieval of materials detail including plants from SAP ([0031] At 938-956, a product configuration can be executed in accordance with the present disclosure. A customized visual force page can house a customized embedded flow for SAP Variant Configuration (VC). SAP VC characteristics and option dependencies can be displayed based on the SAP material and plant selected per the SAP configuration. A user can configure the item in Salesforce utilizing a lighting component in accordance with the present disclosure which calls a VC smart business object. Salesforce can make a web service call using an XML format structure according to the smart business object SAP add-on. Data can be in an XML Format structured in way to be efficiently handled by SAP.);
Deal Registration Handler configured to connect to one or more CRM systems via APIs to log a transaction and check account-based customizations or restrictions, and to retrieve current CRM data comprising customization restrictions or previously negotiated pricing conditions using secure API calls or database queries (paragraph 22, “This approach utilizes a real-time API call to the ERP system to provide real-time data, as opposed to relying on potentially out of date data that is provided by a data sync.”, [0024] Referring now to FIG. 6, after selecting a Salesforce product that is flagged as being configurable, a configuration icon can be graphically display on the CPQ item. Activating the configuration icon can allow a user to initiate an SAP variant configuration process. The variant configuration process can be used, for instance, when quoting complex products with complication specifications. Data as documented on a template worksheet can be passed to the SAP variant configuration through an API. A user can configure the system to view pricing during configuration or when the pricing is stored on the CPQ Quotation Line. After the configuration process, information such as Model, Material Characteristics, and Plant can be stored on CPQ Quote Line. Accordingly, using the process 600 shown in FIG. 6, as a product is being configured for a quote, various rule-based options can be retrieved from the ERP system in real-time and presented to the user through the CRM software interface., paragraph 28, “. Once the SAP customer ID is determined, a list of Sales Areas Data (Sales Org, Distribution Channel, Division) available for that customer in SAP can be pulled from SAP using API-based communication. “, [0018] In accordance with various embodiments, the present disclosure utilizes real-time microcomponents that are schematically shown in FIG. 1. Such microcomponents 100A-F can focus on very specific tasks of creating, processing, and retrieving particular data and transactions from a customer relationship management system 102. The real-time microcomponents in accordance with the present disclosure, can operate independently or together utilizing workflows 104 associated with the associated CRM system 102 thereby allowing flexibility. Without limitations, example real-time microcomponents 100 A-F can be bounded to any CRM transactions or processes, such as related to opportunity, quotation, sales order, invoice, case, and so forth. Moreover, in some embodiments the CPQ functionality is provided by the CRM system 102. In other embodiments, the CPQ functionality is provided through a specialized software platform, such as a CPQ system. Beneficially, in accordance with some embodiments, such real-time microcomponents can be configurable by an administrator of the CRM system, thereby minimizing complex coding. Moreover, since real-time microcomponents 100A-F can be independent of each other, functional and technical upgrades can be minimally evasive, as one component can be upgraded or patched without necessarily affecting the others., [0029] At 910-912, a customer smart bFusiness object passes the SAP customer ID to the Standard SAP BAPI to look up the customer using SAP customer ID. Customer details are returned, which can include sales area information associated with that customer. It is noted that SAP requires sales area data to process any price simulation or create any document, however, other CRM system may not have such a requirement. At 916, the user then selects an SAP Sales Area via the Salesforce interface. Then, as part of the sales area picker process, the sales area selection is saved to the CPQ quote header at 918. In accordance with various embodiments, future quotes can automatically display the previously selected sales area while giving the user the ability to change it, as may be necessary. It is noted that the CPQ quote configuration options are based on the sales area selected. Salesforce can also call a customized page, such as a visual force page, that contains an application that includes a particular process flow. Then, once the flow completes, there can be a visual force page action that is invoked which persists the information to the Salesforce CPQ quote header SObject record.”, the handler is mapped to the system’s CPQ microcomponents and smart business objects. They connect CRM and ERP systems through API/web services communications. This functionally teaches the claimed deal registration handler connected to CRM via APIs. Logging a ttransaction is functionally taught by creation and persistence of opportunity, quotation, and sales order transaction records in CRM/CPQ. Sales area data is customer/account specific data retrieved from SAP and associated with the Salesforce account/CPQ quote. Because configuration options depend on the selected sales area, the system teaches checking account based customization options or restrictions. Customer specific sales area data corresponds to customization restrictions because it controls available CPQ options. Pricing data returned to the quote line corresponds to pricing conditions. The system teaches retrieving that data using API communications. );
a Quote to Order (QTO) Module in communication with the data storage and the SPoG UI, the QTO Module configured to generate an automated quote based on optimized pricing calculated by the AAML Module and materials ([0034] At 958-972, a price simulation process can be performed. A customized Salesforce CPQ quote calculator plugin in accordance with the present disclosure, referred to as an opportunity pricing smart business object in FIGS. 9A-C, can be utilized to calculate pricing per the SAP Configuration. SAP Customer ID, Sales Area Data (Sales Organization, Distribution Channel, Division), Material ID, and Plant can be submitted to the opportunity pricing SBO which, in turn, calls the standard SAP BAPI to simulate the creations of an SAP document. The pricing data can then be returned from SAP via the framework described herein and stored on the Salesforce CPQ Quote Line Item.)
However, Hochheiser does not disclose but Makhija discloses a data lake configured to monitor real-time data changes across a plurality of transactional systems including ERP systems and CRM systems, capture the real- time data changes using one or more Change Data Capture (CDC) mechanisms, process and standardize the captured data for storage in a data layer comprising a data mesh and a plurality of Purposive Datastores (PDSes), and retrieve current supply-chain data from the plurality of PDSes, the current supply-chain data comprising inventory data, product data, customer data, pricing data, or transaction data ([0013] The present invention provides several advantages over the prior art. For example, in one advantageous aspect, the present invention provides a self-driven ERP or SCM system and a method for operating the same with faster processing times, reduced error and accurate data flow across the platform. The system utilizes sub network of devices and server for secured communication with reduced processing time due to automatic creation of scripts by a bot based on the data models, the change in the at least one attribute, the impact data and AI based processing logic for recommending an action/task to a user… [0035] Referring to FIG. 1, a self-driven system 100 for operating one or more applications including supply chain management (SCM) and enterprise resource planning (ERP) applications is provided in accordance with an embodiment of the present invention. The system 100 includes at least one computing device/entity machine 101 for initiating at least one function to be performed on the one or more applications over a network. The system 100 further includes a server 106 configured to receive input from the entity machine 101. The system 100 includes a support architecture 107 for performing the functions on the one or more applications depending upon the type of input received at the server 106. The system 100 includes a data lake 108 for storing plurality of data from distinct sources, where the data includes, text data, voice data, image data, functional data, data models, scripts etc. to be processed based on Artificial intelligence and machine learning…[0042]… . The support architecture 107 includes a data manager 115 for managing data relating to any function of the Enterprise application EA or SCM application. In an example embodiment, the data may include supplier data with changed attributes like lead time during inventory or transportation function of a supply chain application…0046] In an embodiment, the data cleansing and normalization engine 116 is configured to clean data received at the data lake in real time using natural language processing and machine learning algorithms for enhanced accuracy. Since, the data will be received from multiple disconnected sources, the engine 116 has an ability to remove duplicates, standardize and group the data. The cleansing engine is coupled to a data mapper and curator engine. The engine 116 detects and corrects Corrupt or duplicate or vague data. Further, the cleansed data is sent for approval through a routing mechanism post which they are stored in master data tables of the data lake. Also, an audit of the received data and cleansed data is stored in the data lake... 0047] In an example embodiment, the data lake 108 includes plurality of databases as shown in FIG. 1. The data lake 108 includes a relational database 122a for storing related data sets received from distinct sources, a non-relational database 122b for storing non-related raw data sets, a functional database 124 for storing a library of functions enabling creation of a plurality of data models for execution of tasks in one or more applications including ERP and SCM, a plurality of registers 125 for temporarily storing data from various sources for determination of characteristic of the data like change in attribute of received data or receipt of a new attribute data itself…[0070] In an embodiment, the plurality of distinct data sources includes internet of things (IOT), demand from various sources at different levels like retailers, distribution channels, POS systems, customer feedback, supplier collaboration platform, invoices, purchase orders (PO), finance modules, inventory management module, contracts and RFx module, supplier module, item master, bill of materials, vendor master, warehouse management module, logistics management module, social media, weather, real time commodity and stock market prices, geo-political news etc. It shall be apparent to a person skilled in the art that the data source may include other source within the scope of the present invention.” While the claim broadly recites “one or more CDC mechanisms”; it does not require log-based, trigger-based or polling based CDC. The system supplies the operational change dection/capture function by verifying received data and determining changed or new attributes. The system teaches multiple purpose differentiated stores. Although Makhija does not use the term “PDS”, under BRI, files tores, cache stores, graph stores, relational stores, and non relational stores are PDS like because they are specialized for different storage/retrieval purposes);
a Single Pane of Glass User Interface (SPoG UI) configured to interact with the data lake through APIs ([0091] Referring to FIG. 1F is a block diagram 100F of a recommendation platform generating recommendation of a task/action to a user of the self-driven system is shown in accordance with an embodiment of the invention. The service provider structure 135 interacts through event stream 134 with data lake having graph store 123c and search store 123d. The data extracted from the data lake after NLP of the received data and using data frame SQL is provided to the subscriber through the user interface.”, “[0098] In an embodiment, the system includes pro-active detection algorithms for any record/transactions (items/Suppliers/PO/Invoices etc) being entered by a user (supplier/Customer/Employee etc) at the user interface. These will ensure that the Master tables are clean, accurate, complete and non-fraudulent/non-duplicate at any point in time and the data flowing through every single module or pipeline is clean and accurate. The master tables are stored in relational database 122a.”);
an Advanced Analytics and Machine Learning (AAML) Module configured to store and execute rule-based or machine-learning algorithms ([0055] In an exemplary embodiment, Query Language (QL) tool 130 provides a flexible and powerful way to get insights on transactional view across supply chain data model. The QL tool provides ability to apply desired machine learning algorithm on key attributes from the data platform. The recommendation is attached to desired workflow/UI element/rules/validations…. 0094] In exemplary embodiment, each of the plurality of machine learning (ML) models are built on real time data across all data points in the supply chain data lake, with multiple predictor attribute. This leads to models with higher degree of accuracy and confidence.)
SPoG UI interacting with API and data lake (0052] Referring to FIG. 1A a perspective view of a high-level architecture (100A) of a self-driven system for one or more applications including EA and SCM is shown in accordance with an embodiment of the invention. The high-level system architecture includes a user interface (UI), an application programming interface (API), functional objects, data access objects, an event handler, and the data lake 108. The UI interacts with the data lake through a master data API. The data lake 108 includes a file store 123a, a cache 123b, a graph store 123c in addition to the relation database 122a and non-relational database 122b as shown in FIG. 1A.);
Interactions between data lake and system components via Restful APIs ([0064] In an embodiment, the system architecture and applications are designed on API first strategy. All producers and consumers of the data in the system expose data using restful services (API). Central API gateway 134 ensures high reliability and fault tolerance. In case calling application is not reachable, it includes inbuilt retry policies to manage connectivity failures. Further, it provides additional layer of security.);
Retrieve, through the data lake, current CRM data using secure API calls or database queries ([0064] In an embodiment, the system architecture and applications are designed on API first strategy. All producers and consumers of the data in the system expose data using restful services (API). Central API gateway 134 ensures high reliability and fault tolerance. In case calling application is not reachable, it includes inbuilt retry policies to manage connectivity failures. Further, it provides additional layer of security.);
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitations above as taught by Makhija in the teaching of Hochheiser, in order to provides self-driven AI based system and method for operating one or more applications including enterprise application and supply chain management applications (please see Makhija abstract).
Hochheiser in view of Makhija does not disclose but Hwang discloses a CTO module configured to execute configure to order tasks including bill of materials generation ([0018] FIG. 1 is an illustration of a possible graph for BOM structure analysis. Specifically, FIG. 1 illustrates a graph 100 that represents a BOM using a tree representation. The graph 100 includes a plurality of nodes 102. The membership of the BOM can be represented as a finite set of materials (e.g., nodes) and a finite set of edges that connect the materials. For example, the BOM can be represented mathematically as shown in Equation (1):);
a Bill of Materials (BOM) Generator configured to generate a hierarchical bill of materials (BOM) using a recursive algorithm that traverses parent-child component relationships and to match the generated BOM against process status ([0018] FIG. 1 is an illustration of a possible graph for BOM structure analysis. Specifically, FIG. 1 illustrates a graph 100 that represents a BOM using a tree representation. The graph 100 includes a plurality of nodes 102. The membership of the BOM can be represented as a finite set of materials (e.g., nodes) and a finite set of edges that connect the materials. For example, the BOM can be represented mathematically as shown in Equation (1):..[0056]…The server system 706 then compares the minimal canonical form to a corresponding material node in the BOM structure. Accordingly, during setup of the directed acyclic graph, the server system 706 stores in the memory area 702 a link between each process node in the process network and a corresponding material node in the BOM structure that is a product of that process node. The BOM structure and/or the process network are valid if the status of the chosen process node matches the corresponding material node. If the two are do not match, then the BOM structure and/or the process network is invalid. The server system 706 stores a state of the BOM in the memory area 702.” Hwang discloses a BOM tree which is a hierarchical BOM. Material nodes and edge define parent child components relationships. Recursive parent and recursive child definitions teach recursive traversal trhough the hierarchy. Hwang discloses the BOM comparison/validation function, Hochheiser supplies the real time ERP/SAP material and plant availability data, which corresponds to inventory/availability data and Makhija discloses the RESTful API/data access infrastructure.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitations above as taught by Hwang in the teaching of Hochheiser in view of Makhija, in order to validate a bill of material (BOM) structure having a plurality of nodes (please see Hwang abstract).
However, Hochheiser in view of Makhija does not disclose but Pinheiro discloses a real time data mesh architecture ([0033] FIG. 5 is a data mesh diagram that illustrates data flows generated by a method for providing a data architecture and implementation strategy designed to support the development of data and analytics assets with speed and scale, according to an exemplary embodiment., [0036] FIG. 8 is a block diagram of a distributed data lake by which data assets are aligned to source domains or consumer domains, according to an exemplary embodiment.). Pinheiro also discloses a change data capture mechanism ([133]… The data assets are pulled by the consumer, rather than pushed to the consumer, and kept up-to-date based on standards such as Change Data Capture (CDC) or Append Logs. Data consumers must be able to easily navigate and access data solely for their consumption, and must not redistribute data that they consume, as it violates data management standards and product ownership protocols.); domain owned data assets hosted in a distributed domain oriented data lake ([0085] In an exemplary embodiment, a data architecture is based on an inversion of a centralized and monolithic data architecture in order to realize a more distributed data architecture of domain-aligned data assets and pipelines. The data architecture intentionally decentralizes the data assets into the various domains, putting the domain data experts in charge. Instead of flowing the data from domains into a monolithic and centrally owned data lake, the various domains need to host and serve their domain data assets in a fast and easily consumable way on a distributed data lake. The architecture treats domain ownership and governance of data that the domain produces and consumes as a primary concern, while relegating data infrastructure (i.e., data platform and services) as a secondary concern.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitations above as taught by Pinheiro in the teaching of Hochheiser in view of Makhija, in order to provide a data architecture and implementation strategy designed to support the development of data and analytics assets with speed and scale (paragraph 2, Pinheiro).
Novelty and Non-Obviousness
No prior art was applied to claims 2-7 and 16-20 because a combination of the prior art applied above with the prior art of record would have results in a piece meal rejection using impermissible hindsight.
The closest prior art for claims 2-7 and 16-20 is the prior art of record.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OMAR ZEROUAL whose telephone number is (571)272-7255. The examiner can normally be reached Flex schedule.
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, Kevin Flynn can be reached at 5712703108. 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.
OMAR . ZEROUAL
Examiner
Art Unit 3628
/OMAR ZEROUAL/Primary Examiner, Art Unit 3629
Prosecution Insights