Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Status of Claims
Claims 1-19 and 21 are pending.
Response to Arguments
Applicants’ arguments regarding the 101 rejection(s) have been considered but are not persuasive.
Applicant argues:
The claims do not recite a judicial exception and instead recite error source identification in a distributed computing environment.
That the environment happens to involve payment process configurations does not convert a technical error-correction method into a commercial interaction any more than a method of detecting buffer overflows in banking software would be a financial transaction. The claimed process is a technical operation, not a commercial interaction or fundamental economic practice. See Enfish for reference.
Examiner Response – The specification at 0002 states that the embodiments of the disclosure relate generally to payment systems and more particularly, to the use of payment process configurations for payment processing orchestration.
Second, the claims do not recite a mental process. The assertion that error source identification and modification are directed to errors in program instructions that a human could identify manually ignores the technical specificity of the claims as amended. No human analyst using pen and paper could remotely access locally stored operation data across distributed devices, compare modified payment process configurations against stored configurations, identify the error source, and correct the identified error in the manner claimed.
Examiner Response – The claims do not disclose remotely accessing payment process configurations and the modified payment process configurations are claimed as “not locally stored”, which may be an architectural constraint but not an affirmative technical step. Nothing in the claims or specification prohibits the active steps of receiving, accessing, identifying, comparing and correcting from being performed manually or mentally.
At the very least, “identifying…an error source” and “correcting…an error in the error source” must be treated as additional elements because these steps require interaction with physical equipment.
Office Response – The applicant’s argument des not explain why or how the steps require interaction with physical equipment.
In response the Office asserts that even if the claims were directed to error source identification and correction they would still recite an abstract idea since the error source identification and subsequent modification are directed to errors in program instructions, i.e., data. In such a case the claims would be directed to a mental process that can be performed by a human using pen and paper. As a first matter the payment process configurations may include configurable instructions, workflows, operations, etc. (0008, 0029, 0058, 0060). Secondly, The orchestration device may rely upon any number of error analysis techniques, comparisons, thresholds, or the like (0074). Because of the lack of specificity in the instructions and error analysis the Office interprets the instructions
The orchestrator and participant devices are not generic but define specific architectural roles.
Office Response – The applicant cites specific architectural “roles”, confirming the fact that the components are described by what they do and not what they are. Applicant’s arguments identify the particular actions that the components undertake but do not claim any particular structure.
The limitation that the orchestrator device does not locally store payment process configurations modified for participant devices” is not insignificant extrasolution activity but is a structural constraint on the system architecture central to the error identification method.
Office Response – The Office agrees that this is not insignificant extrasolution activity however, the local storage of PPCs and remote storage of modified PPCs are a field-of-use limitation for the for the comparison and modification steps. The comparison and modification are the substance of the claim; the storage arrangement merely constrains where they occur.
Participant devices independently modify and locally store their own configurations, and the orchestrator does not have those modified configurations. This is what necessitates the claimed solution: the orchestrator must affirmatively "access[] ... first operation data stored locally by the first participant device" and "access[] ... second operation data stored locally by the second participant device," then compare that data to identify the error source. Without this architectural constraint, the claimed method would be unnecessary.
Office Response – This is a circular argument. The applicant argues that because the data is distributed among devices it must be locally and remotely accessed. The necessity is self-generated: 1) the method is necessary because the architecture requires distributed access, 2) the architecture requires distributed access because the data is stored in distributed locations, 3) the data is stored in distributed locations because the claim says so.
The claims set forth a practical application because they provide a specific technical solution to a specific technical problem. The Specification describes a concrete technical problem: in distributed payment processing environments, participant devices independently modify their configurations, and when an error occurs during the payment process, there is no mechanism for centrally identifying which participant's modified configuration is the source of the error. See Specification paragraphs [0006], [0069]-[0074]. The claims provide a specific technical solution: an orchestrator device that, upon receiving an error notification, remotely accesses operation data stored locally on each participant device, compares that data to a stored configuration to identify the error source, and corrects the error. This is not merely a "stated outcome"; it is a concrete, claimed mechanism for error identification and correction in a distributed computing architecture. See DDR Holdings, LLC v. Hotels.com, L.P.,15 of 18 773 F.3d 1245, 1257 (Fed. Cir. 2014) in which claims directed to a solution "necessarily rooted in computer technology" to overcome a problem specifically arising in the realm of computer networks are patent eligible.
Office Response – applicants argument is again circular. Applicant argues the claims are necessarily rooted in computer technology but only because they have been framed as occurring within a distributed computer system. The Office sees the claims as resolving payment processing inconsistencies but as stated previously, there is nothing in the claims or the specification which confine the solution to computer implementation other than the framing of the claims within this field of use. Most importantly, the identifying, comparing and correcting steps are not detailed. Nothing in the claims or specification identifies what steps are performed when identifying, comparing and correcting.
The insignificant extrasolution activity is not “well-understood, routine and conventional”
The insignificant extra-solution activity issue was previously addressed.
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.
Claim(s) 1-19 and 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s):
A computer-implemented method for error source identification, the computer-implemented method comprising:
receiving, by an orchestrator device, an error notification associated with a payment process that includes operations by a first participant device and a second participant device, wherein the orchestrator device stores a plurality of payment process configurations locally but does not locally store payment process configurations modified for participant devices:
accessing, by the orchestrator device, first operation data stored locally by the first participant device, wherein the first operation data comprises a first payment process configuration modified for the first participant device;
accessing, by the orchestrator device, second operation data stored locally by
the second participant device, wherein the second operation data comprises a second payment process configuration modified for the second participant device;
identifying, based on the error notification and by the orchestrator device comparing the first operation data and the second operation data to a stored payment process configuration, an error source in either the first payment process configuration modified for the first participant device or the second payment process configuration modified for the second participant device; and
correcting, by the orchestrator device, an error in the error source wherein correcting the error in the error source comprises modifying at least one of the first payment process configuration or the second payment process configuration.
The underlined elements represent certain methods of organizing human activity, commercial interactions because the claims are directed toward facilitating payments.
This judicial exception is not integrated into a practical application because the abstract idea is implemented using computers including an orchestration device and participant devices which are generically recited, adding the words “apply it”, or the like, to the abstract idea. The claims also include a limitation defining the storage locations however, this is mere field-of-use, confining the claim to a distributed architecture, a particular environment.
The claims do not recite an inventive concept for the reasons given under Prong Two, step 2A.
Claims 8 and 15 are similarly rejected. Claim 8 is directed to an apparatus comprising a processor and a memory with computer-readable instructions. Claim 15 is directed an apparatus comprising means. Each claim comprises generically recited elements amounting to adding the words “apply it” as cited above.
The dependent claims merely narrow the abstract idea and as a whole and, in combination, merely comprise the abstract idea with the words “apply it”.
Claim 2 further confirms the distributed architecture field-of-use.
Claims 3, 4, 6 and 7 narrow the payment process configuration modification process.
Claim 5 merely narrows the PPC identification process.
The remaining dependent claims are similar and are similarly rejected.
Conclusion
THIS ACTION IS MADE FINAL. 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 WILLIAM E RANKINS whose telephone number is (571)270-3465. The examiner can normally be reached on 9-530 M-F.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett Sigmond can be reached on 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WILLIAM E RANKINS/Primary Examiner, Art Unit 3694
