Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
  • G06F16/48—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data

Definitions

• 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.
• 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.
• 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.
• 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.
• objects comprised of digital data relating to informational events (i.e. , any process or activity that produces digital data).
• the invention captures the digital data
• 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.
• an event object which stores the actual event information
• an event tag that relates the event object to a corresponding data object stored in the database.
• the present invention permits anyone with access to the database to retrieve both data and event objects (so long as they still exist).
• 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.
• 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.
• the present invention is a system for creating an object which stores digital data.
• 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.
• 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.
• 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.
• the second object includes a second tag which cross-references the first object
• the first object includes a first tag which cross-references the second object.
• 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.
• 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.
• 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.
• 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 TechnologyTM.
• 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.
• 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.
• desk-top personal computers laptops
• hand-held computers and devices e.g., PalmPilot ®
• digital telephones digital televisions
• video-conferencing equipment video-conferencing equipment
• FIG. 1 shows a representative embodiment of a computer system on which the present invention may be implemented.
• 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.
• 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.
• LAN local area network
• intranet e.g., an intranet
• WWW a local area network
• 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.
• 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
• CD- ROM drive 12 for writing to, and accessing information stored on, CD-ROM.
• peripheral devices such as printer 14 for outputting images, text, or the like.
• peripheral devices also may include a scanner (not shown) for inputting images and various audio capturing devices (not shown) for inputting audio information.
• FIG. 2 shows the internal structure of PC 1.
• 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.
• operating system 20 is a windowing operating system, such as Microsoft ® Windows95; although the invention may be used with other operating systems as well.
• data management code 21 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.
• display interface 22 Also included in PC 1 are display interface 22, keyboard interface
• 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.
• 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.
• 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.
• PC 1 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.
• 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.
• processor 30 also executes output driver 19 so as to perform appropriate formatting of the output results for transmission to printer 14.
• 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
• 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.
• 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.
• 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.
• 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
• 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.
• FIG. 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
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the API can capture information input or selected by a user following the occurrence of the event.
• 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).
• 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.
• 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).
• the object tag contains an encrypted representation of its components; although encryption is not required.
• 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.
• event reference 50 comprises a path to a location of event container 45.
• 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.
• 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.
• 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.
• 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".
• this checksum algorithm is such that it is difficult to achieve a same value "y" using different data object contents.
• a checksum algorithm based on the commonly used CRC polynomials (32 or more bits) is preferably used.
• 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.
• 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.
• 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.
• 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.
• object reference 48 comprises a path to the data object in the central repository from the corresponding event object on the client.
• 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.
• Event system information 55 comprises information concerning the environment in which the event occurred.
• 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.
• 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.
• the server then provides the event tag to the client, where construction of the event object is completed.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a bank may use the present invention in order to track information relating to a check being processed through its various value points.
• the original informational event can comprise a customer depositing a check into his/her account.
• the present invention takes over.
• the invention can begin while the digital data is being entered.
• 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.
• 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.
• the digital data i.e., the "object content”
• a server e.g. , via a network
• the data object is generated, in the manner described above, and stored in the repository.
• 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.
• 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).
• 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.
• 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.
• 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.
• FIG 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.
• 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.
• the data in data object 100 i.e., object content 100a
• the data in data object 100 include captured data from event object 101 (e.g.
• event content 101a event content 101a
• captured data from event object 102 e.g. , event content 102a
• 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.
• object tag 103 includes event checksums 109 and 110 and data object checksum 111, as well as system data 112.
• 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.
• 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.
• the preferred embodiment of the invention encrypts the event and/or object tags.
• the invention can accommodate the use of any type of encryption.
• the invention uses asymmetric encryption having a public/private key infrastructure.
• asymmetric encryption all private key use (as implemented by the customer) occurs during generation of the event tags and object tags on the server.
• the private key component is used to encrypt the tags.
• 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.
• 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.
• 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.
• 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.
• 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.
• standard distributed transaction processing techniques such as using a two-phase commit between the event object and the data object.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• Figure 8 shows a preferred process for verifying the validity of stored data objects and their corresponding object tags.
• 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.
• 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.
• 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.
• Figures 9 to 11 show the software architecture of a preferred embodiment of the present invention.
• client 35 Figure 10
• server 36 Figure 9
• client 35 includes API 41 to capture digital data relating to an event at a value point of business process 67
• APIs 69 and 70 to effect communication over a network (e.g. , IP, IPX, etc.) with server 36 and server directory 65, respectively.
• client 35 includes decrypt API 71 to perform any necessary decryption, find name API
• 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.
• network APIs 79 and 80 respectively, control communication with client 35 and server directory 65 shown in Figure 11.
• 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)
• encrypt and decrypt data APIs 87 and 89 perform any necessary encryption and decryption, respectively.
• encrypt API 87 uses a private key
• 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.
• LDAP LDAP
• NDS Novell Directory Server
• Figure 12 shows business vectors for managing, inventorying, monitoring, integrating, and controlling data across different (representative) value points of a business process or enterprise.
• 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.
• 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.
• FIG. 14 Another way of describing the foregoing is shown by Figures 14 to 16.
• value points 101a to lOlh which can relate to a business process, transaction, or information, among other things
• 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.
• 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.
• 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.
• the data objects of the present invention may be used to track the history of a business.
• the present invention provides an application-specific API which allows a customer to select which data to capture.
• 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.
• 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.
• 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.
• 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).
• 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.
• 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.
• the physical inventory e.g. , desks, hardware, phones, products produced or being produced, and/or stored in a warehouse, etc.
• an auditor could assign a dollar value to these data objects and potentially reflect these values on a balance sheet.
• 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.
• FIG. 17 shows an abstract view of this process, whereby data objects (i.e. , D.I.T.T.O.TM) are generated from data produced within a digital environment (i.e. , the Corporate Digital Boundary TM ), and stored within the central repository, termed the D.I.T.T.O. BANC TM.
• D.I.T.T.O.TM data objects
• the M.I.M.I.C.TM process takes over to manage, inventory, monitor, integrate and control these data objects.
• 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.
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Multimedia (AREA)
• Data Mining & Analysis (AREA)
• Databases & Information Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Library & Information Science (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=22609035

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Family Cites Families (3)

• 1999
  • 1999-10-04 WO PCT/US1999/023057 patent/WO2000021000A1/en not_active Application Discontinuation
  • 1999-10-04 CA CA002349370A patent/CA2349370A1/en not_active Abandoned
  • 1999-10-04 AU AU64129/99A patent/AU6412999A/en not_active Abandoned
  • 1999-10-04 EP EP99951758A patent/EP1119819A1/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events