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 .
The claim set, filed on 6/24/2025, is acknowledged and considered.
Claims 1, 9, and 17 are independent claims. Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/29/2025 and 6/30/2026 was filed after the mailing date of the claims on 6/24/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-19 of U.S. Patent No. 12368600. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Both current application 19247855 and US Patent 12368600 include similar features of providing fraud detection signals, receiving device integrity token comprising a verdict that indicates a level of trustworthiness of the client device based on the fraud detection signals related to the client device, generating an attestation token comprising a set of data comprising a token creation time that indicates a time at which the attestation token was created, the device integrity token, and a payload that includes data specific to a request and a digital signature generated using a private key wherein sending the request with the attestation token to a recipient. Thus, the elements of claims 1-20 of the current application 19247855 contains similar elements of claims 1-19 of US Patent 12368600. Claims 1-19 of the current application 19247855 is anticipated by claims 1-19 of US Patent 12368600.
This is a non-provisional non-statutory double patenting rejection because the conflicting claims have been patented.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nagasundaram, et al. [US 20150112870] in view of Neve de Mevergnies, et al. [US 20190007212].
As per claim 1: Nagasundaram, et al. teaches a computer-implement method comprising:
providing, by a client device and to a device integrity system, fraud detection signals related to the client device; [Nagasundaram: para 0047; The contextual information may be utilized to verify the validity of a token and prevent further processing of the token if there is any indication of fraud or misuse. See also para 0096]
receiving, by the client device and from the device integrity system, a device integrity token comprising a verdict that indicates a level of trustworthiness of the client device based on the fraud detection signals; [Nagasundaram: para 0132; the merchant have a predefined set of authentication processes and fraud rules regarding the risk levels that are appropriate for tokens. The fraud rules define a high risk level and indicate that a high risk level indicates that a token should not be validated. The transaction token associated with the payment network "A" indicating a high risk level would not be validated based on designated fraud rule indicators or settings provided by the merchant. The token verifier computer indicate this validation decision in the token verification response message. Thus, the message associated to the validation based on risk levels and rules prompts a level of trustworthiness which is based on the fraud detection signals. See also para 0139]
generating, by the client device, an attestation token comprising: [Nagasundaram: para 0007, 0010-0011]
a set of data comprising (i) a token creation time that indicates a time at which the attestation token was created, (ii) the device integrity token, and (iii) a payload that includes data specific to a request; and [Nagasundaram: para 0010; a transaction token include a token format that may include 64 bits of financial institution information (e.g., an issuer identifier, a data type, transmission channel information, token purpose information, etc.) and 64 bits of consumer/product information (e.g., a token verifier, geo-location information, device fingerprinting information, token payload information, etc.). Accordingly, any entity in the transaction flow may understand the context (who issued the token, when it was generated (i.e. token creation time), when it will expire, etc.) surrounding a token at any time. Further, the contextual information may be verified or validated by a token verifier or token issuer at any time to ensure that the transaction token is valid. The transaction token or a token that is verified or validated suggest “an attestation token”. Para 0026; The transaction token include any suitable type of information or format. For example, the transaction token include a format that comprise data elements including a system identifier, an account issuer identifier, a data type identifier, a channel identifier, a token purpose identifier, a token verifier identifier, information about the channel properties associated with the transaction token, and a token payload or account substitute. Para 0107; The contextual information comprise identification of entities involved in the transaction such as the token requestor device and token issuer computer. The contextual information may further comprise any information surrounding or related to the transaction token and entities involved in the transaction, such as, for example, a time associated with the token request, expiration of the token, purpose of the token, transaction channel to be utilized for the token, and geo-location of the token requestor device. The token verifier identifier suggest the “the device integrity token”, as this is associated to a verifier computer, see also para 0121. The token payload information suggest “payload that includes data specific to a request” as the payload applies to the specific transaction and request. Para 0109; the transaction token format include information identifying a token issuer, token purpose, generation or request time, expiration date or time, geo-location of the token subscriber, consumer, or token requestor, one or more usable transaction channels, any other conditions or limitations, and any other information that may be useful to entities handling the transaction token. The generation time suggest “a token creation time”]
**a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device; and [**rejected under the secondary reference, discussion below]
sending, by the client device, the request with the attestation token to one or more recipients. [Nagasundaram: para 0144; sending the transaction information including the transaction token to a payment processing network for processing. More examples on para 0152]
Nagasundaram suggest a set of data comprising (i) a token creation time that indicates a time at which the attestation token was created, (ii) the device integrity token, and (iii) a payload that includes data specific to a request [Nagasundaram: para 0010, 0026, 0107-0109]. However, Nagasundaram does not clearly include “a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device”
Neve de Mevergnies discloses signing server is configured with token signing engine which includes an algorithm used to sign a token. The token signing engine uses a digital signing process involving an asymmetric key pair that includes a private key and an associated public key. The token signing engine applies a one-way hash function to at least some of the contents of the token to produce a hash value. Then, a cryptographic algorithm uses the private key of the key pair to sign (or encrypt) the hash value to create a signature. The signature can then be inserted into the token header of the token. The token signing engine also inserts the public key of the key pair into the token header. The signature created by the private key can be reverted (or decrypted) to the data that was signed (e.g., the hash value) by using the public key of the key pair. The private key could be a symmetric key, in which the signature created by the private key can be inverted (or decrypted) to the pre-signed data by using the same private key [Neve de Mevergnies: para 0086]. Neve de Mevergnies further discusses the signature of the token can be generated by signing server using data in token properties, token payload, and/or first segment of token header. Token properties contains information related to the token and to the particular device that was used to create the token. Information related to the token can include, for example, the token payload type, token payload size, and an expiration parameter (e.g., expiration seconds, minutes, hours, etc.). Information related to the particular device that was used to create the token can include, for example, device ID, a nonce, and a timestamp. [Neve de Mevergnies: para 0097-0098]. As such, one would be motivated to include “a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device”, for verification process ensures that the signed token is verified for authenticity (based on its signature), integrity (based on a hash of its contents), device specific (based on its device ID), and expiration (based on a nonce and/or time).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Neve de Mevergnies with Nagasundaram to teach “a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device” for the reason to ensure the signed token is verified for authenticity (based on its signature), integrity, device specific, and expiration [Neve de Mevergnies: para 0122].
Claim 2: Nagasundaram: para 0101 in view of Neve de Mevergnies: para 0086 [suggesting “a public key corresponding to the private key”, under the same pretext and motivation as in claim 1]; discussing the computer-implemented method of claim 1, wherein the set of data comprises a public key corresponding to the private key.
Claim 3: Nagasundaram: para 0012, 0098 [token payload is associated with the consumer account]; discussing the computer-implemented method of claim 1, wherein the request comprises a request to manage user data of a user of the client device and the payload comprises data specifying an operation to perform on the user data.
Claim 4: Nagasundaram: para 0059, 0126; discussing the computer-implemented method of claim 1, wherein the request comprises a request for a digital component and the payload comprises data for use in selecting the digital component.
Claim 5: Nagasundaram: para 0010, 0085; discussing the computer-implemented method of claim 4, wherein the payload comprises information about a resource with which the digital component will be presented.
Claim 6: Nagasundaram: para 0040 in view of Neve de Mevergnies: para 0086, 0122 [suggesting “a digital signature of a second set of data…second private key”, under the same pretext and motivation as in claim 1]; discussing the computer-implemented method of claim 1, wherein: the device integrity token comprises a digital signature of a second set of data included in the device integrity token; and the digital signature of the second set of data is generated using a second private key of the device integrity system.
Claim 7: Nagasundaram: para 0101 in view of Neve de Mevergnies: para 0086 [suggesting “a public key corresponding to the private key”, under the same pretext and motivation as in claim 1]; discussing the computer-implemented method of claim 6, wherein the second set of data comprises a public key corresponding to the private key of the client device.
Claim 8: Nagasundaram: para 0010, 0030 [generation time of the token, includes secondary tokens]; discussing the computer-implemented method of claim 6, wherein the second set of data comprises a second token creation time that indicates a time at which the device integrity token was created.
As per claim 9: Nagasundaram, et al. teaches a system, comprising:
one or more processors of a client device; and [Nagasundaram: para 0012]
one or more memories having stored thereon computer readable instructions that, when executed by the one or more processors [Nagasundaram: para 0012], cause the one or more processors to perform operations comprising:
providing, by the client device and to a device integrity system, fraud detection signals related to the client device; [Nagasundaram: para 0047; The contextual information may be utilized to verify the validity of a token and prevent further processing of the token if there is any indication of fraud or misuse. See also para 0096]
receiving, by the client device and from the device integrity system, a device integrity token comprising a verdict that indicates a level of trustworthiness of the client device based on the fraud detection signals; [Nagasundaram: para 0132; the merchant have a predefined set of authentication processes and fraud rules regarding the risk levels that are appropriate for tokens. The fraud rules define a high risk level and indicate that a high risk level indicates that a token should not be validated. The transaction token associated with the payment network "A" indicating a high risk level would not be validated based on designated fraud rule indicators or settings provided by the merchant. The token verifier computer indicate this validation decision in the token verification response message. Thus, the message associated to the validation based on risk levels and rules prompts a level of trustworthiness which is based on the fraud detection signals. See also para 0139]
generating, by the client device, an attestation token comprising: [Nagasundaram: para 0007, 0010-0011]
a set of data comprising (i) a token creation time that indicates a time at which the attestation token was created, (ii) the device integrity token, and (iii) a payload that includes data specific to a request; and [Nagasundaram: para 0010; a transaction token include a token format that may include 64 bits of financial institution information (e.g., an issuer identifier, a data type, transmission channel information, token purpose information, etc.) and 64 bits of consumer/product information (e.g., a token verifier, geo-location information, device fingerprinting information, token payload information, etc.). Accordingly, any entity in the transaction flow may understand the context (who issued the token, when it was generated (i.e. token creation time), when it will expire, etc.) surrounding a token at any time. Further, the contextual information may be verified or validated by a token verifier or token issuer at any time to ensure that the transaction token is valid. The transaction token or a token that is verified or validated suggest “an attestation token”. Para 0026; The transaction token include any suitable type of information or format. For example, the transaction token include a format that comprise data elements including a system identifier, an account issuer identifier, a data type identifier, a channel identifier, a token purpose identifier, a token verifier identifier, information about the channel properties associated with the transaction token, and a token payload or account substitute. Para 0107; The contextual information comprise identification of entities involved in the transaction such as the token requestor device and token issuer computer. The contextual information may further comprise any information surrounding or related to the transaction token and entities involved in the transaction, such as, for example, a time associated with the token request, expiration of the token, purpose of the token, transaction channel to be utilized for the token, and geo-location of the token requestor device. The token verifier identifier suggest the “the device integrity token”, as this is associated to a verifier computer, see also para 0121. The token payload information suggest “payload that includes data specific to a request” as the payload applies to the specific transaction and request. Para 0109; the transaction token format include information identifying a token issuer, token purpose, generation or request time, expiration date or time, geo-location of the token subscriber, consumer, or token requestor, one or more usable transaction channels, any other conditions or limitations, and any other information that may be useful to entities handling the transaction token. The generation time suggest “a token creation time”]
**a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device; and [**rejected under the secondary reference, discussion below]
sending, by the client device, the request with the attestation token to one or more recipients. [Nagasundaram: para 0144; sending the transaction information including the transaction token to a payment processing network for processing. More examples on para 0152]
Nagasundaram suggest a set of data comprising (i) a token creation time that indicates a time at which the attestation token was created, (ii) the device integrity token, and (iii) a payload that includes data specific to a request [Nagasundaram: para 0010, 0026, 0107-0109]. However, Nagasundaram does not clearly include “a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device”
Neve de Mevergnies discloses signing server is configured with token signing engine which includes an algorithm used to sign a token. The token signing engine uses a digital signing process involving an asymmetric key pair that includes a private key and an associated public key. The token signing engine applies a one-way hash function to at least some of the contents of the token to produce a hash value. Then, a cryptographic algorithm uses the private key of the key pair to sign (or encrypt) the hash value to create a signature. The signature can then be inserted into the token header of the token. The token signing engine also inserts the public key of the key pair into the token header. The signature created by the private key can be reverted (or decrypted) to the data that was signed (e.g., the hash value) by using the public key of the key pair. The private key could be a symmetric key, in which the signature created by the private key can be inverted (or decrypted) to the pre-signed data by using the same private key [Neve de Mevergnies: para 0086]. Neve de Mevergnies further discusses the signature of the token can be generated by signing server using data in token properties, token payload, and/or first segment of token header. Token properties contains information related to the token and to the particular device that was used to create the token. Information related to the token can include, for example, the token payload type, token payload size, and an expiration parameter (e.g., expiration seconds, minutes, hours, etc.). Information related to the particular device that was used to create the token can include, for example, device ID, a nonce, and a timestamp. [Neve de Mevergnies: para 0097-0098]. As such, one would be motivated to include “a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device”, for verification process ensures that the signed token is verified for authenticity (based on its signature), integrity (based on a hash of its contents), device specific (based on its device ID), and expiration (based on a nonce and/or time).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Neve de Mevergnies with Nagasundaram to teach “a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device” for the reason to ensure the signed token is verified for authenticity (based on its signature), integrity, device specific, and expiration [Neve de Mevergnies: para 0122].
Claim 10: Nagasundaram: para 0101 in view of Neve de Mevergnies: para 0086 [suggesting “a public key corresponding to the private key”, under the same pretext and motivation as in claim 1]; discussing the system of claim 9, wherein the set of data comprises a public key corresponding to the private key.
Claim 11: Nagasundaram: para 0012, 0098 [token payload is associated with the consumer account]; discussing the system of claim 9, wherein the request comprises a request to manage user data of a user of the client device and the payload comprises data specifying an operation to perform on the user data.
Claim 12: Nagasundaram: para 0059, 0126; discussing the system of claim 9, wherein the request comprises a request for a digital component and the payload comprises data for use in selecting the digital component.
Claim 13: Nagasundaram: para 0010, 0085; discussing the system of claim 12, wherein the payload comprises information about a resource with which the digital component will be presented.
Claim 14: Nagasundaram: para 0040 in view of Neve de Mevergnies: para 0086, 0122 [suggesting “a digital signature of a second set of data…second private key”, under the same pretext and motivation as in claim 1]; discussing the system of claim 9, wherein: the device integrity token comprises a digital signature of a second set of data included in the device integrity token; and the digital signature of the second set of data is generated using a second private key of the device integrity system.
Claim 15: Nagasundaram: para 0101 in view of Neve de Mevergnies: para 0086 [suggesting “a public key corresponding to the private key”, under the same pretext and motivation as in claim 1]; discussing the system of claim 14, wherein the second set of data comprises a public key corresponding to the private key of the client device.
Claim 16: Nagasundaram: para 0010, 0030 [generation time of the token, includes secondary tokens]; discussing the system of claim 14, wherein the second set of data comprises a second token creation time that indicates a time at which the device integrity token was created.
As per claim 17: Nagasundaram, et al. teaches a non-transitory computer readable medium storing instructions that upon execution by one or more computers cause the one or more computers to perform operations comprising:
providing, by a client device and to a device integrity system, fraud detection signals related to the client device; [Nagasundaram: para 0047; The contextual information may be utilized to verify the validity of a token and prevent further processing of the token if there is any indication of fraud or misuse. See also para 0096]
receiving, by the client device and from the device integrity system, a device integrity token comprising a verdict that indicates a level of trustworthiness of the client device based on the fraud detection signals; [Nagasundaram: para 0132; the merchant have a predefined set of authentication processes and fraud rules regarding the risk levels that are appropriate for tokens. The fraud rules define a high risk level and indicate that a high risk level indicates that a token should not be validated. The transaction token associated with the payment network "A" indicating a high risk level would not be validated based on designated fraud rule indicators or settings provided by the merchant. The token verifier computer indicate this validation decision in the token verification response message. Thus, the message associated to the validation based on risk levels and rules prompts a level of trustworthiness which is based on the fraud detection signals. See also para 0139]
generating, by the client device, an attestation token comprising: [Nagasundaram: para 0007, 0010-0011]
a set of data comprising (i) a token creation time that indicates a time at which the attestation token was created, (ii) the device integrity token, and (iii) a payload that includes data specific to a request; and [Nagasundaram: para 0010; a transaction token include a token format that may include 64 bits of financial institution information (e.g., an issuer identifier, a data type, transmission channel information, token purpose information, etc.) and 64 bits of consumer/product information (e.g., a token verifier, geo-location information, device fingerprinting information, token payload information, etc.). Accordingly, any entity in the transaction flow may understand the context (who issued the token, when it was generated (i.e. token creation time), when it will expire, etc.) surrounding a token at any time. Further, the contextual information may be verified or validated by a token verifier or token issuer at any time to ensure that the transaction token is valid. The transaction token or a token that is verified or validated suggest “an attestation token”. Para 0026; The transaction token include any suitable type of information or format. For example, the transaction token include a format that comprise data elements including a system identifier, an account issuer identifier, a data type identifier, a channel identifier, a token purpose identifier, a token verifier identifier, information about the channel properties associated with the transaction token, and a token payload or account substitute. Para 0107; The contextual information comprise identification of entities involved in the transaction such as the token requestor device and token issuer computer. The contextual information may further comprise any information surrounding or related to the transaction token and entities involved in the transaction, such as, for example, a time associated with the token request, expiration of the token, purpose of the token, transaction channel to be utilized for the token, and geo-location of the token requestor device. The token verifier identifier suggest the “the device integrity token”, as this is associated to a verifier computer, see also para 0121. The token payload information suggest “payload that includes data specific to a request” as the payload applies to the specific transaction and request. Para 0109; the transaction token format include information identifying a token issuer, token purpose, generation or request time, expiration date or time, geo-location of the token subscriber, consumer, or token requestor, one or more usable transaction channels, any other conditions or limitations, and any other information that may be useful to entities handling the transaction token. The generation time suggest “a token creation time”]
**a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device; and [**rejected under the secondary reference, discussion below]
sending, by the client device, the request with the attestation token to one ormore recipients. [Nagasundaram: para 0144; sending the transaction information including the transaction token to a payment processing network for processing. More examples on para 0152]
Nagasundaram suggest a set of data comprising (i) a token creation time that indicates a time at which the attestation token was created, (ii) the device integrity token, and (iii) a payload that includes data specific to a request [Nagasundaram: para 0010, 0026, 0107-0109]. However, Nagasundaram does not clearly include “a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device”
Neve de Mevergnies discloses signing server is configured with token signing engine which includes an algorithm used to sign a token. The token signing engine uses a digital signing process involving an asymmetric key pair that includes a private key and an associated public key. The token signing engine applies a one-way hash function to at least some of the contents of the token to produce a hash value. Then, a cryptographic algorithm uses the private key of the key pair to sign (or encrypt) the hash value to create a signature. The signature can then be inserted into the token header of the token. The token signing engine also inserts the public key of the key pair into the token header. The signature created by the private key can be reverted (or decrypted) to the data that was signed (e.g., the hash value) by using the public key of the key pair. The private key could be a symmetric key, in which the signature created by the private key can be inverted (or decrypted) to the pre-signed data by using the same private key [Neve de Mevergnies: para 0086]. Neve de Mevergnies further discusses the signature of the token can be generated by signing server using data in token properties, token payload, and/or first segment of token header. Token properties contains information related to the token and to the particular device that was used to create the token. Information related to the token can include, for example, the token payload type, token payload size, and an expiration parameter (e.g., expiration seconds, minutes, hours, etc.). Information related to the particular device that was used to create the token can include, for example, device ID, a nonce, and a timestamp. [Neve de Mevergnies: para 0097-0098]. As such, one would be motivated to include “a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device”, for verification process ensures that the signed token is verified for authenticity (based on its signature), integrity (based on a hash of its contents), device specific (based on its device ID), and expiration (based on a nonce and/or time).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Neve de Mevergnies with Nagasundaram to teach “a digital signature of the set of data, wherein the digital signature is generated using a private key of the client device” for the reason to ensure the signed token is verified for authenticity (based on its signature), integrity, device specific, and expiration [Neve de Mevergnies: para 0122].
Claim 18: Nagasundaram: para 0101 in view of Neve de Mevergnies: para 0086 [suggesting “a public key corresponding to the private key”, under the same pretext and motivation as in claim 1]; discussing the non-transitory computer readable medium of claim 17, wherein the set of data comprises a public key corresponding to the private key.
Claim 19: Nagasundaram: para 0012, 0098 [token payload is associated with the consumer account]; discussing the non-transitory computer readable medium of claim 17, wherein the request comprises a request to manage user data of a user of the client device and the payload comprises data specifying an operation to perform on the user data.
Claim 20: Nagasundaram: para 0059, 0126; discussing the non-transitory computer readable medium of claim 17, wherein the request comprises a request for a digital component and the payload comprises data for use in selecting the digital component.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Leynna Truvan whose telephone number is (571)272-3851. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM, EST.
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, Amir Mehrmanesh can be reached at 571-270-3351. 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.
Leynna Truvan
Examiner
Art Unit 2435
/L.TT/Examiner, Art Unit 2435
/EDWARD ZEE/Primary Examiner, Art Unit 2435
Prosecution Insights