Object Story Signaling for Consumer Communications

In today's business environment, information about various entities is stored within a variety of database systems and structures. Inefficiencies and insecurities related to generating, storing, accessing, and maintaining information related to the various entities may cause confusion and mistrust.

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).

Systems, methods and apparatuses for maintaining information about various subjects of a marketplace are described herein. For example, in one embodiment, information elements about facilities, companies, brands, and conditions are created by computer systems throughout the supply chain or lifecycle of a product, which may refer to a good or service. The various actors provide information about claims that they make about the people, places, and things that make up the actions performed in creating, transporting, owning, maintaining, and dispositioning a product. These claims are accompanied by evidence information that proves the validity of the claim. Claims can be made either manually by an actor using a properly authenticated computing system which is networked to the other devices in the network, or they can be created automatically by sensor endpoints that read information, create claims and evidence and send it to the network independently. These claims and evidence are aggregated and stored, either centrally or distributed in a manner that prevents the unauthorized addition, subtraction, or alteration of information within the claim and evidence objects. During the lifetime of the product, actors using computing systems can access the claims and evidence to create business intelligence on the business environment of the marketplace. The end consumer can access the claims and evidence using a computing/communication device connected to the Internet. The owners, maintainers, and those that possess or otherwise use a product can make claims about themselves, changes, maintenance, possession, or use of the product while under their control. Other related embodiments are also described and claimed.

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

Authentication manager: computing element responsible for authenticating users to an object story computing network and assigning them roles.

Automation information system: computing element that integrates sensor information into an object story.

Certification authority: computing element that provides cryptographic information for access to an object story.

Claim element: fundamental information object containing a statement that is made about a product, entity, facility, or location.

Component: A portion of a larger object. A component can include a subassembly, part, ingredient, or other sub-portions of a product; a department, team, or individual of an entity; a sub-facility (for example, emergency room) of a facility (for example, hospital); or a smaller location (for example, room) of a larger location (for example, building).

Consumer computing device: computing element of the consumer for accessing the public portions of the object story data structures.

Consumption element: portion of a product object story that contains information about the consumer(s) interaction, use, or maintenance of the product.

Conversion element: portion of a product object story that contains information about the ultimate end-of-life disposal of the product.

Custody element: portion of a product object story that maintains information about the chain-of-custody of the product as it was manufactured and distributed.

Evidence element: fundamental information object containing evidence of the veracity of a corresponding claim element.

Legacy adapter: computing element that interfaces non-object story aware legacy computing systems to the object story structures.

Manufacturer information system: computing element within the manufacturer for access to the object story management systems.

Object: a product (for example, a perishable good, a durable good, or service), a facility (for example, a place built for a particular purpose), an entity (for example, an individual, company, or group), or a location.

Object story: information about lifecycle aspects of an object. If the term “object story” is used, it can mean that the information refers to any of the objects described herein. The term “object story” will be modified when necessary to identify the type of information that is stored. For example a product object story refers to information about a product, a facility object story refers to information about a facility; and so forth.

Object story data structure: a data structure that includes or incorporates elemental aspects of an object story, the data structure or elemental aspects may be distributed across set of networked, distributed nodes.

Origin element: portion of an object story that contains information about the components that make up the object and the process by which the object is made.

Remote substory access: computing element responsible for accessing object story, or elements thereof, at other business entities.

Story manager: computing element responsible for storing object story data structure.

Today's systems do not allow a user to query or maintain information from the entire lifecycle of a product in an online fashion. Embodiments provide improvements on the present state of the art by creating a secure, distributed set of computing systems that can maintain many different information elements about each step and participant in the manufacturing, development, and lifecycle process and make that information available in a customized manner to those that desire the information to make decisions.

The object story represents the collection of information (in particular claims and evidence) about aspects of a lifecycle of an object. This information constituting an object story is embodied in an object story data structure that may be stored in one or more of a set of networked, distributed computing nodes and data structures. The object story data structure may be constructed in a distributed fashion and may be sharable between the different actors based on their authorized role in the process. The object story may represent elemental aspects over the development and functional lifetime of the object. It may also be recursive in its nature. For example, an ingredient object story may contribute information about parts, which are contained within a subassembly object story, which may be contained within a product object story. An object story for a facility may contain component object story structures specifying each of the warehouses at that site. Those object stories may contain object stories for the module, pod, or pallet rack containing products and they would contain or link to the product object stories for the products currently stored there. Information about the entities involved in the process may also be recursive. A company object story may represent claims and evidence on the operations of a company (such as its carbon footprint), but it may also contain a department object story for each department in the company, or a site object story for each site in which manufacturing occurs. The department/site object stories would contain claims and evidence information relevant to that department/site (such as an external certification of fair wage practices). This creates a rich, navigable, set of information about the components, people, and places that are associated with an object.

1 FIG. There are many actors involved in a lifecycle of a product and each actor has important information to contribute to the product object story. The actors are shown inin 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; however, other embodiments allow interactions with these entities across all phases of the lifecycle. Various facilities and companies may supply components, which would be associated with component object stories that are associated with facility/company object stories. Once a product is manufactured it may pass through several distributors, transport services, and retailers during a custody phase. For a durable good such as a car, there may be several consumers who purchase, maintain, 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 recycled or disposed.

In some embodiments, various object stories may include elements that correspond to each of these phases. For example, a product object story may include an origin element, a custody element, a consumption element, and a conversion element. Each of these elements, which may also be referred to as stories, may include one or more other object stories or claim elements that are relevant to actors and operations of the corresponding phase.

The origin element may include claim elements and component/facility/entity/location object stories that are relevant to the origin phase of the product. In some instances, the origin element may include component object stories for the components of the product, with each component object story incorporating facility/entity/location object stories that are related to the corresponding component. Further, the claim elements within the origin element may be associated with facility/entity/location object stories that are related to assertions of the corresponding claim elements.

The custody element may include claim elements and object stories (e.g., component, facility, entity, or location object stories) that are relevant to the custody phase of the product. For example, the claim elements/object stories may be provided to track possession through the custody phase. claim elements and facility/entity/location object stories may describe how and when distributors, transporters, and retailers had possession of the product.

The consumption element may include claim elements and object stories (e.g., component, facility, entity, or location object stories) that are relevant to the consumption phase of the product. For example, claim elements and facility/entity/location object stories may be provided to describe how and where the product is used and by whom. In some embodiments, modifications to the product may also be tracked by claim elements and appropriate object stories. For example, if a component of the product is replaced or an additional component is added, a new component object story may be added into the product object story along with the object story of the entity that manufactured or installed the replacement/added component. For another example, service, maintenance, or repair records may be added to the product object story by adding new claim elements/object stories related to the action performed, the entity performing the action, and any components added by the action.

The conversion element may include claim elements and object stories (e.g., component, facility, entity, or location object stories) that are relevant to the consumption phase of the product. For example, claim elements and facility/entity/location object stories may be provided to describe how and where the product is disposed or recycled and by whom.

The product object story represents information about the product and its ingredients throughout all of these phases and with respect to all of the actors and locations that are involved in its lifecycle. This information can be created and maintained at several different levels. For example, a durable good, such as a car may need to be tracked at the level of an individual item (a car with a specific VIN number containing an engine with a specific serial number). Products can also be tracked as batches (such as all of the goods produced on a given day). Or a single product object story can be used to represent claims that cover all of the products created by a manufacturer (containing information such as the certified organic nature of all offered products). Object stories can also be used independently of products to convey information about the facilities and companies used. For example, a company object story can be used to convey the certifications on the labor and ethical values of the company, regardless of the product delivered by that company.

Each actor in the lifecycle of the information on the product, facilities, or entities involved may have specific rights to read and write information to the object story element that is pertinent to their role in the lifecycle. Each of these actors may maintain computing information systems and data management systems in order to cooperatively build and maintain the object stories that communicate the related information.

1 FIG. Whiledescribes incorporating object stories into lifecycle elements of a product, object stories as described herein may also be generated/utilized independently of a product. For example, facility/entity/location object stories may be generated, accessed, and maintained as described herein without being defined with reference to a particular product. So, while some embodiments describe facility/entity/location object stories being incorporated into a product story to provide information on how the facility/entity/location was involved with the product, other embodiments are not so limited. For example the facility/entity/location object stories may be independent from a product story or, in other examples, the facility/entity/location object stories may include product object stories.

2 FIG. 200 illustrates computing systemsinvolved in the creation, maintenance, and access of an object story in accordance with some embodiments.

200 250 250 1 FIG. The computing systemsmay include an object story management (OSM) systemto maintain and manage the distributed data structure of the object story. The OSM systemmay be responsible for ensuring that a complete object story can be accessed when needed, and may be responsible for ensuring that the local actors can perform those actions on the object story that are permitted by their role. Each of the actors inmay implement an OSM system. In another embodiment, a third party may implement these systems and the actor's systems will interact with this third party to maintain a decentralized store of object story information.

201 202 203 204 214 201 201 201 204 202 203 214 The OSM System may include a number of modules including, for example, story manager, authentication manager, certification authority module, remote story access module, and the public interface module. The story managermay be responsible for maintaining the storage of the information about a subject of the object story and ensuring that other entities can view or alter only those portions that their role allows. The story managermay 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 story manageruses one or more distributed ledgers to maintain the information. The remote story access modulemay be responsible for maintaining links to those portions of the object story that are not stored locally. If the actor wishes to modify a portion of the object story that is not local, the remote story access module contacts a remote data management system, authenticates its actor and retrieves the portion of the object story that they are authorized to use. The authentication managermay be responsible for identifying the entities that access the object story, verifying their identities and assigning them roles that grant them the proper access to the necessary portions of the object story. The certification authority modulemay be responsible for enrolling entities into the object story network and providing them cryptographic identification so that they can access the information stored. The public information modulemay be responsible for representing on the public network the object stories managed by the entity.

200 260 250 The computing systemsmay further include computing information systemsto access or otherwise interact with object stories via the OSM system. Each actor may have different computing information systems depending on their role in the ecosystem—with different rights available to them. In another embodiment, a third party may implement these systems and the actor's systems will interact with this third party to maintain a decentralized store of object story information.

260 260 205 205 250 1 FIG. 1 FIG. The computing information systemimplement, in software and hardware, the roles of the various actors in, accessing (for example, reading or writing) the object story or elements thereof as necessary. A representative sample of the computing information systemsare shown from the basic roles defined in. Other embodiments may contain other systems that fulfill alternative or additional roles. A supplier information systemmay provide object story information representing their company and object stories representing the ingredients or subassemblies they provide to a manufacturer or agricultural producer. The supplier information systemmay provide full product object story data structures for those ingredients that the OSM systemmakes available to the manufacturer or downstream ingredient supplier. For example, an automobile manufacturer story manager may receive full product object story data structures from their subassembly suppliers—such as the engine manufacturer—and integrate those data structures into the car's object story. This is recursive as well, so that the engine object story may contain the product object story structures of each of its constituent parts—such as the pistons. And the piston object story may contain information about the steel used in the manufacturing process. In this way, the product object story of a manufactured or processed item may contain or represent full information on an item from its basic ingredients through the chain of suppliers of those ingredients until they have been integrated into components, subassemblies, and finally the fully manufactured or processed item. The product object story may also contain information in facility object stories to define the location where it was manufactured. Each of the component object stories may contain company object stories defining claims and evidence about the manufacturer of that component.

213 The manufacturer information systemmay supply the portions of the product or facility object story related to the final manufactured item and where it was created. It reads and writes information about the manufacturing facilities and the process that created the product.

207 208 206 209 209 210 210 209 210 260 211 211 212 212 The distributor information systemmay provide information to the product object story for an item that has been manufactured and is in the process of being shipped out for distribution either to the next step in the manufacturing process or to the consumer. This may include many variables stored in location object stories such as location, time, temperature, shock sensors reporting bad handling practices, etc. The warehouse information systemmay record information about where, for how long, and under what conditions the product was stored in the manufacturer's warehouse before being sent for distribution. It may also supply information about the warehouse itself in a facility object story for the warehouse. The consumer computing devicemay provide a public view of any type of object story so that a consumer can browse the information that is important to them in their buying decision. The automation information systemcan be located throughout any of the actors in the process. The automation information systemmay include various sensorsto report conditions of storage, manufacturer, shipment, etc. For example, the temperature in a food processing assembly line, the length of time that a subassembly remained in the warehouse before being used, or the quality control information and images that define that the item has been properly inspected. In various embodiments, the sensorsmay be image sensors, temperature sensors, timers, barcode readers, proximity sensors, accelerometers, shock or impact sensors, etc. The automation information systemmay take the information from the sensorsand write it into the appropriate portions of the product or location object story corresponding to the actor's role. The computing information systemmay include a legacy adapter. Not all entities in the manufacturing process may be object-story aware. The legacy adaptermay interface with a legacy system, pull data from the legacy system, format it properly and include it into an object story where needed. In this way even the smallest supplier that runs primarily on email can be integrated into a larger object story network.

3 FIG. 300 300 illustrates a lifecycle diagramof a product in accordance with some embodiments. The lifecycle diagramincludes an origin phase (where a product is manufactured), a custody phase (where a product is sent through the distribution chain to the consumer), a consumption phase (where the product is used and maintained by one or more owners), and finally a conversion phase (where the product is recycled or disposed).

Each of these phases may generate information that is stored in claim elements or object stories. In this way, a complete history of a product including actions performed on or with respect to the product and those participants that have performed the actions is maintained.

4 FIG. 401 402 402 403 Note that an object story, as stated above, may be fully recursive. The product object story of an item may contain within it (or maintains links to) the product object story structures for its subassemblies. The subassembly product object story structures may contain or maintain links to the object story structures for their constituent parts, object story structures for locations where they were manufactured, object story structures for entities performing the related actions, etc. An example is shown inThe main item's product object storymay contain, or contain references to, the product object story for each of a number of subsystems, for example, subassembly product object story. The subsystem product object story structuremay contain, or contain references to, its constituent part's component object story structure. This process continues for as long as information is available until the most basic ingredient is defined.

401 404 404 405 The product object storymay also contain, or contain references to a company object story, defining information about the manufacturer. The company object storymay contain, or contain references to other object stories, such as a facility object storydefining information about the location that created the product.

These high-level, recursive data objects may be maintained across the computing elements of the object story network of all of the participants of the supply chain for a product. The story manager at any network node may choose to copy an object story for an ingredient locally, or maintain a link to the ingredient object story at the supplier node. In other embodiments, parts of the object story may be distributed across one or more distributed ledgers or blockchains. If links are maintained, the manufacturer can contribute information to the elements, subassembly, ingredient, or parts object stories to provide the upstream supply chain manufacturers with important information about how the ingredients are related to the whole. This bi-directional communication between the elements of the supply chain may provide important business intelligence to the other members of the supply chain. For example, if a supplier finds a manufacturing defect in a part manufactured on a particular day, they can query their story manager and determine what subassemblies and manufactured goods contain the defective parts. This allows them to alert the downstream manufacturers more precisely than can be done today.

The object story structures and the network elements provide a framework within which atomic information elements may be represented. The smallest information elements are the claim and the evidence elements. A claim is any information that any entity wants to assert about a product item, a producer, a location, a facility, or entity, or the method and location of production, ingredients, usage, etc. Example claims are “This item was grown on an organic farm”; “This item was manufactured at factory number 3”; “Factory number 3 has fair wage and labor guidelines”; and “The company has been certified green by a third party organization”. Each claim may also contain evidence elements that are a form of proof that the claim can be trusted. Examples of evidence are “Here are third party certifications on the organic nature of the farm that produced the ingredients”; “Here are certifications of the wage and working conditions in the factory”; and “Here are the certification results on the status of the company.” Claims and evidence may be created by networked computer systems within the manufacturing process. These may be manually established by an authorized agent, or they may be automatically made by information processing elements embedded in the manufacturing and shipping process.

5 FIG. Each claim may have a chain of evidence elements that provide verification of the claim being made, and the claims for a particular object story are linked together to create a chain of claims. This structure is shown inin accordance with some embodiments.

501 502 Each claim elementcontains a link to the next claim element in the chain, and they contain links to chains of evidence elementsthat provide verification of the truth of the claim.

502 502 1. Assertion—evidence element contains no evidence, the claim is asserted by the author of the claim. For example, a farm may state that they have organic processes. 2. Self-Certification—the evidence element contains a reference to information about a review process that the author has gone through for self-certification that allows them to make the claim. For example, a farm may state that they have organic processes and provide the data for the self-certification that they have gone through that allows them to make the claim. 3. Basic Audit—the evidence element contains a reference to information about an external audit performed on the certification of the author. For example, a farm may supply audit information from a third party that shows their compliance to organic standards. 4. Third-Party Certification—the evidence element contains information from a third-party certifying entity as to the status of the author. For example, a farm may supply a third-party organic inspection certificate that shows their status. 5. Third-Party Certification with Audit—the evidence element contains information from a third-party audit that shows that the external certification is currently up to date. This structure allows for a flexible representation of evidence elementsproviding various levels of proof of the truth of a claim. Each evidence elementcan be judged to be at one or more levels of evidence. The rule then can be stated that the higher the level of evidence of the element, the stronger the proof of the truth of the claim. In one embodiment, there are the following levels of evidence.

In other embodiments, additional/alternative levels of evidence may be used that are useful for a specific field.

Throughout the object story structure's lifetime, various claims and evidence may be added to it to represent information about the product, facility, location, or those who have owned or interacted with the product. One embodiment maintains claims for the ingredients, the manufacturing facility, the location, condition, and details of the manufacturing process, the distribution custody chain, and information from the consumer about usage, or maintenance, and ultimate conversion or recycling information. Claims may cover information about the process, ingredients, materials, practices, custody, facilities, and other aspects of the life of the product and those that interact with a product. Other types of claim elements can be added as needed. Any validated and authenticated user of the system can create claim and evidence elements on parts of the various object story types to which they have the proper level of assigned rights.

It is crucial that the claim elements in an object story provide truthful information. Thus, it is of paramount importance that the claim elements and the associated evidence elements are stored and linked securely in such a manner that they cannot be improperly added to, deleted, or altered after they are made. In addition, each claim and evidence element must be able to be traced back to the claimant through an unmodifiable digital identity. One embodiment of a process to secure linked evidence and claim elements is as a set of distributed blockchains or a distributed ledger secured by cryptographic hashes.

Claims and evidence may be built into an overall set of object stories as an item is manufactured, shipped, purchased, maintained, resold, and ultimately disposed. A full set of object stories for a complex item may potentially contain thousands of claims and evidence elements made by hundreds of different parties. This allows each of the parts that make up the item to be tracked securely back to their original sources.

6 FIG. 600 illustrates portions of a product object story data structureand incorporated portions in accordance with some embodiments.

600 600 600 600 604 The product object story data structuremay include a globally unique identifier (GUID) that identifies the object story associated with the object story data structure. The object story data structuremay further include a type field that has a value of product type. The object story data structuremay further include an owner field that provides an object story data structure for an entity that owns or is otherwise responsible for the object story. The value of the owner field may be linked to a company object story data structure. This structure may include a GUID that identifies the entity that manufactures the product, and other fields corresponding to the entity (for example, a name field, an address field, a contact field, a certification field, etc.). The company object story data structure may further include a claims field that includes a chain of claim and evidence elements corresponding to the entity.

600 608 612 616 620 The object story data structuremay further include a plurality of element fields such as, for example, an origin field for an origin story related to the product object story, a custody field for a custody story related to the product object story, a consumption field for a consumption story related to the product object story, and a conversion field for a conversion story related to the product object story. Each of the element fields may include a pointer to respective element data structures. For example, the origin field may include a pointer to origin story data structure; the custody field may include a pointer to custody story data structure; the consumption field may include a pointer to consumption story data structure; and the conversion field may include a pointer to conversion story data structure.

608 The origin story data structuremay include a GUID; an ingredients field that includes a set of object stories for components, facilities, entities, or locations corresponding to the origin story; and an origin claims field that includes a chain of claim elements corresponding to the origin story. The claim chain may be implemented as one or more distributed ledgers or blockchains.

612 The custody story data structuremay include a GUID; an ingredients fields that includes a set of object stories for components, facilities, entities, or locations corresponding to the custody story; and a custody claims field that includes a chain of claim elements corresponding to the custody story. The claim chain may be implemented as one or more distributed ledgers or blockchains.

616 The consumption story data structuremay include a GUID; an ingredients fields that includes a set of object stories for components, facilities, entities, or locations corresponding to the consumption story; and a consumption claims field that includes a chain of claim elements corresponding to the consumption story. The claim chain may be implemented as one or more distributed ledgers or blockchains.

620 The conversion story data structuremay include a GUID; an ingredients fields that includes a set of object stories for components, facilities, entities, or locations corresponding to the conversion story; and a conversion claims field that includes a chain of claim elements corresponding to the conversion story. The claim chain may be implemented as one or more distributed ledgers or blockchains.

604 608 612 616 620 700 704 7 FIG. Each of the data structures,,,, andmay include links to respective object stories or claim elements.illustrates the claim elementand corresponding evidence elementin accordance with some embodiments.

700 The claim elementmay include a GUID; dictionary field that defines the syntax and semantics under which this claim element was created; a claim information field that provides a description of the claim; an evidence chain field that includes a chain of evidence elements corresponding to the claim (the evidence chain may be implemented as one or more distributed ledgers or blockchains); a previous hash field containing a cryptographic hash of the previous elements in the chain; and a link to a next claim element.

704 The evidence elementmay include a GUID; a dictionary field that defines the syntax and semantics under which this evidence element was created; an evidence field that provides a description of the evidence; a previous hash field containing a cryptographic hash of the previous elements in the chain; and a link to a next evidence element.

6 7 FIGS.and While various elements and data structures ofdescribe incorporating claims and evidence elements through blockchains, other embodiments may include non-blockchain techniques including, but not limited to, local storage of the relevant information.

8 37 FIGS.- illustrate various operation flow/algorithmic structures that may be implemented by various computer system/devices described herein. These flow/structures describe how actions may be performed to maintain a robust information environment around a product, facility, entity, or location.

8 FIG. 800 illustrates an operational flow/algorithmic structurethat may be used to initialize an object story in accordance with some embodiments.

800 801 804 801 804 801 804 The flow/structuremay initialize object story structures. The object story structure may be a product object story structure for a single manufactured or agricultural item or batch of items; or it may be facility/location/entity object story depending on the context in which the system is being used. Operations-may include authentication operations and assigning rights and roles to an end user that is accessing the object story network. A variety of authentication/assignment operations may be used for-. The operation-are intended to represent basic functionality and do not constrain the embodiment that is chosen.

805 800 806 807 800 213 203 808 809 2 FIG. At, the flow/structuremay include an information system creating a new object story structure to represent the information that will be maintained about the item. Atand, the flow/structuremay include the information system creating basic claims and evidence elements for the object story structure—such as the creation date, time, information about the facilities used to store product, etc. It may then cryptographically link those elements into the object story structure so that they cannot be altered at a later time. Referring to, the information system may be a manufacturing information systemthat uses cryptographic elements that it has received from the certification authority. Atand, the information system sends the initialized object story structure to the story manager for storage. The story manager determines the best architecture for storing the object story. This can be centralized in a database, distributed across multiple databases, or remotely stored depending on the embodiment.

9 FIG. 900 900 illustrates an operational flow/algorithmic structurefor creating a claim and variable levels of evidence in accordance with some embodiments. The claim and evidence created by flow/structuremay be inserted into the object story.

900 901 902 903 904 905 906 907 908 8 FIG. This flow/structurebegins atwith authentication of the user of an information system and obtaining rights and roles that allow the user to create claims and evidence on an object story. This process may be similar to that described in. Once the information system has obtained the necessary permissions, it queries the story manager for the object story of the item that it needs to add a claim and evidence element atand the story manager responds with the correct structure at. At, the manufacturing information system creates a claim element stating a condition of the object that is being processed. This can be an assertion that a manufacturer wishes to express about a product—such as date, time of manufacture, condition of the processing plant. Or it can be an assertion that an entity wishes to express about a facility, location, or itself. Examples of these assertions could include a statement about the carbon footprint of the facility, the current temperature at a location, or the certifications of the company, department, or individual that is being described in the object story, The information system then obtains the highest level of evidence that it has for this claim element at. See the section above on the variable levels of evidence elements that are available. As an example, the information system may choose a third-party certification to show the carbon footprint of a facility. At, it links the evidence element to the claim element in such a way that it cannot be altered or removed without an indication of a change. At, the information system links the claim element (with its attached evidence element) into the appropriate claim chain within the object story in such a way that it cannot be altered or removed without an indication of a change. The information system then provides the updated object story structure back to the story manager for storage at. The story manager may store the information locally, distributed, or make the necessary changes at a third-party manager of the object story structure. This may include making changes across a number of distributed ledgers or blockchains.

10 FIG. 1000 1000 illustrates an operational flow/algorithmic structurefor including a component object story into a larger object story in accordance with some embodiments. The flow/structuremay occur when a component, (for example, a sub-assembly, ingredient, department, smaller location) is included into a larger object (for example, product, company, large location). Additionally/alternatively a similar process may be used when a user wants to define information about smaller entities (for example, a department as part of a company). It shows the recursive nature of the object story structures as the object story for the component is included in the object story for the larger object.

1000 1001 1002 1003 1004 1005 1006 1007 8 FIG. The flow/structurebegins atwith authentication of the user of an information system and obtaining rights and roles that allow the user to create claims and evidence in an object story. This may be similar to that described above with respect to. Once the information system has obtained the necessary permissions, it queries the story manager for the object story of the item for which it needs to create a component claim and evidence atand the story manager responds with the correct structure at. In order to perform this, the story manager may access local or remote storage or interact with third-party systems that maintain object story structures on behalf of a requesting party, for example, the manufacturer. The information system then determines the unique identifier of the component (e.g., ingredient, part, department) that is to be included in the larger object story at. The information system then contacts the appropriate object-story aware system and requests the object story for the component at. The remote object-story-aware system checks the authentication information of the requestor and creates an object story for the requested component at. This object story contains only those elements that the information system is authorized to consume. At, the information system links the component object story into the origin element of the larger object story in such a manner that it cannot be altered or deleted without an indication of change. The story manager may then integrate the object story back into the storage. There are many different embodiments of how this process can be carried out. The story manager may copy the component object story locally or maintain live links to the object-story aware supplier.

11 FIG. 1100 1100 illustrates an operation flow/algorithmic structurethat describes an automated sensor data integration in accordance with some embodiments. In the flow/algorithmic structure, the sensor data may be automatically associated with an object story. For example, this could represent the history of temperature and humidity readings integrated into a warehouse facility object story.

1101 1100 209 1102 210 1103 1104 1105 1106 2 FIG. 2 FIG. At, the flow/structuremay include the automation information system (e.g., automation information systemfrom) sensing a unique identifier of an item that it is monitoring. This can be, for example, a product in the manufacturing flow or the conditions in a warehouse. The identifier may be sensed by scanning bar codes imprinted on the item, RFID chips accompanying the item through the process, visual recognition of the item using cameras, other object identification mechanisms, user input, etc. The automation information system then, at, obtains information from the environment via a set of sensors (e.g., sensorsof). These sensors can consist of time, temperature, information from other equipment, or visual inspection images of the item among other items. Atandthe automation information system creates claim and evidence elements corresponding to the sensor readings that it has received. It secures the evidence elements to the claim so that they cannot be altered or deleted without an indication of a change. Atand, the automation information system sends the packaged claim and evidence chains to the story manager for integration into the particular object story and the story manager links the claim into one of the claim chains of the given object story.

12 FIG. 1200 1200 illustrates an operation flow/algorithmic structurethat describes presentation of public information to a consumer in accordance with some embodiments. Presenting the accumulated data about a product to the end consumer may be one advantage of the object story network. In the flow/algorithmic structure, the consumer, may seek to retrieve information about an object, which may be a product, facility, entity, or location. In just one example, a consumer may be considering a purchase of a product and seek to retrieve more information about the product. For example, the product may be a used item and the consumer may be interested in information about the previous owners and how they have maintained the item.

1201 206 2 FIG. At, the user initiates a session with their consumer computing device (e.g., consumer computing deviceof). This may consist of using software that is designed to access the object story or utilize functionality within another party's software (such as using a “more info” button within a purchase application provided by a third-party).

1202 At, the consumer computing device, is used to identify the object of interest. Among the embodiments of this action are scanning the label, querying an RFID element in the product, scanning and recognizing a QR code or e-ink display, using machine assisted visual recognition of the item that is of interest, or receiving user input of an identifier associated with the object. The consumer computing device may obtain an identifier from the item that represents a unique identification of the object. This can be the type of the product such as “Model XX Stereo,” or it can be batch identification such as “Batch YYZZ of peanut butter” or it can uniquely identify the item itself, such as “Serial Number AABBCC.” The identification can also be of an entity, for example, a manufacturer of a product. The consumer may be interested in determining the corporate ethics of the entity. The decision of the level of identification is up to the implementation of the object story and the information that is to be offered to the consumer.

1203 214 250 1204 1205 2 FIG. 2 FIG. At, the user's consumer computing device makes the identification available to the public interface module (e.g., public interface moduleof) of the OSM system (e.g., OSM systemof) of the party that manages the object story structures. The public interface module then assembles the public information in the requested object story and sends it back to the consumer computing device atand.

1206 At, the consumer computing device determines if there is an existing “profile of values” for the user. The profile of values may be an expression of the interests and importance of particular aspects of manufacturing, governance, or operation of the user. For example, the user may be interested in organic conditions of ingredients, or they may be more interested in the carbon footprint or fair labor practices of the manufacturer. For another example, the user may be interested in diversity, equity, and inclusion practices of a corporation. There is a wide range of value types that can be expressed in any embodiment of this concept. The profile of values can be established directly by the user by using an interface to the consumer computing device, or they can be inferred from the user's past behavior on the consumer computing device, or they can be established by any combination of these methods.

In some embodiments, the computing device may solicit interests of a user. For example, the computing device may provide the user with a list of interests that are available for selection by the user. These interests may be of a general nature, or they may be tailored to specific object types (for example, product, facilities, locations, entities) or even to specific objects (for example, a specific product, facility, location, or entity). In the event the available interests are tailored to a specific object type, they may be presented to the user for selection after receiving an indication of the object of interest.

In some embodiments, in addition to obtaining one or more interests of the user, the computing device may provide the user with a weighting field that allows the user to provide a weight associated with each interest. The user may input weighting values into the weighting field to provide different levels of importance for different interests. The weighting field may allow the user to reorder the interests, control a sliding scale associated with each interest, enter a numerical or other demarcated weighting value, etc.

In some embodiments, the computing device may track the user's interaction with the system and provide recommendations based on the user's interactions. For example, the computing device may provide suggestions for new interests and associated weighting values, suggestions for modifying currently selected interests or importance levels, etc.

1207 1208 If a profile of values exists on or is otherwise available to the system, the consumer computing device tailors the information in the claims and evidence of the item's object story to match the user's profile of values at. If there is no established profile of values the consumer computing device creates a generic interface to the claims and evidence of the item's object story at.

1209 1210 The security of each of the claims and evidence are verified at. At, because of the variable levels of evidence available within the claims made in the object story, the interface to the consumer computing device can make an indication of the strength of the claims made.

1210 1211 For example, self-certified organic status can be displayed differently than third-party verified organic status. This presents the first level of information in which the user may be interested. Because of the recursive nature of the object story the user can request deeper information about the components of the item, atand. For example, the first level of information could be the packaging plant of an agricultural product. The user could choose to view the claims and evidence of the health certification of the department that performed the packaging.

13 FIG. 1300 illustrates a diagramthat represents contract settlement through usage of claims and evidence in accordance with some embodiments. The cryptographic strength of the claims and evidence objects can be used within terms of a contract to provide the proof needed to transfer values between entities.

1301 1302 1303 1305 1303 1304 Two business entitiesandcreate a contract. The contract can be embodied as either a written, legal document or as an electronic contract. In either case, the contract specifies conditions within it and value to be transferred between the entities if those conditions are met. The contract can be written in any embodiment such that value can flow from either party to the other party and the amount of value transferred can be conditional on other conditions specified in the contract. This value can be a fiat currency, bank transfers, or electronic value items such as a cryptocurrency. In the current embodiment, the conditions of the contractreference claims and evidence elements of various object story structures. Any embodiment of a contract is allowed with any expressible stipulations and conditions provided that those conditions are tied to claims and evidence elements of an object story. With the integration of the object story, the contract conditions can express anything that can be contained within a claim element and can stipulate required levels of linked evidence elements in order to transfer variable levels of value between the entities. This allows for automated contract settlement that is a method and apparatus for monitoring the object story and automatically settling the contract when the necessary conditions are met within the object story. The process of operations on an electronic contract are described in the following operation flows/algorithmic structures.

14 FIG. 1400 illustrates an operation flow/algorithmic structurethat describes operations of an electronic contract between two entities, for example, a manufacturer and a component supplier, in accordance with some embodiments. This embodiment is shown for illustrative purposes, other embodiments are envisioned between any two entities in the business process and other physical embodiments of contracts that depend on claim and evidence elements of an object story.

1400 1401 1403 1404 1405 1406 1408 1407 1409 8 FIG. The flow/structurebegins atwith authentication of the user of an information system, for example, a manufacturing information system, and obtaining rights and roles that allow the user to process an object story. This may be similar to that described above with respect to. Once the information system has obtained the necessary permissions, it opens the electronic contract. This electronic contract can be stored within an object story or it can be stored within a separate database or business information system. The information system executes the code of the electronic contract at. The electronic contract requests the appropriate object story from the story manager at. This can be one or more product object stories, or it can be the object story for a facility, entity, location, or component thereof. The electronic contract executes code that reads claim and evidence elements from the object story at, checks the cryptographic integrity of those elements, and determines if the evidence elements meet the requirements expressed in the electronic contract. If the conditions are met at, the electronic contract takes the necessary steps to transfer value to the other party at. If the conditions are not met, the electronic contract notifies the other party as to the failure to fulfill the conditions of the electronic contract at. The electronic contract then creates claim and evidence elements within the object story to indicate the results of the conditions atand provides it to the Story manager for permanent storage.

15 FIG. 1500 illustrates an operation flow/algorithmic structurethat describes consumer addition to an object story in accordance with some embodiments. In some embodiments, the object story may be delivered to an end consumer via the consumer computing device at a point of purchase. In other embodiments, the object story can be used beyond the point of purchase for an entity to communicate information about an object. For example, a rental car company may want to keep track of the maintenance performed on their vehicles through object story information. Ownership, rental and maintenance information, and other information may be stored within the product object story for the cars so that future owners can query the object story for the car they are purchasing to verify its history.

1500 Given that the object story structures contain information across the entire lifecycle of a product, information from consumers is important to both future owners of the item as well as the manufacturer to determine the long term effects of the items that it creates. In flow/structure, the user adds information to the object story for a product object story

1501 1502 1502 1503 1504 1505 At, an event occurs with respect to the product that the user wishes to record. This event could be maintenance or repair, or it could be repurposing or disposal of the product. The user interacts with their consumer computing device to identify the product at. The consumer computing device identifies the product to the story manager at. The story manager retrieves the appropriate object story at, determines the permissions of the consumer, and receives the information that user wishes to specify atand. Embodiments of this can include product ownership registration, maintenance records for the product, user reviews, or indications of the disposal or recycling of the product.

1505 The information supplied incan be either free-form (such as an email) or it can be formatted into claim, evidence, and object story structures by the consumer computing device. For example, a transmission overhaul could be specified by the consumer computing device as a set of claims and evidence of the date and time of the work, along with a product object story for the replacement parts, a facility object story of the location where the work took place, and a company object story representing the person performing the work containing their certifications to perform the work correctly.

1506 The story manager integrates this information into the appropriate sections of the product object story at. This information can now be part of the record for the given product item.

16 FIG. 1600 illustrates an operational flow/algorithmic structurethat describes bidirectional business information flow using distributed linked object stories in accordance with some embodiments.

250 201 204 2 FIG. As stated above, the object story structures may be hierarchical and fully recursive. An object story for an item may reference the object story structures for each of its constituent components and may also reference object stories for the facilities, entities, and locations involved in the manufacture. When the computing elements that manage the object story structures (see e.g., OSM systemof) integrate the object story of an component, they can be copied locally by the story manageror they can remain distributed to the component supplier and be managed through the remote substory access module. In the embodiment where they are distributed, the object story computing elements can maintain business-to-business intelligence and communications through use of the integrated object story structures. Information about component usage and quality can be added to the component object story by the manufacturer to be communicated to the component producer. Information about changes to the component status—such as defects or recalls—can be communicated to the manufacturer and traced at the serial number level. This flow shows this bi-directional communications path through alerts sent from the product manufacturer's object story computing elements to the component supplier's object story computing elements.

1600 1601 1603 1604 1605 1606 1607 1608 1609 The flow/structureshows the bi-directional nature of the business information that is available in a distributed embodiment of an object story computing system. In operations-, the manufacturing information system determines that a particular component has been included in the manufacturing process and links the component's object story into the product object story. In doing so, the remote substory access element communicates with its peer at the supplier site and retrieves a link to the component object story structures at. The manufacturer's manufacturing information system then creates new claim and evidence elements into the component's object story structures to identify the product into which the component was included at. Sometime later at, the manufacturing information system at the component supplier is notified of a defect in the component. The manufacturing information system at the component supplier adds claims and evidence elements to the object story structure noting the fault at. It then retrieves the claim and evidence elements added to the component object story by the manufacturer identifying the manufactured product in which the defective component was included at. The component manufacturing information system can then notify the product manufacturer of a recall or product defect through, for example, an out-of-band mechanism at.

17 FIG. 1700 illustrates an operational flow/algorithmic structurethat describes legacy partner integration in accordance with some embodiments.

6 7 FIGS.and 2 FIG. 2 FIG. 2 FIG. 211 212 The core of the communication between the peers in the object story process is focused on the object story structures (see, for example,). Some entities may not have a full object story aware infrastructure as defined in. These entities are considered legacy entities. They may have a wide range of business information system with varying degrees of sophistication; some may be running sophisticated business software that is not object story aware, while others may be small suppliers that are run mostly by email or paper-based transactional systems. In order to integrate those suppliers into an object story computing environment, a legacy adapter (see, for example, legacy adapterof) is defined as a computing element that bridges between a legacy system (for example, legacy systemof) and the object story aware system.

1700 1700 The flow/structuredescribe operations of legacy adapter computing element and the legacy system to ensure that bi-directional communication is enabled between the object story aware system and a legacy entity. Other embodiments can support other configurations where the supplier may be object story aware but the manufacturer is using legacy systems. The flow/structureshows only one message flowing from the supplier to the manufacturer and one message flowing back to the legacy system. In other embodiments many different kinds of messages can be supported between these entities.

1700 1701 1702 202 203 1703 2 FIG. 2 FIG. In flow/structure, the process begins atwhere a legacy system sends a non-object aware message to the manufacturer. This message can be in a plurality of formats including machine-to-machine business messages, email, text messages, etc. The legacy adapter receives the message and, at, identifies the sender from the contents of the message and looks up the identity of the sender in the object story computing system. This includes the authorization and authentication information from the authentication manager (see, for example, authentication managerof) and the supplier's cryptographic identity from the certification manager (see, for example, certification authority moduleof). At, the legacy adapter parses the message. There are a wide range of embodiments comprehended in this step from determining the fields of an electronic machine-to-machine message to natural language processing on a human generated email message.

1704 1705 The legacy adapter determines the content of the message and identifies the changes that must take place in the object story system due to this message. For example, this could be an email message identifying shipment of an ingredient and the legacy adapter needs to create the corresponding object story structures for the ingredient, the supplier, and the transporter. It could also reference an entity which already has an object story structure representation in which case the legacy adapter looks up the necessary object story structure based on identifying information in the message at. The legacy adapter then reads and writes claims and evidence elements in order to carry out the actions required by the message at. This may include encapsulating the original message in an evidence element as proof that the message was received and acted upon. The legacy adapter takes these actions with the identity of and on behalf of the legacy system.

1706 1704 1707 1708 1709 At, the legacy adapter monitors select object story structures for changes that must generate information flows back to the legacy system. When the legacy adapter creates an object story at, it assumes responsibility for monitoring the object story structure and proactively sending information about the item to the legacy system. When a change occurs on a monitored object story, the legacy adapter determines when a message is required to be sent to the legacy system and the necessary format of that message at. The legacy adapter formats the appropriate message, gathers any necessary login information to the legacy system, authenticates itself and sends the message at. This message may be in any of a number of formats, from a properly formatted machine-to-machine business information message, to a human readable e-mail, text message, or a synthesized voice phone message. The legacy adapter then records the message as a claim and evidence element documenting the message at.

18 FIG. 1800 1800 202 illustrates an operation flow/algorithmic structurethat may be used to authenticate a user's access to an object story in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by the authentication manageror components thereof.

1800 1804 206 250 202 250 201 203 204 202 1800 The flow/structuremay include, at, receiving authentication information in an authentication request from a user. In some embodiments, the authentication request may be received from a user device such as consumer computing deviceor any other user device. In some embodiments, the authentication request may be received from another entity based on a request from the user device. For example, the user device may request access to an object story, and another element of the OSM systemmay generate and send the request to the authentication managerbased on the request from the user device. In some embodiments, the other element of the OSM systemmay be, for example, the story manager, the certification authority, or the remote story access moduleand may be from the same entity or a different entity that controls the authentication managerperforming the flow/structure.

1800 1808 The flow/structuremay further include, at, determining whether the user is authenticated. Any of the variety of authentication mechanisms may be used for this process.

1808 1800 1812 250 If, at, it is determined that the user is not authenticated, the flow/structuremay further include, rejecting the authentication request. The rejection of the authentication request may include generating and sending a message to the requesting entity, for example, the user device or another entity of the OSM system.

1808 1800 2 213 FIGS., If, at, it is determined that the user is authenticated, the flow/structuremay further include, providing a security token for the user. In some embodiments, the security token may be provided to a Manufacturing Info System () or another device (for example, the requesting entity).

19 FIG. 1900 1900 201 illustrates an operation flow/algorithmic structurethat may be used to generate an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by the story manageror components thereof.

1900 1904 The flow/structuremay include, at, receiving an authenticated user request to generate an object story. The request may have been authenticated as described elsewhere herein. The object story may correspond to a product object story, a component object story, a facility object story, a location object story, or an entity object story.

1900 1908 The flow/structuremay further include, at, identifying claims/evidence elements. The claim element may include an assertion about conditions related to the product facility, location or entity, and the evidence element may support the veracity of the assertion. In some embodiments, the claims may correspond to one or more lifecycle elements such as, for example, an origin story element, a custody story element, a consumption story element, or conversion story element. In some embodiments, one or more requests may be sent to other computing systems to identify the claims or evidence elements.

1900 1912 The flow/structuremay further include, at, generating an object story data structure to include the claim/evidence elements. In some embodiments, the inclusion of the claim/evidence elements may be done by incorporating a series of links from the object story data structure to lifecycle elements of the data structure, to claim/evidence elements or to other object story data structures as described elsewhere herein.

1900 1916 The flow/structuremay further include, at, storing the object story data structure in an access restricted manner. Portions of the object story data structure, including portions incorporated through one or more links, may be stored in a common database, a distributed database across multiple sites, or in one or more distributed ledgers. Access to parts of the object story data structure may be restricted based on entity roles.

20 FIG. 2000 2000 250 illustrates an operation flow/algorithmic structurethat may be used to generate/alter an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of an OSM systemor components thereof.

2000 2001 The flow/structuremay include, at, receiving, from a user, a request to create an object story data structure to hold information about a product, facility, location, company or entity.

2000 2002 The flow/structuremay further include, at, creating the object story data structure in storage and returning and identifier of the object story. The object story data structure may be any of the types of object story data structures. The identifier may be a GUID that may be used in later accesses (either read or write accesses) to the object story data structure.

2000 2003 The flow/structuremay further include, at, receiving the object story identifier (for example, the GUID) and a component object story to include into the object story data structure. The component object story may include information about a component (for example, an ingredient, a part, or subassembly) of a product or about a sub-part of a larger entity/location/facility (for example a building as a part of a facility, or a department as part of a company). The component object story may have been created by an entity different than the entity creating the main object story.

2000 2004 The flow/structuremay further include, at, altering the storage of the object story data structure to include, directly or by the linked reference, the component object story.

2000 2005 The flow/structuremay further include, at, receiving an object story identifier (e.g., the GUID) and the cryptographically linked set of claim and evidence elements to include, directly or by linked reference, into the object story.

2000 2006 The flow/structuremay further include, at, altering the storage of the object story data structure to include, directly or by the linked reference, the cryptographically linked set of claim and evidence elements.

21 FIG. 2150 2160 2150 2160 illustrates operation flows/algorithmic structuresandthat may be used to generate an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of a company's object story aware system (for example, a legacy adapter) and flow/structuremay be performed by a participant in the lifecycle process with only legacy information systems.

2160 2101 The flow/structuremay include, at, generating and sending a message in a commonly used business message format. The format may be E/biz, email, text, phone, etc. The message may be a notification of the supplied component (for example, part, ingredient, or subassembly)

2150 2102 2101 The flow/structuremay include, at, receiving the message (sent at) from the remote system.

2150 2103 The flow/structuremay further include, at, parsing the message to detect information related to the component and information on the identity of the sender.

2150 2104 The flow/structuremay further include, at, creating an object story or portion thereof based on the information of the supplied component.

2150 2105 The flow/structuremay further include, at, creating and cryptographically linking claim and evidence elements as needed from the information in the message using the local cryptographic information of the message sender.

2150 2106 The flow/structuremay further include, at, supplying the local story manager with a new object story (or portion thereof) for the item being referenced.

2150 2107 The flow/structuremay further include, at, generating a reply to the message that the information has been received and integrated with information that can be used to identify the object story (or portion thereof) in the future.

2150 2108 2102 The flow/structuremay further include, at, sending the reply message using a commonly used business message format. The message format may be similar to that of the message received at.

2160 2109 The flow/structuremay further include, at, receiving the reply message.

22 FIG. 2250 2260 2250 2260 illustrates operation flows/algorithmic structuresandthat may be used to provide an indication of a change of an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of a company's object story aware system (for example, a legacy adapter) and flow/structuremay be performed by a participant in a lifecycle process with only legacy information systems.

2250 2201 The flow/structuremay include, at, determining the changes occurred to an object story related to an object associated with a legacy participant. The object story may correspond to a product or component that was sourced by the legacy participant. In other embodiments, the object story may be one created to represent the facility or company of the legacy participant.

2250 2202 The flow/structuremay further include, at, generating an indication message to the legacy participant indicating that the stored information has been updated.

2250 2203 The flow/structuremay further include, at, sending the indication message using a commonly used business message format.

2260 2204 2203 The flow/structuremay include, at, receiving the indication message sent at.

23 FIG. 2350 2360 2350 2360 illustrates operation flows/algorithmic structuresandthat may be used to update an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of a company's object story aware system (for example, a legacy adapter) and flow/structuremay be performed by a participant in a lifecycle process with only legacy information systems.

2360 2301 The flow/structuremay include, at, generating and sending a message in a commonly used business message format. The message may serve as a notification of an update to an object/component provided by the legacy information system.

2350 2302 2301 The flow/structuremay include, at, receiving the message (sent at) from the remote system.

2350 2303 The flow/structuremay further include, at, parsing the message to detect information identifying the updated object/component and the identity of the sender.

2350 2304 The flow/structuremay further include, at, creating and cryptographically linking claim and evidence elements or an entire object story as needed from the information in the message using the local cryptographic information of the message sender.

2350 2305 The flow/structuremay further include, at, supplying the local story manager with the claim and evidence elements or newly created object story to be integrated into an object story with the identity of the remote supplier.

2350 2306 The flow/structuremay further include, at, generating a reply to the message to indicate that the information has been received and integrated with the indicated object story.

2350 2307 2302 The flow/structuremay further include, at, sending the reply message using a commonly used business message format. The message format may be similar to that of the message received at.

2360 2308 The flow/structuremay further include, at, receiving the reply message.

24 FIG. 2450 2460 2450 2460 illustrates operation flows/algorithmic structuresandthat may be used to access information of an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of a company's object story aware system (for example, a legacy adapter) and flow/structuremay be performed by a participant in a lifecycle process with only legacy information systems.

2460 2401 The flow/structuremay include, at, generating and sending a message in a commonly used business message format. The message may serve as a request for information on an object or component.

2450 2402 2401 The flow/structuremay include, at, receiving the message (sent at) from the remote system.

2450 2403 The flow/structuremay further include, at, parsing the message to detect information identifying the object/component and information on the identity of the sender.

2450 2404 The flow/structuremay further include, at, looking up information on the identified object/component in a corresponding object story with the local story manager.

2450 2405 The flow/structuremay further include, at, generating a reply to the message with the information that the legacy system is authorized to view.

2450 2406 2402 The flow/structuremay further include, at, sending the reply message using a commonly used business message format. The message format may be similar to that of the message received at.

2460 2407 The flow/structuremay further include, at, receiving the reply message.

25 FIG. 2500 2500 200 illustrates an operation flow/algorithmic structurethat may be used to provide secured access to an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the computing system, which may be a company's object story aware system.

2500 2501 18 FIG. The flow/structuremay include, at, receiving authentication information, completing the authentication, and supplying a security token. The authentication information may be received in an authentication request from a component supplier object story aware system. This may be done consistent with the description of.

2500 2502 2501 The flow/structuremay further include, at, receiving a message from a remote object story aware system with a security token representing the remote object story user's rights in the local system. The security token may be the same previously provided at.

2500 2503 The flow/structuremay further include, at, determining whether the security token is valid for the requested access.

2503 2500 2504 2505 If it is determined, at, that the security token is not valid for the requested access, the flow/structuremay include rejecting the request at, and sending a message of rights violation at.

2503 2500 2506 If it is determined, at, that the security token is valid for the requested access, the flow/structuremay include accessing the required object story with the authentication information of the local system at.

2506 2500 2507 Following, the flow/structuremay include,, altering the storage of the object story to include the contents of the received object story. In other embodiments, other access operations may be performed including maintaining portions of the object story as links to other entities.

2500 2508 The flow/structuremay further include, at, sending a message indicating success.

26 FIG. 2600 2600 200 illustrates an operation flow/algorithmic structurethat may be used to access an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the computing system, which may be any participant's object story aware system.

2600 2601 The flow/structuremay include, at, creating an authentication request. The authentication request may be sent to a company's object story aware system. The authentication request may include authentication information to authenticate a user of the remote object story aware system.

2600 2602 The flow/structuremay further include, at, creating a message containing a component object story that is to be included into a larger object story owned by the receiver of the message.

2600 2603 The flow/structuremay further include, at, receiving a message indicating either a rights violation or successful incorporation of the component object story into the object story.

27 FIG. 2700 2700 200 illustrates an operation flow/algorithmic structurethat may be used to provide secured access to an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the computing system.

2700 2701 The flow/structuremay include, at, receiving authentication information from a local or remote system.

2700 2702 The flow/structuremay further include, at, determining whether the authentication information is valid.

2702 2700 2703 If it is determined that the authentication information is not valid at, the flow/structuremay further include, at, rejecting the authentication request. The rejecting of the authentication request may include sending a message to the entity providing the authentication information or the related request.

2702 2700 2704 If it is determined that the authentication information is valid at, the flow/structuremay further include, at, supplying a security token representing the validated authentication of the requesting entity. The supplying may be done by transmitting a message to the system requesting authentication or to another entity.

2700 2705 2704 The flow/structuremay further include, at, receiving a request to access a portion of an object story with a security token attached. The security token may be the same provided at, or may be derived therefrom. The request to access may be a request to retrieve a portion of the object story or may be a request to alter a portion of the object story. As used herein, alter could include any modification including supplementing, amending, appending, etc.

2706 At, a module may obtain the access rights of the user based on the authenticated identity. In some embodiments, the access rights may be locally stored, or may be stored by a remote entity, in which case, a request may be sent to the remote entity for the access rights. The access rights may provide different levels of access to different portions of an object story based on roles that an entity plays with respect to a particular object story

2707 At, the operation may include determining whether the user has sufficient rights to perform the requested operation.

2707 2700 2708 If it is determined that the user does not have sufficient rights for the requested access at, the flow/structuremay advance to rejecting the request at. The rejecting of the request may include sending a message to the entity requesting the access.

2707 2700 It is determined that the user has sufficient rights for the requested access at, the flow/structuremay further include performing the requested access. Performing the requested access may include retrieving the requested portion of the indicated object story from storage or making the requested alteration on the portion of the indicated object story. In some embodiments the output may be tailored to include only those portions to which the requester has rights. For example, if the request is for a product object story, but the user only has rights to access one of the component object stories within the product object story, the output may only include the component object story. The output may also provide an indication that the request for other parts of the product object story has been rejected

2700 2710 The flow/structuremay further include, at, transmitting a message with the requested portion or an indication of making the requested change.

28 FIG. 2800 2800 200 illustrates an operation flow/algorithmic structurethat may be used to change an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the computing system.

2800 2801 The flow/structuremay include, at, receiving a request to include new content into an existing object story with the security token attached. The content may be claim/evidence elements or other object stories.

2800 2802 27 FIG. The flow/structuremay further include, at, using the security token to authenticate identity of the user and obtain access rights of the user based on the authenticated identity. This may be done similar to that discussed above with respect to.

2803 2800 2804 If it is determined that the rights are not sufficient for the requested access at, the flow/structuremay include rejecting the request at. The rejecting of the request may include sending a message to the entity requesting the access.

2803 2800 2805 If it is determined that the rights are sufficient for the requested access at, the flow/structuremay further include receiving the portion of the object story relevant to the content from storage both local and distributed at.

2800 2806 In the event the content includes claim/evidence elements, the flow/structuremay further include, at, cryptographically linking the claim/evidence elements together so they cannot be deleted or altered.

2800 2807 The flow/structuremay further include, at, making the requested change in the indicated object story as stored in both local and distributed storage.

2800 2805 2807 In some embodiments, the flow/structuremay not include a physical receipt of the distributed storage instances at. Instead, the requested changes made atmay be accomplished by sending messages to one or more remote entities that managed the distributed storage instances.

29 FIG. 2900 2900 200 illustrates an operation flow/algorithmic structurethat may be used to generate claims/elements in an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the computing system.

2900 2901 The flow/structuremay include, at, identifying a unique identifier of an object (for example, product, component, facility, entity, or location) being monitored. Identification may be based on a sensor input, user input, or input from information monitoring systems.

2900 2902 The flow/structuremay further include, at, retrieving the object story of the identified object from storage. In some embodiments, the object story may be retrieved from local or remote storage.

2900 2903 The flow/structuremay further include, at, obtaining sensor data or other input about conditions of the environment. The sensor data/other input may be automatically generated or user initiated.

2900 2904 The flow/structuremay further include, at, creating claims/evidence elements or object stories corresponding to the sensor data or other input.

2904 2900 2905 In the event the claims and evidence elements are created at, the flow/structuremay further include, at, cryptographically linking the claims and evidence elements so that they cannot be altered.

2900 2906 The flow/structuremay further include, at, altering the storage of the object story for the monitored object to include the object stories or cryptographically linked set of claim/evidence elements.

30 FIG. 3000 3000 200 illustrates an operation flow/algorithmic structurethat may be used to manage an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the computing system(for example, a user's consumer computing device).

3000 3001 The flow/structuremay include, at, initiating a session with a user's consumer computing device.

3000 3002 The flow/structuremay further include, at, determining a unique identifier of an object, for example, a product, a component, a facility, a location, or an entity. This may be done by scanning a portion of the label, a QR code, recognizing the information from an image, or some other sensor/user input.

3000 3003 214 2 FIG. The flow/structuremay further include, at, generating a request to the public interface module () of the owner of an object story of the object. The request may be for some or all of the object story.

3000 3004 3003 The flow/structuremay further include, at, receiving a fulfilled request. The fulfilled request may include some or all of the object story requested at.

3000 3006 The flow/structuremay further include, at, determining whether the user has an established set of values.

3006 3000 3007 If it is determined, at, that the user has an established set of values, the flow/structuremay further include, at, creating a grouping of claims and evidence elements most relevant to the user's values.

3006 3000 3008 If it is determined, at, that the user does not have an established set of values, the flow/structuremay further include, at, creating a grouping of claims and evidence elements grouped according to a default configuration. The default configuration may be a grouping of information that is commonly requested.

3000 3009 The flow/structuremay further include, at, verifying the security of each claim and evidence element.

3000 3010 The flow/structuremay further include, at, displaying the group of claims and evidence elements through a user interface with an indication of the level of strength of the evidence for each of the claims.

3000 3011 The flow/structuremay further include, at, allowing the user to request deeper information about the object, or component thereof, through a user interface.

3000 3012 The flow/structuremay further include, at, retrieving and displaying the requested deeper information through the user interface.

3000 While aspects flow/structureare described as being performed by a consumer computing device, in other embodiments, some or all of these operations may be performed by another entity. For example, some or all of the operations may be performed by the manufacturer's object story aware system. In these embodiments, the manufacturer's object story aware system may retrieve the established set of values for a particular user directly from the user or from a database storing such information.

3000 3000 The flow/structureshows the user interacting with a single entity for information on the object story of interest. Because of the nature of the object story structure to contain links to other object stories stored by other entities, this action may require consulting a number of other entity's object story aware systems, and performing the flow/structurewith those systems.

31 FIG. 3100 3100 200 illustrates an operation flow/algorithmic structurethat may be used to provide requested information related to an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the computing system, which may be a company's object story aware system.

3100 3101 The flow/structuremay include, at, receiving a request for information on an identified object (for example, product, component, facility, location, or entity) and retrieving the portions of the corresponding object story that are accessible. The request may be sent by a user's consumer computing device. In some embodiments, this request may include authentication information from the user, for example, a security token.

3100 3102 The flow/structuremay further include, at, fulfilling the request by transmitting the Object Story elements on the network.

3100 3101 3102 In some embodiments, the flow/structuremay further include determining that the user has the proper security credentials for accessing the portion of the object story prior to fulfilling the request. In some embodiments, the request atmay not include any authentication information. In such cases, the portions of the object story that are provided atmay be restricted to publicly-available portions. Thus, some object stories may provide a baseline of information that may be accessed (likely in a read-only manner) even without user authentication and rights verification.

This flow may occur at the manufacturer's systems or it may be implemented by a third-party which is a decentralized store of the object story information across multiple manufacturers.

32 FIG. 3200 3200 200 illustrates an operation flow/algorithmic structurethat may be used to define and execute a contract with terms related to an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the computing system.

3200 3201 The flow/structuremay include, at, establishing a contract between parties within a lifecycle of a product. The contract may be written or electronic.

3200 3202 The flow/structuremay further include, at, including contract terms that reference claims and evidence elements that may be present in the various object stories for the product, component, facility, location, or entity referenced in the contract.

3200 3203 The flow/structuremay further include, at, completing the contract between the two parties in the lifecycle of the product or thereafter.

3200 3204 The flow/structuremay further include, at, retrieving the portions of the object stories that are relevant to the contract.

3200 3205 The flow/structuremay further include, at, determining the level of value to be transferred between the parties based on the claims and evidence elements in the strength of those evidence elements.

3200 3206 The flow/structuremay further include, at, transferring the value between the parties.

3200 3207 The flow/structuremay further include, at, notifying the parties of the claims and evidence and the value transferred.

3200 3208 The flow/structuremay further include, at, creating new claims and evidence elements based on the contract status and value transferred and cryptographically linking those claims and evidence elements.

3200 3209 The flow/structuremay further include, at, integrating the cryptographically linked claims and evidence elements into the relevant object stories.

33 FIG. 3300 3300 250 illustrates an operation flow/algorithmic structurethat may be used to add information to an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the OSM system(for example, consumer computing device or any system present in the lifecycle for an object that is object story aware).

3300 3301 The flow/structuremay include, at, initiating a session with the user's consumer computing device. This may consist of using software that is designed to access the object story or utilize functionality within another party's software (such as using a “provided feedback” button within an application provided by a third-party).

3300 3302 The flow/structuremay further include, at, determining a unique identifier of an object. This may be done by scanning a portion of a label, a QR code, recognizing a product or company from an image, or some other user/sensor input.

3300 3303 The flow/structuremay further include, at, generating a request to a public network interface of the owner of the object story of the object to add information to the object story for the product. This may be at the manufacturer of a product, the current owner, or a third-party service which is a decentralized store of object story information for many products. The request may also include the user's identity and authentication information corresponding to the user.

3300 3304 The flow/structuremay further include, at, receiving a reject message or a success message. The reject/success message may be received from the object story aware system.

3300 3305 If the reject message is received, the flow/structuremay further include notifying the user of the rejection at.

3300 3306 If the success message is received, the flow/structuremay further include, at, generating and sending a message containing the information about the lifecycle of the identified object.

3300 3307 The flow/structuremay further include, at, receiving a subsequent success message to indicate the information has been incorporated into the object story of the product.

34 FIG. 3400 3400 250 illustrates an operation flow/algorithmic structurethat may be used to add information to an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the OSM system, which may be a manufacturer's or owner's object story aware system or the systems present at a third-party decentralized store of object information that supports multiple products.

3400 3401 The flow/structuremay include, at, receiving a request to create information about a lifecycle of an object. The request may be received from a user's consumer computing device.

3400 3402 The flow/structuremay further include, at, determining whether the authentication information in the request is valid.

3400 3403 3405 If it is determined that the authentication information in the request is not valid, the flow/structuremay include, at, rejecting the request and, at, generating and transmitting a rejection message to the user's consumer computing device.

3400 3406 3401 If it is determined that the authentication information in the request is valid, the flow/structuremay include, at, generating and sending an authentication success message. The authentication success message may indicate that the authentication is valid and may request lifecycle information. In other embodiments, the lifecycle information may be initially transmitted in the request received at.

3400 3407 The flow/structuremay further include, at, receiving the message with the lifecycle information and the object identification. In other embodiments, the identifier may be an identifier of an object story.

3400 3408 The flow/structuremay further include, at, finding an object story for the identified object in storage. The storage may be remote or local.

3400 3409 The flow/structuremay further include, at, creating and cryptographically linking claims and evidence elements or further object stories as needed depending on the information supplied by the user. For example, the user may be notifying a system that manages the object story for a car that they have taken ownership. The user may supply a claim and evidence of ownership along with an object story representing information about themselves. In some embodiments, if the user has its own OSM, management of the car's object story may also be passed to the user's OSM once the new ownership is verified.

3400 3410 The flow/structuremay further include, at, integrating the cryptographically linked claims and evidence elements or object stories into the object story of the object.

3400 3411 The flow/structuremay further include, at, altering the storage for the indicated object story to include the new claims and evidence elements or object stories.

3400 3412 The flow/structuremay further include, at, generating and sending a success message to the user. This may indicate that the lifecycle information has been included in the object story.

35 FIG. 3500 3500 250 illustrates an operation flow/algorithmic structurethat may be used to manage an object story in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the OSM system, which may be a company's object story aware system.

3500 3501 The flow/structuremay include, at, determining that a component has been included in manufacture or maintenance of a product. The component may be included in the maintenance of the product by replacing an existing component or by adding an additional component.

3500 3502 The flow/structuremay further include, at, authenticating to the local story manager and retrieving the object story for the indicated product.

3500 3503 The flow/structuremay further include, at, requesting the component object story from a local remote sub story access module.

3500 3504 The flow/structuremay further include, at, determining, by the remote substory access module, that a supplier is indicated and authenticating with the supplier's remote substory access module to retrieve the component object story.

3500 3505 The flow/structuremay further include, at, receiving a reject or success message from the supplier remote substory access module.

3500 3506 If the reject message is received, the flow/structuremay further include receiving the request rejection and notifying the user at.

3500 3507 If the success message is received, the flow/structuremay further include receiving the reply message at. The reply message may include the component object story or portions thereof.

3500 3508 The flow/structuremay further include, at, integrating the component object story into the product object story. The integration may be by directly including the component object story or by linking the component object story into the product object story. This integration may also include the object stories for facilities, location, or entities that performed the integration.

3500 3509 The flow/structuremay further include, at, generating and sending a message indicating that the component has been used in the manufacture of an indicated/identified product. The message may be sent to the supplier of the component.

3500 3510 The flow/structuremay further include, at, monitoring link component object stories and noticing a change to a remote object story or receiving a message of a change (e.g., a defect) of a component object story.

3500 3511 The flow/structuremay further include, at, looking up the indicated component object story in the local story manager to determine all affected product object stories.

3500 3512 The flow/structuremay further include, at, issuing a notice (for example, a recall notice) of all affected products.

36 FIG. 3600 3600 250 3600 illustrates an operation flow/algorithmic structurethat may be used to update an object story data structure in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the OSM system, which may be a component supplier's object story aware system. In some embodiments, one or more of the operations of the flow/structuremay be performed by a remote sub story access module.

3600 3601 The flow/structuremay include, at, receiving an access request and an indicated object story. The request may be received from a manufacturer's object story aware system.

3600 3602 The flow/structuremay further include, at, determining whether the authentication information in the request is valid.

3600 3603 3604 If the authentication information in the request is not valid, the flow/structuremay include rejecting the request atand generating and transmitting a rejection message at. The rejection message may be transmitted to the manufacturer's object story aware system.

3600 3605 If the authentication information in the request is valid, the flow/structuremay include retrieving the indicated object story from the local story manager at.

3600 3606 The flow/structuremay include, at, formatting and sending a reply message containing either the object story information directly or link to a public network interface where the object story may be retrieved.

3600 3607 3600 The flow/structuremay include, at, receiving an integration message. The integration message may indicate the component has been incorporated into an indicated/identified object). The flow/structuremay further include, at generating and cryptographically linking claim and evidence elements about the object into the component Object Story. This information may include additional object stories for the facilities or entities that incorporated the component.

3600 3608 The flow/structuremay include, at, causing the story manager to save the new information elements as part of the component object story.

37 FIG. 3700 3700 250 3700 illustrates an operation flow/algorithmic structurethat may be used to notify an entity of a defect in accordance with some embodiments. In some embodiments, the flow/structuremay be performed by one or more modules of the OSM system, which may be a component supplier's object story aware system. In some embodiments, one or more of the operations of the flow/structuremay be performed by a supplier information system.

3700 3701 The flow/structuremay include, at, determining a defect in a component. The component may be one that was provided by the supplier.

3700 3702 The flow/structuremay include, at, accessing the object story for the component. The object story may be accessed from local or remote storage.

3700 3703 The flow/structuremay include, at, creating and cryptographically linking claim and evidence elements indicating the defect.

3700 3704 The flow/structuremay include, at, integrating the defect claim and evidence elements into the component object story.

3700 3705 The flow/structuremay include, at, sending a message to a user associated with the component notifying them of the defect. The user may have incorporated the component into their product

38 FIG. 3800 3800 260 250 illustrates a devicein accordance with some embodiments. The devicemay implement one or more of the computing information systemsor OSM system.

3800 3801 3802 3803 3804 3805 3800 3800 38 FIG. The devicemay include processors, memory/storage circuitry, a user interface, a network interface, and sensors. The components of the devicemay 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 ofis intended to show a high-level view of some of the components of the device. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

3800 3806 The components of the devicemay be coupled with various other components over one or more interconnects, 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.

3801 3802 3800 3801 3807 3802 3807 3800 3808 The processorsmay include processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory/storageto cause the deviceto perform operations as described herein. For example, in some embodiments, the processorsmay access object story codestored in the memory/storage. Upon executing the object story codethe devicemay manage (including generating, accessing, storing, etc.) object story data structuresas described herein.

3802 3800 3802 3801 3802 3801 3804 3802 The memory/storagemay include any type of volatile or non-volatile memory that may be distributed throughout the device. In some embodiments, some of the memory/storagemay be located on the processorsthemselves (for example, L1 and L2 cache), while other memory/storageis external to the processorsbut accessible thereto via a memory interface, which may be part of I/O interface. The memory/storagemay 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.

3803 3800 3803 3800 The user interfaceincludes various input/output (I/O) devices designed to enable user interaction with the device. The user interfaceincludes 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 alia, 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.

3805 The sensorsmay include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) 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.

3804 The network interfacemay 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).

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.

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.

Some non-limiting examples are provided below.

Example 1 includes a method comprising: obtaining an identifier of an object and a token to authenticate an identity of a user requesting information about the object, wherein the object is a facility, entity, or a location; transmitting, to an object story management (OSM) system, the identifier and the token; receiving, from the OSM system, one or more portions of an object story data structure for the object, the one or more portions to include: a claim element that includes an assertion about the object and an evidence element that is to support veracity of the assertion, or a component object story data structure for a component within the object; determining whether the user has a profile of values accessible by the system; and providing at least one portion of the one or more portions of the object story data structure based on the determination of whether the user has a profile of values accessible by the system.

Example 2 includes the method of example 1 or some other example herein, further comprising: receiving user input or a scanner input to obtain the identifier.

Example 3 includes the method of example 1 or some other example herein, further comprising: transmitting the identifier to a public interface module of the OSM system that manages the object story data structure for the object.

Example 4 includes the method of example 1 or some other example herein, wherein determining whether the user has a profile of values comprises: determining the user has a profile of values that is stored and accessible to the system.

Example 5 includes the method of example 1 or some other example herein, wherein determining whether the user has a profile of values comprises: determining the user has a profile of values that are inferred from a history of user interactions accessible to the system.

Example 6 includes the method of example 4 or example 5 or some other example herein, further comprising: selecting the at least one portion from the one or more portions based on the profile of values.

Example 7 includes the method of example 1 or some other example herein, wherein providing at least one portion comprises: formatting and displaying the at least one portion of the one or more portions.

Example 8 includes a method of example 7 or some other example herein, wherein the at least one portion comprises a first claim element that includes a first assertion about the object, a first evidence element to support veracity of the first assertion with a first level of evidence on a scale of proof, and formatting and displaying the at least one portion comprises: formatting and displaying the first claim element based on the first level.

Example 9 includes the method of example 8 or some other example herein, wherein the at least one portion further comprises a second claim element that includes a second assertion about the object, and a second evidence element to support veracity of the second assertion with a second level of evidence on the scale of proof, wherein the first level is higher than the second level; and formatting and displaying the at least one portion comprises: formatting and displaying the second claim element based on the second level, wherein the format and display of the first and second claim elements is to provide an indication that the first claim element is associated with a higher level of evidence on the scale of proof than the second claim element.

Example 10 includes a method comprising: receiving a request that identifies an object, wherein the object is a facility, entity, or location, and the interface is a network interface or a user interface; and obtaining one or more interests of a user with respect to aspects of the object; displaying, based on the one or more interests, information corresponding to a claim element of an object story data structure, the claim element to include an assertion about the object.

Example 11 includes a method of example 10 or some other example herein, wherein the claim element is a first claim element, and the method further comprises: identifying a first evidence element associated with the first claim element, the first evidence element to support veracity of the first assertion with a first level of evidence on a scale of proof; and displaying the information corresponding to the first claim element based on the first level of evidence.

Example 12 includes the method of example 10 or some other example herein, further comprising: receiving an input from the user; and obtaining the one or more interests based on the input.

Example 13 includes the method of example 12 or some other example herein, further comprising: providing, to the user, a plurality of available interests for selection; and receiving the input with selections of the one or more interests from the plurality of available interests.

Example 14 includes the method of example 13 or some other example herein, further comprising: providing, to the user, a weighting field; and receiving, in the input from the user, weighting values provided in the weighting field, the weighting values associated with individual interests of the one or more interests.

Example 15 includes the method of example 14 or some other example herein, wherein a first weighting value is associated with a first interest of the one or more interests; and a second weighting value is associated with a second interest of the one or more interests, the first weighting value to correspond to a first level of importance and the second weighting value to correspond to a second level of importance, the first level being different from the second level.

Example 16 includes the method of example 10 or some other example herein, further comprising: receiving a record of user interaction; and transmitting, to the user based on the record of user interaction, a suggestion of a new interest, a modification of an interest of the one or more interests, or a modification of a weighting value of the weighting values associated with individual interests of the one or more interests.

Example 17 includes the method of example 10 or some other example herein, further comprising: receiving a record of user behavior related to aspects of the object; and obtaining the one or more interests based on the record of user behavior.

Example 18 includes a method comprising: obtaining an identifier of an object, wherein the object is a facility, entity, or a location; transmitting a request to an object story management (OSM) system with the identifier; receiving, from the OSM system, one or more portions of an object story data structure for the object, the one or more portions to include: a claim element that includes an assertion about the object and an evidence element that is to support veracity of the assertion, or a component object story data structure for a component within the object; determine whether the user has a profile of interests accessible by the system; and providing at least one portion of the one or more portions of the object story data structure based on the determination of whether the user has a profile of interests accessible by the system.

Example 19 includes the method of example 18 or some other example herein, further comprising: receiving user input or scanner input to obtain the identifier.

Example 20 includes the method of example 18 or some other example herein, further comprising: transmitting the identifier to a public interface module of the OSM system that manages the object story data structure for the object.

Example 21 includes a method of example 18 or some other example herein, wherein determining whether the user has a profile of interests comprises: determining the user has a profile of interests that is stored and accessible.

Example 22 includes the method of example 18 or some other example herein, wherein determining whether the user has a profile of interests comprises: determining the user has a profile of interests that are inferred from a history of user interactions.

Example 23 includes method of example 21 or 22 or some other example herein, further comprising: selecting the at least one portion from the one or more portions based on the profile of interests.

Example 24 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1-23, or any other method or process described herein.

Example 25 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-23, or any other method or process described herein.

Example 26 may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1-23, or any other method or process described herein.

Example 27 may include a method, technique, or process as described in or related to any of examples 1-23, or portions or parts thereof.

Example 28 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-23, or portions thereof.

Example 29 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-23, or portions thereof.