Current computing systems typically include computer hardware upon which is installed an operating system (OS) and one or more disparate software applications, such as word processor applications, spreadsheet applications, electronic mail applications, graphics applications, drawing applications, etc. Typically, each application stores, manages and accesses data related to that application separately. This is referred to as data duplication. Data duplication occurs even if the same information is already stored or maintained elsewhere on the computer system by another application. Often, this is because the disparate applications are separate and distinct from each other and use different data formats.
Data duplication is very common for data related to principals, e.g., persons and entities that are actors within the computer system. For example, an electronic mail application may include a database of contact objects. Each contact object may correspond to a principal, such as a person, a computer, a corporation, a group, etc., and include one or more names, telephone numbers, e-mail addresses, social security numbers, employee numbers, student numbers, drivers license numbers, credit card numbers, physical addresses and other information for the principal. In addition, word processor, spreadsheet and graphics applications may include an author field with every document they create that includes information about the principal creating the document. Such author information typically includes some or all of the information found in a contact object.
Principal data duplication is also common within the OS. The OS may maintain a Local Account that uses a userName as its identity. A Globally Unique Identifier (GUID), in addition to the distinguished name and a Security Identifier (SID), could be used as an identity in an Active Directory. At the application programming interface (API) level, one may use a Security Account Manager (SAM) or Net API to retrieve SAM's userName, while a Directory Access API could be used to retrieve GUIDs and SIDs. In addition to this, the LookupAccountName method in the API could be used to search for a SID. The formats for each of these data elements may not be standardized. In addition, each of these data elements, e.g., a GUID, a SID, a UserName, etc. used by the OS may be stored separately, even though they all relate to the same principal.
This duplication of principal data throughout the computer system is clearly an inefficient use of limited memory resources. It also potentially makes the documents created by applications larger. An even greater problem is that the duplication of principal data increases the probability that some of the data will be out of date and incorrect. Yet another drawback is that it is difficult, if not impossible, for an application to associate disparate principal data stored in different locations (such as GUIDs, SIDs, e-mail addresses, etc.) and different formats with a given principal.
Such data duplication, however, has been necessary because each application has used its own proprietary methods and formats for storing, managing and accessing principal data. In addition, different applications have different methods for accepting and updating principal data that could make the data inappropriate for use by other applications. Therefore, sharing of data between disparate applications is not possible without prior knowledge of where, how and in what format another application stores its data.
USPTO Backgrounds
USPTO Backgrounds