Patent ID: 12216781

DESCRIPTION OF EMBODIMENTS

Systems and related methods for the creation, sharing, updating and storage of electronic records containing event data and documents relevant before, during or after the operation and execution of a process are presented herein. In some embodiments of the present invention, a system for the creation, sharing, updating and storage of an electronic record of a process may comprise a distributed ledger. A distributed ledger may include, but is not limited to, a Blockchain, Hashgraph or Directed Acyclic Graph.

A multitude of events and event data can be observed in every process. The present invention enables a user to share an electronic record of a process with a multitude of other parties such as partners and third parties involved in the execution of the process or interested in monitoring of the process. In some embodiments of the present invention, event data, documents or electronic records of a process may be written to a distributed ledger in the form of a hash or in their original form. In other embodiments of the present invention, data may be represented using encryption technology or other forms of abstraction.

A majority of examples used in this invention disclosure use event data that is generated by or related to the operation and execution of a process that may occur in the field of transportation, logistics or material movement. However, the present invention is not limited to the field of transportation, logistics or material movement and may apply equally to other fields in which events occur and event data may be generated including, but not limited to, operations for warehousing, cross-docks, manufacturing, assembly, picking, packing, shipping, quality inspection, testing and labs, retail, service provision, human resources, financials, insurance, rental and leasing, stock markets, logistics exchanges, agricultural, construction, refinery, mining and drilling, feed yards, hospitals, restaurants, food trucks, catering, hotels, cruise ships, hospitality, theme parks, passenger travel, airports, seaports, rail yards, switching yards, train stations, subway stations, bus terminals, waste management, maintenance or repair, installation, defense and military, law enforcement, document management, public or private entertainment, concerts, sporting events, motor or animal racing, museums, or pop-up stores. Operations during which event data is captured include, but are not limited to, private, for-profit, non-profit, commercial, government, non-government or military operations.

Event data may be captured during the use of supply chain assets such as a vehicle or material handling equipment which may include, but are not limited to, heavy trucks, light trucks, trailers, tankers, self-driving trailers, containers, self-driving containers, tanker trucks, delivery vans, step vans, maintenance vans, repair vans, installation vans, pickup trucks, tractors, agricultural vehicles, agricultural machines, lawn mowers, golf carts, container moving equipment, trailer moving equipment, robotic movers, cranes, construction equipment, drilling and mining equipment, oil and gas exploration equipment, forklifts, pallet jacks, robotic storage shelves, material pickers, buses, locomotives, rail cars, switching engines, specialty railroad equipment, passenger trains, commuter trains, subway trains, law enforcement vehicles, fire trucks, ambulances, first responder vehicles, passenger vehicles, taxis, ride sharing vehicles, airplanes, helicopters, drones, airborne passenger transport vehicles, motorcycles, scooters, boards, bicycles, boats, barges, container ships, tanker ships, cruise ships, sail boats, yachts, ferries, catamarans, personnel moving ships, landing crafts, hovercrafts, tug boats, or speed boats. Some or all of these vehicles may be operated manually by a human operator, semi-autonomously or fully autonomously without a human operator. Semi-autonomous or autonomous supply chain assets may be controlled by a human operator present in the asset or by a remote human operator.

Event data may be captured by means of a manual user entry or by means of an event data capture device or computer that can partially or fully capture event data automatically. Devices or computers that enable either manual, automated, or partially manual and partially automated capture of event data include, but not limited to, a smart watch, a wearable device, a medical or biometric device, a sensor or actuator, an Internet of Things device, a USB device, a phone, a pager or other wireless device, a barcode reader, a handheld RFID device, a stationary RFID device, an RTLS device, a BLE device, a GPS device, a lidar, a radar, a CPU, a GPU, a FPGA, a chip with an integrated circuit, an electronic logging device, a sensor, an actuator, a tablet computer, a desktop computer, a laptop computer, a data center computer, a data center server, an image capture device, a video capture device, a sound recording device, a device used for the operation of a supply chain asset, a device permanently attached to a supply chain asset, a device temporarily used during the operation of a supply chain asset, a device attached to a product or material, a device attached to a pallet or packaging, a device mounted to a building, a device positioned along a road, a public or private website, a public or private database, a device controlled by a third party, a computer controlled by a third-party, a computer controlled by a third party involved in or affected by the operation of a process, a satellite, a surveillance camera, or a drone. A computer may be located locally or remotely including, but not limited to, in a data center or a computer cloud. Data capture devices may communicate with one another through one of several means including, but not limited to, a connection using a wire or cable, a wireless connection using nearfield technologies, a wireless connection using cellular or satellite wireless networks, a wireless connection using proprietary wireless networks or a connection in which data is downloaded manually or automatically from one computer and then uploaded manually or automatically to another computer. In some embodiments of the present invention, data capture devices or computers may only capture event data. In other embodiments of the present invention, they may also format, process, analyze, display, share, or store event data as well.

Event data may be captured in formats including, but not limited to, textual, numerical, still image, video, graphical, abstracted, abbreviated, proprietary, or audible form. Event data may be obtained by way of collection mechanisms including, but not limited to, means employed by any device or computer listed above, manual or automated user entry or selection, automated software entry or selection, third-party systems by way of an interface, direct or indirect measurement, a trigger by another computer, or observation. Event data may further be obtained through means including, but not limited to, data previously stored on any device or computer listed above, data previously stored on any computer described in the present invention disclosure, manual or previously stored data entered by users, manual or previously stored user selections, rule-based or otherwise automated software inputs, data from artificial intelligence systems, data generated by machine learning algorithms, data from other computers used in the capture of events, data from computers comprising a distributed ledger, data from publicly available sources, data from private sources, or data from documents including, but not limited to, instructions for handling of a process, instructions for handling of materials, instructions for operating an asset, instructions for operating a machine, user manuals, certificates, warranties, or other documents related to the operation and execution of a process. Examples of events and event data are listed further below.

In some embodiments of the present invention, events may be captured by devices or computers that are temporarily attached to a supply chain asset or material. Examples of temporary devices or computers may include, but are not limited to, wireless sensors to measure conditions such as shock, acceleration, deceleration, temperature, humidity, physical location sensors, or hardware devices that temporarily monitor the operating conditions of the supply chain asset. Other temporary devices may include, but are not limited to, RFID tag readers, barcode readers, BLE devices, USB devices or other wireless devices that allow for the identification of items through the scan of a barcode or electronic tag. A temporary device or computer may be attached to materials being transported, to packaging materials, or to a supply chain asset. A temporary device or computer may communicate with any other computer described in the present invention in a multitude of ways including, but not limited to, through a computer network such as the Internet to which it may connect wirelessly or by means of a cable, or through other mechanisms to upload or download event data. Temporary devices may be used frequently in some embodiments of the present invention, especially when autonomous vehicles may be used for a multitude of purposes or for a multitude of people or freight movements. The data generated by temporary devices may be available immediately, or it may only become available after a period of time has passed.

In some embodiments of the present invention, event data may be captured and processed by external systems that are not directly controlled by parties who are involved in the execution of a process or transaction including, but not limited to, a security camera, a warehouse camera, a camera mounted on a material moving asset such as a pallet jack, operator gear, or forklift, a camera mounted on another supply chain asset, an RFID reader, or a variety of sensors. For example, a camera mounted to the outside of the loading dock of an adjacent facility to a pick-up location may capture the license plate of a supply chain asset to identify the supply chain asset and then send an alert to the system described in the present invention disclosure so that all parties involved in the transaction may be notified that the supply chain asset has arrived at the pick-up location loading dock.

Events that occur during a process and the resulting event data include, but are not limited to, a date, a time, a physical location, a supply chain asset, a supply chain asset owner, a supply chain asset operator, a device, a computer, a material, a freight, a warehouse, a cross-dock, a yard, a storage location, a facility, a manufacturing plant, a depot, a retail location, a home base, a repair location, a plan or planning process, a user name, a password, a temporary password, a cryptographic public key, a cryptographic private key, a hash, a third-party operator, a location, a device, a customer, a retailer, a wholesaler, a distributor, a shipper, a carrier, a case, a process, an origin location, a midway point, a destination, a route, a tracking process, an identifier designated by a third-party system, a traffic condition, a road condition, a road hazard, road construction, a type of road, a light condition, an atmospheric condition, a facility condition, a location of a supply chain asset, a location along a route, an alert about an exception condition, a travel time, a dwell time, a delay, an accident, an estimated departure time, an estimated arrival time, a loading capacity, weight of loaded freight on a supply chain asset, dimensions of a supply chain asset, a hazardous material classification, instructions for handling of a hazardous material, a weather condition, a temperature condition, a barometric condition, measurement of a shock, measurement of an impact, measurements taken directly from a supply chain asset, an operating condition of a supply chain asset, a breakdown, a need for repair, a need for maintenance, an application of brakes, an application of acceleration, an obstacle, a breakdown in wireless communication, establishment of wireless communication, one or more results of actions taken by an operator, establishment of a route, a change in a route, a sensor reading, an image capture, a satellite image, a video, a purchase order, a sales order, a transportation order, a shipping order, a packing list, a bill of materials, a delivery note, a waybill, an air waybill, a bill of lading, a CMR document, a multimodal bill of lading, a cargo insurance certificate, a commercial invoice, an international commercial invoice, an international proforma invoice, an international purchase order, a general conditions of international sale document, an ATA carnet, a carnet, a certificate of origin, a certificate of inspection, an inspection by a customs officer, an acceptance of freight by a customs officer, a rejection of freight by a customs officer, a certificate of analysis, a phytosanitary document, a kosher certificate, a halal certificate, a manifest, a transport order, presence of a material, absence of a material, presence of an operator or passenger, absence of an operator or passenger, a change in freight, absence of a change in freight, a payment receipt, absence of a payment receipt, loading of freight, time to load freight, securing of freight, capture of an image of freight, dwell time at a warehouse or dock, charges for excessive dwell time at a warehouse or dock, staging of freight prior to loading, absence of freight staging prior to loading, availability of human operators during loading, a freight condition at origin, presence of freight securing devices at origin, absence of freight securing devices at origin, handling instructions for freight securing, freight pickup completion, a freight condition at points along a route, duration of a transport process, a delay in freight delivery, damages to freight during shipment, proximity to a destination, distance from a destination, time to reach a destination, sequence of multi-stop deliveries, closeness of multi-stop delivery points, freight shipment completion, freight condition at destination, dwell time at destination, unloading of freight, time to unload freight at a destination, condition of freight securing devices at destination, freight drop-off completion, a freight theft, a freight damage, availability of human operators during unloading, results of quality inspections, time to return to an origin location, time to return to a home base location, time to a second or following pick-up location, distance to a second or following pick-up location, time to a second or following drop-off location, distance to a second or following drop-off location, condition of a manufacturing asset, condition of a freight moving or supply chain asset, an inventory, an inventory location, availability of a material in inventory, an inventory dwell time, a container location, a container dwell time, a trailer location, a trailer dwell time, a FIFO sequence, a LIFO sequence, a restocking sequence, a restocking signal or alert, a quality inspection result, a quality inspection trigger, a staging location, a staging process completion signal, a staging process incomplete signal, a human operator availability during freight staging, a process operator or its identifier, operator certifications and permits, supply chain asset permits, a hazardous material permit, a hazardous material certification for an operator, material inventory on a supply chain asset, tool availability on a supply chain asset, parts or tools inventory at an installation or maintenance location, proximity to an installation or maintenance point, distance from an installation or maintenance location, time to reach an installation or maintenance location, time to return to a depot or base location, sequence of multi-stop installation or maintenance operations, dwell time at an installation or maintenance location, closeness of multi-stop installation or maintenance locations, a physical storage location of materials, a condition of a manufacturing asset, demand for materials in specific markets and geographies, availability of materials in geographic locations, price of a material, public holidays, employee vacation, employee sickness, employee absence, employee licenses and certifications, employee health status, employee permits to enter specific locations, a certificate to operate supply chain asset, a drivers license, a commercial drivers license, financial payments, a factoring invoice, receipts of financial payments, terms of payment, payment delays, immediate payments, discounts and bonuses, motivational incentives, points to complete a process, transaction, activity or task, availability of other contractual agreements, a fuel condition, an energy condition, availability of fuel or energy, location of a refueling or charging point, a regulatory mandate, a law or ordinance, completion of a process, non-completion of a process, availability of documents relevant to the operation of a process, availability of computers relevant to the operation of a process, or availability of human or machine operators monitoring the operation of a process. In some embodiments of the present invention, the above data may be captured in its original form. In other embodiments of the present invention, the above data may be represented by an identifier or through abbreviation or abstraction. Some events and event data are the result of processes performed by supply chain assets or operators engaged during the operation and execution of a supply chain process while other events and event data are external occurrences and out of the control of a human or machine operator, a business or a third party. The absence of an event completion including, but not limited to, unfinished event data inputs, disrupted event data inputs, incorrect event data inputs, or missing event data inputs may be considered event data in its own right for the purposes of the present invention disclosure. The absence of documents including, but not limited to, empty documents, incomplete documents, corrupted document files, incorrect documents, or missing documents may be considered event data in its own right for the purposes of the present invention disclosure.

The sharing and updating of event data and documents is an important part of the present invention. When exceptions from expected values for event data or documents occur, any computer used by the present invention may create and send an alert about an exception condition to any other computer or to users of external systems. Exception alerts may be treated as event data for the purposes of the present invention disclosure and, in some embodiments of the present invention, they may be written to a distributed ledger in the same way as any other event data. Further applying the principle, when any computer shown in the present invention disclosure determines that a different course of action from an initial course of action may be necessary, it may create and send an alert about a change in the course of action to any other computer or to users of external computers. Alerts about a change in a course of action may be treated as event data for the purposes of the present invention disclosure and, in some embodiments of the present invention, they may be written to a distributed ledger in the same way as any other event data.

Materials or freight may include, but are not limited to, raw materials, parts, consumables, work-in-progress materials, manufacturing assets, packaging, freight securing devices, pallets or crates, containers, written documents such as manuals or instructions, or finished goods or products. Materials may have a physical form generally as a gas, liquid or solid or they may not have a physical form including, but not limited to, software or data.

Supply chain assets and devices that capture, format or process event data or create or enhance documents may be used in a variety of processes. A supply chain process is a business process, or transaction, which comprises a series of activities or tasks comprising of people, machines, materials, skills, and knowledge to achieve an aim or objective. For the purposes of the present invention disclosure, we refer to a process as a class of transactions, for example “loading of freight” or “unloading of freight,” and to transactions as an instance of a process, for example the “loading of freight on a given day in a specific location”. In some embodiments of the present invention, a process may comprise of many transactions and many transactions may all be instances of a single process. In other embodiments of the present invention disclosure, a process may only comprise of one transaction. Processes may generate events and event data or are affected by events and event data. For example, the outcome of a process, transaction, activity or task is one or more event or event data. Often, an event resulting from activities performed in one process or transaction serves as a basis for how activities in another process or transaction are performed. A simple example may be that when a material pickup by a truck is delayed at the material origin, the likelihood of a delay in the material delivery at a destination increases greatly. Supply chain processes may generate or enhance documents or are affected by documents. For example, the arrival and departure times of a supply chain asset at a location may be recorded in one or more documents.

A process may comprise a multitude of events that may occur in a sequence or in parallel. Events comprise of the occurrence of a state and are documented through event data. When an event occurs, the resulting event data is captured by one or more devices or computers. An important aspect of how a process and an event are related to one another is that a process typically begins with an event and ends with an event. For example, a shipper may have freight that needs to be moved. The shipper may determine a route, a day and time, availability of a supply chain asset, etc. in order to begin the process of transporting the freight. The initial steps of setting up a plan are considered a course of action within the present invention disclosure. The first event and resulting event data in this process may be to set a course of action including, but not limited to, determining a pickup time, determining a drop off time, determining a transit time, determining a loading time, identifying special handling instructions, and so on. This course of action is then communicated to other participants in the transaction so that they can plan how to operate later processes. At different stages during the operation of a process, events, event data and documents may be used to monitor whether the course of action is still attainable or whether a change in the course of action is necessary. Delays of a supply chain asset for example due to problems in loading, traffic or extreme weather conditions, delays during unloading, etc. may lead to a change in the initial course of action.

A supply chain is a series of processes comprising of people, machines, materials, skills, and knowledge that transform one or more raw materials into one or more finished products, which includes the transport of materials and goods from one point to another until they reach a final consumer location. For example, processes include, but are not limited to, inbound transportation of materials, manufacturing, warehousing, outbound shipping, placement of product in customer locations, maintenance sites or installation sites, maintenance of materials after installation and also the return of products from customers back to retailers, distributors, wholesalers, or manufacturers. Further examples of supply chain processes include, but are not limited to, loading of materials onto supply chain assets, storing of materials, counting and inspecting of materials, counting materials in storage, quality inspections, repair or replacement of defective materials, replenishment of missing materials, exchange of older materials for newer ones, taking of materials out of storage, audits, collection of metrics regarding cost, time, quality, quantity or other attributes of processes or materials, planning of manufacturing processes, execution of a manufacturing process, marketing and sales promotions, advertising, sponsorship or social media campaigns, employee training and education, labor disputes or strikes, or unloading of materials at a destination.

In some embodiments of the present invention, the execution of a process documented through the capture, sharing, updating and storage of event data and documents in an electronic record may yield metrics describing the performance of a supply chain asset, an operator, a party directly involved in the operation and execution of a process, a party not directly involved in the operation and execution of a process, or other aspects of the supply chain process itself. Metrics may serve as a basis for operational decision-making by human or machine operators of any of the computers described in the present invention. Metrics may be displayed to human or machine operators in formats including, but not limited to, textual, numerical, abstracted, abbreviated, compressed, or graphical form. Examples of metrics include, but are not limited to, operator work hours, drive times, dwell times, supply chain asset utilization, warehouse efficiency, depot efficiency, retail location efficiency, fuel efficiency, route efficiency, travel time, toll charges, fee charges, insurance premiums, accident conditions, insurance payments, freight per customer metrics, freight per mile metrics, cost per mile metrics, weather influences on supply chain assets, efficiency by freight type, efficiency by trailer type, efficiency by process, efficiency by transport type, efficiency by distance to destination, efficiency in less-than-truckload operations, efficiency in last mile operations, efficiency in sea port deliveries and pickups, efficiency in airport deliveries and pickups, efficiency in parcel delivery, maintenance and repair efficiency, or the efficiency of a system to store event data on a distributed ledger. Any computer used by the present invention may collect, process, share or use metrics as described above.

In some embodiments of the present invention external data sources may be used to obtain data that adds meaning during the interpretation and analysis of event data. In other embodiments of the present invention, external data sources may be used to obtain event data or documents that are then attached to an electronic record of a process. In yet other embodiments of the present invention, external data sources may be used to create an electronic record of a process. External data sources may include, but are not limited to, an enterprise resource planning system (ERP), a customer data system, a supplier system, a business partner system, a transportation management system (TMS), a route management system, a freight forwarding system, a freight brokerage system, a warehouse management system (WMS), a global trade management system, a financial system, a banking system, a credit card processing system, an online sales system, a sales support system, a customer relationship management system (CRM), a supplier relationship management system (SRM), a human resource management system, a time and attendance system, an online database, a system containing publicly available data, a system containing private data, a system containing confidential data, a system containing military data, or a system containing government data.

In some embodiments of the present invention, a supply chain asset may be an autonomous vehicle or autonomous material movement equipment. An autonomous supply chain asset may operate fully autonomously, partially autonomously or fully manually with a human operator. One or more autonomous supply chain assets may be locally or remotely monitored by a human or machine operator. Examples of autonomous material movement equipment include, but are not limited to, autonomous forklifts, autonomous shelves, computer-controlled conveyor belts, autonomous drones, or other robotic equipment.

In some embodiments of the present invention, a system for the creation, sharing, updating and storage of electronic records containing data, event data and documents relevant for the operation and execution of a process may comprise a distributed ledger. Types of distributed ledgers include, but are not limited to, a Blockchain, Hashgraph or Directed Acyclic Graph, which may be public or private. A permissioned distributed ledger is generally a type of a private distributed ledger but can be a public distributed ledger in some embodiments of the present invention. A distributed ledger may have two or more nodes in a network of nodes. In some embodiments of the present invention, it is conceivable that a distributed ledger may only have one node. A distributed ledger may reside on one or more computers. A node of a distributed ledger may reside on one or more computers. A computer may host one or more distributed ledgers. A distributed ledger may reside on any of the computers discussed in this invention disclosure.

Referring toFIG.1, a network for the creation, sharing, updating and storage of an electronic record in regard to the execution of a process is shown. Network100comprises several computers including the system described by one embodiment of the present invention disclosure (101,200), a network for data sharing (102), operator computers (103), partner computers (104) and external data sources (105).

Element101(System200) shows a system for the creation, sharing, updating and storage of electronic records of a process. Element101allows users to register, create, share and display electronic records of a process, to upload documents and update data contained in an electronic record, to create a summary file of an electronic record and to store an electronic record of a process. Element101is described in detail inFIG.2.FIG.1should not imply that Network100requires precisely one electronic record system for processes (101) or is limited to a specific number of electronic record systems for processes (101).

Element102shows the network by which computers may share data with each other. Forms of networks may include, but are not limited to, the public Internet, a private network, a government network or other networks intended to share data between computers that may or may not be directly connected to one another. Elements listed in Network100may connect to the network (102) through a variety of means including, but not limited to, local area wireless communication, wide area wireless communication, satellite wireless communication, cables or by way of data uploads and downloads that may be handled manually or automatically.

Element103shows an operator computer used by a person or machine to access an electronic record of a process. An operator computer receives event data and documents from system101and collects event data and documents during the execution of a process, which it sends back to system101so that an electronic record of a process may be updated. Examples of operator computers include, but are not limited to, smartphones, tablet computers, laptop computers or other hardware devices used during the operation of a process.FIG.1should not imply that Network100requires precisely one operator computer (103) or is limited to a specific number of operator computers (103).

Element104shows a partner computer used by a person or machine to participate in the sharing and updating of an electronic record containing event data and documents during the execution of a process. A partner computer may be granted access to an electronic record created, shared, updated and stored in system101. A partner computer may also generate event data and documents used by system101to update an electronic record for the execution of a process.FIG.1should not imply that Network100requires precisely one partner computer (104) or is limited to a specific number of partner computers (104).

Element105shows external data sources used to obtain data about a process, event data or documents regarding the execution of a process. In some embodiments of the present invention, external data sources may be systems that can provide data used in the creation of an electronic record of a process such as from an Enterprise Resource Planning (ERP) system or Transportation Management System (TMS). In other embodiments of the present invention, external data sources may be websites or databases that contain information relevant to the execution of a process. In still further embodiments of the present invention, electronic record data, event data, documents, summary files of an electronic record, electronic records of a process or user credentials may be sent to an external data source (105) using Component209.FIG.1should not imply that Network100requires precisely one external data source (105) or is limited to a specific number of external data sources (105).

Sharing of event data between two or more of the computers in Network100occurs by means of communication. Data formats used in communication may include, but are not limited to, native, proprietary, textual, numerical, image, video, audio, abbreviation, abstraction, compression, hash, or encrypted form. Event data or documents may be sent from one Element to any other Element in the format in which they were captured or received, or in a different format from the one in which they were captured or received. Communication between two or more computers in Network100may be unsecured or secured. Secured communication may include, but is not limited to, the use of authentication of users prior to the display of event data or documents, the use of encryption for event data or documents during the sending and receiving, the use of private and public keys, the use of secure socket layers, or the use of a virtual private network.

In some embodiments of the present invention, Elements in Network100may display electronic record, event data or documents in graphical form, numerical or textual form, on a map, or as a performance metric to a user.

In other embodiments of the present invention, Elements in Network100may be located on or embedded in a supply chain asset. For example, a supply chain asset may integrate Element103into its own computing systems and devices that are used for the capture and processing of event data may be connected to the supply chain asset as well. A practical example may be that Element103may be part of an on-board computer of an autonomous vehicle, which also connects to a variety of sensors including, but not limited to, cameras, operational vehicle sensors, GPS sensors, weight sensors, temperature sensors, or light sensors.

Referring toFIG.2, one embodiment of the present invention comprising a system for the creation, sharing, updating and storage of an electronic record of a process is shown. System200comprises of twelve components used in the creation, sharing, updating and storage of an electronic record of a process.

Component201allows users and partners to register in System200. User or partner credentials collected during registration may include, but are not limited to, a username and password. In some embodiments of the present invention user or partner credentials may also include biometric data including, but not limited to, a fingerprint, retina image, a voice frequency, a gait, a facial image, a user location, a DNA marker, or any combination thereof. In some embodiments of the present invention, users or partners may enter additional data, for example a company name, a company identifier such as a tax number, a business location, an email address, a phone number, or an answer to a security question. In other embodiments of the present invention, users or partners may enter a payment method and preference for payment processing during registration. In some embodiments of the present invention, user or partner registration may include the sharing of orientation or training materials.

Component202allows System200to capture, store and manage data that is collected during the registration of users or partners or at later points in time. Component202also allows users or partners to access, change and save data about them. Further, Component202validates user credentials when they log into System200.

Component203allows System200to register operators. Operator credentials collected during registration may include, but are not limited to, a username and password. In some embodiments of the present invention operator credentials may also include biometric data including, but not limited to, a fingerprint, retina image, a voice frequency, a gait, a facial image, a user location, a DNA marker, or any combination thereof. In some embodiments of the present invention, operators may enter additional data, for example a company name, a company identifier such as a tax number, a business location, an email address, a phone number, or an answer to a security question. In some embodiments of the present invention, operators may enter a payment method and preference for payment processing during registration. In some embodiments of the present invention, operator registration may include the sharing of user orientation or training materials.

Component204allows System200to capture, store and manage data that is collected during the registration of operators or at later points in time. Component204also allows operators to access, change and save data about them. Further, Component204validates operator credentials when they log into System200and, in some embodiments of the present invention, into System300.

Component205enables System200to create an electronic record of a process. In one embodiment of the present invention, an electronic record of a process may be created manually by a person. In another embodiment of the present invention, an electronic record may be created through data import from an ERP system or TMS or from another external data source (105) using Component209. In yet another embodiment of the present invention, an electronic record may be created through data import from a partner (104) or an operator (103) computer. An electronic record of a process comprises data about the process itself such as, at a minimum, a process name or identifier. In some embodiments of the present invention, an electronic record may contain additional data including, but is not limited to, one or more locations, one or more material descriptions, one or more lists of work steps, one or more lists of data capture tasks to be completed by an operator, or one or more instruction sets for operators relevant to the execution of a process.

Component206allows System200to process and store electronic records of a process. It further allows for the association of event data and documents to an electronic record of a process so that they can be displayed to users of System200along with the electronic record of a process. Component206further allows users of System200to update data in the electronic record itself or event data and documents associated with the electronic record of a process. When changes are made to the electronic record of a process, Component206processes those changes. For example, a partner may use a computer to upload a document to be associated with an electronic record of a process. Component206ensures that the document is associated to the correct electronic record and that it is displayed when users of System200select to view the electronic record. Component206further allows System200to create a summary file of an electronic record and to associate the summary file to the electronic record itself.

Component207processes and stores documents related to an electronic record of a process. In some embodiments of the present invention Component207may receive documents from Elements in network100. In other embodiments of the present invention, Component207may create documents based on event data received from Component208, from Elements of Network100, or though user data inputs for example. A multitude of documents may be associated with an electronic record of a process. One of the benefits of System200is that when a document has been associated with an electronic record of a process, users of System200with authorization to access the document may be able to view them. In some embodiments of the present invention, documents may need to be further processed. For example, a user of System200may upload a document into a text processor format such as Microsoft Word. Component207may then process the document into a different file format such as Portable Document Format (PDF). In some embodiments of the present invention, a document may be displayed in its entire length. In other embodiments of the present invention, a document may be analyzed and summarized by a human or machine user of the system to only display a summary of the contents. In yet other embodiments of the present invention, a software such as an artificial intelligence or machine learning software may access and analyze a document to derive further insights.

Component208processes and stores event data related to an electronic record of a process. Component208may receive event data from Component209or from other Elements in network100. One benefit is that when event data has been associated with an electronic record of a process, users of System200with authorization to access the event data are able to view it. In some embodiments of the present invention, event data may need to be further processed. For example, event data may be a location of a supply chain asset. It may be collected through an operator computer (103) and sent to System200in the form of latitude and longitude coordinates. In this case, Component208further processes the event data to establish and display a physical location in textual form or to display the physical location on a map. Another example may be that an operator may collect photographic images or video recordings or obtain a signature image during the execution of a process, which Element103for example sends to Component208so that they can be associated with the electronic record.

Component209allows System200to access data stored on other systems or databases such as an ERP or TMS or other sources of data as described herein in the present invention disclosure through an interface into external data sources (105). System200may receive external data from a variety of sources. For example, component209may obtain data from external data sources (105) using automated computer system interface mechanisms including, but not limited to, an EDI document, an application programming interface, an application binary interface, a file grabber, direct access to an external computer, or direct access to an external computer database. In some embodiments of the present invention, a user of System200may manually enter data obtained from an external data source (105) by mechanisms that include, but are not limited to, looking at an external system, receiving data in an email or similar message, receiving a data file on a storage device, or receiving data via communication with a user of an external computer.

Component210processes and stores data obtained from an external data source (105) that is associated to an electronic record of a process. In some embodiments of the present invention, external data may need to be further processed. For example, it may be beneficial to obtain traffic and weather data through an external data source (105) so that it may be associated to an electronic record of a process. Components in System200may request the data from an external data source (105) through Component209and may, for example, receive data about traffic and weather for a specific route of a supply chain asset. Component210compares the traffic and weather data to the route and current location of the supply chain asset in order to determine whether the supply chain asset may be affected by traffic or weather causing a delay along its route to reach a destination.

Component211handles user (“Partner”) access rights to an electronic record of a process, to event data and documents, to summary files and other data including, but not limited to, user lists, address lists or contact lists. Only users who have been allowed access to an electronic record of a process are able to view or update it. In some embodiments of the present invention, not all users of System200may have access to all data contained in an electronic record of a process. Some event data or documents may only be appropriate to share with some, but not all users of System200. For example, a manufacturer may operate System200and invite a third-party logistics provider (3PL) to view an electronic record of a process. The 3PL in turn may invite a freight broker to view the same electronic record of a process. The freight broker may invite a dispatcher to view the same electronic record of a process. The dispatch may invite an operator, in this case a truck driver, to execute the process. There may be commercial agreements between the manufacturer and 3PL that cannot be shared with any of the other partners. Likewise, the 3PL may have commercial agreements with a broker that cannot be shared with the manufacturer, dispatcher or operator and so on. Component211enables users to designate who may view specific electronic record data, event data or documents as part of an electronic record of a process. Another example, using the same case, may be that a dispatcher may not wish to disclose the identity of an operator to a freight broker, 3PL or manufacturer. Component211enables the dispatcher to select whether to share or not to share the identity of an operator.

Component212handles the addition of users (“Partners”) to System200in the form of invites. Users may be invited to share and update an electronic record of a process in a multitude of ways. In one embodiment of the present invention, a first user of System200may invite a second user who may be a partner or an operator by way of providing a unique identification including, but not limited to, an email address, a phone number, a username or another form of unique identifier. Component212may then check whether an invited user has already been registered in System200. In some embodiments of the present invention, if the user has previously registered in System200, Component212may send an email or text message notification to the user that he has been invited to view the electronic record of a process by logging into System200using his user credentials. In other embodiments of the present invention, if the user has not previously registered to use System200, Component212may send an email or a text message with instructions on how to register for System200. Once the new user registers in System200, he will be able to view the electronic record of a process. In other embodiments of the present invention, users who have been invited to view an electronic record of a process may in turn invite other users to view the same electronic record of a process. In further embodiments of the present invention, new users may be invited to view an electronic record of a process by way of selection. For example, System200may display a number of potential users or partners to a first user who has created an electronic record of a process. New users may be suggested to a first user based on specific criteria including, but not limited to, available capacity, geographic location or reputation. In still further embodiments of the present invention, a human or machine operator not associated with the user who created an initial electronic record of a process may determine which other users should be invited to share and update an electronic record of a process. In yet other embodiments of the present invention, a software program may determine which other users should be invited to share and update an electronic record of a process.

Referring toFIG.22, shown is Block Diagram2200comprising a flow for one embodiment of the present invention allowing a user to register in reference to System200and Network100. The flow shown in Block Diagram2200comprises of six steps and begins with step2201in which a user selects to register in System200using Component201. In step2202, the user enters a username and password. Not shown in Block Diagram2200, a user may also select alternative means to authenticate users in System200which may include, but are not limited to, two-factor authentications, multi-factor authentications, the use of public and private keys, a fingerprint, retina image, a voice frequency, a gait, a facial image, a user location, a DNA marker, or any combination thereof. Shown again in Block Diagram2200, in step2203a user may select to enter address and contact data including, but not limited to, a physical address, an email address or a phone number. In some embodiments of the present invention, a user may also elect to omit this step. Not shown in Block Diagram2200, in other embodiments of the present invention, it may be mandatory for the user to enter or confirm an email address or phone number. In step2204, a user may elect to enter business data including, but not limited to, a company name, company address and contact data, or operational details about the users' company. In some embodiments of the present invention, a user may elect to omit this step. In step2205, a user may elect to enter payment data including, but not limited to, a payment preference, bank account details or credit card information. In some embodiments of the present invention, users may have a preference for receiving an invoice. In other embodiments of the present invention, users may have a preference for payment by credit card or direct money transfer. In yet other embodiments of the present invention, users may have a preference for other forms of payment. In some embodiments of the present invention, a user may elect to omit this step. In specific embodiments of the present invention, steps2203through2205may not be part of the system. In step2206, Component201saves the registration data provided by the user and sends it to Component202for storage and use, for example to allow users of System200to log into the system.

Referring toFIG.3, shown is Block Diagram300comprising a flow for one embodiment of the present invention to manually create an electronic record of a process in reference to System200and Network100. The flow shown in Block Diagram300comprises of seven steps and begins with step301in which a user logs into System200to manually create an electronic record of a process using Component205. In step302a user enters or selects detailed information about a process to create an electronic record. For example, in a transport process detailed information may include, but is not limited to, an origin location, a destination location, details about the freight or transportation cost. In step303a user may select or attach documents. In some embodiments of the present invention, System200may maintain often used documents using Component207from which a user can select the documents that he wishes to attach to the electronic record. In other embodiments of the present invention, a user may elect to attach documents that were not previously stored in System200. In yet other embodiments of the present invention, a user may select previously stored documents and also add new ones. For example, a user may attach a commercial invoice, bill of lading, manifest or special handling instructions. In some embodiments of the present invention, the user may elect to omit this step, for example if there are no documents to attach during the setup of the electronic record. In step304a user may select the types of event data that should be collected during the execution of the process by an operator. For example, in a transport process a user may ask an operator to allow for the collection of regular updates of his location while driving along a route, to take images of the loading and unloading of freight, or to collect signatures during pickup and drop-off as proof that everything was handled correctly from the perspective of a warehouse or operations supervisor. In some embodiments of the present invention, the user may elect to omit this step, for example if there is no event data to select or if a predetermined selection of event data already exists. In some embodiments of the present invention, System200may be designed to allow additional parties to observe the progress of a process during its execution. In this case, a user may add additional parties in step305that are allowed to monitor or observe the execution of a process. For example, additional parties could be organizations that are not sharing access to an electronic record in System200but may be invited to receive updates about specific aspects of progress during the execution of a process. These additional parties may be notified of their inclusion in a process or transaction by way of receiving email or text messages. In some embodiments of the present invention additional parties may only view a part of the available data. In some embodiments of the present invention, the user may elect to omit this step, for example if there are no additional parties to invite. In some embodiments of the present invention there may also not be a step where users invite additional parties. In step306a user invites at least one partner to share and update an electronic record of a process. The process for inviting a partner is described in more detail in Block Diagram500and in the description of Component212of System200. In step307Component205sends the electronic record of a process to Component206for processing and storage.

Referring toFIG.4, shown is Block Diagram400comprising a flow for another embodiment of the present invention to automatically create an electronic record of a process in reference to System200and Network100. The flow shown in Block Diagram400comprises of seven steps and begins with step401when an external system sends an electronic record of a process to Component205using Element105in Network100. Interfaces to external data sources are described in detail in the discussion of Component209in System200. For example, data in an external record used during a supply chain transaction may include, but is not limited to, an origin location, a destination location, details about the freight, a route or transport cost. Not shown in Block Diagram400, an external system may create an electronic record of a process that does not need to be changed or refined any further. For example, it may already include all needed documents, preferences for event data and a list of additional parties and partners that are to be invited. Shown again in Block Diagram400, in step402a user may select an electronic record of a process imported from an external system that has been created automatically in order to edit the electronic record of a process using Component205. In step403the user may attach one or more documents to the electronic record. In some embodiments of the present invention, System200may maintain a list of often-used documents stored by Component208from which a user may select the ones that he wants to attach to the electronic record. In other embodiments of the present invention, a user may select to attach documents that were not previously stored in System200. In yet other embodiments of the present invention, a user may select stored documents and also add new ones. For example, a user may attach a commercial invoice, bill of lading, manifest or special handling instructions. In some embodiments of the present invention, the user may also elect to omit this step, for example, if there are no documents to attach. In step404a user may select the types of event data that should be collected during the execution of the process. For example, in a transport process a user may ask an operator to agree to the sending regular updates of his location while driving along a route, to take images of the loading and unloading of freight, or to collect signatures during pickup and drop-off as proof that everything was handled correctly from the perspective of a warehouse or operations supervisor. In some embodiments of the present invention, the user may also elect to omit this step, for example, if there is no event data to select. In some embodiments of the present invention, System200may be used to allow additional parties to observe the progress of a process during its execution. In this case, a user may add additional parties in step405that are allowed to observe the execution of a process. For example, additional parties could be organizations that are not sharing direct access to an electronic record in System200, but that may be invited to receive updates about progress or an estimated time of arrival during the execution of a process. Additional contacts may be updated by way of receiving email or text messages or by seeing a specifically designed view that just shares a subset of available data. In some embodiments of the present invention, the user may elect to omit this step, for example if there are no additional parties to invite. In some embodiments of the present invention there may not be a step where users invite additional parties. In step406a user invites at least one supply chain partner to share and update an electronic record of a process. The process for inviting a partner is described in more detail in Block Diagram500and in the description of Component212of System200. In step407Component205updates the electronic record of a process and sends it to Component206for processing and storage.

Referring toFIG.5, shown is Block Diagram500comprising a flow to invite a partner to share and update an electronic record of a process in reference to System200and Network100. The flow shown in Block Diagram500comprises of eight steps and begins with step501when a user identifies a partner to invite for sharing and updating an electronic record of a process using Component205. In step502a user enters a unique identifier for the partner. Unique identifiers may include, but are not limited to, email address, phone number, or username. In step503Component205saves the invite data entered by the user and sends it to Component212. In step504Component212requests that Component202checks whether the partner has already registered in System200in which case a partner record exists. If a partner record exists, Component212sends a notification to the invited partner in step505. If the partner is not known in System200, Component212sends a welcome message with a link to a registration page in step506to the invited partner. In this case, the new partner may register to use System200in step507. The registration process has been described in detail in Block Diagram2200. In step508Component211associates the partner to the electronic record of a process and records that the partner now has access to the electronic record of a process.

Not shown in Block Diagram500are other embodiments of the present invention in which new users may be invited to view an electronic record of a process by way of selection. For example, a human or machine operator or a software program may determine which partners should be invited to share and update an electronic record of a process. Further not shown in Block Diagram500are cases where a user may enter additional data about an invited partner such as data that may be used later when the partner registers to access System200.

Referring toFIG.6, shown is Block Diagram600comprising a flow to share a document associated with an electronic record of a process in reference to System200and Network100. The flow shown in Block Diagram600comprises of six steps and begins with step601in which a user identifies a document that he wishes to share by adding it to the electronic record of the process in System200. In step602the user checks whether the document is already stored in System200using component207. If it is, the user selects the document and component206associates the selected document with the electronic record of a process in step603. If the document has not been previously stored in System200, the user uploads a new document using Component206and Component207associates the uploaded document to the electronic record of a process in step604. In both cases, whether the document had been previously stored or not, Component211checks which partners have been invited to view the specific electronic record of a process and whether they are authorized to view the document in step605. In some embodiments of the present invention, a user setting up an electronic record of a process may designate which documents and event data partners are authorized to view. In other embodiments of the present invention, partner access to documents and event data may be based on predefined rules or an authorization configuration. In yet other embodiments of the present invention, partners may view all documents and event data associated to an electronic record of a process. In step606System200displays the document to those partners who have been authorized, but not to partners who are not authorized to view the document.

Referring toFIG.7, shown is Block Diagram700comprising a flow to share event data with a partner in reference to System200and Network100. The flow shown in Block Diagram700comprises of seven steps and begins with step701in which an operator captures event data using an operator computer (103) such as a data capture device. In step702the operator computer sends the event data to Component208. In step703Component208processes the event data for display. In some embodiments of the present invention, Component208may not need to further process the event data received from an operator computer, for example in cases where further processing is not necessary such as with textual information. In step704a partner accesses System200using Component202and in step705the partner selects to display an electronic record of a process. In step706Component211checks the partner authorization to view event data. In some embodiments of the present invention, users of System200may elect to share all event data with partners and observers. In other embodiments of the present invention, users may designate which partner or observer may view which event data. In step707System200displays the event data to the partner, if he is authorized to view the event data.

Referring toFIG.8, shown is Block Diagram800comprising a flow to create a summary file of an electronic record of a process in reference to System200and Network100. In some embodiments of the present invention, a summary file of an electronic record may be created by System200. In other embodiments of the present invention, a summary file may not be created. In further embodiments of the present invention, a system other than System200may create a summary file of the electronic record of a process. In yet further embodiments of the present invention, a summary file may contain all event data and documents that have been associated to the electronic record of a process. In still further embodiments of the present invention, a summary file may only contain a subset of associated event data or documents. The flow shown in Block Diagram800constitutes one example for the creation of a summary file and comprises of nine steps. It begins with step801in which a process concludes so that no further event data or documents are going to be added to the electronic record of the process. In step802Component206assesses all data generated or used during the execution of a process. In step803Component206creates a summary file for an electronic record in which to aggregate and present all relevant data used, created or gathered during the execution of a process. In step804Component206adds shipment, material and route data to the summary file. In step805Component206adds event data gathered or generated during the execution of a process to the summary file. In step806Component206adds shipper, user or partner data created, gathered or generated during the execution of a process to the summary file. In step807Component206adds operator data created, gathered or generated during the execution of a process to the summary file. In step808Component206adds the documents that were used or have been created during the execution of a process to the summary file. In step809Component206saves the summary file and associates it to an electronic record of a process.

Not shown in Block Diagram800, there may be cases in which multiple summary files may need to be created because different parties have different authorizations to view event data and documents. The logic shown in Block Diagram800still applies in this case while Component206uses Component211to validate the access rights for each partner.

Referring toFIG.9, shown is Block Diagram900comprising a practical example for sharing of event data and documents during the execution of a process in reference to System200and Network100. In the example a first user may be a shipper who invites a first partner who may be a transportation dispatcher to manage and oversee the delivery of freight from a factory to a retail location using a supply chain asset. The process may be handled by an operator such as a truck driver. The flow shown in Block Diagram900comprises of twelve steps and begins with step901in which a first user creates a new electronic record for a process in System200. In step902a first user uploads a bill of lading (BOL) and a handling instruction document for the materials that are transported using Component207. Not shown in Block Diagram900, Component207may process both documents and will save them and then Component206associates them to the electronic record of this process. Shown again in Block Diagram900, in step903, using Component212, a first user invites a first partner to share an electronic record of the process including all event data and documents. In step904a first partner accepts the invitation from a first user and is now able to view the electronic record of the process along with its event data and documents in System200. In step905a first partner uploads a rate confirmation as a third document using Component207. The new document is now available to a first user as well. In step906a first partner invites an operator to carry the freight from the factory to the retail location. In step907the operator accepts the invitation on his computer (103) such as a smart phone or tablet. In step908the operator collects event data such as GPS locations, photographic images of the freight during loading and unloading as well as signatures from supervisors at the manufacturing and retail location during pickup and drop-off respectively. The operator computer (103) sends all event data to System200where it may be processed by Component208. In step909Component208processes the event data captured by the operator and Component206adds it to the electronic record of the process so that the first user and first partner may view it. Once the operator completes all activities related to the delivery of the freight to a retail location, the operator acknowledges the completion of the process in step910on his computer (103). In step911the process now completes, and Component206creates a summary file of the electronic record in step912.

Referring toFIG.10, another embodiment of the present invention for a network comprising a distributed ledger for the creation, sharing and updating of an electronic record in regard to the execution of a process is shown. Network1000comprising a distributed ledger comprises several computers including the system described by the present invention disclosure (1001,1100), a network for data sharing (1002), a distributed ledger network comprising at least one node (1003), operator computers (1004), partner computers (1005) and external data sources (1006). The main difference between Network100and Network1000is that the latter comprises a distributed ledger.

With the exception of Element1003, the remaining elements1001through1006function in the same manner as their corresponding Elements101through105described in Network100with the exception that Network1000comprises a distributed ledger.

Element1001(System1100) shows a system comprising a distributed ledger for the creation, sharing, updating and storage of electronic records of a process. Its components are described in detail inFIG.11. Element1001comprising a distributed ledger allows users to register, to create, share and display electronic records of a process, to upload documents and update data contained in an electronic record, to create a summary file of an electronic record, to create a hash of a summary file and to store an electronic record of a process.FIG.10should not imply that Network1000requires precisely one electronic record system for processes (1001) comprising a distributed ledger or is limited to a specific number of electronic record systems for processes (1001) comprising a distributed ledger.

Element1002shows the network by which computers may share data with each other and by which System1001may access a distributed ledger (1003).

Element1003is a distributed ledger comprising at least one node. A distributed ledger may be private, public, or a hybrid form of private-public. Different distributed ledger technologies or platforms may include, but are not limited to, Bitcoin Blockchain, Ethereum Blockchain, Hashgraph or Directed Acyclic Graph technology. Data may be written to a distributed ledger in several formats including, but not limited to, a hash, in encrypted form, in otherwise abstracted form or in its original form. Data may also be written to two or more separate distributed ledgers. For example, a hash of data may be written to a public distributed ledger and the same data may also be written to a private distributed ledger in its original form. Data may also be written partially to a first distributed ledger and partially to a second distributed ledger. For example, a hash of data may be split into two parts where one part is written to a first distributed ledger and a second part to a second distributed ledger. In some embodiments of the present invention some or all data contained in an electronic record of a process may be stored on a distributed ledger exclusively. In this way, a distributed ledger may serve as a repository for some or all data that is created and shared before, during or after the execution of a process. In other embodiments of the present invention event data and documents that did not previously exist in other Elements of Network1000may be obtained from a distributed ledger. In still other embodiments of the present invention data stored on a distributed ledger may serve as the basis for decision-making by third parties not directly involved in the execution of a process such as banks, insurance agencies, factoring providers or leasing providers.

Element1004shows an operator computer used by a person or machine to access an electronic record of a process, to capture event data and, in some embodiments of the present invention, documents.FIG.10should not imply that Network1000requires precisely one operator computer (1004) or is limited to a specific number of operator computers (1004). In certain embodiments of the present invention, Component1104may create a hash of operator data or operator registration data.

Element1005shows a partner computer used by a person or machine to participate in the sharing and updating of an electronic record containing event data and documents during the execution of a process.FIG.10should not imply that Network1000requires precisely one partner computer (1005) or is limited to a specific number of partner computers (1005).

Element1006shows external data sources used to obtain event data or documents regarding the execution of a process.FIG.10should not imply that Network1000requires precisely one external data source (1006) or is limited to a specific number of external data sources (1006).

Sharing of event data between two or more of the Elements in Network1000occurs by means of communication in the same manner described for Network100.

In some embodiments of the present invention, Elements in Network1000may display an electronic record, event data or documents in graphical form, numerical or textual form, on a map, or as a performance metric to a user.

In some embodiments of the present invention, Elements in Network1000may be located on or embedded in a supply chain asset. For example, a supply chain asset may integrate Element1004into its own computing systems and devices that are used for the capture and processing of event data may be connected to the supply chain asset as well. A practical example may be that Element1004may be part of an on-board computer of an autonomous vehicle, which also connects to a variety of sensors including, but not limited to, cameras, operational vehicle sensors, GPS sensors, weight sensors, temperature sensors, or light sensors.

Referring toFIG.11, another embodiment of the present invention for a system comprising a distributed ledger for the creation, sharing, updating and storage of an electronic record of a process is shown. System1100comprising a distributed ledger comprises of fourteen components used in the creation, sharing, updating and storage of an electronic record of a process. The main difference between System200and System1100is that the latter comprises a distributed ledger.

Components1101through1112function identical to Components201through212.

Component1113handles the connection between System1100comprising a distributed ledger and a network of nodes on one or more distributed ledgers (1003). For example, Component1113handles authorizations to access a network of nodes on distributed ledger (1003) and submits data that has been designated to be written to a distributed ledger. In some embodiments of the present invention, Component1113may connect to more than one distributed ledger at a time and may write data to one or more distributed ledgers. In some embodiments of the present invention, Component1113may connect to more than one distributed ledger to write partial data to a first distributed ledger and partial data to a second distributed ledger. In some embodiments of the present invention, Component1113may request event data or documents from one or more distributed ledgers that it connects to. In some embodiments of the present invention, Component1113may write electronic records, event data or documents to a distributed ledger at the time when the data has been collected and processed. In other embodiments of the present invention, Component1113may write data about electronic records, event data or documents to a distributed ledger at the time when the electronic record of a process has been completed and a summary file has been established. For example, all data from an electronic record of a process, all event data and all documents may be combined into a summary file, which is then written to a distributed ledger in its original format or as a hash. In yet other embodiments of the present invention, Component1113may write a hash of data to one or more distributed ledgers. In particular embodiments of the present invention, Component1113may write data in its original form to one or more distributed ledgers.

Component1114stores hashes of data that have been generated by other Components in System1100comprising a distributed ledger. Hashes stored in Component1114are associated with their original electronic records, event data, documents and summary files so that original documents can be retrieved when they are needed. In some embodiments of the present invention hashes may be stored elsewhere so that Component1114may not be required.

Referring toFIG.12, a block diagram with a practical example for linking data blocks on a distributed ledger, a blockchain in this case, using hashes is shown. Block Diagram1200comprises of six elements to illustrate how blocks form a chain on a distributed ledger. Element1201shows a first block in a distributed ledger that is often called a genesis block. Data elements 1.1 to 1.n have been written to the first block. Element1201as the first block does not contain a hash since no previous blocks exist. When no further data is written to a first block, a hash of the first block is created as illustrated by Element1202. The hash representing the content of the first block is written to the second block and new data elements 2.1. to 2.n are added to the second block until it has been completed as shown in Element1203. Then a hash of the data contained in the second block is created as shown by Element1204. The hash representing the second block is written to a third block and new data elements 3.1. to 3.n are added to the third block until it has been completed as shown in Element1205. Then a hash of the data contained in the third block is created as shown in Element1206. This process continues for all future blocks on the distributed ledger.

Data itself may also be written to a distributed ledger in the form of a hash or in its original format. When data is stored on a distributed ledger in hashed form, a computer applies a hash function to create a hash, or mathematical abstraction, of the original data. This is important to prove at later points in time that the original data has not been changed or altered by a user of a computer system or by the computer system itself. When this proof may be required at a later point in time, a user may create a hash of the original data available in a computer system and compare it to a hash written to a distributed ledger at the time the hash was added. If the first and second hashes do not match, a user knows that the data has been altered or compromised. When data is stored on a distributed ledger in its original form, data formats include, but are not limited to, in complete and unaltered (“original”) form, in formatted form, in abstracted form, in abbreviated form, in compressed form, or in encrypted form.

A practical example of hashed and whole data is a bill of lading document. In its original form, the document contains data such as origin and destination locations, information about materials that are being shipped and other details that describe a shipment transaction. The document itself is the original data in that anyone can read and understand its contents. When a hash algorithm is applied, the contents of the document are represented by a string of characters. A person or computer that analyzes the original data can derive meaning from it while this is not possible when the same person or computer analyzes a hash, which is just an abstract string of characters. For example, if the sentence “Today is a warm and pleasant day” is converted into a hash using an MD5 algorithm, the resulting hash is “890863fc4d30a9d4b5f1d857fbe3e2ed”. If the sentence is slightly changed, the hash value also changes, which makes it possible to prove that original data inside of a document has changed. For example, if the sentence changes to “Today is a cold and pleasant day” the hash value changes to “eb65089fedc860ca35c3107ddd280b74” using the same algorithm.

Referring toFIG.13, shown is Block Diagram1300comprising a flow to store an original document to a private distributed ledger in reference to System1100and Network1000. The flow shown in Block Diagram1300comprises of seven steps and begins with step1301in which a user uploads a document, for example a Bill of Lading (BOL), to System1100in reference to a specific electronic record of a process. In step1302Component1107processes and stores the BOL document and Component1106associates it with electronic record of a process to make it available for display to users of System1100. In step1303Component1107, or in other embodiments not shown inFIG.13Component1106, notifies Component1113that the BOL document is available to be added to a private distributed ledger. In step1304Component1113requests that the BOL document be added to a private distributed ledger. In step1305Component1113adds the BOL document to a block and broadcasts the transaction to a network of nodes (1003) participating in a private distributed ledger. Not shown in Block Diagram1300, a BOL document may be added to a block on a distributed ledger by a system or component that is not part of System1100. For example, Component1113may send the instruction to add the BOL document to a block on a distributed ledger to a dedicated distributed ledger system rather than adding the BOL document to a block directly. In step1306the nodes in the network (1003) validate the transaction and add the BOL document to their blocks. In step1307the BOL document has been added to a block and to a private distributed ledger.

Not shown in Block Diagram1300in some embodiments of the present invention a hash of an electronic record, event data, a document, a summary file, or user credentials may be written to a private or public distributed ledger. Also not shown in Block Diagram1300in other embodiments of the present invention a document file may be written to a public distributed ledger in its original format. Further not shown in Block Diagram1300in further embodiments of the present invention an electronic record, event data, a summary file or user credentials may be written to a private or public distributed ledger in their original format. Still further not shown in Block Diagram1300in certain embodiments of the present invention data may be written to a distributed ledger at certain point in time or on certain days as opposed to immediately.

Referring toFIG.14, shown is Block Diagram1400comprising a flow to write a hash of a summary file of an electronic record of a process to a public distributed ledger in reference to System1100and Network1000. The flow shown in Block Diagram1400comprises of nine steps and begins with step1401in which a process concludes so that no further event data or documents are going to be added to the electronic record of the process. In step1402Component1106saves a summary file of the electronic record of the process and attaches it to the electronic record itself. In step1403Component1106creates a hash of the summary file and stores it using Component1114. In step1404Component1106associates the hash with summary file and the electronic record of the process. In step1405Component1106notifies Component1113that a hash of a summary file of the process is available to be added to a public distributed ledger. In step1406Component1113requests that the hash of a summary file be added to a public distributed ledger. In step1407Component1113adds the hash of a summary file to a block and broadcasts the transaction to a network of nodes (1003) participating in a public distributed ledger. Not shown in Block Diagram1400, a hash of a summary file of an electronic record of a process may be added to a block on a distributed ledger by a system or component that is not part of System1100. For example, Component1113may send the instruction to add the hash of a summary file of an electronic record of a process to a block on a distributed ledger to a dedicated distributed ledger system rather than adding the hash of a summary file of an electronic record of a process to a block directly. In step1408the nodes in the network (1003) validate the transaction and add the hash of a summary file to their blocks. In step1409the hash of a summary file has been added to a block and to a public distributed ledger.

Not shown in Block Diagram1400, in some embodiments of the present invention a hash of an electronic record, event data, a document, or user credentials may be written to a public or private distributed ledger. Further not shown in Block Diagram1400in other embodiments of the present invention an electronic record, event data, a document, a summary file or user credentials may be written to a public or private distributed ledger in their original form. Also not shown in Block Diagram1400in further embodiments of the present invention a summary file may be written to a public distributed ledger in its original format. Still further not shown in Block Diagram1400in certain embodiments of the present invention data may be written to a distributed ledger at certain point in time or on certain days as opposed to immediately.

Referring toFIG.15, shown is Block Diagram1500comprising a practical example of a flow for writing event data, in this case a photographic image, in its original form to a private distributed ledger in reference to System1100comprising a distributed ledger and Network1000. In the example an operator is a person who moves freight such as a truck driver. The flow shown in Block Diagram1500comprises of eleven steps and begins with step1501in which an operator uses Element1004to capture event data in the form of a photo of freight. For example, the operator may wish to document the condition of the freight during a delivery process so that he can later prove that the freight was properly transported, did not experience damages and that no other harm came to it. In step1502the operator computer (1004) sends the photographic image to Component1108for processing and storage. In step1503Component1308processes the photo, for example by formatting it, reducing its file size or converting it into a PDF format. In step1504Component1108stores the photo of the freight. In step1505Component1106associates the photo of the freight to an electronic record of a process. In step1506Component1106notifies Component1113that a photo is available to be added to a private distributed ledger. In step1507Component1113requests that the photo of freight is added to a private distributed ledger. In step1508Component1113adds the photo to a block and in step1509Component1113broadcasts the transaction to a network of nodes (1003) participating in the private distributed ledger. In step1510the nodes in the network validate the transaction and add the photo of freight to their blocks. In step1511the photo of freight has been added to a block and to a private distributed ledger. Not shown in Block Diagram1500, a photo may be added to a block on a distributed ledger by a system or component that is not part of System1100. For example, Component1113may send the instruction to add a photo to a block on a distributed ledger to a dedicated distributed ledger system rather than adding the photo to a block directly.

Referring toFIG.16, another embodiment of the present invention for a network comprising two or more distributed ledgers for the creation, sharing, updating and storage of an electronic record in regard to the execution of a process is shown. Network1600comprising of two or more distributed ledgers comprises several computers including the systems previously described in the present invention disclosure for Network100and Network1000. Network1600comprising a distributed ledger comprises of a system to handle electronic records of a process (1601), a network for data sharing (1602), a first distributed ledger network comprising at least one node (1603), a second distributed ledger network comprising at least one node (1604), an operator computer (1605), a partner computer (1606) and external data sources (1607). The main difference between Network1000and Network1600is that the latter comprises two or more distributed ledgers. System1100comprising a distributed ledger functions in Network1600in the same way as it does in Network1000with the exception that they store data on more than one distributed ledger.

Element1601(System1100) shows the system for creating, sharing, updating and storing an electronic record of a process. Its components are described in detail inFIG.11.FIG.16should not imply that Network1600requires precisely one electronic record system for processes (1601) or is limited to a specific number of electronic record systems for processes (1601).

Element1602shows the network by which other Elements in Network1600may share data with each other and by which they may access two or more distributed ledgers (1603,1604). This embodiment of the present invention disclosure shows two distributed ledgers, but in some embodiments of the present invention all systems and methods discussed here apply equally to the use of three and more distributed ledgers as well.

Element1603is a first distributed ledger comprising at least one node. Element1604is a second distributed ledger comprising at least one node. Elements1603and1604function in the same way as Element1003in Network1000.

Element1605shows an operator computer used by a person or machine to access an electronic record of a process. Element1605functions in the same way as Element1004in Network1000.

Element1606shows a partner computer used by a person or machine to participate in the sharing and updating of an electronic record containing event data and documents during the execution of a process. Element1606functions in the same way as Element1005in Network1000.

Element1607shows external data sources used to obtain event data or documents regarding the execution of a process. Element1607function in the same way as Element1006in Network1000.

A practical example for when electronic records, summary files, event data, documents or user credentials that may be stored on more than one distributed ledger is that different parties involved in the operation and execution of a supply chain transaction may wish to use private distributed ledgers in addition to a public distributed ledger. Another example may be that different parties may prefer the use of different distributed ledger technologies, which would necessitate the writing of event data to more than one distributed ledger. Still another example may be that an implementation of one embodiment of the present invention is based on the use of a public distributed ledger for writing of hashes while data in its original form may be written to a private distributed ledger. Still another example may be that data may need to be made available to third-parties such as insurance or financing companies who may have their own distributed ledger technology. Still another example may be that some or all of the parties involved in the sharing and updating of an electronic record of a process may maintain their own distributed ledger.

Referring toFIG.17, shown is Block Diagram1700comprising a flow to write to write a hash of a summary file of an electronic record to two or more public distributed ledgers (1603,1604) in reference to System1100and Network1600. The flow shown in Block Diagram1700comprises of eleven steps and begins with step1701in which a process completes so that no further event data or documents are going to be added to the electronic record of the process, which triggers Component1106to create and save a summary file of the electronic record and to associate the summary file to the electronic record itself. In step1702Component1106creates a hash of the summary file, stores the hash using component1114and associates it to the summary file itself and the electronic record. In step1703Component1106notifies Component1113that a hash of a summary file of the process is available to be added to two public distributed ledgers. In step1704Component1113requests that the hash of a summary file be added to a first public distributed ledger (1603) and in step1705Component1113requests that the hash of a summary file be added to a second public distributed ledger (1604). In step1706Component1113adds the hash of a summary file to a block and broadcasts the transaction to a first network of nodes participating in a first public distributed ledger (1603). In step1707Component1113adds the hash of a summary file to a block and broadcasts the transaction to a second network of nodes participating in a second public distributed ledger (1604). In step1708the nodes in a first network validate the transaction and add the hash of a summary file to their blocks. In step1709the nodes in a second network validate the transaction and add the hash of a summary file to their blocks. In step1710the hash of a summary file has been added to a block and to a first public distributed ledger (1603). In step1711the hash of a summary file has been added to a block and to a second public distributed ledger (1604).

Not shown in Block Diagram1700, in some embodiments of the present invention a hash of an electronic record, event data, a document, or user credentials may be written to two or more public or private distributed ledgers. Further not shown in Block Diagram1700in other embodiments of the present invention an electronic record, event data, a document, a summary file or user credentials may be written to two or more public or private distributed ledgers in their original form. Also not shown in Block Diagram1700in further embodiments of the present invention a summary file may be written to two or more public distributed ledgers in its original format. Still further not shown in Block Diagram1700in certain embodiments of the present invention data may be written to two or more distributed ledgers at certain point in time or on certain days as opposed to immediately. Still not shown in Block Diagram1700, in certain embodiments of the present invention a first distributed ledger may be public, and a second distributed ledger may be private or vice versa. Further not shown in Block Diagram1700, a hash of a summary file of an electronic record of a process may be added to a block on a distributed ledger by a system or component that is not part of System1100. For example, Component1113may send the instruction to add a hash of a summary file of an electronic record of a process to a block on a distributed ledger to a dedicated distributed ledger system rather than adding the hash of a summary file of an electronic record of a process to a block directly.

Referring toFIG.18, shown is Block Diagram1800comprising a flow to write a summary file of an electronic record in its original format to two or more private distributed ledgers (1603,1604) in reference to System1100and Network1600. The flow shown in Block Diagram1800comprises of ten steps and begins with step1801in which a process completes so that no further event data or documents are going to be added to the electronic record of the process, which triggers Component1106to create and save a summary file of the electronic record and to associate the summary file to the electronic record itself. In step1802Component1106notifies Component1113that a summary file of an electronic record of a process is available to be added to two private distributed ledgers. In step1803Component1113requests that the summary file be added to a first private distributed ledger (1603) and in step1804Component1113requests that the summary file be added to a second private distributed ledger (1604). In step1805Component1113adds the summary file to a block and broadcasts the transaction to a first network of nodes participating in a first private distributed ledger (1603). In step1806Component1113adds the summary file to a block and broadcasts the transaction to a second network of nodes participating in a second private distributed ledger (1604). In step1807the nodes in a first network validate the transaction and add the summary file to their blocks. In step1808the nodes in a second network validate the transaction and add the summary file to their blocks. In step1809the summary file has been added to a block and to a first private distributed ledger (1603). In step1810the summary file has been added to a block and to a second private distributed ledger (1604).

Not shown in Block Diagram1800, in some embodiments of the present invention a hash of an electronic record, event data, a document, a summary file, or user credentials may be written to two or more public or private distributed ledgers. Further not shown in Block Diagram1800in other embodiments of the present invention an electronic record, event data, a document, or user credentials may be written to two or more public or private distributed ledgers in their original form. Also not shown in Block Diagram1800in further embodiments of the present invention a summary file may be written to two or more public distributed ledgers in its original format. Still further not shown in Block Diagram1800in certain embodiments of the present invention data may be written to two or more distributed ledgers at certain point in time or on certain days as opposed to immediately. Also not shown in Block Diagram1800, in certain embodiments of the present invention a first distributed ledger may be public, and a second distributed ledger may be private or vice versa. Further not shown in Block Diagram1800, a summary file of an electronic record of a process may be added to a block on a distributed ledger by a system or component that is not part of System1100. For example, Component1113may send the instruction to add a summary file of an electronic record of a process to a block on a distributed ledger to a dedicated distributed ledger system rather than adding the summary file of an electronic record of a process to a block directly.

Referring toFIG.19, shown is Block Diagram1900comprising a flow to write a partial summary file to a first private distributed ledger (1603) and a partial summary file to a second private distributed ledger (1604) in reference to System1100and Network1600. The flow shown in Block Diagram1900comprises of eleven steps and begins with step1901in which a process completes so that no further event data or documents are going to be added to the electronic record of the process, which triggers Component1106to create and save a summary file of the electronic record and to associate the summary file to the electronic record itself. In step1902Component1106splits the summary file of an electronic record into two parts and associates both with the electronic record and the original summary file. In step1903Component1106notifies Component1113that a first and a second part of a summary file of an electronic record are available to be added to two private distributed ledgers. In step1904Component1113requests that a first part of a summary file be added to a first private distributed ledger (1603) and in step1905Component1113requests that a second part of a summary file be added to a second private distributed ledger (1604). In step1906Component1113adds a first part of a summary file to a block and broadcasts the transaction to a first network of nodes participating in a first private distributed ledger (1603). In step1907Component1113adds a second part of a summary file to a block and broadcasts the transaction to a second network of nodes participating in a second private distributed ledger (1604). In step1908the nodes in a first network validate the transaction and add a first part of a summary file to their blocks. In step1909the nodes in a second network validate the transaction and add a second part of a summary file to their blocks. In step1910a first part of a summary file has been added to a block and to a first private distributed ledger (1603). In step1911a second part of a summary file has been added to a block and to a second private distributed ledger (1604).

Not shown in Block Diagram1900, in some embodiments of the present invention a hash of a partial electronic record, partial event data, a partial document, a partial summary file, or partial user credentials may be written to two or more public or private distributed ledgers. Further not shown in Block Diagram1900in other embodiments of the present invention a partial electronic record, partial event data, a partial document, or partial user credentials may be written to two or more public or private distributed ledgers in their original form. Also not shown in Block Diagram1900in further embodiments of the present invention partial summary files may be written to two or more public distributed ledgers in their original format. Still further not shown in Block Diagram1900in certain embodiments of the present invention data may be written to two or more distributed ledgers at certain point in time or on certain days as opposed to immediately. Also not shown in Block Diagram1900, in certain embodiments of the present invention a first distributed ledger may be public, and a second distributed ledger may be private or vice versa. Further not shown in Block Diagram1900, a first and second partial summary file of an electronic record of a process may be added to blocks on two or more distributed ledgers by a system or component that is not part of System1100. For example, Component1113may send the instruction to add a first and second partial summary file of an electronic record of a process to block on two or more distributed ledgers to one, two or more dedicated distributed ledger systems rather than adding the first and second partial summary file of an electronic record of a process to a block directly.

Referring toFIG.20, shown is Block Diagram2000comprising a flow to write a first partial hash of a summary file to a first public distributed ledger (1603) and a second partial hash of a summary file to a second public distributed ledger (1604) in reference to System1100and Network1600. The flow shown in Block Diagram2000comprises of eleven steps and begins with step2001in which a process completes so that no further event data or documents are going to be added to the electronic record of the process, which triggers Component1106to create and save a summary file of the electronic record and to associate the summary file to the electronic record itself. In step2002Component1106creates a hash of the summary file and splits the hash of the summary file of an electronic record into two parts and associates both with the electronic record and the original summary file. The hash and its two parts are stored using Component1114. In step2003Component1106notifies Component1113that a first and a second part of a hash of a summary file of an electronic record are available to be added to two public distributed ledgers. In step2004Component1113requests that a first part of a hash of a summary file be added to a first public distributed ledger (1603) and in step2005Component1113requests that a second part of a hash of a summary file be added to a second public distributed ledger (1604). In step2006Component1113adds a first part of a hash of a summary file to a block and broadcasts the transaction to a first network of nodes participating in a first public distributed ledger (1603). In step2007Component1113adds a second part of a hash of a summary file to a block and broadcasts the transaction to a second network of nodes participating in a second public distributed ledger (1604). In step2008the nodes in a first network validate the transaction and add a first part of a hash of a summary file to their blocks. In step2009the nodes in a second network validate the transaction and add a second part of a hash of a summary file to their blocks. In step2010a first part of a hash of a summary file has been added to a block and to a first public distributed ledger (1603). In step2011a second part of a hash of a summary file has been added to a block and to a second public distributed ledger (1604).

Not shown in Block Diagram2000, in some embodiments of the present invention a partial hash of an electronic record, event data, a document, or user credentials may be written to two or more public or private distributed ledgers. Still further not shown in Block Diagram2000in certain embodiments of the present invention data may be written to two or more distributed ledgers at certain point in time or on certain days as opposed to immediately. Also not shown in Block Diagram2000, in certain embodiments of the present invention a first distributed ledger may be public, and a second distributed ledger may be private or vice versa. Further not shown in Block Diagram2000, a first and second partial hash of a summary file of an electronic record of a process may be added to blocks on two or more distributed ledgers by a system or component that is not part of System1100. For example, Component1113may send the instruction to add a first and second partial hash of a summary file of an electronic record of a process to block on two or more distributed ledgers to one, two or more dedicated distributed ledger systems rather than adding the first and second partial hash of a summary file of an electronic record of a process to a block directly.

Referring toFIG.21, shown is Block Diagram2100comprising a flow to write a hash of a first partial summary file to a first public distributed ledger (1603) and a hash of a second partial summary file to a second public distributed ledger (1604). The flow shown in Block Diagram2100comprises of eleven steps and begins with step2101in which a process completes so that no further event data or documents are going to be added to the electronic record of the process, which triggers Component1106to create and save a summary file of the electronic record and to associate the summary file to the electronic record itself. In step2102Component1106splits the summary file of an electronic record into two parts, creates a hash for each part, stores both hashes using Component1114and associates both hashes and both parts of a summary file with the electronic record and the original summary file. In step2103Component1106notifies Component1113that a first and second hash for two parts of a summary file of an electronic record are available to be added to two public distributed ledgers. In step2104Component1113requests that a hash of a first part of a summary file be added to a first public distributed ledger (1603) and in step2105Component1113requests that a hash of a second part of a summary file be added to a second public distributed ledger (1604). In step2106Component1113adds a hash of a first part of a summary file to a block and broadcasts the transaction to a first network of nodes participating in a first public distributed ledger (1604). In step2107Component1113adds a hash of a second part of a summary file to a block and broadcasts the transaction to a second network of nodes participating in a second public distributed ledger (1604). In step2108the nodes in a first network validate the transaction and add a hash of a first part of a summary file to their blocks. In step2109the nodes in a second network validate the transaction and add a hash of a second part of a summary file to their blocks. In step2110a hash of a first part of a summary file has been added to a first block and to a first public distributed ledger (1603). In step2111a hash of a second part of a summary file has been added to a block and to a second public distributed ledger (1604).

Not shown in Block Diagram2100, in some embodiments of the present invention a hash of a partial electronic record, partial event data, a partial document, or partial user credentials may be written to two or more public or private distributed ledgers. Still further not shown in Block Diagram2100in certain embodiments of the present invention data may be written to two or more distributed ledgers at certain point in time or on certain days as opposed to immediately. Also not shown in Block Diagram2100, in certain embodiments of the present invention a first distributed ledger may be public, and a second distributed ledger may be private or vice versa. Further not shown in Block Diagram2100, a hash of a first and second partial summary file of an electronic record of a process may be added to blocks on two or more distributed ledgers by a system or component that is not part of System1100. For example, Component1113may send the instruction to add a hash of a first and second partial summary file of an electronic record of a process to block on two or more distributed ledgers to one, two or more dedicated distributed ledger systems rather than adding the hash of a first and second partial summary file of an electronic record of a process to a block directly.

The use of the term “or” in the claims is used to mean “and/or” unless explicitly indicated to refer to alternatives only or the alternatives are mutually exclusive, although the disclosure supports a definition that refers to only alternatives and to “and/or.” When used in conjunction with the word “comprising” or other open language in the claims, the words “a” and “an” denote “one or more,” unless specifically noted. The terms “comprise,” “have” and “include” are open-ended linking verbs. Any forms or tenses of one or more of these verbs, such as “comprises,” “comprising,” “has,” “having,” “includes” and “including,” are also open-ended. For example, any method that “comprises,” “has” or “includes” one or more steps is not limited to, possessing only those one or more steps and also covers other unlisted steps.

Unless indicated otherwise, or otherwise clearly contradicted by context, the steps in the methods disclosed herein can be performed in any order.