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 .
This action is in response to the claims filed 6/17/2024. Claims 1-18 are pending. Claims 1 (a machine) and 12 (a method) are independent.
Response to Arguments
Applicant’s arguments, filed 12/30/2025, with respect to the rejection(s) of claim(s) 1 and 12 under Caceres in view of Smith have been fully considered and are persuasive. Caceres in view of Smith does not disclose homomorphic encryption. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Caceres et al., US 2020/0021445 (filed 2018), in view of Smith et al., US 2017/0357496 (filed 2016), and Smith et al. US 2016/0366180 (filed 2015).
Applicant's arguments filed 12/30/2025 have been fully considered but they are not persuasive.
On pages 6-7, Applicant states “’publicly accessible internal source code’ – a clear, objective characteristic that defines the structure and nature of the software.”
This argument is not persuasive.
Examiner does not contest the definition of open-source software. Rather Examiner finds that determining whether software is open source, or even whether to classify software as open source is a non-trivial value judgement that cannot, in any way, be performed by the claimed invention.
For example, how would a system determine if any given provided software is ‘open source’ or not? Does the software have to be entirely open source? Can it use proprietary libraries or open source APIs and be considered open/closed source? Even if the software provider asserted that the software is open source, does such need to be validated?
While the concept of open-source software is well known, the ability for a system to make a judgement based thereupon without any mechanism for determination thereof is impossible.
On pages 7-8, Applicant discusses that the claimed second software is not open-source and uses homomorphic cryptography and the claimed first software is open source and uses the TEE. This argument is not persuasive.
The transitional phrase ‘comprising’ is open-ended and does not exclude additional elements. MPEP 2111.03. Therefore, the first and the second software can be treated as equivalent such that both are subject to homomorphic encryption and ‘data stored in the protection zone’. In other words, Applicant’s stated distinction that different software are handled differently is not required by the claim as the claim does not require the exclusion of any acts from either software. For this distinction, a so called “negative limitation” is necessary, see MPEP 2173.05(i).
Applicant’s further remarks are dependent on those addressed and are not persuasive for the reasons noted above.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph 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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claims 1-10 and 12-18 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was 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, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1 and 12 require:
“determine whether an operation command requested by a user corresponds to the first software or a second software …
Wherein the first software has publicly accessible internal source code, and the second software has non-public internal source code”.
The written description does not provide a mechanism for the claimed “electronic device” and claimed “encryption method” to distinguish between software that has “publicly accessible internal source code” and “non-public internal source code”.
Specifically, no source code is analyzed within the claim or specification nor is any accessibility thereof determined.
Claims 2-10 and 13-18 are rejected due to their dependency on claims 1 and 11, respectively.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-10 and 12-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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claims 1 and 12 require: “wherein the first software has publicly accessible internal source code, and the second software has non-public internal source code.”
It is unclear what this clause requires as no step or structure is required of the system or software. Should software be “publicly accessible” such accessibility would not be provided by the claimed “electronic device” and is outside of the claim and unclaimed functionality.
From a more practical standpoint, this is an impossible test to administer even outside of claim analysis as software will often be combinations of public and non-public source code; a classic example being common libraries used will be public, while some core will be unpublished. Added to this, there is no easy mechanism to determine whether software is ‘public’ or sufficiently public.
The term “publicly accessible internal source code” in claim 1 and 12 is a relative term which renders the claim indefinite. The term “publicly accessible internal source code” is not determinable within the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claims 2-10 and 13-18 are rejected due to their dependency on claims 1 and 11, respectively.
Claims novel over the art of record
Claims 2-3, 7, 15 not anticipated or obvious in view of the art. The further combination of limitations required in claims 2, 7, and 15 are not anticipated or reasonably rendered obvious by the references of record.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 10, 12, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caceres et al., US 2020/0021445 (filed 2018), in view of Smith et al., US 2017/0357496 (filed 2016), and Smith et al. US 2016/0366180 (filed 2015), hereafter Smith2
As to claims 1 and 12, Caceres discloses a machine/method comprising:
a communication device configured to communicate with an external device;
a memory storing data; and (see Caceres Fig. 1A.)
a processor configured to support a trusted execution environment (TEE) function, wherein the processor is configured to: (“The TEE refers to a secure area of the main processor in the client device, which ensures that sensitive data is stored, processed, and protected in an isolated, trusted environment. TEE is isolated from the rich OS, and includes a separate, isolated bootloader and kernel. In this way, the TEE is provided with a higher level of security and increased privileges compared to the rich OS.” Caceres ¶ 15)
store a received first software in a protection zone corresponding to the TEE function, (“attestation engine may periodically verify the integrity of the application code in RAM” Caceres ¶ 30. “Attestation engine 220 may be located in the TEE of client device 210” Caceres ¶ 47)
when …, signature information corresponding to the first software, and hash information corresponding to the first software (“the attestation data may include one or more attestation parameters, by which the identity of the application may be verified.…an electronic signature associated with an application (e.g., an APK signature, etc.), a hash associated with an application (e.g., a hash function, a numeric string (e.g., identifying an application identifier, a program manager identifier, data in the application manifest file, and/or the like) identifiable using a hash function, etc.)” Caceres ¶ 18. “the attestation engine performs the application attestation by obtaining an attestation parameter stored by the attestation engine, and verifying an identity of the challenged application using the attestation parameter.” Caceres ¶ 26. See also ¶ 27)
are received from the external device, (“the attestation parameter may be obtained based on performing a lookup by an application server device identifier” Caceres ¶ 26)
generate a secret key corresponding to the first software, (“the attestation engine may selectively generate a temporary key based on a result of comparing the attestation parameter and the application file attribute” Caceres ¶ 29)
determine whether an operation command requested by a user (“when the application is opened, at runtime, periodically, simultaneous with a user logging into an application” Caceres ¶ 24. “such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button” Caceres ¶ 55) corresponds to the first software (“TEE is isolated from the rich OS, and includes a separate, isolated bootloader and kernel. In this way, the TEE is provided with a higher level of security and increased privileges compared to the rich OS.” Caceres ¶ 15) or to a second software; (“The rich OS may be rooted, for example, where a user removes software restrictions and is granted root (administrator) access. When a device becomes rooted, the user may install a custom (i.e., non-factory) kernel, which may compromise the client device and/or applications running on the client device.” Caceres ¶ 14)
when the operation command is received through the first software, perform an operation corresponding to the first software by using the first software and the data, stored in the protection zone. (“the application may respond to the challenge (i.e., 110, FIG. 1B), from the application server device, by sending the attestation key. Alternatively, the application may respond to the challenge by presenting a signed attestation certificate to the application server device. The application server device may grant the application access to the application server device, based on attesting the application using the attestation key and/or attestation certificate.” Caceres ¶ 34)
Caceres does not explicitly disclose:
when the first software … are received from the external device
Smith discloses:
when the first software, signature information corresponding to the first software, and hash information corresponding to the first software are received from the external device
(see Smith Fig. 7, items 708, 714, 700, 722, 726 and associated description).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Caceres with Smith by providing the application in addition to the hash/signature thereof by the application server. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Caceres with smith in order to ensure the integrity of software that is installed on an endpoint, Smith ¶¶ 2 and 3, where the server that has possession of a hash/signature of software also has the software.
Caceres in view of Smith does not disclose:
perform an operation based on a homomorphic encryption scheme when the operation command is received through the second software; and
Smith2 discloses:
perform an operation based on a homomorphic encryption scheme when the operation command is received through the second software; and (“Additive homomorphic ciphers use a public key that is distributed to a network of IoT nodes that encrypt local telemetry data, then perform an addition operation over the ciphertexts. The resultant ciphertext can be decrypted using a private key held by a third party seeking an attestation of the IoT network.” Smith2 ¶ 16)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Caceres in view of Smith with Smith2 by providing homomorphic functionality to process attestation requests. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Caceres in view of Smith with Smith2 in order to protect attestation or other data to be processed and provided to third parties, Smith2 ¶¶ 15, 38.
As to claims 10 and 18, Caceres in view of Smith disclose the machine/method of claims 1 and 12 and further discloses:
wherein the processor is configured to check integrity of the open software when the open software is received (see Smith Fig. 7, items 708, 714, 700, 722, 726 and associated description), generate the secret key in case of confirming the integrity. (“the attestation engine may selectively generate a temporary key based on a result of comparing the attestation parameter and the application file attribute” Caceres ¶ 29)
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caceres et al., US 2020/0021445 (filed 2018), in view of Smith et al., US 2017/0357496 (filed 2016), Smith et al. US 2016/0366180 (filed 2015), and Wei et al., US 10,657,293 (filed 2019).
As to claim 4, Caceres in view of Smith and Smith2 disclose the machine of claim 1 but does not disclose:
wherein the processor is configured to encrypt a received private key, which is identity-based secret key, by using the TEE function, and store the encrypted private key in the protection zone.
Wei discloses:
wherein the processor is configured to encrypt a received private key, which is identity-based secret key,
(“the setup server 402 can store device information for the FPGA 304 including a device ID 410 a, a device private key entropy 412 a, and a bitstream authentication key 414 a. The device ID 410 a is a string that uniquely identifies the FPGA 304, the device private key entropy 412 a is a randomly or pseudo-randomly generated string for the FPGA 304, and the bitstream authentication key 414 a is a string for authenticating an encrypted bitstream 408 a.” Wei col. 8, ln. 30).
by using the TEE function, and store the encrypted private key in the protection zone.
(“FPGA-based TEE setup 400 in accordance with implementations of this specification. During the TEE setup 400, a setup server 402 exchanges information with the FPGA 304 to create an FPGA-based TEE. The aims of the TEE setup 400 are twofold: (1) the FPGA 304 is programmed to decode, authenticate, and install an encrypted bitstream 408a from the setup server 402; and (2) the setup server 402 is programmed to authenticate with the FPGA 304 and to send private keys to be deployed (404a) to the FPGA 304. Once receiving deployed private keys 404b, the key service 319e (FIG. 3) of the FPGA 304 manages those keys and use them to communicate with outside processes and devices.” Wei col. 8, ln. 10).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Caceres in view of Smith and Smith2 with Wei by provisioning the TEE of Caceres with a private key as done in Wei. It would have been obvious to a person of ordinary skill in the art to combine Caceres in view of Smith and Smith2 with Wei in order to provision devices with keys for secured communication with authorized entities, thereby protecting commands and data communicated to the TEE from tampering, Wei col. 8, ln. 10.
Claim(s) 5-6 and 13-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caceres et al., US 2020/0021445 (filed 2018), in view of Smith et al., US 2017/0357496 (filed 2016), Smith et al. US 2016/0366180 (filed 2015), and Kong et al., US 2021/0044575 (filed 2020).
As to claims 5 and 13, Caceres in view of Smith and Smith2 disclose the machine/method of claims 1 and 12 but does not disclose:
wherein the processor is configured to encrypt an operation result corresponding to the open software by using the secret key.
Kong discloses:
wherein the processor is configured to encrypt an operation result corresponding to the open software by using the secret key.
(“the processor 1302 may sign the hardware information, based on the application key. The processor 1302 may sign the hardware information using the private key of the application key, via an encryption module (e.g., the encryption module 22) operating in the TEE 1304.” Kong ¶ 268. “may generate the application certificate 1237 by signing, using the fused key 1251, data including the collected information, the challenge, and the public key of the application key 1245.” Kong ¶ 272).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Caceres with Smith and Smith2 by using the certificate generation mechanisms of Kong, e.g. using the generated keys. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Caceres in view of Smith and Smith2 with Kong to generate attestation certificates with linked keys for encrypted communications and verifications of attestations, Kong ¶ 284.
As to claims 6 and 14, Caceres in view of Smith, Smith2 and Kong disclose the machine/method of claims 5 and 13 and further discloses:
wherein the processor is configured to control the communication device to transmit the encrypted operation result and encryption key information corresponding to the secret key.
(“the processor 1302 may sign the hardware information, based on the application key. The processor 1302 may sign the hardware information using the private key of the application key, via an encryption module (e.g., the encryption module 22) operating in the TEE 1304.” Kong ¶ 268. “may generate the application certificate 1237 by signing, using the fused key 1251, data including the collected information, the challenge, and the public key of the application key 1245.” Kong ¶ 272).
Claim(s) 5, 8-9, 13 and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caceres et al., US 2020/0021445 (filed 2018), in view of Smith et al., US 2017/0357496 (filed 2016), Smith et al. US 2016/0366180 (filed 2015), and Wooten et al., US 2017/0103209 (filed 2015).
As to claims 5 and 13, Caceres in view of Smith and Smith2 disclose the machine/method of claims 1 and 12 and further discloses:
wherein the processor is configured to encrypt an operation result corresponding to the open software by using the secret key.
Wooten discloses:
wherein the processor is configured to encrypt an operation result corresponding to the open software by using the secret key.
(“To migrate secrets, migration module 532 can cause the software modules to unlock (i.e., decrypt) the secrets locked by the previous versions of the software modules using the migration keys and then lock (i.e., encrypt) the unlocked secrets using the sealing keys generated for the new versions of the software modules.” Wooten ¶ 97. “The device (and/or the framework) can then execute a first key derivation function (KDF) to generate a first sealing key from a hash of the SMD of the first software module using the FDS value. The first sealing key can be specific to the first software module and thus, the first software module can use the first sealing key to both access and lock its secrets.” Wooten ¶ 28).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Caceres in view of Smith and Smith2 with Wooten by sealing and unsealing at least a portion of the software modules as done in Wooten. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Caceres in view of Smith and Smith2 with Wooten in order to verify software updates and migrate secrets from the old version of software, thereby allowing security with software updates, Wooten abstract.
As to claims 8 and 16, Caceres in view of Smith, Smith2 and Wooten disclose the machine/method of claims 5 and 13 and further discloses:
wherein the processor is configured to store the encrypted operation result (data stored in memory for some time while processing Caceres ¶ 26) and information on the open software in the memory. (“the attestation engine performs the application attestation by obtaining an attestation parameter stored by the attestation engine, and verifying an identity of the challenged application using the attestation parameter.” Caceres ¶ 26.)
As to claims 9 and 17, Caceres in view of Smith, Smith2 and Wooten disclose the machine/method of claims 8 and 16 and further discloses:
wherein the processor is configured to compare the information on the open software corresponding to (“the attestation engine performs the application attestation by obtaining an attestation parameter stored by the attestation engine, and verifying an identity of the challenged application using the attestation parameter.” Caceres ¶ 26.)
a ciphertext with software for performing the operation in case that the data used by the open software is stored in the memory in a form of the ciphertext, and
decrypt the ciphertext by using the secret key in case that the two software are the same software. (“The device (and/or the framework) can then execute a first key derivation function (KDF) to generate a first sealing key from a hash of the SMD of the first software module using the FDS value. The first sealing key can be specific to the first software module and thus, the first software module can use the first sealing key to both access and lock its secrets.” Wooten ¶ 28).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Willden et al., US 9,697,371, discloses remote authorization of usage of protected data in a TEE.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
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, Rupal Dharia can be reached at (571) 272-3880. 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.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492