DETAILED ACTION
This action is in response to communication filed on 6/26/2015.
Claims 1-20 are pending.
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 .
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-7 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-7 of U.S. Patent No. 12,368,756. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims are a broader recitation of the patented claims directed to the same secret-provisioning, session-key generation, and mixed-payload decryption process.
The present application is a continuation of Application No. 18/223,786, now U.S. Patent No. 12,368,756. The applications share common inventors and a common assignee.
Claim 1 of U.S. Patent No. 12,368,756 recites a computing device that: sends, via a web browser plugin of a web browser application, a request for a server secret comprising a device fingerprint and an identification of the web browser plugin; receives the server secret and a public certificate; establishes a TLS session; generates a session key based on the server secret, the public certificate, the device fingerprint, the identification of the web browser plugin, a unique identifier of a user, and a nonce string; receives, via the TLS session, data comprising unencrypted data and encrypted data; and decrypts the encrypted data based on the session key.
Present claim 1 recites the same process at a higher level of generality: send a request for a server secret comprising a device fingerprint and an identification of an application; receive the server secret; establish a session; generate a session key based on the server secret, the device fingerprint, and the identification of the application; receive, via the session, data comprising unencrypted data and encrypted data; and decrypt the encrypted data based on the session key.
A web browser plugin is a species of an application. A TLS session is a species of a session. Identification of the web browser plugin is a species of identification of an application. Present claim 1 merely omits the public certificate, the unique identifier of a user, and the nonce string from the independent claim, and recites the remaining elements in generic form. Omitting elements from a patented claim and rewriting species as genera does not render the present claim patentably distinct. It would have been obvious to one of ordinary skill in the art to generalize claim 1 of U.S. Patent No. 12,368,756 in that manner and arrive at present claim 1. The result is the same pipeline: request a server secret using a device fingerprint and an application identification, receive the secret, establish a session, derive a session key from the secret plus the fingerprint plus the application identification, receive mixed plaintext and ciphertext over the session, and decrypt with the derived key.
Present claims 2–7 correspond to claims 2–7 of U.S. Patent No. 12,368,756 as follows:
Claim 2 of the present application recites generating the session key based on a nonce string generated on a periodic basis. Claim 2 of U.S. Patent No. 12,368,756 recites determining the nonce string on a periodic basis. The claims are not patentably distinct.
Claim 3 of the present application recites generating a first public-private key pair, signing the server secret using that pair, and storing the signed server secret. Claim 3 of U.S. Patent No. 12,368,756 recites generating, via the web browser plugin, a first public-private key pair; signing the server secret and the public certificate; and storing the signed server secret and the signed public certificate. Present claim 3 is a broader recitation of the same signing-and-storage step and is not patentably distinct.
Claim 4 of the present application recites storing the session key in temporary storage that is deleted based on closing of the application or expiration of a period of time. Claim 4 of U.S. Patent No. 12,368,756 recites the same temporary storage associated with the web browser plugin, deleted based on closing of the web browser application or expiration of a period of time. Present claim 4 is not patentably distinct.
Claim 5 of the present application recites generating the device fingerprint by executing code received from the one or more remote servers. Claim 5 of U.S. Patent No. 12,368,756 recites generating the device fingerprint by executing, in the web browser, code received from the one or more remote servers. Present claim 5 is not patentably distinct.
Claim 6 of the present application recites sending a request for sensitive data, wherein the encrypted data comprises the sensitive data. Claim 6 of U.S. Patent No. 12,368,756 recites the same limitation. The claims are not patentably distinct.
Claim 7 of the present application recites that the device fingerprint identifies hardware components of the computing device or a name of a network used by the computing device. Claim 7 of U.S. Patent No. 12,368,756 recites the same limitation. The claims are not patentably distinct.
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 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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-2, 4, 6-9, 11, 12-15, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lin et al. (US 2020/0092090) in view of Wasiq et al. (US 2018/0026950).
Regarding claim 1, Lin discloses a computing device configured to protect sensitive data, the computing device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the computing device to:
send, to one or more remote servers, a request for a server secret that comprises: a device fingerprint of the computing device, and an identification of an application executing on the computing device;
Lin’s application 218 sends a device-secret request to the remote root-secret service. That request comprises the device fingerprint Devinfo{u}. Application 218 is the application executing on the device, and Lin later requires the application name as key-derivation input and as a plaintext field on the data packet.
Lin [0093]: “The DSecret request module 222 is configured to, during deployment of the user computing device 210 and after launching, prepare a device secret request DSecretEnvRequest packet, and send the DSecretEnvRequest to the RSecret service 230. In certain embodiments, the DSecret request module 222 is configured to read device fingerprint (Devinfo{u}), generate randomly a key X, obtain a public key of the RSecret service 230, encrypt the Devinfo{u} and the key Xusing the public key obtained from the RSecret service 230, and encoding the encrypted data so as to form the DSecretEncRequest … the ciphertext of the DSecretEnvRequest after encryption is C, and C=Enc_{PubK}(Devinfo{u}, X), where PubK is a public key provided by the root secret service 230, Devinfo{u} is the fingerprint of the user computing device 210, Xis the key provided by the user computing device, which may be a symmetric key, and the fingerprint Devinfo{u} and the key X are main components of the plaint DSecretRequest”
Lin [0112]: “During initialization, the launching module 220 retrieves the device fingerprint Devinfo{u} and randomly generates a key X. In certain embodiments, the fingerprint of the user computing device 210 is in the format of media access control (MAC) address or IMEI or other form, and is hardcoded in the application 218 and can identify the user computing device 210 uniquely”
Lin [0115]: “At procedure 608, the DSecret request module 222 prepares a request for device secret code (DSecretEnvRequest). Specifically, the DSecret request module 222 organizes a plain DSecret request packet comprising the fingerprint Devinfo{u} and the key X as shown in FIG. 9B, and then uses the public key PubK to encrypt the plain DSecret request packet and encodes to form the enveloped message DSecretEnvRequest: C=Enc_{PubK}(Devinfo{u}, X)”
DSecret is the claimed server secret. The request that obtains it comprises the device fingerprint. The executing application is application 218.
Lin [0163]: “The EncodedDataPacket includes the timestamp t, the name of the application app name, the hash value of the device finger print H(Devinfo{u}), and the ciphertext that is encrypted”
Lin [0178]: “The field version is a string indicating the version number of the application 218. … The field appname is a string containing the name of the application 218”
Lin [0186]: “device secrets are unique and as well as each data key is derived uniquely per device, per app, and per request”
Under BRI, the request is sent by the identified executing application 218, and Lin already treats application identity as required keying material.
receive, from the one or more remote servers and in response to the request for the server secret, the server secret;
Lin [0094]: “The DSecret receiving module 224 is configured to, upon receiving the DSecretResponse from the RSecret service 230, retrieve the DSecret{u} from the DSecretResponse, and store the DSecret{u}. … the DSecretResponse includes the DSecret{u} and is encrypted using the key X, and the DSecret receiving module 224 first decodes and decrypts the DSecretResponse, and then retrieves the DSecret{u}. … the DSecret receiving module 224 decrypts the ciphertext C′ by: Dec_{X}(C′)=error, DSecret{u}, so as to obtain the DSecret{u}”
The remote server returns DSecret{u} in response to the fingerprint request. That is receipt of the server secret.
generate a session key based on: the server secret, the device fingerprint of the computing device, and the identification of the application;
Lin’s data key D_u{t} is generated from exactly those three inputs (plus a timestamp).
Lin [0095]: “The data encryption module 226 is configured to generate the data key based on the DSecret{u} received from the RSecret service 230 and stored in the user computing device 210. In certain embodiments, the data encryption module 226 constructs the data key using the timestamp value of when the packet is generated, the hash value of the device information hdid, where hdid=H(Devinfo{u}), the name of the application 218, and the DSecret{u}” and “the data decryption module 228 is configured to generate the data key based on the DSecret{u}, the hash value of the device information, the name of the application extracted during the above decoding or stored in the user computing device 210”
Lin [0163]: “ The encryption is performed using the data key D_u{t}, which is calculated by: D_u{u}=KDF(DSecret{u}, H(Devinfo{u}), app_name, t)”.
decrypt the encrypted data based on the session key.
Lin [0095]: “The data decryption module 228 is configure to, after deployment and during operation, receive an EncodedDataPacket from the backend service 250, decode the EncodedDataPacket to obtain encrypted data, H(Devinfo{u}), timestamp, application name, etc., generate a data key for the encrypted data, and decrypt the encrypted data using the generated data key, so as to obtain sensitive data embedded in the EncodedDataPacket”.
However, the prior art does not explicitly disclose the following:
establish a session with the one or more remote servers;
receive, from the remote server and via the session, data comprising unencrypted data and encrypted data;
Wasiq in the field of the same endeavor discloses techniques for application layer encryption of selected fields on top of TLS. In particular, Wasiq teaches the following:
establish a session with the one or more remote servers;
Wasiq [0033]: “The connection request causes a client transport layer to establish 304 a TLS session to a corresponding service transport layer on a server computer system. As part of establishing the TLS session, the client transport layer negotiates a set of session keys with the service transport layer that is shared with the service transport layer. The service transport layer participates in establishing 306 the TLS session and negotiating the session keys, and indicates to the service application that the client application is requesting a connection. The service application accepts 308 the connection request from the client, resulting in the end-to-end secure connection being established from the client application to the service application”
A TLS session between the client application and the remote service is the claimed session.
receive, from the remote server and via the session, data comprising unencrypted data and encrypted data;
Wasiq [0031]: “A first plaintext data segment 206, a sensitive plaintext data segment 208, and a second plaintext data segment 210 are transmitted between the client computer system 202 and the server computer system 204. An application-layer cryptographic key 212 is used to apply application encryption to the sensitive plaintext data segment 208 to produce application-encrypted sensitive plaintext data 214. The secure transport protocols implemented on the client computer system 202 and the server computer system 204 utilize a transport session key 215 to apply secure transport encryption 216 to the first plaintext data segment 206, the application-encrypted sensitive plaintext data segment 208, and the second plaintext data segment 210”
Wasiq therefore receives, on the established TLS session, plaintext segments together with application-encrypted segments.
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to carry out Lin’s fingerprint-based secret request, DSecret receipt, and D_u{t} key derivation inside Wasiq’s TLS session, and to receive Lin’s EncodedDataPacket (plaintext metadata + cipher) as Wasiq’s mixed plaintext-plus-application-ciphertext traffic on that session. One would have been motivated to combine since Lin already sends EncodedDataPackets to backend service 250 over HTTP and encrypts only selected fields, not the whole channel. Wasiq is in the same field of endeavor and expressly places that pattern on a TLS session with a remote server (Wasiq, FIGS. 2–3). Putting Lin’s HTTP packets on Wasiq’s TLS session is the ordinary HTTPS wrapper for Lin’s already-keyed web traffic. The result is predictable: a session is established with the remote servers, and the mixed unencrypted/encrypted packet is received via that session and decrypted with the key Lin already derives from server secret + fingerprint + application name.
Regarding claim 2, Lin-Wasiq discloses the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to generate the session key based on a nonce string generated on a periodic basis.
Lin generates the working key from the claim 1 inputs plus a timestamp t that is created when each packet is generated, so a new value is produced for every packet and every key is unique to that packet:
Lin [0081]: “Each D u is derived from the corresponding DSecret and the timestamp value when the data key is generated. The D_u is generated on-demand when the mobile device or the backend service needs to encrypt data before sending that data, or decrypt the data after receiving the data that is encrypted. As a result, each D_u is unique to each transmitted data packet, which guarantees the highest security level”
Lin [0163]: “The encryption is performed using the data key D_u{t}, which is calculated by: D_u{t}=KDF(DSecret{u}, H(Devinfo{u}), app_name, t)”
Lin’s t is a once-used, time-varying KDF input generated on a repeating per-packet basis. Under BRI that is a nonce string generated on a periodic basis.
Regarding claim 4, Lin-Wasiq discloses the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to:
store the session key in temporary storage, wherein the temporary storage is configured to be deleted based on one or more of: closing of the application; or expiration of a period of time.
Wasiq stores session cryptographic material only for the life of the connection and deletes it when that period ends.
Wasiq, [0022]: “The cryptographic material provided by the transport layer to the application layer is associated with a secure network connection. When the secure network connection is terminated, the transport layer deletes the cryptographic material because the cryptographic material is no longer needed to maintain the secure network connection”.
Regarding claim 6, Lin-Wasiq discloses the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: send, to the remote server, a request for sensitive data, wherein the encrypted data comprises the sensitive data.
Wasiq, [0033]: “a client application connects to a service provided by a service application. The connection request causes a client transport layer to establish 304 a TLS session … The service application accepts 308 the connection request from the client, resulting in the end-two-and secure connection being established from the client application to the service application”.
Regarding claim 7, Lin-Wasiq discloses the computing device of claim 1, wherein the device fingerprint identifies one or more of: hardware components of the computing device, or a name of a network used by the computing device.
Lin, [0112]: “During initialization, the launching module 220 retrieves the device fingerprint Devinfo{u} and randomly generates a key X. In certain embodiments, the fingerprint of the user computing device 210 is in the format of media access control (MAC) address or IMEI or other form, and is hardcoded in the application 218 and can identify the user computing device 210 uniquely”.
Regarding claim(s) 8-9, 11, 13-14 and 15-16, 18, 20 do(es) not teach or further define over the limitation in claim(s) 1-2, 4, 6-7 and 1-2, 4, 6 respectively. Therefore claim(s) 8-9, 11, 13-14 and 15-16, 18, 20 do(es) is/are rejected for the same rationale of rejection as set forth in claim(s) 1-2, 4, 6-7 and 1-2, 4, 6 respectively.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Lin et al. (US 2020/0092090) in view of Wasiq et al. (US 2018/0026950) in view of O’Neil et al. (US 2021/0288794).
Regarding claim 3, Lin-Wasiq discloses the invention substantially, however the prior art does not explicitly disclose the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to:
generate a first public-private key pair;
sign, using a first public-private key pair, the server secret; and
store the signed server secret.
O’Neil in the field of the same endeavor discloses a browser generates a public-private key pair, receives a server-issued security token (SJWT, signed JWT from the IAM server), stores that token with the private key, and uses the private key to sign the token when talking to the server.
generate a first public-private key pair;
O’Neil [0032]: “When a user attempts to login to a first application, an application on the browser on the user's computer (e.g., browser application), can generate a first public-private key pair [Ab and Av] that includes a first public key [Ab] and a first private key [Av] for the first application.”
sign, using a first public-private key pair, the server secret; and
O’Neil [0037]: “If the credential information input by the user is correct (e.g., the user has entered their correct username and password), then the user is authenticated and a security token is generated for the user. The security token can be a JSON Web Token (JWT) security token. In the example embodiments, the JWTs are signed JWTs. The JWTs are signed by the server (e.g., IAM server) using a private key that is known only to the server. Therefore, the JWTs disclosed in the example embodiments cannot be manipulated or modified. The security token embeds the second public key [Sb]. Therefore, the security token that is generated for the user with the second public key [Sb] can be identified as SJWT[Sb].”
store the signed server secret.
O’Neil [0039]: “The security token (SJWT[Sb]) is then stored in the local storage of the browser. The token SJWT[Sb] can now be used to securely communicate with the server application by signing requests made to the server by the non-extractable key Sv (e.g., sign{Sv, {request, SJWT(Sb)}). The security token can be stored in the browser's IndexedDB IAM which is a client side browser storage that stores information associated with the server. Sv and SWJT[Sb] can both be saved in IndexedDB IAM.”
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to apply O’Neill’s client key pair and signature to Lin’s stored DSecret so that the provisioned secret cannot be altered or replayed from local storage. The combination uses a known integrity technique on a known stored secret, with a predictable result and no change to Lin’s key-derivation function.
Regarding claim(s) 10 and 17, do(es) not teach or further define over the limitation in claim(s) 3 respectively. Therefore claim(s) 10 and 17 is/are rejected for the same rationale of rejection as set forth in claim(s) 3 respectively.
Claims 1-2, 4, 6-9, 11, 12-15, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lin et al. (US 2020/0092090) in view of Wasiq et al. (US 2018/0026950) in view of Hebert et al. (US 2021/0067551).
Regarding claim 5, Lin-Wasiq discloses the invention substantially, however the prior art does not explicitly dislcose the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: generate the device fingerprint of the computing device by executing code received from the one or more remote servers.
Hebert in the field of the same endeavor discloses techniques for collecting that same class of identifier by sending code from the server and running it on the client.
generate the device fingerprint of the computing device by executing code received from the one or more remote servers.
Hebert, [0020]: “Some digital fingerprints (e.g., JS Fingerprint 2 and Web GL) are determined by sending a browser a portion of code (e.g., JavaScript) to run and the result becomes the digital fingerprint.”
Hebert, [0040]: “a fingerprint challenge is sent to the requesting browser in process block 606, and a fingerprint is then computed in process block 608. The fingerprint challenge can be sent, for example, from fingerprint agent 504 to browser 512, and the fingerprint can be computed by fingerprint agent 504 and/or browser 512.”
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to generate Lin’s device fingerprint by executing server-supplied code as in Hebert, instead of (or in addition to) reading a hardcoded MAC/IMEI. Both references already need a unique device identifier; Hebert supplies the conventional browser method for producing one. The result is Lin’s same Devinfo{u} input to the secret request and KDF, obtained by a known fingerprinting technique, with no unexpected result.
Regarding claim(s) 12 and 19, do(es) not teach or further define over the limitation in claim(s) 5 respectively. Therefore claim(s) 12 and 19 is/are rejected for the same rationale of rejection as set forth in claim(s) 5 respectively.
Conclusion
For the reason above, claims 1-20 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
