WO2000021000A1 - Data management system - Google Patents

Abstract

A system creates a plurality of objects, each of which relates to a value point through which digital data passes. The system captures digital data relating to an event, and generates an object tag for an object, which object tag relates the digital data to the event. The digital data and the object tag are then stored in the object. Thereafter, the capturing, generating and storing steps are repeated for each value point through which the digital data passes, and the resulting objects are stored in a memory. These objects may then be retrieved from memory, and used to manage, inventory, monitor, integrate and control the digital data therein and/or corresponding information relating to the event.

Description

DATA MANAGEMENT SYSTEM

BACKGROUND OF THE INVENTION

Field Of The Invention

The present invention is directed to a system which transforms digital information into objects, and which uses these objects to manage, inventory, monitor, integrate, and control this digital information.

Description Of The Related Art

The Internet, long the sole domain of engineers, scientists, and academics, has made significant inroads into everyday life. A driving force behind these inroads is the development of the World Wide Web ("WWW"), which provides the ability to seamlessly link and access information across networks of computers using browser functionality. Increased Internet acceptance and its ease-of-use for both novice and sophisticated users has motivated business enterprises to evaluate how they can bring Internet functionality into their organizations. This functionality, when developed on top of a company's internal computer network, is called an "intranet", and when extended to external partners is called an "extranet" .

Technology itself, however, is not the primary force driving the growth in business adaptation of intranets and extranets. Instead, it is the dynamics of the customer-oriented marketplace that is mandating the need for immediate generation, processing, and availability of information. Information- intensive and information-dependent enterprises are responding to this need by working in distributed and multi-team environments and by maximizing the use of information-delivery technologies. Intranets and extranets have promoted these developments significantly by enabling employees at different geographic locations to work together on capturing, generating, assessing, updating, distributing, and reporting information. Technologies which make this possible include Java and ActiveX; browsers; the WWW; transmission protocols such as TCP/IP, HOP, IPX, IP Multicast, FTP, HTTP, and DHCP; security protocols like SSL, TLS, SET, and IPSec; increased computing processing power; network computers ("NCs"); hypertext linking mechanisms such as HTML, XML, DHTML, and VRML; security technologies such as encryption, authentication, digital signatures, and directories; cross-system methodologies like CORBA and COM; and industry committees like the Internet Engineering Task Force ("IETF") and the Object Management Group ("OMG").

From a software developer's standpoint, the challenge is to integrate the foregoing (and other) technologies and architectures with business organizational and operational support and user behavior so as to transcend the constraints of today's somewhat limited information structures and directly apply the value of information content in a business context. The business challenge is to leverage existing and enabling technologies to reduce the time and costs associated with integrating the myriad of information being produced by various business, divisional, and processing units.

To this end, solutions currently exist for integrating information produced by various business units. For example, workflow systems help users define, analyze, and track work processes, as well as schedule, control, and route work items. Groupware systems provide organizations with numerous applications including office production, business process reengineering, group project management, customer service support, document integration, sales force automation, publication coordination and routing, and analysis. Knowledge management systems integrate various technologies, such as workflow, groupware, and messaging systems in an attempt to provide an enterprise-wide solution to information use. Enterprise resource planning ("ERP") systems integrate diverse business functions such as manufacturing, logistics, sales, marketing, and human resources.

While the foregoing types of systems integrate information to one degree or another, they have serious drawbacks. For example, such systems typically force businesses to adapt to proprietary or vendor-specific technologies and, moreover, often require integration of disparate and non-standard information-producing environments and technology infrastructures. In order to conform to these new technologies, business often must change the way they operate. This is clearly undesirable. Accordingly, there exists a need for a system which permits enterprise- wide, cross-platform data integration (i.e. , exchange, access, etc.) but which is substantially non- intrusive from a business perspective.

SUMMARY OF THE INVENTION

The present invention addresses the foregoing needs by creating and maintaining a database, preferably in a central repository, which stores objects comprised of digital data relating to informational events (i.e. , any process or activity that produces digital data). Specifically, the invention captures the digital data at transactional, business, process, or other value points or points of production relative to a business. This digital data need not necessarily comprise information created in the event, but rather may include information which identifies the event, the application that precipitated the event, or other relevant information. In any case, the invention then produces a standardized, enterprise, interpretive, non-reputable, non-disputable, and singularly unique data object that includes, but is not limited to, a summary of the digital data and a tag which relates the data object to the event. This data object is then stored in the database, from which it may be retrieved and the data stored therein accessed.

The invention also creates an event object which stores the actual event information, together with an event tag that relates the event object to a corresponding data object stored in the database. By including tags in both the event object and the data object, the present invention permits anyone with access to the database to retrieve both data and event objects (so long as they still exist). As a result, using the invention, it is possible to access data relating to event information (i.e. , the data object) and/or the event information itself (i.e. , the event object), regardless of specific characteristics (e.g., format, type, protocol, etc.) of that information. Moreover, the data and events objects are created without the use of any particular proprietary or vendor- specific technologies, thereby making the invention non- intrusive from a business perspective. Thus, according to one aspect, the present invention is a system for creating an object which stores digital data. Specifically, the system captures digital data relating to an event. This digital data can basically comprise any information relating to or describing the event, including, but not limited to, the format of data created by the event, a summary description of the event, the application that caused the event, the hardware on which the event occurred, etc. The system then generates an object tag for the object, which relates the digital data to the event. Thereafter, the digital data and the object tag are stored in the object. In this way, the invention is able to create a database, or "bank" , of objects relating to a plurality of informational events, which database may be accessed, e.g. , via a networked computer, in order to obtain information regarding the events.

According to another aspect, the present invention is a system for creating objects which store event information and digital data relating to the event information. The system captures the digital data relating to the event information, generates a first object to store the digital data, and then generates a second object to store the event information. In this aspect of the invention, the second object includes a second tag which cross-references the first object, and the first object includes a first tag which cross-references the second object. The use of tags in this aspect of the invention facilitates access to the objects, and thus the substantive information stored therein, irrespective of where those objects are stored.

According to still another aspect, the present invention is a system for creating a plurality of objects, each of which relates to a value point through which digital data passes. These value points through which the digital data passes may be related or unrelated. In any case, the system captures digital data relating to an event occurring at a value point, generates an object tag for an object, where the object tag relates the digital data to the event, and stores the digital data and the object tag in the object. The capturing, generating and storing steps are then repeated for each value point through which the digital data passes.

By virtue of the foregoing features of the invention, it is possible to generate a plurality of objects for data as the data passes through different values points. For example, using the invention, it is possible to generate objects containing data relating to a document (i.e., an informational event) as that document passes through various reviewing stages (i.e. , value points) in a business organization. These objects can then be retrieved, as desired, in order to access the data stored therein. Depending upon what data is stored, it may be possible to determine, e.g. , whether the document was approved, and at what stage of the reviewing process approval occurred.

According to still another aspect, the present invention is a system for using data objects containing digital data relating to event information, where each of the data objects contains an object tag relating to an event object containing the event information. The system retrieves one or more of the data objects from a memory, reads an object tag in at least one data object retrieved in the retrieving step, and retrieves event information from event objects which correspond to the data object. By virtue of this feature of the invention, it is possible to retrieve both the digital data in the object and the actual event information itself.

This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiments thereof in connection with the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a networked computer system on which a preferred embodiment of the present invention may be implemented. Figure 2 shows an architecture of the system of Figure 1.

Figure 3 is a flow diagram showing process steps for implementing a preferred embodiment of the present invention.

Figure 4 shows the relationship between processing occurring on a client and that occurring on a server in a preferred embodiment of the present invention.

Figure 5 shows the relationship between an application, an application-specific API, and the invention. Figure 6 shows the architecture of data and event objects according to a preferred embodiment of invention.

Figure 7 shows an event object validation process.

Figure 8 shows a data object validation process. Figure 9 shows the architecture of a server used in a preferred embodiment of the invention.

Figure 10 shows the architecture of a client used in a preferred embodiment of the invention.

Figure 11 shows the architecture of a server directory used in a preferred embodiment of the invention.

Figure 12 shows an analysis of a business process using business vectors, prior to use of the invention.

Figure 13 shows an analysis of a business process using business vectors, subsequent to use of the invention. Figure 14 shows value points within a digital boundary at which digital data may be captured in accordance with the invention.

Figure 15 shows, in the abstract, creating data objects at the value points shown in Figure 14, and storing those data objects in a repository.

Figure 16 depicts some benefits of the invention diagrammatically.

Figure 17 is an abstract view of a specific implementation of the invention by Promontory Software Technology™.

Figure 18 shows a representative architecture of a symmetric tag that can be used with the present invention.

Figure 19 shows a distributed, multi-part event implementation used within this invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention comprises computer-executable code (i.e. , process steps) which creates objects based on informational events, which stores those objects in memory, and which uses them to manage, inventory, monitor, integrate, and control data. The invention can be used in connection with any type of device or process which produces digital data, including, but not limited to, desk-top personal computers, laptops, hand-held computers and devices (e.g., PalmPilot^®), digital telephones, digital televisions, and video-conferencing equipment. For the sake of brevity, however, the invention will be described in the context of a networked desk-top computer system.

In this regard, Figure 1 shows a representative embodiment of a computer system on which the present invention may be implemented. As shown in Figure 1 , PC 1 includes network connection 2 for interfacing to server 4 on network 5, which can be, e.g., a local area network ("LAN"), an intranet, or the WWW, and fax/modem connection 6 for interfacing with local or remote devices.

PC 1 also includes display screen 7 for displaying information to a user and/or inputting information, keyboard 9 for inputting text and user commands, mouse 10 for positioning a cursor on display screen 7 and for inputting user commands, disk drive 11 for reading from and writing to floppy disks installed therein, and CD- ROM drive 12 for writing to, and accessing information stored on, CD-ROM. PC

1 may also have one or more peripheral devices attached thereto, such as printer 14 for outputting images, text, or the like. These peripheral devices also may include a scanner (not shown) for inputting images and various audio capturing devices (not shown) for inputting audio information.

Figure 2 shows the internal structure of PC 1. As shown in Figure 2, PC 1 includes memory 15, which comprises a computer-readable medium such as a computer hard disk, flash memory, RAID ("redundant array of inexpensive disks), etc. Memory 15 stores data 16, applications 17, output driver 19, and an operating system 20. In preferred embodiments of the invention, operating system 20 is a windowing operating system, such as Microsoft^® Windows95; although the invention may be used with other operating systems as well. Among the applications stored in memory 15 is data management code 21, which comprises computer-executable process steps for generating objects and for managing, inventorying, monitoring, integrating, and controlling these objects in accordance with the present invention. A detailed description of this application is provided below. Also included in PC 1 are display interface 22, keyboard interface

23, mouse interface 24, disk drive interface 25, CD-ROM drive interface 26, computer bus 27, RAM 29, processor 30, and printer interface 31. Processor 30 preferably comprises a microprocessor or the like (e.g. , from the Intel^® family of computer processing chips) for executing applications, such as those noted above, out of RAM 29. Such applications, including data management code 21 of the present invention, may be stored in memory 15 (as noted above) or, alternatively, on a floppy disk in disk drive 11 , a CD-ROM in CD-ROM drive 12, or other data storage medium. In this regard, processor 30 accesses applications (or other data) stored on a floppy disk via disk drive interface 25 and accesses applications (or other data) stored on a CD-ROM via CD-ROM drive interface 26.

Application execution and other tasks of PC 1 may be initiated using keyboard 9 or mouse 10, commands from which are transmitted to processor 30 via keyboard interface 23 and mouse interface 24, respectively. Output results from applications running on PC 1 may be processed by display interface 22 and then displayed to a user on display 7. To this end, display interface 22 preferably comprises a display processor for forming images based on data provided by processor 30 over computer bus 27, and for outputting those images to display 7. Output results from applications, such as the present invention, running on PC 1 may also be provided to printer 14 via printer interface 31. In this case, processor 30 also executes output driver 19 so as to perform appropriate formatting of the output results for transmission to printer 14. Turning to data management code 21, in general, data management code 21 transforms digital information or activity produced in any digital environment (e.g. , a business, a consortium of businesses linked via an extranet, or, more generally, any sector served by the present invention) into "data objects" by capturing standardized, enterprise, flexible, interpretive, non-reputable, and singularly unique digital data sets (i.e. , digital data) at client-defined (or random) points within the digital environment. These data sets are then stored as data objects in a database located, for example, in a central network repository, such as a server or the like, from which the data sets can be validated, and then retrieved, viewed, queried, etc. to gain information concerning processing activities within the digital environment. The invention thus enables a linked, holistic, and enterprise perspective of objects irrespective of where or how they are produced, moved, and manipulated within the digital environment.

1.0 Object Creation

In more detail, data management code 21 is comprised of computer- executable process steps for, among other things, creating a plurality data objects, each of which relates to a value point through which digital data passes or at which the digital data is created. Upon execution, the code captures digital data relating to and describing an event which occurs at the value point, generates an object tag for a data object which relates the digital data to the event, and stores the digital data and the object tag in the data object. Thereafter, the capturing, generating and storing steps are repeated for each value point which provides additional digital data. The data objects created by this code are stored in memory

(e.g. , a database), where they may be accessed by other remote (e.g. , on the WWW) or local (e.g. , on a LAN or intranet) users. Similar "event objects" are also created by the invention, which store information relating to the event, and which include event tag cross-references to corresponding data objects. These event objects may also be stored in a memory (although not necessarily), from which the event objects and the information stored therein may be accessed using the data objects.

Figure 3 shows process steps for implementing a preferred embodiment of the present invention. As described in more detail below, these process steps are preferably implemented using client/server architecture (such as

PC 1 and server 4 shown in Figure 1); although this is not a requirement of the invention. In this regard, Figure 4 shows the functional relationship between the portion of the invention that may reside on client 35, and the portion of the invention that may reside on server 36. To begin, in step S301, an informational event 37 occurs in business process 39, preferably on client 35. This informational event triggers, or initiates, the use of the present invention. The informational event can comprise any process which produces or outputs digital data, and is customer-dependent, meaning that the technologies (e.g. , hardware) and/or processes (e.g. , software, protocols, etc.) that create the informational event are chosen by a customer and not dictated by the present invention. By way of example, the informational event can comprise creating a document using a word processing program, placing an order for stock or merchandise electronically, sending an E-mail, making a telephone call using a digital telephone, broadcasting an HDTV television program, receiving a data packet over a LAN or the Internet, scanning a document such as a check, generating a database record, etc. What is relevant here is the creation of digital data by virtue of the event. The format of that data is irrelevant, since the invention can be configured to accommodate any type of digital data, as described below. Similarly, the technology or process used to create the digital data is also irrelevant, as the invention can be used in connection with any process or application that creates digital data. Step S302 creates an event container 45, preferably on client 35, for holding information produced by the event of step S301. The purpose of creating an event container at this juncture is to resolve what would otherwise be a circular reference in generating an object used to hold the event information generated by step S301 (i.e. , the "event object") and an object used to hold data captured by step S303 below (i.e. , the "data object"). More specifically, as described in detail below, each event object has bound thereto an event tag which cross-references a corresponding data object, and each data object has bound thereto an object tag which cross-references a corresponding event object. Thus, in order to generate an object tag for the data object, the invention creates the event container which, ultimately, will hold the event object, and which is referenceable by the object tag.

The event-container includes the event information generated in step S301, but does not, as of this point in the process, include an event-tag, as that is added subsequently in preferred embodiments of the invention. The fundamental property of this event container is that its reference will not change after the event tag is added. That is, the event container allows an event reference to be created prior to the creation and binding of an event tag to the event container. This event reference can then used to construct the data object and its object tag, as described in more detail below.

Step S303 captures digital data relating to the informational event, which digital data comprises the "object content" 40, i.e., the contents of a data object generated by the invention. To implement this step, the preferred embodiment of the present invention uses a customer-specific business process application programming interface ("API"). That is, the API interfaces with the customer where the event, from which the data is captured, takes place. In a particular implementation, the API would be a seamlessly implemented utility from a business perspective that captures data (e.g., business rules) that define the informational event or processing activity.

Which data is captured by the API is based on the customer, hence the use of a "customer-specific" API. That is, an API can be configured to capture any type of data for any informational event-producing application, and to provide that data to the server. For example, the API can capture the name and version of an application generating data, the size of the data created by the event, a customer ID, customer name, account number, security, encryption code, or, more generally, any information that can be provided by the application, and relay that information to the server. Likewise, the API can capture information input or selected by a user following the occurrence of the event. Finally, it should be noted that while the invention can capture any type of data, the capture of any particular digital data is not required.

Figure 5 depicts the relationship between the event-producing application, the API, and a data management engine (which comprises the remainder of data management code 21). As shown in the figure, API 42 is interposed between application 41 and engine 43 so as to capture digital information from the application upon the occurrence of an event, and to transfer that digital data to the engine for further processing. Also shown in Figure 5 is database 44, into which data objects created by the present invention are stored. This is described in more detail below. Step S304 generates an object tag 46 for the data object. This is preferably, although not necessarily, done on the server. The object tag provides a verifiable reference from data object 47 to a corresponding event object 49 (both of which have not, as of this point in the process, been completely constructed). To this end, in preferred embodiments of the invention, the object tag contains an encrypted representation of its components; although encryption is not required.

Specifically, the object tag is created by determining an event reference 50 to the event information (i.e. , to event container 45), determining system information 51 relating to the data management system on the server, determining a checksum 52 for the data object based on the digital data captured in step S303, and forming object tag 46 based on one or more of event reference 50, system information 51, and checksum 52. With regard to event reference 50, event reference 50 comprises a path to a location of event container 45. In more detail, the event reference is a "path name" to the event container (and thus eventually to the event object) on the client which uniquely identifies the event container from among any other event objects within a digital environment. The content of the event reference is generated on the client (or, more generally, wherever the event occurs), and is defined and interpreted by the invention in the manner described below to access event information in an event object.

System information 51 (the "data object" system information) comprises information concerning the server, since the data object, in this embodiment of the invention, is generated on the server. Usually, the system information is different from the event information (although this is not necessarily the case in all embodiments of the invention), and comprises information relating, e.g., to system hardware or to ambient data. For example, in one embodiment of the invention, the system information can include an IP or IPX address of the server, the time and date that the data object was created, or the like. This information is included in the data object in order to provide those with access thereto information pertaining to the environment in which the data object was created.

Checksum 52 (the "data object" checksum) is a unique number that is determined based on object content 40. In preferred embodiments of the invention, the checksum is generated algorithmically on the server based on the data object's content (i.e., the captured digital data). More specifically, in these embodiments, the checksum is an algorithmic-based condensation of the object content. The purpose of the checksum is to verify the data object's validity by detecting any changes, deliberate or otherwise, to the original event information, the data object's content, or any other data generated by the invention. For example, for a given data object's content at value point VP, the checksum algorithm will output a value "y". In preferred embodiments of the invention, this checksum algorithm is such that it is difficult to achieve a same value "y" using different data object contents. To this end, a checksum algorithm based on the commonly used CRC polynomials (32 or more bits) is preferably used. Once the event reference, the data object system information, and the data object checksum are determined, in step S304 some or all of this information is combined to form object tag 46. In step S305, a data object 47 is created, preferably on the server, by binding the object tag created in step S304 to the data object's content captured in step S303. In step S306, this data object is stored in a memory which, in preferred embodiments of the invention, is a central repository located, e.g., in the server or elsewhere on the system. Of course, the repository can be remote as well (e.g. , on the Internet). It is noted that the memory comprising the central repository may or may not be physically and logically distributed. In step S307, an event tag is generated for use with an event object that holds the event information generated in step S301. Step S307 is preferably implemented on the server; although it may be implemented on the client as well. The event tag binds to the event object and cross-references a corresponding data object. Step S307 is similar to step S304 above, in that it includes determining an object reference 48 to the data object, determining "event" system information 55 relating to the client (since the event object is generated on the client), determining an "event" checksum 56 based on the event information produced in step S301, and forming the event tag based on one or more of object reference 48, event system information 55, and event checksum 56. In this regard, object reference 48 comprises a path to the data object in the central repository from the corresponding event object on the client. In more detail, the object reference, in this case, is a "path name" to the data object, and uniquely identifies the data object from among any other data objects within the central (or other information) repository. The object reference is defined and interpreted by the invention, in the manner described below, to associate the event object to the data object, i.e., to associate the original event information to the information captured therefrom as per the invention. Event system information 55 comprises information concerning the environment in which the event occurred. In this embodiment, the system information comprises information concerning the client, since the event object is generated on the client. Event checksum 56 is a unique number that is determined based on event information 37. In preferred embodiments of the invention, event checksum 56 is generated algorithmically from the event information, as described above with respect to the data object. The event checksum is included in the event object as part of the event tag, and is used to verify the event object's validity, as described in more detail below. In a preferred embodiment of the invention, event system information 55 and event checksum 56 are generated on client 35, and provided to server 36. The server then generates event tag 59 by combining system information 55, checksum 56, and object reference 48. In these embodiments, the server then provides the event tag to the client, where construction of the event object is completed. Of course, it is noted that the invention is not limited to this configuration. For example, event tag 59 may be generated on the client or, generally speaking, the tasks involved with generating the data object and event object can be split by the client and server in any manner that is deemed convenient under the circumstances. In step S308, construction of event object 49 is completed, preferably on the client, by binding event tag 59 to event container 45. Figure 6 shows the relationship of event object 49 to data object 47. More specifically, as shown in Figure 6, event object 49 includes event tag 59 and event content 37. Event tag 59 includes checksum 56 (calculated from event content 37), system information 55, and object reference 48. Object reference 48 references data object 47. Data object 47 includes digital data (i.e. , object content) 40 and object tag 46. Object tag 46 includes checksum 52 (calculated from digital data 40), system information 51, and event reference 50. Event reference 50 references event object 49. Returning to Figure 3, in step S309 the event object is stored in a memory which is local to the client; although this is not a requirement of the invention. In fact, where the event object is stored is really a concern of the customer-specific business processes and implementation procedures, and not the invention. That is, using the invention, in particular an event reference in a data object, it is possible to access the event object wherever the customer decides to store it (and, of course, if the customer so allows). Moreover, it is noted that the invention does not even require the customer to store the event object. Rather the event object can be "erased", if the customer so desires. Of course, doing this will lose the original event information. However, the data object will still contain a record of the event, and perhaps even the original event information if the capturing API is designed as such. As a result, even in cases where the original event information has been lost, the present invention ensures that something (i.e. , the digital data captured by the API) pertaining to the original event was generated.

Following step S309, processing ends, meaning that the data and event object creation phase of the invention has ended. That part of the invention pertaining to using these data and/or event objects follows below. First, however, it should be noted that the process steps shown in Figure 3 need not necessarily be executed in the order shown, and that the order shown is merely an expeditious way to explain the invention's operation. In fact, preferred embodiments of the invention generate the event object and the data object substantially in parallel, or at least as much in parallel as is possible given the cross-referencing required to create the event and data objects and any differences in capabilities between the client and server.

To give a "real- world" example of the process shown in Figures 3 and 4, a bank may use the present invention in order to track information relating to a check being processed through its various value points. In this example, the original informational event can comprise a customer depositing a check into his/her account. Once information relating to the check (e.g., check number, amount, time, date, account number, teller ID, etc.) has been entered into the bank's computer, the present invention takes over. Alternatively, the invention can begin while the digital data is being entered. In any case, once triggered, the invention captures digital data relating to the check (and, as noted, the system). This digital data is captured by a customer-specific API which is generated in accordance with the customer's needs. Here, the customer application is a data inputting device at a bank; therefore information which may be relevant to the customer and its processing applications may include that noted above.

Once the digital data, i.e., the "object content", has been captured, it is transmitted to a server (e.g. , via a network), where the data object is generated, in the manner described above, and stored in the repository. Meanwhile, the event object is generated in the manner described above at the location of the API (e.g. , the bank), where it may or may not be stored, depending upon the particular technology set in place, in this example, by the bank. The data object may then be retrieved or queried later by employees of the bank (or anyone else with access thereto), even in cases where information relating to the original transaction is no longer available. The bank may then use (e.g. , view, analyze, process, etc.) the digital data in the retrieved data object to gain information regarding the original transaction and/or retrieve the original event information from a corresponding event object if such an object is still available.

To do the latter, the invention extracts the object tag from the data object, compares it to event tags either on or provided by the bank's processing system, and, once a match is found, accesses the event object (via the event reference in the event object's tag). In this regard, it is also noted that the present invention provides alternatives to the above-described practice of using separate event and object tags. That is, in alternative embodiments of the invention, a "symmetric" object tag is generated based on a combination of the digital data captured in step S303 and the event information produced in step S301. In this case, an object container, analogous to the event container described above, may be created so as to provide a data object reference. The symmetric tag is then created, which includes a checksum as well as references to both the event object and the data object. This symmetric tag is then bound to both the data object and the event object, providing a cross-reference therebetween. The construction of such a symmetric event tag is shown in Figure 18. These alternative embodiments thus eliminate the need for two separate tag generation processes.

In this regard, the present invention also provides for an alternative use of a single event object associated with a single data object via a single tag. That is, in alternative embodiments of the invention, a single event can be manifested as multiple separate parts (e.g. , documents, database records, etc.). For example, a single event which comprises processing a bank customer's ATM cash withdrawal might involve the simultaneous modification of the customer's account balance, the ATM's current cash balance, and a marketing database tracking ATM usage. While the invention certainly allows for the generation of three separate data objects and tags corresponding to each of the three data modification events described, it also allows for treating the ATM transaction as a single value point event, meaning that a single data object is created containing specific data (i.e. , object content) from each of the three parts of this transaction and an object tag is generated containing an event checksum and an event reference for each of the three parts. The construction of such an object tag in preferred embodiments of the invention is shown Figure 19. More specifically, as shown in Figure 19, a single symmetric object tag 103 is generated based on data in data object 100 and data in plural event objects 101, 102, etc. In this case, each of the event objects corresponds to multiple parts of a single event. This single object tag is then bound to both the data object and each event object and is used to reference and/or retrieve those objects. In this regard, as shown in Figure 19, the data in data object 100 (i.e., object content 100a) include captured data from event object 101 (e.g. , event content 101a), captured data from event object 102 (e.g. , event content 102a), and captured data from any additional event objects (not shown). Object tag 103 contains both a reference 104 to corresponding data object 100 and references 106, 107, etc. to corresponding event objects. Likewise, object tag 103 includes event checksums 109 and 110 and data object checksum 111, as well as system data 112. In preferred embodiments of the invention, this system data can comprise information concerning one or more clients and the server in the event that a client-server architecture is used in generating the event and data objects. With respect to encryption of tags, it should be noted that the use of encryption is not necessary to the invention; although it can significantly enhance security surrounding the data and event objects. For example, in a "trusted environment" , such as monitoring applications within real time control systems (e.g., robots), encryption is not strictly necessary. However, even in these cases, unencrypted event and object tags are significantly easier to counterfeit than their encrypted counterparts. As a result, the preferred embodiment of the invention encrypts the event and/or object tags. To this end, the invention can accommodate the use of any type of encryption. In a preferred embodiment, however, the invention uses asymmetric encryption having a public/private key infrastructure. In asymmetric encryption, all private key use (as implemented by the customer) occurs during generation of the event tags and object tags on the server. In such cases, the private key component is used to encrypt the tags. On the other hand, the public key component enables decryption and validation of an object and its tag without access to the private key and, therefore, without access to the means of encrypting the tags.

Finally, as described above, in preferred embodiments, the invention is implemented in a distributed environment having separate client and server functionality. This client/server architecture can comprise physically (or geographically) separate devices, such as PC 1 (e.g., the client) and server 4 shown in Figure 1. In this regard, server 4 may comprise a PC similar to that of PC 1 ; although it should be noted that the server can comprise any data processing apparatus so long as it is loaded with the appropriate portions of data management code 21. Alternatively, the client/server architecture of the present invention can comprise the same physical device (e.g., PC 1 alone), having the different client and server functionalities of the present invention. In the majority of cases, however, the client and server will not be one and the same, and there will be more clients producing event information than there will be servers.

Of course, as in any client/server environment, the flow of data between the client and server should be reliable. That is, the creation of the event object and the data object should be substantially simultaneous relative to side effects, meaning that both the event object and the data object are created, or neither one is. The invention implements this by employing standard distributed transaction processing techniques, such as using a two-phase commit between the event object and the data object. In this regard, it should be noted that while the two-phase commit is one of the most commonly used techniques for ensuring that distributed activities are substantially simultaneous relative to side effects, the invention allows for any other technique that might be used for this purpose.

2.0 Obiect Validation

Once data objects and event objects are created by the present invention, they may be retrieved and used in a variety of ways, as described below in section 4.0 below. However, the usefulness of these objects is limited if they have been corrupted either accidentally or deliberately. Accordingly, the invention includes methods for verifying the validity of event objects and data objects, i.e., for verifying that the event objects and the data objects have not been altered since their creation. These methods are implemented by computer-executable code stored, e.g. , on a user's PC, and may be executed each time a data object or an event object is retrieved or, in cases where objects themselves pass between different value points, once the object reaches the next value point.

Figure 7 depicts a preferred event object validation process in accordance with the present invention. In brief, this validation process verifies that the event information and event tag stored in the event object have not been altered since the event object's creation, and that a valid corresponding data object and object tag were also created at that time. Of course, this process will be used only if the event object in question still exists. To begin, the validation process extracts event information 37 from event object 49, and generates a checksum 60 therefrom (e.g. , in the client). This checksum is preferably generated in the same manner as original event checksum 56. That is, if for given data X, the algorithm generating checksum 56 produces checksum Y, any algorithm which also generates checksum Y from data X may be used to calculate checksum 60. Event tag 59 is then also extracted from the event object, and original event checksum 56 extracted therefrom. In this regard, if the event tag is encrypted, interpretation of the original event checksum requires decrypting the event tag prior to extracting the original event checksum (using, e.g. , a public key to effect decryption). This original event checksum 56 is then compared to checksum 60. If the two are equal, the process outputs a result 61, which indicates that the event information and the event tag have not been modified since their creation. If the two are not equal, the result indicates that the event information and/or the event tag have been modified since their original creation.

Also, if desired, the object tag and the digital data stored in the data object may be verified in connection with, or independently of, the process shown in Figure 7. That is, during the extraction of the event tag, object reference 48 can also be determined (since event tag 59 contains the object reference, as described in detail above). The object reference can then be used to query data object 47 subject to customer-imposed access and security requirements enforced on the repository, in order to verify the validity of the data object. A process for verifying the validity of the data object is set forth below.

More specifically, Figure 8 shows a preferred process for verifying the validity of stored data objects and their corresponding object tags. By comparison with Figure 7, it is clear that the process for verifying the validity of data objects is analogous to that for verifying the validity of event objects. That is, this process verifies that the digital data and object tag stored in the data object have not been altered since the object tag's creation. It also verifies that the data object corresponds to a valid event. The validation process begins by extracting digital data 40 from data object 47 and generating checksum 62 therefrom. This checksum is preferably generated in the same manner as original data object checksum 52. As was the case above, if for given data X, the algorithm generating checksum 52 produces a checksum Y, any algorithm which also generates checksum Y from data X may be used to calculate checksum 62. Thereafter, object tag 46 is extracted from data object 47, decrypted if necessary, and original data object checksum 52 is extracted therefrom. Original data object checksum 52 is then compared to checksum 62. A result 64 is output based on this comparison, which indicates whether either the digital data or the object tag have, or have not, been modified since their creation.

Also, if desired, the event tag and the event information stored in the event object may be verified in connection with, or independently of, the process shown in Figure 8. That is, during the extraction of object tag 46, event reference 50 can also be extracted, since object tag 46 contains the event reference, as described in detail above. The event reference can then be used to query the event object, subject of course to any customer-imposed access and security limitations at the location of the event object, in order to verify the validity of the event object. The process for verifying the validity of the event object is set forth above with respect to Figure 7.

3.0 Architecture

Figures 9 to 11 show the software architecture of a preferred embodiment of the present invention. In this architecture, client 35 (Figure 10) and server 36 (Figure 9) interface within an existing digital environment with the aid of server directory 65 (Figure 11). Starting with Figure 10, client 35 includes API 41 to capture digital data relating to an event at a value point of business process 67, and APIs 69 and 70 to effect communication over a network (e.g. , IP, IPX, etc.) with server 36 and server directory 65, respectively. In addition, client 35 includes decrypt API 71 to perform any necessary decryption, find name API

72 to determine the logical name of the server based on information in caches 74 and 75, and event validation API 76 to validate event tags via event object validation process 77, which preferably corresponds to the process shown in Figure 7. On the server side, shown in Figure 9, network APIs 79 and 80, respectively, control communication with client 35 and server directory 65 shown in Figure 11. In addition API 81 creates data objects and stores them in repository 82, set name API 84 establishes the server name, API 85 performs object validation in accordance with data object validation process 86 (as shown, e.g. , in Figure 8), and encrypt and decrypt data APIs 87 and 89 perform any necessary encryption and decryption, respectively. In this regard, in a preferred embodiment of the invention, encrypt API 87 uses a private key and decrypt API 89 uses a corresponding public key, as described above.

Server directory 65 includes APIs 90 and 91 for communicating with client 35 and server 36, and for registering and locating which servers store data objects, i.e., which servers include central repositories, in server name directory 92. These servers may be physically and logically distributed across an organization. Alternatively, the servers may be isolated or non-linked. In addition, server directory 65 and server 36 may be implemented separately, or on the same server. In this regard, in preferred embodiments of the invention, a directory server, such as an LDAP or NDS ("Novell Directory Server") server could be used.

4.0 Information Use

The following pertains generally to using the data objects and event objects created by the present invention. To begin, the use to which the data objects are put depends upon the data that they contain. Therefore, a discussion will first be provided as to which data to include in the data objects. In this regard, in preferred embodiments of the invention, customer applications, business processes, and/or value points are selected based on an assessment of where the benefits of capturing a standard data set (i.e. , digital data) are most leveraged and maximized from a holistic, cross-process, or enterprise perspective. The benefits of a common data set once created and subsequently stored in a repository are, for example, the ability to manage, inventory, monitor, integrate, and control this data and, by design, the underlying business process that the data represents. Thus, an analysis of each process with respect to managing, inventorying, monitoring, integrating, and controlling data will help to identify which data should be captured therefrom and stored as data objects. Figure 12 illustrates a method of performing such an analysis in accordance with the present invention.

More specifically, Figure 12 shows business vectors for managing, inventorying, monitoring, integrating, and controlling data across different (representative) value points of a business process or enterprise. Using the business vectors shown in Figure 12, it is possible to determine whether each value point of a business process is able to perform the stated functions, and whether each stated function can be performed for each value point. The aggregate of each business vector and value point are shown, as is the cross-value point and cross-business vector results at the row/column intersection. As shown in Figure 12, using conventional data management methods, it was not possible to obtain satisfactory managing, inventorying, monitoring, integrating, and controlling of data across different value points of a business process. By configuring the API to capture the appropriate data, and generating data and event objects in accordance with that data, it is possible to generate the results shown in Figure 13, which is a substantial improvement along and across each business vector and value point.

Another way of describing the foregoing is shown by Figures 14 to 16. For example, in a current digital environment 100, such as that shown in Figure 14, value points 101a to lOlh (which can relate to a business process, transaction, or information, among other things), while potentially linked are, in this case, separate or disparate islands of production. The present invention can be used to capture a standard, enterprise- wide, non-reputable data set at each of these value points, generate data objects therefrom, and then send these data objects to a central repository 102, as shown in Figure 15. This repository holds an inventory of all the data objects produced at each value point, as described above.

By virtue of the data in the repository, the separate or disparate islands of production comprising the value points are effectively pulled together, thereby enabling an organization to mange, inventory, monitor, integrate and control information produced at these value points. That is, the stored data objects enable such things as managing informational events throughout their life-cycle, assessing economic and knowledge contribution to an organization, assessing production efficiency of processes, recreating history, establishing relationships between value points, and, of course, providing a common enterprise perspective of the information being produced. This is depicted in the abstract by Figure 16, wherein value points 101a to lOlh are enabled by the invention to manage informational events across life-cycle 102, effect business vectors 103, relate the value points 104, and provide an enterprise perspective 105.

Thus, by way of example, the data objects of the present invention may be used to track the history of a business. In this regard, as noted above, the present invention provides an application-specific API which allows a customer to select which data to capture. In preferred embodiments of the invention, the API is configured to capture, at each current value point, references to data objects relating to prior value points. That way, it is possible to use the data objects stored in the central repository to track the history of the business. For example, mathematical induction can be used to track the history using the stored data objects (i.e., if a condition holds true for x=0 and for x=n-l, then it must also hold true for x=n). Moreover, including references to a previous data object in a current data object enables a user to retrieve data from those previous data objects as well as corresponding previous event objects. This is particularly useful in cases where data is being passed through different value points.

Another possible implementation of the present invention is in connection with stock trading. That is, the invention can be incorporated into existing transaction processes to capture predefined digital data that is necessary and sufficient to describe a transaction. For example, the types of information that could be captured and stored in data objects include broker and client names, type of products (e.g., equity stocks), product names (e.g. , IBM^® shares), number of shares, amount of shares, currency type (e.g. , Irish Pounds), and the date. Querying these data objects once they have been created and stored can benefit an organization in several ways. For instance, a complete history can be recreated of the informational events that make up the transaction. This may be done to identify where things may have been delayed or incorrectly processed. The non- reputable nature of the data objects can be used to verify that certain activities did in fact happen (e.g. , IBM^® shares were bought at $100 rather than at $1000). This data could also be used in a court of law or in arbitration to settle disputes. Likewise, the data could be processed/analyzed to anticipate further problems with the trade, e.g. , no shares are anticipated to be available on a "settlement" day so the bank will have to buy shares or loan its own shares in order to satisfy a commitment it made on behalf of the customer to buy those shares.

Data and event objects generated in accordance with the present invention could also be used to address Y2K (i.e. , year 2000) concerns. That is, the data objects can contain the date and time they were generated, along with the business context in which the transaction was completed. This information — e.g., the date — could then be verified independently of the processes which generated the transaction. The data objects could also be used to help the transition from individual European currencies to the Euro. The currencies that are used in the transaction, along with their exchange rates via-a-vis each other and the Euro, could be captured and stored as data objects. These data objects could subsequently be retrieved and processed to verify the validity of these multi- currency transactions. Another possible use of the data objects generated by the present invention is in the financial services field, in particular, derivatives. In this regard, derivatives are financial instruments (i.e., a product) whose value is derived (hence the name derivative) from a value assigned or implied on an underlying asset or part of an asset (e.g. , an equity stock). In theory, the value of the derivative at any point in time should not exceed the value of the underlying asset at the same point in time. A problem, however, arises in assigning a realistic value to underlying parts that make up the assets. For example, applying slight variations in inflation rates or foreign exchange could have a drastic affect on the value of an asset. The data objects generated by the present invention could help to overcome this by providing mechanisms that reflect the present value of the derivative, when it was created, and where it is in its life cycle within a corporation. Using the invention in this way could have helped a noted Swiss bank determine the cause of a $700 million derivative-related loss that occurred in 1997 and a similar $700 million derivative-related loss in 1998.

The data objects generated by the present invention may also have an intrinsic value. More specifically, in an implementation of the invention, one could assign an economic or dollar value to each data object appropriate to its position within the life cycle of a corporation. This is similar to today, when auditors assign a dollar value to all of the physical inventory (e.g. , desks, hardware, phones, products produced or being produced, and/or stored in a warehouse, etc.) and reflect these values on the company's balance sheet. Since a data object can represent all informational events within and of importance to the corporation, and since the repository is an inventory of information relating to these events (i.e. , the data objects), an auditor could assign a dollar value to these data objects and potentially reflect these values on a balance sheet.

In this regard, the value of a data object on being queried from the central repository is only as good as the data contained therein. Therefore, to maximize its value, the captured data should model and identify the enterprise, holistic view of an informational event being produced. If the data captured comprises the correct data model, then its exploitation will enable users with varying degrees of proficiency and with varying job or function profiles to view the same data from the context in which they wish to use and see the data.

Therefore, people in marketing or engineering can interpret the (same) data from within their own or other context. Of course, the potential uses of the data objects (and even objects) generated by the present invention are virtually limitless. Accordingly, the foregoing examples are not intended to restrict the invention, but rather are provided to show its breadth. In this regard, another representative embodiment of the invention is produced by Promontory Software Technology™ . Figure 17 shows an abstract view of this process, whereby data objects (i.e. , D.I.T.T.O.™) are generated from data produced within a digital environment (i.e. , the Corporate Digital Boundary ™ ), and stored within the central repository, termed the D.I.T.T.O. BANC ™. Once these data objects are stored, the M.I.M.I.C.™ process takes over to manage, inventory, monitor, integrate and control these data objects.

As shown, in accordance with this embodiment, as is the case with the invention in general, a data object is created for both an initial event and, if so desired, for all subsequent events. Code to implement a version of this embodiment of the invention is set forth below in the Appendix attached hereto. Thus, as set forth above, the present invention provides an enterprise-wide system which operates in a heterogeneous, multi-platform, distributed environment (e.g. UNIX, Windows, NT, client/ server). The invention integrates disparate and non-standard information types irrespective of where, how, or when they are produced and moved within the enterprise. It is non- intrusive from a business perspective, meaning that it does not affect business practices significantly, if at all, and that it does not dictate which platforms or technologies a client should use. The system is automated in generating its data, and is also non-proprietary.

Moreover, the system is substantially transparent to users on the data acquisition and/or data generation sides. The system can produce enterprise, standardized, non-reputable, and unique data objects that are sufficient to describe informational events. The system leverages existing and future network infrastructure (e.g., IP, Novell, etc.), is multi-platform (e.g., Unix, NT, etc.), works along side and compliments workflow and distributed-processing tools, and utilizes current and future security protocols and methodologies (e.g., public/private key encryption). The system integrates disparate and non-standard information-producing environments and technology infrastructures (e.g., internal or proprietary networks), and is efficient in capturing its required digital data, while not denigrating network performance or degrading the performance of the servers, workstations, business, process, transactional, and other digital production environments. Finally, the system of the present invention can be implemented on a case-by-case, process-by-process, basis, but is also enterprise- wide scalable in order to provide a holistic and enterprise integrated software system. The system is also portable to a heterogeneous set of platforms, and reliable, in that data that moved across a network is maintained in a cache if the network fails and either continues the transmission or cancels any side-effects, such as incomplete or tampered data.

The present invention has been described with respect to a particular illustrative embodiment. It is to be understood that the invention is not limited to the above-described embodiment and modifications thereto, and that various changes and modifications may be made by those of ordinary skill in the art without departing from the spirit and scope of the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method of creating an object which stores digital data, the method comprising the steps of: capturing digital data relating to an event; generating an object tag for the object, the object tag relating the digital data to the event; and storing the digital data and the object tag in the object.

2. A method according to Claim 1, wherein the generating step comprises the steps of: determining an event reference to information relating to the event, the event reference comprising a path to the information relating to the event; and forming the object tag based, at least in part, on the event reference.

3. A method according to Claim 2, wherein the determining step determines the event reference by (i) creating an event container for holding the information relating to the event, and (ii) obtaining a location of the event container.

4. A method according to Claim 1, wherein the generating step comprises the steps of: determining system information relating to a system which performs the method; and forming the object tag based, at least in part, on the system information.

5. A method according to Claim 1, wherein the generating step comprises the steps of: determining a checksum for the object based on the digital data; and forming the object tag based, at least in part, on the checksum.

6. A method according to Claim 1, wherein the generating step comprises the steps of: determining an event reference to information relating to the event, the event reference defining a path to the information relating to the event; determining system information relating to a system which performs the method; determining a checksum for the object based on the digital data; and forming the object tag based on the event reference, the system information, and the checksum.

7. A method according to Claim 1, wherein the event comprises any process that produces digital information.

8. A method according to Claim 7, wherein the event is performed by an external application.

9. A method according to Claim 1, wherein the capturing step is performed by an application programming interface ("API") which has been developed for the event.

10. A method of creating objects which store event information and digital data relating to the event information, the method comprising the steps of: capturing the digital data relating to the event information; generating a first object to store the digital data; and generating a second object to store the event information, the second object including a second tag which cross-references the first object, and the first object including a first tag which cross-references the second object.

11. A method according to Claim 10, further comprising the step of retrieving the event information from the second object using the first tag from the first object.

12. A method according to Claim 10, further comprising the step of generating the first tag; wherein the step of generating the first tag comprises: a first determining step for determining a reference to the second object, the reference defining a path to the second object; a second determining step for determining system information relating to a system which performs the method; a third determining step for determining a checksum for the first object based on the digital data; and forming the first object tag based on at least one of the reference, the system information, and the checksum.

13. A method according to Claim 12, wherein the first determining step determines the reference by (i) creating an event container for the event information, and (ii) obtaining a location of the event container.

14. A method according to Claim 10, further comprising the step of generating the second tag; wherein the step of generating the second tag comprises: a first determining step for determining a reference to the first object, the reference defining a path to the first object; a second determining step for determining system information relating to a system which performs the method; a third determining step for determining a checksum for the second object based on the event information; and forming the second object tag based on at least one of the reference, the system information, and the checksum.

15. A method according to Claim 12, wherein the first determining step determines the reference based on a location of the first object.

16. A method according to Claim 10, further comprising the steps of retrieving and displaying the digital data from the first object.

17. A method according to Claim 10, wherein the first object is generated on a server and the second object is generated on a client of the server.

18. A method according to Claim 10, wherein the first object includes a checksum; and further comprising the step of verifying the validity of the first object based on the checksum.

19. A method according to Claim 10, wherein the second object includes a checksum; and further comprising the step of verifying the validity of the second object based on the checksum.

20. A method of creating a plurality of objects, each of the objects relating to a value point through which digital data passes, the method comprising the steps of: capturing digital data relating to an event; generating an object tag for an object, the object tag relating the digital data to the event; storing the digital data and the object tag in the object; and repeating the capturing, generating and storing steps for each value point through which the digital data passes.

21. A method according to Claim 20, further comprising the steps of: storing objects for plural value points in a memory; retrieving an object for one or more specified value points; and processing digital data stored in at least one object retrieved in the retrieving step.

22. A method according to Claim 20, wherein the value points comprise events in an enterprise at which the digital data is processed.

23. A method of using data objects containing digital data relating to event information, wherein each of the data objects contains an object tag relating to an event object containing the event information, the method comprising the steps of: retrieving one or more of the data objects from a memory; reading an object tag in at least one data object retrieved in the retrieving step; and retrieving event information from event objects which correspond to the object tag for the at least one data object.

24. A method according to Claim 23, further comprising the step of processing the event information.

25. A method according to Claim 23, wherein the retrieving step comprises (i) retrieving the event information by extracting an event reference from the object tag, and (ii) retrieving the event information from one or more event objects having locations defined in the event reference.

26. Computer-executable process steps stored on a computer- readable medium, the computer-executable process steps to create an object which stores digital data, the computer-executable process steps comprising: code to capture digital data relating to an event; code to generate an object tag for the object, the object tag relating the digital data to the event; and code to store the digital data and the object tag in the object.

27. Computer-executable process steps according to Claim 26, wherein the generating code comprises: code to determine an event reference to information relating to the event, the event reference comprising a path to the information relating to the event; and code to form the object tag based, at least in part, on the event reference.

28. Computer-executable process steps according to Claim 27, wherein the determining code determines the event reference by (i) creating an event container for holding the information relating to the event, and (ii) obtaining a location of the event container.

29. Computer-executable process steps according to Claim 26, wherein the generating code comprises: code to determine system information relating to a system which performs the method; and code to form the object tag based, at least in part, on the system information.

30. Computer-executable process steps according to Claim 26, wherein the generating code comprises: code to determine a checksum for the object based on the digital data; and code to form the object tag based, at least in part, on the checksum.

31. Computer-executable process steps according to Claim 26, wherein the generating code comprises: code to determine an event reference to information relating to the event, the event reference comprising a path to the information relating to the event; code to determine system information relating to a system which performs the method; code to determine a checksum for the object based on the digital data; and code to form the object tag based on the event reference, the system information, and the checksum.

32. Computer-executable process steps according to Claim 26, wherein the event comprises any process that produces digital information.

33. Computer-executable process steps according to Claim 32, wherein the event is performed by an external application.

34. Computer-executable process steps according to Claim 26, wherein the capturing step is performed by an application programming interface

("API") which has been developed for the event.

35. Computer-executable process stored on a computer-readable medium, the computer-executable process steps to create objects which store event information and digital data relating to the event information, the computer- executable process steps comprising: code to capture the digital data relating to the event information; code to generate a first object to store the digital data; and code to generate a second object to store the event information, the second object including a second tag which cross-references the first object, and the first object including a first tag which cross-references the second object.

36. Computer-executable process steps according to Claim 35, further comprising code to retrieve the event information from the second object using the first tag from the first object.

37. Computer-executable process steps according to Claim 35, further comprising code to generate the first tag; wherein the code to generate the first tag comprises: first determining code to determine a reference to the second object, the reference defining a path to the second object; second determining code to determine system information relating to a system which executes the computer-executable process steps; third determining code to determine a checksum for the first object based on the digital data; and code to form the first object tag based on at least one of the reference, the system information, and the checksum.

38. Computer-executable process steps according to Claim 37, wherein the first determining code determines the reference by (i) creating an event container for the event information, and (ii) obtaining a location of the event container.

39. Computer-executable process steps according to Claim 35, further comprising code to generate the second tag; wherein the code to generate the second tag comprises: first determining code to determine a reference to the first object, the reference defining a path to the first object; second determining code to determine system information relating to a system which executes the computer-executable process steps; third determining code to determine a checksum for the second object based on the event information; and code to form the second object tag based on at least one of the reference, the system information, and the checksum.

40. Computer-executable process steps according to Claim 37, wherein the first determining code determines the reference based on a location of the first object.

41. Computer-executable process steps according to Claim 35, further comprising code to retrieve and to display the digital data from the first object.

42. Computer-executable process steps according to Claim 35, wherein the code to generate the first object is executed on a server and the code to generate the second object is executed on a client of the server.

43. Computer-executable process steps according to Claim 35, wherein the first object includes a checksum; and further comprising code to verify the validity of the first object based on the checksum.

44. Computer-executable process steps according to Claim 35, wherein the second object includes a checksum; and further comprising code to verify the validity of the second object based on the checksum.

45. Computer-executable process steps stored on a computer- readable medium, the computer-executable process steps to create a plurality of objects, each of the objects relating to a value point through which digital data passes, the computer-executable process steps comprising: code to capture digital data relating to an event; code to generate an object tag for an object, the object tag relating the digital data to the event; code to store the digital data and the object tag in the object; and code to repeat capturing, generating and storing for each value point through which the digital data passes.

46. Computer-executable process steps according to Claim 45, further comprising: code to store objects for plural value points in a memory; code to retrieve an object for one or more specified value points; and code to process digital data stored in at least one object retrieved by the retrieving code.

47. Computer-executable process steps according to Claim 45, wherein the value points comprise events in an enterprise at which the digital data is processed.

48. Computer-executable process steps stored on a computer- readable medium, the computer-executable process steps to use data objects containing digital data relating to event information, wherein each of the data objects contains an object tag relating to an event object containing the event information, the computer-executable process steps comprising: code to retrieve one or more of the data objects from a memory; code to read an object tag in at least one data object retrieved by the retrieving code; and code to retrieve event information from event objects which correspond to the object tag for the at least one data object.

49. Computer-executable process steps according to Claim 48, further comprising code to process the event information.

50. Computer-executable process steps according to Claim 48, wherein the retrieving code comprises (i) code to retrieve the event information by extracting an event reference from the object tag, and (ii) code to retrieve the event information from one or more event objects having locations defined in the event reference.

51. An apparatus for creating an object which stores digital data, the apparatus comprising: a memory which stores computer-executable process steps; and a processor which executes the computer-executable process steps so as (i) to capture digital data relating to an event, (ii) to generate an object tag for the object, the object tag relating the digital data to the event, and (iii) to store the digital data and the object tag in the object.

52. An apparatus according to Claim 51, wherein the processor generates the object tag by (i) determining an event reference to information relating to the event, the event reference defining a path to the information relating to the event, and (ii) forming the object tag based, at least in part, on the event reference.

53. An apparatus according to Claim 52, wherein the processor determines the event reference by (i) creating an event container for holding the information relating to the event, and (ii) obtaining a location of the event container.

54. An apparatus according to Claim 51, wherein the processor generates the object tag by (i) determining system information, and (ii) forming the object tag based, at least in part, on the system information.

55. An apparatus according to Claim 51, wherein the processor generates the object tag by (i) determining a checksum for the object based on the digital data, and (ii) forming the object tag based, at least in part, on the checksum.

56. An apparatus according to Claim 51, wherein the processor generates the object tag by (i) receiving an event reference to information relating to the event, the event reference defining a path to the information relating to the event, (ii) determining system information, (iii) determining a checksum for the object based on the digital data, and (iv) forming the object tag based on the event reference, the system information, and the checksum.

57. An apparatus according to Claim 51, wherein the event comprises any process that produces digital information.

58. An apparatus according to Claim 57, wherein the event is performed by an external application.

59. An apparatus according to Claim 51, wherein the capturing step is performed by an application programming interface ("API") which has been developed for the event.

60. A system for creating objects which store event information and digital data relating to the event information, the system comprising: one or more memories which store computer-executable process steps; and one or more processors which executes the computer-executable process steps so as (i) to capture the digital data relating to the event information, (ii) to generate a first object to store the digital data, and (iii) to generate a second object to store the event information, the second object including a second tag which cross-references the first object, and the first object including a first tag which cross-references the second object.

61. A system according to Claim 60, wherein the processor(s) execute process steps so as to retrieve the event information from the second object using the first tag from the first object.

62. A system according to Claim 60, wherein the processor(s) execute process steps so as to generate the first tag by (i) determining a reference to the second object, the reference defining a path to the second object, (ii) determining system information, (iii) determining a checksum for the first object based on the digital data, and (iv) forming the first object tag based on at least one of the reference, the system information, and the checksum.

63. A system according to Claim 62, wherein the processor(s) determine the reference by (i) creating an event container for the event information, and (ii) obtaining a location of the event container.

64. A system according to Claim 60, wherein the processor(s) execute process steps so as to generate the second tag by (i) determining a reference to the first object, the reference defining a path to the first object, (ii) determining system information, (iii) determining a checksum for the second object based on the event information, and forming the second object tag based on at least one of the reference, the system information, and the checksum.

65. A system according to Claim 62, wherein the processor(s) determine the reference based on a location of the first object.

66. A system according to Claim 60, wherein the processors further execute process steps so as to retrieve and to display the digital data from the first object.

67. A system according to Claim 60, wherein the first object is generated by a processor on a server and the second object is generated by a processor on a client of the server.

68. A system according to Claim 60, wherein the first object includes a checksum; and wherein the processor(s) further execute process steps so as to verify the validity of the first object based on the checksum.

69. A system according to Claim 60, wherein the second object includes a checksum; and wherein the processors execute process steps so as to verify the validity of the second object based on the checksum.

70. An system for creating a plurality of objects, each of the objects relating to a value point through which digital data passes, the system comprising: at least one memory which stores computer-executable process steps; and at least one processor which executes the process steps so as (i) to capture digital data relating to an event, (ii) to generate an object tag for an object, the object tag relating the digital data to the event, (iii) to store the digital data and the object tag in the object, and (iv) to repeat the capturing, generating and storing steps for each value point through which the digital data passes.

71. A system according to Claim 70, wherein the processor further executes process steps so as (i) to store objects for plural value points in a memory, (ii) to retrieve an object for one or more specified value points, and (iii) to process digital data stored in at least one object retrieved in the retrieving step.

72. A system according to Claim 70, wherein the value points comprise events in an enterprise at which the digital data is processed.

73. A system for using data objects containing digital data relating to event information, wherein each of the data objects contains an object tag relating to an event object containing the event information, the system comprising: at least one memory which stores computer-executable process steps; and at least one processor which executes the process steps so as (i) to retrieve one or more of the data objects from a memory, (ii) to read an object tag in at least one data object retrieved in the retrieving step, and (iii) to retrieve event information from event objects which correspond to the object tag for the at least one data object.

74. A system according to Claim 73, further wherein the processor executes process steps so as to process the event information.

75. A system according to Claim 73, wherein the processor retrieves the event information by (i) retrieving the event information by extracting an event reference from the object tag, and (ii) retrieving the event information from one or more event objects having locations defined in the event reference

76. A method of using data objects stored in a central repository, where the store data relating to an informational event, the method comprising the steps of: retrieving a data object from the central repository; extracting data from the data object which relates to an informational event; and processing the extracted data.

77. A method according to Claim 10, wherein the first and second tags are identical, each of the first and second tags comprising a symmetric tag which includes references to both the first object and to the second object.

78. Computer-executable process steps according to Claim 35, wherein the first and second tags are identical, each of the first and second tags comprising a symmetric tag which includes references to both the first object and to the second object.

79. A system according to Claim 60, wherein the first and second tags are identical, each of the first and second tags comprising a symmetric tag which includes references to both the first object and to the second object.

80. A method of creating objects which store event information and digital data relating to the event information, the method comprising the steps of: capturing the digital data relating to the event information; generating a first object to store the digital data; and generating a plurality of additional objects, each for storing the event information, the plurality of additional objects each including an object tag which cross-references the first object, and the first object including an object tag which cross-references the plurality of additional objects.

81. A method according to Claim 80, wherein the object tag comprises a symmetric tag which includes reference information comprising locations of the first object and the plurality of additional objects.

82. Computer-executable process steps stored on a computer- readable medium, the computer-executable process steps to create objects which store event information and digital data relating to the event information, the computer-executable process steps comprising: code to capture the digital data relating to the event information; code to generate a first object to store the digital data; and code to generate a plurality of additional objects, each for storing the event information, the plurality of additional objects each including an object tag which cross-references the first object, and the first object including an object tag which cross-references the plurality of additional objects.

83. Computer-executable process steps according to Claim 82, wherein the object tag comprises a symmetric tag which includes reference information comprising locations of the first object and the plurality of additional objects.