Use of a unique transferrable title to control access to product data

Abstract

The present application relates to devices and components including apparatus, systems, and methods to provide flexible access to data stored across a cooperating supply chain.

Description

USE OF A UNIQUE TRANSFERRABEE TITEE TO CONTROE ACCESS TO PRODUCT DATACROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Application No. 63 / 568,819, filed March 22, 2024, entitled “USE OF A UNIQUE TRANSFERRABLE TITLE TO CONTROL ACCESS TO PRODUCT DATA,’’ which is hereby incorporated by reference in its entirety.TECHNICAL FIELD

[0002] This application relates generally to data storage and access systems and, in particular, to technologies for using unique transferrable title to control access to product data.BACKGROUND

[0003] In today’s business environment, information about a product is generated by many actors during the lifecycle of the project. For example, manufacturers may create information about how the product was created; and shippers may create information about how and when the product was transported. Every entity7touching the product will have data about that product and what they have done to it. This complex environment applies to both digital as well as physical products. Not only are there a large number of actors but they can be chosen just-in-time. Consider a shipper transporting a package. The action may be put up to bid and the lowest cost shipper may be used. This dynamic environment means that there may not be established relationships between the actors. Today, there are three options for storing product data. First, it can be stored within database systems and structures that are owned by the originator of that data. Second, certain events can be shared among the actors through an Electronic Data Interchange (EDI) system. The other actors are notified of changes in the data and can store the information within database systems and structures that are owned by the actor. Third, the data can be stored at a third party in a centralized or distributed storage system where each actor is authorized to access under control of an authentication and authorization system.

[0004] Because of the dynamic nature of a product’s supply chain, each of these three solutions has critical shortcomings in how they provide access to the data about a product. Consider the limited case of the number of actors that a product may pass through on its way to market. The producer creates the item and sends it to a shipper. The shipper contracts with one or more transporters depending on the requirements of the shipment and the shipment costs. The product may arrive at a port and need to be held by an actor responsible for the clearance of customs in the arriving country. The product may then be passed on to a distributer and finally to the recipient. Compounding the complexity of this situation is that many of these actors may not be known to each other, nor draw n from a fixed set of actors known in advance. For example, the producer may not know7the transporter used by the shipper, and the decision of which transporter to be used may not be set until the transport price is sent out to bid. This very dynamic nature of the environment leads to challenges in each of the methods for storing and transmitting data. The first case, where data is stored within database systems and structures that are owned by the originator of the data means that data cannot be shared among the various actors. Information about how the product was transported will be spread across information systems of all of the actors. The actors have the ability to open their information systems to the other actors in the chain, through federated identity7systems, but this assumes that all of the actors are known and entered into the system. The second case, where data is interchanged via an EDI system has the same problem of having the data distributed across all of the actors. Maintaining data consistency becomes extremely difficult if the various actors represent information in their databases differently. The third case allows for data consistency since the data is stored in a single logical information system but requires that all actors have a pre-existing relationship with that information system and have rights to the data granted to them for access.

[0005] Determining the rights to access (read, modify, or write) a particular data item has the same problem as storage and transmission of the data - the set of actors processing information about a product is dynamic and complex. In a discretionary' access system, the owner of the data defines the rights of the various actors that can access the data. Consider the shipment situation above. The producer creates the product, at that time they own the information elements about production including the information element about the current location of the product. The producer hands the product off to a shipper. Does the producer retain ownership rights over the location information element, or do they transfer ownership to the shipper who then fills in the element to represent their warehouse? The shipper thenhands off the product to one or more contract transporters (possibly not known to the original producer). If the producer retains ownership of the location, how do they authorize an unknown transporter to make changes to the location information element? Does ownership of the information element transfer to the transporter when they receive the shipment? The information systems of today are designed around a fixed set of roles among a fixed set of actors that are all known to either a centralized authority or known to each other. These restrictions mean that dynamic product information across the lifecycle of a product cannot be easily accessed and maintained causing confusion and mistrust in the business processes.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 illustrates actors that may be involved in a lifecycle of a product in accordance with some embodiments.

[0007] FIG. 2 illustrates entities involved in production and deployment of a digital asset in accordance with some embodiments.

[0008] FIG. 3 illustrates computing systems involved in the creation, maintenance, and access of the lifecycle data in accordance with some embodiments.

[0009] FIG. 4 illustrates the internal elements of system components in accordance with some embodiments.

[0010] FIG. 5 illustrates the elements of a Data Object Title (DOT) structure in accordance with some embodiments.

[0011] FIG. 6 illustrates an operation flow / algorithmic structure operating on a Product Lifecycle Information Storage System to determine a data owner for a Data Element in accordance with some embodiments.

[0012] FIG. 7 illustrates an operation flow / algorithmic structure operating on a Data Owner Information System for determining whether a given request is permitted in accordance with some embodiments.

[0013] FIG. 8 illustrates an operation flow / algorithmic structure operating on a Data Custodian Information System for determining whether a given request is permitted in accordance with some embodiments.

[0014] FIG. 9 illustrates an operation flow / algorithmic structure operating on a Data Accessor to request access to a Data Element in accordance with some embodiments.

[0015] FIG. 10 illustrates an operation flow / algorithmic structure operating on a Product Lifecycle Information Storage System to process a request for data access in accordance with some embodiments.

[0016] FIG. 11 illustrates an operation flow / algorithmic structure operating on a Data Owner Information System to complete operations on data access in accordance with some embodiments.

[0017] FIG. 12 illustrates a signaling and operational diagram of elements of a system for processing a request to access a data element in accordance with some embodiments.

[0018] FIG. 13 illustrates a signaling and operational diagram of elements of the system for completing the request to access a Data Element introduced in FIG. 12 in accordance with some embodiments.

[0019] FIG 14 illustrates an operation flow / algorithmic structure operating on a Product Lifecycle Information Storage System to create a new Data Element in accordance with some embodiments.

[0020] FIG. 15 illustrates an operation flow / algorithmic structure operating on a Product Lifecycle Information Storage System to transfer the ownership of a Data Element from one Actor to another in accordance with some embodiments.

[0021] FIG. 16 illustrates an operation flow / algorithmic structure operating on a Data Object Title System to transfer ownership of a Data Element from one Actor to another in accordance with some embodiments.

[0022] FIG. 17 illustrates a signaling and operational diagram of elements of a system for processing a request to transfer ownership of a Data Element from one Actor to another in accordance with some embodiments.

[0023] FIG. 18 illustrates an operation flow / algorithmic structure operating on a Product Lifecycle Information Storage System to alter stored permissions for a Data Element in accordance with some embodiments.

[0024] FIG. 19 illustrates an operation flow / algorithmic structure operating on a Data Owner Information System to alter stored permissions for a Data Element in accordance with some embodiments.

[0025] FIG. 20 illustrates an operation flow / algorithmic structure operating on a Data Custodian Information System to alter stored permissions for a Data Element in accordance with some embodiments.

[0026] FIG. 21 illustrates a signaling and operational diagram of elements of a system for processing a request to change permissions of a Data Element in accordance with some embodiments.

[0027] FIG. 22 illustrates an operation flow / algorithmic structure operating on a Product Lifecycle Information Storage System to create a Data Custody relationship for a Data Element in accordance with some embodiments.

[0028] FIG. 23 illustrates an operation flow / algorithmic structure operating on the Data Owner Information System to create a Data Custody relationship for a Data Element in accordance with some embodiments.

[0029] FIG. 24 illustrates an operation flow / algorithmic structure operating on a Data Custodian Information System to create a Data Custody relationship for a Data Element in accordance with some embodiments.

[0030] FIG. 25 illustrates a signaling and operational diagram of elements of a system for processing a request to create a Data Custody relationship for a Data Element in accordance with some embodiments.

[0031] FIG. 26 illustrates an operation flow / algorithmic structure operating on a Product Lifecycle Information Storage System to delete a Data Custody relationship for a Data Element in accordance with some embodiments.

[0032] FIG. 27 illustrates an operation flow / algorithmic structure operating on a Data Owner Information System to delete a Data Custody relationship for a Data Element in accordance with some embodiments.

[0033] FIG. 28 illustrates an operation flow / algorithmic structure operating on a Data Custodian Information System to delete a Data Custody relationship for a Data Element in accordance with some embodiments.

[0034] FIG. 29 illustrates a signaling and operational diagram of elements of a system for processing a request to delete a Data Custody relationship for a Data Element in accordance with some embodiments.

[0035] FIG. 30 illustrates a device that can be used to carry out operations in accordance with some embodiments.DETAILED DESCRIPTION

[0036] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrase “A or B” and “A / B” means (A), (B), or (A and B); and the phrase “based on A” means “based at least in part on A,” for example, it could be “based solely on A” or it could be “based in part on A.

[0037] Systems, methods, and apparatuses for maintaining information about the lifecycle of a manufactured, agricultural, or digital object are described herein. For example, in one embodiment, information elements about subassemblies, ingredients, manufacturing process, and transport conditions are created by computer systems throughout the supply chain. The various actors provide information about the status of the process. Information can be read, modified, or written about the status of a product by an actor using a properly authenticated computing system that is networked to the other devices in the network, or they can be created automatically by sensor endpoints that read information, and createinformation elements and send it to the network independently. This information is aggregated and stored, either centrally or distributed in a manner that prevents the unauthorized addition, subtraction, or alteration of information. During the lifetime of the product, actors using computing systems can access the information to inform each other of milestones in the product’s lifecycle or to create business intelligence on the manufacturing process. Other related embodiments are also described and claimed.

[0038] The following is a glossary of terms that may be used in this disclosure.

[0039] Actor: One of the cooperating entities that share data as part of the system. An actor can implement one of the following roles. A single computing system may implement one or more of the actor roles or they may be distributed among different computing systems.

[0040] Data Accessor: The actor that initiates a request for reading, modifying, or writing a particular data element in the computing network.

[0041] Product Lifecycle Information Storage: The role that manages the storage of the data elements of the system. The Product Lifecycle Information Storage operates as a point of contact for access requests to Data Elements.

[0042] Data Owner: The role that has final authority over the authorization rights for a given Data Element.

[0043] Data Custodian: The role that has delegated authority over the authorization rights for a given Data Element.

[0044] Data Custodian Policy: An electronic list of actions that are allowed to be delegated under a Data Custodian role. A Data Custodian Policy may also be referred to herein, as a custody policy, a Data Custodian Contract, or a custody contract.

[0045] Data Element: An atomic unit of data that is grouped and treated as a single unit.

[0046] Data Object Title (DOT): An unalterable block of data that defines a Data Element. Ow nership of a DOT defines ownership of an associated Data Element.

[0047] Today’s systems are very rigid in how they allow' data to be shared among the various Actors in the product’s lifecycle. Data Elements are either duplicated across the various Actors, or are defined in a storage system with a fixed set of roles and responsibilities among the Actors who are all assumed to know and trust each other. In a discretionary access control system, the Data Owner for any Data Element maintains an access control list that specifies the other Actors in the system and their rights to access (read, modify, write) a particular Data Element. In today’s systems the Data Owner is fixed and defined at the timethat the Data Element is created. The Data Owner is often the same Actor that stores the data making the authorization of whether the Actor is performing a valid data access a decision that is completely internal to the storage of the system. As described above, various problems exist with this rigid structure given the dynamic nature of today’s supply chains. Embodiments of the present disclosure provide improvements on the present state of the art by creating a secure DOT. The owner of the DOT is defined to be the current Data Owner for the corresponding Data Element. In contrast to today’s systems the Data Owner role may be transferred among the Actors by transferring the ownership of the DOT. In this case, the Data Owner may be completely separated from the storage of the Data Element and may reside in systems owned and operated by other business entities. In addition to permanent transfer of the Data Owner role, embodiments also define a Data Custodian role where the Data Owner can pass its ownership rights to another Actor in a temporary fashion. The Data Custodian can then define access control operations on the Data Element, under oversight of the Data Owner. Embodiments also provide for a chained set of Data Custodian relationships. Actor 1 may create a Data Custodian relationship with Actor 2. Actor 2 may then create a Data Custodian relationship with Actor 3. These chains may be arbitrarily long. Actor 3 may allow data access to other Actors that are unknown to Actor 1 or Actor 2. During a data operation, the end node in the chain (Actor 3 in the example above) determines the authentication and authorization of the operation. However, each Actor in the chain may assert their oversight using a Data Custodian Policy that is stored with the Data Custodian relationship. In the example above. Actor 1 may establish a Data Custodian Policy with Actor 2 that only read operations are allowed to be delegated under the Data Custodian Policy. If Actor 3 allow s a write operation on a particular Data Element, the Data Custodian Policy between Actor 1 and Actor 2 will override that decision and that operation will not be permitted. Using these operations a distributed set of computing systems can maintain many different Data Elements about a product’s lifecycle and allow rights to access that information to be securely transferred betw een Actors that may not have complete knowledge and trust of each other. As an example, consider the case where a manufacturer contracts with a shipping company for transport of a product. The manufacture may create a Data Custodian relationship allowing the shipping company control over a limited set of Data Elements. The shipping company may contract with a transport firm that is not known to the manufacturer and they may create a Data Custodian relationship with that transport firm. The transport firm may then assign the product to a particular truck and the transport firm controls which truck may read or write tothe Data Element representing the current location of the product. When the transport is complete, the Data Custodian relationships are deleted and the manufacturer regains complete control over the operations on the Data Element.

[0048] Information about a product’s lifecycle may be stored in one or more of a set of networked, distributed computing nodes and data structures. Different Data Elements may reside in different storage locations and may be replicated across locations to ensure continuous access to the data in the presence of system faults. The Data Elements stored may represent elemental aspects over the development and functional lifetime of the product or they may represent more structured sets of information. For example, ingredients contribute information about parts, which are aggregated into information about subassemblies, which are aggregated into information about a manufactured product. The Data Elements may also contain precise data about the current location or state of a product (where it is located along with the conditions that it is currently experiencing). The various Data Accessors in the product’s lifecycle may have various rights to read, modify, or write those Data Elements and those rights may change over time. The entities within a product’s lifecycle are shown in FIG. 1 in accordance with some embodiments. A product may pass through four phases. The origin is the creation of the product from ingredients, smaller parts, subassemblies, and into final manufacture. A regulator or partner is shown as interacting only with the manufacturer; how ever, other embodiments allow interactions with these entities across all phases of the lifecycle. Once a product is manufactured it may pass through several distributors, transport services, and retailers during a custody phase. The product may be made available to the consumer at a retailer. For a durable good such as a car, there may be several consumers who purchase and resell the product throughout its life in the consumption phase. Finally the end of the product’s lifecycle may be the conversion phase where it is converted into a new product, recycled, or disposed.

[0049] In some embodiments, the information stored for a product may include a plurality' of Data Elements corresponding to each of these phases. For example, information about a product may include a set of Data Elements about its origin that can be written by the manufacturer until the product is delivered to the next entity in the lifecycle. After that point, the manufacturer should have no rights to alter the Data Elements about the product’s origin. A transporter may have rights to modify Data Elements corresponding to custody information but only so long as the product is in their physical custody. A consumer may have rights to modify Data Elements about product use, for as long as they own a product. And a recyclermay have rights to information about product conversion Data Elements but only after having been surrendered by the consumer.

[0050] The same type of dynamic and complex environment may hold for digital products as well as more conventional physical products. FIG. 2 shows a limited set of the entities involved in production and deployment of a digital asset in some embodiments. As shown, two modules are created and tested by independent companies before being integrated with a third party package. Each of the entities shown may be separate legal companies (as shown) or they may be contributed by different projects teams in the same organization. A reasonably complex digital asset, such as a medical patient information system, may have hundreds of module suppliers and integrate dozens of third party' packages. The integrated package is then deployed onto many hardware instances that may be owned and operated by other entities. The integrated hardware and software may be maintained by yet another entity such as a cloud service provider. Consider the case of the medical patient information system, the hardware may be owned by a medical office or hospital that has either an internal team to maintain the system or contracts that function to an outside party. In this case, the developer of the system may not have any pre-existing relationship with the operational contractors for a particular hospital. However, in a failure case, information about the testing and integration of the system may be critical to that team for finding and fixing problems.

[0051] Each of these entities may maintain computing information systems and data management systems in order to cooperatively build and maintain the set of product information throughout the product’s lifecycle. This data may consist of test results, code review notes, times of commitment to centralized source control systems, etc.

[0052] FIG. 3 is a high level and simplified illustration of the basic operations of a system 300 in accordance with some embodiments. Data Elements, for example, Data Element 321, may be stored within a centralized or distributed Information Storage 320. The Information Storage 320 may be any of a number of well-known storage systems that provide fault-tolerant, redundant, and distributed storage for Data Elements. A Product Lifecycle Information Storage System 310 manages access to the Data Elements ensuring that the current Data Owner for the Data Element 321 authorizes the access to the Data Element 321. There may be one or more Product Lifecycle Information Storage Systems 310 across a number of the entities illustrated in FIGs. 1 and 2. A Data Accessor Information System 360 may initiate the process of requesting access to a given Data Element by connecting to the Product Lifecycle Information Storage System 310 and sending an access request (Step 1).There are a number of remote data access protocols including Hypertext Transfer Protocol (HTTP), SAMBA, or a Server Message Block (SMB). Any of these protocols may be chosen for the system 300. When the Product Lifecycle Information Storage System 310 receives an access request, it may first determine the Data Owner for the given Data Element 321. This is because the Data Owner is not state and may change betw een requests. The Product Lifecycle Information Storage System 310 may contact a Data Object Title System 330 to determine the current Data Owner for the given Data Element 321 (Step 2). As will be described in further detail, the Data Object Title System 330 may maintain the current Data Owner for a given Data Element. The Data Object Title System 330 may respond with information on how- to contact the Data Owner Information System 350 for the given Data Element 321. The Product Lifecycle Information Storage System 310 may then contact interfaces of the Data Owner Information System 350 (Step 3). The Product Lifecycle Information Storage System 310 may pass all information contained in the access request of Step 1 This information may include authentication information that provides an identity of the Data Accessor. If the Data Owner Information System 350 determines there is an outstanding Data Custodian relationship for the Data Element 321, it may contact Data Custodian Information System 370 (Step 4). For a current Data Custodian relationship the Data Custodian Information System 370 may determine whether it has an outstanding Data Custodian relationship with another entity and call a Data Custodian information System of the other entity (Step 4a) for whether authorization of the Data Accessor request is allowed. If the Data Custodian Information System 370 determines there are no outstanding Data Custodian relationships, it validates the Data Accessors Information System’s authentication information and then determines the authorization of the Data Accessor. The Data Custodian Information System 370 may then reply to the Data Owner Information System 350 (Step 4) (or a caller Data Custodian Information System (370) if part of Step 4a) with the decision on the authorization of the access. The receiving Data Owner Information System 350) (or Data Custodian Information system 370 if part of Step 4a) may then determine if the authorization is allowed under the outstanding Data Custodian relationship. It then may respond to the caller Data Owner Information System (350) (Step 4) (or Data Custodian information System 370 if part of Step 4a) with the authorization decision. At some point the authorization information arrives back at the Data Owner Information System 350 and any outstanding toplevel Data Custodian relationship is consulted to determine if the access is authorized. If there is no outstanding Data Custodian relationship, the Data Owner Information System 350 maydirectly validate the Data Accessor’s authentication and look up the operation requested by the Data Accessor Information System 360 against the rights allowed the Data Accessor for the given Data Element 321. The Data Owner Information System 350 responds to the Product Lifecycle Information System 310 completing Step 3). In Step 4, the Product Lifecycle Information Storage System 310 may cany7out the operation (or respond with an error condition) and respond to the Data Accessor Information system 350 with the results. During any of the steps in the system, the Product Lifecycle Information Storage System 310, the Data Owner Information System 350, and the Data Custodian Information System 370 may record the action to a Blockchain Management System 340 to create a permanent record of the decisions and actions taken (Step 5). The Blockchain Management System 340 may be any embodiment of a distributed ledger with cryptographic support for immutability and traceability of entities placed on the blockchain. Common blockchains include the Bitcoin or Ethereum blockchains. No specific requirements are placed on the blockchain implementation other than the ability to immutably record data blocks provided by the Actors of the system. The access request is then completed in Step 6 as the Product Lifecycle Information Storage System 310 replies to the request from the Data Accessor Information Storage System 360 from Step 1.

[0053] FIG. 4 illustrates elements of the system 300 in accordance with some embodiments. In particular, FIG. 4 illustrates examples of internal interfaces of the elements of the system 300.

[0054] The internal interfaces shown in FIG. 4 cany out the operations shown in the steps of FIG. 3 and the details of the operations in later figures. This may allow the Product Lifecycle Information Storage System 310 to maintain and manage the distributed data structure of the information about a product. The Product Lifecycle Information Storage System 310 may be responsible for ensuring that a complete set of information on a product’s lifecycle can be accessed when needed, and may be responsible for ensuring that the various actors can perform those actions on the object story that are permitted by their roles defined by the Data Owner for each Data Element. Alternately, the Product Lifecycle Information Storage System 310 may be responsible for only a portion of the information about a product’s lifecycle and the complete set of information may be stored across many Product Lifecycle Information Storage Systems 310. Each of the entities in FIGs. 1 or 2 may implement the Product Information Lifecycle Storage System 310. In another embodiment, athird partj' may implement these systems and the Actor's systems will interact with this third party to maintain a store of product information.

[0055] The Product Lifecycle Information Storage System 310 may include a number of modules including, for example, Data Storage Manager 411, an Authorization Manager 412, a DOT Manager 413, and a Blockchain Recorder 415. The Data Storage Manager 411 may be responsible for maintaining the storage of the information about the product and ensuring that the data is securely represented and free from errors. The Data Storage Manager 411 may interact with the Information Storage 320 to store the information in a database that is centralized on a single server, replicated on multiple servers, or distributed across multiple systems sites / entities. In some embodiments, the Data Storage Manager 411 uses one or more distributed ledgers to maintain the information. For each Data Element, the Data Storage Manager 411 may store both the data of the Data Element as well as the DOT defining the title for that information element into the Information Storage 320. The Authorization Manager 412 may be responsible for ensuring that access to the Data Elements within the Data Storage Manager 411 is allowed by the current Data Owner of the given Data Element. The DOT Manager 413 may be responsible for interacting with the Data Object Title System 430 to create, transfer, and retrieve the DOTs that correspond to Data Elements managed by the Product Lifecycle Information Storage System 310. At times in the operation, the Product Lifecycle Information Storage System 310 may need to record and validate information to a distributed blockchain in order to maintain an immutable record of operations. The interaction with one or more blockchain implementations may be accomplished through the Blockchain Access module 414.

[0056] The Data Owner Information System 350 and Data Custodian Information System 370) may control the authorization of access to the Data Elements of one or more Product Lifecycle Information Storage Systems 310. The Data Owner Information System 350 carries out the actions of the Data Ow ner role for a Data Element, while the Data Custodian Information System 370 carries out the actions of a Data Custodian for a Data Element. Because these roles are similar, the Data Owner Information System 350 and the Data Custodian Information System 370 may implement many of the same internal interfaces. The Data Owner Information System 350 may include an Authentication Manager 451, an Authorization Manager 452, a Blockchain Manager 453, a Data Custody Manager 454, and a Data Security Manager 455. The Data Custodian Information System 370 may include an Authentication Manager 471, an Authorization Manager 472, a BlockchainManager 473, and a Data Custody Manager 474. The Authorization Managers 451 and 471 and the Authorization Managers 452 and 472 approve the authorization and authentication requests respectively sent to them. The Blockchain Managers 453 and 473) may provide access to the blockchain in order to record and look up items stored thereon. The Data Custody Managers 454 and 474 may provide the ability to create and manage Data Custodian relationships. The Data Security Manager (454) may manage keys to the Data Elements and encrypts / decrypts data at the request of the Data Accessor Information System 360.

[0057] The Data Accessor Information System 360 initiates the request to read, modify, or write a Data Element. The Data Accessor Information System 360 may include a Data Access Requestor 461 to contact the Data Storage Manager 411 of the Product Lifecycle Information System 310 using any commonly known data access protocols such as HTTP, SAMBA, or SMB. The Data Accessor Information System 360 also supplies authentication information as part of the request in order to prove its identify in the system. This data request initiates one or more of the operations defined in later figures and discussions, resulting, if successful, in a copy of the Data Element, or the rights to write / modify a Data Element. This Data Element may be encrypted by the Data Owner so the Data Accessor Information System 360 may implement modules shown as a Data Encryption Manager 462 and a Data Decry ption Manager 463 in order to communicate with the Data Security7Manager module 455 of the Data Owner Information System 450 to perform the necessary operations.

[0058] The DOT system 330 implements in hardware and software a system for issuing, storing, transferring, and verifying DOTs. When issued, a DOT may define information about a Data Element stored within the Product Lifecycle Storage System 310. Ownership of the DOT may define the Actor to be in the data ownership role for a given Data Element. The DOT system 330 may include a DOT Minter 431 to create a new DOT for a Data Element and represent the current ownership of that DOT. The DOT system 330 may further include a DOT Transfer Manager 432 to affect a transfer of ownership of the DOT from one Actor to another. Ownership of the DOT can be defined in a number of ways. The DOT Transfer Manager 432 may store information about the current owner, the current owner may be represented within the DOT structure, the ownership may be carried on the Blockchain Management System 340, or ownership may be defined by ownership of a Non- Fungible Token (NFT) defined on the Blockchain Management System 340.

[0059] There are a number of ways that ownership of the DOT can be established and maintained. The DOT structure itself may contain an indication of the current owner, w ithcryptographic proof that this owner has been allowed to take possession of the data element. The DOT owner can be recorded on a centralized leger or register in the system. Transfer of ownership would then be accomplished by changing the leger record for the given DOT. The DOT owner can be recorded on a decentralized blockchain and ownership would be transferred by recording a new ow nership record on the blockchain. Ownership of the DOT can be based on ownership of another digital entity’. This could be based on the ownership of a non-fungible token (NFT). The most popular NFT is based on the Ethereum blockchain and is documented in ERC-721 at htps: / / eips.ethereiHn.org / EIPS / eip-721. Transfer of ownership of the DOT would be completed by changing ownership of the corresponding NFT. Transferring of data ownership may establish a complete and final transfer of the ability' to make decisions about the rights of actors to perform operations on this data element.

[0060] The DOT system 330 may further include a DOT Verifier (433) to determine the validity and current oyyner of any given DOT and provide the accessing entity’ an assurance as to the correctness of the DOT and the identity of the current owner of that DOT. There may be a number of DOT systems 330 distributed across the network maintaining DOTs for a single product information system, but any single DOT will map to a single DOT system 330.

[0061] FIG. 5 illustrates elements of a DOT 510 in accordance with some embodiments. The DOT 510 may contain a Data Element ID 501 that is a globally unique identifier of the data element stored within the Product Lifecycle Information Storage System 310 . The DOT 510 may also contain a DOT ID 502 that contains a globally unique identifier of the DOT 510. A Data Address field (503) of the DOT 510 may contain an address yvithin the Product Lifecycle Information Storage System 310 where the data is stored. This field is optional and may provide ease of implementation providing the location directly instead of requiring the Product Lifecycle Information Storage System 310 to internally map the Data Element ID 501 to the location. A fourth optional element of the DOT 510 is a data description 504, yvhich may provide a human-readable description of the type of information that is stored in the associated Data Element. Additionally, there may be a field containing a cryptographic proof of authenticity 5505 of the DOT 510. There are a number of mechanisms that can be used to prove authenticity such as a digital signature by the author of the DOT 510. In some embodiments there may be additional fields that contain information about the current owner of the DOT.

[0062] FIGs. 6, 7, and 8 illustrate a set of operation flows / algorithmic structures that may be used among a networked set of computing systems (for example, computing system 3000 of FIG. 30) to complete basic operations on Data Object Titles and determining permitted operations under the Data Owner and Data Custodian of a Data Element. These flows will be re-used in later diagrams as subtasks.

[0063] FIG. 6 illustrates an operational flow / algorithmic structure 600 operating on the Product Lifecycle Information Storage System (410) to locate and verily the current Data Owner for a Data Element in accordance with some embodiments. This figure / descri ption will be reused in later operational flows whenever the Product Lifecycle Information Storage System 310 locates the current Data Owner for a Data Element.

[0064] In operation 601 , the Product Lifecycle Information Storage System 310 determines which Data Element is being requested and determines the DOT that corresponds to this Data Element. This may include a number of tasks that could be performed by the Product Lifecycle Information Storage System 310. For example, an address or other unique identifier within the Information Storage 320 may be supplied by the caller of the operational flow. Once the Data Element and the DOT for the Data Element have been located, in operation 602 the Product Lifecycle Information Storage System 310 may call the DOT System 330 to determine the current owner of the DOT for the given Data Element. As stated above in the discussion for FIG. 4, there are many options for the DOT System 330 to store and associate the current Data Owner with the Data Element. In operation 603, the Product Lifecycle Information Storage System 310 may contact the DOT Verifier 433 to verify the integrity of the DOT. If the integrity of the DOT is verified, operation 605 may include the Product Lifecycle Information Storage System 310 returning the information on the current Data Owner for the Data Element. If the integrity of the DOT is not verified, an error condition is returned to the caller.

[0065] FIG. 7 illustrates an operational flow / algorithmic structure 700 that may be used on the Data Owner Information System 350 role for determining whether a given request is permitted on a Data Element in accordance with some embodiments. This figure / description will be reused in in later operational flows whenever the Data Owner Information System 350 is called on to determine whether any operation is permitted on a Data Element.

[0066] In operation 701, the Data Owner Information System 350 receives a request to its Authorization Manager 452 to authorize a requested operation on a Data Element. Inoperation 702, the Authorization Manager 452 may attempt to determine if there are any open Data Custody relationships that it has issued on this Data Element. If, in operation 702. there are no existing Data Custody relationships, the Authorization Manager 452 may attempt to perform authentication of the Actor requesting access in operation 703. It may pass any authentication information that it has to the Authentication Manager 451 for verification. The Authentication Manager 451 may, in operation 705, use any of the common authentication systems to authenticate the Actor requesting access. This may include username and password, public key infrastructure tokens, or any form of identity federation. If operation 705 fails, the failure may be recorded to the Blockchain Management System 340 and the Data Owner Information System 450 responds to the request of operation 701 with an error. If the authentication of operation 705 succeeds, the Authorization Manager 452 may. in operation 706, identify the Actor requesting access and determine the access control list for the given Data Element. Any of the common forms of secure storage of access control lists may be used in the embodiment. In operation 707, the Authorization Manager 452 determines if the requested operation is permitted under the access control list for the Data Element and the Actor requesting the operation. If the operation is not permitted, the failure is recorded to the Blockchain Management System 340 and the Data Owner Information System 350 responds to the request of operation 701 with an error. If operation 707 succeeds, the Authorization Manager 452 may, in operation 709, create a record of the approval and call the Blockchain Management System 340 to record the approval. In operation 710, the Authorization Manager 452 responds to the request of operation 701 with success.

[0067] If, in operation 702, there exists an open Data Custody relationship created by this Data Owner on the given Data Element, the Data Owner Information System 350 performs operations 711 through 716 to process the Data Custody relationship. In operation 711, the Data Owner Information System 350 may determine if the requested operation permits a Data Custody relationship. Data Custody relationships may be limited for various reasons that are outside of the details of this embodiment; for example, the Data Owner may want to limit all Data Custody Relationships while it is processing on the Data Element. If the Data Custody relationship is currently permitted, the Authorization Manager 452. in operation 712, retrieves the Data Custody relationship information including the actor to which they have granted Data Custody. The Authorization Manager 452 may use any of a variety of storage mechanisms for the Data Custody relationships that it maintains in various embodiments. In one embodiment, it may store Data Custody relationship information on thedistributed blockchain and contact the Blockchain Management System 340 in order to retrieve the necessary information. In operation 713. the Authorization Manager 452 of the Data Owner Information System 350 calls the Authorization Manager 472 of the Data Custodian Information System 370 to process the authentication. This generates the operational flow described in FIG. 8 below for the Data Custodian Information System 370. Success may be determined at operation 713, resulting in one of three possible states. Positive failure to authenticate leads to recording the failure to the Blockchain Management System 340 and the Data Owner Information System 350 responds to the request of operation 701 with an error. Operation 713 may also result in the condition of “Unknown Actor.” As will be described in further detail herein, this may be generated by the Data Custody Information System 370 when the Data Custodian does not have a record of this Actor and has no permission information. In this case, even though there is an outstanding Data Custody operation, the Data Owner Information System 350 may complete the authorization of the Actor by jumping to operation 704 and completing the authorization as if there were no Data Custody relationships. This allows existing data access permissions from Actors that may not be known to the Data Custodian to continue to operate in the presence of a Data Custody relationship. If operation 713 succeeds, the Authorization Manager 452 of the Data Owner information System 350 may obtain the custody policy for the outstanding custody relationship. In operation 716, the custody policy may be consulted to determine whether the requested operation is valid under the Data Custodian Policy. The format of the Data Custodian Policy may vary by embodiment and may be a simple text or extensible markup language (XML) file containing rules, or may be a smart contract stored by the Blockchain Management System 340 along with the Data Custodian Policy. If the operation is permitted under the Data Custodian Policy, operation 716 succeeds and the flow continues at operation 708.

[0068] FIG. 8 illustrates an operational flow / algorithmic structure 800 that may be used on the Data Custodian Information System 350 for determining whether a given request is permitted on a Data Element in accordance with some embodiments. This figure / description may be reused in in later operational flows whenever a Data Custodian Information System 350 is called on to determine whether any operation is permitted on a Data Element.

[0069] This flow is similar to the operations defined for the Data Owner Information System 350 in FIG. 7 where the corresponding modules of the Data Custodian InformationSystem 370 take the role of the modules of the Data Owner Information System 350. Because of the repetition, the flow will not be looked at in depth, but only the differences will be highlighted here. The keys difference for the Data Custodian Information System 370 is at operation 805 during authentication of the Actor requesting access. For the Data Custodian, the result of the authentication operation may result in success, failure, or “Unknown Actor.” The “Unknown Actor” case allows the Data Custodian to signal to the caller that the Actor requesting access is not known to the Data Custodian and needs to be authenticated by the Data Owner Information System 350 or Data Custodian Information System 370 that initiated the request in operation 801. In operation 806, the Data Custodian Information System 370 responds with the “Unknown Actor” indication to the request.

[0070] All other aspects of the Data Custodian Information System 370 operations during permission verification may be similar to that described with respect to the Data Ow ner Information System 350. This allows there to be an arbitrarily long chain of Data Custody relationships that are processed during the authorization of a data access.

[0071] With the basic operations of finding the Data Owner and determining whether a given operation is permitted by the Data Owner and any existing Data Custodians, use cases can be shown for the elements of the system.

[0072] FIGs. 9 through 13 illustrate operation flows / algorithmic structures and signaling and operational diagrams that may be used to complete basic read / modify / write operations on a Data Element in accordance with some embodiments. FIG. 9 shows an operation flow / algorithmic structure 900 of the Data Accessor Information System 360 . FIG. 10 show s an operation flow / algorithmic structure 1000 of the Product Lifecycle Information Storage System 310. FIG. 11 shows an operation flow / algorithmic structure 1100 of the Data Owner Information System 350 . FIGs. 12 and 13 show signaling and operational diagrams 1200 and 1300, respectively, with respect to the elements described in FIGs. 9-11.

[0073] For this set of figures, many preconditions may be established. A Data Element may be stored in the Product Lifecy cle Information System, a DOT may be established for that Data Element, there may be a defined Data Owner of the DOT, and any- illustrated Data Custodian relationships may have been established.

[0074] FIG. 9 illustrates the operational flow / algorithmic structure 900 that may be used to perform the Data Accessor role in accordance with some embodiments. A Data Accessor may be performing a read or write operation on a Data Element (a modify operation is a read operation followed by a write operation). In operation 901. the Data AccessorInformation System 360 initiates the access request by using its Data Access Requestor module 461 to create a valid access request for a given Data Element. The protocol used and the format for the request may be any of a set of commonly available data exchange protocols and may depend on the individual Product Lifecycle Information Storage System 310 that will process the request or on the Data Element itself. The Data Accessor Information System 360 then sends this request to the Product Lifecycle Information System 310 for the given Data Element across the network that connects the devices. FIG. 10 shows the operations that occur on the Product Lifecycle Information System 310 to complete this request.

[0075] When the request is completed in operation 902, the Data Access Requestor module 461 will receive an indication of success or failure of the operation. If this is read operation, the Data Element may be included with the result of the request. If the Data Element is encrypted by the Data Owner, the address of the Data Owner’s Security Manager interface 455 will also be included. If the request was not successful at operation 903, error processing in operation 904 may occur. The steps of the error processing are unique to the needs of the application performing the data request. If the operation 903 was successful, one of two paths will be selected at operation 905. For a read operation, the Data Accessor’s system will determine if the data is encrypted by the Data Ow ner in operation 906, potentially from data returned in operation 902. If the Data Element is not encrypted the Data Accessor Information System 360 has successfully obtained the Data Element. If the Data Element is encrypted, the Data Decryption Manager (463) may call, in operation 908, the Data Owner Information System’s Security Manager module 455 for a decryption. If the call is determined to be successful at operation 910, the Data Accessor Information System 360 has successfully obtained the data.

[0076] A write operation is performed in a manner similar to the read operation. In operation 905, the Data Accessor Information System 360 may determine a write operation is being performed and the system may first check whether the data must be encrypted by the Data Owner at operation 907. If the data is to be encrypted, the Data Encryption Manager 462 calls the Data Owner Information System's Security Manager module 455 for an encryption. If the call is determined to be successful at operation 911. the Data Accessor Information System 460 has successfully obtained the encrypted data. If the data was not encrypted in operation 907, operation 909 is bypassed. Then, in operation 913 the Data Accessor Information System 360 writes the desired Data Element (encrypted or not) to the Product Lifecycle Information Storage System 310 Data Storage Manager 411.

[0077] FIG. 10 illustrates the operational flow / algorithmic structure 1000 that may be used to perform the Product Lifecycle Information Storage System 310 role for data access in accordance with some embodiments. In operation 1001, the Product Lifecycle Information Storage System 310 receives an access request for a Data Element from a Data Accessor Information System 360. This request was generated by the Data Accessor Information System 360 in operation 901 of FIG. 9. In operation 1002. the Product Lifecycle Information System 310 performs operational flow 600 of FIG. 6 in order to determine the current Data Owner of the DOT and the validity of the DOT. If this is not successful, an error is returned to the Data Accessor Information System 360 that initiated the request. If the DOT and current Data Owner are correctly located, the Authorization Manager 412 may determine the network address of the Current Data Owner and the address of its Authorization Manager 452. In operation 1004, the Authorization Manager 412 calls the Authentication Manager 452 of the Data Ow ner Information System 350 for the Data Element initiating flow 700 of FIG.7 to determine whether the data access is permitted. If operation 1004 returns an error, the Product Lifecycle Information Storage System 310 responds to the Data Accessor Information System 360 that initiated the request with the corresponding error. If operation 1004 succeeds, in operation 1005 the Authorization Manager 412 receives the permission and may retrieve the data from the Data Storage Manager 411 in the case of a read operation. It then responds to the Data Accessor Information System 360 that initiated the request including the data if applicable. For a write operation, in 1006, the Product Lifecycle Information Storage System 310 waits for the Data Accessor Information System 360 to supply the information to write. Since an arbitrary7period of time may have elapsed, in operation 1007. the Data Storage Manager 411 validates that the write request has been authorized by the Data Owner for the Data Element. There are a number of ways this can be accomplished. For instance, the Blockchain Management System 340 may be consulted to find a record of the approval, or the Data Accessor Information System 360 may include information from the Data Owner Information System 350 representing its approval. If authorized, the Data Storage Manager 411 carries out the write operation to the Information Storage System 320 in operation 1008.

[0078] FIG. 11 shows the operational flow / algorithmic structure 1100 that may be used to perform the Data Owner Information System 350 role for data access to an encrypted Data Element in accordance with some embodiments. Flow 700 of FIG. 7 shows the operational on the Data Owner Information System (450) for determining whether a givenoperation is permitted. This is used by the Product Lifecycle Information Storage System (410) in operation 1004 of flow 1000 in FIG. 10. FIG. 11 is reserved for those operations on the Data Owner Information System 350 when the Data Accessor Information System 360 determines in operations 906 or 907 of flow 900 of FIG. 9 that the data that it wants to read or write is encry pted.

[0079] The flow is initiated in operation 1101 when the Security Manager module 455 of the Data Owner Information System 350 receives a request from the Data Accessor Information System 360 for an encryption or a decryption of a Data Element. In operation 1102, the Security Manager module 455 may determine that the request corresponds to a previously authorization operation on the Data Element by the calling Data Accessor. The Security Manager module 455 may use any mechanism to determine whether the operation has been authorized. It may have internal history of past authorizations or it may contact the Blockchain Management System 340 to find the correct authorization. If no record of a valid authorization is found, the failure may be recorded to the Blockchain Management System 340 and the Data Owner Information System 350 responds to the request in operation 1105 with an error. If operation 1102 succeeds, the Security Manager module 455 of the Data Owner Information System 350 may, in operation 1104, determine the key necessary- for the requested cry ptographic operation and perform the requested operation on the Data Element. Any of the common cry ptographic operations and key storage mechanisms may be supported by various embodiments.

[0080] FIGs. 12 and 13 illustrates signaling and operational diagrams 1200 and 1300, respectively, that may be used to complete the data access operation in accordance yvith some embodiments. The scenario shown is for a Data Owner to have granted a Data Custody relationship with one Data Custodian yvho has then created a Data Custody relationship with a second Data Custodian.

[0081] FIG. 12 starts with the Data Accessor Information System 360 formatting a Data Access request and sending it to the Product Lifecycle Information Storage System 310 as in operation 901 of FIG. 9. The Product Lifecycle Information Storage System 310 then completes operations 1002 of FIG. 10. which involves completing the flow 600 of FIG. 6 to obtain and validate the DOT for the Data Element that is requested. The Product Lifecycle Information System 310 may then complete operation 1003 of FIG. 10 to determine the current Data Owner for the Data Element. The Product Lifecycle Information Storage System 310 may then send an authorize request to the Data Owner Information System 350 as inoperation 1004 of FIG. 10. The Data Owner Information System 350 in this scenario performs operations 702 and 703 of FIG. 7 as part of the permission determination flow and determines that there is an open Data Custody relationship for this Data Element. The Data Owner Information System 350 may then perform operation 712 of FIG. 7 in order to obtain the Data Custodian for this Data Element. The Data Owner Information System 350 then generates an authorization request as per operation 713 of FIG. 7. The Data Custodian Information System 370 receives the request and may perform operations 802 and 803 of FIG. 8 and determines that it has granted an open Data Custody relationship for this Data Element. The Data Custodian Information System 370 may then perform operation 812 of FIG. 8 in order to obtain the Data Custodian for this Data Element. The Data Custodian Information System 370 then generates an authorization request as per operation 814 of FIG. 8. The receiving Data Custodian Information System 370 may then perform operations 802 and 803 of FIG. 8 and determines that it has not granted an open Data Custody relationship for this Data Element. The receiving Data Custodian Information System 370 then maycomplete operations 804 and 805 and, in this scenario, determines that the Data Accessor is not an Actor which it recognizes. It then returns '‘Unknown Actor’’ to the calling Data Custodian Information System 370 which may jump to operations 804 and 805 of FIG. 8 to attempt an authentication itself. In the scenario shown, the authentication succeeds and the Data Custodian Information System 370 proceeds to operations 807 and 808 of FIG. 8 to determine whether the Data Accessor is permitted the access under the access control system of the Data Custodian Information System 370. In the given scenario it returns success to the Data Owner Information System 350, which then performs operation 716 and 717 of FIG. 7 to determine whether the operation is permitted under the Data Custody relationship. In the scenario, this succeeds and the Data Owner Information System 350 responds to the Product Lifecycle Information System 310 with success. The Product Lifecycle Information System 310 may then complete operation 1005 of FIG. 5 to complete the operation and send the result of the request to the Data Accessor Information System 360

[0082] FIG. 13 illustrates the signaling and operational diagram 1300 that may be used to complete access to the Data Element in the presence of encrypted data in accordance with some embodiments. The Data Assessor Information System 360 initiates the process by completing operation 905 of FIG. 9. If this is a read operation, the Data Assessor Information System 360 completes operation 906 of FIG. 9 to determine if the data is encrypted. If it is. the Data Assessor Information System 360 sends a decryption request as per operation 908 ofFIG. 9 to the Data Owner Information System 350. The Data Owner Information System 350 may then complete operations 1101, 1102 and 1104 of FIG. 11 to determine that the decryption request is valid, to obtain the key, and to decrypt the data, which it returns to the Data Assessor Information System 360. If this is a write operation, the Data Assessor Information System 360 determines whether it requires encryption in operation 907 of FIG. 9. If it does, the Data Assessor Information System 360 sends an encryption request as per operation 909 of FIG. 6 to the Data Owner Information System 350. The Data Owner Information System 350 may then complete operations 1101, 1102 and 1104 of FIG. 11 to determine that the encryption request is valid, to obtain the key, and to encrypt the data, which it returns to the Data Assessor Information System 360. The Data Assessor Information System 360 then completes operation 913 to write the Data Element to the Product Lifecycle Information Storage System 310. The Product Lifecycle Information Storage System 310 completes operations 1006, 1007, and 1008 of FIG. 10 to determine that this write operation has been authorized and writes the data to the Information Storage 320.

[0083] FIG. 14 illustrates an operational flow / algorithmic structure 1400 that may be used by the Product Lifecycle Information Storage System 310 to create a new Data Element in accordance with some embodiments. This operation may be initiated by any Actor in the system and the Data Element may represent any information that the Actor wants to store and may contain a combination of structured and unstructured data.

[0084] This flow / structure 1400 begins at operation 1401 where the Product Lifecycle Information Storage System 310 receives a request to create a new Data Element. A variety of verification mechanisms may be used in this communication to ensure that the Actor is the actor represented by the given actor ID and is authorized to create Data Elements in the group, such as digital signatures based on certificates issued by a trusted certification authority. The verification operation is intended to represent basic functionality and does not constrain details of a specific embodiment. In operation 1402, the Data Storage Manager 411 creates and reserv es the storage space required for the requested Data Element. The storage resides in the abstract Information Storage 320 of FIG. 3. In operation 1403, the Data Storage Manager 411 calls the DOT Minter 431 of the Data Object Title System 330 in order to create a DOT representing the new Data Element. It supplies the Data Element ID, which uniquely specifies the Data Element in the Data Storage Manager 411. Optionally it supplies the other fields of the DOT as specified in FIG. 5. The DOT Minter 431 creates the necessary DOT and returns it to the Data Storage Manager 411. In operation 1404, the Data StorageManager 411 initiates the flow 1600 of FIG. 16 with the Data Object Title System 330 in order to transfer the ownership of the DOT to the Actor who is creating the Data Element. In operation 1405, the Data Storage Manager 411 associates the given DOT ID with the storage location reserved in operation 1402. In operation 1406, the Data Storage Manager 411 may record the create operation on the blockchain that is used to maintain a record of actions associated with this Data Storage Manager 411.

[0085] FIGs. 15 and 16 represent operational flows / algorithmic structures 1500 and 1600, respectively, which may be used for transferring the ownership of a Data Element from one Actor to another in accordance with some embodiments.

[0086] FIG. 15 illustrates the operational flow / algorithmic structure 1500 that may be used by the Product Lifecycle Information Storage System 310 to transfer the Data Owner relationship for a given Data Element from one Actor to another in accordance with some embodiments. The flow begins at operation 1501 where the Product Lifecycle Information Storage System 310 receives a request to transfer ownership of a Data Element. The request may include the new Data Owner's ID and authentication information. In operation 1502. the Data Storage Manager 411 completes operation 600 of FIG. 6 to determine the Data Owner for the given Data Element. When the Data Owner has been identified, the Data Storage Manager 411 may, in operation 1503, initiate the transfer of the DOT for the Data Element by calling the DOT Transfer Manager 432 to complete flow 1600 of FIG. 16. Upon completion, at operation 1504 the Data Storage Manager 411 determines whether the transfer operation succeeded and, if not, responds to the request with an error in operation 1510. In operation 1505, the Data Storage Manager 411 determines if the Data Element is nowrencr pted and whether the new Data Owner desires to store encry pted data in the Data Element. If it is currently encrypted, operation 1506 returns the encrypted value to the requestor who started the operation in 1501. The requestor may then initiate flow 1100 of FIG. 11 with the old Data Owner to obtain a decrypted version of the data and re-encrypt that data if it so chooses. In operation 1507, the Product Lifecycle Information Storage System 310 waits for the requestor Data Accessor Information System 360 to supply the information to write into the Data Element. In operation 1508, the Data Storage Manager 411 receives the new data and validates that the change of ownership has been authorized by the Data Owner in operation 1503. There may be various methods on how it stores and accesses this information that are not meant to constrain the embodiment. The status of operation 1503 may be pushed into an internal queue of pending transfers or it may be recorded to the Blockchain ManagementSystem 340. If the operation has been authorized, the Data Storage Manager carries out the write operation into the Information Storage System 320 with the Data Element from the new Data Owner.

[0087] FIG. 16 illustrates the operational flow / algorithmic structure 1600 that may be used to transfer a DOT from one Actor to another in accordance with some embodiments. The flow defines the operations of the Data Object Title System 330 in performing the transfer of the DOT. It begins at 1601 where the DOT Transfer Manager 432 receives a request to transfer the ownership of the DOT. The request may contain the current Data Owner's ID and the new Data Owner's ID along with authentication information for the Actor performing the request. In operation 1602, the DOT Transfer Manager 432 looks up the DOT and the cunent owner of the DOT from internal or external data structures. The structures used to perform this operation may be internal to the DOT or may include centralized or distributed databases or a distributed ledger such as a blockchain. The structures may also include ownership of a separate data entity such as, for example, an NFT. The data structures used to record the DOT are intended as basic functionality and do not constrain the embodiments. In operation 1603, the DOT Transfer Manager 432 determines w hether there is an existing owner for this DOT. The case of no existing owner may occur if the Data Element corresponding to the DOT is in the process of being created in flow 1500 above. If there is a current owner, in operation 1604, the DOT Transfer Manager 432 initiates flow 700 of FIG. 7 to determine if the transfer of ownership is permitted by the current Data Owner. Provided that successful permission has been obtained, the DOT Transfer Manager 432 may, in operation 1606, complete the necessary operations to transfer ownership of the DOT to the new- Data Owner. These operations may depend on the form of the DOT and how it is stored. For internally stored objects, a simple record in a table may be changed, for blockchain operations or NFT representations of the DOT, the DOT Transfer Manager 432 carries out the necessary operation on the given blockchain to enact the transfer of the DOT. In the final step, the DOT Transfer Manager 432 may, in operation 1607, record the transfer of ownership with the Blockchain Management System 340 in order to create a permanent and immutable record of the transfer.

[0088] FIG. 17 illustrates a signaling and operational diagram that may be used to transfer ownership from one Data Owner to another in accordance with some embodiments. There are a number of possible flows through the system that can occur, with various error conditions encountered. The scenario shown is for transfer of ownership for an encryptedData Element. It begins when a Data Accessor Information System 360 initiates an ownership transfer to a Product Lifecycle Information Storage System 310. This initiates flow 1500 on the Product Lifecycle Information Storage System 310. At the beginning of this flow the Product Lifecycle Information Storage System 310 initiates flow 600 with the Data Object Title Sy stem 330 to obtain the DOT for the Data Element. The Product Lifecycle Information Storage System 310 then initiates a Transfer Ownership request 1503 with the Data Object Title System 330. The Data Object Title System 330 then initiates flow 1600 to perform the transfer operation. It determines whether there is a current Data Owner. In the case provided there is a current Data Owner and the Data Object Title System 330 initiates an Authorize Request with the Data Owner Information System 350. The Data Owner Information System 350 then initiates flow 700 of FIG. 7 to determine whether the operation is permitted or not. If the operation is permitted, the Data Owner Information System 350 provides a success indication to the Data Object Title System 330, which then continues flow 1600 with operations 1606 and 1607 to complete the transfer of the DOT. The Data Object Title System 330 then returns success to the Product Lifecycle Information Storage System 310, which continues flow 1500. The Product Lifecycle Information Storage System 310 determines in this scenario that the data element is encrypted. It returns the request in step 1507 and waits for the Data Accessor Information System 360 to write an encry pted result. The Data Accessor Information System 360 calls the original Data Owner Information System 350 to initiate flow 1100 of FIG. 11 to decrypt the Data Element. The Data Owner Information System 350 then returns the decrypted result to the Data Accessor Information System 360. The Data Accessor Information System 360 then may encry pt the Data Element and write it to the Product Lifecycle Information Storage System 310 to continue flow- 1500 of FIG. 15. The Product Lifecycle Information Storage System 310 validates that the operation is permitted in step 1508 and writes the Data Element to the Information Storage System 320 in step 1509. It then returns a success code in a response, completing the flow .

[0089] The remainder of the operational flow s / diagrams (FIGs. 18-29) are presented in groups of four to show one embodiment of the flows for the use cases of permission changes, the creation of Data Custody relationships, and the deletion of Data Custody relationships. In particular, FIGs. 18-21 correspond to permission changes, FIGs. 22-25 correspond to creation of a Data Custody Relationship, FIGs. 26-29 correspond to deletion of a Data Custody Relationship.

[0090] FIG. 18 illustrates an operational flow / algorithmic structure 1800 that may be used by the Product Lifecycle Information Storage System 310 to initiate a change of permissions for a given Data Element. In operation 1801, the Product Lifecycle Information Storage System 310 receives a request for permission changes on a Data Element that it stores. This request contains all of the necessary authentication and permission information to complete the rest of the data flow. In operation 1802, the Product Lifecycle Information Storage System 310 may contact the Data Object Title System 330 to complete flow 600 of FIG. 6 to determine the current owner of the DOT and verify the correctness of the DOT. If successful, the Product Lifecycle Information Storage System 310 then proceeds to operation 1804 where it may look up the Data Owner Information System 350 from the DOT. In operation 1805. the Product Lifecycle Information Storage System 310 calls the Authentication Manager 452 of the Data Owner Information System 350 to initiate the flow 1900 of FIG. 19 to complete the permission change operation. If operation 1805 succeeds, in operation 1807 the Product Lifecycle Information Storage System 310 responds to the requestor with success and completes the operational flow.

[0091] FIG. 19 illustrates an operational flow / algorithmic structure 1900 that may be used by the Data Owner Information System 350 in order to affect a permission change on a Data Element. The flow begins in operation 1901 where the Data Owner Information System 350 receives a request for a change of permissions to a given Data Element. This request must include all information necessary for the operation including the ID of the Data Element, the authentication information of the requestor as well as additional information. In operation 1902, the Data Owner Information System 350 determines whether the request is being made for this Actor or a different one. The request may be for a different actor if this request is under a Data Custodian Policy supported by this Data Owner. In the case where the Data Owner is the Actor that is being requested, the Authorization Manager 452 authenticates the Actor initiating the request in operations 1903 and 1904. If the authentication is determined to be successful at operation 1905, the Data Owner Information System 350 may determine whether the permission change is allowed under existing rights in operation 1906. If it is allowed, the Authorization Manager 452 makes the necessary changes to the requestor’s permissions in operation 1907. These permissions may be stored in various manners in different embodiments. Some embodiments will store the permissions locally in an internal data structure of the Authorization Manager 452 while others may record the permissions on the external blockchain via the Blockchain Management System 340. TheData Owner Information System 350 completes this request by making a record of the permission changes to the Blockchain Management System 340 in order to have an immutable record of operations on the system.

[0092] If, in operation 1902, the Data Owner Information System 350 finds that it is not the Actor that is being requested for the permission changes, the Authorization Manager 452 may look up any outstanding Data Custody relationships that exist for this Data Element in operation 1909. If a Data Custody operation is found at operation 1910, the Data Owner Information System 350 may determine whether the operation is permitted under the custody policy at operation 1911. For example, the Data Custodian Policy may define that write permissions are not allowed under the contract. The Data Owner Information System 350 would then fail the operation at this point and return an error. If the requested permissions are allowed under the Data Custodian Policy, the Authorization Manager 452 then may determine the network interfaces of the Data Custodian Information System 370 to which it has granted custody. There are many possible storage locations that are allowed under various embodiments. In some systems the Data Owner Information System 350 may store the Data Custody relationships in internal data structures or it may store them externally in the Blockchain Management System 340. In operation 1913, the Authorization Manager 452 may complete the flow by calling the Data Custodian Information System 370 with the permission change request and initiating operation 2000 of FIG. 20.

[0093] FIG. 20 illustrates an operational flow / algorithmic structure 2000 that may be used by the Data Custodian Information System 370 to affect a permission change on a Data Element. The flow shown in FIG. 20 is identical to the operations of FIG. 19 for the Data Owner Information System 350 with the Actor being changed to the Data Custodian Information System 370 and modules therein. This allows an arbitrary’ long chain of Data Custody relationships to be navigated until the correct Actor is identified which stores the permissions that are required to be changed.

[0094] FIG. 21 illustrates a signaling and operational diagram that may be used to affect a permission change on a given Data Element. There are a wide variety of operational paths that may be taken across the system depending on the number of Data Custody operations that are outstanding and the error conditions that may be encountered during the flow. FIG. 21 shows a single scenario where a Data Owner has granted Data Custody to a Data Custodian and the request for the permission change is to the Data Custodian. The flow begins by the Data Accessor Information System 360 initiating a Permission Change Requestto the Product Lifecycle Information Storage System 310. This initiates flow 1800 of FIG. 18 on the Product Lifecycle Information Storage System 310. It receives the request in operation 1801 and then performs flow 600 of FIG. 6 on the Data Object Title System 330 to obtain and validate the DOT for the given Data Element. The Product Lifecycle Information Storage System 310 then initiates flow 1900 on the Data Owner Information System 350 by sending a permission change request. In the scenario the Data Owner Information System 350 receives the request at operation 1901, determines that it is not the Actor that is being requested, looks up the Data Custody relationship and determines that the change request is permitted under the Data Custody Relationship, operation 1910 and generates a permission change request to the Data Custodian Information System 370. The Data Custodian Information System 370 receives the permission change request in operation 2001. and determines that the request is indeed for this Actor. The Data Custodian Information System 370 then authenticates the Actor initiating the request and determines whether the permission change is allowed in operation 2006. If it is allowed, the Data Custodian Information System 370 makes the necessary changes to the requestor’s rights in operation 2007, records the operation on the blockchain in operation 2008, and returns an indication of success, which completes Flow 2000. Flow 1900 is completed by the Data Owner Information System 350 reporting success to the Product Lifecycle Information Storage System 310 which completes flow 1800 by responding with success to the Data Accessor Information System 360 that initiated the action.

[0095] FIG. 22 begins the set of figures that show one embodiment for the Actors involved in the creation of a Data Custody relationship. FIG. 22 illustrates an operational flow / algorithmic structure 2200 that may be used by the Product Lifecycle Information Storage System 310 to create a Data Custody relationship for a given Data Element in accordance with some embodiments. This flow is identical to Flow 1800 of FIG. 18 except in the types of information requests and the flows that are triggered in other actors. In operation 2201, the Product Lifecycle Information Storage System 310 receives a request for a Data Custody relationship on a Data Element that it stores. This request contains all of the necessary authentication and permission information to complete the rest of the data flow. In operation 2202, the Product Lifecycle Information Storage System 310 may contact the Data Object Title System 330 to complete flow 600 of FIG. 6 to determine the current owner of the DOT and verity' the correctness of the DOT. If successful, the Product Lifecycle Information Storage System 310 then proceeds to operation 2204 where it may look up the Data OwnerInformation System 350 from the DOT. In operation 2205, the Product Lifecycle Information Storage System 310 calls the Authentication Manager 452 of the Data Owner Information System 350 to initiate the flow 2300 of FIG. 23 to complete the creation of the Data Custody relationship. If operation 2205 succeeds, in operation 2207 the Product Lifecycle Information Storage System 310 responds to the requestor with success and completes the operational flow.

[0096] FIG. 23 illustrates an operational flow / algorithmic structure 2300 that may be used by the Data Owner Information System 350 in order to create a Data Custody relationship on a Data Element in accordance with some embodiments. The flow begins in operation 2301 where the Data Owner Information System 350 receives a request for a Data Custody relationship on a given Data Element. This request must include all information necessary for the operation including the ID of the Data Element, the authentication information of the requestor as well as additional information. In operation 2302, the Data Owner Information System 350 determines whether the request is being made for this Actor or a different one. The request may be for a different actor if this request is under a Data Custody relationship supported by this Data Owner. In the case where the Data Owner is the Actor that is being requested, the Authorization Manager 452 authenticates the Actor initiating the request in operations 2303 and 2304. If the authentication is determined to be successful at operation 2305, the Data Owner Information System 350 may determine whether the permission change is allowed under existing rights in operation 2306. If it is allowed, the Authorization Manager 452 looks up any existing Data Custody relationships that may exist for this data element in operation 2307. These relationships may be stored in various manners in different embodiments. Some embodiments will store the relationships locally in an internal data structure of the Authorization Manager 452 while others may record the relationships on the external blockchain via the Blockchain Management System 340. In this embodiment, if an existing Data Custody relationship is found, the request to create another generates an error; other embodiments may allow' multiple Data Custody relationships to exist from the same data owner. The Data Owner Information System 350 completes this request by making a record of the Data Custody relationship creation to the Blockchain Management System 340 in order to have an immutable record of operations on the system.

[0097] If in operation 2302, the Data Owner Information System 350 finds that it is not the Actor that is being requested for the Data Custody creation, the AuthorizationManager 452 may look up any outstanding Data Custody relationships that exist for this Data Element in operation 2310. There are many possible storage locations that are allowed under various embodiments. In some systems the Data Owner Information System 350 may store the Data Custody relationships in internal data structures or it may store them externally in the Blockchain Management System 340. If a Data Custody operation is found in operation 2311, the Data Owner Information System 350 may determine whether the operation is permitted under the custody policy in operation 2312. For example, the Data Custodian Policy may define that data custody relationships are not allowed for a sensitive Data Element. The Data Owner Information System 350 would then fail the operation at this point and return an error. If the requested operation is allowed under the Data Custodian Policy, the Authorization Manager 452 then may determine the network interfaces of the Data Custodian Information System 370 to which it has granted custody in operation 2313. In operation 2314, the Authorization Manager 452 may complete the flow by calling the Data Custodian Information System 370 with the Data Custody creation request and initiating operation 2400 of FIG. 24.

[0098] FIG. 24 illustrates an operational flow / algorithmic structure 2000 that may be used by the Data Custodian Information System 370 in order to affect the creation of a Data Custody relationship on a Data Element in accordance w ith some embodiments. The flow' shown in FIG. 24 is identical to the operations of FIG. 23 for the Data Owner Information System 350 with the Actor being changed to the Data Custodian Information System 370 and modules therein. This allows an arbitrary long chain of Data Custody relationships to be navigated until the correct Actor is identified wfiich creates and stores the Data Custody relationship that is requested.

[0099] FIG. 25 illustrates a signaling and operational diagram that may be used to affect the creation of a Data Custody relationship on a given Data Element in accordance w ith some embodiments. There are a wide variety of operational paths that may be taken across the system depending on the number of Data Custody operations that are outstanding and the error conditions that may be encountered during the flow. FIG. 25 shows a single scenario where a Data Owner has granted Data Custody to a Data Custodian and the request for the creation of another Data Custody relationship is to the Data Custodian. The flow begins by a Data Accessor Information System 360 initiating a create Data Custody relationship request to a Product Lifecycle Information Storage System 310. This initiates flow 2200 of FIG. 22 on the Product Lifecycle Information Storage System 310. It receivesthe request in operation 2201 and then performs flow 600 of FIG. 6 on the Data Object Title System 330 to obtain and validate the DOT for the given Data Element. The Product Lifecycle Information Storage System 310 then initiates flow 2300 on the Data Owner Information System 350 by sending a Data Custody Creation request. In this scenario, the Data Owner Information System 350 receives the request at operation 2301, determines that it is not the Actor that is being requested at 2302, looks up the Data Custody relationship at 2310 and 231 1. determines that the change request is permitted under the Data Custody Relationship at 2312, determines network interfaces at 2313, and generates a Data Custody creation request to the Data Custodian Information System 370 at 2314. The Data Custodian Information System 370 receives the Data Custody creation request in operation 2401, and determines that the request is indeed for this Actor. The Data Custodian Information System 370 then authenticates the Actor initiating the request and determines whether the Data Custody creation is allowed in operation 2406. If it is allowed, the Data Custodian Information System 370 looks up any existing Data Custody relationships for this Data Element in operation 2407. In this scenario, it finds that there are no existing Data Custody relationships, so it creates the necessary Data Custody relationship in operation 2409, records the operation on the blockchain, and returns success which completes Flow 2400. Flow- 2300 is completed by the Data Owner Information System 350 reporting success to the Product Lifecycle Information Storage System 310, which completes flow 2200 by responding with success to the Data Accessor Information System 360. which initiated the action.

[0100] FIG. 26 begins the set of figures that show one embodiment for the Actors involved in the deletion of a Data Custody relationship. FIG. 26 illustrates an operational flow7algorithmic structure 2600 that may be used within a computing system (3000 of FIG. 30) representing a Product Lifecycle Information Storage System 310 to delete a Data Custody relationship for a given Data Element. This flow is identical to Flow 1800 of FIG. 18 except in the types of information requests and the flow s that are triggered in other Actors. In operation 2601, the Product Lifecycle Information Storage System 310 receives a request for the deletion of a Data Custody relationship on a Data Element which it stores. This request contains all of the necessary authentication and permission information to complete the rest of the data flow. In operation 2602 the Product Lifecycle Information Storage System 310 may contact the Data Object Title System 330 to complete flow7600 of FIG. 6 to determine the current owner of the DOT and verify the correctness of the DOT. If successful, the Product Lifecycle Information Storage System 310 may then proceed to operation 2604where it may look up the Data Owner Information System 350 from the DOT. In operation 2605. the Product Lifecycle Information Storage System 310 calls the Authentication Manager (452) of the Data Owner Information System 350 to initiate the flow 2700 of FIG. 27 to complete the deletion of the Data Custody relationship. If operation 2605 succeeds, in operation 2607 the Product Lifecycle Information Storage System 310 responds to the requestor with success and completes the operational flow.

[0101] FIG. 27 illustrates an operational flow / algorithmic structure 2700 that may be used by the Data Owner Information System 350 in order to delete a Data Custody relationship on a Data Element in accordance with some embodiments. The flow begins in operation 2701 where the Data Owner Information System 350 receives a request for the deletion of a Data Custody relationship on a given Data Element. This request must include all information necessary for the operation including the ID of the Data Element, the authentication information of the requestor as well as additional information. In operation 2702, the Data Owner Information System 350 determines whether the request is being made for this Actor or a different one. The request may be for a different actor if this request is under a Data Custody relationship supported by this Data Owner. In the case where the Data Owner is the Actor that is being requested, the Authorization Manager (452) authenticates the Actor initiating the request in operations 2703 and 2704. If the authentication is determined to be successful at operation 2705, the Data Owner Information System 350 may determine whether there are any existing Data Custody relationships on the Data element in operation 2706. These relationships may be stored in various manners in different embodiments. Some embodiments will store the relationships locally in an internal data structure of the Authorization Manager 452 while others may record the relationships on the external blockchain via the Blockchain Management System 340. In this embodiment, if an existing Data Custody relationship is found, in operation 2708, the Data Owner Information System 350 checks that the Actor requesting the delete is the Actor that is the Data Custodian in the relationship. If it is the Data Custodian, in operation 2709, the Data Owner Information System 350 completes this request by deleting the record of the Data Custody relationship and records the operation to the Blockchain Management System 340 in order to have an immutable record of operations on the system.

[0102] If, in operation 2702, the Data Owner Information System 350 finds that it is not the Actor that is being requested for the delete operation; the Authorization Manager (452) may look up any outstanding Data Custody relationships that exist for this DataElement in operation 2710. There are many possible storage locations that are allowed under various embodiments. In some systems the Data Owner Information System 350 may store the Data Custody relationships in internal data structures or it may store them externally in the Blockchain Management System 340. If a Data Custody operation is found in operation 2711, the Authorization Manager 452 then may determine the network interfaces of the Data Custodian Information System 370 to which it has granted custody in operation 2713. In operation 2714. the Authorization Manager 452 may complete the flow by calling the Data Custodian Information System 370 with the Data Custody creation request and initiating operation 2800 of FIG. 28.

[0103] FIG. 28 illustrates an operational flow / algorithmic structure 2800 that may be used by the Data Custodian Information System 370 in order to affect the deletion of a Data Custody relationship on a Data Element in accordance with some embodiments. The flow show n in FIG. 28 is identical to the operations of FIG. 27 for the Data Owner Information System 350 with the Actor being changed to the Data Custodian Information System 370 and modules therein. This allows an arbitrary’ long chain of Data Custody relationships to be navigated until the correct Actor is identified which creates and stores the Data Custody relationship that is requested.

[0104] FIG. 29 illustrates a signaling and operational diagram that may be used to affect the deletion of a Data Custody relationship on a given Data Element in accordance with some embodiments. There are a wide variety of operational paths that may be taken across the system depending on the number of Data Custody operations that are outstanding and the error conditions that may be encountered during the flowy FIG. 29 show s a single scenario where a Data Owner has granted Data Custody to a Data Custodian and the request for the deletion is for a Data Custody relationship that the Data Custodian has granted. The flow begins by the Data Accessor Information System 360 initiating a delete Data Custody relationship request to the Product Lifecycle Information Storage System 310. This initiates flow' 2600 of FIG. 26 on the Product Lifecycle Information Storage System 310. It receives the request in operation 2601 and then performs flow 600 of FIG. 6 on the Data Object Title System 330 to obtain and validate the DOT for the given Data Element. The Product Lifecycle Information Storage System 310 then completes operation 2604 and initiates flow 2700 on the Data Owner Information System 350 by sending a Data Custody deletion request. In this scenario, the Data Owner Information System 350 receives the request at operation 2701. determines that it is not the Actor that is being requested at 2702. and looksup any outstanding Data Custody relationships at operation 2710. It finds an existing relationship and looks up the network interfaces of the Data Custodian Information System 370 for the Data Custody relationship in operation 2712. It generates a Data Custody deletion request to the Data Custodian Information System 370, which initiates flow 2800 of FIG. 28. The Data Custodian Information System 370 receives the Data Custody deletion request in operation 2801. and determines that the request is indeed for this Actor (operations 2801 and 2802). The Data Custodian Information System 370 then authenticates the Actor initiating the request in operations 2803 and 2804. If successful, in operation 2806 it looks up any existing Data Custody relationships for this Data Element. In this scenario, it finds an existing Data Custody relationship in operation 2807 and finds that the Actor requesting the delete is the Actor to which it has granted custody in operation 2808. The Data Custodian Information System 370 then completes operation 2809 to record the operation to the blockchain and returns success which completes Flow 2800. Flow 2700 is completed by the Data Owner Information System 350 reporting success to the Product Lifecycle Information Storage System 310 which completes flow 2200 by responding with success to the Data Accessor Information System 360 which initiated the action.

[0105] FIG. 30 illustrates a device 3000 in accordance with some embodiments. The device 3000 may implement one or more of the Data Accessor Information System 360, the Data Owner Information System 350, the Data Custodian Information System 370, the Product Lifecycle Information Storage System 310 or the Data Object Title System 330.

[0106] The device 3000 may include processors 3001 , memory / storage circuitry 3002, a user interface 3003, a network interface 3004, and sensors 3005. The components of the device 3000 may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 30 is intended to show a high-level view of some of the components of the device 3000. However, some of the components show n may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

[0107] The components of the device 3000 may be coupled with various other components over one or more interconnects 3006, which may represent any type of interface, input / output, bus (local, system, or expansion), transmission line, trace, optical connection, etc. that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0108] The processors 3001 may include processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 3002 to cause the device 3000 to perform operations as described herein. For example, in some embodiments, the processors 3001 may access information system code 3007 stored in the memory / storage 3002. Upon executing the information system code 3007 the device 3000 may manage (including generating, accessing, storing, etc.) product lifecycle data 3008 as described herein.

[0109] The memory / storage 3002 may include any type of volatile or non-volatile memory that may be distributed throughout the device 3000. In some embodiments, some of the memory / storage 3002 may be located on the processors 3001 themselves (for example, LI and L2 cache), while other memory / storage 3002 is external to the processors 3001 but accessible thereto via a memory interface, which may be part of I / O interface 3004. The memory / storage 3002 may include any suitable volatile or non-volatile memory' such as, but not limited to, dynamic random access memory' (DRAM), static random access memory' (SRAM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), Flash memory, solid-state memory, or any other type of memory' device technology'.

[0110] The user interface 3003 includes various input / output (I / O) devices designed to enable user interaction with the device 3000. The user interface 3003 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button), a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry' includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position(s), or other like information. Output device circuitry may include any' number or combinations of audio or visual display, including, inter aha, one or more simple visual outputs / indicators (for example, binary' status indicators such as light emitting diodes (LEDs) and multi -character visual outputs, or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.), with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the device 3000.[OHl] The sensors 3005 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensordata) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units comprising accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems comprising 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (for example, thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (for example, cameras or lensless apertures); light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like), depth sensors, ambient light sensors, ultrasonic transceivers; microphones or other like audio capture devices; etc.

[0112] The network interface 3004 may be any type of wired / wireless network interface capable of facilitating communication with databases and other systems (including other computing information systems, OSM systems, or legacy systems).

[0113] Any of the above-described examples may be combined with any other example (or combination of examples), unless explicitly stated otherw ise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0114] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

[0115] EXAMPLES

[0116] Some non-limiting examples are provided herein.

[0117] Example 1 includes a method comprising: generating, based on a user request, a Data Element stored within a storage system for a Data Element of information about a product; identifying the Data Owner of said Data Element through a data structure representing the title to the Data Element; and obtaining authorization from the Data Owner for each operation on the Data Element.

[0118] Example 2 includes the method of example 1 or some other example herein, further comprising: transferring the Data Owner role between Actors by transferring ownership of the given title structure.

[0119] Example 3 includes the method of example 1 or some other example herein, further comprising: storing the data in an encry pted fashion with the current Data Owner retaining keys to the encryption.

[0120] Example 4 includes the method of example 1 or some other example herein further comprising verifying data operations (read, modify', write) by contacting the current Data Owner in order to authorize the operation. Example 5 includes a method comprising: generating, based on a user request, a Data Custody relationship between the grantor and grantee within a storage system for a Data Element of information about a product; identify ing the Data Custodian for a Data Element through a Data Custody data structure representing the relationship; and obtaining authorization from the Data Custody grantee for each operation on the Data Element.

[0121] Example 6 includes the method of example 5 or some other example herein further comprising consulting the Data Custodian Policy as an additional factor in determining if the operation is authorized

[0122] Example 7 includes the method of example 5 or some other example herein further comprising consulting the Data Ow ner as an additional factor in determining if the operation is authorized.

[0123] Example 8 includes a method comprising: creating a unique Data Element on a storage system for information about a product; creating a Data Object Title (DOT) data structure for the given Data Element; and assigning ownership of the DOT to the entity that created the Data Element.

[0124] Example 9 includes the method of example 8 or some other example herein, wherein the ownership of the Data Object Title (DOT) is maintained within the structure.

[0125] Example 10 includes the method of example 8 or some other example herein, wherein the ownership of the Data Object Title (DOT) is maintained through a record on a distributed blockchain within the system.

[0126] Example 11 includes the method of example 8 or some other example herein, wherein the ownership of the Data Object Title (DOT) is maintained by ownership of a Non- Fungible Token (NFT) on the blockchain within the system or on some other external blockchain.

[0127] Example 12 includes a method [FIG. 9] comprising: receiving a request for a read operation on a unique Data Element on a storage system for information about a product; determining the Data Owner for the Data Element through the Data object Title(DOT) for the Data Element; and contacting the Data Owner for authorization of the read operation prior to returning the data

[0128] Example 13 includes the method of example 12 or some other example herein wherein determining all Data Custody relationships that have issued by the Data Owner (or some other Actor) for the Data Element; contacting each Data Custodian for authorization of the read operation prior to returning the data; and consulting the Data Custodian Policy for each data custody relationship as to whether the operation is allowed under the Data Custodian Policy. Example 13.1 includes the method of example 13 or some other example herein, wherein the data is encrypted by the Data Owner and the requestor contacts the Data Owner for a decry ption of the data.

[0129] Example 14 includes a method [FIG. 10] comprising: receiving a request for a write operation on a unique Data Element on a storage system for information about a product; determining the Data Owner for the Data Element through the Data object Title (DOT) for the Data Element; and contacting the Data Owner for authorization of the read operation prior to returning the data

[0130] Example 15 includes the method of example 14 or some other example herein wherein determining all Data Custody relationships that have issued by the Data Owner (or some other Actor) for the Data Element; contacting each Data Custodian for authorization of the read operation prior to returning the data; and consulting the Data Custodian Policy for each data custody relationship as to whether the operation is allowed under the Data Custodian Policy.

[0131] Example 15. 1 includes the method of example 15 or some other example herein, wherein the data is encrypted by the Data Owner and the requestor contacts the Data Owner for a encryption of the data before the write operation completed.

[0132] Example 16 includes a method comprising: receiving a request for a transfer of ownership operation on a unique Data Element on a storage system for information about a product; determining the Data Owner for the Data Element through the Data Object Title (DOT) for the Data Element; contacting the Data Owner for authorization of the transfer operation prior completing the operation; and transferring ownership by transferring the ownership of the corresponding DOT.

[0133] Example 17 includes the method of example 16 or some other example herein, wherein the ownership of the DOT is maintained within the structure.

[0134] Example 18 includes the method of example 16 or some other example herein, wherein the ownership of the DOT is maintained through a record on a distributed blockchain within the system.

[0135] Example 19 includes the method of example 16 or some other example herein, wherein the ownership of the DOT is maintained by ownership of an NFT on the blockchain within the system or on some other external blockchain.

[0136] Example 20 includes a method comprising: receiving a request for a change in permissions operation on a unique Data Element on a storage system for information about a product; determining the Data Owner for the Data Element through the Data obj ect Title (DOT) for the Data Element; contacting the Data Ow ner for authorization of the permission change operation prior to performing the operation; and recording the new permissions with the Data Owner.

[0137] Example 21 includes the method of example 20 or some other example herein wherein determining all Data Custody relationships that have issued by the Data Owner (or some other Actor) for the Data Element; contacting the each Data Custodian for authorization of the permission change operation; consulting the Data Custodian Policies for each data custody relationship as to whether the operation is allowed under the Data Custodian Policy; and recording the new permissions w ith the proper data custodian for the requestor.

[0138] Example 22 includes a method comprising: receiving a request for a new Data Custody relationship between a grantor and a grantee on a unique Data Element on a storage system for information about a product; determining the Data Owner for the Data Element through the Data object Title (DOT) for the Data Element; contacting the Data Owner for authorization of the operation prior to creating the Data Custody relationship; and recording the new Data Custody relationship.

[0139] Example 23 includes the method of example 22 or some other example herein wherein determining all Data Custody relationships that have issued by the Data Owner (or some other Actor) for the Data Element; contacting the each Data Custodian for authorization of the new Data Custody relationship; consulting the Data Custodian Policy for each Data Custody relationship as to whether the operation is allowed under the Data Custodian Policy; and recording the new Data Custody relationship.

[0140] Example 24 includes a method comprising: receiving a request to delete a Data Custody relationship betw een a grantor and a grantee on a unique Data Element on a storage system for information about a product; authenticating the request is from the grantorof the Data Custody relationship; recording the deletion of the Data Custody relationship; and messaging the Data Custody grantee to delete any Data Custody relationships that it has established for the Data Element.

[0141] Example 25 includes a method comprising: receiving an access request associated with a data element; identifying, based on the access request, a first identifier associated with the data element and a second identifier associated with a data object title (DOT) that is associated with the data element; and determining a current owner of the DOT.

[0142] Example 26 includes the method of example 25 or some other example herein, wherein determining the current owner comprises: identifying a DOT system that issued the DOT; transmitting, to the DOT system, a request that includes the second identifier; and receiving, from the DOT system, a response that includes an indication of the current owner.

[0143] Example 27 includes the method of example 26 or some other example herein, wherein the response further includes information on how to contact a data owner information system associated with the data element.

[0144] Example 28 includes the method of example 25 or some other example herein, wherein the DOT includes the first identifier, the second identifier, an address of the data element, and a cryptographic proof of authenticity of the DOT.

[0145] Example 29 includes the method of example 25 or some other example herein, further comprising: identifying an authentication manager of the current owner; transmitting, to the authentication manger, a request to authorize the access request; receiving, from the authentication manager, a response to authorize the access request; and performing an access operation associated with the access request, based on the response to authorize the access request.

[0146] Example 30 includes the method of example 29 or some other example herein, further comprising: transmitting a record of performing the access operation to a blockchain management system for storage.

[0147] Example 31 includes the method of example 29 or some other example herein, wherein the access request is a first permission change request that includes authentication information associated with an actor making the first permission change request and includes a third identifier associated with a second actor to which the first permission change request is directed, and the method further comprises: obtaining an address of an authentication manager associated with the third identifier; and transmitting a second permission changerequest to the authentication manager based on the address, wherein the second permission change request includes the authentication information and the first identifier.

[0148] Example 32 includes a method comprising: generating a data object title (DOT) associated with a data element, the DOT to include an identifier of the data element, an identifier of the DOT, and a data address of the data element; determining an owner of the DOT; receiving a request associated with the DOT; and providing, in response to the request, an indication of the owner of the DOT.

[0149] Example 33 includes the method of example 32 or some other example herein, further comprising: associating the owner with the DOT by including an identifier of the owner in the DOT, providing a record in a blockchain of the owner of the DOT, or providing the owner with a non-fungible token (NFT) that indicates ownership of the DOT.

[0150] Example 34 includes the method of example 32 or some other example herein, further comprising: providing, in response to the request or another request, an indication to verify an validity of the DOT.

[0151] Example 35 includes the method of example 32 or some other example herein, wherein the owner is a first owner and the method further comprises: receiving a request to transfer ownership of the DOT from the first ow ner to a second owner, the request to include an identifier of the first ow ner, an identifier of the second ow ner, and authentication information; determining transfer of ownership permitted by the first owner; transferring, based on said determining transfer of ownership permitted by the first owner, ownership to the second owner; and recording an indication of said transferring ownership in a blockchain.

[0152] Example 36 includes a method comprising: receiving, at an authorization manager, a request to authorize a requested access of a data element; determining w hether there are any open data custody relationships associated with the data element and accessible by the authorization manager; and determining whether to authorize the requested access of the data element based on said determining whether there are any open data custody relationships associated with the data element and issued by the authorization manager.

[0153] Example 37 includes the method of example 36 or some other example herein, wherein the authorization manager is a first authorization manager, the request is a first request, said determining whether there are any open data custody relationships comprises determining there is an open data custody relationship associated with the data element and issued by the first authorization manager, and the method further comprises: transmitting, to a second authorization manager associated with the open data custody relationship, a secondrequest to authorize the requested access of the data element; and receiving an authorization response from the second authorization manager.

[0154] Example 38 includes the method of example 37 or some other example herein, further comprising: determining whether the requested access of the data element is included in a list of one or more access actions delegated under a data custody role of the open data custody relationship; and determining whether to permit the requested access of the data element based on said receiving the authorization response and said determining whether the requested operation is included in the list of one or more actions.

[0155] Example 39 includes the method of example 37 or some other example herein, further comprising: determining that a custody operation is permitted; and transmitting the second request to the second authorization manager based on said determining that the custody operation is permitted.

[0156] Example 40 includes the method of example 37 or some other example herein, wherein the second request includes an indication of an actor associated with the requested access, the authorization response includes an indication that the actor is unknown, and the method further comprises: attempting to authenticate the actor with the first authorization manager based on the authorization response including the indication that the actor is unknown; and determining whether to authorize the requested access of the data element based on said attempting to authenticate the actor with the first authorization manager.

[0157] Example 41 includes the method of example 36 or some other example herein, wherein determining whether there are any open data custody relationships associated with the data element and issued by the authorization manager includes determining there are no open data custody relationships associated with the data element and issued by the authorization manager, and the method further comprises: authenticating an actor associated with the request; accessing a list of one or more access actions delegated under a role associated with the authorization manager, wherein the role is a data ownership role or a data custody role; determining whether the requested access of the data element is included in the list of one or more actions; and determining whether to permit the requested access of the data element based on said determining whether the requested operation is included in the list of one or more actions.

[0158] Example 42 includes the method of example 36 or some other example herein, wherein the authorization manager is associated with a first actor, the requested access is a permission change request and the method further comprises: determining that the permissionchange request is directed to the first actor; and transmitting, based on said determining that the permission change request is directed to the first actor, the permission change request to an authentication manager associated with the first actor.

[0159] Example 43 includes the method of example 36 or some other example herein, wherein the authorization manager is associated with a first actor, the requested access is a permission change request and the method further comprises: determining that the permission change request is directed to a second actor; determining, based on said determining that the permission change request is directed to the second actor, a data custody relationship for the data element exists with the second actor, wherein the data custody relationship permits a permission change; and transmitting, based on said determining that the data custody relationship for the data element exists with the second actor and the data custodyrelationship permits the permission change, the permission change request to the second actor.

[0160] Example 44 includes the method of example 36 or some other example herein, wherein the authorization manager is associated with a first actor, the requested access is a request to create a data custody relationship, and the method further comprises: determining that the request to create the data custody relationship is directed to the first actor, and transmitting, based on said determining that the request to create the data custody relationship is directed to the first actor, the request to create the data custody relationship to an authentication manager associated with the first actor.

[0161] Example 45 includes the method of example 36 or some other example herein, wherein the authorization manager is associated with a first actor, the requested access is a request to create a data custody relationship, and the method further comprises: determining that the request to create the data custody relationship is directed to a second actor; determining, based on said determining that the request to create the data custody relationship is directed to the second actor, an open data custody relationship for the data element exists with the second actor, wherein the open data custody relationship permits additional custodydelegation; and transmitting, based on said determining that the request to create the data custody relationship is directed to the second actor and the open data custody relationship permits additional custody delegation, the request to create the data custody relationship to the second actor that has the open data custody relationship associated with the data element.

[0162] Example 46 includes the method of example 36 or some other example herein, wherein the authorization manager is associated with a first actor, the requested access is arequest to delete a data custody relationship, and the method further comprises: determining that the request to delete the data custody relationship is directed to the first actor, and transmitting, based on said determining that the request to delete the data custody relationship is directed to the first actor, the request to delete the data custody relationship to an authentication manager associated with the first actor.

[0163] Example 47 includes the method of example 36 or some other example herein, wherein the authorization manager is associated with a first actor, the requested access is a request to delete a data custody relationship, and the method further comprises: determining that the request to delete the data custody relationship is directed to a second actor; determining, based on said determining that the request to delete the data custody relationship is directed to the second actor, an open data custody relationship for the data element exists with the second actor, wherein the open data custody relationship permits deletion of custody delegations; and transmitting, based on said determining that the request to delete the data custody relationship is directed to the second actor and the open data custody relationship permits deletion of custody delegations, the request to delete the data custody relationship to the second actor that has the open data custody relationship associated with the data element.

[0164] Example 48 includes a method comprising: receiving a request to transfer ow nership of a data object title (DOT) that is associated with a data element, wherein the request includes a current data owner identifier (ID), a recipient data owner ID, and authentication information for an actor that is requesting transfer of ownership of the DOT. and the DOT includes a data element ID and an address of the data element; sending, to an authentication manager associated with the current data oworer ID, a request to authorize an ownership change, the request to include the authentication information; receiving, from the authentication manager, a response to indicate a successful authorization of the ownership change; and transferring ownership of the DOT to the recipient data owner ID.

[0165] Example 49 includes the method of example 48 or some other example herein, wherein transferring ow nership of the DOT comprises: changing a record in a stored table; transferring ownership of a non-fungible token (NFT) associated with ownership of the DOT; or transferring ownership of the DOT on a blockchain.

[0166] Example 50 includes the method of example 48 or some other example herein, further comprising: transmitting a request to store a record of said transferring ow nership of the DOT on a blockchain.

[0167] Example 51 includes a method comprising: receiving a first transfer request to transfer ownership of a data object title (DOT) associated with a data element to a new owner, the first transfer request to include an identifier of the new owner; determining a current owner of the DOT; transmitting, to a DOT system, a second transfer request that includes the identifier of the new owner and an identifier of the current owner.

[0168] Example 52 includes the method of example 51 or some other example herein, wherein the second transfer request includes authentication information for an actor that is requesting transfer of ownership of the data element.

[0169] Example 53 includes the method of example 51 or some other example herein, further comprising: obtaining a DOT associated with the data element; verifying a validity of the DOT; determining the current owner based on said verifying the validity of the DOT.

[0170] Example 54 includes the method of example 51 or some other example herein, further comprising: receiving, from the DOT system, an indication that ownership of the data element has been transferred to the new7owner; determining the data element is encrypted; and providing, to a data accessor information system based on said receiving the indication that ownership of the data element has been transferred and determining that the data element is encry pted, a current value of the data element.

[0171] Example 55 includes the method of example 54 or some other example herein, further comprising: receiving, from the data accessor information system, updated information for the data element; and updating the data element with the updated information.

[0172] Another example may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1-55, or any other method or process described herein.

[0173] Another example may include one or more non-transitory, computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-55, or any other method or process described herein.

[0174] Another example may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-55, or portions thereof.

[0175] Another example may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1-55, or portions thereof.

[0176] Any of the above-described examples may be combined with any other example (or combination of examples), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

Claims

CLAIMS1. A method comprising: receiving an access request associated with a data element; identifying, based on the access request, a first identifier associated with the data element and a second identifier associated with a data object title (DOT) that is associated with the data element; and determining a current owner of the DOT.

2. The method of claim 1 , wherein determining the current owner comprises: identifying a DOT system that issued the DOT; transmitting, to the DOT system, a request that includes the second identifier; and receiving, from the DOT system, a response that includes an indication of the current owner.

3. The method of claim 2, wherein the response further includes information on how to contact a data owner information system associated with the data element.

4. The method of claim 1, wherein the DOT includes the first identifier, the second identifier, an address of the data element, and a cryptographic proof of authenticity of the DOT.

5. The method of claim 1, further comprising: identifying an authentication manager of the cunent owner, transmitting, to the authentication manger, a request to authorize the access request; receiving, from the authentication manager, a response to authorize the access request: and performing an access operation associated with the access request, based on the response to authorize the access request.

6. The method of claim 5, further comprising:transmitting a record of performing the access operation to a blockchain management system for storage.

7. The method of claim 5 wherein the access request is a first permission change request that includes authentication information associated with an actor making the first permission change request and includes a third identifier associated with a second actor to which the first permission change request is directed, and the method further comprises: obtaining an address of an authentication manager associated with the third identifier; and transmitting a second permission change request to the authentication manager based on the address, wherein the second permission change request includes the authentication information and the first identifier.

8. A method comprising: generating a data object title (DOT) associated with a data element, the DOT to include an identifier of the data element, an identifier of the DOT, and a data address of the data element; determining an owner of the DOT; receiving a request associated with the DOT; and providing, in response to the request, an indication of the ow ner of the DOT.

9. The method of claim 8, further comprising: associating the owner with the DOT by including an identifier of the owner in the DOT, providing a record in a blockchain of the owner of the DOT, or providing the owner with a non-fungible token (NFT) that indicates ownership of the DOT.

10. The method of claim 8, further comprising: providing, in response to the request or another request, an indication to verify an validity of the DOT.

11. The method of claim 8, wherein the owner is a first owner and the method further comprises: receiving a request to transfer ownership of the DOT from the first owner to a second owner, the request to include an identifier of the first owner, an identifier of the second owner, and authentication information;determining transfer of ownership permitted by the first ow er; transferring, based on said determining transfer of ownership permitted by the first owner, ownership to the second owner; and recording an indication of said transferring ownership in a blockchain.

12. A method comprising: receiving, at an authorization manager, a request to authorize a requested access of a data element; determining whether there are any open data custody relationships associated with the data element and accessible by the authorization manager; and determining whether to authorize the requested access of the data element based on said determining whether there are any open data custody relationships associated with the data element and issued by the authorization manager.

13. The method of claim 12, wherein the authorization manager is a first authorization manager, the request is a first request, said determining whether there are any open data custody relationships comprises determining there is an open data custody relationship associated with the data element and issued by the first authorization manager, and the method further comprises: transmitting, to a second authorization manager associated with the open data custody relationship, a second request to authorize the requested access of the data element; and receiving an authorization response from the second authorization manager.

14. The method of claim 13, further comprising: determining w hether the requested access of the data element is included in a list of one or more access actions delegated under a data custody role of the open data custody relationship; and determining whether to permit the requested access of the data element based on said receiving the authorization response and said determining whether the requested operation is included in the list of one or more actions.

15. The method of claim 13, further comprising: determining that a custody operation is permitted; andtransmitting the second request to the second authorization manager based on said determining that the custody operation is permitted.

16. The method of claim 13, wherein the second request includes an indication of an actor associated with the requested access, the authorization response includes an indication that the actor is unknown, and the method further comprises: attempting to authenticate the actor with the first authorization manager based on the authorization response including the indication that the actor is unknown; and determining whether to authorize the requested access of the data element based on said attempting to authenticate the actor with the first authorization manager.

17. The method of claim 12, wherein determining whether there are any open data custody relationships associated with the data element and issued by the authorization manager includes determining there are no open data custody relationships associated with the data element and issued by the authorization manager, and the method further comprises: authenticating an actor associated with the request; accessing a list of one or more access actions delegated under a role associated with the authorization manager, wherein the role is a data ownership role or a data custody role; determining whether the requested access of the data element is included in the list of one or more actions; and determining whether to permit the requested access of the data element based on said determining whether the requested operation is included in the list of one or more actions.

18. The method of claim 12, wherein the authorization manager is associated with a first actor, the requested access is a permission change request and the method further comprises: determining that the permission change request is directed to the first actor, and transmitting, based on said determining that the permission change request is directed to the first actor, the permission change request to an authentication manager associated with the first actor; .

19. The method of claim 12, wherein the authorization manager is associated with a first actor, the requested access is a permission change request and the method further comprises: determining that the permission change request is directed to a second actor; determining, based on said determining that the permission change request is directed to the second actor, a data custody relationship for the data element exists with the second actor, wherein the data custody relationship permits a permission change; and transmitting, based on said determining that the data custody relationship for the data element exists with the second actor and the data custody relationship permits the permission change, the permission change request to the second actor.

20. The method of claim 12, wherein the authorization manager is associated with a first actor, the requested access is a request to create a data custody relationship, and the method further comprises: determining that the request to create the data custody relationship is directed to the first actor, and transmitting, based on said determining that the request to create the data custody relationship is directed to the first actor, the request to create the data custody relationship to an authentication manager associated with the first actor.

21. The method of claim 12, wherein the authorization manager is associated with a first actor, the requested access is a request to create a data custody relationship, and the method further comprises: determining that the request to create the data custody relationship is directed to a second actor; determining, based on said determining that the request to create the data custody relationship is directed to the second actor, an open data custody relationship for the data element exists with the second actor, wherein the open data custody relationship permits additional custody delegation; and transmitting, based on said determining that the request to create the data custody relationship is directed to the second actor and the open data custody relationship permits additional custody delegation, the request to create the data custody relationship to the second actor that has the open data custody relationship associated with the data element.

22. The method of claim 12, wherein the authorization manager is associated with a first actor, the requested access is a request to delete a data custody relationship, and the method further comprises: determining that the request to delete the data custody relationship is directed to the first actor, and transmitting, based on said determining that the request to delete the data custody relationship is directed to the first actor, the request to delete the data custody relationship to an authentication manager associated with the first actor.

23. The method of claim 12, wherein the authorization manager is associated with a first actor, the requested access is a request to delete a data custody relationship, and the method further comprises: determining that the request to delete the data custody relationship is directed to a second actor; determining, based on said determining that the request to delete the data custody relationship is directed to the second actor, an open data custody relationship for the data element exists with the second actor, wherein the open data custody relationship permits deletion of custody delegations; and transmitting, based on said determining that the request to delete the data custody relationship is directed to the second actor and the open data custody relationship permits deletion of custody delegations, the request to delete the data custody relationship to the second actor that has the open data custody relationship associated with the data element.

24. A method comprising: receiving a request to transfer ownership of a data object title (DOT) that is associated with a data element, wherein the request includes a current data owner identifier (ID), a recipient data owner ID, and authentication information for an actor that is requesting transfer of ow nership of the DOT, and the DOT includes a data element ID and an address of the data element; sending, to an authentication manager associated with the current data owner ID, a request to authorize an ownership change, the request to include the authentication information; receiving, from the authentication manager, a response to indicate a successful authonzation of the ownership change; and transferring ownership of the DOT to the recipient data ow er ID.

25. The method of claim 24, wherein transferring ownership of the DOT comprises: changing a record in a stored table; transferring ownership of a non-fungible token (NFT) associated with ow nership of the DOT; or transferring ownership of the DOT on a blockchain.

26. The method of claim 24, further comprising: transmitting a request to store a record of said transferring ownership of the DOT on a blockchain.

27. A method comprising: receiving a first transfer request to transfer ownership of a data object title (DOT) associated with a data element to a new- owner, the first transfer request to include an identifier of the new owner; determining a current owner of the DOT; transmitting, to a DOT system, a second transfer request that includes the identifier of the new7owner and an identifier of the current owner.

28. The method of claim 27, wherein the second transfer request includes authentication information for an actor that is requesting transfer of ownership of the data element.

29. The method of claim 27, further comprising: obtaining a DOT associated with the data element; verifying a validity7of the DOT; determining the current owner based on said verifying the validity of the DOT.

30. The method of claim 27, further comprising: receiving, from the DOT system, an indication that ownership of the data element has been transferred to the new owner; determining the data element is encrypted; and providing, to a data accessor information system based on said receiving the indication that ownership of the data element has been transferred and determining that the data element is encrypted, a current value of the data element.

31. The method of claim 30, further comprising: receiving, from the data accessor information system, updated information for the data element; and updating the data element with the updated information.

Images