DETAILED ACTION
Notice of Pre-AIA or AIA Status
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
Applicant’s arguments, see page 9, filed 07/16/2026, with respect to the previous rejection of claims 1, 4-5, 7-10, 12-13, 16-18, 20, and 22-26 under 35 U.S.C. § 112(a) have been fully considered and are persuasive. The rejection of claims 1, 4-5, 7-10, 12-13, 16-18, 20, and 22-26 under § 112(a) written description has been withdrawn in response to the amendment to the claims no longer reciting a dynamic data element per se being configured to change.
Applicant’s arguments, see page 10, filed 07/16/2026, with respect to the previous rejection of claims 1, 4-5, 7-10, 12-13, 16-18, 20, and 22-26 under 35 U.S.C. § 112(b) have been fully considered, but they are not persuasive. The previous Non-Final rejection mailed 04/17/2026 (see pages 7-8) rejected independent claims 1, 10, and 18 for containing the limitation “wherein the dynamic data element is configured to change for each initialization request message”, where the limitation was indefinite because it was unclear what the newly claimed “for each request” was referring to, since the claims previously recited “an initialization request message”, not “requests” plural.
Here, the limitation now reads “wherein the dynamic data element is different for each initialization request message transmitted by the communication device”. The same issue of the claim reciting “for each initialization request message” while the claims only previously recite “an initialization request message”, not “requests” or “request messages” plural. Therefore, the insufficient antecedent basis rejection will be maintained below.
Applicant's arguments, see pages 10-13, filed 07/16/2026, with respect to the rejection of claims 1, 4-5, 7-10, 12-13, 16-18, and 22-26 under 35 U.S.C. § 102(a)(2) have been fully considered but they are not persuasive.
Applicant first argues on pages 11-12 that, “Claim 1 recites "generating, by a communication device, an initialization request message to provision access data to a digital wallet application on the communication device, wherein the communication device comprises a mobile phone, wherein the access data comprises account information." The Examiner asserts that paragraphs [0109]-[0110] of Oosthuizen teaches this aspect of the claim.
Paragraphs [0109]-[0110] of Oosthuizen describe verifying an association between an enrolled application and a user. The communication device may be used to conduct a transaction.
Therefore, Oosthuizen describes that an application on a communication device is enrolled and that the communication device is used to conduct a transaction.
This does not teach that a communication device generates an initialization request message to provision access data to a digital wallet application on the communication device.
Specifically, Oosthuizen is not directed to provisioning access data to a digital wallet application a communication device, as described in claim 1.”
The Examiner respectfully disagrees.
The Examiner first submits that the broadest reasonable interpretation of the claimed “generating, by a communication device, an initialization request message to provision access data to a digital wallet application on the communication device” is met by the Oosthuizen reference disclosing at least “The user may be conducting a transaction, such as a financial transaction, against a user account (114) (e.g. a financial account) maintained by an entity (112). The user may be using an application (122), resident on a communication device (104), or another appropriate device to conduct the transaction and may be prompted for his or her authorization of the transaction. As mentioned, the application (122) and/or communication device (104) may have previously been enrolled with a remote server (102) operated by the entity (112) or by an authentication service provider on behalf of the entity. The remote server (102) may receive (302) a verification request from the entity responsive to the user (116) transacting or requesting to transact against the user account (114). The request may identify the relevant communication device (104), for example by including the verified device identifier or a communication address of the device (104) or alternatively a user identifier pointing to the verified device identifier or a communication address of the device (104). The verification request may be received together with a transaction authorization request” (Oosthuizen [0109-0110], underline added). Oosthuizen explicitly discloses that the server may receive a verification request message, generated by the relevant application resident on the communication device being used by the user to conduct a transaction, and the said request message is perfectly capable of performing the claimed intended use of the request “to provision access data to a digital wallet application on the communication device”. In response to applicant's argument that “Oosthuizen is not directed to provisioning access data to a digital wallet application a communication device”, a recitation of the intended use (i.e., “to provision access data to a digital wallet application on the communication device”) of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim. This is especially the case within Oosthuizen reference as the said request message disclosed by Oosthuizen is what allows for access data (Oosthuizen [0067-0069] account information and database) to later be received by the communication device from the server computer as later claimed (Oosthuizen [0120-0122] “Once the communication device (104) has been verified, the transaction (e.g. financial transaction) may be allowed to proceed and the remote server (102) may transmit (326) a verification message to the entity to indicate to the entity that the association has been verified and that the transaction may continue. The transaction may, for example, be authorized. The remote server (102) may transmit (328) a verification and/or authorization message to the communication device (104). The verification and/or authorization message may indicate verification of the association between the application (122) and the user and/or authorization of the transaction and may be transmitted from the remote server (102) to the communication device (104) via the secure communication channel. The communication device (104) may receive (330) the verification and/or authorization message from the remote server (102)”).
Therefore, the rejection under 35 U.S.C. § 102(a)(2) will be maintained.
Applicant then argues on pages 12-13 that Oosthuizen does not teach the claimed invention accompanied by a recitation of the claim language, and then attests that independent claims 1, 10, and 18 are therefore allowable.
The Examiner respectfully disagrees.
Since applicant does not give any further explanation as to how the previously cited art differentiates from the claimed invention other than repeating the amendments made to the claim and making the conclusory statement that the prior art does not allegedly teach the claim limitations, the examiner defers to the rejection below as a response to this argument.
Applicant's arguments, see page 13, filed 07/16/2026, with respect to the rejection of claim 20 under 35 U.S.C. § 103 have been fully considered but they are not persuasive.
Since applicant does not give any further explanation as to how the previously cited art differentiates from the claimed invention other than asserting dependence upon an allegedly allowable claim, the examiner defers to the rejection below as a response to this argument.
Applicant finally attests that new claims are allowable for being dependent upon an allegedly allowable claim and Applicant further alleges that none of the previously cited art teaches or suggests the content of new claims 27-28. Since applicant does not give any further explanation as to how the previously cited art differentiates from the claimed invention other than dependence upon an allegedly allowable claim and making the conclusory statement that the prior art does not allegedly teach the claim limitations, the examiner defers to the rejection below as a response to this argument.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 4-5, 7-10, 12-13, 16-18, 20, 22, 24-25 and 27-28 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding Claims 1, 10, and 18:
Amended independent claims 1, 10, and 18 recite “wherein the dynamic data element is different for each initialization request message transmitted by the communication device”. The limitation is indefinite because it is currently unclear what the newly claimed “for each initialization request message” is referring to, since the claims previously recite “an initialization request message”, not “requests” plural. Therefore, there is insufficient antecedent basis for this limitation in the claim.
The dependent claims fall together accordingly.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 4-5, 7-10, 12-13, 16-18, 22, 24-25 and 28 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Oosthuizen; Gerhard Gysbert (US Publication No. Us 2019/0251561 A1) hereinafter Oosthuizen.
Regarding Claims 1 and 10:
Claim 1. Oosthuizen discloses a method comprising: generating, by a communication device, an initialization request message to provision access data to a digital wallet application on the communication device by storing account information to the digital wallet application (Oosthuizen Fig. 3, [0109-0110], [0067-0069] account information and database; [0075-0076] “The communication device (104) may have an application (122) installed thereon. The application (122) may be provided by the entity (112) (or by an authorisation [sic] service provider on behalf of the entity) and may enable the user (116) to transact against or otherwise interact with the user account (114) using the communication device (104). The application (122) and/or communication device (104) may be configured to establish a secure communication channel with the remote server (102) via which the communication device (104) and/or application (122) are uniquely identifiable by the remote server (102). In this manner, the remote server (102) is able to distinguish messages and/or data received from the communication device (104) from messages and/or data received from other communication devices and to attribute received messages and/or data as having been received from the communication device (104) and/or application (122). There thus exists a verified association (130) between: the user (116) and the user account (114); the portable credential device 108) and the user account (114); and, the portable credential device (108) and the user (116). Further, a secure communication channel (132) can be established between with the remote server (102) and communication device (104)/application (122) by way of which the communication device (104) and/or application (122) are uniquely identifiable by the remote server (102)”), wherein the communication device comprises a mobile phone (Oosthuizen Fig. 1 communication device is a mobile phone, [0075]), wherein the access data provisioned to the digital wallet application comprises account information (Oosthuizen [0067-0069] account information and database); transmitting, by the communication device, the initialization request message to a server computer (Oosthuizen Fig. 3, [0109-0110]); receiving, by the communication device in response to the initialization request message to provision access data to the digital wallet application, a dynamic data element from the server computer (Oosthuizen Fig. 3, [0109-0112], [0090-0091]), wherein the dynamic data element is different for each initialization request message transmitted by the communication device (Oosthuizen Fig. 3, [0089-0093] “The token may include additional information, such as a cryptograph which is configured to validate that the token is relevant to the current session and not a replay attack. Obtaining the token may include generating the cryptograph. The cryptograph may serve to prevent replay of the token and may for example include a set of data elements (e.g. a nonce) which have been signed by the portable credential device. The set of data elements may include a random number received from the server or the like.”, [0109-0112]); performing, by the communication device, a message exchange process with a user device via near field communications (NFC) (Oosthuizen [0089-0092] NFC contemplated), wherein the user device comprises a payment card (Oosthuizen Fig. 1 portable credential device is a card, [0069]), wherein in the message exchange process that is performed via NFC, the dynamic data element is transmitted from the communication device to the user device (Oosthuizen [0089-0094] NFC contemplated), and a cryptogram is received by the communication device from the user device (Oosthuizen [0109-0116]), wherein the cryptogram is generated by the user device by: performing encryption on static data elements, including a user device identifier, using a first encryption key on the user device to generate a second encryption key, wherein the user device identifier is an account number, wherein the first encryption key is a base key associated with an issuer of an account, and encrypting the dynamic data element using the second encryption key (Oosthuizen [0109-0116]; [0069-0071] the credential may comprise a cryptogram or encryption key and/or one or more of a primary account number “The AC card key may be generated using an AC master key which may be used by an authorization [sic] system associated with an issuer of the portable credential device to decrypt messages from the portable credential device … For example, in the case of a user financial account, the user identifier (114A) and credential (114B) may be issued to and associated with the user (116) when the user registers or opens the financial account with the entity (112)”; [0091-0094] an encryption key can be used to create the credential for example; claim 6 “wherein at least a portion of the token has been derived by performing an operation on the data elements and the credential, and wherein the operation is one of a hash of the data elements and the credential or a signing or encryption of the data elements using the credential”); transmitting, by the communication device, a provisioning request message including the user device identifier and the cryptogram to the server computer (Oosthuizen [0117-0119]); and receiving, by the communication device from the server computer, the access data (Oosthuizen [0120-0122]), wherein in response to receiving the access data, the communication device is configured to conduct transactions (Oosthuizen [0067-0069] and [0075] may conduct financial transactions), wherein the mobile phone and the user device are associated with a same user (Oosthuizen Fig. 1 user clearly controls both the portable credential device and communication device, [0075]).
Claim 10 discloses substantially the same content and is therefore rejected under the same rationales. Oosthuizen discloses a communication device comprising: a processor; and a computer readable medium, coupled to the processor, the computer readable medium comprising code, executable by the processor (Oosthuizen [0158-160]).
Regarding Claims 4 and 12:
Claim 4. Oosthuizen further discloses the method of claim 1 (Oosthuizen Fig. 3, [0109-0110]), wherein the server computer is in communication with an access data vault, and wherein the server computer retrieves the access data from the access data vault (Oosthuizen [0067-0074]).
Regarding Claims 5 and 13:
Claim 5. Oosthuizen further discloses the method of claim 1 (Oosthuizen Fig. 3, [0109-0110]), wherein the message exchange process utilizes get processing option and application identifier request and response messages (Oosthuizen [0069-0072] EMV communications contemplated).
Claim 13 discloses substantially the same content and is therefore rejected under the same rationales.
Regarding Claims 7 and 16:
Claim 7. Oosthuizen further discloses the method of claim 1 (Oosthuizen Fig. 3, [0109-0110]), wherein the access data provisioned to the communication device is used to conduct a transaction by interfacing with an access device (Oosthuizen [0068-0069] may conduct financial transactions).
Claim 16 discloses substantially the same content and is therefore rejected under the same rationales.
Regarding Claims 8 and 17:
Claim 8. Oosthuizen further discloses the method of claim 1 (Oosthuizen Fig. 3, [0109-0110]), wherein the first encryption key is derived from data existing on the user device (Oosthuizen [0089-0093] payment credentials can be on the portable credential device).
Claim 17 discloses substantially the same content and is therefore rejected under the same rationales.
Regarding Claim 9:
Claim 9. Oosthuizen further discloses the method of claim 1 (Oosthuizen Fig. 3, [0109-0110]), wherein a numerical value of zero is transmitted from the communication device to the user device in the message exchange process (Oosthuizen [0089-0094] NFC and nonces contemplated).
Regarding Claim 18:
Claim 18. Oosthuizen discloses a method comprising: receiving, by a server computer from a communication device, an initialization request message to provision access data to a digital wallet application on the communication device by storing account information to the digital wallet application (Oosthuizen Fig. 3, [0109-0110], [0067-0069] account information and database; [0075-0076] “The communication device (104) may have an application (122) installed thereon. The application (122) may be provided by the entity (112) (or by an authorisation [sic] service provider on behalf of the entity) and may enable the user (116) to transact against or otherwise interact with the user account (114) using the communication device (104). The application (122) and/or communication device (104) may be configured to establish a secure communication channel with the remote server (102) via which the communication device (104) and/or application (122) are uniquely identifiable by the remote server (102). In this manner, the remote server (102) is able to distinguish messages and/or data received from the communication device (104) from messages and/or data received from other communication devices and to attribute received messages and/or data as having been received from the communication device (104) and/or application (122). There thus exists a verified association (130) between: the user (116) and the user account (114); the portable credential device 108) and the user account (114); and, the portable credential device (108) and the user (116). Further, a secure communication channel (132) can be established between with the remote server (102) and communication device (104)/application (122) by way of which the communication device (104) and/or application (122) are uniquely identifiable by the remote server (102)”), wherein the communication device comprises a mobile phone (Oosthuizen Fig. 1 communication device is a mobile phone, [0075]), wherein the access data provisioned to the digital wallet application comprises account information (Oosthuizen [0067-0069] account information and database); providing, by the server computer to the communication device, a dynamic data element (Oosthuizen Fig. 3, [0109-0110]), the communication device thereafter performing a message exchange process with a user device via near field communications (NFC) (Oosthuizen [0089-0092] NFC contemplated), wherein the dynamic data element is different for each initialization request message transmitted by the communication device (Oosthuizen Fig. 3, [0089-0093] “The token may include additional information, such as a cryptograph which is configured to validate that the token is relevant to the current session and not a replay attack. Obtaining the token may include generating the cryptograph. The cryptograph may serve to prevent replay of the token and may for example include a set of data elements (e.g. a nonce) which have been signed by the portable credential device. The set of data elements may include a random number received from the server or the like.”, [0109-0112]), wherein the user device comprises a payment card (Oosthuizen Fig. 1 portable credential device is a card, [0069]), wherein in the message exchange process that is performed via NFC, the dynamic data element is transmitted from the communication device to the user device, and a cryptogram is received by the communication device from the user device (Oosthuizen [0089-0094] NFC contemplated, [0109-0116]), wherein the cryptogram is generated by the user device by: performing encryption on static data elements, including a user device identifier, using an encryption key on the user device to generate a second encryption key, wherein the user device identifier is an account number, wherein the first encryption key is a base key associated with an issuer of an account, and encrypting the dynamic data element using the second encryption key (Oosthuizen [0109-0116]; [0069-0071] the credential may comprise a cryptogram or encryption key and/or one or more of a primary account number “The AC card key may be generated using an AC master key which may be used by an authorisation [sic] system associated with an issuer of the portable credential device to decrypt messages from the portable credential device … For example, in the case of a user financial account, the user identifier (114A) and credential (114B) may be issued to and associated with the user (116) when the user registers or opens the financial account with the entity (112)”; [0091-0094] an encryption key can be used to create the credential for example; claim 6 “wherein at least a portion of the token has been derived by performing an operation on the data elements and the credential, and wherein the operation is one of a hash of the data elements and the credential or a signing or encryption of the data elements using the credential”); receiving, by the server computer, a provisioning request message including the user device identifier and the cryptogram (Oosthuizen [0117-0119]); and providing, by the server computer, the access data (Oosthuizen [0119-0122]), wherein in response to receiving the access data, the communication device is configured to conduct transactions (Oosthuizen [0067-0069] and [0075] may conduct financial transactions), wherein the mobile phone and the user device are associated with a same user (Oosthuizen Fig. 1 user clearly controls both the portable credential device and communication device; [0075-0076]).
Regarding Claim 22:
Claim 22. Oosthuizen further discloses the method of claim 1 (Oosthuizen Fig. 3, [0109-0110]), wherein a session ID is received by the communication device from the server computer in a same message as the dynamic data element (Oosthuizen [0090-0091] session tokens contemplated), and wherein the provisioning request message further comprises the session ID (Oosthuizen [0089-0091] session tokens contemplated during enrollment “The set of data elements may include a random number received from the server or the like. In some cases, the data elements may include the device identifier and a time stamp. The cryptograph may be generated by the portable credential device or the communication device”).
Regarding Claim 24:
Claim 24. Oosthuizen further discloses the method of claim 22 (Oosthuizen Fig. 3, [0109-0110]), wherein the account information comprises a primary account number associated with a credit card (Oosthuizen [0076], [0067-0069] account information and database, [0089-0090] “The portable credential device (108) may for example be a proximity communication enabled smart card. In the case of the entity being a financial institution the portable credential device may be a proximity communication enabled bank card (e.g. a near field communication (NFC) enabled credit, debit or check card) and the credential may include payment credentials (or a subset thereof) which are usable in conducting a financial transaction against the user account (114)”).
Regarding Claim 25:
Claim 25. Oosthuizen further discloses the method of claim 22 (Oosthuizen Fig. 3, [0109-0110]), wherein the account information comprises a payment token (Oosthuizen [0076], [0067-0069] payment credentials), wherein the method is for provisioning the account information to the mobile phone (Oosthuizen Fig. 1 communication device is a mobile phone, [0075]; [0145] disclosure of the intended use anticipated “In one exemplary scenario, a user may use his or her bank-issued NFC-enabled credit/bank card with his or her NFC-enabled phone to prove that he or she is in possession of the bank issued card and hence that the phone can be enrolled for transacting with the relevant bank against the account with which the bank card is associated”).
Regarding Claim 28:
Claim 28. Oosthuizen further discloses the method of claim 1 (Oosthuizen Fig. 3, [0109-0110]), wherein the communication device comprises an access device emulator application programming interface (ADE API) to communicate directly with a service provider (Oosthuizen Fig. 1 and [0075] application 122 installed within the communication 104 to communicate with an entity 112 “The communication device (104) may have an application (122) installed thereon. The application (122) may be provided by the entity (112) (or by an authorisation [sic] service provider on behalf of the entity) and may enable the user (116) to transact against or otherwise interact with the user account (114) using the communication device (104)”; [0106] “Once enrolled, the user (116) may use the communication device (104) and application (122) installed thereon to interact with the entity (112) remotely, via the communication network (106). As the association between the application (122) and the user has been verified, and as the communication device (104) and/or application (122) is uniquely identifiable by the entity (112), the entity may consider messages, instructions and the like received from the communication device (104) to have originated from the user (116). This may obviate the need for other methods of authentication and may provide a more seamless digital interface between the user and entity”; [0133] “the portable credential device (108) may be a smart card or a proximity communication enabled smart card (e.g. an ISO 14443-4 enabled smart card, bank card, or the like). The token obtaining component (424) may include a proximity communication interface component (426) which is configured to interact with the portable credential device (108) via a proximity communication interface. The proximity communication interface component (426) may provide a radio frequency proximity communication interface (e.g. NFC, RFID, BLE, etc. interface). In one implementation, for example, the proximity communication interface component (426) implements an application protocol data unit (APDU) to facilitate communication between the portable credential device (108) and the communication device (104). The APDU implemented by the proximity communication interface component (426) may be configured in terms of ISO/IEC 7816-4 to enable the token obtaining component (424) to obtain the token, credential and/or cryptograph, as the case may be, from a portable credential device (108) being an NFC-enabled bank card or the like. The proximity communication interface component (426) may interface with an appropriate contactless element of the communication device providing the appropriate radio frequency front-end including for example an antenna and transceiver”), wherein the communication device is configured to receive from the user device, via the ADE API, an available applications response comprising a list of available account application identifiers (AIDs) and application configuration options associated with the available AIDs (Oosthuizen [0069] “the credential may include payment credentials or a subset of payment credentials with which a user may transact against the user account. “Payment credentials” as used herein may include a data construct usable in conducting a financial transaction, such as Track 1 or Track 2 payment credentials, Europay-MasterCard-Visa (EMV) formatted payment credentials and/or one or more of: a primary account number (PAN), an expiry date, a card verification value (CVV), a service code, a cardholder name and the like. The credential may further include an encryption key (e.g. a private key or symmetric key). In some implementations the credential may include an application cryptogram (AC) card key which is unique to the portable credential device. The AC card key may be generated using an AC master key which may be used by an authorisation [sic] system associated with an issuer of the portable credential device to decrypt messages from the portable credential device. In some implementations the credential may include payment credentials encrypted using an encryption key such as an AC card key”, [0094] “he communication device (104) may interact with the portable credential device (108) by way of a proximity communication interface. The proximity communication interface may be a radio frequency proximity communication interface, such as NFC, radio frequency identification (RFID), Bluetooth (registered trade mark) Low Energy (BLE) or the like. In some implementations the proximity communication interface may be an EMV-certified proximity communication interface. In some cases the proximity communication interface may be an NFC interface configured for one or more of: reader, writer and peer-to-peer modes of operation.”; [0133] “In one implementation, for example, the proximity communication interface component (426) implements an application protocol data unit (APDU) to facilitate communication between the portable credential device (108) and the communication device (104). The APDU implemented by the proximity communication interface component (426) may be configured in terms of ISO/IEC 7816-4 to enable the token obtaining component (424) to obtain the token, credential and/or cryptograph, as the case may be, from a portable credential device (108) being an NFC-enabled bank card or the like. The proximity communication interface component (426) may interface with an appropriate contactless element of the communication device providing the appropriate radio frequency front-end including for example an antenna and transceiver”; [0147] other modifications possible “The user may for example obtain an unassigned or otherwise generic portable credential device and use the verified association which exists between the user and the communication device, as well as a proximity communication interface, to obtain a credential from the portable credential device and cause the credential to be linked with a user account maintained by the entity. In this manner, the user may link new portable credential devices and associated credentials to the user account, which links may be verified by virtue of the token having been received from the verified communication device”).
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.
Claim(s) 20 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Oosthuizen as applied to claims 1, 4-5, 7-10, 12-13, 16-18, 22, 24-25 and 28 above, and further in view of Venot et. al. (US Publication No. US 2016/0232523 A1) hereinafter Venot.
Regarding Claim 20:
Claim 20. Oosthuizen discloses the method of claim 18 (Oosthuizen Fig. 3, [0109-0110]).
Oosthuizen does not explicitly disclose wherein the cryptogram is formed using a DES encryption process (Venot [0078] communications may use DES or triple data encryption standards to establish a secure session).
It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the method of provisioning access data disclosed by Oosthuizen with the encryption algorithms taught by Venot. The motivation for this combination would be to ensure that eavesdroppers, observers, and attackers may not snoop on communications and learn the account information being transmitted. Although Oosthuizen discloses generic encryption, the teachings of Venot clearly render obvious the use of DES or triple DES standards to establish secure cryptographic communications.
Regarding Claim 27:
Claim 27. The combination of Oosthuizen and Venot further teaches the method according to claim 1 (Oosthuizen Fig. 3, [0109-0110]), wherein the generating the cryptogram by the user device further comprises: encrypting a second dynamic data element using the second encryption key (Oosthuizen [0109-0116]; [0069-0071] the credential may comprise a cryptogram or encryption key and/or one or more of a primary account number; [0091-0094] an encryption key can be used to create the credential for example; claim 6 “wherein at least a portion of the token has been derived by performing an operation on the data elements and the credential, and wherein the operation is one of a hash of the data elements and the credential or a signing or encryption of the data elements using the credential”), wherein the cryptogram is formed using a triple DES encryption process (Venot [0078] communications may use DES or triple data encryption standards to establish a secure session “Any other suitable form of secured communication between the processing network 13 and the gateway 11 may be implemented as one of ordinary skill would recognize”).
Conclusion
The prior art made of record in the submitted PTO-892 Notice of References Cited and not relied upon is considered pertinent to applicant’s disclosure.
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 MIGUEL A LOPEZ whose telephone number is (703)756-1241. The examiner can normally be reached 8:00AM-5:00PM.
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 on 5712727624. 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.
/M.A.L./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/ Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights