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 Claims
This action is in response to remarks received 12/18/2025.
Claims 15-20 are withdrawn from consideration pursuant to the restriction requirement and are not examined on the merits in this Office action.
This application claims earlies priority from Provisional Application 62712475, filed 07/31/2018.
Claims 1 & 8 are independent and claims 2-7 & 9-14 are dependent.
Claims 1-14 are currently pending and have been examined.
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.
Under Step 2A – Prong One: The Claims Are Directed to an Abstract Idea.
Claim 1 recites a series of steps for processing and managing payment information associated with a bill statement and a calendar entry, including transmitting to a user device an electronic message for display in a statement notification interface having a graphical element; upon activation, adding an electronic calendar entry that includes a token including payment data; receiving a payment request including the token transmitted upon activation of a second graphical element; decrypting the token to retrieve the payment data, transmitting a payment confirmation request using the payment data, receiving an approval notification and a payment confirmation, and updating a payment record based on the confirmation and payment data.
These steps collectively reflect a conventional payment workflow implement using generic computing technology. These limitations, when considered as a whole, describe organizing and executing a payment transaction and communicating payment information/confirmation between parties, which amounts to a fundamental economic practices of facilitating payment of a bill and associated information exchange or commercial interactions (i.e., initiating and completing payment of a bill using transmitted payment information and confirmations) that can be, and historically have been, performed by humans with pen and paper or basic computing tools; and therefore constitutes an abstract idea.
Courts have consistently held that concepts such as processing payments, authorizing transactions, confirming payments, and updating financial records constitute abstract ideas. See, e.g., Alice, 573 U.S. at 219–221; Bilski v. Kappos, 561 U.S. 593 (2010); Credit Acceptance Corp. v. Westlake Servs., 859 F.3d 1044 (Fed. Cir. 2017).
Accordingly, the claims recite an abstract idea.
Step 2A – Prong Two: The Claims Are Not Integrated into a Practical Application.
The claims do not integrate the abstract idea into a practical application.
Although the claims recite various computing elements—such as a payment server, user device, non-transitory computer-readable storage medium, electronic calendar, graphical elements, tokens, and encryption/decryption—these elements are recited at a high-level of generality and are used only as tools to implement the abstract idea.
The claims do not recite:
an improvement to the functioning of a computer or server;
an improvement to encryption technology or tokenization techniques;
a specific technical solution to a problem rooted in computer technology; or
a particular data structure or protocol that improves security or efficiency.
Instead, the claimed components merely receive, transmit, display, decrypt, store, and update information, which are generic computer functions. The electronic calendar entry, graphical elements, and token merely represent organizational and notification mechanisms for facilitating payment transactions and do not impose any meaningful limitation that confines the abstract idea to a particular technological implementation.
Thus, the claims merely apply the abstract idea using generic computing components, rather than integrating the abstract idea into a practical application.
Step 2B: The Claims Do Not Recite an Inventive Concept.
The claims do not include additional elements that amount to significantly more than the abstract idea.
Identified abstract idea (from Step 2A above): facilitating payment of a bill and related information exchange/confirmation between parties (e.g., initiating a payment request, authoring/approving payment, confirmation payment, and updating payment records.)
The additional elements (i.e., claim limitations considered “beyond” the abstract idea) recited—such as token use and decryption, transmitting confirmation requests, receiving approval notifications, updating payment records, and displaying confirmation interfaces; are well-understood, routine, and conventional activities in the field of electronic payment processing. When the claim is evaluated as a whole, the following limitations are treated as the additional elements used to implement the abstract idea in a computing environment:
transmitting to a user device an electronic message for display in a statement notification interface having a graphical element, (a user-interface display/notification function);
upon activation, adding an electronic calendar entry …, (a scheduling and information-organization function);
a token including payment data & receiving a payment request including the token …, (use of a token as a data container/identifier);
decrypting the token to retrieve the payment data, (encryption/decryption invoked at a functional result level);
transmitting a payment confirmation request … receiving an approval notification and a payment confirmation, and updating a payment record …, (computer-implemented messaging and record-update operations).
In accordance with Step 2B of the 2019 PEG, the additional elements are identified separately from the abstract elements and evaluated to determine whether they amount to significantly more than the abstract idea. Evaluation of whether the additional elements amount to “significantly more”: these additional elements, individually and in combination, do not amount to significantly more than the identified abstract idea because they reflect generic computer implementation of the payment workflow:
The UI notification/graphical element and calendar entry creation are conventional user-interface and scheduling functions that merely present/organize information and prompt a user to take an action; they do not impose a meaningful technological constraint or improve computer functionality.
The token and decryption are recited only at a high level (e.g., token including payment data, decrypting the token), without any particular token format, cryptographic technique, key management, protocol, or other nonconventional security mechanism that would represent a technical improvement.
The remaining steps (receiving a request, sending confirmation, receiving approval/confirmation, updating records) are routine electronic transaction processing and data updating operations.
Accordingly, since the encryption and tokenization are invoked only at a functional level, without specifying any unconventional technique or improvement; likewise, displaying confirmation requests and updating records are routine data processing and user-interface operations; the claim merely uses generic computing components to receive, transmit, display, decrypt, store, and update information to carry out the abstract idea, rather than reciting an inventive concept that transforms the abstract idea into patent-eligible subject matter.
Considering the additional elements as an ordered combination does not change the analysis. The claimed sequence (displaying a notification, creating a calendar entry, passing a token, decrypting to obtain payment data, requesting approval/confirmation, and updating a record) reflects a conventional computerized payment authorization/confirmation workflow and represents organizing human/commercial activity with generic computer functions. Therefore, the claim does not include additional elements that amount to significantly more than the abstract idea nor transform the abstract idea into patent-eligible subject matter.
The claims do not recite additional elements that amount to significantly more than the abstract idea under Step 2B of the Alice/Mayo framework and therefore are not directed to patent-eligible subject matter under 35 U.S.C. § 101.
The dependent claims are separately considered. Each dependent claim adds further limitations (additional elements) beyond the abstract idea; however, those additional elements likewise amount to conventional computer implementation and/or insignificant extra-solution activity (e.g., additional notifications, additional message content, additional record fields, routine security/formatting options, or routine UI variations).
For example, claims 2 and 9 (mobile device UI and approval notification handling) add limitations directed to triggering display of a payment confirmation request on a mobile device, receiving an approval notification, and transmitting the approval notification. These limitations relate to routine user-interface operations and electronic messaging and do not recite any technological improvement or unconventional technique.
Claims 3 and 10 (extracting/storing payment data and token generation) add limitations directed to extracting and storing payment data from a bill statement file and generating a token including the payment data. These limitations reflect routine data processing and token creation steps and do not specify any nonconventional data structure, token format, or technical improvement.
Claims 4 and 11 (associated token with customer identifier) add limitations directed to storing the token in association with a customer identifier linked to a customer record. These limitations reflect conventional database association and record-linking techniques.
Claims 5 and 12 (enhanced bill statement file generation) add limitations directed to generating an enhanced bill statement file form an electronic bill statement file. These limitations reflect routine file generation and formatting operations and do not impose a meaningful technological constraint.
Claims 6 and 13 (registration request and electronic address storage) add limitations directed to processing a registration request to store an electronic address in a customer record to permit processing of a payment request. These limitations reflect conventional account setup and record management functions.
Claims 7 and 14 (expanded payment request fields) add limitations directed to including a payment amount, payment due date, vendor identifier, and vendor account identifier in the payment request. These limitations merely specify additional informational content and do not recite any technical improvement.
Accordingly, each dependent claim adds only conventional computer implementation details and/or insignificant extra-solution activity beyond the abstract idea. Therefore, the dependent claims likewise do not recite an inventive concept for substantially the same reasons discussed above.
Conclusion – §101
Because the claims are directed to an abstract idea and do not recite additional elements sufficient to amount to significantly more than the abstract idea itself, claims 1–14 are rejected under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-14 are rejected under 35 U.S.C. 102 (a)(1) & (a)(2) as being anticipated by Donald H. Graham, III et al. (US 2011/0270763 A1, herein Graham).
As per claim 1, Graham teaches a system for payment processing comprising:
a payment server having a non-transitory computer-readable storage medium with computer- executable instructions for causing a processor of the payment server to:
transmit to a user device an electronic message configured to display a statement notification interface having a graphical element, the graphical element having logic code to automatically add an electronic calendar entry comprising a token including payment data to an electronic calendar of the user device if the graphical element is activated at the user device, wherein the payment data comprise a customer identifier, a payment amount, and a payment due date, wherein the token is encrypted, the payment server being configured to decrypt the token to access the payment data, wherein an electronic application on the user device provides the electronic calendar storing the electronic calendar entry (Graham ¶¶ [155, 192, 194-195, 259-260, 272, 292, 294, 299, 389 & 445]:
upon detecting activation of the graphical element at the user device, add the electronic calendar entry to the electronic calendar using the logic code, the electronic calendar entry configured to display a second graphical element for activating a payment request at the user device, wherein activating the payment request opens the electronic application on the user device to initiate a payment using the payment data of the token (Graham ¶¶ [155, 259-260 & 445].
receive the payment request including the token transmitted by the user device upon activation of the second graphical element (Graham ¶¶ [331 & 333]);
decrypt the token to retrieve the payment data using the token (Graham ¶¶ [174, 194, 344 & 445]);
transmit a payment confirmation request to an electronic address stored in a customer record linked to the payment data, the payment confirmation request populated with the payment data (Graham ¶¶ [215, 275, 277, 279-282, 290, 299, 314, 360 & 345]);
receive an approval notification in response to the payment confirmation request, the approval notification approving a payment transaction (Graham ¶¶ [299, 313-314, 361, 377, 416-417, 423, 427 & 430]);
receive a payment confirmation indicating successful processing of the approved payment transaction (Graham ¶¶ [151, 182, 275, 279-280, 299, 314 & 445]); and
update a payment record with the payment confirmation and the payment data (Graham ¶¶ [250, 292 & 433]).
As per claim 8, the claim recites analogous limitations as claim 1 above and interpreted under the same premise.
As per claim 2, Graham teaches the system of claim 1, Graham further teaches
wherein the user device comprises a mobile device, the electronic application having a non-transitory computer-readable storage medium with computer-executable instructions for causing a processor of the mobile device to:
trigger display of the payment confirmation request on the mobile device (Graham ¶¶ [51, 182, 275, 279-280, 299, 314 & 445]);
receive the approval notification in response to the display of the payment confirmation request at the mobile device (Graham ¶¶ [299, 313-314, 361, 377, 416-417, 423, 427 & 430]); and
transmit the approval notification to the payment server (Graham ¶¶ [199, 215, 279, 299, 310 & 314]).
As per claim 9, the claim recites analogous limitations as claim 2 above and interpreted under the same premise.
As per claim 3, Graham teaches the system of claim 1, Graham further teaches
wherein the payment server is further configured to:
extract and store the payment data from a bill statement file (Graham ¶¶ [198, 363 & 445]); and
generate the token including the payment data (Graham ¶¶ [259, 272 & 299-300]).
As per claim 10, the claim recites analogous limitations as claim 3 above and interpreted under the same premise.
As per claim 4, Graham teaches the system of claim 3, Graham further teaches
wherein the payment server is further configured to store the token in association with the customer identifier, the customer identifier linked to the customer record (Graham ¶¶ [259, 292, 295-296, 299-300, 313-314, 327-330 & 335-340]).
As per claim 11, the claim recites analogous limitations as claim 4 above and interpreted under the same premise.
As per claim 5, Graham teaches the system of claim 3, Graham further teaches
wherein the bill statement file comprises an enhanced bill statement file, wherein the payment server is configured to generate the enhanced bill statement file from an electronic bill statement file (Graham ¶¶ [194-195, 205, 259-260, 281-282, 344 & 445]).
As per claim 12, the claim recites analogous limitations as claim 5 above and interpreted under the same premise.
As per claim 6, Graham teaches the system of claim 1, Graham further teaches
wherein the payment server is configured to process a registration request to store the electronic address in the customer record to permit processing of the payment request (Graham ¶¶ [206, 310 & 358]).
As per claim 13, the claim recites analogous limitations as claim 6 above and interpreted under the same premise.
As per claim 7, Graham teaches the system of claim 1, Graham further teaches
wherein the payment request indicates a payment amount, a payment due date, a vendor identifier, and a vendor account identifier (Graham ¶¶ [155-156, 276, 366 & 445 194-195, 259-260, 294 & 299]).
As per claim 14, the claim recites analogous limitations as claim 7 above and interpreted under the same premise.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TONY P KANAAN whose telephone number is (571)272-2481. The examiner can normally be reached Monday- Friday 7:30am - 3:30 pm EST.
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, Matthew Gart can be reached at 5712723955. 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.
/T.P.K./Examiner, Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696