Techniques to process three-dimensional object files while maintaining privacy

Abstract

To provide methods, systems and storage media for processing a three-dimensional (3D) object file or object model in a privacy-preserving manner.SOLUTION: A method comprises: receiving, from a remote computing device, an encrypted object file comprising a specification of a 3D printable object; receiving a request to process the encrypted object file to identify a characteristic of the 3D printable object; obtaining an encrypted comparison file; computing an encrypted Minkowski sum of the encrypted object file and the encrypted comparison file to generate an encrypted result file that comprises information about the characteristic, where computing the encrypted Minkowski sum is performed without decrypting the encrypted object file; and sending the encrypted result file to the remote computing device.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] Embodiments of the present disclosure relate to additive manufacturing.

Background Art

[0002] Additive manufacturing (often known as 3D printing) enables the production of structures with complex shapes that are not achievable by subtractive manufacturing methods. For example, hollow structures that are costly or difficult to achieve in machining processes (i.e., material removal by turning, drilling, and milling) can be created layer by layer in additive manufacturing. Many forms of additive manufacturing utilize a transformation of a substance from one state to another, such as from a liquid to a solid, by a chemical reaction or by heating (e.g., melting the material at specific locations and allowing it to solidify when cooled). Hybrid Manufacturing (HM) incorporates additive manufacturing technology and subtractive manufacturing technology into a multimodal manufacturing process that combines the advantages of both manufacturing processes.

[0003] In some cases, a designer may want to ensure that an object model is printable and that the designer's objectives are achieved. For example, if an object model contains very small features, some of those features may not be printable depending on the specifications of the 3D printer used to fabricate the part. Additionally, in some cases, a part may be intended to undergo additional processes after it is 3D printed. In such cases, a designer may want to ensure that the manufacturing tools used in these post-printing processes have access to specific external regions of the part. Also, a designer may want to ensure that the printed part fits or mates well with other parts of a larger assembly.

Brief Description of the Drawings

[0004] The described embodiments and their advantages can be best understood by referring to the following description in conjunction with the accompanying drawings. These drawings in no way limit any form and details that may be added by those skilled in the art to the described embodiments without departing from the spirit and scope of the described embodiments.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

[0005] Like numbers indicate like elements.

DETAILED DESCRIPTION OF THE INVENTION

[0006] The present disclosure provides various techniques for identifying characteristics of a 3D object model used in 3D printing. A 3D object model is a digital file that can be processed and converted into instructions for instructing a 3D printer to fabricate an object, referred to herein as a 3D printed part or simply a part. The characteristics to be identified can be any characteristics that assist a designer in determining whether the object model can be correctly printed and whether the resulting 3D printed part meets the designer's objectives. For example, a designer may wish to ensure that a part fits or mates well with other parts of a larger assembly, or to confirm that a particular external area of the part is accessible by a tool. Depending on the type of analysis to be performed, a user's computing device may not have the processing resources to perform the numerous calculations involved. For this and other reasons, it may be useful to send the object model to a service provider, which can process the object model, identify the intended characteristics, and generate a result that can be returned to the user. However, if the object model contains proprietary information, the user may be hesitant to share the object model with an untrusted service provider.

[0007] In some cases, a user may want to compare their 3D model with a 3D model owned by a third party. For example, the design of a tool or other component may be the intellectual property of a third party collaborating with the user on a particular project. In such situations, while both parties may still be able to compare their respective 3D models to identify compatibility issues, they may want to keep their respective 3D models confidential from each other.

[0008] The present disclosure describes a technique that enables a user to obtain an analysis of a 3D object model from a service provider in a privacy-protected manner such that the service provider does not have access to the characteristics of the object represented by the 3D object model. The user can send an object file derived from the 3D object model to the service provider, and the service provider performs a privacy-protected computation that provides some type of evaluation or analysis of the 3D object model. The service provider computing system uses homomorphic encryption such that the computations performed by the service provider on the object file are performed within an encrypted region, which prevents the service provider from having access to the underlying unencrypted data. Both the object file provided to the service provider and the result file returned to the user are encrypted and can only be decrypted by a private key owned by the user.

[0009] Fully homomorphic encryption is a type of encryption that enables computations to be performed on encrypted data without first decrypting the encrypted data. The resulting computation is in encrypted form and, when decrypted, produces the same output as would be generated if the operation had been performed on the unencrypted data. There are various types of fully homomorphic encryption techniques. A fully homomorphic encryption technique that supports an infinite number of multiplication and addition operations in the encrypted domain is called fully homomorphic. A fully homomorphic encryption technique that supports only one type of operation, such as multiplication or addition, in the encrypted domain is called partially homomorphic. A fully homomorphic encryption technique that supports both multiplication and addition operations in the encrypted domain but only a limited number of operations is called somewhat homomorphic. As an example, there exists a somewhat homomorphic encryption scheme that enables the computation of low-degree polynomials on encrypted data.

[0010] Files sent to a service provider computing system may be referred to herein as object files. In some embodiments, the object file may be derived from a 3D object model, such as an STL file, as further described in connection with FIG. 1. Manipulation of the object file can include comparing the user's object file to another file, referred to herein as a comparison file. For example, the comparison file may be derived from a 3D object model representing a tool or other component within an assembly. In some embodiments, the service provider may store a set of comparison files to be compared with the user's object file. In other embodiments, the comparison file may be received by the service provider from a third party, and the third party may desire to keep the comparison file confidential from the service provider and / or the user. For example, a user may wish to perform a comparison between the user's object file and a tool specification owned by a third party. In such embodiments, the service provider receives both the user's object file and the comparison file in an encrypted form, thereby maintaining the privacy of both parties. This enables cooperation between the parties without the need for the parties to share designs with each other or with the service provider.

[0011] The user can specify the type of comparison to be performed, such as distance comparison, collision or overlap detection, distance detection, non-printable feature detection, etc. Each of these comparisons may involve different types of mathematical operations. In some embodiments, the user and the service provider execute the Minkowski sum protocol to achieve the desired results. The Minkowski sum protocol operates such that the service provider can provide various comparisons through the Minkowski sum of the object file and the comparison file. Depending on the type of comparison being performed, additional operations may be performed (by the user's computing device, the service provider computing system, or a third-party computing device) to achieve the desired result, and the Minkowski sum protocol functions as a primitive protocol that serves as the basis for various types of comparison operations. In other words, each of these various types of comparisons is formulated as a set of procedures where the Minkowski sum is the primitive protocol executed by the service provider computing system. Other primitive protocols are also possible within this framework.

[0012] The techniques described herein improve the operation of a computing system by enabling the service provider's computing system to evaluate the customer's 3D object files for various purposes (printability, tool access, component compatibility) while maintaining the privacy of the customer's owned intellectual property. Operations that may not have been practical to perform on the user's computing device can here be offloaded to the service provider's system, which has the processing resources required to complete the task in a reasonable amount of time.

[0013] FIG. 1 shows a block diagram of a system for implementing a protocol for processing 3D object models in a privacy-protected manner according to some embodiments of the present disclosure. As shown in FIG. 1, system 100 includes a service provider computing system 102 coupled to one or more computing devices such as client device 104 and third-party device 106 via network 108.

[0014] The service provider computing system 102 can include hardware such as a processing device, volatile memory, persistent data storage devices, networking equipment, and other hardware devices. The service provider computing system 102 can include any suitable type of computing device or machine having programmable processing resources, including, for example, a server computer, a desktop computer, a laptop computer, a tablet computer, etc., and can be a distributed set of devices. The service provider computing system 102 may comprise a single machine or may include a plurality of interconnected machines (e.g., a plurality of servers configured within a cluster). For example, the service provider computing system 102 can be implemented in a cloud computing system. Similarly, the client computing device 104 and the third-party computing device 106 may include hardware such as a processing device, volatile memory, persistent data storage devices, networking equipment, and other hardware devices.

[0015] The client device 104 can include an object model 110. The object model 110 describes 3D objects that may be printable by a 3D printer 112. The object model 110 can be of any suitable file type, such as a computer-aided design (CAD) model (e.g., in the AutoCAD™, Solidworks™, STEP, VRML, IGES, or DXF format), an STL model, or other point cloud models (e.g.,.obj,.x3d, files, etc.). In some embodiments, the client computing device 104 can include 3D modeling software that enables a user to generate and / or manipulate the object model 110. The client computing device 104 can also store or otherwise have access to a collection of object models that can be downloaded, viewed, and modified via the 3D modeling software.

[0016] The client device 104 can also include comparison software 114 that enables a user to access processing services available through the service provider computing system 102 to identify characteristics of the object model 110. The comparison software 114 can send processing requests to the service provider computing system 102, encrypt files, and cooperate with the service provider computing system 102 to perform calculations to achieve the requested processing results.

[0017] In some embodiments, the comparison software 114 may convert the object model 110 into an object file 116 having a data format suitable for further processing described herein. In some embodiments, the object file 116 is a 3D array of voxels representing the 3D object specified by the object model 110. The 3D array of voxels may also be referred to as a third-order tensor. Embodiments of the present technique can also be implemented using first-order tensors (1D arrays) and second-order tensors (2D arrays). The numbers in a 1D array or multi-dimensional array may sometimes be referred to as components of the tensor.

[0018] If the object model 110 is not in an acceptable format, the object model 110 can be processed to generate the object file 116. For example, if the object model 110 is an STL file, the object model 110 is represented by a list of vertices corresponding to the triangulated faces of the object. The object model 110 can also include metadata such as file name, creator, modification data, etc. Processing the object model 110 to generate the object file 116 may include converting the object representation to an equivalent tensor representation and removing the metadata. In some embodiments, the object file 116 can be generated by the comparison software 114 in response to a processing request initiated by the user.

[0019] The service provider computing system 102 includes a comparison engine 118 that can be implemented as hardware, or a combination of hardware and software (e.g., one or more processing devices programmed to perform the functions described herein). The comparison engine 118 is configured to process the object file 116 according to a request received from the client computing device 104. The comparison engine 118 implements a processing protocol used to process the object file 116 and performs encrypted computations that form the basis of the primitive protocol while maintaining the privacy of the client's data. The comparison engine 118 processes the object file 116 by comparing the object file 116 with another file, herein referred to as the comparison file 120. Comparing the object file 116 with the comparison file 120 means calculating functions of the object file 116 and the comparison file 120, e.g., the Minkowski sum of the object file 116 and the comparison file 120.

[0020] The comparison file 120 may be a tensor of the same order as the object file 116, e.g., another 3D tensor or an array of voxels. The comparison file 120 may similarly be derived from a 3D object model by the service provider computing system 102 or a third party device 106.

[0021] The service provider computing system 102 includes, or can access, a memory device 116 that maintains a design library 114. The design library 114 can include various object specifications that can be used as comparison files 120 for processing object files 116 received from the client device 104. For example, the design library 114 can include comparison files 120 representing various 3D parts, manufacturing tools, or specifications of various 3D printers. In some embodiments, the comparison file 120 can be provided by a third-party computing device 106.

[0022] The client computing system 104 can send a processing request to the service provider computing system 102. To ensure that the service provider cannot access the object specifications included in the object file 116, the client computing system 104 first encrypts the object file 116 and then sends it to the service provider computing system 102. The object file 116 can be encrypted using any suitable homomorphic encryption technique, including fully homomorphic encryption, somewhat homomorphic encryption, and partial homomorphic encryption. Somewhat homomorphic encryption techniques generally use fewer processing resources compared to fully homomorphic encryption and may therefore be preferred in some cases depending on the type of computation to be performed on the encrypted file. The encryption method uses a pair of cryptographic keys 120 called a public key and a private key. The file can be encrypted using the public key but can only be decrypted using the corresponding private key. Therefore, the public key can be shared without losing privacy, but the private key is held by the client device 104 and is not shared.

[0023] The encryption of the object file 116, the packaging of the request, and the communication with the service provider computing system 102 can be performed by the comparison software 114. Further, the mathematical calculations performed by the client device 104 according to the processing protocol can be performed by the comparison software 114. As will be further described in connection with FIGS. 2-5, the calculations performed by the client device 104 are coordinated with the calculations performed by the comparison engine 118 on the service provider computing system 102. The type and order of the calculations can vary depending on the type of comparison being performed. In some embodiments, the comparison software 114 may be downloaded from the service provider computing system 102.

[0024] The processing request sent from the client device 104 can include an encrypted object file 116, the public key used to encrypt the object file 116, and process identification information describing the type of comparison to be performed. For example, the process identification information can describe a request to process the object file 116 to determine if there are parts that are too small to print by the 3D printer 112. The request can also indicate the minimum printable size, or a specific printer model that can be used to determine the minimum printable size. In some embodiments, the process instruction information can describe a request to process the object file 116 to determine which regions of the printed object are accessible by a tool such as a subtractive manufacturing tool. The request can also identify the specific tool used for the comparison. Other types of processes can also be requested, such as determining whether the printed object will collide with another part of the same assembly, or determining the amount of clearance between parts. The comparison file 120 can be obtained based on the process identification information received from the client device 104. For example, the process identification information can identify a specific tool having a corresponding design specification within the design library 114, and this design specification can be retrieved from storage and used as the comparison file 120.

[0025] In some embodiments, the comparison file 120 is received from a third-party computing device 106. For example, a user may wish to collaborate with a third party in a joint project that includes one or more objects designed by the third party, such as a tool or another component of an assembly. In such an example, the client device 104 can send the public key to the third-party device 106, and the third-party device 120 encrypts the comparison file 120 before sending the comparison file 120 to the service provider computing system 102. In this way, the third party can also maintain the privacy of its design unless the service provider provides the encrypted comparison file 120 to the client device 104. In some cases, the third party may not be interested in protecting the privacy of the design, in which case the comparison file 120 may be sent from the third-party device without encryption, and the service provider computing system 102 can encrypt the comparison file 120 to enable calculations to be performed in the encrypted area.

[0026] When the request is received by the service provider computing system 102, a processing protocol is initiated. The processing protocol may include various calculations performed by the comparison engine 118 in cooperation with the client device 104. If the comparison file 120 has not yet been encrypted, the service provider computing system 102 first encrypts the comparison file 120 using the public key provided by the client device 104.

[0027] Among the possible operations, in particular, the comparison engine 118 can calculate the encrypted Minkowski sum of the encrypted object file 116 and the encrypted comparison file 120. The Minkowski sum is calculated in the encrypted domain, that is, without decrypting the files. In some embodiments, all requests are processed using the Minkowski sum as the basic unit of calculation. Thus, each request is formulated to use the Minkowski sum in addition to one or more additional operations that can be performed by the client device 104 or the service provider computing system 102. For example, the processing protocol may include exchanging intermediate data sets between the client device 104 and the service provider computing system 102 before the final result is obtained. Exemplary processing protocols are described in connection with FIGS. 2-5.

[0028] The Minkowski sum (also called dilation or convolution of A and B) of two tensor files A and B can be formed by adding each element in A to each element in B. The Minkowski sum can also be calculated by converting each tensor file to the frequency domain and computing the product for each element of the tensors. In an embodiment, the comparison engine 118 can calculate the Minkowski sum in the spatial domain or the frequency domain. When the Minkowski sum is calculated in the frequency domain, the object file 116 and the comparison file 120 can be converted to the frequency domain using a Fourier transform algorithm, such as a Discrete Fourier Transform (DFT), a Fast Fourier Transform (FFT), etc. The converted object file 116 and the converted comparison file 120 can be tensors with floating-point precision up to a specified number of significant digits. The frequency domain version of the object file 116 can be calculated by the client device 104 (e.g., before encryption) or by the service provider computing system 102 within the encrypted region, depending on the details of a particular implementation, such as the type of homomorphic encryption used.

[0029] The final result of the processing request is received by the client device 104 in the form of an encrypted result file. The result file may then be decrypted by the client device 104 and may undergo further processing. For example, if the decrypted result file is in the frequency domain, the client device 104 can use an inverse Fourier transform to convert the file to the spatial domain. Additionally, the decrypted result file may be used to generate a 3D representation of the object, which can be displayed to the user via a graphical user interface (GUI). The characteristics of the 3D object can be represented differently depending on the type of processing request. For example, non-printable characteristics of the 3D object may be highlighted, or characteristics accessible by a tool may be highlighted.

[0030] Upon receiving the result, the user can modify the corresponding 3D object model 110 to address potential printing issues and / or select the corresponding object model 110 for printing by the 3D printer 112. It will also be understood that additional processing may be required to convert the 3D object model 110 into a form used by a specific type of 3D printer 112. For example, a program called a slicer can convert the 3D object model 110 from a CAD or STL file to a G-code file.

[0031] FIG. 2 is a diagram showing the Minkowski sum protocol between a client device and a service provider computing system according to some embodiments of the present disclosure. Referring to FIG. 1, these processes executed by the client device 104 may be executed by the comparison software 114, and the processes executed by the service provider computing system 102 may be executed by the comparison engine 118. It will be understood that the actual implementation of the Minkowski sum protocol may include additional calculations depending on the specific characteristics being calculated. A more detailed protocol is described in connection with FIGS. 3 and 4. The process can start from block 202.

[0032] In block 202, the client device 104 obtains an object file. The object file can be a three-dimensional array of voxels representing an object that can be fabricated by a 3D printer. In some embodiments, the client device 104, in block 204, converts the object file into a frequency domain representation. For example, the client device 104 can use a Fourier transform such as a fast Fourier transform (FFT) to convert the object file into a frequency domain representation.

[0033] In block 206, the object file is encrypted using the public key of the public-private key pair. Any suitable homomorphic encryption technique can be used.

[0034] Next, the client device 104 sends a processing request to the service provider computing system 102. The processing request can identify the type of process to be executed or the type of characteristics to be identified. Along with the request, the client device 104 also sends the encrypted object file and the public key used to encrypt the object file.

[0035] In response to the request, the service provider computing system 102 obtains a relevant comparison file in block 208 based on the request. The comparison file can be obtained from the storage device of the service provider computing system 102 based on the details of the request. The comparison file can describe tool specifications, component specifications of other components in the assembly, minimum printable features, etc.

[0036] In block 212, the service provider computing system 102 encrypts the comparison file using the public key received from the client device 104. In block 214, the service provider computing system 102 calculates the encrypted Minkowski sum of the encrypted object file and the encrypted comparison file. In the embodiment shown in FIG. 2, the encrypted Minkowski sum E[G] is calculated in the frequency domain by calculating the product of each element of the encrypted object file E[C] and the encrypted comparison file E[D], which is represented by Equation 1 below.

[0037]

Equation

[0038] Wherein, i, j, k assume all allowable values within the assigned coordinate space. This utilizes the fact that multiplication in the frequency domain is equivalent to calculation in the spatial domain, and the fact that the encryption function E(·) is multiplicatively homomorphic. Although E(·) is also additively homomorphic, its property is not utilized in the above relationship. The encrypted Minkowski sum E[G] (referred to as the result file in this specification) is then transmitted to the client device 104.

[0039] In block 216, the client device decrypts the result file using the private key. In block 218, the client device converts the decrypted result file into the spatial domain, which is the convolution of the object file and the comparison file.

[0040] It will be understood that embodiments of protocol 200 may include additional blocks not shown in FIG. 2, and some of the blocks shown in FIG. 2 may be omitted. Additionally, the processes associated with blocks 202 - 216 may be executed in an order different from the order shown in FIG. 2. For example, in the above embodiment, the Minkowski sum is calculated in the frequency domain, and the calculation in the frequency domain is more computationally efficient than calculating the Minkowski sum in the spatial domain. However, it will be understood that embodiments of the present technology also include calculating the Minkowski sum in the spatial domain. In such embodiments, blocks 204, 210, and 216 can be skipped, and the encrypted Minkowski sum E[G] is calculated in the spatial domain by calculating the element-by-element sum of the encrypted object file E[C] and the encrypted comparison file E[D], which is represented by Equation 2 below.

[0041]

Equation

[0042] In the above relationship, all of the coordinates i, j, k, x, y, z are assumed to be all allowable values within the assigned coordinate space. This relationship is identical to the spatial region convolution of the objects represented by C and D. This relationship utilizes the fact that the encryption function E(·) is additively and multiplicatively homomorphic. This method of calculating the Minkowski sum is an alternative to that taught by Equation 1, but is likely to be more mathematically complex.

[0043] In addition, in some embodiments, the object file can be transformed into the frequency domain (within the encrypted region) by the service provider computing system 102 rather than by the client device 104. In such embodiments, blocks 204 and 216 can be skipped, and the service provider computing system 102 transforms the encrypted object file into the frequency domain before calculating the Minkowski sum and transforms the result back into the spatial domain before transmitting the encrypted result file to the client device 102.

[0044] FIG. 3 is a diagram showing a Minkowski sum protocol among a client device, a service provider computing system, and a third-party computing device, according to some embodiments of the present disclosure. Referring to FIG. 1, these processes executed by the client device 104 can be executed by the comparison software 114, and the processes executed by the service provider computing system can be executed by the comparison engine 118. It will be understood that the actual implementation of the Minkowski sum protocol may include additional calculations depending on the particular characteristics being computed. A more detailed protocol is described in connection with FIGS. 3 and 4. The process can start at block 302.

[0045] In block 302, the client device 104 obtains an object file. The object file can be a three-dimensional array of voxels representing an object that can be manufactured by a 3D printer. In some embodiments, the client device 104 converts the object file into a frequency domain representation in block 304, for example, using the FFT algorithm.

[0046] Similarly, the third-party device 106 obtains a comparison file in block 306. The comparison file can describe tool specifications, part specifications of another part in the assembly, minimum printable feature size, etc. The comparison file can be a tensor of the same order, for example, a three-dimensional array of voxels. Further, the third-party device 106 converts the comparison file into a frequency domain representation in block 308.

[0047] In block 310, the object file is encrypted using the public key of a public-private key pair. Any suitable homomorphic encryption technique can be used. In addition, the client device 104 also sends the same public key to the third-party device 106. In block 312, the comparison file is encrypted by the third-party device 106 using the public key received from the client device 104.

[0048] Both the encrypted object file and the encrypted comparison file are sent to the service provider computing system 102. The client device 104 can also send a processing request to the service provider computing system 102. The processing request can identify the type of process to be executed or the type of characteristics to be identified. In addition, the client device 104 can identify the third-party device 106 and / or the comparison file provided by the third-party device 106.

[0049] In response to the request, the service provider computing system 102 calculates, at block 314, the encrypted Minkowski sum of the encrypted object file and the encrypted comparison file. The encrypted Minkowski sum can be calculated in the frequency domain, as described above in connection with FIG. 2. The encrypted Minkowski sum is then sent as a result file to the client device 104.

[0050] At block 316, the client device decrypts the result file using the private key. At block 318, the client device 104 converts the decrypted result file to the spatial domain, which is the convolution of the object file and the comparison file.

[0051] It will be understood that embodiments of protocol 200 may include additional blocks not shown in FIG. 3 and some of the blocks shown in FIG. 3 may be omitted. Additionally, the processes associated with blocks 302 - 318 may be executed in an order different from that shown in FIG. 3. For example, as described above in connection with FIG. 2, the Minkowski sum may be calculated in the spatial domain. Additionally, the object file and the comparison file may be converted to the frequency domain by the service provider computing system 102 (in the encrypted domain) rather than by the client device 104 and third - party devices.

[0052] Figure 4 is a diagram showing a process for identifying an external region of a 3D printable part accessible by a tool using the Minkowski sum protocol according to some embodiments of the present disclosure. Referring to Figure 1, the process executed by the client device 104 can be executed by the comparison software 114, and the process executed by the service provider computing system 102 can be executed by the comparison engine 118. The process of Figure 4 uses the Minkowski sum protocol shown in Figures 2 and 3 as a primitive protocol, and this primitive protocol is combined with additional operations to achieve the processing goals identified in the request. The process can start from block 402.

[0053] In block 402, the client device 104 obtains an object file in block 402. The object file can be a three-dimensional array of voxels representing an object that can be manufactured by a 3D printer. In some embodiments, the client device 104 or the service provider computing system 102 can convert the object file into a frequency domain representation. For the sake of brevity, the steps involved in the conversion between the spatial domain and the frequency domain are not shown in Figure 4. However, it will be understood that the Minkowski sum can be calculated in the spatial domain or the frequency domain as described in connection with Figures 2 and 3.

[0054] In block 404, the object file is encrypted using the public key of a public-private key pair. Any suitable homomorphic encryption technique can be used.

[0055] Next, client device 104 sends a processing request to service provider computing system 102. The processing request can include an identifier that identifies the request as a request to find an external region of an object file that is accessible by a tool. The request can also include an identifier that identifies a comparison file that represents the tool. For example, the identifier can identify a particular tool, a particular comparison file, or a particular third - party device from which the comparison file was received. Along with the request, client device 104 also sends an encrypted object file and the public key used to encrypt the object file.

[0056] In response to the request, service provider computing system 102, at block 406, obtains a comparison file that describes the tool specification, i.e., the tool specification for the associated tool identified in the request. For example, the tool can be a drill, a lathe, a Dremel kit, etc. Referring to FIG. 1, the tool specification can be obtained from data storage device 116 of service provider computing system 102 or from third - party computing device 106.

[0057] At block 408, service provider computing system 102 calculates the complement of the tool specification, i.e., the reciprocal of the tool specification. For example, filled voxels in the tool specification are empty in the complement, and empty voxels in the tool specification are filled in the complement.

[0058] At block 410, service provider computing system 102 encrypts the complement of the tool specification using the public key received from client device 104.

[0059] In block 412, the service provider computing system 102 calculates an encrypted Minkowski sum of the encrypted object file and the encrypted complement of the tool specification. As described above, the encrypted Minkowski sum can be calculated in the frequency domain or the spatial domain. When calculated in the frequency domain, the object file can be transformed into the frequency domain by the client device 104 or the service provider computing system 102. Then, the encrypted Minkowski sum (referred to herein as the result file) is transmitted to the client device 104.

[0060] In block 414, the client device 104 decrypts the result file using the private key. In some embodiments, the client device 104 can also transform the decrypted result file into the spatial domain if it is not already in the spatial domain. In this embodiment, the result file identifies the area outside the part described by the 3D object file, which is accessible by the tool described by the tool specification.

[0061] In block 416, the client device 104 displays the result. For example, the 3D object model may be displayed on the GUI of the client device. In some embodiments, the result file can be used to modify the displayed 3D object model to highlight or otherwise identify areas that are accessible or inaccessible by the tool.

[0062] It will be understood that embodiments of protocol 400 may include additional blocks not shown in FIG. 4, and some of the blocks shown in FIG. 4 may be omitted. Additionally, the processes associated with blocks 402 - 416 may be executed in an order different from that shown in FIG. 4.

[0063] FIG. 5 is a diagram showing a process of finding non-printable features of parts using the Minkowski sum protocol according to some embodiments of the present disclosure. Referring to FIG. 1, the process executed by the client device 104 can be executed by the comparison software 114, and the process executed by the service provider computing system 102 can be executed by the comparison engine 118. The process of FIG. 5 uses the Minkowski sum protocol shown in FIGS. 2 and 3 as a primitive protocol, which is combined with additional operations to achieve the processing goals identified in the requirements. The process can start from block 502.

[0064] In block 502, the client device 104 obtains an object file. The object file can be a three-dimensional array of voxels representing an object that can be manufactured by a 3D printer. In some embodiments, the client device 104 or the service provider computing system 102 can convert the object file into a frequency domain representation. For the sake of brevity, the steps involved in the conversion between the spatial domain and the frequency domain are not shown in FIG. 4. However, it will be understood that the Minkowski sum can be calculated in the spatial domain or the frequency domain as described in connection with FIGS. 2 and 3.

[0065] In block 504, the client device 104 calculates the complement of the object file.

[0066] In block 506, the client device 104 encrypts the complement of the object file using the public key of the public-private key pair. Any suitable homomorphic encryption technique can be used.

[0067] Next, client device 104 sends a processing request to service provider computing system 102. The processing request can include an identifier that identifies the request as a request to find non-printable features within an object file, i.e., regions of the object file that are too small to print. In this embodiment, the comparison file may be referred to as a minimum printable feature file, and the minimum printable feature file describes the minimum printable features according to specifications applicable to the identified 3D printer. Thus, the request can also include an identification of a particular 3D printer or the minimum printable feature size. Along with the request, client device 104 can also send an encrypted complement of the object file (referred to as the first encrypted file in FIG. 5) and the public key used to encrypt the file.

[0068] In response to the request, service provider computing system 102, at block 508, obtains a minimum printable feature file, i.e., a comparison file that describes the minimum printable features of the 3D printer identified in the request. The minimum printable feature file may be a tensor in which components are arranged to form a shape (e.g., a circle, sphere, square, cube, etc.) centered at the origin and having a diameter equal to the size of the minimum printable feature. Referring to FIG. 1, the minimum printable feature file can be obtained from data storage device 116 of service provider computing system 102 or from third-party computing device 106. Additionally, the minimum printable feature file can be generated based on a description of the minimum printable feature size. For example, if the minimum printable feature size is 1 millimeter, the minimum printable feature file can be generated by creating a tensor that describes a sphere with a 1-millimeter diameter centered at the origin.

[0069] At block 510, service provider computing system 102 encrypts the minimum feature file using the public key received from client device 104.

[0070] In block 512, the service provider computing system 102 calculates the encrypted Minkowski sum of the first encrypted file and the encrypted minimum feature file. As described above, the encrypted Minkowski sum can be calculated in the frequency domain or the spatial domain. When calculated in the frequency domain, the first encrypted file can be transformed into the frequency domain by the client device 104 or the service provider computing system 102. The encrypted Minkowski sum generated in block 512 is referred to herein as an intermediate result. The intermediate result is transmitted to the client device 104.

[0071] In block 514, the client device 104 decrypts the intermediate result using the private key. In some embodiments, the client device 104 can also transform the decrypted intermediate result into the spatial domain if it is not already in the spatial domain.

[0072] In block 516, the client device 104 calculates the complement of the decrypted intermediate result.

[0073] In block 518, the client device 104 encrypts the complement of the decrypted intermediate result to generate an additional file referred to herein as the second encrypted file. The second encrypted file is transmitted to the service provider computing system 102.

[0074] In block 520, the service provider computing system 102 calculates the encrypted Minkowski sum of the second encrypted file and the encrypted minimum feature file. As described above, the encrypted Minkowski sum can be calculated in the frequency domain or the spatial domain. The encrypted Minkowski sum generated in block 520 is referred to herein as the result file. The encrypted result file is transmitted to the client device 104.

[0075] In block 522, the client device 104 decrypts the result file using the private key. In some embodiments, if the client device 104 does not yet have a spatial area, it can also convert the decrypted result file into a spatial area. In this embodiment, the result file identifies features of parts described by a 3D object file that are smaller than the minimum printable feature size applicable to a particular 3D printer.

[0076] In block 524, the client device 104 displays the result. For example, a 3D object model can be displayed on the GUI of the client device. In some embodiments, the result file can be used to modify the displayed 3D object model to highlight or otherwise identify features that are smaller than the minimum printable feature size.

[0077] It will be understood that embodiments of protocol 500 may include additional blocks not shown in FIG. 5 and that some of the blocks shown in FIG. 5 may be omitted. Additionally, the processes associated with blocks 502-524 may be performed in an order different from the order shown in FIG. 5.

[0078] FIG. 6 is a process flow diagram of a method for processing a 3D object model in a privacy-protected manner according to an embodiment of the present disclosure. Method 600 can be executed by hardware or a combination of hardware and software. For example, referring to FIG. 1, method 600 can be executed by a comparison engine 118 residing on a service provider computing system 102. The method can start at block 602.

[0079] At block 602, a request to process an encrypted object file and an encrypted object file is received from a remote computing device. The encrypted object file may include specifications of a 3D printable object in the form of a three-dimensional tensor (e.g., an array of voxels). The request is to process the encrypted object file to identify characteristics of the 3D printable object. Blocks 604, 606, and 608 may be executed in response to the request.

[0080] At block 604, an encrypted comparison file is obtained. The comparison file may be received from a local storage device or a third-party remote computing device. The comparison file may be encrypted using a homomorphic encryption key received from the remote computing device that sent the request. The comparison file may be received in an encrypted form from a third party. In some embodiments, the comparison file is also converted to a frequency domain representation before or after being encrypted.

[0081] At block 606, an encrypted Minkowski sum of the encrypted object file and the encrypted comparison file is calculated to generate an encrypted result file containing information about the characteristics, and the calculation of the encrypted Minkowski sum is performed without decrypting the encrypted object file. The Minkowski sum may be performed in the spatial domain or the frequency domain. The characteristics may vary depending on the nature of the comparison file and other calculations performed according to an embodiment.

[0082] At block 608, the encrypted result file is sent to the remote computing device.

[0083] Furthermore, depending on the details of a particular implementation, the encrypted result file may be converted to the spatial domain before being returned to the remote computing device.

[0084] Embodiments of method 600 may include additional blocks not shown in FIG. 6 and some of the blocks shown in FIG. 6 may be omitted. For example, depending on the type of analysis being performed, method 600 may include one or more additional rounds of receiving a file from a remote computing device and returning a result before a final result is obtained. The processes associated with blocks 602-608 may be performed in an order different from the order shown in FIG. 6.

[0085] FIG. 7 is a process flow diagram of a method for processing a 3D object model in a privacy-protected manner according to an embodiment of the present disclosure. Method 700 may be executed by hardware or a combination of hardware and software. For example, referring to FIG. 7, method 700 may be executed by comparison software 114 present on client device 104. The method may start from block 702.

[0086] In block 702, an object file including specifications of a 3D printable object is obtained. The encrypted object file includes specifications of a 3D printable object that may be in the form of a three-dimensional tensor (e.g., an array of voxels). The object file may be obtained, for example, from storage or generated from an object model. The object file may also be converted to a frequency domain representation depending on the protocol details of a particular implementation.

[0087] In block 704, the object file is encrypted using a public key to generate an encrypted object file. The public key may be part of a public key-private key pair generated according to homomorphic encryption technology. The public key is kept secret and not shared with the remote computing system.

[0088] In block 706, an encrypted object file and a request to process the encrypted object file to identify the characteristics of the 3D printable object are sent to the remote computing system. Further, in some embodiments, the public key is also sent to the remote computing system so that the remote computing system can encrypt the comparison file used in the calculation of the Minkowski sum. In some embodiments, the public key is sent to a third-party computing device, and the third-party computing device provides the encrypted comparison file to the remote computing system.

[0089] In block 708, the encrypted result file is received from the remote computing system. The encrypted result file includes the encrypted Minkowski sum of the encrypted object file and the encrypted comparison file. Further, the encrypted result file is generated by the remote computing system in the encrypted region.

[0090] In block 710, the encrypted result file is decrypted using the private key corresponding to the public key to generate an unencrypted result file.

[0091] In block 712, the unencrypted result file is processed to determine the characteristics of the 3D printable object. Processing the unencrypted result file may include converting the result file from the frequency domain to the spatial domain. Processing the unencrypted result file may also include displaying the information contained in the result file, generating a 3D visual representation of the result file, and / or changing the 3D visual representation of the corresponding object model using the result file.

[0092] Embodiments of method 700 may include additional blocks not shown in FIG. 7, and it will be understood that some of the blocks shown in FIG. 7 may be omitted. For example, depending on the type of analysis being performed, method 700 may include one or more additional rounds of sending and receiving files to and from a remote computing system before a final result is obtained. The processes associated with blocks 702-712 may be performed in an order different from the order shown in FIG. 7.

[0093] FIG. 8 is a process flow diagram of a method for identifying an external region of a 3D printable part accessible by a tool, according to an embodiment of the present disclosure. Method 800 may be performed by hardware, or a combination of hardware and software. For example, referring to FIG. 1, method 800 may be performed by comparison engine 118 residing on service provider computing system 102. Further, it will be understood that method 800 may use the Minkowski sum protocol described in connection with FIGS. 6 and 7 as a primitive protocol. Thus, the details described in connection with FIGS. 6 and 7 may also be applicable to method 800, depending on the design details of a particular implementation. The method can start at block 802.

[0094] At block 802, an encrypted object file and a request to process the encrypted object file are received from a remote computing device. The encrypted object file includes the specifications of a 3D printable object. The request is to process the encrypted object file to identify the regions of the 3D printable object accessible by the tool. Blocks 804, 806, and 808 may be performed in response to the request.

[0095] At block 804, a tool specification is obtained, the complement of the tool specification is calculated, and the complement of the tool specification is encrypted to generate an encrypted comparison file.

[0096] In block 806, an encrypted Minkowski sum of the encrypted object file and the encrypted comparison file is calculated to generate an encrypted result file that describes the region of the 3D printable object accessible by the tool. The calculation of the encrypted Minkowski sum is performed without decrypting the encrypted object file.

[0097] In block 808, the encrypted result file is sent to a remote computing device.

[0098] Embodiments of method 800 may include additional blocks not shown in FIG. 8, and it will be understood that some of the blocks shown in FIG. 8 may be omitted. The processes associated with blocks 802 - 808 may be performed in an order different from that shown in FIG. 8.

[0099] FIG. 9 is a process flow diagram of a method for identifying non-printable features of a 3D printable part according to an embodiment of the present disclosure. Method 900 can be executed by hardware, or a combination of hardware and software. For example, referring to FIG. 1, method 900 can be executed by a comparison engine 118 present on a service provider computing system 102. Further, it will be understood that method 900 can use the Minkowski sum protocol described in connection with FIGS. 6 and 7 as a primitive protocol. Thus, the details described in connection with FIGS. 6 and 7 can also be applied to method 900, depending on the design details of a particular implementation. The method can start from block 902.

[0100] In block 902, a first encrypted file and a request are received from a remote computing device. The first encrypted file is an encrypted complement of an object file including the specifications of a 3D printable object. The request is to process the first encrypted file to identify non-printable features of the 3D printable object. Blocks 906 - 912 may be executed in response to the request.

[0101] In block 904, an encrypted minimum feature file describing the minimum printable features of a 3D printer is obtained.

[0102] In block 906, a first encrypted Minkowski sum of the first encrypted file and the encrypted minimum feature file is calculated to generate an encrypted intermediate file, and the encrypted intermediate file is sent to the remote computing device.

[0103] In block 908, a second encrypted file is received from the remote computing device. The second encrypted file includes an encrypted complement of the encrypted intermediate file.

[0104] In block 910, a second encrypted Minkowski sum of the second encrypted file and the encrypted minimum feature file is calculated to generate an encrypted result file.

[0105] In block 912, the encrypted result file is sent to the remote computing device. The encrypted result file includes encrypted information describing non-printable features of the 3D printable object.

[0106] Embodiments of method 900 may include additional blocks not shown in FIG. 9, and some of the blocks shown in FIG. 9 may be omitted. It will be understood that the processes associated with blocks 902-908 may be performed in an order different from that shown in FIG. 9.

[0107] FIG. 10 shows a diagrammatic representation of a machine in an exemplary form of a computer system 1000 in which a set of instructions 1022 or processing logic 1026 for causing a machine to perform any one or more of the methodologies discussed herein may be executed. In various embodiments, the machine may be connected (e.g., networked) to other machines in a local area network (LAN), intranet, extranet, or the Internet. The machine may operate as a server or client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), tablet PC, personal digital assistant (PDA), cellular phone, web appliance, server, network router, switch or bridge, hub, access point, network access control device, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, although only a single machine is illustrated, the term "machine" shall also be construed to include any collection of machines that individually or jointly execute a set of instructions or multiple sets of instructions to perform any one or more of the methodologies discussed herein. In an embodiment, computer system 1000 may represent a service provider computing system 102, a client computing device 104, or another computing device or system.

[0108] An exemplary computer system 1000 includes a processing device 1002, a main memory 1004 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM)), a static memory 1006 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1018, which communicate with each other via a bus 1030. Any of the signals provided through the various buses described herein may be time-division multiplexed with other signals and provided through one or more shared buses. Additionally, the interconnections between circuit components or blocks may be shown as a bus or as a single signal line. Each of the buses may alternatively be one or more single signal lines, and each of the single signal lines may alternatively be a bus.

[0109] The processing device 1002 represents one or more general-purpose processing devices such as a microprocessor, a central processing unit, etc. More specifically, the processing device can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computer (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing another instruction set, or a processor implementing a combination of instruction sets. The processing device 1002 can also be one or more dedicated processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, etc. The processing device 1002 can execute processing logic 1026 for performing any of the operations and processes described herein.

[0110] The data storage device 1018 may include a machine-readable storage medium 1028, in which one or more sets 1022 (e.g., software) of instructions that implement any one or more of the operations and processes described herein are stored. The instructions 1022 may also exist, in whole or at least partially, in the main memory 1004 or in the processing device 1002 during their execution by the computer system 1000, and the main memory 1004 and the processing device 1002 also constitute a machine-readable storage medium. The instructions 1022 may be further transmitted or received through the network 1020 via the network interface device 1008. The processing logic 1026 and / or the instructions 1022 may include comparison software 114 and / or a comparison engine 118, which are configured to enable the processing device 1002 to perform any of the tasks described herein for processing an object model or an object file in a privacy-protected manner.

[0111] Although the machine-readable storage medium 1028 is shown as a single medium in the exemplary embodiment, the term "machine-readable storage medium" should be interpreted to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that store one or more sets of instructions. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer), such as software, a processing application. Examples of machine-readable media include, but are not limited to, magnetic storage media (e.g., floppy disks), optical storage media (e.g., CD-ROMs), magneto-optical storage media, read-only memory (ROM), random-access memory, erasable programmable memory (e.g., EPROM and EEPROM), flash memory, or other types of media suitable for storing electronic instructions.

[0112] The foregoing description sets forth numerous specific details, such as examples of specific systems, components, methods, etc., to provide a good understanding of some embodiments of the present disclosure. However, it will be apparent to those skilled in the art that at least some embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known components or methods are not described in detail or are presented in a simple block diagram form to avoid unnecessarily obscuring the present disclosure. Accordingly, the specific details described are merely illustrative. Specific embodiments may vary from these illustrative details and still be considered within the scope of the present disclosure.

[0113] In addition, some embodiments may be implemented in a distributed computing environment where a machine-readable medium is stored on or executed by two or more computer systems. Additionally, information transferred between computer systems may be pulled or pushed via a communication medium connecting the computer systems.

[0114] Embodiments of the claimed subject matter include, but are not limited to, various operations described herein. These operations may be performed by hardware components, software, firmware, or combinations thereof.

[0115] The operations of the methods herein are shown and described in a particular order, but the order of operations of each method may be changed so that a particular operation may be performed in a reverse order or so that a particular operation may be performed at least partially concurrently with other operations. In another embodiment, the instructions or sub-operations of separate operations may be in an intermittent or alternating fashion.

[0116] The foregoing description of the illustrated implementations of the invention, including what is set forth in the abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Specific implementations of the invention and examples thereof are described herein for illustrative purposes, but as will be recognized by those of ordinary skill in the art, various equivalent modifications are possible within the scope of the disclosure. As used herein, the terms “example” or “exemplary” are meant to serve as examples, instances, or illustrations. Any aspect or design described herein as “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the terms “example” or “exemplary” is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless otherwise specified or clear from the context, “X includes A or B” is intended to mean any of the natural inclusive permutations. That is, “X includes A or B” is satisfied under any of the foregoing instances where X includes A, where X includes B, or where X includes both A and B. In addition, the articles “a” and “an” as used in this application and the appended claims are generally to be construed to mean “one or more” unless otherwise specified or clear from the context as being directed to the singular form. Further, the use of the terms through “an embodiment” or “one embodiment” or “an implementation” or “one implementation” is not intended to mean the same embodiment or implementation unless so stated. Further, as used herein, terms such as “first,” “second,” “third,” “fourth,” etc. are meant to serve as labels to distinguish different elements and may not necessarily have a meaning in the order of their numerical designation.

[0117] It will be understood that the disclosures made above, as well as variations or alternatives of other features and functions, can be incorporated into many other different systems or applications. It is intended that various presently unforeseen or unexpected alternatives, modifications, variations, or improvements may subsequently be made by those skilled in the art, and these are also encompassed by the following claims. The claims may cover embodiments of hardware, software, or combinations thereof.

Claims

1. 1. A method for processing three-dimensional (3D) object files in a privacy-preserving manner, comprising: receiving, from a remote computing device, an encrypted object file including a specification of a 3D printable object and a request to process the encrypted object file to identify characteristics of the 3D printable object; In response to said request, Obtaining an encrypted comparison file; calculating, by a processing device, an encrypted Minkowski sum of the encrypted object file and the encrypted comparison file to generate an encrypted result file containing information about the characteristic, wherein calculating the encrypted Minkowski sum is performed without decrypting the encrypted object file; and transmitting the encrypted result file to the remote computing device; A method comprising:

2. 2. The method of claim 1 , wherein computing the encrypted Minkowski sum comprises computing a frequency domain element-wise product of the encrypted object file and the encrypted comparison file, and the encrypted result file is an encrypted frequency domain representation of the encrypted Minkowski sum.

3. Calculating the encrypted Minkowski sum comprises: computing a frequency domain element-wise product of the encrypted object file and the encrypted comparison file; converting the encrypted Minkowski sum into a spatial domain representation, the encrypted result file being an encrypted spatial domain representation of the encrypted Minkowski sum; The method of claim 1 , comprising:

4. The method of claim 1 , wherein computing the encrypted Minkowski sum comprises computing a spatial domain element-wise sum of the encrypted object file and the encrypted comparison file.

5. The method of claim 1 , wherein obtaining the encrypted comparison file comprises receiving the encrypted comparison file in encrypted form from another remote computing device.

6. Obtaining the encrypted comparison file includes: receiving an encryption key from the remote computing device; receiving an unencrypted comparison file from another remote computing device; encrypting the unencrypted comparison file using the encryption key to generate the encrypted comparison file; Including, The method of claim 1.

7. Obtaining the encrypted comparison file includes: receiving an encryption key and a file identifier from the remote computing device; receiving an unencrypted comparison file from a local storage device that corresponds to the file identifier; encrypting the unencrypted comparison file using the encryption key to generate the encrypted comparison file; Including, The method of claim 1.

8. The method of claim 1 , wherein the encrypted object file is an encrypted frequency or spatial domain representation of a 3D array of voxels representing a 3D object specified by an object model.

9. The method of claim 1 , wherein the encrypted comparison file is an encrypted 3D array of voxels representing a minimum printable feature, and the characteristics identify features of the 3D printable object that are smaller than the minimum printable feature.

10. 2. The method of claim 1, wherein the encrypted comparison file is an encrypted 3D array of voxels representing a specification of a tool, and the characteristics identify exterior regions of the 3D printable object that are accessible by the tool.

11. 1. A system for processing three-dimensional (3D) object files in a privacy-preserving manner, comprising: Memory, A processing device operably coupled to the memory, the processing device comprising: receiving, from a remote computing device, an encrypted object file including a specification of a 3D printable object and a request to process the encrypted object file to identify characteristics of the 3D printable object; In response to said request, Get the encrypted comparison file, calculating an encrypted Minkowski sum of the encrypted object file and the encrypted comparison file to generate an encrypted result file containing information about the property, the encrypted Minkowski sum being calculated without decrypting the encrypted object file; transmitting the encrypted result file to the remote computing device; A processing device; A system comprising:

12. 12. The system of claim 11, wherein to calculate the encrypted Minkowski sum, the processing device calculates a frequency domain element-wise product of the encrypted object file and the encrypted comparison file, and the encrypted result file is an encrypted frequency domain representation of the encrypted Minkowski sum.

13. To compute the encrypted Minkowski sum, the processing device: computing a frequency domain element-wise product of the encrypted object file and the encrypted comparison file; converting the encrypted Minkowski sum into a spatial domain representation, the encrypted result file being an encrypted spatial domain representation of the encrypted Minkowski sum; To carry out The system of claim 11.

14. The system of claim 11 , wherein to obtain the encrypted comparison file, the processing device receives the encrypted comparison file in encrypted form from another remote computing device.

15. To obtain the encrypted comparison file, the processing device: receiving an encryption key and a file identifier from the remote computing device; receiving an unencrypted comparison file from a local storage device that corresponds to the file identifier; encrypting the unencrypted comparison file using the encryption key to generate the encrypted comparison file; To carry out The system of claim 11.

16. A non-transitory computer readable medium having instructions stored thereon, the instructions, when executed by a processing device, causing the processing device to: receiving, from a remote computing device, an encrypted object file including a specification of a 3D printable object and a request to process the encrypted object file to identify characteristics of the 3D printable object; In response to said request, Obtaining an encrypted comparison file; calculating, by the processing device, an encrypted Minkowski sum of the encrypted object file and the encrypted comparison file to generate an encrypted result file containing information about the characteristic, the encrypted Minkowski sum being calculated without decrypting the encrypted object file; transmitting the encrypted result file to the remote computing device; To carry out Non-transitory computer-readable medium.

17. 17. The non-transitory computer-readable storage medium of claim 16, wherein to calculate the encrypted Minkowski sum, the instructions cause the processing device to calculate a frequency domain element-wise product of the encrypted object file and the encrypted comparison file, and the encrypted result file is an encrypted frequency domain representation of the encrypted Minkowski sum.

18. To compute the encrypted Minkowski sum, the instructions cause the processing device to: computing a frequency domain element-wise product of the encrypted object file and the encrypted comparison file; converting the encrypted Minkowski sum into a spatial domain representation, the encrypted result file being an encrypted spatial domain representation of the encrypted Minkowski sum; To carry out 20. The non-transitory computer-readable storage medium of claim 16.

19. 20. The non-transitory computer-readable storage medium of claim 16, wherein to obtain the encrypted comparison file, the instructions cause the processing device to receive the encrypted comparison file in encrypted form from another remote computing device.

20. To obtain the encrypted comparison file, the instructions cause the processing device to: receiving an encryption key and a file identifier from the remote computing device; receiving an unencrypted comparison file from a local storage device that corresponds to the file identifier; encrypting the unencrypted comparison file using the encryption key to generate the encrypted comparison file; To carry out 20. The non-transitory computer-readable storage medium of claim 16.

Images