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 .
Response to Arguments
2. Applicant’s arguments filed on , with respect to the 35 U.S.C. 103 rejection of claims 1-20 as being unpatentable over U.S. Publication No. 20180336553 hereinafter Brudnicki in view of U.S. Publication No. 20180349886 hereinafter Blakesley. have been fully considered. However, upon further consideration, a new ground(s) of rejection is made in view of amended claims.
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.
3. Claims 1-21 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, and further in view of U.S. Publication No. 20160358172 hereinafter Ziat.
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 110/ 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 (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:
receiving, from the computing device, a request to provision a credential for the funding account on the computing device, wherein the credential is not yet provisioned on the computing device
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.
Brudnicki in view of Blakesley does not disclose:
receiving, from the computing device, a request to provision a credential for the funding account on the computing device, wherein the credential is not yet provisioned on the computing device
Ziat discloses:
receiving, from the computing device, a request to provision a credential for the funding account on the computing device, wherein the credential is not yet provisioned on the computing device (Fig. 6, element 602, para 0046 “Process 600 may begin at step 602, where device 100 may communicate credential provisioning request data 652 with transaction entity subsystem 400, where credential provisioning request data 652 may include a selection of at least one particular commerce credential or card to be provisioned on to device 100 as well as any other suitable information associated with device 100.” Fig. 6, element 612, Para 0055 “For example, at step 612 of process 600 of FIG. 6, transaction entity subsystem 400 (e.g., SMP broker component 410) may analyze the received credential provisioning response data of information 658 and may then generate and transmit first credential device data 662, such as pass data, to electronic device 100. Such pass data may include any suitable description or identification of the first payment scheme credential to be provisioned (e.g., a hashed-version of the credential's PAN, virtual and/or actual (e.g., D-PAN and/or F-PAN)), as well as any associated metadata, all of which may be provided by credential provisioning response data of information 658 of step 608.” Fig. 6, Para 0057 “ For example, as shown in FIG. 5, after step 612, the provisioning of the first payment scheme credential may result in pass 119a being stored on device 100 for use by card management application 113b and may result in first SSD 154a being provisioned on device 100 (e.g., secure element 145) to include applet 153a with PAN 159a and AID 155a of the first payment scheme credential.”)
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 in view of Blakesley to include receiving, from the computing device, a request to provision a credential for the funding account on the computing device, wherein the credential is not yet provisioned on the computing device, as taught by Ziat.
The motivation would have been to provisioning credential on an
electronic device for in a secure transaction.
As per claim 2, Brudnicki in view of Blakesley and Ziat 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 and Ziat 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 and Ziat 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 and Ziat 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 and Ziat 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 and Ziat 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.
As per claim 21, Brudnicki in view of Blakesley and Ziat discloses:
The method of claim 1, wherein the credential is used by the computing device to facilitate a transaction using the funding account (Brudnicki para 0052 and 0053).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights