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 07/24/2024.
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure Statement(s) filed 02/07/2025 and 11/11/2025 have been considered. Initialed copies of the Form 1449 are enclosed herewith.
Claim Rejections - 35 USC § 112
Claim 14 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 14 recites the limitation: “providing, in response a nonsatisfaction by the device of the one or more conditions by the device based on performing a transaction, obtaining, from the device, a second request override the nonsatisfaction;” The metes and bounds of this limitation are unclear, as it’s not clear 1) what is being provided, and 2) the phrase “in response a nonsatisfaction by” appears to be missing a conjunction phrase, rendering the claim indefinite.
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) - The claims pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a system, method and non-transitory computer-readable medium.
Step 2A – Prong One (Do the claims recite an abstract idea?)
Claim 1 recites an idea, in part, by:
receiving a request to use a credential stored on the first device;
determining whether the second device is in proximity to the first device; and
in response to a determination that the second device is in proximity to the first device, providing access to the credential and authorizing usage of the credential for a transaction performed by the second device.
Claim 9, while varying in scope, recites a related idea, in part, by:
providing a first portion of a credential;
obtaining a request to use the credential;
providing, in response to the request, a second portion of the credential; and authorizing, based on the first portion and the second portion, usage of the credential.
Claim 16, while varying in scope, recites a related idea, in part, by:
obtain a list of one or more devices registered with a user account;
provision a credential, wherein the credential is associated with an account stored on the user account;
provide the credential to a device on the list of one or more devices; and
in response to the device being within a predetermined proximity to the processor, authorize use of the credential on the device.
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) but for the recitation of generic computer components for providing a payment credential to use in a transaction based on the device being on a list, or in proximity to a device or based a provided first and second portion of the credential. That is other than reciting a device, first device, second device, non-transitory computer readable medium, processor, memory, and a secure element nothing in the claim elements are directed towards anything other than commercial or legal interactions for providing a payment credential to use in a transaction based on the device being on a list, or in proximity to a device or based a provided first and second portion of the credential. 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 device, first device, second device, non-transitory computer readable medium, processor, memory, and a secure element. The device, first device, second device, non-transitory computer readable medium, processor, memory, and secure element 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 computers. For example, [0024], and [0087-0094] describes electronic device and invention being implement using generic computer components. 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)). 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 device, first device, second device, non-transitory computer readable medium, processor, memory, and a secure element 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) (creating and maintaining "shadow accounts", "create electronic records, track multiple transactions, and issue simultaneous instructions");, are well-understood routine and conventional, similar to the instant application claims which recites and sending and receiving data over network between the devices for providing a payment credential to use in a transaction based on the device being on a list, or in proximity to a device or based a provided first and second portion of the credential. 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-8, 10-15, 17-20 are all steps that fall within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas but for generally linking the use of the judicial exemption to a particular technical computing environment, by further describing the generic network devices and ineligible for the same reasons as detailed in Prong 2 of the analysis above. 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 § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 9-12, and 15 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Adams (US Patent 11,605,078 B1), “Adams”.
As per claim 9, Adam discloses:
A non-transitory computer-readable medium, comprising: [0113]
computer-readable instructions that, when executed by a processor, cause the processor to perform one or more operations comprising: [0225]
providing, to a device, a first portion of a credential; col. 3 lines 25-33, col.7 lines 48-50, col. 8 lines 17-31 and 46-50, In such circumstances, a payment card issuer can issue a payment card to a user. Instead of (or in addition to) being associated with a CVV2 (or similar security measures), the payment card can be associated with a dynamic code or token that the user can provide when requesting a transaction that uses the payment card. The dynamic code can be generated by the payment issuer system (or a third party) and can be provided to the user via a channel accessed by the user (e.g., a verification application on the user's device)… In some implementations, verification application 348 (or other channel) can include information about the payment cards such as purchases, balances and previous dynamic codes. In other embodiments, verification application 348 provides only dynamic codes. Verification application 348 can provide dynamic codes for multiple payment cards and can include an indication of the time remaining (e.g., a countdown, watch, or timer) for each of the current dynamic codes. In some embodiments, multiple payment cards can be listed with a corresponding dynamic code and/or the countdown until the dynamic code changes on one tab of the application or one webpage of a website; in other embodiments, the user can select a payment card from the list of payment cards to view the dynamic code and/or the remaining time… For example, the icon can use colors such as red when the dynamic code is not available and green when the dynamic code is available… Verification application 348 can reside on a device associated with the user of the payment card or can reside on a server and be accessed via a device.
obtaining, from the device, a request to use the credential; col. 10 line 59-67, see also col. 11 lines 9-20 Receiving operation 402 receives a request from a first device for a dynamic code via an application… Receiving operation 508 receives a request for authorization of a transaction. The request can be received from a remote computing device (e.g., payment processor computing device, merchant computing device) and can include an identifier of the payment card and a verification code, among other information (e.g., time user requested transaction).
providing, in response to the request, a second portion of the credential to the device; and col. 10, lines 60-67, see also col. 2 line 56-67 Before completing a purchase, the user can be required to provide a valid dynamic code associated with the payment card… FIG. 4 is a flow diagram illustrating a set of operations 400 for restricting use of a payment card using a digital code and a second device. Receiving operation 402 receives a request from a first device for a dynamic code via an application. Decision operation 404 determines whether the first device is paired with (or within a proximity of) a second device (e.g., parent's device). When the first device is not paired with (or within a proximity of) the second device, decision operation 404 branches to obfuscating operation 406 which obfuscates or otherwise does not display the dynamic code. When the first device is paired with (or within a proximity of) the second device, decision operation branches to displaying operation 408 which displays the dynamic code.
authorizing, based on the first portion and the second portion, usage of the credential by the device. col. 3 lines 49-62, When requesting a transaction, the user can provide the dynamic code (referred to as a verification code when provided to the merchant system) to the merchant system, which in turn passes the verification code along with other transaction information (e.g., account number, time, merchant identifier, merchant location) to the payment card issuer system for authorization of the transaction. The payment card issuer system can obtain the value of the dynamic code at the time of the transaction and compare it to the verification code provided by the user to the merchant. The “time of the transaction” is generally when the merchant received the transaction request. However, in some implementations the time of the transaction refers to when the payment card issuer receives the authorization request.
As per claim 10, Adams discloses:
providing the first portion and the second portion comprises provisioning an instance of the credential on the device. col. 5 lines 50-57, col. 8 lines 17-31 and 46-50 A memory 150 can also include data memory 170 that can include payment card identifiers, user identifying information such as addresses or zip codes, whether the user has installed the verification application on a device, dynamic codes, historical transaction information, expiration dates etc., which can be provided to the program memory 160 or any element of the device 100… In some implementations, verification application 348 (or other channel) can include information about the payment cards such as purchases, balances and previous dynamic codes. In other embodiments, verification application 348 provides only dynamic codes. Verification application 348 can provide dynamic codes for multiple payment cards and can include an indication of the time remaining (e.g., a countdown, watch, or timer) for each of the current dynamic codes. In some embodiments, multiple payment cards can be listed with a corresponding dynamic code and/or the countdown until the dynamic code changes on one tab of the application or one webpage of a website; in other embodiments, the user can select a payment card from the list of payment cards to view the dynamic code and/or the remaining time.
As per claim 11, Adam discloses:
determining whether the device is in proximity to the processor; and col. 4 lines 5-25, For example, before allowing a user to access a dynamic code and thus complete a purchase, the authorizing entity can check whether the user and/or user's device is within a proximity of a specified second device. “Within a proximity” can mean the first device is within a certain distance of the second device, that the first device and the second device are on the same local area network (or can access the same local area network), or that the first device and the second device are paired using a short-range communications protocol such as Bluetooth or near field communications (NFC). In response to the second device being paired with or within a proximity of the user's device, the dynamic code can be accessed by the user. In some embodiments, the dynamic code is sent from the second device via a communications protocol to the user's device. In other embodiments, the dynamic code is not sent from the second device to the first device, but the second device is required to be within a proximity of the first device in order for the first device to access the dynamic code.
in response to a determination that the device is in proximity to the processor, providing the second portion. col. 4 lines 5-25, For example, before allowing a user to access a dynamic code and thus complete a purchase, the authorizing entity can check whether the user and/or user's device is within a proximity of a specified second device. “Within a proximity” can mean the first device is within a certain distance of the second device, that the first device and the second device are on the same local area network (or can access the same local area network), or that the first device and the second device are paired using a short-range communications protocol such as Bluetooth or near field communications (NFC). In response to the second device being paired with or within a proximity of the user's device, the dynamic code can be accessed by the user. In some embodiments, the dynamic code is sent from the second device via a communications protocol to the user's device. In other embodiments, the dynamic code is not sent from the second device to the first device, but the second device is required to be within a proximity of the first device in order for the first device to access the dynamic code.
As per claim 12, Adam discloses:
wherein: the credential comprises one or more conditions, and the one or more conditions comprise at least one of a time limit for using the credential by the device, a spending limit for using the credential by the device, or a transaction limit for the credential by the device. col. 8 line 60 – col. 9 line 9 . In some embodiments, a predetermined time period can be set (e.g., the user is required to have accessed the channel within an hour prior to the payment card issuer receiving the transaction authorization request). In other embodiments, the time period can begin when the dynamic code changed to the dynamic code that was active at the time of the transaction and can end at the time of the transaction. Thus, the system can verify that the user accessed the channel during the relevant time period. The system can further verify that the user provided authentication credentials (e.g., username/password, biometric information, personal identification number) which were verified within the time period.
As per claim 15, Adams discloses:
determining whether a user of the device is an authorized user; and col. 8 lines 6-16 In some embodiments, the user is required to authenticate to the device and/or channel such as verification application 348 to obtain access to the dynamic code. For example, the user can be authenticated to the device and/or channel by providing biometric information, a personal identification number, or a password. In some embodiments, verification application 348 (or other channel) can operated by the same party as dynamic code generation module 346.
in response to a determination that the user is an authorized user, providing the second portion. col. 8 lines 6-16, see also col. 8 line 60- col. 9 line 24 In some embodiments, the user is required to authenticate to the device and/or channel such as verification application 348 to obtain access to the dynamic code. For example, the user can be authenticated to the device and/or channel by providing biometric information, a personal identification number, or a password. In some embodiments, verification application 348 (or other channel) can operated by the same party as dynamic code generation module 346…. The system can further verify that the user provided authentication credentials (e.g., username/password, biometric information, personal identification number) which were verified within the time period. In some implementations, the payment card issuer can look at a history of interactions with the user to ensure that the user accessed a particular tab in the application or web page in the web portal to obtain the dynamic code
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-8 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hayes, et al. (US Patent Application Publication 20240346485), “Hayes” in view of Adam (US Patent 11,605,078 B1), “Adam”.
As per claim 1, Hayes discloses:
A method, comprising: [0172]
receiving, by a first device and from a second device, a request to use a credential stored on the first device; [0138] A first mobile wallet may register a second mobile wallet as a helper with the mobile wallet provider. The first mobile wallet may ask the mobile wallet provider to establish communication with the second mobile wallet to get help while shopping. The first mobile wallet may be used to show products of interest to the second mobile wallet user and the first mobile wallet may be used to ask the second mobile wallet to lend a payment element the first mobile wallet to allow a purchase using a selected element. The second mobile wallet (lender) may send a loaner payment element to the first mobile wallet (borrower) and the borrower submit the loaner element to a POS device while in communication with the lender. When the transaction is complete, the borrower returns the loaner element to the lender.
Hayes does not expressly disclose the following, Adam, however discloses:
determining whether the second device is in proximity to the first device; and col. 4 lines 3-29, In response to the second device being paired with or within a proximity of the user's device, the dynamic code can be accessed by the user. In some embodiments, the dynamic code is sent from the second device via a communications protocol to the user's device.
in response to a determination that the second device is in proximity to the first device, providing access to the credential on the second device and authorizing usage of the credential for a transaction performed by the second device. col. 3 line 49-65, col. 4 lines 3-29, In response to the second device being paired with or within a proximity of the user's device, the dynamic code can be accessed by the user. In some embodiments, the dynamic code is sent from the second device via a communications protocol to the user's device… When requesting a transaction, the user can provide the dynamic code (referred to as a verification code when provided to the merchant system) to the merchant system, which in turn passes the verification code along with other transaction information (e.g., account number, time, merchant identifier, merchant location) to the payment card issuer system for authorization of the transaction.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hayes with the ability to provide the credential to the second device when the second device is within a proximity of the user’s device as taught by Adam, doing so further allows additional security to be imposed, requiring the users be within a proximity of one another in order to use a shared account, such as a child cannot make a purchase using the shared payment card if the parent's device is not within a proximity of or paired with the child's device. (col. 3 lines 1-9)
As per claim 2, Hayes discloses:
wherein providing the access to the credential comprises provisioning an instance of the credential on the second device. [0138], see also [0164-0166] The second mobile wallet (lender) may send a loaner payment element to the first mobile wallet (borrower) and the borrower submit the loaner element to a POS device while in communication with the lender. When the transaction is complete, the borrower returns the loaner element to the lender.
As per claim 3, Hayes does not expressly disclose the following, Adams, however discloses:
further comprising providing, over a network used to determine the second device is in proximity to the first device, a verification value associated with the credential. col. 3 line 49-65, col. 4 lines 3-29, In response to the second device being paired with or within a proximity of the user's device, the dynamic code can be accessed by the user. In some embodiments, the dynamic code is sent from the second device via a communications protocol to the user's device… When requesting a transaction, the user can provide the dynamic code (referred to as a verification code when provided to the merchant system) to the merchant system, which in turn passes the verification code along with other transaction information (e.g., account number, time, merchant identifier, merchant location) to the payment card issuer system for authorization of the transaction.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hayes with the ability to provide the dynamic code to the second device when the second device is within a proximity of the user’s device as taught by Adam, doing so further allows additional security to be imposed, requiring the users be within a proximity of one another in order to receive the dynamic code, such as a child cannot make a purchase using the shared payment card if the parent's device is not within a proximity of or paired with the child's device. (col. 3 lines 1-9)
As per claim 4, Hayes discloses:
further comprising storing, by the first device, a list of one or more devices comprising the second device. [0182] This may be achieved by having the trusting user digital wallet holder to grant access to cloud based secure element (CBSE) stored payment credentials to trusted (secondary) digital wallet holders. Thus, a mobile wallet system described herein includes a cloud based SE, a first and at least one second mobile wallet, and an access-controlled database in which access to the database is set by the first mobile wallet and grants access to a second, and possibly other, mobile wallets. The access-controlled database may be stored on the CBSE or on the first mobile wallet (or both, and may be split across both), and gives access to payment credentials stored in the CBSE to the second or other mobile wallets.
As per claim 5, Hayes discloses:
wherein providing the access to the credential comprises receiving, by the first device from a third-party network, information for provisioning an instance the credential on the second device. [0145-0147]] Each mobile wallet 19010 or payment account has a unique ID which may be identified by the mobile wallet provider 19020 and/or the issuer 19060. The first mobile wallet 19010a (borrower) establishes real-time secure communication with a second mobile wallet 19010b (lender or helper). The communication may be provided by the mobile wallet provider 19060 or a trusted third party. For example, the communication may be provided by the methods described above… The payment window 20040 may show available or in-use (e.g., via highlighting) payment elements, such as a Wells Fargo Visa card 20041, a checking account 20042, and a debit card 20043. The payment window 20040 may also include a send button 20044 that is utilized to initiate a transmission of the information. For example, the helper may select a payment element, for instance the Wells Fargo Visa 20041, which may be highlighted when selected, and touch the send icon 20044 to send it to the remote mobile wallet 19010a.
As per claim 6, Hayes discloses:
wherein the credential comprises a temporary credential that includes at least one of a time limit for using the credential by the second device, a spending limit for using the credential by the second device, or a transaction limit for the credential by the second device. [0123] 1) generated at a sending wallet client that includes personalized payment credentials and token use key value pairs that describe how the token may be used; and 2) sent to a receiving wallet client wherein the receiving wallet client manages the use of the received payment token pursuant to the provided key value pairs. The key value pairs describe the use of the payment token as being at least one of: for single use, for a period of time, for a specified product, at a specified location, and for a limited dollar amount. The receiving wallet client may limit the use of the token upon any single or combination of any of the criteria above, and may automatically remove the payment token when the token is no longer valid for use.
As per claim 7, Hayes discloses:
further comprising prior to receiving the request, provisioning an instance of the credential on the first device. see fig. 20, [0048], [0051], [0147] The payment window 20040 may show available or in-use (e.g., via highlighting) payment elements, such as a Wells Fargo Visa card 20041, a checking account 20042, and a debit card 20043… For example, the helper may select a payment element, for instance the Wells Fargo Visa 20041, which may be highlighted when selected, and touch the send icon 20044 to send it to the remote mobile wallet 19010a… Mobile wallet applications 1060 and 1070 store one or more data structures that store digital representations of payment and non-payment elements of the user... In some examples, these elements may be issued by sending the digital representations to one or more mobile wallet recipients. Thus, using the disclosed techniques, it may be possible to automatically provision and populate a mobile wallet with little consumer effort.
As per claim 8, Hayes discloses:
wherein the transaction comprises a payment-based transaction. [0074] In some examples, the recipient may verify the identity of the sending mobile wallet. This may be important to maintaining security when processing financial transactions electronically without human intervention. For instance, the recipient mobile wallet may receive a monthly electric bill from a power company and may verify authenticity of the bill by verifying the sender of the bill before making a payment automatically. In some examples, the sender may sign the message with a digital signature.
As per claim 16, Hayes discloses:
A system, comprising: [0047]
a memory; [0113]
a secure element; and [0129] The personalized credentials 18020 may be a digital copy of the personalized credentials that are found on Secure Elements (SE), which are hardware components in which, e.g., a credit card number may be stored. The SEs may exist either on a chip (embedded), or in a subscriber identity module (SIM), and used to payments between an instantiation of a payment application on the SE and a payment application on a point-of-sale (POS) terminal using a card reader using EMVCo standards.
a processor configured to: [0255]
obtain a list of one or more devices registered with a user account; [0047], [0182-0183] This may be achieved by having the trusting user digital wallet holder to grant access to cloud based secure element (CBSE) stored payment credentials to trusted (secondary) digital wallet holders. Thus, a mobile wallet system described herein includes a cloud based SE, a first and at least one second mobile wallet, and an access-controlled database in which access to the database is set by the first mobile wallet and grants access to a second, and possibly other, mobile wallets. The access-controlled database may be stored on the CBSE or on the first mobile wallet (or both, and may be split across both), and gives access to payment credentials stored in the CBSE to the second or other mobile wallets…The trusted person could simply send a request to the trusting person's wallet for access to the card. If the trusting person has previously set the trusted person's wallet identifier as a privileged user that may access a card or cards from the trusting person's digital wallet without express consent, the trusted person may access the trusting person's digital wallet and gain access to the cards or other contents of the wallet so designated… Mobile wallet domains 1010 and 1030 include two respective user computing devices 1040 and 1050 with mobile wallet applications 1060 and 1070 executing along with operating systems 1080 and 1090 respectively.
provision a credential on the secure element, wherein the credential is associated with an account stored on the user account; [0129], [0163] The personalized credentials 18020 may be a digital copy of the personalized credentials that are found on Secure Elements (SE), which are hardware components in which, e.g., a credit card number may be stored. The SEs may exist either on a chip (embedded), or in a subscriber identity module (SIM), and used to payments between an instantiation of a payment application on the SE and a payment application on a point-of-sale (POS) terminal using a card reader using EMVCo standards… first mobile wallet (i.e., originator) may create a proxy payment element (PPE) with a payment element (e.g., credit card, debit card, checking account) in the first mobile wallet and transfer it to the second mobile wallet (i.e., recipient) securely via a W2W communication infrastructure. The PPE may include a total amount, originator's mobile wallet ID, payment element ID, payment issuer ID, effective date, and specifies usage conditions.
provide the credential to a device on the list of one or more devices; and [0175], [0183-0184] FIG. 26 is block diagram illustrating components of an example of a system 26000 for providing access control to payment credentials that is described in more detail below. A primary trusting wallet client 19101a authenticates to a wallet server 26100, e.g. over a network 26003 using, e.g., a secure HTTP interface 26005, and gains authorized access to a CBSE 26010 and an access control database 26020. The access control database may be inside or outside of the CBSE. The primary trusting wallet client 19010a then may update an account record to include at least one secondary wallet client 19010b, 19010c to have access to payment credentials 26030a, 26030b (collectively or representative instance 26030) stored on the cloud based SE 26010… At this point, the originator mobile wallet 19010a has produced and holds a proxy element with the specification shown in FIG. 23. The proxy element may be encrypted in a configuration. The originator sends the proxy element to the recipient wallet 19010b in operation 24013 by using a secure W2W communication infrastructure. The recipient wallet 19010b may store the proxy element in a memory.
Hayes does not expressly disclose the following, Adams, however discloses:
in response to the device being within a predetermined proximity to the processor, authorize use of the credential on the device. col. 3 line 49-65, col. 4 lines 3-29, In response to the second device being paired with or within a proximity of the user's device, the dynamic code can be accessed by the user. In some embodiments, the dynamic code is sent from the second device via a communications protocol to the user's device… When requesting a transaction, the user can provide the dynamic code (referred to as a verification code when provided to the merchant system) to the merchant system, which in turn passes the verification code along with other transaction information (e.g., account number, time, merchant identifier, merchant location) to the payment card issuer system for authorization of the transaction.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hayes with the ability to provide the credential to the second device when the second device is within a proximity of the user’s device as taught by Adam, doing so further allows additional security to be imposed, requiring the users be within a proximity of one another in order to use a shared account, such as a child cannot make a purchase using the shared payment card if the parent's device is not within a proximity of or paired with the child's device. (col. 3 lines 1-9)
As per claim 17, Hayes discloses:
wherein the processor is further configured to provide, based on a provisioning of an instance of the credential, usage of the credential by the device. [0138], [0175], see also [0164-0166] At this point, the originator mobile wallet 19010a has produced and holds a proxy element with the specification shown in FIG. 23. The proxy element may be encrypted in a configuration. The originator sends the proxy element to the recipient wallet 19010b in operation 24013 by using a secure W2W communication infrastructure. The recipient wallet 19010b may store the proxy element in a memory… The second mobile wallet (lender) may send a loaner payment element to the first mobile wallet (borrower) and the borrower submit the loaner element to a POS device while in communication with the lender. When the transaction is complete, the borrower returns the loaner element to the lender.
As per claim 18, Hayes discloses:
wherein the processor is further configured to obtain, from a network, the list of one or more devices, wherein the user account is stored on the network. [0164], [0184] The mobile wallet credentials may be stored in a secure cloud system and the mobile wallet provider may provide credentials for a selected payment to the mobile wallet... FIG. 26 is block diagram illustrating components of an example of a system 26000 for providing access control to payment credentials that is described in more detail below. A primary trusting wallet client 19101a authenticates to a wallet server 26100, e.g. over a network 26003 using, e.g., a secure HTTP interface 26005, and gains authorized access to a CBSE 26010 and an access control database 26020. The access control database may be inside or outside of the CBSE. The primary trusting wallet client 19010a then may update an account record to include at least one secondary wallet client 19010b, 19010c to have access to payment credentials 26030a, 26030b (collectively or representative instance 26030) stored on the cloud based SE 26010.
As per claim 19, Hayes does not expressly disclose the following, Adams, however discloses:
wherein the predetermined proximity is based on a radio network configured to detect the device. col. 2 lines 58-65, see also col. 4 lines 9-20, examiner notes, pairing a device includes the devices detecting one another, To restrict the user's use of the payment card, the dynamic code can be accessible to the user when a certain second device is within a proximity (e.g., electronically paired with, on the same local area network, within a distance of) the user's device… “Within a proximity” can mean the first device is within a certain distance of the second device, that the first device and the second device are on the same local area network (or can access the same local area network), or that the first device and the second device are paired using a short-range communications protocol such as Bluetooth or near field communications (NFC).
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hayes with the ability to provide the credential to the second device when the second device is paired with the first device via blue-tooth or NFC as taught by Adam, doing so further allows additional security to be imposed, requiring the users be within a proximity of one another in order to use a shared account unless the devices are paired, such as a child cannot make a purchase using the shared payment card if the parent's device is not within a proximity of or paired with the child's device. (col. 3 lines 1-9)
As per claim 20, Hayes does not expressly disclose the following, Adams, however discloses:
wherein in response to the device not being within the predetermined proximity to the processor, the processor is further configured to maintain the credential inactive for use by the device. col. 8 lines 39-50, col. 9 lines 1-5, In some embodiments, prior to the user's device displaying the dynamic code, verification application 348 on the user's device determines whether the user's device is within the proximity of/paired with the second device. Verification application 348 can display an icon that shows whether the dynamic code is available to the user so that the user can more easily see whether a transaction will be authorized. For example, the icon can use colors such as red when the dynamic code is not available and green when the dynamic code is available. The user can select the icon to obtain the dynamic code… In other embodiments, the time period can begin when the dynamic code changed to the dynamic code that was active at the time of the transaction and can end at the time of the transaction. Thus, the system can verify that the user accessed the channel during the relevant time period.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hayes with the ability to indicate the codes as available or not as taught by Adam, doing so further allows the user to know if a transaction will be authorized based on the icons indicating whether the dynamic code is available or not (col. 8 lines 39-50, col. 9 lines 1-5).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Adam (US Patent 11,605,078 B1), “Adam” in view of Hayes, et al. (US Patent Application Publication 20240346485), “Hayes”.
As per claim 13, Adam does not expressly the following, Hayes, however discloses:
further comprising in response to a determination of a nonsatisfaction of the one or more conditions by the device, removing the credential on the device. [0123] The key value pairs describe the use of the payment token as being at least one of: for single use, for a period of time, for a specified product, at a specified location, and for a limited dollar amount. The receiving wallet client may limit the use of the token upon any single or combination of any of the criteria above, and may automatically remove the payment token when the token is no longer valid for use.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Adam with the ability to automatically remove the token when it is no longer valid as taught by Hayes, doing so further allows to automatically be removed based on the criteria related to the use of the payment token [0123].
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Adam (US Patent 11,605,078 B1), “Adam” in view of Gaudin, et al. (US Patent 10,504,094 B1), “Gaudin”.
As per claim 14, Adam does not expressly disclose the following, Gaudin, however discloses:
providing, in response a nonsatisfaction by the device of the one or more conditions by the device based on performing a transaction, obtaining, from the device, a second request override the nonsatisfaction; and col. 21 lines 15-34, Further, the vehicle payment application 266 may include spending limits for each of the stored financial cards, which may be monthly spending limits, yearly spending limits, etc. For example, a parent and/or guardian of the user may set a monthly spending limit on one of the stored financial cards. When transmitting the payment would cause the user to exceed the allotted spending limit for the financial card, the payment authorization screen 360 may include a message indicating that the payment would cause the financial card to exceed the spending limit and/or requesting the user to select another financial card. In some scenarios, the user may be able to override the spending limit, for example by entering an emergency override code, receiving permission from the parent and/or guardian who entered the spending limit, etc.
providing, to the device, an authorization to override the nonsatisfaction, thereby allowing the device to use the credential for the transaction. col. 21 lines 15-34, In some scenarios, the user may be able to override the spending limit, for example by entering an emergency override code, receiving permission from the parent and/or guardian who entered the spending limit, etc.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Le Saint, et al. (US Patent Application Publication 20180026973) discloses “Enhance authentication techniques may include receiving credential data of a secondary device by a primary device, generating a cryptogram using the credential data of the secondary device, and transmitting the cryptogram to an access device to request for authorization to use an account associated with a user of the primary device. The authorization can be granted based on verification of the cryptogram and an interaction activity pattern of interactions between the primary device and a set of communication devices including the secondary device.” Salama, et al. (US Patent 10,510,072 B2) discloses “The disclosed embodiments include computerized methods and systems that enable users to delegate a functionality of a mobile application through pre-loaded tokens. In one aspect, the disclosed embodiments may temporarily delegate or “loan” financial products loaded into a mobile wallet of a user to other eligible users. 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. The second user device may, for example, process the mobile wallet token and establish the delegated financial provide in the second user's mobile wallet in accordance with the at least one of the temporal or financial conditions.”
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