Abstract:
An embodiment relates generally to a method of linking. The method includes receiving a message associated with at least one technical issue being resolved in a first system and containing non-confidential information and searching a knowledgebase in a second system based on the message to obtain at least one related entry. The method also includes associating at least one related entry with the non-confidential information of the message, updating at least one related entry with the non-confidential information, or creating a new entry with the non-confidential information, in the knowledgebase.

Description:
FIELD 
       [0001]    This invention relates generally to a knowledgebase, more particularly, to systems and methods for linking closed issues in a support database with the knowledgebase. 
       DESCRIPTION OF THE RELATED ART 
       [0002]    Computers and software have become critical tools in today&#39;s information based society. Computers and software have provided tools to users to greatly increase work efficiencies. However, with the advantages provided by computers and software come occasional technical problems associated with the computers and software applications. A typical solution to a computer and software technical problem is to contact a technical support person. A user can use a variety of methods to contact a technical support person, e.g., call a designated telephone number, open a chat session, send an email, etc. No matter which method a user chooses to contact a technical support person, a support ticket in a case management tool is created for a particular user&#39;s particular technical problem. Case management systems are generally well known systems such as Numara Help Desk™, Sinergia Help Desk™, Issue Tracker, etc. 
         [0003]    The support ticket can initially contain a variety of information such as a description of the problem, i.e., a support issue, reporting user, assigned personnel, contact information, etc. As the support issue is resolved the support technician updates the support ticket with information describing how the solution was resolved. Once the support issue is resolved, the ticket and its respective solution are stored within a database of the case management system. 
         [0004]    The solutions to the resolved support issues can be of great interest to a wide audience of users. However, the solutions to resolved support issues are not distributed because case management systems are typically closed since they often contain sensitive information. In most cases, the summary and resolution of the case is of interest to the wider audience. Accordingly, there is a need in the art to obtain information from a closed system to an open system, which can then be disseminated to the wider audience. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0005]    Various features of the embodiments can be more fully appreciated, as the same become better understood with reference to the following detailed description of the embodiments when considered in connection with the accompanying figures, in which: 
           [0006]      FIG. 1  depicts an exemplary system in accordance with an embodiment; 
           [0007]    FIG,  2  illustrates an exemplary service portal of the system shown in  FIG. 1  in accordance with another embodiment; 
           [0008]      FIG. 3  depicts an exemplary knowledgebase linker shown in  FIG. 1  in accordance with yet another embodiment; 
           [0009]      FIG. 4  illustrates an exemplary issue notification graphical user interface in accordance with yet another embodiment; 
           [0010]      FIG. 5  depicts an exemplary closed ticket schema in accordance with yet another embodiment; 
           [0011]      FIG. 6  illustrates an exemplary flow diagram in accordance with yet another embodiment; 
           [0012]      FIG. 7  depicts an exemplary computing platform in accordance with yet another embodiment. 
       
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
       [0013]    For simplicity and illustrative purposes, the principles of the present invention are described by referring mainly to exemplary embodiments thereof. However, one of ordinary skill in the art would readily recognize that the same principles are equally applicable to, and can be implemented in, all types of information and service portals, and that any such variations do not depart from the true spirit and scope of the present invention. Moreover, in the following detailed description, references are made to the accompanying figures, which illustrate specific embodiments. Electrical, mechanical, logical and structural changes may be made to the embodiments without departing from the spirit and scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense and the scope of the present invention is defined by the appended claims and their equivalents. 
         [0014]    Embodiments relate generally to systems and methods for a knowledgebase linker that can be configured to link closed support issues with entries in a knowledgebase in a two-stage close. More particularly, a user can contact a help desk of a service portal to resolve a technical issue. An support ticket can be created in a case management system to assist a support technician or engineer, i.e., service agent, to resolve the reported issue. When the ticket is resolved, the underlying case management system can store the closed ticket as a first stage of the two-stage close as well as to associate the closed ticket with the knowledgebase linker. 
         [0015]    The knowledgebase linker can be configured to extract key words from the received close ticket to perform a key word search in the knowledgebase. The key words dictionary can be determined by the technical support staff, user community or combinations thereof. The keyword search in the knowledgebase can return related entries from the knowledgebase 
         [0016]    The knowledgebase linker can then provide the related entries to the assigned service agent. The knowledgebase linker can generate an issue notification graphical user interface (“GUT”), e.g., a web page, that displays a list of related entries associated with the closed ticket as well as an option to add a new entry in the event of the search generating no results. The knowledgebase linker can then forward the issue notification GUI or a link thereto to the assigned service agent by electronic messaging (electronic mail, instant messaging, etc.). The service agent can select the appropriate related entries of the listed entries, supplement the selected related entries with additional description and/or create a new entry for the knowledgebase on the issue notification GUI. The knowledgebase linker can then update the knowledgebase with the relevant information from the closed ticket to the knowledgebase as the second stage of the two-stage close. 
         [0017]      FIG. 1  illustrates an exemplary system  100  in accordance with an embodiment. It should be readily apparent to those of ordinary skill in the art that the system  100  depicted in  FIG. 1  represents a generalized schematic illustration and that other components may be added or existing components may be removed or modified. Moreover, the system  100  may be implemented using software components, hardware components, or combinations thereof. 
         [0018]    As shown in  FIG. 1 , the system  100  includes users  105 , a network  110  and a service portal  115 . The users  105  can be private individuals, employees of private business or public entities or other persons interested in accessing the service portal  115 . The users  105  can access the service portal  115  using personal computers, personal mobile devices, workstations or other networked computing platforms. 
         [0019]    The network  110  can be a combination of wide area and local area networks such as the Internet. The network  110  can be configured to provide a communication channel between the users  105  and the service portal  115 . The network  110  can implement a variety of network protocols to provide the communication channel such as Internet Protocol (“IP”) Vx, ATM, SONET, or other similar network protocols. 
         [0020]    The service portal  115  can be configured to provide products and services to the user  105  as well as provisioning, installation services, updates to software and hardware products, and technical support. The service portal  115  can, among other functions, provide a list of products such as software applications and/or hardware devices as well as services such as installation, configuration, maintenance, etc., for users to purchase. As a non-limiting example, the service portal  115  can also provide information for users to research, compare and purchase software, hardware and consulting services in support of those software and/or hardware purchases. The service portal  115  can also be configured to provide support services by subscription to those same software, service, and/or hardware purchase. 
         [0021]    In accordance with various embodiments, the service portal  115  can be configured to provide a knowledge library  120 . The knowledge library  120  provides a resource for users to resolve a variety of user issues, including technical issues regarding products and/or services provided by the service portal  115 . The knowledge library  120  can contain a knowledgebase (labeled as Kbase)  125 , forum(s)  130 , frequently asked questions, or other types of electronic self-help services. The knowledgebase  125  can comprise of a database of Wiki-style articles that can be searched, revised and added thereto. The forums  130  can provide a mechanism for user with issues or problems to post questions and receive assistance from the user community. 
         [0022]    The service portal  115  can also provide a help desk  135  that is supported by service agents. If a user has the proper entitlement status for access to the help desk  135 , a user can contact a service agent for assistance with a technical issue for products and/or services purchased from the service portal  115 . The user can contact the service agent using a chat server  140  that provides for chat services, instant messaging services and/or VoIP services. Alternatively, the user can submit a written description of the technical issue, current equipment configuration, and other written information through an issue submission form submitted through electronic messaging techniques. The electronically submitted issue can be automatically processed by the case management system  145  to generate a ticket and assigned a first available service agent. 
         [0023]    The service agent can also create a ticket in the case management system  145  to track the submitted technical issue and insert a description of the issue and other related information on the ticket. The ticket can assist the service agent in managing the resolution of the issue and documenting the resolution of the technical issue. When the issue is resolved, the ticket is deemed closed and stored in an associated database of the case management system  145  as stage one of the two-stage close. The case management system  145  can then associate a copy or a link of the closed ticket to the knowledgebase linker  145 . 
         [0024]    The knowledgebase linker  150  can be configured to provide a link for the relevant information regarding the issue description, software/hardware configuration and issue resolution to the knowledgebase  125 . More particularly, the knowledgebase linker  150  can extract key words from a received close ticket to perform a key word search in the knowledgebase  125  on the received closed ticket, where the key words are obtained from a key words dictionary. The key words dictionary can be determined by the technical support staff, user community or a combinations thereof. The keyword search in the knowledgebase  125  can return related entries. 
         [0025]    The knowledgebase linker  150  can then provide the related entries to the assigned service agent of the closed ticket or the first available service agent depending on the embodiment. The knowledgebase linker  150  can generate a related issue graphical user interface (“GUI”, e.g., a web page) That displays a list of related entries associated with the closed ticket, problem description, problem resolution, any system configuration information, an editing option, and an option to add a new entry in the event of the search returning no results. 
         [0026]    The knowledgebase linker  150  can then notify the assigned service agent about the related issue GUI by directly forwarding the related issue GUI or a link thereto by electronic messaging techniques (electronic mail, instant messaging, etc.). The service agent can select the appropriate related entries that already exists in the knowledgebase  125 , supplement any selected related entries with additional description that allow the agent to relate an existing entry to the case, and/or create a new entry for the knowledgebase  125  through the related issues GUI. When the service agent activates a submit widget on the related issue GUI, the knowledgebase linker  150  can then update the knowledgebase  125  with the relevant information for the selected related entries as a second stage of the two-stage close in the case management system  145 . 
         [0027]      FIG. 2  illustrates a more detailed block diagram of the service portal  115  in accordance with another embodiment. It should be readily apparent to those of ordinary skill in the art that the service portal  115  depicted in  FIG. 2  represents a generalized schematic illustration and that other components may be added or existing components may be removed or modified. 
         [0028]    As shown in  FIG. 2 , the service portal  115  can include a web store module  205  that a user can interface with the service portal. The web store module  205  can provide the graphical user interfaces (“GUIs”) and associated functions and/or services for the service portal  115 . As an non-limiting example, the web store module  205  can generate a log-in GUI for a user to authenticate and enter the service portal  115 . 
         [0029]    The web store module  205  can couple with an application program interface (“API”) module  210 . The API module  210  can be configured to provide an interface between the functions and/or services provided by the web store module  205  and to the appropriate module of the service portal  115 . More particularly, the API module  210  can call or direct a requested function or service from the user to the respective module that provides that requested function or service. For example, a user may request a price of a product, e g., an electronic mail program, the API module  210  can direct the request to a get price function in a support tools module  215 . 
         [0030]    The API module  210  can also be configured to interface with the support tools module  215 . The support tools module  215  can be configured to provide the supporting software and hardware to implement the functionality of the service portal  115 . The support tools module  215  can contain and provide access to databases that contain information such as products lines, services providers, on-line self-help (e.g., knowledgebase  125 ), etc, The support tools module  215  can also provide services like a chat services, a help desk, installation, provisioning, etc. 
         [0031]    The API module  210  can be further configured to couple with an identification (“ID”) module  220 . The ID module  220  can be configured to provide identification management services for the service portal  115 . The ID module  220  can also store information related to users such as purchase history, user profile, usage history of the user, and entitlement data. 
         [0032]    The API module  210  can be further configured to couple with a universal messaging module  225 . The universal messaging module  225  can be configured to provide a messaging application that unifies messages. More specifically, electronic mail (“email”), documents, and instant messaging can be linked in a single application. The universal messaging module  225  can also provide a mechanism for a user to view all the related documents for the user from email to Wiki pages. 
         [0033]    An installer tools  230  can be coupled to the API module  210 . One of the services provided by the service portal  115  can be the purchase of software applications provided by independent software vendors (“ISVs”). As part of the delivery of the software applications, the ISV can be required to maintain and update the installation tools to install their respective software applications. Accordingly, the installer tools  230  can be a repository where independent software vendors can deposit their respective installation tools. 
         [0034]    The API module  210  can be further coupled to the communication layer  235  (labeled as COMM layer in  FIG. 2 ). The communication layer  235  can be configured to provide the underlying services for the modules of the service portal  115  to communicate. For example, the communication layer  235  can contain middleware for a product database to communicate with a graphical user interface requesting a product description. 
         [0035]    The API module  210  can be further coupled to an application management module  240  (labeled as APP MGMT in  FIG. 2 ). The application management module  240  can be configured to manage applications as requested by users. More specifically, a user may purchase a prepackaged software application pack (e.g., an operating system, electronic mail program and data mining program) from the service portal  115 , which is stored in an application stack module  245 . The application management module  240  can then deliver the purchased software application stack, install and configure the software application stack at a third party site such as a server farm  250  or store the software application stack in a storage farm  255  for the user to retrieve. 
         [0036]    The server farm  250  can be configured to provide computing platforms for users to lease. Accordingly, users can have a backup version of their systems, a testing platform to perform quality assurance tests on new applications, execute a program requiring excess MIPS, or any other similar computing task. 
         [0037]    The storage farm  255  can be configured to provide storage space for users to lease. Accordingly, users can lease disk storage space to back up data, provide a hot data swap, or other storage intensive tasks. 
         [0038]    In some embodiments, the knowledgebase linker  150  can be configured to be executed in the support tools module  215 . In other embodiments, the knowledgebase linker  150  can be executed as a standalone module. 
         [0039]      FIG. 3  depicts a more detailed block diagram of the knowledgebase linker  150  in accordance with another embodiment. It should be readily apparent to those of ordinary skill in the art that the knowledgebase linker  150  depicted in  FIG. 3  represents a generalized schematic illustration and that other components may be added or existing components may be removed or modified. 
         [0040]    As shown in  FIG. 3 , the knowledgebase linker  150  can comprise a control module  305 , a user interface module  310 , a case management interface (labeled as “CASE MANAGEMENT I/F” in  FIG. 3 ) module  315 , and a knowledgebase interface (labeled as “KBASE I/F” in  FIG. 3 )  320 . It should be readily obvious to one of ordinary skill in the art that the depicted modules  305 - 320  can be implemented as software applications (programmed in C, C++, JAVA, PHP, etc.), hardware components (EEPROM, application specific integrated circuit, microprocessor, etc.) or combinations thereof. 
         [0041]    The control module  305  can be configured to manage and interface with the other modules  310 - 320  to provide the functionality of the knowledgebase linker  150  as described above and further described herein below. 
         [0042]    The user interface module  310  can be configured to generate graphical user interfaces (“GUIs”) as required by the control module  305 . For example, the user interface module  310  can generate an issue notification GUI and/or a link to the issue notification GUI. The issue notification GUI can notify the assigned service agent a list of related entries in the knowledgebase  125  based on a key word search of a received closed ticket, an option to add entries and an option to modify current entries or other related information. An example of the issue notification GUI is shown in  FIG. 4 . 
         [0043]      FIG. 4  depicts an exemplary issue notification GUI  400  in accordance with yet another embodiment. The GUI  400  is merely illustrative and other variations of the GUI  400  are well within the contemplated embodiments. The GUI  400  can be implemented as a graphical page implemented in XML, HTM, SGML, or other mark-up language. 
         [0044]    As shown in  FIG. 4 , the issue notification GUI  400  comprises of selector buttons  405 A-N, which are respectively associated with entry text boxes  410 A-N and selector button  415 , which is associated with add entry text box  420 . The issue notification GUI  400  also comprises of an issue description text box  425 , an issue solution text box  430 , a system configuration text box  435 , a submit button  440 , and a later button  445 . 
         [0045]    The entry text boxes  410 A-N can each store a related entry from the knowledgebase  125  that was returned on a key word search extracted from a received closed ticket. The number of entry text boxes  410 A-N is dependent on the number of found related entries from the knowledgebase  125 . The entry text boxes  410 A-N can also be editable to allow the service agent to create a new entry for the knowledgebase  125 . 
         [0046]    Accordingly, the service agent can select any number of related entries to update with the relevant and non-confidential information, i.e., the issue description, issue resolution and system configuration, from the received close ticket. The selected entries of entry text boxes  410 A-N can then be updated with the relevant information. 
         [0047]    The add entry text box  420  can be text box that the service agent can add a new entry for the knowledgebase  125  in the event that the service agent is not satisfied with the existing list of related entries or the key word search did not return any results. The activation of associated selector button  415  will update the information contained in the add entry text box  420  to the knowledgebase  125  with the relevant information from the closed ticket. 
         [0048]    The issue description text box  425  can contain a description of the issue that was retrieved from the closed ticket. This text box  425  can also be editable by the service agent to supplement the description or to remove confidential information. The issue solution text box  430  can contain a description of the resolution of the issue. In some cases, the issue may not be resolved because it was traced to a known bug being resolved by the vendor. The system configuration text box  435  can contain a description of the computer system of the reporting user which can include hardware, software, and configuration information. 
         [0049]    The submit button  440  can be configured to update the knowledgebase  125  with any selected related entries for text boxes  410 A-N and  420  by activation of the respective selector buttons  405 A-N and  415 . In one update process, the text from the issue description text box  425 , the issue resolution text box  430 , and the system configuration text box  430  is updated to the knowledgebase  125  to the selected related entries. Alternatively, the knowledgebase linker  150  can update the related entries with links to an issue description field, an issue resolution field, and a system configuration field of the database record for the closed tickets. An example of the schema for a closed ticket is depicted in  FIG. 5 . 
         [0050]      FIG. 5  illustrates an exemplary closed ticket record  500  in accordance with yet another embodiment. It should be readily apparent to those of ordinary skill in the art that the closed ticket record  500  shown in  FIG. 5  represents a generalized schematic illustration and that other fields can be added or existing fields can be removed or modified. 
         [0051]    As shown in  FIG. 5 , the closed ticket record  500  can comprise a ticket number (labeled as “TICKET NO.”) field  505 , a service agent field  510 , a user field  515 , an initial date field  520 , a stage one closed date (labeled as “S1 CLOSE DATE”) field  525 , a stage two close date (labeled as “S2 CLOSE DATE”) field  530  an issue description field  535 , an issue resolution field  540 , and a system configuration field  545 . 
         [0052]    The ticket number field  505  can store the ticket number of the ticket. The ticket number can be a numerical identification method to reference the issue. The service agent field  510  can store The identity of the service agent working on the issue. The user field  515  can store the identity of the user reporting information. This field can also contain user contact information, user history, and other related user information that may be needed by the case management system  145 . 
         [0053]    The initial date field  520  can contain the date of when the issue was reported to the case management system  145 . The stage one closed date field  525  can contain the date the issue was resolved by the service agent in the case management system  145 . The stage two closed date field  530  can contain the date was the issue was updated to the knowledgebase  125 . 
         [0054]    The issue description field  535  can store a description of the issue. The issue resolution field  540  can store a description of the resolution of the issue by the service agent. The system configuration field  545  can contain the information related to the hardware, software, and configuration information of the reporting user&#39;s system. 
         [0055]    Returning to  FIG. 4 , the issue notification GUI  400  can farther comprise a later button  445 . When activated, the control module  305  can be configured to close the GUI  400  and wait for a predetermined amount of time. For example, the delay may be a half hour. The delay may be used to allow the service agent to finish a current issue or is busy with other matters. However, in an effort to keep the knowledgebase  125  updated, the control module  305  can return the issue notification GUI to the service agent&#39;s display until the service agent closes the issue notification GUI  400  by activating the submit button  440 , that is, stage two of the two-stage close. 
         [0056]    Returning to  FIG. 3 , in some embodiments, the user interface module  310  can be considered an application program interface module which provides the necessary tools and interfaces to communicate with other modules of the knowledgebase linker  150  and the other modules of the service portal  115 . 
         [0057]    The control module  305  can be configured to couple with the case management interface module  315 , which provides a communication channel for the control module  305  to receive a copy of the closed ticket or a link to the closed ticket. The case management interface module  315  can be implemented as an application program interface (“API”), a function call, a remote procedure call, or other similar mechanism. 
         [0058]    The control module  305  can be further coupled to the knowledgebase interface  320 . The knowledgebase interface  320  can provide a communication channel for the control module  305  to query the knowledgebase  125  as well as to update relevant information from the closed ticket to the knowledgebase  125  either directly or by a link. Similar to the case management interface module  315 , the knowledgebase interface  320  can be implement with an API, a function call, a remote procedure calls, or other similar mechanism. 
         [0059]      FIG. 6  illustrates an exemplary flow diagram  600  executed by the knowledgebase linker  150  in accordance with yet another embodiment. It should be readily apparent to those of ordinary skill in the art that the flow diagram  600  depicted in  FIG. 5  represents a generalized schematic illustration and that other steps may be added or existing steps may be removed or modified. 
         [0060]    As shown in  FIG. 6 , the control module  305  can be configured to receive a copy of the closed ticket from the case management system  145 , in step  605 . The control module  305  can extract out the non-confidential information from the closed ticket, i.e., service agent, issue description, issue resolution and system configuration, and temporarily buffer the closed ticket. In some embodiments, the control module  305  can receive a link to the closed ticket from the case management system  145 . The control module  305  can then query the database associated with the case management system  145  to retrieve the non-confidential relevant information from the respective fields ( 530 - 540 ) of closed ticket record  400  associated with the received closed ticket. This information can also be buffered by the control module  305  when received. 
         [0061]    In step  610 , the control module  305  can be configured to perform a key word search on the non-confidential information using a key word dictionary. The system administrators, technical support staff of the service portal, and/or users may have determine the terms in the key word dictionary. The resulting key words from the non-confidential information can then be temporarily buffered by the control module. 
         [0062]    In step  615 , the control module  305  can query the knowledgebase  125  with the extracted key words from the received closed ticket. The control module  305  can then receive the results from the knowledgebase  125 , in step  620 . 
         [0063]    In step  625 , the control module  305  can display the search results from the knowledgebase  125 . More specifically, the control module  305  can populate the received related entries from the knowledgebase  125  in a respective entry text box  410 A-N in an issue notification GUI  400 . The number of text boxes being used is dependent on the number of the related entries returned. The control module  305  can then send the issue notification GUI  400  to the assigned service agent on the closed ticket. 
         [0064]    In step  630 , the control module  305  has received the selected related entries from the service agent upon activation of the submit button  440 . More specifically, the service agent had activated at least one of the selector buttons  405 A- 405 N to indicate the selected related entries. Subsequently, the control module  305  can be configured update the selected related information with the issue description, issue resolution, and configuration information or post a link to this information, in step  635 . 
         [0065]    In step  640 , the control module  305  has received the modified entries from the service agent upon activation of the submit button  440 . The service agent can select the appropriate selector button ( 405 A-N) for the related entry to be modified. Since the entry text boxes  410 A-N are editable, the service agent can add or delete the selected related entry as needed. Subsequently, the control  305  can proceed to the processing of step  635 . 
         [0066]    In step  645 , the control module  305  has received a new entry upon activation of the submit button  440 . More specifically, the service agent selected the selector button  415  and added a new entry in the add entry text box  420 . The added text is then updated along with the issue description, issue resolution, and system configuration information (or a link thereto) to the knowledgebase  125 , in step  445 . 
         [0067]    For the processing associated with steps  630 ,  640 , and  645 , all three events can occur individually or in combinations. For example, a service agent can select any number related entries and add a new entry to the knowledgebase  125 . 
         [0068]      FIG. 7  illustrates an exemplary block diagram of a computing platform  700  where an embodiment may be practiced. The functions of the knowledgebase linker  150  may be implemented in program code and executed by the computing platform  700 . The knowledgebase linker  150  may be implemented in computer languages such as PASCAL, C, C++, JAVA, etc. 
         [0069]    As shown in  FIG. 7 , the computer system  700  includes one or more processors, such as processor  702  that provide an execution platform for embodiments of the knowledgebase linker  150 . Commands and data from the processor  702  are communicated over a communication bus  704 . The computer system  700  also includes a main memory  706 , such as a Random Access Memory (RAM), where the knowledgebase linker  150  may be executed during runtime, and a secondary memory  708 . The secondary memory  708  includes, for example, a hard disk drive  710  and/or a removable storage drive  712 , representing a floppy diskette drive, a magnetic tape drive, a compact disk drive, etc., where a copy of a computer program embodiment for the knowledgebase linker  150  may be stored. The removable storage drive  712  reads from and/or writes to a removable storage unit  714  in a well-known manner. A user interfaces with the knowledgebase linker  150  with a keyboard  716 , a mouse  718 , and a display  720 . The display adapter  722  interfaces with the communication bus  704  and the display  720 . The display adapter  722  also receives display data from the processor  702  and converts the display data into display commands for the display  720 . 
         [0070]    Certain embodiments may be performed as a computer program. The computer program may exist in a variety of forms both active and inactive. For example, the computer program can exist as software program(s) comprised of program instructions in source code, object code, executable code or other formats; firmware program(s); or hardware description language (HDL) files. Any of the above can be embodied on a computer readable medium, which include storage devices and signals, in compressed or uncompressed form. Exemplary computer readable storage devices include conventional computer system RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and magnetic or optical disks or tapes. Exemplary computer readable signals, whether modulated using a carrier or not, are signals that a computer system hosting or running the present invention can be configured to access, including signals downloaded through the Internet or other networks. Concrete examples of the foregoing include distribution of executable software program(s) of the computer program on a CD-ROM or via Internet download. In a sense, the Internet itself, as an abstract entity, is a computer readable medium. The same is true of computer networks in general. 
         [0071]    While the invention has been described with reference to the exemplary embodiments thereof, those skilled in the art will be able to make various modifications to the described embodiments without departing from the true spirit and scope. The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. In particular, although the method has been described by examples, the steps of the method may be performed in a different order than illustrated or simultaneously. Those skilled in the art will recognize that these and other variations are possible within the spirit and scope as defined in the following claims and their equivalents.