DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Acknowledgements
This Office Action is in response to the amendments to the drawings filed April 11, 2025 (“April 2025 Drawings”), amendments to the specification filed April 11, 2025 (“April 2025 Spec.”), and the December 9, 2025 (“December 2025 Response”) which includes, inter alia, claim amendments (“December 2025 Claims”) and remarks (“December 2025 Remarks”).
Claims 37 and 39-47 are currently pending and have been examined.
Drawings
The April 2025 Drawings are herein acknowledged and are acceptable.
Specification
The April 2025 Spec. is herein acknowledged and is acceptable.
Claim Objections
Claim 40 is objected to because of the following informalities: “the credit card approval server” is not previously mentioned in the claim; for purposes of applying the prior art, the Examiner will interpret it as “a credit card approval server.” 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 37 and 39-47 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.
Step 1 of the Subject Matter Eligibility Analysis for Products and Processes1 (“SME Analysis”):
Claims 37 and 39-47 are directed to a system.
Thus, Claims 37 and 39-47 are directed to one of the statutory categories.
Step 2A- Prong One of the SME Analysis:
Claim 37 recites/describes the following steps:
at least one group of members,
that includes one or more disposable payment elements, at least one of the one or more disposable payment elements comprising at least a prepaid card number and security code and having a zero balance;
to issue the one or more disposable payment elements;
a loyalty club application; and
a loyalty club comprising a members and rules;
receive a request to provide a disposable payment element of the one or more disposable payment elements with details of a member from the group of members to perform a transaction from a point of sale (POS);
allocate a selected disposable payment element of the one or more disposable payment elements to the member;
the selected disposable payment element to the loyalty club application;
send a request to check a credit balance of the member to the loyalty club server;
receive a set of rules applicable to the member from the rules;
approve the transaction based on the set of rules and the credit balance;
convert at least part of the credit balance to money and upload the money to the selected disposable payment element;
receive a message that the purchase is completed;
delete the selected disposable payment element; and
a new disposable payment element.
These steps, under the broadest reasonable interpretation, describe or set-forth a member performing a purchase by checking a member credit balance, converting the credit to money, and using a disposable payment element loaded with the money at a point of sale, which amounts to a commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). These limitations therefore fall within the “certain methods of organizing human activity” subject matter grouping of abstract ideas.
Thus, Claim 37 recites an abstract idea.
The dependent claims likewise recites/describes these steps (by incorporation - and therefore also recite limitations that fall within this subject matter grouping of abstract ideas); therefore, this claim recites an abstract idea under the same analysis. Any elements recited in a dependent claim that are not specifically identified/addressed by the Examiner under step 2A (prong two) or step 2B of this analysis shall be understood to be an additional part of the abstract idea recited by that particular claim.
Thus, Claims 37 and 39-47 recite an abstract idea.
Thus, Claims 37 and 39-47 recite an abstract idea.
Step 2A- Prong Two of the SME Analysis:
The claims recite the additional elements/limitations of:
a payment manager server;
database;
a processing circuitry;
a payment element database;
a payment element generator operably coupled to the payment manager server and configured to;
a computing device operably coupled to the payment manager server and configured to run; and
a loyalty club server;
payment manager server;
a members database;
a rules module;
wherein the processing circuitry is configured to:
upload;
receive...from the rules module;
delete…from the payment element database; and
upload…to the payment element database.
The requirement to execute the claimed steps/functions using a “system” having various “servers,” “databases,” “generators,” “modules,” “processing circuitry,” “device,” and “application,” is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
The recited additional elements of “upload,” simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea; mere post-solution activity in conjunction with an abstract idea). The term “extra-solution activity” is understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim. The recited additional elements are considered “extra-solution” because the step/act of uploading is merely moving data from one location to another. These limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application (see MPEP 2106.05(h)).
Furthermore, although the claims recite a specific sequence of computer-implemented functions, and although the specification suggests certain functions may be advantageous for various reasons (e.g., business reasons), the Examiner has determined that the ordered combination of claim elements (i.e., the claims as a whole) are not directed to an improvement to computer functionality/capabilities, an improvement to a computer-related technology or technological environment, and do not amount to a technology-based solution to a technology-based problem.
The dependent Claims fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e., they are part of the abstract idea recited in each respective claim).
Therefore, the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application.
Accordingly, Claims 37 and 39-47 are directed to an abstract idea.
Step 2B of the SME Analysis:
As discussed above in “Step 2A – Prong 2”, the requirement to execute the claimed steps/functions using a “system” having various “servers,” “databases,” “generators,” “modules,” “processing circuitry,” “device,” and “application,” is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations therefore do not qualify as “significantly more” (see MPEP 2106.05(f)).
As discussed above in “Step 2A – Prong 2”, the recited additional elements of “upload”/ “uploading” simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea; mere post-solution activity in conjunction with an abstract idea). These additional elements, taken individually or in combination, additionally amount to well-understood, routine and conventional activities previously known to the industry, appended to the judicial exception.
Furthermore, the receiving rules and deleting the selected disposable payment element amount to well-understood, routine and conventional activities previously known to the industry, appended to the judicial exception.
The courts have recognized the following computer functions to be well‐understood, routine, and conventional functions when they are claimed in a merely generic manner: receiving, processing, and storing data2, electronic recordkeeping3, and receiving or transmitting data over a network, e.g., using the Internet to gather data4. Uploading is a form of transmitting and storing data.
Thus, the limitations of “uploading” “receive” and “delete” do not qualify as “significantly more” (see MPEP 2106.05(d)). This conclusion is based on a factual determination.
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer, append the abstract idea with insignificant extra solution activity associated with the implementation of the judicial exception, (e.g., mere data gathering, post-solution activity), and appended with well-understood, routine and conventional activities previously known to the industry.
The dependent claims fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e., they are part of the abstract idea identified by the Examiner to which each respective claim is directed).
In conclusion, no additional element, or combination of additional claims elements amount to significantly more than the abstract idea identified above.
For the reasons stated above, Claims 37 and 39-47 as whole do not amount to significantly more than the abstract idea itself.
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.
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.
Claims 37, and 39-44 are rejected under 35 U.S.C. 103 as being unpatentable over Bondesen et al. (US 9,721,268 B2)(“Bondesen”) in view of Cardina et al. (US 2012/0116902 A1)(“Cardina”) and further in view of Hage (US 2014/0195324 A1)(“Hage”).
As to Claim 37, Bondesen teaches system (“systems,” C.4, L.9) for executing payments over a digital network (Network 401)(“processing payments using the at least one payment credential associated with the digital wallet,” C.1, L.57-58) comprising:
a payment manager server (Remote Server 402) comprising a user database (“database” C.30, L.17, “one or more of the systems, devices, or servers may be combined into a single system, device, or server, or be made up of multiple systems, devices, or server.” C.24, L.27-29, “least one database maintained by an entity that issued the account 530” C.27, L.57-58) that includes at least one group of members (“dedicated group of tokens that are associated with a specific merchant” C.11, L.1-11, “multiple shared tokens may be provided to the collaborative group of users 2.” C.18, L.39-40)(“the merchant account may accrue rewards and/or loyalty points, or the like, that are redeemable for monetary value. For example, in such an embodiment, the payments credential may be a rewards card number issued to the user and linked to a rewards account that is maintained by the third party merchant, a gift card that is issued to the user and liked to a rewards account that is maintained by the third party merchant, a rewards account number that is issued to the user and linked to a rewards account that is maintained by the third party merchant” C.28, L.16-26, “authenticating the user’s identity comprises comparing the received authentication credentials to information that is stored in a database and maintained by the entity that issued the payment credential” C.30, L.15-18), a processing circuitry (processing device 452, see Fig.4 and associated text C.24, L.39-45) and a payment element database (Token and Account Database 52, see Fig.1, “It is further understood that one of more of the server, systems, and devices can be combined in other embodiments and still function in the same or similar way…” C.25, L.54-56; thus, the server includes the database 52) that includes one or more disposable (“Single-use tokens may be utilized once, and thereafter disappear, are replaced or are erased, while multi-use tokens may be utilized more than once before they disappear, are replaced, or are erased.” C.5, L.22-25) payment elements (“multiple shared tokens may be provided to the collaborative group of uses 2.” C.18, L.39-40), at least one of the one or more disposable payment elements comprising at least a prepaid card (“a pre-paid account” C.4, L.40) number (“Tokens may be 16-digit numbers (e.g., like credit, debit,” C.5, L.26)” C.5 L.26) [and security code] and having a zero balance (“the account may be a new account, and as such the account may need to be funded in order to enter into transactions using the shared token” C.14, L.61-63);
a payment element generator (tokenization service 50) operably coupled to the payment manager server and configured to issue the one or more disposable payment elements (“may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52” C.7, L.35-57, “multiple shared tokens may be provided to the collaborative group of uses 2.” C.18, L.39-40);
a computing device (payment devices 4) operably coupled to the payment manager server and configured to run a loyalty club (“the merchant account may accrue rewards and/or loyalty points, or the like, that are redeemable for monetary value. For example, in such an embodiment, the payments credential may be a rewards card number issued to the user and linked to a rewards account that is maintained by the third party merchant, a gift card that is issued to the user and liked to a rewards account that is maintained by the third party merchant, a rewards account number that is issued to the user and linked to a rewards account that is maintained by the third party merchant” C.28, L.16-26, “authenticating the user’s identity comprises comparing the received authentication credentials to information that is stored in a database and maintained by the entity that issued the payment credential” C.30, L.15-18) application (“To this extent, the application programming interface may be additionally associated with and/or linked to at least one database and/or remote server that is maintained by the entity responsible for issuing and/or maintaining the account associated with the payment credential” C.30, L.29-34); and
[a loyalty club server operably coupled to the payment manager server and comprising a members database and a rules module;]
wherein the processing circuitry is configured to (“may perform one or more of the steps and/or sub-steps discussed herein...” C.24, L.65-67, “any of the advantages, features, functions, devices, and/or operational aspects of any of the embodiments of the present invention described and/or contemplated herein may be included in any of the other embodiments of the present invention described and/or contemplated herein, and/or vice versa.” C.39, L.36-41);
receive a request (“request a token for the payment device” C.9, L33) to provide a disposable payment element of the one or more disposable payment elements (“stores groups of tokens” C.10, L.10, “may generate (e.g., create, request, or the like) a token … and stores an association between the token and the user account number in a secure token and account database 52” C.7, L.38-43, “multiple shared tokens may be provided to the collaborative group of uses 2.” C.18, L.39-40) with details of a member (“the tokens may include user account information” C.9, L.50-51) from the group of members to perform a transaction from a point of sale (POS) (“user 2 may set up the digital wallet by communicating with the issuing financial institution 40 (e.g., the user’s financial institution) to request a token for the payment device” C.9, L.31-33, “The user 2 may enter into a transaction with the merchant 10 using a payment device 4 ( or a payment instrument through the Internet).” C.9, L.58-60);
allocate a selected disposable payment element of the one or more disposable payment elements to the member (“may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52” C.7, L.35-57, “multiple shared tokens may be provided to the collaborative group of uses 2.” C.18, L.39-40);
upload the selected disposable payment element to the loyalty club application (“the shared token or shared token information may be stored in an application that can be used for in-person transactions at a POS or for e-commerce transactions.” C.14, L.42-44);
send a request to check a credit balance of the member to a loyalty club server (“sending a request, via the application programming interface, to receive the supplemental information related to the payment credential from the at least one database and receiving a response comprising the supplemental information related to the payment credential from the at least one database.” C.33, L.15-20, “receiving, via the application programming interface from the at least one database,…” C.33, L.51-52 “the supplemental information comprises the available balance of the account associated with the payment credential,” C.32, L.17-19, “a rewards card number issued to the user and linked to a rewards account,” C.28, L.19-21, “It is further understood that one of more of the server, systems, and devices can be combined in other embodiments and still function in the same or similar way…” C.25, L.54-56, “embodiments of the present invention may take the form of an entirely business method embodiment, an entirely software embodiment (including firmware, resident software, micro-code, stored procedures in a database, or the like), an entirely hardware embodiment, or an embodiment combining business method, software, and hardware aspects” C.39, L.55-60, “the merchant account may accrue rewards and/or loyalty points, or the like, that are redeemable for monetary value. For example, in such an embodiment, the payments credential may be a rewards card number issued to the user and linked to a rewards account that is maintained by the third party merchant, a gift card that is issued to the user and liked to a rewards account that is maintained by the third party merchant, a rewards account number that is issued to the user and linked to a rewards account that is maintained by the third party merchant” C.28, L.16-26);
receive a set of rules (“the limitations may be placed on the tokens. Any transaction associated with the token may be monitored or stored as described by the present invention herein, which may then determine if the transaction is allowed or denied based on the limitations associated with the token” C.22, L.4-9) applicable to the member (“As such, the institution may be the issuing financial institution 40, the tokenization service 50 institution, and/or the client that sets the limits. In the embodiment in which the client sets and/or stores the limits, the issuing financial institution 40 or the tokenization service 50 institution (e.g., through the digital wallet or another application) may communicate with the client to determine, or otherwise access, the limits stored at the client, and determine if the transaction should be allowed or denied before allowing or denying the transaction.” C.16, L.10-19) [from the rules module];
approve the transaction based on the set of rules and the credit balance (“The issuing financial institution 40 determines if the user 2 has the funds available to enter into the transaction, and if the transaction meets other limits on the user account, and responds with approval or denial of the transaction.” C.8, L.57-61, “If the transaction (e.g., transaction information) fails to meet the limits, the transaction may be denied. Alternatively, if the transaction (e.g., transaction information) meets the limits then transaction may be allowed.” C.16, L.40-43);
[convert at least part of the credit balance to money and] upload the money to the selected disposable payment element (“reload the card with monetary funds” C.32, L.31);
receive a message that the purchase is completed (“The approval runs back through the processing channels until the acquiring financial institution 20 provides approval or denial of the transaction to the merchant 10 and the transaction…is completed,” C.8 L.61-65, “the system may provide the user with an alert that indicates they have just processed a transaction and/or purchased with a merchant” C.32, L.38-40, “It is further understood that one of more of the server, systems, and devices can be combined in other embodiments and still function in the same or similar way…” C.25, L.54-56, “embodiments of the present invention may take the form of an entirely business method embodiment, an entirely software embodiment (including firmware, resident software, micro-code, stored procedures in a database, or the like), an entirely hardware embodiment, or an embodiment combining business method, software, and hardware aspects” C.39, L.55-60);
delete the selected disposable payment element (“After the transaction is completed the token may be deleted, erased, or the like if it is a single-use token” C.10, L.65-66) from the payment element a database (“deleting the at least one single-use electronic token from the accessed digital wallet stored (i) in the at least one database…,” Claim 1, i.e.: Token and Account Database 52, see Fig.1, since “It is further understood that one of more of the server, systems, and devices can be combined in other embodiments and still function in the same or similar way…” C.25, L.54-56, “embodiments of the present invention may take the form of an entirely business method embodiment, an entirely software embodiment (including firmware, resident software, micro-code, stored procedures in a database, or the like), an entirely hardware embodiment, or an embodiment combining business method, software, and hardware aspects” C.39, L.55-60); and
upload a new disposable payment element to the payment element database (“may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52” C.7, L.38-43).
Bondesen does not directly disclose
at least one of the one or more disposable payment elements comprising [a security code];
a loyalty club server operably coupled to the payment manager server and comprising a members database and a rules module;
the request to check the credit balance is to the loyalty club server;
the receive the rules is from the rules module;
[convert at least part of the credit balance to money and] upload the money to the selected disposable payment element.
Cardina teaches at least one or more disposable payment elements comprising a security code (“CVV” [0035]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bondesen by the feature of Cardina, and in particular to include in the at least one of the one or more disposable payment elements of Bondesen, the security code, as taught by Cardina. A person having ordinary skill in the art would have been motivated to combine these features because it would provide an added layer of security to the disposable payment element, and also because it would facilitate the use of the disposable payment element with systems that require the input of the security code.
Hage teaches
a loyalty club server (Loyalty Clearinghouse Server 103) operably coupled to a payment manager server (Credit Card Company 606, see Fig.6) and comprising a members database (Points Database 103B)(“user’s account in the Points Database 103B, [0023], “members have accounts” [0035]) and a rules module (“the conversion rate may be specified by the loyalty program or the loyalty clearinghouse” [0027], “each step or element may have a corresponding computer system or software component” [0044], i.e.: module);
receive a request to check a credit balance to the loyalty club server (“To do so, in a first arrangement, an application on the Mobile Device 602 is accessed, and communicates with Loyalty Clearinghouse Server 608 using the smartphone's data/cell communication link. Using the information accessed from the Loyalty Clearinghouse Server 608, the Mobile Device 602 may display the points available to the customer and/or the conversion value of the points to a currency (such as dollars).” [0034]);
receive rules from the rules module (“Optionally, the application will show the customer the conversion rate of points to a particular currency in addition to the price of a selected item, and current points balance.” [0026]);
upload the money to the selected disposable payment element (“If the user chooses to pay for the purchase with her points, the Loyalty Clearinghouse Server 103 will determine the number of points needed based on the purchase price (which may include shipping, tax, and other charges) and the point-currency conversion rate, deduct those points from the user’s account in the Points Database 103B, generate a temporary credit card number that has a credit of the currency value of the deducted/redeemed points, and fill in the temporary credit card number in the order page (or present the number to the user to enter into the order page).” [0023]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Bondesen/Cardina combination by the features of Hage and in particular to include in the Bondesen/Cardina combination, the loyalty club server operably coupled to the payment manager server and comprising a members database and a rules module, as taught by Hage, to include in the request to check the balance of Bondesen in the Bondesen/Cardina combination, the feature that it is from the loyalty club server, as taught by Hage, to include in the receive rules step of Bondesen in the Bondesen/Cardina combination, that it is from the rules module, as taught by Hage, and to include in the convert step of Bondesen in the Bondesen/Cardina combination, the feature of upload the money to the selected disposable payment element, as taught by Hage.
A person having ordinary skill in the art would have been motivated to combine these features “to provide payment flexibility in a seamless manner” (Hage, [0001]).
As to Claim 39, the Bondesen/Cardina/Hage combination discloses as discussed above. Hage teaches wherein the set of rules comprises an exchange rate of the credit balance of the member of the loyalty club to a currency (“conversion rates of various loyalty program points to a currency is stored in Points Database,” [0021]).
As to Claim 40, the Bondesen/Cardina/Hage combination discloses as discussed above. Bondesen further discloses wherein the processing circuitry is configured to receive a second set of rules applicable to the member (“The financial institution determines if the funds are available in the user account for the transaction and if the transaction information meets other limits by comparing the transaction information with the limits associated with the token, the user account associated with the token, or other limits described herein. If the transaction meets the limits associated with the token or user account, then the issuing financial institution 20 allows the transaction” C.10, L.27-35) from the credit card approval server.
As to Claim 41, the Bondesen/Cardina/Hage combination discloses as discussed above. Cardina teaches wherein the disposable payment element comprising a payment card date of expiration (“expiration date,” [0035]).
As to Claim 42, the Bondesen/Cardina/Hage combination discloses as discussed above. Bondesen further discloses wherein the disposable payment element is configured to do at least one of access, retrieve and maintain the payment card information of the loyalty club member (“may present the user with an option to enable the digital wallet to receive supplemental account information related to a payment credential that is included in the account… select to view a payment credential, in response the system may present the user a message stating ‘click here to view’…” C.28, L.35-47, “the merchant account may accrue rewards and/or loyalty points, or the like, that are redeemable for monetary value. For example, in such an embodiment, the payments credential may be a rewards card number issued to the user and linked to a rewards account that is maintained by the third party merchant…” C.28, L.16-26).
As to Claim 43, the Bondesen/Cardina/Hage combination discloses as discussed above. Bondesen further discloses a credit card approval server (340) (issuing financial institution 40) operably coupled to the payment manager server (“To this extent, the application programming interface may be additionally associated with and/or linked to at least one database and/or remote server that is maintained by the entity responsible for issuing and/or maintaining the account associated with the payment credential” C.30, L.29-25).
As to Claim 44, the Bondesen/Cardina/Hage combination discloses as discussed above.
Bondesen does not directly disclose wherein the processing circuitry is configured to receive a request from the credit card approval server to check member balance.
Hage teaches receive a request from the credit card approval server to check member balance (“The credit card company, in turn, contacts the Loyalty Clearinghouse Server at 716 to determine if the customer has enough points, and if so, deducts the points from the customer’s account and issues a one-time credit card” [0038]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Bondesen/Cardina/Hage combination by the feature of Hage and in particular to include in the processing circuitry of the Bondesen in the Bondesen/Cardina/Hage combination, the feature of receive a request from the credit card approval server to check member balance, as taught by Hage. A person having ordinary skill in the art would have been motivated to combine these features “to provide payment flexibility in a seamless manner” (Hage, [0001]).
Claim 45 is rejected under 35 U.S.C. 103 as being unpatentable over Bondesen in view of Cardina, in view of Hage, and further in view of Mukherjee et al. (US 2012/0072306 A1)(“Mukherjee”).
As to Claim 45, the Bondesen/Cardina/Hage combination discloses as discussed above.
Bondesen does not directly disclose wherein the processing circuitry is configured to transfer an amount of money paid by the payment manager server for a purchase made by the member to the credit card approval server at a predetermined date.
Mukherjee teaches transfer an amount of money paid by the payment manager server for a purchase made by the member to the credit card approval server at a predetermined date (“the collection of the reimbursement amount in block 312 of the method 300 is performed in response to the expiration of a predetermined amount of time. For example, the payment service provider 106 may initiate the collection of the reimbursement amount once a week, once a month, once every several months, etc.” “the payment service provider 106 collects the reimbursement amount from the financial institution” [0052]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Bondesen/Cardina/Hage combination by the feature of Mukherjee, and in particular to include in the processing circuitry configuration of Bondesen in the Bondesen/Cardina/Hage combination, the feature of transfer an amount of money paid by the payment manager server for a purchase made by the member to the credit card approval server at a predetermined date, as taught by Mukherjee.
A person having ordinary skill in the art would have been motivated to combine these features because this would help to ensure proper remuneration to the appropriate party.
Claims 46-47 are rejected under 35 U.S.C. 103 as being unpatentable over Bondesen in view of Cardina, in view of Hage, and further in view of von Mueller et al. (US 2013/0254117 A1)(“Mueller”).
As to Claim 46, the Bondesen/Cardina/Hage combination discloses as discussed above. Bondesen further discloses wherein the POS comprises an at least one of a cashier machine, a physical payment terminal (“As illustrated in FIG. 4, the POT 406 may include a communication device 410, a processing device 412, and a memory device 414. The processing device 412 is operatively coupled to the communication device 410 and the memory device 414. In some embodiments, the processing device 412 may send or receive data from the mobile device 404 and/or the remote server 402 via the communication device 410. Such communication may be performed either over a direct connection and/or over a network 401. As such, the communication device 410 generally comprises a modem, server, or other device for communication with other devices on the network 401” C.25, L.30-41) and a virtual payment terminal.
Bondesen does not directly disclose wherein a content of the payment element is encrypted and the POS is configured to decrypt the content of the payment element.
Mueller teaches wherein a content of the payment element (“The token information can have at least a primary account number of a bank card,” [0043], “token 101 can include a charge card, debit card, credit card, loyalty card, or other token that can be used to identify such items as the customers, their account, and other relevant information” [0087]) is encrypted (“the POS 104 receives the encrypted PAN information from the token and” [0148]) and the POS is configured to decrypt the content of the payment element (“data encrypted in the magstripe reader can be sent to the issuing bank before it is decrypted while in other systems it is decrypted in the POS” [0011], “the data capture device 103 is physically separated, but in communicative contact with, the POS 104, in other environments these items can be in the same housing or in integrated housings” [0111]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Bondesen/Cardina/Hage combination by the feature of Mueller, and in particular, to include in the Bondesen/Cardina/Hage combination, the feature of wherein a content of the payment element is encrypted, as taught by Mueller, because it would help to prevent unauthorized use of the payment element by concealing it from unauthorized users, and to include in the Bondesen/Cardina/Hage combination, the feature of the POS is configured to decrypt the content of the payment element, as taught by Mueller, because this would allow the POS to verify the content.
As to Claim 47, the Bondesen/Cardina/Hage/Mueller combination discloses as discussed above.
Bondesen does not directly disclose wherein the POS is configured to transfer the decrypted content of the payment element to the credit card approval server.
Mueller teaches wherein the POS is configured to transfer the decrypted content of the payment element to the credit card approval server (“As a further example, in one embodiment, transaction processing, network may include one or more processors or clearing houses to clear transactions on behalf of issuing banks and acquiring banks” [0115])(“data encrypted in the magstripe reader can be sent to the issuing bank before it is decrypted while in other systems it is decrypted in the POS” [0011], “the data capture device 103 is physically separated, but in communicative contact with, the POS 104, in other environments these items can be in the same housing or in integrated housings” [0111], see Fig.4).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Bondesen/Cardina/Hage/Mueller combination by the feature of Mueller, and in particular, to include in the Bondesen/Cardina/Hage/Mueller combination, the feature of wherein the POS is configured to transfer the decrypted content of the payment element to the credit card approval server, as taught by Mueller, because this would allow the system to determine approval of the transaction more expeditiously.
Response to Arguments
Applicant’s arguments filed in the December 2025 Remarks have been fully considered but they are not persuasive.
On pages 11-13, Applicant argues he the cited art does not disclose various elements of the claims. The Examiner respectfully disagrees. As outlined in the respective rejection, and duplicated below for convenience,
Bondesen discloses a system (“systems,” C.4, L.9) for executing payments over a digital network (Network 401)(“processing payments using the at least one payment credential associated with the digital wallet,” C.1, L.57-58) comprising:
a payment manager server (Remote Server 402) comprising a user database (“database” C.30, L.17, “one or more of the systems, devices, or servers may be combined into a single system, device, or server, or be made up of multiple systems, devices, or server.” C.24, L.27-29, “least one database maintained by an entity that issued the account 530” C.27, L.57-58) that includes at least one group of members (“dedicated group of tokens that are associated with a specific merchant” C.11, L.1-11, “multiple shared tokens may be provided to the collaborative group of users 2.” C.18, L.39-40)(“the merchant account may accrue rewards and/or loyalty points, or the like, that are redeemable for monetary value. For example, in such an embodiment, the payments credential may be a rewards card number issued to the user and linked to a rewards account that is maintained by the third party merchant, a gift card that is issued to the user and liked to a rewards account that is maintained by the third party merchant, a rewards account number that is issued to the user and linked to a rewards account that is maintained by the third party merchant” C.28, L.16-26, “authenticating the user’s identity comprises comparing the received authentication credentials to information that is stored in a database and maintained by the entity that issued the payment credential” C.30, L.15-18), a processing circuitry (processing device 452, see Fig.4 and associated text C.24, L.39-45) and a payment element database (Token and Account Database 52, see Fig.1, “It is further understood that one of more of the server, systems, and devices can be combined in other embodiments and still function in the same or similar way…” C.25, L.54-56; thus, the server includes the database 52) that includes one or more disposable (“Single-use tokens may be utilized once, and thereafter disappear, are replaced or are erased, while multi-use tokens may be utilized more than once before they disappear, are replaced, or are erased.” C.5, L.22-25) payment elements (“multiple shared tokens may be provided to the collaborative group of uses 2.” C.18, L.39-40), at least one of the one or more disposable payment elements comprising at least a prepaid card (“a pre-paid account” C.4, L.40) number (“Tokens may be 16-digit numbers (e.g., like credit, debit,” C.5, L.26)” C.5 L.26) [and security code] and having a zero balance (“the account may be a new account, and as such the account may need to be funded in order to enter into transactions using the shared token” C.14, L.61-63);
a payment element generator (tokenization service 50) operably coupled to the payment manager server and configured to issue the one or more disposable payment elements (“may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52” C.7, L.35-57, “multiple shared tokens may be provided to the collaborative group of uses 2.” C.18, L.39-40);
a computing device (payment devices 4) operably coupled to the payment manager server and configured to run a loyalty club (“the merchant account may accrue rewards and/or loyalty points, or the like, that are redeemable for monetary value. For example, in such an embodiment, the payments credential may be a rewards card number issued to the user and linked to a rewards account that is maintained by the third party merchant, a gift card that is issued to the user and liked to a rewards account that is maintained by the third party merchant, a rewards account number that is issued to the user and linked to a rewards account that is maintained by the third party merchant” C.28, L.16-26, “authenticating the user’s identity comprises comparing the received authentication credentials to information that is stored in a database and maintained by the entity that issued the payment credential” C.30, L.15-18) application (“To this extent, the application programming interface may be additionally associated with and/or linked to at least one database and/or remote server that is maintained by the entity responsible for issuing and/or maintaining the account associated with the payment credential” C.30, L.29-34); and
[a loyalty club server operably coupled to the payment manager server and comprising a members database and a rules module;]
wherein the processing circuitry is configured to (“may perform one or more of the steps and/or sub-steps discussed herein...” C.24, L.65-67, “any of the advantages, features, functions, devices, and/or operational aspects of any of the embodiments of the present invention described and/or contemplated herein may be included in any of the other embodiments of the present invention described and/or contemplated herein, and/or vice versa.” C.39, L.36-41);
receive a request (“request a token for the payment device” C.9, L33) to provide a disposable payment element of the one or more disposable payment elements (“stores groups of tokens” C.10, L.10, “may generate (e.g., create, request, or the like) a token … and stores an association between the token and the user account number in a secure token and account database 52” C.7, L.38-43, “multiple shared tokens may be provided to the collaborative group of uses 2.” C.18, L.39-40) with details of a member (“the tokens may include user account information” C.9, L.50-51) from the group of members to perform a transaction from a point of sale (POS) (“user 2 may set up the digital wallet by communicating with the issuing financial institution 40 (e.g., the user’s financial institution) to request a token for the payment device” C.9, L.31-33, “The user 2 may enter into a transaction with the merchant 10 using a payment device 4 ( or a payment instrument through the Internet).” C.9, L.58-60);
allocate a selected disposable payment element of the one or more disposable payment elements to the member (“may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52” C.7, L.35-57, “multiple shared tokens may be provided to the collaborative group of uses 2.” C.18, L.39-40);
upload the selected disposable payment element to the loyalty club application (“the shared token or shared token information may be stored in an application that can be used for in-person transactions at a POS or for e-commerce transactions.” C.14, L.42-44);
send a request to check a credit balance of the member to a loyalty club server (“sending a request, via the application programming interface, to receive the supplemental information related to the payment credential from the at least one database and receiving a response comprising the supplemental information related to the payment credential from the at least one database.” C.33, L.15-20, “receiving, via the application programming interface from the at least one database,…” C.33, L.51-52 “the supplemental information comprises the available balance of the account associated with the payment credential,” C.32, L.17-19, “a rewards card number issued to the user and linked to a rewards account,” C.28, L.19-21, “It is further understood that one of more of the server, systems, and devices can be combined in other embodiments and still function in the same or similar way…” C.25, L.54-56, “embodiments of the present invention may take the form of an entirely business method embodiment, an entirely software embodiment (including firmware, resident software, micro-code, stored procedures in a database, or the like), an entirely hardware embodiment, or an embodiment combining business method, software, and hardware aspects” C.39, L.55-60, “the merchant account may accrue rewards and/or loyalty points, or the like, that are redeemable for monetary value. For example, in such an embodiment, the payments credential may be a rewards card number issued to the user and linked to a rewards account that is maintained by the third party merchant, a gift card that is issued to the user and liked to a rewards account that is maintained by the third party merchant, a rewards account number that is issued to the user and linked to a rewards account that is maintained by the third party merchant” C.28, L.16-26);
receive a set of rules (“the limitations may be placed on the tokens. Any transaction associated with the token may be monitored or stored as described by the present invention herein, which may then determine if the transaction is allowed or denied based on the limitations associated with the token” C.22, L.4-9) applicable to the member (“As such, the institution may be the issuing financial institution 40, the tokenization service 50 institution, and/or the client that sets the limits. In the embodiment in which the client sets and/or stores the limits, the issuing financial institution 40 or the tokenization service 50 institution (e.g., through the digital wallet or another application) may communicate with the client to determine, or otherwise access, the limits stored at the client, and determine if the transaction should be allowed or denied before allowing or denying the transaction.” C.16, L.10-19) [from the rules module];
approve the transaction based on the set of rules and the credit balance (“The issuing financial institution 40 determines if the user 2 has the funds available to enter into the transaction, and if the transaction meets other limits on the user account, and responds with approval or denial of the transaction.” C.8, L.57-61, “If the transaction (e.g., transaction information) fails to meet the limits, the transaction may be denied. Alternatively, if the transaction (e.g., transaction information) meets the limits then transaction may be allowed.” C.16, L.40-43);
[convert at least part of the credit balance to money and] upload the money to the selected disposable payment element (“reload the card with monetary funds” C.32, L.31);
receive a message that the purchase is completed (“The approval runs back through the processing channels until the acquiring financial institution 20 provides approval or denial of the transaction to the merchant 10 and the transaction…is completed,” C.8 L.61-65, “the system may provide the user with an alert that indicates they have just processed a transaction and/or purchased with a merchant” C.32, L.38-40, “It is further understood that one of more of the server, systems, and devices can be combined in other embodiments and still function in the same or similar way…” C.25, L.54-56, “embodiments of the present invention may take the form of an entirely business method embodiment, an entirely software embodiment (including firmware, resident software, micro-code, stored procedures in a database, or the like), an entirely hardware embodiment, or an embodiment combining business method, software, and hardware aspects” C.39, L.55-60);
delete the selected disposable payment element (“After the transaction is completed the token may be deleted, erased, or the like if it is a single-use token” C.10, L.65-66) from the payment element a database (“deleting the at least one single-use electronic token from the accessed digital wallet stored (i) in the at least one database…,” Claim 1, i.e.: Token and Account Database 52, see Fig.1, since “It is further understood that one of more of the server, systems, and devices can be combined in other embodiments and still function in the same or similar way…” C.25, L.54-56, “embodiments of the present invention may take the form of an entirely business method embodiment, an entirely software embodiment (including firmware, resident software, micro-code, stored procedures in a database, or the like), an entirely hardware embodiment, or an embodiment combining business method, software, and hardware aspects” C.39, L.55-60); and
upload a new disposable payment element to the payment element database (“may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52” C.7, L.38-43).
Bondesen does not directly disclose
at least one of the one or more disposable payment elements comprising [a security code];
a loyalty club server operably coupled to the payment manager server and comprising a members database and a rules module;
the request to check the credit balance is to the loyalty club server;
the receive the rules is from the rules module;
[convert at least part of the credit balance to money and] upload the money to the selected disposable payment element.
Cardina teaches at least one or more disposable payment elements comprising a security code (“CVV” [0035]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bondesen by the feature of Cardina, and in particular to include in the at least one of the one or more disposable payment elements of Bondesen, the security code, as taught by Cardina. A person having ordinary skill in the art would have been motivated to combine these features because it would provide an added layer of security to the disposable payment element, and also because it would facilitate the use of the disposable payment element with systems that require the input of the security code.
Hage teaches
a loyalty club server (Loyalty Clearinghouse Server 103) operably coupled to a payment manager server (Credit Card Company 606, see Fig.6) and comprising a members database (Points Database 103B)(“user’s account in the Points Database 103B, [0023], “members have accounts” [0035]) and a rules module (“the conversion rate may be specified by the loyalty program or the loyalty clearinghouse” [0027], “each step or element may have a corresponding computer system or software component” [0044], i.e.: module);
receive a request to check a credit balance to the loyalty club server (“To do so, in a first arrangement, an application on the Mobile Device 602 is accessed, and communicates with Loyalty Clearinghouse Server 608 using the smartphone's data/cell communication link. Using the information accessed from the Loyalty Clearinghouse Server 608, the Mobile Device 602 may display the points available to the customer and/or the conversion value of the points to a currency (such as dollars).” [0034]);
receive rules from the rules module (“Optionally, the application will show the customer the conversion rate of points to a particular currency in addition to the price of a selected item, and current points balance.” [0026]);
upload the money to the selected disposable payment element (“If the user chooses to pay for the purchase with her points, the Loyalty Clearinghouse Server 103 will determine the number of points needed based on the purchase price (which may include shipping, tax, and other charges) and the point-currency conversion rate, deduct those points from the user’s account in the Points Database 103B, generate a temporary credit card number that has a credit of the currency value of the deducted/redeemed points, and fill in the temporary credit card number in the order page (or present the number to the user to enter into the order page).” [0023]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Bondesen/Cardina combination by the features of Hage and in particular to include in the Bondesen/Cardina combination, the loyalty club server operably coupled to the payment manager server and comprising a members database and a rules module, as taught by Hage, to include in the request to check the balance of Bondesen in the Bondesen/Cardina combination, the feature that it is from the loyalty club server, as taught by Hage, to include in the receive rules step of Bondesen in the Bondesen/Cardina combination, that it is from the rules module, as taught by Hage, and to include in the convert step of Bondesen in the Bondesen/Cardina combination, the feature of upload the money to the selected disposable payment element, as taught by Hage.
A person having ordinary skill in the art would have been motivated to combine these features “to provide payment flexibility in a seamless manner” (Hage, [0001]).
Thus, the argument is not persuasive.
Conclusion
Applicant’s amendment filed on December 9, 2025 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 MONICA A MANDEL whose telephone number is (571)270-7046. The examiner can normally be reached Monday and Thursday 10:00 AM-6:00 PM.
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, Ilana Spar can be reached at (571) 270-7537. 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.
/M.A.M/Examiner, Art Unit 3622
/ILANA L SPAR/Supervisory Patent Examiner, Art Unit 3622
1 See Subject Matter Eligibility Analysis for Products and Processes in MPEP §2106 III.
2 See Alice Corp., 134 S. Ct. at 2360. But see Example 4 (AI-4: global positioning system).
3 See Alice Corp., 134 S. Ct. at 2359 (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716 (updating an activity log).
4 See Ultramercial, 772 F.3d at 716-17; buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014); Cyberfone Systems, LLC v. CNN Interactive Group, Inc., 558 Fed. Appx. 988, 993 (Fed. Cir. 2014). But see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result--a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)).