Patent Description:
However, the ability to reconstruct an object from a digital representation using arbitrary manufacturing equipment and material introduces certain technical challenges related to the verification and validation of constructed objects. Current systems for additive manufacturing lack verification and validation systems for ensuring that objects produced by the process are appropriately certified. If, for example, a replacement part for an industrial asset is possible to produce via an additive manufacturing process, any user with access to an appropriately configured additive manufacturing device can reproduce the part. End users who purchase or otherwise receive such a part of no way of verifying that a replacement part manufactured in this way was produced using a correct build file, using correct manufacturing media, and on a properly configured additive manufacturing device. A fault, failure, or non-standard condition at any step of the additive manufacturing process or with any material component of the produced part may result in a catastrophic failure of that part when installed in the industrial asset.

Document reference <NUM> discloses additive manufacturing making use of blockchain to record various steps of the process.

Document reference <NUM> delves into digital security risks to additive manufacturing as well as the various stakeholders involved in securing its processes.

It would therefore be desirable to provide systems and methods for implementing a historical data record of an additive manufacturing process with verification and validation capabilities that may be integrated into additive manufacturing devices.

The invention is defined by the independent apparatus claim <NUM> and method claim <NUM>. Embodiments of the invention are defined by the appended claims.

Some embodiments generally relate to methods and systems for implementing a distributed ledger-based manufacturing history of an additive manufacturing process. Embodiments include additive manufacturing devices that include hardware configured to enable distributed ledger access and authentication of various inputs and outputs of an additive manufacturing process. Embodiments further include systems and methods supporting the verification and validation of output objects, including systems and methods with the capability of identifying a particular output object as "certified" in response to determining that the distributed ledger history associated with the object meets certain criteria.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the embodiments.

The following does not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.

The inventors have recognized that the problems of verification and validation of objects printed using additive manufacturing devices pose significant obstacles to the democratization and uptake of the technology. To this end, the inventors have implemented electronic processes that generate a cryptographically protected electronic records that may be used to verify, validate, and certify objects produced using additive manufacturing techniques. Furthermore, these electronic records allow for a flexible, straightforward mechanism for analyzing object histories that provide improved techniques for identifying the cause of faults and errors.

To this end, the inventors have developed improved additive manufacturing devices and techniques that enable interaction with a distributed ledger database to record interactions between an object and various devices, materials, and processes through an additive manufacturing process. As a specific example, embodiments may interact with a blockchain ledger to record elements of the manufacturing process in a format that ensures each transaction is properly signed and/or validated, and that signed/validated transactions are not able to be retroactively altered. Embodiments include both additive devices configured to utilize such a distributed database and other devices that enable interaction with the same distributed database by other components of the additive manufacturing process. For example, a manufacturer of additive manufacturing media may transact with the distributed database when producing the manufacturing media, such that each lot of media is associated with a particular transaction signed by the manufacturer. Similarly, a build file authoring system or author may transact with the distributed database when authoring a new build file to create a record that may be employed to later validate the build file.

It should be appreciated that embodiments of the distributed ledger database may be implemented according to various protocols and systems capable of providing the functionality described herein. An example embodiment utilizes the blockchain protocol, but it should be appreciated that various other similar frameworks, protocols, and/or mechanisms for providing distributed ledger database techniques that are capable of supporting transaction validation and authentication using a distributed ledger may also be employed.

As used herein, the term "distributed ledger" should be understood to refer to a type of database that is spread across multiple parties. Records stored in such a distributed ledger may be stored in a continuous ledger or organized into blocks, as in the case of the "blockchain protocol. " In the present context, embodiments may be implemented according to various configurations of the distributed ledger. For example, embodiments may employ permissioned or unpermissioned ledgers, and such ledgers may be public or private depending upon the desired participants. As a particular example, embodiments may implement multiple redundant copies of a database on disparate computing nodes, with a shared ledger of hashed transactions made to those databases. The shared ledger may be employed to enable individual copies of the database to verify the transactions written to each database.

As used herein, the term "blockchain" refers to a type of distributed ledger database that encodes records into "blocks" of a number of records. Blocks are chained together by including references in blocks to preceding and/or subsequent blocks.

As used herein, the terms "additive manufacturing device", and "additive printer" should be understood to refer to any manufacturing device that serves to produce a three dimensional output object from a digital file using techniques that may include, but are not limited to, fused deposition modeling, fused filament fabrication, direct ink writing, stereolithography, digital light processing of photopolymers, powder bed head 3d printing, electron beam melting, selective laser melting, selective heat sintering, selective laser sintering, direct metal laser sintering, laminated object manufacturing, directed energy deposition, or electron beam freeform fabrication.

<FIG> is a high-level architecture of a system <NUM> for implementing a distributed ledger-enabled additive manufacturing device in accordance with some embodiments. The system <NUM> provides for improved functionality of an additive printer <NUM> by enabling verification and validation functionality for the manufacturing process and various components thereof. The system <NUM> advantageously provides an integrated system that utilizes a blockchain or other distributed database ledger to enable validation across various elements of an additive manufacturing process. The system <NUM> particularly describes a distributed ledger <NUM> in communication with one or more additive printers <NUM>, build file authoring systems <NUM> and material manufacturers <NUM>, though it should be appreciated that various other users or stakeholders of an additive manufacturing process (e.g., a customer purchasing a produced object) may also access the distributed ledger <NUM> in some embodiments, such as to verify the origin or manufacturing process used to manufacture a particular object.

The additive printer <NUM> may be any additive manufacturing device as known in the art. The additive printer <NUM> receives a build file <NUM> which contains instructions for manufacturing an output object <NUM>. The build file <NUM> may be provided in any suitable format for instructing the additive printer <NUM> to construct the object, including but not limited to the. X3G, file extensions, or the like. The build file <NUM> may be created by the build file author <NUM>. It should be understood that while some exemplary embodiments are generally described herein with respect to additive manufacturing devices, various non-claimed embodiments may also be implemented for other digital manufacturing processes that are not necessarily "additive". For example, embodiments may also be employed with investment casting processes, etching processes, and the like.

At the time the build file <NUM> is created, the build file author <NUM> may generate an authoring transaction to the distributed ledger <NUM> using a private key assigned to the build file author <NUM>. The build file author <NUM> may also encode the build file <NUM> with a public key corresponding to the private key, enabling authentication of the build file <NUM> by the additive printer <NUM> via the distributed ledger <NUM>.

Similarly, the material manufacturer <NUM> may generate a material manufacturing transaction via the distributed ledger <NUM> upon manufacturing of a lot of material, such as a powder lot <NUM>. The material manufacturer <NUM> may sign the material manufacturing transaction with the distributed ledger <NUM> using a private key associated with the material manufacturer <NUM>, and indicate a serial number or public key on the powder lot <NUM> itself (e.g., on the packaging, such as a barcode or Quick Recognition (QR) code). Upon initiating a manufacturing action using the powder lot <NUM>, the additive printer <NUM> may scan the powder lot <NUM> and identify the serial number or public key. The additive printer <NUM> uses the identified serial number or public key to determine the origin of the manufactured powder by verifying the material manufacturing transaction with the distributed ledger <NUM> initiated by the material manufacturer <NUM> at the time the powder lot <NUM> was manufactured.

To enable validation of a build process by the additive printer <NUM>, the build file author <NUM> and the material manufacturer <NUM> may interface with the distributed ledger <NUM> to store a data structure representing a particular agreement or contract between the build file author <NUM> and the material manufacturer <NUM>. This contract may include, for example an indication of a build file hash provided by the build file author <NUM>, and a material lot provided by the material manufacturer <NUM>. An example of an architecture leveraging such techniques is described further below with respect to <FIG>.

The additive printer <NUM> includes a controller <NUM>, a material scanner <NUM>, and manufacturing hardware <NUM>. The controller <NUM> includes hardware configured by firmware and/or software to manage and control the operations of the additive printer <NUM>. These operations include, but are not necessarily limited to, controlling the manufacturing hardware <NUM> to initiate a manufacturing process of an object, communicating with the distributed ledger <NUM> to verify received materials and other inputs, initiating one or more object manufactured transactions to record the results of an additive manufacturing process. Although various exemplary embodiments describe the controller <NUM> as a component of the additive printer <NUM>, it should also be appreciated that in some unclaimed embodiments certain functionality of the controller <NUM> may be implemented by computing hardware separate from, but in communication with, the additive printer <NUM>. For example, the validation and distributed ledger-interface functionality may be implemented by a computing device that acts as an intermediary between the additive printer <NUM> and the blockchain ledger <NUM>. A detailed example of an embodiment of a controller <NUM> is described further below with respect to <FIG>.

The manufacturing hardware <NUM> includes various components required to implement an additive manufacturing process. As noted above, the manufacturing hardware <NUM> is configured and/or operated by instructions received by the controller <NUM>. The manufacturing hardware <NUM> may include, for example, lasers, light emitting diodes (LEDs), actuators, positioning sensors, temperature sensors, powder deposition tools, wire feed systems, material reservoirs, and the like.

The material scanner <NUM> includes hardware configured to scan a lot of input material to determine an identifier associated with that material. The identifier may include, for example, a value signed by a public key of the material manufacturer <NUM>, as described above. The identifier may be obtained by the scanner, for example, by scanning a barcode or QR code printed on material packaging, embedded within a Near Field Communication (NFC) or Radio Frequency Identifier (RFID) included within or disposed on the material packaging, or the like.

When programmed by the build file <NUM>, the controller <NUM> configures the manufacturing hardware <NUM> to manufacture the powder lot <NUM> (or other material) to create an output object <NUM>. During the manufacturing process, the additive printer <NUM> may communicate with the distributed ledger <NUM> to determine whether the creation process of the output object <NUM> meets certain criteria to label the output object <NUM> as a "certified" output object. For example, labeling the output object <NUM> as a certified output object may occur in response to determining that the build file <NUM> is verified as being received from an authorized build file author, and the powder lot <NUM> was manufactured by an authorized material manufacturer. An example of a system architecture for performing this validation is described further below with respect to <FIG>, and an example of a process for utilizing a distributed ledger to perform certification of the output object is described further below with respect to <FIG>.

The output object <NUM> may include an identifier to associate the object <NUM> with the particular distributed ledger transaction or transactions that occurred during the manufacturing process. For example, an object serial number may be printed upon or embedded within the object (e.g., as part of the manufacturing process) that may be used to as a key to perform a lookup within the distributed ledger for the particular transactions (e.g., powder lot identification, build file identification, additive manufacturing device identification) that resulted in production of the output object <NUM>.

<FIG> illustrates a detailed example of a logical data interactions <NUM> involving a controller <NUM> of an additive manufacturing device. The controller <NUM> may be, for example, an example of a controller <NUM> as described above with respect to <FIG>. The controller <NUM> may include computing hardware programmed by software and/or firmware to perform the functions illustrated in <FIG>. An example of hardware for implementing such a controller is described further below with respect to <FIG>.

The controller <NUM> includes build logic <NUM> for performing a manufacturing process. The build logic <NUM> receives a build file <NUM> which includes instructions for manufacturing an object. The build file <NUM> may include a build file identifier <NUM> signed by the author of the build file that enables verification with a distributed ledger. The build logic <NUM> receives this file and uses the build file identifier <NUM> to access a distributed ledger interface <NUM> to verify the origin of the build file with a blockchain ledger. This validation may occur according to known cryptographic techniques implemented within the distributed ledger, such as where the build file identifier <NUM> is signed by a private key of the build file author, and the controller <NUM> verifies the origin of the build file identifier using a public key of the build file author.

The build logic <NUM> is also configured to initiate an object manufactured transaction via the distributed ledger interface <NUM> upon completion of the additive manufacturing process to generate a record in the distributed ledger. To this end, the build logic <NUM> may transact with the distributed ledger to store an identifier for the output object (e.g., a serial number) along with the material identifier <NUM> of the material and the build file identifier <NUM> of the build file used to build the object. This object manufactured transaction may be signed by a private key <NUM> of the build logic for use in future validation operations. In some embodiments, the build logic <NUM> is further configured to determine whether each of the component parts of the process meet with certain criteria to label the output object as a "certified" object. For example, if the build file author is verified as coming from an authorized source and the manufacturing material from an authorized material manufacturer, the build logic indicates in the transaction record that the object is certified for use in validation by other parties.

The controller <NUM> also includes material verification logic <NUM>. The material verification logic <NUM> receives a material identifier <NUM> associated with a lot of manufacturing material being processed by the additive manufacturing device controlled by the controller <NUM>. As noted above with respect to <FIG>, the material identifier <NUM> may be scanned or otherwise read from packaging containing the material. The material identifier <NUM> includes a material identifier value <NUM>, which in some embodiments it is signed by the manufacturer of the material in the same or a similar manner as the build file identifier <NUM>. Upon receiving the material identifier <NUM>, the material verification logic <NUM> may utilize the distributed ledger interface <NUM> to verify the origin of the material via the distributed ledger.

The build logic <NUM> communicates with output verification logic <NUM> to verify and validate the object produced by an additive manufacturing process. The output verification logic <NUM> includes logic configured to determine that a build process has been completed. The output verification logic <NUM> may for example, interface with one or more sensors of the additive manufacturing device to ensure that certain tolerances were met during the manufacturing process (e.g., temperature ranges, amount of manufacturing material used). Upon verification of the manufacturing process, the output verification logic <NUM> may use the distributed ledger interface <NUM> to transact with the distributed ledger to indicate that the build process for the object was completed successfully.

Each of the build logic <NUM>, material verification logic <NUM>, and output verification logic <NUM> may be associated with a respective private key <NUM>, <NUM>, <NUM>. The private keys <NUM>, <NUM>, <NUM> enable each portion of the additive manufacturing process to be registered in the distributed ledger by the respective component of the additive printer. This process may be performed by each component individually, or the build logic <NUM> may initiate a transaction on behalf of various elements of the additive manufacturing device. While the instant embodiment is described with respect to verification of the build file, manufacturing material, and build process, various other aspects of the process may also be be validated and/or stored in the distributed ledger. For example, transactions related to shipping the output object to a purchaser, updating a software or firmware version of the controller <NUM>, or installing the output as a replacement part in an industrial asset may also be written to the distributed ledger as transactions for recordkeeping and validation.

<FIG> illustrates an example of an architecture <NUM> for implementing a distributed ledger-enabled additive manufacturing process in accordance with some embodiments. The architecture <NUM> illustrates communication among a ledger <NUM>, a series of distributed databases <NUM><NUM>-<NUM>n, and parties to an additive manufacturing process <NUM>, <NUM>, <NUM>. Communication among the ledger <NUM> and the distributed databases <NUM> may be implemented according to various distributed database protocols. For example, embodiments may employ the blockchain protocol as described above. According to various embodiments, each of the databases <NUM> may maintain a separate copy of transaction records performed by parties to the distributed database architecture. As transactions are performed against the data stored in these databases <NUM>, the databases <NUM> may generate hashes that are published to the ledger <NUM>. Validation of these transactions and updating, verifying, and reconciling the various transactions performed with each copy of the database <NUM> may be performed according to various distributed database techniques, such as blockchain.

To enable validation of manufacturing processes by, for example, an additive printer <NUM>, various parties to the transaction may implement contracts with other parties to the process that are published to the ledger <NUM> and the underlying databases <NUM>. For example, an embodiment of a ledger defines one or more contract data structures that enable parties to indicate their participation in particular parts of the manufacturing process. For example, the ledger <NUM> may be configured to accept transactions that indicate a source for a build file, a source for a lot of manufacturing media, and an authorized build quantity of the build file.

To enable these transactions, the ledger <NUM> may implement application programming interfaces (APIs) and the like that enable parties to establish relationships with one another that are published to the distributed database. For example, a given contract between a build file author and a material manufacturer may include a data structure with a build file hash value <NUM> provided by the build file author <NUM>, and a material hash value <NUM> provided by a material manufacturer <NUM>. These hash values <NUM>, <NUM> may be derived, for example, from the build file itself (e.g., a hash of the digital file) and from a characteristic of a lot of manufacturing media (e.g., from a serial number of the lot of media). A record of the contract may be created within the ledger <NUM>, and the hash values and their relationship stored within the databases <NUM>.

In some embodiments, the values used to form the contract for storage in the database <NUM> may be specific to the particular build file and lot of manufacturing media. Alternatively, in some embodiments various other levels of abstraction may be employed. For example, a contract may exist that identifies a particular manufacturer, rather than a lot of manufacturing media. Similarly, a contract may exist that identifies a particular build file author, rather than the exact file to be used. As another example, some contracts may include various logical operations to allow for completion by multiple parties. For example, a contract may be signed by a particular build file author for a particular build file and any one of multiple suppliers of a manufacturing media such that the build file can be used with manufacturing media provided by any one of the suppliers.

The ledger <NUM> and databases <NUM> may also store transaction records with an additive printer <NUM> for use in facilitating the validation of an output object. To initiate a build operation, the additive printer <NUM> receives a copy of the build file <NUM> from the author <NUM>, the same build file used to generate the build hash <NUM>. The additive printer <NUM> also receives a material identifier <NUM> (e.g., a package serial number) associated with the lot of manufacturing media to be used in the build process. To validate the manufacturing process, the additive printer <NUM> performs a hashing operation on the build file <NUM> and the material identifier <NUM> and sends the derived hash values to the ledger <NUM> as a query for validation. If a corresponding transaction exists within the database <NUM>, then the query may be satisfied and the additive printer <NUM> may proceed with the build.

Once the build of the object <NUM> is complete, embodiments may assign a serial number to the object <NUM> and create another transaction via the ledger <NUM>. This transaction may, for example, include a reference to the contract that was verified as a precursor to building the object, along with a hash value associated with the object <NUM> and/or the particular additive printer <NUM>. As such, the process of creating a record of an object <NUM> within the ledger <NUM> may be completed as a set of two or more contracts, with a first contract used to verify the various components of the build process, and a second contract that references the completed first contract and includes a reference to the completed object <NUM>.

It should be appreciated that while the contracts described here generally relate to validation of a build file and manufacturing media for use on a single additive device, alternative embodiments may include additional parties and validation processes. For example, a first contract may be employed between the parties as described above (e.g., build file author and material supplier), and a second contract may be employed referencing the first contract and multiple steps of a build process. In such a case, each step of the build process may perform a separate validation with the ledger <NUM> such that the contract to build the object <NUM> is completed only once each of the plurality of steps of the build process occur.

Once the transaction is written to the ledger <NUM> for the manufacturing of the object <NUM>, that transaction is propagated to the databases <NUM> and may be used to identify the manufactured object at a later time. For example, a database may exist that maps a part serial number to the ledger such that the serial number can be used to lookup the corresponding records in the distributed databases <NUM>. The attestation capabilities of the architecture <NUM> ensure that records accessed in such a manner are correct, enabling purchasers of the object <NUM> to validate the origin and manufacturing history of the object <NUM>.

The various components of the systems described in <FIG> may be implemented by one or more computing nodes having specially programmed hardware and software. <FIG> illustrates an example of such hardware for implementing a distributed ledger for an additive manufacturing process as described above with respect to <FIG>. While the instant example <NUM> is described with respect to a computing node, it should be readily appreciated that embodiments may be implemented across multiple computing nodes having various distributions of tasks and functions.

The computing device <NUM> may be any computing device operable for implementing aspects of the system described above with respect to <FIG>. In this regard, the computing device may be, for example, a server, a personal computer, an additive manufacturing device controller, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, or any other type of computing device. It should also be appreciated that, in some contexts, the computing device may comprise multiple such devices in a linked or networked architecture. For example, a graphical user interface may be provided by a "thin client" capable of execution on a mobile device, with server functions provided by a desktop or server computer.

The computing device <NUM> of the illustrated example includes a processor <NUM>. The processor <NUM> of the illustrated example is hardware, and may be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer. In the illustrated example, the processor <NUM> is structured in communication with a memory <NUM>, input/output circuitry <NUM>, communication circuitry <NUM>, build interface circuitry <NUM> and verification interface circuitry <NUM>.

Although the elements of the computing device <NUM> are described as discrete components, it should be appreciated that the components <NUM>-<NUM> may overlap in hardware and functionality. For example, elements of the build interface circuitry <NUM> may incorporate or overlap with elements of the processor <NUM>, the communication circuitry <NUM>, the memory <NUM>, and the like. In some embodiments, the functionality of certain elements of the computing device <NUM> may be subsumed or covered completely by other elements of the device, such as in cases where an element of the computing device <NUM> is implemented via programmed hardware provided by another component of the computing device <NUM> (e.g., the processor <NUM> programmed by one or more algorithms stored in the memory <NUM>).

The memory <NUM> may encompass any number of volatile and non-volatile storage devices, including but not limited to cache memory of the processor, system memory, mechanical or solid-state hard disk storage, network accessible storage (NAS) devices, redundant array of independent disk (RAID) arrays, or the like. Access to the memory <NUM> may be provided by one or more memory controllers implemented as hardware of the processor <NUM> and/or memory <NUM>. The memory <NUM> may store instructions for programming the processor <NUM> to perform the various algorithms and functions for implementing embodiments as described herein.

The computing device <NUM> also includes an input/output circuitry <NUM>. The input/output circuitry <NUM> may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface. The input/output circuitry <NUM> may provide for communication with one or more input devices that permit a user to enter data and commands to the computing device <NUM> and one or more output devices for enabling audible and visual components of a graphical user interface. For example, the input/output circuitry <NUM> may provide data interfaces for displaying an interface via a monitor and receiving inputs from a keyboard, mouse, touchscreen, or the like. The input/output circuitry <NUM> may enable a user to enter data and commands that are received by the processor <NUM> to perform various functions. As further examples, the input/output circuitry <NUM> may enable input via an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint, a gesture input system, and/or a voice recognition system. Examples of output devices enabled by the input/output circuitry <NUM> include, but are not limited to display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a printer and/or speakers).

The communication circuitry <NUM> includes one or more communication devices such as a transmitter, a receiver, a transceiver, a modem and/or network interface card configured to facilitate exchange of data with external machines (e.g., computing devices of any kind, including but not limited to the various layers of the data access framework <NUM> described above with respect to <FIG>) via a network (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.). In some embodiments, the communication circuitry <NUM> includes an interface for communicating with an additive printer, such as in scenarios where the computing device <NUM> is located externally to the additive printer as an interface to a distributed database.

The build interface circuitry <NUM> includes hardware configured to interact with and control an additive manufacturing process performed by an additive manufacturing device. The build interface circuitry <NUM> may include processing circuitry, such as the processor <NUM>, programmed to ingest a build file and control hardware components of an additive manufacturing device to use that build file to manufacture an object. In this regard, the build interface circuitry <NUM> may also communicate with one or more device drivers for the particular manufacturing components (e.g., powder dispenser, laser, temperature sensors) during the manufacturing process.

The verification interface circuitry <NUM> includes hardware configured to communicate with a distributed ledger to verify manufacturing process inputs and to generate transactions to the distributed ledger during and/or after the manufacturing process. To this end, the verification interface circuitry <NUM> may include processing circuitry, such as the processor <NUM>, to implement protocols and algorithms to perform these functions. The verification interface circuitry <NUM> may also include communications hardware, such as provided by the communications circuitry <NUM>, for communicating with a distributed ledger to validate and generate transactions with that ledger as described above with respect to <FIG> and <FIG>.

<FIG> illustrates an example of a process <NUM> for implementing a distributed ledger-based additive manufacturing history in accordance with some embodiments. The process is implemented by an additive manufacturing device, such as the additive printer <NUM> described above with respect to <FIG>. Embodiments may also be implemented utilizing computer hardware such as the controller <NUM> described with respect to <FIG>, the architecture described with respect to <FIG>, and the computer system hardware <NUM> described with respect to <FIG>. The process <NUM> illustrates a mechanism for utilizing a distributed ledger to verify and validate an additive manufacturing process using an additive manufacturing device configured to communicate with that distributed ledger.

The process begins at action <NUM>, where a build file is received. As noted above, the build file may include an identifier suitable for consulting a distributed ledger database to determine the legitimacy of the build file and a purported identity of the build file author. At action <NUM>, the process <NUM> determines a hash from the build file.

At action <NUM>, the process receives a material identifier. As noted above, the material identifier may be affixed or printed on packaging for the physical manufacturing media being used in the manufacturing operation. As with the build file, the material identifier may include a purported manufacturer of the material and a signed identifier suitable for interacting with the distributed ledger to verify the authenticity of the material. At action <NUM>, a hash of the material identifier is determined. At action <NUM>, the build file hash and the material hash are combined and validated using a ledger. Validating the combination may include initiating a query to the ledger to determine if a contract exists in a distributed database for that combination.

At action <NUM>, a manufacturing operation is initiated to create an output object in response to validating the build/material combination. The manufacturing operation may include, for example, programming a digital manufacturing device (e.g., an additive printer) using the build file and using a lot of manufacturing material associated with the material identifier to create the output object.

At action <NUM>, an identifier is determined for the object. Determining an identifier for the object may include, for example, assigning a serial number to the object. At action <NUM>, the process <NUM> initiates a transaction to the ledger referencing the build/material combination and the object identifier. For example, the build/material contract may exist in the distributed database as an earlier transaction, and the generated ledger transaction may include a reference to that earlier transaction and the object serial number.

Embodiments may further utilize the transaction generated at action <NUM> to enable other aspects of the additive manufacturing process. For example, a contract between a build file author and material manufacturer may include a quantity term. Once a number of transactions referencing that contract have been published as a result of manufacturing processes, then the ledger may automatically mark the contract as completed and prevent further authentication of build operations using that contract.

Various improved functionalities and use cases may result from the use of these systems. For example, in the event of a defective part, the distributed ledger may be consulted to identify the original additive manufacturing device, the manufacturing media, and the build file used to create that defective part. These values may then be cross-referenced to do lookups of other parts with the same characteristics to attempt to identify commonalities that may be causing the defect (e.g., a misconfigured additive manufacturing device, an error in a build file, or a adulterated lot of manufacturing media).

Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with embodiments of the present invention (e.g., some of the information associated with the databases described herein may be combined or stored in external systems). For example, although some embodiments described herein relate to assets employed in an industrial context, any of the embodiments described herein could be applied to other types of systems and assets.

Claim 1:
An additive manufacturing device configured to interact with a distributed ledger system, the additive manufacturing device comprising:
manufacturing hardware configured to generate an object via an additive manufacturing process; and
a controller configured to:
receive a build file comprising instructions for controlling the manufacturing hardware to generate the object;
receive a material identifier indicating a particular lot of manufacturing media, wherein the material identifier comprises an identifier electronically signed by a manufacturer of the particular lot of manufacturing media;
validate the build file and the material identifier via the distributed ledger system to verify at least one of an author of the build file or an origin of the particular lot of manufacturing media, perform a hashing operation on the build file and the material identifier and send the derived hash values to the distributed ledger system as query for validation;
control the manufacturing hardware using the build file to generate the object using the particular lot of manufacturing media; and
in response to completion of the generation of the object, generate an object manufactured transaction to the distributed ledger system indicating a result of the validation of the origin of the at least one of the build file or the material identifier, wherein validating the origin of the particular lot of manufacturing media comprises accessing the distributed ledger to verify a material manufacturing transaction between the manufacturer of the particular lot of manufacturing media and the distributed ledger at completion of manufacturing of the particular lot of manufacturing media.