US20070061347A1

Movatterモバイル変換

Info

Publication number: US20070061347A1
Application number: US11/554,632
Authority: US
Inventors: Christopher Burnley; Brian Gerhold; Wei Zheng; Pamela Day; Mike Sherman
Original assignee: Blazent Inc
Current assignee: Blazent Inc
Priority date: 2001-04-27
Filing date: 2006-10-31
Publication date: 2007-03-15
Also published as: US6782350B1; US20070061450A1; US7188170B1

Abstract

Some embodiments of the invention provide a method for tracking the use of software resources of a computer. This method identifies an instance when a particular software resource is used. It then measures and records a time period relating to the detected utilization of the software resource. In some embodiments, this time period is an estimated duration of the utilization of the software resource.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional application of application Ser. No. 10/136,177, entitled “System for Managing Resources”, which is a continuation of application Ser. No. 10/135,864, entitled “Method and Apparatus for Managing Resources”, filed Apr. 29, 2002, now U.S. Pat. No. 6,782,350, which issued Aug. 24, 2004, and which claims the benefit of provisional Application No. 60/286,814, entitled “Digital Asset/Digital Resource Management and Reporting System”, filed Apr. 27, 2001, the disclosures of which are incorporated herein by reference in their entirety.

BACKGROUND

1. Field of the Invention

Embodiments of the present invention are directed to method and apparatus for managing resources and in particular to a system and method for storing and aggregating data for later retrieval.

2. Description of Related Art

In the last few years, there has been a dramatic increase in the number of computers that are used in business and residential environments. The use of computers, however, is not well understood. This is because currently there are few mechanisms for gathering data relating to the hardware and software resources of computers and to the usage of these resources. There are even fewer mechanisms for analyzing any such data. Therefore, there is a need in the art for a system that gathers data relating to the hardware and software resources of one or more computer and gathers data relating to the usage of these resources. In addition, there is a need for a system that filters and analyzes such data, in order to provide a better understanding of the resources employed by the computers and the usage of these resources.

SUMMARY

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 presents a block diagram that conceptually illustrates one embodiment of the invention.

FIG. 2 illustrates the software architecture of a client application of some embodiment of the invention.

FIG. 3 illustrates several operations that a software inventory tracker of some embodiments performs.

FIG. 4 illustrates one example of a cache used by the software inventory tracker.

FIG. 5 illustrates several operations that the software inventory tracker performs.

FIG. 6 presents a conceptual illustration of a software utilization tracker of some embodiments.

FIG. 7 illustrates several operations that a data-gathering engine of the software utilization tracker performs.

FIG. 8 illustrates several operations that a data-exporting engine of the software utilization tracker performs.

FIGS. 9-11 illustrates the attributes of start, update, and stop software-utilization data items in some embodiments of the invention.

FIG. 12 presents a conceptual illustration of a browser tracker.

FIG. 13 illustrates several operations that a data-gathering engine of the browser tracker performs.

FIG. 14 illustrates several operations that a data-exporting engine of the browser tracker performs.

FIGS. 15-17 illustrates the attributes of start, update, and stop browser data item in some embodiments of the invention.

FIG. 18 illustrates several operations that a hardware inventory tracker.

FIG. 19 illustrates an example of an add inventory data item for a CPU.

FIG. 20 illustrates a hardware utilization tracker of some embodiments of the invention.

FIG. 21 illustrates a set of operations that a data-gathering engine of the hardware utilization tracker performs.

FIG. 22 illustrates a set of operations that the data-gathering engine of the hardware utilization tracker performs for the storage utilization.

FIG. 23 illustrates several operations that a data-exporting engine of the hardware utilization tracker performs.

FIG. 24 illustrates the attributes of a hardware-utilization data item III some embodiments.

FIG. 25 illustrates the software architecture of a data filter of some embodiments of the invention.

FIG. 26 illustrates a flow of operations of the data filter.

FIG. 27 illustrates the architecture of the server-side software of some embodiments of the invention.

FIG. 28 illustrates the schema of a collection database of some embodiments of the invention.

FIG. 29 illustrates the architecture of the application server in some embodiments of the invention.

FIG. 30 illustrates several operations that a software inventory handler of some embodiments performs.

FIG. 31 illustrates several operations that a hardware inventory handler of some embodiments performs.

FIG. 32 illustrates several operations that a software utilization handler of some embodiments performs.

FIG. 33 illustrates several operations that a browser handler of some embodiments performs.

FIG. 34 presents a conceptual illustration of the categorization operation of a server data filter.

FIG. 35 presents a more detailed example of the categorization operations that the server data filter performs in some embodiments.

FIG. 36 illustrates the schema for a data warehouse.

FIG. 37 illustrates a conceptual block diagram of a computer.

DETAILED DESCRIPTION

In the following description, numerous details are set forth for purpose of explanation. However, one of ordinary skill in the art will realize that the invention may be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary detail.

I. SYSTEM ARCHITECTURE

FIG. 1 presents a block diagram that conceptually illustrates one embodiment of the invention. This embodiment is a resource measurement system (RMS)100 that is designed to provide visibility and insight into utilization of computer resources. TheRMS100 uses a client-server architecture. Hence, it includes aserver105, anetwork110, andseveral client computers115. It also includes adata storage125.

Each client computer is a computing device, such as a server computer, a desktop computer, a laptop computer, a personal digital assistant (“PDA”), a network device, etc. In the embodiment illustrated inFIG. 1, each client computer includes aclient application120 that gathers certain information regarding the resources of its client computer and the usage of these resources. In some embodiments, eachclient application120 is automatically loaded onto its client computer from theserver105 when its client computer is first introduced in the client-server environment. One example of aclient application120 is further described below in Section II.

Theclient applications120 relay the data that they gather to theserver105 through thenetwork110. This network can be a local area network (“LAN”), a wide area network (“WAN”), or a network of networks (such as the Internet). Theserver105 processes the data that it receives from the client applications. For instance, it might filter, combine, and/or categorize the received data. It then stores the data in adata storage125. The server then analyzes the data in the data storage and generates reports based on this data. The analysis and reporting can be done in an automated fashion. Alternatively, the analysis and/or reporting might be done by an administrator or at the direction of the administrator.

In some embodiments, one computer forms theserver105 and itsdata storage125. Alternatively, in other embodiments, several computers form the server and/or its data storage. For instance, in some embodiments, one or more server computers are used to gather data from the client applications, one or more data storage computer systems are used as the data storage, and one or more server computers are used to analyze and generate reports based on the data stored in the data storage. Theserver105 and its data storage are further described below in Section III for some embodiments of the invention.

II. CLIENT APPLICATION

A. ARCHITECTURE

FIG. 2 illustrates the software architecture of theclient application120 of some embodiment of the invention. As shown in this figure, theclient application120 includes abrowser tracker205, asoftware utilization tracker210, asoftware inventory tracker215, ahardware utilization tracker220, ahardware inventory tracker225, an operating system (“OS ”)tracker230, anactivity tracker235, ascheduler240, adata filter245, adata aggregator250, anevent trigger255, and amessenger260.

As further shown in this figure, theclient computer115 typically includes one ormore browsers265,several software resources270, andseveral hardware resources275. Not illustrated inFIG. 2 is the operating system that controls the usage of the hardware resources and serves as the foundation of the software applications of theclient computer115. Different embodiments of the invention use different operating systems for the client computer. The embodiments described below use one of the Windows® operating systems offered by Microsoft Corporation.

The client application's software and

hardware inventory trackers

215 and225 respectively inventory the various software and

hardware resources

270 and275 of theclient computer115. The software resources inventoried by thesoftware inventory tracker215 include application and non-application files that are stored in the client computer's storage (e.g., its hard drive or removable storage). Examples of such files are .exe, .sys, .com, .bat, .dll, .doc, .xsl files.

The hardware resources inventoried by thehardware inventory tracker225 can include any hardware or hardware setting of theclient computer115. Examples of these resources are memory, disk storage, CPU(s), network card(s), sound card, video card, virtual memory settings, etc.

The client application'sbrowser tracker205 monitors the use of the client computer's browsers. The browser tracker tracks different browser events in different embodiments. In the embodiments described below, the browser tracker tracks one or more time periods for each URL event of the browsers. Different embodiments define a URL event differently. In the embodiments described below, a URL event is detected upon a successful download of the content that resides at a particular URL. In other embodiments, a URL event occurs when a browser requests certain content that resides at a particular URL. The content residing at a particular URL will be referred to below as the particular URL's content.

In the embodiments described below, the time periods that the browser tracker maintains for each URL event are run time, focus time, and active time. A URL event's run time represents the duration of time that a browser presents the URL's content at the client computer (e.g., displays in a window or frame). Focus time represents the duration of time that the browser's presentation of a URL's content is in focus. Different embodiment can have different definitions for an application that is in focus. In the embodiments described below, an application is in focus when it is an application that takes input from the keyboard and the mouse button. Active time represents the duration of time that a user at the client computer is actively engaged with the browser's presentation of a URL's content.

Thesoftware utilization tracker210 monitors the use of the client computer'ssoftware resources270. This tracker tracks different usage metrics in different embodiments of the invention. In some embodiment, this tracker records three time periods each time a software application is opened on the client computer. These three time periods are: (1) run time, which represents the duration of time that the application is open, (2) focus time, which represents the duration of time that the application is in focus, and (3) active time, which represents the duration of time that the user is actively engaged with the application. The client application'shardware utilization tracker220 monitors the use ofcertain hardware resources275 of theclient computer115. In some embodiments, this tracker records certain performance characteristics of certain hardware resources over time. For instance, in some embodiments, this tracker records the utilization of the computer's CPU(s), memory, disk storage, and network adapter(s) over time.

Thehardware utilization tracker220, thebrowser tracker205, and thesoftware utilization tracker210 interact with thescheduler240 in order to synchronize their data collection with the universal clock of thecomputer system100 ofFIG. 1. Specifically, each of these trackers includes a local cache in which it stores data that it sporadically receives and/or generates. The data in each tracker's local cache is periodically stored to the storage of the client computer. This allows the data to be recovered by the server, in the event of an unexpected shutdown (e.g., a crash) of the client computer or in the event that the client application does not get a chance to send all its data to the server before it has to logoff. In such events, the server can receive the data the next time that the client application starts on the client computer. Based on a notification from the scheduler, each tracker reads out the content of its local cache and generates data items relating to data that it generated and/or collected during a particular time interval. In some embodiments, the server configures each of the three

trackers

205,210, and220 to ask the scheduler to send it notifications according to a particular schedule for the tracker. The scheduler maintains a time that is synchronized with the clock of theserver105, and this in turn allows the scheduler to send its notifications according to the server clock.

These notifications, in turn, allow the three

trackers

205,210, and220 to gather their data according to the system clock.

In the embodiment illustrated inFIG. 2, the software and

hardware inventory trackers

215 and225 do not use the scheduler to schedule their inventory operations. This is because the design of theclient application120 does not require precise temporal data with the inventory data. Therefore, it allows the inventory trackers to control the start of their inventory operations based on timers that they keep internally. One of ordinary skill, however, will understand that other embodiments might require the inventory trackers to gather their inventory data at precise system times identified through the scheduler or some other mechanism. Alternatively, one of ordinary skill will also appreciate that some embodiments might not requiresoftware inventory tracker205,software utilization tracker210, and/orhardware utilization tracker220 to use the scheduler or to operate based on the system clock.

The browser and

software utilization trackers

205 and210 also interact with theOS tracker230 and theactivity tracker235, as illustrated inFIG. 2. TheOS tracker230 periodically provides the browser and software utilization trackers with the identity of (1) the software application that is currently in focus, and (2) the list of the applications that are currently open. In some embodiments that are implemented in the MS Windows® environment, the OS tracker identifies the focused application and obtains the current process list from the OS by using commonly used processes that are generally referred to as Enum Procs for the different Windows OS's.

Theactivity tracker235 provides the browser and software utilization trackers with an activity variable that specifies whether the application that is in focus is active or not (i.e., whether the computer user is actively engaging the application that is currently in focus). In some embodiments, the activity tracker determines whether the focused application is active based on keyboard and mouse events. For instance, in some embodiments, the activity tracker uses a timer to check periodically for the keyboard and mouse events. Specifically, each time the timer expires, the activity tracker in these embodiments uses GetASynchKeyState and GetCursorPos API's to obtain the content of the keyboard and mouse buffers. When the retrieved content of either of these buffers has changed from the last time that the activity tracker retrieved their contents, the activity tracker sets its activity variable to active if this variable was previously inactive. On the other hand, when the content of neither buffer has changed from the last time that the activity tracker checked these buffers, the activity tracker sets the activity variable to inactive if this variable was previously active. After retrieving the contents of the keyboard and mouse buffers and possibly changing the state of the activity variable, the activity tracker resets its timer and waits for the next time that it has to examine these buffers.

The data filter245 receives the data items generated by the browser, software, and hardware trackers205-225. This filter discards some of the collected data that is not particularly relevant for the resource manager. In some embodiments, theserver105 performs additional filtering operations. Accordingly, in these embodiments, the filtering operation of the data filter245 is meant only as a first order filtering operation that discards only some of the irrelevant data.

The data filter245 stores the filtered data (i.e., the data that remains after the filtering) in thedata aggregator250. Theevent trigger255 checks the data items stored in thedata aggregator250, in order to determine whether a triggering event has occurred for transmitting some or all of the data items in the aggregator to theserver105. In some embodiments, the triggering events can relate to the amount of data stored in the aggregator, the number of data items stored in the aggregator, the attributes of one or more data items, etc. Also, in some embodiments, one or more of the triggering events might not be related to the data items. For instance, in some embodiments, a trigger event might be a timer event that periodically occurs every fixed time interval (e.g., every 30 minutes). To simplify the illustration of the client application's architecture,FIG. 2 illustrates onedata aggregator250 and oneevent trigger255 for the browser, software, and hardware trackers205-225. However, some embodiments specify one data aggregator and one event trigger for each of these trackers. Whenever the event trigger detects the occurrence of an event for transmitting some or all of the data items in the aggregator, the event trigger notifies the aggregator to pass the data items to themessenger260 for transmission to theserver105 through thenetwork110.

Themessenger260 is a typical transport module for a client/server environment. It is a bidirectional transport module that receives and transmits data to theserver105. In some embodiments, this messenger employs a fail-safe mechanism that caches the data items when the messenger does not detect a network connection or when the messenger fails to transmit successfully the data to the server (e.g., when the messenger does not receive a confirmation from the server that it has received the data items, in the embodiments where the server is required to send an acknowledgment reply).

This messenger also employs a back-off algorithm that does not immediately try to resend data to the server after a transmission failure.

The messenger transmits each data packet with a session identifier (“session ID”). The session ID is a unique identifier that theserver105 assigns to the client application each time the application starts. Each session ID uniquely identifies each execution of the client application. Each session ID includes the ID of the user that is logged on to the client computer during the session. It also includes the ID of the computer that is used during that session. In some embodiments, the data items that are transmitted between the client application and the server are embedded in XML documents.

FIG. 2 illustrates the client application architecture for only some embodiments of the invention. One of ordinary skill will realize that other embodiments might employ other architectures and/or other modules. For instance, some embodiments might include modules to track the usage of specific software resources.

B. SOFTWARE INVENTORY TRACKER

Thesoftware inventory tracker215 inventories the software files of theclient computer115. The inventoried software resources include application and non-application files, such as .exe files, .sys files, .com files, .bat files, dll files, doc files, .xsl files, etc. In some embodiments, thesoftware inventory tracker215 periodically scans the client computer's disk storage to inventory the software files that it needs to examine. This tracker maintains a cache that identifies all the inventoried software files.

Each time that this tracker identifies a software file that has been added, removed, or modified, it generates a data item that identifies the added, removed, or modified data file. The tracker passes such data items to the data filter, which then filters them and passes the filtered data to the aggregator for eventual transmission to thesystem server105. At the system server, the inventoried data can be analyzed for a variety of purposes. For instance, the data can be analyzed in order to identity the software resources employed ondifferent client computers115, to categorize these software resources, to detect unauthorized additions, removals, and/or modifications of software files, to detect unlicensed software, etc. The inventoried data is also used to facilitate the software utilization analysis that is performed based on the data collected by thesoftware utilization tracker210.

FIG. 3 illustrates several operations that thesoftware inventory tracker215 performs periodically to create and maintain its cache of inventoried files and to identify added, removed, and modified files. Thetracker215 starts these operations at the expiration of a timer that it maintains. As shown inFIG. 3, thetracker215 initially identifies (at305) the list of files that it needs to scan. In some embodiments, thetracker215 identifies at305 only some of the files that it needs to inventory periodically. This is because instead of scanning the entire storage of the client computer in a single repetitive inventory operation, thetracker215 in some embodiments divides its inventory operation into several sub operations, with each sub operations inventorying a different set of files. This reduces the duration of each inventory operation and thereby makes the inventory process less noticeable to the user.

Next, at310, the tracker215 (1) creates an inventory cache when this is the first time that it is performing the operations ofFIG. 3 for the current session, or (2) loads the previously created inventory cache when this iteration is not the first iteration of the operations ofFIG. 3.

As mentioned above, the inventory cache identifies all the inventoried software files.FIG. 4 illustrates one example of such a cache. As shown in this figure, thecache405 includes oneentry410 for each software file that thetracker215 inventories. Eachinventory entry410 includes aprimary identifier415 and asecondary identifier420. In the embodiments described below, the primary identifier is a software inventory identification (“SIID”), which is a unique identification of a file that is produced based on the content of the file. Some embodiments generate the SIID for a file by hashing some or all of the file's content (e.g., hashing the first 10 MB of the file). Some of these embodiments use standard hashing techniques, such as a standard 128 bit hashing technique. The secondary identifier is based on computer system attributes of the file. These attributes are referred to below as secondary-identifier attributes. For instance, in the embodiments described below, the secondary identifier attributes includes the name, the storage location (e.g., the file path), modified date, and size of the file. The secondary identifier attributes can include other attributes, such as manufacturer (if applicable).

As further described below, thetracker215 uses two identifiers for each inventoried file so that it can identify previously inventoried files that have had only their content modified or their system attributes modified. It should be noted that a change to a file's content would change its SIID. Also, thetracker215 treats a file as one that has not previously been inventoried when the file's content, name, and storage location are all modified after the file is inventoried.

After creating or loading the cache at310, thetracker215 scans (at315) each file in the list generated at305. For each scanned file, thetracker215 performs (at315) several operations illustrated inFIG. 5. These operations (1) generate an SIID for the file, and (2) possibly generate a data item for the file if it has not yet been inventoried or if it has been modified after the last time that it was inventoried.

Specifically, as shown inFIG. 5, thetracker215 generates (at505) an SIID for the file. It then determines (at510) whether the inventory cache includes an entry with an SIID that matches the SIID of the file. If not, thetracker215 then determines (at515) whether the inventory cache includes an entry that specifies secondary-identifier attributes that match the file's secondary-identifier attributes. If not, thetracker215 adds (at520) adata entry410 in the inventory cache for the file, where the data entry specifies the file's SIID and secondary-identifier attributes. At520, thetracker215 generates a new data item (called an “add data item”) that is for directing theserver105 to add the newly inventoried file to the list of files that the server maintains for the client computer. In some embodiments, this generated data item specifies the SIID, name, path, application name (if applicable), version (if applicable), size, modification date (if applicable), manufacturer (if applicable). If applicable, this data item also specifies license information such as number, type, registered user, description, and expiration date.

If thetracker215 identifies (at515) a cache entry that specifies secondary-identifier attributes that match the secondary-identifier attributes of the file, thetracker215 identifies the file as one that was previously inventoried but has its content changed since the last time that it was inventoried. Hence, at525, it changes the SIID of the cache entry identified at515 to the SIID generated at505. It also generates a data item (called a “modify data item”) that specifies the new SIID for the file. In some embodiments, the modify data item provides the old and new SlID's for the modified file, as well as any other attribute of the file that has changed since it was last inventoried.

If thetracker215 identifies (at510) a cache entry with an SIID that matches the SIID generated at505 for the file, the tracker determines (at530) whether the entry with the matching SIID specifies secondary-identifier attributes that match the secondary-identifier attributes of the file. If so, thetracker215 ends the operations ofFIG. 5 without generating any data item, as it has identified a data entry with an SIID, file name, and storage location that match the SIID, file name, and storage location of the file. Such identification means that the tracker has previously inventoried the scanned file and that this file's content, name, and storage location have not been modified since it was last inventoried.

On the other hand, in some cases, thetracker215 determines (at530) that the entry with the matching SIID does not specify secondary-identifier attributes that match the secondary-identifier attributes of the file. This occurs when the file's secondary-identifier attributes are modified after it has been inventoried but its content remains the same. For these situations, thetracker215 makes (at535) the secondary-identifier attributes specified by the cache entry identified at510 identical to the secondary-identifier attributes of the file. It also generates (at535) a modify data item that specifies the modification to the secondary-identifier attributes of the file. In some embodiments, the modify data item provides the old and new file secondary-identifier attributes that have changed since the file was last inventoried. After315, thetracker215 identifies (at320) the files that have been removed since the last time it inventoried the group of files identified at305. The tracker identifies the removed files by scanning the inventory cache and identifying any data entry (1) which relates to the list of filed generated at305 and (2) which was not identified (at315) as a data entry with a primary identifier or a secondary identifier that matched the primary or secondary identifier of a file on the list. For each data entry that thetracker215 identifies at320, it generates a data item that specifies that the file associated with the entry's SIID has been removed, and then removes the entry from the inventory cache.

Next, the tracker determines (at325) whether any file that it identified at315 as a newly added file (as the file did not have primary and secondary identifiers that matched the primary and secondary identifiers of any cache data entry) has a license script associated with it. If so, thetracker215 uses a script manager to extract the license data for each newly added file that has an associated license script, and then adds the license data to the data item that the process generated for the file. After325, the tracker resets (at330) its internal timer that notifies it of when to repeat the operations illustrated inFIG. 3. After330, the operations illustrated inFIG. 3 terminate. Thetracker215 eventually sends all the data items that it generated at315 and320 to the data filter.

Thesoftware inventory tracker215 also works in conjunction with thesoftware utilization tracker210. Specifically, each time theutilization tracker210 encounters a new running process, it provides the inventory tracker with the secondary-identifier attributes of the file associated with the newly encountered process, and asks theinventory tracker215 for the SIID of this file. The inventory tracker then performs the operations illustrated inFIG. 5 for this file. Specifically, thetracker215 generates (at505) for the file an SI ID, which it then supplies to the utilization tracker. It also (1) at520, adds a new data entry in the inventory cache and generates an add data item when it identifies the file as one that has not been previously inventoried, or (2) at525 or530, modifies a data entry in the inventory cache and generates a modify data item when it identifies the file as one that has been modified since the last time that it was inventoried. The execution of the operations ofFIG. 5 in response to an SlID-request by the software utilization tracker provides the software inventory tracker with a capability to perform on-demand inventory management.

C. Software Utilization Tracker

Thesoftware utilization tracker210 monitors the use of the client computer'ssoftware resources270. In the embodiments described below, this tracker monitors the use of .exe application files. One of ordinary skill will realize that other embodiments can also monitor the use of other software files, such as .dll files, .doc files, .xsl files, etc.

FIG. 6 presents a conceptual illustration of the software utilization tracker. As shown in this figure, the software utilization tracker includes a data-gathering engine605, acache610, and a data-exportingengine615. The data-gathering engine605 receives the output of theOS tracker230 and theactivity tracker235. Based on these outputs, the data-gathering engine605 gathers data each time a software application is opened on the client computer. For each opened application, the gathered data relates to: (1) the application's run time, which is the duration of time that the application is open, (2) the application's focus time, which is the duration of time that the application is in focus, and (3) the application's active time, which is the duration of time that the user is actively engaged with the application. The data-gathering engine stores the gathered data in thecache610. The data-exportingengine615 reads out the content of the cache610 (i.e., generates data items) each time it receives a notification from thescheduler240. The data-gathering engine is first described below by reference toFIG. 7. The data-exportingengine615 is then described by reference toFIGS. 8-11.

Each time an application is opened, the OS defines a new process and a new OS process ID that specifies this new process. At any given time, the OS maintains a list of all currently active processes. In other words, this list (called a “process list”) enumerates the process ID's of all processes running at a given time. The OS tracker periodically obtains from the OS this process list. When theclient application120 starts (e.g., at boot up), the data-gathering engine registers to periodically receive the list of applications that are open (i.e., the process list) from the OS tracker.

Each time that the data-gathering engine605 receives a process list from theOS tracker230, the data-gathering engine performs several operations illustrated inFIG. 7. As shown in this figure, theengine605 starts by updating (at705) an internal process list that it maintains. This internal process list enumerates the OS process ID's of all processes for which thecache610 currently stores values.

To update the internal process at705, theengine605 determines (at705) whether each particular process ID on the received process list is on its internal process list. Whenever a particular process ID on the received list is not on its internal list, theengine605 adds (at705) the particular process ID to the internal list. Also, each time theengine605 adds (at705) a particular process ID to its internal list, the engine performs the following six operations. First, it identifies the secondary-identifier attributes of the application associated with the added process ID, and asks theinventory tracker215 for the SIID of the associated application.

Second, it generates a unique ill that in conjunction with the session ill uniquely identifies this execution of the application. Third, it specifies the current time as the start time for this execution of the application. Fourth, it instantiates a data object in the cache for storing several attributes relating to this execution of the application. Fifth, it stores the received OS process ill, the generated SIID, the identified unique ill, and the start time for this execution of the application in the instantiated data object. Sixth, it initializes several other attributes of the instantiated data object. These attributes include (1) an end time for specifying the time when this execution of the application terminates, (2) an incremental process duration for specifying an incremental duration of this execution, (3) a focus duration for specifying the time that this execution was in focus, (4) an active time for specifying the time that this execution was actively engaged by the user.

These six operations do not have to be performed in sequence. After705, the data-gathering engine605 increments (at710) the incremental process duration of each process on the data-gathering engine's process list except the processes that were just added at705. The engine increments each process duration by the amount of time since the last instance when the OS tracker provided its list of running applications to the data-gathering engine.

Next, the engine determines (at715) whether a process is currently in focus. Each time the focus changes from one process to another, the OS tracker notifies theengine605 of the identity of the new process that is in focus. This engine then increments the focus-duration attribute of the previously focused process' data object in thecache610, and sets an internal variable that identifies the newly focused process. Different embodiments increment the focus-duration attribute of the previously focused process differently. Some embodiments increment this attribute by a fixed time interval. Others increment this attribute by the amount of time that has elapsed since the last time that this attribute was incremented. For the later approach, the data-gathering engine605 needs to maintain a timer to measure the elapsed time.

At715, the data-gathering engine examines the value of its internal variable to determine whether a process is currently in focus, and if so, the identity of the focused process. If this engine determines (at715) that no process is in focus, it transitions to735, which is further described below.

On the other hand, if a process is in focus, the data-gathering engine determines (at720) whether the focused process is also active. This engine makes this determination based on the activity variable that it receives from theactivity tracker235. The activity tracker periodically supplies an activity variable that specifies whether the user is currently engaging a focused application.

When the activity variable specifies an active status, the data-gathering engine transitions from720 to730. At730, this engine increments the focus-duration and active-duration attributes of the focused process' data object in thecache610. In some embodiments, theengine605 increments these attributes by a time interval between receiving the current process list and the previous process list. When the activity variable specifies an inactive status, the data-gathering engine transitions from720 to725. At725, this engine increments just the focus-duration attribute of the focused process' data object in thecache610. Again, in some embodiments, the engine increments the focus-duration attribute by the time interval between receiving the current process list and the previous process list.

From725 or730, the data-gathering engine transitions to735. At735, this engine identifies any process specified on its internal process list that is not specified on the received process list (i.e., identifies any process that is no longer running). For each process that this engine identifies at735, this engine (1) specifies the current time as the stop time of the process, and (2) sets the process' stop time in the data object for the process in thecache610. After735, the flow illustrated inFIG. 7 terminates.

As mentioned above, the data-exportingengine615 reads out the data that the data-gathering engine605 stores in thecache610. The data-exporting engine reads out this data each time it receives a trigger event from the scheduler.FIG. 8 illustrates several operations that the data-exportingengine615 performs each time it receives a trigger event from the scheduler. As shown in this figure, the data-exportingengine615 initially selects (at805) a process from the internal process list that the data-gathering engine605 periodically updates at705. The data-exportingengine615 then examines (at810) the cache to determine whether it specifies a start time for the selected process. If so, this engine generates (at810) a start data item for the selected process.FIG. 9 illustrates the attributes of astart data item900 in some embodiments of the invention. Thestart data item900 specifies the start time, the SIID, and the unique ill of the selected process.

After810, the data-exportingengine615 generates (at815) an update data item for the selected process.FIG. 10 illustrates the attributes of anupdate data item1000 in some embodiments of the invention. Theupdate data item1000 specifies the SIID, the unique ill, the incremental process-running duration, the focus duration, and the active duration of the selected process. At815, the data-exportingengine615 sets the SIID, unique ill, and incremental process-running duration of the update data item to the corresponding values of these attributes that are stored in thecache610. At815, theengine615 also re-initializes the selected process' process-running duration in the cache.

After815, theengine615 examines (at820) the cache to determine whether it specifies a non-default focus duration and/or active duration for the selected process. If so, the engine adds (at820) the incremental focus and/or active durations to the update data item generated at815. At820, theengine615 also re-initializes the selected process' focus and active durations.

Next, the data-exportingengine615 examines (at825) the cache to determine whether it specifies termination data for the selected process. If so, this engine generates (at825) a stop data item for the selected process.FIG. 11 illustrates the attributes of astop data item1100 in some embodiments of the invention. Thestop data item1100 specifies the SIID, the unique ill, and the stop time of the selected process. When the cache includes termination data for the selected process, the data-exporting engine not only generates the stop data, but also removes (at825) the selected process' ill from the internal process list.

After830, the data-exporting engine determines (at835) whether it has examined all the processes specified on the internal process list. If not, the engine returns to805 to select another process specified by this list, and then to repeat810-830 for this newly selected process. When this engine determines (at835) that it has examined all the processes specified by the internal process list, it specifies (at840) the start and stop times of the tracking interval. The tracking interval is the interval between the current and last times that the exportingengine615 performed the operations ofFIG. 8 (i. e., between the current and last times that the exportingengine615 received trigger events from the scheduler). It specifies the tracking-interval start and stop times for all the data items that it generated in the current iteration of operations805-835. It can specify the start and stop times by incorporating these times in each generated data item, or it can have one copy of the start and stop times for all the data items stored in the aggregator. After840, theengine615 terminates the flow illustrated inFIG. 8.

D. Browser Tracker

Thebrowser tracker205 monitors the use of the client computer's browsers. The browser tracker tracks different browser events in different embodiments. In the embodiments described below, the browser tracker tracks one or more time periods for each URL event of the browsers.

In the embodiments described below, a URL event occurs when the client computer downloads the content that resides at a particular URL. The content residing at a particular URL will be referred to below as the particular URL's content.

FIG. 12 presents a conceptual illustration of the browser tracker. As shown in this figure, the browser tracker includes a data-gathering engine1205, acache1210, and a data-exportingengine1215. The data-gathering engine605 receives data from theOS tracker230 and theactivity tracker235. Specifically, when theclient application120 starts (e.g., at boot up), the data-gathering engine registers to receive periodically the process list and focused-process ID from the OS tracker, and registers to received the activity signal from the activity tracker.

This engine also receives URL echo events through one of two mechanisms illustrated inFIG. 12. In some embodiments, the data-gathering engine1205 receives URL echo events through abrowser tracker agent1235 that is loaded with thebrowser1230. In some of these embodiments, thebrowser tracker agent1235 is used in conjunction with the Internet Explorer (“IE”) browser. In these embodiments, this agent is a .dll that is loaded when the IE browser is loaded. When loaded, thisagent1235 registers as a client for receiving IE events from the IE browser. Each time IE downloads certain content that resides at a particular URL, it publishes an IE event to all registered recipients of IE events. A published IE event specifies the downloaded URL, some HTTP header info as well as some frame information. Whenever thebrowser tracker agent1235 receives an IE event, it forwards it to the data-gathering engine1205 of thebrowser tracker205.

In other embodiments, the data-gathering engine1205 receives these events through the dynamic data exchange (“DDE”)1220 of the OS. Specifically, thebrowser1230 registers with the OS as a DDE server when the browser loads. Each time the browser tracker's data-gathering engine1205 identifies (on the process list received from the OS tracker) a new instance of a browser that is running, this engine registers with the OS as a DDE client that should receive browser events relating to the newly identified browser instance. From thereon, whenever the browser downloads certain content that resides at a particular URL through the newly identified browser instance, the browser publishes its URL event to each module (including engine1205) that registered as a DDE client for the newly identified browser instance. Each URL event that is published in this manner provides the URL plus some ancillary frame information. In some embodiments, the data-gathering engine1205 uses the DDE-mechanism for non-IE browsers, such as the Netscape navigator.

Based on the data that it receives, the data-gathering engine1205 stores data in thecache1210 each time it receives a URL event. For each URL event, the gathered data relates to: (1) the URL's incremental run time, which represents an incremental duration of time that the browser presents the URL's content at the client computer (e.g., displays in a window or frame), (2) the

URL's focus time, which represents the duration of time that the browser's presentation of a URL's content is in focus, and (3) the URL's active time, which is the duration of time that a user at the client computer is actively engaged with the browser's presentation of a URL's content.

The data-exportingengine1215 reads out the content of the cache1210 (i.e., generates data items) each time it receives a notification from thescheduler240. The data-gathering engine is first described below by reference toFIG. 13. The data-exportingengine1215 is then described by reference toFIGS. 14-17.

Each time that the data-gathering engine1205 receives a URL event for a particular instance of a running browser, the data-gathering engine performs several operations illustrated inFIG. 13. As shown in this figure, theengine1205 initially generates (at1302) a URL ID. In some embodiments, the generated URL ID is an MD5 hash of the domain and path data of the URL. Next, theengine1205 determines (at1305) whether it had previously received another URL event for the particular browser instance at issue (i.e., the browser instance of the received URL event). If not (i.e., if the received URL is the first URL event that the engine has received in the current session for the particular browser instance at issue), the engine sets (at1310) a variable Current URL to the URL of the received event. This variable identifies the current URL of the particular browser instance at issue.

Theengine1205 then specifies (at1315) a unique ID for the received URL event, and adds this unique ID and the generated URL Id to a URL event list that the engine maintains. The unique ID in conjunction with the session ID uniquely identifies the received URL event. At1315, the engine also specifies the current time as the start time for the received URL. Also, it records the browser for the received URL event.

At1315, the engine then (1) instantiates a data object in thecache1235 for the received URL event, and (2) stores the URL, URL ID, unique ID, start time, and browser of the received URL event in this instantiated data object. In the embodiments that use thebrowser tracker agent1235, the engine also stores (at1315) in the cache data object the header information that it receives as part of the URL event supplied by theagent1235. Also, at1315, the engine initializes several other attributes of the instantiated data object. These attributes include (1) an end time for specifying the time when the URL event terminates, (2) a incremental run duration for specifying an incremental duration of time that the browser presents the URL's content at the client computer, (3) a focus duration for specifying the time that the URL event is in focus, and (4) an active time for specifying the time that the URL event is actively engaged by the user.

After1315, the data-gathering engine1205 increments (at1317) the incremental run duration of the received URL event. The engine increments this duration by the amount of time since the last instance when this engine received a URL event for the particular browser instance at issue. After1317, the engine determines (at1320) whether the particular browser instance at issue is currently in focus. Each time the focus changes from one process to another, the OS tracker notifies theengine1205 of the identity of the new process that is in focus. If the previously focused process is the particular browser instance at issue, this engine then increments the focus-duration attribute of the cache data object of the previously focused URL event for the particular browser instance, and then sets an internal variable that identifies the newly focused process. Different embodiments increment the focus-duration attribute of a previously focused

URL event differently. Some embodiments increment this attribute by a fixed time interval.

Others increment this attribute by the amount of time that has elapsed since the last time that this attribute was incremented. For the latter approach, the data-gathering engine1205 needs to maintain a timer to measure the elapsed time.

At1320, At1320, the data-gathering engine examines the value of its internal variable to determine whether a process is currently in focus, and if so, the identity of the focused process. If this engine determines (at1320) that the particular browser instance at issue is not in focus, it ends the operations illustrated inFIG. 13. On the other hand, if the particular browser instance at issue is in focus, the data-gathering engine determines (at1325) whether the focused browser instance at issue is also active. This engine makes this determination based on the activity variable that it receives from theactivity tracker235. The activity tracker periodically supplies an activity variable that specifies whether the user is currently engaging a focused application.

When the activity variable specifies an active status, the data-gathering engine transitions from1325 to1330. At1330, this engine increments the focus-duration and active-duration attributes of the cache data object for the active, focused URL event. In some embodiments, theengine1205 increments these attributes by a time duration that corresponds to the time interval between receiving the current and previous events for the particular browser instance at issue.

When the activity variable specifies an inactive status, the data-gathering engine transitions from1325 to1335. At1325, this engine increments just the focus-duration attribute of the cache data object of the focused URL event. Again, in some embodiments, the engine increments the focus-duration attribute by the time duration that corresponds to the time interval between receiving the current and previous events for the particular browser instance at issue. After1330 or1335, the operations illustrated inFIG. 13 terminate. If the engine determines at1305 that it has received a prior URL event for the particular browser instance at issue (i. e., if the received URL is not the first URL event that the engine has received in the current session for the particular browser instance at issue), the engine determines (at1340) whether the URL of the received event is identical to the Current₁₃URL for the particular browser instance at issue. If so, the engine transitions to1317, which was described above. If not, it transitions to1345. At1345, the engine specifies the current time as the stop time of the Current₁₃URL's event, and sets this URL event's stop time in its data object in thecache1210. From1345, the engine transitions to1310, which was described above.

The data-gathering engine1205 also sets the stop time of the Current₁₃URL of a particular browser instance, when this engine determines that the particular browser instance is no longer running. Specifically, as mentioned above, this engine receives the process list from the OS tracker periodically. Whenever it receives such a list, one of the tasks that it performs is to identify any browser instance that was on the previous process list (i.e., the process list that it received immediately before the current process list) but not the current process list. If it identifies any such recently terminated browser instance, the engine (1) identifies the object in thecache1210 for storing data relating to this browser instance's Current₁₃URL, and (2) sets the stop time specified by this object to the current time.

As mentioned above, the data-exportingengine1215 reads out the data that the data-gathering engine1205 stores in thecache1210. The data-exporting engine reads out this data each time it receives a trigger event from the scheduler.FIG. 14 illustrates several operations that the data-exportingengine1215 performs each time it receives a notification from the scheduler.

As shown in this figure, the data-exportingengine1215 initially selects (at1405) a URL event from the URL-event list that the data-gathering engine1205 keeps. The data-exportingengine1215 then examines (at1410) thecache1210 to determine whether it specifies a start time for the selected URL event. If so, this engine generates (at1410) a start data item for the selected URL event.FIG. 15 illustrates the attributes of astart data item1500 in some embodiments of the invention. Thestart data item1500 specifies the URL ill, the browser ID, the start time, the URL, the unique ill, and the header information (if any) of the selected URL event.

After1410, the data-exportingengine1215 generates (at1412) an update data item for the selected URL event.FIG. 16 illustrates the attributes of anupdate data item1600 in some embodiments of the invention. Theupdate data item1600 specifies the URL ID, the unique ID, the focus duration, the active duration, and the incremental running duration of the selected URL event. At1412, the data-exportingengine615 sets the unique ID and incremental running duration of the update data item to the corresponding values of these attributes that are stored in thecache1210. At1412, theengine1215 also re-initializes the selected URL's running duration in the cache.

After1412, theengine1215 examines (at1415) the cache to determine whether it specifies a non-default focus duration and/or active duration for the selected URL event. If so, this engine adds (at1415) the incremental focus and/or active durations to the update data item generated at1412. At1415, theengine1215 also re-initializes the selected URL event's focus and active durations.

Next, the data-exportingengine1215 examines (at1420) the cache to determine whether it specifies termination data for the selected URL event. If so, this engine generates (at1420) a stop data item for the selected URL event.FIG. 17 illustrates the attributes of astop data item1700 in some embodiments of the invention. Thestop data item1700 specifies the URL ill, the unique Id and the stop time of the selected URL event. When the cache includes termination data for the selected URL event, the data-exporting engine not only generates the stop data, but also removes (at1425) the selected URL event' ill from the URL event list.

After1425, the data-exporting engine determines (at1430) whether it has examined all URL events specified on the URL-event list. If not, the engine returns to1405 to select another URL event specified by this list, and then to repeat1410-1425 for this newly selected URL event. When this engine determines (at1430) that it has examined all events specified by the URL event list, it specifies (at1435) the start and stop times of the tracking interval. The tracking interval is the interval between the current and last times that the exportingengine1215 performed the operations ofFIG. 14 (i.e., between the current and last times that the exportingengine1215 received trigger events from the scheduler). It specifies the tracking-interval start and stop times for all the data items that it generated in the current iteration of operations1405-1430. It can specify the start and stop times by incorporating these times in each generated data item, or it can have one copy of the start and stop times for all the data items stored in the aggregator. After1430, theengine1215 terminates the flow illustrated inFIG. 14.

E. Hardware Inventory Tracker

Thehardware inventory tracker225 inventories the hardware resources of theclient computer115. The hardware resources inventoried by thehardware inventory tracker220 can include any hardware or hardware setting of theclient computer115. Examples of these resources are memory, disk storage, CPU(s), network card(s), sound card, video card, virtual memory settings, etc.

In some embodiments, thehardware inventory tracker225 periodically inventories the hardware resources and maintains an inventory cache that identifies all the inventoried resources.

Each time that this tracker identifies a hardware resource that has been added or removed, it generates a data item that identifies the added or removed resource. The tracker passes such data items to the data filter, which then filters them and passes the filtered data to the aggregator for eventual transmission to thesystem server105.

At the system server, the inventoried data can be analyzed for a variety of purposes. For instance, the data can be analyzed in order to identity the hardware resources employed ondifferent client computers115, to categorize these hardware resources, to detect unauthorized additions and/or removals of hardware resources, etc. The inventoried data can also be used to facilitate the hardware utilization analysis that is performed based on the data collected by thehardware utilization tracker210.

Figure18 illustrates several operations that thehardware inventory tracker225 performs periodically to create and maintain its cache of inventoried resources. Thetracker225 starts these operations at the expiration of a timer that it maintains. As shown inFIG. 18, thetracker225 initially (at1805) (1) creates an inventory cache when this is the first time that it is performing the operations ofFIG. 18 for the current session, or (2) loads the previously created inventory cache after the first iteration of the operations ofFIG. 18. As mentioned above, the inventory cache identifies each inventoried hardware resource by a hardware identifier that is generated from the hash of the attributes of the hardware resource.

After creating or loading the cache at1805, thetracker225 identifies (at1810) a list of hardware resources installed on the client computer. In some embodiments, the tracker obtains this list from the OS through a WMI (Windows Management Instrumentation) call that asks the OS for all hardware resources of the client computer.

After1810, thetracker225 selects (at1815) a resource specified by the list identified at1810. At1815, thetracker225 generates a hardware identifier (a hardware inventory ID, or HIID) for the resource selected at1815, based on the hash of the attributes of the selected resource. Next, the tracker uses (at1820) the generated hardware identifier to determine whether the inventory cache specifies the resource selected at1815. If so, the tracker transitions to1830, which is described below. If not, the tracker (at1820) (1) adds a data entry in the inventory cache for the resource, where the data entry specifies the resource's HIID, and (2) generates a new data item (called an “add data item”) that is for directing theserver105 to add the newly inventoried resource to the list of resources that the server maintains for the client computer. In some embodiments, the generated add data item specifies the HIID, class, category, description, friendly name, manufacturer, driver version, driver file size, driver file date, value, and units.

FIG. 19 illustrates an example of an add data item for a CPU. As illustrated in this figure, not all the data attributes of an add data item need to be used for a particular resource.

After1825, thetracker225 transitions to1830. At1830, the tracker determines whether it has examined all the resources specified by the list generated at1810. If not, it returns to1815 to select another resource from the list, and to perform the subsequent operations on the newly selected resource. Otherwise, it determines (at1835) whether each resource that the cache originally specified at1805 was identified at1820 as matching one of the resources specified by the list generated at1810.

If not, thetracker225 selects (at1840) a resource that was originally specified by the cache but was not examined at1820. At1840, the tracker removes the data entry in the cache for the selected unexamined resource, and then generates a remove data item for this resource. After1840, the tracker returns to1835 to determine whether it has now examined at1820 or1840 each resource that the cache originally specified at1805. If not, the tracker transitions to1840 again to select another unexamined resource, remove its data entry from the inventory cache, and generate its remove data item. Otherwise, when the tracker determines that it has examined each resource originally specified by the cache, the tracker resets (at1845) the timer that it uses to trigger its inventory operations, and then ends this inventory iteration. Thetracker225 eventually sends all the data items that it generates at1825 and1840 to the data filter.

F. Hardware Utilization Tracker

Thehardware utilization tracker220 monitors the use ofcertain hardware resources275 of theclient computer115. In some embodiments, this tracker records certain performance characteristics of certain hardware resources over time. For instance, in some embodiments, this tracker records the utilization of the computer's CPU, memory, disk storage, and network adapter over time. Also, in some embodiments, this tracker records the use of the CPU, memory, and network adapter by each individual process.

As illustrated inFIG. 20, the hardware utilization tracker includes a data-gathering engine2005, acache2010, and a data-exportingengine2015, like the browser and software utilization trackers. For some embodiments of the invention,FIG. 21 illustrates the set of operations that the data-gathering engine2005 performs to collect usage data for a particular hardware resource. Specifically, in some embodiments, this engine performs these operations to gather information about CPU, memory, or network utilization. Each iteration through the operations illustrated inFIG. 21 gathers information about one particular hardware resource (i.e., gathers information about the CPU, memory, or network card). As further described below, theengine2005 performs a simpler set of operations for gathering usage data about the client computer's storage.

The set of operations illustrated inFIG. 21 start each time a timer that thegathering engine2005 maintains expires. As shown inFIG. 21, the hardware utilization tracker initially obtains (at2105) data regarding the overall use and the per-application use of a particular hardware resource (e.g., the CPU) at a particular time. In some embodiments, the tracker obtains this data from the OS through a WMI (Windows Management Instrumentation) call that asks the OS for data for the particular hardware resource.

For each use that the gathering engine monitors, it specifies a set of attributes in thecache2005. This set of attributes includes tracking-interval start and end times, a usage value, a min value, and a max value. At2110, theengine2005 adds the total-use data obtained at2105 to a total-use summation value that it stores in thecache2010. It also adds (at2110) each particular per application use obtained at2105 to a summation value that it stores in the cache for the particular per application use. At2110, theengine2005 also ensures that each utilization that it obtained at2105 is specified on a list that it maintains of the utilizations in the current tracking interval.

Next, theengine2005 determines (at2120) whether the data obtained at2105 is the first data obtained for the particular hardware resource during the current tracking interval. If so, the tracker transitions to2165, which will be further described below. Otherwise, the tracker performs several calculations at2125. It averages the total use that it obtained for the particular hardware in the current iteration through the operations ofFIG. 21, with the total use that it obtained in the iteration that immediately preceded the current one. This engine also determines whether the total use obtained at2105 is either less than the min or greater than the max recorded for the particular hardware in the cache. If the received total use is less than the recorded min, this engine sets the recorded min to the received total use. If the received total use is greater than the recorded max, this engine sets the recorded max to the received total use.

Next, at2130, the data-gathering engine2005 determines whether the average computed at2125 exceeds a configurable threshold value. One of ordinary skill will appreciate that in some embodiments the threshold determination at2130 might determine whether a computed average is less than a threshold value.

If the engine determines (at2130) that the threshold is exceeded, it increments (at2135) by one a counter that it maintains for the total use. The client application initializes this counter when the client application starts, and the hardware utilization tracker re-initialized this counter at the end of each tracking interval.

If the engine had also detected that the threshold was exceeded during the last iteration through the operations ofFIG. 21 for the hardware resource at issue, theengine2005 also increments (at2135) a total duration attribute that it stores for the overall use of the hardware resource at issue. It increments this duration by the amount of time since the last instance when this engine performed the operations illustrated inFIG. 21 for the hardware resource at issue. The client application initializes this total duration when the client application starts, and the hardware utilization tracker re-initialized this counter at the end of each tracking interval. From2135, theengine2005 transitions to2140.

The engine also transitions to2140 from2130, when it determines that the computed average does not exceed the threshold. At2140, the engine determines whether it has examined all the received per-application uses of the particular hardware. If not, it selects (at2145) a received per-application usage. It then averages (at2150) the per-application use that it obtained for the particular hardware in the current iteration through the operations ofFIG. 21, with the per-application use that it obtained in the iteration that immediately preceded the current one.

This engine also determines (at2150) whether the selected per-application use is either less than the min or greater than the max recorded for the selected per-application use of the particular hardware in the cache. If the received total use is less than the recorded min, this engine sets (at2150) the recorded min to the received total use. If the received total use is greater than the recorded max, this engine sets (at2150) the recorded max to the received total use.

From2150, the engine transitions to2155, where it determines whether the average computed at2150 exceeds a threshold value for the selected per-application use. If so, it increments (at2160) by one a counter that it maintains for the selected per-application use. Like the total-use counter, the client application initializes each per-application use counter when the client application start, and the hardware utilization tracker re-initialized each such counter at the end of each tracking interval. If the engine had also detected that the threshold was exceeded during the last iteration through the operations ofFIG. 21 for the hardware resource at issue, theengine2005 also increments (at2160) a per-application duration attribute that it stores for the selected application's use of the hardware resource at issue. It increments this duration by the amount of time since the last instance when this engine performed the operations illustrated inFIG. 21 for the hardware resource at issue. The client application initializes this per-application duration when the client application starts, and the hardware utilization tracker re-initialized this duration at the end of each tracking interval.

From2160, theengine2005 transitions to2140. The engine also transitions to2140 from2155, when it determines that the threshold has not been exceeded.

When the engine determines (at2140) that all the received per-application usages have been examined, it transitions to2165. At2165, the engine resets the timer that it uses for performing the tracking operations illustrated inFIG. 21 for the particular hardware resource. It then ends the current iteration of these operations.

FIG. 22 illustrates the set of operations that theengine2005 performs for the storage utilization. This set is simpler than the set of operations illustrated inFIG. 21. In some embodiments, the data-gathering engine2005 does not track per-application uses of the storage.

Hence, it does not obtain any per-application data at2105, and does not store or increment any per-application data at2110. Also, its set of operations for storage-utilization tracking does not include operations2140-2160. Accordingly, the engine transitions to2165 from2135 and from2130 (when the threshold is not exceeded). The remaining operations illustrated inFIG. 22 are similar to those similarly numbered inFIG. 21, and therefore will not be further described in order not to obscure the description with unnecessary detail.

The data-exportingengine2015 reads out the data that the data-gathering engine2005 stores in thecache2010. The data-exporting engine reads out this data each time it receives a trigger event from the scheduler.FIG. 23 illustrates several operations that the data-exportingengine2015 performs each time it receives a notification from the scheduler for a particular hardware device (e.g., for the CPU). Specifically, in some embodiments, this engine performs these operations to export data about CPU, memory, or network utilization. Each iteration through the operations illustrated inFIG. 23 gathers information about one particular hardware resource (i.e., gathers information about the CPU, memory, or network card). As further described below, theengine2015 performs a simpler set of operations for exporting data about the client computer's storage.

As shown in this figure, the data-exportingengine2015 initially determines (at2305) whether the utilization of the hardware resource at issue exceeds a threshold at least once during the tracking interval that just ended. If not, theengine2015 terminates its operation. Otherwise, it determines (at2310) whether the overall utilization of the hardware resource exceeds the overall threshold at least once. If not, the engine transitions to2330, which is described further below.

Otherwise, when theengine2015 determines that the overall utilization exceeded the overall threshold at least once, it generates (at2315) a hardware-utilization data item that stores the overall use of the hardware resource that is at issue (e.g., the overall use of the CPU, when this iteration of the operations ofFIG. 23 is for exporting collected CPU data).

FIG. 24 illustrates the attributes of a hardware-utilization data item in some embodiments. As shown in this figure, the hardware-utilization data item includes (1) the tracking interval start and stop times, (2) a resource-utilization type (e.g., CPU, or CPU by application), (3) a name for the utilization, (4) the duration, and (5) the average, minimum, and maximum utilization. Theengine2015 retrieves the duration as well as the minimum, and maximum utilization data from thecache2010. It computes the value of the average attribute by (1) taking the total-use summation value that was created and probably repeatedly incremented at2110 and (2) dividing it by the duration of the tracking interval. It can also retrieve the tracking interval start and stop times and the resource-utilization name and type from the cache, or it can maintain a record of these parameters itself.

As shown inFIG. 24, the hardware-utilization data item also includes an SIID attribute. When the data item relates to per-application use of a particular hardware resource, the SIID specifies the application that is using the hardware resource. The hardware-utilization data item also specifies exception attributes. The exception attributes include two values, which are: (1) an exception level, and (2) a count value that specifies the number of times that the use exceeded a configured threshold value. Some embodiments might also include the configured threshold value as an exception attribute of the hardware-utilization data item.

engine

2015 specifies the exception attributes at2320. Specifically, at2320, the engine retrieves attributes relating to the exception level from thecache2010. These attributes are the count and duration that were computed at2135 by the data-gathering engine. Based on the retrieved count and duration data, the engine specifies an exception level. For instance, some embodiments might specify five exception levels for CPU usage, where each level requires that the CPU utilization exceed its threshold usage a particular number of times for a particular duration.

After identifying the appropriate exception level at2320, the engine populates (at2325) the exception attributes (e.g., the exception level and its related count) in the generated data item. It then transitions to2330. At2330, it determines whether the cache stores data for any application whose use of the particular hardware resource exceeded the application's threshold use at least once in the last tracking interval (i.e., the tracking interval that just ended).

If so, it generates (at2335) a hardware-utilization data item that stores the selected application's use of the hardware resource that is at issue (e.g., the word processor's use of the CPU, when this iteration of the operations ofFIG. 23 is for exporting collected CPU data).

This generated data item is similar to the one generated at2315, which was described above and illustrated inFIG. 24. One difference is that the data item generated at2335 includes the SIID of the application selected at2335. Another difference is that the average attribute specified by the data item generated at2335 is the average hardware utilization by the selected application.

Accordingly, the data-exporting engine computes this value by taking the summation value that was created and possibly incremented at2110 for the selected application, and dividing it by the duration of the tracking interval. Also, the data-exporting engine computes the exception level of data item generated at2335 based on the count and duration that the data-gathering engine computed at2160 for the selected application. The data-exporting engine then records the computed exception level and its related count value in the data item that it generates (at2335) for the selected application.

From2335, the engine transitions to2320 and then to2325, in order to compute the exception level and then populate the exception attribute in the data item generated at2335. When theengine2015 determines that it has examined the utilization data of each application whose use exceeded its threshold value, it terminates the operations illustrated inFIG. 23. The data exporting engine's operation for exporting storage data items is much simpler.

Essentially, as the storage usage does not include per application usage, theengine2015 only performs the

operations

2305,2315,2320, and2325. For the storage data, the engine terminates its operations (1) when it determines at2305 that the threshold value was not exceeded once, or (2) when it completes its operation at2325.

One of ordinary skill will understand that other embodiments might specify exceptions for hardware utilization differently. For instance, some embodiments might measure a duration for each contiguous period that a hardware resource is being used above a threshold value. These embodiments might then specify the exception level not only based on the number of times that the threshold is exceed but also based on the duration of each contiguous time period that the use exceeds the threshold value.

G. Data Filter

FIG. 25 illustrates the software architecture of the data filter245 in some embodiments of the invention. As shown in this figure, thedata filter245 includes afiltering engine2505, five rule sets2510-2530, anXML parser2535, and five XML rule documents2540-2560. Embedded in each XML rule document is one set of rules. Specifically,XML rule document2540 includes filtering rules for browser utilization data items,XML rule document2545 includes filtering rules for software utilization data items,XML rule document2550 includes filtering rules for software inventory data items,XML rule document2555 includes filtering rules for hardware utilization data items, andXML rule document2560 includes filtering rules for hardware inventory data items.

The XML parser generates a rule set for each rule document. In some embodiments, it parses out each rule in a rule document and generates a data object that specifies the parsed-out rule. The rule set corresponding to a rule document is the collection of the rule data objects generated from the rule document. The data filter illustratedFIG. 25 embeds the filtering rules in XML documents in order to allow theclient application120 to easily modify its filtering rules.

Theclient application120 can seamlessly receive XML rule documents, which can be easily parsed out into new filtering rule sets. Thefiltering engine2505 uses the rule sets2510-2530 to filter the data items that the data filter receives from the browser, software, and hardware trackers205-225, and then passes the filter data items to the aggregator. This engine uses the rule set2510 to filter browser utilization data items, uses the rule set2515 to filter software utilization data items, uses the rule set2520 to filter software inventory data items, uses the rule set2525 to filter hardware utilization data items, and uses the rule set2530 to filter hardware inventory data items.

As mentioned above, each rule set includes a number of rules relating to the filtering of the data items for the rule set. In some embodiments, the rules of a rule set can specify the elimination of a data item or the modification of some or all attributes of a data item. The rules might also specify that thefiltering engine2505 needs to pass a data item through to the aggregator without any modifications. In some embodiments, thefiltering engine2505 receives a data item, identifies the appropriate rule set for the data item, sequentially invokes the rules in the identified rule set, and passes the data item to each invoked rule. Each invoked rule then makes no modification to the data item or commands the data item to modify some or all of its attributes, or to mark itself for deletion by the filtering engine.FIG. 26 illustrates one such flow of operations of the data filter.

Examples of filtering operation suggested by a rule include (1) eliminating software utilization and inventory data items that relate to certain SIID's (e.g., filtering out inventory data items relating to back up programs or OS level executables), (2) eliminating hardware inventory data items that relate to unused hardware resources (e.g., unused network adapters), (3) eliminating hardware utilization data items that do not relate to certain monitored metrics (e.g., eliminating data relating to CPU utilization that is less than 20 percent), and (4) modifying browser utilization data items that specify query strings (e.g., replacing a long query string with a shorter one).

AlthoughFIG. 25 illustrates five rule sets that are generated from five rule documents, one of ordinary skill will realize that other embodiments might use fewer or greater number of rule sets and rule documents. For instance, some embodiments use three rule sets that are generated from three rule documents, where one of the rule documents is for browser utilization, one is for software inventory and utilization, and one is for hardware inventory and utilization.

III. Server

A. Architecture

Figure27 illustrates the architecture of the server-side software105 of some embodiments of the invention. In these embodiments, theserver105 includes anapplication server2705, acollection data storage2710, adata transformer2715, adata warehouse2720, areporting engine2725, and are-categorizing module2730. These components of the server can be implemented on one or more computers.

As shown inFIG. 27, theapplication server2705 communicates with one ormore client applications120. The application server performs various session services, such as authenticating users that log on at theclient computers115, providing each authenticated client computer with a session ID, maintaining a universal system time, etc. The application server also receives inventory and usage data from the client applications, filters this data, aggregates some or all of the filtered data, and stores the data in thecollection data storage2720. Thedata transformer2715 transforms the data stored in the collection data storage into a format that is optimized for efficient querying, analysis, and reporting. The data transformer stores the transformed data in thedata warehouse2720.

The data warehouse includes a category table, which, as further described below, specifies categories that the application server uses to categorize the collected data. Asystem administrator2735 can modify the category table's categories that are used during the categorization. There-categorizing engine2730 periodically examines the category table, and further modifies the records in this table based on the system administrator's modifications.

Thereporting engine2725 queries the data in thedata warehouse2720, and generates reports based on the queries. In some embodiments, the reporting engine is a commercially available third-party tool, such as the reporting tool of Microstrategy Corporations. In some embodiments, the reporting engine presents its reports through a web browser, such as Internet Explorer. Also, the reporting engine has different querying and reporting options. For instance, it can perform queries and distribute the results of its queries in an automated fashion (e.g., perform queries at pre-determined time intervals and transmit the result via e-mail). Alternatively, the reporting engine can perform queries in response to a direct user request, and can have the user manually direct its delivery of the query results.

B. Collection Data Storage

The collection data storage is a database in some embodiments.FIG. 28 illustrates the schema of this database in some embodiments of the invention. As shown in this figure, this database includes inventory tables, utilization tables, and personnel tables. The inventory tables store inventory data that the client applications gather relating to the hardware, software, and browser resources (i.e., the hardware, software, and browser assets) of their computers. The inventory tables include a primary asset table2805 that stores attributes used for queries that are applicable across all asset types. Examples of such attributes are an attribute's type, name, category, category ill, and parent category ill. These tables also include three secondary asset tables2810, one for software assets, one for hardware assets, and one for browser assets. Each secondary table stores attributes that are unique to its asset type (i.e., the secondary software, hardware, and browser tables store attributes that are unique respectively for software, hardware, and browser assets). Each record in a secondary assets table is associated with a record in the primary asset table through an Asset₁₃ID, which is the identifier for an inventoried asset. In some embodiments, the Asset₁₃ID for a software item is its SI ID, for a hardware item is its HIID, and for a browser item is its URL ID.

As shown inFIG. 28, the utilization tables include four hardware tables2815,2820,2825, and2827 and three process tables2830-2840. The three process tables are used to store data relating to software utilization and browser events. The three process tables include the primary process table2830, and the secondary process tables2835 and2840. The primary process table2830 can store numerous records, where each record corresponds to a browser event or software utilization that thesystem100 tracks. Each record specifies a Process₁₃ID, a Unique₁₃ID, an Asset₁₃ID, start and end times, a duration, and a session ID. The Asset₁₃ID is the SIID of the software application or URL ill of the URL event, and it associates the usage data with records in the inventory tables. The Process₁₃ID is an ill that the application server assigns to each new instance of a software utilization or URL event (i.e., assigns each time it receives a start data item from the software or browser tracker of a client). In this manner, the Process₁₃ID uniquely identifies an instance of software utilization or URL event.

The Unique₁₃ID of each record in the process table2830 is the client's Unique₁₃ID for the software utilization or the URL event. Also, the start and end times of each record in the process table are the start and end times that the client application reports in the start and stop data items for the software and URL event of the record. The duration specified by each record in the primary process table2830 is the total duration of the software utilization or browser event corresponding to the record. The session ID of a record in the process table2830 is the session ID that theserver105 assigned to theclient application120 that gathered the data stored in the record.

As shown inFIG. 28, the primary process table also includes an attribute that provides the Browser ID. This application server uses this attribute only for browser event. Specifically, when it receives a start data item from the browser tracker of a client application, it extracts the browser ID in the received data item. It then uses the extracted ID to populate the Browser ID attribute of the record in the process table2830 that it creates for the received browser event.

The secondary process tables2835 and2840 can respectively store data regarding the focus and active durations of a software utilization or browser event that is recorded in the primary process table2730. Each record in a secondary process table is associated with a record in the primary process table2830 through the Process₁₃ID assigned by the application server.

Also, the application server might create multiple records in the secondary process tables2835 and2840 for the same software utilization or browser event. Specifically, each time the application server receives an update data item that includes a focus or active duration, the application server creates a new record in the secondary table2835 or2840 to store the received focus or active duration. For each such record, the secondary table records the start and stop times of the tracking interval during which the focus or active data was captured. As mentioned above, the client applications report the start and stop times of a tracking interval with the data items that it generates at the termination of the tracking interval.

The hardware table2820 can store numerous records relating to hardware utilization that thesystem100 tracks. Each record specifies a Hardware₁₃ID, Resource₁₃Type₁₃ID, Asset₁₃ID, start time, end time, duration, average, mm, max, Exception₁₃ID, session ID, and SIID. The Hardware₁₃ID is an ID that the application server assigns each time it receives a data item from a hardware utilization tracker of a client application. In this manner, the Hardware₁₃ID uniquely identifies an instance of a hardware utilization. A record's session ill is the session ill that theserver105 assigned to theclient application120 that gathered the data stored in the record. The start and end times of each record in the hardware table are the start and end times that the client application reports in the start and stop data items for the hardware utilization of the record. A record's duration in the hardware table2820 is the duration of the record's corresponding hardware utilization (i.e., the duration reported in the received hardware utilization data item). A record's Asset₁₃ID in the hardware table2820 is the ID of the computer that contains the record's corresponding hardware resource. This ID is generated by the application server, and it is the parent category ID that is stored in the primary asset table2805 for the corresponding hardware resource. In this manner, this asset ID associates the hardware utilization data with records of hardware resources in the inventory tables.

A hardware utilization tracker of a client application typically generates multiple data items for a particular hardware item during a session. Several data items would relate to the overall use of the particular hardware item during different tracking intervals in a particular session. Other data items would relate to the per-application use of the particular hardware item in the particular session. Each time the application server receives a data item from a hardware utilization tracker, the application server creates a new record in the hardware table2820. If the data item is one that relates to a particular software application's use of a particular hardware device, the application server records the particular software application's SIID in the hardware-table record that it creates for the received start data item. The average, min, and max attributes of a record in the hardware table2820 are the average, min, and max attributes that are reported in the received data item.

The Resource₁₃Type₁₃ID of each record in the hardware table2820 specifies a particular resource type. The name and usage metric (e.g., time, bytes, etc.) of each resource type are specified in the Resource₁₃Type table2815. Accordingly, the Resource₁₃Type _ID indexes a record in the Resource₁₃Type table2815 that specifies the name and usage metric (e.g., time, bytes, etc.) for its particular resource type.

The Exception₁₃ID of each record in the hardware table2820 indexes a record in the Resource₁₃Exception table2827, which provides a Resource₁₃Threshold₁₃ID, an Exception₁₃Level, and an Exception₁₃Count for the Exception₁₃ID. The Exception₁₃_Count provides the number of times that the threshold was exceeded during the hardware-utilization specified in the corresponding hardware-table record. The Exception₁₃Level and the Exception₁₃Count are provided by the received data item, in some embodiments. In other embodiments, the exception levels are computed at the server, based on exception attributes collected by the client applications.

The Resource₁₃Threshold₁₃ID of an exception record in the exception table2827 specifies a record in the Resource₁₃Threshold table2825. The record that this ID indexes provides the configurable threshold parameters for the ID's exception. In some embodiments, these parameters include a size operator (e.g., greater than, or less than), a threshold value (e.g., 10%), and the number of times that the threshold value needs to be crossed before specifying an exception.

The personnel tables include the Tracked₁₃Personnel table2845, a Global₁₃Personnel table2850, one or more ERP₁₃Tables2855, and an Asset₁₃Personnel table2860. The Tracked₁₃Personnel table2845 stores a record for each individual that the system tracks. Each record in this table specifies the domain, user logon, session ID, and possibly other system-administration attributes for the record's corresponding individual. In some embodiments, the session ID includes the user ID of the individual.

The Global₁₃Personnel table2850 stores a record for each individual of an entity that is employing the resource-management system100. Some of these individuals might not have their resources tracked by thesystem100. Also, each individual's record is specified in the Global₁₃Personnel table by a unique user ID. In addition, each individual's record in the Global Personnel table is associated to one or more records in one or more ERP tables. The ERP tables are typically provided by commercially available ERP tools that allow an entity to store its organizational information. In some embodiments, the ERP table or tables provide the department, location, and job-title for each individual identified in the Global₁₃Personnel table2850.

The Asset Personnel table2860 associates the records of each tracked individual with the records of the assets tracked for the individual. Specifically, for each asset that the individual uses at some point, the Asset₁₃Personnel table stores a record that identifies the individual and the used asset. Each such record specifies the status of the individual's association with the asset. In some embodiments, the status attribute has two values, which are “current” and “removed.” The records in the Tracked₁₃Personnel, Global₁₃Personnel, ERP, and Asset Personnel tables are associated through the user ID's.

C. Application Server

FIG. 29 illustrates the architecture of theapplication server2705 in some embodiments of the invention. In these embodiments, the application server includes amessenger2905, a data
-item identifier2910, asession manager2915, asynchronizer2920,several data handlers2925
2945, adata filter2950, and adatabase interface2955.
The messenger is a typical transport module for a client/server environment. It is a bi-directional module that receives and transmits data to and from theclient applications120. When a user first logs on to the system, the messenger has thesession manager2915 authenticate the user and generate a session ill for the client application on the user's computer. The messenger then relays the generated session ID to the client application.
From thereon, the client application forwards message lists to the messenger, where each message list includes a session ID and one or more messages containing one or more data items. The messenger then uses the data-item identifier2910 to identify the type of each data item in the received message list. After identifying a data item's type, the messenger has the appropriate handler for the data item process the data item.
As illustrated inFIG. 29, the application server has five data handlers, which are: thebrowser handler2925, thesoftware utilization handler2930, thesoftware inventory handler2935, thehardware inventory handler2940, and thehardware utilization handler2945. These handlers respectively process data items for browser utilization, software utilization, software inventory, hardware inventory, and hardware utilization. The use of different data handlers for different data types allows the architecture of the application to be extensible. Each time thesystem100 has to track a new data type, a new data handler is added to the application server to process the new data items. The five handlers illustrated inFIG. 29 are further described below. In processing a data item, each handler might generate a new data item and direct thedata filter2950 to filter the new data item. If any portion of the data item remains after the filtering, the data filter or the handler directs the filtered data item to thedatabase interface2955. This interface then stores the filtered data item in thecollection database2710. Once a data item has been successfully processed (i.e., it has been processed, filtered, and perhaps stored), the handler that processed the data item returns a confirmation to themessenger2905, which, in turn, returns this confirmation to the client application that forwarded the data item. In some embodiments, the messenger collects in a message list several confirmations for the same client application, so that it can forward several confirmations in one message packet. If the application server has a problem processing a particular data item (e.g., problems in the handling, filtering, or storing of a data item), the application server notifies the client application of its failure, and the reason for its failure, in a message list that it forward to the client application. The client application can then re-transmit its data until it is successfully processed, or until a particular number of attempts are made.
As illustratedFIG. 29, the application server also includes thesynchronizer2920. This synchronizer maintains the system clock. The schedulers of the client application periodically synchronize their clocks with the system clock. This synchronization can be initiated by the synchronizer or the schedulers.FIG. 29 illustrates the architecture of the application server for only some embodiments of the invention. One of ordinary skill will realize that other embodiments might employ other architectures and/or other modules. For instance, in some embodiments, the application server also includes a configuration module that communicates with themessenger2905. This module receives new configuration and filter files from an administrator, and uses these files to configure the modules (e.g., the filter and tracker modules) of the client applications.
1. Software and Hardware Inventory Handlers
Figure30 illustrates several operations that thesoftware inventory handler2935 performs when it receives a data item from themessenger2905. As illustrated in this figure, theinventory handler2935 initially extracts (at3005) the resource ID (i.e., the SIID) and session ID from the received data item. From the extracted the session ID, the handler can obtain the user ID. The handler then determines (at3010) whether the received data item specifies an add operation. If so, the handler determines (at3015) whether it has previously inventoried the resource identified at3005.
If the handler has not previously inventoried the identified resource, it extracts (at3020) all inventory data that is contained in the received message about the resource. It then generates (at3025) a data item that specifies that thedatabase interface2955 needs to add records to the primary asset table2805 and the secondary software asset table2810 for the resource identified at3005. The generated data item provides the resource attributes extracted at3020, so that the database interface can populate the added records in the asset tables2805 and2810. The generated data item also specifies that a record needs to be added to the Asset₁₃Personnel table2860 to establish an association between the identified-user's records (i.e., the record of the user that was identified at3005) in the personnel tables2845-55 and the identified-resource's records
(i.e., the records of the resource that was identified at3005) in the asset tables2805 and2810.
Next, at3030, the handler has the data item generated at3025 filtered by thedata filter2950. If any portion of the generated data item remains after the filtering, the handler or data filter forwards (at3030) the generated, filtered data item to thedatabase interface2955. After3030, the handler returns (at3035) a notification to the messenger. This notification might indicate a successful or unsuccessful processing of the received data item. An unsuccessful-processing notification is returned when thedatabase interface2955 fails to store the filtered data item in the collection database. Thehandler2935 also generates an unsuccessful-processing notification when any of the other operations illustrated inFIG. 30 fail. After3035, the handler terminates its operation.
If the handler determines (at3015) that it has previously inventoried the resource identified at3005, it determines (at3040) whether the Asset₁₃Personnel table2860 includes a record that associates the identified user and resource (i.e., the user and resource that were identified at3005). If so, the handler transitions to3035 to return a notification regarding its processing of the received data item.
If the handler determines (at3040) that the Asset₁₃Personnel table does not include a record that associates the identified user and resource, the handler generates a data item at3045. This data item specifies that thedatabase interface2955 needs to add a record to the Asset Personnel table2860 to establish an association between the identified-user's records in the personnel tables2845-55 and the identified-resource's records in the asset tables2805 and2810. The handler then transitions to3030, which was described above.
If the handler determines at3010 that the operation is not an add operation, it determines (at3050) whether the Asset₁₃Personnel table2860 includes a record that associates the user and resource identified at3005. If not, the handler transitions to3035 to return a notification regarding its processing of the received data item. Otherwise, the handler determines (at3055) whether the received data specifies a modify operation. When the received data specifies a remove operation, the handler transitions to3060 from3055. At3060, the handler generates a data item that specifies that thedatabase interface2955 needs to modify the record (for the identified user and resource) in the Asset₁₃Personnel table2860 to reflect the removal of the identified resource. Specifically, this data item would direct the database interface to modify the status attribute in this record to “removed.” From3060, the handler transitions to3030, which was described above. When the handler determines (at3055) that the operation is a modify, it directs (at3065) the database interface to retrieve the records in the asset tables2805 and2810 that correspond to the resource's previous SIID, which is supplied by the update data item. At3065, the handler then merges the modifications received in the update data item with the retrieved records, and then generates a new data item that directs the database interface to add new records to the primary and secondary asset table2805 and2810 for the resource identified at3005. The generated data item provides the resource attributes that remain after the merging of the received data and retrieved records, so that the database interface can populate the added records in the asset tables2805 and2810. The generated data item also specifies that a record needs to be added to the Asset Personnel table2860 to establish an association between the identified-user's records in the personnel tables2845-55 and the newly added resource records in the asset tables2805 and2810. The generated data item further specifies that thedatabase interface2955 needs to modify the status attribute of the previous record (for the identified user and resource) in the Asset_Personnel table2860 to reflect the removal of the identified resource (i. e., to modify the status attribute in this record to removed). From3065, the handler transitions to3030, which was described above.
FIG. 31 illustrates several operations that thehardware inventory handler2940 performs when it receives a hardware-inventory data item from themessenger2905. This set of operations is similar to the set of operations illustrated inFIG. 30 for thesoftware inventory handler2935. There are two differences between the two sets of operations. First, thehardware inventory handler2940 performs its operations for data items relating to the hardware inventory.
Accordingly, the hardware inventory handler creates records in the secondary hardware asset table2810, and the Asset₁₃ID's of these records are the HID's and not SIID's. Second, thehardware inventory handler2940 does not perform theoperations3055 and3065, as the hardware inventory trackers do not generate data items that specify modifications to the previously inventoried hardware. Hence, if the hardware inventory handler determines (at3050) that there is an association in the Asset₁₃Personnel table between the user and the hardware resource identified at3005, the handler transitions to3060, which was described above. The remaining operations illustrated inFIG. 31 are similar to those similarly numbered inFIG. 30, and therefore will not be further described in order not to obscure the description with unnecessary detail.
2. Software and Browser Utilization Handlers
FIG. 32 illustrates several operations that thesoftware utilization handler2930 performs when it receives a data item from themessenger2905. With the received data item, thehandler2930 receives the tracking-interval start and stop times from the messenger. As illustrated inFIG. 32, theutilization handler2930 initially extracts (at3205) from the received data item (1) the session ID, (2) the resource ID (i.e., SIID), and (3) the Unique₁₃ID. Next, the handler determines (at3210) whether it has inventoried the software resource specified by the extracted SIID (i.e., whether the asset tables include one or more records with an Asset₁₃ID that matches the extracted SIID). If not, the handler returns (an3215) an error to the client application through themessenger2905, and then terminates its operation.
Otherwise, the handler determines (at3220) whether the received data item is a start data item that specifies the start of the utilization of a particular software resource. If so, the handler specifies (at3225) a Process₁₃ID that it will use to keep track of this reported utilization instance of the particular software resource. Next, the handler generates (at3230) a data item that directs thedatabase interface2955 to add a new record to the primary process utilization table2830. The generated data item specifies that this record's (1) Process₁₃ID is the ID specified at3225, (2) Asset₁₃ID, session ID, and unique ID are respectively the SIID, session ID, and unique ID extracted at3205, and (3) start time is the start time specified in the received data item. The generated data item also directs the database interface to initialize the duration field of the new record in the primary process utilization table.
Next, at3235, the handler has the data item generated at3230 filtered by thedata filter2950. If any portion of the generated data item remains after the filtering, the handler or data filter forwards (at3235) the generated, filtered data item to thedatabase interface2955. After3235, the handler returns (at3040) a notification to the messenger. This notification might indicate a successful or unsuccessful processing of the received data item. An unsuccessful-processing notification is returned when thedatabase interface2955 fails to store the filtered data item in the collection database; otherwise, a successful-processing notification is returned. After3240, thehandler2930 terminates its operation.
If the handler determines (at3220) that the data item is not a start data item, it determines (at3245) whether this data item is a stop data item. If the received data item is not a stop data item, it must be an update data item. An update data item always specifies a process duration and sometimes specifies a focus duration and/or an active duration.
Accordingly, when the handler determines (at3240) that the received data item is not a stop data item, it performs a duration validity check operation at3255. This checking operation is to ensure that the duration of any active or focused period reported by the received update data item is valid. In some embodiments, this checking operation ensures that the following three conditions are met. First, the focus duration has to be less than the tracking duration, where the tracking duration is the difference between the tracking-interval stop and start times received from the messenger. Second, the active duration has to be less than the tracking duration. Third, the focus duration cannot be less than the active duration. If all three conditions are met, the handler determines (at3255) that the reported focus and/or active durations are valid, and transitions to3260, which is further described below.
However, if either of the first two conditions is not met, the checking operation specifies that the received update data item does not specify valid active and/or focus durations. In this situation, the handler returns (an3215) an error to the client application through themessenger2905, and then terminates its operation. On the other hand, when both of first two conditions are met, but the third one is not, the handler (at3255) sets the active duration equal to the focus duration, and then specifies that the reported focus and active durations are valid. It then transitions to3260.
At3260, the handler generates a data item that directs thedatabase interface2955 to modify one or more records in the process utilization table for the received data item's process.
Specifically, the generated data item specifies the Unique₁₃ID and session ID that were extracted at3205. The data interface2955 can use these two ID's to identify the record in the process utilization table2830 for the received data item's software process. The generated data item directs the database interface to add the process duration specified by the received data item to the duration attribute of the identified record in the primary process utilization table2830.
When the received data item specifies a focus duration, the data item generated at3260 will also direct the database interface (1) to create a new record in the focus process table2835, (2) to store the received focus duration and the received tracking-interval start and stop times in this record, and (3) to store the Process₁₃ID (i.e., the ID of the record in the primary process table2830 that specifies session and unique ID's that match the session and unique ID's in the received data item) in this record. Similarly, when the received data item specifies an active duration, the generated data item will also direct the database interface (1) to create a new record in the active process table2840, (2) to store the received active duration and the received tracking-interval start and stop times in this record, and (3) to store the Process₁₃ID in this record. After3260, the handler transitions to3235, which was described above.
If the handler determines (at3245) that the received data item is a stop data item, it generates (at3250) a data item that directs thedatabase interface2955 to modify the record in the primary process utilization table2830 for the received data item's software process. Specifically, the generated data item specifies the Unique₁₃ID and session ID that were extracted at3205, in order to allow the database interface to identify the record in the process utilization table2830 for the received data item's software utilization. The generated data item directs the database interface to set the end time specified by the received data item as the end time of the identified record in the primary process table2830. After3250, the handler transitions to3235, which was described above.
When thebrowser handler2925 receives a browser data item from themessenger2905, the handler performs a set of operations that is illustrated inFIG. 33. This set is similar to those illustrated inFIG. 32. There are only a few differences between the two sets of operations. For instance, the resource ID that the browser handler extracts at3205 is the URL ID.
Also, when the browser handler determines (at3210) that it has not inventoried the resource identified by the extracted URL ID, it transitions to3305 instead of3215. At3305, the browser handler extracts the inventory data in the received data item. This inventory data includes the Browser ID, URL, and possibly header information. The engine then (at3305) generates a data item that directs the database to create records to the primary and secondary asset tables2805 and2810, and populate these records with the extracted URL and header information.
After this data item is generated, the browser handler transitions to3225 from3305, since the received data item must be a start data item. As mentioned above, the browser handler specifies (at3225) a Process₁₃ID for the newly received URL event, and then generates (at3230) a data item that directs the database interface to add a record to the process table2830 for the newly received URL event. The data item generated at3230 also directs the interface to populate the Browser ID attribute of this record with the browser ID extracted at3305. From3230, the browser handler transitions to3235 to filter both the data items generated at3305 and3230. The remaining operations illustrated inFIG. 33 are similar to those similarly numbered inFIG. 32, and therefore will not be further described in order not to obscure the description with unnecessary detail.
3. Hardware Utilization Handler
Each time the hardware utilization handler receives a data item from the messenger, it creates a record in the hardware-utilization table2820 and a record in the exception table2827. It then populates each of these records with the data that it extracts from the received data item. It also populates these tables with the appropriate indices to the other tables. The attributes of these tables and how they relate to the attributes of the received data item were described above in Section III.B. After populating these records, the hardware utilization handler returns a notification to the messenger regarding the completion of its task.
4. Data Filter
The server data filter2950 has an identical architecture to the architecture of the client data filter245. In other words,FIG. 25 illustrates not only the architecture of the client data filter245 but also illustrates the architecture of theserver data filter2950. The only difference between the two architectures is that while the data from thefiltering engine2505 goes to theaggregator250 in case of the client data filter245, the data from thefiltering engine2505 goes either to thedatabase interface2955 or to the data-source handler in case of theserver data filter2950.
Also, like the client data filter245, the server data filter2950 performs the filtering operations illustrated inFIG. 26. Specifically, for each data item that thefilter2950 receives from a particular handler, the filter identifies the appropriate rule set for the particular handler, sequentially invokes the rules in the identified rule set, and passes the data item to each invoked rule. Each invoked rule then either (1) makes no modification to the data item, or (2) commands the data item to modify some or all of its attributes or to mark itself for deletion. There are several reasons for performing filtering at both the client and server environments. For instance, in some embodiments, the client filters discard data that should not be collected; the server can then be adaptively configured to choose selectively the collected data that is to be discarded. Also, the filtering at the server can often be immediately modified, whereas filtering at the client might not be immediately modifiable due to delays in deployment of the client filter documents2540-2560.
In addition to its filtering operation, the server data filter2950 performs a categorization Operation. The server data filter2950 performs the categorization operation each time it receives an inventory add data item for a new software resource or a start data item for a URL event. This operation identifies the category attribute that is stored in the primary asset table2805 for a software resource or for a URL event.
FIG. 34 presents a conceptual illustration of the categorization operation of theserver data filter2950. The filter performs these operations when an inventory handler supplies to it a data item regarding a newly inventoried software resource, or when the browser handler supplies to it a data item for a new URL event. The operations illustrated inFIG. 34 are embedded in the XML filter documents for the inventory and browser handlers. Accordingly, in the embodiments, the server data filter2950 performs the operations illustrated inFIG. 34 as part of its filtering engine's invocation of the rules in the rule set of the appropriate handler.
As illustrated inFIG. 34, the server data filter2950 initially determines (at3405) whether the rule set has a rule that specifies a category attribute for the inventoried resource or URL event. If so, the filter sets (at3410) the category of the inventory or URL add data item to the attribute specified by the rule. Otherwise, the filter selects a first categorization criteria at3415. It then determines (at3420) whether the receive data item specifies a value for the selected first criteria that matches a value that the data filter stores for the first selected criteria. If not, the filter sets (at3425) the category attribute of the created Asset₁₃Table record to “uncategorized.”
On the other hand, when thedata filter2950 determines (at3420) that the received data Item specifies a matching value for the selected first criteria, the data filter selects another categorization criteria at3430. Next, at3435, the filter determines whether the data item specifies a value for the criteria selected at3430 that matches a value in a set of values that the data filter stores for the set of criteria selected thus far. If not, the filter sets (at3440) the category attribute of the created Asset₁₃Table record based on all selected criteria except the one that was selected last at3430. After3440, thefilter2950 terminates its categorization operation.
If the filter identifies a matching value at3435, the filter determines (at3445) whether it has examined all the categorization criteria. If not, it transitions back to3430 to select another categorization criteria. When the filter determines (at3445) that it has examined all the categorization criteria, the filter sets the category attribute (at3450) of the created at Asset₁₃Table record based on all selected criteria. The filter then terminates its categorization operation.
FIG. 35 presents a more detailed example of the categorization operations that thefilter2950 performs in some embodiments when it receives an add inventory data item for a new software resource. As shown in this figure, the data filter initially determines (at3505) whether the software inventory handler's rule set has a rule that specifies a value for the category attribute of the record that is created in the primary asset table for the received add data item. If so, the filter sets (at3510) the category attribute to the value specified by the rule.
Otherwise, the filter determines (at3515) whether the start data item specifies a manufacturer identity that matches a manufacturer identity that the filter stores. If not, the filter sets (at3520) the category attribute of the created Asset_Table record to “uncategorized.”
Otherwise, the filter determines (at3525) whether the received data item specifies path-information that matches any path data in the set of common path data that the filter stores for the manufacturer identified at3515. If not, the filter specifies the category attribute of the primary-asset-table record according to the manufacturer identified at3515. For instance, if Microsoft is the identified matching manufacturer, the filter might set the category attribute to “a Microsoft product. ”
On the other hand, when the filter identifies matching path data at3525, it determines (at3535) whether the received data item specifies an executable name that matches a name in the set of executable names that the filter stores for the manufacturer identified at3515 and the path data identified at3525. If not, the filter specifies (at3540) the category attribute of the primary-as set-table record according to the matching manufacturer and path data. For instance, the filter might set the category attribute to “Microsoft office” when the identified manufacturer and path information are Microsoft and programs/MSoffice.
If the filter identifies a matching executable name at3535, it determines (at3545) whether the received data item specifies a version that matches one of the versions specified in the filters storage for the manufacturer identified at3515, the path data identified at3525, and the executable name identified at3535. If not, the filter specifies (3550) the category attribute of the primary-asset-table record according to the matching manufacturer, path data, and executable name. For instance, the filter might set the category attribute to “Microsoft office/.xsl” when the identified manufacturer, path information, and executable name are Microsoft, programs/MS office, .xsl.
the filter identifies a matching version at3545, it determines (at3555) whether the received data item identifies an application name that matches one of the names specified in the filter storage for the manufacturer identified at3515, the path data identified at3525, the executable name identified at3535, and the version identified at3545. If not, the filter specifies (at3560) the category attribute of the primary-as set-table record according to the matching manufacturer, path data, executable name, and version. For instance, the filter might set the category attribute to “Microsoft office/.xsl/v. 5.0” when the identified manufacturer, path information, executable name, and version are Microsoft, programs/MS office, .xsl, and version 5.0.
On the other hand, if the filter identifies a matching application name at3555, the filter specifies (at3565) the category attribute of the primary-as set-table record according to the matching manufacturer, path data, executable name, version, and application name. For instance, the filter might set the category attribute to “Microsoft Excel, version 5.0” when the identified manufacturer, path information, executable name, version, and application name are Microsoft, programs/MS office, .xsl, version 5.0, and Excel.
In some embodiments, the set of operations that thefilter2950 performs to categorize a new URL event is similar to the flow illustrated inFIG. 35. In these embodiments, however, one difference between the two sets of operations is that the URL categorization examines the URL (that is specified in the received start URL data item) in order to identify the manufacturer, path data, executable name, version ID, and application name. Another difference is that the URL categorization determines before3515 whether the URL is an internal or external URL. If the URL is an external one, the filter examines the received external URL in view of one or more categorization criteria (that are not illustrated inFIG. 35) in order to specify a category for the received URL. If the URL is an internal one, the filter performs a set of operations similar to3515-3565.
D. DATA WAREHOUSE
The collection database stores inventory and utilization records that can be analyzed along different temporal and organizational dimensions. However, these records are not optimally organized for efficient querying and analysis. Accordingly, as mentioned above, the data transformer2715 (1) transforms the data stored in thecollection database2710 into a format that is optimized for efficient reporting and analysis, and (2) stores the transformed data in thedata warehouse2720.
In some embodiments, the data warehouse employs a star schema that has several fact tables that store several types of data that are useful for querying and analyzing along different dimensions.FIG. 36 illustrates one such schema, which includes five fact tables for five types of data. The five types are inventoried assets, software and browser utilization, hardware utilization, time periods, and usage durations.
The five fact tables are (1) the DW₁₃Asset table3605 for storing inventory data, (2) the DW₁₃Process table3610 for storing software and browser usage data, (3) the DW₁₃Hardware table3615 for storing hardware usage data, (4) DW₁₃Times table3620 for storing temporal data regarding software, browser, and hardware usage, and (5) DW₁₃Duration table3625 for storing duration data regarding software, browser, and hardware usage.
Each record in the asset table3605 has an Asset ID. Each record also includes several asset attributes (such as name, etc.) like the asset tables2805 and2810 of the collection database.
Also, each record in the process and hardware tables3610 and3615 has an Asset₁₃ID index that associates the record with a record in the asset table3605. The records in the data warehouse asset, process, and hardware tables3605-3615 have indices that associate these tables with four tables that store organization dimension attributes. These four tables are (1) the DW₁₃User table3630 for identifying all tracked personnel of an organization, (2) the DW₁₃Job₁₃Title table3635 for specifying different job titles in the organization, (3) the DW₁₃Department table3640 for specifying different departments in the organization, and (4) the DW₁₃Location table3645 for specifying different locations (e.g., addresses) of the organization. Thedata transformer2715 populates these four tables and the associated indices in the asset, process, and hardware tables based on organization dimension attributes from the ERP table2855.
Each record in the process table3610 also includes a Browser₁₃ID index. This index associates each URL-event record that is specified in the process table3610 with a record in a browser table3697, which provides information about the browser that was used for the particular URL event.
Each record in the asset and process tables3605 and3610 includes a Category₁₃ID index that associates the record with a record in a DW₁₃As set₁₃Category table3650. Each record in the category table3650 specifies a category by having a field for the Category₁₃ID and a field for the category name. Some embodiments use a hierarchical category scheme, which allows each category to belong to one or more parent and grandparent categories. Accordingly, for these embodiments, each record in the category table also specifies the Category₁₃ID of each parent category of the category specified by the record. This allows the inventory and usage data in tables3605 and3610 to the queried at different levels in the categorization hierarchy. Some embodiments allow an administrator to modify the categorization hierarchy. For these embodiments, the server-side architecture illustrated inFIG. 27 includes acategorizing module2730 that periodically examines the records in the category table3650 and corrects any parent Category₁₃ID that needs to be modified to reflect modifications to the categorization hierarchy that were made by the administrator.
Each record in the process and hardware tables3610 and3615 includes a Duration₁₃ID index that associates the record with a record in the DW₁₃Duration table3625. The DW₁₃Duration table associates each Duration₁₃ID with a duration value and a type. The duration type can be total, focus, or active. Accordingly, the duration type specifies whether the duration data specified for a record in the process or hardware table3610 or3615 relates to a measured total duration, a measured focus duration, or a measured active duration. In some embodiments, thedata transformer2715 creates one record in the process table to record the total duration of a process. It also creates one record in the process table for each active or focus duration record in the collection database tables2835 and2840. In these embodiments, the data transformer also creates one record in the hardware table for each record in the collection database table2820.
The DW₁₃Duration table also associates each Duration₁₃ID with a Time₁₃ID index into the DW₁₃Times table3620. Each record in the process and hardware tables3610 and3615 also includes a Time₁₃ID index that associates the record with a record in the DW₁₃Times table3620.
The DW₁₃Times table associates each Time₁₃ID with a timestamp that specifies the start time of the corresponding process or hardware utilization. This table also associates each Time₁₃ID with month, year, day, hour, quarter, and day-in-weak ID's. These six IDs associate each Time₁₃ID with six tables that store temporal dimension attributes. These six tables are (1) the DW₁₃hour table3655 for specifying all hours a day, (2) the DW₁₃Month table3660 for specifying all months in a year, (3) the DW₁₃Quarter table3665 for specifying all quarters in a year, (4) the DW₁₃Year table3670 for specifying several years, (5) the DW₁₃DIW table3675 for specifying a number for a day in a week, and (6) the DW₁₃Day table3680 for specifying all days in a week.
Each record in the hardware table3615 also includes an SIID, an average, a min, and a max. These attributes are similar to the similar attributes in the hardware table2870 in the collection database. The hardware table3615 also includes (1) a Resource₁₃Type₁₃ID index into a DW₁₃Resource₁₃Type table3685, which lists the difference resource types, and (2) an Exception₁₃ID index into a DW₁₃Exception table3690, which includes a record for each different exception type. The tables3685 and3690 are similar to the above-described tables2815 and2827.
As mentioned above, thereporting engine2725 queries the data in thedata warehouse2720, and generates reports based on the queries. In some embodiments, the reporting engine is a commercially available third-party tool, such as the reporting tool of Microstrategy Corporations.
A typical query is a search for data along one or more dimensions. Accordingly, the reporting engine typically performs a query by first identifying the appropriate ID's in the dimension tables, and then using the identified ID's to identify the records in the fact tables that store the desired factual data. The records that are identified in some fact tables might require the reporting engine to query data in other fact tables. The data in the fact tables can then be manipulated (e.g., summed) to generate some or all of the data in the reports.
For example, assume that the query is for active use of Microsoft word in July 2001 by the finance department. Accordingly, the reporting engine's query string will first identify (1) the month and year ID's for July and 2002 from the month and year tables3660 and3670, and (2) the department ID from the department table3640. The identified department ID is used to search for each record in the asset table3605 that has that department ID, and has as the asset name Microsoft Word. Each such record will have a particular asset ID. Next, the month and year ID are used to identify time ID's. The identified time and asset ID's are then used to identify one or more records in the process table3610.
Each identified record in the process table3610 has a duration ID, which identifies a duration record in the duration table3625. Accordingly, the records in the duration table that specify an active duration, and that correspond to the identified records in the process table can then be identified. The duration of these records (in the duration table) can then be aggregated to provide an aggregate value for the active use of Microsoft word in July 2002 by the finance department. Of course, this data does not need to be aggregated, or might be aggregated in smaller pieces. For instance, if the query required that the active use be illustrated on a daily basis, the collected data for each day could be aggregated and displayed.
As mentioned above, in some embodiments, the reporting engine presents its reports through a web browser, such as Internet Explorer. Also, the reporting engine has different querying and reporting options. For instance, it can perform queries and distribute the results of its queries in an automated fashion (e.g., perform queries at pre-determined time intervals and transmit the result via e-mail). Alternatively, the reporting engine can perform queries in response to a direct user request, and can have the user manually direct its delivery of the query results.
IV. Computer Architecture
FIG. 37 conceptually illustrates the basic components of a computer that can serve as a server or client computer of theresource management system100. Thiscomputer3700 includes abus3705, aprocessor3710, asystem memory3715, a read-only memory3720, apermanent storage device3725,input devices3730, andoutput devices3735.
Thebus3705 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of thecomputer system3700. For instance, thebus3705 communicatively connects theprocessor3710 with the read-only memory3720, thesystem memory3715, and thepermanent storage device3725.
From these various memory units, theprocessor3710 retrieves instructions to execute and data to process in order to execute the processes of the invention. The read-only-memory (ROM)3720 stores static data and instructions that are needed by theprocessor3710 and other modules of the computer system. Thepermanent storage device3725, on the other hand, is read-
and-write memory device. This device is a non-volatile memory unit that stores instruction and data even when thecomputer system3700 is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as thepermanent storage device3725. Other embodiments use a removable storage device (such as a floppy disk or zip®disk, and its corresponding disk drive) as the permanent storage device.
Like thepermanent storage device3725, thesystem memory3715 is a read-and-write memory device. However, unlikestorage device3725, the system memory is a volatile read-and
-write memory, such as a random access memory. The system memory stores some of the instructions and data that the processor needs at runtime. In some embodiments, the invention's processes are stored in thesystem memory3715, thepermanent storage device3725, and/or the read-only memory3720.
Thebus105 also connects to the input andoutput devices3730 and3735. The input devices enable the user to communicate information and select commands to the computer system. Theinput devices3730 include alphanumeric keyboards and cursor-controllers.
Theoutput devices3735 display images generated by the computer system. For instance, these devices display IC design layouts. The output devices include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD).
Finally, as shown inFIG. 37,bus3705 also couplescomputer3700 to anetwork3765 through a network adapter (not shown). In this manner, the computer can be a part of a network of computers (such as a local area network (“LAN”), a wide area network (“WAN”), or an Intranet) or a network of networks (such as the Internet).
Any or all of the components ofcomputer system3700 may be used in conjunction with the invention. However, one of ordinary skill in the art would appreciate that any other system configuration may also be used in conjunction with the present invention.
While the invention has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the invention can be embodied in other specific forms without departing from the spirit of the invention. For instance, the client applications in some embodiments might communicate with the application server through e-mails. Also, some embodiments might not associate the usage data with the user data. For example, these embodiments might only track the usage data by itself. Also, other embodiments might aggregate the duration data differently than the embodiments described above. Thus, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims.

Claims

1. A system for tracking utilization of resources of computers, the system comprising:

a plurality of client computers, wherein each computer has one or more resources that the system tracks;

a client application for each client computer, each client application for collecting utilization duration data relating to the utilization of the resources of the application's corresponding client computer;

an application server for receiving the utilization duration data collected by the client applications and for storing the received data in a storage structure;

a second storage structure; and

a data transformer for transforming the duration data stored in the first storage structure into a format that is optimized for querying, wherein the data transformer stores the transformed data in the second storage structure.

2. The system ofclaim 1, wherein the second storage structure uses a star schema.

3. The system ofclaim 1 further comprising:

a reporting engine for querying the second storage structure and generating reports based on the results of the query.

4. The system ofclaim 3, wherein the duration data stored in the second storage structure is associated with a number of searchable criteria; and

wherein for each query, the reporting engine specifies a set of search criteria and parameters for the criteria and then retrieves from the second storage structure duration data that satisfies the set of search criteria.

5. The system ofclaim 4, wherein at least for some of the queries, the reporting engine aggregates at least some of the duration data that the reporting engine retrieves from the second storage structure.

6. The system ofclaim 4, wherein the searchable criteria include temporal data relating to the duration data.

7. The system ofclaim 4, wherein the searchable criteria include organizational data relating to the duration data.

8. The system ofclaim 4, wherein the application server, first storage structure, second storage structure, and reporting engine operate on one computer.

9. The system ofclaim 4, wherein the application server, first storage structure, second storage structure, and reporting engine operate on more than one computers.

10. The system ofclaim 1, wherein at least the client applications, application server, or data transformer aggregate some of the collected duration data.

11. The system ofclaim 2, wherein the star schema has several fact tables for storing several types of data

12. The system ofclaim 11, wherein the types of data are selected from the group consisting of: inventoried assets, software utilization, browser utilization, hardware utilization, time periods, and usage durations.