Endpoints and protocols for trusted digital manufacturing

Abstract

Providing trusted endpoints and protocols for digital manufacturing. [Solution] An endpoint for trusted processing, comprising at least one secure controller configured for connection to a wide area network and at least one untrusted controller configured for local communication, wherein the endpoint is configured for connection to a processing machine, receives digitally signed data defining at least one item for manufacture, verifies the digitally signed data, and after verifying the digitally signed data, instructs the processing machine to manufacture at least one item.

Description

Technical Field

[0001] (Cross - reference to related applications) This application claims the benefits and priority of U.S. Provisional Application No. 63 / 020,191, filed on May 5, 2020, the entire disclosure of which is incorporated herein by reference as if set forth in its entirety herein.

[0002] The embodiments described herein relate to methods and systems for reliable on - demand manufacturing, and more particularly, but not exclusively, to methods and systems for verifying digitally signed data in a processing machine before manufacturing an item.

Background Art

[0003] Supply chains for modern manufacturing methods such as additive manufacturing (AM) and computer numerical control (CNC) machining include both physical raw materials and digital data elements. Digital data elements include configurations and low - level manufacturing instructions for individual machines and control, in whole or in significant part, the dimensional, mechanical, and sometimes material properties of the item to be produced. Digital manufacturing (DM) encompasses these highly data - driven manufacturing and processing processes. A well - known example of DM is 3D printing, where the computer (digital) model of an item is directly processed or "printed" on a 3D printer. To produce a particular item, a manufacturer requires data elements for that item and a compatible DM machine, and similarly, any change to the data elements will result in a change to the item produced, and such changes can be ambiguous to the user.

[0004] From a security perspective, DM has a large attack surface that is larger than that of conventional manufacturing. New attack surface vectors within DM include the disclosure or modification of data files (e.g., CAD models, AM artifacts, G-code, machine parameters, etc.). Any modification to data elements can also make it difficult to strengthen process controls to ensure, for example, that the material, mechanical, and functional properties of a given part are substantially the same and immutable when, where, or to its manufacturer.

[0005] Traceability (or a true digital twin) is crucial for certain parts (for example, in aircraft manufacturing), meaning that for a given instance of a part, the manufacturer needs to be able to determine when, where, and by whom it was manufactured, the design files used, the inspection standards applied, etc. While capturing and retrieving this type of information is a well-established process for conventionally manufactured parts, the temporal and spatial decoupling of the design, manufacturing, and operation of digitally and additively manufactured parts can make traceability more difficult.

[0006] Currently, DM machines themselves are difficult to resolve from a cybersecurity standpoint; that is, they typically contain sophisticated computer systems designed for standalone or industrial / commercial network deployments, but are not designed (or not necessarily intended) to meet the rigorous cybersecurity certifications typically required for network deployments in defense, medical, aerospace, and other security-critical environments, and / or more generally, are not trusted. The computer systems themselves can be threat vectors if they are connected to an internal network.

[0007] As a result, in many confidential environments, DM machines are "airgated" from confidential networks. DM artifacts (data) are "uploaded" and transported via read-only media (such as CD-ROMs). More generally, even in less stringent cybersecurity regulatory environments, uncontrolled copies of DM artifacts are vectors for industrial espionage, sabotage, and leakage of trade secrets, and can lead to circumvention of quality control processes, policies, and regulatory controls. Specifically, vulnerabilities introduced by uncontrolled copies of DM data and isolated DM machines include those related to privacy, authenticity, control, readiness, agility, and convenience. If not physically secure or destroyed, a malicious actor may gain access to the data on the medium. For example, a security breach on a user's computer could allow an attacker to modify DM / AM artifacts, for example, leading to a component defect in use. A well-intentioned user could "tweak" or modify DM artifacts, thereby jeopardizing process control. Currently, there is no secure way to digitally close the feedback loop (for example, between processing and the entire production process) for traceability, intellectual property (IP) protection, quality analysis, etc. The process itself is cumbersome and inconvenient for the user compared to, for example, clicking "print" in a web portal and printing a part on any machine authorized worldwide, similar to what a user could do with a network-connected printer.

[0008] From a commercial standpoint, DM could enable a new market where users could purchase licenses to process items on their own machinery rather than buying ready-made items. However, sellers would distribute data (similar to licensed software) instead of delivering physical items. The feasibility of commercializing such a market would depend on strengthening contractual clauses in the digital ecosystem, such as quantity limits or redistribution of DM data, which would require a strong relationship of trust and other certainties in the processes of data distribution, processing, and data removal (deactivation of licensed content upon expiration of the license period). However, as discussed earlier, DM / AM machines themselves are generally unreliable, thus requiring institutions to extend trust from the DM data source to the DM machine and its users, requiring a minimum level of trust. Therefore, there is a need for methods and systems to improve DM machines and to verify instructions for processing items. [Overview of the project] [Means for solving the problem]

[0009] This summary is provided to introduce, in a simplified form, some of the concepts that are further explained below in the detailed explanation section. This summary is not intended to identify or exclude any important or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0010] One embodiment relates to an endpoint for trusted processing. In some embodiments, the endpoint comprises at least one secure controller configured for connection to a wide area network and at least one untrusted controller configured for local communication, and the endpoint is configured for connection to a processing machine and is further configured to receive, verify the digitally signed data defining at least one item for manufacture, and after verifying the digitally signed data, to instruct the processing machine to manufacture at least one item.

[0011] In some embodiments, the secure controller is configured to be unmodifiable by the user.

[0012] In some embodiments, the endpoint is further configured to generate a receipt upon completion of the manufacture of at least one item.

[0013] In some embodiments, the processing machine is a 3D printer.

[0014] In some embodiments, the untrusted controller is configured to be modifiable by the user.

[0015] In some embodiments, the endpoints are network-connected.

[0016] In some embodiments, the digitally signed data is also encrypted. In some embodiments, the digitally signed data is encrypted using a key associated with the endpoint.

[0017] In some embodiments, at least one secure controller and at least one untrusted controller are electrically isolated from each other.

[0018] In some embodiments, the endpoint and the processing machine are placed side by side.

[0019] In another aspect, the embodiments relate to a method for trusted on-demand manufacturing. In some embodiments, the method includes the steps of: receiving digitally signed data describing at least one item for manufacture at an endpoint connected to a processing machine; verifying the digitally signed data at the endpoint; and, after verifying the digitally signed data, manufacturing at least one item using the digitally signed data, wherein the endpoint comprises at least one secure controller and at least one untrusted controller.

[0020] In some embodiments, digitally signed data is encrypted using a public key associated with the endpoint.

[0021] In some embodiments, the method further includes the step of inspecting the manufactured item for compliance with at least one parameter specified in the digitally signed data.

[0022] In some embodiments, the secure controller is configured to be unmodifiable by the user.

[0023] In some embodiments, the untrusted controller is configured to be modifiable by the user.

[0024] In some embodiments, the endpoint is network-connected.

[0025] In some embodiments, the digitally signed data is also encrypted. In some embodiments, the digitally signed data is encrypted using a key associated with the endpoint.

[0026] In some embodiments, at least one secure controller and at least one untrusted controller are electrically isolated from each other.

[0027] In some embodiments, the endpoint and the processing machine are co-located. The present invention provides, for example, the following. (Item 1) An endpoint for trusted processing, the endpoint comprising: at least one secure controller configured for connection to a wide area network; and at least one untrusted controller configured for local communication. The endpoint is configured for connection to a processing machine, and is further configured to: receive digitally signed data defining at least one item for manufacturing; verify the digitally signed data; and after verifying the digitally signed data, instruct the processing machine to manufacture the at least one item. An endpoint further configured to perform the above. (Item 2) The secure controller of item 1, configured to be unmodifiable by a user. (Item 3) The endpoint of item 1, further configured to generate a receipt upon completion of the manufacturing of the at least one item. (Item 4) The processing machine of item 1, which is a 3D printer. (Item 5) The untrusted controller of item 1, configured to be modifiable by a user. (Item 6) The aforementioned endpoint is the endpoint described in item 1, which is connected to the network. (Item 7) The aforementioned digitally signed data is also encrypted at the endpoint described in item 1. (Item 8) The digitally signed data is encrypted using the key associated with the endpoint, as described in item 7. (Item 9) The at least one secure controller and the at least one untrusted controller are electrically isolated from each other, from the endpoints described in item 1. (Item 10) The endpoint and the processing machine are juxtaposed endpoints as described in item 1. (Item 11) A method for reliable on-demand manufacturing, wherein the method is At the endpoint connected to the processing machine, receive digitally signed data describing at least one item for manufacturing, At the endpoint, the digitally signed data is verified, After verifying the digitally signed data, the digitally signed data is used to manufacture the at least one item. Includes, The endpoint comprises at least one secure controller and at least one A method that includes an untrusted controller. (Item 12) The method according to item 11, wherein the digitally signed data is encrypted using a public key associated with the endpoint. (Item 13) The method of item 11, further comprising inspecting the manufactured item for compliance with at least one parameter specified in the digitally signed data. (Item 14) The method described in item 11, wherein the secure controller is configured to be unmodifiable by the user. (Item 15) The untrusted controller is configured to be modifiable by the user, as described in item 11. (Item 16) The endpoint is connected to the network, as described in item 11. (Item 17) The digitally signed data is also encrypted, as described in item 11. (Item 18) The method according to item 17, wherein the digitally signed data is encrypted using a key associated with the endpoint. (Item 19) The method according to item 11, wherein the at least one secure controller and the at least one untrusted controller are electrically isolated from each other. (Item 20) The endpoint and the processing machine are placed side by side, according to the method of item 11. [Brief explanation of the drawing]

[0028] Non-exclusive and non-exclusive embodiments of this disclosure are described with reference to the following figures, and unless otherwise specified, similar reference figures refer to similar parts from various viewpoints.

[0029] [Figure 1] Figure 1 illustrates a block diagram of a trusted endpoint for digital manufacturing according to one embodiment.

[0030] [Figure 2] Figure 2 illustrates a flowchart of a method for reliable on-demand manufacturing according to one embodiment.

[0031] [Figure 3]Figure 3 depicts a trusted endpoint for digital manufacturing with an air gap traverse according to one embodiment.

[0032] [Figure 4] Figure 4 illustrates a flowchart of a method for digital manufacturing transactions according to one embodiment.

[0033] [Figure 5] Figure 5 illustrates a block diagram of a networked machining process at a trusted endpoint of digital manufacturing according to one embodiment. [Modes for carrying out the invention]

[0034] Various embodiments are described in full below with reference to the accompanying drawings, which form part of this specification, and these illustrate specific exemplary embodiments. However, the concepts of this disclosure can be implemented in many different forms and should not be construed as being limited to the embodiments described herein, but rather these embodiments will be understood by those skilled in the art, the concepts of this disclosure. The techniques and their implementations are provided as part of a thorough and complete disclosure to fully convey their scope. Embodiments may be practiced as methods, systems, or devices. Therefore, embodiments may take the form of hardware implementations, full software implementations, or implementations combining software and hardware aspects. Accordingly, the following detailed description should not be taken as limiting.

[0035] Any reference in the specification to “one embodiment” or “an embodiment” means that certain features, structures, or characteristics described in relation to an embodiment are included in at least one exemplary implementation or technique provided by this disclosure. Any other appearance of the phrase “in one embodiment” in the specification does not necessarily refer to all identical embodiments.

[0036] Furthermore, the terminology used within this specification has been selected primarily for readability and guidance purposes, and not to precisely describe or define the disclosed subject matter. Therefore, this disclosure is intended to be illustrative and non-limiting with respect to the scope of the concepts discussed herein.

[0037] The embodiments herein cover devices, hardware, systems, methods, protocols, and other inventions relating to extending robust trust, policies, controls, and traceability to manufacturing and operations performed on unreliable or untrusted equipment, where users operate the equipment with minimal trust. In security terminology, the embodiments implement means to ensure data privacy (INFOSEC) of data files as well as authenticity and integrity. Some embodiments cover methods and devices for trusted on-demand manufacturing.

[0038] Figure 1 depicts a block diagram of a trusted endpoint 100 for digital manufacturing according to one embodiment. In some embodiments, endpoint 100 may be a trusted endpoint. In some embodiments, endpoint 100 may be a DM endpoint.

[0039] In some embodiments, a method extends trust from a DM data source (DMDS) 110 to a DM device. In some embodiments, the device may constitute an endpoint 100, which is referred to herein as a trusted endpoint for digital manufacturing (DMTE) 105. In some embodiments, the DMTE 105 enables DM processing transactions, including secure, bidirectional, transactional communication between the DMDS 110 and the DMTE 105. The DMTE 105 facilitates two methods for DM processing transactions: a networked method (i.e., network connectivity exists between the DMDS 110 and the DMTE 105) and an air-gapped method (i.e., not networked). In some embodiments, the method of carrying data from the DMDS 110 to the DMTE 105 and vice versa is the only essential difference between these methods (as shown in more detail in Figures 3 and 5).

[0040] In some embodiments, the term "DMDS110" may refer to a system or service configured to store, manage, aggregate, sell, or otherwise provide DM data. In some embodiments, DMTE105 may be associated with, for example, a single DMDS110 within an organization. In some embodiments, DMTE105 may be associated with multiple DMDS110s.

[0041] In some embodiments, the DMDS110 (or its components and / or auxiliary services) may include a user interface (not shown), such as a web portal and a touchscreen, which enables a user to request the processing of an item in the DM machine 120, among other things, via the DMTE105. In some embodiments, the DMDS110 includes a Digital Manufacturing Transaction Manager (DMTM) involved in DM processing transactions, and in some embodiments, includes or communicates with a controller 125, which is a component that communicates with the network-connected DMTE105. In some embodiments, the DMDS110 may also interface with or communicate with an external (non-local) DM data source, for example, to obtain third-party data elements for processing. In some embodiments, the controller 125 may reside outside the DMTE105 and be separated from the DMDS110. In some embodiments, the controller 125 is a component of the DMDS110.

[0042] Some embodiments use strong cryptographic techniques as a primary mechanism for establishing and verifying trust between DMDS110 and DMTE105. For the purposes of disclosure herein, the terms public-key cryptography and public-key infrastructure (PKI) will be used to describe logical cryptographic operations. As will be understood by those skilled in the art, the embodiments are independent of any particular cryptographic system or its embodiments, and any cryptographic system that provides equivalent or stronger assurance may be used. In some embodiments, the ultimate source of trust (the starting point of the trust chain) in a PKI is a set of root certificate authorities. In some embodiments, without loss of generality, it may be assumed that, at least within a given administrative domain, DMDS110 and DMTE105 are configured to trust certificates and other material signed or issued by each other's root certificate authorities (or equivalents).

[0043] Both methods (network-connected and air-gapped) involve a non-normative logical sequence of the following events, some of which may be arbitrary, and some of which may or may not depend on the order of execution according to certain embodiments.

[0044] In some embodiments, the DMTE 105 may include a trusted computer platform 130 that is electrically isolated from the connected DM machine 120 by an isolation barrier 135, or galvanically isolated by at least one of these. As will be understood by those skilled in the art, in some embodiments, the electrical or galvanic isolation barrier may be implemented, for example, by using optical breakers, inductive couplings, coupling transformers, or other methods or components. In some embodiments, the DMTE 105 may include a "trusted side" 130 and an "untrusted side" 140. In some embodiments, the trusted side 130 is isolated from the untrusted side 140 using an isolation barrier. In some embodiments, at least one controller 127 on the trusted side 130 is electrically isolated from at least one controller 150 on the untrusted side 140 using an isolation barrier. In some embodiments, the secure controller 127 on the trusted side 130 is configured to be unmodifiable by the user. In some embodiments, the non-secure controller 150 on the untrusted side 140 is configured to be modifiable by the user.

[0045] Computer elements on the trusted side 130 communicate with the DM machine 120 via communication between a secure controller 127 and an untrusted controller 150, such as a microprocessor or field-programmable gate array (FPGA). In some embodiments, this array communicates data, and for example, the DM machine 120 communicates with the untrusted side 145. It provides isolation from the control path to prevent it from "breaking through" 40.

[0046] In some embodiments, the DMTE105 may be a standalone, internally embedded system or embedded device. The DMTE105 may comprise at least two components, namely a trusted side 130 and an untrusted side 140. In some embodiments, the trusted side 130 may comprise at least one interface 183 for mounting a DM package, such as a secure controller 127, an encryption key storage device 173, and a persistent local storage device 152, a user interface 189, and trusted computer resources.

[0047] In some embodiments, an untrusted side 140 with an interface, configured to connect to at least one external DM machine 120, may communicate with the trusted side 130 through an isolation barrier and an untrusted controller 150, such as a microcontroller or FPGA, configured to communicate with a secure controller 127, such as an FPGA or microcontroller, on the trusted side 130 145. In some embodiments, the secure controller 127 may be configured for connection to a wide area network (WAN) or a local area network (LAN). In some embodiments, the untrusted controller 150 may be configured for local communication.

[0048] In some embodiments, the DMTE 105 may support being connected to up to one DM machine 120. In some embodiments, there is a one-to-one relationship between the DMTE 105 and the DM machine 120. In some embodiments, the DMTE 105 may be configured to connect to and operate any DM machine 120 that supports one or more of the untrusted side interfaces outside the DMTE that are linked to the untrusted side 140. In some embodiments, this connection may require any modifications to the physical hardware of the DMTE 105 or to the firmware 138 or software of the trusted side 130 of the DMTE 105. In some embodiments, this connection may not require any modifications to the hardware, software, and / or configuration of the DM machine 120.

[0049] In some embodiments, the trusted computer platform 130 is electrically isolated or galvanically isolated from the untrusted computer platform 140 using an isolation barrier 135. In some embodiments, the connection on the untrusted computer platform 140 may be earth-referenced, so the trusted computer platform 130 may remain floating relative to earth. In some embodiments, the isolation withstand voltage of the isolation barrier 135 may be at least 5kV.

[0050] In some embodiments, communication between a trusted computer platform 130 and an untrusted computer platform 140 may use a low-level serial or parallel interface, such as Low Voltage Operating Signals (LVDS), which is only capable of exchanging application-level data. This interface may be an isolated data channel (IDC) 160 and may be configured to support duplex and / or half-duplex operation.

[0051] In some embodiments, the IDC prevents the untrusted computer platform 140 from accessing memory, storage, and control functions on the trusted computer platform 130. In some embodiments, the IDC bridges network traffic to or from the untrusted computer platform 140. Or it is not used for communication.

[0052] In some embodiments, other electrical or galvanic isolation logic level signals may pass between controllers 127 and 150 on the trusted side 130 and the untrusted side 140, but never cross the isolation barrier 135 to link signals from an external DM machine or an external untrusted side 140 interface.

[0053] In some embodiments, radio frequency / electromagnetic interference (RF / EMI) shielding may be used to surround the untrusted side 140, providing isolation from radiated interference to the outside of the trusted side 130 and DMTE 105. In some embodiments, such isolation is at least 80 dBm. In some embodiments, additional RF / EMI shielding may be used, for example, around the trusted side 130, power supply, etc. In some embodiments, the presence of a ground connection is not assumed.

[0054] In some embodiments, the DMTE may use at least one form of tamper resistance 170 that protects at least all key materials and volatile memory. In some embodiments, the isolation barrier 135 may include or be configured to surround both the trusted side 130 and the untrusted side 140 of the DMTE 105 (excluding the external interface).

[0055] In some embodiments, the protocols, interfaces, formats, and semantics for DMDS-DMTE communication, DMTE PKI and key management, DM packages, and DM processing receipts are well defined and standardized.

[0056] In some embodiments, the DMTE105 may include a battery-backed real-time clock (RTC) or equivalent (not shown). In some embodiments, network-based clock synchronization such as GPS or other clock synchronization methods may be used.

[0057] In some embodiments, the DMTE 105 may be physically located within the DM machine, for example, as a plug-in card or an optional module. In some embodiments, some essential differences between such embodiments and a “standalone” DMTE are the DMTE itself, as well as the type and format of the external interface on the untrusted side of the DMTE, where the DM machine is still treated as untrusted, and the interface on the trusted side 130 of the DMTE, including the user interface, is located outside the DM machine 120, as described below.

[0058] In some embodiments, the DMTE may have at least one trusted-side external interface. In some embodiments, all external interfaces connected to the trusted-side 130 may be clearly marked as such and located far enough away from the untrusted-side external interface 180.

[0059] In some embodiments, the DMTE 105 may include at least one 10 / 100 / 1,000-base-T Ethernet® interface 181 connected to the trusted side 130 and exposed via a standard RJ-45 jack. In some embodiments, the Ethernet® interface 181 may support auto-duplex, auto-MDI / MDX, and auto-negotiation.

[0060] In some embodiments, the DMTE105 is a built-in trusted DVD / CD drive. ROM drives, or other optical or magnetic memory removable media drives, etc. - May include a bubble medium 183. In some embodiments, the drive may be field-replaceable without special training, and drive replacement does not activate or trigger any tamper-resistant mechanism.

[0061] In some embodiments, the DMTE 105 may include a trusted, externally accessible reader ("Flash Card Reader") for one or more types of non-USB flash memory removable media 183 (e.g., SD card, CompactFlash®, etc.). In some embodiments including a Flash Card Reader, the embodiment may take measures to ensure that writing cannot be done to such media (e.g., by permanently deasserting write validity).

[0062] In some embodiments, the DMTE105 may include an externally accessible USB host port (not shown) that is hardware-restricted and trusted, with all other device profiles / types permanently disabled (in hardware), for use with keyboard and mouse HID devices. In some embodiments, the use of an external keyboard and / or mouse is not required for normal operation.

[0063] In some embodiments, the DMTE105 may have a display with a resolution typically better than or equivalent to 1,024 × 768, and a width and height of 6 inches or more. In some embodiments, the display is implemented by exposing a VGA, DVI, HDMI®, DisplayPort, or other display output interface 189 on the trusted side. In some embodiments, the display is implemented as a buried display. In some embodiments, the buried display is IP65 rated (environmental rating) or higher. In some embodiments, the buried display is field-replaceable without special training, and replacing the buried display does not activate or trigger any tamper-resistant mechanism.

[0064] In some embodiments, the DMTE 105 may include a user input mechanism in the user interface 189, comprising a touchscreen and / or soft keys located on the outer periphery of the embedded display (if applicable). In some embodiments, if soft keys are implemented, at least four soft keys are located adjacent to each edge of the display (left, right, top, and bottom). In some embodiments, the embedded touchscreen must comply with other requirements for the embedded display.

[0065] In some embodiments, the DMTE105 may include other buttons, switches, lights, annunciators, general-purpose inputs / outputs (GPIOs), etc., which may be coupled to the trusted side as needed.

[0066] In some embodiments, the DMTE 105 may include a reader (not shown) for a physical authentication token such as a smart card, in which case the DMTE includes equipment for an external reader, which includes a built-in trusted reader or is directly connected to the DMTE 105 via a dedicated trusted connector / interface (not shown).

[0067] For security reasons, the DMTE105 does not expose serial, JTAG, programming, or any other means of directly controlling or modifying the DMTE's hardware, firmware, and / or software from outside the tamper detection boundary (i.e., accessing such an interface would trigger tamper detection). In some embodiments, the DMTE 105 may be configured to expose a distinct, dedicated external trusted-side interface (not shown) to perform equivalent or similar functions only when the use of the interface requires strong authentication, and only when the DMTE's trusted platform module (TPM) 173 may be the source of authority.

[0068] The trusted side 130 may include a security system such as a TPM 173 or equivalent. In some embodiments, the TPM is involved in “key bundle” functions such as securely storing key material and generating key material, and can securely store other information such as certain system configuration information as needed. In some embodiments, privileged operations on the DMTE 105, such as confidential configurations and firmware upgrades, require authentication from the TPM 173 or equivalent. In some embodiments, the TPM 173 may be integrated into the processor 127 of the trusted side. In some embodiments, the TPM 173 may comprise one or more components that are distinctly different from the processor 127 of the trusted side.

[0069] In some embodiments, each DMTE105 is assigned its DMTE ID, which is a globally unique identifier. The DMTE ID can be used by an external system to look up the corresponding public key, certificate, or equivalent for an individual DMTE. Each DMTE105 has the ability to verify digital signatures, certificates, etc., presented to it using only locally available information (i.e., without browsing external resources). In some embodiments, the DMTE firmware is configured to be digitally signed. DMTE105 may be designed not to run or install unsigned firmware, firmware with an invalid signature, or firmware not signed by a trusted entity.

[0070] The trusted side of DMTE105 may include a highly reliable flash / solid-state memory (or equivalent) 152, which will be used as a persistent storage device. In some embodiments, the capacity of this persistent storage device is at least 32 GB. In some embodiments, the contents of this storage device are encrypted at the time of device installation. In some embodiments, the key material associated with the encryption is contained within or managed by TPM173.

[0071] In some embodiments, the entirety of the untrusted and trusted sides 140, 130 of DMTE105, including firmware, programmable hardware, hardware, software, source code, etc., may be audited, examined, and certified by one or more industry and / or government standards for hardware and software security.

[0072] In some embodiments, some embodiments of the DMTE 105 may assume that any connected DM device 120 may be untrusted and potentially adversarial. The hardware and software of the DMTE 105 are designed so that an attacker or adversary cannot gain control of, access, or modify data, or otherwise endanger the trusted side of the DMTE 105 from the untrusted side 140, except to the extent that the behavior of the untrusted side 140, such as electrical malfunction, may cause loss of service or denial of service to the DMTE 105 itself. As will be understood by those skilled in the art, in the context of cybersecurity, the nouns “attacker” and “adversary” are interpreted broadly to include humans, organizations, machines, or other automated devices.

[0073] In some embodiments, the trusted side 130 has the ability to restart, reset, and reflash / reload the firmware (or reprogrammable logic) of the untrusted side 140.

[0074] In some embodiments, the untrusted side 140 does not contain any non-volatile memory or persistent storage device that is writable by the untrusted side 140 and / or cannot be forcibly and reliably erased or overwritten by the trusted side 130.

[0075] In some embodiments, the sole assertion of trust on the untrusted side 140 of the DMTE 105 and the attached DM machine 120 is that DM instructions, configurations, and commands transmitted to the untrusted side 140 by the trusted side 130 will be faithfully transmitted to the DM machine 120, that the DM machine 120 will faithfully apply and accurately execute such instructions, configurations, and commands, and will provide truthful information / feedback in response to informational queries (e.g., job progress, firmware version, material to be loaded, etc.), and that the untrusted side 140 will faithfully transmit such information / feedback to the trusted side 130. Any DM machine 120 that fails to satisfy this assertion may be unusable for any application requiring or expecting any form of reliable machining.

[0076] Certain aspects of the implementation and control of policies, such as the verification of parts being processed, may assume that an authorized user (also referred to herein as the “operator”) interacting with DMTE105 is trustworthy and acting in good faith. That is, any aspect of a policy, implementation, or control whose accuracy or integrity depends on user input implicitly presupposes that the user is trustworthy and acting in good faith. In some embodiments, automated quality control or inspection may be utilized to reduce reliance on the operator’s trustworthiness.

[0077] In some embodiments, DMTE105 never uploads or copies DM data from DM data source 110 to persistent storage on DM machine 120 unless required for DM machine 120 to function and policy / control metadata within the DM package (securely provided by DMDS110) explicitly permits such upload or copy.

[0078] In some embodiments, the DMTE 105 stores the encrypted DM package (or its components) on the trusted persistent local storage device 152. In some embodiments, any data stored on the trusted persistent local storage device 152 may be permanently deleted upon closing of the transaction.

[0079] In some embodiments, unencrypted DM package content (other than specific metadata) is never written to persistent storage device 152. In some embodiments, such content may be stored in volatile memory, provided that it is guaranteed to be permanently erased or overwritten upon completion of the transaction.

[0080] In some embodiments, DMTE may generate a receipt for completed transactions. In some embodiments, the receipt may include information relating to processed parts (quantity, quality control data, etc.), operators (users), and / or other information required to satisfy policies, controls, and / or contractual guarantees. In some embodiments, the receipt may include encrypted content.

[0081] In some embodiments, each DMTE105 is configured to store digitally signed receipts in the persistent storage device 152 for a minimum time period, typically at least 180 days. During this time, authorized users can read, view, and, if necessary, upload the issued receipts to the DMDS110 or other authorized destination.

[0082] In some embodiments, the DMTE105 may not contain such an integrated wireless transceiver (e.g., 802.11 or Bluetooth®) unless the transceiver is inevitably embedded within other components (e.g., a system-on-chip integrated circuit), and all radio frequency (RF) inputs and outputs are permanently coupled to signaling ground and completely contained within the tamper detection boundary 170.

[0083] In some embodiments, the DMTE 105 includes an untrusted side external interface 180 for connecting the DM machine 120. In some embodiments, the external interface 180 connected to the untrusted side 140 may be clearly marked as such and located far enough away from the untrusted side external interface (e.g., 189).

[0084] In some embodiments, the DMTE105 may have a 2-wire or 4-wire RS232 serial interface 182, which is an untrusted side, and this interface 182 may be exposed via a 9-pin D-style connector (not shown). In some embodiments, the DMTE105 may have a 4-wire RS485 serial interface 182, which is an untrusted side. In some embodiments, if implemented, the RS485 interface 182 may operate in 2-wire (half-duplex) and 4-wire (full-duplex) modes.

[0085] The DMTE105 may have a 10 / 100Base-T Ethernet® interface 129, which is an untrusted side exposed via an RJ-45 jack. In some embodiments, the interface 129 is configured to support auto-negotiation of speed, MDI / MDX, and duplex. In some embodiments, the interface 129 may not be connected, bridged, or otherwise associated with a trusted side Ethernet® 181 or other trusted side network interface. Some embodiments optionally support 1,000Base-T Ethernet®.

[0086] In some embodiments, the DMTE105 may have an untrusted USB 2.0 (or later) host interface 131 exposed via a Type A or Type C female jack (not shown).

[0087] In some embodiments, the DMTE 105 may include an untrusted USB 2.0 (or later) device interface 131 exposed via a Type B or Type C female jack (not shown). In some embodiments, the USB host interface implementation may also enable or be reconfigured to enable device mode operation, in which case the same interface may be used for both host mode and device mode.

[0088] In some embodiments, the DMTE105 may include at least four untrusted single-ended general-purpose input / output (GPIO) 137 logic level connections, if included, which typically use a fifth pin connected to a separate logic level ground (0V) to a 5-pin Phoenix-style terminal block (or equivalent). It is exposed through.

[0089] Figure 2 illustrates a flowchart of a method for reliable on-demand manufacturing 200 according to one embodiment.

[0090] In some embodiments, the user requests the processing of a specific item on a particular DM machine controlled by the DMTE (step 210). In some embodiments, the request may specify certain parameters such as the material and quantity of the item to be manufactured. If the request is permitted according to the parameter set in the DMTE, a new DM transaction is initiated. In some embodiments, the request may not be permitted according to the parameter set in the DMTE, such as the method for manufacturing a weapon. In such cases, if the DMTE recognizes the request as an unacceptable request, the DM transaction request will be terminated.

[0091] In some embodiments, after the request is granted, the DMDS assembles a DM package for the specific item to be processed on the DM machine (step 220). In some embodiments, the DM package may include processing instructions such as G-codes, as well as control / policy assertions such as machine configuration and maximum quantity.

[0092] In some embodiments, the DMDS digitally signs the DM package using its signature certificate (or equivalent) (step 230). In some embodiments, this signature is an assertion that the DM package originates from a specific DMDS.

[0093] In some embodiments, the DMDS encrypts the DM package (step 240). In some embodiments, this encryption may be used to ensure data privacy across the contents of the DM package. In some embodiments, the DMDS may use the public key (or equivalent) of the DMTE to encrypt at least one of the DM packages or the signed contents within it. In some embodiments, the DMDS may not encrypt the DM package.

[0094] In some embodiments, the DM package is transported to the DMTE, where optionally, the DM package is decrypted and verified (step 250). In some embodiments, the DMTE may verify the digital signature of the DM package and the digital signature of any signed content. In some embodiments, if at least one of decryption or signature verification fails (step 265), an acknowledgment of the request failure is generated, transported to the DMDS, and returned (step 270).

[0095] In some embodiments, upon successful decryption and signature verification (step 255), the DMTE may begin processing the specific item (step 260). In some embodiments, the DMTE may begin processing in cooperation with the operator (user).

[0096] In some embodiments, each processed example of a specific item is matched, and DMTE records whether the match passed or not (step 280).

[0097] When the quantity specified in the DM package is used up (specific item matching and passing case), or at the operator's request to terminate the processing of the DM package, or at any other termination of the DM package, the DMTE generates a receipt for the processing of the DM package, which is transported to and returned to the DMDS (step 290).

[0098] Upon receiving a valid receipt for the DM package, DMDS completes and closes the transaction (step 295).

[0099] Figure 3 depicts a DMTE 305 having an air gap traverse 310 according to one embodiment 300. In some embodiments, the DMTE 305 and a processing machine such as a DM machine 320 may be placed side by side.

[0100] In some embodiments, the signed and encrypted DM package may be downloaded by the user 325 at interface 330, written to a removable medium 335 such as a CD / DVD ROM, and transported across the air gap 310 to the DMTE 305. In some embodiments, the DM package may be transported physically. In some embodiments, the DMTE 305 may generate a receipt 345 after the requested item has been processed in the DM machine 320, which is then transported across the air gap 310. In some embodiments, the DM machine may be a 3D printer. In some embodiments, the receipt 345 may be a QR code (registered trademark).

[0101] In some embodiments, each DM package assembled by DMDS350 may include a globally unique transaction identifier. In some embodiments, this identifier may be in the form of a type 4UUID (RFC4112). In some embodiments, this identifier may include a UTC timestamp with a precision of 1 second.

[0102] In some embodiments, the receipt 345 may be digitally signed by the DMTE 305. In some embodiments, the values ​​within the receipt 345 may be encrypted by the DMTE 305, for example, under the public key of the DMDS, in which case a second digital signature may also be included on the receipt 345. In some embodiments, at least one receipt 345 may be partially or fully encrypted. In some embodiments, the receipt 345 may include the transaction identifier UUID of the corresponding unencrypted DM package.

[0103] In some embodiments, the receipt 345 may be stored in a persistent storage device 360 ​​on the DMTE 305.

[0104] In some embodiments, unless explicitly permitted by the policy / control metadata of the DM package, DMTE305 will not authorize a DM package having a transaction identifier UUID consistent with any DM package for which DMTE305 has issued a receipt, and a person skilled in the art would recognize this as a form of defense against replay attacks.

[0105] In most embodiments, the stored receipt 345 may be visible on a display 370 associated with the DMTE 305. In some embodiments, the display 370 may be placed on top of the DMTE 305. In some embodiments, the stored receipt 345 may be visible as at least one of QR codes®, PDF417 2D barcodes, or other machine-readable graphic formats. In some embodiments, the operator may be able to print a hard copy of the receipt in the same format.

[0106] In some embodiments, DMT is applied to air-gapped transactions. E305 displays receipt 345 on its display 370, and the subsequent air gap Prior to approving the transaction, user confirmation (i.e., confirmation that the receipt has been captured) is required. In network-connected transactions, the digital content of the receipt is transmitted to the DMDS350 over the network. In some embodiments, the digital content may be transmitted in alphanumeric or binary format.

[0107] In some embodiments, the DMDS350 may expose an API that receives receipts in the form of an image (e.g., a digital photograph of a 2D barcode). In some embodiments, the DMDS350 may expose an API that receives receipts in the form of a binary or string (e.g., the decoded content of the receipt).

[0108] In some embodiments, a cross-platform mobile application is, It may be made available to users so that they can use a mobile device with a digital camera to take a picture of or scan the receipt and upload it to DMDS350 or other authorized system.

[0109] In some embodiments, the receipt 345, or other non-machine-machine interaction used for the air-gap transaction 300, may take a form other than a 2D barcode, image, or equivalent. For example, the receipt 345 may be presented as a string of characters that the user rewrites and transmits to the DMDS 350. In some embodiments, the data within the receipt 345 may be securely transmitted from the DMTE 305 to the DMDS 350 in a one-way manner without direct connectivity between the DMTE 305 and the DMDS 350 (i.e., across the air gap 310).

[0110] In some embodiments, the DMTE 305 may further include a printer 385, or a printing device connected to the trusted side. In some embodiments, the printer 385 is integrated into the DMTE 305, while in some embodiments, the printer 385 is located outside the DMTE 305 and connected to an interface provided by the trusted side. In embodiments with a printer 385, the printer 385 may be used to print a (physical paper) receipt 345 for transmission across the air gap 310. In some embodiments, the printer 385 may further be used to print hard copies of other information, such as inspection results.

[0111] In some embodiments, when a user sends a receipt to the DMDS350 for an air-gapped 310 transaction, the transmission confirms that any copies of the removable medium 335 and its contents have been securely destroyed or erased. In some embodiments, the DM package stored on the removable medium 335 may be strongly encrypted.

[0112] In some embodiments, upon issuance of receipt 345, the DMTE 305 may permanently erase the DM package and any of its contents (excluding any contents that may be contained within the receipt for the DM package) from all local storage devices 360 on the DMTE 305 (except for read-only removable media).

[0113] In some embodiments, the DMTE305 has the ability to receive and queue multiple parallel DM transaction requests and DM packages. In some embodiments, if the queuing step is supported, an operator may be able to select a DM package to be processed and / or switched or modified from among multiple queued packages via interface 330 or a user interface associated with the DMTE305. This feature allows for the sequential processing of several parts, e.g., components of an assembly, or time-sharing of the DM machine 320. Make it possible.

[0114] In some embodiments, air-gapped DMTE305s (i.e., DMTEs that never communicate with DMDS350s over the network) can be configured to approve DM requests and packages from multiple DMDS350s.

[0115] In some embodiments, the DMTE 305 is configured to allow an authorized operator (user) to request the processing of an ad-hoc, unauthorized, and / or unsigned DM package stored and distributed on a removable medium 335 (for example, for prototyping, testing, or under extenuating circumstances). In some embodiments, during such processing, the DMTE 305 always prominently displays a message on the display 370 indicating that ad-hoc processing is in progress. While there is no “transaction” for such processing, the DMTE 305 may generate and record a receipt 345 for such processing. In some embodiments, “ad-hoc” processing is disabled by default and is not enabled in production or development environments.

[0116] In some embodiments, the DMTE 305 hardware can ensure that the medium 335 is accessed in a read-only manner, that is, the DMTE hardware can ensure that data cannot be written to the medium 335.

[0117] In some embodiments, the removable medium 335 is a non-volatile memory module such as a flash or SD card. In these embodiments, hardware read-only assurance can be implemented by physically disconnecting a “write-allow” pin / connector on the external connector on the separate trusted side. In some embodiments, the write-allow pin is clipped or completely removed from the connector. In some embodiments, this allows for the convenient use and reuse of an unmodified non-volatile memory module to transmit the DM package to the DMTE 305, while ensuring that the medium is not written to on the DMTE 305 side of the air gap 310.

[0118] In some embodiments, the medium 335 may include a container configured to store files and documents such as machine-readable metadata files, machine-readable DM machine configuration files, DM processing files, machine-readable and machine-executable inspection or test specification files, human-readable documents or files, machine-readable DM machine interface definition files, or digital signatures. In some embodiments, the container of the medium 335 may be digitally signed. In some embodiments, the signature may be stored separately or placed within the container. In some embodiments, the metadata file describes the contents of the container and the corresponding DM recipe. In some embodiments, the metadata file may further specify specific actions to be taken prior to, during, and / or after DM processing. In some embodiments, the metadata file includes a machine-readable declaration and parameterization of policies, controls, or other rules to be enforced or applied to the associated DM transaction.

[0119] In some embodiments, the metadata file defines an exact DM machine 320, or an equivalent class of DM machines whose recipes are compatible with it. In some embodiments, the step of defining an exact DM machine 320 may include the model of the DM machine 320, the manufacturer, firmware revisions, etc. In some embodiments, the DM machine 320 may be configured to connect any existing files via an interface. In some embodiments, the DM machine 320 has an endpoint that communicates with the defined DM machine 320. The methods that should be defined may include, but are not limited to, data encoding, timing, electrical / signaling methods, physical layer protocols, application layer protocols, and error handling semantics.

[0120] In some embodiments, the combination of metadata, DM machine configuration, DM processing file, and, where applicable, DM interface file may fully define and constrain the processing of a specific item on a specific DM machine 320 from a specific material (e.g., a specific metal alloy powder).

[0121] In some embodiments, the container on the removable medium 335 is an archive file such as ZIP or TAR. In some embodiments, the container supports data compression.

[0122] In some embodiments, the DM recipe may further include a digital signature on one or more of its contents. In some embodiments, these digital signatures assert the authoritative source or origin of the individual contents.

[0123] In some embodiments, one or more of the content may be encrypted. In some embodiments, the metadata further comprises a specification for the specific content of the DM receipt, which is generated for a DM transaction for a given recipe.

[0124] In some embodiments, there may be many DM recipes for a given item, each recipe being specific to processing on a particular DM machine 320, and each recipe being produced from a specific material.

[0125] In some embodiments, the DM recipe includes passing inspections, tests, etc. Items processed according to the Shipi are developed, verified, and proven to have predictable, well-characterized mechanical, dimensional, material, aesthetic, and / or other properties with high reliability. In some embodiments, these properties may be invariant with respect to the place and time the item is processed. In some embodiments, these properties are invariant in multiple (types) DM machines for a given material.

[0126] In some embodiments, two or more of the files containing recipes may be incorporated into a single file, and / or one logical file may be split into multiple separate files.

[0127] Some embodiments may comprise a DM package method, mechanism, protocol, and system components. In some embodiments, the DM package may comprise a container, a DM recipe, at least one machine-readable metadata file, and DM transaction metadata, including a DM transaction identifier (ID) and one or more digital signatures. In some embodiments, the DM recipe, metadata file, and DM transaction metadata may be contained within the container and digitally signed. In some embodiments, the signatures may be stored separately or placed within the container. In some embodiments, the metadata file fully describes the contents of the container.

[0128] In some embodiments, the metadata file and / or DM transaction metadata, or a combination thereof, identify an endpoint or set of endpoints intended to execute the corresponding DM transaction. DM transaction metadata includes machine-readable declarations and parameterizations of policies, controls, or other rules that will be enforced or applied to the transaction. In some embodiments, declarations and parameterizations may be added to those that may be specified in the DM recipe.

[0129] In some embodiments, the container is an archive file such as ZIP or TAR. In some embodiments, the container supports data compression. In some embodiments, the DM package may further contain a digital signature on one or more of its contents. In some embodiments, these digital signatures assert the authoritative source or origin of the individual contents. In some embodiments, the signed data within the DM package may also be encrypted.

[0130] In some embodiments, the DM package is transmitted to the processing environment via a removable digital medium 335, such as a CD / DVD ROM or a removable storage device. In some embodiments, the DM package is transmitted to the processing environment via a computer network. In embodiments where the DM package is transmitted to a DMTE 305, the DM package comprises metadata, DM recipes, and a set of files necessary to satisfy a DM transaction request for a specific item on a specific DM machine 320, which is served by a specific DMTE 305. In some embodiments, no other external information is required by the DMTE 305 to satisfy the transaction request.

[0131] In some embodiments, the DM recipe includes all data files, metadata, machine configuration, user instructions, actionable inspection or approval requirements, material specifications, and / or other information required to process a given item produced from a specific material on a particular DM machine 320. In some embodiments, the DM recipe may be transmitted from the DMTE 305 to the DM machine 320 using at least one of a serial drive, USB, P2P network, or other equivalents recognized by those skilled in the art 395.

[0132] In some embodiments, the policies, controls, and / or rules enforced include limitations relating to the number of parts that can be processed from the package, the date and time after which the package is invalidated (or cannot be processed), distribution information for processed parts, or requirements for users performing inspections.

[0133] In most embodiments, DM package files may be encrypted under a DMTE or the recipient's public key (or equivalent) during device installation and in transit (over a communication line). Decrypted files may be digitally signed by individual DMDS350s (data source or authorization source), and their contents may be digitally signed (individually or separately) by their individual authorization sources.

[0134] In some embodiments, where the untrusted side of the DMTE comprises a programmable logic device such as an FPGA or microcontroller, the recipe may further comprise one or more firmware / bitstream files that will be used to program the untrusted side, enabling the system to add support for new DM machines in a data-driven manner without modifying the DMTE itself, and also enhancing the recipe so that items processed from the recipe are each processed using the same interface logic / firmware.

[0135] Figure 4 shows a flowchart of a method for a digital manufacturing transaction 400 according to one embodiment. —Draw the chart. In some embodiments, DM processing transactions are implemented by a DM Transaction Manager (DMTM). In some embodiments, the DMTM is a component of the DMDS or surrounding system.

[0136] In some embodiments, a user request initiates a DM processing transaction ("transaction") (step 410). In some embodiments, the user submits the request through a user interface or API. In some embodiments, the transaction request may comprise the identity of the requesting user, an identifier for the specific item to be processed, an identifier for the specific DM machine, and, where applicable, a specific DM recipe defined by the user. In some embodiments, the request may further include specific materials, or materials from which the item should be processed. In some embodiments, the DM recipe is automatically selected by a DMTM, DMDS, or another component.

[0137] In some embodiments, upon receipt of the DM transaction request, the DMTM verifies the request (step 420). In some embodiments, this verification may include at least one of the following: verification that the requesting user is authorized to access and process a given item; verification that the requesting user is authorized to request processing on a selected DM machine; verification that a selected DM recipe is compatible with the selected DM machine, if a DM recipe is not selected, verification that a DM recipe compatible with the selected DM machine exists; verification that the facility where the selected DM machine is located is capable of performing the required quality control or inspection; verification that the selected item is authorized to be processed at the location of the selected DM machine (for example, to comply with the requirements of the International Trade in Arms Regulations (ITAR) or other contractual obligations); or verification that the requested item to be manufactured complies with at least one parameter specified in the digitally signed data.

[0138] In some embodiments, if matching fails (step 425), the DM transaction request is rejected (step 430). In some embodiments, the DMTM takes action to inform the requesting user that the request has been rejected. For example, in some embodiments, the user may receive an alert on the interface that the DM transaction has been rejected. In some embodiments, the DMTM may include beeping or a warning light to indicate to the user that the request has been rejected.

[0139] In some embodiments, the DMTM may create a log entry for rejected transaction requests (step 440). In some embodiments, such an entry may not be associated with a transaction identifier if the transaction was never opened / started.

[0140] In some embodiments, if the matching is successful (step 435), the DMTM opens a new DM transaction for the request (step 450).

[0141] In some embodiments, each DM transaction is assigned a unique transaction identifier (step 460). In some embodiments, the identifier may be in the form of a type 4UUID [RFC4122]. In some embodiments, from step 460 onward, all state changes or updates related to this transaction are permanently stored.

[0142] In some embodiments, the DMTM assembles DM packages for transactions. Assume (step 470). In some embodiments, the DMTM decomposes and retrieves any non-local data elements requested for processing. The DM processing may fail at this point if the external resources are unavailable or the request is refused. In this event, the DMTM closes the transaction with a failure status.

[0143] If all elements have been successfully disassembled, the DM package may be delivered to the DMTE of the DM machine or an equivalent location where the item is processed (step 480). In some embodiments, the receipt may be delivered to the DMTM (step 481).

[0144] In some embodiments, the DMTM verifies the receipt issued by the DMTE or equivalent (step 482). Some embodiments have well-defined semantics and procedures for handling invalid receipts.

[0145] In some embodiments, after verifying the receipt, DMTM may delete any copies of the external data element that it may own (step 490). In some embodiments, DMTM forwards the receipt to the third-party owner or other authorized agent of the external data element, and if third-party licensing rights are involved in the transaction, individual licensing rights are transferred when communicating with the licensor.

[0146] In some embodiments, the DMTM closes the transaction (step 495). In some embodiments, step 495, which closes the transaction, may include, where applicable, the DMTM issuing a notice to other systems, agents, users, etc.

[0147] In some embodiments, the DMTM periodically checks open transactions and, if necessary, the request status from network-connected DMTEs (or equivalents). In some embodiments, the DMTM checks open transactions and, if necessary, the request status from network-connected DMTEs (or equivalents) on demand. For open transactions with associated licensing / lease rights, the DMTM has a mechanism to notify the requesting user, supervisor, or other designated person to whom the individual licensed / leased content has not been transferred, and / or takes other actions as stipulated in the policy or, in some embodiments, provided by the implementation.

[0148] In some embodiments, an authorized user may terminate an open transaction awaiting receipt if the processing facility is destroyed or due to equipment failure. This type of transaction termination results in a unique record in the transaction log, including the identity of the user who requested the transaction termination. If the transaction is associated with a licensing / lease right, the DMTM may transmit a distinct form of receipt to the lessor / licensor, i.e., it may uniquely indicate that the transaction did not terminate successfully, and the DMTM may provide the lessor / licensor with any gap information it may have regarding the DM transaction, such as the number of DM processes, which is reported by the DMTE during periodic status checks.

[0149] In some embodiments, transaction log entries for open, close, receipt recording, abnormal termination, lease acquisition, and lease transfer are digitally signed by the DMTM. In some embodiments, the DMTM may sign any transaction log entries as needed.

[0150] In some embodiments, the DMTM supports the ability to manage the processing of composite items (items that are assemblies of several other items) transactionally and automatically. In some embodiments, the DMTM supports the ability to fulfill DM processing requests across multiple DMTEs (for example, when multiple instances of an item are required).

[0151] In some embodiments, the DMTM supports the ability for an authorized user to view pending (open) transactions for a particular DMTE (or equivalent) or group of DMTEs, and for an authorized user to set priorities for pending jobs that are queued per machine.

[0152] Figure 5 depicts a block diagram 500 of a networked machining process at a trusted endpoint 505 of digital manufacturing, according to one embodiment. In some embodiments, signed and encrypted DM packages are transmitted from DMDS 510 to DMTE 505 via the network 515. Similarly, receipts are returned to DMDS 510 after the completion of machining at the DM machine 520.

[0153] In some embodiments, the user may interact with the DMDS 510 directly or indirectly at the interface 530. In some embodiments, the user may be geographically distant from the DMDS 510 and / or DMTE 505. In some embodiments, the DMTE 505 and the DM machine 520 are placed side by side.

[0154] In some embodiments, a user requesting a given network-connected DM processing transaction, and other authorized users, have the ability to verify, through interaction with DMDS510 or another authorized system, that the corresponding DM package has been delivered to the corresponding DMTE505, to check whether a receipt has been received, to view the receipt, and to refer to other relevant transaction information.

[0155] In some embodiments, an authorized user has the ability to interrupt a network-connected DM processing transaction via DMDS510 or another authorized system prior to the distribution of individual DM packages to individual DMTE505s. In this case, no receipt is generated, and the transaction is closed.

[0156] In some embodiments, an authorized user may interrupt a DM processing transaction via DMDS510 or another authorized system before processing has begun. In this case, DMTE505 issues and transmits a receipt indicating that processing has not begun, and the transaction is successfully closed.

[0157] In some embodiments, in response to a network-connected DM processing request and the receipt of the associated DM package, the DMTE505 may alert the operator via its display and / or other annunciator that a new “job” has arrived.

[0158] In some embodiments, further interaction between the operator and the DMTE505 may be required, for example, to confirm the loading of input materials or other preparation steps.

[0159] In some embodiments, the operator has the ability to reject a network-connected DM processing request. In such cases, the DMTE505 issues and transmits a receipt indicating that processing was not initiated, and the transaction is successfully closed.

[0160] In some embodiments, upon receipt of a valid DM package, the DMTE505 will notify the individual DMDS510 that it has received the package and that the package is valid.

[0161] In some embodiments, the DMDS510 can securely query the network-connected DMTE505 for the status of any DM processing request (identified by a transaction identifier UUID), including fetching the corresponding receipt (if issued).

[0162] In some embodiments, the network connection 515 between DMDS510 and DMTE505 is via a secure encrypted protocol (such as carrier layer security). In some embodiments, the establishment of the connection may include mutual authentication, for example, via client and server certificates. In some embodiments, additional security mechanisms are implemented at other protocol layers.

[0163] In some embodiments, upon completion of a network-connected transaction, DMDS510 informs DMTE505 that the receipt has been successfully delivered, and DMTE505 attempts to transmit the corresponding receipt to the requesting DMDS510 instance. In some embodiments, if DMTE505 is unable to deliver the receipt, it may retry the delivery a randomly selected number of times, typically divided into intervals of at least 30 minutes, and the redistribution of the receipt will typically be completed after a certain time interval without exceeding 72 hours.

[0164] The methods, systems, and devices discussed above are embodiments. Various configurations may omit, substitute, or add various procedures or components as needed. For example, in alternative configurations, the method may be carried out in a different order than described, and its various steps may be added, omitted, or combined. Also, features described for one configuration may be combined in various other configurations. Different aspects and elements of a configuration may be combined in similar ways. Furthermore, technology evolves, and therefore many elements are embodiments and do not limit the scope of this disclosure or claims.

[0165] For example, embodiments of the present disclosure are described above with reference to block diagrams and / or operational illustrations of methods, systems, and computer program products according to embodiments of the present disclosure. Functions / actions referred to in blocks may occur outside the order shown in any flowchart. For example, two blocks shown consecutively may actually be executed substantially in parallel, or blocks may sometimes be executed in reverse order depending on the associated functionality / action. In addition, or alternatively, not all blocks shown in any flowchart need to be implemented and / or executed. For example, if a given flowchart has five blocks containing functions / actions, it is possible that only three of the five blocks are implemented and / or executed. In this embodiment, any three of the five blocks may be implemented and / or executed.

[0166] The statement that a value exceeds (or surpasses) a first threshold is equivalent to the statement that the value satisfies or exceeds a second threshold that is slightly greater than the first threshold, for example, the second threshold being a single value higher than the first threshold within the resolution of the relevant system. The statement that a value is less than (or within) a first threshold is equivalent to the statement that the value is less than or equal to a second threshold that is slightly lower than the first threshold, for example, the second threshold being a single value lower than the first threshold within the resolution of the relevant system.

[0167] Specific details are given in the description to provide a complete understanding of the exemplary configurations (including implementations). However, the configurations may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques are shown without unnecessary details to avoid obscuring the configurations. This description provides only exemplary configurations and does not limit the scope, applicability, or configurations of the claims. Rather, the foregoing descriptions of configurations will provide a permit to those skilled in the art for implementing the techniques described. Various modifications may be made in the function and arrangement of elements without departing from the spirit or scope of this disclosure.

Claims

[Claim 1] The invention as described in the drawings of the present application.

Images