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 communication (Preliminary Amendment) filed on 04/30/2024.
Status of claims in the instant application:
Claims 1-10 and 13-22 are pending.
Claims 11-12 have been canceled.
Claims 1-10 and 13-14 have been amended.
Claims 15-19 and 21-22 have been added.
Priority
This application is a 371 of PCT/CN2023/078239 filed on 02/24/2023. This also claims foreign priority to “CHINA 202210267993.3 filed on 03/17/2022”. Applicant has provided the priority document.
Information Disclosure Statement
Information Disclosure Statements (IDS) filed on 04/30/2034 and 03/19/2025 have been considered, and a signed copies of the IDS forms have been attached to this office action.
Drawings
The drawings are objected to because various labels and notations are not legible; they need to be corrected so that labels and notations are legible, and readable. For example markings in FIG. 4 are not legible.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The abstract of the disclosure is objected to because it contains grammatical error.
Abstract of the disclosure recites, “Provided in the present application are a data transmission method and related device. An method comprises: receiving a transmission preparation request sent by a user end before sending transmission data, and generating configuration information based on at least part of data in the transmission preparation request”.
This should recite, “Provided in the present application are a data transmission method and related device. The [[An]] method comprises: receiving a transmission preparation request sent by a user end before sending transmission data, and generating configuration information based on at least part of the data in the transmission preparation request”
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
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.
Claim 2-6, 8-10, 15-18, 21-22 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 pre-AIA the applicant regards as the invention.
Claims 2, 15 and 21 recite the term “configuration information”; however their parent claims and the claims themselves also previously recite “configuration information”. It’s not clear from the claim language if the later recitation(s) of “configuration information” is referring to the one previously recited or it’s a new one. The term “configuration information” is missing antecedent basis, making the claim language ambiguous/indefinite.
Therefore, claims 2, 15 and 21 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 pre-AIA the applicant regards as the invention. The dependent claims 3-6, 16-18 and 22 are also rejected for the same reasons as claims 2, 15 and 21 as the dependent claims do not rectify the issues in the parent claims or they have additional issue.
Claims 3-5 and 16-18 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 pre-AIA the applicant regards as the invention. These claims have missing antecedent basis for the term “authentication request”.
Claims 4-5, 9-10, 17-18 and 22 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 pre-AIA the applicant regards as the invention. These claims have missing antecedent basis for the term “temporary public key”.
Claims 8-10 and 21-22 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 pre-AIA the applicant regards as the invention. These claims have missing antecedent basis for the term “second identification data”.
**** Note: For the terms identified above as having missing antecedent basis are interpreted to be recited with “the” before the term for any subsequent recitation after the first recitation. For example, “configuration information” should be recited as “the configuration information” after the first recitation to provide proper antecedent basis.
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, 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.
Claims 1, 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Pat. No.: US 9973481 B1 to Sharifi Mehr; Nima (hereinafter “Mehr”) in view of Pub. No.: US 20200125717 A1 to WANG (hereinafter “WANG”).
Regarding Claim 1. (Currently Amended) Mehr discloses A data transmission method (Mehr, Abstract, FIG. 3: … The present document describes systems and methods that, in some situations, improve data security. In one embodiment, communications between a client and a server are encrypted using an envelope-based encryption scheme …), comprising:
generating configuration information based on at least part of data in a received transmission preparation request (Mehr, col.6,ln.28-46; col.7,ln.49-61;col.8,ln.12-15): … In the example illustrated in FIG. 2, the sender 202 generates an envelope-encrypted message 212 containing a DEKR 214 and DEK-encrypted data 216. In one embodiment, the sender 202 generates a random DEK … FIG. 3 shows a process that, when performed, transmits an encrypted message from a sender to a recipient using envelope encryption, in accordance with an embodiment. A swim diagram 300 illustrates operations performed by the sender, the recipient, and a data encryption key server. At block 302, the sender encrypts a plaintext message with a DEK. In some implementations, the sender generates a random or pseudorandom DEK for each envelope … At block 304 the sender encrypts the DEK with a KEK, and sends the encrypted DEK to the data encryption key server. The KEK is a shared secret key maintained by both the sender and the recipient …), the received transmission preparation request sent by a user end before sending transmission data (Mehr, col.7,ln.49-61; col.8,ln.12-32): … FIG. 3 shows a process that, when performed, transmits an encrypted message from a sender to a recipient using envelope encryption, in accordance with an embodiment. A swim diagram 300 illustrates operations performed by the sender, the recipient, and a data encryption key server. At block 302, the sender encrypts a plaintext message with a DEK. In some implementations, the sender generates a random or pseudorandom DEK for each envelope … At block 304 the sender encrypts the DEK with a KEK, and sends the encrypted DEK to the data encryption key server …);
generating an authentication request [through a trusted execution environment] based on the configuration information (Mehr, col.8,ln.16-32: … When the data encryption key server receives the encrypted DEK, the data encryption key server stores 306 the encrypted DEK, and then generates 308 a reference to the DEK called a DEKR. The DEKR can be an address, URI, URL, partial URL, signed or pre-signed URL, index, offset, index to key management system, or other identifier associated with the DEK …) and sending the authentication request to the user end (Mehr, col.8,ln.16-32): … The data encryption key server returns the DEKR to the sender …), so that the user end envelope-encrypts the transmission data based on the authentication request (Mehr, Abstract; col.8,ln.16-32; FIG. 2: … The present document describes systems and methods that, in some situations, improve data security. In one embodiment, communications between a client and a server are encrypted using an envelope-based encryption scheme … At block 310, the sender places the DEKR into an envelope with the DEK-encrypted message. In some implementations, the sender encrypts the DEKR with the KEK and places the encrypted DEKR into the envelope with the DEK-encrypted message …);
However, Mehr does not explicitly teach, but WANG from same or similar field of endeavor teaches:
“generating an authentication request through a trusted execution environment (WANG, Abstract, Para [0051-0055], FIG. 5: … Provided is an authentication protection system based on a trusted environment. The system includes: a client application, a trusted execution environment (TEE) processing unit … In step 501, the client application 302 sends a request for establishing the context to the TEE processing unit 303, and provides identity authentication information for proving its legitimacy. In step 502, the TEE processing unit 303 forwards the request and the identity authentication information to the daemon application 304, and the daemon application 304 verifies the identity authentication information provided by the client application 304 … the daemon application 304 selects to use a certain HASH algorithm, and allocates and records an initial context secret KEY which is a verification secret key used in a subsequent interaction process … In step 505, the TEE processing unit 303 returns the encrypted secret key to the client application 302, and the client application 302 decrypts and extracts the initial secret key using a private key corresponding to the public key in the identity authentication information …)”
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 the teachings of WANG into the teachings of Mehr, because it discloses that, “When the trusted environment-based authentication protection system and method, and the storage medium provided by the embodiments of the present disclosure are used, after security verification and detection based on the client application are performed, a calculation is performed on a parameter used in a connection establishment process by using a hash algorithm and a context key, a calculation is performed in a function calling process by using a random number provided by the daemon application as an auxiliary parameter, and comparisons are performed by the daemon application to ensure complete and trusted parameters in each step of a connection process and the continuous and trusted connection process, thereby improving the security of an information interaction between environments with different security levels, and improving system security (WANG, Para [0022])”.
Mehr further discloses:
“receiving feedback information sent from the user end, the feedback information comprising envelope-encrypted transmission data (Mehr, Abstract; col.8,ln.16-32: …The envelope containing the encrypted message and DEKR is sent 312 to the recipient. At block 314, the recipient receives the envelope containing the DEKR and the encrypted message …); and
obtaining the transmission data by decrypting the feedback information (Mehr, Abstract; col.8,ln.48-52: … When the recipient receives the encrypted DEK, the recipient decrypts 324 the encrypted DEK using the KEK. The recipient, at block 326, decrypts the encrypted message using the DEK. The resulting text message is available to the recipient …).”
SA#1: Regarding Claim 13. This claim contains all the same or similar limitations as claim 1, and hence similarly rejected as claim 1.
*** Note: Mehr also discloses a device with a processor, memory and program executed by the processor to perform the claimed functions (Mehr: col.7,ln.7-16; col.24,ln.17-28).
SA#1: Regarding Claim 14. This claim contains all the same or similar limitations as claim 1, and hence similarly rejected as claim 1.
*** Note: Mehr also discloses a non-transitory computer-readable storage medium with a processor, memory and program executed by the processor causes a device to perform the claimed functions (Mehr: Claim 8).
Claims 2 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Pat. No.: US 9973481 B1 to Sharifi Mehr; Nima (hereinafter “Mehr”) in view of Pub. No.: US 20200125717 A1 to WANG (hereinafter “WANG”), as applied to claim 1 above, and further in view of Pub. No.: US 20050154889 A1 to Ashley et al. (hereinafter “Ashley”).
Regarding Claim 2. (Currently Amended) The combination of Mehr-WANG discloses the method of claim 1, however it does not explicitly teach but Ashley from same or similar field of endeavor teaches, “wherein generating configuration information comprises:
receiving from the user end a transmission preparation request that comprises at least one of a key length, an encryption mode, identification information of the user end (Ashley, Abstract: … A method for establishing a secure context for communicating messages between a client and a server is presented that is compliant with the Generic Security Service application programming interface (GSS-API). The client sends to the server a first message containing a first symmetric secret key generated by the client and an authentication token; the first message is secured with the public key from the server's public key certificate. After the server authenticates the client based on the authentication token, the client then receives from the server a second message that has been secured with the first symmetric secret key and that contains a second symmetric secret key. The client and the server employ the second symmetric secret key to secure subsequent messages sent between the client and the server …) and a second value; and
generating configuration information by integrating at least one of the key length, the encryption mode, the identification information of the user end (Ashley, Abstract, Para [0032]: … A method for establishing a secure context for communicating messages between a client and a server is presented that is compliant with the Generic Security Service application programming interface (GSS-API). The client sends to the server a first message containing a first symmetric secret key generated by the client and an authentication token; the first message is secured with the public key from the server's public key certificate. After the server authenticates the client based on the authentication token, the client then receives from the server a second message that has been secured with the first symmetric secret key and that contains a second symmetric secret key. The client and the server employ the second symmetric secret key to secure subsequent messages sent between the client and the server … …) and the second value.”
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 the teachings of Ashley into the teachings of Mehr-WANG, because it discloses that, “The present invention may be implemented on a variety of hardware and software platforms, as described above with respect to FIG. 1A and FIG. 1B. More specifically, though, the present invention is directed to an improved public-key-based mechanism for establishing a secure context for communication between a client and a server that is compliant with the Generic Security Services Application Program Interface (GSS-API); a secure context comprises information that is shared between two or more communicating entities for the duration of a communication session during which multiple secure messages may be exchanged between the communicating entities (Ashley, Para [0024])”.
Regarding Claim 15. This claim contains all the same or similar limitations as claim 2, and hence similarly rejected as claim 2.
Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20200125717 A1 to WANG (hereinafter “WANG”) in view of Pat. No.: US 9973481 B1 to Sharifi Mehr; Nima (hereinafter “Mehr”).
Regarding Claim 7. (Currently Amended) WANG discloses A data transmission method (WANG: Abstract, FIG. 5), comprising:
sending a transmission preparation request to a trusted hardware end based on received transmission preparation data (WANG, Abstract, FIG. 5, Para [0051, 0003]: … Provided is an authentication protection system based on a trusted environment. The system includes: a client application, a trusted execution environment (TEE) processing unit, a daemon application and a trusted application; where the client application is configured to issue a security authentication business request to the TEE processing unit for calling a security business … In step 501, the client application 302 sends a request for establishing the context to the TEE processing unit 303, and provides identity authentication information for proving its legitimacy … a hardware-supported isolation execution technology emerges, and a trusted execution environment (TEE) is a technology framework defined by the Global Platform to support software and hardware isolation between a non-trusted execution environment and the trusted execution environment …);
receiving an authentication request sent from the trusted hardware end (WANG, Abstract, FIG. 5, Para [0051]: … In step 502, the TEE processing unit 303 forwards the request and the identity authentication information to the daemon application 304 …);
parsing and confirming the authentication request (WANG, Abstract, FIG. 5, Para [0051-0052]: … the daemon application 304 verifies the identity authentication information provided by the client application 304 … In step 503, the daemon application 304 selects to use a certain HASH algorithm, and allocates and records an initial context secret KEY which is a verification secret key used in a subsequent interaction process. The hash algorithm may also be other algorithms for making information secure, such as symmetric or asymmetric encryption algorithms…);
in response to determining that the authentication request is true, obtaining [envelope-encrypted] transmission data by performing [envelope encryption] on transmission data (WANG, Abstract, FIG. 5, Para [0052-0053]: … In step 504, the daemon application 304 encrypts the secret key using a public key in the identity information provided by the client application 302 …); and
However, WANG does not explicitly teach, but Mehr from same or similar field of endeavor teaches:
“obtaining envelope-encrypted transmission data by performing envelope encryption (Mehr, Abstract; col.8,ln.16-32; FIG. 2: … The present document describes systems and methods that, in some situations, improve data security. In one embodiment, communications between a client and a server are encrypted using an envelope-based encryption scheme … At block 310, the sender places the DEKR into an envelope with the DEK-encrypted message. In some implementations, the sender encrypts the DEKR with the KEK and places the encrypted DEKR into the envelope with the DEK-encrypted message …))”.
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 the teachings of Mehr into the teachings of WANG, because it discloses that, “The envelope-based encryption scheme has applications beyond merely transmitting messages from a sender to a recipient. For example, in a data storage service, data can be stored on a remote storage server as a collection of records, each record including a DEKR and data encrypted with a DEK (i.e., an envelope). In various implementations, the encrypting and decrypting operations can be performed by a client or by the server (Mehr, col.3,ln.35-42)”.
WANG further discloses:
“generating feedback information based on the envelope-encrypted transmission data, and sending the feedback information to the trusted hardware end (WANG, Abstract, FIG. 5, Para [0052-0053]: … In step 504, the daemon application 304 encrypts the secret key using a public key in the identity information provided by the client application 302, and returns the encrypted secret key to the TEE processing unit 303 …); *** Note: Mehr combined previously already discloses envelope-encrypted transmission data.”
Regarding Claim 20. This claim contains all the same or similar limitations as claim 7, and hence similarly rejected as claim 7.
*** Note: Mehr also discloses a device with a processor, memory and program executed by the processor to perform the claimed functions (Mehr: col.7,ln.7-15; col.24,ln.17-28).
Allowable Subject Matter
Claims 3-6, 8-10, 16-19 and 21-22 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Applicant’s response must also address 112 rejections and other objection.
Reasons for allowance will be furnished upon allowance.
Pertinent Prior Arts
The following prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
US 20060248336 A1; Bruns et al.: Bruns discloses A system for communicating a message securely between a sender and a receiver. The sender provides a key server with a string specifying the receiver. The key server obtains a message key and a particular envelope encryption key corresponding with a particular envelope decryption key, encrypts the message key with the envelope encryption key (creating the envelope), and provides the envelope to the sender-client. The sender-client encrypts the message with the message key and provides it and the envelope to the receiver. The receiver-client receives these and asks an authentication server for the envelope decryption key. The authentication server obtains the envelope decryption key and provides it to the receiver. The receiver then decrypts the envelope with the envelope decryption key, to get the message key, and decrypts the message.
US 20020138735 A1; Felt et al.: Felt discloses a system and a method which utilizes a combination of message-based encryption and message-based digital signing to ensure the security and authenticity of a message or message buffer sent from one party or process to another in a transaction processing system. In one embodiment the invention includes a method comprising the steps of: creating an encryption envelope by encrypting a message buffer, signing the encrypted contents of said message buffer with a digital signature, sending said encryption envelope from the sender process to the recipient process, receiving the encryption envelope at the recipient process, decrypting said encryption envelope to retrieve said message, and verifying the identity of the sender process by retrieving the digital signature from the encryption envelope. The invention allows intermediate recipients to inspect the message, and provides for reliable authentication, confidentiality, integrity, and non-repudiation, of communicated messages.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHABUB S AHMED whose telephone number is (571)272-0364. The examiner can normally be reached on 9AM-5PM EST M-F.
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, Ali Shayanfar can be reached on 571-270-1050. 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.
/MAHABUB S AHMED/Examiner, Art Unit 2434
/TESHOME HAILU/Primary Examiner, Art Unit 2434