Patent Publication Number: US-2023164192-A1

Title: Identifying suspicious entries in a document management system

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of co-pending U.S. application Ser. No. 17/234,362, filed Apr. 19, 2021, which is incorporated by reference in its entirety. 
    
    
     BACKGROUND 
     Field of Disclosure 
     The present disclosure generally relates to a document management system, and more specifically to identification of suspicious entries in documents managed by the document management system. 
     Description of the Related Art 
     Entities use a document management system to electronically store data related to the entities. The data is stored in one more documents in the document management system. Various users such as employees of the entities create new entries in the document that describe operations related to the entities. Conventional document management systems are unable to identifying suspicious entries that are indicative of suspicious activity at the entities. 
     SUMMARY 
     In one embodiment, a document management system manages documents of an entity. The document management system monitors for entries in a document that are suspicious. Entries in the document are classified by the document management system as a “suspicious entry” or a “non-suspicious entry.” In one embodiment, a suspicious entry is indicative of potentially malicious activity at the entity. 
     To classify entries in the document, the document management system stores a security policy for the document. The security policy includes a plurality of security rules where each security rule defines distinct attributes of a suspicious entry. Entries in the document are compared with the security policy to classify the entries as either a suspicious entry or a non-suspicious entry. In one embodiment, the document management system generates a list of suspicious entries included in the document for review. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG.  1    is a high-level block diagram illustrating an embodiment of an environment for entry classification according to one embodiment. 
         FIG.  2    is a high-level block diagram illustrating a detailed view of a document management system, according to one embodiment. 
         FIG.  3    a high-level block diagram of a security policy module included in the document management system, according to one embodiment. 
         FIG.  4    is an example of document according to one embodiment. 
         FIG.  5    is an example of an entry in the document according to one embodiment. 
         FIG.  6    is an example of a security policy for a document, according to one embodiment. 
         FIG.  7    is an example notification of suspicious entries in a document according to one embodiment. 
         FIG.  8    is an example list of suspicious entries in a document according to one embodiment. 
         FIG.  9    is an interaction diagram illustrating a process of identifying a suspicious entry in a document according to one embodiment. 
         FIG.  10    is a high-level block diagram illustrating another embodiment of an environment for entry classification according to one embodiment. 
         FIG.  11    is system diagram of a computer system, according to one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     The Figures (FIGS.) and the following description describe certain embodiments by way of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein. Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures. It is noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. 
     Document Management System Environment 
       FIG.  1    is a high-level block diagram illustrating an embodiment of an environment  100  of a document management system  103  for identifying suspicious entries in documents of an entity  101 . The entity  101  may represent a single entity in one embodiment. In other embodiments, the entity  101  may represent a group of entities that belong to a single entity. An example of an entity  101  included in the environment is an automobile dealership or a group of automobile dealerships. However, the entity  101  can be any type of entity that requires the identification of suspicious entries in documents. The documents managed by the document management system  103  may include any type of data related to the entity  101 . 
     In one embodiment, the environment  100  includes the entity  101  and a plurality of client devices  107 A to  107 C connected to each other via a network  105 . As shown in  FIG.  1   , the enterprise  101  includes a document management system  103 . Note that in another embodiment such as shown in  FIG.  10   , the document management system  103  may be separate from the entity  101  as will be further described below with respect to  FIG.  10   . Any number of document management systems, entities, and client devices may be present in other embodiments. 
     The network  105  provides a communication infrastructure between the parties included in environment  100 . The network  105  is typically the Internet, but may be any network, including but not limited to a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a mobile wired or wireless network, a private network, or a virtual private network. 
     Client devices  107  may include any device having an application that communicates with the document management system  103 . For example, a client device  107  may be a mobile device or personal computer. Generally, client devices  107  represent devices of the entity  101 . Representatives of the entity  101  use the client devices  101  to access entries in one or more documents stored by the document management system  103 . 
     Accessing a document stored by the document management system  103  allows users to view existing entries in the document, add new entries to the documents, modify existing entries in the documents, and/or delete existing entries in the document. In one embodiment, the client device  107  may include an application that allows interaction with the document management system  103  to access documents stored by the document management system  103 . The application may be a dedicated application specifically designed (e.g., by the organization responsible for the document management system  103 ) to enable interactions with the document management system  103 . 
     The document management system  103  manages one or more documents that store data related to the entity  101 . Users of client devices  107  may access a document managed by the document management system  103  to add new entries to the document. In one embodiment, a new entry to the document describes an activity at the entity  101 . The document management system  103  analyzes the new entry to classify the entry as either “suspicious” or “non-suspicious.” An entry classified as suspicious indicates that the activity described by the entry is potentially malicious. As will be further described below, the document management system  103  generates a list of suspicious entries in the document that may be reviewed to confirm malicious activity at the entity  101 . 
     Document Management System 
       FIG.  2    is a high-level block diagram illustrating a detailed view of the document management system  103  of  FIG.  1   . In one embodiment, the document management system  103  includes a document database  201 , a security policy database  203 , a training database  205 , a training module  207 , a security policy module  209 , a reception module  211 , and a security module  215 . Note that in other embodiments, the document management system  103  may include other modules and/or databases than those illustrated in  FIG.  2   . 
     The document database  201  stores one or more documents of the entity  101 . An example of a document stored in the document database  201  is a ledger that includes data related activities of the entity  101 . The ledger may include multiple entries that are organized into groups of one or more journals and/or identifiers, for example. However, any organizational format may be used to organize data stored in a document. 
       FIG.  4    is an example document  300  according to one embodiment.  FIG.  4    illustrates a list view of a plurality of entries included in the document  400 . As shown in  FIG.  4   , the entries included in the document  400  are arranged in a series of rows. For example, the document includes entries  401 A to  401 C arranged in separate rows. Each entry  401  includes a plurality of entry attributes. The entry attributes included of an entry include a plurality of fields and a corresponding value for each field. The entry attributes of the entry describe an activity at the entity  101 . 
     In one embodiment, each entry shown in the list view of entries shown in  FIG.  4    is selectable to access a detailed view of the entry. Selecting an entry from the list view results in a display of a detailed view of the entry.  FIG.  5    is an example of a detailed view of an entry according to one embodiment. The detailed view  500  of the entry includes data such as one or more postings  501  made to the entry. Each post to the entry includes entry attributes such as fields and values for the fields. 
     Referring back to  FIG.  2   , in one embodiment the security policy database  203  stores security polices for documents managed by the document management system  103 . In one embodiment, a security policy for a document includes a plurality of security rules where each security rule defines distinct attributes of a suspicious entry. The security policy is used by the document management system  103  to classify an entry in the document as suspicious or non-suspicious, as further described below. 
     The training database  205  stores training data. In one embodiment, the training data is used to train the security policy module  207  to dynamically generate security rules. In one embodiment, the training data may include different training groups of training entries where each training group is associated with a different type of activity at the entity  101  over a period of time (e.g., 3 months). An example of a type of activity is entries made to a particular destination in the document. Each training group of training entries may include a first sub-group of training entries related to a specific type of activity at the entity  101  where each training entry in the first sub-group is classified as a non-suspicious entry and a second sub-group of training entries related to the specific type of activity at the entity  101  where each training entry in the second sub-group is classified as a suspicious entry. In one embodiment, the first sub-group with non-suspicious training entries represents attributes of non-suspicious trends of activity associated with the sub-group whereas the second sub-group with suspicious training entries represents attributes of suspicious trends of activity associated with the sub-group. 
     The training module  207  trains the security policy module  209  to automatically generate security rules for a security policy of a document. In one embodiment, the training module  207  trains the security policy module  209  to generate security rules for the security policy of the document using the different training groups of training entries stored in the training database  205 . The training module  207  may train the security policy module  209  to generate one or more security rules for each type of activity that occurs at the entity  101  using the training data. 
     To train the security policy module  209 , the training module  207  extracts training attributes of the training data. The training attributes extracted by the training module  209  from the training data serve as descriptive, quantitative representations of the training data for use in training the security policy module  209 . In one embodiment, the training module  209  generates different groups of extracted training attributes where each group of extracted training attributes is associated with a corresponding one of the training groups of training entries. Each group of extracted training features may include a sub-group of attributes that represent the suspicious training entries in the group and a sub-group of attributes that represent the non-suspicious training entries in the group. The combination of the various attributes extracted from training data serves as feature vectors that characterize the training data. 
     The training module  209  applies the features vectors that characterize the training data to the security policy module  205  as an input to the security policy module  205 . The training module  209  trains the security policy module  205  to learn a set of weights on training attributes of the training data so that the security policy module  205  can automatically generate security rules for a security policy. Thus, the trained security policy module  205  is trained to recognize suspicious activity from the training data and generate rules that allow the document management system  103  to identify potentially malicious activity from entries in the document. 
     In one embodiment, the training module  209  will re-train the security policy module  205  using updated training data. In one embodiment, the updated training data includes new entries to the document over a period of time that are classified by the document management system  103  as suspicious and non-suspicious. In another embodiment, the training module  209  re-trains the security policy module  205  based on feedback received on the classifications made by the security module  215  as will be described below. By re-training the security policy module  205 , the security policy module  205  can improve the generation of security rules that better reflect malicious and non-malicious activities of the entity  101 . 
     The security policy module  205  generates a security policy for a document that includes one or more security rules where each security rule defines distinct security attributes of a suspicious entry. The security attributes included in a security rule describe attributes of a suspicious entry which is representative of a malicious activity at the entity  101 . Entries in the document having attributes that match the security attributes of any one of the security rules included in the security policy is classified as a suspicious entry. Entries to the document having attributes that do not match the security attributes of any one of the security rules included in the security policy is classified as a non-suspicious entry. 
     In one embodiment, the security attributes of a security rule may include a particular destination in the document that is associated with the security rule. The destination in the document describes where in the document an entry will be posted to according to one embodiment. An example of a destination is an identifier and/or journal in the document. 
     The security attributes for a security rule may also specify one or more names of representatives within the entity  101 . An entry to the document that is made by one of the names in the security policy may indicate that the entry is suspicious, for example. The name may be a specific user (e.g., a name of the user or user identifier) or the name of a role type (i.e., occupation type) of a representative of the entity  101  such as “clerks.” In yet another example, the name in a security rule may specify a name of a group of representatives that are subject to the security rule. For example, all representatives who are in the “service” group may be subject to the security rule. 
     The security attributes for a security rule may specify invalid dates and/or times for entries. The invalid dates and/or times indicate when the entity  101  is non-operational (e.g., closed). Thus, new entries to the document should not be created during the invalid dates and/or times. In another example, the security attributes for a security rule may specify data values that are outside a valid range or valid percentage that is associated with a field in the document. In yet another example, the security attributes include one or more locations of client devices  107  where any entries made from the locations is suspicious. Note that the security attributes described herein are merely exemplary. A security rule may include different security attributes than described herein. 
       FIG.  3    is a high-level block diagram of the security policy module  205  according to one embodiment. The security policy module  205  includes a user security policy module  301  and a set of dynamic security policy modules  303 A to  303 N where N is a positive integer. The security policy module  205  may include different modules than shown in  FIG.  3    in other embodiments. 
     In one embodiment, the user security policy module  301  generates a security rule based on a definition received from a user (e.g., an administrator) of the document management system  103 . Thus, the user security policy module  301  generates a user defined security rule. In one embodiment, the definition received by the user security policy module  301  from the client device  107  of the user includes at least the destination associated with the security rule and one security attribute for the security rule that indicates any entries to the destination are suspicious. 
     In one embodiment, the dynamic security policy modules  303 A to  303 N are machine-learned neural network models. Any machine learning algorithm may be used by the machine-learned neural network models such as linear regression, logistic regression, SVM, etc. The dynamic security policy modules  303 A to  303 N are trained by the training module  207  to automatically generate security rules for the security policy. Each dynamic security policy module  303  is associated with a type of activity that occurs in the entity  101  and is trained to generate security rules for the type of activity. For example, dynamic security policy module  303 A is trained to generate security rules for entries of activities associated with a first destination in the document whereas dynamic security policy module  303 B is trained to generate security rules for entries of activities associated with a second destination in the document that is distinct from the first destination. Thus, the dynamic security policy modules  303 A to  303 N automatically generate security rules to identify different types of suspicious entries in the document that are representative of malicious activity at the entity  101  due to being trained on the attributes of the suspicious and non-suspicious entries included in the training data. In one embodiment, a representative of the entity  101  may modify a security rule that is automatically generated by a dynamic security policy module  303 . 
     To automatically generate security rules for the document, each dynamic security policy module  303  retrieves entries from the document that correspond to the type of activity that the dynamic security policy module  303  is trained to generate rules for. The entry attributes of each retrieved entry are input to the dynamic security policy module  303  and the dynamic security policy module  303  generates one or more security rules according to the entry attributes. The security rules generated by each dynamic security policy module  303  represent activity that is malicious as it is not consistent with the non-malicious activity in the document. 
       FIG.  6    shows an example security policy that includes a plurality of security rules. The security rules are organized based on whether the security rule is user defined or dynamically generated by the security policy module  209 . For example, the security policy may include user defined rule  601  that classifies any entries to the document made to identifier  1  (e.g., the destination) between Monday to Friday before 8 AM and after 5 PM as a suspicious entry. 
     The security policy shown in  FIG.  6    may include a plurality of dynamically created security rules  603 . For example, the security policy may include a dynamically generated rule  603 A for identifier  5  (e.g., a destination) that classifies any entries including values that are less than a threshold percentage of a predetermined value as suspicious. The security policy may also include a dynamically generated rule  603 B that classifies any entries to identifier  3  (e.g., a destination) made by a group of users  1  and a group of users  2  as suspicious. Lastly, the example security policy may also include a dynamically generated rule  603 C that classifies any entries to any identifier (e.g., a destination) in the document from a client device  107  located in Africa and South America as suspicious. 
     Referring back to  FIG.  2   , the document management system  103  includes a reception module  211 . The reception module  211  receives requests from client devices  107  to access a document stored by the document management system  103  and processes the requests. That is, the reception module  211  module fulfills the requests by the client devices  107  to access the requests. For example, the reception module  211  retrieves requested entries of the document from the document database  201  and transmits the retrieved entries to the devices  107  that submitted the requests. In another example, the reception module  211  adds new entries to the document based on requests to add the new entries from the client devices  107 . 
     In one embodiment, the reception module  211  extracts entry attributes from the entries being accessed. The entry attributes of an entry may include fields in the entries, values of the fields, and a destination associated with the entry (e.g., identifier or journal). The reception module  211  may also extract from the request from the client device request attributes including a type of access request (e.g., view, add, modify, or delete) and attributes of the user (e.g., user identifier) that provided the request. The reception module  211  may forward the extracted attributes to the security module  215 . 
     In one embodiment, the security module  215  classifies entries in the document as suspicious or non-suspicious according to the security policy for the document. In one embodiment, the security module  215  classifies new entries to the document as suspicious or non-suspicious. The entries may be classified at the time of the request to add the new entries is made. Alternatively, the security module  215  may classify new entries for the document in batches. For example, new entries over a period of time (e.g., the past week) are aggregated and classified by the security module  215 . In one embodiment, the security module  215  retroactively classifies existing entries in the document as suspicious or non-suspicious. 
     To classify an entry, the security module  215  compares the attributes of the entry and the request with the security policy for the document to determine whether to classify the entry as suspicious or non-suspicious. In one embodiment, all of the attributes of the entry and request must match all of the security attributes in at least one security rule in order for the security module  215  to classify the entry as suspicious. Thus, a partial match of a security rule would not cause the security module  215  to classify an entry as suspicious. 
     Although the security module  215  may classify a new entry as suspicious, the entry is still entered in the document according to one embodiment. In one embodiment, the security module  215  generates a security alert that is transmitted to an administrator of the document management system  103 . The security alert indicates one or more suspicious entries in the document were identified. For example,  FIG.  7    illustrates an example of the document shown in  FIG.  3    that includes a security alert  701  of suspicious entries. 
     In one embodiment, the security module  215  generates a list of suspicious entries in the document. The list is transmitted to a client device  107  of the administrator of the document management system  103  or any other representative of the entity  101 , for example. Each of the suspicious entries may be reviewed. In one embodiment, the security module  215  receives from the client device  107  of the administrator feedback on the classification. The feedback confirms whether the classification of the entry as suspicious is valid or invalid. The administrator can further investigate the malicious activity associated with the suspicious entry if the classification of the entry as suspicious is valid. In contrast, no further investigation is required if the classification of the entry is invalid. 
       FIG.  8    illustrates an example list of suspicious entries  800 . The suspicious entries are arranged in a series of rows where each row includes a suspicious entry. Each suspicious entry includes a feedback mechanism  801 . The feedback mechanism  801  is used to provide feedback whether a classification of an entry as suspicious is valid or invalid. In the example shown in  FIG.  8   , the feedback mechanism  800  is a drop down menu to provide feedback that “Yes” the entry is suspicious or “No” the entry is not suspicious. Other types of feedback mechanisms may be used. 
     In one embodiment, the security module  215  transmits the received feedback to the training module  205 . The training module  205  re-trains the security policy module  209  according to the feedback. That is, the training module  205  may adjust the weights of the feature vectors according to whether the feedback indicates classifications of entries are valid or invalid. By retraining the security policy module  209  based on the feedback, the security policy module  209  improves classification of entries in the document. 
     In an alternative embodiment, the security module  215  automatically prevents new entries from being added to the document that are classified as suspicious. The security module  215  may provide a notification to the client device  207  attempting to add the suspicious entry that the entry is suspicious. Thus, the entry would require revision or approval from the administrator to be entered in the document. 
     Process for Securing a Document 
       FIG.  9    is an interaction diagram illustrating a process identifying suspicious entries in a document according to one embodiment. In one embodiment, document management system  103  stores a document  901 . The document includes entries comprising data related to the entity  101 . The document management system  103  also stores  903  a security policy for the document. The security policy for the document includes a plurality of security rules where each security rule defines distinct attributes of a suspicious entry. 
     The client device  107 A transmits  905  an entry for the document. The document management system  103  classifies  903  the entry as suspicious. In one embodiment, the document management system  103  classifies the entry by comparing attributes of the entry and the request with the security rules included in the security policy. The document management system  103  classifies the entry as a suspicious entry responsive to a match between the attributes of the entry and security attributes of at least one security rule. The document management system  103  transmits  905  an alert responsive to the entry being classified as suspicious. 
     Alternate Document Management System Environment 
       FIG.  10    is a high-level block diagram illustrating an alternate embodiment of an environment  1000  of a document management system for identifying suspicious entries of documents of an entity  1001 . The environment  1000  is similar to the environment  100  shown in  FIG.  1   . The environment  1000  includes an entity  1001 , a document management system  1003  and client devices  107 . The entities in environment  1000  perform similar functions as their counterparts in environment  100  shown in  FIG.  1    thus the description is omitted for readability. 
     However, in environment  1000  the document management system  1003  is separated from entity  1001 . In the example of  FIG.  10   , a separate entity may be responsible for operating the document management system  1003  that manages documents on behalf of the entity  1001 . Alternatively, the same entity may be responsible for both the entity  1001  and the document management system  1003 , but the document management system  1003  is separated from the entity  1001 . 
     Hardware Components 
       FIG.  11    is a diagram illustrating a computer system  1100  upon which embodiments described herein may be implemented within the document management system  103 / 1003  and client devices  107 . For example, in the context of  FIG.  1   , the document management system  103 / 1003  and client devices  107  may each be implemented using a computer system such as described by  FIG.  11   . The document management system  103 / 1003  may also be implemented using a combination of multiple computer systems as described by  FIG.  1011   . 
     In one implementation, the document management system  103 / 1003  and client devices  107  each include processing resources  1101 , main memory  1103 , read only memory (ROM)  1105 , storage device  1107 , and a communication interface  1109 . The document management system  103 / 1003  and client devices  107  each include at least one processor  1101  for processing information and a main memory  1103 , such as a random access memory (RAM) or other dynamic storage device, for storing information and instructions to be executed by the processor  1001 . In one embodiment, multiple processors are employed by the document management system  103 / 1003  to perform the techniques described above in order to improve efficiency of the document management system  103 / 1003  and reduce computation time when securing documents. Main memory  1103  also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor  1101 . The document management system  103 / 1003  and client devices  107  may each also include ROM  1105  or other static storage device for storing static information and instructions for processor  1101 . The storage device  1107 , such as a magnetic disk or optical disk or solid state memory device, is provided for storing information and instructions. 
     The communication interface  1109  can enable each of document management system  103 / 1003  and client devices  107  to communicate with each other through use of a communication link (wireless or wireline). Each of document management system  103 / 1003  and client devices  107  can optionally include a display device  1111 , such as a cathode ray tube (CRT), an LCD monitor, an LED monitor, OLED monitor, a TFT display or a television set, for example, for displaying graphics and information to a user. An input mechanism  1113 , such as a keyboard that includes alphanumeric keys and other keys, can optionally be coupled to the computer system  1100  for communicating information and command selections to processor  1101 . Other non-limiting, illustrative examples of input mechanisms  1113  include a mouse, a trackball, touch-sensitive screen, or cursor direction keys for communicating direction information and command selections to processor  1101  and for controlling cursor movement on display device  1111 . 
     Examples described herein are related to the use of the document management system  103 / 1003  and client devices  107  for implementing the techniques described herein. According to one embodiment, those techniques are performed by each of the document management system  103 / 1003  and client devices  107  in response to processor  1101  executing one or more sequences of one or more instructions contained in main memory  1103 . Such instructions may be read into main memory  1103  from another machine-readable medium, such as storage device  1107 . Execution of the sequences of instructions contained in main memory  1103  causes processor  1101  to perform the process steps described herein. In alternative implementations, hard-wired circuitry may be used in place of or in combination with software instructions to implement examples described herein. Thus, the examples described are not limited to any specific combination of hardware circuitry and software. Furthermore, it has also proven convenient at times, to refer to arrangements of operations as modules, without loss of generality. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combinations thereof. 
     Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic is included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily referring to the same embodiment. 
     Some portions of the above are presented in terms of methods and symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A method is here, and generally, conceived to be a self-consistent sequence of steps (instructions) leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer to certain arrangements of steps requiring physical manipulations of physical quantities as modules or code devices, without loss of generality. 
     It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “displaying” or “determining” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices. 
     Certain aspects disclosed herein include process steps and instructions described herein in the form of a method. It should be noted that the process steps and instructions described herein can be embodied in software, firmware or hardware, and when embodied in software, can be downloaded to reside on and be operated from different platforms used by a variety of operating systems. 
     The embodiments discussed above also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability. 
     The methods and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the embodiments are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings described herein, and any references below to specific languages are provided for disclosure of enablement and best mode. 
     While the disclosure has been particularly shown and described with reference to one embodiment and several alternate embodiments, it will be understood by persons skilled in the relevant art that various changes in form and details can be made therein without departing from the spirit and scope of the invention.