Object monitoring and management system

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This is the first application filed for the present invention.

MICROFICHE APPENDIX

[0002] Not applicable.

TECHNICAL FIELD

[0003] The present invention relates to computerized systems for monitoring and managing physical assets or other objects and, in particular, to a system for enabling paperless, cross-entity identification, monitoring and management of the physical assets or other objects to which a computer-readable identification tag can be affixed.

BACKGROUND OF THE INVENTION

[0004] Various inventory and asset management systems have been developed for industrial use, because such systems have become an essential part of many industrial operations. Industries such as manufacturing, ore mining and processing, oil and gas procurement, refining and distribution need to track not only manufactured goods or produced materials during warehousing but also equipment that is used for production, distribution, etc. Existing inventory systems generally apply the same algorithms for warehousing and equipment tracking. However, the process of equipment tracking is much more complicated than that of warehousing merchandise or products. A warehouse inventory system typically tracks an object or a group of objects, each object or group being marked by a distinguishing identification tag readable by a device that is coupled directly or indirectly to a computer. The computer maintains a database with a number of records that describes the tracked objects.

[0005] Many methods of object monitoring and management are taught in the prior art. They are used in variety of industries, including manufacturing, health care facilities, libraries, etc. The main purpose of these prior art methods is to provide an instrument for effective asset management.

[0006] An example is U.S. Pat. No. 4,920,488 entitled PHYSICAL INVENTORY SYSTEM, which issued to Filley on Apr. 24, 1990. Filley describes a digital computer data base system and method for tracking a physical inventory that consists of land and fixtures, and items in or on the land, such as buildings, oil wells, pumps, and items within the buildings. In addition, the patent provides a system for tracking not only an inventory of each item, but also its physical location with respect to a geographical location of the item.

[0007] Another example is U.S. Pat. No. 6,014,628 entitled METHOD AND SYSTEM FOR TRACKING ANY ENTITY THROUGH ANY SET OF PROCESSES UTILIZING A TEMPORAL PROJECTION, which issued to Kovarik, Jr. on Jan. 11, 2000. Kovarik describes a method and system for a generic representation of a tracking domain that can be applied to new tracking applications with minimal development of new software. The patent describes a system having an overall architecture in which common abstractions are coalesced into a common design and architecture. The components of the system provide a foundation for applying tracking systems for one particular purpose to other application areas, e.g. the system can be adapted for a tracking system to provide aircraft security, or a tracking system for the manufacture of auto parts.

[0008] A disadvantage of all known prior art inventory tracking and asset management systems is that they fail to provide mechanisms for secure cross-entity access to asset management information. Consequently, truly “paperless” modes of operation have been impossible. Effective asset management inevitably involves the interaction of a plurality of autonomous, or semi-autonomous entities. For example, in an oil or gas production facility, the management of production equipment such as wellhead equipment, storage vessels, pipelines, etc. requires cooperative interaction of owner's personnel, maintenance service providers, regulatory inspectors, insurers, etc. In the past, these interactions have been documented, verified and accounted for using bulky paper systems that are expensive to provision and maintain, and often difficult to understand. Of course, paper systems are also difficult to correlate, search and audit.

[0009] There therefore exists a need for a completely computerized system for identifying and tracking physical assets or other objects and managing all activities associated with those assets, including shipment, transfer of ownership, inspection, maintenance, logging, calibrating, scheduling, repair, etc. In addition, the system preferably enables tracking of a physical location of the respective assets.

SUMMARY OF THE INVENTION

[0010] The present invention therefore provides a system for monitoring and managing objects. The system comprises a central database for storing information used to track objects wherein each object is identified by a unique computer-readable identifier, the central database being structured to enable an entity to retrieve, write and modify information about objects that the entity owns. The central database is further structured to permit a plurality of third parties to retrieve information from the central database on cross-entity basis, to enable object tracking, maintenance, inspection and other procedures by third party service providers, regulators, etc.

[0011] The present invention also provides a method for monitoring and managing objects. The method comprises steps of identifying objects to be tracked by attaching to each object a unique computer readable identifier; storing information in a central database that is used to track the objects; providing access to the database by an entity to retrieve, write and modify information about objects that an entity owns; and providing access to a plurality of third parties to create, retrieve or modify information in the database on cross-entity basis, to enable object tracking, maintenance, inspection and other procedures by third party service providers, regulators, etc.

[0012] In accordance with a further aspect of the invention, the method comprises a step of providing a secure connection between the database and a plurality of entities and third parties using a gateway to provide structured information related to a tracked object.

[0013] In accordance with a further aspect of the invention, the information about the object in the central database is stored it a plurality of tables having a standardized set of attributes.

[0014] In accordance with a further aspect of the invention, each table is identified using a unique primary key that is in the same format for all tables.

[0015] In accordance with another aspect of the invention, a portable unit is operated to read the computer readable identifier that is attached to the tracked objects. Programmed processes execute on the portable unit to perform one of creating, writing and modifying a database record that is associated with the tracked object in the portable unit. The portable unit is either placed in a docking station or is equipped with radio communications to permit the portable unit to establish a connection with the central database for the purpose of synchronizing a subset of records in the central database with a database of records maintained by the portable unit. The portable unit establishes a connection with the central database and records are transferred to, or retrieved from the central database.

[0016] In accordance with another aspect of the invention, the method comprises a step of operating the portable unit to generate the unique key associated with a specific object to be tracked by concatenating a first string that is uniquely associated with the portable unit and a second string that is generated by the portable unit.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0018]FIG. 1 is a schematic diagram illustrating an object monitoring and management system in accordance with the invention, and users of the system;

[0019]FIG. 2 is a block diagram that schematically illustrates an example of a scope of access of each object owner to records in the database of the system illustrated in FIG. 1;

[0020]FIG. 3 is a block diagram that schematically illustrates an example of a scope of access by a third party service provider/regulator to predetermined contents of records in the database;

[0021]FIG. 4 is a schematic diagram of an exemplary embodiment of the object monitoring and management system illustrated in FIG. 1;

[0022]FIG. 5 is a block diagram of software layers required on the server illustrated in FIG. 4;

[0023]FIG. 6 is a block diagram of software layers required on the desktop computers illustrated in FIG. 4;

[0024]FIG. 7 is a block diagram of software layers required on portable units illustrated in FIG. 4;

[0025]FIG. 8 schematically illustrates joins performed to retrieve data from the database based on object location;

[0026]FIG. 9 schematically illustrates joins performed to retrieve data from the database based on object asset class;

[0027]FIG. 10 illustrates an Issuing Unit Registry Table used to store information about issuing units;

[0028]FIG. 11 illustrates an example of a primary key structure that is used in all tables of the database illustrated in FIG. 4;

[0029]FIG. 12 is a schematic diagram of an exemplary implementation of the system shown in FIG. 1;

[0030]FIG. 13 is a schematic diagram illustrating how the exemplary implementation of the system shown in FIG. 12 is used by service providers, regulators, etc.; and

[0031]FIG. 14 is a schematic diagram illustrating how entities can partition data in a central database structured in accordance with the invention.

[0032] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0033] The invention provides a computerized object monitoring and management system that enables comprehensive paperless tracking, maintenance and/or management of physical assets. The system permits owners of the assets to control access to records so that maintenance service providers, regulatory authorities, and other third parties have access to information required for their respective functions on a cross-owner basis.

[0034]FIG. 1 is a conceptual diagram that schematically illustrates an object monitoring and management system <b>10</b> in accordance with an embodiment of the invention. A globally accessible database <b>12</b> stores information about monitored objects <b>14</b>. Each object <b>14</b> is identified by a physically attached computer readable identifier (e.g. a tag, barcode, or the like) <b>16</b>. The database <b>12</b> is accessed via a gateway <b>18</b> that serves as a secure entry channel. Access to the database is restricted by a security layer <b>20</b>, such as a firewall and/or other access control systems. The company/organization layer <b>22</b> represents entities that use the system for the propose of monitoring and managing objects they own, possess or control. The companies/organizations access the database <b>12</b> through the gateway <b>18</b> and security layer <b>20</b>. Each company/organization <b>22</b> only has access to records in the database <b>12</b> related to monitored objects <b>14</b> that it owns, possesses or controls. A company/organization that is granted access to the system <b>10</b> can retrieve, write or modify records related only to its own objects. Each company/organization can have objects in one or more locations.

[0035] Another category of users of the system <b>10</b> are third parties, which are not owners of the objects <b>14</b> that are monitored by the system <b>10</b>. The third parties represented by layer <b>24</b> of FIG. 1 include, for example, service providers and regulators such as the accounting firms <b>26</b>, maintenance providers <b>28</b>, transportation providers <b>30</b>, manufacturers <b>32</b>, safety inspectors <b>34</b>, government inspectors <b>36</b>, regulatory agencies <b>38</b>, surplus brokers <b>40</b>, enterprise resource planners (ERP) <b>42</b>, and others such as insurers, etc. The third parties operate and/or cooperate with the companies/organizations <b>22</b>, to provide services required to manufacture produce, maintain, distribute or account for the objects. Each entity in the company/organization layer <b>22</b> can also control access to information in the database <b>12</b> by its own departments, divisions or regional offices. For example, a department that is responsible for enterprise resource planning may be granted access only to information about objects <b>14</b> related to equipment surplus <b>40</b> and information required by the Enterprise Resource Planning (ERP) system <b>42</b>.

[0036]FIG. 2 schematically illustrates the structure of the company/organization <b>22</b> access to the database <b>12</b>. The database <b>12</b> is organized in a plurality of tables: “Table 1” <b>50</b>, “Table 2” <b>52</b>, “Table 3” <b>54</b>, and “Table 4” <b>56</b>. Each table in the database <b>12</b> stores a number of records respectively arranged in table rows, which are schematically illustrated as rows <b>68</b>, <b>70</b> and <b>72</b>. The respective records store information about particular objects belonging to particular ones of the respective companies/organizations <b>22</b>. Each company/organization <b>22</b> can create, retrieve, update, and modify information about objects <b>14</b> that it owns. The respective companies can only operate within the boundaries of the information related to their own objects <b>14</b>. Each record in the database stores information about one object <b>14</b> that belongs to the company/organization <b>22</b>. A filter, such as database “view” <b>60</b> for Company 1 controls a scope of access to the database <b>12</b> by the Company 1. Each company/organization <b>22</b> has a “view” that controls the company's access to records in the database <b>12</b>, in a manner well known in the art. In the example shown, “Company 1” <b>62</b> can only access the records in “row 1” <b>68</b> of “table 1” <b>50</b> and “row 1” <b>68</b> of “table 3” <b>54</b>.

[0037] As explained above, each company/organization <b>22</b> that uses the system <b>10</b> can grant access to third parties to use the system within the scope of business of the third party. FIG. 3 schematically illustrates a structure of third party access to the database <b>12</b>. The database <b>12</b> is structured to permit any required information about an object to be stored. For example, information that describes a physical condition and location of a monitored object <b>14</b> can be stored. Rows <b>90</b>, which include a record number <b>50</b>, a company identifier <b>52</b>, a class attribute <b>54</b>, and an object attribute <b>56</b> in the database <b>12</b> shown in a simplified schematic form, store information about objects <b>14</b> owned by company 1 and company 2.

[0038] In this example, the respective companies have granted access to a vessel inspection agency <b>36</b> to read, write or modify vessel inspection records in the database <b>12</b>. The respective companies have also granted access to pump maintenance records to a pump maintenance service provider. A plurality of views <b>88</b> control access to the various records in the database <b>12</b>. Each view is associated with an issuing unit group, as will be explained below in detail.

[0039] The vessel inspection view controls access to records in the database <b>12</b>, as explained above. Using the view, a vessel inspector is able to create, retrieve and modify the vessel inspection records belonging to both companies 1 and 2, as illustrated by the check marks in the respective boxes associated with record numbers 1-3, 5 and 6. However, the vessel inspection view prevents the vessel inspector from viewing or modifying other records in the database <b>12</b>. Furthermore, the database <b>12</b> may contain many other records (not shown) containing information about the vessels that are not vessel inspection records, and to which the vessel inspector has no access.

[0040] The pump service view permits a pump serviceman to create, retrieve and modify the pump maintenance records (record numbers 4, 7 and 8) related to pumps owned by both companies 1 and 2, as indicated by the check marks in boxes associated with the respective records 4, 7 and 8. The pump serviceman cannot, however, access any of the vessel inspection records, or any other records in the database <b>12</b> aside from the pump service records. As also shown, the recpective company 1 and company 2 each have views that permit them to view any record in the database <b>12</b> assocaited with objects they respectively own. It should be understood that the database <b>12</b> may serve other companies that have not granted access to their records to the vessel inspection agency or the pump manienance service. In that case, neither the vessel inspector nor the pump serviceman would have access to any of their company records, regardless of whether they were vessel inspection or pump service records. Consequently, the system in accordance with the invention permits controlled cross-entity access to facilitate regulatory, inspection, maintenance and other business procedures, as explained above with reference to FIG. 1.

[0041]FIG. 4 schematically illustrates an embodiment of the object monitoring and management system <b>10</b>. This embodiment of the object monitoring and management system <b>10</b> includes a server <b>100</b> that provides the secure gateway <b>18</b> (FIG. 1) to the database <b>12</b>. The system <b>10</b> further includes desktop computers <b>102</b>, handheld portable units <b>104</b>, and object tags <b>16</b>. The portable units <b>104</b> communicate with the server <b>100</b> through a bi-directional link <b>102</b>, which may be, for example, a desktop computer with a parallel or universal systems bus (USB) port to which the portable unit is connected by a docking station or a cable connector; a modem connected to a personal digital assistant (PDA) or a cellular telephone; a wireless link; or any other interface for providing a connection directly or indirectly to an open network such as the Internet <b>109</b>. The system <b>10</b> is adapted to monitor objects <b>14</b> that are uniquely identified by an object tag <b>16</b>, which is physically affixed to the object <b>14</b>. The object tag <b>16</b> can be any computer readable identifier. In one embodiment, objects <b>14</b> to be monitored are identified by a computer readable identifier known as an iButton® that is manufactured by Dallas Semiconductor. The iButton® is a computer readable chip encased in a dime-sized stainless steel case. This type of computer readable tag can operate within a wide range of temperatures and environmental conditions. In comparison to other types of computer readable object tags <b>16</b>, for example a printed bar code, the iButton® is more robust. However, the object tag <b>16</b> is selected to meet the tracking requirements and any suitable computer-readable tagging system can be used with equal success. A computer readable object tag <b>16</b> is attached to, printed on or otherwise affixed to each object <b>14</b> that is owned by the company/organization that uses the system <b>10</b> for monitoring and managing their objects.

[0042] The portable units <b>104</b> are the principal tool used for monitoring objects. The portable units <b>104</b> are handheld computers adapted to read information recorded in or on the object tag <b>16</b>. The portable units <b>104</b> run software applications that maintain respective portable databases, and connect with server <b>100</b> using, for example, a serial port or a universal system bus (USB) connection <b>106</b> to the bi-directional link <b>102</b>. As used in this document, the term “desktop computers” <b>102</b> means any computing machine or appliance adapted to connect with the server <b>100</b> via the Internet <b>109</b> by connection <b>110</b>, and to transfer information between the connected portable unit <b>104</b> and the server <b>100</b>. The server <b>100</b> maintains the database <b>12</b> that stores information about objects belonging to the companies/organizations that use the system <b>10</b> and, in addition, provides secure authorized access to the database <b>12</b> by the desktop computers <b>102</b>.

[0043] As shown in FIG. 5, the server <b>100</b> includes an operating system <b>124</b>, an open database connectivity (ODBC) application <b>122</b>, and a relational database management system (RDBMS) <b>120</b>.

[0044] As shown in FIG. 6, the desktop computers <b>102</b> are provisioned with front-end software <b>130</b>, a conduit application <b>132</b>, a secure shell <b>134</b>, and an open database connectivity (ODBC) application <b>122</b>. In one embodiment of the invention, these components interact with the server <b>100</b> and the portable units <b>104</b>. The server <b>100</b> is, for example, accessed through the Internet by the front-end application <b>130</b>. Data transmission is ported through a data encryption utility of the secure shell <b>134</b>, and decrypted by the server <b>100</b>. Object management and tracking data is not stored on the desktop computer <b>102</b>. The database connectivity is provided by standard connectivity software such as ODBC, an object linking and embedding database (OLE DB), or ActiveX® Data Objects (ADO).

[0045] As shown in FIG. 7, the portable unit <b>104</b> is provisioned with a portable database <b>140</b>, a conduit application <b>132</b>, a database management system (DBMS) <b>142</b> and a data management and tracking application <b>144</b>. Although the portable units <b>104</b> in the embodiment described below are not wireless devices, it should be understood that the invention contemplates and encompasses the use of wireless portable units <b>104</b> that are adapted to communicate wirelessly with the server <b>100</b>.

[0046] In an embodiment of the invention, the central database <b>12</b> is a relational database that stores information about monitored objects organized as a plurality of tables. Each table consists of a plurality of records having a standardized set of attributes, and each record is accessed by a unique primary key that has the same format across all of the tables. The database scheme is sufficiently abstracted and standardized to provide the flexibility required to permit the system <b>10</b> and control database <b>12</b> to be adapted to different areas of use without redeploying the system <b>10</b>.

[0047] Table 1 shows the basis of the standardized database schema. The “ObjectId” attribute is the standardized primary key that is associated with monitored objects. The “ParentObjectId” attribute is used in a variety of standard relationships the require a single foreign key link to another table, and, in recursive relationships, to the relation itself. A master detail relationship can be represented by two tables that are immediately connected by storing the “ObjectId” of the master relation in the “ParentObjectId” of the detail relation. The “Created” and “LastModified” attributes are timestamps and are used in every table to respectively record a date and time that the record was created, and the date and time of a most recent update. The “ObjectNametag” attribute is a standardized object name used primarily for standardized presentation in lists, which are displayed for browsing and searching. Since most object classes require that a user have a facility for browsing and searching, including the ObjectNametag attribute eliminates the inconvenience of planning for it in each object class. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 1</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Template</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="84PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Characteristics</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>ObjectId</entry><entry>character (10)</entry></row><row><entry /><entry>ParentObjectId</entry><entry>character (10)</entry></row><row><entry /><entry>ObjectNametag</entry><entry>character (50)</entry></row><row><entry /><entry>LastModified</entry><entry>timestamp</entry></row><row><entry /><entry>LastModifiedBy</entry><entry>character (10)</entry></row><row><entry /><entry>CreatedBy</entry><entry>character (10)</entry></row><row><entry /><entry>Created</entry><entry>timestamp</entry></row><row><entry /><entry>OrgId</entry><entry>character (10)</entry></row><row><entry /><entry>CreatedByIUID</entry><entry>character (10)</entry></row><row><entry /><entry>LastModifiedByIUID</entry><entry>character (10)</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0048] The “OrgId” attribute in the table schema in each table across the system enables the storage of all records of one class for all companies/organizations that are users of the system in a single table, but presents to each company/organization only its own records. When a company/organization accesses or modifies its records, the records in the table are filtered by the system on the basis of the attribute “OrgId” that, as described above, is a key and is associated with the company/organization that owns the object. As will be explained below in detail, issuing unit groups are associated with a key value (OrgId) that identifies a company/organization and, thus, the system is able to provide the company/organization with access to only its own records. In addition, third parties use issuing units associated with other attributes of the database schema, such as location or asset class, to access the records in the database simply by filtering on those attributes directly, without filtering the database on the “OrgId” attribute. This permits third parties such as inspection, maintenance, insurance and regulatory agencies access records in the database on a cross-entity basis. It should be understood, however, that each company/organization defines its own issuing unit groups and therefore controls which third parties have access to their records, as well as the scope of access of each third party.

[0049] Attributes “CreatedByIUID” and “LastModifiedByIUID” are associated with a portable unit <b>104</b> or the desktop computer <b>102</b> that created the record, or and modified it. The value of these respective attributes is used as a foreign key to a registry table for these units <b>104</b>.

[0050] Attributes “CreatedBy” and “LastModifiedBy” store an identity of a user who created and a user who most recently modified the record. The value of these respective attributes is used as a foreign key to a user table.

[0051] In addition to the above-described attributes of a standardized scheme of the database <b>12</b>, each table contains attributes that characterize a monitored object that are used to compile a description of the object. For example, Table 2 stores information about object location. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 2</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Location</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Characteristics</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>ObjectId</entry><entry>character (16)</entry></row><row><entry /><entry>ParentObjectId</entry><entry>character (16)</entry></row><row><entry /><entry>ObjectNametag</entry><entry>character (30)</entry></row><row><entry /><entry>LastModified</entry><entry>timestamp</entry></row><row><entry /><entry>LastModifiedby</entry><entry>character (16)</entry></row><row><entry /><entry>CreatedBy</entry><entry>character (16)</entry></row><row><entry /><entry>Created</entry><entry>timestamp</entry></row><row><entry /><entry>LocationTreeid</entry><entry>character (16)</entry></row><row><entry /><entry>LocationTreeSeq</entry><entry>integer</entry></row><row><entry /><entry>LocationDesc</entry><entry>character (20-48)</entry></row><row><entry /><entry>LocationType</entry><entry>character (16)</entry></row><row><entry /><entry>OrgId</entry><entry>character (16)</entry></row><row><entry /><entry>LocLSD</entry><entry>integer</entry></row><row><entry /><entry>LocSection</entry><entry>integer</entry></row><row><entry /><entry>LocTownship</entry><entry>integer</entry></row><row><entry /><entry>locrange</entry><entry>integer</entry></row><row><entry /><entry>LocMeridian</entry><entry>character (2)</entry></row><row><entry /><entry>LocLongDeg</entry><entry>integer</entry></row><row><entry /><entry>LocLongMin</entry><entry>integer</entry></row><row><entry /><entry>LocLongSec</entry><entry>integer</entry></row><row><entry /><entry>LocLongdesc</entry><entry>character (30)</entry></row><row><entry /><entry>LocLatDeg</entry><entry>integer</entry></row><row><entry /><entry>LocLatMin</entry><entry>integer</entry></row><row><entry /><entry>LocLatsec</entry><entry>integer</entry></row><row><entry /><entry>LocLatdeSc</entry><entry>character (30)</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0052] In order to provide a standardized scheme for each table structure, the attributes “ObjectId”, “ParentObjectId”, “Created”, “LastModified”, “ObjectNametag”, “OrgId”, “CreatedBy”, and “LastModifiedBy” are included in Table 2. However, the attributes “CreatedByIUID”, and “LastModifiedByIUID” are not included.

[0053] The remainder of the attributes of the table 2 (location)—“LocationTreeid”, “LocationTreeSeq”, “LocationDesc”, “LocationType”, “LocLSD”, “LocSection”, “LocTownship”, “locrange”, “LocMeridian”, “LocLongDeg”, “LocLongMin”, “LocLongSec”, “LocLongdesc”, “LocLatDeg”, “LocLatMin”, “LocLatsec”, “LocLatdesc”—store specific information that describes the location of the monitored object <b>14</b>. In this embodiment, attributes related to location describe the location using geographical coordinates of the object location, such as latitude and Alongitude. The mailing address of the object location is also stored. It should be understood that different attributes may be added to the standardized schema and that attributes can be adapted to define specific characteristics of an object.

[0054] The relational database <b>12</b>, which includes the plurality of tables, permits information to be extracted from the database using different criteria. As is known in the art, in order to extract information from a relational database, it is necessary to form a query to the database. A query that uses an interrelation within a plurality of tables is known as a join. FIG. 8 illustrates a simplified example 200 of a join between tables IUREGISTRY <b>210</b>, IUGROUP <b>212</b>, IUGOJECTXREF <b>214</b>, LOCATION <b>216</b>, and ASSET <b>218</b>. This join is performed to obtain records from the ASSET <b>218</b> table. This five-table join also shows some of the standardized attributes of the schema.

[0055] Each portable unit <b>104</b> has its own record in the Issuing Unit Registry Table “IURegistry” <b>210</b> and belongs to one and only one issuing unit group that is stored as an attribute “IUGroupId” <b>222</b>. The join <b>220</b> between the attribute “IUGroupId” <b>222</b> in the “IURegistry” table <b>210</b> and the attribute “ObjectId” <b>224</b> in the “IUGroup” table <b>212</b> is then connected by a join <b>226</b> to a many-to-many resolving relation table “IUGObjectXREF” <b>214</b>. In a logical entity diagram the “IUGObjectXREF” table <b>214</b> would appear as two entities, since logically there is a first entry for a cross-reference between the “IUGroup” table <b>212</b> and the “Location” table <b>216</b> as one pair, and a second reference between the “IUGroup” table <b>212</b> and the “ASSET” table <b>218</b> as another pair. However, the universal primary key that is the attribute “ObjectId” <b>224</b> permits both cross-references to be combined physically into a single table and the records are automatically sorted out by the joins. In this case, the attribute “XREFObjectId“ <b>228</b> joins to the attribute “ObjectId” <b>224</b> of the “Location” table <b>216</b>, which then joins to the “ASSET” table <b>218</b> via the foreign key attribute “LocationId” <b>234</b> in the “ASSET” table <b>218</b>.

[0056] Partitioning by the table “ASSETCLASS” <b>238</b> instead of by table “Location” <b>216</b>, as shown in FIG. 8, is shown in FIG. 9. Partitioning by the table “ASSETCLASS” <b>238</b> is done in the same way as has been described above with reference to FIG. 8 with the exception that the join is to the “ASSETCLASS” table <b>238</b> rather than the “Location” table <b>216</b> shown in FIG. 8. In this case, the table “XREFObjectId“ <b>214</b> relation to the table “ASSETCLASS” <b>238</b> selects only those records for the given asset class.

[0057] Each portable unit <b>104</b>, as previously described, has its own record in the issuing unit registry table “IURegistry” <b>210</b> and belongs to one and only one issuing unit group, which is stored as an attribute “IUGroupId” <b>222</b>. The join <b>220</b> between the attribute “IUGroupId” <b>222</b> in the “IURegistry” table <b>210</b> and the attribute “ObjectId” <b>224</b> in the “IUGroup” table <b>212</b> is then connected by a join <b>226</b> to the many-to-many resolving relation table “IUGObjectXREF” <b>214</b>. In a logical entity diagram the “IUGObjectXREF” table <b>214</b> would appear as two entities, since logically there is one for a cross-reference between the “IUGroup” table <b>212</b> and the “ASSETCLASS” table <b>238</b> as one pair and between the “IUGroup” table <b>212</b> and the “ASSET” table <b>218</b> as another pair. However, the universal primary key that is the attribute “ObjectId” <b>224</b> of the “ASSETCLASS” table <b>238</b> permits both tables to be combined physically into one table and the records are automatically sorted out by the joins. In this case, the attribute “XREFObjectId” <b>228</b> joins to the attribute “ObjectId” <b>224</b> of the “ASSETCLASS” table <b>238</b>, which then joins <b>242</b> to the “ASSET” table <b>218</b> via the foreign key attribute “ASSETCLASSID” <b>244</b> in the “ASSET” table <b>218</b>.

[0058] The attribute “ObjectId” in the standardized schema of the table structure in the database is a unique primary key that is associated with the objects across all the tables of the database. This embodiment of the invention provides an algorithm for issuing a unique primary key, wherein any issuing unit, such as a portable unit <b>104</b> or desktop computer <b>102</b> that is authorized to create a record in the database is capable, during the recording of information, of generating a primary key that is ensured to be unique. Each issuing unit is commissioned by the central server and associated with a unique alphanumeric sequence that is a constant for that issuing unit. An example of the table that stores information about issuing units is shown in FIG. 10.

[0059] The central database stores a registry of issuing units. The registry table <b>250</b> consists of multiple attributes from the standardized table scheme and comprises columns “Objectid” <b>252</b>, “ParentObjectId” <b>254</b>, “OrgId” <b>256</b> and “IssuingUnitCode” <b>258</b>. Each field <b>260</b> and <b>262</b> in the column “ObjectId” <b>252</b> is a primary key, wherein, in this particular example, the data “00020010” of the field <b>260</b> uniquely identifies an issuing unit “000A” (field <b>264</b>). Each of fields <b>264</b> and <b>266</b> of column <b>258</b> “IssuingUnitCode” is the primary key constant for the issuing unit because this 4-character string appears in every record generated by this issuing unit. The content “00020010” of the field <b>260</b> “ObjectId” can be interpreted as being a record generated by a different issuing unit, whose primary key constant is “0002”. Each of fields <b>268</b> and <b>270</b> contain coded information that is associated with a name of a company/organization. Field <b>268</b> contains “00000001”, which identifies a particular company/organization. Fields <b>272</b> and <b>274</b> of the column <b>254</b> “parentobjectid” are empty because issuing units do not have parent objects. The field <b>262</b> that contains “000A0010” illustrates an example of the issuing unit registering itself.

[0060] A primary key <b>280</b> shown in FIG. 11 consists of two parts <b>282</b> and <b>284</b>, and in this embodiment of the invention totals 8 characters selected from a 62-character alphabet, wherein each of parts <b>282</b> and <b>284</b> consists of 4 characters. The first part <b>282</b> is a primary key constant that is associated with an issuing unit (issuing unit code) and the second part <b>284</b> is a sequential 4-character string generated for the monitored object by the issuing unit.

[0061] Each portable unit <b>104</b> carries its own portable database that is a subset of the main database <b>12</b>. Usually the contents of the portable database of the portable unit <b>104</b> is limited to a description of the objects that are located at one or several sites of the company/organization. The portable unit database <b>140</b> for certain periods of time exists independently, and for those periods of time the user can make changes related to the objects. As well, changes can be made to the same object records in the main database <b>12</b> or other portable unit databases <b>140</b>. In order to avoid ambiguity in describing the same objects, the system synchronizes all of the databases. The synchronization process is independent of all application layer content. In one embodiment, the system provides for synchronization of the databases using three processes:

[0062] Portable unit processing;

[0063] Desktop processing; and

[0064] Server processing.

[0065] The portable unit <b>104</b> uses internal flags to keep track of every record changed, inserted or deleted since the last synchronization. On the server <b>100</b>, a parameter record is kept for each issuing unit that records the date-time stamp of the last synchronization.

[0066] At synchronization, the portable unit <b>104</b> is linked to a desktop unit via a serial or USB port, for example. The flagged records on the portable unit <b>104</b> are uploaded into two transaction tables. These tables are defined in a data dictionary. The data dictionary describes the application tables and fields that are used during synchronization. A master table describes the tables and provides as a description two character codes that are used on the portable units <b>104</b>, and a detail table contains one row for each attribute in any table that is described. The master table consists of two attributes, a table code and a table name. The detail table consists of the following attributes: table code, attribute code, attribute name and data type. These two tables are used to build dynamic SQL statements to retrieve download rows from any table that is mentioned in the master tables with identical WHERE clauses. Each row of the table selected for download is broken down into rows of data, one for each attribute in the detail table. The use of the master and detail tables provides an abstraction of the database schema from the synchronization process and, in addition, permits the selection of a subset of attributes for download from any of the tables. The use of a data dictionary also enables effective operations within the capabilities of the portable units <b>104</b> due to available memory and user interface capacity.

[0067] In one embodiment, the synchronization process is initiated when the user places the portable unit <b>104</b> in a docking cradle <b>105</b> (FIG. 12). Placing the portable unit <b>104</b> in the docking cradle <b>105</b> prompts the portable unit <b>104</b> to immediately start attempting to contact the synchronization application of the desktop computer <b>102</b> through the serial port. The records are uploaded by a transport layer of the frontend application <b>130</b> and are stored in a table on the desktop computer <b>102</b>. After the upload is complete, the desktop synchronization conduit <b>132</b> (FIG. 6) connects with the server <b>100</b> to pass the synchronization table transactions to the, appropriate tables on the server <b>100</b>. A coded form of the table name and all the fieldnames is sent with the records, so a data dictionary can be used to sort the data and apply the transactions to the proper tables. Each time a synchronization process is performed, a portable unit application revision number, last revision date, or any other suitable indicator, is also passed to the server <b>100</b>. If any software patches or program revisions are available, they are downloaded to the portable unit <b>104</b> as a part of the synchronization process. Thus, the portable unit “clients” are always kept current and software distribution issues are resolved.

[0068]FIG. 12 illustrates exemplary relations and interactions within the object monitoring and management system <b>10</b>. The system <b>10</b> provides a paperless, digital solution that maintains an entity asset list in a real time environment. In this particular example, two entities “company 1” and “company 2” are users of the system <b>10</b>. The first entity “company 1” is represented by a desktop computer <b>102</b> in the main office <b>300</b>, desktop computer <b>102</b> in the field office <b>302</b>, portable units <b>104</b> and asset objects <b>14</b> that are located at the location <b>304</b> of the “company 1”. Each of these objects <b>14</b> is equipped with a physically affixed computer readable tag <b>16</b>.

[0069] The second entity “company 2” is represented by a desktop computer <b>102</b> in the main office <b>306</b>, desktop computer <b>102</b> in the field office <b>308</b>, and portable unit(s) <b>104</b> and asset objects <b>14</b> that are located at the location <b>310</b> of the “company 2”. Each of these objects <b>14</b> is likewise equipped with a physically affixed computer readable tag <b>16</b>. Each office <b>300</b>, <b>302</b>, <b>306</b> and <b>308</b> has an Internet connection <b>110</b> for using the Internet <b>109</b> to connect desktop computers <b>102</b> to the server <b>100</b>, which has access to the database <b>12</b>.

[0070] In order to track their assets, the personnel <b>312</b> of “company 1” and “company 2” identify objects <b>14</b> belonging to the respective companies using computer readable tags <b>16</b>. The tags <b>16</b> store unique digital information that can be associated with the monitored objects in the portable database <b>140</b> and central database <b>12</b>.

[0071] The company locations <b>304</b> and <b>310</b> can be out of range of wireless or wireline communication facilities, such as telephone networks, the Internet, radio or mobile telephone networks. Furthermore, objects <b>14</b> can be mobile or dispersed across a wide geographical area. For example, in the oil and gas industry, the equipment for exploration or for production is, for the most part, far from any communication facilities and some of it is frequently relocated.

[0072] Objects to be monitored and managed by the system must be identified by a computer readable tag <b>16</b>. A tag <b>16</b> may be glued or otherwise secured to an accessible position on the object <b>14</b>. The computer readable tags <b>16</b> can be affixed to objects <b>14</b> indoors or out-of-doors in a wide variety of environmental conditions. After the computer readable tag <b>16</b> is affixed to the object <b>14</b>, the digital information contained in the tag <b>16</b> is read using the portable unit <b>104</b>, which is a handheld computer. The handheld computer is a portable, lightweight version of a personal computer that can operate using a battery. The portable unit <b>14</b> runs applications, has a monitor, keyboard, memory and standard interfaces for communicating with other digital devices. In one embodiment, the portable unit <b>104</b> is configured to communicate with a desktop computer <b>102</b> in the field offices using a serial port connection.

[0073] In one embodiment, the computer readable tag <b>16</b> stores a 14-character universally-unique serial number on a chip encased in a stainless steel container that is very resistant to most forms of corrosion. The 14-character serial number can be read by the portable unit <b>104</b>. The tag <b>16</b> is contacted using an interface of the portable unit <b>104</b> that is adapted to read the tag <b>16</b>. The portable unit applies a small voltage to the tag and reads the serial number stored by the tag <b>16</b>. After the serial number is read, an operator <b>312</b> may crate a record using a keyboard of the portable unit <b>16</b>. The record may contain any desired information about the object <b>14</b>, for example a detailed description of the object, a description of a location of the object, a digital photograph of the object, etc. Other information about of the object <b>14</b> may be entered in the field of office <b>302</b>, in the main office <b>300</b>, or by authorized third parties as will be explained below in more detail.

[0074] After the personnel <b>312</b> have completed the identification of the object <b>14</b> and have created the required records in the portable database, they may return to the field office and place the portable unit <b>16</b> in the docking station <b>105</b> that is connected to the desktop computer <b>102</b>. The new data from the database of the portable unit is automatically transferred to the central database <b>12</b> maintained by the server <b>100</b> using the Internet <b>109</b>. Consequently, the databases of the portable unit <b>16</b> and server <b>100</b> are synchronized and information about the object <b>14</b> becomes globally accessible for authorized users of the system. The authorized personnel <b>312</b> of the company that owns the object <b>14</b> as well as authorized third parties can modify the information about the object <b>14</b>, or create new records related to the object <b>14</b>.

[0075] When information about a particular object <b>14</b> is entered and stored in the database <b>12</b>, that information is accessible for use by all company personnel having an issuing unit belonging to an issuing unit group associated with an attribute of the object <b>14</b>. For example, in many industries, equipment must be periodically maintained or inspected. The personnel <b>312</b> who are responsible for maintenance and inspection use the system to identify any object that must be maintained or inspected. When an object <b>14</b> is identified as requiring maintenance or inspection, the personnel <b>312</b> at the field office download any required information into their portable unit <b>104</b>, if necessary.

[0076] The personnel <b>312</b> use information about the object to locate that object <b>104</b> and to identify the particular object <b>104</b> that requires maintenance or inspection. Thereafter, the tag <b>16</b> is read to ensure that the object <b>14</b> has been correctly identified. Information about specific maintenance or inspection operations performed can be entered by the personnel <b>312</b> during the maintenance or inspection operation. After the personnel have returned to the field office and the portable unit <b>104</b> is placed in the docking station <b>105</b> connected to the desktop computer <b>102</b>, any information about the maintenance work or inspection that was created or modified in the course of the work is transferred to the database <b>12</b>.

[0077] In addition, companies/organizations that are users of the system can authorize third parties to access to their information in the database <b>12</b>. The third party, as described below, can be any individual, public or private company or regulatory agency. An example illustrated in FIG. 13 shows how the object monitoring and management system is used by a third party <b>313</b>. The third party <b>313</b> is authorized by one or more companies/organizations that use the system to access a subset of the information in the database <b>12</b> associated with the respective company/organization. The third party <b>313</b> is granted access only to records related to an area of responsibility of the third party.

[0078] In this example, the third party <b>313</b> has desktop computers <b>102</b> in a main office <b>314</b> and a field office <b>316</b>. As explained above, each object <b>14</b> owned by the respective companies at the locations <b>304</b> and <b>310</b>. Each object <b>14</b> at the location <b>304</b> and <b>310</b> is identified by a computer readable tag <b>16</b>. The objects <b>14</b> at the location <b>304</b> are owned by “company 1” and the objects <b>14</b> at the location <b>310</b> are owned by “company 2”. Companies 1 and 2 define issuing unit groups that permit the third party <b>313</b> to use the system. The third party <b>313</b> may be, for example, a regulatory agency such as an Environmental Protection Agency, or a safety board that is responsible for regulating operations or inspecting equipment of “company 1” and “company 1”.

[0079] The third party <b>313</b> may, for example, periodically query the central database <b>12</b> to determine the objects that require maintenance or inspection and download to the portable unit <b>104</b>, a subset of database <b>12</b> that contains information about objects <b>14</b> to be inspected. The third party personnel <b>313</b> then use the remote database of the portable unit <b>104</b> to identify the location of an object <b>14</b>, confirm an identity of the object <b>14</b> by reading the tag <b>16</b>, and enter information relevant to the maintenance or inspection of the object when the personnel <b>313</b> return to the field office <b>316</b> and place the portable unit <b>104</b> into a docking station <b>105</b>. The information is automatically transferred to the database <b>12</b> via the connection <b>110</b> with the Internet <b>109</b>.

[0080]FIG. 14 schematically illustrates the partitioning of the database <b>12</b>. Access to information in the database <b>12</b> is controlled by each company/organization, which partitions the data to control access in any way desired. The company/organization partitions the data using an interface dialog that permits data access groups, referred to as Issuing Unit Groups (IUGroups) to be defined, or selected from a list of predefined IUGroups. Issuing Units are physical or logical devices commissioned to generate primary keys, as described above. Each Issuing Unit, such as a portable Unit <b>14</b>, can belong to one and only one IUGroup. An Issuing Unit can be decomissioned and recommissioned to a different IUGroup. The purpose of the IUGroup is to abstract the partitioning of the information in database <b>12</b> away from the Issuing Units. This permits multiple Issuing Units to access the same subset of the database <b>12</b>. The association of IUGroups to objects <b>14</b> is a many-to-many relationship. Consequently, a single IUGROUP can be associated with any object <b>14</b>, and an object <b>14</b> can be associated with more than one IUGROUP. This permits a company/organization to partition the information in database <b>12</b> related to objects <b>14</b> that it owns along different lines.

[0081] After an IUGroup is selected using the interface dialog as described above, the company/organization user selects multiple instances of an object class to be associated with the IUGroup. The system <b>10</b> then creates corresponding entries in the IUBObjectXREF table <b>214</b> that associate the respective object instances with the respective IUGROUPs by writing two ObjectId values in each row, IUGObjectId <b>236</b> AND XREFObjectId <b>228</b> (FIG. 9). Since all primary keys in each of the object classes are identical in format, the system <b>10</b> can associate any object class with any IUGroup within the same IUObjectXREF table <b>214</b>. A reference in table <b>214</b> to OrgId is unnecessary because the Issuing Units are assigned unique primary key constants that are independent of OrgId. However, the IUGroup table <b>212</b> (FIG. 9) has a reference to a foreign key to OrgId.

[0082] Issuing Units, including portable units <b>104</b><i>a</i>-<i>d</i>, belong to one and only one Issuing Unit Group (IUGroup). The IUGroup controls the way in which data in the database <b>12</b> is partitioned, and therefore controls the subset of database <b>12</b> that is synchronized with each portable unit <b>104</b><i>a</i>-<i>d. </i>In the example shown in FIG. 14, the Issuing Units are the desktop computers <b>102</b><i>a,b </i>and portable units <b>104</b><i>a</i>-<i>d, </i>however, it should be understood that the same principles apply to any Issuing Unit. One of the portable units <b>104</b><i>a </i>that is operated by company <b>50</b> (company 1) is synchronized with data related to objects <b>14</b> in Location 1, while portable unit <b>104</b><i>b </i>of company <b>50</b> is synchronized with information related to objects <b>14</b> in Asset class 1 owned by company <b>50</b>. The portable unit <b>104</b><i>c </i>of company 2, is synchronized with information related to all objects <b>14</b> in Locations 1 and 2. On the other hand, the portable unit <b>104</b><i>d </i>used by third party <b>348</b> is synchronized with information in Asset Class 2 related to objects belonging to both companies 1 and 2.

[0083] Several tables in the database <b>12</b>, for example, “ASSET”, “Location” and “MATERIAL TRANSFER”, include an attribute that is, or is associated with, the unique serial number that is stored in the computer readable identification tag <b>16</b>. For the tables “ASSET” and “Location”, the unique serial number stored by the identification tag <b>16</b> is the only identifying attribute. However, in these tables, as with any other table in the database, a primary key is the attribute “OBJECTID”. To associate the unique identification number with a specific object, the system maintains a table “BUTTONREGISTRY”.

[0084] Table 3 is an example of the “BUTTONREGISTRY” table. <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 3</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>“BUTTONREGISTRY”.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Characteristics</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>ObjectId</entry><entry>character (10)</entry></row><row><entry /><entry>ButtonId</entry><entry>character (16)</entry></row><row><entry /><entry>TableCode</entry><entry>character (12)</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0085] The attribute “Objectid” is a primary key of the object to which the identification tag <b>16</b> is affixed. The attribute “TableCode” is a reference to a table where the “ObjectId” can be found; and the attribute “BUTTONID” is the unique serial number stored by the identification tag <b>16</b>.

[0086] When portable unit reads an identification tag <b>16</b>, the portable unite first looks for the attribute “BUTTONID” in the “BUTTONREGISTRY” table to find out which table stores the details of the object description. Then the system retrieves information from that table using the attribute “BUTTONID”, to retrieve the with the description of the object <b>14</b>.

[0087] Because the system <b>10</b> permits third parties to have access on a cross-entity basis to selected subsets of information in the database <b>12</b>, it is sometimes necessary for a third party organization to superimpose a different hierarchical structure on data in the database <b>12</b> than that imposed by the respective companies/organizations that own the objects <b>14</b>. This may be necessary if the third party requires its own location tree to control data partitioning to portable units <b>104</b>. For example, a regulatory agency may require data partitioning of information related to a set of objects <b>14</b> by regions that do not correspond to locations used by the object owners, because the regulatory agency has inspection districts that encompass two or more owner locations, or the like. Consequently, the regulatory agency may need to create its own hierarchical structure of regions and districts, by which it organizes references to the objects <b>14</b>. This requires that the object <b>14</b> have two “parents” locations, one location being defined by the object owner, and another one by the regulatory agency. In order to avoid ambiguity in location description, one embodiment of the system <b>10</b> uses a LocationXREF table that stores the parent-child relationship separately. The LocationXREF table consists of two main attributes “LocationobjectId” and “LocationParentObjectId”. For any one value of an attribute “LocationObjectId”, more than one row can be stored for a value of the attribute “LocationParentObjectId”. The same principal can be applied to other attributes of the database <b>12</b>, in order to accommodate any situation that may need to be accommodated between the parties having access to subsets of information in the database <b>12</b>.

[0088] Consequently, the system <b>10</b> enables a completely paperless process for asset or process management. The system <b>10</b> permits an application service provider (ASP) to provide paperless asset or process management to a plurality of unrelated companies/organizations. Each company/organization perceives an exclusive database that can be partitioned in any convenient way to control access to information. At the same time, third party service providers, regulatory authorities, and the like can be granted access to information required for their respective functions, and permitted to create new data in the database required to support the paperless process without compromising the confidentiality or security of other data in the database <b>12</b>.

[0089] The system <b>10</b> has been described with reference to portable units <b>14</b> that are synchronized in a batch process and are not adapted for wireless communications with the server <b>100</b>, in order to support operations in remote areas where wireless services are unavailable, unreliable, or too expensive. It should be understood, however, that the invention is equally adapted to use with portable units <b>104</b> that have wireless communications capability, in which case synchronization could be a dynamic process conducted on a transaction basis.

[0090] The embodiments of the invention described above are therefore intended to be exemplary only, the scope of the invention being limited solely by the scope of the appended claims.