CTNF 18/962,229 CTNF 85634 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Specification 06-14 AIA Applicant is reminded of the proper content of an abstract of the disclosure. A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art. If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives. Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps. Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length. See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts. The abstract of the disclosure is objected to because the phrase “disclosure in the abstract in line 1. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b). 07-29 AIA The disclosure is objected to because of the following informalities: the hyperlink in par 0033 . Appropriate correction is required. 07-29-04 The disclosure is objected to because it contains an embedded hyperlink and/or other form of browser-executable code. Applicant is required to delete the embedded hyperlink and/or other form of browser-executable code; references to websites should be limited to the top-level domain name without any prefix such as http:// or other browser-executable code. See MPEP § 608.01. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim(s) 1, 3-10, and 12-18 are rejected under 35 U. S.C. 103 as being unpat entable over Sandelov et al 2018/0005227 in view of L axminarayanan et al US 2016/0301683. As per claim 1. Samdelov discloses a comp uter-implemented method for authenticating a transaction over a secure network, the method comprising: receiving, by a digital service server, from a merchant plug-in (MPI) computing device ( 0040 The dynamic transaction card can also include: (local) memory storing a cryptogram (and/or a cryptogram generator) and a token corresponding to a transaction method loaded on the dynamic transaction card; ), via a directory server, a token and a first cryptogram for the transaction , the first cryptogram unique to the transaction (fig.3, transmit token + Cryptogram to payment Issuer, i.e. a digital service server from the POS, i.e. a merchant plug-in (MPI) and fig.1, 0053 the dynamic transaction card can communicate the token, tokenized PAN, PAN, or other payment account identifier to the POS system and 0054 receive a first token selected randomly from the group of seven tokens from the mobile computing device ); and then decrypting, by the digital service server, the token into sensitive data (0053 to decrypt the cryptogram by retrieving—from a domain name system affiliated with an issuer of the dynamic transaction card—cryptographic protocols corresponding to the cryptogram (and/or cryptogram generator) programmed into the dynamic transaction card; to decrypt the token to identify the transaction method; to authenticate the transaction with the transaction method based on the decrypted cryptogram and the decrypted token, and to pass back to the POS system confirmation of the transaction, such as in the form of a PAN product identifier and a token assurance level); and validating, by the digital service server, the first cryptogram, based on one or more session keys (0035 In response to a request to authorize the card—such as including a unique identifier of the dynamic transaction card, the cryptogram loaded onto the dynamic transaction card, and/or login information entered by the user within the native application—received from the user via the native application and [0098] the dynamic transaction card is pre-loaded with multiple cryptogram generators (e.g., “secret keys” for generating different varieties of cryptograms). In this implementation, the various cryptogram generators can execute corresponding cryptographic schemes, and the dynamic transaction card can thus emulate various transaction methods through various tokens schemes and various corresponding cryptographic schemes hosted by various token generators and 0053 to decrypt the cryptogram by retrieving—from a domain name system affiliated with an issuer of the dynamic transaction card—cryptographic protocols corresponding to the cryptogram (and/or cryptogram generator) programmed into the dynamic transaction card; to decrypt the token to identify the transaction method; to authenticate the transaction with the transaction method based on the decrypted cryptogram and the decrypted token, and to pass back to the POS system confirmation of the transaction, such as in the form of a PAN product identifier and a token assurance level and 0036 the payment processor may flag the transaction as fraudulent or otherwise unexpected.) and 0120 at a first time, the dynamic transaction card can detect a magnetic stripe card reader proximal the magnetic stripe emulator during a first swipe through the magnetic stripe card reader integrated into a POS system and drive the magnetic stripe emulator according to a first magnetic stripe sequence command corresponding a first cryptogram and a first token representing a (default) first transaction method. However, at a second time succeeding the first time and within a preset duration of the first time (e.g., 3 seconds), the detect can detect initiation of second swipe of the dynamic transaction card through the magnetic stripe card reader. In response to initiation of the second swipe , the dynamic transaction card can flag the first swipe as an ineffective swipe (e.g., due to a failure of the magnetic stripe card reader). Thus, the dynamic transaction card can drive the magnetic stripe emulator according to the (same) first magnetic stripe sequence command during the second swipe. If the dynamic transaction card detects no more swipes following the second swipe for a threshold duration of time (e.g., thirty seconds), the dynamic transaction card can mark the second swipe successful and disregard the first swipe as an ineffective miscommunication between the dynamic transaction card and the magnetic stripe card reader and 0134 the user taps the dynamic transaction card three time to trigger the dynamic transaction card to enter an “online transaction mode,” and the dynamic transaction card authenticates its use, as described above. In this example, the dynamic transaction card then executes generates a new cryptogram for an upcoming online transaction with a selected transaction method, packages the new cryptogram and a token corresponding to the selected transaction method, and transmits the cryptogram and token back to the mobile computing device; the native application then disseminates the cryptogram and token: to an other native application to complete a transaction within the other native application; into a webpage or other interface within a web browser executing on the mobile computing device; or directly to an acquirer with a tag/flag identifying the online transaction initiated through another native application or web browser executing on the user's computing device . As in this example, the dynamic transaction card can thus authenticate, i.e. setting up the transaction authentication , a transaction with a transaction method hosted by the dynamic transaction card , such as by requiring a valid fingerprint scan at the dynamic transaction card and/or by requiring a wireless connection between the dynamic transaction card and an associated computing device (e.g., a smartphone), and the dynamic transaction card can selectively supply transaction data for a selected transaction method accordingly to enable secure “card-not-present” (e.g., online, remote) transaction.); and sending, to a user device of a user, an authentication request message, as an authentication step-up, to verify the user and the authenticity of the transaction (0062 the dynamic transaction card can store the token (or a decryptdd form of the token) in local memory of the dynamic transaction card. In this implementation, the dynamic transaction card can confirm receipt of the token from the mobile computing device by transmitting a confirmation notice to the mobile computing device. In response to confirmation of receipt of the token, the mobile computing device can delete the token from local memory and 0025 authentication server—to authenticate a transaction with the dynamic transaction card based on alignment between a token and cryptogram received from the dynamic transaction card at a POS system). Sandelov does not disclose prior to authorization of a transaction: then based on the first cryptogram not being validated: setting a validation flag to a defined value indicating that the first cryptogram is not valid; sending, to a user device of a user, an authentication request message, as an authentication step-up, to verify the user and the authenticity of the transaction. However, Laxminarayanan discloses prior to authorization of a transaction: then based on the first cryptogram not being validated: setting a validation flag to a defined value indicating that the first cryptogram is not valid ( 0057-0058 If the cryptogram was not validated by the payment processing network 107 , then, the issuer computer 109 may want to perform additional authentication processing with respect to the user device 102 and/or the user of the user device 102 before authorizing the transaction. In some embodiments, issuer computer 109 may include other relevant information in the authorization response message, such as risk analysis information.); sending, to a user device of a user, an authentication request message, as an authentication step-up, to verify the user and the authenticity of the transaction (0057-0058 If the cryptogram was not validated by the payment processing network 107 , then, the issuer computer 109 may want to perform additional authentication processing with respect to the user device 102 and/or the user of the user device 102 before authorizing the transaction). Sandelov and Laxminarayanan are both considered to be analogous to the claimed invention because they are in the same field of transaction processing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sandelov to incorporate the teachings of Laxminarayanan and provide user authentication before processing the transition. Doing so would prevent fraudulent transaction, thereby increasing the protection for the transaction. As per claim 10. Sandelov discloses a system for authenticating a transaction on a secure network, the system comprising: a digital service server (0099 a service provider) including a first processor and a first non-transitory memory, the first non-transitory memory including first executable instructions, which, when executed by the first processor (0135 The computer-readable medium can be stored on any suitable computer readable media such as RAMs, ROMs ), cause the first processor to: prior to authorization of a transaction (fig.2, token service provider sends the token to the mobile before authentication of the token and cryptogram S140 and S150): receive, from a merchant plug-in (MPI) computing device, via a directory server, a token and a first cryptogram for the transaction, the first cryptogram unique to the transaction (0025 —to authenticate a transaction with the dynamic transaction card based on alignment between a token and cryptogram received from the dynamic transaction card at a POS system.) Tfig.2, ACQUIRER received the TOKEN +CRYPTOGRAM S150 and S140 from the MARHCANT system/POS, i.e. MPI computing device,0026 POS”) systems at vendors); and then decrypt the token into sensitive data (0053 to decrypt the cryptogram by retrieving—from a domain name system affiliated with an issuer of the dynamic transaction card—cryptographic protocols corresponding to the cryptogram (and/or cryptogram generator) programmed into the dynamic transaction card); and validate the first cryptogram, based on one or more session keys (0025 to the dynamic transaction card, as shown in FIG. 2. (Alternatively, the dynamic transaction card can generate the token via a token generator stored locally on the dynamic transaction card, wherein outputs of the local token generator on the dynamic transaction card are known by a select external entity—such as the affiliated financial institution or an authentication server— to authenticate a transaction with the dynamic transaction card based on alignment between a token and cryptogram received from the dynamic transaction card at a POS system.) and [0098] the dynamic transaction card is pre-loaded with multiple cryptogram generators (e.g., “secret keys” for generating different varieties of cryptograms); and an issuer server computing device (fig.2, Issuer server received the Auth Request.. ) a coupled in communication with the digital service server, via a network, the issuer server computing device including a second processor and a second non-transitory memory (0135 The computer-readable medium can be stored on any suitable computer readable media such as RAMs, ROMs ), the second non-transitory memory including second executable instructions, which, when executed by the second processor, cause the second processor to, based on the first cryptogram not being validated ( 0134 the dynamic transaction card can thus authenticate a transaction with a transaction method hosted by the dynamic transaction card, such as by requiring a valid fingerprint scan at the dynamic transaction card and/or by requiring a wireless connection between the dynamic transaction card and an associated computing device (e.g., a smartphone), and the dynamic transaction card can selectively supply transaction data for a selected transaction method accordingly to enable secure): set a validation flag to a defined value indicating that the first cryptogram is not valid ( 0036 The POS system can then transmit these encrypted data to a payment processor, which interfaces with the token generator and/or the financial institution to authenticate these encrypted data as a proper token and cryptogram pair before debiting and crediting of the user's account and the merchant's account to complete the transaction. (However, in response to receipt of the token exclusively (i.e., without the cryptogram) or receipt of the token with a different cryptogram, the payment processor may flag the transaction as fraudulent or otherwise unexpected.) and 0068 if a communication is not received from the mobile computing device within a threshold period of time (e.g., 500 milliseconds) of transmitting the inquiry, the dynamic transaction card can transition into a locked state (or reattempt wireless communication with the mobile computing device by transmitting a second inquiry before transitioning into the locked state) in which emulation of a transaction method by the dynamic transaction card in a subsequent transaction is disabled, i.e. not valid , such as until a passcode is entered into and authenticated at the dynamic transaction card or until a wireless connection is again established with the mobile computing device, ); and send, to a user device of a user, an authentication request message, as an authentication step-up, to verify the user and the authenticity of the transaction (0068 the dynamic transaction card is operable in a sleep mode (or other low-power state) when not in use and occasionally transitions into a test mode to check-in with the associated computing device to maintain authorization of use of the dynamic transaction card). Sandelov does not disclose prior to authorization of a transaction: then based on the first cryptogram not being validated: setting a validation flag to a defined value indicating that the first cryptogram is not valid; sending, to a user device of a user, an authentication request message, as an authentication step-up, to verify the user and the authenticity of the transaction. However, Laxminarayanan discloses prior to authorization of a transaction: then based on the first cryptogram not being validated: setting a validation flag to a defined value indicating that the first cryptogram is not valid ( 0057-0058 If the cryptogram was not validated by the payment processing network 107 , then, the issuer computer 109 may want to perform additional authentication processing with respect to the user device 102 and/or the user of the user device 102 before authorizing the transaction. In some embodiments, issuer computer 109 may include other relevant information in the authorization response message, such as risk analysis information.); sending, to a user device of a user, an authentication request message, as an authentication step-up, to verify the user and the authenticity of the transaction (0057-0058 If the cryptogram was not validated by the payment processing network 107 , then, the issuer computer 109 may want to perform additional authentication processing with respect to the user device 102 and/or the user of the user device 102 before authorizing the transaction). Sandelov and Laxminarayanan are both considered to be analogous to the claimed invention because they are in the same field of transaction processing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sandelov to incorporate the teachings of Laxminarayanan and provide user authentication before processing the transition. Doing so would prevent fraudulent transaction, thereby increasing the protection for the transaction. As per claim 3. Sandelov and Laxminarayanan The computer-implemented method of claim 1, Sandelov discloses further comprising, based on a response to the authentication request message not being received from the user for a predetermined amount time, rejecting, by an issuer server of an issuer, the transaction(0053 when a transaction is made with the dynamic transaction card, the dynamic transaction card can communicate the token, tokenized PAN, PAN, or other payment account identifier to the POS system through the magnetic stripe emulator, transmitter (e.g., antenna), or other communication means, the POS system can route the token to the token generator, acquirer, and/or payment network, the token generator, acquirer, and/or payment network can generate and send a request to the user account associated with the dynamic transaction card, and a native application executing on the user's computing device can send the cryptogram to the requesting entity for payment verification. The payment network then cooperates with an issuer of the transaction method and the token generator: to confirm the identity of the dynamic transaction card emulated in the transaction method by accessing a registry of cryptograms associated with the dynamic transaction card; to decrypt the cryptogram by retrieving—from a domain name system affiliated with an issuer of the dynamic transaction card—cryptographic protocols corresponding to the cryptogram (and/or cryptogram generator) programmed into the dynamic transaction card; to decrypt the token to identify the transaction method; to authenticate the transaction with the transaction method based on the decrypted cryptogram and the decrypted token, and to pass back to the POS system confirmation of the transaction, such as in the form of a PAN product identifier and a token assurance level). As per claim 4. Sandelov and Laxminarayanan discloses The computer-implemented method of claim 1, Sandelov further comprising, based on a response to the authentication request message not being received from the user after a number of attempts, rejecting, by an issuer server of an issuer, the transaction (0089 in response to selection of the first encrypted transaction method (e.g., a virtual credit card), the dynamic transaction card can: generate or access a first magnetic stripe sequence command corresponding to (e.g., communicating) the cryptogram and the token representing the first transaction method; and prepare the magnetic stripe emulator to drive the magnetic stripe emulator according to the first magnetic stripe sequence command. Therefore, in response to detecting a magnetic stripe card reader proximal the dynamic transaction card, the controller can drive the magnetic stripe emulator according to the first magnetic stripe sequence command, thereby transmitting the cryptogram and the token of the first transaction method to the magnetic stripe card reader at a POS system. As described above, the POS system can then transmit the cryptogram, the token, and transaction information (e.g., payment amount requested and location of the transaction) to a payment issuer affiliated with a financial institution hosting the transaction method. Subsequently, in response to concurrent receipt of the cryptogram and the token, the payment issuer may issue payment to the merchant, to authorize the transaction. However, in response to selection of a second transaction method in the set of unencrypted transaction methods, the dynamic transaction card can: generate or access a second magnetic stripe sequence command corresponding to unencrypted transaction account information, such as credit card numbers, account holder name, account holder address, etc. in lieu of a cryptogram and a token. In response to selection of a second transaction method, the controller of the dynamic transaction card can drive the magnetic stripe emulator according to the second magnetic stripe sequence command, thereby transmitting the unencrypted transaction account information of the second transaction method to the magnetic stripe card reader at a POS system). As per claim 5. Sandelov and Laxminarayanan discloses The computer-implemented method of claim 1, Sandelov further comprising: based on a response to the authentication request message being received: generating, by an issuer server of an issuer, a first message including a validation result and the sensitive data; and transmitting, by the issuer server, the first message to MPI computing device (0095 an external cryptogram generator, such as a dynamic transaction card issuer, may preload the dynamic transaction card with a group of cryptograms and supply a log (or registry) of the group of cryptograms to a financial institution affiliated with the dynamic transaction card issuer. Upon receipt of the dynamic transaction card, the user may pair the dynamic transaction card with the mobile computing device, thereby informing the financial institution that the (particular) dynamic transaction card including the (particular) group of cryptograms corresponds to the (particular) user affiliated with the (particular) mobile computing device. Thus, the native application of the mobile computing device can load a set of tokens representing a set of transaction methods affiliated with the (particular) user. The dynamic transaction card can download—in real-time, sequentially, or asynchronously—the set of tokens from the mobile computing device and store the tokens in local memory. Additionally, the dynamic transaction card can pair each token in the set of tokens with a cryptogram in the group of cryptograms. Thus, the dynamic transaction card can generate a set of magnetic stripe sequence commands representing each token and cryptogram pair and, thus, representing each encrypted transaction method. In response to detecting a magnetic stripe card reader proximal the dynamic transaction card and in response to selection of a particular transaction method, the dynamic transaction card can drive the magnetic stripe emulator to output a particular magnetic stripe sequence command corresponding to the cryptogram and token pair representing the particular transaction method). As per claim 6. Sandelov and Laxminarayanan discloses The computer-implemented method of claim 5, Laxminaryanan wherein the validation result includes the defined value indicating that the first cryptogram is not valid ( 0057-0058 If the cryptogram was not validated by the payment processing network 107 , then, the issuer computer 109 may want to perform additional authentication processing with respect to the user device 102 and/or the user of the user device 102 before authorizing the transaction. In some embodiments, issuer computer 109 may include other relevant information in the authorization response message, such as risk analysis information). As per claim 7. Sandelov and Laxminarayanan discloses The computer-implemented method of claim 6, Sandelov discloses further comprising: validating, by the digital service server, the token; and wherein the validation result includes a verification value indicative of successful validation of the token(0050 when a transaction is made with the dynamic transaction card, a local token generator—stored on the dynamic transaction card and synchronized with an authentication server—can generate a token and the dynamic transaction card can communicate the token, encrypted (e.g., “tokenized”) PAN, PAN, or other payment account identifier to the POS system through the magnetic stripe emulator, transmitter (e.g., antenna), or other communication means, and the native application executing on the user's computing device can communicate the cryptogram to the POS system. The token and cryptogram are then routed from the POS to the payment network). As per claim 8. Sandelov and Laxminarayanan discloses the computer-implemented method of claim 1, Sandelov discloses further comprising: receiving, by the MPI computing device, from the user device, the sensitive data and the first cryptogram (0093 fig.2, the dynamic transaction card can request and receive the current location from the mobile computing device at the Merchant); generating, by the MPI computing device, the token for the sensitive data (0098 , the dynamic transaction card is pre-loaded with multiple cryptogram generators (e.g., “secret keys” for generating different varieties of cryptograms). 0099 The dynamic transaction card then decrypts the encrypted cryptogram generator during a transaction with the dynamic transaction card. ); and transmitting, by the MPI computing device, an authentication request to the digital service server, via the directory server, the authentication request including the token and the first cryptogram, but not the sensitive data ( 0111 the magnetic stripe card reader (in a merchant 's POS) can thus pass a form of the token and the cryptogram from the dynamic transaction card to an acquirer (i.e., a merchant hosting a POS) and on to a payment network for authentication and fig 2. Merchant sends the authentication request to Acquirer not including the sensitive data). As per claim 9. Sandelov and Laxminarayanan discloses the computer-implemented method of claim 8, Sandelov discloses wherein the sensitive data includes an account number and one or more of: a customer name, a customer address, a merchant name, and/or a merchant address( 0045 a cryptogram can include a unique and encrypted identifier—such as an alphanumeric card address, an encrypted card number, and/or a binary bit sequence identifier—corresponding to and identifying a dynamic transaction card. During a transaction, the dynamic transaction card can output a magnetic sequence that represents the cryptogram in lieu of an unencrypted static identifier of the dynamic transaction card itself (e.g., the dynamic transaction card's serial number or wireless address) in order to further obscure the dynamic transaction card and the identity of its owner). As per claim 10. Sandelov discloses a system for authenticating a transaction on a secure network, the system comprising: a digital service server (0099 a service provider) including a first processor and a first non-transitory memory, the first non-transitory memory including first executable instructions, which, when executed by the first processor (0135 The computer-readable medium can be stored on any suitable computer readable media such as RAMs, ROMs ), cause the first processor to: prior to authorization of a transaction (fig.2, token service provider sends the token to the mobile before authentication of the token and cryptogram S140 and S150): receive, from a merchant plug-in (MPI) computing device, via a directory server, a token and a first cryptogram for the transaction, the first cryptogram unique to the transaction; and then decrypt the token into sensitive data( 0025 —to authenticate a transaction with the dynamic transaction card based on alignment between a token and cryptogram received from the dynamic transaction card at a POS system.) Tfig.2, ACQUIRER received the TOKEN +CRYPTOGRAM S150 and S140 from the MARHCANT system/POS, i.e. MPI computing device,0026 POS”) systems at vendors); and validate the first cryptogram, based on one or more session keys( 0053 to decrypt the cryptogram by retrieving—from a domain name system affiliated with an issuer of the dynamic transaction card—cryptographic protocols corresponding to the cryptogram (and/or cryptogram generator) programmed into the dynamic transaction card 0025 to the dynamic transaction card, as shown in FIG. 2. (Alternatively, the dynamic transaction card can generate the token via a token generator stored locally on the dynamic transaction card, wherein outputs of the local token generator on the dynamic transaction card are known by a select external entity—such as the affiliated financial institution or an authentication server— to authenticate a transaction with the dynamic transaction card based on alignment between a token and cryptogram received from the dynamic transaction card at a POS system.) and [0098] the dynamic transaction card is pre-loaded with multiple cryptogram generators (e.g., “secret keys” for generating different varieties of cryptograms); and an issuer server computing device (fig.2, Issuer server received the Auth Request..) coupled in communication with the digital service server, via a network, the issuer server computing device including a second processor and a second non-transitory memory, the second non-transitory memory including second executable instructions, which, when executed by the second processor, cause the second processor to, based on the first cryptogram not being validated( ( 0134 the dynamic transaction card can thus authenticate a transaction with a transaction method hosted by the dynamic transaction card, such as by requiring a valid fingerprint scan at the dynamic transaction card and/or by requiring a wireless connection between the dynamic transaction card and an associated computing device (e.g., a smartphone), and the dynamic transaction card can selectively supply transaction data for a selected transaction method accordingly to enable secure): set a validation flag to a defined value indicating that the first cryptogram is not valid(0036 The POS system can then transmit these encrypted data to a payment processor, which interfaces with the token generator and/or the financial institution to authenticate these encrypted data as a proper token and cryptogram pair before debiting and crediting of the user's account and the merchant's account to complete the transaction. (However, in response to receipt of the token exclusively (i.e., without the cryptogram) or receipt of the token with a different cryptogram, the payment processor may flag the transaction as fraudulent or otherwise unexpected and 0068 if a communication is not received from the mobile computing device within a threshold period of time (e.g., 500 milliseconds) of transmitting the inquiry, the dynamic transaction card can transition into a locked state (or reattempt wireless communication with the mobile computing device by transmitting a second inquiry before transitioning into the locked state) in which emulation of a transaction method by the dynamic transaction card in a subsequent transaction is disabled, i.e. not valid , such as until a passcode is entered into and authenticated at the dynamic transaction card or until a wireless connection is again established with the mobile computing device ); and send, to a user device of a user, an authentication request message, as an authentication step-up, to verify the user and the authenticity of the transaction( 0068 the dynamic transaction card is operable in a sleep mode (or other low-power state) when not in use and occasionally transitions into a test mode to check-in with the associated computing device to maintain authorization of use of the dynamic transaction card). Sandelov does not disclose prior to authorization of a transaction: then based on the first cryptogram not being validated: setting a validation flag to a defined value indicating that the first cryptogram is not valid; sending, to a user device of a user, an authentication request message, as an authentication step-up, to verify the user and the authenticity of the transaction. However, Laxminarayanan discloses prior to authorization of a transaction: then based on the first cryptogram not being validated: setting a validation flag to a defined value indicating that the first cryptogram is not valid ( 0057-0058 If the cryptogram was not validated by the payment processing network 107 , then, the issuer computer 109 may want to perform additional authentication processing with respect to the user device 102 and/or the user of the user device 102 before authorizing the transaction. In some embodiments, issuer computer 109 may include other relevant information in the authorization response message, such as risk analysis information.); sending, to a user device of a user, an authentication request message, as an authentication step-up, to verify the user and the authenticity of the transaction (0057-0058 If the cryptogram was not validated by the payment processing network 107 , then, the issuer computer 109 may want to perform additional authentication processing with respect to the user device 102 and/or the user of the user device 102 before authorizing the transaction). Sandelov and Laxminarayanan are both considered to be analogous to the claimed invention because they are in the same field of transaction processing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sandelov to incorporate the teachings of Laxminarayanan and provide user authentication before processing the transition. Doing so would prevent fraudulent transaction, thereby increasing the protection for the transaction. As per claim 12. Sandelov and Laxminarayanan discloses The system of claim 10, Sandelov wherein the second executable instructions, when executed by the second processor, cause the second processor to reject the transaction based on a response to the authentication request message not being received, for a predetermined amount time, from the user( [0035] In response to a request to authorize the card—such as including a unique identifier of the dynamic transaction card, the cryptogram loaded onto the dynamic transaction card, and/or login information entered by the user within the native application—received from the user via the native application, the financial institution may: identify the dynamic transaction card based on the log described above; confirm a match between the dynamic transaction card and the account information provided by the user; and query a token generator to generate a token (e.g., an encrypted representation of sensitive account information, such as a credit card number) if the cryptogram, dynamic transaction card, and user account information match. The token generator can then return this token to the mobile computing device via the Internet. Upon receipt of the token, the native application can: visually indicate to the user that the dynamic transaction card has been authorized; store the token in local memory on the mobile computing device and upload the token to the dynamic transaction card immediately before a transaction with a POS system; or transmit the token to the dynamic transaction card immediately for local storage on the dynamic transaction card. (Alternatively, the dynamic transaction card can be loaded with a token generator integrated into the dynamic transaction card. The token generation can generate a single-use or multi-use token for emulation during a transaction method.)). As per claim 13. Sandelov and Laxminarayanan discloses The system of claim 10, Sandelov wherein the second executable instructions, when executed by the second processor, cause the second processor to reject the transaction based on a response to the authentication request message not being received, after a number of attempts, from the user ( [0068] In a similar implementation, the dynamic transaction card is operable in a sleep mode (or other low-power state) when not in use and occasionally transitions into a test mode to check-in with the associated computing device to maintain authorization of use of the dynamic transaction card. For example, the dynamic transaction card can transition from the sleep mode into the test mode once per five-second interval (or at any other frequency or interval); once in the test mode, the wireless communication module within the dynamic transaction card can broadcast an inquiry for the unique wireless address of the mobile computing device affiliated with the dynamic transaction card. In this example, if a communication is received (wirelessly) from the mobile computing device in response to transmission of the inquiry (e.g., within 500 milliseconds of transmitting the inquiry), the dynamic transaction card can preserve authorization of its use and transition back into the sleep mode. However, in this example, if a communication is not received from the mobile computing device within a threshold period of time (e.g., 500 milliseconds) of transmitting the inquiry, the dynamic transaction card can transition into a locked state (or re-attempt wireless communication with the mobile computing device by transmitting a second inquiry before transitioning into the locked state) in which emulation of a transaction method by the dynamic transaction card in a subsequent transaction is disabled, such as until a passcode is entered into and authenticated at the dynamic transaction card or until a wireless connection is again established with the mobile computing device, as shown in FIG. 8. Therefore, in this implementation, the dynamic transaction card can preserve authorization of its use until a scheduled check-in with the affiliated mobile computing device fails to yield a viable wireless connection with the mobile computing device. Alternatively, the dynamic transaction card can execute Block S 120 to establish a (constant) wireless connection with the mobile computing device, to authorize its use in a subsequent transaction while the wireless connection persists, and to disable its use (e.g., disable emulation of a transaction method) when the wireless connection fails or is lost). As per claim 14. Sandelov and Laxminarayanan discloses The system of claim 10, Sandelov wherein the second executable instructions, when executed by the second processor, cause the second processor to, based on a response to the authentication request message being received: generate a first message including a validation result and the sensitive data; and transmit the first message to the MPI computing device( [0036] Upon receipt of the token, the dynamic transaction card can associate the token with the cryptogram, such as by compiling these data into a magnetic stripe sequence command thereby correlating the transaction method represented by the token with a unique identifier of the dynamic transaction card. Subsequently, in response to detecting a magnetic stripe card reader of a POS system proximal the dynamic transaction card, the dynamic transaction card (e.g., a controller in the dynamic transaction card) can drive the magnetic stripe emulator according to the magnetic stripe sequence command, thereby communicating both the cryptogram and the token to the POS system. The POS system can then transmit these encrypted data to a payment processor, which interfaces with the token generator and/or the financial institution to authenticate these encrypted data as a proper token and cryptogram pair before debiting and crediting of the user's account and the merchant's account to complete the transaction. (However, in response to receipt of the token exclusively (i.e., without the cryptogram) or receipt of the token with a different cryptogram, the payment processor may flag the transaction as fraudulent or otherwise unexpected.)). As per claim 15. Sandelov and Laxminarayanan discloses The system of claim 14, Laxminarayanan discloses wherein the validation result includes the defined value indicating that the first cryptogram is not valid (0057-0058 If the cryptogram was not validated by the payment processing network 107 , then, the issuer computer 109 may want to perform additional authentication processing with respect to the user device 102 and/or the user of the user device 102 before authorizing the transaction. In some embodiments, issuer computer 109 may include other relevant information in the authorization response message, such as risk analysis information). As per claim 16. Sandelov and Laxminarayanan discloses The system of claim 10, Sandelov discloses further comprising: the MPI computing device, the MPI computing device including a third processor and a third non-transitory memory, the third non-transitory memory including third executable instructions ( 0093 fig.2, the dynamic transaction card can request and receive the current location from the mobile computing device at the Merchant), which, when executed by the third processor, cause the third processor to: receive, from the user device, the sensitive data and the first cryptogram; generate the token for the sensitive data(0047 recites establishing a wireless connection with a mobile computing device; and Block S 130 of the method S 100 recites, in response to establishing the wireless connection with the mobile computing device, accessing a first token associated with the first cryptogram. Generally, in Blocks S 120 and S 130 , the dynamic transaction card connects to the user's mobile computing device via a wireless network (e.g., a local ad hoc network) to retrieve data pertinent to completing a transaction method stored on the dynamic transaction card. In particular, the dynamic transaction card can execute Blocks S 120 and S 130 to download (and/or generate) a token corresponding to a particular transaction method—accessed previously by the native application executing on the user's computing device, as described above—which the dynamic transaction card then combines with the cryptogram to generate a magnetic stripe sequence command for this transaction method); and transmit an authentication request to the digital service server, via the directory server, the authentication request including the token and the first cryptogram, but not the sensitive data(0111 the magnetic stripe card reader (in a merchant 's POS) can thus pass a form of the token and the cryptogram from the dynamic transaction card to an acquirer (i.e., a merchant hosting a POS) and on to a payment network for authentication and fig 2. Merchant sends the authentication request to Acquirer not including the sensitive data). As per claim 17. Sandelov and Laxminarayanan discloses The system of claim 16, Sandelov wherein the sensitive data includes an account number and one or more of: a customer name, a customer address, a merchant name, and/or a merchant address ([0035] In response to a request to authorize the card—such as including a unique identifier of the dynamic transaction card, the cryptogram loaded onto the dynamic transaction card, and/or login information entered by the user within the native application—received from the user via the native application, the financial institution may: identify the dynamic transaction card based on the log described above; confirm a match between the dynamic transaction card and the account information provided by the user; and query a token generator to generate a token (e.g., an encrypted representation of sensitive account information, such as a credit card number) if the cryptogram, dynamic transaction card, and user account information match. The token generator can then return this token to the mobile computing device via the Internet. Upon receipt of the token, the native application can: visually indicate to the user that the dynamic transaction card has been authorized; store the token in local memory on the mobile computing device and upload the token to the dynamic transaction card immediately before a transaction with a POS system; or transmit the token to the dynamic transaction card immediately for local storage on the dynamic transaction card. (Alternatively, the dynamic transaction card can be loaded with a token generator integrated into the dynamic transaction card. The token generation can generate a single-use or multi-use token for emulation during a transaction method). As per claim 18. Sandelov and Laxminarayanan discloses The system of claim 16, Sandelov wherein the third executable instructions, when executed by the third processor, further cause the third processor to: receive an authentication value from the issuer server, via the directory server; and transmit the authentication value and the token to the issuer server (0034] The financial institution (and/or the dynamic transaction card manufacturer) can then send the dynamic transaction card to a user (i.e., an account holder at the financial institution), such as via a physical mail service. Upon receipt of the dynamic transaction card, the user may trigger the dynamic transaction card to wirelessly pair to her smartphone. Through a native application executing on her smartphone, the user may then request authorization of the dynamic transaction card, such as by logging in to her financial account—hosted by the financial institution—within the native application) . 07-21-aia AIA Claim (s) 2 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Sandelov et al 2018/0005227 in view of Laxminarayanan et al US 2016/0301683 and Lakka et al US 2019/0108515 . As per claim 2. Sandelov and Laxminarayanan The computer-implemented method of claim 1, the combination does not explicitly discloses further comprising: diversifying, by the digital service server, a master key from an issuer master symmetric key, which is specific to an issuer; and diversifying, by the digital service server, one or more session keys from the diversified master key based on an application transaction count (ATC), the one or more session keys including the one or more diversified session keys. Lakka discloses diversifying, by the digital service server, a master key from an issuer master symmetric key, which is specific to an issuer; and diversifying, by the digital service server, one or more session keys from the diversified master key based on an application transaction count (ATC), the one or more session keys including the one or more diversified session keys (0026 The DSS 110 , in turn, is configured to map the received token to the account number (e.g., the PAN, etc.) for the consumer's payment account and to generate to a directory server nonce (DSN). The DSN may include a number, for example, an unpredictable number, utilized to provide entropy into the AAV and/or an issuer authentication value (IAV) associated therewith. In addition, the DSS 110 is configured to validate the received DSRP cryptogram for the transaction (i.e., perform a cryptographic key validation). Specifically, the DSS 110 is configured to diversify a master key from the issuer master symmetric key (e.g., a key generated, by the DSS 110 , for the issuer 104 , etc.) and then to diversify one or more session keys from the master key (e.g., based on the ATC maintained by the DSS 110 , etc.). The DSS 110 is configured to use the session key(s) to validate the DSRP cryptogram received from the directory server 118 . Further, when the cryptogram is validated, the DSS 110 is configured to increment the ATC, for example, by recording the ATC value as a used value (thereby potentially preventing its repeated use), etc. Additionally, or alternatively, when the DSRP cryptogram is not validated, the DSS 110 is configured to store the DSRP data in memory in association with the ATC and/or the DSN ). Sandelov and Laxminarayanan and Lakka are both considered to be analogous to the claimed invention because they are in the same field of transaction processing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sandelov to incorporate the teachings of Laxminarayanan, teaching of Lakka and provide user authentication before processing the transition. Doing so would prevent fraudulent transaction, thereby increasing the protection for the transaction. As per claim 11. Sandelov and Laxminarayanan discloses The system of claim 10, the combination does not disclose wherein the first executable instructions, when executed by the first processor, cause the first processor to: diversify a master key from an issuer master symmetric key, which is specific to an issuer; and diversify one or more session keys from the diversified master key, based on an application transaction count (ATC). However, Lakka discloses wherein the first executable instructions, when executed by the first processor, cause the first processor to: diversify a master key from an issuer master symmetric key, which is specific to an issuer; and diversify one or more session keys from the diversified master key, based on an application transaction count (ATC)( [0026] The DSS 110 , in turn, is configured to map the received token to the account number (e.g., the PAN, etc.) for the consumer's payment account and to generate to a directory server nonce (DSN). The DSN may include a number, for example, an unpredictable number, utilized to provide entropy into the AAV and/or an issuer authentication value (IAV) associated therewith. In addition, the DSS 110 is configured to validate the received DSRP cryptogram for the transaction (i.e., perform a cryptographic key validation). Specifically, the DSS 110 is configured to diversify a master key from the issuer master symmetric key (e.g., a key generated, by the DSS 110 , for the issuer 104 , etc.) and then to diversify one or more session keys from the master key (e.g., based on the ATC maintained by the DSS 110 , etc.). The DSS 110 is configured to use the session key(s) to validate the DSRP cryptogram received from the directory server 118 . Further, when the cryptogram is validated, the DSS 110 is configured to increment the ATC, for example, by recording the ATC value as a used value). Sandelov and Laxminarayanan and Lakka are both considered to be analogous to the claimed invention because they are in the same field of transaction processing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sandelov to incorporate the teachings of Laxminarayanan, teaching of Lakka and provide user authentication before processing the transition. Doing so would prevent fraudulent transaction, thereby increasing the protection for the transaction . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Wong et al US 2014/0337236 discloses 0112 In some embodiments, mobile device 101 may decrypt the provisioning scripts using the personalization session key used to generate the cryptogram. 0076] Master encryption key database 202(K) may store any encryption keys by which a cryptogram or other data may be decrypted or verified. For example, in some embodiments, each issuer, payment processing network, or device manufacturer may be associated with a different secret encryption key. Thus, if user authentication information provided in a request for provisioning includes a cryptogram, the appropriate master encryption key may be required to decrypt and validate the cryptogram. In some embodiments, user, device, or account information may be used to determine an appropriate master encryption key to retrieve from database 202(K) In some embodiments, the master key may be used to derive a specific key in order to verify the cryptogram . Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm. 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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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. /ABU S SHOLEMAN/Primary Examiner, Art Unit 2496 Application/Control Number: 18/962,229 Page 2 Art Unit: 2496 Application/Control Number: 18/962,229 Page 3 Art Unit: 2496 Application/Control Number: 18/962,229 Page 4 Art Unit: 2496
Prosecution Insights