DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the application filed on 01/15/2025 and the preliminary amendment filed on 03/20/2025.
Claims 21-41 are currently pending in this application. Claims 1-20 are cancelled. Claims 21-41 are new.
No information disclosure statement (IDS) has been filed.
Examiner’s Note
Applicant is suggested to include information from figure 9 with related text (e.g., digitally signing with the SDK’s private key, encrypt with a shared key, etc.) of the specification in the claims to provide the application in a better position for an allowance.
Claim Objections
Claim 35 is objected to because of the following informalities: the claim includes “The system of claim 31, , wherein the operations …”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL. —The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 21-41 are rejected under 35 U.S.C. 112(a), as failing to comply with the written description requirements (e.g., the new matter issue).
Applicant has recited the claims 21, 31 and 36 to include subject matter “… encrypting, by a data-collection application or a security application associated with the data-collection application, a data element using a first level storage key to generate a secured object, wherein the first level storage key comprises at least one of … (iii) a public key of the data-collection application, the public key of the data collection application for encrypting information to be transmitted from the server; and (iv) a private key of the server, the private key of the server generating a signature for information to be transmitted by the server …”, however, these amended limitations were not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
Examiner noted that the specification describes that “… fig. 9 depicts the user of private and public keys for encrypting information and digitally signing information by the client app/data-collection module/security module and by the servers …” – see page 26, lines 6-9; and “encrypt point-to-point downloads with SDK’s public key, encrypt broadcasted downloads with shared key, digitally sign downloads with the server’s private key – see fig. 9, wherein these encryption are performed by the InAuth server (NOT by a data-collection application or a security application associated with the data-collection application as recited limitations)
Claims 22-30, 32-35 and 37-41 depend from the claim 21, 31 or 36, and are analyzed and rejected accordingly.
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.
Claims 21-41 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
Applicant is suggested to review all claims for clarification (e.g., capability, compatibility and/or antecedent basic issues) and some of them (not all because they are too many) are indicated below.
Claims 21 and 31 recite “A computer-implemented trusted path for secure communication method …” – for the claim 21, and “A trusted path for secure communication system …” – for the claim 31. However, the remaining limitations of the claims 21, 31 (and the dependent claims 22-30 and 32-35) do not include any thing about the trusted path, therefore not further limiting to the claimed “trusted path”. Please note that the information “… for secure communication method/system …” is interpreted as “an intended use” (or how/where to use the trusted path) and having no limiting weight for the trusted path. Therefore, it is not clear how the claimed limitations are limiting the trusted path – or omitting necessary component/information which causes the limitations unclear.
Claim 21 (claims 31 and 36 include similar limitations) recites:
“A computer-implemented trusted path for secure communication method for information exchanged between a client device and a server on a network, the method comprising the step of (for only the claim 1): encrypting, by a data-collection application or a security application associated with the data-collection application, a data element using a first level storage key to generate a secured object … (i) a public key of the server … (ii) a private key of the data collection application … (iii) … (iv) …”, however, it is not clear (1) whether the encrypting entity (e.g., the data collection application) has any relationship with the client device and/or the server because the data collection application is encrypting the data/information using the public/private key of the server – or omitting necessary step/component which cause the limitation unclear; (2) whether an application (e.g., the data-collection application) has a private/public key – or it is not clear to define a boundary of the limitations; (3) whether the same information (e.g., the data element) is encrypted using different keys (e.g., the public key of the server, the private key of the data collection, etc.); (4) how the define a level (e.g., a first level) of a storage key (e.g., a parent key of a storage key tree, etc.);
“… to generate an encrypted data element … encrypting, by a data-collection application … a data element using … (i) a public key of the server … for encrypting information to be transmitting via the data-collection application to the server …”, however, it is not clear (1) how the generated encrypted data element is converted to the encrypting information to be transmitted; (2) whether the data-collection application is a part of the server to use the public key of the server for encryption or not – it is not clear to define a boundary of the limitations; (3) whether the encrypting information is generated by an entity or server to be transmitted via (or through) the data-collection application to the server;
“… to generate an encrypted data element … encrypting, by a data-collection application … a data element using … (ii) a private key of the data-collection application … for generating a signature for the information to be transmitted to the server …”, however, it is not clear (1) how the generated encrypted data element is converted to the signature for information to be transmitted; (2) whether the data-collection application has any relationship (e.g., a part of the server, linked through a network, etc.) for the transmission – it is not clear to define a boundary of the limitations;
“… to generate an encrypted data element … encrypting, by a data-collection application … a data element using … (iii) a public key of the data-collection application … for encrypting information to be transmitted from the server …”, however, it is not clear (1) how the generated encrypted data element is converted to the encrypting information to be transmitted; (2) whether the data-collection application is a part of the server to transmit the encrypting information from – it is not clear to define a boundary of the limitations; (3) whether “encrypting information to be transmitted” is the same as “encrypting information to be transmitted” included in item (i) above;
“… to generate an encrypted data element … encrypting, by a data-collection application … a data element using … (iv) a private key of the server … generating a signature for information to be transmitting by the server …”, however, it is not clear (1) how the generated encrypted data element is converted to the signature for information to be transmitted; (2) whether the data-collection application is a part of the server to use the private key of the server for encryption or not – it is not clear to define a boundary of the limitations; (3) whether the signature for information is generated by an entity or server to be transmitted by the server; (4) whether “a signature for information to be transmitted” is the same as “a signature for information to be transmitted” included in item (ii) above.
Claims 22-30, 32-35 and 37-41 depend from the claim 21, 31 or 36, and are analyzed and rejected accordingly.
Claims 22, 32 and 37 recite “… wherein the first level storage key further comprises: (v) a shared key, the shared key for encrypting broadcasted downloads”, however, it is not clear (1) whether “the shared key” is shared between/among which entities (e.g., routers, switches, etc.); (2) how to define the “broadcasted downloads” (e.g., which entity is broadcasting, which entity is downloading, etc.) – or omitting necessary step/component which causes the limitations unclear.
Claims 23, 24, 33, 34, 38 and 39 recite:
“… storing the encrypted data element in a first file in a sandbox comprising a portion of a file system of the user device …”, however, it is not clear (1) how the encrypted data element (encrypted by the data-collection application) can be stored in the file of the file system of the user device (e.g., the data-collection application is a part of the user device, etc.); (2) the term, “the user device”, has antecedent basis issue for the claims 33 and 38;
“… encrypting the first level storage key using a second level storage key and storing the encrypted first level storage key in a second file in the sandbox”, however, it is not clear (1) how to define between “the first level storage key” and “a second level storage key” (e.g., different levels of storage security, etc.); (2) how to define “a second file” in the sandbox – it is not clear to define a boundary of the limitations;
“… the portion of the first file system of the user device being accessible only by the data collection application …”, however, it is not clear (1) whether t the data collection application is a part of the user device to access the file system of the user device; (2) whether “the data collection application” is the same as “the data-collection application” included before or not.
Claims 25, 35 and 40 recite “… upon request from the data-collection application: (i) decrypting the encrypted data element … (ii) providing, by the security application, the decrypted data element to the data-collection application”, however, it is not clear (1) whether the data element is encrypted and decrypted by the data-collection application or not – see the limitations of claim 21, 31 or 36; (2) whether the data element is encrypted and decrypted by the security application or not – see the limitations of claim 21, 31 or 36.
Claims 26, 36 and 41 recite “… wherein the first level storage key further comprises a private key of the data-collection application, for decrypting information transmitted from the server; and … upon request from the data-collection application: (i) decrypting the encrypted data element … (ii) providing, by the security application, the decrypted data element to the data-collection application”, however, it is not clear (1) whether “a private key of the data-collection application” is the same as “a private key of the data-collection application” included before or not; (2) how the information is encrypted and transmitted from the server – or omitting necessary step/component which causes the limitations unclear; (3) whether the data element is encrypted and decrypted by the data-collection application or not – see the limitations of claim 21, 31 or 36; (4) whether the data element is encrypted and decrypted by the security application or not – see the limitations of claim 21, 31 or 36.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.— Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 22-30 and 32-35 rejected under 35 U.S.C. 112(d) as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends.
The claims are directed to “method” or “system”, yet they are written to depend on “a (computer-implemented) trusted path”. The claims fail to further limit the (computer-implemented) trusted path. See also the 112(b) rejections above for the secure communication method/system being “an intended use”.
Applicant may cancel the claims, amend the claims to place the claims in proper dependent form, rewrite the claims in independent form, or present a sufficient showing that the dependent claims compile with the statutory requirements.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 21-35 are rejected under 35 U.S.C. 101 because the claims are directed to non-statutory subject matter as the claims do not fall within at least one of the four categories of patent eligible subject matter.
Claims 21 and 31 recite “A computer-implemented trusted path for secure communication method …” – for the claim 21, and “A trusted path for secure communication system …” – for the claim 31. However, the claimed subject matter, “A (computer-implemented) trusted path” is not at least one of the four categories of the patent eligible subject matter because the trusted path (e.g., a link between two nodes in a network, etc.) is NOT obviously a process nor a machine. Moreover, the trusted path neither a manufacture nor a composition of matter. Therefore, the claims are not eligible under 35 U.S.C. 101 because they do not fall within at least one of the four categories of patent eligible subject matter.
Claims 22-30 and 32-35 depend from the claim 21 or 31, and are analyzed and rejected accordingly.
Examiner’s Note Regarding Prior-art Rejections
As explained in the 112, and 101 rejections stated above, the current limitations are in a condition of lack of clarity and/or capability for a prior-art examination. However, a potential concept of the application can be found in:
Agrawal (US 8,392,709 B1) teaches a method and system for a single request-single response protocol with mutual replay attack protection. The system receives multiple single request messages, each of which may include a respective nonce, timestamp, and digital signature. The system may create a record of previously received nonce(s) that, at any given time, may include multiple message nonce(s) received within a valid period of time prior to that given time. To validate a given single request message the system may verify the digital signature of the that message, determine that the timestamp of that message indicates a time within the valid period of time prior to the current time, and determine the nonce of the that message is not present within the record of previously received nonce(s). The system may send a single response message that includes the same nonce as the validated message - see figs. 1, 3; abstract, columns 4-6 of Agrawal.
Benson et al. (US 8,190,893 B2) teaches a method for providing message authenticity by accepting transaction information, a first data item used for authenticating an originating user, cryptographically processing the transaction information using only a second data item, wherein the entropy of the first data item is less than the entropy of the second data item, and authenticating the originating user using the first data item. The first data item can be a sequence of digits corresponding to those displayed on an external device, such as, for example, an RSA authorization token, credit card, etc. A consequential evidence of the transaction may be secured to provide after-the-fact evidence of the transaction. This evidence can include a message written to a tamper-resistant log record, the message including the transaction information, the first data item, the second item, and an identifier for the originating user, as well as other information. At a subsequent point, the transaction can be shown to have been sent by the originating user and received by the intended recipient, by consulting the log record - see figs. 1-3; abstract; columns 5-6 of Benson.
Nadalin et al. (US 2006/0294366 A1) teaches a method and system for supporting the establishment of a secure communication session within a data processing system. A certificate request command is sent from a server to a client. A certificate command is received at the server from the client in response to the certificate request command, and the certificate command is accompanied by a public key certificate and an attribute certificate that is digitally signed by a private key that is bound to the public key certificate. A secure communication session is established in response to successfully verifying the public key certificate. The attribute certificate contains credential information for an authentication operation or an authorization operation that is performed after establishment of the secure communication session – see abstract, figs. 4D, 6; paras. [0053] – [0055] of Nadalin.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAUNG T LWIN whose telephone number is (571)270-7845. The examiner can normally be reached on Monday - Friday 10:00 am - 6:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on 571-272-3739. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAUNG T LWIN/Primary Examiner, Art Unit 2495
Prosecution Insights