DETAILED ACTION
Claim Status
This is first office action on the merits in response to the application filed on 3/28/2025.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are currently pending and have been examined.
Claim Objections
Claims 7 and 14 are objected to because of the following informalities:
In claim 7, line 4; and claim 14, corresponding line, “download” should read --to download--.
Appropriate correction is required.
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 a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under the Step 1 of the Section 101 analysis, Claims 1-7 are drawn to a system which is within the four statutory categories (i.e. a machine), Claims 8-14 are drawn to a method which is within the four statutory categories (i.e., a process), and Claims 15-20 are drawn to a non-transitory computer-readable medium which is within the four statutory categories (i.e., a manufacture).
Since the claims are directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea). Based on consideration of all of the relevant factors with respect to the claim as a whole, claims 1-20 are determined to be directed to an abstract idea. The rationale for this determination is explained below:
Regarding Claims 1 and 15:
Claims 1 and 15 are drawn to an abstract idea without significantly more. The claims recite “display an authentication user interface for a second user based at least in part on a selection of an authentication hyperlink, the authentication user interface being associated with accessing a virtual payment instrument that is linked to a transaction account of a first user; transmit a user credential for the second user using the authentication user interface; receive the virtual payment instrument based at least in part on an authentication of the user credential for the second user; and display a wallet user interface that includes the virtual payment instrument based at least in part on a receipt of the virtual payment instrument, the wallet user interface displaying a spending policy for the virtual payment instrument that has been set by the first user.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). For example, but for the “authentication user interface”, “hyperlink”, “virtual payment instrument”, and “wallet user interface” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical business relations, because the entities including the client and the first and second users interact with one another to set up the virtual payment instrument and spending policy.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A system, comprising: a client device comprising a processor and a memory; and machine-readable instructions stored in the memory that, when executed by the processor, cause the client device to at least:”, “A non-transitory, computer-readable medium, comprising machine-readable instructions that, when executed by a processor of a client device, cause the client device to at least:”, “authentication user interface”, “hyperlink”, “virtual payment instrument”, and “wallet user interface”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claim 8:
Claim 8 is drawn to an abstract idea without significantly more. The claims recite “receiving, by a client device, an authentication hyperlink associated with providing a second user access to a virtual payment instrument, the virtual payment instrument being originated by a first user; displaying, by the client device, an authentication user interface for the second user based at least in part on a selection of the authentication hyperlink; transmitting, by the client device, a user credential for the second user using the authentication user interface; receiving, by the client device, data associated with the virtual payment instrument based at least in part on an authentication of the user credential for the second user; and displaying, by the client device, a wallet user interface that includes the virtual payment instrument based at least in part on a receipt of the virtual payment instrument, the wallet user interface displaying a spending policy for the virtual payment instrument that has been set by the first user.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). For example, but for the “client device”, “hyperlink”, “virtual payment instrument”, “authentication user interface”, and “wallet user interface” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical business relations, because the entities including the client and the first and second users interact with one another to set up the virtual payment instrument and spending policy.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A computer-implemented method comprising:”, “client device”, “hyperlink”, “virtual payment instrument”, “authentication user interface”, and “wallet user interface”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claims 2-7, 9-14, and 16-20:
Dependent claims 4, 11, and 18 only further elaborate the abstract idea and do not recite additional elements.
Dependent claims 2-3, 5-7, 9-10, 12-14, 16-17, and 19-20 include additional limitations, for example, “client device”, “user interface component”, “virtual payment instrument”, and “machine-readable representation” (Claims 2, 9, and 16); “machine-readable representation” and “virtual payment instrument” (Claims 3, 10, and 17); “virtual payment instrument”, “user interface component”, and “point of sale (POS) terminal” (Claims 5, 12, and 19); “client device”, “virtual payment instrument”, and “wallet user interface” (Claims 6, 13, and 20); and “client device”, “wallet application”, and “virtual payment instrument” (Claims 7 and 14), but none of these limitations are deemed significantly more than the abstract idea because, as stated above, they require no more than generic computer structures or signals to be executed, and do not recite any Improvements to the functioning of a computer, or Improvements to any other technology or technical field.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation or implementing the judicial exception on a generic computer.
Therefore, whether taken individually or as an ordered combination, claims 2-7, 9-14, and 16-20 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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, 4-8, 11-15, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goodwin (US 20190080309 A1) in view of Russell (US 11489842 B1).
Regarding Claims 1 and 15, Goodwin teaches A system, comprising: a client device comprising a processor and a memory; and machine-readable instructions stored in the memory that, when executed by the processor, cause the client device to at least (Goodwin: Abstract; Paragraph(s) 0004): A non-transitory, computer-readable medium, comprising machine-readable instructions that, when executed by a processor of a client device, cause the client device to at least (Goodwin: Abstract; Paragraph(s) 0004, 0030):
display an authentication user interface for a second user based at least in part on a selection of an authentication [hyperlink], the authentication user interface being associated with accessing a virtual payment instrument that is linked to a transaction account of a first user (Goodwin: Paragraph(s) 0016, 0046, 0049 teach(es) an application may present a graphical user interface to a user (e.g., on a display), and the user may select certain functions of the client device to be executed by providing input to the user interface. In addition, the service provider server may be configured to generate and manage secondary accounts (e.g., virtual cards) associated with a primary account); …; and display a wallet user interface that includes the virtual payment instrument based at least in part on a receipt of the virtual payment instrument, the wallet user interface displaying a spending policy for the virtual payment instrument that has been set by the first user (Goodwin: Paragraph(s) 0068, 0003 teach(es) once a secondary account has been generated, the service provider may transmit an identifier for the secondary account (e.g., the token) to the secondary client device. In some embodiments, this may involve transmitting the secondary account identifier (i.e., virtual payment instrument) to the secondary client device (i.e., second client device) using a device identifier (i.e., device identifier from the beneficiary user data) received in the request to generated the secondary account).
However, Goodwin does not explicitly teach …based at least in part on a selection of an authentication hyperlink, …transmit a user credential for the second user using the authentication user interface; receive the virtual payment instrument based at least in part on an authentication of the user credential for the second user.
Russell from same or similar field of endeavor teaches …based at least in part on a selection of an authentication hyperlink, …transmit a user credential for the second user using the authentication user interface; receive the virtual payment instrument based at least in part on an authentication of the user credential for the second user (Russell: Col. 3, lines 58-66; Col. 11, line 65 ~ Col. 12, line 15; Col. 12, lines 30-53 teach(es) The systems and methods also generate automated messages that can be sent to proposed delegates with a link (i.e., hyperlink for configuring a wallet application) and authentication code so that the delegate can be securely enrolled (i.e., for registering) with the account management service. By generating automated messages at the point of the user's device, the embodiments facilitate trust between the delegate and the account management service, since the user initiates the enrollment process directly via a message over SMS; service has determined that the delegate has accepted enrollment. At this point, the service must request the necessary identification information so that the delegate can be trusted to approve transactions. In step 1204, service may retrieve delegate approval policies. These policies may be set by the user at an earlier point, as described above and shown schematically in FIG. 4. In step 1206, service may select an appropriate authorization level based on information indicated in the delegate approval policies. For example, if the user indicates that the delegate can approve transactions up to $500, this may correspond with a particular predetermined authorization level).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Goodwin to incorporate the teachings of Russell for …based at least in part on a selection of an authentication hyperlink, …transmit a user credential for the second user using the authentication user interface; receive the virtual payment instrument based at least in part on an authentication of the user credential for the second user.
There is motivation to combine Russell into Goodwin because a person of ordinary skill in the art would appreciate Russell’s hyperlink facilitating secure communications between the system and the second client device (Russell: Col. 3, lines 58-66; Col. 11, line 65 ~ Col. 12, line 20).
Regarding Claim 8, Goodwin teaches A computer-implemented method comprising (Goodwin: Abstract):
displaying, by the client device, an authentication user interface for the second user … (Goodwin: Paragraph(s) 0016, 0046, 0049 teach(es) an application may present a graphical user interface to a user (e.g., on a display), and the user may select certain functions of the client device to be executed by providing input to the user interface. In addition, the service provider server may be configured to generate and manage secondary accounts (e.g., virtual cards) associated with a primary account); transmitting, by the client device, a user credential for the second user using the authentication user interface; receiving, by the client device, data associated with the virtual payment instrument based at least in part on an authentication of the user credential for the second user (Goodwin: Paragraph(s) 0068, 0003, 0022, 0027,0034, 0042 teach(es) once a secondary account has been generated, the service provider may transmit an identifier for the secondary account (e.g., the token) to the secondary client device. In some embodiments, this may involve transmitting the secondary account identifier (i.e., virtual payment instrument) to the secondary client device (i.e., second client device) using a device identifier (i.e., device identifier from the beneficiary user data) received in the request to generated the secondary account; An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer); and displaying, by the client device, a wallet user interface that includes the virtual payment instrument based at least in part on a receipt of the virtual payment instrument, the wallet user interface displaying a spending policy for the virtual payment instrument that has been set by the first user (Goodwin: Paragraph(s) 0046, 0016, 0049, 0086, 0104 teach(es) the service provider server may be configured to generate and manage secondary accounts (e.g., virtual cards) associated with a primary account. In addition, the user may select certain functions of the client device to be executed by providing input to the user interface; the service provider server may dynamically generate a set of protocols for that transaction based on itinerary data for that secondary account).
However, Goodwin does not explicitly teach receiving, by a client device, an authentication hyperlink associated with providing a second user access to a virtual payment instrument, the virtual payment instrument being originated by a first user, and …based at least in part on a selection of the authentication hyperlink.
Russell from same or similar field of endeavor teaches receiving, by a client device, an authentication hyperlink associated with providing a second user access to a virtual payment instrument, the virtual payment instrument being originated by a first user, …based at least in part on a selection of the authentication hyperlink (Russell: Col. 3, lines 58-66; Col. 11, line 65 ~ Col. 12, line 15; Col. 12, lines 30-53 teach(es) The systems and methods also generate automated messages that can be sent to proposed delegates with a link (i.e., hyperlink for configuring a wallet application) and authentication code so that the delegate can be securely enrolled (i.e., for registering) with the account management service. By generating automated messages at the point of the user's device, the embodiments facilitate trust between the delegate and the account management service, since the user initiates the enrollment process directly via a message over SMS; service has determined that the delegate has accepted enrollment. At this point, the service must request the necessary identification information so that the delegate can be trusted to approve transactions. In step 1204, service may retrieve delegate approval policies. These policies may be set by the user at an earlier point, as described above and shown schematically in FIG. 4. In step 1206, service may select an appropriate authorization level based on information indicated in the delegate approval policies. For example, if the user indicates that the delegate can approve transactions up to $500, this may correspond with a particular predetermined authorization level).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Goodwin to incorporate the teachings of Russell for receiving, by a client device, an authentication hyperlink associated with providing a second user access to a virtual payment instrument, the virtual payment instrument being originated by a first user, and …based at least in part on a selection of the authentication hyperlink.
There is motivation to combine Russell into Goodwin because a person of ordinary skill in the art would appreciate Russell’s hyperlink facilitating secure communications between the system and the second client device (Russell: Col. 3, lines 58-66; Col. 11, line 65 ~ Col. 12, line 20).
Regarding Claims 4, 11, and 18, the combination of Goodwin and Russell teaches all the limitations of claims 1, 8, and 15 above; and Goodwin further teaches wherein the spending policy comprises at least one of a monetary a limit, a spending category, or an expiration date (Goodwin: Paragraph(s) 0066-0067, 0042, 0044, 0086 teach(es) a request to generate a secondary account (virtual payment instrument) is received by the service provider server from a primary client device. In addition, one or more protocols (spending policy) may be selected to be associated with the secondary account; the user may request an increase in a spending limit or an extension of some specific status).
Regarding Claims 5, 12, and 19, the combination of Goodwin and Russell teaches all the limitations of claims 1, 8, and 15 above; and Goodwin further teaches wherein the wallet user interface includes a spending policy area and a checkout area, the spending policy area including the spending policy for the virtual payment instrument, the checkout area comprises at least one user interface component that is configured to presenting the virtual payment instrument to a point of sale (POS) terminal (Goodwin: Paragraph(s) 0079, 0043, 0018-0019, 0024, 0085 teach(es) the functionality may be implemented via a checkout element rendered within a browser application, the functionality may be implemented via a checkout element rendered within a mobile application that manages access to a resource, or the functionality may be implemented via a checkout element rendered within a payment application (e.g., a mobile application used to complete payments at a physical location); the access device may a point-of-sale (POS) device).
Regarding Claims 6, 13, and 20, the combination of Goodwin and Russell teaches all the limitations of claims 1, 8, and 15 above; and Goodwin further teaches wherein the machine-readable instructions stored in the memory that, when executed by the processor, cause the client device to at least: receive an updated spending policy for the virtual payment instrument, the updated spending policy representing a change in the spending policy by the first user; and display the updated spending policy in the wallet user interface (Goodwin: Paragraph(s) 0086, 0104 teach(es) the user may request an increase in a spending limit or an extension of some specific status).
Regarding Claims 7 and 14, the combination of Goodwin and Russell teaches all the limitations of claims 1, 8, and 15 above; and Goodwin further teaches wherein the machine-readable instructions that receive the virtual payment instrument further cause, when executed by the processor, cause the client device to at least: receive an instruction download a wallet application associated with the virtual payment instrument; install the wallet application in the client device; and activate the virtual payment instrument for use on the client device based at least in part on the installation of the wallet application (Goodwin: Paragraph(s) 0027 teach(es) A digital wallet may allow the user to load one or more payment cards onto the digital wallet so as to make a payment without having to enter an account number or present a physical card. A digital wallet application may allow the user to view an account statement including information regarding transactions conducted on accounts loaded on the digital wallet).
Claim(s) 2-3, 9-10, and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goodwin (US 20190080309 A1) in view of Russell (US 11489842 B1), as applied to claims 1, 8, and 15, and in further view of McClung (US 20160162882 A1).
Regarding Claims 2, 9, and 16, the combination of Goodwin and Russell teaches all the limitations of claims 1, 8, and 15 above; however the combination does not explicitly teach wherein the machine-readable instructions stored in the memory that, when executed by the processor, cause the client device to at least: receive a selection of a user interface component for presenting the virtual payment instrument; generate a machine-readable representation of the virtual payment instrument based at least in part on the selection of the user interface component; and display the machine-readable representation of the virtual payment instrument.
McClung from same or similar field of endeavor teaches wherein the machine-readable instructions stored in the memory that, when executed by the processor, cause the client device to at least: receive a selection of a user interface component for presenting the virtual payment instrument; generate a machine-readable representation of the virtual payment instrument based at least in part on the selection of the user interface component; and display the machine-readable representation of the virtual payment instrument (McClung: Paragraph(s) 0108, 0159 teach(es) allowing a consumer to make a payment through the user's mobile device, such as through the use of barcodes, communication between the payment provider and a merchant, and other methods).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Goodwin and Russell to incorporate the teachings of McClung for the benefit of facilitating a choice by a consumer of one of a plurality of eWallets from an eWallet entity or from an eWallet provider and using a hyperlink for transactions (See at least McClung: Abstract; Paragraph(s) 0335).
Regarding Claims 3, 10, and 17, the combination of Goodwin, Russell, and McClung teaches all the limitations of claims 2, 9, and 16 above; however the combination does not explicitly teach wherein the machine-readable representation of the virtual payment instrument is a one-dimensional bar code or a two-dimensional bar code.
McClung further teaches wherein the machine-readable representation of the virtual payment instrument is a one-dimensional bar code or a two-dimensional bar code (Goodwin: Paragraph(s) 0108, 0159, 0248, 0233, as stated above with respect to claims 2, 9, and 16).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Goodwin and Russell to incorporate the teachings of McClung for the benefit of facilitating a choice by a consumer of one of a plurality of eWallets from an eWallet entity or from an eWallet provider and using a hyperlink for transactions (See at least McClung: Abstract; Paragraph(s) 0335).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm 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, Neha Patel can be reached at (571)270-1492. 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.
/CLAY C LEE/Primary Examiner, Art Unit 3699