System and method for visualizing auto-identification data

The present invention relates to processing auto-identification data, and more particularly to systems and methods for visualizing auto-identification data.

Auto-id systems are used, for example, to identify or otherwise obtain information about products used in manufacturing, purchasing or selling, shipping, or other commercial transactions. Information about physical objects, such as boxes in the back room, is stored in association with the tags attached to the boxes and other identifiers, and / or the objects tagged with unique identifiers. It may be placed on the shelves of retail stores. And certain devices, such as readers or sensors, may be used to identify physical objects by accessing identifiers. It then uses information stored in the computer system that corresponds to the object, such as the brand name of the object or the expiration date of the object.

An example of an auto-id system is known as an RFID (Radio-Frequency Identification) system. RFID generally refers to a technique in which a unique number (and / or other identifying information) is stored on a microchip associated with an RFID tag or transponder-coupled antenna. The reader is used to communicate with the antenna and obtain a unique number from the microchip, thereby obtaining information related to the unique number. Advantageously, RFID is fast and wireless, does not require direction or line-of-sight to enable communication between readers and tags, and reduces or eliminates the need for humans to enter data. As a result, RFID can identify, for example, tagged objects in stores or warehouses, automatically pay tolls by car with RFID tags, and / or identify authorized persons for admission to restricted areas. It can be used in many applications of.

There are many types of auto-id systems. Examples include 2D barcode scanners, smart card devices / readers, optical character recognition systems, and biometric systems (eg, retina and fingerprint scans). Many or all of such systems reduce costs, increase efficiency, improve data accuracy, and provide higher resolution data (up to a single item / object), thereby enterprises. Improve customer satisfaction in system operation.

<p> However, one problem with auto-id is that it may potentially require a huge amount of information. For example, a large number of readers may access the auto-id from more identifiers. Moreover, each identifier may have relevant information about the particular object to which they are attached. To increase the severity of this problem, the data associated with each identifier may change over time. Thus, large datasets may even grow larger over time. While such large datasets may contain useful information for performing a wide variety of tasks, it is difficult to present such large amounts of data in a meaningful way to the user. Therefore, it would be advantageous to develop a technique for displaying and visualizing auto-id data.</p><p> Thus, the display and visualization of auto-id data needs to be improved. The present invention solves these and other problems by providing systems and methods for visualizing auto-ids.</p>

<p> Embodiments of the present invention improve the visualization of Auto-ID data. In one embodiment, the invention stores a plurality of tag identifications, each tag identification stores a plurality of positions associated with at least one position, and each tag identification is one or more. To store information with multiple attributes related to an attribute, to generate a hierarchy based on at least one position or at least one attribute related to multiple tag identification, and as a nested shape corresponding to the hierarchy. Includes a method of processing auto-identification data that comprises displaying at least a portion of the information associated with each tag identification and at least a portion of the location.</p><p> In one embodiment, multiple nested shapes at the first hierarchy level correspond to positions, and there at least one shape nested within at least one position corresponds to an object with attached tag identification. To do.</p><p> In one embodiment, the stored information includes multiple time stamps, wherein the object is displayed at multiple positions at the first hierarchical level that depict the movement of the object over time.</p><p> In one embodiment, the lowest hierarchical level of the nested shape comprises filling with at least one of the above attributes.</p><p> In one embodiment, the filling comprises different colors, patterns, or shadows to distinguish between different values of at least one attribute.</p><p> In one embodiment, the filling corresponds to the utilization of the asset at the location.</p><p> In one embodiment, the method further comprises filtering or aggregating the information.</p><p> In one embodiment, the method further comprises storing multiple timestamps and displaying a time slider to allow the user to see changes in position or attribute values at different times. Be prepared.</p><p> In one embodiment, the hierarchy comprises multiple positions.</p><p> In one embodiment, the hierarchy comprises a plurality of properties of a plurality of objects related to the stored tag identification.</p><p> In another embodiment, the invention uses receiving multiple tag identifications, receiving multiple position identifiers, each tag identification associated with at least one position identifier, and using at least one tag identification. , Information about an object related to at least one identifier, associating a position with information that contains multiple attributes, generating a hierarchy based on at least one position or at least one attribute, and making a hierarchy Includes a method of processing auto-identifying data, including displaying at least a portion of the information and position as the corresponding nested shape.</p><p> In one embodiment, the nested shape is associated with a weight that determines the size of the nested shape.</p><p> In one embodiment, the weight is calculated based on at least one attribute associated with tag identification.</p><p> In one embodiment, the hierarchy comprises a plurality of hierarchically related positions or hierarchically related attributes.</p><p> In one embodiment, the plurality of nested shapes at the first hierarchy level correspond to positions, where at least one shape nested at at least one position corresponds to the object possessed by the attached tag identification. ..</p><p> In another embodiment, the invention stores a plurality of tag identifications, each tag identification stores a plurality of positions associated with at least one position, and each tag identification is one or more. Performs an auto-identification data processing method that comprises storing information with multiple attributes related to multiple attributes and displaying at least a portion of the information and at least a portion of the location as a tree map. Includes computer-readable media containing instructions for controlling computer systems.</p><p> In one embodiment, the treemap contains multiple nested shapes at the first hierarchy level corresponding to the position, where at least one shape nested at at least one position is an object with attached tag identification. Corresponds to.</p><p> In one embodiment, the method further comprises storing multiple time stamps and displaying a time slider to allow the user to see changes in position or attribute values at different times. ..</p><p> In one embodiment, the treemap comprises filling with at least one of the above attributes.</p><p> In one embodiment, the treemap comprises multiple nesting shapes with associated weights that determine the size of the nesting shape.</p><p> Embodiments of the present invention improve the visualization of auto-id data. In one embodiment, the invention stores a plurality of tag identifications, each tag identification stores a plurality of positions associated with at least one position, and each identification stores one or more attributes. Storing information with multiple attributes related to, generating a hierarchy based on at least one position or at least one attribute related to multiple tag identification, and each as a nested shape corresponding to the hierarchy. Display at least part of the information or at least part of the location related to tag identification.</p><p> In one embodiment, multiple nested shapes at the first hierarchy level correspond to positions, where at least one shape nested within at least one position corresponds to an object with attached tag identification.</p><p> In one embodiment, the stored information includes a plurality of time stamps, wherein the object is displayed at a plurality of positions at the first hierarchical level in order to depict the movement of the object over time.</p><p> In one embodiment, the lowest hierarchical level of the nested shape comprises filling with at least one of the above attributes.</p><p> In one embodiment, the filling comprises different colors, patterns, or shadows to distinguish between different values of at least one attribute.</p><p> In one embodiment, the filling corresponds to the utilization of the asset at the location.</p><p> In one embodiment, the hierarchy and its filling are specified by the user.</p><p> In one embodiment, the method further comprises storing multiple time stamps and displaying a time slider so that the user can see changes in position or attribute values at different times.</p><p> In one embodiment, the hierarchy comprises multiple positions.</p><p> In one embodiment, the hierarchy comprises a plurality of properties of a plurality of objects related to the stored tag identification.</p><p> In another embodiment, the invention uses receiving multiple tag identifications, receiving multiple location identifiers, each tag identification associated with at least one position identifier, and using at least one tag identification. , Information about an object related to at least one position identifier, relating a position to information containing multiple attributes, generating a hierarchy based on at least one position or at least one attribute, and Includes a method of processing auto-identifying data that comprises displaying at least a portion of the information and position as the corresponding nested shape.</p><p> In one embodiment, the nesting is related to the weights that determine the size of the nesting.</p><p> In one embodiment, the weights are calculated based on at least one attribute associated with tag identification.</p><p> In one embodiment, the hierarchy comprises a plurality of hierarchically related positions or hierarchically related attributes.</p><p> In one embodiment, the first layer level nesting shape corresponds to a position, where at least one shape within at least one position corresponds to an object having an attached tag identification.</p><p> In another embodiment, the invention stores a plurality of tag identifications, each tag identification stores a plurality of positions associated with at least one position, and each tag identification is one or more. Performs an auto-identification data processing method that includes storing information with multiple attributes related to multiple attributes and displaying at least a portion of the information and at least a portion of the location as a tree map. Includes computer-readable media containing instructions for controlling computer systems.</p><p> In one embodiment, the treemap contains multiple nesting shapes within a first hierarchical level corresponding to a position, where at least one within at least one position corresponding to an object with attached tag identification. The shapes are nested.</p><p> In one embodiment, the method further comprises storing multiple time stamps and displaying a time slider to allow the user to see changes in position or attribute values at different times. ..</p><p> In one embodiment, the treemap comprises filling with at least one of the above attributes.</p><p> In one embodiment, the treemap comprises a plurality of nested shapes with related weights that determine the size of the nested shape.</p><p> In another embodiment, the invention further stores a server for receiving multiple tag identifications and related locations, each tag identification associated with at least one location, and information that the database has multiple attributes. And combined with a repository for storing multiple tag identifications and locations, each of which is related to one or more of the above attributes, and a repository for accessing tag identifications, locations, and information. An auto-id data processing system that includes a visualization software system that includes an auto-id data processing system that displays at least a portion of information or at least a portion of its location as a tree map.</p><p> In one embodiment, the treemap contains multiple nested shapes at the first hierarchical level corresponding to a position, where at least one shape nested within at least one position has an attached tag identification. Corresponds to the object.</p><p> In one embodiment, the visualization software maps information in the repository to a display.</p><p> In one embodiment, the visualization software includes an aggregator component, a filter component, a time navigation component, and a tracking component.</p><p> The following detailed description and accompanying drawings provide a better understanding of the essence and benefits of the present invention.</p>

What is described here is a technique for displaying automatic identification data. The following description is for illustration purposes and provides a number of examples and specific details to provide a thorough understanding of the present invention. However, for those skilled in the art, the invention may include some or all of the features in these examples alone or in combination with other features below, as defined in the claims. It will be apparent that additional modifications and equivalents of the features and concepts described may be included. Embodiments of the present invention can be stored in computer-readable media that are implemented in software and include instructions that control a computer system to perform the methods of processing auto-identifying data below.

FIG. 1 is a network diagram of the auto-id system 100. In FIG. 1, multiple enterprise applications 102, 104, 106, and 108 may include data visualization components for intuitively displaying auto-id data. The application may include a supply chain management application 102, an asset tracking and management system 104, a warehouse management application 106, and an analysis system 108, as in the example. Supply Chain Management 102 may be used by a company to monitor manufacturing, purchasing, shipping, or sales of a company's products or services. The asset tracking and management system 104, for example, within a site, organization, or between organizations, determines which assets (eg, inventories) are available, unavailable, or desired by an entity. Alternatively, it may be used to monitor and track a large number of assets. Warehouse management application 106 may be used to oversee warehouse acceptance, inventory, selection, and shipping aspects. Analytical system 108 may also be used to quantify aspects of business operations, such as quick response to customer requests, loss due to theft, corporate profits or other factors that may affect management. Good. Given the large amount of auto-id data in such systems, the data visualization software and techniques described here may be used to analyze auto-id data quickly and efficiently.

In Figure 1, the auto-id information is obtained by the application through the use of middleware infrastructure 110 that implements the auto-id system that automatically retrieves, stores, shares, and uses the auto-id information. .. The auto-id system supports the automatic collection and use of information, such as information about products sold or used by businesses, and includes an identifier (eg, a tag) and a reader that retrieves information about the identifier. In FIG. 1, examples of auto-id elements include a barcode reader / printer 112 that can be used to read or print barcode labels attached to objects. RFID reader / printer 114 is shown, which may be used to read or assign information from RFID tags attached to objects. RFID tags may include either passive or active tags. The reader position may be used to provide the tag position. Sensor 116 may also refer to, for example, an environmental sensor (eg, a thermometer), a voice, or an optical character recognition sensor. Mobile reader 118 refers to a reader that can be carried by the user to sense RFID tags or other auto-id identifiers. Finally, in Figure 1, a PLC (Program Logic Controller) device represents a digital controller used for applications such as on / off control, timing, logic, counting, and sequencing. Other devices, such as biometric devices, can also be included.

The example enterprise application in Figure 1 illustrates the potential need for an enterprise to collect, share, and use auto-id data from the entire system. For example, the supply chain management system 102 may need to know how much certain assets are currently available, based on the data in the asset management application 104. Analysis system 108 is a general example of performance issues (such as warehouse usage, reasons for delivery delays, or to ensure product progress through the supply chain), issues (such as product counterfeit patterns), and physical objects. Data can also be extracted from the auto-id middleware 110 and from other applications 102, 104, or 106 to discover good visibility (goods, cases, loading platforms). The analysis system 108 may report the results found, for example, through a portal system using the visualization techniques described herein.

Information obtained by any auto-id device / system 112-120 may be communicated, shared, and used with any enterprise application 102-108, as shown in Figure 1. In this way, an entity can obtain and use essentially real-time information throughout its range of operations. In addition, a company may share information with other companies. For example, the supply chain management application 102 can be associated with a first company (eg, a retail store) and the warehouse management application can be associated with a second company (eg, a manufacturer). By retrieving information from auto-id devices / systems 112-120 and sharing this and other information across the middleware infrastructure 110, both of these companies can streamline their operations. it can.

FIG. 2 shows an auto-id system that can be used to visualize auto-id data according to one embodiment of the invention. The auto-identification (auto-id) system 200 includes an object 210 tagged with 220. Object 220 can be, and is not limited to, any of a variety of objects, including, but not limited to, store goods, company assets (eg, computers or medical devices), or even people. For example, tag 220 may be an RFID tag and includes an identification stored electronically within the tag. A reader 230 located within the range of the tag 220 may use a radio signal to receive tag identification (tag ID) from the tag. The reading process by the reader 230 may be started, for example, by a reading request. In some embodiments, the reader 230 may also be able to write (print) information on the tag 220. Since the position of the reader is usually known, the received tag ID can be associated with a known position of the reader 220. When the reader issues a read request, all tags within the reader's range can return their tag IDs. Thus, the reader 230 can receive a large number of tag IDs from different tags, which may result in the location of the reader associated with multiple tag IDs. The tag ID received by the reader 230 can be transmitted to the server 230 and then the tag ID's can be stored in the storage facility. In one embodiment, the tag ID and location are stored in one or more databases 250. Since the tag ID is associated with a particular object, other information about the object is also stored. In one embodiment, the tag ID, location, and attributes of each object are stored in a database table, such as tables 251 and / or 252 in database 250.

The system application described in FIGS. 1 and 2 may receive and store a very large number of tag IDs from a large number of readers located over a wide range of locations. This may result in a large amount of data being generated as a result of the implementation of the auto-id system. In addition, the system can store hierarchical data at different points in time. As mentioned above, using this information can be challenging. In one embodiment, the present invention provides a data visualization software component 260 that organizes auto-id information into hierarchies and displays the information in an intuitive format hierarchy that includes nested shapes to show the hierarchical relationships of the data. Including.

3A-C show the auto-id hierarchy according to one embodiment of the present invention. Figures 3A-B show a hierarchical visualization of data in a nested structure known as a treemap. Treemap visualization represents information hierarchically in multidimensional mapping. In this example, the nested squares are used to represent a two-sided hierarchy. Please understand that other shapes can be used. The highest level of the tree hierarchy for node 310 in FIG. 3A may be represented in the treemap as the outer frame 310 in FIG. 3B. The other tree levels 320 and 330 in Figure 3A in the tree hierarchy are represented by the inner frame of the treemap in Figure 3B. For example, at second level 320, the three information nodes 321, 322, and 323 in FIG. 3A are represented by the rectangles 321, 322, 323 in FIG. 3B nested within the rectangle 310. Similarly, at second level 330, the three information nodes 331, 332, 333 in FIG. 3A are represented by the rectangles 331, 332, 333 in FIG. 3B nested within the rectangle 322. The tree hierarchy may be specified by the user according to various different requirements. In some embodiments, the hierarchy may be changed interactively to view the data in different ways.

In one embodiment, the treemap transforms the data in the table using various weights and labels. Node weights may be determined by the numerical data associated with the tag ID. Such data may be used to determine the size of the shape of the treemap node boundaries (eg, the size of a rectangle). Node weights may determine the display size and can be used as a measure of the importance or degree of interest. In another example, the treemap visualization may follow a list of properties to transform the hierarchy into a visual display. For example, if node 310 is an ancestor of node 320 (ie, a node at hierarchy level 320 is a subnode of node 310), the shape of the node 310's boundary completely encloses the node 320's boundary box. The shape of the boundary between two nodes may intersect when one node is an ancestor of the other. For the purposes of the example, this example divides the space to draw a hierarchy and shows the sides of a rectangle that spans the hierarchy levels. Further, the weight of a node can be greater than or equal to the total weight of its children. In addition to setting the shape of the node boundaries, you may also set other display properties such as color (tone, color, brightness), shape, shadows, patterns, and boundaries. In some applications, color may be an important visual property. Because it's a fast and accurate way to get information and make decisions. In one embodiment, the display may be implemented by mapping content information such as position, attribute value, tag ID, etc. to display the property. For text-based data rather than pneumatic-based data, colors can be assigned to distinguish unique fields.

FIG. 3C shows an auto-id method according to an embodiment of the present invention. At 301, the system stores the tag ID (auto-id). For example, the tag ID may be retrieved by the reader and stored in one or more database tables. At 302, the position associated with the tag ID is also stored. For example, the tag ID received by a particular reader may be associated with a known location of the reader, and the location and tag ID may be stored in a database. In 303, the information associated with each tag is also stored. For example, when a tag ID is received, the ID may be used to query data from the database to get information about the tagged object. The position of the object may be stored with such information. In one embodiment, information about each object may be stored as multiple attributes (eg, database records). Attributes such as the object's name, model, price, or other useful attributes are associated with the tag ID.

At 304, a hierarchy is created. The hierarchy can include the position associated with the tag ID, the value of the attribute, or both. For example, the tag ID may be associated with a location such as "Room 3471D", which could be, for example, the location of the reader who received the tag ID. Such a room may be in the west wing on the third floor of the eastern area of the county hospital. This may create a hierarchy with "county services" as the top (or root) node of the hierarchy. "Hospital" may be one of the subnodes under "County Services". The "eastern area" is a subnode of the "hospital" and the "third floor" is a subnode of the "eastern area". "West Wing" is a subnode of "3rd floor", and "Room 3471D" is a subnode of "West Wing". As explained in the previous example, positions can be used to generate hierarchies, but it should be understood that other information can be used to generate hierarchies. In another embodiment, the hierarchy can be a plurality of properties of the object associated with the stored tag identification. For example, the tag ID may be attached to a mobile phone owned by the company and tracked as an asset. If the reader reads the tag ID, that ID is used to retrieve the information, which can include the "device type" attribute set on the "mobile phone", and therefore the "mobile phone" , Can be one level of hierarchy. The company may distribute many types of mobile phones to employees, such as Motorola®, Nokia®, or other manufacturers. These manufacturer descriptors may be subnodes of "cell phone" nodes in the hierarchy. In addition, the "mobile phone" may be a subnode of the "communication equipment" node, the "communication equipment" node may be a subnode of the "electronic equipment" node, and the "electronic equipment" node may be a subnode of the "company assets" node. unknown. These examples can specify most useful hierarchies and organize auto-id data It shows that it can be used to make it. At 305, the hierarchy may be displayed, for example, as a treemap using the nested shape shown in FIG. 3B.

FIG. 4 shows a method of displaying auto-id data according to an embodiment of the present invention. At 401, the tag ID is retrieved, for example, by a reader. In 402, the position identifier (position ID) is associated with the tag ID. The position ID is used to determine the position of the reader detected by a specific tag ID. Since the tag ID is associated with the reader's location, some of this information may be used to associate all the information about a particular object that the reader has attached to a particular location. The location ID may be a known location of the reader from which the tag ID was retrieved. Alternatively, the location ID may be a code such as a reader ID, which code may be used, for example, to search for the location of the reader. Once the tag ID and reader position specifiers have been determined, some of this information may be used to correlate information about the tagged object. For example, at 403, information may be accessed based on tag ID. For example, the tag ID may be received by the server and used as query input to the database. Information about the tag may be retrieved in response to the query. In one embodiment, the tag ID is used to access information in the database that corresponds to the particular object to which the tag ID is attached. As shown in 404, attributes can be associated with their respective tag IDs (for example, the name, position, time, and other useful properties of the tagged object), and different attributes will differ over time. Can take a value. As shown in 405, the position may be an attribute associated with the tag ID. For example, if the location ID is the number corresponding to the reader, the location ID may be entered first in the query to retrieve information about the reader. The position of the reader may be stored as an attribute of the reader, such a position is accessed and is the position of the tag ID. It may be applied to the device. At 406, the information may be organized hierarchically. For example, as described above, the hierarchy may be based on position and / or attributes. In 407, the hierarchy is displayed as multiple nested shapes (eg, rectangles or squares). In 408, "filling" is associated with one or more shapes based on the information corresponding to the tag ID. For example, a shape may be "filled" with a different color, shadow, pattern, or other visual identifier with any type of information. An example is shown below in more detail.

FIG. 5 shows an auto-id data visualization software system according to an embodiment of the present invention. Data visualization software 510 concatenates with a repository 520 of stored auto-id information, including information corresponding to identifiers (ie, referred to as auto-ids or tag IDs), locations, and objects with identifiers. Has been done. The visualization software 510 is used to perform various actions on the auto-id, including a filtering component 511, an aggregator component 512, a tracking component 513, a time navigation 514, a mapping component 516, and a hierarchical component 517. Can include software components. The visualization software 510 can include various other components for implementing the features and functions described herein.

The filtering component 511 may be used to filter the data based on user preference. For example, the user may specify a range of numerical data to be displayed (for example, top W rank, top X%, or between Y and Z). The filtered data may be grayed out or hidden from the view, for example. For database data, input form elements (checkboxes, radio buttons, text boxes, etc.) can be used to limit visual display.

The aggregator component 512 allows data to be displayed in two types of resolutions, aggregated and non-aggregated. When the data is aggregated, each individual asset may not be visible. Instead, an aggregate representation is shown. Numerical data can be aggregated in a variety of ways, including mean, mean, maximum, minimum, or total, to name just a few cases. Text-based data can be aggregated, for example, by count. Count-based aggregations may be represented by steps. Aggregated visualization of auto-id data allows users to dig into aggregated data types, as data can be aggregated by location, storage type, or device type. By visualizing auto-id data, including location or other information, the auto-id information can be aggregated and the position average, maximum, or minimum can be displayed.

The example in Figure 5 further illustrates the time navigation component. In some embodiments, time data (here a time stamp) may be stored with information about tag IDs, locations, and other objects. For example, when a reader accesses a tag ID, the reader may return a time value to specify the time when the tag ID was detected by the reader. As objects move between different positions, hierarchical data may indicate that a particular object was in different positions at different times. In one embodiment, more detailed below, the time slider may be used to allow the user to view information at a particular point in time. The position of an object at a particular time will also be indicated based on the position of the time slider.

Embodiments of the invention may also include tracking component 513. Tracking, such as asset tracking, may track objects over time and location, for example. Objects may be tracked at different times across different locations, as treemaps provide users with the ability to filter, aggregate, and manipulate data over time. In one embodiment, a flag or other visual identifier can be applied to a treemap node to mark an asset. Since objects move over time, visual identifiers make it easy to identify the movement of an object.

The other two components of the data visualization software system 510 include a mapping component 516 and a hierarchical component 517. Hierarchical component 517 may access the specified auto-id data in repository 520 to build the hierarchy. Hierarchies may, for example, be specified by the user (ie, based on location or other information) or programmed into the system as part of an application. As mentioned above, the mapping component 516 is used to map the information in repository 520 to the display. Mapping component 516 may leverage the functionality contained in other components to generate a displayed visualization of the data. Mapping 516 implements visualizations for different calculated data types, such as lost or misplaced objects, failure rates, uptime, years, migration rates, or various other useful information. You may. For example, a system may include a predicted location, which may compare the predicted location with the actual location to determine if an asset has been misplaced or lost. Mistaking for losing an asset can be highlighted by color or used for filtering. As another example, the system may track device failures. Failures may be tracked by ranking (eg, the most failed device) and / or probability (eg, the percentage of failures of a type of device). As an example, the application may calculate asset failure rankings and percentages. Rankings and percentages may be used as input variables for treemaps. This information can be displayed visually via the size of the nest and / or the color or shadow display scheme. The dataset can also be filtered, for example, based on failure.

In one embodiment, the data may also be accessed to determine utilization. From this dataset, the application may extract the rank and rate of assets used. The top-to-bottom ratio of assets may be used, for example, as data entry for treemaps. Utilizations can be displayed, for example, through nested, size, color, or shadow. Usage data can also be used for filtering. Table 1 shows other properties that may be displayed by other embodiments of the present invention.

<tables num="1"><img file="JP2007122688A_D0001.tif" /></tables>

The features and advantages of the present invention can be more easily understood through the specific examples that follow. First, an example of the present invention applied to a healthcare application will be presented. Figure 6A is an example of a display of hospital equipment utilization across multiple departments. The size of each square is about the same. Each square corresponds to one of the specific fixtures including wheelchairs, colposcopes, syringe pumps, ultrasound, walkers, stretchers, hearing aids, crutches, IV pumps, inhalers and more. The pattern assigned to each square is related to the utilization of one of the particular fixtures. Utilization rates range from pattern 601 (low utilization of 20% or less) to pattern 604 (high utilization of 90% or more). In other embodiments, different colors or shadows (eg, shades) may be used to indicate different utilization rates. From this figure, the equipment manager of the hospital in the clinical medical school can identify the utilization rate of various positions, for example. By combining location and utilization, managers can decide whether low utilization equipment should be moved to higher utilization areas. For example, a second obstetric wheelchair may be moved to the ER. This is because the ER has only one wheelchair for high utilization. The second wheelchair is in use in obstetrics, as marked by the pattern.

FIG. 6B is an example of aggregation according to another embodiment of the present invention. Information may be aggregated at one or more levels of the hierarchy, as shown in Figure 6B. In this example, the asset utilization in 610 ER, 611 radiology department, 612 room, 614 clinical engineering, and another room upstairs is to show the average asset utilization at each location. , Each was aggregated.

Figure 7 is an example of displaying the status of hospital equipment across multiple departments. Conditions include 701 available, 702 under maintenance, or 703 in use. The squares are about the same size and the pattern is related to the condition of the equipment. Pattern 701 includes that the item is available, pattern 702 includes that the item is under maintenance, and pattern 703 includes that the item is in use. For example, if a hospital equipment manager receives an IV pump call from a nurse, it is easy to see which available pump is closest to the nurse. By combining location and condition, the manager can determine the overall condition of the equipment across the hospital. An overall view of the hospital's equipment status will allow equipment managers to make accurate choices about whether to purchase equipment or rent equipment. If a type of equipment is used frequently or is under constant maintenance, the equipment manager can decide whether to rent or buy more equipment.

FIG. 8 is an example of display according to another embodiment of the present invention. This example shows the same information as in Figure 7, where the hierarchy has been modified so that the data is grouped by equipment type, department, and part, rather than grouping the data by floor, department, and equipment. .. This change will allow equipment managers to view the condition of equipment by type of equipment, thereby facilitating easier identification of available equipment.

FIG. 9 is an example of a display that tracks an object over time according to another embodiment of the invention. This example visualization shows how an asset moves over a period of time. In one embodiment, a particular object may be associated with a visual identifier, such as a flag. For example, surgical upstairs syringe pumps and IV pumps may be associated with, for example, flags 910 and 911, and ER (emergency emergency room) first floor wheelchairs may be associated with flag 912. In one embodiment, the flag may be associated with a different color, such as orange 912, red 902, yellow 903. These colored flags may be placed on a particular asset that the user wants to track. Further, in one embodiment, the time sliders shown in 904 and 905 may be used to browse information at different times. For example, the information associated with each auto-id may include, for example, a time stamp that may be used to indicate the time an object is at a location. Here, the visual time slider 904 is set at 2:00 pm on October 20, 2005. Therefore, at this point, the marked syringe pump 910 and IV pump 911 are shown in the second floor surgery and the marked wheelchair 912 is shown in the first floor ER. The flag was still associated with those given equipment, but the wheelchair had been moved to the hospital room on the third floor. This visualization of RFID information makes it easy to see how equipment has moved over time. Also, the condition of equipment changes over time. The wheelchair was "usable" at 2 o'clock. At 2:30 pm, the wheelchair indicates "in use". Therefore, an object may appear at multiple positions on a first hierarchy level (eg, across different floors) to indicate changes in the state (eg, movement) of the object over time.

FIG. 10 is an example of a display that tracks an object over time according to another embodiment of the invention. In this example, a single object is shown in a single display at different times. For example, a time range may be specified and information for a particular object may be shown as it changes over time. At 1010, the wheelchair may have been on the second floor of the Department of Clinical Engineering on Monday in a "maintenance" state. On Tuesday 1011, the wheelchair may be on the ground floor of the ER in a "usable" state. On Wednesday 1012, the wheelchair may be on the third floor of the hospital room. On Thursday, 1013, the wheelchair was moved again to the ground floor of the Department of Radiology. The ability to track equipment movement and condition over time allows equipment managers to view equipment activity from a high level perspective. It also allows the user to identify problems and issues by checking the history of equipment movements.

FIG. 11 is an example of a display showing the arrangement of equipment over different positions according to another embodiment of the present invention. Figure 11 shows the placement of laptops across multiple rooms at a conference. The size of each square is proportional to the price of each laptop, and the pattern shows the different processing speed of each laptop. This visualization allows IT (Information Technology) event managers to easily see which room has what type of laptop. For example, a conference room may have different requirements: That is, room B23 does not require a high speed laptop, all the remaining rooms need to have a laptop with a processor of at least 1GHz, one laptop per room is used as a projector, which has a low processing speed. It's fine. With these requirements in mind, the visualization of auto-id data is that room B32 has a processor of 600MHz and the processors in rooms B73 and C13 are at least 1GHz, so these rooms have lower processing. Show the user that they can have at least one of those laptops exchanged for speed.

Similarly, other embodiments of the invention are used to identify misplaced objects, track the degree of movement, identify the age of an object, or determine the read rate by an auto-id reader. You may. For example, the size of each square in one embodiment may be the same for all laptops. The pattern or color associated with each square may indicate all laptops that are currently misplaced (for example, an auto-id reader may have an object that is far from where it should be. Detect.). For example, if a laptop is expected to be in a room, but is placed elsewhere or not recorded by any reader, the square corresponding to the laptop will be highlighted. It will be patterned or indicate that the laptop has been misplaced. Therefore, IT event managers can easily see which laptop is currently misplaced. Similarly, objects may be associated with a degree of movement. For example, the pattern or color used to fill a square on the screen may be proportional to the movement level. A particular pattern or light tint may indicate that the object has often not been moved, while another pattern or dark tint may indicate that the object has often been moved. In other embodiments, the age of the asset can also be distinguished by a pattern or shade of color. For example, lighter green may be used to indicate newer assets and dark gray may be used to indicate older assets. Years visualization allows IT event managers to distinguish between older laptops and the depreciated value of laptops by their color. Decisions on the placement of older assets may also be made through the facility. In another embodiment, read rates may be monitored to identify potentially problematic auto-id components. For example, the read rate is in color Or it may be associated with a pattern and displayed in a treemap. From the treemap, IT event managers can identify problem leaders and laptops by location. Since the objects are grouped by position, the position of the dark colored cells may indicate, for example, a dysfunctional leader.

FIG. 12 is an example of filtering in another embodiment of the present invention. In some embodiments, some of the data associated with auto-id is displayed while other data is hidden from the view to allow the user to focus on certain attributes of the data. May be. For example, in one embodiment, the data may be filtered to show the operator the missing or misplaced assets. For example, laptops may be placed in various rooms of the conference center. The size of each asset is displayed in proportion to the cost, and the color or pattern may be associated with different operators. This visualization allows IT event managers to identify the location and responsibility of missing assets. From this view, the user can also identify an individual who mishandles a large amount of assets.

As in another example, a treemap may show the placement of customer tools in multiple contract manufacturing plants. For example, one contract factory may manufacture products for different customers. Each customer-manufactured job may require different tools (for example, tools for job A / customer A, job B / customer A, job A / customer B, etc.). The tool may have an auto-id, whereby the location of each tool may be determined within the factory facility and the ID of each tag may be associated with the job and / or customer. The top level of the treemap corresponds to the company, and the first level corresponds to the manufacturing facility. Lower levels may specify a particular location for each facility. The size of each shape in the treemap hierarchy may represent the cost of the asset, and the color or pattern may represent the customer. So if the user wants to locate all the tools needed in Job F / Customer Z, the user filters the treemap and interacts to the level needed to identify the desired tool location. You may move in the format. Thus, for example, an accounting manager can identify a facility that currently contains the assets of a particular customer and plan the execution of a job.

In another embodiment, the filter may be set to indicate a failure rate with equipment. For example, the visualization may identify the top% or top ranked faulty assets. The size of the treemap shape may represent the cost of the asset, and the pattern or color may represent the type of asset (for example, manufacturing plant tools). For example, only the shapes corresponding to the top 10 with the highest failure rates or the top 5 with the highest failure assets may be shown. Thus, the tool manager can identify, for example, the top 10 failed tools. From this visualization, the user can determine that a particular asset requires a large investment that is prone to failure.

In yet another embodiment, filtering can be used to identify missing assets according to safety level. For example, some assets (tools or raw materials) in a manufacturing plant may be more dangerous to employees than others. Such items may contain auto-ids that can be associated at a secure level in the database. This information, along with the location information obtained during the read, may be used to visualize the dangerous assets of the facility. For example, treemap visualizations may identify missing assets with the highest level of security. The size of the shape of each treemap may represent the cost of the asset, and the color or pattern may represent the level of safety. Filtering is limited to the highest security level (for example, 1 represents the safest asset, 5 represents the most dangerous asset class, 1-5 classes of safety levels 4 and 5). The assets that have been used may be used. From this calculation, the tool manager can identify the missing tools at safety levels 4 and 5. From this visualization, the user can determine which assets should be identified immediately due to potential harm to employees. The user can also identify, for example, the location with the most missing asset (eg, a manufacturing facility).

Illustrated auto-id infrastructure.

FIG. 13 is a block diagram of an example of an auto-id system. In FIG. 13, enterprise application 1302, as well as various other enterprise applications, may include the various applications 102-108 of FIG. 1 discussed above. One or more of these applications may include visualization components that perform the techniques described above for visualizing auto-id data.

The auto-id infrastructure 1304 may represent, for example, some or all of the middleware infrastructure 110 in Figure 1. Specifically, the auto-id infrastructure 1304 includes auto-id nodes 1306, 1308, and 1310. The auto-id nodes 1306, 1308, and 1310 generally represent nodes in defined locations designed to associate the information obtained by the auto-id device 1318-1326 with existing business logic or data. In addition, auto-id nodes 1306, 1308, 1310 may be used to store historical information for products or objects that have been tracked by autoid device / system 1318-1 326. Such historical information has been collected and combined for the desired purpose, for example, state information at a particular time, the location of the object, and the tracked object or environmental information associated with the particular location. May contain information for multiple objects.

The auto-id nodes 1306, 1308, and 1310 may be strategically deployed throughout the enterprise or across multiple enterprises. For example, one or more auto-id nodes 1306 may be located at the location of manufacture, while auto-id1308 may be located at the location of retail product distribution, and auto-id node 1310 may be located at the retail store. It may be positioned in. In addition, one or more auto-id nodes can be provided to raw material suppliers, manufacturing plants, manufacturing distribution centers, and transportation service locations. As described above, the information specific to the actual setting of the auto-id node may be acquired and retained only in the specific node.

For example, a retail store's auto-id node 1310 may be used to track the retail price of an item, or the number of items on a retail store's shelves. Such information may not be useful for the auto-id node 1306 at the manufacturing site, but may be partially useful for the auto-id node 1308 at the retail distribution location. For example, the auto-id node 1308 in a retail distribution location may not be interested in the retail price of an item, but may be interested in the number of items currently on the shelf (for restocking purposes).

Similarly, business processes and business logic in different locations, such as the visualization software above, may benefit from the use of local auto-id nodes 1306, 1308, and 1310. For example, retail auto-id node 1310 can include workflows to prevent object theft, while manufacturing auto-id node 1316 monitors the amount of objects manufactured over a period of time. You may be interested in that. Thus, the use of a distributed network of localized auto-id nodes allows the system 1300 to process information more efficiently and in a more user-friendly way in various locations.

Each auto-id node in system 1300 may include one or more device controllers, as shown in Figure 13 as device controllers 1312, 1314, and 1316, which are distributed auto-. id associated with node 1308. Of course, each of the auto-id nodes 1306, 1308, and 1310 may have fewer or more device controllers, or may not use any device controllers at all.

Referring to device controller 1314 as an example, FIG. 13 shows that device controller 1314 may be used to supervise and coordinate some or all operations of auto-id device 1318-1326. Of course, device controllers 1312 and 1316 may be used to supervise the operation of similar auto-id devices that may be connected to those device controllers.

More specifically, device controller 1314 may be used to process data from auto-id node 1318-1326 to increase the efficiency of its associated auto-id node 1308. For example, the device controller 1314 may move external information, or in a way that is useful for the distribution function of the auto-id node 1308, and / or in a way that is useful for the enterprise application 1302, by its auto-id node 1308. The data may be combined or modified in the specified manner.

In this way, the device controller 1314 coordinates and manages the auto-id device 1318-1326, probably based on instructions from the auto-id node 1308, and relays (processes) information from the auto-id device to the auto-id node 1308. ). For example, the auto-id node 1308 is a device controller 1314 to get a specific class of data (such as quality) for object 1328 (eg toys or other items distributed to retailers for sale). May be used to direct to. Device controller 1314 then uses RFID / printer 1320 to retrieve this information from tag 1330 associated with object 1328, and the object specific number in question is available for auto-id node 1308. You may move any undesired information currently acquired before passing that information.

As another example, auto-id node 1308 may instruct device controller 1314 to assign information to object 1328. For example, the device controller 1314 may change the current price of an object 1328 (for example, to store new price information or in the context of an RFID tag 1330 attached to an object of some class). May use 1320.

From Figure 13, each of the device controllers 1312, 1314, and 1316 filters, aggregates, writes, or separates data for all its associated auto-id devices and / or environmental devices 1318-1326. At the same time that the auto-id node 1308 may be used to perform operations on, the auto-id node 1308 filters, aggregates, writes, or performs other operations on the data for its associated device controllers 1312, 1314, and 1316. Please understand that it can be operated to do. In this way, the auto-id node 1308 is a business process that can be run on one or more of enterprise applications 1302, even if it integrates information from its device controllers 1312, 1314, and 1316. Good.

The extension may reveal that enterprise application 1302 can behave to aggregate aggregated information from all of auto-id nodes 1306, 1308, and 1310. In addition, it should be understood that information that is useful at one level of System 1300 may not be very useful at another level. For example, enterprise application 1302 may not be interested in or have access to low-level information (eg, item-level) collected by reader / printer 1320. Rather, enterprise application 1302 may only be interested in the information to the extent that it is filtered and / or integrated by device controller 1314 and / or auto-id node 1308.

As a result of the architecture described, business logic from enterprise applications 1302 and / or from multiple enterprise applications may be supported in auto-id middleware (for example, as part of the auto-id infrastructure 110 in Figure 1). Please understand that it may not be possible. In addition, such multiple enterprise applications may be supported by a single physical hardware system and a single auto-id middleware that are common to all enterprise applications.

FIG. 14 is a block diagram of the network architecture 1400 for use with the auto-id infrastructure 1304 in FIG. More specifically, FIG. 14 shows an architecture in which the auto-id infrastructure 1304 in FIG. 13 can be used with the EPC (Electronic Product Code) developed for use in auto-id systems.

EPC refers to a unique number that resembles a UPC (Uniform Product Code) identifier, which allows multiple organizations and companies to collect their respective products, goods, services, or their collections (eg, pallets, cases, or truck shipments). ) Is a predetermined format and scheme that you have agreed to use to uniquely specify and identify. In the context of RFID systems, the EPC may then be assigned to tag 1330 on object 1328 in Figure 13. For example, a classic EPC has a header field (to distinguish between different formats), a manufacturing field (each organization that assigns an EPC has its own manufacturing format), a product field (product code), and a serial number. Defined by four fields (attached to the product).

In FIG. 14, EPCIS (EPC Information Service) layer 1404 enables the exchange of EPC data on the network. That is, EPCIS provides a standard format or protocol that allows a reader with an identified EPC number to find and use information about that number (and hence its associated item). .. In some executions and / or related implementations, for example, languages such as PML (Physical Mark-up Language) and / or XML (eXtensible Mark-up Language) use the above transformations or business-level EPC information. May be used for.

The EPCIS layer 1404 receives information from the application manager 1406, which generally oversees information events (eg tag readings) and manages communication events to the EPCIS layer 1404 and thereby the EPCIS repository 1410. It is operational. Repository 1410 accumulates data over a relatively long period of time, during which Application Manager 1406 acts to monitor and configure Repository 1410 when it is not readily available for any particular application or device. To do. Generally speaking, the flow of information about the number of objects may be too much for repository 1410 to be really useful in real time, especially at a given potential network delay. Rather, the auto-id node 1408 may be used to track such information, perhaps over a period of time, and that information may be immediately useful to the auto-id node 1408.

Application Manager 1406 and EPCIS Layer 1404 have access to ONC (Object Naming Service), and ONC has application management 1406 and EPCIS Layer 1404 as well as DNS (Domain Name Service), which is the EPC code for the product. A search service that allows you to find information about a product based on. ONS1412 may have different levels of information, which may be categorized by whether the information is stored locally or non-locally in the product, for example.

The ALE (Application Level Event) interface layer 1414 provides an interface to the device manager 1416 and the device controller 1418. More specifically, the ALE interface layer 1414 may be used to filter or aggregate information events received from device manager 1416 and / or device controller 1418. Device manager 1416 may be used to manage the state and / or configuration of device controller 1418.

As also shown in FIG. 14, reader protocol interface 1412 provides an interface for device 1422. That is, different companies may adopt different types of devices 1422, or other auto-id devices, and these devices and companies may utilize different reader protocols for communicating with readers. The reader protocol interface 1420 is designed to allow communication with all readers in system 1400.

From Figure 14, system 1400 may be used without the auto-id infrastructure 1304 in Figure 13, and conversely the auto-id infrastructure 1304 in Figure 13 may be used without the other elements in Figure 14. I want you to understand. Thus, Figure 14 shows that the auto-id infrastructure 1304 in Figure 13 may use the EPC network and standards, but use is not mandatory.

The above description shows various embodiments of the invention, along with examples of how aspects of the invention are implemented. The above examples and embodiments should not be considered as the only embodiment, but are presented to demonstrate the flexibility and advantages of the invention as defined in the claims. Based on the above disclosure and claims, other arrangements, embodiments, implementations, and equivalents are apparent to those skilled in the art and adopted without departing from the spirit and scope of the invention as defined in the claims. May be done. The terms and expressions used herein are used to describe various embodiments and examples. It is acknowledged that these terms and expressions are not construed except for the features illustrated and described or in part thereof, and that various modifications are possible within the scope of the appended claims.

<figref num="1">The network diagram of the auto-id system is shown.</figref><figref num="2">An auto-id system according to an embodiment of the present invention that can be used to visualize auto-id data is shown.</figref><figref num="3A">The auto-id hierarchy according to one embodiment of the present invention is shown.</figref><figref num="3B">The auto-id hierarchy according to one embodiment of the present invention is shown.</figref><figref num="3C">The auto-id hierarchy according to one embodiment of the present invention is shown.</figref><figref num="4">A method of displaying auto-id data according to an embodiment of the present invention is shown.</figref><figref num="5">An auto-id data visualization software system according to an embodiment of the present invention is shown.</figref><figref num="6A">This is an example of the utilization rate display for hospital equipment across multiple departments.</figref><figref num="6B">This is an example of aggregation according to another embodiment of the present invention.</figref><figref num="7">This is an example of status display for hospital equipment across multiple departments.</figref><figref num="8">This is an example of display according to another embodiment of the present invention.</figref><figref num="9">It is an example of a display that tracks an object over time according to another embodiment of the present invention.</figref><figref num="10">It is an example of a display that tracks an object over time according to another embodiment of the present invention.</figref><figref num="11">This is an example of a display indicating the distribution of equipment over different locations according to another embodiment of the present invention.</figref><figref num="12">This is an example of filtering according to another embodiment of the present invention.</figref><figref num="13">It is a block diagram of an exemplary auto-id system.</figref><figref num="14">FIG. 3 is a block diagram of an exemplary network structure used with the auto-id infrastructure of FIG.</figref>