JP2005515135A - Context-aware real-time item tracking system architecture and method of use - Google Patents

Abstract

  Methods and apparatus, including computer program products, for real time and context awareness tracking (116) of items are provided. Read the tag (102) associated with the item, supply the information read from the tag, and location information about the tag by at least two companies, and visualize the treatment information about the item to the companies in the supply chain Hold. The treatment information can be mapped to items and information affecting the items, for example, a world model that tracks geospatial events and traffic delays. The visibility of treatment information can be controlled by permission. Visible information may include relationships between specific items and business documents such as ordering and shipping documents.

Description

  The present invention relates to tracking tangible items.

  Conventional tangible item tracking systems often include a calculator and software. Such a system maintains information indicating a status such as the current location of the tracked object. This can be thought of as a virtual world.

  In conventional systems, discrepancies can easily occur between the actual status of an item and the status indicated by the system. In many cases, discrepancies are caused by manual data entry errors and system limitations. As a result of such a problem, in the conventional system, the actual depiction may be distorted or fragmented. In addition, most conventional systems monitor with a very limited range and resolution, for example, some systems can only distinguish between product classification and quality, but not individual items. .

This specification describes methods and apparatus, including computer program products, for context-aware real-time item tracking.
As used herein, the term “item” shall mean an actual tangible object to avoid ambiguity resulting from the use of the term “object”. The term “object” is used in the following text only when referring to a data processing structure.

  In general, in one aspect, the invention features a system and method for tracking items, and components configured to perform the method aspect. A system according to the present invention is a tagged component that includes information specifying a standard for tagging one or more items, each tag including a globally unique identifier, and a tag communicating Context-aware intelligence that includes an object interface component that includes a device that receives the context information, logic that processes the context information, and logic that specifies system actions and executes in response to the context information And communication middleware components for communication between components of the system and with devices outside the system.

  In general, in another aspect, the invention features a system and method for item context awareness and real-time tracking, and components configured to perform the method aspect. The method according to this aspect is an action that receives multiple instances of tag read data, each instance including information read from a tag coupled to the item, and the read information is automatically received from the tag. Multiple instances of tag read data, including a unique digital identifier read, each instance including status information including the location of the corresponding tag, and its combined item when the unique identifier is read from the tag Are actions that collectively receive information read from tags coupled to a number of items, and actions that receive one or more instances of contextual information, each instance having an associated tagging Describes an impossible physical situation, and context information indicates the status, including the position of the situation, Multiple instances of text information collectively contain information describing multiple situations, using actions received and tag read data and context information to identify virtual items and situations in the virtual world Actions to hold, where a virtual item contains each object of a number of items, a virtual situation contains each object of a number of situations, and each of the objects represents the status of its corresponding item or situation And actions for detecting interactions occurring in the virtual world between the situation and the item represented by the virtual item and the virtual situation.

  In general, in another aspect, the invention features a system and method for making information available between businesses, and components configured to perform the method aspect. The method according to this aspect is an action of receiving multiple instances of tag lead data from a first company, each instance automatically from a tag associated with an item, including at least a unique digital identifier. Multiple instances of tag read data received from the first company, each instance includes status information including the location of the corresponding tag and the item coupled to it, including the read information The information read from the tag that is combined with the item of the item is collectively included, the tag read data includes the data obtained from the first data processing system of the first company, the action received from the first company An action that uses tag lead data to maintain a virtual representation in a virtual world, where the virtual representation is And an action for receiving multiple instances of tag lead data from a second company, each virtual representation representing a status corresponding to each virtual representation, wherein each instance is at least Including information automatically read from the tag associated with the item, including a unique digital identifier, each instance including status information including the location of the corresponding tag and the item associated with the second company The multiple instances of tag read data received from the batch include information read from the tags coupled to the first multiple items, the tag read data being the second data of the second company. A virtual world using actions and tag read data received from a second company, including data from a processing system An action to maintain a virtual representation in which the virtual representation includes a virtual representation of each of the second number of items, each virtual representation represents a corresponding status, and is received for a particular item from any symbol Using the tag read data, the virtual expression corresponding to the item is updated, and the information from the updated virtual expression and the virtual world can be used by both the first company and the second company. Execute the action to be performed.

  In general, in another aspect, the invention relates to a system and method for updating information on a writable tag coupled to an item, and components configured to perform this method aspect. It is characterized by. The method according to this aspect is an action for receiving first attribute information about a first item in the system, wherein the first attribute information is automatically read from a first tag coupled to the first item. The first attribute information includes a first identifier for identifying the first item, and an action for receiving the second attribute information for the second item in the system, An action wherein the second attribute information is obtained from data automatically read from a second tag associated with the second item, and the second attribute information includes a second identifier identifying the second item An action for receiving relationship information specifying a relationship between the first item and the second item in the system, and a first and second virtual item representing the first and second items in the system, respectively. An action to be held, wherein the object represents information representing the first attribute information and the second attribute information, and sensor information, respectively, and in this system, a virtual situation representing the relationship between the first and second items is represented. Actions to be held and actions for recognizing alarm conditions from information in physical and virtual situations, where the alarm conditions relate to the first item, and update attributes to be written to the first item in response to the alarm condition An action that generates information, an action that detects the presence of the first tag in the tag writer station, and an existence of the first tag in the tag writer station after the alarm condition is recognized in this system In the tag writer station, the update information is written to the first tag in the tag writer station. To run and that action.

  Advantageous implementations can have one or more of the following features. By mapping information in the virtual world about items and situations to standardized dimensions across the virtual world of time, 3D space, and unique identity, items and situations can be tracked with respect to each other in space and time . The method also alerts the virtual world user whenever it determines that the detected interaction affects any of a number of items. The method also maintains in the virtual world a representation of each current location of the item and a representation of each current location of the situation, each representation reflecting the last received tag lead data and context information. To do. The method also represents position and situation in latitude, longitude, and altitude. The method also maintains an item location history and a situation location history. The method also obtains a prediction of at least one future location of the item from the virtual world based on a history of the location of the item. The method also obtains future position predictions based on the situation position history. The method also maintains in the virtual world a representation of each current state of the item and a representation of each current state of the situation, the representation being the tag read data and context information received last, respectively. Reflect. The method also maintains an item status history and a status status history. The method also obtains a prediction of at least one future state of the item from the virtual world based on the history of the state of the item. The method also obtains future state predictions based on the state state history. The method also associates each instance of tag read data and context information with a time stamp and synchronizes each time stamp to a single standard. Conditions that cannot be tagged include weather-related situations and describe the location of the weather-related situation by at least longitude, latitude, and altitude. Situations that cannot be tagged include traffic accidents and describe the location of the traffic accident by at least longitude, latitude, and altitude. The method also receives one or more instances of hierarchy information, each instance describing a hierarchy between items represented in the virtual world, and using the received hierarchy information, Holds a context object that represents one. At least one of the hierarchies is a relationship between items, where some specific items are contained within another item. The method also receives sensor information obtained from a sensor attached to the first item, and updates the first physical object for the first item with the sensor information. The method also receives an instance of context information from an external system. The method also receives an instance of context information, which includes telemetry data from sensors attached to a particular location. The method also receives telemetry data generated by a sensor attached to a specific point or area and representing a situation occurring at the specific point or area, and the virtual world is represented by the situation represented by the telemetry data. When it detects that the affected item is at a point or area represented in the virtual world, it alerts the user of the virtual world, which is a person or a computer program. The method may also be generated by a sensor attached to a particular point or area and receive temperature data representing the current temperature of the point or area in the context object in the virtual world, where the virtual world depends on the current temperature. When detecting that the affected item is at a point or area represented in the virtual world, the item and current temperature are represented in the virtual world to alert the virtual world user, A person or computer program. The present invention also provides a temperature exception to the physical object and causes the procedure to be executed when the temperature exception is satisfied. This procedure consists of generating an alarm to the user, who is a person or a computer program. The method also assigns a rule to the physical object that is operable to trigger a trigger event or cause an action to be performed depending on current information in the virtual world. The method also assigns a rule to the context object that is operable to trigger a trigger event or cause an action to be performed depending on current information in the virtual world. The method further receives, processes, and responds to a query regarding the status of the item at the current time when the item was represented in the virtual world or at a past time that was represented. The method also queries for the status of the item and items that have a specific relationship to the specific item if the specific item at the current or past time is represented or represented in the virtual world. Receive, process and respond.

  In general, in another aspect, the invention features a method and apparatus that includes a computer program product that provides multiple companies with access to information about items in a supply chain. The tag associated with the item is read and the information read from the tag and the location information about the tag are provided by at least two companies and used to hold treatment information about the item. Action information is visible to companies in the supply chain. The tags can be radio frequency identification tags each having an ePC (electronic product code) as a unique tag identifier. The visibility of treatment information can be controlled by permission. Visible information may include relationships between specific items and business documents, such as ordering and shipping documents. By visualizing the shipping document, the information read from the item tag can be used to verify the identity or integrity of the shipping product. The system according to the present invention is a means for receiving a number of instances of tag lead data from a first company, each instance comprising information read from a tag coupled to an item, Each tag contains a unique tag that is automatically read from the tag, and each instance also includes the corresponding tag location when the tag identifier is read from the tag and the item associated with it. Multiple instances of lead data collectively include information read from tags coupled to multiple items, and treatment information about the item using tag lead data received from the first company And means for receiving a number of instances of the second tag read data from the second company, wherein each instance Contains the information read from the tag that is bound to, and the read information contains a unique tag identifier that was automatically read from the tag, and each instance of the corresponding tag when the tag identifier is read from the tag Multiple instances of tag read data received from a second company collectively include information read from tags coupled to at least one of the multiple items, including the location and the item coupled to it. , Means and means for holding treatment information about an item using tag read data received from a second company, using tag read data received for a specific item from any company Means for updating the treatment information and means for visualizing the treatment information to a number of companies in the supply chain including the first and second companies.

  Advantageous implementations of the foregoing system may have one or more of the following features. The system is a means for receiving a number of instances of third tag read data from a third company, each instance including information read from a tag associated with the item, Each tag includes a unique tag identifier that is automatically read from the tag, and each instance also includes the corresponding tag location when the tag identifier is read from the tag and the item associated therewith. Receiving means, where multiple instances of lead data collectively include information from a tag coupled to at least one of a number of items, and the item using tag lead data from a third company Means for holding the treatment information, and updating the treatment information using the tag read data received for a specific item from any company, It may include a lifting means. The system may be implemented such that tags coupled to multiple items include radio frequency identifier (RFID) tags, and each RFID tag carries an electronic product code (ePC) as a unique tag identifier. it can. The system can be implemented such that the visibility is controlled visibility, and the system further receives permission information indicating the extent to which the treatment information is visible to a particular company in the supply chain. And means for visualizing only treatment information permitted by the permission information to a specific company. The system can be implemented such that the treatment information includes a plurality of item attributes, and the permission information specifies a company that can visualize the item attributes for at least one of the item attributes. This system includes a number of companies including a supplier company and a destination company, and the supplier company provides an order document for an order placed by the destination company and a product prepared to satisfy the order placed by the destination company. A shipping document for the physical shipment and the visibility includes the visibility of the relationship between the tag lead data and the business document including the ordering document and the shipping document, and the real-time handling of the item The means for providing visibility to the company further includes tag identifiers for items corresponding to approval in shipping, information for associating each tag identifier with the shipping number of the shipping document, and information for associating the pickup number with the ordering number of the ordering document. Means for receiving shipping information including, means for correlating tag lead data with shipping information, and making the correlation available to the destination company, the tag identifier for the item in the destination company shipping It can be implemented to include a means to be able to see shipment using.

  In general, in another aspect, the invention features a method and apparatus that includes a computer program product for communicating between nodes of a distributed system that tracks items. The system is a node hierarchy in a first company, where the node hierarchy includes one or more parent nodes and one or more local nodes, each local node being a child of the parent node. A node hierarchy and a node hierarchy in a second company, the node hierarchy including one or more parent nodes and one or more local nodes, each local node being a child of the parent node Including a node hierarchy. Within this system, each node maintains a mapping between multiple items and responsible nodes. In the mapping, for each item, at least one parent node, which is a responsible node designated for the item, is designated, and different designated responsible nodes are specified for at least two items. Each node is operable to receive multiple instances of tag read data, including information read from the tag that each instance is bound to the item, and the read information is automatically retrieved from the tag. Includes a unique tag read, each instance also including the corresponding tag location when the tag identifier is read from the tag and the item associated with it, and multiple instances of tag read data Contains the information read from the tag linked to the item. For each instance of tag read data, each node is operable to communicate the tag read data to the designated responsible node identified by the mapping held by the node.

  Advantageous implementations of the system can include additional features. The system can be implemented such that the mapping established at the first node is different from the mapping established at the second node. After transmitting tag read data from the node to the designated node for the item, the system receives additional information about the item from the designated node, updates the action information for the item, and updates the received additional information. It can be realized to reflect. Multiple items can receive tag lead data and have a hierarchical relationship with each other. The tag identifier can specify the producer or product classification of the item.

  In general, in another aspect, the invention features a method and apparatus that includes a computer program product for communicating item treatment information in a distributed system. The system includes a monitoring system, one or more subscribers including 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, and publish the event to one or more event routers. The event includes a tag identifier, a reader identifier, and a time stamp. A system for tracking tagged items subscribes to receive events related to one or more tagged items from one or more event routers, and uses the received events when receiving events. And is operable to update treatment information for one or more tagged items. Each event router is operable to maintain a list of subscribers, receive events from the monitoring system, and send events to the subscribers.

  In general, in another aspect, the invention features a method and apparatus that includes a computer program product for transferring data between a sensor or actuator device and a host application. A computer program product according to the invention causes an item of data to be received by a data processing device, specifies which data the rule supplies to an external application, and includes an item identifier from one or more tag readers. Data is received, each item identifier is read from a digital tag coupled to the physical item, the item identifier uniquely identifies the item, additional item data is received from other sensor devices, and other items The sensor device is a device other than a tag reader, wherein the additional item data includes additional physical item attributes other than the item identifier, and the additional item data is identified by the tag reader. Which subset of item identifiers and additional item data is to be used using the rules, item identifiers, and additional item data Part or is determined to supply the application, the external application, is operable to supply the data consisting of only the internal component set item identifier and additional items data received. In addition, the computer program product receives data from an external application, the data includes configuration data for controlling the actuator device, and the configuration data is in a format compatible with the actuator device. It is operable to convert and provide the converted configuration data to the actuator device.

  In general, in another aspect, the invention features a system and method for communicating tracking information. The method includes receiving a plurality of identification codes, uniquely identifying a virtual item with which each identification code is associated, and sorting the plurality of identification codes into one or more sets of identification codes A step of recognizing a redundant code portion common to each identification code in the identification code set, a step of creating a document including one or more identification code sets, and organizing the document into a hierarchical structure. For each set, a step of temporarily collecting redundant parts into a list and omitting redundant parts and collecting respective identification codes into a list is included.

  In general, in another aspect, the invention features a system and method for filtering tracking information. The method searches for a plurality of identification codes associated with a plurality of virtual items, the virtual item including an item and a container for the item, each identification code uniquely identifying the associated virtual item. A step that is a character string; in each identification code, a step of finding a character indicating whether the related object is an item or a container; and based on the found character, each identification code corresponds to either an item or a container Determining.

  In general, in another aspect, the invention features a system and method for communicating tracking information about an item. The method includes creating tracking information for a collection of items, wherein the tracking information represents each of the items as one or more attributes and any corresponding values, and for each different attribute in the tracking information. Encode each instance with its corresponding different encoding scheme to encode the tracking information, send the encoded tracking information to the recipient, and which attributes the recipient is allowed to access And a step of supplying a subset of the encoding scheme to the recipient, the subset including only the encoding scheme of the attribute that the recipient is permitted to access. Including.

  The present invention can be implemented to realize one or more of the following advantages. The system of the present invention can recognize a virtually unlimited number of items and other items in the real world, as well as relationships between items and others. The system can be realized on a wide range of scales. The architecture of the system can easily operate and input into a wide variety of applications. The architecture also supports the tracking of a very large number of anything, such as items or situations that affect items. Similarly, the architecture can associate any kind of attribute with a tracked item or situation. Hierarchical and other relationships can be defined between tracked objects and used for tracked objects in that relationship. The architecture is open to all types of data sources, including all types of sensors and scanners, and status information such as weather, traffic conditions, airplane and freight schedules, arrival time data, etc. A system that provides such a transportation schedule is included. The system provides a comprehensive and intelligent glue between the real world and the virtual world and can be used for context recognition and real-time item tracking.

  The system inherently integrates context-aware intelligence. Such intelligence allows the system to know which geospatial events affect which items to be tracked and take action in response to such events. The system can provide generic geospatial abilities in dynamic context recognition intelligence. Based on the available data and telemetry, the system knows where, how and which items are at a particular point in time with respect to each other, and can invoke actions according to defined rules. it can.

  The system can be integrated with existing software and hardware systems using a non-proprietary public interface. Such an interface allows the system to be compatible with existing systems without requiring plug-ins or upgrades to the existing system. For example, the system can provide a non-proprietary public interface to integrate virtually any type of tag, tag reader, scanner, sensor, and application. The system can be implemented to include an application that can generally read data from item tags and write data. The system can include comprehensive tracking of real time telemetry. The system can integrate existing geographic information systems (“GIS”) and data.

The system supports the development of a whole range of new or improved applications across industries. Such applications include those related to supply chain management, material tracking and management, security and intrusion control, transportation, fee collection, point of sale information management, and baggage handling. However, it is not limited to these.
The system can be scaled from the local level to the global level. That is, the system can be implemented to support business units, single companies, and groups of companies in one or more industries. The system can track items and status in real time. The system can provide the current and past status of an item or group of items, for example, from a remote location by wireless communication or through a network such as the Internet.

  With various ingenuity, in the future, a large number of items of all types will be uniquely tagged and in many cases will be globally identifiable by sensors that operate automatically. The system operates across multiple industries and companies and can provide smart enterprise-level item tracking proposals. The system provides an open, comprehensive and reconfigurable business method that can be applied to many industries and applications. This business method allows customers to define a virtual representation of the item generically, introduce it into the software system through NetArc, provide rules to read actions based on dynamic context data, and And the system can be queried for a number of attributes relating to or derived from past contexts.

  The system can access users and external applications via a non-proprietary interface, for example a self-describing document such as a web browser or an XML (Extensible Markup Language) document. The system can track a large number of uniquely tagged items and, if necessary, telemetry data in time and space. The system provides a public, comprehensive and non-proprietary interface to sensors, devices, and services that track the location of items or their environment and / or telemetry data therefrom and provide them to the system. The system also provides a public and non-proprietary interface for sensors, devices, and services that write data to those tags that can receive physical items or data. The system defines uniquely tagged items and virtual representations of their hierarchy, including specific attributes and methods, and allows the system to retrieve actions based on known dynamic context data Sophisticated data access filters at the attribute level of data objects that define items, define virtual representations of physical constraints or other effects that can affect items, and represent items and other real world objects Users who define settings, query the system for a number of features related to or derived from the current and historical context of the tracked item, virtualize them, and share item relationship data with their counterparts over the network Provides interfaces, application interfaces, and tools.

  The system can be used by various entities for their own purposes, each entity being visible to other entities using the system, its tagged items, its data input devices, And part or all of the information regarding the tracking target status. Other entities may use this information to plan the use and effect of various contributions or their beneficial interactions at the time the contributions are made, regardless of the purpose for which the information was originally collected or provided. You can learn from the experience and history of the entire user community of the system, without the need for a point.

  The system allows for early detection of manual errors made during the shipping process, such as in preparation for shipping or loading a truck. The system provides maximum visibility of the actual treatment of goods in the supply chain. The system permanently stores all histories and supports reliability, warranty, customer return, theft prevention, and other business processes. This system will be integrated with existing systems to avoid duplication of functionality. The present invention enables as much functionality as possible and effectively utilizes tags used to track items to enable invoicing based on, for example, detection of shipments at customer destinations.

The system can operate continuously 365 days a year, 24 hours a day. Software upgrades can be done dynamically without disconnecting the entire system. Data can be stored in a generic structure that does not change if the semantic structure of the data changes. In the event of a failure, the system can be quickly recovered by a recovery mechanism with low latency.
The system can be scaled to accommodate a large number of users. The mechanism for changing data can be done out-of-band from the mechanism for querying data. Queries can be limited to the previous state of the data, so the current state is not overloaded by too many queries.

  The system need only be able to communicate at a low level between nodes, and still ensure synchronization with the location of each tracked item and the latest state of treatment moving between the geographically dispersed nodes of the system. Can take. This system enables business processing to be continuously performed at the local node even when communication from the local node to the rest of the system is impossible. Once the disconnected node is reconnected, the system collects unreported data and ensures that the disconnected node collects it and communicates it to the rest of the system, disconnecting changes received by other nodes. Make sure that you communicate to the nodes you want. In addition, traffic and item history storage costs are reduced by reporting only the movement of the top item in the item hierarchy.

  This system can receive data from billions of smart items in real time, and does not need to expand processing capacity in large quantities to collect and filter it. Smart items need not be confined to a single factory or warehouse. The system can collect data from many geographically dispersed locations. The system does not need to support a hardware specific interface for any possible type of smart item. The system can be easily expanded to accommodate new communication channels and new hardware interfaces. Business rules can adapt the system to new configurations and situations, and the software engine does not need to be reprogrammed.

The system can be used to implement adaptive real-time inventory management. Instead of receiving periodic reports of inventory changes collected, the system can allow inventory changes to be reported in real time and without human intervention. Instead of a replenishment plan that only takes place according to a fixed schedule, the timing of the replenishment plan can be made adaptive and increased or decreased in frequency according to the reported real-time inventory level.
The system can conceal the redundant part of the UID to save memory or bandwidth during communication. The system can receive a set of UIDs read from different types of items and determine which type of item is identified by a particular UID. From this determination, the system can filter out the UID associated with a certain item type and provide only the set of UIDs for that type of filtered item to the recipient.

The system can provide selective access to tracking information. The system can provide the convenience that the same tracking information can be sent to all consumers, and at the same time, the access level to the information can be varied according to the consumer's permission level. That is, the system encodes the tracking information, but a given consumer can only be provided with a means for decoding a portion of the tracking information.
The encoding system can perform not only access control but also efficient transmission of information. The system can replace the descriptive text inside the tracking information with coded text that is shorter than the descriptive text. When storing tracking information in a tag, this can increase the information that can be stored in the tag. When tracking information is communicated over the network, this reduces the amount of bandwidth consumed by the information.

The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will be apparent from the description, drawings, and claims.
It should be noted that like reference numbers and designations in the various drawings indicate like elements.

Best Mode for Carrying Out the Invention

Table of contents 1. System overview 2. Embodiment of the present system 2.1 Scenario for inter-company shipment 2.2 Bidirectional data flow Alternative Embodiments of the Invention 3.1 Software Upgrade 3.2 Inter-company Visibility
3.3 Data communication and coherence between world models 3.4 Identification by item in international transactions 3.5 Item scenario 3.6 Information retrieval scenario 4. Data transfer between item tracking system and tag reader 4.1 Event router 4.2 Integration engine 5. Tracking information compression, filtering, and encoding

1. System Overview The system according to the present invention receives information about items and situations affecting the items in a public, non-proprietary form. As used herein, the term “item” has a very broad meaning. This includes the meaning of the term “item” as used in the previously cited patent applications. For compatibility with ERP (Enterprise Resource Planning), SCM (Supply Chain Management) and Strategic Logistics System, the notion of items is items such as bill of materials, freight exchange, packing list, pick list, etc. When it is seen, it shall include everything normally implied. Thus, this includes any physical object that could be produced, shipped, sold to consumers, and so on. It can also include any material that may be referenced in company accounting or other business systems such as shipping.

  A tagged item is an item with a self-identifying tag. A tag can be associated with a single item (in the sense described above) or with a group of items. Thus, to name just a few examples, a tagged item can be any of the following: Containers, trucks or trailers, such as individual items such as soap bottles, supplies such as tagged laptops, possibly cases containing collections of various types of items, or cargo beds containing many cases, Airplanes, ships, and wagons.

  In consumer products and other areas, items may not be equipped with any type of item specific tag. For example, a tagged case may contain 48 bottles of soap, each having a bar code with the same UPC (Uniform Product Code) or SKU (Stock Keeping Unit) or other product number; Each can be sold separately to the customer. The tracking system can correlate shipments tracked at the tag level with point-of-sale information management receipts that individually track items at a fixed price. Bar codes usually carry only an item type or SKU, not a UID (unique system identifier). The system can make some assumptions that associate bar code data with tag data. If inventory is carried out at the case level by a tag in a supermarket or a retail store, periodic inventory using a tag reader can be utilized. Once the case disappears from inventory, the system assumes that its contents can be placed on a display shelf and sold in any order. Without identifying individual items, there is no way to maintain the accuracy of the tracking system after opening the tagged case.

  Generally, the tag is an RFID (Radio Frequency Identifier) tag, but need not be based on RF technology. For example, the tag can be implemented to read by optical, magnetic, magneto-optical, or other techniques, or by or without physical contact between the tag and the reader. In addition, the tag can be passive (does not incorporate internal power supplies for communication and data transmission) or active, and may or may not have processing capabilities. In this specification, it is assumed that a tag is a digitally identifiable tag. This means that the tag has the property that a unique digital identity (ID) can be read directly from the tag using some kind of reader. Certain digitally identifiable tags can also be written, which is particularly useful when information needs to be made available without relying on a communications network.

  In this specification, the term “virtual item” is used to mean data corresponding to an item and used as this item representation. Similarly, the term “virtual circumstance” is used to mean data that corresponds to and is used to represent tangible and intangible objects, including, for example, relationships and events. A virtual item or virtual situation can be realized as an object in the sense of the term object-oriented program. However, this can be achieved by any other convenient method, for example, by a record in a database.

In general, virtual conditions are created and maintained because they represent something that has the potential to affect the item represented by the virtual item, which can be collectively referred to as a situation. An example of a situation is a geospatial event, such as a hurricane that may hinder the navigation of a transport ship carrying a tracked item, a worker who may interfere with the removal of the item from the transport ship It can include strikes and traffic accidents that can delay the delivery of items.
The term hierarchy means an association or relationship between an item and a situation. For example, in the case of a single can in a can platform, an event that affects the platform will also affect this can. A virtual situation can represent a hierarchy.

  The system receives information from various sources. The information source can be coupled to the system through a network such as the Internet or directly. The system can be configured to receive information from an information source through a proprietary or private interface, in which case the format of the information is converted to be compatible with the system. The system includes data input devices such as tag readers, sensors, and scanners. Through such devices, the system can continuously track and record the state of goods and the situations represented by physical objects and context objects. The status of a product can include its status, attributes, and location.

2. One Embodiment of the System As shown in FIG. 1, the item tracking system (ITS) according to the present invention comprises a tag component (“TC”) 102, an object interface component (“OIC”) 104, a communication middleware component ( “CMC”) 106, context-aware intelligence component (“CAIC”) 108, and human interface component (“HIC”) 110. In an alternative embodiment, the HIC 110 is integrated with other components. Each of these components can be implemented as a computer program that runs on one or more computers and controls devices that perform data acquisition, output, and transmission functions. FIG. 1 also illustrates communication flows between components of the ITS and between the system and external application 112, the external market 114, and other external ITS. This communication flow can be realized by any method as long as it is a convenient public format, such as through the exchange of XML documents.

  The aforementioned components consist of a distributed, real-time, and event-based architecture. Each component or all components, or any combination of system components, can be realized at the micro to macro level. A micro-level implementation is an implementation on a single device, and a macro-level implementation is an implementation on a number of devices, such as a network of computers. It is. Each component can be distributed across a number of devices, including computers, interconnected by a network. Each component is constituted by a number of different applications, that is, realized, and these perform the function of the component together. The component architecture described above allows the system to aggregate and adjust functionality from the local level to the global level, while using a non-proprietary standard interface to implement hardware and Ensure that the software can be easily integrated.

  Components can include software systems and associated devices. A software system includes any software, application, or computer program product. For example, a software system can be an application and server that operate at the enterprise level. Communication between software systems can be performed through a communication network. The component exposes a generic open interface for services accessible over the network, such as those based on public standards, such as XML over HTTP. These components are further described below.

Tag components Items installed in the system should be attached to any of the available item level tagging technologies, eg active and passive radio frequency identifier (“RFID”) tags, bar codes, and singles. A unique identifier is attached to each tag that can be used.
When the system first recognizes an item or situation, it is said to have been introduced into the system and a corresponding object (ie, virtual item or situation) is created. The system assigns a specific dynamic n-dimensional context and attribute space to the introduced object. For example, the system can assign owner, price, lot number, and temperature to the installed object. Optionally, the system attaches certain rules to the introduced object. For example, the system can attach a rule that specifies that action z should occur if the temperature of the corresponding item adds to level y.

The specific embodiment of the TC 102 publishes and specifies which tagging technology can be used in the system and how it is used. The TC 102 includes a distributed knowledge system based on Internet technology. That is, the TC 102 generally specifies a globally unique identifier and how to apply it, a catalog that describes the specifications of the corresponding tag, its reader / writer hardware, and any aspect of those specifications, Specific standards and regulations that apply to tagging, standardized communication and context data formats and interfaces, read and write process specifications, processing and transmission requirements for active tags, and telemetry data specifications, best Includes and provides industry practices, ie knowledge about selection and deployment of tags and tag content, security and authorization requirements and standards, benchmarks, implementation guidelines, and frequently asked questions.
In addition, TC102 allows manufacturers, system integrators, and customers to identify, validate, and implement optimal item-tag-reader / writer combinations and standards for specific situations. Tools, content, software deployment kits, and applications can also be provided. The TC can be constructed in any software development environment so as to satisfy the aforementioned requirements.

The object interface component OIC 104 converts data from attached hardware to the system and vice versa. The OIC 104 can also execute all necessary internal processing.
OIC 104 is a sophisticated, general-purpose, bidirectional smart software interface between the system and the real world. Here, objects are introduced into the system, their status and telemetry data are received, filtered, transformed, preprocessed and processed as necessary. Depending on the current context or status data, the object can be implemented to attach a rule that can trigger an alarm event or cause an action, so the OIC 104 can embed a rule engine, Or it can be implemented in conjunction with it to process these types of rules. By customizing the OIC 104, the customer can be sure that when one of the customer's tag readers first detects an item tag that the system can map to a unique system identifier ("UID"), the OIC 104 You can specify what to do. Such actions can include communication with external applications, eg, ERP (Enterprise Resource Planning) applications.

  The OIC 104 also comprehensively communicates with the system how tag interface hardware, eg, RFID readers, bar code scanners, polymer tag readers, and scanners, and their operating software. Is specified, and the validity is judged. As a result, the OIC 104 is a general-purpose software that surrounds all tag-specific read / write devices that perform standardized integration, data validation, filtering and transformation, bi-directional event-based safety communication, and data pre-processing. -Acts as a wrapper (generic software wrapper).

Not only can the OIC 104 receive data, it can also send data to the hardware and software attached to the system, and ultimately to the tagged item itself, so the system uses the OIC to send data such as If they are sent to items and are configured to be remotely controllable, they can be controlled from a remote location.
The OIC 104 can enforce and enforce sophisticated security schemes for all inbound and outbound communications, such as those based on digital certificates. The OIC 104 can be constructed with any software development environment that satisfies the above requirements.

Communication middleware components When components communicate, they send and receive standardized events, which can be sent and received over the network. CMC 106 determines and forwards the validity of standardized events between OIC 104 and CAIC 108 (discussed below) and typically between any of the system components. The CMC 106 can also determine and transfer the validity of standardized events between any of the system components and other applications, devices and components.
The CMC 106 performs functions such as data and authentication validation, storage and retrieval, storage, data decryption / encryption, and event multicasting. The CMC 106 can apply and enforce sophisticated security schemes for all inbound and outbound communications, such as those based on digital certificates. The CMC 106 can be constructed by any software development environment that satisfies the above requirements.

Context Aware Intelligence Component CAIC 108 includes logic that provides the system with intelligence, and for what, where, and how the tagged item represented by the introduced object is at a specific point in time Receive, process, and respond to inquiries about whether they existed, existed, or would exist, with respect to each other or to the real-world features. The CAIC 108 provides public internal and external interfaces that plug in additional mechanisms such as applications and rules and extend its generic service set.

As previously mentioned, the system can include a virtual situation that represents an event that could potentially affect the item. Examples of such events include hurricanes, hot spots or areas, and traffic jams. The virtual status can also describe the attributes of the item. Examples of attributes include geospatial path, speed, and destination. Sensor telemetry readings can also be introduced as a virtual situation.
The CAIC 108 includes a database that allows the system to store and retrieve the current state of installed objects and the history of state changes for these objects. This database can process geospatial data and can be distributed across multiple computers and multiple sites.
The CAIC 108 can apply and enforce sophisticated security schemes for all inbound and outbound communications, such as those based on digital certificates. The CAIC 108 can be constructed with any software development environment that satisfies the above requirements.

Human Interface Component HIC 110 comprehensively integrates a number of technologies suitable for human access and control of the system. These techniques include, for example, all kinds of data visualization techniques, including voice control, stylus control, and multi-mode human interface based on HTML or XML. The HIC 110 separates the application and infrastructure layers from the presentation and human interaction (interactive processing) layers.
The HIC 110 can apply and enforce sophisticated security schemes for all inbound and outbound communications, such as those based on digital certificates. The HIC 110 can be constructed by any software development environment that satisfies the above requirements.

Introducing objects into the system In operation, objects (e.g., virtual items and virtual situations) can be introduced into the system using standardized parameterized events. These events include at least the system UID. In addition, certain attributes, methods, and rules are also attached to the installed object (eg, current temperature, current owner, manufacturer, temperature exceptions, alarms, rules, data access, and authorization specifications) specifications)).

Unique identifier The system maps every installed object to a system UID. This identifier must be globally unique in order for the system to be able to tune from the local level to the global level and to integrate successfully with other systems. If the object indicator has a tag with a globally unique identifier, the identifier can be used as a UID. However, the identifier is not necessarily used. One such unique identifier is the electronic product code (ePC) of the MIT (Massachusetts Institute of Technology) AutoID Center. FIG. 2A shows the format of ePC.

The system divides the UID to improve search performance.
One way to attach unique tags to items is to attach RFID chips to them. These electronic chips hold at least one relatively unique identifier, which can be read by a specific reader device. More sophisticated chips also have dynamic data storage capabilities with external read / write capabilities, and smart chips include built-in processing power. One advantage of RFID technology is that a large number of items can be identified automatically from a distance without disassembling or unpacking them. Alternatively, the system can tag virtual items with identifiers that can be mapped to system UIDs using other techniques such as item level bar codes, magnetic tape, and polymer tags. .

Events The system can communicate internally and externally using events. The following presents an example of an XML document representing such an event. Any convenient form can be used to represent an event.
<event>
<type> SEEN_OBJECT </ type>
<parameters>
<sender>
<UID> xx.xxxxxxx.xxxxxx.xxxxxxxxx </ UID>
<type> RFID_READER </ type>
</ sender>
<telemetry>
<UID> xx.xxxxxxx.xxxxxx.xxxxxxxxy </ UID>
<temperature>
<unit> C </ unit>
<value> 45.43 </ value>
</ temperature>
</ telemetry>
</ parameters>
</ event>

Time, Space, Unique Identifier, Context, Hierarchy The system maps every introduced object to a system-wide standardized dimension of time, space (3-D), unique identifier (UID), and context. . The system saves the input data along with the system-wide synchronization time stamp. Space refers to anything from a point (pure position) to a complex three-dimensional polyhedron in three-dimensional space (eg, representing the position, size, and shape of an item). The context can be n-dimensional (eg, representing attributes such as temperature, speed, and weight).
Each dimension is measured in standard units throughout the system, for example, units based on international standards, such as Coordinated International Time (“UTC”), and International Unit System (“SI”).

Since time and space are invariant dimensions, the system's core space is compatible with all other systems, such as GIS, that operate in these dimensions or a subset thereof. Introduced objects can be part of a dynamic hierarchy. Hierarchies can be described by virtual situations.
Based on internal or external event data, the system tracks and records the state of items represented by objects introduced in the aforementioned space. An alert can then be issued as follows regarding the answers to the queries, the status of the introduced objects in the space, and the relationships between them.

-Where was the item (UID) on December 12, 2001?
Where are all items of type x (UID) within radius y from address z?
-Which of my supplies will be damaged by tropical storms x?
• Where is the closest spare part of asset x and when can it be delivered to factory y as early as possible?
-Where are all the delivery products of lot number x currently located?
-Where is the closest request for my product x that will expire in y days?
·warning! The storage of chemicals x and y is too close to each other.
·warning! Employee x is not authorized to take laptop y out of building z.
Based on historical data, statistics, or other methods, the system can also obtain future status or behavior of the introduced objects or their population.

Direct or derived location data There are various ways to describe the location of an item in the system. An example of a direct description is a collection of longitude, latitude, and altitude data organized in a standard way.
An example of the description of the derived position data is the address of the facility where the tag reader is arranged. The system maps the tag reader's address to the system's standard coordinate system, assumes that the item found by the tag reader (represented by its UID) is in the vicinity of the tag reader, and Associate the position with the item's position.

Object Level Data Access Permission Model The object model includes definitions of UIDs, attributes, and which system users have read / written / modified which attribute, method, and rule authority. be able to. The system assigns a globally unique identifier to each of its users. This identifier can be based on an electronic product (electronic product) code (ePC), an EPC manager portion of the ePC, or the like.
Depending on the assigned permissions and using standardized parameterized events, the system user writes, reads and modifies the data of the installed object. Access to object data depends on the defined permission settings. The following presents an example of an XML document that represents a virtual item that implements the described authorization model. However, this is only an example, and any convenient expression can be used.

<virtual_item>
<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> 2300000 </ value>
<read_authorization>
<OUID> xxxxxxx </ OUID>
<OUID> yyyyyyy </ OUID>
<OUID> zzzzzzz </ OUID>
</ read_authorization>
<write_authorization>
<OUID> xxxxxxx </ OUID>
</ write_authorization>
<change_authorization>
<OUID> xxxxxxx </ OUID>
</ change_authorization>
</ price>
</ virtual_item>

Communication Security Scheme This system uses general authentication and security schemes (such as those based on digital authentication and encryption) for communication with and between components, and for communication to other systems and external devices. Contains.

2.1 Inter-enterprise shipping scenario We will now describe a scene where the system tracks and records the location and temperature of high quality fish products that shipper Y is transporting from manufacturer X to retail store Z .
Below, how this system performs the function demonstrated previously is demonstrated roughly. Manufacturer X packs the product and attaches an RFID tag to each box. The RFID tag includes a UID and can additionally store an expiration date, a maximum temperature threshold, and a maximum encounter temperature reading (T _max ). Manufacturer X loads the boxes onto the carrier and attaches an active reusable temperature sensor device to each carrier. Alternatively, such a sensor can be attached to each box, although the expense increases. These devices are fitted with an RFID tag that contains a UID and in addition can store temperature readings and maximum encounter temperature readings (T _max ). These devices periodically measure current temperatures and store readings in RFID tags attached to them. An alarm occurs when the temperature exceeds a certain threshold. Upon arrival at the retail store, updated expiration dates and maximum encounter temperature data based on the sensor device's temperature history record are written to the RFID tag of each box.

  Manufacturer X wants to reduce the number of boxes (rejections) rejected by retailer Z that shipper Y must be responsible for, eg, boxes exposed to high temperatures during transport. Shipper Y wants to increase customer satisfaction and gain market share by ensuring full visibility of current location and temperature during shipment. In addition, the shipper wants to detect quality problems and theft that occurs due to the contractor. Retail store Z wants to reduce costs by identifying and rejecting damaged products upon arrival, thus reducing returns and at the same time increasing customer satisfaction.

  The following describes in detail how the system helps each party to achieve its goals. FIG. 3 shows that manufacturer X, shipper Y, and retail store Z procured the object interface components (OIC) 34x, 34y, 34z of the system behind their respective firewalls 33x, 33y, 33z. One embodiment for realizing individual installation is shown. In addition, they have jointly worked with external application service provider tag components (TC) 32, communication middleware components (CMC) 36, context-aware intelligence components (CAIC) 37, and human interface components ( HIC) 38 is used. External application service providers provide these services through a network such as the Internet. Alternatively, each party can subscribe to one embodiment of the system provided by the service provider. In this latter case, each party need not procure and install an OIC. In yet another alternative, one or more of the parties may install and use all five components of the system. In this case, the parties do not need to subscribe to the service provider and their CMCs can communicate by sending events over a network such as the Internet.

  Based on specifications, standards, best industry practices, and other information obtained from TCs, Manufacturer X can read-write RFID tags and interrogators (eg, active or passive) that meet the product and scene requirements described above. Procurement type RFID tag, frequency, reader range, built-in temperature sensor, memory size, price point, case material, and bonding needs. Based on specifications, standards, best industry practices, and other information obtained from the TC, Shipper Y and Retailer Z each have a number of RFID interrogators that are compatible with Manufacturer X's RFID tags and systems. (Reading is possible only).

  When manufacturer X procures a box of products, manufacturer X attaches one RFID tag and introduces the system with its unique identifier, acceptable temperature range, and initial expiration date. FIG. 4 shows this introduction operation. A box is manufactured and a tag is attached (step 20). The manufacturer's OIC connection tag reader detects the tag and reads its UID (step 21). The OIC generates a SEEN event including the UID and sends it to the CMC (step 22). The CMC forwards it to the CAIC (step 23). If the object for the UID is known, the CAIC updates the object status and status history log according to the input data (“Yes” branch of step 24, step 28). Otherwise, the CAIC determines whether the event is a NEW (new) virtual item event (decision step 25). If the event is a NEW object event, the CAIC creates a new virtual item in the UID according to the specified data (step 26), and stores the NEW virtual item data (step 27). Otherwise, the following operations are performed. The CAIC sends an OBJECT UNKNOWN event for the UID to the CMC (step 46). The CMC forwards this event to the manufacturer's production system (step 45), which generates an INTRODUCE virtual item event in the UID with attributes, access rights, rules, and alerts and alerts. The event is sent to the CMC (step 44). The CMC forwards this event to the OIC (step 43), and the OIC generates a NEW virtual item event for the UID and sends it to the CMC (step 42). The OIC also determines whether there is a request to write data to the tag (step 41). If so, the OIC writes data to the tag (step 40). In this illustration, the data is a “good until date”, temperature threshold, and maximum encounter temperature reading (step 40). In either case, the NEW virtual item event is forwarded by the CMC to the CAIC (step 23) and handled as described above.

  As shown in FIG. 5, when manufacturer X loads the carrier for delivery, manufacturer X attaches an active temperature sensor to the carrier, resets the sensor's memory, and activates it (step 50). ). The sensor measures the temperature at each scheduled time (step 52) and saves the measured temperature along with the time stamp in the history log on the tag (step 54). If the temperature exceeds the maximum encounter value, this new maximum value is also stored in the tag (step 56).

  FIG. 6 shows the response of the system to loading a box (step 60) on a load carrier with sensors. The manufacturer's OIC connection tag reader detects the tag and its UID (step 62), generates a SEEN event for the UID, and sends it to the CMC (step 64). The CMC forwards these events to the CAIC (step 66). The CAIC updates the status and status history log of the virtual item identified by the detected UID according to the input data from the event (step 68).

When the shipper Y's OIC reader detects the tag, the CAIC updates the system. FIG. 7 shows this update operation. The shipper's OIC connection tag reader detects the tag of the box on the carrier including the sensor tag and reads its UID and _Tmax data (step 70). The OIC generates a SEEN event with these data and sends it to the CMC (step 71). The CMC forwards the event to the CAIC (step 72). The CAIC updates the status and history log of the corresponding virtual item according to the received input data (step 73). The CAIC determines whether T _max is within the limit (step 74). If not, the CAIC sends an alarm event to the CMC (“no” branch from step 74, step 75), which forwards the alarm to the manufacturer and shipper ERP application (step 76).

  Upon receipt of the shipment, retail store Z determines the actual maximum temperature data of the product from the attached RFID tag and the validity of the expiration date. FIG. 9 also shows this reading operation.

If damaged boxes are detected, they are identified and the CAIC alerts the store manager using the HIC component. SMS (Short Message Service) messages, pager messages, or any other convenient form of message transmission can be used for this purpose. FIG. 8 also illustrates this alarm action, where the retail store's OIC connection tag reader detects the UID of the tag on the box on the carrier, including the sensor tag carrying the UID, maximum temperature T _max and temperature history T _history. Read (step 80). The OIC generates a CMCSEEN event using the UID, T _max and T _history information, and sends it to the CMC (step 81). The CMC forwards the event to the CAIC (step 82). The CAIC updates the status and history log of the virtual item according to the input data. The CAIC also calculates a new expiration date for each box based on the T _max and T _history information and the manufacturer's rules (step 84). If the CAIC determines that the box is damaged ("Yes" branch from decision step 85), the CAIC sends an alarm event to the CMC with a UID and _Tmax (step 86), and the CMC forwards the alarm to the HIC. (Step 87). The HIC then sends an SMS message and alerts the store owner of the retail store (step 88). Regardless of whether the box is damaged, the OIC determines whether there is a request to write data to the tag (step 89), and if so, the CAIC uses the UID and data about the tag to A WRITE DATA event is generated and sent to the CMC (step 90). The CMC forwards these events to the OIC (step 91), and the OIC writes the “best before (valid) expiration” and T _max data to the tag (step 92).

  The system can receive context information, such as traffic and weather information, from a third party provider. In general, introducing information into the system can be done by having the provider push the information in, or by having the system pull in the information. Having such information allows the system to report or predict shipping delays or other situations that may affect the movement or conditions of the introduced items. FIG. 9 shows that this is achieved by the provider introducing information into the system. In this illustration, the traffic information provider generates an INTRODUCE virtual situation event using the UID and attributes and sends this event to the CMC (step 120), which forwards the event to the OIC (step 122). The received OIC uses the UID and CMC to generate a NEW virtual status event in the CMC (step 124), and the CMC forwards this event to the CAIC (step 126). The CAIC determines that this event is a NEW virtual situation event type (“Yes” branch of decision step 128), generates a new virtual situation for the UID according to the specified data, and creates a new virtual situation. The situation data is stored (step 132).

2.2 Bidirectional data flow The system can provide a data flow and a bidirectional data flow on the tag. FIG. 10 shows a scene. A tag 152 is attached to the box 150. This tag contains a UID and can additionally store an expiration date, maximum temperature threshold, maximum encounter temperature reading, and price. The temperature data on the tag 152 may be used to measure the temperature of the box 150, for example, at a temperature measurement station (station) where the reading can be written to the tag 152, or by a temperature sensor operably coupled to the tag 152. It can be updated each time.

  Data on the tag 152 can be automatically read by the tag reader 158 using, for example, RFID technology. In one embodiment, the tag reader 158 periodically “scans” its surrounding environment within a specified range. In another embodiment, the tag reader 158 is activated to scan its surrounding environment, for example by a proximity sensor. For example, if the scan returns valid reading data (via communication 154) because the tag 152 has moved into the scanning area, the tag reader 158 sends the received data to the system 166 (communication). 162). In this example, it is assumed that the system 166 maintains a virtual item 168 that was previously introduced (by communication 172) by the external application 174, and the external application 174 also defined the rule 170 and was attached to the virtual item 168. To do. Rule 170 is defined as "If the maximum encounter temperature of the box stored in the tag is higher than 45 degrees Fahrenheit, write the day as a new expiration date on the tag." Rule 170 may be defined in any format, syntax, or computer code that is compatible with system 166. Whenever system 166 receives new data read from tag 152, rule 170 is executed. If rule 170 returns a positive result, system 166 calculates a new expiration date, such as the current day, and sends the new expiration date and UID of tag 152 to tag writer 160 (via communication 164). The tag writer 160 is caused to write new expiration date data in the expiration date data field of the tag 152 (by communication 156).

FIG. 11 shows another scenario where the external application 174 periodically queries the system 166 for the latest state of the highest encounter temperature of the box 150 stored in the tag 152. In this scene, the logic that can be identified as the rule 171 again is part of the external application 174. The external application 174 sends an event containing the UID of the tag 152, the new expiration date, the updated price, and the updated regulatory information to the system 166. This event causes the system 166 to send the received expiration date, price, and UID to the tag writer 160 (via communication 164). The system 166 then causes the tag writer 160 to write the received data to the corresponding data field of the tag 152. Such communication can occur over any communication medium, including over a network, eg, the Internet.
In these situations, a tag reader that can read the data stored in the tag 152 allows the recipient of the box 150 to specify an expiration date and price based on the temperature to which the box 150 was exposed during tracking. can do.

  FIG. 12 illustrates one aspect of the data flow process. In the illustrated example, the system receives attribute information including a UID for a first item by reading a first tag coupled to the first item (step 1202). The system also receives attribute information about the second item and context information obtained from data automatically read from the sensor coupled to the second item (step 1204). The system uses this information to hold the virtual first and second items. The system also receives relationship information specifying the relationship between these items, and maintains a virtual relationship (step 1208). Having this information, the system can recognize an alarm condition for the first item based at least in part on one of the virtual items (step 1210). In response to the alarm condition, the system generates updated attribute information and writes it to the first item (step 1212). The system then detects the presence of the first tag at the tag writer station (step 1214) and causes the tag writer station to write the updated information to the first tag (step 1216).

In these situations, alarm conditions can be recognized, and the system itself can execute rules that respond to alarms and calculate update information, or this can be done in an application outside the system. In the latter case, the application receives information from the system from the object held by the system, generates update attribute information, and supplies it to the system with a request to write it to the first tag.
FIG. 13 illustrates another aspect of the data flow process. In the example shown, the system receives attribute information for a first item obtained from tag data automatically read by a first tag reader from a first tag coupled to the first item (step 1302). The system also receives update attribute information for the first item (step 1304). Later, the system detects the presence of the first tag at a different tag writer station (step 1306) and causes the tag writer station to write update information to the first tag (step 1308). In this situation, the update information can be calculated inside the system itself, or it can be done in an application outside the system. In the latter case, the application receives information from the object held by the system from the system, generates updated attribute information, and supplies it to the system along with a request to write it to the tag.

3. Alternative Embodiments of the System As shown in FIG. 14, the system according to the present invention can be implemented using a shared ITS (item tracking system) and multiple local ITSs, most often personal ITSs. The system need not have an explicit upper level shared node. Some embodiments of the system are federations of corporations and there may be no hierarchy above the companies. In another embodiment, there may be a number of top shared nodes above the company level, each possibly corresponding to a specific industry sector. In general, the structure will vary due to various considerations, including agreement within the supporting industry.

In FIG. 14, the existing ERP (symbolic resource planning) system 1401 can be any local enterprise software used to manage the movement and storage of products. The ERP system for each company (or part of a company) may be different.
Each company has a number of tag readers 1402 and supplies digital information from digitally identifiable tags to the local ITS. In general, a tag reader is any combination of hardware and software capable of supplying digital data collected from any item or container. The reader can be installed on the production line, in storage locations, in shipping and receiving areas, in loading docks, trucks or other mobile vehicles, and can be a handheld wireless connection device. Some implementations optionally have hardware and software to intervene between the actual physical reader and the ITS.

  In FIG. 14, each local ITS 1403 is a hardware and software system that can be implemented on one or more computer systems. The system is typically geographically close to the rest of the enterprise, but may be physically located anywhere that can be connected to the local ERP system and tag reader accordingly. Typically, an ITS provides services to a single company or part of that company. Thus, if there are more than one local ITS, each can be operated by a different company. ITS also applies to other existing enterprise software systems, such as those used for supply chain management, business planning, customer relationship management, and new software services enabled by the type of data obtained from ITS. Can be connected.

Shared ITS 1404 is an item tracking system shared by multiple local ITSs. This generally connects to a number of local ITS systems and can also connect to a number of other supplying ITS systems. Shared ITS can also be connected to other new and existing enterprise software systems.
Local and shared ITS communicate through a network connection 1405 that can be any of the inter-computer communication techniques. In general, between businesses, communications are encrypted for security, and digital security certificates or other security means are used to authenticate those involved in the communications. The communication medium may include the public internet. This connection typically passes real-time or near real-time messages that represent the disposition of tagged items and other information that represents shipping documents, transport vehicles, and the like.

Each individual site 1406 is a collection of hardware and software necessary to support internal processing at each individual site. The site can be a manufacturer, distributor, retail store, private home, repair shop, or any other location or part of a location that handles tagged items.
New and existing applications 1407 are existing enterprise software systems, such as those used for supply chain management, business planning, customer relationship management, and new software services enabled by the types of data obtained from ITS. It is. Through the network connection 1408, these applications can query the ITS regarding the current status and past history of items being tracked by the ITS and other information. These queries do not change the state recorded in the ITS system, so there is some loss of usability, but instead of processing the query against the raw data in ITS, it is permanent. It can be handled by processing the log of the ITS status held in the storage (storage medium).

  FIG. 15 illustrates the basic software components within the item tracking infrastructure. Real-time input processing software 1501 accepts disposition and other messages from tag readers, existing ERP systems, and other ITS systems. These messages can be in XML or other formats. The message may represent the creation of physical or logical items, or a change in the treatment or status of these items. This part of the software interprets the incoming message, references the data storage element 1502, takes appropriate action based on the message content and stored data, updates the data structure as specified, possibly an error message or Send other reports back to the message source.

  Data structure and persistent storage 1502 records and maintains representations of logical, physical item relationships, status and history tracked by ITS. For example, the software can record that a unique tag corresponds to a particular detergent bottle. The detergent can be physically housed in a box (another unique tag and item known within the ITS) that may be on the track (another unique tag and item within the ITS). The position of the track itself can be periodically updated in response to real time messages from the real time input processing software 1501 and the action of the software. The data structure can also record that the detergent is part of a shipment (logical item with a UID). Data structures and persistent storage preserve data structures even if there is a hardware or software failure. Any robust method of building persistent storage can be used. For example, information can be recorded in a nonvolatile manner using software database technology or a magnetic disk drive.

  The query software interface 1503 provides an interface between the ITS and the external enterprise software application. For example, if a traditional ERP (Enterprise Resource Planning) or SCM (Supply Chain Management) system needs an update on the current actual location of an item, it sends a query. The ITS persistent storage can provide the information needed for processing, and the querying interface can use this information to “identify by specific product type (currently identified by product code) within a given geographic region. ) Can be processed. Alternatively, a query such as “Report all milk cartons that have been on the shelf for less than 48 hours” can be processed.

3.1 Software Upgrade The core 310 of the ITS infrastructure (shown in FIG. 16) must operate continuously 365 days a year, 24 hours a day. When significant economic activity depends on certain parts of the system, it is not practical to bring the system down for maintenance or system upgrades. However, the system needs to be upgraded in various ways. The architecture described below addresses this need.
Consider three types of software upgrades. Ie, adding or deleting fields (ie, properties), adding or changing code (ie, computer program instructions) for semantic notification of field contents, and major system upgrades. is there.

  Manufacturers, distributors, retailers, and others must add or remove data fields from individual items (items) or representations of items for the convenience of individual operations. It may not be possible. For example, it may be desirable to add a field that indicates the temperature at which the item was processed. This information may be important, for example, for long-term reliability and product return studies. This processing temperature field contains different information than the existing temperature field, such as the current temperature and the highest temperature detected during transportation or storage of the device. Similarly, this may be handled differently. For example, a manufacturer desires to store process temperature values for long periods of time for reliability studies, but would not want to reveal it to other manufacturers or perhaps any other organization.

Other examples of adding or deleting data fields include the following cases. A retailer wants to record items that have been purchased and then returned. Regulations have changed and a law has required that this type of product be timed to sell. The field is filled in by the manufacturer and the distributor and retailer take action accordingly.
In another example, the distributor is responsible for providing a return fare for items returned to the manufacturer by the consumer. Distributors should add a field called “Return Freight Payer” to automatically fill in the distributor's name so that the legally responsible party will be charged when the item is returned. Want. Such distributor information may or may not be obtained from the history. However, the additional field reveals who will pay this fee without querying the history.

In general, the system can dynamically add new data fields (ie, properties) to any existing object. In addition, object records are accepted by either the upper or lower hierarchical system without changing the program and without having to change previous or future objects of the same type.
Deletion may be desirable for data fields that only make sense when the object is in a state. For example, a field associated with a shipping list or packing list is only valid when the object represents an item that is part of the current shipment. Once the shipment is formally received, the shipment information field is deleted from the active data structure (but kept in history). Alternatively, if invalid fields are not deleted, they are marked invalid.

The system can be upgraded by adding or changing code that implements semantic behavior. In general, it is desirable to continually add new capabilities to the system and review old functionality. These changes include many decisions such as where to add new capabilities, who will program, how to check, and how to minimize the impact on other activities Cost.
Examples of situations that require the addition or change of semantic behavior (senmantic behavior) include the following cases. New members joined the consortium and needed new functionality to handle that type of product. Existing functionality has changed. For example, the method of handling the due date setting has changed, or better procedures have been developed for loading trucks.

Adding functionality to any element of the infrastructure requires the addition of new data fields.
The change in semantic behavior has the potential to crash the entire system. It is therefore essential to inspect and introduce new code that changes semantic behavior with careful control. In general, the semantic processing of a particular item type and a particular item can be changed without stopping the operating system. Furthermore, it guarantees at a high level that the behavior for other objects does not change.
Major system upgrades are possible, including upgrades that change all software, disk format upgrades, and hardware upgrades. In general, the system can transparently switch the operation of the central system from one hardware / software configuration to the other without any loss of service visibility. This procedure will be rare.
For system reliability reasons, you can run the shadow system. Such systems also have a major system upgrade mechanism.

As shown in FIG. 16, active data storage is decoupled from all semantic methods. Core 610 comprises a small set of basic functionality but otherwise is independent of any object identification process. As a result, the core 1610 does not need to change when adding new data fields or new semantic processing. Such cores are very common and can be optimized for their basic functionality and very high reliability. It is rare that the programming of the core 1610 changes.
Since other parts of the system communicate via inter-process communication or document exchange, the core 1610 can continue to operate even if other components 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 previous events (assuming idempotency) or by using what is obtained from persistent storage to reproduce the current state. . As discussed below, changes that have not been delivered to persistent storage 1620 must be re-executed.
A small set of functions that efficiently address all the various system requirements is described below.

As shown in FIG. 16, the stateless real time semantics 1630 performs the following operations. (1) Accept a treatment message from the network. The action message always specifies at least one item. (2) Search for an object (a plurality of objects) corresponding to the designated item. In general, locking can be avoided. (3) An appropriate semantic processing method is selected using information from the object. (4) Search for any other necessary objects and lock them if necessary. (5) Calculate the updated object record. (6) The change is transferred to the core 1610, and all object records are unlocked.
The real time semantics 1630 is completely stateless. Therefore, it is possible to stop at any part, restart, and continue the operation at any time. This makes it easy to dynamically load a new semantic method using, for example, the Java® mechanism and restore from any failure.

  There are several ways to select a method to apply to incoming treatment messages. The appropriate code depends on both the type or class of object and the indicated action. For example, although the loading of a transport vehicle is probably very similar for most objects, the “sale to end user” procedure can be highly dependent on the type of item. At least two alternative embodiments are possible. (1) Based on the explicit product type field used in the ePC proposed by the MIT Auto-ID center. (2) Check the specified object, and possibly its route type object, to obtain the item type identifier.

  The second technique does not depend on the development of the ePC numbering system and works with any tag system. Furthermore, its level of indirection allows a wide class of objects to be processed with the same software. For example, all detergent products from one manufacturer may be treated with the same code, while another manufacturer may have a different code. Finally, the core 1610 can be configured to flag individual items and trigger different codes. This allows live inspection of new code limited to a small set of objects. To achieve high performance, this code should be multi-threaded. This allows the object (and possibly any root object referenced by that object) to be captured before issuing the semantic code.

The core 1610 has the advantage that it can be implemented without persistence. To gain flexibility and speed, the core 1610 can be a computer memory subsystem. Alternatively, core 1610 can be mapped directly to persistent storage mechanism 1620.
The persistent storage mechanism 1620 is a module that takes a stream of object change notifications from the core 1610 and commits them to the persistent storage. From the stored information, a current snapshot of the system state can be quickly created.

The history mechanism 1640 is provided as follows. The system has two activity sources. That is, typically a treatment (deposition) message representing a beep or signal from an individual item, and a query for stored object movement data by an external system. The object move beep updates the core 1610. Because these represent changes to the state of the entire universe of items, they do not require access to previous history. External queries are involved in travel history and current actions, but do not need to change state.
The system can accumulate history and also has an up-to-date view of the current state, so it can be optimized for large non-real time search intensive queries. it can. Since this is essentially read-only, it can be easily duplicated to accommodate large queries.

The history mechanism also requires persistent storage. Thus, the history mechanism is typically incorporated within the persistent storage mechanism 1620.
Core 1610 has the least functionality set. It can create and extend objects
(A) Create an object
(B) A function for adding or deleting property name-value pairs is included.
All object names are unique and the size is arbitrary. Names are taken from an extensible name list to prevent surges and avoid the creation of conflicting names with inconsistent meanings.

The core 1610 can access and change property values. That is,
(A) Return all properties (name-value pairs)
(B) updating property name-value pairs;
be able to.
Core 1610 has specialized (built-in) property list 1710 functionality, such as named collection ownership and membership,
(A) Includes the ability to create a new formal-name set object owner (root), and (b) the ability to add and delete members of a named set.
Finally, the core 1610 is very rarely used but has an object locking feature,
(A) includes the ability to lock the object-provided signature; and (b) the ability to unlock the object-provided matching signature.

  This very small set of core 1610 functionality makes little use for searching for tags, readers, or items in the real world. This is a major advantage. The data structure is sufficiently general that it does not need to change depending on the meaning of the items that pass through the supply chain and other applications. The core 1610 software is highly optimized to perform a small set of operations, while semantic changes are addressed in stateless semantic methods. Of course, as the data structure grows, more rules are incorporated into it, and some semantic changes require the current object structure to be rebuilt. However, this can be done live on the system and does not involve software modification of the core 1610.

The following shows a simplified example of how these structures can be used.
# 1147: {objectedID: # 1147} {obj_Type: Base_EPC_Type} {Software_Version: 2}
{Class :? Detergent ”} {PML :? http: .....”}
{EPC_Type_Collection_Root: # 341, # 576 .........}

# 341: {ObjectID: # 341} {ObjType: EPC_Object_Instance}
{EPC_Type_Collection_Member: # 1147} {Container_Collection_Member: # 3328}

# 576: {ObjectID: # 576} {ObjType: EPC_Object_Instance}
{EPC_Type_Collection_Member: # 1147} {Container_Collection_Member: # 3328}

# 621: {ObjectID: # 621} {ObjType: EPC_Object_Instance}
{EPC_Type_Collection_Member: # 1147} {Container_Collection_Member: # 3348}

# 2287: {ObjectID: # 2287} {ObjectType: ERP_Shipment}
{Shipment_Collection_Root: # 3328 .........}
{Shipment_Enterprise_Member: # 3347}
{Shipment_System_Source: “R / 3_4.6”}

# 3328: {ObjectID: # 3328} {ObjType: Container}
{Container_Description: “14 x 18 x 10 Cardboard Box”}
{Immediate_Location_Type: Follow_higher_level_container}
{Container_Collection_Root: # 341, # 576}
{Shipment_Collection_Member: # 2287}
{Container_ollection_Member: # 4421}

# 4421: {ObjectID: # 4421} {ObjType: Container}
{Container_Description :? 10,0001b Truck ”}
{Immediate_Location_Type: GPS Long-Lat-Alt}
{Container_Collection_Root: # 3328}
{Latitude: 32N} {Longitude: 60.45} {Altitude: 327M} {Location_Last_Update:
1/12/2002 14:27}

# 3348: {ObjectID: # 3348} {ObjType: Container}

{Container_Description :? Warehouse Shelf ”}
{Immediate_Location_Type: Fixed Storage Location}
{Storage_Location_LOcal :? Shelf3 ”
{Container_Collection_Root: # 621 ...}
{Container_Collection_Member: # 4462}

# 4462: {ObjectID: # 4462} {ObjType: Container}
{Container_Description :? Warehouse Region ”}
{Immediate_Location_Type: Fixed Storage Location}
{Storage_Location_Local :? Regio 16 ”
{Container_Collection_Root: # 3348 ...}
{Container_Collection_Member: # 4481 ...}

# 4481: {ObjectID: # 4481} {ObjType: Container}
{Container_Description :? Warehouse ”}
{Immediate_Location_Type: Top Level Fixed Location with Lat / Long / Alt}
{Container_Collection_Root: # 4462 ...}
{Latitude: 31N} {Longitude: 60.45} {Altitude: 100M}

The above table describes a fairly complex situation and is also shown in FIGS.
As shown in this table, # 1147 means the product class “detergent”. Specific detergent bottles are represented by object instances # 341, # 576, and # 621.
As shown in FIG. 18, two of these detergent bottles 1810 are in a cardboard box 1820. The box is on track 1830, which has a GPS geodetic system to report location in real time. A box is part of a particular shipment. There is a third detergent bottle 1940 that is stored on a shelf 1960 in the area 1970 of the warehouse 1950.

Aggregation mechanisms provide significant power to data structures. For example,
Given the object ID of the basic type of detergent EPC (# 1147), we query the set and get all instances of the detergent and its current location.
Given a warehouse object ID, all items in the warehouse and their storage locations can be obtained.
Given the object ID of any instance of the detergent, the corresponding shipping number can be obtained if it exists.
Given the object ID of the shipment, all items and their locations can be obtained.
Given a track's object ID, all items in the track and their associated shipping documents can be obtained.

Data recovery Data recovery is an important issue. FIG. 20 shows the latency in the system from when a beep is detected in the leaves of the network 2010 until the implication of that beep is recorded in the persistent storage 2020. Assuming a catastrophic failure at the shared (central) site 2030, restoration begins with the information currently on the disk and implies taking into account all changes that have not yet been processed.
One restoration technique is to record a certain amount of history within the network infrastructure itself 2060. For example, an issue-subscribe distribution mechanism can be constructed to have reliable internal persistent data storage. Another approach is to have persistent storage at each leaf node of the network.

The total storage required 2040 is equal to the total system-wide latency from the tag reader to the system persistent storage.
In general, it is not easy to make sure which events have been affected and what has been lost. Furthermore, there is no inherent order in the processing of events through the real time semantic part 1630 and the core 1610. If enough events are played back to make up for the largest possible loss, it works well if all the processing is idempotent and unrelated to the order. When this condition is met, the invoked action 2060 means that the ultimate system state is the same if the events are processed in a different order, or if the same event is processed more than once. .

Location Updates Some high value items and transport vehicles such as trucks can be tagged with a real time location system (RTLS) that performs periodic location updates. For example, the WhereTag tag provided by WhereNet Corporation of Santa Clara, California, broadcasts its identifier to the local area in the 2.4 GHz band and determines the location by triangulation. These tags can only be changed by broadcasting at regular intervals from seconds to minutes and physically accessing the tags.
In addition, wide area systems can be updated periodically using GPS (Global Positioning Satellite) receivers in conjunction with conventional communication systems, such as cell phones or low bandwidth satellite uplink systems. It can be performed. The base station may poll the communication system to confirm the current location, or may be called at a programmable interval from a remote location.

  The basic function of the tracking system is to receive location information reports. While it is convenient to have a single location reporting method, using latitude and longitude inside a narrow area such as a building or warehouse can be risky with many unnecessary extra calculation steps and therefore generally The reference local frame is used. Suitable for use in a wide area is latitude, longitude, and altitude data obtained from a GPS system.

Batch Identification In general, an item tracking system provides more information than a simple beep when an item is detected by a reader. Such information may be a planned action when the read items are approaching in batches. For example, “The following items are taken from stock and boxed for shipment x”. At any location, the system is provided with information regarding this shipment.
Such information can be directly connected to a system application (eg, an application using a web browser) and indirectly from a terminal close to the tag reader or from a local system that can send an appropriate message to the tracking system. Can be obtained.

Items often arrive in bulk, so the beep can be cached internally until the end of the batch is recorded. The reader or local system then sends a message to the tracking system that contains information about all items in the batch.
Each batch can be given a unique ID. A batch number (batch ID) is one way to concisely communicate common information about a group of items. Each reader can have a default batch ID, which is used if no batch ID is specified. When using a batch ID, the message from the reader can be in the following format:

Time stamp, batch ID (eg 96-bit ePC), item ID
Use of such batches can support a sort function that is used when items are not grouped before being read. For example, an assembly line may have a series of items and a series of bins. The reader reads the tag on each item and determines, for example, whether to put the item in bins 1, 2 or 3. Each bin may indicate a different treatment, for example. The reader associates a different batch ID with each bin and associates each item with the batch ID of the bin into which it is placed.

Batch-designated primitives can include readers with unique IDs and shipments with unique IDs as well. Associate the reader with the shipment to generate a specific batch with a unique ID. Multiple batches can be associated with the same shipment, even from the same or different leaders. Primitives required for shipment may include a unique ID, a local shipment number (eg, a number used within a local ERP), a product destination, a target delivery date, and a target delivery time.
By associating each item with a batch rather than a reader, information can be repeated securely and without confusion. For example, if a treatment message is sent again, for example due to a system failure and restart, the state of the system will not change if a batch-item pair is used instead of a leader-item pair.

Treatment Action A treatment action describes a state change for a hierarchy of objects and items related to or associated with a tagged item. The action actions include, for example, creating an item, i.e., initial introduction to item tracking, location change, inventory check, shipping, loading, unloading, and termination of tracking.
The action action “Create Item” records the initial properties of the item, such as manufacturer, type, date of production and location. This action may also include initializing the tag with some given data. This generally includes an indication of the initial storage location of the item.

The treatment action “change location” indicates that the item has been moved to a new given location or has already been moved. “Inventory check” indicates that the item is recorded as detected at the storage location.
The action action “shipping” indicates that the item is designated as part of a shipment. The local ERP system may be given a known shipping number.
The action “load” indicates that an item is detected while loading a certain transport vehicle. A truck or other transportation ID may be connected to a shipping ID.
The action “unload” indicates that an item is detected during the unloading of a vehicle. What is necessary is just to connect vehicle ID to shipping ID.
A treatment action “reversal” is an action that effectively cancels any previous treatment for the same item and the same batch. This is often required to reverse the previous procedure. For example, reversal may occur when there are too many items loaded. This action is not an act.
The action action “end tracking” indicates that the item is not expected to be seen again by the tracking system. This action can be performed, for example, in a retail store sale or when opening a package of items and reusing the case. The system can store item data for later warranty or historical purposes.
There are many other possible treatments. Flexible designation of treatment is preferred.

Shipments Ships typically identify a packing list in the form of an item-type quality list. Shipments also dictate the planned movement of these item types to their destination. A destination can be a customer with an address or another location of the same company. The tracking system determines the location, eg, latitude and longitude, from the address or receives this information as part of the shipping description.
Shipping is known to local ERP systems. The tracking system retrieves shipping information, matches a particular item with a generic item type in the shipping list, and reports a discrepancy.
Can be associated with a specific transport vehicle. For example, several different shipments, some going to the same address and some going to different addresses can be loaded on the same truck. The system can verify that the truck is loaded correctly. The system can also track or estimate the position of the track and respond to inquiries regarding the position of the item.
In practice, a particular logical shipment may span several transport vehicles. In this situation, the system tracks physical shipments rather than logical shipments.
The system shows how to identify and communicate with a transport vehicle. Thus, the system can respond to a question such as "Please tell me the driver's name and mobile phone number because my meat shipment heading to San Francisco is contaminated."

Transport Route “Transport Route” information is information about the predicted geographic route of a transport vehicle such as a ship or truck. This can be a series of waypoints, such as city or highway intersections, individual highway or road names, longitude and latitude, and the like. The transport route may be given explicitly. For example, this may be input manually. Alternatively, this may be calculated or inferred. This will be described below. Transport routes apply directly to transport vehicles, but only indirectly to specific shipments.

Action message An action message was that an item was detected at a specified time and was part of a batch intended for a particular action, such as moving to another storage location, shipping to a customer, etc. Indicates. The action message can be in the following format:
Time stamp, batch ID, item ID
This concise message links the item, reader, and shipping number known to the local ERP system together. Sending the same treatment message repeatedly provides the very advantageous property of not changing the state of the tracking system.
Tag memory The purpose and functionality of the system described is only for tracking tagged items. However, in certain applications, when a tag is detected, it may be necessary to write data to the item tag at some stage. This system can write and read such tag data at any site.

  The system can provide large-scale event reports. For example, the system can report to other applications when certain serious events occur. This can, for example, send a message when the shipment arrives at the customer, thereby causing an invoice to be issued.

3.2 Inter-enterprise visibility This system enables inter-enterprise visibility of items in the supply chain. The system can receive, store and create visible treatment information for items such as the location of the items as they move within a single company or between multiple companies. In addition, the system can receive, store and create visual correlation information relating items to customer orders, shipping documents, and other business processes. The system can receive correlation or treatment information from any participant or company in the supply chain and can create information that can be viewed by other participants or companies in the supply chain.
As shown in FIG. 26, the system can track items and access very extensive tracking information. For example, the infrastructure can track items arranged in many different settings, including factories, warehouses, retail outlets, and homes throughout the country or around the world.

Visibility Control In one embodiment, the system can control visibility. In other words, only a subset of item tracking information is visible to a particular participant in the supply chain. As shown in FIG. 28, the system can receive permission information that specifies permission settings for various attributes of the item. The system uses this permission information to determine which attributes are visible to which companies. For example, the authorization model shown in FIG. 28 specifies that the destination attribute of an item is visible to the shipper but not visible to the manufacturer. Visibility control will be discussed in more detail below in the heading “Controlling Access to Tracking Information”.

World Model Structure FIG. 27 shows a World Model (WM) structure supplied by many companies. The world model is a structure that records and maintains relationship representations, states, and history of items tracked by the ITS. The world model can be realized as a two-row structure. That is, the parent WM 2710 in the upper row tracks items that are inside a particular company, and the local WM 2720 in the lower row tracks items that are located at a physical location within the particular company. The local WM can be accommodated within the local ITS 1403 (shown in FIG. 4), and the parent WM can be accommodated within the shared ITS 1404. Through the network connection unit 1405, the parent WM of one company can communicate with the parent WM of another company or the parent WM of another department or column in the company.

FIG. 27 shows a federation or peer company structure where each company shares information directly with other companies. The system can also accommodate other types of configurations. For example, FIG. 29 shows a hierarchy, or consortium configuration, where each company's parent WM 2920 provides information to the central WM 2190. Alternatively, federation and hierarchy configurations can be combined. For example, one of the parent WMs 2710 in the federated model may also represent the central WM 2910 of the consortium of parent WM 2920.
In FIG. 27, each company is shown as having a single parent WM 2710. However, in some cases, for example, the parent WM 2710 can be realized as a cluster of the parent WM group 3010 as shown in FIG. 30 for the purpose of scalability. Each parent WM 3010 can correspond to a different set of product classes in the enterprise. Each parent WM 3010 also maintains connectivity to local WM 2710, other parent WM 2170 at other companies, and higher-level business applications such as ERP systems.

3.3 Data Communication and Coherence Between World Models The following sections describe systems and methods for communicating data through multiple nodes in a distributed architecture, such as the federated architecture shown in FIG.
The method provides bi-directional communication between the local WM 2720 and the parent WM 2710. The parent WM 2710 can report changes to the tracked item (e.g., recall of contaminated meat or price changes) to other WMs. Conversely, the local WM 2720 can report item treatment changes (eg, item creation, movement, or termination) to the parent WM 2710.

For each item, at least one parent WM 2710 is designated as the responsible WM for that item. Any information regarding items received by any local WM 2710 in the entire federation is reported to the responsible WM. In this way, the responsible WM maintains a complete history of items. Data restoration can be improved by duplicating the responsible WM. For example, the second WM 2710 can also be designated as the responsible WM for the item, and any information received regarding this item is sent to both responsible WMs.
Other non-responsible WMs that hold information about the item can freely clean up and remove the information once they have reported the “business critical” changes to the responsible WM. Thus, any local WM 2720 can be restarted from an empty WM. However, changes that were not reported before the reboot are lost unless these changes were saved to internal storage before the reboot.

Data Transfer to Responsible WM The local WM 2710 receives multiple instances of tag read data, each instance containing information read from a tag that is bound to the item detected at the local node. Multiple instances of tag lead data may collectively include information read from tags associated with multiple items in the shipment of the item. Shipments in the supply chain often contain one or more levels of items contained within the shipment (eg, a shipment may contain a loading platform that contains a case containing individual items). . Thus, in some cases, the local WM 2720 receives both the data read from the shipping tag and the data read from the tag for the items contained within the shipment (eg, loading platform, case, and individual items). Can do.

For each item, the local WM 2720 reports the tag read data to the responsible WM for that item. To determine the responsible WM for an item, the local WM 2720 can look up a mapping table that maintains the association between the item and the designated responsible node. The mapping table can be queried using all or any part of the UID of the item.
Each item in the shipment can be mapped to a designated responsible WM. Items belonging to different product classes can be mapped to different designated WMs. For each item, the designated responsible WM can be the same across all nodes, or can change from node to node. In other words, each node maintains its own mapping table, and the association in each mapping table can be different for each node.

  For example, an operational rule can determine that all business critical items within a single company are reported to the parent WM of that company. The parent WM can be a single WM or a cluster. Once the movement is reported to the parent WM, the parent WM can be configured to report the movement of one item to another WM outside the enterprise. For example, if a retail store reports the movement of an item to a manufacturer, a more efficient supply chain can be operated. Accordingly, when a tool at the retail store level is sold, the local WM can determine that the responsible WM is a parent WM within the same company. However, in the parent WM node, the parent WM can determine that the WM in charge of the same tool is a parent WM of a different company. In one example, the remote WM can correspond to the manufacturer of that particular tool. In another example, the remote WM may represent a combination of tasks such as all manufacturers of tools.

  In some cases, one node can be configured to act as a forwarding and shipping agent for another node. For example, a manufacturer can specify a single externally accessible node for all updates from outside the enterprise. Once a change is received at this node, the node can examine its own responsible WM mapping table and distribute updates according to product class. This can spread the computation and data storage load so that it is not visible outside the enterprise.

  The following section describes one embodiment of a protocol for exchanging state information between WMs. This embodiment uses state exchange messages to exchange state data between WMs. The message parameters include the item's UID, the current state of the item, and the time stamp when the state last changed. The recipient of the state exchange responds with an acknowledgment message indicating the current known state and time stamp. The state change message is sent again until an acknowledgment is received.

Item (Item) Creation When an item is first created at the physical site of the manufacturer (Company A), the local WM (World Model WM_AL1) at the physical site receives the “Create Item” action action. WM_AL1 then creates a logical representation, eg, an object representation of the item, and specifies that this object is in an “active, dirty” state.
The state of an object can be specified using a combination of flags, including “active”, “deferred”, “pending”, or “dirty” flags. “Active” means that the object is the latest version of the object. “Deferred” means that some other world model has a unique active version. “Pending” is a temporary designation used while the system captures the correct designation. “Dirty” means that the status has changed since it was last reported to the responsible WM and is important to the business.

WM_AL1 then reports the creation of the item to the responsible WM (WM_AP). This report can take the form of a state exchange message.
The WM_AP creates a local object and designates “deferred”. The WM_AP then places this object in the WhereUsed list of WM_AL1. The WhereUsed list is a mapping that tracks which objects are located in which local WM.
The WM_AP then sends a state change and acknowledgment message to WM_AL1. This state change and approval message may also include information that the parent wants to be associated with the newly created item. Upon receiving the approval, WM_AL1 deletes the designation of “dirty” from the object.

Subsequent business critical changes Once an item has been created, subsequent business critical changes are also reported to the responsible WM. WM_AL1 changes the state of the object to “active, dirty”, sends a state exchange message to the responsible WM (WM_AP), and clears the “dirty” flag when receiving an acknowledgment from WM_AP that the change has been recorded.

Moving out of the site When WM_AL1 detects an item at the exit gate of the site, WM_AL1 reports this to the responsible WM as a business critical event. WM_AL1 sets the object state to “deferred, dirty” and sends a state change message to WM_AP. The WM_AP updates the local object to “deferred” and sends an approval to WM_AL1. When WM_AL1 receives the approval, it clears the dirty flag.

Collection and communication destination information In some cases, the destination of an item may be known. The destination can be another site within the same company, or the destination can be another company. For example, a business document related to an item may include destination information. The business document information is acquired by communication with a conventional enterprise software system such as ERP (Enterprise Planning System). For example, business information associates a specific shipment represented by a hierarchy of item tags with a shipment and order number understood by conventional systems. The organization, site, and shipping address are all associated with a unique UID in the same manner as the UID assigned to the physical item. The target WM receiving the advance notice of shipment can be explicitly specified in one field of the shipment record, or calculated using the same mechanism used to find the responsible WM for the physical item. May be preferred.
For example, when a responsible WM transfer and update mechanism is used, a shipping layer advance notice can be transmitted as follows. A shipping destination record can be created with a UID that is expected to be the WM that the responsible WM expects to receive this shipment. Once this shipment is physically assembled and the specific item tag for this shipment is known, this tag hierarchy can be recorded as a change to the collection destination record. Any changes to this record can be automatically communicated to the responsible WM set as the actual target destination WM. Once the physical shipment arrives at the WM, it has all the tag information and can fully verify the exact shipment.
In other cases, the destination of the product may not be known within the system. This may be the result of poor integration with the ERP system. The entire system can handle both cases.

Move to another site within the same company (site AL2)
If the destination is known, the WM_AP places the object in the WM_AL2 WhereUsed list and sends a state exchange message to the WM_AL2. When the item arrives at site AL2, WM_AL2 changes the state of the object to “active, dirty” and sends a state exchange message to WM_AP. The WM_AP modifies the local object and responds with a status exchange and acknowledgment message.
In some cases, the destination is not known in advance. When the item arrives at the destination site AL2, WM_AL2 creates a local object in "pending, dirty" state and sends a state exchange message to WM_AP. The WM_AP updates its local object, moves the local object to the “WhereUsed” list of WM_AL2, and responds with a status exchange and approval message to MW_AL1.

Move to another company (site BL1)
If the destination is known, the WM_AP sends a state exchange message to the parent WM of the destination site (WM_BP). WM_BP creates a “deferred” object and places it in the WhereUsed list of WM_BL1. The WM_BP responds with a status exchange and acknowledgment message to the WM_AP and also sends a status exchange message to the WM_BL1. WM_BL1 creates a “deferred” object and puts it in the incoming list. WM_BL1 responds with a status exchange and acknowledgment message to WM_BP.
When the item arrives at site BL1, WM_BL1 changes the state of the object to “active, dirty” and sends a state exchange message to WM_BP. The WM_BP updates the local object and responds with a status exchange and acknowledgment message. The WM_BP then sets the dirty flag and sends a state exchange to the responsible WP, ie WM_AP. The WM_AP updates its local object and WhereUsed list and responds with a status exchange and acknowledgment message to the WM_BP.

  If the destination is not known in advance and the item arrives at BL1, WM_BL1 creates a “pending, active, dirty” flag and sends a status exchange message to WM_BP. WM_BP creates a “pending, active, dirty” object, puts it in the WhereUsed list of WM_BL1, and responds with a status exchange and approval message to WM_BL1. The WM_BP then sends a state exchange to the responsible WM, ie WM_AP. The WM_AP updates its local object and WhereUsed list and responds with a status exchange and approval message to the WM_BP.

Reducing data traffic between WMs In an alternative embodiment, every item in a shipment or item hierarchy need not be reported to the responsible WM, such as between a specific local WM and a specific responsible WM. Two WMs can be configured. Which items are reported can vary between different WM pairs.
Information defining the item hierarchy can be provided to both the local WM and the responsible WM. For each item detected at the local node, the local WM can verify each item against the provided hierarchy information. However, when reporting to the responsible WM, the local WM can report only items at a certain level (eg, top level) in the hierarchy, with the additional indication that all items below this hierarchy have also been verified.

Reliability under Message Loss or Duplex Transmission A “pending” or “dirty” state is reliably converted to an “active” or “deferred” state. This is because the state exchange message is automatically retried until an acknowledgment is received. In some cases, for example, a dual transmission can occur after the WM reboots from persistent storage. Since state exchange messages carry time stamps, they only affect them if the deferred entity is older than the incoming update.
The clock can be synchronized across the network using conventional mechanisms such as NTP (Network Time Protocol) or GPS clock. However, the system can operate without a high degree of clock synchronization.

System cold restart The system can be built with an empty local WM. A “pending” object is created whenever an item is later detected. Once all items are viewed, the WM is complete.

Periodic Cleanup The local WM can periodically request updates of “pending” or “dirty” objects, or objects that have not been updated for a period of time. Objects that have not been referenced for some time can be evicted into free memory. The responsible WM can drive, that is, move, objects that are not referenced for a certain period of time to long-term storage.

3.4 Identification by Item in International Transactions In the following scene, please refer to FIG. 54 for the tagging and tracking system and method technology for the needs of the government customs department when dealing with import related information. While explaining. The application described below is based on a core network-like information environment for an item tracking system (ITS), which is referred to as an ITS core. ITS Core provides the following functionality to support this application of handling information related to imports of goods across national borders.

Receive and hold information from the tag reader system that identifies individual items read by the reader and generally provides contextual information such as the intended action for the item.
Receive and retain information specifying physical relationships between items. This includes changes in relationships, including the fact that one item is in or on the other. (For example, the bin is in the box, the box is on the carrier, the carrier is placed in the container, and the container is placed on the ship).
-By receiving and maintaining property information about items in an extensible format, applications using the core can add new types of information about the items held by the core without requiring any reprogramming of the core. Lets you add information.
Provide such information in a universally accessible format, such as the format of a self-describing XML (Extensible Markup Language) document, across company boundaries.

The ITS core provides, receives and holds information specifying the logical relationship between items, more generally logical and physical items. For example, ITS
(A) Export supplier factory,
(B) recipient addressee,
(C) responsible import agent (d) a list of specific products to import with a unique tag identifier, and (e) a unique reference to specific tariff rules for each type of item,
Receive information about planned shipments that specify
Logical items (a, b, c, e) are treated as physical items and have specific entries in ITS. ITS uses incoming information to build and maintain logical relationships between physical and logical items. This allows, for example, any reading of a physical item tag in a shipment by a customs officer at the port of entry to be immediately related to the corresponding shipping document and the customs rules related to the request. Similarly, any reference to any of the importers immediately leads to a list of items in the shipment (or shipments). The logical item structure includes relationships with cargo beds, containers, vehicles, and other packaging units, storage, or transportation. The position of the ship can be updated periodically, so that actual knowledge about the position of the goods planned to enter a port is obtained. Thus, when a ship enters the port, the customs department can know the exact goods and their transportation and storage history without having to look at paper documents. This information can be used to plan the appropriate personnel, target the alleged importer, and otherwise support customs operations.
ITS keeps a full history of item movement as reported by tag readers and other sources. This information can be used by customs agencies for their own research and statistical purposes. This information is also very valuable to importers, shippers, and others who need to track the current location and treatment of their shipments.

In the embodiment described below, the ePC contains a unique item identifier and item class as an extension of EAN (European Product Number) or UPC (Uniform Product Code) information, while a PML (Physical Markup Language) document Used to contain the physical description of the item.
The ITS Core is a public, highly scalable, real-time material tracking infrastructure that collects and integrates real-time material information from the networked item-unique tag infrastructure, Distribute to enterprise applications. This infrastructure is built with suitable tag readers, which are connected to one or more ITS systems through a network. Thus, the movement of these tagged items can be tracked from the central location in real time each time the item is reported by the tag reader. Network-like tags form a two-way communication path between a company and uniquely identified tangible and intangible items called smart items and a group of custodians who hold and manage them. If some of the tags are smart, smart items can be obtained. Smart items and machines contain and communicate any information that end users write on tags.

  In addition to writing commercial information, such as ePC, PML, size, weight, price, warranty, history, etc. to the tag, the tag has product level rules and regulations, tax and fee information, updated trading contract rules , Preferential handling instructions, customs tables for more than one country, import restrictions for more than one country, storage instructions, hazardous material management information, and customs services are required to expedite shipments and achieve modernization objectives It can also accommodate any other information.

  The ITS has information about location, status, customs processing status, and other information about the processing of all tagged items throughout the system. This information can be obtained directly from ITS or through existing and new applications that collect data from ITS. Since the ITS core is open, general purpose, and independent of applications, the ITS core has a huge number of events expected to be handled by the customs department, exceeding 20,000,000 events per second in the United States alone. Processing can be performed without placing a burden on the core enterprise software system, such as conventional supply chain management and business planning systems. While ITS tracks large numbers of individual items and shipping units, traditional supply chain management systems are usually only involved in tracking both items. For example, ITS can track 20,000 individual cameras, and traditional supply chain management systems consider this as a single entry.

The ITS core and applications described here provide some important functionality.
• Communication specific to the detailed item type from the customs department to the original manufacturer and importer difference.
• Safe, certified and detailed (loading platform and item level, serial number specific) communications regarding items and shipping plans from the original manufacturer to the customs department.
・ Automated paperless product tracking from origin to import port and beyond.
• Tags on each loading platform or item tie a pre-reported shipping plan directly to a physical import without the need to examine paper documents.
-When widely implemented, networked instances of systems using the ITS core will be handled in the world trading system where many of the products are located, the intended import port, and the tariffs negotiated and planned for these specific items Can be shown in real-time images.

Customs systems using ITS Core include domestic trade and customs agencies and PGAs (important government agencies), importers and exporters, trade promoters, foreign GPAs, shipping and business planning services, retail stores and For manufacturers, it can function as a networked real-time material data repository.
Since the ITS core is an application-agnostic open network system, its data can be used by any enterprise application environment just like a database, and can be seamlessly integrated into it. . Multi-dimensional real-time material data can be managed by any application, such as supply chain management, customer and supplier relationship management, product lifecycle management, financial management, human resource management, security and business intelligence. Can be used for various treatments and for analysis. Real-time material data is multidimensional because it can have many components. For example, ITS tracks the time the item was moved, the relative position of the item in the container, the location of the container, eg logical status such as “Checked and Approved”, responsible shipper, intended destination, etc. can do.

  One or more instances of the ITS core and supporting applications function on mainframe, client-server, and distributed network environments, both as local personal networks and global collaborative networks, similar to the Internet used today. Can be deployed. End users include desktop enterprise portals within personal networks, the Internet, direct encrypted telephone connections, personal digital assistants (PDAs), and voice-over-telephone connections via mobile devices and telephones. ITS data can be accessed through multiple contact points.

FIG. 54 shows the stage of automated ITS information flow in a scene involving the import of goods into the United States and the use of ITS information by the US Customs Department and other government agencies and operations. The aforementioned organizations and operations are collectively referred to as companies here.
In FIG. 54, a company or group of companies is represented by a rectangle, each of those local ITS resources is represented by an associated ellipse, and the flow of information is represented by numbered arrows, The numbers in the figure correspond to the heading numbers in the description of each stage below. Each company's local ITS resources can be one or more instances of the ITS core and supporting applications, which together constitute a local ITS network. The illustration of single and multiple networks is merely for the sake of simplicity. The scene corresponding to FIG. 54 proceeds as follows.

5401
A retail store / end user places an order with an international manufacturer or supplier and specifies the classification, number, amount, contract terms, etc. of the product.
5402
Manufacturers produce products according to retailer / end user specifications, assign and write ePC and PML documents (PMLs) to each product's item-unique tags, and provide this information to ITS To do. (Alternatively, other information other than PML and ePC can be recorded only in the ITS data storage unit if the tag does not have the necessary storage capacity.)
The manufacturer writes relevant commercial data such as price, warranty, production cost, product classification, weight, size, manufacturer, shipping conditions and instructions on each product tag and prepares the item ID for shipping . All of this information is always provided to the ITS so that any application that can use this information can see it. Tag storage is done for customs officials and other persons with hand-held readers who do not have convenient access to the network connection to the ITS site.
The manufacturer seals the shipment, confirms that the shipment is tagged, the information on the tag is the same as the item being shipped, and sends the data to the central and joint US Customs Department ITS network. Upload to. At the same time, the manufacturer sends the ordering information to the wide area shipping and business planning service for collection and transfer. Finally, the manufacturer informs the retailer of the shipping status in real time.

5403
US Customs automatically sends updated fees, special handling and storage instructions, import rules and regulations, and other relevant regulatory information to PGA, wide area shipping and business planning services.
5404
Wide-area shipping / business planning services include US customs regulations and tax information, ITS, and tags on shipping boxes, loading platforms, transport cases, etc. that are relevant to the product being shipped, to the extent that the tags correspond. Automatically with the appropriate shipping hierarchy. The global shipping / work planning service then aggregates and classifies shipments by ePC and US and foreign tariff designations and regulations. Products and shipments are grouped and divided into appropriate tiers and assigned to cargo beds, boxes, carrying cases, and delivery vehicles (trucks, ships, airplanes, cars, etc.).
Shipping information is sent to the appropriate local / foreign GPAs and customs. This information generally includes vehicle identification information, import / regulation information, weight, potential hazards, manufacturer, ePC, volume, etc. Data is assigned to the item / box / carrying case to be shipped. Shipment ID information should be uploaded to the GPS (Global Geodetic Satellite) of the delivery vehicle and the customs smart pass (similar to the highway car smart pass) that can be used for electronic settlement of the shipment. Can do. If necessary, Global Shipping / Business Planning Services provide real-time location, status, and context information for all ongoing shipments, US and local customs, US brokers, importers and business planning services. , Manufacturers, as well as retail stores. The shipment is then performed and the business planning service uploads the location of the shipment and the estimated arrival time to the foreign customs department and PGA.

5405
The foreign PGA / Customs will provide a real-time advance shipment notice to all approved custodians and confirm and record the shipping timing, location and date of departure with US Customs. In addition, the foreign PGA / Customs will automatically confirm that the shipment meets the latest export requirements by product and shipment classification, industry and shipping location. The relevant PGA and individual custodian are notified of the shipment. The foreign PGA / customs will also confirm that the shipment is in accordance with all current export regulations and requirements and that the appropriate PGA will monitor the shipment as appropriate.
Finally, the foreign PGA / Customs sends shipping storage and handling instructions to the corresponding shipping port and agent.

5406
The foreign customs agency / port confirms that the appropriate agent is notified of the shipment and is available when the shipment is carried out. Foreign and US agents communicate special handling and storage instructions required for specific goods.
5407
The following activities take place at the US Customs Authority / Port. Compliant shipment / business planning service shipments automatically enter the port / border entry location while being automatically scanned by the local non-destructive reading system. The non-destructive tag reader automatically verifies that the received product is identical to the product identified and shipped by the manufacturer according to ePC and PML. Compliance with all regulations and security information written on the original tag is also confirmed. If the shipment is wrong or fraudulent, warnings will be given to local officials to perform manual censorship and take appropriate containment measures. Corresponding officials and PGAs are notified of the shipment and are available when the shipment is executed. The US customs agency / port can also automatically confirm that the shipment complies with all current charges, priority handling, storage requirements, restrictions, regulations, etc. US Customs is notified of incoming shipments and is given real-time shipment information by product classification, price, quantity, industry, etc. required for US Customs statistics. Appropriate and correct charges and taxes are automatically collected and deposited. All relevant shipping information is sent to US brokers and importers. Some tags can relay and confirm the composition of the item to be shipped (eg, a tire contains only tire materials and no drugs or smuggled goods).

5408
The broker / importer automatically confirms that the correct fee has been collected and notifies the local business planning service and US Customs of the status and conditions of the shipment. The broker / importer further confirms that the shipment is correct and matches the retail and manufacturer's shipping requirements.
5409
The local shipping / business planning service informs US Customs of the status and location of the shipment and delivers the shipment to the retailer / end user.

5410
Retailers / end users can log on to US Customs ITS or access another system that can access status information from Customs ITS to identify accurate shipping status, status, and location at any time can do. Finally, the retailer / end user confirms the correct pickup, notifies the manufacturer, performs automatic payments, and ships and tag information for shipping documents from the manufacturer, shipper, and customs. Confirm.
The above scene and system described with reference to FIG. 54 have the following advantages.

1. Transactions and economic growth Real-time and seamless customs processing can be achieved through the use of censorship and inspection using non-destructive tags. Shipment and charge compliance levels can be increased. A real-time automated transaction processing and material tracking network is presented and integrated with risk and security management systems through PGA and personal custodians. Networked public-private collaboration and harmonization and automatic guarantees for fair trade. Automatically manage and enforce international trade contracts. Prevention of predatory trading and unfair trading practices can be greatly improved by item identification and smart tag technology and counterfeit alerts. Accounting and management related to revenue collection is automated through the application and renewal of automatic charges.

2. Border security Passengers can be automatically identified and seized prior to arrival through the use of smart cards or tags embedded in passports, travel tickets, driver's licenses, or other forms of national or international IDs be able to. A non-destructive personal identification system can be developed by a remote tag reader. Know the shipments of dangerous goods, weapons and munitions in advance and in real time. Improve information exchange on exports and imports of private and PGA confidential or controlled products.

3. Narcotics trading Automatic, non-destructive identification of potentially narcotic shipments, through the use of high-risk shipment shipments and product telemetry (condition, temperature, chemical composition, etc.) Can be achieved. Obtain real-time data on identified or likely drug shipments from identified high-risk shippers and countries, thereby improving PGA notification, coordination, and resource allocation be able to. A pre-automatic deployment of the tag for the identified carrier, an improvement of the goal setting technique, and a blocking means can be obtained.

4). Criminal Finance
The non-destructive research infrastructure can track automatic shipping payments and match actual payments with actual shipping fees and terms. It can automatically identify fake or incorrect shipping payments, potential real-time disruptions of criminal fundraising. Several countries, including the European Union, are considering embedding tags in actual banknotes, making it possible to track large cash transfers in real time.

5. Public protection Greatly reduced potentially harmful, dangerous, and / or life-threatening situations caused by unacceptable or illegal items, and their pre-management and real-time tracking can be improved. US embargoes and sanctions against certain industries, organizations and / or foreign countries can be automatically realized in real time. The import of illegal goods and / or counterfeits can be greatly reduced by automatic and real time shipment identification and verification systems. Non-destructive inspection technologies, such as x-ray van, RF and microwave airfield security systems can be expanded and maximized by allowing selection tags to be read. . If the tag information is linked with an image recognition technique based on video detection, multimedia material tracking can be performed.

6). Management Responsibility Agent assignment can be optimized based on anticipated shipment, nature of shipment (hazardous substances, perishables, source, etc.) for correct shipment at the right place when the right agent is right Guarantee that it can be utilized for. Agent and port accountability can be increased by more reliable and prompt information from shipping. Accurate financial data, import statistics, resources and materials for personal and public custodians can be automatically tracked in real time. Annual and interim status and inspection reports can be automatically updated and completed. GAO recommendations can be automatically realized for all PGAs and custodians. Real-time import / export information by UPC, product classification, industry, manufacturer and geography can achieve recognition of real-time border situations.
Real time U.S. balance of payment renewals, U.S. Customs department information for Congress budget office and treasury, full history of inspections, shipments, etc. Can be shared by individuals and public custodians.

  In addition to the advantages described above, the following cost reductions can also be realized. Processing with full or almost complete data accuracy and data entry redundancy and paperless processing for all tag-compliant shipments, reduction of customs personnel required for manual inspection, automatic shipping identification and fee application Significantly improved cycle times, reduced production verification team visits for manufacturers compliant with all tag systems, automatic identification of fraud / counterfeit shipments, IPR (Intellectual Property Rights) for all tagged shipments Improve foreclosure, reduce fee errors, ensure correct fee billing, reduce fees / customs and trade disputes, optimize resources by improving customs information, share automatic shipment confirmation / status information with importers / exporters PGA's real-time harmonization of monetary savings from expeditors, investigations and accusations of all tracked and targeted goods Improved cargo forced inspection by the use of non-destructive testing techniques for shipment conforming to all tags (cargo enforcement examination) a significant increase in the number.

  The customs department can also increase revenue by using such a system as follows. Automated trading compliance, border leakage and smuggling reduction in line with all current shipping contracts and tax revenue collection for all tagged shipments. Improve toll collection, improve existing service quality for higher and / or new service fees, increase injunction of criminal goods, stolen goods and counterfeits, real Enable next-generation services such as time transactions and payment balance information.

3.5 Item Scenario
The following sections describe item scenarios.
The following scenes (scenarios) can occur when creating an item. An item is manufactured and then associated with a specific item ID. As the item moves from production, it enters the tracking system at the first reader. The steps are (1) create a “new item” disposition and properties for all desired items, and (2) create a batch ID binding reader and action. The system senses a series of action messages and processes them to create system data for the new item.
When transferring items to the warehouse, the following scenarios can occur: Prior to the transfer, the warehouse worker indicates to the system the actions planned for the item. If the reader is in a fixed position and there is no ambiguity with respect to the intended position, for example if the reader is on a small storage room door or on a conveyor belt to the storage room, all this information shall be the default. Can do. The step creates (1) a treatment indicating “treatment-position change”. (2) Create a batch ID binding reader and procedure. The system senses a series of treatment messages that indicate a change in position.

  When shipping items, the following scenarios can occur: Typically, a local ERP or business planning system has an entry that tells a list of item types and quantities to be shipped to a customer at a given destination. The customer may be the person himself. The system may have the following identification and verification capabilities: (1) Identify specific items to ship. (2) Verify that all specified item types and quantities are actually shipped. For example, the shipping and packing process is verified against an internal ERP system. (3) Identify all shipments scheduled to be sent to a particular transport vehicle, for example shipments loaded on a particular truck. (4) Verify that all items are actually loaded on the correct transport vehicle.

  During delivery, the system reports the estimated or actual location of the transport vehicle. In more complex situations, it is possible that the goods will be resold and change direction while being transported. The system verifies that the correct item is unloaded at each destination. The system can optionally allow RFID detection of shipments at the destination to act as evidence of delivery and billing. The system can optionally dynamically capture the delivery time of the shipment and update the internal delivery time estimate.

With these primitives, the following steps can be performed when moving from the storage room to shipping. The local ERP system reports planned shipments to the local ITS. The storage clerk uses the system application to select a shipment ID from the list, select a SHIPMENT action type, identify a local reader ID, and generate a unique batch ID. The clerk uses existing procedures to pull items from the warehouse and place them on the leader. The leader sends a series of action messages
Time stamp, batch ID, item ID
To the system in the form

  The attendant instructs the completion of the batch on the system application. The system application can immediately indicate any inconsistencies, such as missing items or extra items. These discrepancies can be corrected in-situ by using a reversal procedure.

With these primitives, the following steps can be performed when moving from shipping to shipping. The shipping clerk uses this system to confirm that a certain shipment (which is already known to the system) is loaded on a transport vehicle (eg, truck). This action associates a leader (in the loading / unloading home for the truck) with the vehicle and indirectly with a collection of shipments. As a result, a batch ID is obtained. The reader is in the system
Time stamp, batch ID, item ID
Send a series of action messages of the form

  The attendant instructs the completion of the batch on the system application. The system application can immediately indicate any inconsistencies, such as missing items or extra items. The system knows the complete set of shipments to be loaded on this truck. These discrepancies can be corrected in-situ by using a reversal procedure. Any query to the system for any particular item indicates that it is on this track and is part of the designated shipping ID that is known to the local ERP system. Thus, if an item falls from a truck, all information from both the system and the local ERP system can be found.

  With these primitives, the following steps can be performed when moving from transport to receipt: The truck enters the unloading home at one of the shipping points. The system associates the shipping address with a known system location for any given shipment. The taker pulls up the system application and is shown a collection of shipments scheduled for delivery by a vendor. Alternatively, the shipping clerk enters the truck ID and is given a list of related shipments. If the tractor section of the tractor-trailer truck changes along the way, the driver can also carry a shipping instruction or tag to clearly identify the shipment (multiple shipments). Finally, the clerk uses the same transport data object used by the original shipping clerk (several shipping clerk). Many sources may load shipments on the same truck.

Even if a large number of shipments are involved, the system application knows exactly which items to unload from the truck. The treatment type is indicated as “load and unload at default position”. As a result, a batch ID is obtained. The leader sends a series of action messages
Timestamp Batch ID Item ID
To the system in the form

The attendant instructs the completion of the batch on the system application. The system can immediately inform whether extra material has been unloaded or whether a portion of the shipment is still on the truck.
Finally, the system knows that the shipment has been delivered and can send a billing message.

Reliability issues All messages are delivered, but they may appear in any order and some may be replayed. The system can also deal with various computer crashes in the system and possible playback of stored messages. For example, each computer in the chain can accumulate a set of messages and record them to disk. When the upstream computer crashes and restarts, it can request playback of previous messages or what appears to be undelivered messages stored internally.

The system can be unaffected by any playback of events. For example, the system may encounter the following situation:
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 merely an iteration and is typically filtered at the lowest possible level, but may be passed to the system.
Next, the operator may find that the movement of item X was incorrect and may enter the reverse.
Timestamp 3: Reverse item X.
Then, some parts of the system may crash and generate the next playback.
Timestamp 2: Read item X and report as part of batch B1.
Perhaps if the reverse is not replayed due to some aspect of how the system crashes, the system
Timestamp 1: Item X is read and reported as part of batch B1.
Timestamp 3: Reverse item X. (Batch B1)
Timestamp 2: Item X is read and reported as part of batch B1.
Will be detected.
However, the correct interpretation is no movement of item X. In order to obtain such an interpretation, the reversal is made sticky. For example, it is useful to accumulate reversals and play after every non-answer event in a given batch.

With an accurate distributed clock (+/− several milliseconds), the system records a time stamp for each treatment with each item that includes a reversal. The system can ignore action messages that are newer than the last message received and produce the correct result with the previously described sequence. However, this method does not always produce correct results.
For example, assume the event and the corresponding time stamp are as follows:
Move Item X Timestamp 1: Item X is read and reported as part of Batch B1.
Item X moves again Timestamp 2: Item X is read and reported as part of batch B2.
The operator considers the movement of item X to be in error Timestamp 3: Reverse item X. (Batch 2)
The system crashes or some other event causes scrambling, and the system
Timestamp 2: Item X is read and reported as part of batch B2.
Timestamp 3: Reverse item X. (Batch B2)
Timestamp 1: Item X is read and reported as part of batch B1.
Detect.

  A simple algorithm of ignoring all but the newer than the last message received for this item means that the system ignores the batch B1 message and the batch B2 message is (correctly) ignored. However, the system considers item X to be in the state prior to batch B1, which is incorrect. A more effective algorithm during system restoration is to sort all messages obtained within the restoration time window by their time stamp and then process all messages in sequence.

3.6 Information retrieval scenarios (scenes)
The system can be implemented to provide a human level query interface, which can be done by a cooperating system or both.
Some of the functionality of the query interface, regardless of the example query and where it is implemented, is as follows.
Where is the basic query for a particular item? It is. For example, where is this particular medicine bottle? This query is easy to implement using conventional query construction techniques at low cost. Such techniques can also provide a query construction mechanism that allows for interactive selection of qualifiers, such as item time, manufacturer, etc., to separate individual items. That is, the user does not need to know the actual item ID, and only needs to inquire the system so as to specify the medicine manufactured on a certain date and shipped to a certain pharmacy.

Where are the specific types of items in other queries? There is. For example, where are all the D-cell batteries in the world? It is. There may be multiple item types (eUPCs) in a D-cell battery, depending on the number of manufacturers, the number of chemical types, packaging, etc. A reasonable interface will allow queries to be built across multiple types.
For other queries, where are the items in a given region? For example, within 100 miles of Seattle, where are all size D batteries? Or where is the item within the given shipping scope? For example, where are all size D batteries within 4 hours from Seattle? It is. Such queries can be addressed by first creating a table of predicted shipment delays from different geographic locations to Seattle. In this complexly defined geography, the system can search for items in the geography table.

Also, where does the system have all items with a given property? It is possible to respond to such queries. For example, where (current date-manufacturing date)> 2 years all chemical bottles are located? Where are all the radial tires made by Firestone between January 1, 2000 and January 1, 2001? How long has the size D battery been in the storage room before being transferred to the retail location? Which dark period of time the D size battery was on the retail store shelf until it was sold? .
The system can be implemented to provide a variety of statistical options, such as mean, standard deviation, variance, minimum and maximum location calculations. Therefore, what is the average shipping time between position X and position Y for this system? It is possible to respond to such queries. For example, how long does it take to ship a product manufactured by Acme to Chicago from Seattle? It can respond to the query.

Implementation Strategy for Advanced Queries The entire system of federated ITS implementations communicating with each other and additional application software, including geospatial applications, uses items collected from simple scans of passive tags and dynamically Can be predicted and answer complex queries. Such a query would require a much more expensive location tracking technique per item, other than the present invention.
In the advanced query example, where are the Duracell batteries that can be shipped to Seattle within 4 hours using normal shipping methods? All roads through Colorado are closed. Which shipments can be affected? Where is the current predicted position of all minced meat shipments? Is included.

Queries related to shipping delays The system keeps track of when shipments are loaded onto a truck, the destination of the shipment, and when the unloading of the shipment at the destination is complete. Thus, the system can record and collect this information for each pair of start and end positions that appear in the system. This accumulation of data allows the system to calculate shipping time statistics, such as average, mode, standard deviation, maximum, minimum, etc. So where are the Duracell batteries that can be shipped to Seattle within 4 hours using normal shipping methods? Queries based on time are also possible.

  There are several ways to respond to the pickup delay query. For example, in the first method, the steps are as follows. (1) Identify all item types that support Duracell batteries. (2) Identify all storage locations for Duracell batteries with available battery inventory within a maximum geographic region (eg, Canada, United States) based on item type. (3) Identify all destinations in the Seattle statistical area that have received Duracell batteries in the past. This operation is a simple geographic search based on Seattle, battery item type, and accumulated history. (4) Based on the list of destinations from step 3, find all average shipping time inputs at these destinations. Pay attention to the departure position for each shipping delay. (5) Find the intersection of the starting position in step 4 with the available inventory location from step 2. (6) Based on the delay, the starting position / destination position / average delay record identified in step 5 is sorted. Select those that meet the criteria of an average delay of 4 hours or less. (7) Step 6 gave an answer to the query. The resulting location can be shown on the map. (8) Other information, such as shipping costs, can also be used to narrow the selection, so for example, the system returns possible sources in ascending order of shipping costs.

This method only considers the starting location that was used to ship to Seattle in the past. The search can also be extended to examine the combination of segments with respect to the history of shipments, in which case the total expected delay of the sum of segments does not exceed a given target within some tolerance.
The method described above can be easily modified to find Seattle's cheapest battery source, regardless of shipping time.

The first method identifies shipping delays and possible commodity sources based on battery shipping history. The second method uses commercially available route planning software and services. These solutions are already accepted and estimate the optimal route and operating (or other transport) time between any two locations in the United States or other countries. Using this technique as a reference, the query can be answered using the following steps: (1) Identify all item types that support Duracell batteries. (2) Identify all storage locations for Duracell batteries with available battery inventory within a maximum geographic region (eg, Canada, United States) based on item type. (3) Using route planning software, create a table of operating hours from each location where the battery is in stock to Seattle. (4) Sort the table and specify the storage location where the operation time from Seattle is within 4 hours.
The second method is possible, but identifies a shipping route that is not frequently used in practice. For example, for tax and other reasons, Duracell may never ship a battery from Canada to the United States. The foregoing method can indicate that Vancouver is the earliest battery source from Seattle. Next, whether or not to use this supply source is a business decision.

Shipping interruption query This system keeps track of the supply sources and destinations of all current shipments. The system also knows the start time and average delivery time of each shipment for each pair of start and end positions. Therefore, all roads through Colorado are closed. Which shipments are affected? Can respond to such queries.

  There are several possible ways to respond to a shipment interruption query. For example, in the first method illustrated with reference to FIG. 21, the steps can be performed as follows. (1) Identify the geographical region where the movement was interrupted, for example, Colorado. The area is approximated by a rectangle 2110. (2) Identify all current shipments and items planned for the time period of interest. (3) The following steps are executed for each shipment. (A) A bounding box is formed between the start position 2130 and the end position 2140. (B) It is determined whether the boundary frames intersect or overlap. (C) If they absolutely intersect, it is considered a potential interruption. As will be described below, even when there is no intersection, there may be interruptions depending on, for example, highways, mountains, waterways, and the like. See below.

This method gives a basic and general indication of potential interruptions. In order to form a more specific instruction, it is only necessary to look at the straight path 730 from the starting position to the ending position. If the interruption of movement intersects this line, the indication of potential interruption becomes stronger.
In the more accurate second method shown using FIG. 22, there is a concept of a transportation route.
In the second method, steps 1 to 5 of the first method are used to indicate whether the interruption of movement 810 may affect a particular shipment. If the border frame intersects with the interruption of movement, the details of the planned transportation route are examined, for example, by examining the road point 2220. If the planned route intersects the movement interruption rectangle, the potential for interruption is quite high. This figure shows that the interruption of movement blocks the straight path, but does not actually block the planned path 810.

  In the third method shown using FIG. 23, a more detailed route can be obtained. Such a route can be obtained by directly entering the details of each route, by road name, or by using route planning software. Such detailed information allows for a more accurate detection of interruptions to vehicle transport on established roads. The steps are as follows. (1) Define a movement interruption 2310 for a highway or a blocked road segment. (2) Find all transport routes 2320 for all shipments within the time frame. (3) The movement interrupted road section is collated with the planned route. If they match, the indicated route is interrupted.

Real Time Location Search Expressions and Queries A real time location search (search) system (RTLS) can perform continuous tracking of objects. Such tracking is usually done using a transponder, but the transponder can be expensive. This system employs a tag carrying an inexpensive passive RFID tag, and can provide an appropriate function of RTLS.
That is, there are two basic methods for position search queries. In the first approach, the transport system (eg, truck, ship, airplane) has RTLS. Monitor the real-time location search of all transportation agencies, and the system associates a particular item to the transportation agency and hence the location. In the second method, the current position of an item is approximated using information collected by reading from a passive tag at a fixed position and information related to planned shipment. This approach is much less expensive and provides many of the advantages of the transport RTLS approach without requiring any RTLS infrastructure. It can also work with a third party carrier.

If the transport has an RTLS feature, the official shipping process associates the shipment with a transport mode. If the transport itself is a tagged object, such as a truck with an RTLS type tag, the system knows the exact shipping location at the time of the latest RTLS update.
An example of a location search query is to show the estimated current location of all minced meat shipments. The RTLS method follows these steps. (1) Check the item type of the desired ground meat shipment. (2) Find all current shipments of this item type. (3) Identify the transport vehicle associated with each shipment. (4) Find the location of the transport that is the tagged object by finding the latest RTLS update for the tag. (5) For example, based on latitude and longitude, the current location is indicated by a graphic.

Without the RTLS function, the system knows when to load the shipment on the truck, the destination of the shipment, and when the unloading of the shipment at the destination is complete. Thus, the system can record and collect this information for each pair of start and end positions that appear in the system. The system can then calculate the average shipping time. With this information, the system can estimate the current location of the shipment, optionally with a confidence range.
This method corresponds to a sample query (indicating the estimated current location of all minced meat shipments) as follows: (1) Check the item type of the desired ground meat shipment. (2) Based on the previous history, obtain the average shipping time of these shipments. (3) Find all current shipments of this item type. (3) For each shipment, compare the recorded start time and the difference between the current time and the average delivery time. This amount estimates the percentage of the stroke that has been completed.

The current location can be estimated and displayed in several different ways.
In the straight line method shown in FIG. 24, the entire delivery process is approximated by a direct straight path from the start position to the end position. By calculating an estimated rate 2410 of the completion process and assuming a straight path, the position 2420 of the shipment can be estimated. This method does not correspond to real world roads or highways, but provides an acceptable approximation of the location of the product relative to the destination.

  In another method shown by using FIG. 25, as discussed above, a detailed route is constructed for each shipment. This technique can give a detailed sequence of route segments 2510-2518, for example, which can be highlighted on the map. The route planning software can estimate the travel time to any given point on the route. For example, in FIG. 25, the estimated driving time to each interchange point is estimated and illustrated. Based on knowledge of the actual departure time, the system can estimate the current location of the delivery vehicle at a specific location level on a specific road. This approach is particularly useful in determining the impact of known transportation interruptions, such as bridge closures.

4). Data Transfer Between Item Tracking System and Tag Reader The following sections describe embodiments of the system where hardware and software intervene between the tag reader and the ITS. Alternatively, intervening hardware and software functionality may be integrated into the ITS, for example, as part of the OIC 104 shown in FIG.

4.1 Event Router One embodiment of the system uses one or more routers to transfer information between the ITS and the tag reader. An event is a message passed between software entities. When an event is used, an event on the receiving side of the event can be notified or a request can be sent to the receiving side. An event router can be used to distribute events between various entities. Examples of suitable event routers include topic-based KnowNow (R) event routers available from KnowNow Incorporated, Mountain View, California, or content available from Distributed Systems Technology Center, Queensland, Australia Includes Elvin messaging services based on. A combination of topic-based event routers and content-based event routers may also be used.
For purposes of illustration, the present invention will be described with respect to use in specific situations, inventory management situations.

FIG. 36 shows retail locations for an item tracking system (ITS) used as part of an inventory management system. The retail position is a store. The store has an inventory list that includes tagged items. When tagged items are brought into or out of the store, this is detected by the position monitoring system 3610.
The monitoring system 3610 includes a number of tag readers located at one or more locations within the store. The monitoring system 3610 also includes a memory that stores the current state of each item in the inventory list. The status indicates whether the item is at or taken from a given location. The monitoring system 3610 also includes computer logic to determine when an item's state has changed, for example, when an item has been added to or taken from a given location.

The logic can further be configured to send an update whenever it detects a change in the state of the item. The inventory inventory update can take the form of an event that includes an item ePC, a tag reader ePC, and a time stamp. The event can also include IN / OUT parameters that specify whether the change is the addition or deletion of an item.
In one implementation, the monitoring system 3610 includes one or more smart display shelves. Smart display shelves are display shelves that can report when physical items are added to or removed from the display shelves. A smart display shelf includes a number of tag readers disposed at one or more locations on the display shelf. The smart display shelf also includes computer logic that determines whether an item has been added to or deleted from the inventory.
The ITS 3620 maintains tracking information for a number of items, including items that are listed in the store inventory list. Whenever an item enters or exits a store, the ITS receives an event from the monitoring system 3610, updates its data storage, and reflects the event.

  The inventory planner 3640—computer program solution—usually operates on a periodic schedule and performs inventory management functions. In the operation related to the store, the stock planner 3640 searches the stock data from the ITS 3620 and determines whether or not to replenish the stock in the store. The inventory planner 3640 can receive alerts from an early warning agent (EWA) 3630, which, in addition to its normal periodic schedule, has at least an inventory management function at least in connection with the store. Part of it can be executed. That is, the EWA 3630 can send a warning to the inventory planner 3640 and cause the inventory planner to determine whether or not the store inventory needs to be replenished. The EWA receives events from the monitoring system 3610 whenever items enter and leave the store, and optionally when they move from one part of the store to another. Using information received in such an event, the EWA decides when to send an alert to the inventory planner 3640.

The early warning agent EWA 3630 includes logic to determine when to send an alert. Determining whether to send a warning includes applying one or more rules to the information received in the inventory update. A rule specifies a state and an action to be performed when this state is met. For example, a rule can specify that an alert be sent whenever an inventory level falls below a certain value.
The EWA 3630 can apply a predetermined set of rules, or the EWA 3630 can include artificial intelligence logic to adapt its behavior to the EWA 3630 in response to current inventory or historical inventory patterns. be able to. Artificial intelligence logic allows EWA to estimate potential variability in inventory levels in the near future, identify potentially dangerous situations early enough, and take corrective action. For example, in the initial state, a rule can specify that an alarm should be raised when inventory falls below ten. However, if EWA 3630 detects that alerts are sent much more frequently during the summer season than during other seasons, EWA 3630 increases the threshold from 10 to 20 during the summer season and causes inventory planner 3640 to You can adapt to this seasonal variation by notifying early impending stock shortages. This adaptive behavior is done with minimal human intervention and with minimal need for parameter adjustments or any other type of manual calibration.

The EWA 3630 searches and analyzes current and past inventory data to detect trends such as the gap between the replenishment plan and actual replenishment, and builds a predictive model for future inventory needs. These trends and predictions can be determined using linear regression, classification, regression trees, or other stochastic algorithms.
In one embodiment, the EWA 3630 estimates potential fluctuations in consumption activity that may affect each replenishment plan, or inventory (eg, from past transfer data, a planned truck load of 12 oz bottles from Bob's Bottles Estimate to arrive at any time within 4 hours prior to 6 hours after delivery time, the amount is between 95% and 100% of the requested amount). EWA 360 compares the promised delivery times and actual delivery times for various quantities of previously delivered inventory to determine the actual delivery date and quantity for future replenishment activities that have been planned but not yet completed. Generate predictions. The EWA 3630 collects estimates of potential variability for several individual activities to determine an estimate of potential variability for the entire inventory. These algorithms can be implemented using a decision tree such as a classification or regression tree.

In another embodiment, instead of taking into account individual activities, EWA 3630 builds a predictive model based on aggregated data representing the level of replenishment and consumption. These algorithms can be implemented using a probabilistic inference model such as a conditional Gaussian approximation.
Further details regarding the algorithm used by EWA 3630 are filed on May 31, 2002 and are co-pending US Provisional Patent Application 60/90 entitled “Inventory Early Warning Agent”. 384,638. The contents thereof are included in the present application by quoting here.

Inventory Planner The inventory planner 3640 can be any application that generates an inventory replenishment plan. One such inventory planner 3640 is the Advanced Planner and Optimizer (APO) available from SAP AG.
Inventory planner 3640 includes logic to generate a replenishment plan. The logic receives an alarm from wear 3630 and determines whether replenishment is required in response to the alarm.
In one embodiment, inventory planner 3640 generates a replenishment plan for the entire inventory. The EWA 3630 monitors a portion of inventory. By combining a number of EWA 3630s, the entire inventory can be covered. An alert on a portion of inventory triggers inventory planner 3640 to make a decision as to whether or not the replenishment planned for the entire inventory must be re-planned.

This determination may include retrieving inventory data from ITS 3620 and determining or predicting acceptance based on the retrieved inventory data. For example, if there is a high demand trend for the product X, the inventory planner 3640 is planned to increase not only the product X but also the product Y. Product Y is a product for which product X is known to be the leading indicator.
As shown in FIG. 37, event routing middleware, such as an event router (ER) 3710, is used to distribute events between various entities, for example, the monitoring system 3610, ITS 3620, EWA 3630, and inventory planner 3640. can do. Examples of suitable event routers include topic-based KnowNow (R) event routers available from KnowNow Incorporated, Mountain View, California, or available from Distributed Systems Technology Center, Queensland, Australia, Includes content-based Elvin messaging services. A combination of topic-based event routers and content-based event routers may also be used.

Content-based event forwarding In the location implementation, messages are forwarded from the publisher to the subscriber based on the content of each message. The content of each message can be divided into a number of content fields. For example, the message 01.0037F2.001508.000319F827 for an item with ePC can be split into the following content fields.
(1) Header: 01
(2) Manufacturer: 0037F2
(3) Product class: 001508
(4) Serial number: 000319F827
(5) Message type: Seen @, request, response seen @ message is a message reporting that an item has been detected at a specific location. A “request” message is used to send the request to the subscriber, and a “response” message is used to publish the requested information. Other message types can also be defined.
The subscriber can specify a message filter based on the value of the content field.
(Eg manufacturer = 0037F2 & message type = seen @)

Event forwarding based on topic In an alternative embodiment, events are classified according to topic. A software entity may only be interested in events related to a topic. Software entities can subscribe to only certain topics, receive only events related to these topics, and not receive other topics.

FIG. 38 shows a topic structure based on the ePC structure. A separate topic can be created for each of the ePC data fields: manufacturer, product class, and sequence number. For example, for the item 01.0037F2.001508.000319f827 with ePC, the following topics can be created.
(1) \ centauri \ 0037F2 \ 001508 \ 000319F827 \ see @-This topic covers "seen @" events for items.
(2) \ centauri \ 0037F2 \ 001508 \ 000319F827 \ *-This topic covers both the events reported in Topic 1 and other types of events related to items, such as “request” and “response” events. Including.
(3) \ centauri \ 0037F2 \ 001508 \ *-This topic includes both events reporting to Topic 2 and events related to other items in the same product class 001508.
(4) \ centauri \ 0037F2 \ *-This topic includes all events reporting to Topic 3 and events for another item with the same manufacturer 0037F2.

Separate topics can be created for events related to the leader. For example, the following topics can be created for a reader with ePC 01.0B39C2.000815.004711F827.
(1) centauri \ oB39C2000815004711F827 \ Have-Seen-ePC—This topic covers events related to a specific reader that detected a specific ePC.
(2) centauri \ oB39C2000815004711F827 \ * — This topic covers events related to the specific reader that detected any ePC.

  A topic-based event router has a set of topics, and each topic has an address, eg, a URL. By sending an event to a topic address, the event can be published to that topic. An publishing entity such as monitoring system 3610 (FIG. 37) can refer to an Extended Object Naming Service (EONS) 3720 to determine the appropriate topic URL to publish the event. EONS 3729 maintains a mapping between an item ePC (or reader ePC) and one or more ERs along with its corresponding topics. EONS takes an item (or reader) ePC as input and returns a URL (multiple URLs) for one or more identified topics. The EONS 220 can be realized by extending a conventional ONS such as the ONS developed by Oat Systems and MIT Auto-ID Center. This is described in more detail in the Object Name Service Technical Manal (issued by MIT Auto-ID Center). The conventional object naming system is similar to and based on the well-known Internet Domain Name System (DNS).

Protocol Flow for Issuance As shown in FIG. 39, the monitoring system 3610 identifies that an item has been added to or removed from inventory. The monitoring system 3610 generates an event that includes a tag identifier, a reader identifier, and a time stamp. The tag identifier identifies the changed item. The reader identifier identifies the reader that detected the change. The time stamp specifies when a change is detected.
The monitoring system 3610 then refers to the EONS 3720 to determine where to send the event. The monitoring system 3610 supplies the EONS with the item ePC and the reader ePC, and conversely receives the item topic and reader topic URLs from the EONS. The monitoring system 3610 then sends the event to both topics.

The Item Topic and Leader Topic ER (s) forwards the event to one or more subscribers. For example, an ITS may be a subscriber to an item topic and an EWA may be a subscriber to a leader topic. The EWA receives an event from the ER and determines whether to send an alert to the inventory planner.
When sending an alert, this triggers the inventory planner to replan the inventory replenishment. To obtain current data for the inventory inventory, the inventory planner can send an event to the ER requesting inventory data. The ER then responds by forwarding the event to the ITS and sending the requested inventory data to the inventory planner.

Protocol Flow for Subscription As shown in FIG. 40, for each topic that the subscriber wants to subscribe, the subscriber first refers to the EON to determine the address of the ER for a given topic and then publishes to the topic Wait for the event to be done.
Upon receiving the event, the subscriber can use the reader identifier included in the event to determine the location of the item. The location can also be a physical location (eg, specific longitude, latitude and altitude), or a logical location (eg, inside container XYZ or track ABC). The subscriber can also use the tag identifier to find the location of additional information about the item. For example, a tag identifier can be used to retrieve a PML (Product Markup Language) document for an item.

As shown in FIG. 41, EONS can maintain a mapping between multiple tagged items (or readers) and multiple ERs. As discussed above, the mapping corresponds to a number of keys including item keys and reader keys. EONS can service a number of monitoring systems 3610 and other tag reader applications. In one embodiment, the EONS is a distributed subsystem that receives mapping information, a query server that responds to queries that request the location of information, and a name resolver (name that resolves the ePC into an ER location. including resolver).
As shown in FIG. 42, a specific ER can be distributed over multiple ITS (and other subscribers), and a specific ITS can subscribe to multiple ERs. The user can define a desired range for each ITS and configure the distribution scheme accordingly.

4.2 Integrated Engine As shown in FIG. 31, one embodiment of the system can use an integrated engine 3110, which acts as an intermediary between ITS and tag readers. The integration engine 3110 can be realized as mediation software and hardware between the reader and the ITS. Alternatively, the integration engine 3110 can be integrated into the ITS, for example, as part of the OIC 104 of FIG.

  The integration engine 3110 can communicate with the tag reader 102 and other types of smart items. As used herein, a “smart item” is an item or machine that can store its own data and communicate it to an external system. Any communication channel (eg, radio frequency, infrared) can be used. The communication process can lead to changes in the data stored in the smart item. More sophisticated smart items also have processing capabilities and can interact directly with other smart items to negotiate common behavior, for example. Smart items can store and communicate different types of data, including a unique item identifier (UID) and other item attributes of the item. Some have sensors and can record environmental data such as temperature, humidity, acceleration, or position. The transmitted data can be real time data, historical data, or both.

Examples of smart items include tag-to-items, RFID interrogators, actuator devices, aware good, and embedded Internet devices. An actuator device is a machine that moves and controls something (eg, conveyor belt, vending machine). A recognized product is a product (for example, a product equipped with a position or temperature sensor) that can detect information about the environment.
Support for a given sensor or actuator device is implemented using a hardware interface, such as the example hardware interface shown in FIG. The integration engine 3110 collects data from different types of smart items 3120 and supplies the collected data to the higher-level application 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 various smart items 3120, processes the data, and supplies the processed data to the upper application 3130 in real time. Performing in real time in this way means processing when data is received and supplying when data is processed. The integration engine 3110 can also receive data from the upper application 3130 and write the data to the smart item 3120.
Processing the data can include filtering the data. For example, one application may only be interested in receiving UID and location data, while another application may only be interested in collecting data from a certain smart item. A separate filter can be provided for each application that requests data.

Data processing can also include summation of data. In data summation, data is combined with each other to generate higher order data. For example, the UID of an item located in a track is combined with the temperature reading from the track to generate a temperature reading for that item. Data summing can make the data more meaningful than handling the data individually. In addition, it is possible to accumulate the real time data into a batch by summing, and send the batch data at a predetermined interval instead of the real time. The data can be time stamped using the date and time of collection.
The integration engine 3110 is configured to interface with different types of hardware interfaces with basic read and write functionality. The integration engine 3110 converts between a hardware specific data format and a generic format, i.e., in some cases an application specific format. In this way, the integration engine 310 hides hardware specificity from the application 3130.

  FIG. 32 shows how multiple smart engines can be managed using multiple integration engines 3110. Each integration engine 3110 can transfer data to a particular location (e.g., factory, loading / unloading home, store) and assign it to be transferred from there. Application 3130 can subscribe to one or more integration engines 3110. Each integration engine 3110 can be implemented as a number of nested integration engines 3110. The output of one integration engine 3110 can be an input to the upper integration engine 3110.

FIG. 33 shows an example of an embodiment of the integration engine 3110. The integration engine 3110 manages all resources and objects associated with interactive processing with smart items and controls the entire 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 techniques, such as Java, C #, or C ++ objects.
Control manager 3310 provides a programming interface between integration engine 3110 and application 3130. The programming interface implements a general purpose (non-embodiment specific) communication interface into which various adapters can be plugged. The adapter performs conversion between a specific communication interface (for example, RPC, COM, CORBA, JMS, HTTP) and a general-purpose communication interface.

  The control manager 3310 receives the rule from the application 3130, interprets this rule, receives the client command, interprets the client command, instantiates the appropriate interrogator agent, processing agent, and communication agent, and Execute. Rules can define or constrain various aspects of the behavior of interrogator agents, processing agents, and communication agents. For example, the rule may specify which data is supplied to the application (eg, if it is UID or position data, only data is supplied), which data is written to the hardware (eg, track temperature is a predetermined threshold) If it drops below, write a command to turn off the air conditioner) or when to write data (eg once a day). The rule also determines how to combine the collected data to generate higher-level data (for example, combining the UID of the item located in the truck with the temperature of the truck to determine whether the item is overheated) ). Each time the control manager 310 receives data, it interprets and applies the rules.

  In one embodiment, the control manager 3310 includes or is coupled in some way to a rule repository that stores rules received from the application and a rules engine that executes the stored rules. Rules received from the application can be expressed as UML (Unified Modeling Language) model, EBJ (Enterprise Java Beans) beans, or XML (Extensible Markup Language) documents. If necessary, the control manager 310 converts the rules into an internal format used by the rules engine.

  The interrogator agent 3320 is responsible for controlling an entire single hardware device interface, such as an RFID controller interface. The interrogator agent 3320 interfaces with a hardware interface, a control manager 3310, and a processing agent 3330. Interrogator agent 3320 receives data from the hardware interface. The interrogator agent 3320 can be configured according to the hardware interface requirements. For example, some hardware interfaces require synchronous polling while other interfaces generate events or interrupts. The interrogator agent 3320 generally does not process any collected data, but instead simply forwards the data to the processing agent 3330 for processing.

The processing agent 3330 is responsible for data filtering, summing, and conversion operations. The processing agent 3330 performs bidirectional processing with the control manager 3310 and the interrogator agent 3320.
In performing data filtering, processing agent 3330 receives sensor data collected by one or more interrogator agents. The processing agent 3330 calls the rule engine and determines whether any of the data satisfies the conditions specified by the rule. Any data that does not satisfy the condition is not transferred. Data that satisfies the condition is transferred to the communication agent 3340.

When executing the data summation, the processing agent 3330 stores the received data in a buffer until all data requested by a given rule is received.
Processing agent 3330 receives data in a hardware specific format. The processing agent 3330 uses the mapping table to convert between the hardware specific format and the general format that the integration engine 3110 outputs to the application 3130.

  The data load can be shared among many processing engines. A processing agent 3330 may process only data including certain information, such as a purchase order number, for example. In such a case, the interrogator agent 3320 may identify the type of hardware (eg, a bar code scanner emits bar code information) or metadata describing the data (eg, with reference to FIG. 34). The type of information collected based on one of those (as specified in the logical tag type). A certain processing agent 3330 may process complex data and data added from the outputs of several processing agents 3330. One or more same processing agents 3330 may be responsible for applications that request the same type of data.

Communication agent 3340 is responsible for supplying data to application 3130 using either a push model or a pull model. The application can explicitly request to perform a read or write operation on the smart item 3120 (pull mode), or the application notifies when the integration framework receives data from the smart item 3120 Can be requested (push mode).
Communication agent 3340 receives processed data from one or more processing agents 3330 and provides this data to all subscribed applications 3130. The communication agent 3340 maintains a list of subscription applications 3130 and their respective destination parameters. The communication agent 3340 is a set of a plurality of communication agents 3340, and each communication agent can realize a specific communication interface or protocol (for example, RPC, COM, CORBA, JMS, or HTTP).

  Instead of supplying the processed data directly to the subscription application 3130, the communication agent 3340 can use an intermediary, ie an event router. The event router appears on the list of subscribed applications. An event router is a service that transfers messages (events) between software entities. Messages can be used to notify the message receiver about an event or send a query to the receiver. Examples of suitable event routers include the KnowNowO event router available from KnowNow Incorporated, Mountain View, California, or the Elvin messaging service available from Distributed Systems Technology Center, Queensland, Australia. In one embodiment, the communication agent 340 provides data in the form of a data object (or collection of objects) with methods that can be called by external applications to retrieve UIDs and additional item data. In another embodiment, the data format is XML. The advantage of XML is that it is 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 higher-order software to perform bidirectional processing with lower-layer hardware (underlying hardware). A wide range of RFID technologies are currently available from a number of vendors. Depending on the application scenario, it is necessary to select a specific type of tag (passive / active, read-only / rewriteable, etc.). Since the hardware interface is implemented using published standards, it has the advantage that it can be used with various RFID technologies from various vendors. The hardware interface may receive a request to read data from the hardware device or a request to write data to the hardware device. Data from the hardware device can be sent to either interrogator agent 3320 or processing agent 3330.

  The interface 3400 includes an abstraction layer and a server 3410, and conceals details of the interrogator 3420. Server 3410 communicates with interrogator 3420 through a hardware dependent interface. At runtime, an instance of a particular server 3410 is responsible for only one interrogator 3420. However, several applications can communicate with the same server 3410 instance at the same time.

Server 3410 supports at least two different types of read requests. A discrete read request returns information only about tags that are currently readable. A continuous read request returns information on all tags that have been read and buffered since the previous read request was made.
Server 3410 may accept data to write. The data to be written can be data stored on the tag, or can be control data for controlling the behavior of hardware. For example, a smart conveyor belt can receive control data that switches between a left belt and a right belt, and a smart vending machine can control the price of an item or control the temperature of a machine Can receive data.

In addition, the server 3410 can use the following functions.
Initialization This function initializes the interface 3400 for use. All hardware is initialized as needed for communication ports and software objects and processes. Hardware specific details can be set in a hardware specific configuration file.
Terminate This function terminates the use of the interface 3400. This is the reverse function of initialization. Release all hardware, close communication ports, and terminate all software objects and processes involved (unless used by other processes). This is a general purpose termination function. Hardware specific details can be set in a hardware specific configuration file.
Flag Detection This function detects whether a tag can be read now and how many tags can be read.

Define Logical Tag Type This function defines a logical tag type for a given tag. The logical tag type describes the organization of the data on the tag. This is shown in the example of the electronic tag 3500 shown in FIG. As shown, the user data on the tag is physically composed of n 32-bit data blocks. However, logically it has three named data fields. That is, a product number (“ARTNR”) 3510, a product description (“ARTDESC”) 3520, and a price (“PRICE”) 3530. As shown, the field length and start address 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 (to easily map the field to application data), and a description for each data field. The logical tag type also defines the location where the tag identifier is stored. The logical tag type definition can be extended to include other information.

Get Logical Tag Type Description and Field Name This function gets information about the logical tag type. This is typically used to obtain the field name, as well as the length and data type of the field.
Start / Stop Continuous Reading This function starts or stops the continuous reading mode of operation.
Reading a field from multiple tags This function reads data from a specific field of all tags that are readable at the time the function is executed. The parameter specifies whether a discrete or continuous reading mode is required. In continuous mode, the server stores the information of all read tags in a buffer. This buffer is cleared each time the read function is called in continuous mode. However, in the discrete mode, the buffer is not cleared.

Reading a field from a specific tag This function is similar to the previous function. The difference is that the field is read only from a single tag with a particular tag ID. In order to identify a tag having a specified tag ID, it may be necessary to read multiple tags.
Write field to multiple tags This function writes the same data to a specific field of all tags that can be written at the time the function is executed. The fields are named and depend on the tag type defined for the tag. Write the same data to all tags. This function can be used for mass tag writing, for example at the end of a production line.

Writing a field to a specific tag This function writes data to a specific field of a specific tag within the operating range of the tag reader-writer. The fields are named and depend on the tag type defined for the tag. The tag to be written is specified by its UID. Data is written only to the specified field. Any data in the tag field that was not specified is left unchanged.
Also, the data field can be locked by either of two write functions as long as the hardware supports its functionality. Fields can be written and locked at the same time, or previously written fields can be locked to prevent overwriting their data.
Hardware specific calls Some hardware may be able to provide certain functionality beyond the scope of this interface. In order to make this functionality available to customers, this feature provides a mechanism to pass hardware specific calls directly from the application.

Error handling When a communication error occurs, the hardware device 3420 or the server 3410 first tries to solve the problem on its own, for example, by retrying an operation many times. If that low level error handling fails, the interface 3400 provides information about what went wrong so that the application can take appropriate action.
In addition to a comprehensive error code that defines the error type, a detailed description of the error is given. The interface 3400 recognizes at least the following types of error conditions.
(1) The interrogator does not respond. I failed to initialize the interrogator.
(2) Read error. Although n tags were detected, they could only be read correctly from m tags (m <n). The absence of a tag at the site is not an error condition.
(3) Write error. The tag could not be written because it was not in the field or because of certain writing problems, such as a locked field or general failure.
(4) The hardware is not compatible. Functions such as data lock may not be supported by all hardware.

5. Compression of the tracking information, filtering, and the encryption following sections, to compress the tracking information, and filtering, or will be described embodiments for communicating between symbols after encrypting. This embodiment is described in the context of a scene involving producers and consumers. The producer or consumer can be a manufacturer, distributor, or retail store, or any other location or part of a location that handles tagged items.

  As shown in FIG. 43, the producer 4301 sends the shipment 4303 to the consumer 4302. The shipment 4303 includes several tagged items 4304 in a tagged container 4305. When the consumer 4302 receives the shipment 4304, the consumer tag reader system 4306 reads information from the container tag 4307 and the item tag 4308. In order to verify the shipment 103, the consumer 102 needs shipment content information 4309 from the producer 4301. The shipping information 4309 can include the UID of the container and the UID of all items in the container. Other information related to each item, such as the item's color, can be placed in the tag's UID or stored outside the tag. Through a communication network 4301, for example, the Internet, the consumer 4302 can receive shipping information 4309 from the producer 4301 and send status update information to the producer. The local ITS 4311 at the consumer location retrieves information from the tag reader system 4306 and matches the tag information with the shipping information 4309.

As shown in FIG. 45, a method 4500 for communicating tracking information between a producer and a consumer can begin with the producer receiving a plurality of identification codes. Each identification code uniquely identifies the associated item (4510).
The identification code can be read from a tag associated with the item. In order to enable cross-business object tracking, each tag carries a unique identification code for the associated item, for example, an electronic product code (ePC) 4500 shown in FIG. The ePC 4500 is a 96-bit, 8-bit header (bits 0-7) 4510 and three data fields, an ePC manager (bits 8-35) 4620, an object class (bits 36-59) 4630, and a sequence number ( Bits 60 to 95) 4640. Each organization that can tag an item has a unique code in the ePC manager field. Each product classification in the organization has a unique code in the object class field. Each individual item of product has a unique code in the sequence number. UIDs other than ePC can be used in the same manner.

The producer sorts the identification codes into a set of one or more identification codes (4520). Each set of identification codes corresponds to a particular type of item (eg, all basketballs from a given manufacturer).
For each set of identification codes, the producer recognizes a redundant portion of the code that is common to each identification code in the set (4530). For example, as shown in FIG. 47, a full basketball ePC from a given manufacturer includes a redundant portion 4701. That is, ePCs share the same ePC manager and object class. This redundancy is inherent in the hierarchical structure of ePC.

The producer creates a document that includes one or more sets of identification codes (4540). However, for such documents, ePC can occupy a large percentage of the document size. For example, as shown in FIG. 47, the shipping document contains item level information including ePC for each item to be shipped. As the number of items increases, ePC becomes the majority of the document size.
In order to reduce the document size, the producer 4301 once summarizes the redundant parts of the code for each set of identification codes and puts each tag on the list together with the redundant parts of the omitted code (4550). Thus, the hierarchical design of ePCs can facilitate the compression of information associated with each ePC. For example, all basketballs shipped to a packaged location need not include all ePCs for each basketball in the shipping document. Instead, as shown in FIG. 48, the shipping document only includes one entry for the ePC manager and object class in the ePC prefix 4802, and each sequence number 4803 of each individual basketball shipped. That's it.

  Masking techniques similar to method 4500 can be applied to other contexts besides shipping. For example, masking can be applied in the context of production to reduce the size of a production order. In preparation for manufacturing a new line of items, factories typically generate a production sequence that lists the ePCs for each item in a list. This is the same case for each ePC header, ePC manager, and object class. By applying the method 4500 to the production sequence, this redundancy can be eliminated and instead of putting all the ePCs in the list for each item, the redundant part can be omitted and only the serial numbers can be collected in the list.

  The document (shipping, production, or other) size can also be further reduced by recognizing that there is no need to list the serial number for each item produced when the serial number is sequential. Instead, as shown below, all that needs to be included in the list is the first produced item (“EPC_BASE”) and the total number of items produced (eg, 100). Additional information for each item, such as the color of the item, can be listed individually for each item, as shown below.

<PRODUCTION_ORDER ID = 1234566>
<ITEM_LIST QUANTITY = 1000EPC_PREFIX = 01.000A89.00016F>
<EPC_BASE> 00168123 </ EPC_BASE>
<ITEM>
<COLOR> RED </ COLOR>
</ ITEM>
<ITEM>
<COLOR> BLUE </ COLOR>
</ ITEM>
<ITEM>
<COLOR> RED </ COLOR>
</ TTEM>
</ TTEM_LIST>
</ PRODUCTION_ORDER>

  Along the supply chain, there are typically items that are tagged and items that are not tagged. In addition, only some types of items, such as cargo beds or packages, may have RFID tags. In addition, each company may tag items. For example, a shipping company can tag its shipping package and automate its own business planning process. Thus, there may be RFID tags at the item, package, loading platform, and container level, and these tags may be from different companies. However, a simple reader / interrogator cannot distinguish, for example, a container of items from items. As a result, all UIDs that are read must be reported to the central system and filtered. This process is inefficient and very cumbersome for systems that must process millions of reports per day.

The enterprise ePC manager controls the assignment of object classes and sequence numbers. An enterprise can also specify its own scheme for physical objects that are used as accessories for items produced by the enterprise. For example, loading platforms and packages by multiple manufacturers may or may not have their own ePC tags. However, in the shipping company context, there are containers for the items that are actually shipped. The process of transferring shipments between docks is facilitated by checking only the carrier or package, not the entire contents of the carrier or package. This approach requires the shipping company to attach its own ePC to the container.
The reader can be configured to acquire only certain types of ePC patterns. For example, the reader can be configured to register only containers that begin with the letter “1” in the object class portion of the ePC. The actual XML filtering method has the following format.
<Container_Class> 01.1234566.1XXXXX </ Container_Class>

  In this example, X is a wildcard in the string that forms the ePC, and the reader accepts any data at these locations. By configuring the reader in this way, the reader can filter the read ePC and check only the container type specified in the method. Thus, filtering can reduce messages sent from the reader to a monitoring application, ie, a process such as a shipping confirmation process.

FIG. 49 illustrates a method 4900 for filtering tracking information. Filtering can be performed by the reader or reader system at various stages in the delivery process (ie, by various consumers) and at various levels within a particular consumer. For example, as described above, the filtering process can be performed at the tag-reader level. Alternatively, or in addition, the consumer's ITS can also filter data received from the tag reader.
An identification code associated with a plurality of items, including individual items and item containers, is retrieved (4910). Each identification code (eg, ePC) is a character string that uniquely identifies the associated item. The identification code can be retrieved from various sources, such as from a tag reader, from a shipping document, or ITS (shared or local).

In each identification code, characters indicating whether the item is an individual item or a container of the item are arranged (4920). As mentioned above, containers can be distinguished from individual items, and containers have a “1” as the first character in the object class portion of the code. However, other characters and character positions can be used. Based on the arranged characters, a determination is made as to whether the identification code corresponds to an individual item or a container (4930).
When such a determination is made at the tag-reader level, the tag reader can distinguish individual items from the item's container, and this distinction can be used for recipients of the read information. Filter out no reads. For example, if the recipient is a shipping company, it may be desirable to know only the tag information of each container of the item, but not the tag information of the item itself. In such a case, the reader itself, or a higher-level component in the system, can filter out codes for individual items and send only tag information about the container to the recipient.

Controlling access to tracking information In an inter-enterprise computing environment, tracking information can be used by many consumers. However, producers do not necessarily want all consumers to share the same level of access. For example, manufacturers can record information about shipments, such as “responsible” or “quality grade”, and some consumers (eg, customs offices) are allowed access. However, other consumers (eg, retail stores) are not allowed access.
In one embodiment, only a portion of the document is provided to the consumer when controlling access to the tracking information. For example, the shipping company need only know the total amount of goods being shipped, but the shipping company need not know (or be allowed to know) other attributes (eg, color, price) of the goods.

  However, it may be more efficient to simply send the same encoded document to all consumers. Thus, in an alternative embodiment, the same document is supplied to all consumers in an encoded format. Each consumer is then separately provided with selection means for decrypting only a portion of the document. Encoding and decoding can be completely transparent to an external system 4312, eg, an ERP system. In other words, the input and output of the tracking system can be plain text uncoded documents.

As shown in FIG. 50, when performing the method 5000 for controlling access to tracking information, the producer creates tracking information for the collection of items. The tracking information represents each of the items as one or more attributes and any corresponding values (5010). When the producer encodes the tracking information, it encodes (5020) each instance of each individual attribute in the tracking information with its corresponding separate encoding scheme. The producer sends the encoded tracking information to the receiver (5030), determines what attribute the receiver is allowed to access (5040), and supplies a subset of the encoding scheme to the receiver (5050). ). The subset includes only the encoding scheme for the attributes that the recipient is allowed to access.
The method 5000 can be performed at various points in the tracking process, such as before tracking information is stored in a tag or before the tracking information is deposited in a shared ITS. The method 5000 can be performed whenever tracking information is released and the source wants to control access to the tracking information.

  As shown in FIG. 51, when performing the method 5100 to access tracking information, the consumer receives encoded tracking information for a set of items. The tracking information represents each of the items as one or more attributes and any corresponding value, and to encode the tracking information, each instance of each individual attribute in the tracking information is represented by its corresponding individual code. (5110). The consumer also receives a subset of the encoding scheme. This subset includes only the encoding scheme for the attributes that the recipient is allowed to access (5120). Finally, the consumer decrypts (5130) the attributes that the recipient is authorized to access.

Tracking information can be stored in an XML document as part of a tag attached to a physical object. The reader allows the consumer to retrieve the XML document from the tag. Alternatively, the consumer can retrieve the XML document from another location, such as a shared ITS or another computer system.
The document type definition (DTD) or XML method defines the metadata of a CML document. The DTD can be included in the XML document or stored separately. For example, the following DTD called Product has attribute fields of ProductType, ProductID, Version, Vendor, SalePrice, ProducePlace, ProduceTime, ExpireTime, ResponsiblePerson, QualityGrade, and Weight.

<? xml version = “1.0” encoding = “UTF-8”?>
<! ELEMENT Product (ProductType, ProductID, Version, Vendor, Saleprice,
ProducePlace, ProduceTime, ExpireTIme, ResponsiblePerson, QualityGrade)>
<! ELEMENT productType (#PCDATA)>
<! ELEMENT productID (#PCDATA)>
<! ELEMENT Version (#PCDATA)>
<! ELEMENT Vendor (#PCDATA)>
<! ELEMENT SalePrice (#PCDATA)>
<! ELEMENT producePlace (#PCDATA)>
<! ELEMENT produceTime (#PCDATA)>
<! ELEMENT ExpireTime (#PCDATA)>
<! ELEMENT ResponsiblePerson (#PCDATA)>
<! ELEMENT QualityGrade (#PCDATA)>
<! ELEMENT productSet (#Product +)>

An XML document based on this DTD file is shown below.
<? xml version = “1.0” encoding = “UTF-8”>
<! DOCTYPE ProductSet SYSTEM? ProductSet.dtd ”>
<ProductSet>
<Product>
<ProductType> XXXX </ ProductType>
<ProductID> 45EF76345 </ ProductID>
<Version> E3DF67 </ Version>
<Vendor> AAA </ Vendor>
<SalePrice> 1988-12-28 </ SalePlace>
<ProducePlace> 621 </ ProducePlace>
<ProduceTime> 2000-12-28 </ PeoduceTime>
<ExpireTIme> 2002-12-28 </ ExpireTime>
<ResponsiblePerson> KellyDe </ ResponsiblePerson>
<QualityGrade> 6 </ QualityGrade>
</ Product>
<Product>
<ProductType> XXXY </ ProductType>
<ProductID> 45E003123 </ ProductID>
<Version> 9FD56 </ Version>
<Vendor> BBB </ Vendor>
<SalePrice> 3.4 </ SalePrice>
<ProducePlace> 621 </ ProducePlace>
<ProduceTime> 2000-02-28 </ [ProduceTime>
<ExpireTime> 2000-02-28 </ ExpireTime>
<ResponsiblePerson> Kevin Smith </ ResponsiblePerson>
<QualityGrade> 8 </ QualityGrade>
</ Product>
</ ProductSet>

  FIG. 52 shows a document, index table, and encoded document system used to communicate tracking information with tagged items in network 5240. The producer 4301 uses the index table 5230 to convert the producer's XML document 5210 into an encoded XML document 5215. The index table can also be used when the producer DTD file 5220 is converted into the encoded DTD file 5225. The consumer receives encoded XML or encoded DTD file 5260/5270 from the producer over the network. The consumer uses the destination index table to convert the encoded XML document into a consumer XML document 5265 or the encoded DTD file into a consumer DTD file 5275. The consumer uses a consumer XML document or a consumer DTD file.

  The index table 5230 is used when an XML document is generated on the producer side. The index table associates tag names with index values. Each attribute field has a corresponding tag name describing the attribute. Optionally, each attribute field also has a corresponding value. Tag names are generally descriptive and the index is a tag name encoding. The encoding may be selected to be efficient for the expected tag number. An index table for processing the ProductSetXML document discussed above can be expressed as follows:

table
Tag name Index
Product 1
ProductType 2
ProductID 3
Version 4
Vendor 5
SalePrice 6
ProducePlace 7
ProduceTime 8
ExpireTime 9
ResponsiblePerson 10
QualityGrade 11
ProductSet 12
The index values in the above index table can be arbitrary, which makes it difficult to interpret the encoded XML document without the index table.

Based on the index table, the XML document is converted into an intermediate data document called an encoded XML document 5215. An encoded XML document corresponding to the above-described XML document created using the index table is as follows.
<? xml version =? 1.0 ”encoding =? UTF-8”>
<! DOCTYPE 12 SYSTEM? 12.dtd ”>
<12>
<1>
<2> XXXX </ 2>
<3> 45EF76345 </ 3>
<4> E3DF67 </ 4>
<5> AAA </ 5>
<6> 1988-12-28 </ 6>
<7> 621 </ 7>
<8> 2000-12-28 </ 8>
<9> 2002-12-28 </ 9>
<10> KellyDe </ 10>
<11> 6 </ 11>
</ 1>
<1>
<2> XXXY </ 2>
<3> 45E003123 </ 3>
<4> 9FD56 </ 4>
<5> BBB </ 5>
<6> 3.4 </ 66>
<7> 621 </ 7>
<8> 2000-02-28 </ 8>
<9> 2002-02-28 </ 9>
<10> Kevin Smith </ 10>
<11> 8 </ 11>
</ 1>
</ 12>

The encoded DTD file is generated based on the original DTD file. The encoded DTD file shown above and generated using the index table shown above is as follows.
<? xml version = “1.0” encoding = “UTF-8”?>
<! ELEMENT 1 (2,3,4,5,6,7,8,9,10,11)>
<! ELEMENT 1 (#PCDATA)>
<! ELEMENT 2 (#PCDATA)>
<! ELEMENT 3 (#PCDATA)>
<! ELEMENT 4 (#PCDATA)>
<! ELEMENT 5 (#PCDATA)>
<! ELEMENT 6 (#PCDATA)>
<! ELEMENT 7 (#PCDATA)>
<! ELEMENT 8 (#PCDATA)>
<! ELEMENT 9 (#PCDATA)>
<! ELEMENT 10 (#PCDATA)>
<! ELEMENT 11 (#PCDATA)>
<! ELEMENT 12 (1 +)>

When a consumer decrypts a document, the consumer can change the tag name to better support the consumer's own naming convention.
In addition to controlling access, yet another advantage of encoding information is that encoded tag names generally occupy less space than unencoded tag names, which can be very descriptive. That's it. The index values can be selected to be small as in the simple numerical index method exemplified above.
Tag memory is limited. Therefore, by using a small index value, more tracking information (for example, attribute field) can be included in the tag. Similarly, when tracking information is conveyed over the network, encoded information can use less bandwidth for transmission than an unencoded version.

  FIG. 53 illustrates a method for checking the appropriate index table used to create an encoded XML document. Initially, the system checks (5310) to see if the index table needs to be updated. If not necessary, an encoded XML document or an encoded DTD file is created using an existing index table. If the index table needs to be updated, a new index table is created, which is then used to create an encoded XML document or encoded DTD file (5330).

The encoded XML document is transformed through a network or stored in a smart tag attached to a physical object. On the consumer side, the document is decrypted using the destination index table. With respect to the index table, as shown in the following example, the destination index table associates tag names with index values.
table
Tag name Index
Product 1
ProductType 2
ProductIdentification 3
VersionNumber 4
VendorName 5
ProduceTime 8
ExpireTime 9
ProductSet 12

Every index in the destination index table must also be in the corresponding source index table used in creating the encoded document. However, not all indexes in the index table are in the corresponding destination index table. The consumer of the XML document receives the tag name and index only for the attribute fields that the producer has allowed the consumer to share. For example, if an XML document is created by a manufacturer, the consumer is a retail store, and the manufacturer does not want the retail store to see attribute fields called ResponsiblePerson and QualigyGrade, these indexes Not in the index table.
Different tag names can be attached to specific indexes in the destination index table and the corresponding index table. Therefore, the consumer can change the tag name to suit the application. For example, as shown above, the consumer can replace ProductID with ProductIdentification, VersionNumber with VersionNumber, and VendorName with Vendor. However, the meaning of these tags must be the same for their associated application.

Based on the destination index table and encoded DTD file shown above, the consumer obtains the following DTD file.
<? xml version = “1.0” encoding = “UTF-8”?>
<! DOCTYPE ProductSet SYSTEM? ProductSet.dtd ”>
<! ELEMENT Product (ProductType, ProductIdentification, VersionNumber,
VendorName, SalePrice,
ProducePlace, ProduceTime, ExpireTime)>
<! ELEMENT ProductType (#PCDATA)>
<! ELEMENT ProductIdentification (#PCDATA)>
<! ELEMENT VersionNumber (#PCDATA)>
<! ELEMENT VendorName (#PCDATA)>
<! ELEMENT SalePrice (#PCDATA)>
<! ELEMENT ProducePlace (#PCDATA)>
<! ELEMENT ProduceTime (#PCDATA)>
<! ELEMENT ExpireTime (#PCDATA)>
<! ELEMENT ProductSet (Product +)>

Based on the destination index table and the encoded XML document shown above, the consumer obtains the following XML document:
<? xml version =? 1.0 ”encoding =? UTF-8”>
<! DOCTYPE ProductSet SYSTEM? ProductSet.dtd ”>
<ProductSet>
<Product>
<ProductType> XXXX </ ProductType>
<ProductIdentification> 45EF76345 </ ProductIdentification>
<VersionNumber> E3DF67 </ VersionNumber>
<VendorName> AAA </ VendorName>
<SalePrice> 1988-12-28 </ SalePrice>
<ProducePlace> 621 </ ProducePlace>
<ProduceTime> 2000-12-28 </ ProduceTime>
<ExpireTime> 2002-12-28 </ ExpireTime>
</ Product>
<Product>
<ProductType> XXXY </ ProductType>
<ProductIdentification> 45E003123 </ ProductIdentification>
<VersionNumber> 9FD56 </ VersionNumber>
<VendorName> BBB </ VendorName>
<SalePrice> 3.4 </ SalePrice>
<ProducePlace> 621 </ ProducePlace>
<ProduceTime> 2000-02-28 </ ProduceTime>
<ExpireTime> 2002-02-28 </ ExpireTime>
</ Product>
/ ProductSet>

  The present invention can be implemented in digital electronic circuitry, or computer hardware, software, or a combination thereof. The present invention is tangibly embodied in a computer program product, i.e., an information carrier, e.g., a machine readable storage or propagation signal, and executed by a data processing apparatus, e.g., a programmable processor, computer, or multiple computers. Therefore, it can be realized as a computer program for controlling the operation thereof. Computer programs can be written in any form of programming language, including compiled or interpreted languages, and include modules, components, subroutines, or other units suitable for use in a computing environment. Can be deployed in any form. A computer program can be deployed to run on one computer or on one computer or on multiple computers distributed across multiple sites and interconnected by a communication network.

The method steps of the present invention may be performed by one or more programmable processors executing a computer program to perform the functions of the present invention by processing input data and generating output. The method steps can also be performed by a special purpose logic circuit, for example, an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), and the apparatus of the present invention is used as this special purpose logic circuit. Can be realized.
Processors suitable for the execution of computer programs include, by way of example, both general purpose and special purpose computers, and any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor that executes instructions and one or more memory devices that store instructions and data. In general, a computer also includes or is operatively coupled to receive or receive data from one or more mass storage devices that store data, eg, magnetic, magneto-optical disks, or optical disks. Forward. Information alone suitable for embodying computer program instructions and data includes, by way of example, semiconductor memories, eg, magnetic disks such as EPROM, EEPROM, and flash memory devices, internal hard disks and removable disks. All forms of non-volatile memory, including magneto-optical disks and CD-ROM and DVD-ROM disks. The processor and the memory can be augmented by, or incorporated in, special purpose logic circuitry.

  In order to perform interactive processing with a user, the present invention is based on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) for displaying information to the user, a keyboard, a mouse, or a trackball. As described above, the present invention can be realized on a computer having a pointing device for supplying input to the computer. Other types of devices can be used as well to perform interactive processing with the user. For example, the feedback provided to the user can be any form of perceptual feedback, such as visual feedback, auditory feedback, or contact feedback, and the input from the user can be any form including acoustic, audio, or contact input. Can be received at.

The present invention provides a back-end component, such as a computer system that includes a data server, or a middleware component, such as a computer system that includes an application server, or a front-end component, such as a graphic user interface. Implementation on any computer that includes a web browser that allows a client computer or user to interact with embodiments of the present invention, or any combination of such back end, middleware, or front end components be able to. The components of the system can be interconnected by any form or medium of digital 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 a client and a server. A client and server are generally remote from each other and typically perform bidirectional processing through a communication network. The client and server relationship is generated by computer programs that execute on each computer and have a client-server relationship with each other.

  The present invention has been described above with reference to specific embodiments and scenes. Other embodiments also fall within the scope of the present invention. For example, the steps of the present invention can be performed in a different order and still achieve desired results. The system is flexible and provides a number of business methods for tracking items. In one method, one or more consumers subscribe to a system provided by a service provider that distributes services over a network such as the Internet. In this case, customers do not need to procure components or the entire system, thereby saving capital costs. Alternatively, the customer saves operating costs by procuring components for the entire system. Alternatively, the system can accommodate any combination of the business methods described above. For example, a customer can subscribe to the system, and a customer can procure components or the entire system.

  Other scenes also fall within the scope of the present invention. The system supports the development of a range of new and improved applications across the industry, from individual to global. Other uses of the system include supply chain management, material tracking management, security and access control, transportation, fee collection, point-of-sale information management applications, and baggage transportation. These examples are described in more detail below.

Supply Chain Management RFID systems are ideally suited for the identification of high-unit, high-value products that travel through an assembly process (eg, production of automobiles or agricultural machinery). RFID systems also provide the essential durability for permanent identification of product transporters such as boxes, transport cases, and cargo beds.
Material tracking and management Application to material tracking and management monitors the flow of equipment, people, and documents within a space such as a building, premises, or terminal, for example, tighter control of materials and items including individuals Including things that are surely tracked. Specific applications in material management include record / document tracking, person tracking, premises management, and equipment tracking.
Security and intrusion control The movement and use of valuable equipment and personnel can be related through transponders attached to or attached to equipment or people. The transponder can also be embedded within a credit card size security badge. Home security call systems and building intrusions are two examples of security and intrusion control applications.
Transportation The transponder can be attached to a vehicle (eg, aircraft, freight car, truck) and can contain important information about the vehicle and its contents. Transportation applications include aircraft identification, freight car and shipping container tracking, public transport ticketing, and weighing station applications.
Toll collection Applications for toll collection involve installing a transponder on the vehicle. The transponder sends a code identifying the prepaid balance to the reader, which automatically deducts the charge from the prepaid balance.
Point-of-sale information management These applications include electronic investigation of retail items, anti-counterfeiting, and sales transaction processing, and are often individual tags with low-cost transponders, which are essentially active tags. It involves attaching to retail items.
Baggage transport In baggage transport applications, an RFID transponder, such as a smart label, is attached to an air bag as a tag, and the passenger has his final destination since he was deposited at the airport in the air baggage handling process. Track your luggage until when you arrive.

1 is a block diagram illustrating a system according to the present invention. It is a figure which shows an example of a unique identification code. It is a block diagram which shows one embodiment of this system. It is a flowchart which shows an item introduction process. It is a flowchart which shows operation | movement of a temperature sensor device and an RFID tag. FIG. 5 is a flow diagram showing the response of the system to an event such as loading on a box carrier. It is a flowchart which shows update operation. It is a flowchart which shows an update, reading, and alarm operation | movement. It is a flowchart which shows supply operation | movement. FIG. 3 is a block diagram illustrating an alarm recognition and a scene of data flow to and from a tag. FIG. 6 is a block diagram illustrating another scene of alarm recognition and data flow to and from the tag. FIG. 6 is a flow diagram illustrating one aspect of a data flow process. FIG. 6 is a flow diagram illustrating another aspect of the data flow process. It is a block diagram which shows one embodiment of this system. It is a block diagram which shows the software component inside this system. FIG. 6 is a block diagram illustrating a mechanism for storing, changing, and querying tracking information. FIG. 6 is a block diagram illustrating property list functionality. It is a block diagram which shows the scene of a shipment. It is a block diagram which shows the scene of another shipment. It is a block diagram which shows a data restoration mechanism. It is a block diagram which shows a query response mechanism. It is a block diagram which shows a query response mechanism. It is a block diagram which shows a query response mechanism. It is a block diagram which shows a query response mechanism. It is a block diagram which shows a query response mechanism. 1 is a block diagram illustrating a large scale implementation of an infrastructure. FIG. It is a block diagram which shows a world model structure. It is a block diagram which shows a permission model. It is a block diagram which shows a world model structure. It is a block diagram which shows the parent node implement | achieved as a cluster. It is a block diagram which shows one embodiment of this system. FIG. 2 is a block diagram illustrating one embodiment using a number of hierarchically integrated engines. It is a block diagram which shows an integrated engine. It is a block diagram which shows a hardware interface. It is a block diagram which shows an electronic tag. 1 is a block diagram of the basic structure of an inventory management system implemented with an item tracking system according to the present invention. FIG. 3 is a block diagram of one embodiment using event routing. FIG. 38 is a diagram of the main structure for event routing. FIG. 4 is a protocol flow diagram for publication. FIG. 4 is a protocol flow diagram for subscription. It is a block diagram of an object naming service for locating an event router. FIG. 6 illustrates the use of an event router to distribute among multiple item tracking systems. It is a block diagram of the communication system between a producer and a consumer. 1 is a block diagram of a communication system between a producer and a consumer using a shared item tracking system. FIG. It is a flowchart of the transmission method of tracking information. It is a figure which shows the structure of an electronic product code (ePC). It is a figure which shows the shipping document which does not mask. It is a figure which shows the shipping document which masked. It is a flowchart of the filtering method of tracking information. It is a flowchart of the transmission method of tracking information. FIG. 6 is a flow diagram of a method for accessing tracking information. It is a figure which shows the system of the document used in transmission of tracking information, an index table, and an encoding document. FIG. 4 is a flow diagram of a method for checking that an appropriate index table is used to create an encoded XML document. It is a block diagram which shows an example of the information flow between customer service and another agency and business.

Claims (51)

A method of context awareness and real-time item tracking,
Receiving a number of instances of tag read data, each instance including information read from a tag associated with the item, wherein the read information is a unique read automatically from the tag; Including digital identifiers, each instance including status information including the location of the corresponding tag, and its combined item when a unique identifier is read from the tag, and multiple instances of the tag read data Including information read from tags coupled to a number of items in bulk, and
Receiving one or more instances of context information, each instance describing an associated untagged physical situation, wherein the context information indicates a status including a location of the situation; A step in which multiple instances of context information collectively include information describing a number of situations;
Using the received tag lead data and context information to retain virtual items and virtual statuses in a virtual world, the virtual items including objects of each of the multiple products, Including an object for each of the multiple situations, each of the objects representing the status of its corresponding item or situation;
Detecting an interaction occurring in the virtual world between the situation represented by the virtual item and the virtual situation and the item. The method of claim 1, wherein
By mapping information in the virtual world about the article and situation to a standardized dimension across the virtual world consisting of time, three-dimensional space, and a unique identifier, the article and situation are relative to each other in space and time. A method characterized by being traceable. The method of claim 1, further comprising:
Whenever it is determined that the detected interaction affects any of the multiple items, the method includes generating an alarm to a user of the virtual world, wherein the user is a person or a computer program. Feature method. The method of claim 1, further comprising:
Maintaining in the virtual world a representation of the current location of each of the articles and a representation of the current location of each of the situations, each of which reflects the last received tag read data and context information. A method characterized by being. 5. The method of claim 4, further comprising:
A method comprising the step of representing a position and a situation in latitude, longitude, and altitude. 5. The method of claim 4, further comprising:
A method comprising maintaining a history of position of the article and a history of position of the situation. 6. The method of claim 5, further comprising:
Obtaining a prediction of at least one future location of the article from the virtual world based on a history of the location of the article. 8. The method of claim 7, further comprising:
Obtaining a prediction of the future location based also on a history of location of the situation. The method of claim 1, further comprising:
Holding in the virtual world a representation of the current state of each of the articles and a representation of the current state of each of the situations, each of which reflects the last received tag read data and context information A method characterized by that. The method of claim 9, further comprising:
A method comprising: maintaining a history of the state of the article and a history of the state of the situation. The method of claim 10, further comprising:
Obtaining a prediction of at least one future state of the article from the virtual world based on a history of the state of the article. The method of claim 11, further comprising:
Obtaining a prediction of the future state based also on a history of the state of the situation. 9. A method according to claim 1 or claim 8, further comprising:
A method comprising associating a time stamp with each instance of tag read data and context information, wherein each time stamp is synchronized to a single standard. The method of claim 1, wherein
The non-tagable situation includes a weather situation,
A method of describing the location of the weather-related situation by at least longitude, latitude and altitude. The method of claim 1, wherein
The non-tagable situation includes a traffic accident,
A method of describing the location of the traffic accident by at least longitude, latitude, and altitude. The method of claim 1, further comprising:
Receiving one or more instances of hierarchy information, each instance describing a hierarchy between items represented in the virtual world;
Using the received hierarchy information to maintain context objects each representing one of the hierarchies in the virtual world. The method of claim 16, wherein
At least one of the tiers is a relationship between items, where some specific items are contained within another item. The method of claim 1, further comprising:
Receiving sensor information obtained from a sensor attached to the first article;
Updating a first physical object for the first article with the sensor information. The method of claim 1, wherein receiving context information comprises:
Receiving a context information instance from an external system. The method of claim 1, wherein receiving context information comprises:
Receiving an instance of contextual information, the instance comprising telemetry data from a sensor associated with a particular location. 21. The method of claim 20, further comprising:
Receiving telemetry data generated by a sensor associated with a particular point or area and representing a situation occurring at said particular point or area;
Alert the user of the virtual world when the virtual world detects that an article affected by the situation represented by the telemetry data is in the point or area represented in the virtual world And wherein the user is a person or a computer program. 21. The method of claim 20, further comprising:
Receiving temperature data generated by a sensor attached to a particular point or area and representing a current temperature of the point or area in a context object in the virtual world;
When the virtual world detects that an article affected by the current temperature is at the point or area, the article and the current temperature are represented in the virtual world to alert the user of the virtual world And wherein the user is a person or a computer program. The method of claim 1, further comprising:
Providing a temperature exception to the physical object;
Performing an action when the temperature exception is satisfied. 24. The method of claim 23.
The method wherein the action comprises generating an alarm to a user, wherein the user is a person or a computer program. The method of claim 1, further comprising:
Applying a rule to a physical object, the rule being operable to trigger a trigger event or cause an action to be performed depending on current information in the virtual world. A method characterized by that. The method of claim 1, further comprising:
Granting a rule to a context object, the rule being operable to trigger a trigger event or cause an action to be performed depending on current information in the virtual world A method characterized by that. The method of claim 1, further comprising:
Receiving, processing, and responding to a query regarding the status of the article at the present time or the past time that the article was represented in the virtual world. 28. The method of claim 27, further comprising:
If an article with a specific relationship to a specific article at the current or past time is represented in the virtual world, or if it has been represented, a query is received regarding the status of the article and a specific product. Processing and responding steps. A method for updating data on a writable tag associated with an item, comprising:
In the system, receiving first attribute information for a first item, wherein the first attribute information is obtained from data automatically read from a first tag associated with the first item The first attribute information includes a first identifier identifying the first item;
In the system, receiving second attribute information for a second item, wherein the second attribute information is obtained from data automatically read from a second tag associated with the second item. And wherein the second attribute information includes a second identifier identifying the second item;
Receiving relationship information specifying a relationship between the first item and the second item in the system;
In the system, holding the first and second virtual items representing the first and second items, respectively, wherein the object represents the first attribute information and the second attribute information, respectively, Maintaining a virtual status representing sensor information and representing the relationship between the first and second items in the system;
Recognizing alarm conditions from information in the physical and virtual situations, wherein the alarm conditions relate to the first item;
Generating update attribute information to be written to the first item in response to the alarm condition;
Detecting the presence of the first tag at a tag writer station after recognizing the alarm condition in the system;
And a step of causing the tag writer station to write the update information to the first tag when the presence of the first tag is detected in the tag writer station. 30. The method of claim 29.
The alarm condition is recognized in an application external to the system, and the application receives the system information from an object held by the system;
In response to a request to write the update attribute information to the first tag, the update attribute information is generated by the application and supplied to the system by the application.
The system causes the tag writer station to write the update information to the first tag in response to the request. The method of claim 30, wherein
The first and second virtual items represent their corresponding items in the virtual world held by the system;
The method wherein the application monitors the virtual world. 30. The method of claim 29.
The alarm condition is recognized by a component of the system that operates in response to one or more alarm rules provided to the system;
The update information is recognized by a component of the system that operates in response to one or more update rules supplied to the system;
In the tag writer station, the update information is written to the first tag in accordance with one or more write data rules supplied to the system. 30. The method of claim 29, wherein the sensor is coupled to the second tag. 30. The method of claim 29, wherein the sensor is a temperature sensor. 35. The method of claim 34, wherein
The alarm condition is generated when a temperature measured by the sensor exceeds a threshold,
The update information is a shortened product expiration date for the first item. 30. The method of claim 29, wherein the first tag is a radio frequency transponder. 30. The method of claim 29, wherein the first and second identifiers are unique identifiers. A method for performing in a commercial data processing environment, the environment comprising a number of companies in a supply chain, the method providing the company with real-time visibility of the treatment of items in the supply chain. Including the step,
Receiving a number of instances of tag lead data from a first company, each instance including information read from a tag associated with the item, the read information automatically from the tag Each instance includes a tag tag received from the first company, each instance also including the corresponding tag location when the tag identifier is read from the tag and the item associated therewith. Multiple instances of data collectively include information read from tags coupled to multiple items;
Holding treatment information about the item using the tag lead data received from the first company;
Receiving a number of instances of second tag read data from a second company, each instance including information read from a tag coupled to an item, wherein the read information is said tag Each instance includes a unique tag identifier that was automatically read from and each instance received from the second company, including the location of the corresponding tag when the tag identifier was read from the tag and the item associated with it A plurality of instances of tag lead data collectively including information read from a tag coupled to at least one of the plurality of items;
Using the tag read data received from the second company to hold action information for the item, using the tag read data received for a specific item from any of the companies Updating the treatment information, and
Visualizing the treatment information to a number of companies in the supply chain including the first and second companies. 40. The method of claim 38, further comprising:
Receiving a number of instances of third tag lead data from a third company, each instance including information read from a tag associated with the item, wherein the read information is received from the tag; Each instance includes a unique tag identifier that was automatically read, each instance also including the location of the corresponding tag when the tag identifier was read from the tag and the item associated with it, received from the third company The multiple instances of tag lead data collectively include information from a tag coupled to at least one of the multiple items;
The step of holding the treatment information about the item using the tag lead data from the third company, the treatment information using the tag lead data received for a specific item from any company Updating the method. 40. The method of claim 38, wherein
Each of the tags coupled to the multiple items includes a radio frequency identifier (RFID) tag, and each RFID tag carries an electronic product code (ePC) as a unique tag identifier. 40. The method of claim 38, wherein
The visibility is controlled visibility;
The method further comprises:
Receiving permission information indicating a range in which the treatment information is visualized for a specific company in the supply chain; and
And visualizing only the treatment information permitted by the permission information to the specific company. 42. The method of claim 41, wherein
The treatment information includes a plurality of item attributes,
The method, wherein the permission information specifies, for at least one of the item attributes, a company that can visualize the item attribute. 40. The method of claim 38, wherein
The multiple companies include a source company and a destination company,
The supplier company has an order document for an order placed by the destination company, and a shipment document for physical shipment of goods prepared to satisfy the order placed by the destination company,
Visibility includes visibility of the relationship between the tag lead data and business documents including the ordering document and shipping document,
Providing the company with real-time visibility of the treatment of the item further includes
Receiving shipping information, wherein the shipping information is
A tag identifier for the item corresponding to the approval in the shipment;
Information associating each tag identifier with a shipping number of the shipping document;
Information associating the pickup number with the order number of the order document;
Including steps, and
Correlating the tag read data with the shipping information;
Making the correlation available to the destination company and allowing the destination company to confirm the shipment using a tag identifier for the item in the shipment. Receiving a set of rules, specifying which data the rules supply to an external application;
Receiving item data including item identifiers from one or more tag readers, each item identifier being read from a digital tag coupled to a physical item, wherein the item identifier uniquely identifies the item Identify, step,
Receiving additional item data from another sensor device, wherein the other sensor device is a device other than a tag reader and the additional item data is an additional physical item other than an item identifier. Including the item attributes and relating the additional item data to one or more items identified by the tag reader;
Using the rule, item identifier, and additional item data to determine which subset of the item identifier and additional item data to supply to the external application;
Providing the external application with data comprising only the subset of the received item identifier and additional item data. 45. The method of claim 44, wherein the determination and the data supply are made in real time. 45. The method of claim 44, further comprising:
Summing the item identifier with additional item data to generate high-level data;
Providing the upper data to the external application. 45. The method of claim 44, further comprising:
Receiving data from the external application, the data comprising configuration data for controlling an actuator device;
Converting the configuration data into a format compatible with the actuator device;
Providing the converted configuration data to the actuator device. A computer program product tangibly embodied in an information carrier for item context recognition and real-time tracking,
Causing the data processing device to receive multiple instances of tag read data, each instance including information read from a tag associated with the item, the read information being automatically read from the tag Each instance includes status information including the location of the corresponding tag and its combined item when the unique identifier is read from the tag, and a plurality of tag read data The instance collectively contains information read from tags that are combined into a number of items,
Causing the data processing device to receive one or more instances of context information, each instance describing an associated untagged physical situation, wherein the context information indicates a status including a position of the situation; A number of instances of the context information collectively include information describing a number of situations;
Using the received tag read data and context information, the data processing apparatus causes a virtual item and a virtual status in a virtual world to be held, and the virtual item includes objects of each of the multiple products, A situation includes an object for each of the multiple situations, each of the objects representing the status of its corresponding item or situation;
Causing a data processing device to detect an interaction that occurs in the virtual world between the situation and the item represented by the virtual item and a virtual situation;
Computer program product that can operate like A computer program product tangibly embodied in an information carrier and updating data on a writable tag coupled to an item,
Causing the data processing apparatus to receive first attribute information about a first item in the system, the first attribute information obtained from data automatically read from a first tag associated with the first item The first attribute information includes a first identifier identifying the first item;
The data processing apparatus causes the system to receive second attribute information for the second item, and the second attribute information is automatically read from the second tag coupled to the second item. And the second attribute information includes a second identifier for identifying the second item,
Causing the data processor to receive sensor information obtained from data automatically read from a sensor coupled to a second item, and without
Causing the data processing apparatus to receive relationship information specifying a relationship between the first item and the second item in the system;
In the system, the data processing apparatus holds first and second virtual items representing the first and second items, respectively, and the objects represent the first attribute information and the second attribute information, respectively. Information and the sensor information, in the system, holding a virtual situation representing the relationship between the first and second items,
Causing the data processing device to recognize an alarm condition related to the first item from information in the physical and virtual situations;
In response to the alarm condition, the data processor generates update attribute information to be written to the first item,
In the system, the data processor is made to detect the presence of the first tag at the tag writer station after recognizing the alarm condition,
When the data processing device detects the presence of the first tag in the tag writer station, the tag writer station sends the update information to the tag writer station. A computer program product operable to be written. A computer program product tangibly embodied in an information carrier and used in a commercial data processing environment comprising a number of companies in the supply chain,
Receive a number of instances of tag lead data from a first company, each instance containing information read from a tag associated with the item, and the read information is a unique read automatically from the tag And each instance also includes a corresponding tag location when the tag identifier is read from the tag and an item associated therewith, and a number of tag read data received from the first company. An instance collectively contains information read from tags that are bound to a number of items,
Using the tag lead data received from the first company to hold treatment information about the item,
Receive a number of instances of second tag lead data from a second company, each instance including information read from a tag associated with the item, the read information automatically from the tag A unique tag identifier read, each instance also including the corresponding tag location when the tag identifier is read from the tag and the item associated with it, the tag lead received from the second company Multiple instances of data collectively include information read from a tag coupled to at least one of the multiple items;
The tag read data received from the second company is used to hold treatment information about the item, and the tag lead data received from the company about a specific item is used to perform the treatment. Update the information,
By providing a number of companies in the supply chain, including the first and second companies, with the treatment information visible, the company is provided with real-time visibility of the treatment of items in the supply chain. An operable computer program product. A computer program product tangibly embodied in an information carrier for data transfer between a sensor device and a host application,
Have the data processor receive a set of rules that specify what data to supply to the external application,
Causing the data processing device to receive item data including item identifiers from one or more tag readers, each item identifier being read from a digital tag coupled to a physical item, wherein the item identifier is the item Is uniquely identified,
Causing the data processing apparatus to receive additional item data from another sensor device, wherein the other sensor device is a device other than a tag reader and the additional item data is an additional item other than an item identifier; Including the physical item attributes, wherein the additional item data is associated with one or more items identified by the tag reader;
Using the rule, item identifier, and additional item data to determine which subset of the item identifier and additional item data to supply to the external application;
A computer program product operable to cause the external application to supply data comprising only the subset of the received item identifier and additional item data.

Images