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 application filed on 06/21/2024.
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure Statement(s) filed 06/21/2024 have been considered. Initialed copies of the Form 1449 are enclosed herewith.
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-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter in that the system could be interpreted as software per se. As a matter of claim interpretation, the claims recite “… the system comprising: using a hard processor….”, this is not the same as reciting the system comprising a hardware processor, and when given broadest reasonable interpretation a hardware processor is commonly used by software. The system does not recite any other non-tangible components and there for under broadest reasonable interpretation and in light of [00106] and [00240-00242], which states “Operating system layer 16004 provides one or more services to the application layer 16002 and manages hardware in the hardware layer 16006 “, claims 1-7 could be interpreted as software per se. As per MPEP 2106.03, claims that are not directed to any of the statutory categories include: Products that do not have a physical or tangible form, such as information (often referred to as "data per se") or a computer program per se (often referred to as "software per se") when claimed as a product without any structural recitations. For these reasons, claims 1-7 are rejected for being directed to non-statutory subject matter. Appropriate correction is required.
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
using a hardware processor of a first computing device, 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.
using a hardware processor of a second computing device, 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 hardware processor of the second device is configured to perform additional 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
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