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 .
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 non-statutory subject matter, specifically an abstract idea without a practical application or significantly more than the abstract idea.
Under the 35 U.S.C. §101 subject matter eligibility two-part analysis, Step 1 addresses whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. See MPEP §2106.03. If the claim does fall within one of the statutory categories, it must then be determined in Step 2A [prong 1] whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea). See MPEP §2106.04. If the claim is directed toward a judicial exception, it must then be determined in Step 2A [prong 2] whether the judicial exception is integrated into a practical application. See MPEP §2106.04(d). Finally, if the judicial exception is not integrated into a practical application, it must additionally be determined in Step 2B whether the claim recites "significantly more" than the abstract idea. See MPEP §2106.05.
Examiner note: The Office's 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) is currently found in the Ninth Edition, Revision 10.2019 (revised June 2020) of the Manual of Patent Examination Procedure (MPEP), specifically incorporated in MPEP §2106.03 through MPEP §2106.07(c).
Regarding Step 1
Claims 1-9 are directed toward method (process) and claims 10-20 are directed towards system (apparatus). Thus, all claims fall within one of the four statutory categories as required by Step 1.
Step 2A – Prong One (Judicial Exception)
Claims 1–20 are directed to abstract ideas, specifically:
Managing commercial transactions (sales orders, invoices, confirmations);
Collecting, validating, converting, and processing data;
Detecting errors and routing them to appropriate teams;
Presenting information via dashboards and GUIs.
These concepts fall within fundamental economic practices, organizing human activity, and mental processes, as identified in Alice Corp. v. CLS Bank Int’l, 573 U.S. 208 (2014), and MPEP § 2106.04(a).
Step 2A – Prong Two (No Practical Application)
These claims merely apply the abstract idea using generic computer components, including: ERP systems (SAP), Middleware, Databases, Bots, GUIs, APIs and messaging protocols (REST, SOAP, IDOC, XML, JSON, PDF).
These claims do not recite a specific technical improvement to computer functionality, middleware architecture, data conversion algorithms, or ERP processing. Instead, they use computers as tools to automate a longstanding business workflow.
Step 2B – No Inventive Concept
The additional elements, individually and in combination, represent well-understood, routine, and conventional activities, including:
Data validation using rules, Error detection and notification, Automated posting to ERP systems, Dashboard-based monitoring, Integration using standard enterprise formats (IDOC, BAPI, XML).
No claim element amounts to “significantly more” than the abstract idea.
Dependent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because these elements are considered well-understood, routine, and conventional activity, see MPEP §2106.05(d).
Thus, after considering all claim elements, both individually and in combination and in ordered combination, it has been determined that the claims are not enough to transform the abstract idea into a patent-eligible invention since the claim limitations do not amount to a practical application or significantly more than an abstract idea. Accordingly, claims 1-20 are directed to non-statutory subject matter under 35 U.S.C. § 101.
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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over BLEACHER et al. (US 2018/0196843, hereinafter Bleacher) in view of PILLAI et al. (US 9843625, hereinafter Pillai).
With respect to claims 1 and 10, BLEACHER discloses user-facing interfaces for monitoring ERP data, reviewing detected errors, and managing correction workflows (¶¶ [0063]–[0066], dashboards and user interaction modules).
performing steps of creating, modifying, and processing e-orders and e-invoices
(¶¶ [0034]–[0038], [0085]–[0090]).
generating input data including sales order headers and items (¶¶ [0036]–[0038], [0101]–[0104]).
validating the input data based on validation rules (applying validation rules to ERP transaction data to detect incorrect, inconsistent, or incomplete information ¶¶ [0061]–[0064], [0087]–[0089]).
determining one or more errors (automatically identifying erroneous data fields during validation ¶¶ [0065]–[0068], [0090]–[0092]).
automatically executing a bot to resolve one or more errors (automatic correction logic that resolves detected ERP data errors without human intervention, which constitutes execution of automated agents performing corrective actions ¶¶ [0091]–[0094], [0105]–[0108]).
creating and storing sales orders and invoices (updating and storing corrected ERP transaction records following error resolution ¶¶ [0038]–[0040], [0106]–[0108]).
displaying sales order data as troubleshooting, monitoring, and analytical dashboards
(dashboards and reporting interfaces for monitoring ERP data quality, error states, and correction outcomes ¶¶ [0063]–[0066], [0101]–[0103]).
BLEACHER does not explicitly disclose the feature of receiving unprocessed sales data from an external legacy system and converting unprocessed data into processed data attributable to a target SAP standard and sending transactional documents directly or via middleware.
However, PILLAI discloses the feature of:
receiving unprocessed sales data from an external legacy system (extracting enterprise data from external and legacy systems into a middleware platform prior to ERP processing col. 4, lines 12–28; col. 6, lines 5–18); and
converting unprocessed data into processed data attributable to a target SAP standard
(transforming extracted enterprise data into standardized formats compatible with downstream ERP systems col. 6, lines 19–35; col. 7, lines 10–25), and
sending transactional documents directly or via middleware (transmitting transformed enterprise data via middleware to downstream systems using network-based communication protocols col. 7, lines 30–55; col. 9, lines 5–20).
It would have been obvious to one of ordinary skill in the art to combine BLEACHER’s ERP error detection and automated correction techniques with PILLAI’s middleware-based data transformation and transmission system to achieve predictable results, namely automated, reliable end-to-end sales order and invoice processing in an ERP environment. Such combination merely applies known techniques to a known enterprise problem and yields no unexpected results.
With respect to claim 2 BLEACHER further discloses the feature of Validation rules applied at document category, sales organization, product, currency, and customer levels (rule-based ERP validation framework ¶¶ [0061]–[0064]).
With respect to claim 3 PILLAI further discloses the feature of Aggregation of multiple ERP outputs at a single interface is taught by PILLAI’s middleware aggregation layer (col. 6, lines 28–35; col. 9, lines 25–35).
With respect to claim 4 BLEACHER further discloses the feature of Automatic rejection and posting of items during validation (automated correction and record update processes ¶¶ [0091]–[0094]).
With respect to claim 5 BLEACHER further discloses the feature of Automatic notification and routing of errors to appropriate teams (alerting and reporting mechanisms ¶¶ [0066]–[0068]).
With respect to claim 6 PILLAI further discloses the feature of support for multiple document formats (handling heterogeneous enterprise data formats col. 4, lines 20–35; col. 7, lines 10–25).
With respect to claim 7 BLEACHER further discloses the feature of creating transactions individually or in groups is an obvious design choice (batch and individual ERP processing (¶¶ [0035]–[0038]).
With respect to claim 8 PILLAI further discloses the feature of transmission via REST, SOAP, FTP, and email is taught by PILLAI’s network communication and API interfaces (col. 7, lines 30–55).
With respect to claim 9 BLEACHER further discloses the feature of dashboards including validation data and error reports (¶¶ [0063]–[0066]).
With respect to claim 11 BLEACHER further discloses the feature of further comprising an aggregation module to perform aggregation at a single interface of a plurality of cockpit outputs (¶¶ [0061]–[0064], [0087]–[0089]).
With respect to claim 12 BLEACHER further discloses the feature of automatically updating, posting, and committing corrected ERP records after validation and correction based on predefined rules (¶¶ [0036]–[0039], [0091]–[0094], [0105]–[0108]).
With respect to claim 13 PILLAI further discloses the feature of aggregating outputs from multiple enterprise systems into a single middleware interface for presentation and downstream use (col. 6, lines 28–35; col. 9, lines 25–35).
With respect to claim 14 BLEACHER further discloses the feature of automatic detection and automatic correction or rejection of erroneous ERP data during validation, followed by updating/posting corrected records to the ERP system (¶¶ [0090]–[0094], [0105]–[0108]).
With respect to claim 15 BLEACHER further discloses the feature of generating error reports, alerts, and notifications identifying detected errors and communicating such information to relevant users or systems for resolution and oversight (¶¶ [0065]–[0068]).
With respect to claim 16 PILLAI further discloses the feature of handling heterogeneous enterprise data formats and managing failures in processing or transforming such data within middleware systems (col. 4, lines 20–35; col. 7, lines 10–25).
With respect to claim 17 BLEACHER further discloses the feature of processing ERP records individually and in batch form for correction and posting (¶¶ [0035]–[0038]).
With respect to claim 18 PILLAI further discloses the feature of transmitting enterprise data via network protocols and APIs, including web services and file transfer mechanisms, in multiple data formats (col. 7, lines 30–55; col. 9, lines 5–20).
With respect to claim 19 BLEACHER further discloses the feature of maintaining ERP records in various states (e.g., corrected, pending, error) and storing validation results and error information for reporting and analysis (¶¶ [0063]–[0066], [0101]–[0104]).
With respect to claim 20 PILLAI further discloses the feature of exporting and providing enterprise data to external systems and applications for further processing and analysis (col. 6, lines 15–25; col. 9, lines 30–40).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROKIB MASUD whose telephone number is (571)270-5390. The examiner can normally be reached Mon-Fri 8:00-5:00.
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, Fahd Obeid can be reached at 571-270-3324. 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.
/ROKIB MASUD/Primary Examiner, Art Unit 3627