DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the amendment filed on 05/20/2026.
Claims 1, 5, 11, 13, and 15 have been amended and are hereby entered.
Claims 1-20 are currently pending and have been examined.
Response to Arguments
The 101 software per se rejection of claims 1-7 are hereby withdrawn due to applicant’s amendments.
Applicant's arguments filed 05/26/2026 with respect to claims 1-20 rejected under 35 USC 103 and 35 USC 101 for being directed towards an abstract idea have been fully considered but they are not persuasive.
With respect to 101:
Applicant argues #1:
The Claims Address a Computer-Centric Problem Using a Specific Technical Solution, Analogous to DDR Holdings.
The claims are directed to a problem rooted in computer technology and arising in the context of mobile wallet architecture: how to enable a first mobile wallet application on a first computing device to authorize a second mobile wallet application on a second computing device to use a wallet element of the first user, in a manner that preserves data security, embeds user-defined usage parameters within the transmitted data structure itself, and permits the recipient device to evaluate compliance autonomously. This problem does not exist outside the realm of networked mobile wallet applications and encrypted device-to-device data transmission. As in DDR Holdings, LLC v. Hotels.com, L.P, 773 F.3d 1245 (Fed. Cir. 2014), the claimed solution is "necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks." Id. at 1257. The claimed architecture in which a proxy element containing both transaction information and usage parameters is created by a first mobile wallet application, transmitted as an encrypted message to a second mobile wallet application on a different computing device, decrypted at the recipient device, and evaluated against the embedded usage parameters at the recipient device before transaction information is provided for use is a specific technical implementation that does not have a meaningful pre-computer analog. The claims do not recite a generic commercial interaction performed on a generic computer; they recite a specific technical architecture that solves a specific technical problem unique to mobile wallet applications operating across distinct computing devices.
Examiners response:
The Examiner respectfully disagrees, the claims here are not like those the Court found patent eligible in DDR, in which the inventive concept was in the modification of conventional mechanics behind website display to produce a dual-source integrated hybrid display because applicant’s claims here do not address problems unique to the Internet or require an arguably inventive device or technique for displaying information. Here, the focus of the claims is not an inventive concept with wallet-to-wallet communications or encryption, rather the focus of the claims is direct towards abstract concepts for creating a proxy element with usage restrictions for another person to use. The wallets themselves are part of the technical environment in which the idea is being limited and being used to store, send and receive the tokens. MPEP 2106.05(d) provides the sending and receiving data over the internet, as well as electronic recording are WURC functions of computers, (see particularly Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log), receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);), the wallets are merely being used a tool to perform these functions and are generically claimed, such that’s its considered a generic computer component and part of the environment in which the idea is being limited to. Mere instructions to apply the judicial exception using generic computer components and limiting the judicial exception to a particular environment are not indicative of a practical application (see MPEP 20106.05(f) and MPEP 20106.05(h)).
Applicant argues #2:
The Claims Recite Specific Rules Implementing a Technical Improvement, Analogous to McRO.
The Federal Circuit in McRO, Inc. v. Bandai Namco Games America Inc., 837 F.3d 1299 (Fed. Cir. 2016), held that claims reciting specific rules that produce a technological improvement over prior practice are patent-eligible, even when the underlying field involves activities that could be characterized as conventional. Here, the claims recite specific rules governing the creation, transmission, and evaluation of the proxy element. The first mobile wallet application creates a proxy element including specified usage parameters and sends it as an encrypted message; the second mobile wallet application decrypts the message, determines whether a transaction complies with the embedded usage parameters, and responsive to that compliance determination provides the transaction information for use in the transaction. The dependent claims add further specific rules, including packetization of the proxy element into multiple transaction units encrypted with different keys (claims 6, 7, 13, 14, 20) and digital signature verification of the proxy element (claims 5, 12, 19). These specific rules collectively implement a device-level proxy authorization architecture that improves over prior server-mediated approaches by enabling autonomous compliance evaluation at the recipient device. As in McRO, the claimed rules are not directed to an abstract idea but to a specific technical improvement in how computing devices interact to perform a particular function.
Examiners response:
The Examiner respectfully disagrees, the claims in McRO were held patent eligible because the claims were directed at specific rules that resulted in an improvement to the technology of computer generated lip synchronization. The McRO court indicated that it was the incorporation of the particular claimed rules in computer animation that "improved [the] existing technological process." The claims at issue in McRO described a specific way (use of particular rules to set morph weights and transitions through phonemes) to solve the problem of producing accurate and realistic lip synchronization and facial expressions in animated characters, allowing the computer to perform a function not previously performable by a computer. In the instant application, the examiner fails to see where the technological improvement is, the limitations are directed towards steps performed on a computer via the wallet, the functioning of the additional elements or technological processes themselves and as whole are not improved. Furthermore, the patent claims here are not directed to a specific implementation to a solution to a problem in the software arts of improving computer animation through the use of specific rules, therefore McRO has no applicability. Additionally, the use first and second keys for packetizing and sending the proxy elements and subsequently decrypting them are further describing abstract concepts being applied with generic computer components, See, e.g., RecogniCorp, LLC v. Nintendo Co., 855 F.3d 1322, 1327, 122 USPQ2d 1377 (Fed. Cir. 2017) ("Adding one abstract idea (math) to another abstract idea (encoding and decoding) does not render the claim non-abstract");. See BASCOM Glob. Internet Servs., Inc. v. AT&T Mobility LLC, 827 F.3d 1341, 1348 (Fed. Cir. 2016) (performing an abstract idea on an Internet computer network and generic computer is still abstract); see also Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 (Fed. Cir. 2014) ( finding the use of the Internet was not sufficient to save otherwise abstract claims from ineligibility under § 101 where access to copyrighted media over the Internet was controlled in exchange for users viewing advertisements); Bridge & Post, 778 F. App'x at 891 (not all claims that purport to address Internet-centric challenges are eligible such as those that perform business practices known from the pre-internet world).
Applicant argues #3:
The Recited Computer Components Are Not Merely Generic Implementations.
The Examiner's Step 2B analysis treats the claimed elements as generic computer components performing routine functions of receiving, transmitting, and storing data. However, the claims are not directed to merely receiving and transmitting generic data. The claims recite a specific architecture in which two distinct mobile wallet applications residing on separate computing devices interact through encrypted messages containing a specific data structure (the proxy element), with the recipient device's mobile wallet application performing a specific compliance evaluation function as a precondition to providing transaction information for use. This is the type of specific technical arrangement that the Federal Circuit has repeatedly held to be patent-eligible. For the foregoing reasons, the claims are directed to a specific technical solution to a computer- centric problem, recite specific rules producing a technological improvement, and amount to significantly more than the alleged abstract idea. Applicant respectfully requests that the rejection of claims 1-20 under 35 U.S.C. § 101 be withdrawn.
Examiners response:
The Examiner respectfully disagrees, for the same reasons as stated above, the claims fail to address any technical problem in the realm of the computers, and this analogous to a parent creating a restricted account for a child, or a giving a person voucher for a certain amount of money at a particular store, with respect to the wallet creating a proxy of the payment account for a second wallet. As MPEP 2106.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);
With respect to 103:
Applicant's arguments filed 05/20/2026 have been fully considered but they are not persuasive. With respect to applicant’s arguments that Salama and Ortiz fail to render the independent claims obvious, the Examiner respectfully disagrees. Applicant argues the claims require the mobile device to generate the token, which differs from the server of Salama, however by mobile device requesting a token to be generated, one having ordinary skill in the art could interpret that the token is being generated by mobile device/wallet via the server. Additionally, under KSR rational, since the claimed invention is merely a combination of old elements (generating a token and wallet/mobile device), and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further, Ortiz teaches a wallet being used to generate a token, see [0217], and [0283-0288] for example. With respect to the TSM’s of Ortiz, this is stored in the memory of the mobile device along with the applets as disclosed [0215], which the wallet uses to generate a token [0359]. With respect to the tokens including the restrictions, Salama teaches this feature in col. 26 line 45-50, col. 28 lines 61-67, In certain aspects, system 140 execute software instructions that extract information identifying the delegation period and the specified conditions from the received delegation request, and that process the delegated financial product information, the delegation period information, and the condition information to generate a conditional mobile wallet token for user 112 (e.g., in step 610)… System 140 may, for example, process the provided information and transmit, to client device 106, a mobile wallet token that includes information associated with the delegated financial product, and additional information identifying the one or more specified conditions. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the Examiner provided proper teaching suggested motivation, wherein Salama does not expressly disclose allowing users to transfer token person-to-person (mobile device-to-mobile device), and Ortiz’s provides this capability via Bluetooth as discloses [0177], which further allows for users to transfer tokens between devices.
For these reasons, applicant’s arguments are not persuasive.
Claim Objections
Claim 1 objected to because of the following informalities: Claim 1 contains a typo (“yb”) in the limitation “a second memory, the second memory storing instructions, which when executed yb the second hardware processor”. 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 an abstract idea without significantly more, and fails step 2 of the analysis because the focus of the claims is not on the devices themselves or a practical application but rather directed towards an abstract idea, the analysis is provided below.
Step 1 (Statutory Categories) – As discussed above, claims 1-7 fail step 1 of the test. Claims 8-20, however pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a method and non-transitory computer-readable medium.
Step 2A – Prong One (Do the claims recite an abstract idea?) - The idea is recited in the claims, in part, by:
creating and securely transmitting a proxy element comprising:
receiving user input defining usage parameters of the proxy element;
creating the proxy element, the proxy element including at least one of the usage parameters; and
sending the proxy element including the usage parameters to a recipient by sending an encrypted message;
receiving the encrypted message;
decrypting the encrypted message to obtain the proxy element, the proxy element including transaction information and usage parameters;
receiving user input indicating a transaction;
determining that the transaction complies with the usage parameters; and
responsive to determining that the transaction complies with the usage parameters, providing the transaction information of the proxy element for use in the transaction.
The steps recited above under Step 2A Prong One of the analysis under the broadest reasonable interpretation covers commercial or legal interactions (including sales activities or behaviors) for allowing a user to share a payment proxy to another user for use in a transaction but for the recitation of generic computer components. That is other than reciting a network interface, a hardware processor of a first computing device, a mobile wallet application, a graphical user interface for the wallet application, a recipient mobile wallet application on a second computing device, a hardware processor of a second computing device, and a second instance of the mobile wallet application nothing in the claim elements are directed towards anything other than commercial or legal interactions. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Accordingly, the claims recite an abstract idea.
Step 2A – Prong Two (Does the claim recite additional elements that integrate the judicial exception into a practical application?) - This judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of a network interface, a hardware processor of a first computing device, a mobile wallet application, a graphical user interface for the wallet application, a recipient mobile wallet application on a second computing device, a hardware processor of a second computing device, and a second instance of the mobile wallet application. The network interface, hardware processor of the first computing device, mobile wallet application, graphical user interface for the wallet application(s), recipient mobile wallet application on a second computing device, hardware processor of the second computing device, and second instance of the mobile wallet application are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment of mobile computers. Mere instructions to apply the judicial exception using generic computer components and limiting the judicial exception to a particular environment are not indicative of a practical application (see MPEP 20106.05(f) and MPEP 20106.05(h)). As MPEP 2106.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or commercial or legal interaction) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);. Accordingly, these additional elements 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 towards an abstract idea.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, with respect to integration of the abstract idea into a practical application, using the additional elements of network interface, hardware processor of the first computing device, mobile wallet application, graphical user interface for the wallet application(s), recipient mobile wallet application on a second computing device, hardware processor of the second computing device, and second instance of the mobile wallet application to perform the steps recited in Step 2A Prong One of the analysis amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment. Mere instructions to apply an exception using generic computer components and limiting the judicial exception to a particular environment does not provide an inventive concept. The additional elements have been considered separately, and as an ordered combination, and do not add significantly more (also known as an “inventive concept”) to the judicial exception. Further, MPEP 2106.05(d)(ii) provides that receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 224-26, 110 USPQ2d 1984-1985 (2014) (see also creating and maintaining "shadow accounts", "create electronic records, track multiple transactions, and issue simultaneous instructions" (, Alice Corp. Pty. Ltd. v. CLS Bank Int'l 573 U.S. at 224-26, 110 USPQ2d at 1984-85);, and Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;, are well-understood routine and conventional, similar to the instant application claims which recites and sending and receiving data over network, and storing and retrieving information from the mobile devices and their respective wallets for performing the commercial and legal interactions of sharing a payment proxy to another user for use in a transaction. Further, the displaying and GUI steps fall to transform the claims into patent eligible material, as this is part of the field of use and technical environment in which the abstract idea is being implement and does not result in an improvement to additional elements (see MPEP 2106.05(h) Electric Power Group court decision). The claims are not patent eligible.
The dependent claims have been given the full analysis including analyzing the additional limitations both individually and in combination as a whole. For instance, claims 2-7 are all steps that fall within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas, similar to as discussed above, generally linking the use of the judicial exemption to a particular technical computing environment and further describing abstract concepts but for the recitation of generic computer components. The Dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 for the same reasoning as above and the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional limitations of the dependent claims when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-4, 8-11, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Salama, et al (US Patent 10,510,072 B2), “Salama” in view of Ortiz, et al. (US Patent Application Publication 20160019536), “Ortiz”.
As per claim 1, Salama discloses:
A system for creating and securely transmitting, over a network interface, a proxy element, the system comprising: col. 1 lines 50-67
a first computing device comprising: col. 3 lines 42-63
a first hardware processor; col. 3 lines 42-63
a memory, the memory storing instructions, which when executed by the first hardware processor, cause the first hardware processor to perform first operations comprising: col. 4 lines 3-13
executing a mobile wallet application to perform operations comprising: col. 2 lines 7-12, In some instances, the disclosed embodiments include a computing-implemented method that receives, using at least one processor and from a device of a first user, a request to delegate, to a second user, a financial product included within a first mobile wallet administered by a first application program executable by the first user device
providing, as part of the mobile wallet application, a graphical user interface (GUI); col. 27 lines 11-20, In certain aspects, user 110 initiate an execution of a mobile wallet application at client device 104, which may present visual indicators representative of financial products loaded into the first mobile wallet and available for use in purchase transactions (e.g., indicators 502 and 522 within interface 500 of FIG. 5). User 110 may, for example, tap, click on, or otherwise select a displayed indicator associated with a corresponding financial product to request a delegation of the corresponding financial product (e.g., a “delegated financial product”) to an additional user (e.g., user 112).
receiving user input through the GUI defining usage parameters of the proxy element through a user interface associated with the mobile wallet application; col. 27 lines 10-26, User 110 may, for example, tap, click on, or otherwise select a displayed indicator associated with a corresponding financial product to request a delegation of the corresponding financial product (e.g., a “delegated financial product”) to an additional user (e.g., user 112). In some aspects, user 110 may input into client device 104 information identifying user 112 (e.g., an email address, a mobile telephone number, and/or a user name or identifier associated with user 112), and further, may specify one or more conditions under which user 112 may use the delegated financial product.
creating the proxy element, the proxy element including at least one of the usage parameters; and col. 26 line 45-50, col. 28 lines 61-67, In certain aspects, system 140 execute software instructions that extract information identifying the delegation period and the specified conditions from the received delegation request, and that process the delegated financial product information, the delegation period information, and the condition information to generate a conditional mobile wallet token for user 112 (e.g., in step 610)… System 140 may, for example, process the provided information and transmit, to client device 106, a mobile wallet token that includes information associated with the delegated financial product, and additional information identifying the one or more specified conditions.
the second computing device, comprising: col. 3 lines 42-63
a second hardware processor; col. 3 lines 42-63
a second memory, the second memory storing instructions, which when executed by the second hardware processor, cause the second hardware processor to perform second operations comprising: col. 4 lines 3-13
executing a second instance of the mobile wallet application to perform operations comprising: col. 4 lines 3-8, col. 29 lines 15-21 Client devices 104 and 106 may include known computing device components. For instance, client devices 104 and 106 may include one or more tangible, non-transitory memories that store data and/or software instructions, and one or more processors configured to execute software instructions… System 140 may be configured to transmit the conditional mobile wallet token to client device 106 using one or more of the processes outlined above (e.g., in step 612), and a mobile wallet application executed on client device 106 may be configured to decrypt, unpack, and load the delegated financial product into a mobile wallet of user 112 maintained at client device 106.
receiving the encrypted message; col. 29, lines 1-21, see fig. 1 showing the network, in step 610, system 140 may format the delegated financial product information in accordance with one or more requirements of a corresponding mobile wallet application provided by system 140, and may encrypt the formatted information using a public key value specific to user 112 and to client device 106. As described above, system 140 may be configured to encrypt the formatted information using a previously generated public key…System 140 may be configured to transmit the conditional mobile wallet token to client device 106 using one or more of the processes outlined above (e.g., in step 612), and a mobile wallet application executed on client device 106 may be configured to decrypt, unpack, and load the delegated financial product into a mobile wallet of user 112 maintained at client device 106.
decrypting the encrypted message to obtain the proxy element, the proxy element including transaction information and usage parameters; col. 26 line 45-50, col. 28 lines 61-67, col. 29 lines 15-21 System 140 may be configured to transmit the conditional mobile wallet token to client device 106 using one or more of the processes outlined above (e.g., in step 612), and a mobile wallet application executed on client device 106 may be configured to decrypt, unpack, and load the delegated financial product into a mobile wallet of user 112 maintained at client device 106… System 140 may, for example, process the provided information and transmit, to client device 106, a mobile wallet token that includes information associated with the delegated financial product, and additional information identifying the one or more specified conditions.
determining that the transaction complies with the usage parameters; and col. 30 lines 34-42 In some embodiments, system 140 may execute software instructions that determine whether the user 110's delegation of the financial product remains valid (e.g., in step 618). In certain aspects, system 140 may determine whether a current time falls within the boundaries of the specified temporal period, and additionally or alternatively, whether, based on the conditions specified by user 110, the purchase transaction renders invalid the delegation of the financial instrument (e.g., based on the received purchase information).
responsive to determining that the transaction complies with the usage parameters, providing the transaction information of the proxy element for use in the transaction. Col. 26 lines 4-19, fig. 5, col. 27 lines 11-26, In certain embodiments, upon a successful subsequent authentication, user 110 may, though the mobile wallet application executed by client device 104, select one of the loaded financial products for use in a purchase transaction involving one or more participating electronic or physical retailers. Further, and as described above, system 140 may be configured to monitor account, profile, and/or transaction data associated with user 110, identify additional financial products that eligible for inclusion in user 110's mobile product, and further, generate a updated wallet mobile token includes information associated with the additional financial products. In some instances, upon the successful subsequent login, system 14 may be configured to provide the updated mobile wallet token to client device 104, which will decrypt, unpack, and load the additional financial product information into user 110's mobile wallet… In certain aspects, user 110 initiate an execution of a mobile wallet application at client device 104, which may present visual indicators representative of financial products loaded into the first mobile wallet and available for use in purchase transactions (e.g., indicators 502 and 522 within interface 500 of FIG. 5).
With respect to the following limitation, Salama discloses the system 140 sending the encrypted token including the usage parameters to a recipient wallet (col. 26 line 45-50, col. 28 lines 61-67, col. 29 lines 15-21), however does not expressly disclose this as performed by the wallet, Ortiz, however discloses the following as performed by wallet:
sending the proxy element including the usage parameters over a telecommunications network to a recipient mobile wallet application on a second computing device by sending an encrypted message to the second computing device; [0085], [0296], [0321-0323], Abstract In some embodiments, a first user may request that a second user's mobile device 102, 202 be provisioned with a token and/or other data elements associated with the first user's financial account. For example, a first user can enable a second user to make electronic payment in a transaction using the first user's account, e.g., by exchanging the token provision to such second user's mobile device 102, 202, using, for example NFC and/or other “person-to-person” (“P2P”) data exchange techniques in conjunction with secure data features disclosed herein. In such cases, the first user may be able to indicate a transaction limit on the provisioned token or to incorporate any other transaction constraints as described herein… The Root TSM can load a secure element applet module, or package, adapted to cooperate with the virtual wallet application (e.g., VMPA); the package including a plurality (e.g., 4 or more) subordinate (e.g., “shell”) applets 118, 220 and execute installation commands which register each AID w/ each applet within the SE package (applets: shell for MC, Visa, Debit, Controller—manage caching of tokens that comes into the SE), and put a secure element into a pre-personalization state, and swaps an applicable Telco key with the FI (“RBC”) key to enable secure communications;
Additionally, Salama is silent on the following, Ortiz, however discloses:
receiving user input from the second computing device indicating a transaction; [0030] For example, the user can input such an identifier and thereby cause the device, using at least the purchaser-defined identifier, to initiate or otherwise access or execute one of a plurality of transaction authorization data sets, using for example one of a plurality of virtual wallet applications; and, using at least the accessed transaction authorization data set, generate a transaction request data set, the transaction request data set comprising at least two of: an identifier associated with at least one authorized user of at least one transaction payment account, an identifier associated with the transaction communication device; and an identifier associated with the at least one transaction payment account; and to route the generated transaction data request to a transaction adjudication server, using the wireless communication system.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Salama with the ability to transfer tokens using person to person transfer functions as taught by Ortiz, doing so would further users to transfer tokens from mobile device to mobile device over Bluetooth [0177].
As per claim 2, Salama discloses:
wherein the graphical user interface (GUI) further comprises a selection tool to choose between different types of proxy elements including payment and non-payment elements. See fig. 5, col. 22 line 56-67, FIG. 5 illustrates an exemplary interface 500 for a mobile wallet application, in accordance with disclosed embodiments. In one embodiment, and as described above, client device 104 may be configured to decrypt and unpack a received mobile wallet token, further, to display within interface 500 indicators (e.g., indicators 502, 522, and 542) corresponding to financial products included within the received mobile wallet token… In some embodiments, and as described above, the received mobile wallet token may include at least a threshold amount of information identifying a particular financial product (e.g., a credit card, a debit card, and/or a rewards or loyalty card).
As per claim 3, Salama discloses:
wherein the usage parameters comprises a spending limit and wherein determining that the transaction complies with the usage parameters comprises determining that the transaction does not exceed the spending limit. Col. 27 lines 38-50, Abstract, User 110 may also input information into client device 104 that specifies one or more conditions limiting purchase transactions involving the delegated financial product. For example, user 110 may specify a maximum amount of any single purchase and/or a maximum amount of purchases during a particular time period (e.g., hourly, daily, etc.). In some instances, the conditions may specify not only maximum transaction amounts, but may also limit the frequency at which user 112 may initiate purchase transactions using the delegated financial instrument. By way of example, user 110 may specify, through client device 104, conditions that limit user 112 to a specified number of daily transactions (e.g., three) for maximum cumulative amount of $100… For example, the disclosed embodiments may receive, from a first user, a request to delegate a financial product to a second user to complete purchase transactions. In response to the received request, the disclosed embodiments may identify one or more temporal or financial conditions on the delegation, and may generate a corresponding mobile wallet token for transmission to a second user device.
As per claim 4, Salama discloses:
wherein the usage parameters further include a temporal limit defining a validity period for the proxy element, and wherein the second instructions comprise operations comprising invalidating the proxy element upon expiration of the temporal limit. col. 30 lines 34-52, col. 31 lines 1-12 and 50-67, In re Japikse Further, as user 110 may be unaware of user 112's location or of the cost of the promised products, user 110 may specify, through client device 104, a temporal period of twelve hours and termination conditions that enable user 112 to make a single purchase of food or beverages having a value of less than $25.00... If, however, system 140 finds the user 110's delegation of the financial instrument invalid (e.g., step 618; NO), system 140 may execute software instructions that terminate user 110's delegation of the financial instrument to user 112 (e.g., in step 620). By way of example, in finding the delegated financial product invalid in step 618, system 140 may determine that the delegation period has expired, and additionally or alternatively, that the purchase transaction (e.g., Identified in the purchase information received in step 614) violates one or more of the termination conditions established by user 110… In some embodiments, system 140 may execute software instructions that determine whether the user 110's delegation of the financial product remains valid (e.g., in step 618). In certain aspects, system 140 may determine whether a current time falls within the boundaries of the specified temporal period, and additionally or alternatively, whether, based on the conditions specified by user 110, the purchase transaction renders invalid the delegation of the financial instrument (e.g., based on the received purchase information).
As per claims 8-11, claims 8-11 recite substantially similar limitations to those found in claims 1-4, respectively. Therefor claims 8-12 are rejected under the same art and rationale as claims 1-4. Furthermore, Salama discloses a method (see Abstract).
As per claims 15-18, claims 15-18 recite substantially similar limitations to those found in claims 1-4, respectively. Therefor claims15-18 are rejected under the same art and rationale as claims 1-4. Furthermore, Salama discloses a non-transitory computer-readable medium (Col. 2 lines 30-36).
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Salama, et al. (US Patent 10,510,072 B2), “Salama” in view of Ortiz, et al. (US Patent Application Publication 20160019536), “Ortiz” in view of Campos, et al. (US Patent Application Publication 20140344149), “Campos”.
As per claim 5, Salama does not expressly disclose the following, Campos, however discloses:
wherein the mobile wallet application on the first computing device signs the proxy element with a digital signature before sending it to the second computing device, and the mobile wallet application on the second computing device verifies an authenticity of the proxy element by validating the digital signature included in the encrypted message. [0039] For example, an electronic wallet stored in and/or accessed via a phone may include an authentication token, or the phone itself may contain hardware and/or unique electronic data (e.g., authentication data such as serial number, MAC address, SIM card, digital signature, electronic key, user ID, phone number, passcode, etc.) that serves as the authentication token. Such a phone may use near field communication to communicate data associated with the authentication token with a point of sale device for authentication and transaction purposes. For example, the phone may be passed near the point of sale device and transfer user and/or wallet information and authentication information to the point of sale device using near field communication protocol. The phone may transfer all or a portion of the wallet and/or authentication information, leaving the point of sale device to determine which portions are applicable to the current transaction, or the phone may transfer only presently applicable portions of information, i.e. information to be used during the current transaction, to the point of sale device. That is, logic as to the transfer of wallet and/or authentication information to/from the authentication token (e.g., phone) and the point of sale device may reside on the authentication device, on the point of sale device, or both. In an embodiment, the phone may provide hardware and/or software for authenticating a user, for example a camera or scanner and associated application for confirming biometric data associated with the user, and upon authenticating the user, the phone would convey the successful authentication to the point of sale device.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Salama with the ability to use a digital signature as taught by Campos, doing so allows the digital signature for authenticating the user in a transaction [0039].
As per claim 12, claim 12 recites substantially similar limitations to those found in claim 5. Therefor claim 12 is rejected under the same art and rationale as claim 5. Furthermore, Salama discloses a method (see Abstract).
As per claim 19, claim 19 recites substantially similar limitations to those found in claim 5. Therefor claim 19 is rejected under the same art and rationale as claim 5. Furthermore, Salama discloses a non-transitory computer-readable medium (Col. 2 lines 30-36).
Claims 6, 7, 13, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Salama, et al. (US Patent 10,510,072 B2), “Salama” in view of Ortiz, et al. (US Patent Application Publication 20160019536), “Ortiz” in view of Le Saint, et al. (US Patent Application Publication 20180026973), “Le Saint”.
As per claim 6, Salama does not expressly disclose the following, Le Saint, however discloses:
wherein the operations of sending the proxy element including the usage parameters over the telecommunications network to the recipient mobile wallet application on a second computing device by sending the encrypted message to the second computing device comprise: packetizing the proxy element into a first and second transaction unit; [0098] In embodiments in which the account credentials include a token, the token can be stored on either primary device 701 or secondary device 712, or can be split and stored on both devices. In some embodiments, if secondary device 712 can communicate with authentication server 780 directly, instead of using primary device 701 to forward to secondary device 712 the portion of account credentials to be stored on secondary device 712, authentication server 780 may send the portion of the account credentials to be stored on secondary device 712 directly to secondary device 712, and may omit sending that portion of the account credentials to primary device 701.
encrypting the first transaction unit with a first key; [0106] Primary device 901 may start the cryptogram generation process by obtaining the input data to the cryptogram function (e.g., dynamic data received from an access device, a predetermined static string from memory, etc.). The first intermediate cryptogram C1 can be generated by encrypting the input data with the first portion of the cryptogram key K1
encrypting the second transaction unit with a second key; and [0107] In some embodiments, the second intermediate cryptogram C2 can be generated by decrypting C1 with the second intermediate key K4, encrypting this first result with the first intermediate key K3, and then decrypting this second result with the second portion of the cryptogram key K2.
sending the first transaction unit with the second key and the second transaction unit with the first key. [0107], [0119] The second intermediate cryptogram C2 is then provided to primary device 901, and primary device 901 can generate the final cryptogram C that is sent to an access device by encrypting C2 with the first portion of the cryptogram key K1… At block 1306, the primary device stores the first portion of the cryptogram key on the primary device. At block 1308, the primary device sends the second portion of the cryptogram key to the secondary device for storage on the secondary device. The primary device and secondary device may also be provisioned with a first intermediate key and a second intermediate key.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Salama with the ability to encrypt the account credentials as taught by Le Saint, doing so further enhances authentication for access to the account [0119-0120].
As per claim 7, Salama does not expressly disclose the following, Le Saint, however discloses:
wherein the operations of receiving the encrypted message comprise: receiving the first transaction unit and second key; [0093] In some embodiments, storage of different portions of the account credentials on a set of secondary devices can also be randomized, and the primary device may maintain a mapping of which portion is stored on which secondary device such that the primary device can properly recover the account credentials. For example, a first portion of account credentials encrypted using a first key-encryption key derived from the device data of a first secondary device can be stored on a second secondary device, and a second portion of account credentials encrypted using a second key-encryption key derived from the device data of the second secondary device can be stored on the first secondary device. When the primary device requests the credential data from the two secondary devices, the first secondary device may provide the second portion of account credentials and device data of the first secondary device to the primary device, and the second secondary device may provide the first portion of account credentials and device data of the second secondary device to the primary device. The primary device, having knowledge of the mapping of which portion of the account credentials are stored on which secondary device, can then use the device data received from the first secondary device to decrypt the portion of the account credentials received from the second secondary device, and use the device data received from the second secondary device to decrypt the portion of the account credentials received from the first secondary device.
receiving the second transaction unit and first key; [0093] In some embodiments, storage of different portions of the account credentials on a set of secondary devices can also be randomized, and the primary device may maintain a mapping of which portion is stored on which secondary device such that the primary device can properly recover the account credentials. For example, a first portion of account credentials encrypted using a first key-encryption key derived from the device data of a first secondary device can be stored on a second secondary device, and a second portion of account credentials encrypted using a second key-encryption key derived from the device data of the second secondary device can be stored on the first secondary device. When the primary device requests the credential data from the two secondary devices, the first secondary device may provide the second portion of account credentials and device data of the first secondary device to the primary device, and the second secondary device may provide the first portion of account credentials and device data of the second secondary device to the primary device. The primary device, having knowledge of the mapping of which portion of the account credentials are stored on which secondary device, can then use the device data received from the first secondary device to decrypt the portion of the account credentials received from the second secondary device, and use the device data received from the second secondary device to decrypt the portion of the account credentials received from the first secondary device.
unencrypting the first transaction unit with the first key and the second transaction unit with the second key; and [0093] The primary device, having knowledge of the mapping of which portion of the account credentials are stored on which secondary device, can then use the device data received from the first secondary device to decrypt the portion of the account credentials received from the second secondary device, and use the device data received from the second secondary device to decrypt the portion of the account credentials received from the first secondary device…The primary device, having knowledge of the mapping of which portion of the account credentials are stored on which secondary device, can then use the device data received from the first secondary device to decrypt the portion of the account credentials received from the second secondary device, and use the device data received from the second secondary device to decrypt the portion of the account credentials received from the first secondary device…In some embodiments, for stronger transport protection, the second intermediate cryptogram C2 can be generated by decrypting C1 with the second intermediate key K4, encrypting this first result with the first intermediate key K3, decrypting this second result with the second portion of the cryptogram key K2, re-encrypting this third result with the second intermediate key K4, and then re-decrypting this fourth result with the first intermediate key K3. In such embodiments, primary device 901 can generate the final cryptogram C that is sent to an access device by encrypting C2 with the first intermediate key K3, decrypting this first result with the second intermediate key K4, and then re-encrypting this second result with the first portion of the cryptogram key K1.
reconstructing the proxy element with the unencrypted first and second transaction units. [0075], [0093] The primary device, having knowledge of the mapping of which portion of the account credentials are stored on which secondary device, can then use the device data received from the first secondary device to decrypt the portion of the account credentials received from the second secondary device, and use the device data received from the second secondary device to decrypt the portion of the account credentials received from the first secondary device…The encrypted account credentials can be stored encrypted on the primary device or on the secondary device, or be split and stored on both the primary and secondary devices. When the primary device communicates with an access device to request authorization to use an account, the primary device may obtain the device data of the secondary device (and any account credential stored on the secondary device). The primary device can then use the device data of the secondary device to decrypt the account credentials, and use the decrypted account credentials to interact with the access device to request authorization to use the account.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Salama with the ability to encrypt and decrypt the account credentials as taught by Le Saint, doing so further enhances authentication for access to the account [0119-0120].
As per claims 13 and 14, claims 13 and 14 recite substantially similar limitations to those found in claims 6 and 7, respectively. Therefor claims 13 and 14 are rejected under the same art and rationale as claims 6 and 7. Furthermore, Salama discloses a method (see Abstract).
As per claim 20, claim 20 recites substantially similar limitations to those found in claim 6. Therefor claim 20 is rejected under the same art and rationale as claim 6. Furthermore, Salama discloses a non-transitory computer-readable medium (Col. 2 lines 30-36).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
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, Bennett Sigmond can be reached at 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
GREGORY S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694
Prosecution Insights