Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
2. NO restrictions warranted at initial time of filing for patent.
Priority
3. Applicant claims domestic priority under 35 USC 119e to provisional application filed on 07/07/2019.
Information Disclosure Statement
4. The information disclosure statement (IDS) submitted on 01/06/2025, the submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Oath/Declaration
5. Applicant’s Oath was filed on 10/30/2024.
Drawings
6. Applicant’s drawings filed on 10/30/2024 has been inspected and is in compliance with MPEP 608.01.
Specification
7. Applicant’s specification filed on 10/30/2024 has been inspected and is in compliance with MPEP 608.02.
Claim Objections
8. NO objections warranted at initial time of filing for patent.
Remarks
9. Examiner request Applicant review relevant prior art under the conclusion of this office action.
Claim Rejections - 35 USC § 103
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 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.
10. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over
U.S. Publication No. 20180336553 hereinafter Brudnicki in view of U.S. Publication No. 20180349886 hereinafter Blakesley.
As per claim 1, Brudnicki discloses:
A method for credential provisioning using an administration entity ("AE") subsystem, the method comprising, by the AE subsystem (para 0005 “As an example, a method is provided for facilitating a transfer of funds between a first fund account of a credential issuer subsystem and a second fund account of the credential issuer subsystem using a first end-user host electronic device and a second end-user host electronic device and an administration entity subsystem.”)
authenticating a computing device for a user account of the AE subsystem (para 0065 “If user U1 is willing and able to select or confirm a particular payment credential of device 100 for use in funding the potential transaction, operation 536 may receive intent and authentication by user U1 of device 100 to utilize the selected payment credential through any suitable user interaction with device 100. Access SSD 154c may leverage or otherwise use applet 153c of device 100 to determine whether such authentication has occurred before allowing other SSDs 154 (e.g., credential SSD 154a) to be used for enabling its credential information in device transfer funds request data communication. As just one example, applet 153c of access SSD 154c may be configured to determine intent and local authentication of a user of device 100 (e.g., via one or more input components 110, such as a biometric input component 110i of FIG. 3, as may be used by a user interacting with any application of device 100 (e.g., card management application 113b of device 100)) and, in response to such a determination, may be configured to enable another particular SSD for conducting a payment transaction (e.g., with the payment credential of credential SSD 154a).);
in response to the authenticating, identifying an ownership token that is associated with the user account (para 0065 “As just one example, applet 153c of access SSD 154c may be configured to determine intent and local authentication of a user of device 100 (e.g., via one or more input components 110, such as a biometric input component 110i of FIG. 3, as may be used by a user interacting with any application of device 100 (e.g., card management application 113b of device 100)) and, in response to such a determination, may be configured to enable another particular SSD for conducting a payment transaction (e.g., with the payment credential of credential SSD 154a). Next, once intent and authentication has been received for a particular payment credential, operation 536 may include device 100 generating, encrypting, and transmitting device transfer funds request data 536d for use by AE subsystem 400. For example, as mentioned, sender device payment credential data of device transfer funds request data 536d may be generated by selected SSD 154a to include any suitable token data indicative of send token ST-1a and crypto data, which may be generated and/or at least partially encrypted with credential key 155a′, such that such encrypted sender device payment credential data may only be decrypted by an entity with access to that credential key 155a′ (e.g., first issuing subsystem 391 of issuer subsystem 300) for accessing the sender device payment credential data. In some embodiments, once some or all of that sender device payment credential data of credential SSD 154a has been encrypted with credential key 155a′ as CI-encrypted sender device payment credential data at operation 536, that CI-encrypted sender device payment credential data, either alone or along with any additional appropriate transfer data (e.g., any suitable fund amount data indicative of the selected $50 value, any suitable receiver identification data indicative of the selected social token LT-2, any suitable sender device data indicative of ED1-ID and/or U1-ID, any suitable mandate key (e.g., any suitable hash of any suitable unique identifier of device 100 (e.g., a device transfer unique identifier FX1-ID) and selected social token LT-2) that may provide a unique key for the particular combination of sender device 100 and receiver social token LT-2 of the current transaction, etc.), may be encrypted by access information (e.g., by access key 155a of SSD 154a, access key 155c of access SSD 154c, ISD key 156k, and/or CRS 151k and/or signed by CASD 158k) at operation 536 as AE-encrypted sender device payment credential data. Any appropriate sender device payment credential data (e.g., token and crypto data) of selected SSD 154a (e.g., CI-encrypted sender device payment credential data (e.g., encrypted by credential key 155a′) whether or not then encrypted as AE-encrypted sender device payment credential data (e.g., as encrypted by an access key)) may then be communicated along with any additional information, such as an identification of the $50 amount of funds to be transferred and/or identification of the receiver social token LT-2 and/or of ED1-ID and/or of U1-ID and/or of a mandate key of the transfer, as device transfer funds request data 536d from device 100 to AE subsystem 400 at operation 536.” The transfer funds request data generated includes the social tokens which are e-mail addresses, telephone numbers, etc.) with certain registered devices and/or to enable certain secure communications between registered devices and/or to associate certain registered devices with a certain AE user account of AE subsystem 400 (paragraph 0023));
in response to the identifying, providing the computing device with access to the ownership token, wherein the ownership token is for a funding account (para 0066 “That is, at least sender device payment credential data of device transfer funds request data 536d may be encrypted as CI-encrypted sender device payment credential data with a credential key 155a′ that may not be exposed to or accessible by any portion of device 100 outside of its secure element. Moreover, at least a portion of device transfer funds request data 536d may be encrypted as AE-encrypted data with an access key (e.g., access key 155b, 155c, 156k, 151k, and/or 158k (e.g., referred to herein as “access information”)) that may not be exposed to or accessible by any portion of device 100 outside of its secure element. In some embodiments, a transfer may be initiated by a potential receiver sending a request for funds to a sender device (e.g., via text message, e-mail, etc.), and the social token of the receiver that sent the request and/or a funding amount identified in the receiver's request may be automatically used to define a portion of any device transfer funds request data 536d that may be sent in response to the request.”);
after the providing, receiving from the computing device a request to provision on the computing device a credential for the funding account (para 0068 “ For example, using receiver user identifier U2-ID and/or unique electronic device identifier ED2-ID and/or unique user credential identifier PID-2a and/or any other suitable data (e.g., in table 473 and/or in table 493) that may be associated with receive token RT-2a of entry 493c, as well as using receiver user identifier U2-ID and/or unique electronic device identifier ED2-ID and/or unique user credential identifier PID-2b and/or any other suitable data (e.g., in table 473 and/or in table 493) that may be associated with receive token RT-2b of entry 493d, AE subsystem 400 may communicate with device 200 to determine which one of the payment credentials provisioned on device 200 and associated with such unique user credential identifiers PID-2a and PID-2b (e.g., which one of the payment credential on SSD 254a with ST-2a and the payment credential on SSD 254b with ST-2b) ought to be used to determine the funding account that is to receive the funds being transferred. Such a determination may be achieved by providing any suitable prompt to a user of device 200 via any suitable user interface of device 200 (e.g., via a push notification or otherwise to card management application 213b or the like) that may enable a user of device 200 to selectively elect a particular one of those provisioned payment credentials in order to identify its associated funding
account as the account to receive the funds being transferred.);
in response to the receiving, determining that the computing device has access to the ownership token (para 0072 “AE subsystem 400 may link the receive token RT to any suitable AE device registration identifier(s) or AE device registration data (e.g., user identifier U-ID and/or electronic device identifier ED-ID and/or social token LT) that may be associated with the user device on which the payment credential (e.g., the linked send token) is provisioned, such that, when AE subsystem 400 receives a request to transfer funds to a receiver identified by any suitable AE device registration data (e.g., a social token LT of a receiver), AE subsystem 400 may be operative to determine a particular receive token RT associated with that identified receiver and then share that particular receive token RT with CI subsystem 300 such that CI subsystem 300 may use that receive token RT to identify to CI subsystem 300 the appropriate fund account to receive the funds of the requested fund transfer.”)
Brudnicki does not disclose:
and in response to the determining, facilitating an automatic loading of the credential on the computing device
Blakesley discloses:
and in response to the determining, facilitating an automatic loading of the credential on the computing device (para 0021 “In the subject system, the one or more wireless transaction system servers 110 automatically receive indications of card accounts of the user, e.g. without the user having to input information regarding the card accounts. The one or more wireless transaction system servers 110 determine whether a card account is eligible to have a corresponding applet provisioned on the secure element of one or more of the electronic devices 102A-B of the user, such as the electronic device 102A, and, if so, transmit a notification to the one or more electronic devices (e.g., electronic device 102A) indicating the same. For example, the notification may proactively notify the user that they have a card account (a card on file (“CoF”)) that is eligible to be added to the electronic device 102A for use in one or more wireless transaction systems. In some embodiments, a CoF can be detected through any association with a user account. For example, a user can associate a payment card with a particular service that is linked to a user account, such as a media streaming service or an application service. The payment card can then be detected as a CoF associated with the user, which can trigger a notification of a CoF that is eligible to be provisioned to one or more electronic devices associated with the user account. Similarly, provisioning a card account on one electronic device associated with the user account can trigger a notification of a CoF that is eligible to be provisioned on one or more other electronic devices that also are associated with the user account.”)
Therefore, it would have been obvious to one of ordinary skill in the art
before the effective filing date of the claimed invention to modify the method is provided for facilitating a transfer of funds between a first fund account of a credential issuer subsystem of Brudnicki to include and in response to the determining, facilitating an automatic loading of the credential on the computing device, as taught by Blakesley.
The motivation would have been to provisioning credential on an electronic device for in a secure transaction automatically.
As per claim 2, Brudnicki in view of Blakesley discloses:
The method of claim 1, further comprising storing the ownership token in an AE locker of the user account (Brudnicki para 0048 “ For example, user U1 of device 100 may log into its account at AE subsystem 400 (e.g., using an online resource on device 100), where user U1 may enter a first user identifier U1-ID that may be any suitable data that may uniquely identify first user U1 to AE subsystem 400 and/or any suitable first user password data U1-PW associated therewith (e.g., user-specific log-in information to a user-specific account with that administration entity (e.g., via a user-specific identification and password combination or the like)), and provide that user account data to AE subsystem 400 along with any suitable device registration identifier(s) or any suitable device registration data, such as a unique electronic device identifier ED1-ID of device 100 (e.g., any unique identifier assigned to device 100 (e.g., by AE subsystem 400), such as at time of device manufacture) and/or at least one social identifier or social token LT-1 (e.g., at least one telephone number and/or e-mail address) associated with device 100 for user 1 (e.g., any suitable device identification information 119), such that the device registration data of device 100 may be associated with user U1's verified specific user account at AE subsystem 400 (e.g., at device protection subsystem 471).”
As per claim 3, Brudnicki in view of Blakesley discloses:
The method of claim 2, further comprising, after the storing the ownership token in the AE locker of the user account, when a second electronic device is fully authenticated for the user account (Brudnicki para 0042 “ AE subsystem 400 may be provided by any suitable administration and/or commercial entity that may offer various services to a user of a user device (e.g., device 100 and/or device 200) via user-specific log-in information to a user-specific account with that administration entity (e.g., via user-specific identification and password combinations).” para 0048 “ For example, user U1 of device 100 may log into its account at AE subsystem 400 (e.g., using an online resource on device 100), where user U1 may enter a first user identifier U1-ID that may be any suitable data that may uniquely identify first user U1 to AE subsystem 400 and/or any suitable first user password data U1-PW associated therewith (e.g., user-specific log-in information to a user-specific account with that administration entity (e.g., via a user-specific identification and password combination or the like)), and provide that user account data to AE subsystem 400 along with any suitable device registration identifier(s) or any suitable device registration data, such as a unique electronic device identifier ED1-ID of device 100 (e.g., any unique identifier assigned to device 100 (e.g., by AE subsystem 400), such as at time of device manufacture) and/or at least one social identifier or social token LT-1 (e.g., at least one telephone number and/or e-mail address) associated with device 100 for user 1 (e.g., any suitable device identification information 119), such that the device registration data of device 100 may be associated with user U1's verified specific user account at AE subsystem 400 (e.g., at device protection subsystem 471).” Para 0079 “For example, in some embodiments, user U1 and user U2 may be the same user using both first device 100 and second device 200 (e.g., to associate one account of that user with device 100 and generate transaction credential data with device 100 for use in funding another account of that user that may be associated with a credential on device 200).”)
storing the ownership token on the second electronic device (Blakesley Para 0042 “In one or more implementations, the service provider server 120 may transmit the notification to the wireless transaction system server 110 responsive to the service provider server 120 provisioning an applet corresponding to a card account of the user on another electronic device 102B of the user.” The applet is the ownership token. “para 0049 “In one or more implementations, the wireless transaction system server 110 may repeat (404)-(416) for any additional electronic devices associated with the user, such as the electronic device 102B. For example, the electronic devices 102A-B may be registered to a user account associated with the user, such as via a cloud-based device management system that may be associated with the wireless transaction system and/or the wireless transaction system server 110, and/or the wireless transaction system server 110 may receive an indication of the electronic devices 102A-B that are registered to the user.” Though Brudnicki discloses ownership token, Blakesley discloses storing the ownership token on the second electronic device. The motivation would have been to provisioning credential on an electronic device for in a secure transaction automatically.)
As per claim 4, Brudnicki in view of Blakesley discloses:
The method of claim 3, further comprising, after the storing ownership token on the second electronic device, receiving from the second electronic device a request to provision the credential on the second electronic device (Blakesley Para 0045 and 0046 “If the wireless transaction system server 110 determines that the card account is eligible to be added to the electronic device 102A (404), the wireless transaction system server 110 sends a notification to the electronic device 102A that notifies the user that the card account is eligible to be added to the electronic device 102A, e.g., for use in the wireless transaction system (408). The notification message may be transmitted, for example, as text message, a homescreen notification, a notification within an application corresponding to the wireless transaction system, and/or any other form of messaging. In some implementations, a notification may be sent to multiple electronic devices associated with the user (e.g., linked to a common user account) on which the card account can be added.” Para 0046 “In one or more implementations, the notification may include a selectable element, such as a link or virtual control, that the user may select to approve adding the card account to the electronic device 102A.” Para 0049 “In one or more implementations, the wireless transaction system server 110 may repeat (404)-(416) for any additional electronic devices associated with the user, such as the electronic device 102B.” After the applet is provisioned on the second device, the second device can approve the request to add the card information to the second device. Though Brudnicki discloses ownership token, Blakesley discloses receiving from the second electronic device a request to provision the credential on the second electronic device. The motivation would have been to provisioning credential on an electronic device for in a secure transaction automatically.).
As per claim 5, Brudnicki in view of Blakesley discloses:
The method of claim 1, further comprising authenticating the computing device for the user account of the AE subsystem via three factor authentication (Blakesley para 0043 “ For example, the wireless transaction system may require that the electronic device 102A implement two-factor authentication and/or other security mechanisms.” Blakesley does not limit the inclusion of a 3 factor authentication. Though Brudnicki discloses authenticating a computing device , Blakesley discloses authenticating the computing device for the user account of the AE subsystem via three factor authentication. The motivation would have been to provisioning credential on an electronic device for in a secure transaction automatically.).
As per claim 6, Brudnicki in view of Blakesley discloses:
The method of claim 1, further comprising: authenticating a user-specific identifier and password combination (Brudnicki para 0042 and 0048);
authenticating an out of band verification code; and determining, using AE security data, that a correct first AE security code was entered (Blakesley para 0020 “In order to have an applet corresponding to a card account with a given service provider provisioned onto a secure element of one or more of the electronic devices 102A-B, such as the electronic device 102A, a user of the electronic device 102A may access an application running on the electronic device 102A to input information regarding the card account, such as any/all of an account number, a picture of the corresponding physical card, a name, a security code, and the like. After entering the information, the one or more of the service provider servers 120 and/or the one or more wireless transaction system servers 110, such as a TSM server and/or a broker server, may cause the applet corresponding to the card account to be provisioned on a secure element of the electronic device 102A, such as by transmitting a provisioning script to be executed by the secure element of the electronic device 102A.” Para 0058 “The wireless transaction system server 110 may determine, based on the information received from the electronic device 102A, whether one or more security mechanisms are implemented by the electronic device 102A, such as two-factor authentication, and/or whether the current authentication level of the electronic device 102A meets a minimum authentication level for provisioning an applet on the secure element 208 of the electronic device 102A (528).” Providing a multifactor authentication can include out of band verification code and validation of entered verification code/security code. Though Brudnicki discloses authenticating a computing device, Blakesley discloses a multifactor authentication processes for authenticating the computing device for the user account of the AE subsystem. The motivation would have been to provisioning credential on an electronic device for in a secure transaction automatically.).
As per claim 7, Brudnicki in view of Blakesley discloses:
The method of claim 1, further comprising generating the ownership token by performing a cryptographic hash function on a combination of a unique credential identifier of the credential and a unique user identifier of a user (Brudnicki para 0073 “For example, the mandate key that may be generated by sender device 100 and that may be included as a portion of transfer funds request data 536d may be any suitable hash of (i) any suitable unique identifier of device 100 and (ii) the receiver social token of the request, where the unique identifier may be electronic device identifier ED1-ID, user identifier U1-ID, or any other suitable universally unique identifier (“UUID”) that may be a unique one-time device generated UUID (e.g., a device transfer unique identifier FX1-ID, which may be stored in entry 173a of storage 173 of device 100).”).
As per claim 8, the implementation of the method of claim 1 will execute the
non-transitory computer readable storage medium (Brudnicki paragraph
0080) of claim 8. The claim is analyzed with respect to claim 1.
As per claim 9, the claim is analyzed with respect to claim 2.
As per claim 10, the claim is analyzed with respect to claim 3.
As per claim 11, the claim is analyzed with respect to claim 4.
As per claim 12, the claim is analyzed with respect to claim 5.
As per claim 13, the claim is analyzed with respect to claim 6.
As per claim 14, the claim is analyzed with respect to claim 7.
As per claim 15, the implementation of the method of claim 1 will execute
the system of claim 15. The claim is analyzed with respect to claim
1.
As per claim 16, the claim is analyzed with respect to claim 2.
As per claim 17, the claim is analyzed with respect to claim 3.
As per claim 18, the claim is analyzed with respect to claim 4.
As per claim 19, the claim is analyzed with respect to claim 5.
As per claim 20, the claim is analyzed with respect to claim 6.
Conclusion
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Publication No. 20160358172 discloses on paragraph 0005 “As an example, a method for providing a multi-scheme card on an electronic device including a secure element using a transaction entity subsystem and an issuer subsystem may include receiving, at the transaction entity subsystem from the electronic device, credential provisioning request data including request primary account number (“PAN”) information indicative of a request PAN associated with the multi-scheme card, identifying, at the transaction entity subsystem, a plurality of credentials associated with the request PAN information of the received credential provisioning request data, acquiring, at the transaction entity subsystem from the issuer subsystem, first credential provisioning information for a first credential of the identified plurality of credentials, acquiring, at the transaction entity subsystem from the issuer subsystem, second credential provisioning information for a second credential of the identified plurality of credentials, and provisioning, on the electronic device from the transaction entity subsystem, credential data based on the acquired first credential provisioning information and the acquired second credential provisioning information, wherein the provisioning the credential data includes storing, on the secure element of the electronic device, a first applet including a first PAN and a first application identifier (“AID”) associated with the first credential, storing, on the secure element of the electronic device, a second applet including a second AID associated with the second credential, and storing, on the electronic device, link information operative to associate the first applet with the second applet.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GARY S GRACIA whose telephone number is (571)270-5192. The examiner can normally be reached Monday-Friday 9am-6pm.
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, Philip Chea can be reached at 5712723951. 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.
/GARY S GRACIA/Primary Examiner, Art Unit 2499