DETAILED ACTION
This rejection is in response to Amendment filed 11/07/2025.
Claims 2-21 are currently pending and have been examined.
Claim 1 is cancelled.
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 .
Priority
This application is a continuation of and claims priority to U.S. Patent Application No. 17/159,032, filed January 26, 2021, which is a continuation of and claims priority to U.S. Patent Application No. 15/872,926 filed January 16, 2018, which is a continuation of and claims priority to U.S. Patent Application No. 14/192,818, filed February 27, 2014, which claims priority to U.S. Provisional Patent Application No. 61/823,565, filed May 15, 2013.
Response to Arguments
Applicant's arguments filed 11/07/2025 have been fully considered but they are not persuasive.
With respect to Applicant’s arguments on page 8 of remarks filed 11/07/2025 that the provisional obviousness type double patenting rejection cannot be maintained over the claims as amended, Examiner respectfully disagrees.
The amended claims 2-21 are still anticipated by reference claims 1-20 of U.S. Patent No. 11,922,485 B2 because the claim amendments in the instant claims are recited in the patent.
With respect to Applicant’s arguments on page 8-11 of remarks filed 11/07/2025 that the claims are integrated into a practical application because the claims provide faster checkout and Example 42 (e.g. sharing information in a standardized format) is analogous to the claimed invention that is about processing transactions, Examiner respectfully disagrees.
If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology. An indication that the claimed invention provides an improvement can include a discussion in the specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim, or identifies technical improvements realized by the claim over the prior art. See MPEP § 2106.05(a).
To show that the involvement of a computer assists in improving the technology, the claims must recite the details regarding how a computer aids the method, the extent to which the computer aids the method, or the significance of a computer to the performance of the method. Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology. See MPEP § 2106.05(f) and 2106.05(a)(II).
It is unclear to one of ordinary skill in the art how processing a transaction based on the checkout request and funding source improves technology. Faster checkout solves a commercial problem rather than a problem rooted in technology. The claims are not directed to a practical application because the do not provide an improvement to technology and merely use the computer as a tool to process the transaction based on the checkout request and funding source.
The instant claims about processing transactions are not analogous to Example 42 which involves conversion of data in a non-standard form to a standardized format and provides an improvement to users being able to share any information that is inputted into a standardized format.
With respect to Applicant’s arguments on page 11-12 of remarks filed 11/07/2025 that Bell fails teach all of the claim amendments, Examiner respectfully disagrees.
Non-Statutory Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 2-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,922,485 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims 2-21 are anticipated by reference claims 1-20 of U.S. Patent No. 11,922,485 B2. This is a non-statutory, obviousness-type Double Patenting rejection with an anticipation analysis. See MPEP 804(II)(B)(1).
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 2-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more.
Under Step 1 of the Subject Matter Eligibility Test, it must be considered whether the claims are directed to one of the four statutory classes of invention. See MPEP § 2106. In the instant case, claims 2-8 are directed to a system, claims 9-15 is directed to a method, and claims 16-21 are directed to a non-transitory machine-readable medium ( which falls within one of the four statutory categories of invention (process/apparatus). Accordingly, the claims will be further analyzed under revised step 2:
Under step 2A (prong 1) of the Subject Matter Eligibility Test, it must be considered whether the claims recite a judicial exception if so, then determine in Prong Two if the recited judicial exception is integrated into a practical application of that exception. If the claim recites a judicial exception (i.e., an abstract idea), the claim requires further analysis in Prong Two. One of the enumerated groupings of abstract ideas is defined as certain methods of organizing human activity that includes fundamental economic principles or practices (including hedging, insurance, mitigating risk); 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). See MPEP § 2106.04(a)(2).
Regarding representative independent claim 2, recites the abstract idea of:
receive, …, a request to perform a streamlined checkout in association with a transaction…;
access a data file …;
determine that the device is eligible for the streamlined checkout based on the data file indicating that the device is a private device:
extract, from the data file, information related to a first funding source and a second funding source associated with an account with a payment service provider, the information being at least partially masked and captured during a previous session between the payment service provider…;
receive,… , a selection of a particular funding source from the first funding source and the second funding source;
retrieve, from a database…, payment data associated with the particular funding source based on the information and the selection, wherein the payment data comprises unmasked data associated with the particular funding source;
process the transaction based in part on the payment data associated with the particular funding source;
The above-recited limitations amount to certain methods of organizing human activity as it relates to sales activities and commercial interactions because the claim involves receiving a checkout request, accessing funding sources for payments, selecting a funding source, retrieving payment data associated with the funding source, and processing the transaction. Accordingly, the claim recites an abstract idea. See MPEP § 2106.
The Step 2A (prong 2) of the Subject Matter Eligibility Test, is the next step in the eligibility analyses and looks at whether the abstract idea is integrated into a practical application. This requires an additional element or combination of additional elements in the claims to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. See MPEP § 2106.
In this instance, the claims recite the additional elements such as:
A system comprising: a non-transitory memory; and one or more hardware processors in communication with the non-transitory memory and configured to execute instructions from the non-transitory memory to cause the system to: … via an interface associated with a merchant application presented on a device … between a user of the device and a merchant associated with the merchant application…;…stored on the device…;… and the device; without requiring the user to login to the account with the payment service provider, present a user interface associated with the payment service provider on the device, wherein the user interface is separate from the merchant application and includes the information related to the first funding source and the second funding source;… via the user interface…; …external to the device,…; and redirect the device from the user interface back to the interface of the merchant application (Claim 2);
….exclude the third funding source from the user interface (Claim 3);
the merchant application is associated with a merchant website (Claim 4);
…, via a second user interface associated with the payment service provider,…; and store the data file on the device (Claim 5);
the system to log the user out of the account with the payment service provider after storing the data file (Claim 6);
to a merchant server associated with the merchant (Claim 8);
…, by a computer system associated with a payment service provider, …via an interface associated with an application of the entity and presented on a device of the user;…stored on the device …and the device; …the device …; without requiring the user to login to the account with the payment service provider, providing a user interface associated with the payment service provider on the device, wherein the user interface is separate from the application and includes the information related to the first funding source and the second funding source; …via the user interface, …, from a database external to the device (Claim 9);
redirecting the user of the device from the user interface back to the interface of the application (Claims 10 & 17);
after the user of the device is redirected back to the interface of the application (Claim 11);
from the user interface (Claims 12 & 21);
the user interface is presented in a pop-up window (Claim 14);
storing the data file on the device (Claim 15 & 18);
A non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine associated with a payment service provider to perform operations comprising: …, via an interface associated with an online application presented on a device,…a user of the device and an entity associated with the online application;…stored on the device …the device …stored on the device, …and the device; independent of the user logging in to the account with the payment service provider, providing a user interface associated with the payment service provider on the device, wherein the user interface is separate from the online application and includes the information related to the first funding source and the second funding source; …via the user interface, …, from a database external to the device (Claim 16);
to a server associated with the entity (Claim 20).
However, these elements do not amount to an improvement in the functioning of a computer or any other technology or technical field, apply the judicial exception with, or by use of, a particular machine, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception.
Independent claims and dependent claims also fail to recite elements which amount to an improvement in the functioning of a computer or any other technology or technical field, apply the judicial exception with, or by use of, a particular machine, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. For example, independent claims and dependent claims are directed to the abstract idea itself and do not amount to an integration according to any one of the considerations above.
Step 2B is the next step in the eligibility analyses and evaluates whether the claims recite additional elements that amount to an inventive concept (i.e., “significantly more”) than the recited judicial exception. According to Office procedure, revised Step 2A overlaps with Step 2B, and thus, many of the considerations need not be re-evaluated in Step 2B because the answer will be the same. See MPEP § 2106.
In Step 2A, several additional elements were identified as additional limitations:
A system comprising: a non-transitory memory; and one or more hardware processors in communication with the non-transitory memory and configured to execute instructions from the non-transitory memory to cause the system to: … via an interface associated with a merchant application presented on a device … between a user of the device and a merchant associated with the merchant application…;…stored on the device…;… and the device; without requiring the user to login to the account with the payment service provider, present a user interface associated with the payment service provider on the device, wherein the user interface is separate from the merchant application and includes the information related to the first funding source and the second funding source;… via the user interface…; …external to the device,…; and redirect the device from the user interface back to the interface of the merchant application (Claim 2);
….exclude the third funding source from the user interface (Claim 3);
the merchant application is associated with a merchant website (Claim 4);
…, via a second user interface associated with the payment service provider,…; and store the data file on the device (Claim 5);
the system to log the user out of the account with the payment service provider after storing the data file (Claim 6);
to a merchant server associated with the merchant (Claim 8);
…, by a computer system associated with a payment service provider, …via an interface associated with an application of the entity and presented on a device of the user;…stored on the device …and the device; …the device …; without requiring the user to login to the account with the payment service provider, providing a user interface associated with the payment service provider on the device, wherein the user interface is separate from the application and includes the information related to the first funding source and the second funding source; …via the user interface, …, from a database external to the device (Claim 9);
redirecting the user of the device from the user interface back to the interface of the application (Claims 10 & 17);
after the user of the device is redirected back to the interface of the application (Claim 11);
from the user interface (Claims 12 & 21);
the user interface is presented in a pop-up window (Claim 14);
storing the data file on the device (Claim 15 & 18);
A non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine associated with a payment service provider to perform operations comprising: …, via an interface associated with an online application presented on a device,…a user of the device and an entity associated with the online application;…stored on the device …the device …stored on the device, …and the device; independent of the user logging in to the account with the payment service provider, providing a user interface associated with the payment service provider on the device, wherein the user interface is separate from the online application and includes the information related to the first funding source and the second funding source; …via the user interface, …, from a database external to the device (Claim 16);
to a server associated with the entity (Claim 20).
These additional limitations, including the limitations in the independent claims and dependent claims, do not amount to an inventive concept because the recitations above do not amount to an improvement in the functioning of a computer or any other technology or technical field, apply the judicial exception with, or by use of, a particular machine, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. In addition, they were already analyzed under Step 2A and did not amount to a practical application of the abstract idea.
For these reasons, the claims are rejected 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) 2, 4-5, 7-10, 12-13, 15-18, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Bell et al. (US Patent No. 9830587 B1, hereinafter “Bell”) in view of Koskelainen et al. (US Pub. No. 20130046656 A1, hereinafter “Koskelainen”).
Regarding claim 2
Bell discloses a system comprising: a non-transitory memory; and one or more hardware processors in communication with the non-transitory memory and configured to execute instructions from the non-transitory memory to cause the system to (Bell, C16, L14-28: processor; C15, L27-45: non-transitory computer readable storage):
receive, via an interface associated with a merchant application presented on a device, a request to perform a streamlined checkout in association with a transaction between a user of the device and a merchant associated with the merchant application (Bell, C8, L42-55: user of mobile device makes decision to purchase good during shopping session by selecting purchase option and device submits request; C3, L7-26: checkout with pre-filled form; C3, L27-39: PayPal; C7, L25-40: online merchant provides web-based shopping for users to shop and purchase goods online; C1, L40-67: online transaction between user and online merchant; C2, L1-35: application);
access a data file stored on the device; …extract, from the data file, information related to a first funding source and a second funding source associated with an account with a payment service provider, the information being at least partially masked and captured during a previous session between the payment service provider and the device (Bell, C3, L7-26: remember customer from previous purchase transaction and reading the customer's cookies file, and pre-fill the form with the information and retrieves the stored customer's information for purchases; C5, L9-18: a list of payment types previously defined and stored by the mobile device user is retrieved; Bell, C9, L1-5: hide or suppress part of the payment information; C8, L55-67: in response to detecting and intercepting the payment form, the electronic wallet application 114 displays a list of payment types in the electronic wallet account available to the mobile device 110 for completing the online purchase transaction);
…, present a user interface associated with the payment service provider on the device, wherein the user interface is separate from the merchant application and includes the information related to the first funding source and the second funding source; receive, via the user interface, a selection of a particular funding source from the first funding source and the second funding source (Bell, C10, L30-55: automatically populates the online merchant-specific payment form with user information and payment information. At step 312, the populated payment form is transmitted via a secure session to the mobile device 110 and is displayed in the browser on the mobile device and the secure session may be an https session different from the https session initiated by the online merchant; C4, L60-67: user interface to present payment; C5, L1-18: a list of payment types previously is presented to user and user selects payment type; C8, L55-67: select payment type from list; C9, L17: finalize and transmit purchase request for direct payment processing upon user confirmation; C14, L10-20: touch screen displays text/graphics to user);
retrieve, …, payment data associated with the particular funding source based on the information and the selection, wherein the payment data comprises unmasked data associated with the particular funding source; process the transaction based in part on the payment data associated with the particular funding source (Bell, C5, L1-30: selected payment type is retrieved and payment information for selected payment type is retrieved (e.g. actual credit card number) and populated; C8, L55-67: select payment type from list; C9, L17: finalize and transmit purchase request for direct payment processing upon user confirmation);
Bell does not teach:
determine that the device is eligible for the streamlined checkout based on the data file indicating that the device is a private device;
retrieve ,from a database external to the device,…(emphasis added);
without requiring the user to login to the account with the payment service provider, present a user interface…;
and redirect the device from the user interface back to the interface of the merchant application.
However, Koskelainen teaches:
determine that the device is eligible for the streamlined checkout based on the data file indicating that the device is a private device (Koskelainen, [0026]:system uses stored cookie to authenticate the user and process the payment request for product user selects from merchant to be bought; [0043]: access user identification cookie for verification and authentication of payment and retrieve user account based on identification cookie; [0009]: user selects item for purchase which prompts a request sent to user for authentication to purchase item; [0010]: the user payment is authorized by a payment system that verifies an identification cookie stored on the web browser of the browsing device of the user. Following verification of the identification cookie unique to the user's browsing device, the payment system automatically authenticates and processes the payment; [0033]: identification cookie includes digital signature);
retrieve, from a database external to the device,…(emphasis added) (Koskelainen, FIG. 1, [0017]: user 102, payment system 106; FIG. 2, [0024]: payment system 106 comprises a payment system database 206; [0026]: access data from payment system database 206; [0019]: user 102 can be any device);
without requiring the user to login to the account with the payment service provider, present a user interface…(Koskelainen, [0010]: user is not required to provide any details like a user name (e.g. the user ID) or a password to access the payment system and after the payment transaction concludes, the web browser of the user's browsing device receives and displays notification of the completed payment);
and redirect the device from the user interface back to the interface of the merchant application (Koskelainen, [0028]: payment response may contain a confirmation approving the payment request, when this is transmitted to the merchant website 110, thereby completing the transaction and enabling the user 102 to access the purchased online content; [0021] and [0036]: the online content (e.g. online newspaper) is displayed to the user 102 on the browsing device 116 in response to the payment response received; [0040]: the online merchant 104 is an online content provider; [0047]: After the merchant Web server 108 receives the payment authentication message from the web browser 114, the online content is displayed to the user).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified the presentation of the payment information and retrieval of data of Bell with without requiring a user to login, information is presented and redirection of user interface to the interface of merchant application and retrieving data from a database external to the device as taught by Koskelainen because the results of such a modification would be predictable. Specifically, Bell would continue to teach presenting via a user interface the payment information except now without requiring a user to login, information is presented and redirection of user interface to the interface of merchant application according to the teachings of Koskelainen in order to retrieve data and purchase goods faster without logging in. This is a predictable result of the combination. (Koskelainen, [0005]-[0010]).
Regarding claim 4
The combination of Bell and Koskelainen teaches the system of claim 2, wherein the merchant application is associated with a merchant website (Bell, C7, L25-33: online merchant provides web pages).
Regarding claim 5
The combination of Bell and Koskelainen teaches the system of claim 2, wherein executing the instructions further causes the system to: prior to receiving the request to perform the streamlined checkout, receive, via a second user interface associated with the payment service provider, an indication for participating in a streamlined checkout process for a subsequent transaction; generating…using historic transaction data associated with the account (Bell, FIG. 3, C9, L40-67: prior to online session to make purchase, user selects payment type to use for online shopping session and registers the information, then user initiates shopping session by accessing merchant website; C10, L1-33: once event of interest to make purchase is detected, payment form is transmitted to user for display; C5, 1-27: previously stored payment types are retrieved and presented to user; C4, L60-67: interface);
Bell does not teach:
generate the data file using …data; and store the data file on the device.
However, Koskelainen teaches
generate the data file using …data associated with the account; and store the data file on the device (Koskelainen, [0025]: generate and store cookie for device; [0026]: store data on cookie).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified the historic transaction data of Bell with generating a data file using data associated with the account; and store the data file on the device as taught by Koskelainen because the results of such a modification would be predictable. Specifically, Bell would continue to teach the historic transaction data except now generating a data file using data associated with the account; and store the data file on the device is taught according to the teachings of Koskelainen in order to access and process payment request. This is a predictable result of the combination. (Koskelainen, [0026]).
Regarding claim 7
The combination of Bell and Koskelainen teaches the system of claim 2, wherein the information includes one or more shipping preferences of the user (Bell, C3, L5-20: customer information includes shipping address).
Regarding claim 8
The combination of Bell and Koskelainen teaches the system of claim 7, wherein executing the instructions further causes the system to: subsequent to processing the transaction, transmit the one or more shipping preferences of the user to a merchant server associated with the merchant (Bell, C3, L5-35: customer information includes shipping address and during a subsequent purchase, the online merchant retrieves the stored customer's information; C16, L35-50: server).
Regarding claims 9 and 16
Bell discloses a method, comprising:
receiving, by a computer system associated with a payment service provider, a request to process a transaction between a user and an entity, wherein the request is received via an interface associated with an application of the entity and presented on a device of the user (Bell, C8, L42-55: user of mobile device makes decision to purchase good during shopping session by selecting purchase option and device submits request; C3, L7-26: checkout with pre-filled form; C3, L27-39: PayPal; C7, L25-40: online merchant provides web-based shopping for users to shop and purchase goods online; C1, L40-67: online transaction between user and online merchant; C2, L1-35: application);
accessing, from a data file stored on the device, information related to a first funding source and a second funding source associated with an account with the payment service provider, wherein the information is at least partially masked and captured during a previous session between the payment service provider and the device (Bell, C3, L7-26: remember customer from previous purchase transaction and reading the customer's cookies file, and pre-fill the form with the information and retrieves the stored customer's information for purchases; C5, L9-18: a list of payment types previously defined and stored by the mobile device user is retrieved; Bell, C9, L1-5: hide or suppress part of the payment information; C8, L55-67: in response to detecting and intercepting the payment form, the electronic wallet application 114 displays a list of payment types in the electronic wallet account available to the mobile device 110 for completing the online purchase transaction);
…, providing a user interface associated with the payment service provider on the device, wherein the user interface is separate from the application and includes the information related to the first funding source and the second funding source (Bell, C10, L30-55: automatically populates the online merchant-specific payment form with user information and payment information. At step 312, the populated payment form is transmitted via a secure session to the mobile device 110 and is displayed in the browser on the mobile device and the secure session may be an https session different from the https session initiated by the online merchant; C4, L60-67: user interface to present payment; C5, L1-18: a list of payment types previously is presented to user and user selects payment type; C8, L55-67: select payment type from list; C9, L17: finalize and transmit purchase request for direct payment processing upon user confirmation; C14, L10-20: touch screen displays text/graphics to user);
in response to receiving a selection of a particular funding source via the user interface, retrieving, …, payment data associated with the particular funding source based on the information and the selection, wherein the payment data comprises unmasked data associated with the particular funding source, and wherein the particular funding source is one of the first funding source or the second funding source; and processing the transaction based in part on the payment data associated with the particular funding source (Bell, C5, L1-30: selected payment type is retrieved and payment information for selected payment type is retrieved (e.g. actual credit card number) and populated; C8, L55-67: select payment type from list; C9, L17: finalize and transmit purchase request for direct payment processing upon user confirmation; C2, L15-35: stored in memory; C17, L1-25: memory and data structures).
Bell does not teach:
determining that the device is eligible for a streamlined checkout based on the data file indicating the device is a private device;
without requiring the user to login to the account with the payment service provider, providing a user interface…;
retrieving, from a database external to the device, …
However, Koskelainen teaches:
determining that the device is eligible for a streamlined checkout based on the data file indicating the device is a private device (Koskelainen, [0026]:system uses stored cookie to authenticate the user and process the payment request for product user selects from merchant to be bought; [0043]: access user identification cookie for verification and authentication of payment and retrieve user account based on identification cookie; [0009]: user selects item for purchase which prompts a request sent to user for authentication to purchase item; [0010]: the user payment is authorized by a payment system that verifies an identification cookie stored on the web browser of the browsing device of the user. Following verification of the identification cookie unique to the user's browsing device, the payment system automatically authenticates and processes the payment; [0033]: identification cookie includes digital signature);
without requiring the user to login to the account with the payment service provider, providing a user interface…(Koskelainen, [0010]: user is not required to provide any details like a user name (e.g. the user ID) or a password to access the payment system and after the payment transaction concludes, the web browser of the user's browsing device receives and displays notification of the completed payment);
retrieving, from a database external to the device,…(Koskelainen, FIG. 1, [0018]: system 106; FIG.2, [0024]: system 106 includes database; [0026]: access data from database
The motivation to combine Bell and Koskelainen is the same as set forth above in claim 2.
Regarding claims 10 and 17
The combination of Bell and Koskelainen teaches the method of claim 9, further comprising: redirecting the user of the device from the user interface back to the interface of the application (Koskelainen, [0028]: payment response may contain a confirmation approving the payment request, when this is transmitted to the merchant website 110, thereby completing the transaction and enabling the user 102 to access the purchased online content; [0021] and [0036]: the online content (e.g. online newspaper) is displayed to the user 102 on the browsing device 116 in response to the payment response received; [0040]: the online merchant 104 is an online content provider; [0047]: After the merchant Web server 108 receives the payment authentication message from the web browser 114, the online content is displayed to the user).
The motivation to combine Bell and Koskelainen is the same as set forth above in claim 2.
Regarding claims 12 and 21
The combination of Bell and Koskelainen teaches the method of claim 9, wherein the information is further related to a third funding source associated with the account, and wherein the method further comprises: determining that the third funding source is unavailable for the transaction; and excluding the third funding source from the user interface (Koskelainen, FIG. 4B, [0044]: verifies whether the user account balance is sufficient for making the payment and if the account does not have sufficient funds, present different payment options; [0045] Once the user 102 selects a payment option, the user 102 is navigated to a new web browser window linking the user 102 to a payment gateway or to his preferred online banking website at step 416. The user 102 also may be taken to a payment gateway that again provides him multiple option payments. The user 102 recharges his account balance using his online credit card or online banking details at step 418).
The motivation to combine Bell and Koskelainen is the same as set forth above in claim 2.
Regarding 13
The combination of Bell and Koskelainen teaches the method of claim 12, wherein the determining that the third funding source is unavailable for the transaction is based on at least one of a balance of the third funding source or an expiration date of the third funding source (Koskelainen, FIG. 4B, [0044]: verifies whether the user account balance is sufficient for making the payment and if the account does not have sufficient funds, present different payment options).
The motivation to combine Bell and Koskelainen is the same as set forth above in claim 2.
Regarding claim 15
The combination of Bell and Koskelainen teaches the method of claim 9, further comprising: prior to the receiving the request, generating …using historic transaction data associated with the account; …(Bell, FIG. 3, C9, L40-67: prior to online session to make purchase, user selects payment type to use for online shopping session and registers the information, then user initiates shopping session by accessing merchant website; C10, L1-33: once event of interest to make purchase is detected, payment form is transmitted to user for display; C5, 1-27: previously stored payment types are retrieved and presented to user; C4, L60-67: interface).
Bell does not teach:
generating the data file using … data …; and storing the data file on the device.
However, Koskelainen teaches
generating the data file using … data …; and storing the data file on the device (Koskelainen, [0025]: generate and store cookie for device; [0026]: store data on cookie).
The motivation to combine Bell and Koskelainen is the same as set forth above in claim 5.
Regarding claim 18
The combination of Bell and Koskelainen teaches the non-transitory machine-readable medium of claim 16, wherein the operations further comprise: prior to the receiving the request, generating…using transaction data associated with the account; and storing the data file on the device (Bell, FIG. 3, C9, L40-67: prior to online session to make purchase, user selects payment type to use for online shopping session and registers the information, then user initiates shopping session by accessing merchant website; C10, L1-33: once event of interest to make purchase is detected, payment form is transmitted to user for display; C5, 1-27: previously stored payment types are retrieved and presented to user; C4, L60-67: interface).
Bell does not teach:
generating the data file using …data …; and storing the data file on the device.
However, Koskelainen teaches:
generating the data file using …data …; and storing the data file on the device (Koskelainen, [0025]: generate and store cookie for device; [0026]: store data on cookie).
The motivation to combine Bell and Koskelainen is the same as set forth above in claim 5.
Regarding claim 20
The combination of Bell and Koskelainen teaches the non-transitory machine-readable medium of claim 16, wherein the operations further comprise: obtaining one or more shipping preferences of the user based on the information; and transmitting the one or more shipping preferences of the user to a server associated with the entity (Bell, C3, L5-35: customer information includes shipping address and during a subsequent purchase, the online merchant retrieves the stored customer's information; C16, L35-50: server).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Bell and Koskelainen as applied to claim 1 above, and further in view of Grigg et al. (US Pub. No. 2014/0122328 A1, hereinafter “Grigg”).
Regarding claim 3
The combination of Bell and Koskelainen teaches the system of claim 2, wherein the information is further related to a third funding source associated with the account, …(Bell, C5, L5-25: a list of payment types (e.g. MasterCard, Credit Card, Debit Card, is displayed and mobile device user selects the payment type).
The combination of Bell and Koskelainen does not teach:
and wherein executing the instructions further causes the system to: determine that the third funding source is unavailable for the transaction and exclude the third funding source from the user interface.
However, Grigg teaches:
and wherein executing the instructions further causes the system to: determine that the third funding source is unavailable for the transaction and exclude the third funding source from the user interface (Grigg, [0020]: wherein the module does not initiate presentation on the user interface of a payment option unavailable to the user; [0050]: The mobile device may access information associated with the merchant to determine that the merchant will enable the user to pay via a first payment option, but will not enable the user to pay via a second payment option. Based on this information, the mobile device will present the first payment option on the user interface, but will not present the second payment option on the user interface ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified the funding source of Bell and Koskelainen with determining that the third funding source is unavailable for the transaction and exclude the third funding source from the user interface as taught by Grigg because the results of such a modification would be predictable. Specifically, Bell and Koskelainen would continue to teach the funding source except now determining that the third funding source is unavailable for the transaction and exclude the third funding source from the user interface is taught according to the teachings of Grigg in order to not present unavailable payment options. This is a predictable result of the combination. (Grigg, [0020]).
Claim(s) 6, 14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bell and Koskelainen as applied to claim 1 above, and further in view of Goodman et al. (US Pub. No. 20130246943 A1, hereinafter “Goodman”).
Regarding claim 6
The combination of Bell and Koskelainen teaches the system of claim 5, wherein executing the instructions further causes the system to log the user ...of the account with the payment service provider... (Bell, C9, L55-67: user login prior to initiating online session; C10, L1-25: online session includes making purchase request; C3, L7-26: remember customer from previous purchase transaction and reading the customer's cookies file, and pre-fill the form with the information and retrieves the stored customer's information for purchases; C5, L9-18: a list of payment types previously defined and stored by the mobile device user is retrieved; C8, L55-67: in response to detecting and intercepting the payment form, the electronic wallet application 114 displays a list of payment types in the electronic wallet account available to the mobile device 110 for completing the online purchase transaction).
The combination of Bell and Koskelainen does not teach:
wherein executing the instructions further causes the system to log the user out … after storing the data file.
However, Goodman teaches:
wherein executing the instructions further causes the system to log the user out … after storing the data file (Goodman, FIG, 4, [0031] A user logs into one or more web applications 405, each web application having at least one meta-data tag and the logout URL and any additional information is recorded in a database 415 (e.g., local storage) and then management UI automatically issues logouts for multiple websites, 430; [0018]: A web page markup (HTML) meta-data tag is used to record or capture a logout universal resource locator (URL) for a website).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified the logging of the user of the account with the payment service provider of Bell and Koskelainen with logging the user out after storing the data file as taught by Goodman because the results of such a modification would be predictable. Specifically, Bell and Koskelainen would continue to teach logging of the user of the account with the payment service provide except now logging the user out after storing the data file is taught according to the teachings of Goodman in order to securely and automatically logging out a user. This is a predictable result of the combination. (Goodman, [0017]).
Regarding claim 14
The combination of Bell and Koskelainen teaches the method of claim 9, wherein the user interface is presented (Bell, C4, L60-67: user interface to present payment).
The combination of Bell and Koskelainen does not teach:
wherein the user interface is presented in a pop-up window (emphasis added).
However, Goodman teaches:
wherein the user interface is presented in a pop-up window (emphasis added) (Goodman, [0026]: separate pop-up window or additional graphical user interface).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified the presentation of the user interface of Bell and Koskelainen with a pop-up window as taught by Goodman because the results of such a modification would be predictable. Specifically, Bell and Koskelainen would continue to teach the presentation of the user interface except now a pop-up window is taught according to the teachings of Goodman in order to display the interface. This is a predictable result of the combination. (Goodman, [0026]).
Regarding claim 19
The combination of Bell and Koskelainen teaches the non-transitory machine-readable medium of claim 18, wherein the operations further comprise logging the user …the account with the payment service provider prior to the receiving the request (Bell, C9, L55-67: user login prior to initiating online session; C10, L1-25: online session includes making purchase request; C3, L7-26: remember customer from previous purchase transaction and reading the customer's cookies file, and pre-fill the form with the information and retrieves the stored customer's information for purchases; C5, L9-18: a list of payment types previously defined and stored by the mobile device user is retrieved; C8, L55-67: in response to detecting and intercepting the payment form, the electronic wallet application 114 displays a list of payment types in the electronic wallet account available to the mobile device 110 for completing the online purchase transaction).
The combination of Bell and Koskelainen does not teach:
wherein the operations further comprise logging the user out ...
However, Goodman teaches:
wherein the operations further comprise logging the user out ... (Goodman, FIG, 4, [0031] A user logs into one or more web applications 405, each web application having at least one meta-data tag and the logout URL and any additional information is recorded in a database 415 (e.g., local storage) and then management UI automatically issues logouts for multiple websites, 430; [0018]: A web page markup (HTML) meta-data tag is used to record or capture a logout universal resource locator (URL) for a website).
The motivation to combine Bell and Koskelainen with Goodman is the same as set forth above in claim 6.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Bell and Koskelainen as applied to claim 1 above, and further in view of Balasubramanian et al. (US Pub. No. 20090313147 A1, hereinafter “Balasubramanian”)
Regarding claim 11
The combination of Bell and Koskelainen teaches the method of claim 10, wherein the processing the transaction is performed …(Bell, C5, L1-30: selected payment type is retrieved and payment information for selected payment type is retrieved (e.g. actual credit card number) and populated; C8, L55-67: select payment type from list; C9, L17: finalize and transmit purchase request for direct payment processing upon user confirmation).
Bell and Koskelainen does not teach:
processing the transaction is performed after the user of the device is redirected back to the interface of the application (emphasis added).
However, Balasubramanian teaches:
processing the transaction is performed after the user of the device is redirected back to the interface of the application (emphasis added) (Balasubramanian, [0037]: Upon completing any tasks called for by the alternative payment provider 114, the consumer 102 is redirected to the merchant's website 104 and the transaction proceeds towards completion; [0039] Once the consumer 102 is redirected back to the merchant 103, the merchant 103 submits the completed order to the order management system 106 for processing; [0052]: when the consumer 102 is redirected to the UMP 110, the web layer 131 provides the consumer 102 with a web interface).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified the processing of the transaction of Bell and Koskelainen with the processing being performed after the user of the device is redirected back to the interface of the application as taught by Balasubramanian because the results of such a modification would be predictable. Specifically, Bell and Koskelainen would continue to teach the processing of the transaction except now the processing being performed after the user of the device is redirected back to the interface of the application is taught according to the teachings of Balasubramanian in order to redirect the consumer to complete the transaction. This is a predictable result of the combination. (Balasubramanian, [0020]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is cited as Rothman et al. (US Pub. No. 2014/0046780 A1) related to single page checkout, Baskerville et al. (US Pub. No. 20100299220 A1) related to facilitate online transactions via mobile communications and non-patent literature, Card-based Macropayment for Mobile Phones, related to client wallets to store payment information on a user's mobile terminal.
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 LATASHA DEVI RAMPHAL whose telephone number is (571)272-2644. The examiner can normally be reached 11 AM - 7: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, Jeffrey A. Smith can be reached at 5712726763. 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.
/LATASHA D RAMPHAL/Examiner, Art Unit 3688
/Jeffrey A. Smith/Supervisory Patent Examiner, Art Unit 3688
Prosecution Insights