阅读说明：本技术 资产管理设备和方法 (Asset management apparatus and method ) 是由 D·帕特尔 E·米奇 于 2018-10-25 设计创作，主要内容包括：提供了用于在复杂合作环境中监视和管理零件、企业资源和其它资产以及减轻风险的系统、设备和方法。具有基于硬件和基于软件的控制系统的设备扫描和/或写入在用于在制造、维护和/或跟踪处理中使用的资产内、资产上或遍及资产的多个化学、电磁或书写的数据承载标签内的唯一的资产相关的信息。系统记录该特定于资产的信息(例如,使用(一个或多个)安全的网络和/或区块链),从而提供它用于后来由许多受信任的用户访问和修改,以跟踪和控制制造相关的、维护相关的或其它因子。企业资源计划系统既向控制系统输出信息,又从控制系统接收信息,从而协调数据中的改变。(Systems, devices, and methods are provided for monitoring and managing parts, enterprise resources, and other assets and mitigating risks in a complex collaborative environment. A device having a hardware-based and software-based control system scans and/or writes unique asset-related information within an asset, on an asset, or within a plurality of chemical, electromagnetic, or written data-carrying tags throughout an asset for use in manufacturing, maintenance, and/or tracking processes. The system records this asset-specific information (e.g., using a secure network(s) and/or blockchain) providing it for later access and modification by many trusted users to track and control manufacturing-related, maintenance-related, or other factors. The enterprise resource planning system both outputs information to and receives information from the control system to coordinate changes in the data.)

1. A system for managing a plurality of assets, comprising:

a control system (420), the control system (420) configured to receive a first asset identifier and asset information, wherein the asset information is information about the asset other than the first asset identifier;

at least one scanner (119) in communication with the control system (420), the at least one scanner (119) configured to scan one or more data-bearing tags (412) encoded with at least the first asset identifier and to communicate the first asset identifier to the control system (420); and

wherein the control system (420) is in communication with a blockchain (417), and the control system (420) is further configured to cooperate with the blockchain (417) to combine the first asset identifier with the asset information to generate a second asset identifier.

2. The system of claim 1, wherein the first asset identifier identifies a particular asset using an identification mechanism that is different from an identification mechanism used by the control system (420) to identify any other asset.

3. The system of claim 1, wherein the second asset identifier identifies a particular asset using an identification mechanism that is different from an identification mechanism used by the control system (420) to identify any other asset.

4. The system of claim 1, wherein the one or more data-bearing tags are visible.

5. The system of claim 4, wherein the one or more data-bearing tags are placed on or around an asset.

6. The system of claim 1, wherein the data carrying label is not visible.

7. The system of claim 6, wherein the one or more data-bearing tags are one or more scannable particles comprising an encoding.

8. The system of claim 7, wherein the data-bearing tag is sprayed on or integrated with a physical asset.

9. The system of claim 7, wherein the data-bearing tag is visually hidden within a physical asset.

10. The system of claim 1, wherein the data-bearing tag is encoded.

11. The system of claim 9, wherein the asset is a virtual asset.

12. The system of claim 10, wherein the asset is a digital asset.

13. The system of claim 11, wherein the asset is a document.

14. A method for managing a plurality of assets, comprising the steps of:

receiving, with a control system (420), a first asset identifier and asset information, wherein the asset information is information about an asset other than the first asset identifier;

scanning at least one data-bearing tag(s) (412) with at least one scanner (119) in communication with the control system (420), wherein the scanner (119) is configured to scan the data-bearing tag(s) (412) encoded with at least the first asset identifier and to communicate the first asset identifier to the control system (420);

combining a first asset-specific identifier with the asset information using the control system (420) in cooperation with a blockchain (417) to generate a second asset identifier.

15. The method of claim 14, comprising the additional steps of:

an authentication and/or authorization protocol is provided as a precondition for performing the scan.

16. The method of claim 15, comprising the additional steps of:

the presentation of a private key generated using asymmetric encryption is required as a precondition to performing the scan.

17. The method of claim 14, comprising the additional steps of:

providing an authentication and/or authorization protocol as a prerequisite for recording the first asset identifier or the asset information in the cooperation with the blockchain (417).

18. The method of claim 17, comprising the additional steps of:

requiring the presentation of a private key generated using asymmetric encryption as a precondition for recording the first asset identifier or the asset information in the cooperation with the blockchain (417).

19. The method of claim 17, wherein the private key is configured to identify a particular user of the control system (420).

20. The method of claim 17, wherein the private key is configured to identify a particular organization having privileges to access data using the control system (420).

Technical Field

The present invention relates to asset management and, more particularly, to an asset management device, system and method for tracking assets from different sources.

Background

Probabilistic theory is one method for understanding and managing risk. The creation of logos (e.g., traffic signals) and more complex written languages (e.g., ancient sumier's wedge, morse code and modern languages) has made possible the development and dissemination of new risk management systems, including intentional and specific warnings and instructions for actors within an organization (e.g., government or group).

However, in modern history, technology and international business have grown enormously, with numerous aggravated and branching risk variables. The increased number of variables makes it difficult to track and control a particular risk. Thus, even if elaborate risk management systems proliferated and became more complex, they still failed to avoid large-scale disasters.

This is most evident in industries involving large scale manufacturing (e.g., the aerospace industry).

Such industries have taken extraordinary precautions with elaborate, coordinated risk management systems, but the world's compelling disaster caused by errors in manufacturing and maintenance continues in the modern day. Some manufacturing and maintenance related disasters remain under investigation decades later. In the aviation industry, for example, TWA Flight 800 (a Flight to paris from the united states in 1996) ends up in an explosion and takes away the lives of all onboard personnel. The cause is still discussed today, but some believe that explosions are associated with a failed Fuel Quantity Indication System (FQIS), which might otherwise be avoided by better risk management.

In complex industrial manufacturing and maintenance processes, such as those in the aerospace industry for example, the availability and supply of resources is integrated with the field of enterprise resource management ("ERM"). Modern ERM require the development of integrated ways of managing core business processes, as well as the resources they require, including inventory, parts, maintenance services, and supply of finished goods.

There remains a need for more efficient risk management systems and enterprise resource management systems that are adapted to the dynamic needs of individual groups or organizations, contain ever changing information and legal specifications, and produce richer, more complete data about manufacturing and maintenance factors in the aerospace field. One technical problem with existing risk management systems relates to record maintenance systems. Multiple actors within an organization may alter, lose, or otherwise fail to properly maintain records of assets (e.g., parts) tracked by the ERM system, e.g., resulting in incomplete or inaccurate records and unknown risk factors.

Disclosure of Invention

Systems, devices, and methods are provided for monitoring and managing parts, enterprise resources, and other assets and mitigating risks in a complex collaborative environment. According to some aspects of the present invention, a device included in or including a hardware-based and software-based control system retrieves manufacturing-related, maintenance-related, service-related, and asset-related data from a management system, such as an enterprise resource planning system ("ERP"), and creates a digital signature based on data-bearing tag(s), which may be chemical, electromagnetic, visual-based, or other tag(s) ("data-bearing tags") placed on, in, or throughout an asset for use in manufacturing, maintenance, or other processes. A data-bearing tag is a label, identifier, tag, particle, or any other device that contains information about an asset. The control system then combines the information about the asset and the digital signature into a new combined data set and inserts all or at least a portion of the set into the secure network and/or blockchain as a series of recorded values. Preferably, an insertion process into the blockchain is used that creates a secure, encrypted identifier separate from the digital signature associated with the asset. This process creates a new identifier for use on the blockchain unique to a particular asset and allows the user to track any asset recorded by the control system in real time, view important data related to it, and authenticate it and better manage the asset throughout its lifecycle within the control system. The enhanced security of the embodiments of blockchain implementation protects the assets from hacker attacks and other security threats, making the control system substantially inviolable.

In one embodiment, a handheld device (such as a smartphone and sensor with a mobile application according to aspects of the present invention) that includes or is included in a control system scans a unique asset-specific identifier within a plurality of small and/or hidden chemical, electromagnetic, visual, and/or other signal technology-based data-carrying tags that are placed on, in, or throughout an asset (e.g., part) for use in manufacturing, maintenance, or other asset-related processes. The control system then retrieves the manufacturing, maintenance, and/or asset-related data from the ERP or other management system and associates the asset-specific identifier for the particular asset with the asset-related data from the ERP or other management system. The control system may then also provide the data from the data-bearing tag as output to an ERP or other management system. In some aspects of the invention, the control system then creates a new digital identifier and records this asset-specific information (e.g., using a secure network and/or blockchain) along with the digital identifier, thereby providing it for later access and modification by many trusted users, such as ERPs, to track asset-related factors, including the identity, availability, status, location, shipping status, custody history, delivery, and installation of each asset within the manufacturing, maintenance, or other process.

In some embodiments, the control system executes, at least in part, with middleware to provide output and other services to other or external hardware, operating systems, and software programs (such as an ERP or other management system or subsystem thereof), and to integrate its functionality with them and with the overall manufacturing, tracking, and/or maintenance process for the asset(s). For example, the devices and control systems discussed above may communicate with both an ERP or other management system and a blockchain to allow users and software systems external to the control system to integrate functionality with the control system. In some embodiments, an ERP or other management system periodically both outputs and receives information to and from the control system based on intermittent network connections, coordinating changes in the data according to unique protocols.

In other embodiments, the invention is implemented as a comprehensive, fully-enclosed control system that manages the entire asset manufacturing, maintenance, and/or tracking process as an ERP or other management system, and includes both middleware and hardware running it, as well as software that interfaces directly with users and manufacturing and/or maintenance hardware. However, aspects of the present invention are not limited to the enterprise resource planning context.

Further, aspects of the invention will be explained in more detail below with reference to specific figures.

Drawings

The features and advantages of the exemplary embodiments of the invention set forth herein will become more apparent from the detailed description set forth below when taken in conjunction with the following drawings.

FIG. 1 is a schematic block diagram of some elements of a control system according to an example embodiment of the invention.

FIG. 2 is a flowchart illustrating example processing that may be undertaken by a control system according to an example embodiment of the invention.

FIG. 3 is a flowchart illustrating example processing that may be undertaken by a control system according to an example embodiment of the invention.

FIG. 4 is a schematic block diagram of an example environment and process in accordance with an example embodiment of the invention.

FIG. 5 is a schematic block diagram of an example environment and process in accordance with an example embodiment of the invention.

Detailed Description

Example embodiments of the present invention presented herein relate to methods, systems, and computer program products for tracking and managing assets (e.g., parts) in a complex collaborative environment using data-bearing tags disposed in or on the assets managed by a control system now described herein. This description is not intended to limit the application of the example embodiments presented herein. Indeed, after reading the following description, it will become apparent to one skilled in the relevant art(s) how to implement the following example embodiments in alternative embodiments (e.g., involving systems requiring secure asset tracking and management).

Fig. 1 is a schematic block diagram of some elements of a control system (hereinafter "system" or "control system") 100 according to an example embodiment of the invention. In some example embodiments, the control system includes a non-transitory machine-readable medium storing instructions that, when executed by one or more processors, perform various aspects of the invention described herein. The general and other components and aspects described herein are not exhaustive of the many different systems and variations that include many possible hardware aspects that may be used in accordance with example embodiments of the invention. Rather, the control system 100 is an exemplary embodiment.

Control system 100 includes input/output device 101, memory device 103, long-term data storage device 105, and processor(s) 107. The processor(s) 107 can receive, interpret, process, and manipulate signals and execute instructions for further processing and for output, pre-output, and/or storage within and/or outside of the system. The processor(s) 107 may be general-purpose or multi-purpose, single-threaded or multi-threaded, and may have a single core or several processor cores, including microprocessors. Further, the processor can process instructions and signals for the input/output device 101 to cause a user interface to be provided or modified for use by a user on hardware such as, but not limited to, physical hand controls (e.g., on a handheld scanning device such as scanner 119 with triggers to initiate writing and/or scanning of data-bearing labels) and/or a personal computer monitor or terminal monitor (e.g., on local machine(s) 111, scanner 119, or smartphone 120) with a mouse and keyboard and software to facilitate input and presentation (as in a graphical user interface, also referred to as a "GUI").

For example, user interface aspects such as graphical "windows," "buttons," and data entry fields may be presented via, for example, a display, selectable options. When an item is selected, such selection causes an aspect of the control system to command other aspects of the control system to scan, track, access and modify associated data bearing tags and data related to the particular asset(s), select a particular product, part or other asset managed by the ERP to scan and store information related to any of them, and provide a digital signature, identification code or information and record them in a secure manner on a network (e.g., the Internet and/or other networks containing a blockchain). For example, and as explained in more detail below, the control system may command a handheld scanning device or data entry terminal connected with the control system to scan data-bearing tag(s) in or on an asset managed by the control system and provide a security identifier and/or other data related to the asset to the control system stored somewhere (e.g., on long-term data storage device 105 or server(s) and/or on blockchain(s) 109). A data-bearing tag is a label, identifier, tag, particle, or any other device that contains information about an asset. Processor(s) 107 may execute instructions stored in memory device 103 and/or long-term data storage device 105 and may communicate via system bus(s) 175. Input/output device 101 is capable of input/output operations for the system, and may include and communicate through input and/or output hardware, and examples thereof are such as a computer mouse, scanning device or other sensor, actuator(s), communication antenna(s), keyboard(s), smartphone(s) and/or PDA(s), networked or connected additional computer(s), camera(s) or microphone(s), mixer panel(s), real-to-real tape recorder(s), external hard disk recorder(s), additional movie and/or sound editing system(s) or gear (gear), Speaker(s), external filter(s), amplifier(s), preamplifier(s), equalizer(s), computer display screen(s), or touch screen(s). Such input/output hardware may implement a user interface or program created by the software components, allowing the system and user to perform the user settings and inputs discussed in this application. Input/output device 101, memory device 103, data storage device 105, and processor(s) 107 are connected and capable of sending and receiving communications, transmissions, and instructions via system bus (es) 175. The data storage device 105 is capable of providing mass storage for the system and may be or contain a computer readable medium, may be a connected mass storage device (e.g., a flash drive or other drive connected to a Universal Serial Bus (USB) port or Wi-Fi), may use backend (with or without middleware) or cloud storage over a network (e.g., the internet) as a memory backup or as a primary memory storage for an internal mass storage device, or may be just an internal mass storage device, such as a computer hard drive or optical disk drive. In general, the system may be implemented as a client/server arrangement, with features of the system executing on a remote server, networked to the clients, and made up of clients and servers through software on both client and server computers. Also in general, the system may be implemented as middleware, whereby it provides output and other services to external systems, including but not limited to any of the example devices and auxiliary devices and/or systems, shown as internet server(s) and blockchain(s) 109, local machine(s) 111, camera and microphone 113, sensor(s) 114, internet of things or other ubiquitous computing devices 115, ERP 117, scanner 119, and smartphone 120. Similarly, the control system 100 can accept input from any of those auxiliary devices and systems and modify data stored within those auxiliary devices and systems and itself based on any input or output sent through the input/output device 101.

The input and output devices may communicate their input and receive output by any known means, including but not limited to any hardware and/or software examples, shown as internet server(s) and blockchain(s) 109, local machine(s) 111, camera and microphone 113, sensor(s) 114, internet of things or other ubiquitous computing device 115, ERP 117, scanner 119, and smartphone 120.

While the illustrated example of a control system 100 according to the present invention may be helpful in understanding the implementation of aspects of the present invention, any suitable form of computer system known in the art may be used-e.g., a simpler computer system containing only a processor for executing instructions from a memory or transmission source. The illustrated aspects or features may be implemented in digital electronic circuitry, hardware, software, firmware, middleware or any other computing technology known in the art, and any combination thereof, any of which may optionally be aided by external data from external hardware and software through a networked connection, such as through a LAN, WAN or many connections forming the internet. The system may be embodied in a tangibly stored computer program for execution by a programmable processor, as by a machine-readable medium and propagated signals. Many of the possible method steps of the example embodiments presented herein may be performed by such a programmable processor executing a program of instructions, operating on inputs and outputs, and generating outputs and stored data. A computer program comprises instructions for a computer to perform specified activities to bring about specified results, and can be written in any programming language, including compiled and non-compiled and interpreted languages, and machine languages, and can be deployed in any form, including as a complete program, module, component, subroutine, or other suitable routine of the computer program.

FIG. 2 is a process flow diagram of a process 200, which process 200 may be performed by (e.g., by software and/or middleware) a control system implementing example embodiments described herein, such as the example control system 100 set forth above with reference to FIG. 1.

At step 201, a determination is made as to whether an auxiliary ERP source is activated and/or available to share (e.g., communicate over a network connection) asset-related information with a control system. In an example embodiment, such an auxiliary ERP source may be an asset management system, such as ERP 117, which itself may include another control system similar to control system 100 set forth above in fig. 1. In some embodiments, if it is determined in step 201 that no such ERP source is activated and/or available to share asset-related information, then processing proceeds to step 215. Step 215 is discussed in more detail below. In an alternative embodiment, if it is determined in step 201 that no such ERP source is activated and/or available to share asset-related information, then the process restarts.

If at step 201 it is determined that an ERP data source is available, process 200 proceeds to step 203. According to aspects of embodiments described herein, at step 203, asset-related data is summoned and/or loaded from an ERP data source (e.g., ERP 117, scanner 119, or smartphone 120, etc.) for a particular asset to be recorded, managed, and/or tracked using control system 100. In some embodiments, such asset-related data may include, but is not limited to, part numbers, serial numbers, national stock numbers ("NSN"), CAGE codes, compliance documentation or other information, or any other asset-related numbers or other data to be managed by the control system in authenticating, tracking, and otherwise managing the related assets. At step 205, a digital signature unique to the associated asset is created. The digital signature may be based on a data bearing tag placed on, within, or near the related asset. In some example embodiments, the data-bearing tag may be hidden and/or embedded within the associated asset. These data-bearing tags may be small, invisible, or difficult to determine with the naked eye, but scannable, for example, by camera(s), sensor(s), laser scanner(s), etc. communicatively coupled with control system 100. It should be understood that other types of tags now known or later developed (e.g., of any size, attached in any manner to an asset) may also be scanned and otherwise used by the components of the control system set forth herein (e.g., scanner 119). As described above, the data bearing tag may bear data in any manner known in the art, including but not limited to chemical, electromagnetic, and visual indicia that may be scanned by the control system 100. For example, such visual indicia within the data-bearing tag may comprise a scannable color coding, where different scannable colors or color range elements correspond to data elements to be managed by the control system (e.g., without limitation, yellow for a one (1) and green for a zero (0) in a binary system, or in another example system, primary colors for three symbols, where twelve (12) elements create part-or asset-specific numbers). In step 207, the data collected and/or created in steps 203 and 205 are combined to form a new data set. In turn, in step 209, the new data set is recorded on a distributed network (e.g., the internet). In some example embodiments, the new data set is recorded using encryption. In some other example embodiments, a new data set is recorded using a blockchain. In some other example embodiments, the new data set is recorded using a combination of encryption, local storage media, network-connected storage media, and/or storage media within a blockchain. In step 211, an identifier is generated for the relevant part or other asset, which is the basis for the newly created identification code in subsequent step 213. In some embodiments, the identifier is generated by using a blockchain. In other embodiments, the identifier is generated by using a network. In still other embodiments, the identifier is a secure identifier. The secure identifier may be generated by encrypting the identifier using known or future developed encryption techniques, such as symmetric or asymmetric encryption. In some embodiments, the identifier may be a unique identifier such that the related asset is identified to the exclusion of any other assets managed by the system.

In other words, in some embodiments, the control system 420 is configured to receive the first asset identifier and asset information, wherein the asset information is information about the asset other than the first asset identifier. For example, the first asset identifier may be a code written within the data carrying tag that identifies the asset. As another example, the asset information may include a product manufacturer, a current custodian, a model number, and/or a manufacturing date. In some such embodiments, at least one scanner 119 in communication with the control system 420 is configured to scan one or more data-bearing tags 412 encoded with at least a first asset identifier and communicate the first asset identifier to the control system 420. For example, in some embodiments, the scanner 119 may employ a laser or other electromagnetic scanning technology to read the data carrying tag and capture the first asset identifier and asset information. In some such embodiments, control system 420 is in communication with blockchain 417 and is further configured to combine the first asset identifier with asset information in cooperation with blockchain 417 to generate a second asset identifier. In some embodiments, control system 420 is configured to combine the first asset identifier with asset information to generate a second asset identifier in cooperation with a network other than blockchain 417.

The unique identifier and resulting code may then be used indefinitely throughout the life cycle of the associated asset under the management of the control system 100 and/or the ERP 117 to perform various security operations. "secure operations" include any action of the system related to the asset being managed, where an action or actor is recorded and access to the record is controlled through data security techniques. For example, in some embodiments, the security operations include tracking or tracing the custody history or provenance of the asset with the encrypted data. In some embodiments, the security operation includes authenticating the asset based on the secured encrypted data. In some embodiments, the security operations include enriching or updating data records related to the asset (e.g., with new observation or situation related data). In general, security operations may include any actions of the ERP 117 or other system to maintain and/or manage the related assets (and, in some embodiments, to employ an additional authentication layer for asset-related actions, including the required security keys) by reading and writing data from the network and/or blockchain with the required unique identifiers. In some embodiments, the security key may include a username and password protection. In some embodiments, the security key may be multi-factorial, such as with two (2-) factor authentication.

For example, and returning now to step 215, data is scanned from or written onto the embedded data-bearing tag(s) of the associated asset and the asset is identified, and if other data steps as set forth in steps 203, 205, 207, 209, 211, and 213 have been previously performed for that asset, then in step 217 all asset-related data may be summoned and reviewed (e.g., on a display) and stored on the network, server(s), and/or on blockchain(s) 109 and/or ERP 117. Further, in step 219, the asset-related data may be updated, modified, added, deleted, or otherwise altered, for example, in the same location. These steps, including but not limited to data review and modification steps, may be at least partially implemented on a dedicated auxiliary computer unit. In some embodiments, such a dedicated auxiliary computer unit may be hand-held (such as a smartphone or PDA that includes or is networked for communication with the control system). In some embodiments, such an auxiliary computer unit may be dedicated to performing those steps via software that creates a GUI (e.g., a GUI generated on application software that allows a user to invoke, review, and modify ERP or data entries in a blockchain). The level of granularity of the data presentation and modification options may be customized according to the needs or decisions of a particular user or system. For example, in some embodiments, an administrative user or user with exclusive permissions and authentication credentials to do so creates data sets and data enhancement presentation and modification options. For example, for novice users, simpler interfaces may be created and used to replace complex details regarding the identification and tracking-out of assets. Such a simpler interface may also be presented on a screen of a custom PDA networked with the control system, and may present a simple indicator showing whether the scanned asset has a verified provenance from an approved supplier. In some embodiments, visual indicators may be presented on the display to indicate whether such verified provenances exist (e.g., a green indicator for verified provenances and a red indicator for unverified provenances). In some embodiments, such a simpler interface may omit the display of more detailed information about the assets and their history in the ERP. Of course, these embodiments are merely examples of the wide variety of options for data management, review and modification applications that will be apparent to those of ordinary skill in the art in view of the present disclosure.

After each of the user-based and system-based steps set forth as 201 through 221 are performed, the process restarts.

FIG. 3 is a process flow diagram illustrating additional processing 300 that may be undertaken by a control system (such as the example control system 100 set forth above with reference to FIG. 1) in connection with a computer network and the ERP 117 in accordance with an example embodiment of the invention.

In general, and as discussed above, the example processes set forth herein may be performed via software such as middleware and many systems configured for communication. For example, an example system (such as the control system 100) may be configured for communication over one or more networks (such as the internet). In other embodiments, the example system may include or be included within one or more ERPs (such as ERP 117). Such different systems and hardware arrangements may experience network connection failures depending on network conditions, such as network uptime, maintenance, and signal strength, which are both controllable and unpredictable. For example, in some embodiments, the communication connection between any of the one or more systems may be intermittent. In other embodiments, the connections between hardware components may be intermittent. In other embodiments, the connection between one or more systems and one or more hardware components may be intermittent. Even when a relatively constant network connection is possible, some embodiments of the invention may involve other execution issues, such as intermittent and/or delayed communication or command execution for other reasons. For example, in some implementation issues, bottlenecks may need to be avoided. Among other implementation problems, non-standard software and data transfers from various ERPs (such as ERP 117) and other network inefficiencies may occur. As a result, delayed execution of the system (such as the control system 100), ERP (such as ERP 117), or a network of which either or both are part may occur. Also as a result, intermittent disconnections between such systems, ERPs, and networks of which either or both are part may occur at various times when aspects of the invention are implemented. During those times, various data changes related to the management of the assets, data-bearing tags, and other aspects of the invention may occur within the control system, ERP, the network of which either or both are a part, or within aspects in which they cannot be immediately transmitted and coordinated, such as the internet and blockchain. Thus, for example, in steps 219 and 221, it may not be possible to immediately receive or transmit new, updated or modified data. Similarly, an ERP (such as ERP 117) or a different control system on a network (in some embodiments, both may be or may include a control system similar in nature to the control system set forth in fig. 1 above) may not be able to transmit or receive new, updated or modified data immediately at all times.

Accordingly, FIG. 3 illustrates some additional processes that may be taken in view of such network connection failures and other performance issues. In some embodiments, a process for reconciling data differences is provided. In other embodiments, a process for reconciling incompleteness of data is provided. In still other embodiments, provisions may also be made for coordinating other irregular processes.

At step 301, a determination is made whether such connectivity issues exist. For example, in some embodiments, a determination is made whether the control system 100 is disconnected from the ERP 117 or otherwise unable to communicate with the ERP 117, or vice versa. In some embodiments, a determination is made whether the control system is unable to communicate with a larger network, such as the internet and/or a blockchain. In some embodiments, such a blockchain may be configured to store or otherwise manage ERP-related data. If any connections between the control system 100, the ERP 117, the network(s) and/or any of the blockchain(s) 109 are established, then step 303 and subsequent steps are performed in which, among other things, a data log is recorded relating to any previous loss of connectivity. If no such connection is established, step 317 follows, wherein a log is created relating to the network outage. Rules for resolving data conflicts ("resolving conflicts" to data) are then established at step 319. In some embodiments, a log of each loss of network connection between any aspect of the network and any other aspect of the network is created. In some embodiments, such logs include records of times at which interrupts begin and/or end. In other embodiments, such logs include records of which aspects were affected by the interrupt. In some embodiments, a decision tree or other software routine is loaded. Such decision trees or other software routines may contain a set of rules for resolving conflicts in data that change during an interrupt, as will be discussed in more detail below. In some embodiments, rules may be modified based on which particular type of interrupt the rules apply. In other embodiments, those rules may be altered based on which aspects of the network are affected. In some such embodiments, once the network is reestablished, those rules may then be applied to changes made during the particular outage. In some embodiments, such rules are applied according to instructions. In some such embodiments, the system may be configured to receive instructions from a user and/or administrator. In other such embodiments, the system may be configured to receive instructions from the system.

Turning to step 303 and subsequent steps, if it is determined based on such logs that such a network outage has occurred, then all sequential records of any added, updated, or modified data entries that occurred during such an outage are loaded in step 305. In other words, if any additions, updates, or modifications to the data set to be transferred over the intermittent connection have been made or attempted, but not transferred due to the interruption, then upon re-establishing the intermittent connection, those changes are summoned and listed for coordination. In some cases, those additions, updates, or modifications ("changes") originate from aspects or control systems of the control system that are isolated from other control systems or aspects. In some such embodiments, such control systems or aspects of the control systems themselves initiate other changes to the same record during the interruption. As a result, in some embodiments, problematic changes may be associated with a record that has been subject to pre-existing, uncoordinated changes by another part of the system. Those pre-existing, uncoordinated changes may result in opposing, inconsistent or otherwise conflicting data records, as evaluated in step 307. In some embodiments of the invention, a different record is stored for each uncoordinated change, allowing the administrator to see each of them in terms of display. In some such embodiments, the display aspect may present the time of recording of each uncoordinated change. In other such embodiments, the display aspect may present data indicating the user (if any) that initiated the uncoordinated change. In other such embodiments, the display aspect may present data indicating the hardware aspect that initiated the uncoordinated change. The user or hardware aspect that initiates such an uncoordinated change may be referred to as an "initiator" hereinafter in this application. In some embodiments, the data is deconstructed without presenting such display aspects according to a pre-existing set of deconfliction rules. In some such embodiments, such conflict resolution rules may be created by the ERP 117. In some embodiments, the system may be configured to allow an administrator user of ERP to create such conflict resolution rules. Thus, for example, in step 309, conflicting changes may be entered chronologically, resulting in the entry of the most recent change, while preserving aspects of earlier changes that do not conflict therewith. In some embodiments, chronologically entered changes are so entered across all networking aspects of the system (e.g., ERP, control system, and entire network). Alternatively, or additionally, in step 309, the particular type of conflict between uncoordinated changes ("problem") may be determined, and an override attribute or condition attribute may be assigned based on the origin of the conflicting change. For example, in some cases, a "privilege issue" may arise in the sense that conflicting, uncoordinated changes are due to two different users or aspects of the network having different privilege levels making the changes. In some such embodiments, such different permission levels are determined by the control system. In some such embodiments, such different permission levels are determined by a system administrator. In one embodiment, ERP is given "super-administrator" privileges in a subsequent step 311, meaning that the change(s) originating from it will override conflicting, uncoordinated changes originating elsewhere (e.g., elsewhere on the network). In some such embodiments, such super-administrator privileges apply to particular subject matter of conflicting, uncoordinated changes. For example, in some embodiments, such super-administrator privileges may be applied if such changes are related to ERM assets and tagged particle data (objects directly tracked by ERP 117). Similarly, in some embodiments, other aspects of the network may be given higher editing privileges (rights) relative to other topics of conflicting, uncoordinated changes. For example, in step 313, any uncoordinated changes originating in blockchain(s) 109 may override conflicting uncoordinated changes from ERP 117 if the uncoordinated changes are related to ownership and other data of assets that are more directly managed by such external aspects of the network, such as blockchain(s) 109. In some embodiments, another form of resolving conflicting rules may be related to failures in the presentation of context data ("presentation problems"). As with other forms of uncoordinated changes, uncoordinated changes caused by such presentation problems may be due, at least in part, to network connection failures and other performance problems. For example, if similar but slightly different changes are made to data in different aspects of system 100 during a network outage, it may be due, in part, to users of those different aspects not being aware of each other's actions. For example, a user making a subsequent change may not know the change of an earlier user when performing his or her subsequent change. If a subsequent user is aware of a change by an earlier user (in other words, if not because of a network outage), he or she may not intend to make a subsequent change. Thus, the change of this earlier user is a missing context and there is a presentation problem. In some embodiments, special rules may be implemented to resolve conflicts in uncoordinated changes caused by such presentation issues. As a method, according to some embodiments, in step 323, it is determined whether there is a similarity between two conflicting changes. Such similarity may be determined, for example, by using confidence interval matching of data from each uncoordinated change. In some embodiments, a change of an earlier user may be entered and the missing context data of the earlier change is presented to the second user. For example, the missing context data may be the following interpretation (e.g., presented on the display via a GUI aspect): the earlier user "has made a change similar to the change you propose". In other embodiments, missing context data may include the following explanations: an earlier user makes a "similar" change at a particular, earlier time. In some embodiments, a request to enter a subsequent change may still be made. In some such embodiments, changes to subsequent changes may be performed based on the greater context of the context data, through aspects of the GUI that allow for entry of additional feedback as input. For example, in some such embodiments, selection options of the GUI may allow for the execution of original or updated changed commands, which are then executed in step 325. In some embodiments, temporary changes are also recorded. For example, such temporary changes may reflect that an earlier change has not been overridden by a later change by a GUI aspect that allows user feedback unless and until feedback is received.

Whether or not there is a presentation issue, a permission issue, or other type of conflict, each uncoordinated change is thus coordinated and executed according to such a specific series of rules for resolving data conflicts. In some embodiments, such rules themselves may be altered by input in step 315. In some embodiments, the input may be entered through a GUI of the system 100. In other embodiments, the control system itself may alter such rules. In some such embodiments, the control system may alter such rules based on network conditions and inputs.

After reconcileing all changes attempted during network connection failures and other performance issues, when the system is fully connected with the ERP and network, as set forth in this application, the changes continue to be logged and other actions continue to be performed in step 327 before processing resumes.

As with the processes and steps set forth above in FIG. 2, the embodiments set forth above are merely examples of a wide range of options for data management, review and modification applications that will be apparent to those of ordinary skill in the art in view of the present teachings. None of the examples provided in this application should be read as limiting any of the claims. The invention may be implemented in any suitable combination and with any of the aspects set out above, including other and/or more general variations.

FIG. 4 is a schematic block diagram of an example environment 400 and process in accordance with an example embodiment of the invention. A series of example processing steps are shown, including step 401, step 402, step 403, step 404, and step 405, as well as several example environment components — namely, example input device(s) 411, example assets 410 (including example data-bearing tag(s) 412), local control system 413, database(s) 415, and blockchain(s) 417. In some embodiments, local control system 413 and database(s) 415 may be referred to as control system 420, and may be maintained as property of an organization or organization department 422, such as a manufacturing department of a community. As will be discussed in more detail below, depending on the nature of the organization and its organizational units 422 and the permissions granted and the successful execution of the authentication protocol that identifies and verifies the user of system 420, another control system included with or included within system 420, and blockchain(s) 417 provide different levels of read and write access to data managed by control system 420 or another control system. As will be discussed in more detail below, in addition, other users of different organizations, organizational departments, employees or organizations, as well as the assets themselves (any of which may be referred to as "potential actors"), may also hold personal private keys that are read by the control system and/or blockchain(s) 417 to determine what type of read-write access any of those potential actors will be granted and performed. Some of those keys are configured to authorize a particular type of access to a particular asset, user, or set of users. For example, in some embodiments, access to the read data is provided based on the identification of the asset, user, or set of users seeking that access. In other embodiments, the asset, user, or set of users that enter commands to write or otherwise modify data are provided with privileges to write or otherwise modify data based on the identification of the asset, user, or set of users that the system 420 triggered such commands.

In some embodiments, the local control system 413 includes hardware and software to associate and record asset-related identifiers and other data. In other embodiments, the control system 413 is then connected with an input device (such as input device 411) and additional data storage facilities (such as database(s) 415) and network interfaces including, but not limited to, communication with a blockchain (such as blockchain 417). For example, the local control system 413 may be the control system 100 set forth above with reference to fig. 1, or may be included with the control system 100 set forth above with reference to fig. 1 or within the control system 100 set forth above with reference to fig. 1. An example input device 411 is shown that can provide part-related or other asset-related data to the control system 413-namely, a computer keyboard 419, a computer mouse 421, and an identification label scanner 423. In some embodiments, the identification tag scanner 423 may scan or otherwise read and/or transmit data from the data bearing tag(s) 412 on or in an asset, such as the example asset 410. It should be understood that the example input devices, i.e., the computer keyboard 419, the computer mouse 421, and the identification tag scanner 423, as well as the example asset 410 and data-bearing tag(s) 412, are merely examples of possible input devices, asset and data-bearing tags that may be used. Any now known or later developed device capable of generating asset-related data may be controlled by the control system 413 and connected for communication with the control system 413 and used by the control system 413 to generate and record asset-related data managed and tracked by the control system 413 (or a control system comprised by the control system 413 or comprising the control system 413 and/or controlled by the control system 413 or controlling the control system 413). Likewise, any asset that may be generated or managed by an ERP or other organization or user may be tagged or otherwise tagged or embedded with a tag bearing data in any known form. For example, in some embodiments, an asset may be marked with a visual code, such as a QR code or bar code mark. In some embodiments, an asset may be tagged with a data bearing tag that includes an encoded scannable particle. In such embodiments, those particles may be sprayed on or integrated with any physical asset. In some embodiments, digital assets may be marked with embedded codes. For example, in addition to physical parts such as a battery shown as example asset 410, a digital or other information asset or virtual asset such as example document 418 may also be tagged or otherwise associated with data bearing tag(s) 412 that may be presented in encoded form. While the data-bearing tag(s) 412 are shown as being visible, and potentially readable by a human user (who may then enter the data read therefrom into the local control system 413, and thus into the system 420 within the organization or organization department 422), it should be understood that, in some embodiments, the data-bearing tag(s) 412 may not be visible or legible to the naked eye of the human user. In some embodiments, the data-bearing tag(s) 412 may include or be written with a particular encrypted private key uniquely associated with a particular asset (such as the example asset 410), which is referred to hereinafter as the asset private key 425, as will be discussed in more detail below. To extend these particular examples, the local control system 413 or a user of the local control system 413 may command the identification tag scanner 423 to scan for unique data-bearing tags or other devices that include unique identifiers in, on, or around assets to be tracked and managed by the local control system 413. The unique identifier may then be associated with the particular asset. For example, in some embodiments, the control system 420 is configured to receive an input including an identifier and asset-related data, the input created by another input device and stored within a memory device within the local control system 413. In other embodiments, the control system 420 is configured to receive this input by using pre-populated asset-related data entered by the control system 420. In some embodiments, those data is stored in another database, such as database(s) 415, which may be dedicated to recording such identifier and asset related data. As another example, a user may type and/or hand write data related to such assets using an example computer keyboard 419 and/or computer mouse 421. Thus, in some embodiments, a user may read a unique identifier (such as a series of numbers) on a visual data carrying tag on or around an asset and manually enter the number using any of the computer keyboard 419, computer mouse 421 and/or image display 416 to associate it with a particular asset. In some embodiments including the image display 416 in the control system 420, the image display 416 includes a dedicated GUI for recording the identifier. In some embodiments, image display 416 includes a dedicated GUI configured to receive information related to other assets. In some embodiments, any of these asset-related data entry and recording activities may occur in an initial processing step 401, where asset-related data is recorded and associated with a unique identifier for the asset. In some embodiments, those assets and related data are later tracked and managed in accordance with aspects of the invention set forth in this application. In some embodiments, asset private key 425 must be read, relayed, and authenticated before local control system 413, control system 420, and/or blockchain(s) 417 allow any further data access or changes. Also, in some embodiments, any aspect of the control system 420 or another actor with respect to an asset managed by the control system 420 may not be able to insert or generate a new asset for tracking or other management without permission and successful authentication. For example, in some embodiments, the control system 420 does not allow the local control system 413 to insert or generate new parts or assets for tracking or other management without permission and successful authentication. In other embodiments, without permission and successful authentication, the control system 420 will not provide the actor access to present a private key for the organization or organization department 422. In other embodiments, system 420 may not be able to insert or generate new assets for tracking or other management without the permission and successful authentication of control system 422. In some other embodiments, such authentication routines are performed, at least in part, by at least one of blockchain(s) 417. In some embodiments, such licensing and certification requires the actor to maintain, present, and authenticate another private key (a.k.a. the starting private key 427) for this purpose before inserting or generating a new asset for tracking or other management.

Similarly, other asset management activities set forth in this application for controlling a system may similarly be permitted and authenticated even when new assets are not inserted or generated. In some embodiments, the licensing and authentication is performed according to rules set by an administrator. For example, a user (such as an employee), organization, or organization department ("actor") may be required to maintain and present or enter into the control system another particular cryptographic private key (a.k.a. geo-tagging private key 429) before entering into the control system geo-tagging information or other information related to the current location of a particular asset in space. As another example, another form of cryptographic private key (a.k.a. identification private key 431) that identifies the actor and his or her identity and permissions must be presented before such actor provides access or write privileges according to his, her or its identity (status) or permissions as set by the control system and/or administrator. Organization private key 433 is a form of identification private key that, when presented to local control system 413, control system 420, or one of blockchains 417, identifies and authenticates the organization attempting to gain access to, read from, or write to data related to the asset. Other forms of identifying the private key may include an "employee or other user private key," as discussed in more detail below.

In a subsequent process or method step 402, the control system 420 may record the unique identifier and other asset related data within the local control system 413. In some embodiments, the control system 420 may record the unique identifier and other asset-related data in another database, such as the database(s) 415. In some such embodiments, such a database may be dedicated to recording such identifiers and asset-related data. Database(s) 415 may include any hardware, architecture, and software known in the art and suitable for storing data for accessing and using computer software and hardware applications. In some embodiments, for example, but not limiting of, database(s) 415 are written in SQL, NOSQL, NEWSQL. In other embodiments, database(s) 415 are written in any other database language. In some embodiments, database(s) 415 write data to a local server or server(s). Database(s) 415 may be connected or variably connected and disconnected from the remainder of local control system 413. In some embodiments, such connections are dependent on environmental conditions. For example, in some embodiments, a temporary network or other communication disruption may affect the connection of database(s) 415 to control system 420. In some embodiments, such data logging may occur at the time communications are established (e.g., with data packets saved, saved and routed as needed by any suitable networking techniques known in the art or known in the future).

In step 403, local control system 413, database(s) 415, and/or blockchain(s) 417 then record those same data (i.e., data related to the unique identifier and other assets generated by the user, control system 420, and/or input device(s) 411), as appropriate, on one or more of blockchain(s) 417. In some embodiments, in step 403, local control system 413, database(s) 415, and/or blockchain(s) 417 record some, but not all, of those data on one or more of blockchain(s) 417, as appropriate. In general, if and when at least one of blockchain(s) 417 records data and generates additional identifiers, the step of recording on one or more of blockchain(s) 417 can be considered complete. However, in some aspects of the invention, this processing is not completed until an additional step 404 occurs, in which step 404 additional data describing or otherwise relating to the recorded transaction at least one of blockchain(s) 417 is sent from at least one blockchain(s) 417 to database(s) 415 where the additional data is recorded. For example, in some embodiments, at least one of blockchain(s) 417 may generate an acknowledgement of the activity, which is sent back to control system 420 from at least one of blockchain(s) 417. In some such embodiments, such confirmation identifies transaction and asset related data recorded on at least one of blockchain(s) 417. As described herein, such data may include a unique second cryptographic identifier (such as half of a public/private key pair generated by at least one of blockchain(s) 417).

In a subsequent step 405, blockchain(s) 417 or any user of control system 420 (or control system 420 or blockchain(s) 417 itself) may query control system 420 and/or blockchain(s) 417 to review and/or verify asset-related data managed by control system 420. In some embodiments, the control system 420 is queried via a search subsystem. In other embodiments, blockchain(s) 417 are queried via a search subsystem. In some embodiments, such a search subsystem is queried using boolean logic.

As with the other methods and processes set forth in this disclosure, any or all of the above steps may be repeated indefinitely with respect to any asset controlled by the control system 420 to track any number of assets managed by the control system 420. It should also be noted that the precise order and number of steps set forth with respect to any process or method set forth in this application is merely an example, and that different orders and numbers of the set forth steps, as well as additional steps, may be implemented within the scope of the present invention.

FIG. 5 is a schematic block diagram of an example environment and process 500 depicting asset management over time in accordance with an example embodiment of the invention. As shown in portion 550 of the figure, example asset 410 is being tracked and/or otherwise managed at different time intervals-i.e., a first time ("T1", shown as example instance 501), a second time ("T2", shown as example 503), and any number of additional times (to example instance "TN", shown as example instance 505). It should be understood that in some embodiments, the assets 410 are tracked by the control system 100. In other embodiments, assets 410 are managed in other ways. For example, in some such embodiments, any maintenance of the asset 410 is recorded. In other such embodiments, a retention history, including the identification of any actors owning the asset 410 at any time, is recorded. Also as shown in this figure, each instance, including instance 501, instance 503, and instance 505, may be a tracking, maintenance, or other asset management event occurrence by a control system implementing aspects of the present invention, such as control system 420. In some embodiments, each of those events may be performed by a different organization, organization department, or other actor. For example, example instance 501 may be an event performed by a first organization department ("OD 1"), shown as organization department 507, such as maintenance of part 401, while example instance 503 may be an event performed by a second organization department ("OD 2"), shown as organization department 509, and so on, to a series of events ending with a final or last event performed by another organization department ("ODN"), shown as organization department 510.

According to some aspects of the invention, each organization department, such as organization department 507, organization department 509, and organization department 510, as with the organization and organization departments discussed elsewhere in this application, holds different levels of permissions (as interworked by different cryptographic private keys) with respect to data related to assets controlled by the control system 420. For example, in some embodiments, different private keys are issued to such organization(s) or organization department(s) that, when provided to control system 420, create data access, read, write or other privileges according to the particular level provided by control system 420 for each particular private key. In some such embodiments, the control system 420 manages data related to assets controlled by the control system 420 according to a set of rules enforced by the control system 420. Similarly, and as also discussed elsewhere in this application, in some embodiments, each organizational department, such as organizational department 507, organizational department 509, and organizational department 510, may act through employees and other users who themselves may each hold a different cryptographic private key, identifying each of them and/or their permission levels.

For example, organization department 507 includes several individual employees or other users, including user 511, user 512, and up to any final number of users, labeled "Nth" user 513. Similarly, organization department 509 also has several employees or other users, including user 514, user 515, and up to "nth" user 516, and organization department 510 has several employees or other users, including user 518, user 519, up to "nth" user 520. Each of these employees or other users (i.e., user 511, user 512, "nth" user 513, user 514, user 515, "nth" user 516, user 518, user 519, and "nth" user 520) is shown as having his, her, or its own different cryptographic private keys, shown as private key 521, private key 522, private key 523, private key 524, private key 525, private key 526, private key 527, private key 528, and private key 529, that a control system (such as control system 420) performing aspects of the present invention may associate with these private keys the permissions of a particular user accessing, reading, writing, or otherwise managing data related to assets controlled by the control system (such as control system 420).

Likewise, each organizational department, such as organizational department 505, organizational department 507, and organizational department 509, as well as the organization as a whole (shown as organization 530), is shown as having its own distinct cryptographic private key, shown as private key 531, private key 532, private key 533, and private key 534, that a control system (such as control system 420) performing aspects of the present invention may associate with these private keys other specific permissions to access, read, write, or otherwise manage data related to assets controlled by the control system (such as control system 420).

While various exemplary embodiments of the invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein. Thus, the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

In addition, it should be understood that fig. 1-5 are presented for purposes of example only. The architecture of the example embodiments presented herein is sufficiently flexible and configurable so that it can be utilized (and directed) in other ways than that shown in the figures.

Further, the purpose of the foregoing Abstract is to enable the U.S. patent and trademark office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The abstract is not intended to limit the scope of the example embodiments presented herein in any way. It is also to be understood that the processes recited in the claims are not necessarily performed in the order presented.

The claims (modification according to treaty clause 19)

1. A system for managing a plurality of assets, comprising:

a control system (420), the control system (420) configured to receive an asset unique first asset-specific identifier (205) of an asset and asset information (203), wherein the asset information (203) is information about the asset other than the first asset-specific identifier, and the asset information (203) comprises a unique second asset-specific identifier of the asset, wherein the second asset-specific identifier and the first asset-specific identifier (205) each comprise different asset-specific identification data;

at least one scanner (119) in communication with the control system (420), the at least one scanner (119) configured to scan one or more data-bearing tags (412) encoded with at least the first asset-specific identifier (205) and transmit the first asset-specific identifier (205) to the control system (420); and

wherein the control system (420) is in communication with a blockchain (417), and the control system (420) is further configured to cooperate with the blockchain (417) to combine the first asset-specific identifier (205) with the asset information (203) to generate a unique third asset-specific identifier (211) of the asset.

2. The system of claim 1, wherein the first asset-specific identifier (205) identifies a particular asset using an identification mechanism that is different from an identification mechanism used by the control system (420) to identify any other asset.

3. The system of claim 1, wherein the third asset-specific identifier (211) identifies a specific asset using an identification mechanism that is different from an identification mechanism used by the control system (420) to identify any other asset.

4. The system of claim 1, wherein the one or more data-bearing tags (412) are visible.

5. The system as recited in claim 4, wherein the one or more data bearing tags (412) are placed on or around an asset.

6. The system of claim 1, wherein the data bearing tag (412) is invisible.

7. The system as recited in claim 6, wherein the one or more data bearing tags (412) are one or more scannable particles including an encoding.

8. The system of claim 7, wherein the one or more data-bearing tags are sprayed on or integrated with physical assets.

9. The system of claim 7, wherein the asset is a physical asset, and wherein the one or more data-bearing tags are visually hidden within the asset.

10. The system of claim 1, wherein the one or more data-bearing tags are encoded.

11. The system of claim 10, wherein the asset is a virtual asset.

12. The system of claim 10, wherein the asset is a digital asset.

13. The system of claim 11, wherein the asset is a document.

14. A method for managing a plurality of assets, comprising the steps of:

receiving, with a control system (420), a first asset-specific identifier (205) unique to an asset and asset information (203), wherein the asset information (203) is information about the asset other than a first asset identifier, and wherein the asset information (203) comprises a second asset-specific identifier unique to the asset, wherein the second asset-specific identifier and the first asset-specific identifier (205) each comprise different asset-specific identification data;

scanning at least one data-bearing tag (412) with at least one scanner (119) in communication with the control system (420), wherein the at least one scanner (119) is configured to scan the at least one data-bearing tag (412) encoded with at least the first asset-specific identifier (205) and to communicate the first asset-specific identifier (205) to the control system (420);

combining the first asset-specific identifier with the asset information using the control system (420) in cooperation with a blockchain (417) to generate a unique third asset-specific identifier (211) of the asset.

15. The method of claim 14, comprising the additional steps of:

an authentication and/or authorization protocol is provided as a precondition for performing the scan.

16. The method of claim 15, comprising the additional steps of:

the presentation of a private key generated using asymmetric encryption is required as a precondition to performing the scan.

17. The method of claim 14, comprising the additional steps of:

providing an authentication and/or authorization protocol as a prerequisite for recording the first asset-specific identifier or the asset information in the cooperation with the blockchain (417).

18. The method of claim 17, comprising the additional steps of:

requiring the presentation of a private key generated using asymmetric encryption as a precondition for recording the first asset-specific identifier or the asset information in the cooperation with the blockchain (417).

19. The method of claim 18, wherein the private key is configured to identify a particular user of the control system (420).

20. The method of claim 18, wherein the private key is configured to identify a particular organization having privileges to access data using the control system (420).