CN100378714C - Context-Oriented and Real-Time Project Tracking System Structure and Context Analysis - Google Patents

Abstract

A method and device for tracking items in real time and a method and device for tracking items in an environment-oriented manner, which include computer program products. A tag attached to an item is read and information read about the tag from the tag and from environmental information is provided by at least two businesses and used to maintain information about the item and to be visible to businesses in the supply chain. The configuration information may correspond to a world model that tracks the item and conditions affecting the item, such as geospatial events and traffic delays. The visibility of configuration information can be controlled by authorization. Visible information may include relationships between specific items and business documents such as orders and shipping documents.

Description

Context-Oriented and Real-Time Project Tracking System Structure and Context Analysis

technical field

The present invention relates to tracking physical items.

Background technique

Conventional systems for tracking physical items typically include computing devices and software. Such systems store information indicative of this condition, such as the current location of the tracked object. It is conceivable that this is a virtual world.

In traditional systems, there is often a gap between the actual status of a project and the status indicated by the system. Gaps are often caused by erroneous manual data entry and system limitations. As a result of these types of problems, traditional systems present a distorted and fragmented picture of reality. In addition, most conventional systems can only observe in a limited range and resolution, for example, the system can only distinguish the type and quantity of products but cannot distinguish individual items.

Contents of the invention

This specification describes methods and apparatus, including computer program products for context-oriented and real-time tracking projects.

The term "item" is used in this specification to denote a real, physical object to avoid the ambiguity of using the term "object", which is hereinafter used only to refer to a data processing structure.

In one aspect, the invention generally features systems, methods, and components arranged to perform various aspects of the methods that can be used to track items. A system according to the present invention comprising a tagging component comprising information indicating standards for tagging one or more items, each tag comprising a globally unique identifier; a containing and tagging an object interface component of a device for communicating, further comprising means for receiving environmental information; a context-oriented intelligence comprising logic for processing the environmental information and directing system operations to be performed in response to the environmental information; and a communication middleware for Communicate between components of the system and with devices external to the system.

In another aspect, the invention generally features systems, methods, and components arranged for performing various aspects of the methods that can be used for context-oriented and real-time tracking of items. One method according to this aspect is to perform operations that receive multiple instances of tag-read-data, each instance containing the read data from a tag attached to an item. The read information includes a unique digital identifier that is automatically read from the tag, and each instance also contains status information when reading the unique identifier, which includes the location of a corresponding tag and its attached items, the multiple tag read data collectively contains information read from tags attached to multiple items; receives an instance or multiple instance context information, each instance describing an associated unmarkable entity Conditions (physical circumstances), the environmental information indicates the status of a location that includes the condition, the multiple instance environmental information collectively contains information that can describe multiple conditions; use the received tag to read data and environmental information to maintain A virtual item and a virtual situation in a virtual world, the virtual item includes an object usable for each of a plurality of items, and the virtual situation includes an object usable for each of a plurality of situations, each object representing its The state of the corresponding item or environment; and detecting the interaction between the virtual condition representing the condition and the virtual item representing the item occurring in the virtual world.

In another aspect, the invention generally features systems, methods, and components arranged to implement various aspects of the methods of the invention that make information available across enterprises. A method in accordance with this aspect is operable to receive multiple instances of tag read data from a first enterprise, each instance comprising automatically read information from a tag attached to an item, the read The information contains at least one unique digital identifier, each instance of which upon reading the unique identifier also contains status information, which includes the location of a corresponding tag and the item attached to it, received from the first enterprise The plurality of tag read data instances collectively comprise information read from tags attached to items of a first plurality of instances; the tag read data comprises data originating from a first data processing system of a first enterprise; Using tag read data received from the first enterprise to maintain virtual representatives (representatives) in the virtual world, the virtual representatives comprising representatives representing each of the plurality of instance items, each virtual representative representing its Corresponding item status: receiving multiple instances of second tag read data from a second enterprise, each instance comprising information automatically read from a tag attached to an item and containing at least one unique digital identifier, each The instance also includes status information including the location of the corresponding tag and the item to which it is attached, the plurality of tag read data received from the second enterprise collectively includes a read from a tag attached to at least one of the items of the first plurality of instances. The retrieved information, tag read data received from the second enterprise comprises data originating from a second data processing system of the second enterprise: using the tag read data received from the second enterprise to maintain a virtual representations, the virtual representations comprising a representation representing each of the second plurality of instance items, each virtual representation representing the state of its corresponding item, wherein tagged read data received from any enterprise representing a particular item is It is used to update the virtual representative corresponding to the item, and generate usable information to the first and second enterprises from the updated virtual representative and the virtual world.

In general, the invention features systems, methods for updating information on a writable tag attached to an item, and components installed for carrying out various aspects of the method of the invention. A method according to this aspect may perform the following operations: an operation of receiving first attribute information for a first item in the system, wherein the first attribute information is obtained from an attribute attached to the first item Data that is automatically read in a first tag of the system, the first characteristic information includes a first identifier to identify the first item; second characteristic information is received in the system for a second item, wherein the second characteristic information is From data automatically read from a second tag attached to the second item, the second characteristic information includes a second identifier to identify the second item; received within the system from a second item located at the second item The data automatically read by the sensor; the relationship information received in the system indicates the relationship between the first item and the second item; a first and a second virtual item respectively representing the first and second items are maintained in the system, the The object maintains information representing the first property information, the second property information, and the sensor information respectively, and maintains a virtual state representing the relationship between the first and second items within the system, and identifies a warning state from the information in the physical and virtual state , the warning status is related to the first item; generating updated characteristic information in response to the warning status to write into the first item; after identifying the warning status, detecting the existence of the first mark at a mark writing place in the system; and detecting Causes the tag write to write updated information into the tag when the tag exists at the tag write location.

Advantageous implementations may have one or more of the following features. Information about items and conditions in the virtual world will be mapped to virtual global standardized time dimension, three-dimensional space and unique identity, wherein items and conditions can be traced mutually through space and time. The method also generates a virtual world alert to a user, where the user is a natural person or a computer program, upon determining that a detected interaction affects any one of the plurality of items. The method also maintains a representation of the current location of each item and each situation in the virtual world, each representation reflecting the most recently received tag read data and context information. The method also expresses location and condition by latitude, longitude, and altitude. The method also maintains a history of item locations and condition locations. The method also derives from the virtual world at least one prediction of a future location of the item based on the history of the location of the item. The method likewise derives a prediction of future location based on the history of the situation location. The method also maintains a representation of the current state of each item and condition in the virtual world, each representation reflecting the most recently received tag read data and context information. The method also maintains a history of project status and status status. The method derives at least one prediction of the future state of the item from the virtual world based on the history of the item's state. The method also derives a prediction of the future state based on the history of the state of the situation. The method also combines time stamps with each tag reading data and context information entities, each time stamp being synchronized to a single standard. The unmarkable condition includes a weather-related condition; and the location of the weather-related condition is described by at least a latitude, a longitude, and an altitude. The unmarkable condition includes a traffic accident, and the location of the traffic accident is described by at least a latitude, a longitude, and an altitude. The method also receives one or more entities of hierarchy information, each instance describing a hierarchy among items represented in the virtual world; and uses the received hierarchy information to maintain Each represents a virtual state of one of the hierarchies in the virtual world. At least one hierarchy is the relationship between items where certain items are contained within other items. The method also receives sensor information from a sensor located on a first item; and updates a first virtual item for the first item with the sensor information. The method also receives an instance of environment information from an external system. The method receives an instance of environmental information, where the instance includes telemetry data from sensors located at a particular location. The method also receives telemetry data generated by sensors located at a particular point or area and represents conditions at that particular point or area; and detecting an item on or within the point or area in the virtual world is When the condition represented by the telemetry data is affected, an alert is generated to the user, when represented in the virtual world, where the user is a natural person or a computer program. The method also receives temperature data generated by a temperature sensor located at a specific point or area and represents the current temperature of the point or area within the virtual situation in the virtual world; and detects in the virtual world that an item will be located at the point or area A warning is generated to a user when the item and current temperature are affected by the current temperature on or within the area, where the user is a natural person or a computer program. The method also attaches a temperature exception to a virtual item; and causes an action to occur when the temperature exception is satisfied. The operation includes generating an alert to a user, where the user is a natural person or a computer program. The method also attaches a rule to a virtual item that can be manipulated to trigger an alert event or trigger an action based on current information in the virtual world. The method also attaches to a virtual situation a rule that can be manipulated to trigger an alert event or cause an action based on current information in the virtual world. The method also receives, processes and responds to queries regarding the current or past status of an item when the item is currently or in the past represented in the virtual world. The method also receives, processes, and responds to queries regarding the status of an item that currently or in the past has a special relationship with a particular item when the item is currently or in the past represented in the virtual world.

In general, the invention features methods and apparatus, including computer program products, for providing multiple businesses with access to information on items in a supply chain. Tags attached to an item are read and information read from the tag and location information of the tag is provided by at least two businesses and used to maintain configuration information for the item and provide it to businesses in the supply chain. The marks may be radio frequency identification marks each having an ePC (electronic product code, electronic product code) as a unique identifier. Visibility of configuration information can be controlled through authorization. Visible information may include relationships between specific items and commercial documents such as order and shipping documents. With visible shipping documents, information read from item markings can be used to confirm the identity and integrity of the shipment. A system according to the present invention includes a method for receiving multiple instances of tag read data from a first enterprise, each instance comprising information read from a tag attached to an item, the read information including an automatically read tag from a tag. Each instance also contains a corresponding tag location and its attached items. When the tag identifier is read from the tag, the plurality of tag read data instances received from the first enterprise collectively contain the self-attached Information read in tags of multiple items; using tag read data received from a first enterprise to maintain configuration information for an item; method of receiving multiple instances of second tag read data from a second enterprise, each instance Contains information read from a tag attached to an item, the read information includes a unique tag identifier automatically read from the tag, each instance also includes a corresponding tag location and its attached item as tag identifier The plurality of instances of tag read data received from the second enterprise collectively contain information read from tags attached to the plurality of items when the self tag is read; the tag read data received from the second enterprise is used to The item maintains configuration information, wherein tag read data received from either enterprise for a particular item is used to update the configuration information; and the configuration information is made visible to a plurality of enterprises in the supply chain, including the first enterprise and the second enterprise.

Advantageous implementations of the inventive system may include additional features. The inventive system may include methods for receiving a third plurality of instances of tag read data from a third enterprise, each instance comprising information read from a tag attached to an item, the read information including an automatically Each instance of the unique tag identifier read from the tag also contains a corresponding tag location and its attached items. When the tag identifier is read from the tag, the plurality of tag read data instances received from the third enterprise collectively Contains information read from tags attached to most items; maintains configuration information for items using tag reads received from a third firm, where tag reads received from any firm for a particular item are used for updates configuration information. The inventive system can be implemented so that tags attached to multiple items include radio frequency identification (RFID) tags, each RFID tag carrying an electronic product code (ePC) as the unique tag identifier. The inventive system can be implemented such that the visibility is controlled; and the inventive system also includes means for receiving authorization information indicating the extent to which configuration information is visible to a particular enterprise within the supply chain; and only if the authorization information allows configuration information A method of making a particular company visible in a situation. The inventive system may be implemented such that the configuration information contains a plurality of item properties, and with respect to at least one of the item properties, the authorization information indicates which item properties are visible to the enterprise. The inventive system can be implemented so that multiple enterprises include a source enterprise having an order document issued by the destination enterprise for an order and a physical shipment ready-to-fulfill order issued by the destination enterprise, and a destination enterprise A shipping document for the goods; visibility includes visibility of the relationship between tag reading data and business documents including order documents and shipping documents; and providing enterprise real-time item configuration visibility also includes methods for receiving shipping information including: Marking identifiers for items of goods in a shipment; information on shipping documents associating each marking identifier with a shipment number; and information on order documents associating that shipment number with an order number; making markings read data A method of combining the shipment information; and a method of making the combination available to the destination business so that the destination business can use a tag identifier for an item in the shipment to confirm the shipment.

In general, the invention features methods and apparatus, including computer program products, for communicating between nodes of a distributed system that tracks items. The system of the present invention includes a node hierarchical system in a first enterprise, the node hierarchical system includes one or more upper layer (parent) nodes and one or more regional (local) nodes, each regional node is an upper layer node subordinates; and a node hierarchy for a second enterprise, the node hierarchy includes one or more upper-level nodes and one or more regional nodes, and each regional node is a subordinate of an upper-level node. In the system, each node maintains a mapping between items and corresponding nodes. The map indicates for each item that at least one node is a designated response node for that item and that there are different designated response nodes for at least two items. multiple entities operable per node to receive item read data, each instance containing information read from a tag attached to an item, the read information including a unique number automatically read from the tag Identifier, each instance also contains the location of the corresponding tag and its attached item, when the tag identifier is read from the tag, the multiple tag read data are all included in the read from multiple tags attached to multiple items ; and per-instance read data for tags. Each node is operable to associate tag read data with a designated responding node as specified by an image maintained by the node.

Advantageous implementations of the inventive system may include additional features. The inventive system can be implemented such that the image created on a first node differs from the image created on a second node. The system of the present invention may be implemented so that after tagging read data for the item from a node contacts a designated responding node, the node receives additional information about the item from the designated node and updates location information about the item in response to the received additional information . Items related to receiving tag read data may have a hierarchical relationship with each other. The tag identifier may specify a manufacturer or product class of the item.

In general, the invention features methods and apparatus, including computer program products, for associating project configuration information in a distributed system. The system of the present invention includes a monitoring system, one or more users, a system for tracking tagged items, and one or more event routers. The monitoring system is operable to detect one or more tagged items, generate an event including a tag identifier, a read identifier, and a time stamp, and publish the event to one or more event routers. A system operable to track tagged items to subscribe to an event about one or more tagged items, and receive the event from one or more event routers, and upon accepting the event, use the received event to send a message to one or more Mark items to update configuration information. Each event router is operable to maintain a list of users, receive events from the monitoring system, and send events to users.

In general, the invention features methods and apparatus, including computer program products, for communicating data between sensor or actuator devices and higher level applications. A computer program product according to the invention is operable to cause data processing equipment to receive a set of rules indicating what data is to be deployed to an external application; receive items including item identifiers from one or more indicia readers data, each item identifier is read from a digital tag attached to a physical item, the item identifier uniquely identifying the item; additional item data is received from other sensor devices other than tag readers means that the additional item data includes an item identifier appended to an entity item property associated with one or more items identified by the indicia reader: using the rule, the item identifier, and the additional item data To determine which item identifier and the subset of additional item data are to be configured in the external application; and the data configured in the external application only consists of the received item identifier and the subset of additional item data. The computer program is further operable to receive data from an external application, the data comprising configuration data for controlling an actuator device; convert the configuration data into a format compatible with the actuator device; and configure the converted setting data to the file actuator device.

In general, the invention features methods and apparatus for contact tracing information. The method of the present invention includes receiving a plurality of identification codes, each information code uniquely identifying a combined virtual item; arranging the plurality of identification codes into one or more identification code sets; Generic redundant coded parts; create a file containing one or more subsets of identifiers; and organize the file into a hierarchical structure so that for each subset of identifiers, the redundant part is represented by an instance List and each identifier will list the omitted redundant part.

In general, the invention features methods and apparatus for filtering tracking information. The method includes retrieving a plurality of identification codes combined with a plurality of virtual items, the virtual items include items and item containers, each identification code is a string of characters uniquely identifying the combined virtual item; placing in each identification code A character indicates that the combined object is an item or a container; and based on the placed character, each identification code corresponds to an item or container.

In general, the invention features methods and apparatus for associating information about item tracking. The method includes creating tracking information to collect items, the tracking information representing each item as one or more properties and corresponding values selected; each distinct property in the tracking information can be encoded by encoding the tracking information using its corresponding explicit coding scheme information; send the encoded tracking information to a recipient; determine which characteristics the recipient is authorized to access: and provide the recipient with a set of encoding schemes that include only information about which the user is authorized to access The encoding scheme of the feature.

The invention can be implemented to realize one or more of the following advantages. A system according to the present invention is aware of a virtual indefinite number of items as other things in the real world and the relationships between items and other things. The inventive system can be implemented on a wide range of scales. The structure of the system of the present invention is easy to cooperate with it and can configure various application programs at the same time. The structure supports tracking of many types of things such as an item or a condition affecting an item. Likewise, the structure allows various properties to be combined with a tracked item or condition. Hierarchical and other relationships can be divided between tracking things and used to track things within a relationship. The structure is open to any kind of data sources, including all kinds of sensors and scanners, and systems providing status information such as weather, traffic conditions, transportation plans such as air and rail plans, arrival date times, etc. The inventive system provides a versatile and intelligent combination between the real world and a virtual world that can be used to provide context-oriented and real-time tracked items.

The system of the invention itself integrates context-oriented intelligence. This intelligence enables the system of the present invention to know what geospatial events affect which item in the track and to take action in response to those events. The system of the present invention can provide dynamic context-oriented intelligence using general geospatial capabilities. Based on available data as well as telemetry data, the system of the present invention can understand where, how and what items are related to each other at a specific time and further act according to defined rules.

Existing software and hardware systems can be integrated into the system of the present invention by using non-proprietary open interfaces. Utilizing these interfaces, the system of the present invention can be compatible with the existing system without using plug-in programs to update the existing system. For example, the inventive system can provide a non-proprietary open interface to virtually integrate various tags, tag readers, scanners, sensors, and applications. The inventive system can be implemented to include an application that can generically read data from and write data to item tags. The system of the present invention may include general real-time telemetry data tracking. The system of the present invention can integrate existing geographic information systems (Geographical Information systems GIS) and data.

The inventive system supports the development of a full range of new or enhanced applications across industries. Such applications include, but are not limited to, those related to supply chain management, asset tracking and management, security and access control, transportation, toll collection, point of sale, and baggage management.

The system of the present invention is available from a regional to a global stratum. This means that the system of the present invention can be implemented to support a business unit, an individual company or a group of companies, in one or more industries. The system of the present invention can track items and status in real time. The system of the present invention can provide the current and past status of items or groups and can do so remotely, for example, via wireless communication or via a network such as the Internet.

Through various initiatives, a large number of various items in the future can be individually tagged and globally identifiable, in many instances using autonomous operating sensors. The inventive system can operate across industries and companies to provide an intelligent enterprise-level project tracking solution. The system of the present invention provides an open, usable and scalable business approach applicable across multiple industries and applications. This business method allows customers to generically define and import virtual representations of items into a software system on a network, attach rules to issue actions based on dynamic environmental data, and query the inventive system for many related information, or obtain traces from the inventive system The object's current and past environments. Tracked data can be shared among partners based on field-level authorization definitions.

Through a non-proprietary interface, namely a browser or a self-describing document such as XML (Extensible Markup Language) document, the system of the present invention can be accessed by users and external applications. The system of the present invention can massively track, if any, individually tagged items and their telemetry data through time and space. The inventive system provides an open non-proprietary interface to sensors, devices and services that track and provide their location, and/or telemetry data therefrom, items or their environment to the inventive system. The inventive system also provides open non-proprietary interfaces to sensors, devices and services that write data to physical items or their tags that can receive this data. The system of the present invention provides a user interface, an application program interface, and tools for defining individual virtual representations of marked items and their layered systems, including specific characteristics and methods; to define rules that can trigger operations based on system cognition of dynamic environmental data ; to define virtual representations of physical constraints or other actions that can affect items; to define fine-grained data access filters set at a property level on data objects representing items and other real-world things; to interrogate and visually inspect the system's mass related to or derived from tracking current and past environmental characteristics of the project; and sharing project-related data among partners on the network.

The inventive system can be used by a variety of entities for their respective purposes, and each instance can produce some or all of the information about its tagged items, its data entry devices, and tracking status that can be seen by other entities using the inventive system . Such other entities may use this information and benefit from the experience and history of the general public of users of the system of the present invention, regardless of the purpose for which information was collected or provided in the first place, and in all respects need not be responsible for future use and various The benefits of a contribution, or their beneficial interplay, are taken into account when the contribution is made.

The system of the present invention enables early detection of human error in the shipping process, such as during preparation for shipment or when loading into a truck. The inventive system provides maximum visibility into the actual configuration of goods in a supply chain. The inventive system permanently archives all historical records to support reliability, warrantee, customer return, theft proof, and other business processes. The system of the present invention integrates existing systems to avoid duplication of functions. The system of the present invention benefits from the markings used to track items to enable the most automatic functionality, for example, by enabling the creation of inventories based on detection of shipments at customer destinations. The system of the present invention can be continuously operated all the time. Software updates can be performed dynamically without taking the entire system offline. The data can be stored in a general structure that does not change even if the semantic structure of the data changes. In the event of a failure, the low-latency recovery mechanism enables the system to recover quickly.

The inventive system is scalable to support a large number of users. The mechanism used to cause data to change may operate independently of the mechanism for making queries on the data. Queries can be limited to past data states so that the current state is not overloaded with too many queries.

As each tracked item moves between geographically dispersed nodes in the system, the system of the present invention requires only a low-level data link between the nodes in order to ensure an up-to-date, synchronized view of its location and configuration. The system of the present invention allows continued business operations at a regional node even when communication between the regional node and the rest of the system is inoperable. The system of the present invention ensures that once the unconnected nodes have been reconnected, unreported data collected from unconnected nodes has been reliably communicated to the rest of the system and changes received from other nodes have also been reliably communicated to the unconnected nodes. Line nodes get in touch. In addition, by only reporting the movement of higher-level items in a hierarchy of items, contact volume and item history storage costs can be reduced.

The system of the present invention can receive data from a large number of smart items in real time without consuming a lot of processing power to perform collection and filtering. The smart project need not be limited to a single factory or store. The system of the present invention can collect data from many geographically dispersed areas. The inventive system does not need to support a specific hardware interface for all possible types of smart items. The system of the present invention can be easily expanded to accommodate new communication channels and hardware interfaces. Business rules enable the inventive system to adapt to new settings and situations without requiring a software engineer to rearrange operations.

The system of the present invention can be used to have suitable real-time inventory management. Instead of receiving periodic reports of aggregated inventory changes, the system of the present invention enables real-time reporting of inventory changes without human intervention. Replenishment planning is only generated according to a fixed plan, and the timing of the replenishment plan can be adjusted in time, and it will be generated more or less frequently according to the real-time inventory quantity reported.

The system of the present invention can mask redundant portions of a UID to save bandwidth in memory or connections. The system of the present invention can receive a set of UIDs read from different kinds of items and can determine which items are identified by a particular UID. With this determination, the system of the present invention can filter out UIDs belonging to certain item types and provide a filtered set of UIDs belonging to certain item types to a recipient.

The system of the present invention can provide selective access to track information. The system of the present invention can provide the convenience of sending the same tracking information to all customers, but simultaneously provide different levels of information access according to the customer's authorization level. In particular, the system of the present invention may encode tracking information, but only provide a method for a particular customer to decode portions of the tracking information.

The coding system can not only provide access control but also provide effective information linkage. The system of the present invention can replace the descriptive text in the tracking information with a relatively short coded text. If the tracking information is stored on a tag, this allows more information to be stored on the tag. This can reduce the amount of bandwidth consumed by the tracking information if it is passed across the network.

The details of one or more specific embodiments of the invention are set forth in the description below and in conjunction with the accompanying drawings. Other features and advantages of the invention will be apparent from the description of the specification, drawings and claims.

Description of drawings

Figure 1 is a block diagram illustrating a system according to the present invention.

Figure 2 shows an example of a unique identification code.

Figure 3 is a block diagram depicting one embodiment of the system of the present invention.

FIG. 4 is a flowchart describing a project import process.

FIG. 5 is a flowchart describing the operation of a temperature sensing device and an RFID tag.

FIG. 6 is a flow chart depicting the response of the system of the present invention to an event, such as loading a case onto a pallet.

FIG. 7 is a flowchart describing an update operation.

FIG. 8 is a flowchart describing update, read and alert operations.

Fig. 9 is a flowchart describing a supply operation.

Figure 10 is a block diagram illustrating a scenario for alert acknowledgment and data flow into or out of a flag.

Figure 11 is a block diagram illustrating an alternative scheme for alert acknowledgment and data flow into or out of a flag.

FIG. 12 is a flowchart describing an aspect of the data flow process.

FIG. 13 is a flow chart describing another aspect of the data flow process.

Figure 14 is a block diagram illustrating an embodiment of the system of the present invention.

Figure 15 is a block diagram depicting the software components within the system.

Figure 16 is a block diagram depicting the mechanism for storing, changing and querying tracking information.

Fig. 17 is a block diagram describing the function of a property list.

Figure 18 is a block diagram depicting a shipping scheme.

Figure 19 is a block diagram depicting another shipping scheme.

Figure 20 is a block diagram depicting a mechanism for data restoration.

Figure 21 is a block diagram depicting a mechanism for responding to queries.

Figure 22 is a block diagram depicting a mechanism for responding to queries.

Figure 23 is a block diagram depicting a mechanism for responding to queries.

Figure 24 is a block diagram depicting a mechanism for responding to queries.

Figure 25 is a block diagram depicting a mechanism for responding to queries.

Figure 26 is a block diagram depicting a large-scale embodiment of the infrastructure.

Fig. 27 is a block diagram illustrating the structure of a world model.

Figure 28 is a block diagram depicting an authorization scheme.

Fig. 29 is a block diagram illustrating the structure of a world model.

Fig. 30 is a block diagram depicting the implementation of upper nodes as a cluster.

Figure 31 is a block diagram depicting one embodiment of the system of the present invention.

Figure 32 is a block diagram illustrating an embodiment of using multiple integration engines in a layered architecture model.

Figure 33 is a block diagram depicting an integration engine.

Figure 34 is a block diagram depicting a hardware interface.

Fig. 35 is a block diagram illustrating an electronic token.

FIG. 36 is a block diagram of the basic architecture of an invention management system implemented in conjunction with a project tracking system according to the present invention.

Figure 37 is a block diagram of an embodiment using event routing.

Figure 38 is a diagram of a topic structure for event routing.

Figure 39 is an illustration of a protocol flow for publishing.

Figure 40 is an illustration of an agreement flow for subscription.

Figure 41 is a block diagram of an object naming server for hosting an event router.

Figure 42 is an illustration of using an event router to distribute across multiple project tracking systems.

Figure 43 is a block diagram of a system for communicating between a manufacturer and a customer.

Figure 44 is a block diagram of a system for communicating between a manufacturer and a customer using a shared item tracking system.

45 is a flowchart of a method for communicating tracking information.

Figure 46 is an illustration of an Electronic Product Numbering structure.

Figure 47 is an illustration of an unmasked shipping document.

Figure 48 is an illustration of a covered shipping document.

Figure 49 is a flowchart of a method for filtering trace information.

Figure 50 is a flowchart of a method for communicating tracking information.

Figure 51 is a flowchart of a method for accessing tracking information.

Figure 52 is an illustration of a system of files, index tables, and coded files for conveying tracking information.

Figure 53 is a flowchart of a method for checking the appropriate index table for creating an encoded XML document.

Figure 54 is a block diagram illustrating the flow of information between a client server and additional agents and businesses.

Like numerals and nomenclature refer to like components in the drawings.

Description of reference symbols

20 boxes were manufactured and labeled

21,62 Producer's Token Reader connected to the Object Interface Component "sees" the Token (Unique System Identifier, UID)

22,64 The object interface component generates and sends a "seen event" to the communication middleware component

23, 43, 66, 72, 82, 91, 122, 126 CMC routes the event to context-oriented smart components

24 Context Oriented Smart Components: Know the Object (UID)?

25 Context Oriented Smart Component: Is the event of type "New Entity Object (UID) Event"?

26 Environment-oriented smart components create a new physical object (UID) based on specific data

27 Context-oriented smart components store new object data

28 The environment-oriented smart component updates the state and state history of the object (UID) based on the input data

32, 102 Tagging Components (TC)

33x, 33y, 33z firewall

34x Maker X: Object Interface Components

34y Carrier Y: Object Interface Component

34z Retailer Z: Object Interface Components

36, 106 communication middleware component (CMC)

37, 108 Environmentally Oriented Intelligent Components (CAIC)

38,110 Human Interface Component (HIC)

40 Object Interface Component writes data such as "Valid Until" and Temperature Threshold to Tag (UID) and resets T _max

41, 89 Object Interface Components: Write to Required Tags?

42 The object interface component creates and sends a "new entity object (UID) event" to the communication middleware component

44 The production system creates an "introduced entity object event (UID)" including properties, access rights, rules and alerts and sends it to the communication middleware component

45 The communication middleware component routes events to the manufacturer's production system

46 The environment-oriented intelligent component sends "object unknown event (UID)" to the communication middleware component

50 The manufacturer attaches the sensor to a pallet, resets its memory and activates it

52 Sensors: Is it time to measure the temperature?

54 Measure the temperature T and store it together with the time stamp to the history record on the stamp

56 If T>T _max , set T _max =T and store T _max in flag

60 marked pallet loaded with cases and sensors

68 The environment-oriented smart component updates the status and status history of the seen object (UID) according to the input data

70 The Shipper's Indicia Reader connected to the Object Interface Module "sees" the Indicia (UIDs) of the boxes on the pallet including the Sensor Indicia (UID, _Tmax )

71 The object interface component generates and sends a "seen event" (UID, T _max ) to the communication middleware component

73, 83 The environment-oriented smart component updates the state and history of the object (UID) according to the input data

74 Environment-Oriented Smart Components: Is the temperature T _max within limits?

75, 86 The context-oriented smart component sends an alert event (UID, T _max ) to the communication middleware component

76 CMC routes alerts to the manufacturer's and shipper's ERP applications

80 The retailer's token reader connected to the object interface module "sees" the tokens (UIDs) of the cases on the pallet including the sensor tokens (UID, T _max , T _history )

81 The object interface component creates and sends a "seen event" (UID, T _max , T _hisrory ) to the communication middleware component

84 The environment-oriented smart component calculates a new expiration date for each box based on T _max , T _history and manufacturer rules

85 Environment-Oriented Smart Components: Is the Box Broken?

87 The communication middleware component routes the alert to the human interface component

88 human interface component sends a text message to inventory manager

90 The environment-oriented intelligent component manufactures and transmits "write data event (UID, data)" to the communication middleware component

92 Object Interface Component writes such as "Valid Until When" and T _max data to tag (UID)

103, 3620 Item Tracking System (ITS)

104 Object Interface Component (OIC)

112 External applications

114 markets

116 Other environment guidance and real-time tracking systems

120 The traffic information provider creates an "introduced virtual situation event (UID)" including properties and transmits it to the communication middleware component

124 The object interface component creates and sends a "new virtual state (UID) event" to the communication middleware component

128 Context Oriented Smart Component: "Is this event of type "new virtual state event""?

130 Environment-oriented smart components create a new virtual state (UID) according to the specific data

132 context-oriented smart components store new virtual state data

150 items

152 tag(uid, data)

158, 1402, 4314 Tag Reader

160 tag writers

168 virtual projects

170, 171 rule

174 applications

500 tag identifier

1202 Receiving characteristic information about a first commodity

1204 Receive characteristic information and environmental information about a second commodity

1206 Use the received information to maintain a first and a second virtual commodity

1208 Receive relationship information and maintain a virtual relationship

1210 Recognizes alert status on first commodity

1212 In response to an alert condition, manufacture updated property information to be written to the first commodity

1214 Detect first tag exists at a tag write

1216 Write the update information to the first mark at the place where the mark is written

1302 receiving characteristic information about a first item derived from tag data automatically read by a first tag reader from a first tag located on the first item

1304 receives updated property data about the first item

1306 Detect the presence of the first tag at a different tag write

1308 Make the place where the mark is written write the updated information to the first mark

1401 Business systems (such as enterprise resource planning)

1403, 4311, 4315, 4409 Regional Project Tracker

1404, 4401, 4409 shared project tracking system

1405 network connection

1406 independent position

1407, 4407 Existing and new applications

1408 Network connection to carry query to this ITS without changing ITS state

1409 Additional shared ITS systems

1501 Real-time input and processing

1502 Data structure and permanent storage

1503 About the query interface

1504, 1505 software-to-software communication

1610 Core data structure has no meaning

1620 permanent storage mechanism

1630 Basic infrastructure (stateless), real-time semantic segment

1640 History and Status Inquiry System

1710 Object record 1. Object ID 2. Collection 3. Member 4. Attribute

1810 Detergent #341, #576

1820 Case #3328 Shipping Part #2287

1830 Truck #4421 Location Lat/Lon/Alt

1940 Detergent #621

1950 Warehouse #4462...} Latitude: 31N, Longitude: 60.45, Altitude: 100

1960 shelf #3348

1970 Area #4462

2010 Network (publish-subscribe)

2020 permanent storage area

2030 Core position

2040 storage area

2050 semantic area

2060 Network Infrastructure

2070 queue

2110 Route destroyed

2120 Boundary Chest

2130 start position

2140 End position

2150 straight path

2220 waypoint

2320 transport route

2410 Estimated percentage of trips completed

2420 Estimated current position

2510, 2512, 2514, 2516, 2518 route sections

2710, 2720, 2910, 2920, 3010 world mode

3110 Integration Engine

3120 smart project

3130 Advanced Applications

3310 Control managers

3320 Interrogator Agent

3330 Process Agent

3340 Communication Agent

3400 hardware interface

3410 server

3420 Interrogator

3500 electronic token

3510 Article Reference ("ARTNR")

3520 Item Description ("ARTDESC")

3530 Item Prices

3610 monitoring system

3630 Early Warning Agent (EWA)

3640 Inventory Planning Tool

3710 Event Router (ER)

3720 Extended Object Naming Service (EONS)

4301 Producer

4302 consumers

4303 shipment

4304 items

4306 Tag Reader System

4307 Container marking

4308 item tag

4309 Shipment Contents Information

4310 Communication network

4312, 4313 External enterprise resource planning systems

4500, 4900, 5000, 5100 methods

The 4510 receives a plurality of identification codes, each identification code uniquely identifying an associated item

4520 Classify the identification code into one or more groups of identification codes

4530 For each set of identification codes, identify the redundant part of the code, which is common for each set of codes

4540 Create a file containing one or more sets of identification codes

4550 Organize the document in a hierarchical system so that for each set of identifiers, the redundant part is listed with an instance and each identifier is listed with the omitted redundant part

4610 Title

4620 Electronic product code managers

4630 object type

4640 serial number

4701 redundant part

4802 prefix

4910 Receive an identifier combined with multiple items, including individual items and item containers

4920 Place a character in each identifier that identifies the item as unique to an individual item or item container

4930 Determine whether the identification code corresponds to an independent item or a container based on the placed character

5010 Create tracking information about one or more items, each item has one or more properties

5020 Encode this trace information using an explicit encoding scheme for each attribute

5030 Send the tracking information to a recipient

5040 Determine which features the recipient is granted access to

5050 Only a subset of the encoding scheme is provided to the recipient, which includes only encoding schemes for properties that the recipient is authorized to access

5110 Receives tracking information about the encoding of one or more items, each item having one or more attributes, each encoded attribute using an explicit encoding scheme

5120 Receive only a subset of the encoding scheme, which includes only encoding schemes for properties that the recipient is authorized to access

5130 Decodes the attributes the recipient is authorized to access

5210 Producer Extensible Markup Language Document

5215, 5260 Encoding Extensible Markup Language Documents

5220 Producer file type definition file

5225, 5270 encoding file type definition file

5230 index table

5240 network

5245 Flagged items

5265 Consumer Extensible Markup Language Documentation

5275 Consumer File Type Definition File

5280 distributed index table

5310 Does the index table need to be updated?

5320 Create an encoded Extensible Markup Language file and an encoded file type definition file

5330 Create an index table

Detailed ways

Table of contents

1. System overview

2. An embodiment of the system of the present invention

2.1. Cross-enterprise shipping solution

2.2. Two-way data flow

3. Another embodiment of the system of the present invention

3.1. Software upgrade

3.2. Cross-enterprise visibility

3.3. Data linkage and coordination among global models

3.4. Project-based identification schemes in international trade

3.5. Project plan

3.6. Information Retrieval Scheme

4. Data transfer between item tracking system and tag reader

4.1. Event Router

4.2. Integration Engine

5. Compression, filtering and encoding of tracking information

1. System overview

A system according to the present invention receives information about items and conditions affecting the items in a non-proprietary open format. In this specification, the word "item" has a very broad meaning. It includes the meaning used for the word "item" as used in the patent applications referenced above. In order to be compatible with enterprise resource planning (enterprise resource planning, ERP), supply chain management (supply chain management, SCM) and logistics systems, the concept of an item includes a bill of material, bill of lading, packing list, All the normal stuff like menus etc. Thus, it includes any physical item that can have a location, be shipped, sold to a customer, and so on. It may also include any assets that may be referred to in a company's accounting or other business systems such as shipments.

A tagged item is an item that carries a self-identifying mark. The tag can be associated with a single item (in the preceding sense) or can be associated with an aggregate of items. So for example, a tagged item could be one of the following: an individual item like a bottle of soap, an asset like a tagged laptop, a collection of possibly assorted items, or a pallet holding many boxes a container; a container; a truck or trailer; an airplane; a ship; and a train.

In customer goods and other areas, an item may not have any type of item-specific marking. For example, a tagged case may contain 48 bottles of soap, each of which has a barcode for the same UPC (Universal Product Code) or SKU (Stock Keeping Unit) or other product code and each bottle can be sold individually to a customer. A tracking system can combine shipments tracked at the tag level to track sales revenue points for individually priced items. The barcode will generally not carry a UID (Unique System Identifier), just an item type or SKU. The system of the present invention can make some assumptions about the combination of barcode and label data. In supermarkets or retailers, tagged case-level inventory can benefit from the use of a tag reader in daily inventory, and the system of the present invention can be used at any Sell in order. If the individual items are not identified, there is no way to have a correct tracking system after the marked box has been opened.

Typically, a tag is an RFID (Radio Frequency Identification) tag, but it need not be based on radio frequency technology. For example, a tag can be implemented to be read by optical, magnetic, opto-magnetic, or other techniques, whether or not there is physical contact between the tag and the reader. Furthermore, the tag can be passive (contains no internal power source to communicate and transfer data) or active; and it may or may not have processing capabilities. In this specification, an indicium is understood to be a recognizable digital indicia, meaning that the indicium has the property of a unique digital identification that can be read directly from the indicium by some reader. Certain digital identification marks can also be written, which provide additional advantages should the information need to be readily available without relying on a communication network.

In this specification, the term "virtual item" is used to mean data corresponding to and intended to represent an item. Likewise, the term "virtual circumstance" is used to refer to data corresponding to and intended to represent both physical and non-physical things, including, for example, relationships and events. A virtual item or a virtual state can be implemented as an object in the object-oriented programming terminology of the item; however, it can also be implemented in any other convenient way, such as by records in a database.

In general, a virtual state is created and maintained because it represents something - generally referred to as a state - that may affect the item represented by a virtual item. One example of a situation is a geospatial event, which may include, for example, a hurricane that prevents a ship from carrying the shipment of the item being tracked, a labor strike that prevents the unloading of the item from the ship, and a traffic accident that delays the shipment of the item.

The term hierarchy refers to combinations or relationships between items and situations. For example, if a container is placed on a pallet containing the container, events that affect the pallet will also affect the container. A virtual state may represent a hierarchy.

The system of the present invention receives information from many sources, which can be connected to the system via a network such as the Internet or directly. The system of the present invention may be configured to receive information from these sources using proprietary or non-public interfaces, in which case the information is formatted to be compatible with the system. The system of the present invention includes data input devices such as indicia readers, sensors and scanners. Through these devices, the system of the present invention continuously tracks and records the state of goods and conditions represented by physical and environmental objects. The status of an item may include its condition, characteristics, and location.

2. An example of the system

As shown in Figure 1, an item tracking system (item tracking system, ITS) according to the present invention can be combined with a marking component (Tagging component, "TC") 102, an object interface component (Object Interface Component, "OIC") 104 , a communication middleware component (Communication Middleware Component, "CMC") 106, a context-aware intelligence component (Context-Aware Intelligence Component, "CAIC") 108, and a human interface component (Human Interface Component, "HIC") 110 Joint implementation. In an alternative embodiment, the HIC 110 is combined with other components. Each of these components may be implemented as a computer program executing on one or more computers and controlling the apparatus to perform data retrieval, output and transmission functions. Figure 1 also shows the flow of transfers (represented by arrows) between components of the ITS, and between the system and external applications 112, external marketplace 114, and other external ITS 116. This transport flow can be implemented in any convenient, open manner, such as by exchange of XML documents.

The components are arranged with a distributed, real-time and event infrastructure. Each or all of the components or any combination of system components can be implemented from a small to a large scale. Microscale implementation refers to implementation on a single device and giant implementation refers to implementation on multiple devices, such as computers in a network. Each component can be distributed across multiple devices, including computers, interconnected by a network. Each component can be composed of a number of different applications, ie implemented so that the applications perform the functionality of the component in an aggregate. While ensuring that hardware and software can be easily integrated using non-proprietary standard interfaces, the above-described component structure allows the system to group and scale functions from a regional to a global level.

A component may include software systems - including any software, applications, computer program products - and associated devices. For example, a software system may be applications and servers operating at an enterprise level. Transmission between systems can be performed via a transmission network. This component exposes non-proprietary open interfaces to services accessible over a network, such as services based on open standards such as XML over HTTP. The following sections describe this component further.

markup component

Items introduced into the system are tagged with a unique identifier using any available item-level tagging technology, such as active and passive radio frequency identification ("RFID") tags, barcodes, and tags that can be applied on a molecular basis. mark.

When the system first perceives an item or condition, it is introduced into the system as described above; and a corresponding object (ie virtual item or virtual condition) is created. The system of the present invention designates a specific dynamic n-dimensional content and property space to import objects. For example, the system of the present invention may assign owner, price, item number, and temperature to an incoming object. The system of the present invention can optionally attach specific rules to imported objects. For example, the system of the present invention can add a rule specifying that if the temperature of the corresponding item reaches level y, then operation z will occur.

The TC 102 in a particular implementation indicates in an open manner what tagging technology can be used with the system and how. The TC 102 includes a distributed knowledge system based on Internet technology. In particular, the TC 102 will generally contain and provide a specification of the Globally Unique Identifier and how it is applied; a catalog describing the specification of the Compliant Mark, its reader/writer hardware and any aspects regarding its use; Specific standards and laws applicable to tagging projects; specifications for standardized communication and content data formats and interfaces; specifications for reading and writing processes, processing and transmission requirements for enabling tagging and telemetry data specifications; Knowledge of selecting and deploying markup and markup content; benchmarking procedures; implementation guides; and frequently asked questions.

Additionally, the TC 102 provides tools, content, software development kits, and specific solutions to enable manufacturers, system integrators, and customers to identify, validate, and implement the best project tag reader/writer combinations and standard applications. The TC 102 can be co-established with any software development environment to meet the above mentioned requirements.

Object Interface Components

The OIC 104 transfers data from attached hardware to the system and vice versa. The OIC 104 may also perform any required local processing.

The OIC 104 is a sophisticated, universal, bi-directional and intelligent software interface between the system and the real world. Here, an object is introduced into the system and its state and telemetry data is received, filtered, transmitted, pre-processed and optionally processed. Because the object can be implemented to carry rules that can trigger alert events or cause actions to occur based on current content or state data, the OIC 104 can be implemented to embed or link to a rules engine to process such rules. By customizing the OIC 104, customers can specify what the OIC should do if the first instance of one of the customer's indicia readers detects an item indicium - which will have an identifying indicia so that the system can be mapped to a unique system identifier ( "UID"). These operations may include interfacing with external applications, such as ERP (Enterprise Resource Planning) applications.

The OIC 104 also generally specifies and identifies how tag interface hardware, such as RFID readers, barcode scanners, polymer tag readers and sensors, etc., and their operating systems interface with the system. The OIC 104 thus acts as a generic software wrapper around all specific tag reading/writing devices, providing standardized integration; data validation, filtering, and transmission; bi-directional, event-based security associations; and data pre-processing.

Because the OIC 104 can not only receive data but also transmit data to hardware and software attached to the system, and ultimately to the tagged items themselves, the system of the present invention can use the OIC to write data to the items or remotely control them, If these items are set for this control.

The OIC 104 can apply and implement a sophisticated security scheme, such as a security scheme based on digital certificates, for all inbound and outbound communications. The OIC 104 can be co-established with any software development environment to meet the above mentioned requirements.

Communication Middleware Components

The components communicate by sending and receiving standardized events that these components can send and receive over a network. The CMC 106 identifies and routes standardized events between the OIC 104 and the CAIC 108 (which will be described below) and generally between any system components. The CMC 106 can also identify and route standardized events between any system component and other applications, devices and components.

The CMC 106 performs functions such as data and authentication validation, storage and retrieval, archiving, data decryption/encryption, and multicasting of events. The CMC 106 can apply and implement a sophisticated security scheme, such as a security scheme based on digital certificates, for all inbound and outbound communications. The CMC 106 can be co-established with any software development environment to meet the above mentioned requirements.

Context Oriented Smart Components

CAIC 108 includes providing intelligence to the system to receive, process, and respond to information about what tagged items are represented where and how by the imported objects and how the items are present, past, or future in relation to each other or to real-world functionality at a particular time The logic of the query. The CAIC 108 provides open internal and external interfaces for plugging in additional functions such as applications and rules, extending its common service settings.

As previously mentioned, the system of the present invention may contain virtual conditions, which represent events that may affect an item. Examples of such events include hurricanes, high temperatures at a point or area, and traffic jams. Virtual conditions can also describe the characteristics of the project. Examples of properties include a geospatial path, a velocity, and a target. Telemetry readings from sensors can also be introduced as virtual conditions.

The CAIC 108 includes a database that allows the system to store and retrieve the current state of incoming objects and a history of state changes for these objects. This database handles geospatial data and can be spread across multiple computers and regions.

The CAIC 108 can apply and implement a sophisticated security scheme, such as a security scheme based on digital certificates. The CAIC 108 can be co-established with any software development environment to meet the above mentioned requirements.

Human Interface Components

HIC 110 generically integrates a number of technologies suitable for easy human access and control from the system. These technologies include things like HTML- or XML-based, voice-controlled, stylus-controlled, and polymorphic human interfaces including all kinds of data visualization technologies and similar technologies. The HIC 110 separates the application and infrastructure layer from the presentation and human interaction layer.

The HIC 110 can apply and implement a sophisticated security scheme, such as a security scheme based on digital certificates. The HIC 110 can be co-established with any software development environment to meet the above mentioned requirements.

Import objects into the system of the present invention

In operation, objects such as virtual items and virtual conditions may be introduced into the system using standardized and parameterized events, the events including at least one system UID. In addition, specific properties, methods, and rules can be attached to imported objects (such as current temperature, current owner, manufacturer, temperature anomalies, alerts, rules, data access, and authentication specifications).

unique identifier

The system of the present invention maps all imported objects to a system UID. In order for the system to scale from regional to global levels and also integrate satisfactorily with other systems, this identifier must be globally unique. If the object's referent is marked with a globally unique identifier, that identifier may, but need not, be used as the UID. One such unique identifier is the Electronic Product Code (ePC) of the MIT (Massachusetts Institute of Technology) Automatic Identifier Center. Figure 2 illustrates the format of the ePC.

The system of the present invention can split UIDs to enhance search performance.

One way to uniquely label an item is to attach an RFID chip to the item. These electronic chips hold at least one relative unique identification mark which can be read by a specific reader device. More sophisticated chips enable dynamic data storage with external read/write capabilities while smart chips contain built-in processing power. One of the advantages of RFID technology is the automatic identification of various items over a distance without disassembling or unpacking them. The system of the present invention can also optionally use other technologies, such as item-level barcodes, magnetic labels, and polymer labels, to affix virtual items with identification marks that can be mapped to system UIDs.

event

The system of the present invention communicates with each other internally and externally by using events. Table 1 provides an example of an XML document representing such an event. Any convenient format for representing events may be used.

<event><type>SEEN_OBJECT</type><parameter><sender><UID>xx.xxxxxxx.xxxxxx.xxxxxxxxx</UID><type>RFID_READER</type></sender><telemetry data>< UID>xx.xxxxxxx.xxxxxx.xxxxxxxxx</UID><temperature>

<unit>C</unit><value>45.43</value></temperature></telemetry></parameter></event>

Table 1

Time, space, unique identity, environment, hierarchical system

The system of the present invention maps each incoming object to a system-wide standardized time, space dimension (3-D), unique identifier (UID), and environment. The system of the present invention stores input data with a system-wide synchronization time stamp. Space refers to everything from a point (simple position) to a complex three-dimensional polyhedron in a three-dimensional space (meaning, for example, position, size, and shape of an item). The environment may be n-dimensional (referring to properties such as temperature, velocity, and weight, for example).

Each dimension is measured in system-wide standard units, such as those based on international standards such as Coordinated Universal Time ("UTC") and the System of Units ("SI").

Because time and space are global dimensions, the core space of the system of the present invention is compatible with all other systems, such as GIS, that also work within these dimensions or a subset thereof. Imported objects may be part of a dynamic hierarchy. Hierarchies can be described by virtual conditions.

Based on internal or external event data, the system of the present invention tracks and records the status of the item represented by the incoming object in the above-mentioned space. Questions can then be answered or alerts can be provided about the state of objects introduced into the space and their relationships, such as:

●Where is the project (UID) December 12, 2001?

• Where are all items of type x (UIDs) at address z within radius y?

●Which of my supplies were affected by Tropical Storm x?

• Where are the closest remaining parts of asset x and how quickly can they be delivered to plant y?

• Where is the closest demand for my product X by deadline y?

●Warning! Chemical products x and y are stored too close to each other.

●Warning! Employee x is not allowed to take laptop y out of building z.

Based on historical data, statistical or other methods, the system of the present invention may also derive future states or introduce behavior of objects or groups thereof.

Direct or derived location data

The location of an item can be described to the system in a number of ways. An example for a direct description is to configure latitude, longitude and altitude data sets in a standard way.

An example for a derived location description is the street address of a facility where a tag reader is located. The system of the present invention maps the street address of the tag reader to the standard coordination system of the system, assumes that the item (represented by its UID) encountered by the tag reader is in its vicinity, and correlates the reader location with the item's location. combined.

Object-Level Data Access Authorization Model

The object schema may include a UID, properties, and a definition of a thing whose properties, methods and rules are authorized for system users to read/write/change. The system of the present invention assigns a globally unique identifier to each user, which identifier can be based on Electronic Product Code (ePC), EPC administrator (part of ePC), etc.

Depending on assigned authorizations and using standardized parameterized events, system users write, read and change data of incoming objects. Object data access depends on the defined authorization settings. Table 2 provides an example of an XML file representing a virtual project implementing the authorization schema described above. However, this is only an example and any convenient representation may be used.

<virtual_project><UID>xx.xxxxxxx.xxxxxx.xxxxxxxxx</UID><current_owner><OUID>xxxxxxx</OUID><change_authorization><OUID>xxxxxxx</OUID></change_ Authorization></current_owner><price><unit>USD</unit><value>230000</value><read_authorization>

<OUID>xxxxxxx</OUID><OUID>yyyyyyy</OUID><OUID>zzzzzzzz</OUID></read_authorization><write_authorization><OUID>xxxxxxx</OUID></write_ Authorization><Change_Authorization><OUID>xxxxxxx</OUID></Change_Authorization></Price><Virtual_Project>

Table 2

Communication Security Solution

The system of the present invention includes a common authorization and security scheme (such as a scheme based on digital authentication and encryption) for communication between components and communication with other systems and external devices.

2.1 Cross-enterprise shipping solution

The system tracks and records the location and temperature of high quality fish shipments by shipper Y from producer X to retailer Z, a scenario will now be described in this case.

The following roughly describes how the system accomplishes the above functions. Manufacturer X boxes the product and puts an RFID tag on each box. The RFID tag includes a UID and can also store an expiration date, a maximum temperature threshold and a maximum encountered temperature reading (T _max ). Maker X places the boxes on pallets and adds a dynamic, recoverable temperature sensing device to each pallet. It is also an option to attach the sensing device to each case, but this would result in a greater expense. These devices are attached with an RFID tag that contains a UID and can store temperature readings and a maximum encountered temperature reading (T _max ). The device periodically measures the current temperature and stores the reading on its attached RFID tag. An alert is triggered when the temperature reaches a certain threshold. Upon arrival at the retailer, an updated expiration date based on the sensor device's temperature history and maximum encountered temperature data is written to each case's RFID tag.

Manufacturer X wants to reduce the number of boxes that are returned by retailer Z ("returns") at the responsibility of shipper y, eg, when the boxes are exposed to high temperatures during shipment. Shipper Y wants to gain market share by providing better customer satisfaction by ensuring full visibility of current location and temperature, and in addition, Shipper Y wants to be aware of quality issues and theft by contractors. Retailer Z wants to be able to identify and return broken products upon delivery, thereby reducing costs by reducing returns and at the same time achieving higher customer satisfaction.

How the system helps each party achieve its goals is described in detail below. Figure 3 illustrates an example where Manufacturer X, Shipper Y and Retailer Z take Object Interface Components (OICs) 34x, 34y, 34z in the system behind their respective firewalls 33x, 33y, 33z and perform a partial installation. In addition, they jointly use a tagging component (TC) 32, a communication middleware component (CMC) 36, a context-oriented intelligence component (CAIC) 37, and a human interface component (HIC) 38 of an external application service provider. Service providers provide these services over a network such as the Internet. Each party may also choose to subscribe to a system implementation provided by a service provider. In the latter example, each party need not obtain and install an OIC. There is also an option for one or more parties to install all five system components for use by all of them. In this example, the parties do not need to subscribe to a service provider, their CMC's can be contacted by sending events over a network like the Internet.

Based on specifications, standards, best industry practices, and other information obtained from TC, Manufacturer X obtains the above product and solution requirements (such as active or passive RFID tags, frequency, reader range, built-in temperature sensor, memory size, price point, example material, and combined requirements) compatible read-write RFID tags and interrogators. Based on specifications, standards, best industry practices, and other information obtained from the TC, shipper Y and retailer Z each acquire some RFID interrogators (which may be read-only) that are compatible with Manufacturer X's RFID tags and systems .

When manufacturer X manufactures a case of product, manufacturer X affixes an RFID tag and introduces its unique identifier, allowed temperature range, and initial expiration date into a system. Figure 4 illustrates this import operation. A box is manufactured and a label is applied (step 20). An indicia reader connected to the OIC and belonging to the manufacturer senses the indicia and reads its UID (step 21). The OIC generates and sends a see event including the UID to the CMC (step 22), and the CMC routes to the CAIC (step 23). If an object about UID is known, the CAIO updates the state and state history of the object according to the input data (branch of step 24 "yes"; step 28); otherwise the CAIC decides whether the event is a new virtual item event (step 25 decision). If the event is a new object event, the CAIC generates a new virtual item as UID according to the specific data (step 26) and stores the new virtual item data (step 27). Otherwise the following operations will take place. The CALC sends an unknown object event as the UID to the CMC (step 46). The CMC routes this event to the manufacturer's production system (step 45), which generates an incoming virtual item event as a UID with properties, access rights, rules, and alerts, and sends this event to the CMC (step 44) . The CMC routes this event to the OIC (step 43), which generates a new virtual item event as UID and sends it to the CMC (step 42). The OIC also determines whether there is a request to write the data to the tag (step 41). The OIC writes the data to the tag, if any (step 40). In this illustration, the data is an expiration date, a temperature threshold, and a maximum encountered temperature reading (step 40). In any event, the new virtual project event is routed by the CMC to the CAIC (step 23) to operate according to the above.

As shown in FIG. 5, when Manufacturer X loads a pallet for shipping, Manufacturer X attaches a dynamic temperature sensor to the pallet, resets the sensor's memory and activates it (step 50). The sensor measures temperature at a schedule (step 52), stores the measured temperature along with the time stamp to a history on the stamp (step 54). If the temperature reaches the maximum value encountered, this new maximum value is also stored on the flag (step 56).

Figure 6 depicts the response of the system of the present invention to loading cases onto a pallet with sensors (step 60). Indicia readers connected to the OIC and belonging to the manufacturer sense the indicia and its UIDs and generate SEEN events as UIDs and transmit to the CMC (step 64). The CMC routes the events to the CAIC (step 66). Based on the input data in the event, the CAIC updates the status and status history of the virtual items identified by the sensing UIDs (step 68).

When a tag is sensed by a reader belonging to shipper Y and connected to the OIC, the CAIC updates the inventive system. Figure 7 illustrates this update operation. An indicia reader belonging to the carrier and connected to the OIC senses the indicia of the boxes containing inductive indicia on the pallet and reads their UIDs and T _max data (step 70). The OIC generates and sends SEEN events and the data to the CMC (step 71). The CMC routes the event to the CAIC (step 72). The CAIC updates the state and history of the corresponding virtual item according to the received data (step 73). The CAIC determines whether _Tmax is within limits (step 74). If not, the CAIC sends an alert event to the CMC (the "no" branch of step 74; step 75), and the CMC routes the alert to the manufacturer's and shipper's ERP applications (step 76).

Upon receipt of the shipment, Retailer Z reads and confirms the exact maximum temperature data for the product from the attached RFID tag and expiry date. Figure 9 illustrates this read operation.

When a damaged box is detected, it is identified and the CAIC alerts the warehouse manager using the HIC component. SMS (Short Message Service) messages, pager messages, or any other convenient form of messaging can be utilized for this purpose. Figure 8 illustrates the operation of this alert, where the tag reader belonging to the retailer and connected to the OIC senses and reads the UIDs of the tags of the case on the pallet containing a sensor tag with a UID, and senses and reads a maximum temperature T _max and a temperature history T _history (step 80). The OIC generates and sends SEEN event and UID, T _max and T _history information to the CMC (step 81). The CMC routes the event to the CAIC (step 82). The CAIC updates the status and history of the virtual item according to the input data (step 83). The CAIC also calculates a new expiration date for each case based on the T _max and T _history information and manufacturer's rules (step 84). If the CAIC determines that the case is damaged ("yes" branch of step 85), the CAIC sends an alert event with UID and T _max to the CMC (step 86), which alerts the route to the HIC (step 87). The HIC then sends an SMS message alerting the retailer's inventory manager (step 88). Regardless of whether the case is damaged, the OIC determines whether there is a request to write the data into the tag (step 89), and if so, the CAIC generates and transmits a WRITE DATA event to the CMC along with the UID and the data about the tag ( Step 90). The CMC routes these events to the OIC (step 91), which writes "Valid Until" and T _max data to the tag

The system of the present invention may receive environmental information, such as traffic or weather information, from third party providers. Basically either have the provider send out the information or have the system ingest the information to bring the information into the system. Such information may allow the system of the present invention to report or predict shipment delays or other conditions that may affect the movement or condition of incoming items. Figure 9 illustrates an example of a provider supplying information to the system. In FIG. 9, a traffic information provider generates an INTRODUCE virtual condition event with a UID and characteristics and sends the event to the CMC (step 120), which routes the event to an OIC (step 122). The receiving OIC generates a NEW virtual state event and UID to the CMC (step 124), which routes the event to the CAIC (step 126). The CAIC determines that the event is the type of the NEW virtual state event (branch of "yes" in step 128), and generates a new virtual item as UID (step 130) according to the specific data, and stores the new virtual state data (step 132).

2.2 Two-way data flow

The system of the present invention can provide data flow on tags as well as bi-directional data flow. Figure 10 illustrates one approach. A label 152 is affixed to a box 150 . The tag contains a UID and can store an expiration date, a maximum temperature threshold, a maximum encountered temperature reading, and a price. The temperature data on the marker 152 may be updated as frequently as the temperature of the case 150 is measured, for example at a temperature measuring station which may write its readings to the marker 152 or may operate a temperature sensor connected to the marker 152 .

Data on tag 152 may be automatically read by tag reader 158, for example using RFID technology. In one embodiment, indicia reader 158 periodically "scans" its environment within a specified range. In another embodiment, the tag reader is triggered to scan its environment, for example by a distance sensor. If a scan returns valid read data (via communication 154 ), eg, due to tag 152 being moved into scan range, tag reader 158 will transmit the received data to system 166 (via communication 162 ). In this example, assume that the inventive system 166 maintains a virtual item 168 that was previously imported (via communication 172 ) by an external application 174 that also defines and attaches a rule 170 to the virtual item 168 . Rule 170 may be defined as "If the maximum encountered temperature of a box stored on its badge is greater than 45 degrees Fahrenheit, write the current date as the valid date onto its badge." Rules 170 may be defined in any format, syntax, or computer code compatible with system 166 . Whenever the system 165 receives new data read from the tag 152, it will execute the rule 170. If the rule 170 returns a positive result, the system 166 will calculate a new valid date such as the current date, and send the new valid date and the UID of the tag 152 to the tag writer 160 (by communication 164), and make the tag write Importer 160 writes new date-of-valid data into the date-of-valid data field on indicia 152 (via communication 156).

FIG. 11 illustrates another scenario in which the external application 174 periodically queries the system 166 for the latest status of the maximum encountered temperature of the case 150 stored on the tag 152 . In this scenario, the logic can again be defined as rules 171 , as part of the external application 174 . The external application 174 sends an event to the system 166 that includes the UID of the token 152, a new expiration date, an updated price, and updated control information. The event trigger system 166 sends the received valid date, price and uID to a token writer 160 (via communication 164). The inventive system 166 then causes the tag writer to write the received data into corresponding data fields on the tag 152 . The aforementioned communication can be carried out through any communication medium, including over a network like the Internet.

In these schemes, having a tag reader that can read the data stored on the tag 152, a receiver of the case 150 will recognize an expiration date and price that is used to track the case 150 during the tracking process. based on exposure temperature.

Figure 12 illustrates one aspect of the data flow process. In an illustrated example. The system of the present invention receives characteristic information about the first item including its UID by reading a first tag located on the first item (step 1202). Similarly, the system of the present invention receives information about a second item and environmental information derived from data automatically read from sensors associated with the second item (step 1204). The inventive system uses this information to maintain a virtual first and second project (step 1206). The inventive system also receives relationship information indicating relationships between items and maintains a virtual relationship (step 1208). With this information, the system of the present invention may identify an alert condition associated with the first item based on at least some of the virtual items (step 1210). In response to the alert condition, the system of the present invention generates updated property information for writing to the first item (step 1212). The system of the present invention then detects the presence of the first tag at a tag write site (step 1214) and causes the tag write site to write updated information to the first tag (step 1216).

In these schemes, the alert condition can be identified, and the rules for responding to the alert and computing updated information are done within the system itself or in an application external to the system. In the latter case, the application receives from the system information originating from objects maintained by the system and generates updated property information and provides it to the system of the invention with a request to write to the first tag.

Fig. 13 illustrates another aspect of the data flow process. In an illustrated example, the system of the present invention receives characteristic information about a first item derived from tag data automatically read by a first tag reader from a first tag located on the first item (step 1302). The inventive system also receives updated property data about the first item (step 1304). The inventive system then detects the presence of the first tag at a different tag write site (step 1306) and causes the tag write site to write updated information to the first tag (step 1308). In this scenario, this updated information can be calculated within the system itself, or it can be done in an application outside the system. In the latter case, the application receives from the system information originating from objects maintained by the system and generates updated property information and provides it to the system of the invention with a request to write to the first tag.

3. Another example of the system of the present invention

As shown in FIG. 14, a system consistent with the present invention can be implemented with a shared ITS (Item Tracking System) and multiple, usually private, domain ITSs. The system of the present invention need not have an explicit top level and shared nodes. Certain implementations of the inventive system will be a federation of businesses without having a hierarchy above the businesses. Other implementations would be multiple top-level, shared nodes, each possibly supporting a particular business unit at the business level. Typically, the architecture will be driven by various considerations, including in supporting protocols within the enterprise.

In FIG. 14, the existing ERP (Enterprise Resource Planning) system 1401 can be any regional enterprise software for managing goods movement and storage. ERP systems for each business (or portion of a business) may be different.

Each enterprise has multiple tag readers 1402 that supply digital information from digital identification tags into an area ITS. Generally an indicia reader is any combination of hardware and software capable of feeding digital data collected from any item or container. The reader can be placed on the production line, in a storage location, in a truck or other mobile carrier, or it can be a hand-held wireless link device. Certain implementations optionally interpose hardware and software between the physical physical reader and the ITS.

In FIG. 14, each regional ITS 1403 is a hardware and software system that can be implemented on one or more computer systems. This system is typically geographically regional with respect to the rest of the business, but can be placed virtually anywhere that is properly linked to the regional ERP system and indicia readers. Usually an ITS serves a single enterprise or a part of that enterprise. Thus, when there is more than one regional ITS, each may be operated by a different enterprise. An ITS can also be connected to other existing enterprise software systems, such as those used in supply chain management, logistics, customer relationship management, and new software services formed from the data available that make up the ITS.

A shared ITS 1404 is an item tracking system shared by multiple regional ITSs. It is widely connected to multiple regional ITS systems and may also be connected to multiple other shared ITS systems. A shared ITS can also be connected to other new and existing enterprise software systems.

Zones and shared ITSs communicate over a network connection 1405, which can be any computer-to-computer connection technology. Often this communication between businesses is encrypted for security, and digital certificates or other security methods are used to authenticate participants in the communication. The communication medium may include a public network. This connection typically communicates in real time or near real time information representing the location of the marked item and other information representing shipping documents, shipping carriers, and the like.

A single location 1406 is the collection of hardware and software required to support zone operations. A location may be a manufacturer, a distributor, a retail establishment, a private residence, a repair station, or any other location or portion of a location that handles marked items.

New as well as existing applications 1407 can be existing enterprise software systems such as those for supply chain management, inventory, customer relationship management and new software services formed from the data available that make up the ITS. Through a network connection 1408, the applications can query the ITS for current status, past history and other information about the items it tracks. These queries do not alter the state recorded within the ITS system, and can be manipulated with little or no loss of utility by processing the ITS's state record stored in a permanent storage area without Handle queries on field data in the ITS.

Figure 15 illustrates the basic software components within the project tracking infrastructure. A real-time input processing software 1501 receives configuration and other information from indicia readers, existing ERP systems, and other ITS systems. These messages can be in XML or other formats. The messages may represent artifacts of physical or logical items, or changes in the configuration or state of these items. This portion of the software interprets incoming messages, consults the data storage item 1502, takes appropriate action based on message content and stored data, updates data structures and may return error messages or other reports to the source of the message.

Data structures and persistent storage 1502 record and maintain representations of the relationship and the state and history of the logical and physical items tracked by the ITS. For example the software may record a unique designation corresponding to a particular jar of detergent. The detergent may actually be in a case (another unique identifier and item known within the ITS), it may be on a truck (another unique identifier and item known within the ITS) and the response is real-time The information and software operation of the processing software 101 for real-time input may periodically update the location of the truck. The data structure may also record the detergent as part of a shipment (a logical item with UID). The data structure and persistent storage save the data structure in case of any hardware and software errors. Any sound method of establishing permanent storage can be used, for example, someone can use software database technology and disk drives to record information in a form that is not easily lost.

A software interface for querying 1503 provides an interface between the ITS and external enterprise software applications. For example, if a traditional ERP (enterprise resource planning) or SCM (supply chain management) system needs an update on the current physical location of an item, it sends an inquiry. The ITS persistent storage area can provide the necessary information for operation, and the interface for interrogation can use this information to operate such as "report all batteries (by a product code) of a specific type currently located in a given geographical area." identification)" query. Or a query like: "Report all cartoned milk that is 48 hours before the best by date"

3.1 Software update

The core 310 of the ITS infrastructure (shown in Figure 16) should operate continuously at all times. Since economic activity depends on a certain part of the system, it is not practical to stop the system to maintain or update the system. However, the inventive system will need to be updated in various ways. The structure thereof will be described below to meet this need.

Three types of software updates will be considered: adding or removing fields (ie, attributes), adding or changing encodings of semantic notifications that implement field content (ie, computer program instructions), and major system updates. Each will be discussed here in turn.

Manufacturers, distributors, retailers, and others may need to add or delete data fields representing individual items or groups of items for the convenience of field operations. For example, you might want to add a field indicating the temperature at which the item was processed. This information may be important, for example, for long-term reliability and product return studies. The processing temperature field contains information different from the existing temperature field, such as the current temperature or the maximum sensed temperature when the device is being transported or stored. It can also be handled differently. For example, the manufacturer may wish to process temperature values for long-term storage for reliability studies, but not to disclose them to other manufacturers or to any institution.

Other examples of adding or removing data fields include: a retailer wishes to record items that were sold but then returned. A regulatory change and some jurisdictions require a shelf life for this product; this field is to be completed by the manufacturer and operated according to the requirements of distributors and retailers.

In another example, a distributor is responsible for providing return shipments on items that are returned to the manufacturer by the customer. The assignor would like to add a field "Return Shipment Responsible Party" which will automatically fill in the assignor's name, so the legally responsible party is responsible when the item is returned. This assignor information may be available from history. But the extra field makes it clear who is responsible without asking for history.

In general, the system of the present invention can dynamically add a new data field (ie attribute) to any existing object. Furthermore, the object record can be received by any higher or lower hierarchical system without program design changes and without changes to past or future objects of the same form.

You may wish to remove data fields that only make sense when the object is in a certain state. For example, fields related to a Shipping Form or Packing Form are only valid if the object represents an item that is part of the current shipment. Once the shipment is formally received, the shipment field is removed from the dynamic data structure (but remains in the history). Optionally mark invalid fields as invalid if they are not removed.

Adding or changing the code that implements the semantic behavior can update the system, and it is generally desirable to continuously increase the system's capabilities and improve older functions. These changes require many choices, such as: when new capabilities are added, who designs the program, how to test and how to minimize the impact on other activities.

Examples of situations that require adding or changing semantic behavior include: a new member joins a partnership and requires new functionality to manage its various goods. Existing functional changes, such as a method of managing shelf life settings, or developing a better loading procedure into trucks.

Any project that adds functionality to the infrastructure may need to add new data fields.

Changing the semantic behavior could bring down the whole system. Therefore it is dangerous to have full control over how the tests are done and to introduce new code that changes the semantic behavior. It is generally possible to change the semantic processing of a particular item form and to change a particular item without stopping the operating system. Furthermore there is a great deal of confidence that the behavior of other objects will not be changed.

Major system updates are possible, including updates to change all software, update disk drive formats, and update hardware, and in general the system of the invention apparently allows central system operations to switch between two hardware/software configurations without causing any problems. Saw loss of service. This step should be very good.

For system reliability factors, a shadow system may be run. Such a system also provides a mechanism for major system updates.

As shown in Figure 16, separate active data storage from all semantic methods. The core 1610 provides a small set of basic functionality but is otherwise independent of any particular object processing. Therefore, the core 1610 does not need to be changed when new data fields or new semantic processing are added. Such a core is very common and can be optimized for its basic functionality and very high reliability. The core 1610 programming will rarely change.

Other parts of the inventive system communicate through inter-process communication or file exchange, so that the core 1610 can continue to operate even if other parts fail and must be restarted.

The core 1610 can be restarted from a previous snapshot. It can then be brought up to date by replaying past events (hypothetical repeatability) or reconstructing the current state using what is available from persistent storage. As described below, changes that have not been committed to persistent storage 1620 must be re-executed.

A small set of functions that will support all the various requirements of the system in an efficient manner is described below.

As shown in FIG. 16, the stateless real-time semantic section 1630 performs the following operations: (1) It receives configuration messages from the network. A configuration message always specifies at least one item. (2) It retrieves the object corresponding to a specific item. Locking can usually be avoided. (3) It can use object-derived information to select an appropriate semantic processing method. (4) It retrieves any further object needs, locking if necessary. (5) It calculates the update object record. (6) It propagates the changes to the core 1610 and may unlock all object records.

The real-time semantic section 1630 is completely stateless. It is therefore possible to switch off any part at any time, restart and continue operation. This greatly helps to dynamically load new semantic methods, eg using Java mechanisms, and recover from any errors.

There are a number of mode selection methods to apply to an incoming configuration message. The appropriate encoding depends both on the type or kind of object and on the indicated configuration. For example, loading a shipping vehicle will likely be very similar for most objects, but the "sell to end user" configuration may be highly dependent on the type of item. At least two implementations can be used alternatively: (1) rely on the explicit product type field used in the ePC, as proposed by the MIT Auto-ID Center. (2) Query the specified object and its possible root-type objects to obtain an item type identifier.

The second method does not depend on the deployment of the ePC numbering scheme and is compatible with any marking system. Again, its devious hierarchy allows a wide variety of objects to be handled by the same software. For example, all detergent products from one manufacturer may be treated with the same code, while detergents from other manufacturers may be coded differently. Finally, the core 1610 can be configured so that individual items can be flagged to trigger different encodings. This allows real-time testing of new codecs limited to small collections of objects. For good results, this code is multi-threaded. This allows the object (and possibly any root objects referenced by the object) to be retrieved before the semantic code is dispatched.

The core 1610 may advantageously be implemented so that it is not persistent. To provide flexibility and speed, the core 1610 may be a computer memory subsystem. The core 1610 can also optionally map directly to the persistent storage mechanism 1620 .

The persistent storage mechanism 1620 is a module that takes a stream of object change notifications from the kernel 1610 and commits them to persistent storage. A current snapshot of the state of the system can be quickly created from the storage area information.

The history mechanism 1640 is provided below. There are two sources of activity for the system of the present invention: configuration messages, which usually represent beeps or signals originating from an individual project, and queries made by external systems to accumulated object data. The object move beep updates the core 1610 because it represents a change in the item's domain state, but does not need to be wired into the past history. This external query is related to the movement history and current configuration, but is not required to change the state.

The inventive system can accumulate history and also have a last look at the current state, so it can be optimized for large non-real-time enhanced queries. Because it is read-only in nature, it can be easily replicated to support a large number of queries.

The history mechanism also requires permanent storage. Therefore, the history function is usually included in the permanent storage mechanism 1620 .

The core 1610 has a minimal set of functionality. Objects can be created and extended, including the following functions:

(a) create an object, and

(b) Add or delete a property name-value pair. All object names are unique and arbitrarily sized. A name is taken from an extendable list to avoid proliferation and avoid conflicting names with inconsistent semantics.

The core 1610 can access and change attribute values, which can in particular:

(a) returns all attributes (name-value pairs), and

(b) Update attribute name value pairs.

The core 1610 has specialized (built-in) attribute list 1710 functions, such as named set ownership and membership, including:

(a) the ability to make object owners (roots) with a new type-name set, and

(b) Adding and removing members from a named set.

Finally, the core 1610 has rarely used object locking, including the following capabilities:

(a) lock the object - provide the signature, and

(b) Unlocking objects - providing consistent signatures.

This very small set of core 1610 functionality has little to do with markers and readers, nor does it have much to do with the item's location in the physical world. This is a major advantage. This data structure is general enough that it does not need to change the semantics of items passing through the supply chain or other applications. The core 1610 software is highly optimized to perform a small set of operations, while semantic changes are accommodated in stateless semantic methods. It is true that many collections will be locked into the data structure as they evolve, and some semantic changes may require reconstruction of the current object structure. However, this can be done in an on-site system without requiring software changes to the core 1610.

The table below provides a simplified example of how these frameworks can be used.

#1147: {object_id: #1147} {object_type: base_EPC_type} {software_version: 2} {kind: "detergent"} {PML: "http..."} {EPC_TYPE_COLLECTION_ROOT: #341, #576...} #341: {Object ID: #341} {Object Type: EPC_Object_Entity} {EPC_TYPE_COLLECTION_Members: #1147}{container_collection_members#3328}

#576: {Object ID: #576} {Object Type: EPC_Object_Entity} {EPC_Type_Collection_Member: #1147} {Container_Collection_Member #3328} #621: {Object ID: #621 } {Object Type: EPC_Object_Entity} {EPC_Type_Collection_Member: #1147} {Container_Collection_Member #3348} #2287: {Object ID: #2287} {Object Type: EPC_Shipment} {SHIP_COLLECTION_ROOT: #3328...}{SHIP_COLLECTION_MEMBER: #3347}{SHIP_SYSTEM_Origin: "R/3_4.6"} #3328: {Object ID: #3328 }{ObjectType: Container}{Object_Description: "14×18×10Carton"}{Live_Position_Type:Follow_Higher_Layered_Container}{Container_Collection_Root: #341.# 576} {Shipping_Collection_Member; #2287}{Container_Collection_Member; #4421} #4421: {Object ID: #4421} {Object Type: Container} {Object_Description: "10,0001b Truck"} {Live_Location_Type: GPS Longitude-Latitude-Altitude} {Container_Collection_Root: #3328} {Latitude: 32N} {Longitude: 60.45} {Altitude: 327M} {Location_Last_Update: 1/12/ 200214:27} #3348: {Object ID: #3348} {Object Type: Container} {Object_Description: "Warehouse Shelf"} {Live_Location_Type: Fixed Storage Location} {Storage Area_Location_Area: " shelf 3'} {container_collection_root: #621...}

{Container_Collection_Member: #4462} #4462: {Object ID: #4462} {Object Type: Container} {Object_Description: "Warehouse Area"} {Live_Location_Type: Fixed Storage Location} {Storage Area _location_area: "area 16"} {container_collection_root: #3348...} {container_collection_members: #4481} #4481: {object id: #4481} {object type: container}{ object_description: "warehouse"} {live_location_type: highest-level fixed location with lat/long/altitude} {container_collection_root: #4462...} {latitude: 31N} {longitude: 60.45 }{Height: 100M}

The above table describes a rather complex situation, also illustrated in Figures 18 and 19.

As shown in the table above, #1147 represents the product category "detergent". Certain canned detergents are represented by object entities #341, #576 and #621.

As shown in FIG. 18 , two of these cans of detergent 1810 are in a carton 1820 . The carton is in a truck 1830 and the truck has a GPS location system for real time location returns. The box is part of a particular shipment. There is also a third can of detergent 1940 stored in a shelf 1960 in an area 1970 of a warehouse 1950 .

The aggregation mechanism gives a great power to data structures such as:

Given an object ID of the detergent EPC base type (#1147), one can query the collection and get all the facts about the detergent and its current location.

Given a repository's object ID, one can discover all items in the repository and where they are stored.

Given the object IDs for all instances of a detergent, one can find the corresponding shipping number, if one exists.

Given a shipment's object ID, one can find all the items and their locations.

Given a truck's object ID, one can find all the items in the truck and their associated shipping documents.

data recovery

Data recovery is a key issue. When a beep is detected on a leave of the network 2010, FIG. 20 illustrates the delay within the system thereafter until the meaning of the beep is recorded in the persistent storage 2020. Assuming a catastrophic failure is at a shared (central) location, recovery means starting with the information currently on disk, and then considering all changes that have not been processed.

One way to recover is to record a certain amount of history within the network infrastructure itself 2060 . For example, a publish-subscribe configuration mechanism can be set up with a reliable internal persistent data store. Another way is to have persistent storage at each leaf node of the network.

All required storage 2040 equals the delay through the system from the time the indicia reader reaches system permanent storage.

It's often not easy to determine which events worked and which ones were missing. Furthermore, there is no inherent order of event processing between the real-time semantic section 1630 and the core 1610 . Assuming all processing is idempotent and independently sequential, replay enough events to cover the largest possible loss of work. If this condition is true, the semantics of causing operation 2060 are: If events are processed in a different order or the same event is processed more than one instance, the final system state will be the same.

location update

Certain high-value items, as well as transport vehicles such as trucks, can be tagged with a real-time location system (RTLS) that updates location periodically. For example, Santa Clara, California-based WherNet offers WherTag markers that periodically broadcast their identification to an area using the 2.4GHz frequency band, and whose location can be determined by triangulation. These tokens are broadcast at regular intervals ranging from seconds to minutes and can only be changed by entities accessing the token.

In addition, wide area systems can utilize GPS (Global Positioning Satellite) receivers combined with a traditional communication system, such as operating telephones or low-bandwidth satellite upload systems, to provide regular location updates. The communication system can be polled for the current position from a base station in turn, or the communication system can be called in time intervals that can be programmed remotely.

A basic capability of a tracking system is to receive reports of location information. While it would be convenient to use only one method to report position, using latitude and longitude in a very narrow area such as a building or a warehouse would run the risk of unnecessary extra computational steps, so usually Uses an offset from a referenced area frame. For wide area use, the latitude, longitude and altitude data available from a GPS system are suitable.

batch identification

Often, more information is provided to the item tracking system than just beeping when an item is seen by a reader. This information may be the configuration for an upcoming batch of items in the plan being read. For example, "The following items are being pulled from inventory and packed into shipment x". Information about this shipment is provided elsewhere by the system of the present invention.

This information can come from a terminal near a tag reader directly connected to a system application (such as a web browser-based application), or indirectly from a local system , which can pass an appropriate message to the tracking system.

Since items usually arrive in batches, the beep can be stored regionally until the end of the batch is recorded. The reader or field system then sends a message to the tracking system containing information about all items in the batch. The message may be in a markup language format such as XML.

Each batch can be given a unique ID. A batch number (Lot-ID) is a means of succinctly communicating general information about a group of items. Each reader can have a default lot-ID, which is used when no lot-ID is specified. If batch-ID is used, the message from the reader can be of the following form:

Time stamp, batch-ID (such as 96bit ePC), project-ID.

Using batches in this way supports a sorting function for when items are not batched before they are read. For example, an assembly line may have a sequence of items and a sequence of boxes. The reader reads the markings on each item and decides to put the item in bin 1 or 2 or 3, for example. Each box may represent, for example, a different configuration. The reader puts a different batch-ID on each case, and each item is linked to the batch-ID of the case placed somewhere.

A basic lot design can include readers with a unique ID and shipments that also have a unique ID. The reader is linked to the shipment to create a specific lot with a unique ID. Multiple lots originating from the same or different readers can be combined into the same shipment. The necessary base shipments may include a unique ID, a regional shipment number (such as that used for a regional ERP), a shipment target, a target delivery date, and a target delivery time.

The association between each item with a batch rather than a reader allows information to be safely repeated without confusion. For example, if configuration information is re-transmitted, the state of the system of the present invention will not change if lot-item pairs are used instead of reader-item pairs due to reasons such as system errors or reboots.

configuration operation

A configure operation describes state changes related to or associated with a tagged item on a hierarchy of objects and items. Configuration operations include such as building an item or first instance bringing in an item to track, location changes, inventory confirmations, shipping, loading, unloading, and end tracking.

The configuration operation "build item" records the initial attributes of an item, such as manufacturer, type, date and place of manufacture, and the like. This action can include initializing the token with some provided data. It usually contains instructions on where the item was originally stored.

The configuration operation "change of location" means that the item will or has been moved to a new given location. "Inventory Confirmation" means that the item is recorded when it is sensed at a storage location.

The configuration operation "shipment" means that the item is designated as part of a shipment. A shipment number known to the regional ERP may be given.

The configuration operation "loading" means that the item is sensed when a particular carrier is loaded. The truck or other shipment ID can be combined to a shipment ID.

The configuration operation "unload" means that the item is sensed when a particular carrier is unloaded. The carrier ID can be combined to a shipment ID.

The configuration operation "undo" is an operation which effectively cancels any past configuration for the same item and same batch. It is often necessary to undo past configurations. For example, undo occurs when loading too many items. This operation is not idempotent.

The configuration action "end tracking" means that the tracking system does not expect to see the item again. This action may occur at times such as retail sales or when item packaging is unpacked and boxes are recycled. The system of the present invention may archive this item data for future assurance or historical purposes.

There are also many possible configurations. Flexible configuration assignments are preferred.

to ship

A Shipment Identification A Packing List, typically in the form: Item-Type Quantity List. A shipment also defines the movement of these item-types to a destination in the plan. The target could be a customer with an address, or another location of the same company. The tracking system determines a location about the address, such as latitude and longitude, or receives this information as part of a shipment description.

The regional ERP system is aware of the shipment. The tracking system can retrieve the shipment information, match specific items with generic item-types in the shipment table, and report discrepancies.

One or more planned shipments can be linked to a specific carrier. For example, several different shipments, partly to the same address and partly to different addresses, can still be loaded onto the same truck. The system of the present invention can verify that the truck is loaded correctly. In addition, the system of the present invention can track or estimate the location of the truck and respond to inquiries regarding the location of the cargo.

A given logical shipment can actually be spread across several delivery trucks. Such allocation can occur above the system level. In this case, the inventive system tracks physical shipments rather than logical shipments.

The system of the present invention can identify the carrier and specify how to communicate with it. The inventive system can thus respond to questions such as: "Tell me the driver's name and cell phone number about the contaminated meat shipment to San Francisco."

transport-route

The "shipping route" information is information about the expected geographic path of a shipping vehicle, such as a ship or truck. It can be a series of way-points, such as cities, highway intersections, individual highway or street names, latitude and longitude, and so on. This transmission route can be provided explicitly. For example, the transmission route can be entered manually. In addition, the transmission route may also be calculated or inferred as described later. A transmission route applies directly to a transmission carrier, and only indirectly in certain shipments.

configuration message

A configuration message means that a specific item is sensed at a specified time and is part of a lot for a specific configuration, eg, moved to another storage location, shipped to a customer, and so on. The configuration message may be of the form:

Timestamp, Batch-ID, Item-ID.

This succinct message combines an item, a reader, and a shipment number known to the regional ERP system. Repeated transmission of the same configuration message has a highly advantageous property because it does not change the state of the tracking system.

tag memory

The system objects and functions described are only relevant for trace flagged items. However, certain applications may require some layer to write data to a tagged item when the tag is sensed. The system of the present invention can write and read such tag data at any location.

The system of the present invention can provide large-scale event reporting. For example, the system of the present invention can report to other applications when certain milestone events occur. For example, when a shipment arrives at a customer, the system of the present invention can send a message, thus triggering the list.

3.2 Cross-enterprise visibility

The inventive system enables cross-enterprise visibility of items located in a supply chain. The system of the present invention can receive, store and create visible configuration information about items, such as the location of items as they move within a single enterprise or across multiple enterprises. In addition, the system of the present invention can receive, store, and create visible correlation information that links items to customer orders, shipping documents, and other business transactions. The system of the present invention can receive dependency or configuration information from any receiving participant or business in the supply chain and can make this information visible to other supply chain participants or businesses.

As shown in Figure 26, the system of the present invention can track items on a large scale and provide access tracking information. For example, its infrastructure can track items that are located in many different environments such as factories, warehouses, retail stores, and homes across countries or the world.

control visibility

In one example, the system of the present invention can provide visibility of control. In other words, only a subset of item tracking information is made visible to particular participants in the supply chain. As shown in FIG. 28, the system of the present invention may receive authorization information indicating authorization settings for various properties of an item. The system of the present invention can use this authorization information to determine which features are made visible to which businesses. For example, the authorization schema shown in Figure 28 indicates that the item's target properties should be seen by the sender, but not by the manufacturer. Control visibility is discussed in more detail under the heading "Access Tracking Items for Controls" below.

world model structure

Figure 27 illustrates a multi-enterprise shared world model (WM) structure. The world model is a structure that records and maintains a description of the relationships, status and history of items tracked by an ITS. The world model that can be implemented is a two-tiered structure: a higher level upper level WM 2710 that keeps track of items located within a particular enterprise; and a lower level region WM 2720 that keeps track of The item at the location of an entity. The local VM can be accommodated in a shared ITS 1403 (as shown in FIG. 14 ) and the upper layer WM can be accommodated in a shared ITS 1404. Through a network connection 1405, a superordinate WM for an enterprise can communicate with superordinate WMs of other enterprises or superordinate WMs of other departments or levels in the enterprise.

Figure 27 depicts a federated or peer-to-peer partnership arrangement in which each business shares information directly with other businesses. Other kinds of arrangements may also be supported by the system of the present invention. For example, Figure 29 shows a hierarchical or composite arrangement in which each enterprise's upper level WM 2920 provides information to a central WM 2910. A combination of federated and hierarchical arrangements is also an option. For example, one of the upper-level WMs 2710 may also represent the central WM 2910 as a combination of upper-level WMs 2920 in federated mode.

In FIG. 27, each enterprise is described as having a single WM 2710, however in some cases, such as for marketing purposes, the upper WM 2710 may be implemented as a cluster of upper WMs 3010, as shown in FIG. 30. Each upper level WM 3010 maintains connections to regional WMs 2720, remaining upper level WMs 2710 in other enterprises, and higher level business applications such as ERP systems.

3.3 Close integration between data communication and world models

The following section describes a system and method for linking data across multiple nodes in a decentralized architecture, such as the federated architecture depicted in FIG. 29 .

This method provides bi-directional transmission between regional WMs 2720 and upper layer WMs 2710. Upper level WMs 2710 can report other WMs about item changes in the track (eg recall notices or price changes for contaminated meat). Conversely, regional WMs 2720 may report item configuration changes (e.g., item creation, movement, or termination) to upper-level WMs 2710.

For each item, designate at least one upper-level WM 2710 as the responsible WM for that item. Generally, the responsible WM is the upper-level WM of the enterprise, and the project is established in this enterprise (such as a manufacturer). Any information about the item received by any regional WM 2720 through the federation is reported to the responsible WM. In this approach, the responsible WM maintains a complete item history. The responsible WM can be replicated to improve data recovery. For example, it is also possible to designate a second WM 2710 as a WM responsible for the item, and any information received about the item is sent to the two responsible WMs.

Once any "commercially significant" changes have been reported to the responsible WM, other non-responsible WMs with information about the item are free to purge that information. Therefore, any independent zone WM 2720 can be restarted by a blank WM. However, changes that have not been reported before the restart will be lost unless they were stored in the local store before the restart.

Data is routed to the responsible WM

A zone WM 2720 receives multiple instances of tag read data, each instance containing information read from a tag attached to an item when an item is detected at the zone node. The multiple entities of the tag read data may collectively contain information read from the tag attached to multiple items in a shipment of items. Shipments in a supply chain typically contain one or more items housed in layers within the shipment (eg a shipment may contain pallets with individual items). Thus, in some cases, the region WM 2720 may receive data read from a shipping label, and with respect to items contained in the shipment (e.g., pallets, boxes, and individual items), the region WM 2720 may also receive data from It marks the data read.

For each item, the regional WM 2720 reports the tag read data to the WM responsible for that item. In order to determine which WM is responsible for the item, the regional WM 2720 may consult a correspondence table that maintains the association between the item and the designated responsible nodes. This correspondence table can be queried using all or any part of the item's UID.

Each item in a shipment may correspond to a designated responsible WM. Items belonging to different product categories can be mapped to different designated responsible WMs. For each project, the specified responsible WM can be the same on all nodes, or it can be different for each node. In other words, each node may maintain its own correspondence table and the associations within each correspondence table may vary from node to node.

For example, within a single enterprise, operating rules may dictate that all important business items be moved to report to an upper-level WM of the enterprise. The upper WM can be a single WM or a cluster. Once the movement has been reported to the upper level WM, the upper level WM can be set to report an item movement to other WMs outside the enterprise. For example, a retailer can report item movements to a manufacturer for more efficient supply chain operations. Thus, when a small part is sold at a retail level, the regional WM can decide which WM is responsible to be an upper level WM within the same enterprise. However, at the upper level WM node, the upper level WM may determine the responsible WM for the same widget as an upper level WM of another enterprise. In an example case, the remote WM may respond to the manufacturer of the particular small part. In another example, the remote WM may represent a business combination of all small parts manufacturers, etc.

In some cases, a node may be configured to act as a forwarding and routing agent for other nodes. For example, a manufacturer may identify a single externally accessible node for all updates from outside the enterprise. Once the update is received at this node, the node can consult its own internal corresponding table responsible for WM and distribute the update according to the product category. This spreads the computing and data storage load in a way that is invisible to the outside of the enterprise.

The next section describes the implementation of a protocol to exchange state information between WMs. This implementation uses a state exchange message to exchange state data between WMs. The message parameter contains the item's UID, the item's current state, and a time stamp when the state was last changed. The receiver of the state exchange responds with an acknowledgment message indicating the currently known state and a time stamp. The status exchange message is resent until acknowledged to be received.

project creation

When an item is first created at a physical location of a manufacturer (enterprise A), the area WM for the physical location (world model WM_AL1) receives a "build item" configuration operation. WM_AL1 then creates a logical representation, such as an object representation of the item, and specifies that the object is in a "dynamic, dirty" state.

The state of an object can be specified using a combination of flags, including "dynamic", "delayed", "dangling" or "dirty" flags. "Dynamic" means that the object represents its latest version. "Delayed" means that certain other world mods have unique dynamic versions. "Pending" is a temporary assignment for the system to retrieve the correct assignment. "Dirty" means that the status has changed in a commercially significant way since last reporting to the responsible WM.

WM_AL1 then reports the project creation to the responsible WM (WM_AP). This report may be in the format of a status exchange message.

WM_AP creates an area object that is designated as "delayed". WM_AP then places this object in the WhereUsed list for WM_AL1. The list used here corresponds to which objects in which area WM it is continuously tracking.

WM_AP then sends a Status-Exchange-And-Accept message to WM_AL1. This status-exchange-and-approval message can also contain information that the parent company wants to combine with the newly created project. Upon receiving the acknowledgment, WM_AL1 removes the "dirty" designation from the object.

Subsequent major corporate changes

Once a project is established, subsequent enterprise significant changes are also reported to the responsible WM. WM_AL1 changes the state of the object to "dynamic, dirty", sends a state exchange message to the responsible WM (WM_AP), and clears the "dirty" flag after receiving acknowledgment from the WM_AP that the change has been recorded .

move out of this location

When WM_AL1 detects that the item is at the exit of the location, WM_AL1 regards this condition as a corporate event and reports it to the responsible WM. WM_AL1 sets the object state to "delayed, dirty" and sends a state exchange message to WM_AP. WM_AP updates the area object as "delayed" and sends an acknowledgment to WM_AL1. WM_AL1 clears the dirty flag after receiving that acknowledgment.

Summarize and communicate target information

In some cases, the object of the project is known. The target can be any location within the same enterprise or another enterprise. For example, corporate documents associated with the project may contain target information. Enterprise file information is obtained by communicating with traditional enterprise software systems such as ERP (Enterprise Resource Planning). For example, enterprise information can be related to a specific shipment and represented by a hierarchy of item tags with shipments and order numbers understood by legacy systems. Organizations, locations, and shipping addresses are all combined with unique UIDs that are similar to UIDs assigned to physical items. The target WM for receiving further notification of the shipment may be explicitly specified in the field of the shipment record, or may preferably be calculated using the same mechanism used to find the responsible WM for a physical item.

For example, the responsible WM routing and update mechanism can be used to direct further notifications of the shipment hierarchy in the following manner. A Shipment Target record can be created with a UID whose responsible WM is calculated as the WM expected to receive the shipment. Once the shipment is physically aggregated and the shipment's specific item tags are known, the tag hierarchy can be recorded as a change to the shipment object record. Any changes to this record can be automatically communicated to the responsible WM, which has been set as the actual target WM. Once the physical shipment arrives at the WM, it can have all the marking information to fully verify the exact contents of the shipment.

In other cases, the destination of the shipment is not known within the system of the present invention. This can result in difficult integration with ERP systems. Both cases can be handled by the whole system.

Move to another location in the same enterprise (Location AL2)

If the target is known, WM_AP puts the object in the WhereUsed list for WM_AL2 and sends a status exchange message to WM_AL2. When the item reaches the AL2 location, WM_AL2 changes the object's state to "dynamic, dirty" and sends a state change message to WM_AP. WM_AP updates the area object and responds with a status-exchange-and-accept message.

In some cases, the target cannot be known in advance. When the item reaches the target location AL2, WM_AL2 creates an area object with a "delayed, dirty" state and sends a state and exchange message to WM_AP. WM_AP updates its area object and moves its area object to the "where used" list for WM_AL2 and responds with a status-exchange-and-accept message to WM_AL1.

Move to another business (location BL1)

If the target is known, WM_AP sends a status exchange message to the upper layer WM (WM_BP) at the target location. WM_BP responds with an Acknowledgment with Status-Exchange-and-Accept message to WM_AP and also sends a Status-Exchange message to WM_BL1. WM_BL1 creates a "delayed" object and puts it in an entry list. WM_BL1 responds with a status-exchange-and-accept message to WM_BP.

Once the item reaches location BL1, WM_BL1 changes the object's state to "dynamic, dirty" and sends a state change message to WM_BP. WM_BP updates the region object and responds with a status-exchange-and-acknowledgement message. WM_BP then sets the dirty flag and sends a status exchange message to the responsible WM, named WM_AP. WM_AP updates its area object and where-to-use list and responds with a Status-Exchange-and-Accept message to WM_BP.

If the target is not known in advance and the item arrives at BL1, WM_BL1 creates a "delayed, dynamic, dirty" object and sends a status exchange message to WM_BP. WM_BP creates a "delayed, dynamic, dirty" object and places it in the where-use list for WM_BL1 and responds with a status-exchange-and-approve message to WM_BL1. WM_BP then sends a status exchange message to the responsible WM, named WM_AP. WM_AP updates its area object and where-to-use list and responds with a Status-Exchange-and-Accept message to WM_BP.

Reduce the amount of data communication between WMs

In an alternate example, between a specific regional WM and a specific responsible WM, the two WMs can be adjusted so that not all items or item hierarchies in a shipment need to be reported to the responsible WM. Which items to report may vary between different WM pairs.

Information defining the project hierarchy can be provided to regional WMs as well as responsible WMs. For each item detected on an area node, the area WM can validate each item against the hierarchy information. However, when reporting to the responsible WM, the regional WM can only report items at a certain level in the hierarchy (e.g. the highest level) with an additional instruct.

Reliability in the event of message loss or copy delivery

A "dangling" or "dirty" state is a reliable transition from a "dynamic" or "delayed" state because state exchange messages are automatically resent until a confirmation is received. In some cases, a copy transfer can occur, for example, after a WM restarts from persistent storage. Since state change messages carry a timestamp, they only take effect if the deferred entity is earlier than the incoming update.

Traditional mechanisms such as NTP (Network Time Protocol) or GPS clock reception can be used to synchronize the clocks on the network, however, the system of the present invention can operate without a high degree of clock synchronization.

Cold restart of the inventive system

The system of the present invention can be rebuilt from empty area WMs. Any subsequent detection of an item results in the creation of a "dangling" object. Once all items have been seen, the WM will end.

regular cleaning

The region WMs can periodically request updates for "dangling", "dirty" objects, or objects that have not been updated for a while. Objects that have not been referenced for a period of time may be purged to spatial storage. The responsible WM may clear or remove long-term storage objects that have not been referenced for some time.

WMs in this area can periodically request updates for "dangling", "dirty" objects, or objects that have not been updated for a while. Objects that have not been referenced for a period of time can be cleared to spatial storage. The responsible WM may clear or remove long-term storage objects that have not been referenced for some time.

3.4 Project-based identification schemes in international trade

The following protocol describes, with reference to FIG. 54, systems and methods for the marking and tracking techniques required by government customs in processing information associated with importation. The application described below is based on a core networked information environment for an item tracking system (ITS) which will be referred to as the ITS core. The ITS core provides the following functionality to support current applications for processing information associated with the import of goods across international borders.

• It receives and maintains information from the Indicia Reader System used to identify individual items read by the Reader, and generally provides environmental information such as the intended configuration of the item.

It receives and maintains information specifying physical relationships between and among items, including changes in such relationships, such as one item being in or on top of another (e.g., a bottle in a box ; this box is on a pallet; this pallet is placed in a container; this container is placed on a ship).

• It receives and maintains attribute information associated with items in extended form, so that applications using the core can add new kinds of information to the information about items maintained by the core without requiring the Any reprogramming of the core.

• It provides information across enterprise boundaries in a generally accessible form such as self-describing XML (Extensible Markup Language) files.

• The ITS core provides, receives and maintains information specifying logical relationships between and among items, more generally both logical and physical items. Example: ITS receives information about a planned shipment specifying

(a) the exporting source factory,

(b) the destination recipient,

(c) the responsible export agency,

(d) a list of specific products to be imported with a unique mark identifier, and

(e) Unique reference to specific customs regulations for each item.

The logical items (a, b, c, e) are treated as physical items and have specific entries in the ITS. ITS uses the incoming information to establish and maintain logical relationships between physical and logical items. This allows any reading of the physical item markings of the shipment, eg, by customs officials at the port of entry, to be immediately correlated with the corresponding shipping documents and claim-related customs regulations. Similarly, any reference to any importer can immediately result in a listing of that shipment (or shipments). The logical project structure includes relationships to pallets, containers, vehicles, and other packaging, storage, or shipping units. The ship's position may be updated periodically, thus giving an actual picture of the position of cargo intended to enter a certain port. Therefore, when a ship comes into port, customs can know the exact cargo and their delivery and custody history without having to consult paper documents. This information can be used to dispatch appropriate personnel, focus on suspicious importers, and otherwise support customs operations.

• The ITS maintains a history of all movements of items reported by tag readers and other sources of information. This information may be used by customs agencies for their own monitoring and statistical purposes.

This information is also valuable to importers, carriers, and other parties who need to track the current location and deployment of their shipments.

In the implementation to be described, the ePC includes a displaced item identifier and item category as an extended form of EAN (European Article Number) or UPC (Universal Product Code) information. Whereas a PML (Physical Markup Language) file is used to include a physical description of an item.

ITS Core is an open, highly scalable, real-time asset tracking infrastructure that collects, integrates and distributes real-time asset information from networked project-uniquely tagged infrastructure to enterprise applications. This infrastructure is established using appropriate tag readers that are networked into one or more ITS systems. Thus, the movement of these tagged items can be tracked in real time from a central location each time the item is reported by a tag reader. A networked token establishes a two-way communication path between tangible and intangible items - known as smart items - that are uniquely identified by the enterprise and the corporate body, and the stakeholders who own and manage them. Some tags can be smart, thus resulting in smart items. Smart items and machines have tags that include and communicate any information written to the tags by the end user.

In addition to the commercial information written to a tag - such as its ePC, PML, size, weight, price, warranty period, history - tags also include administrative and customs information such as product-level rules and regulations, taxes and duties Information, updated trade agreement rules, preferential treatment regulations, tariff schedules for one or more countries, import restrictions for one or more countries, storage procedures, hazardous materials management information, speedy handling of shipments by customs and modernization goals any other information.

The ITS has information on location, status, customs processing status and other information on the processing of all marked items through the system. This information can be provided directly from the ITS or through existing and new applications that collect data from the ITS. Because the ITS core is open, generic, application-agnostic, and independent, it can handle the high volume of events Customs expects to handle, with more than 20,000,000 events per second in the United States alone, without the need for traditional provisioning The core enterprise software system of the chain management and logistics system bears the core enterprise software system. ITS tracks an extremely large number of individual items and shipping units, whereas traditional supply chain management systems typically only involve tracking quantities of items. For example, ITS can track 20,000 individual cameras, which traditional supply chain management systems see as a single entry.

The ITS core and applications described here provide certain key functions:

· Detailed item type specific information from customs to source manufacturer and importer;

· Secured, verified, detailed (pallet and item class, serial number related) communication regarding item, planned shipment from source manufacturer to Customs;

· Automated, paperless tracking of goods from point of origin to port of entry and beyond;

·Attach the pre-reported shipping plan directly to the actual imported goods on each pallet or project vendor's mark without the need to consult paper documents;

• When widely implemented, a networked instance of an ITS core based system can show real-time views of the location of many goods in the world trade system, planned ports of entry, pre-negotiated planned customs treatment of those specific items.

The customs system based on the ITS core can serve as a networked real-time asset data repository for national trade and customs agencies, PGA (participating government agencies), and authorized external stakeholders such as importers and exporters, trade facilitators, Foreign PGAs, shipping and logistics service providers, retailers and manufacturers.

Because the core of ITS is an application-agnostic and open network system, its data can be utilized and seamlessly integrated into any enterprise application environment similar to a database. The multi-dimensional real-time asset data can be used by any application for various operational and analytical purposes, such as supply chain management, customer and supplier relationship management, product life cycle management, financial management, human resource management, security and enterprise intelligence, here only gives some. Real-time asset data is multidimensional and it can have many components. For example, ITS can track when an item was moved, the relative position of the item within the container, the location of the container, logical statuses such as "reviewed and approved", responsible carrier, planned destination, etc.

One or more instances of the ITS core and supported applications can be used in mainframe, client-server, and distributed network environments, and can be deployed as local private networks as well as global collaborative networks, much like the Internet in use today. End users are able to access ITS data through multiple touchpoints including desktop enterprise portals within private networks, the Internet, direct encrypted telephone connections, personal digital assistants (PDAs), mobile devices and voice connections over telephones .

Figure 54 illustrates the various levels of automated ITS information flow as it relates to the importation of goods into the United States and the use of ITS information by US Customs and other agencies and businesses—referred to generally herein as businesses.

In FIG. 54, a company or a company group is represented by a rectangular frame. Their respective local ITS sources are indicated by additional oval boxes, and information flow is indicated by numbered arrows, the numbers in this figure corresponding to the headings in the following description of the various levels of the situation serial number. The local ITS resources of each enterprise can be one or more instances of the ITS core and supporting applications, and the ITS core and supporting applications together constitute a local ITS network. Only single and multiple networks are illustrated to simplify the drawing. The situation corresponding to Figure 54 proceeds as follows:

5401:

Retailers/end users place orders with international manufacturers or suppliers and specify product category, quantity, price and contract period, etc.

5402:

The manufacturer produces the product to the retailer/end user's specification, assigns and writes the ePC and PML file (PML) to each product's item unique tag, and provides this information to the ITS. (Alternatively, the PML and other information outside of the ePC may simply be recorded in the ITS data warehouse if the tag does not have the required storage capacity.)

The manufacturer writes relevant commercial data, such as price, warranty period, production date, product category, weight, size, manufacturer, shipping conditions and procedures, etc., to the label of each product; at the appropriate level (box, pallet, board crates, pails, etc.) on the packaging and shipping container of a shipment; and providing an item ID for said shipment. In any case, all this information is provided to the ITS so that it is visible to every application that can use the information. Storage on the tag is done for the convenience of customs officials and others with hand-held readers who do not have easy access to a network connection to the ITS website.

The manufacturer seals the shipment, and confirms that the shipment is marked and that the information on the mark is the same as the item planned for shipment, uploading the data to the central and partner US Customs ITS network. Simultaneously, the manufacturer sends order information to global shipping and logistics services for picking and shipping. Finally, the manufacturer notifies the retailer of the status of the shipment in real time.

5403:

US Customs automatically sends updated tariffs, special treatment and storage procedures, import rules and regulations and other relevant administrative information to PGA, Global Shipping and Logistics Services.

5404:

Global Shipping/Logistics Services automatically writes U.S. Customs administrative and tax information to the ITS and to the tag - to the extent the tag supports this, and to the carton associated with the product being shipped at the appropriate cargo level, Automatically write US Customs administrative and tax information on pallets, crates, etc. The Global Shipping/Logistics Services segment then marshals and sorts shipments in accordance with ePC and US and foreign customs norms and regulations. Products and goods are batched and arranged on appropriate levels and distributed to pallets, boxes, crates and delivery vehicles (trucks, ships, planes, cars, etc.).

Cargo information is sent to the appropriate local/foreign PGA and customs; this information generally includes means of transport identification information, import/regulatory information, weight, possible hazards, manufacturer, ePC, volume, etc.; data is assigned to the item being shipped /Crates/Crates. Cargo identification information can be uploaded to the delivery vehicle GPS (Global Positioning Satellite) and customs smart pass (similar to toll road car smart pass) systems that can be used to clear goods electronically, or can be made available. Global Shipping/Logistics Services provides U.S. and local customs, U.S. brokers, importers and logistics services, manufacturers and retailers real-time location, status and environmental information for all shipments handled, if required. The shipment is then made and the logistics service uploads the cargo location and estimated time of arrival to the foreign customs and PGA.

5405:

Foreign PGA/Customs provides real-time advance notice of shipment to all approved stakeholders, confirming and recording outbound shipment time, location and date with US Customs. Foreign PGA/Customs also automatically guarantees that said goods comply with the latest export requirements in terms of product and shipping class, industry and shipping location. Notify the appropriate PGA and private risk holder of said shipment. The foreign PGA/customs also ensures that the shipment is current with all export regulations and requirements, and that the appropriate PGA monitors the shipment as appropriate.

Finally, the foreign PGA/customs sends shipping storage and handling instructions to the appropriate shipping port and agency.

5406:

The foreign customs agency/port ensures that the appropriate agency structure is notified of the shipment and that the appropriate agency exists when the shipment is made. Foreign and U.S. agencies communicate special handling and storage instructions required for specific shipments.

5407:

At the US Customs Agency/Port, the following actions take place. Goods for the appropriate transport/logistics services are automatically scanned by the local non-intrusive reading system when entering the port/border entry location. The non-intrusive mark reader automatically confirms that the product received is the same as the product identified and shipped by the manufacturer per ePC and PML. Also confirm compliance with all regulatory and safety information written into the original label. If the shipment is wrong or fraudulent, the local agency is alerted to perform a human check, and appropriate preservation actions are taken. The appropriate agency and PGA are notified of the shipment and are present when the shipment is made. The US customs agency/port can also automatically ensure that the shipment complies with all current tariffs, preferential treatment, storage requirements, restrictions, regulations, etc. US Customs is notified of incoming shipments and is provided with real-time shipping information in the form of product category, price, volume, industry, etc. as required by US Customs Statistics. Appropriate and correct duties and taxes are automatically charged and billed. All relevant shipping information is sent to the US broker/importer. Some markers may be able to route and confirm the composition of the item being transported (eg, tires only include tire material, not pharmaceuticals or smuggled goods).

5408:

The broker/importer automatically confirms that the correct duty is charged and notifies the local logistics service and US Customs of the shipment status and deadline. The broker/importer also warrants that the shipping is correct and in compliance with the retailer's and the manufacturer's shipping terms and conditions.

5409:

The local shipping/logistics service notifies US Customs of the shipping status and location, and delivers the shipment to the retailer/end user.

5410:

The retailer/end user can log on to the US Customs ITS at any time, or access another system that can access status information from the Customs ITS, in order to identify the precise shipping status, condition and location. Finally, the retailer/end user confirms the correct shipment, notifies the manufacturer, and performs automatic payment; and confirms shipping and marking information based on shipping documents from the manufacturer, carrier, and customs.

The situation and system described above with reference to Figure 54 provides the following benefits.

1. Trade and economic growth

Real-time and seamless customs processing can be achieved through the use of non-intrusive, token-based viewing and inspection. Shipping and customs compliance levels can be increased. Real-time maximized business processing and asset tracking networks are provided and integrated with risk and safety management systems through the PGA and private stakeholders. Networked public-private cooperation and automatic assurance of fair trade practices are achieved. International trade agreements can be managed and enforced automatically. Substantially improve prevention of predatory and unfair trade practices through project unique and intelligent tagging technology and anti-spoofing warnings. Automate fiscal management associated with revenue collection through automatic tariff application and updates.

2. Border security

Automatically identify and intercept high-risk tourists before they arrive by using smart cards or tokens embedded in passports, travel tickets, driving licenses or other forms of national and international identification. Non-intrusive personal identification systems can be deployed through remote tag readers. Advance and real-time awareness of shipments of hazardous materials, weapons and munitions can be achieved. The exchange of information with private industry and the PGA regarding the export and import of sensitive or controlled goods could be improved.

3. Smuggling and trafficking of narcotic drugs

Automatic, non-invasive identification of possible narcotic drug shipments can be achieved through the use of transport and product telemetry (state, temperature, chemical composition, etc.) of high-risk cargo. Real-time data can be obtained on identified or possible shipments of narcotic drugs from identified high-risk transporters or countries, thereby enabling better PGA notification, collaboration, and resource allocation. Preemptive and automated deployment of markers to identified vehicles can be achieved, improving targeting techniques and interdiction tools.

4. Criminal Finance

A non-intrusive survey infrastructure can track automated shipping payments, matching actual payments to actual shipping prices and terms. False or erroneous shipping payments, potentially disrupting criminal financial practices in real time, can be automatically identified. Several countries, including the European Union, are considering embedding markings in actual banknotes, enabling shipments of large amounts of cash to be tracked in real time.

5. Public Protection

Substantial reduction and improved proactive management and real-time tracking of potentially dangerous, harmful and/or life-threatening situations arising from prohibited or illegal commodities can be achieved. U.S. embargoes and sanctions against certain industries, organizations, and/or foreign countries can be automatically enforced in real time, and the importation of fraudulent and/or counterfeit goods can be substantially reduced through automated and real-time shipment identification and confirmation systems. They can be extended and maximized by enabling non-intrusive viewing technologies such as x-ray vans, radio frequency and microwave airport security systems to read selected markers. Tag information can be associated with video detection based image recognition techniques for multimedia asset tracking.

6. Management Audit Capabilities

The allocation of agencies can be optimized according to the expected transportation, the characteristics of the goods (hazardous materials, perishable goods, origin, etc.), thereby ensuring that the right agency is available at the right time, in the right place, for the right shipment. Agency and port audit capabilities can be improved through more reliable and expeditious shipping information. Real-time, automated and accurate financial data, import statistics, resources and assets for each private and public stakeholder can be tracked. Annual and interim status and inspection reports can be automatically updated and completed. The GAO (U.S. General Accounting Office) recommendation for all PGAs and stakeholders can be automatically implemented. Real-time border awareness can be achieved through: real-time import and export information via UPC, product category, industry, manufacturer, geography; real-time US settlement of payment updates, US Customs information from Congressional Budget Office and Treasury Department; viewing of Full history, shipping, etc.; and, improved quality of service - automatic tariffs, updates of regulations, statistical information - can be shared by private and public stakeholders.

In addition to the above-mentioned advantages, the following cost savings can be achieved: good or near-good data accuracy and substantially reduced data entry redundancy, paperless handling of all goods marked conformant; Customs agency required; Substantially improved number of processing cycles through automatic cargo identification and tariff application; Reduced number of visits to production inspection teams for all manufacturers compliant with the marking system; Automatic identification of fraudulent/counterfeit shipments, for all markings Improved IPR (Intellectual Property Rights) detention of goods; reduced tariff errors ensuring correct tariffs are charged; reduced duty/customs and trade disputes; improved resource optimization of customs information; automated shipping shared with importers/exporters Confirmation/Status Information - enables freight forwarder industry cost savings; PGA's enhanced real-time collaboration for investigation and prosecution of all tracked and targeted assets; substantially improved use of non-intrusive The number of compulsory inspections of goods carried out by sex inspection technology.

Customs can also achieve increased revenue by using such a system in the following ways: Auto-trade consistent with all current trade agreements and revenue collection for all marked goods; less border penetration and smuggling; improved duty collection; Improves existing service quality for higher and/or new service fees; increases seizure of criminal assets, theft and counterfeit goods; enables next generation services such as payment information that can be sold to private companies and other government agencies real-time trade and settlement.

3.5 Project plan

The next section describes the project proposal

When creating a project, the following scenario occurs. The item is manufactured and then associated with a specific item ID. As the item moves from manufacturing, it enters the tracking system at the first reader. The steps are: (1) create a configuration specifying "new item" and all desired item attributes; and (2) create a batch ID binding reader and configuration. The system of the present invention sees a stream of configuration messages that are processed to create system data about the new item.

When the item is delivered to a warehouse, the following scenarios can occur. Prior to delivery, the warehouse worker instructs the inventive system with the planned operation of the item. If the reader is in a fixed location and is very specific about the intended location - eg a reader on the door of a small storage room or on a conveyor belt going into a storage room - all this information may not appear. This step is: (1) Establish configuration pointing out "configuration-location change" and location. (2) Create a batch ID combination reader and configuration. The system of the present invention sees a series of configuration messages showing position changes.

The following scenarios can occur when shipping an item. Typically, the regional ERP or logistics system has an entry that specifies a specific list of item categories and quantities that should be shipped to a specific customer at a given destination. The client may be for himself. The system of the present invention can provide the following identification and validation capabilities: (1) Identify the specific item to be shipped. (2) Confirm that all item types and specified quantities are actually related to the shipment. For example, confirm shipment and packing process against internal ERP system. (3) Identify all shipments intended to depart on a specific carrier, for example, the shipment will be loaded onto a specific truck. (4) Confirm that all items are actually loaded onto the correct shipping carrier.

During delivery, the system of the present invention reports the projected or actual location of the transport vehicle. In more complex scenarios, goods can be resold and redirected during shipment. The inventive system verifies that the correct items are unloaded at each destination. The system of the present invention optionally allows RFID in transit sensing at destinations to prove delivery and trigger manifests. The inventive system can optionally capture transit time and update internal transit time estimates for dynamic shipments.

Using these basic types, the following steps can be performed from storage to shipping. The regional ERP system reports a planned shipment to a regional ITS. Storeroom personnel use a system application to: select a shipment ID from a list; select the type of configuration for the shipment; identify area reader IDs; and create unique lot IDs. The person uses established procedures to remove items from the storage room and pass them through the reader. The reader sends a series of configuration messages to the inventive system in the following format:

Timestamp Batch-ID Item-ID.

The person indicates on the system app that the batch is complete. The system application of the present invention can immediately point out any discrepancies, such as missing or redundant items. These discrepancies can be locally repaired using an inversion configuration.

Using these basic types, the following steps can be performed from shipment to transport. The shipper uses the system of the present invention to confirm that a specific shipment (known to the system) will be loaded on a specific carrier (eg, a truck). This operation combines a specific reader (located in the loading area of the truck) with a carrier, and indirectly with a package shipment. The result is a batch-ID. The reader sends a series of configuration messages to the inventive system in the following format:

Timestamp Batch-ID Item-ID.

The person indicates on the system app that the batch is complete. The system application of the present invention can immediately point out any discrepancies, such as missing or redundant items. The inventive system knows all sets of shipments that should be loaded onto this truck. These discrepancies can be locally repaired using an inversion configuration. Any inquiry to the system regarding any particular item shows that the item is located on this truck and is part of a specified load ID known to the regional ERP system. Therefore, if an item falls off a truck, all messages from the system as well as the regional ERP system can be found.

Using these basic types, the following steps can be performed from shipping to receiving. The truck drives into the loading area at one of the shipping points. The system of the present invention combines the shipping destination address for any known shipment with a known system location. The receiving person stops the inventive system application and the vendor notifies the person of the shipment set scheduled to ship. The shipper enters the ID of the truck and is given a list of relevant shipments. If the tractor truck's lead head is changed en route, the driver may carry a shipping designation or even a badge to unambiguously identify the shipment. In the end this person uses the same shipping data object that was used by the original shipping person. Multiple sources can load goods onto the same truck.

The system application of the present invention knows exactly which item should be offloaded from the truck, even if multiple shipments are involved. The configuration category is designated as "unload at predetermined location". The result is a batch ID. The reader sends a series of configuration messages to the inventive system in the following format:

Timestamp Batch-ID Item-ID

The person indicates on the system app that the batch is complete. The system of the present invention can discern in real time whether redundant material has been offloaded or if a portion of the shipment remains on the truck.

Finally, the inventive system knows that the shipment was shipped and can trigger a manifest message.

Reliability issues

All messages are sent, but they may appear in any order and some may be played back. The system of the present invention accommodates failure of multiple computers in the system of the present invention and possible playback of cumulative messages. For example, each computer in a chain can accumulate a set of messages and log them to disk. When an upstream system fails and is restarted, it may require playback of previous messages or messages that appear to be partially stored but not transmitted.

The system of the present invention is free from arbitrary playback of events. For example, the system of the present invention may encounter the following situations:

Timestamp-1 Item X is read and reported as part of batch B1.

Timestamp-2 Item X is read and reported as part of batch B1.

This sequence is a simple repetition and would normally be filtered out at the lowest level, but may be sent to the system of the present invention.

Second, an operator may find that moving item X was an error, and enter an undo:

Timemark - 3 Undo Item X

Some parts of the inventive system may then malfunction, producing the following replays:

Timestamp-2 Item X is read and reported as part of batch B1.

If the undo was not replayed, perhaps due to some aspect of how the system failed, the inventive system would see:

Timestamp-1 Item X is read and reported as part of batch B1.

Timestamp-3 Withdrawal of Item X (Batch B1)

Timestamp-2 Item X is read and reported as part of batch B1.

However, the correct interpretation is that there is no movement of item X. To get this interpretation, the undo is made sticky—eg, undo is accumulated and effectively replayed after every no-playback event belonging to a given batch.

Equipped with an accurate decentralized clock (+/- within a few milliseconds), the inventive system records the time stamp of each configuration as well as each item - including revocations. The system of the present invention ignores configuration messages later than the most recently received message, yielding correct results in the previously described sequence. However, this method does not always produce correct results.

For example, suppose the event and corresponding time stamps are as follows:

Item X is moved:

Time stamp -1 Item X is read and reported as part of batch B1.

Item X is moved again:

Timestamp-2 Item X is read and reported as part of batch B2.

The operator believes that the movement of item X2 is wrong:

Timestamp-3 Withdraw item X (batch B2)

System failure or other events of the present invention cause disturbances, so the system of the present invention sees:

Timestamp-2 Item X is read and reported as part of batch B2.

Timestamp-3 Withdraw item X (batch B2)

Time stamp -1 Item X is read and reported as part of batch B1.

The simple algorithm of ignoring all messages except those newer than the most recently received message for this item means that the inventive system will ignore the batch B1 message and the batch B2 message will be (correctly) neglect. However, the system of the present invention would consider item X to be in a state prior to B1, which is incorrect. A more efficient algorithm during system recovery is to sort all available messages from the recovery time window according to their time stamps and then process all messages sequentially.

3.6 Information Retrieval Scheme

The system of the present invention can be implemented to provide a human level interrogation interface, or can be accomplished by a combined system, or both.

Regardless of where it is implemented, examples of queries and certain functions related to the query interface will be described below.

The most basic query is: Where is a particular item? Example: Where is this bottle of medicine? This query is low cost and easy to implement using conventional query construction techniques. This technique can also provide a query build mechanism that allows interactions to select qualifiers like item time, maker, etc. to separate an individual item. That is, the user may not know the actual item ID, but may have to query the system of the present invention to identify a drug manufactured at a certain time and shipped to a certain pharmacy, etc.

Another query is: where is an item of a particular kind located? For example: Where are all the D-cell batteries in the world? There may be many items about D-cell batteries - types (eUPCs), multiple manufacturers, multiple chemistries, packaging, etc. A reasonable interface allows the creation of a query involving multiple categories.

Other queries are: Where are items within a particular geographic space? Example: Where are all the size D batteries within 100 miles of Seattle? Or: Where are the items within a given shipment? Example: Where are all the size D batteries within four hours of Seattle? These inquiries can be supported by first building a table of expected shipment delays from various geographic locations to Seattle. With this complex geography defined, the system of the present invention can find items within the geographic form.

The inventive system may also support queries such as: Where are all the items with a particular attribute? Example: Where are all the vials older than two years (current date - date of manufacture)? Where are all the radial tires manufactured by Firestone between January 1, 2000 and January 1, 2001? What is the average storeroom wait time for this item - type? How long can a size D battery be kept in storage before being sent to a retail location? How long will a size D battery last on the retail shelf?

The system of the present invention can be implemented to provide various statistical options, such as providing average calculation, standard deviation, sales volume, minimum and maximum values. Thus, the system of the present invention can support queries such as: What is the average shipping time from location X to location Y? Example: How long does it take to ship an Acme-made product from Chicago to Seattle?

Implementation Strategies for Advanced Queries

An overall system consists of a combination of ITS implementations that are linked to each other plus additional applications, including a geospatial application that can be gleaned by simply scanning passive markers. data to dynamically predict the location of items and answer complex queries. These inquiries may require more expensive location tracking technology per project.

Examples of advanced inquiries include: Where are the Duracell batteries that can be shipped to Seattle within four hours using general shipping? All roads through Colorado are closed, which shipments may be affected? Where is the expected current location of all ground beef shipments?

Inquiries related to shipment delays

The inventive system knows when a shipment is loaded onto a truck, the destination of the shipment, and when it is unloaded from the shipment when it reaches the destination. The system of the present invention can therefore record and log all pairs of start and end locations that occur in the system. The accumulation of this data allows the system of the present invention to calculate shipment time statistics such as averages, patterns, standard deviations, maximums, minimums, and the like. Thus, time-based inquiries are possible, such as: Where are the Duracell batteries that can be shipped to Seattle in four hours using common shipments?

There are several possible ways to respond to shipment delay inquiries. For example, in the first method the steps are as follows: (1) Identify all item-types corresponding to Duracell batteries. (2) Identify a location with Duracell battery inventory within the largest geographic range (eg, Canada and the United States) of all storage Duracell battery locations based on item-type. (3) Identify all destinations within the Seattle statistical area that have received Duracell batteries in the past. This is a purely geographic search based on Seattle, battery item type, and cumulative history. (4) Based on the list of destinations from step 3, find the average shipment time of all incoming to this destination. (5) Find the intersection of the starting position of step 4 and the available storage position of step 2. (6) Organize the start position/target position/average delay records in step 5 on the basis of delay. Choose those locations where the average latency meets the criteria of four hours or less. (7) Step 6 gives the answer to the question; the position of the result can be displayed on the current map. (8) Other information, such as shipping costs can be optimally selected, so for example, the system of the present invention answers the possible source of the smallest shipping costs.

This method only considers start locations that have been used in the past for shipments to Seattle. The search can be expanded to examine joint historical shipment sections where the total expected delay is within some tolerable level and the aggregate consolidation of the section does not exceed a specified target.

The above method can also be easily adjusted to find the cheapest source of batteries for Seattle regardless of shipment time.

The first method identifies the shipment delay and looks for a possible source of the shipment based on the battery's historical shipments. The second method uses commercially available routing design software and services. These established solutions estimate an optimal route and driving time (or other transportation) between any two locations within the United States or other countries. Using these techniques as a basis, the following steps can be used to answer the query: (1) Identify all item-types that correspond to Duracell batteries. (2) Identify a location with Duracell battery inventory within the largest geographic range (eg, Canada and the United States) of all storage Duracell battery locations based on item-type. (3) Using routing design software, create a driving schedule from each location with battery inventory to Seattle. (4) Collate the table and identify those inventory locations that are within four hours of driving time from Seattle.

The second method identifies possible but less commonly used shipping routes. For example, due to taxes and other factors, Duracell may never ship from Canada to the United States. The above method may show that the fastest source from Seattle is Vancouver. Whether to use this source is a commercial decision.

Shipping Obstacle Inquiry

The inventive system knows the source and destination of all current shipments. The inventive system also knows the start time of each shipment and the average transit time for each pair of start and end locations. So it can answer queries like: All roads through Colorado are closed. Which shipments may be affected?

There are several possible ways to answer shipment barrier queries. For example, in the first method shown in FIG. 21 , the steps may be as follows: (1) Identify the geographical area where the route is destroyed (travel disruption), such as Colorado. (2) Identify all current shipments as well as those planned for a favorable period. (3) Perform the following steps for each shipment: (a) Form a bounding box 2120 for the start location 2130 and end location 2140. (b) Decide whether the bounding boxes intersect or overlap. (c) are considered potentially damaging if they cross in any way. Even without intersections or dependencies, such as on highways, mountains, waterways, etc., there may still be damage, as will be described later. See below.

This method provides a basic and general indication of potential damage. A more definite indication can be made by looking at the straight path 730 from the start position to the end position. If the route damage intersects this, there is a stronger indication of potential damage.

In a second and more specific approach, the idea of having a transport path is illustrated using FIG. 22 .

In the second method, steps 1 through 5 in the first method are used to indicate whether a route break 810 is likely to affect a particular shipment. Details of the planned transport route are checked, for example by taking waypoints 2220 into account, if the bounding box intersects the route for damage. If the planned path intersects the route at right angles to damage, there is substantial potential for damage. This figure illustrates that when a route violation blocks a straight path, it does not actually block the planned route 810 .

Using FIG. 23 to illustrate that in the third method, a more detailed path can be provided. These routes may be provided by local direct access to each route, by street names or by using route planning software. This detailed information allows for more precise detection of damage to established roads affecting carrier transportation. The steps are: (1) Determine 2310 the route damage located on the blocked highway or road section. (2) Find all transport routes 2320 for all shipments within the time window. (3) Pairing the destroyed road portion of the route with the planned route. Where appropriate, the indicated path will be destroyed.

Real-time location indication and inquiry

A real-time location system (RTLS) provides continuous price tracking. This tracking is usually done with a possibly expensive transponder. The system of the present invention can capture items carrying inexpensive passive RFID tags and provide an RTLS approximate capability.

Therefore, there are two basic ways of answering location queries. In a first method, the transportation system (eg, truck, boat, plane, etc.) has a RTLS. The real-time location of all transport systems is monitored, and the system of the present invention associates a specific item with that transport and therefore with that location. In the second approach, the information gathered by reading passive tags from a fixed location along with information about scheduled shipments is used to roughly estimate the item's current location. This method is cheaper and offers many benefits of transporting RTLS without requiring any RTLS infrastructure. It can also work with third-party carriers.

The formal shipment process combines a shipment with a transport mode if there is RTLS capability on the transport. If the shipment itself is a tagged object, such as a truck with an RTLS type tag, the inventive system knows the exact location of the shipment at the time of the most recent RTLS update.

An example of a location query is to display the estimated current location of all ground beef shipments. The RTLS method is according to the following steps: (1) Query the item-type of the desired ground beef shipment. (2) Find all current shipments of this item-type. (3) Identify the carrier used for each shipment. (4) Find out where the shipping tag object is by finding the most recent RTLS update for that tag. (5) Display the current geographic location in terms of, for example, latitude and longitude.

Although without RTLS capability, the system of the present invention knows when the shipment is loaded onto a truck, the destination of the shipment, and when the shipment has been unloaded at that destination. Therefore, the system of the present invention can record and log the information about each pair of start position and end position displayed in the system of the present invention. The system of the present invention can then calculate a median, or average, shipment time. This information allows the system of the present invention to estimate the current location of a shipment, optionally with a confidence range.

This method responds to the query example (displays the estimated current location of all ground beef shipments) using the following steps: (1) Query for the item-type of the desired ground beef shipment. (2) Find the average shipment time of these shipments based on past history. (3) Find out all about the current shipment of this item-type. (4) The start time, current time, and average shipping time are recorded for each shipping comparison. This quantity estimates the percentage of completion of the trip.

This current location can be estimated and displayed in several different ways.

In this straight line method, the approximate estimation of the entire transport stroke using the straight line path from the start position to the end position will be described using FIG. 24 . By calculating the estimated proportion of completion of the trip 2410 and assuming a straight line path, the location of the shipment can be estimated 2420. This method does not correspond to real world roads and highways, but it gives an acceptable rough estimate of the location of the cargo relative to the destination.

In another method, shown in Figure 25, a detailed routing for each shipment is established, as previously described. This method can provide, for example, a detailed sequence of route portions 2510-2518, which can be highlighted on a map. Route planning software estimates the elapsed time to a specific point on any route. For example in Figure 25, the estimated drive time to each exchange point is estimated and illustrated. Based on knowledge of the actual start time, the system of the present invention can estimate the current location of a delivery vehicle at the level of a specific location on a specific road. This method is particularly useful for determining the effects of a known transportation obstacle, such as a closed bridge.

4. Data transfer between item tracking system and tag reader

The following sections will describe the implementation of the system of the present invention, which interposes hardware and software between the tag reader and the ITS. Optionally, intervening hardware and software functions can also be integrated into the ITS, for example as part of the OIC 104 in FIG. 1 .

4.1 Event Router

One implementation of the inventive system uses one or more event routers to forward information between the ITS and the indicia reader. Events are messages that pass from one software entity to another. Events can be used to notify an event receiver that something happened, or to send a query to the receiver. An event router can be used to distribute events among several entities. Examples of event routers that may be used include the topic-based KnowNow ^(R) Event Router, available from KnowNow, Inc., Mountain View, CA; or the content-based Elvin message service, available from Distributed Systems Technology, Queens Island, Australia Center obtained. The topic-based and content-based event routers can also be combined.

For purposes of illustration, the system of the present invention will be described in terms of its use in a particular inventory management scheme.

Figure 36 depicts a retail location with respect to an item tracking system (ITS) used as part of an inventory management system. The retail location is a store. The store has an inventory containing marked items. A monitoring system 3610 detects when tagged items are brought into or out of the store.

The detection system 3610 includes a plurality of indicia readers placed at one or more locations in the store. The monitoring system 3610 also includes memory that stores the current status of each item in the inventory. The status indicates whether the item exists at a particular location or has been moved from that location. The monitoring system 3610 also includes computer logic that determines when the status of the item changes, such as when the item is added to or removed from the particular location.

This logic can be further adjusted to send an update whenever it detects a change in the status of an item. The inventory update may take the form of an event. The event contains the item's ePC, the tag reader's ePC, and a time stamp. The event may also contain an in/out parameter, which indicates whether the change was the addition or removal of an item.

In one implementation, the monitoring system 3610 includes one or more smart shelves. A smart shelf is a shelf that reports when physical items are added to or removed from the shelf. A smart shelf consists of several tag readers placed at one or more positions on the shelf. A smart shelf also contains computer logic to determine whether the item is added or removed from inventory.

An ITS 3620 maintains tracking information for including items belonging to stored inventory items. Whenever an item enters or leaves the store, the ITS receives an event from the monitoring system 3610 and updates its data store to reflect the event.

An inventory planning tool 3640 - a computer program solution - typically operates on a regular schedule to perform inventory management functions. In stores associated with the store, the inventory planning tool 3640 retrieves inventory data from the ITS 3620 and decides whether to replenish the store inventory. The inventory planning tool 3640 can receive alerts from an early alert agent (EWA) 3630, which can cause the inventory planning tool to perform at least some inventory management functions related to the store outside of its normal regular schedule. In particular, the EWA 3630 can send an alert to the inventory planning tool 3640 so that it can decide whether to replenish the inventory needed by the store. The EWA receives an event from the monitoring system 3610 whenever the item enters or leaves the store, even randomly when it moves from one part of the store to another. Using the information received in these events, the EWA decides when to send alerts to the inventory planning tool 3640 .

Early Warning Agent

The EWA 3630 contains logic for deciding when to send an alert. Determining whether to send an alert involves applying one or more rules to information received in an inventory update. A rule specifies a specific condition and a specific action to be performed when the condition is met. For example a plan may specify that an alert should be sent whenever the inventory level falls below a certain value.

The EWA 3630 can apply a predetermined set of rules, or alternatively can include artificial intelligence logic so that it can change its behavior in response to current or historical inventory samples. The artificial intelligence logic enables the EWA to estimate potential inventory level changes in the near future to enable early identification of potentially dangerous situations to allow corrective action. For example, initially the rule could specify that the alert be triggered quickly when the inventory drops below 10. However, if the EWA 3630 detects that it sends alerts much more frequently in summer than in other seasons, the EWA 3630 can accommodate the seasonal change by increasing the threshold from 10 to 20 in summer, so the inventory planning tool 3640 will receive alerts earlier Notice of impending stock shortage.

The EWA 3630 can capture and analyze current and historical inventory data to detect trends such as discrepancies between planned replenishment and actual replenishment, and create a predictive model of future inventory needs. These trends and forecasts can be determined using linear regression, classification, and dendrograms, or other predictive algorithms.

In one embodiment, the EWA 3630 is estimated for each planned replenishment or depletion operation that may affect inventory (e.g., assuming historical execution data, it estimates a planned truck load of 12 oz bottles originating from Bob, which would arrive at Arriving anytime between four hours before and six hours after the planned delivery time in quantities between 95% and 100% of the requested quantity) potential variation. The EWA 3630 compares past committed and actual shipping times for several inventories to generate operational forecasts of planned but not yet completed actual delivery dates and future replenishment quantities. The EWA3630 combines estimates of potential changes for several independent operations, making it one estimate of potential changes for overall inventory. These algorithms may be implemented using the determination of tree-like images such as taxonomic or regional dendrograms.

In other implementations, the EWA 3630 builds the predictive model based on aggregated data representing cumulative levels of replenishment and depletion without regard to individual operations. These algorithms can be implemented using possible inference modes such as conditional Gaussian approximation.

Further details on the algorithm used by the EWA 3630 can be found in the publicly owned, pending U.S. Patent Application for an Inventory Early Warning Agent Procedure, U.S. Provisional Application Serial No. 60/384,638, filed May 31, 2002 filed, the contents of which are incorporated herein by reference.

Inventory Planning Tool

The inventory planning tool 3640 can be any application that plans inventory replenishment. One such inventory planning tool 3640 is the Advanced Planning Tool and Optimization Tool (APO) available from SAP AG.

The inventory planning tool 3640 contains logic for developing an inventory plan. The logic includes logic for receiving an alert from the EWA 3630 and determining whether replenishment is required in response to the alert.

In one embodiment, the inventory planning tool 3640 creates a replenishment plan for a full inventory. An EWA 3630 monitors a portion of the inventory. Multiple EWA 3630s can be combined to cover the entire inventory. An alert about a portion of inventory triggers the inventory planning tool 3640 to determine whether planned replenishment for the entire inventory needs to be re-planned.

The determination may include retrieving inventory data from the ITS 3620 and determining or forecasting demand based on the retrieved inventory data. For example, a high demand trend for product X may cause the inventory planning tool to prepare not only more product X but also more product Y for which product X is known to be the leading indicator.

As shown in FIG. 37, an event routing intermediary software such as an event router (ER) 3710 can be used to distribute events among different entities, for example, between the monitoring system 3610, the ITS 3620, the EWA 3630, and the inventory planning tool 3640 distribute events. Examples of suitable event routers include the topic-based KnowNow ^(R) Event Router, available from KnowNow, Inc., Mountain View, CA; or the content-based Elvin Message Service, available from Distributed, Queens Island, Australia. Acquired from Systems Technology Center. The topic-based and content-based event routers can also be combined.

Content-Based Event Routing

In one embodiment, each message is routed from publisher to user based on the content of each message. The content of each message can be divided into multiple content fields. For example, the message 01.0037F2.001508.000319F827 related to an item with the ePC can be divided into the following content areas:

(1) Title: 01

(2) Manufacturer: 0037F2

(3) Product category: 001508

(4) Serial number: 000319F827

(5) Message type: see@(seen@), request, response-see@message is a message reporting that the item has been detected at a specific location. "Request" messages are used to send a request to a user and "Response" messages are used to issue the response information. Other message types may also be defined.

The user may specify message filters based on values in the content field. (Example: Maker=0037F2 and Message Type=See@)

Topic-based event routing

In an alternative implementation, events may be sorted by title. A software entity may only be interested in events about certain topics. The software entity may only subscribe to some specific topics and it will only receive events on those and not others.

Fig. 38 illustrates a header structure based on an ePC structure. A separate header can be established for each data field of the ePC, namely manufacturer, product type and serial number. For example, for a project with the ePC01.0037F2.001508.000319F827, the following headers could be created:

(1) \centauri\0037F2\001508\000319F827\see@ - This heading covers "see@" events related to this item.

(2)\centauri\0037F2\001508\000319F827\* - This heading contains events reported to Heading 1 as well as other kinds of events related to this item, such as "request" and "response" events.

(3) \centauri\0037F2\001508\* - This heading contains events reported to Heading 2 as well as events related to other items in the same product category 001508.

(4)\centauri\0037F2\* - This heading contains all incidents reported to Title 3, and also includes incidents related to other items of the same manufacturer as 0037F2.

Split headers can also be created for reader-related events. For example, for a reader with the ePC01.0B39C2.000815.004711F827, the following headers can be created.

(1) centauri\0B39C2000815004711F827\ePC Saw - This heading covers events related to a specific reader that has detected a specific ePC.

(2) centauri\0B39C2000815004711F827\* - This event covers events related to a specific reader that has detected any ePC.

A title-based event router has a set of titles and each title has an address, such as a URL. An event can be published to a title by sending the event to the title's address. A publishing entity such as a monitoring system 3610 (FIG. 37) may consult an Extended Object Naming Service (EONS) 3720 in order to determine the URL of the appropriate title to publish a message. An EONS 3720 maintains a correspondence between Item ePCs (or a Reader ePCs) and one or more ERs with their corresponding titles. An EONS takes an item's (or reader's) ePC as input and answers URL(s) for one or more identifying titles. The EONS 3720 can be implemented by extending a conventional ONS, exemplified by the ONS developed by Oat Systems and the MIT Auto-ID Center, described in the Object Naming Service Technical Handbook (developed by MIT Auto-ID). -ID Central Issue) is described in more detail. Traditional object naming systems are similar to and based on the well-known Internet Domain Name System (DNS).

Published protocol flows

As shown in Figure 39, in operation the monitoring system 3610 identifies an item being added to or removed from the inventory. The monitoring system generates an event including a tag identifier, a reader identifier and a time stamp. The tag identifier identifies the item that has changed. The reader identifier identifies the reader that detected the change. Instead, the time stamp identifies when the change was detected.

The monitoring system 3610 then consults the EONS 3720 to determine where to send the event. The monitoring system 3610 provides the EONS the item's ePC and the reader's ePC and retrieves URLs from EONS for the item title and reader title. The monitoring system 3610 then sends the event to the two titles.

ER(S) on Title Items and Reader Items schedules items to one or more users. For example, the ITS may be the user of the item title and the EWA may be the user of the reader title. The EWA receives events from the ER and decides whether to send an alert to the inventory planning tool.

If an alert is sent, the inventory planning tool is triggered to re-plan replenishment of the inventory. To get current data on inventory, the inventory planning tool can send an event to the ER requesting inventory data. The ER then schedules the event to the ITS, which responds by sending the requested inventory data to the inventory planning tool.

Agreement flow about ordering

As shown in Figure 40, for each title a user wants to order, the user first queries EONS to determine the location of the ER for that particular title and then keeps track of events to be posted to the title.

When an event is received, the user can use the reader ID contained in the event to determine the location of the item. The location can be a physical location (eg, a specific latitude, longitude, and altitude) or a logical location (eg, in container XYZ or truck ABC). The user can also use the tag identifier to locate additional information about the item. For example, the tag identifier can be used to retrieve a PML (Product Markup Language) file for the item.

As shown in Figure 41, an EONS can maintain correspondence between multiple tagged items and multiple ERs. As mentioned above, the correspondence supports multiple keys, including an item key and a reader key. The EONS can serve multiple surveillance systems 3610 as well as other indicia reader applications. In one embodiment, the EONS is a decentralized subsystem comprising corresponding information, an interrogation server for responding to queries requesting the location of the information, and a name resolver capable of receiving an ePC and resolving the ePC into an ER location.

As shown in Figure 42, a specific ER can be distributed to multiple ITSs (like other users) and a specific ITS can subscribe to multiple ERs. A user can define the desired range for each ITS and set the dispersion plan accordingly.

4.2 Integration Engine

As shown in Figure 31, one embodiment of the inventive system may use an integration engine 3110 as an intermediary tool between the ITS and the indicia reader. The integration engine can be implemented interposing software and hardware between the indicia reader and the ITS. The integration engine 3110 may alternatively be integrated into the ITS, such as part of the QIC 104 in FIG. 1 .

The integration engine 3110 can communicate with the indicia reader 102 as it does with other types of smart items. In this specification, a "smart item" is an item or machine that can store and communicate data about itself with external systems. Any communication channel (eg radio frequency, infrared) can be used. The communication process may result in changes to data stored in the smart item. More sophisticated Smart Items also have processing capabilities that allow them to interact directly with other Smart Items and, for example, coordinate a common action. Smart items can store and associate different kinds of data including a unique item identifier (UID) and other item characteristics about the item. Some smart items have sensors that store environmental data such as temperature, humidity, acceleration or location. The communication data can be real-time data or historical data, or both.

Examples of smart items include tagged items, RFID interrogators, actuator devices, spotted goods, and embedded web applications. An interrogator is an indicia reader and writer. An actuator device is a machine that moves or controls something (eg, a conveyor belt, a vending machine). A perceived cargo is a cargo for which information about its environment can be detected (eg, cargo equipped with position or temperature sensors).

Support for a particular sensor or actuator device is implemented by using a hardware interface such as the exemplary software shown in FIG. 34 . The integration engine 3110 collects data from different kinds of smart items 3120 and provides the collected data to high-level applications 3130 including the ITS 103. The integration engine 3110 can also write data to the smart item 3120 .

integration engine

The integration engine 3110 reads and writes data from smart items 3120 , processes the data in real-time and provides the processed data to high-level applications 3130 . Doing this in real time means processing the data as it is received and providing the data as it is processed. The integration engine 3110 can also receive data from high-level applications 3130 and write data to smart items 3120 .

Processing the data may include data filtering. For example, one application may only be interested in receiving UIDs and location data, while other applications may only be interested in collecting data from a certain smart item. A separate filter can be provided for each application requesting data.

Processing this data may also include data aggregation. Data aggregation involves combining data together to produce higher order data. For example, combining the UID of an item located in the truck with the temperature read from the truck to produce a temperature reading for the item. Aggregating data can make that data more meaningful than processing it individually. Aggregation may also include accumulating real-time data into a batch and sending the batch of data at predetermined times rather than real-time. The data can be time stamped with the date and time of collection.

The integration engine 3110 is tuned to interface with different kinds of hardware interfaces that provide basic read and write functions. The integration engine 3110 translates between a hardware-specific data format and a generic format, or in some cases between a hardware-specific data format and an application-specific format. In this case, the integration engine 3110 hides hardware details from the application 3130.

Figure 32 illustrates how multiple integration engines 3110 can be used to manage large numbers of smart items. Each integration engine 3110 can be designated to transfer data between specific locations (eg, factories, loading bays, stores) where smart items are found. The application 3130 may subscribe to one or more integration engines 3110 . Each integration engine 3110 may be implemented as a set of multiple integration engines 3110 . The output of an integration engine 3110 can be input into a high-level integration engine 3110 .

FIG. 33 illustrates an exemplary implementation of an integration engine 3110. The integration engine 3110 manages all data and objects involved in interacting with smart items and controls the overall process. The integration engine 3110 includes a control manager 3310 , an interrogator agent 3320 , a processing agent 3330 and a communication agent 3340 . The component can be implemented using conventional programming techniques, including component-based technologies such as Java, C# or C++ objects.

The control manager 3310 provides the programming interface between the integration engine 3110 and applications 3130 . The programming interface implements a generic (non-implementation specific) communication interface to where multiple adapters can be plugged. The adapter switches between a specific communication interface (such as RPC, COM, COKBA, IMS, HTTP) and a general communication interface.

The control manager 3310 receives and interprets the rules from the application 3130, receives and interprets client commands, and instantiates the appropriate query agents, process agents, and communication agents to enforce the rules. The rules may define or constrain various aspects of the behavior of Interrogator Agents, Processing Agents, and Communication Agents. For example, the rules may define what data is provided to an application (e.g., only UID or location data), what data is written to the hardware (e.g., if the truck's temperature drops below a predetermined threshold, write a air-conditioning command) or when this data is provided (e.g. daily). Rules may also define how to combine the collected data to generate higher order data (eg combine the UID of an item located in the truck with the temperature of the truck to determine if the item is overheating). The control manager 3310 interprets and applies the rules as data is received.

In one embodiment, the control manager 3310 is housed in or is somehow associated with a rules store for storing rules received from the application, the control manager is also housed in a rules trigger or in the form of combined with it in some way to enforce the storage rules. Rules received from the application can be represented in UML (Unified Modeling Language) schemas, EJB (Enterprise JavaBeans) fruits or XML (Extensible Markup Language) files. If necessary, the control manager 3310 converts the rules to an internal format used by the rules engine.

An interrogator agent 3320 is responsible for overall control of a single hardware device interface such as an RFID control interface. An interrogator agent 3320 combines a hardware interface, the control manager 3310 and a processing agent 3330. The interrogator agent 3320 receives data from the hardware interface. The interrogator agent 3320 can be adjusted according to the requirements of the hardware interface. For example some hardware interfaces require asynchronous polling, whereas other interfaces generate events or interrupts. The Interrogator Agent 3320 typically does not perform any processing on the collected data, instead it simply forwards the data to a Processing Agent 3330 for processing.

A processing agent 3330 is responsible for data filtering, aggregation and transfer operations. The processing agent 3330 interacts with the control manager 3310 and an interrogator agent 3320 .

To perform data filtering, the processing agent 3330 receives sensor data collected by one or more interrogator agents. The processor agent 3330 exercises the rule engine to determine whether any data satisfies the conditions specified by the rule. The data meeting this condition is forwarded to the communication agent program 3340.

To perform data aggregation, the processing agent 3330 stores the received data in a buffer until it has received all the data required by a particular rule.

The processing agent 3330 receives data in a hardware-specific format. The processing agent 3330 uses a correspondence table to convert between the hardware-specific format and the generic format that the integration engine 3110 outputs to the application 3130.

This data load can be shared among multiple processing agents. Certain processing agents 3330 can only process data containing a certain kind of information, such as purchase order numbers. In these cases, the interrogator agent 3320 decides that it has collected based on the type of hardware (e.g., a barcode scanner emitting barcode information) or metadata describing the data (e.g., with reference to the logical tag type definition illustrated in FIG. 34 ). data type. Certain processing agents 3330 may process complex data—data aggregated from the output of several processing agents 3330. The same processing agent or agent 3330 may serve applications requiring the same kind of data.

A communication agent 3340 is responsible for providing data to the application 3130 using either a push or pull model. An application may explicitly request to perform a read or write operation on the smart item 3120 (pull mode), or an application may request to be notified when the integration framework receives data from the smart item 3120 (push mode). model).

The communication agent 3340 receives processed data from one or more processing agents 3330 and provides that data to all subscribing applications 3130 . The communication broker 3340 maintains a list of ordering programs 3130 and their respective destination parameters. The communication agent 3340 may be a collection of communication agents 3340, each of which implements a specific communication interface or protocol (eg, RPC, COM, CRBA, JMS, or HTTP).

Instead of providing the processed data directly to the ordering application 3130, the communication broker 3340 uses an intermediary tool, such as an event router. The event router will pop up the list of currently subscribed applications. An event router is a server that routes messages (events) between software entities. The message can be used to notify the recipient of the message about the occurrence of certain events or to send a query to the recipient. Examples of suitable event routers include the KonwNow ^(R) Event Router, available from KnowNow, Inc., Mountain View, CA; or the Content-Based Elvin Message Service, available from Distributed Systems Technology Center, Queens Island, Australia.

In one embodiment, the communication agent 3340 provides the data in the form of a data object (or collection of objects) that has methods that can be used by external applications to retrieve the UID or additional item data. In another embodiment, the data format is XML. XML has the advantages of being flexible, extensible, self-describing and widely used for data exchange.

hardware interface

FIG. 34 is a block diagram of an exemplary hardware interface 3400. The hardware interface 3400 is software that enables high-level software to interact with basic hardware. A wide range of RFID technologies is currently available from a number of manufacturers. Depending on the application scenario, a specific type of tag (active/passive, read-only/rewritable, etc.) needs to be selected. It is beneficial to implement this hardware interface using an open standard, so that it can be used in conjunction with multiple RFID technologies available from multiple vendors. The hardware interface can receive queries to read data from the hardware interface or to write data to the hardware interface. Data originating from the hardware interface may alternatively be passed to an interrogator agent 3320 or a processing agent 3330.

The interface 3400 includes an abstraction layer - server 3410 - that hides the details of the interrogator 3420. The server 3410 communicates with the interrogator 3420 through a hardware attached interface. In operation, a particular server 3410 entity is responsible to only one interrogator 3420. However, several applications can simultaneously communicate with the same server 3410 entity.

A server 3410 supports at least two different types of read queries. A delimited read requests reply messages only on tags that are currently being read. A persistent read request reply message on all tags that have been read and buffered after previous read requests have been made.

A server 3410 can receive data to be written. The data to be written can be data stored on a tag or control data controlling the behavior of the hardware. For example, an intelligent conveyor belt may receive control data to switch between left and right conveyor belts; an intelligent vending machine may receive control data to adjust the price of an item or the temperature of the machine.

Additionally, a server 3410 makes available the following functions:

initialization

This function initializes the interface 3400 for use. Initialize all hardware, including necessary communication ports, software objects and processes. This is a general initialization function. Specific hardware details can be set in specific hardware configuration files.

termination

This function terminates the use of the interface 3400 . This is the reverse function of initialization. All hardware is released, communication ports are closed and all associated software objects and processes are terminated (unless they are used by other processes). This is a generic termination function. Specific hardware details can be set in specific hardware configuration files.

detection mark

This function detects whether and how many tags are currently readable.

Define logical tag types

This function defines logical tag types with respect to a specific tag. This logical tag type describes the composition of the data on the tag. The exemplary electronic token 3500 shown in Figure 35 illustrates this. As shown, the user data on the tag physically consists of n 32-bit data blocks. Logically, however, it has three named data fields: an article number ("ARTNR") 3510, a description of the article ("ARTDESC") 3520, and its price ("PRICE") 3530. As shown, the length and start address of this field are not necessarily the same as the block length and start address.

The logical tag type defines the name, starting address and length of each data field, its data type (in order to easily map the field to application data) and a description about each field. The logical tag type also defines where to store a tag identifier. This logical tag type definition can be extended to include other information.

Get logical tag type description and field name

This function gets information about a logical tag type. Normally this function would be used to get the field name as well as the field length and data type.

start/end continuous reading

This function starts or ends the continuous read mode of operation.

Read fields from multiple tags

When executed, the function reads data from a specific field of all tags that can read that data. A parameter indicating whether a delimited read mode or a continuous read mode is required. For continuous mode, the server buffers all read tag information. In continuous mode, each call to the read function clears this buffer. However, a call in split mode does not clear the buffer.

read field from a specific tag

This function is similar to the previous function. The difference is that only fields from a single tag with a specific tag ID are read. It may be necessary to read multiple tags to identify the tag with that particular tag ID.

write field to multiple tags

When executed, this function writes the same data to specific fields of all tags that can be written. This field has a name and depends on the tag type that defines it. The same data is written to all tags. You can use this function for mass writing of marks, for example at the end of a production line.

write field to specific tag

This function writes data to a specific field of a specific tag in the field of tag reader-writer operation. This field has a name and depends on the current token type. The tag being written is specified by its UID. Data is only written to specific fields. Any data in tagged fields not specified in this operation is unchanged.

Data fields can also be locked using either of the two write functions, as long as the hardware supports this function. A field can be written and locked at the same time, or a field that has been written before can just be locked without rewriting its data.

specific hardware calls

Some hardware may provide some functionality beyond the scope of this interface. This function provides a mechanism to call directly from the application through specific hardware for the client to use the function.

wrong operation

When a communication error occurs, the hardware device 3420 or the server 3410 first tries to resolve the error caused by itself, for example, by retrying an operation several times. When a low-level error operation fails, the interface 3400 provides information about where the error occurred so the application can take appropriate action.

In addition to a generic error code that defines the type of error, a detailed description of the error is also provided. The interface 3400 recognizes at least the following types of error conditions:

(1) Interrogator not responding: Interrogator could not be initialized.

(2) Read error: n tags are detected, but only m is read correctly (m<n). No flag in this field is not an error condition.

(3) Write Error: The tag cannot be written, either because there is no tag in the radio field, or because there is some specific write problem, such as a locked field or a general failure.

(4) There is no hardware support. Features like data locking may not be supported by all hardware.

5. Compression, filtering and encryption of tracking information

The following sections describe an embodiment in which the tracking information is compressed, filtered or encrypted before it is communicated from one enterprise to another. The process of an implementation involving a producer and a consumer will be described. A producer or consumer may be a manufacturer, a distributor, or a retail establishment, or any other location or portion of a location that handles the tagged item.

As shown in FIG. 43 , a producer 4301 sends a shipment 4303 to a consumer 4302 . When the shipment 4303 is received by the customer 4302, the customer's indicia reader system 4306 reads the information from the container indicia 4307 and the item indicium 4308. In order to confirm the shipment 4303, the consumer 4302 needs shipment content information 4309 from the producer 4301. This shipment information 4309 may contain the UID of the container and the UIDs of all items in the container. Other information associated with each item, such as the item's color, can be combined with the item's UID or stored externally on the tag. Through a communication network 4310 such as the Internet, the consumer 4302 can receive shipment information 4309 from the producer 4301 and can also send status update information to the producer 4301. The regional ITS 4311 at the customer's location retrieves information from the indicia reading system 4306 and matches the indicia information with the shipment information 4309.

As shown in FIG. 45, a method 4500 for contact tracing information between a producer and a consumer may begin by a producer receiving a plurality of identification codes, each identification code uniquely identifying an item of interest (4510 ).

This identification code can be read from a tag attached to the item. To enable cross-enterprise object tracking, each tag carries a unique identifier for the item in question, for example divided into an 8-bit header (bits 0-7) 4510 and three data fields: ePC Manager (bits 8-35) 4620, object type (bits 36-59) 4630 and sequence number (bits 60-95) 4640. Each flaggable system organization has a unique code for the ePC manager field. Each product category in an organization has a unique code in the object category field. Each individual item of a product has a unique code in the serial number. UIDs other than ePC can also be used similarly.

The producer classifies the identification codes into one or more sets of identification codes (4520). Each set of IDs may correspond to a particular type of item (eg, all basketballs from a particular manufacturer).

For each set of identification codes, the producer identifies redundant portions of codes that are common to each set of codes (4530). For example as shown in Figure 47, ePCs for all basketballs from a particular manufacturer contain a redundant section 4701 - specifically, the ePCs share the same ePC manager and object class. This redundancy is inherent in the ePC's layered architecture.

The producer creates a file containing one or more sets of identifiers (4540). In this file however, the ePC can calculate most of the file size. For example, as shown in FIG. 47, a shipment document contains item-level information that includes ePCs for each shipment item. As the number of items increases, the ePC becomes a significant part of the file size.

In order to reduce the size of the file, the producer 4301 organizes the file so that for each set of identification codes, an instance of the coded redundant part is listed and each tag is juxtaposed with the omitted coded redundant part. In this approach, the hierarchical design of the ePCs can be exploited to compress the information associated with each ePC. For example, for all basketballs packaged and shipped to a location, not all ePCs for each basketball need be included in the shipping documents. Instead, as shown in FIG. 48 , the shipping document may only contain an entry for the ePC manager and object category in an ePC prefix 4802 .

A shielding technique similar to method 4500 can be applied to environments other than shipping. For example, masking can be applied in a production environment to reduce the size of production orders. When preparing a new production line for manufacturing items, a factory typically draws up a production order listing the ePCs for each item. This holds true even when the title, ePC manager, and ePC object type parts are the same. By applying method 4500 to production orders, this redundancy can be reduced and instead of listing all ePCs for each item, this redundancy can be omitted and only the serial number listed.

The size of the file (shipment, production or otherwise) can be further reduced by knowing when serial numbers are consecutive, it is not necessary to list the serial numbers of all production items. Instead, as described below, what needs to be listed is the serial number of the first created item ("EPC_BASE") and the total number of items produced (eg 1000). Additional information about each item, such as the item's color, can be listed separately for each item as described below.

<product_order_id=1234566><item_list_quantity=1000 EPC_prefix=01.000A89.00016F><EPC_base>00168123</EPC_base><item><color>red</color></ item><item><color>red</color></item><item><color>red</color></item></item_list>··

</Product_Order>

Along a supply chain, there will typically be items that are tagged as well as untagged. Also, only certain types of items such as pallets or packages will be tagged with RFID. In addition, each enterprise can mark the project. For example, a shipping company may mark its shipping packaging to automate its warehouse logistics process. Therefore, there may be RFID tags at the item, the package, the pallet, and the container levels, and these tags may come from different businesses. However, a simple reader/interrogator cannot distinguish between, for example, an item and the item container from that item. As a result all read UIDs must be reported to a central system and filtered. This process is inefficient and cumbersome for a system that must process millions of reports in a day.

For an enterprise's ePC manager, it is necessary to control the assignment of tasks and serial numbers of object types. The enterprise may also define its own profiles on entity objects that are attached to items manufactured by the enterprise. For example pallets and packages produced by a manufacturer may or may not have their own ePC markings. However, in the environment of a shipping company, there are containers for shipping physical items. By validating only the pallet or package rather than its entire environment, the transfer shipment process from one shipping area to another can be performed quickly. This method requires the carrier to tag the container with its own ePC. The reader can be tuned for a specific type of ePC pattern. For example the reader can be adjusted to register only containers starting with the character "1" in the object category part of the ePC. The actual XMK filter profile will look like:

<container_type>01.1234566.1XXXXX</container type>

In this example, the Xs are wildcards located in the strings forming the ePC; the reader will accept any data located in these positions. Setting up a reader in this way allows the reader to filter the ePCs it reads, and check only the container types indicated in this profile. Filtering thus reduces the amount of information sent from a reader to a monitoring application or process such as a shipment confirmation process.

FIG. 49 illustrates a method 4900 for filtering trace information. Filtering can occur by a reader or reader system at various stages in the delivery process (ie, through multiple consumers) as well as within a particular consumer. For example, as described above, filtering occurs at the tag reader layer. Alternatively or additionally, a consumer's ITS may also filter the data it receives from the indicia reader.

An identification code associated with a plurality of items is received, including individual items and containers of items (4910). Each identification code (eg, ePC) is a character string that uniquely identifies the combined item. The identification code can be retrieved from multiple sources such as an indicia reader, a shipping document, or an ITS (shared or regional).

A character is placed in each identifier indicating whether the item is a unique stand-alone item or an item container (4920). As noted above, the container can be distinguished from individual items located within the container having "1" as the leading character of the object-kind portion of the code; however, other characters and character positions may also be used. Based on the found character, it is determined whether the identification code corresponds to an individual item or to a container (4930).

When such a determination is done at the tag reader level, the tag reader can distinguish individual items from the item container and use this feature to filter out reads that are not relevant to the recipient of the read information. For example, if the recipient is a shipping company, it may only want to know the marking information about each item's container, but not the item itself. In this case, the reader itself or a higher-level component in the system can filter out the codes on individual items and transmit only the marking information on the container to the recipient.

Control access to tracking information

In a cross-enterprise computing environment, this tracking information can be consumed by multiple consumers. However, the producer may not necessarily want all consumers to share the same degree of access. For example the manufacturer may record information about a shipment, such as "Person in Charge" or "Quality Rating", which may be accessible to some consumers (eg Customs) but not to others.

In one embodiment, access to tracking information is controlled by providing the consumer with only a portion of the file. For example, a shipping company may only need to know (or be authorized to know) the total number of shipments, but the shipping company may not need to know (or be authorized to know) other characteristics of the shipment (eg, color, price).

However, it would be more efficient to just send the same encoded file to all consumers. Therefore, another embodiment provides the same file to all consumers, but in an encoded format. Each consumer is then individually provided with an option to decode only a portion of the file. The encoding and decoding may be completely transparent to an external system 4312 such as an ERP system. In other words, the input and output of the tracking information can be ordinary unencoded files.

As shown in FIG. 50, in performing a method 5000 for controlling access to tracking information, a producer creates tracking information about a collection of items representing each items. The producer encodes the trace information by encoding each instance of each unambiguous property in the trace information with its corresponding unambiguous encoding scheme. The producer sends the encoding tracking information to a recipient (5030), determines which features the recipient is authorized to access (5040), and provides the recipient with a subset of the encoding scheme (5050), the subset Include encoding schemes only for properties that the user is authorized to access.

The method 5000 can be performed at various points in the tracking process, such as before the tracking information is stored in a tag or before the tracking information is accessed in a shared ITS. Method 5000 may be performed whenever tracking information is released and whenever the sender wants to control access to tracking information.

As described in FIG. 51 , in performing a method 5100 for accessing tracking information, a consumer receives coded tracking information about a collection of items, the tracking information representing each item in terms of one or more characteristics and selected corresponding values, The tracking information is encoded by encoding each instance of each unambiguous property in the tracking information with its corresponding unambiguous encoding scheme (5110). The consumer also receives a subset of the encoding schemes, the subset containing only encoding schemes pertaining to properties the recipient is authorized to access (5120). Finally, the consumer decodes the properties to which the recipient is authorized to access (5130).

The tracking information can be stored in an XML document as part of the markup associated with an entity object. With a reader, a consumer can retrieve the XML document from the tag. Alternatively, the consumer can also retrieve an XML document from another location, such as from a shared ITS or other computer system.

A Document Type Definition (DTD) or an XML Schema defines the metadata of an XML document. A DTD can be included in an XML document or stored separately. For example, for a product called by a DTD, as shown in the following table, the characteristic fields of product type, product ID, version, seller, selling price, origin, manufacturing time, valid time, person in charge, quality level, and weight:

<? xml version = "1.0" encoding = "UTF-8"? ><! Project product (product type, product ID, version, seller, selling price, place of origin, manufacturing time, valid time, person in charge, quality level)><! Project Product Type (#PCDATA)><! Project Product ID (#PCDATA)><! Project Version (#PCDATA)><! Project Vendor (#PCDATA)><! Item Sales Price (#PCDATA)><! Project Origin (#PCDATA)><! Project Manufacturing Time (#PCDATA)><! Project Expiration Date (#PCDATA)><! Project Leader (#PCDATA)>

<! Project Quality Class (#PCDATA)><! Item Product Group (Product+)>

An XML file based on this DTD file is in the following table:

<? xml version = "1.0" encoding = "UTF-8"? ><! File Type Product Group System "Product Group.dtd"><Product Group><Product><Product Type>XXXX</Product Type><Product ID>45EF76345</Product ID><Version>E3DF67</Version><Vendor> AAA</seller><selling price>1988-12-28</selling price><origin>621</origin><manufacturing time>2000-12-28</manufacturing time><valid time>2002-12-28 </effective time><person in charge>Kelly De</person in charge><product level>6</product level></product><product><product type>XXXY</product type><product ID>45E003123</ Product ID><Version>9FD56</Version><Seller>BBB</Seller><Selling Price>3.4</Selling Price><Origin>621</Origin><Manufacturing Time>2000-02-28</Manufacturing Time ><effective time>2002-02-28</effective time><person in charge>Kevin Smith</person in charge><product level>8</product level></product></product group>

FIG. 52 illustrates a file system, index tables, and coded files used to associate tracking information and tagged items 5245 in a network 5240. A producer 4301 uses an index table 5230 to convert a producer XML document 5210 into an encoded XML document 5215 . The index table can also be used to convert a producer DTD file 5220 to an encoded DTD file 5225. The consumer receives the encoded XML or encoded DTD file 5260/5270 from the producer on the network. The consumer uses a destination index table to convert the encoded XML document to a consumer XML document 5265, or to convert the encoded DTD document to a consumer DTD document 5275. The consumer uses the consumer XML file or the consumer DTD file.

The index table 5230 is used to create XML files at the producer side. An index table relates tag names to index values. Each property field has a corresponding tag name that describes the feature. Optionally, each property field also has a corresponding value. The tag name is generally descriptive and the index is the encoding of the tag name. An encoding that is efficient for the predicted value of the marker should be chosen. The aforementioned index table for controlling the product group XML file may be as follows:

tag name index Product Product Type Product ID Version Seller Price Origin Production Time Effective Time Responsible Person Product Grade Product Group 123456789101112

The index value in the index table can be arbitrary, thus making it difficult to interpret the coded XML file without the index table.

Based on the index table, an XML document is transferred to an intermediate data file called encoded XML document 5215. An encoded MXL file corresponding to the above XML file created with the index table is:

<? xml version="1.0" encoding="UTF-8"><! File type 12 system "12.dtd"><12><1><2>XXXX</2><3>45EF76345</3><4>E3DF67</4><5>AAA</5><6 >1988-2-28</6><7>621</7><8>2000-12-28</8><9>2002-12-28</9><10>Kelly De</10 ><11>6</11></1><1><2>XXXY</1><3>45E003123</2><4>9FD56</3><5>BBB</5><6 >3.4</6><7>621</7><8>2000-02-28</8><9>2002-02-28</9><10>Kevin Smith</10><11> 8</11></1></12>

At the same time, an encoded DTD file is created based on the original DTD file. The aforementioned coded DTD file corresponding to the DTD file and established together with the index table is:

<? xml version = "1.0" encoding = "UTF-8"? >

<! Item 1 (2, 3, 4, 5, 6, 7, 8, 9, 10, 11)><! Item 1 (#PCDATA)><! Item 2 (#PCDATA)><! Item 3 (#PCDATA)><! Item 4 (#PCDATA)><! Item 5 (#PCDATA)><! Item 6 (#PCDATA)><! Item 7 (#PCDATA)><! Item 8 (#PCDATA)><! Item 9 (#PCDATA)><! Item 10 (#PCDATA)><! PROJECT 11 (#PCDATA)><! Item 12(1+)>

When the consumer encodes the file, the consumer can change the tag names to be more consistent with the consumer's own naming traditions.

To control access, a further benefit of encoding this information is that the encoded tag names take up less space than unencoded tag names, which are often descriptive and can be very long. Optional compact index values like the simple numeric indexing scheme mentioned earlier.

Tags have limited memory or space. Thus, more tracking information (such as property fields) can be included in the markup by using compact index values. Similarly, when the tracking information is communicated across a network, the encoded information may be transmitted using less bandwidth than the unencoded version.

Figure 53 illustrates a method for checking the proper index table for building an encoded XML document. The system of the present invention first checks whether the index table needs to be updated (5310). If no update is required, an encoded XML file or encoded DTD file is created using the existing index table. If the index table needs to be updated, a new index table is created and then used to create an encoded XML file or an encoded DTD file (5330).

The encoded XML document is transmitted over a network or stored in a smart tag associated with a physical object. On the consumer side, a destination index table is used to decode the file. As for the index table as shown in the following example, the destination index table associates tag names with index values.

tag name index product 1

Product Type Product Identification Version Number Vendor Name Production Time Effective Time Product Group   23458912

All the indexes located in the target index table must output the current corresponding source index table, and the source index table is used to create the encoded file. However, all indexes located in an index table may not appear in the corresponding destination index table. A consumer of the XML document receives the tag name and an index to only property fields that the producer authorizes the consumer to share. For example, if the XML file is created by a manufacturer and the customer is a retailer, and the manufacturer does not want the retailer to see the attribute fields named Responsible Person and Product Level, then these indexes will not appear. The retailer's destination index table.

The tag name associated with a particular index of the destination index table may be different from its corresponding index table. Therefore, the consumer can adjust the name to be consistent with the consumer's application. For example, the customer can substitute the product ID with product identification, version number with version number, and vendor name with vendor as described above. But the meaning of these symbols is the same in its related application.

Based on the above purpose index table and encoded DTD file, the consumer will see the following DTD file:

<? xml version = "1.0" encoding = "UTF-8"? ><! File Type Product Group System "Product Group.dtd"><! Project product (product type, product identification, version number, vendor name, selling price, origin, manufacturing time, valid time><! Project product type (#PCDATA)><! Project product identification (#PCDATA)><! Project version Number (#PCDATA)><! Item seller name (#PCDATA)><! Item selling price (#PCDATA)><! Item origin (#PCDATA)>

<! Project Manufacturing Time (#PCDATA)><! Project Expiration Date (#PCDATA)><! Item Product Group (Product+)>

Based on the above purpose index table and the encoded XML file, the consumer will see the following XML file:

<? xml version = "1.0" encoding = "UTF-8"? ><! File Type Product Group System "Product Group.dtd"><Product Group><Product><Product Type>XXXx</Product Type><Product Identification ID>45EF76345</Product Identification><Version Number>E3DF67</Version Number> <Vendor Name>AAA</Seller Name><Selling Price>1988-12-28</Selling Price><Origin>621</Origin><Manufacturing Time>2000-12-28</Manufacturing Time><Validity Time> 2002-12-28</effective time></product><product><product type>XXXY</product type><product identification>45E003123</product identification><version number>9FD56</version number><vendor name >BBB</seller name><sale price>3.4</sale price><origin>621</origin><manufacturing time>2000-02-28</manufacturing time><valid time>2002-02-28</ Effective time></product></product group>

The invention may be implemented in digital electronic circuitry, or in computer hardware, software, or a combination of both. The invention may be implemented as a computer program product, i.e. a computer program tangibly embodied in an information carrier, for example in a machine-readable storage device or in a transmitted signal, for execution by data manipulation means or for controlling the operation of the device. A computer program can be written in any programming language, including compiled or interpreted languages, and it can be implemented in any form, including as a stand-alone program or as a component, component, subroutine, or other program suitable for use in a computer environment unit. A computer program can be implemented to be executed on one computer or on multiple computers at the same site or across multiple sites and interconnected by a communication network.

The method steps of the invention may be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output data. Method steps may also be performed by special purpose logic circuits such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit) and the apparatus of the present invention.

Processors suitable for the execution of a computer program include, for example, general and special purpose microprocessors, and any one or more processors in any type of digital computer. Generally, a processor receives instructions and data from a ROM or a RAM or both. The essential components of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. A computer will also typically include or be operatively associated with one or more mass storage devices such as magnetic disks, magneto-optical disks or optical disks for storing data, for transmitting data to it or receiving data from it or both. Information carriers suitable for containing computer program instructions as well as data include all forms of non-volatile memory - including for example semiconductor memory devices such as EPROM, EEPROM and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; CD-ROM and DVD-ROM discs. The processor and memory may augment or be included with special purpose logic circuitry.

In order to provide interaction with a user, the invention may be implemented on a computer having a display device for displaying information to the user, such as a CRT (Cathode Ray Tube) or LCD (Liquid Crystal Display) display, And a keyboard and a pointing device, such as a slider or a trackball, with which the user provides input to the computer. Other types of devices may also be used to provide interaction with the consumer, for example the feedback provided to the consumer may be any type of sensory feedback such as visual, auditory or tactile feedback; and the input from the consumer may be in any form Received, including auditory, spoken, or tactile input.

The present invention may be implemented in a computer system comprising a back-end component, such as a data server, or comprising a middleware component, such as an application server, or comprising a front-end component, such as having a geographic user interface or A web browser client computer through which a user can interact with an implementation of the present invention or any combination of such backend, middleware or frontend components. The components of the inventive system can be interconnected by any form or medium of digital data communication, eg, a communication network. Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), and the Internet.

The computer system can include clients and servers. A client and server are usually remote and interact with each other usually through a communication network. The relationship of client and server arises by virtue of the computer programs executing on the respective computers and having a client-server relationship to each other.

The invention has been described with specific embodiments and aspects. Other implementations are within the scope of the following claims. For example, the steps of the invention can be performed in a different order and still achieve desirable results. The system of the present invention is flexible and provides many business methods for tracking items. In one approach, one or more customers subscribe to the system of the invention provided by a service provider that distributes the service over a network such as the Internet. In this case, the customer does not need to acquire these components or the overall system, thus saving operating costs. In addition, the customer can also obtain these components or the overall system, thereby saving operating costs. In addition, the system of the present invention can support any combination of the above business methods. For example, certain customers may order the system of the present invention and certain customers may obtain the components or the overall system.

Other arrangements are within the scope of the claimed invention. The inventive system supports the development of new or enhanced applications for a range of industries from a regional to a global scale. Other applications for the system of the present invention include supply chain management, asset tracking management, security and access control, shipping, billing, point of sale applications, and baggage handling. These examples are further described below.

supply chain management

RFID systems are ideally suited for identifying high-unit, high-value products that move through an assembly process, such as automotive or agricultural equipment manufacturing. RFID systems also provide the reliability that is indispensable for the permanent identification of product carriers such as boxes, crates and pallets. Other applications in supply chain management include work in process tracking and parcel delivery.

Asset Tracking and Management

Asset tracking and management applications include those used to monitor the flow of equipment, personnel, and documents in a space such as a building, storage yard, or terminal to enhance, for example, the control of assets and maintain the integrity of items including individuals tracking. Specific applications in asset management include: records/document tracking, personnel tracking, yard management, and equipment tracking.

Security and Access Control

The movement and use of valuable equipment and personal resources can be monitored through transponders attached to or carried by the equipment or individuals. The transponder may also be included in a credit card sized security token reader. Home security call systems and building access are two examples of security and access control applications.

transport

A transponder can be attached to a carrier (eg plane, train, truck) and can contain important information about the carrier and its contents. Shipping applications include aircraft identification, train and shipping container tracking, public transport ticketing, and scale station applications.

TOLL

The charging application includes attaching a transponder to a carrier. The transponder transmits a code identifying a prepaid account to a reader, which automatically debits the account.

point of sale

These applications include retail items, counterfeit prevention, and electronic monitoring of sales transactions and often involve marking individual retail items with low cost transponders, which are dynamic in nature.

baggage handling

In a baggage handling application, airline baggage is tagged with RFID transponders, such as smart tags, to allow airline baggage handling operations to track baggage from the time a passenger checks into the airport until the passenger arrives at his final destination.

Claims (43)

1. A method for environment orientation and real-time project tracking, which at least includes: receiving a plurality of tag read data instances, each instance including information read from a tag attached to an item, the read information including a unique digital identifier read from the tag, when the When the unique identifier is read from the tag, each instance also includes a position of the corresponding tag and the state information of the item attached to it, and the multiple tag read data instances are collectively included from the mark the information read; Receiving one or more context information instances, each instance describing an associated unmarkable entity condition, the context information indicating a state of a location containing the condition, the plurality of instances context information collectively including describing a plurality of conditions Information; Using the received tag to read data and environment information to maintain a virtual item in a virtual world, the virtual item includes an object for each commodity, and the virtual situation includes an object for each situation , where each object represents the state of its corresponding item or condition; and Interactions occurring between the condition and the item represented by the virtual condition and the virtual item in the virtual world are detected. 2. The method of claim 1, wherein: Information about the product and the status in the virtual world is a standardized dimension of the full virtual world that is mapped to time, three-dimensional space, and a unique identifier, whereby the product and the status can be interactively tracked through space and time. 3. The method of claim 1, further comprising: An alert is issued to a user of a virtual world, where the user is a person or a computer program, whenever it is determined that any commodity is affected by a detected interaction. 4. The method of claim 1, further comprising: A representation of each item's current location and each condition's current location is maintained in the virtual world, each individually reflecting the most recently received tag read data and environmental information. 5. The method of claim 4, further comprising: Positions and conditions are represented by latitude, longitude, and altitude. 6. The method of claim 4, further comprising: A history of item locations is maintained and a history of condition locations is maintained. 7. The method of claim 5, further comprising: A predicted value of a future location of at least one commodity is derived from the virtual world based on historical records of commodity locations. 8. The method of claim 7, further comprising: The predicted value of the future location is also derived based on the historical record of the situation location. 9. The method of claim 1, further comprising: A representation of the current state of each commodity and a representation of the current state of each condition is maintained in the virtual world, each of which individually reflects its most recently received tag reading data and environmental information. 10. The method of claim 9, further comprising: A history of item status is maintained and a history of condition status is maintained. 11. The method of claim 10, further comprising: A predicted value of the future state of at least one commodity is derived from the virtual world based on the historical record of the commodity state. 12. The method of claim 11, further comprising: The predicted value of the future state is also derived based on the history of the state of the situation. 13. The method of claim 1 or 8, further comprising: Combining timestamps with each tag read data instance and context information, each timestamp is synchronized to a single standard. 14. The method of claim 1, wherein: the unmarkable condition includes a weather-related condition; and The location of the weather-related condition is described by at least one of latitude, longitude and altitude. 15. The method of claim 1, wherein: the unmarkable condition includes a traffic accident; and The location of the traffic accident is described by at least one latitude, longitude and altitude. 16. The method of claim 1, further comprising: receiving one or more Hierarchy Information instances, each instance being a description of a hierarchy between commodities represented in the virtual world; and The received hierarchy information is used to maintain environment objects in the virtual world, each environment object representing one of the hierarchy. 17. The method of claim 16, wherein: At least one hierarchy is a relationship between items in which certain items are contained within another item. 18. The method of claim 1, further comprising: receiving sensor information from a sensor associated with a first commodity; and A first physical object related to the first product is updated with the sensor information. 19. The method of claim 1, wherein the step of receiving environmental information comprises: An instance of receiving environmental information from an external system. 20. The method of claim 1, wherein the step of receiving an instance of environmental information comprises: Instances of environmental information are received, where the instances include, for example, telemetry data from sensors associated with a particular location. 21. The method of claim 20, further comprising: receiving telemetry data generated by a sensor associated with a specific point or area, the telemetry data representing a condition at the specific point or area; and generating an alert to a user in the virtual world when the virtual world detects that an item is located on or in the point or area represented in the virtual world that may be affected by conditions represented by the telemetry data, wherein The user is a person or a computer program. 22. The method of claim 20, further comprising: receiving temperature data generated by a temperature sensor associated with a specific point or area, the temperature data representing the current temperature of the specific point or area; and With the product and the current temperature represented in the virtual world, when the virtual world detects that a product is located on or in the point or area that may be affected by the current temperature, a user in the virtual world or generate an alert, where the user is a person or a computer program. 23. The method of claim 1, further comprising: attach an exception temperature to an entity object, and When the exception temperature is met, an operation is caused. 24. The method of claim 23, wherein: The operation includes generating an alert to a user, where the user is a person or a computer program. 25. The method of claim 1, further comprising: Attach a rule to a physical object that can be manipulated to trigger an alert event or trigger an action based on current information in the virtual world. 26. The method of claim 1, further comprising: Attaching a rule to an environment object can be manipulated to trigger an alert event or cause an action based on current information in the virtual world. 27. The method of claim 1, further comprising: A query is received, processed and responded to regarding the current or past status of an item in the virtual world. 28. The method of claim 27, further comprising: Receiving, processing and responding to an inquiry regarding the status of an item, the item and the current or past status of the specific item in the virtual world having a specific relationship to each other. 29. A method of updating information attached to a writable tag of an item, comprising at least: Receiving first characteristic information of a first item in a system, wherein the first characteristic information is data automatically read from a first tag attached to the first item, the first characteristic data includes identifying the first a primary identifier of the item; Receiving second characteristic information of a second item in a system, wherein the second characteristic information is data automatically read from a second tag attached to the second item, the second characteristic data including identifying the second a second identifier for the item; receiving sensor information in a system from data automatically read from a sensor coupled to the second item; Receiving relationship information in a system indicating a relationship between the first item and a second item; maintaining a first and a second virtual item respectively representing the first and second items in a system, the The object maintenance information respectively represents the first characteristic information and the second characteristic information and the sensor information, and maintains a virtual state representing the relationship between the first item and the second item in the system; identifying an alert condition associated with the first item from information in the physical and virtual conditions; generating updated property information written to the first item in response to the alert condition; detecting, in a system, the presence of the first mark in a mark writing area after the alert condition is identified; and When it is detected that the first mark is located in the mark writing area, the mark writing area writes the updating information into the first mark in the mark writing area. 30. The method of claim 29, wherein: the alert condition is identified by an application external to the system that receives information from the system from objects maintained by the system; the application generates updated property information and is provided to the system by the application along with a request for the updated property information to be written into the first tag; and In response to the request, the system causes the tag writing area to write the updated information into the first tag. 31. The method of claim 30, wherein: the first and second virtual items represent corresponding items in a virtual world maintained by the system; and The application monitors the virtual world. 32. The method of claim 29, wherein: identifying the alert condition by a component of the system operating in accordance with one or more alert rules provided to the system; a component of the system operating in accordance with one or more update rules provided to the system generates an update message; and According to one or more data writable rules provided to the system, the tag writing area writes the update information to the first tag. 33. The method of claim 29, wherein the sensor is attached to the second marker. 34. The method of claim 29, wherein the sensor is a temperature sensor. 35. The method of claim 34, wherein: the alert condition arises because the temperature measured by the sensor exceeds a threshold; and The update information is data on a shortened product expiration date of the first item. 36. The method of claim 29, wherein the first marker is a radio frequency transponder. 37. The method of claim 29, wherein the first and second identifiers are globally unique identifiers. 38. A method to be performed in a business data processing environment, wherein the environment includes a plurality of businesses located in a supply chain, said method comprising at least the steps of: Provide real-time visibility of the company's item location in the supply chain, which is achieved by the following steps: receiving multiple instances of tag read data from a first enterprise, each instance including information read from a tag attached to an item, the read information including a unique number read from the tag identifier, each instance further comprising a location containing the corresponding marker and its attached item when the identifier is read from the marker, the plurality of marker read data instances received from the first enterprise collectively comprising from Information read by tags attached to multiple items; maintaining configuration information for the item using the tag read data received from the first enterprise; Receive a plurality of second tag read data instances from the second enterprise, each instance including information read from a tag attached to an item, the read information including a unique type of tag read from the tag digital identifier, when the unique identifier is read from the tag, each instance also includes a location containing the corresponding tag and its attached item, the plurality of tag read data instances received from the second enterprise as a whole Contains information read from a tag attached to at least one item of the plurality of items; maintaining configuration information for the item using the indicia read data received from a second enterprise, wherein indicia read data received from either enterprise for a particular item is used to update the configuration information; and The configuration information is made visible to enterprises in the supply chain including the first and second enterprises. 39. The method of claim 38, further comprising: Receive multiple instances of third tag read data from a third enterprise, each instance comprising information read from a tag attached to an item, the read information including a type automatically read from the tag a unique tag identifier, when the tag identifier is read from the tag, each instance also includes a location containing the corresponding tag and its attached items, a plurality of tag read data read from the third enterprise The instance collectively comprises information read from a tag attached to at least one item of the plurality of items; and Configuration information for the item is maintained using the indicia read data received from a third enterprise, wherein indicia read data received from either enterprise for a particular item is used to update the configuration information. 40. The method of claim 38, wherein: The tags attached to the plurality of items include radio frequency identification tags, each radio frequency identification tag carrying an electronic product code as its unique tag identifier. 41. The method of claim 38, wherein: the visibility is the controlled visibility; and The method also includes: receiving authorization information indicating the extent to which the configuration information should be made visible to a particular enterprise in the supply chain; and This particular enterprise is made to only see the configuration information allowed by the authorization information. 42. The method of claim 41, wherein: The configuration information contains a number of project properties; and The authorization information indicates, for at least one item property, which item properties are visible to the enterprise. 43. The method of claim 38, wherein: the plurality of businesses includes a source business and a destination business; the source business has an order document for an order placed by the destination business and a shipping document for a physical shipment of goods in preparation for fulfilling the order placed by the destination business; Visibility includes visibility of relationship between indicia read data and enterprise documents including the order document and the shipping document; and Provides real-time visibility into the enterprise project configuration, which also includes: Receive shipment information that includes the following information: Regarding the marking identifier corresponding to the goods in the shipment; information on associating each marking identifier with a shipment number for the shipment document; and Information about combining the shipment number with the order number for the order document; correlating the tag reading data with the shipment information; and The association is made available to the destination business so the destination business can use a tag identifier for an item in the shipment to validate the shipment.

Images