DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Application
This action is in reply to the correspondence received through June 25, 2026.
Claims 1-8 are pending.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. However, applicant cannot rely upon the certified copy of the foreign priority application to overcome certain intervening prior art rejections because a translation of said application has not been made of record in accordance with 37 C.F.R. § 1.55. See M.P.E.P. §§ 215 and 216.
Information Disclosure Statement
The information disclosure statement submitted June 25, 2026, and its contents have been considered.
Claim Rejections - 35 U.S.C. § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3 and 5-7 are rejected under 35 U.S.C. § 102(a)(2) as being anticipated by Bourgerie et al. (U.S. Pub. No. 2025/0175322 A1) (hereinafter “Bourgerie”).
Claims 1 and 5: Bourgerie, as shown, discloses the following limitations:
an interface (see at least ¶ [0090]: FIG. 1 a schematically shows an example of an embodiment of a configuration device 110. Device 110 may be for determining encrypted computation parameters for carrying out an encrypted computation on noisy ciphertexts; see also at least ¶ [0104]: the system 100 in this example comprises a compiler device 111, a data provider device 113 and an encrypted computing device 112. Compiler device 111 may be combined with encrypted computing device 112 or data provider device 113 in a single device. Device 112 may be configured to receive encrypted data items from a data provider 113. At least one or more data items may be received in encrypted form. One or more further data items may be received in plain format. Device 112 may be configured to receive a homomorphic executable for performing the encrypted computation from the compiler device 111; see also at least ¶¶ [0091]-[0098]);
a memory in which a compiler is stored (see at least ¶ [0096]: some of the figures show functional units that may be functional units of the processor system. For example, a figure may be used as a blueprint of a possible functional organization of the processor system. The processor circuit(s) are not shown separate from the units in most figures. For example, the functional units shown in FIGS. 2-6 (see below) may be wholly or partially implemented in computer instructions that are stored at a device such as device 110, e.g., in an electronic memory of device 110, and are executable by a microprocessor of device 110. In hybrid embodiments, functional units are implemented partially in hardware, e.g., as coprocessors, e.g., arithmetic and/or cryptographic coprocessors, and partially in software stored and executed on device 110; see also at least ¶ [0104]: the system 100 in this example comprises a compiler device 111, a data provider device 113 and an encrypted computing device 112. Compiler device 111 may be combined with encrypted computing device 112 or data provider device 113 in a single device. Device 112 may be configured to receive encrypted data items from a data provider 113. At least one or more data items may be received in encrypted form. One or more further data items may be received in plain format. Device 112 may be configured to receive a homomorphic executable for performing the encrypted computation from the compiler device 111; see also at least ¶ [0117]); and
a processor (see at least ¶ [0091]: device 110 may comprise a processor system 130, a storage 140, and a communication interface 150. Storage 140 may comprise local storage, e.g., a local hard drive or electronic memory. Storage 140 may comprise non-local storage, e.g., cloud storage. In the latter case, storage 140 may comprise a storage interface to the non-local storage. For example, storage 140 may be for storing data representing a computation graph of the encrypted computation. In this representation, the computation graph may be divided into multiple subgraphs. A subgraph may be defined by a type from a set of one or more types, and by zero or more instantiation parameters for the type; see also at least ¶¶ [0094]-[0098] and [0327]),
wherein the processor is configured to:
based on a first type of program is input through the interface, convert the program into a second type of program for processing a homomorphic encrypted ciphertext using the compiler (see at least ¶ [0106]: interestingly, device 112 may perform the encrypted computation according to encrypted computation parameters determined as described in this specification. For example, the encrypted computation parameters may be determined by compiler device 111, e.g., the homomorphic executable may be according to the encrypted computation parameters. In such a case, compiler device 111 may be based on device 110 of FIG. 1 a , e.g., may comprise processor system 130, storage 140, and/or communication interface 150 of FIG. 1 a . It is in principle also possible for the determination of the encrypted computation parameters to be performed by device 112 or device 113 or a different device, however, in which case this device may be based on device 110 of FIG. 1 a . Device 112 may be based on device 119 of FIG. 1 b , e.g., device 112 may comprise processor system 139, storage 149, and/or communication interface 159 of FIG. 1 b; see also at least ¶ [0107]: optionally, the compiler device 111 or data provider device 113 may be further configured to generate key material for the encrypted computing device 112 to perform the encrypted computation, e.g., including a bootstrapping key for performing a programmable bootstrapping as discussed herein. The device generating the key material may provide the bootstrapping key 151 to device 112, e.g., send it via computer network 150, upload it to a shared storage, etc. Key material can also be generated by a separate key generation device (not shown in this figure); see also at least ¶ [0115]: a set of homomorphic encryption operations may be defined for the computation. For example, from the homomorphic encryption operations a computation graph of the encrypted computation, also known as a network or circuit of operations, may be built that together implement the computation, e.g., by a compiler device 111 or by the computation device 112 itself. For example, the operations may include Boolean operations. The way the homomorphic encryption operations are combined, e.g., which operation is applied to which operand in the pool, determines the computation that is being performed. For example, the computation may be represented as a list of homomorphic encryption operations that are to be performed together with an indication on which encrypted data item they are to be performed, thereby implicitly defining the computation graph by their input/output relations; see also at least ¶ [0120]: optionally, the encrypted computation graph ECG may be obtained by performing a compilation COMP, 220, that takes as input an unencrypted computation graph PROG, 210, and transforms the graph into the encrypted computation graph ECG. The compilation COMP may act on a graph of plain operators PROG. By using the provided techniques, this graph PROG may be transformed into a corresponding graph of FHE operators ECG with a correct and optimized set of parameters ECP, 280; see also at least ¶ [0127]: compilation COMP may map a plain operator to a respective set of one or more FHE operators. Both the plain operator and the set of FHE operators may compute the same operation, with the former operating on plain and confidential data, and the latter operating on plaintexts and ciphertext. For this, techniques can be used that are known in the art per se. Interestingly, for the resulting graph ECG, the techniques described herein can be used to find the best encrypted computation parameters; see also at least ¶¶ [0169], [0306], and [0327]), and
identify a time when a bootstrapping is required to expand a plaintext space of the homomorphic encrypted ciphertext in the conversion process (see at least ¶ [0008]: most homomorphic operations increase the noise that is inherent in a homomorphically encrypted data item. When many such operations are performed, the noise may reach a level such that unique decryption is no longer possible. Generally, it is known to use a technique called bootstrapping to reduce the noise of a homomorphically encrypted value. Bootstrapping may use a public key called a bootstrapping key. By using bootstrapping to reducing noise when needed, in principle it is possible to compute any desired number of homomorphic operations; see also at least ¶ [0010]: interestingly, the output of the programmable bootstrapping has an amount of noise that is independent of the noise in the input ciphertext. Thus, by performing the programmable bootstrapping, the noise in the input ciphertext can be reduced to a fixed amount, while possibly at the same time applying a function to the input ciphertext. By performing the programmable bootstrapping at appropriate times, it is possible to perform encrypted computations of unlimited multiplicative complexity; see also at least ¶ [0011]: the operation of encrypted computation techniques, and in particular TFHE-like schemes, is influenced by various encrypted computation parameters. These including various parameters of the encryption scheme itself, for example, the number of mask values and the modulus to use for LWE, as well as parameters that affect particular encrypted operations, such as the decomposition level used in the programmable bootstrapping operation; see also at least ¶ [0012]: the encrypted computation parameters need to be selected with care. In general, the parameters can affect the security of the encrypted computation (for example, the more noise is added at encryption, or the larger the number of mask values, the harder it is to break the encryption scheme); the accuracy of the outcome of the computation (for example, the polynomial size influences the number of bits of accuracy at which a computation can be carried out); and the computational and storage requirements for carrying out the computation (for example, the decomposition level of the programmable bootstrapping and the LWE parameters affect the size of the bootstrapping key and the computational complexity of carrying out this operation); see also at least ¶ [0034]: it is noted that different types of subgraph may share the same base and/or level parameters, corresponding to their use of the same key switching and/or bootstrapping keys. On the other hand, it is possible for different subgraphs to have the same structure per se in terms of cryptographic operations, but different base and/or level parameters, corresponding to performing the same operations but with different bootstrapping and/or key switching keys. Thus, by defining the types and parameters appropriately, an appropriate level of flexibility of the optimization can be achieved; see also at least ¶ [0245]: the inventors envisaged a better way of automatically determining which key switching and/or bootstrapping keys to use in which subgraph. Namely, multiple sets of parameters (e.g., level and/or base) corresponding to multiple sets of key switching and/or bootstrapping keys may be defined, for example, as part of the global encrypted computation parameters or as parameters for a given type of subgraph may comprise. The number of sets to be used may be preconfigured. For a given subgraph 770-772, an encrypted computation parameter δ, 780-782 of that subgraph may identify which set of parameters is used in the subgraph; see also at least ¶ [0265]: the inventors realized that it is possible to optimize for this trade-off and thereby automatically determine, for respective subgraphs of a given type, respective numbers of programmable bootstrappings to be performed during the subgraph, e.g., as in this example, during the application of the respective linear map. Accordingly, subgraph types may be defined that have a variable number of programmable bootstrappings d. For example, the computation graph of the encrypted computation that is input to the optimization may not comprise programmable bootstrappings during the application of respective linear maps, where the optimization inserts those programmable bootstrappings as appropriate; see also at least ¶ [0267]), and
generate a code for inserting a bootstrapping operation at the identified time (see also at least ¶¶ [0265] and [0267] and the analysis above; see also at least ¶ [0169]: having determined the encrypted computation parameter ECP, a combining operation COMB, 224, may be applied in which the parameters ECP may be substituted into the encrypted computation graph ECG that they parameterize. Accordingly, the computation graph ECG may be compiled into a set of instructions HE, 290 for an encrypted computation engine. By executing the instructions HE, the encrypted computation may be carried out according the determined encrypted computation parameters ECP; by the same device that performs the optimization OPT or, more typically, by a different device that receives the instructions HE for execution; see also at least ¶ [0327]: the program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiment of the method; see also at least ¶¶ [0259], [0265]-[0267], and [0306]-[0309]),
Claims 2 and 6: Bourgerie discloses the limitations as shown in the rejection above. Further, Bourgerie, as shown, discloses the following limitations:
wherein the processor is configured to:
based on an execution of the compiler,
identify a time when the bootstrapping is required for the data processed by the program by analyzing an execution flow of the first type of program (see at least ¶ [0028]: the computational cost may be determined in various ways, for example, by performing a simulation or measurement of the actual running time of the encrypted computation; see at least ¶ [0018]: the inventors realized that the computation graph of an encrypted computation is in many cases made up of certain patterns that can occur multiple times throughout the encrypted computation. For example, a pattern can be that an encrypted linear map is applied to one or more inputs; followed by a key switching; followed by a modulus switching; and followed by a blind rotation and sample extraction; see also at least ¶¶ [0106], [0115], [0120], [0127], [0245], [0259], [0265], and [0267]),
determine at least one bootstrapping candidate based on the identified time (see at least ¶ [0034]: it is noted that different types of subgraph may share the same base and/or level parameters, corresponding to their use of the same key switching and/or bootstrapping keys. On the other hand, it is possible for different subgraphs to have the same structure per se in terms of cryptographic operations, but different base and/or level parameters, corresponding to performing the same operations but with different bootstrapping and/or key switching keys. Thus, by defining the types and parameters appropriately, an appropriate level of flexibility of the optimization can be achieved; see also at least ¶ [0245]: the inventors envisaged a better way of automatically determining which key switching and/or bootstrapping keys to use in which subgraph. Namely, multiple sets of parameters (e.g., level and/or base) corresponding to multiple sets of key switching and/or bootstrapping keys may be defined, for example, as part of the global encrypted computation parameters or as parameters for a given type of subgraph may comprise. The number of sets to be used may be preconfigured. For a given subgraph 770-772, an encrypted computation parameter δ, 780-782 of that subgraph may identify which set of parameters is used in the subgraph; see also at least ¶¶ [0018], [0028], and [0117]), and
generate the code based on one of the at least one bootstrapping candidate (see also at least ¶ [0169]: having determined the encrypted computation parameter ECP, a combining operation COMB, 224, may be applied in which the parameters ECP may be substituted into the encrypted computation graph ECG that they parameterize. Accordingly, the computation graph ECG may be compiled into a set of instructions HE, 290 for an encrypted computation engine. By executing the instructions HE, the encrypted computation may be carried out according the determined encrypted computation parameters ECP; by the same device that performs the optimization OPT or, more typically, by a different device that receives the instructions HE for execution; see also at least ¶ [0327]: the program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiment of the method; see also at least ¶¶ [0259], [0265]-[0267], and [0306]-[0309]).
Claims 3 and 7: Bourgerie discloses the limitations as shown in the rejection above. Further, Bourgerie, as shown, discloses the following limitations:
based on the number of candidates are identified in plural,
calculate a delay time when the bootstrapping is performed on each of the plurality of candidates (see at least ¶ [0028]: the computational cost may be determined in various ways, for example, by performing a simulation or measurement of the actual running time of the encrypted computation; see also at least ¶ [0152) and
determine a bootstrapping plan based on a candidate with a minimum delay time (see at least ¶ [0020]: the optimization may then be phrased in terms of this representation of the computation by types and instantiation parameters. The optimization may take into account computational cost, security, and accuracy. In particular, the optimization may minimize the computational cost while ensuring that the computation is sufficiently secure and accurate. This way, a solution may be obtained that, given requirements on security and accuracy, is most computationally efficient. The optimization can be configured to ensure that additional constraints are satisfied, for example, constraints on storage requirements related e.g. to the number of different bootstrapping or key switching keys that are used in the encrypted computation. In many cases, this is not needed however, e.g., storage requirements may be encoded by fixing them as part of the definition of the optimization problem such that it does not need to be separately ensured that they are satisfied; see also at least ¶ [0095]: processor subsystem 130 may be further configured to perform an optimization of the encrypted computation parameters, including the respective sets of encrypted computation parameters for the respective types. In this optimization, the encrypted computation parameters may be optimized to minimize a computational cost of carrying out the encrypted computation according to the encrypted computation parameters; see also at least ¶ [0138]: The optimization may be configured to look for values for the encrypted computation parameters ECP that minimize a computational cost Cost(
PNG
media_image1.png
38
25
media_image1.png
Greyscale
, x) of carrying out the encrypted computation
PNG
media_image1.png
38
25
media_image1.png
Greyscale
according to the encrypted computation parameters x, while ensuring a desired level of security, and the correctness of the computation result (up to a given probability); see also at least ¶¶ [0157]-[0158], [0198], and [0297]), and
generate the code for automatically inserting the bootstrapping operation according to the determined bootstrapping plan (see also at least ¶ [0169]: having determined the encrypted computation parameter ECP, a combining operation COMB, 224, may be applied in which the parameters ECP may be substituted into the encrypted computation graph ECG that they parameterize. Accordingly, the computation graph ECG may be compiled into a set of instructions HE, 290 for an encrypted computation engine. By executing the instructions HE, the encrypted computation may be carried out according the determined encrypted computation parameters ECP; by the same device that performs the optimization OPT or, more typically, by a different device that receives the instructions HE for execution; see also at least ¶ [0327]: the program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiment of the method; see also at least ¶¶ [0259], [0265]-[0267], and [0306]-[0309]).
Claim Rejections - 35 U.S.C. § 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.
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 4 and 8 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Bourgerie et al. (U.S. Pub. No. 2025/0175322 A1) (hereinafter “Bourgerie”) in view of Gu et al. (U.S. Pub. No. 2017/0116396 A1) (hereinafter “Gu”).
Claims 4 and 8: Bourgerie discloses the limitations as shown in the rejection above. Further, Bourgerie, as shown, discloses the following limitations:
wherein the processor configured to:
translates the generated code into an [] intermediate language (see at least ¶ [0306]-[0309]: transforming an unencrypted computation graph into the computation graph of the encrypted computation; and/or compiling the computation graph of the encrypted computation into a set of instructions for an encrypted computation engine; and/or carrying out the encrypted computation according to the determined encrypted computation parameter; see also at least ¶ [0327]: the program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiment of the method; see also at least ¶¶ [0034] and [0169]), and
converts the translated code into the second type of program based on a homomorphic encryption library (see at least ¶ [0169]: having determined the encrypted computation parameter ECP, a combining operation COMB, 224, may be applied in which the parameters ECP may be substituted into the encrypted computation graph ECG that they parameterize. Accordingly, the computation graph ECG may be compiled into a set of instructions HE, 290 for an encrypted computation engine. By executing the instructions HE, the encrypted computation may be carried out according the determined encrypted computation parameters ECP; by the same device that performs the optimization OPT or, more typically, by a different device that receives the instructions HE for execution; see also at least ¶ [0327]: the program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiment of the method; see also at least ¶¶ [0306]-[0309]).
Bourgerie does not explicitly disclose, but Gu, as shown, teaches that the intermediate language is a low level virtual machine (LLVM) intermediate language (see at least ¶ [0006]: the invention provides a unified security framework in which the advantages of software tools in a first collection which are used for translation between representations, for optimization, compilation and so forth, are combined with the advantages of software tools in a second collection which are used for protection of software. In one example, the software tools in the first collection may be tools of the LLVM project, which generally operate using the LLVM intermediate representation. However, tools from other collections which operate using other intermediate representations may be used, for example tools from the Microsoft common language infrastructure, which typically use the common intermediate language CIL. Below, the intermediate representation used by the software tools in the first collection will be denoted as a first intermediate representation. Note that software tools in the first collection may also include tools for protection of software, such as binary rewriting protection tools; see also at least ¶ [0015]: the first intermediate representation may be LLVM intermediate representation, LLVM IR, although other intermediate representations could be used such as Microsoft CIL; see also at least ¶¶ [0022], [0024] and [0027]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the software development optimization and protection techniques taught by Gu with the systems for optimizing encrypted computation parameters disclosed by Bourgerie, because Gu teaches at ¶ [0005] that it would be “desirable to be able to provide protection against attacks for items of software, and to provide such protection across a range of software representations such as different source code languages and native code types, while also maintaining good levels of performance of the software on end user devices. It would also be desirable to deliver software suitably protected in this way for use on multiple different platform types” and at ¶ [0006] that its techniques advance these “desirable” objectives. See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the software development optimization and protection techniques taught by Gu with the systems for optimizing encrypted computation parameters disclosed by Bourgerie, because the claimed invention is merely a combination of old elements (the software development optimization and protection techniques taught by Gu and the systems for optimizing encrypted computation parameters disclosed by Bourgerie), in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. See M.P.E.P. § 2143(I)(A).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. The following references have been cited to further show the state of the art with respect to systems for optimizing encrypted computation parameters.
Chevallier-Mames et al. (U.S. Pub. No. 2024/0259181 A1) (computational network conversion for fully homomorphic evaluation);
Lang et al. (U.S. Pub. No. 2020/0410399 A1) (automatically configuring an action determination model);
Rosing et al. (U.S. Pub. No. 2022/0019441 A1) (hyper-dimensional computing systems and related applications);
Chen et al. (U.S. Pub. No. 2021/0399872 A1) (enabling constant plaintext space in bootstrapping in fully homomorphic encryption);
Marcolla et al. (“Survey on fully homomorphic encryption, theory, and applications.” Proceedings of the IEEE 110.10 (2022): 1572-1609).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christopher Tokarczyk, whose telephone number is 571-272-9594. The examiner can normally be reached Monday-Thursday between 6:00 AM and 4:00 PM Eastern.
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, Mamon Obeid, can be reached at 571-270-1813. 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.
/CHRISTOPHER B TOKARCZYK/Primary Examiner, Art Unit 3687
Prosecution Insights