Abstract:
A system and method for collectively indexing a collection of documents in paper or electronic form. The collective index is created for all documents, which may come from a variety of sources and be initially presented in a variety of formats. Documents are converted to a standard electronic format, then analyzed and processed to identify, locate, and tag objects of interest. Hierarchical menus are created with multiple categories.

Description:
[0001]    This application claims benefit of and priority to U.S. Provisional Application No. 61/874,332, filed Sep. 5, 2013, by Joseph Crowe, et al., and is entitled to that filing date for priority. The specification, figures and complete disclosure of U.S. Provisional Application No. 61/874,332 are incorporated herein by specific reference for all purposes. 
     
    
     FIELD OF INVENTION 
       [0002]    This invention relates to a system and related methods for indexing a collection of documents in paper or electronic form and creating an intuitive menu structure therefor. 
       BACKGROUND OF INVENTION 
       [0003]    A typical business or commercial enterprise will possess a host of documents in paper or electronic form from a variety of sources. While each may be independently indexed, the documents as a whole are not, thus making it difficult to locate needed reference material quickly and efficiently. 
       SUMMARY OF INVENTION 
       [0004]    In various embodiments, the present invention comprises a computer assisted system and related methods for indexing a collection of documents in paper or electronic form and creating an intuitive menu structure therefor. The collective index is created for all documents, which may come from a variety of sources and be initially presented in a variety of formats. 
         [0005]    Initially all documents, papers and data are collected. Electronic form documents are converted to a common standard format (such as PDF), if they are not already in that format. Paper documents are converted to that same common standard format by means known in the art. In one exemplary embodiment, all of the documents in standard format (e.g., PDF) representing the pertinent subject matter to be indexed are placed in a single work or file folder on a storage device (e.g., hard drive) on a computer or server device. 
         [0006]    Each document is then analyzed and processed. All buttons and destinations in a document are mapped out. In several embodiments, the processing comprises the creation of a spreadsheet for each type of object of interest. In this embodiment, the left-hand column represents a list or collection of names or titles for each individual object of interest of a certain type (e.g., names of air handling units). The second column contains a unique identifier tag (e.g., an alpha-numeric code) for each named object of interest. Other columns in the spreadsheet represent a combination of the different types of information available for each object of interest and the file locations where that information can be found. While this exemplary embodiment of the invention uses a spreadsheet, it should be noted that any similar form of data file or program type used for storing information can be used. 
         [0007]    Each document file is reviewed and searched to find subject matter pertinent to the objects of interest. When a piece of information relative to any object of interest is located within a document, the exact view of the information is marked with a unique identifier tag. While the unique identifier tag can be in any form, in one embodiment, the unique identifier tag is a two-part alpha-numeric string denoting a combination of the object of interest (e.g., Air Handling Unit), and the kind of information pertaining to the object of interest (e.g., drawing plan view of the unit), with an underscore character used to separate the parts. The page view best representing the floor plan view of an air handling unit named “AHU-DT-10-01” thus would receive the unique identifier tag of “FLOOR_DT1001.” A “destination” is added to the PDF document file with that unique identifier tag in the list of destinations within the document, thus representing the location and view of that information within the PDF document file. 
         [0008]    After a destination is added to the list of destinations in the PDF document, it is marked on the spreadsheet, within the row representing the named object of interest, and with the column representing the PDF file name where the designation resides (e.g., “Mech Drawings.pdf”), the type of information the destination is marking (e.g., “Floor Plan”), or both. 
         [0009]    This process is completed for each object of interest in the spreadsheet assigned by type until all PDF documents have been thoroughly searched, analyzed, and provided with destinations. The spreadsheets are simultaneously updated to reflect the destinations created with the PDF documents. If an object of interest was depicted within the PDF documentation, it is overlaid with an invisible button or link. The button/link is named after the unique identifier tag of that object of interest. These buttons/links are provided with Javascript (or similar coding) based on the information within the corresponding spreadsheet. 
         [0010]    After completion of the processing of all documents, the process proceeds to conceptual menu construction. It should be noted that code construction can be performed simultaneously with conceptual menu construction. For conceptual menu construction, all objects of interest cataloged in the spreadsheets described above are now organized by type, using name and unique identifier tag, into a simple columnar list format in multiple type spreadsheets. Each type is given a title, which may be placed at the top of the list of objects of interest for that type (e.g., “Air Handling Units”). This title is subsequently used for the menu title for a menu representing the type, and for each object of interest belonging to this type, there is a name and unique identifier tag provided below the title. 
         [0011]    Each type is then assigned to a category (a collection of similar types). In a process similar to that described above for types, each category is given a name, and a category spreadsheet is generated where all types and categories are listed under higher level categories. This process is repeated for all categories in the spreadsheet until one final level category is reached (above all sub-categories and their types). In one exemplary embodiment, the end result is a spreadsheet where each row represents a category or a type of object of interest, and each column indicates the level of the category. The process allows for many levels of sub-categories between the highest-level category (e.g., “Home Menu”) and the types of objects of interest. Each sub-category belongs to the nearest higher-level category above it and each type of object of interest belongs to the sub-category above it. 
         [0012]    The menu category spreadsheet file may be reviewed to ensure that every category or sub-category falls within a higher level category up to the top level, and that each type of object of interest belongs to the lowest level of category. Then the spreadsheets cataloging the objects of interest are reviewed to ensure that all objects of interest belong to a category listed in the menu spreadsheet file. 
         [0013]    The process then proceeds to menu face construction, which generates the object of interest menus. In one exemplary embodiment, a Visual Basic macro is executed on each spreadsheet cataloging the objects of interest to examine the quantity of objects of interest, and determine the best layout for the objects to be displayed as buttons in a menu. It then creates a menu for the type of the group, and each object of interest within it is represented by a button. In one embodiment, the type of menu created is a PowerPoint menu. The title for each object of interest menu is taken from the title given to the objects of interest list, and the object of interest names are applied to individual buttons. The number of buttons in the menu is automatically determined and placed depending on the total number of objects of interest to be included in the menu. 
         [0014]    The menu category spreadsheet file undergoes a similar process to create the Home Menu and the various category and sub-category menus. The process (which can be executed through a Visual Basic macro, or other similar program) examines the quantity of sub-categories for each higher-level category, and determines the best layout for the objects to be displayed as menu buttons. It then creates a menu (such as a PowerPoint type menu) for each category, where the menu title is the category name, and each button represents one of the sub-categories for that category. 
         [0015]    Once the basic menu faces are constructed for all category and type menus, the menus are then completed. In one exemplary embodiment, where the document files are in PDF format, the completion process generates PDF menus using the basic menu faces. A Visual Basic macro (or other similar program) opens each PowerPoint menu, generates an identical PDF menu, and uses the unique identifier tag information from the button in each PowerPoint file to overlay the PDF with buttons in the same arrangement, with each button tagged by its unique identifier tag. The buttons correlate with objects of interest, and the button for each object of interest is named after its tag. The identifier tag can be used to reference the information providing in the spreadsheets cataloging the objects of interest generated earlier. 
         [0016]    The system similarly generates a PDF menu for each category and sub-category menu face, with the PDF overlain with buttons in the same arrangement. Each button is named the same as it was named in the PowerPoint file, with a .pdf suffix added. 
         [0017]    Separate from the menu construction process, the system proceeds with constructing code text files. This construction can be performed simultaneously with menu construction. Code text file construction uses the object of interest spreadsheet file for each type, where all objects of interest have been associated with relevant document files (e.g., PDF document files), and the locations within those files. A macro program (such as a Visual Basic macro program) is executed on each of these type spreadsheet files, and generates a text file for each object of interest based on the information provided for that object (i.e., the information provided in that object&#39;s row), wherein the text in the file is in the form of code. In one embodiment, the macro program arranges the information from the spreadsheet row into a Javascript code format which can be placed into PDF files. Each text file is named after the unique identifier tag for its object of interest. The text files, each representing an object of interest with “pointers” to important locations within the original collection of PDF documents, may be collected in a single folder. For example, the text file “DT1001.txt” contains the Javascript which will be placed into relevant PDF files which have buttons or links with the “DT1001” tag (which corresponds to a “AHU-DT-10-01” air handling unit). 
         [0018]    The code from the text files is then injected into relevant PDF files. In one embodiment, all of the PDF documents analyzed and all of the PDF menu files generated are placed into a common folder for ease of processing. A Visual Basic script (or other similar program) then processes a PDF document by opening it, and collecting a list of buttons and links available in the PDF. For each button or link, the process first determines whether the button or link is named after a document, or a unique identifier tag for an object (this is apparent by the button or link name). If the button/link is named after another document (e.g., “Air Handling Units.pdf”), the program generates a Javascript code for the button/link and inserts the code into the PDF document so that when the button/link is clicked (such as by an end-user), the code opens the document bearing the same name as the button/link. This is the case for all category PDF menus. 
         [0019]    If the button/link is named after the unique identifier tag of an object of interest, the program searches the text files for a file name bearing the unique identifier tag. If a match is found, the text file is opened and the Javascript code is copied from it and placed within the PDF document. When a user clicks the button/link, a pop-up menu is presented showing options that can guide the user to various destinations. The unique identifier tags exist within both the PDF menus and the original PDF document files. 
         [0020]    The present invention also comprises a code-verification phase. In one embodiment, a Visual Basic script (or similar program) is executed on each PDF file. The program compiles a list of each filename as well as each button and destination within that file. It then opens each type spreadsheet representing each object of interest, and verifies that each data point shown on the spreadsheet is accurately associated with the buttons and destinations list collected from the PDFs. Any points which do not have a match are marked in some way (e.g., highlighted, or with a different color), for easy detection. Mismatched points can then be corrected either in the spreadsheet or in the PDF documents by re-executing the appropriate steps. 
         [0021]    The complete library of PDF documents and menus can then be stored on one or more single computer storage devices (e.g., external disk drive, computer hard drive, portable drive, USB drive, or the like), and provided to end-users. The end-user can initiate the menu file and proceed through the menus to find the information needed, then click on the appropriate link or button to go to that information in the original PDF document, wherever located. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0022]      FIG. 1  shows a chart of a library indexing process in accordance with an exemplary embodiment of the present invention. 
           [0023]      FIG. 2  shows a chart of a cross-indexing and menu construction process from  FIG. 1 . 
           [0024]      FIG. 3  shows an example of an object of interest spreadsheet. 
           [0025]      FIG. 4  shows a document file being analyzed. 
           [0026]      FIG. 5  shows another example of an object of interest spreadsheet. 
           [0027]      FIG. 6  shows an example of a completed object of interest spreadsheet. 
           [0028]      FIG. 7  shows an example of a button overlay in a document file. 
           [0029]      FIG. 8  shows an example of an object of interest list. 
           [0030]      FIG. 9  shows an example of a category hierarchy. 
           [0031]      FIGS. 10-16  show examples of object of interest menus. 
           [0032]      FIG. 17  shows an example of a top-level category menu. 
           [0033]      FIG. 18  shows an example of a second-level category menu. 
           [0034]      FIGS. 19-20  show examples of menus with identifier tag overlays. 
           [0035]      FIG. 21  shows an example of a folder with text files. 
           [0036]      FIG. 22  shows an example of a pop-up window with menu. 
           [0037]      FIG. 23  shows an example of a code-verification spreadsheet. 
       
    
    
     DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
       [0038]    In various embodiments, the present invention comprises a computer assisted system and related methods for indexing a collection of documents in paper or electronic form and creating an intuitive menu structure therefor. With reference to  FIG. 1 , initially all documents and data are collected  100 . Electronic form documents are converted to a common standard format (such as PDF), if they are not already in that format. Paper documents are converted to that same format by means known in the art  102 . In one exemplary embodiment, all of the documents in standard format (e.g., PDF) representing the pertinent subject matter to be indexed are placed in a single work or file folder on a storage device (e.g., hard drive) on a computer or server device. Each document is then analyzed and processed (Phase 1, as seen in  FIG. 2 ). All buttons and destinations in a document are mapped out  104 . 
         [0039]    In several embodiments, the processing comprises the creation of a spreadsheet for each type of object of interest. An example of a spreadsheet for “Air Handling Units”  200  as the object of interest is shown in  FIG. 3 . In this embodiment, the left-hand column  202  represents a list or collection of names or titles for each individual object of interest of a certain type (e.g., names of air handling units). The second column  204  contains a unique object identifier tag (e.g., an alpha-numeric code) for each named object of interest. Other columns in the spreadsheet represent a combination of the different types of information available for each object of interest and the file locations where that information can be found. While this exemplary embodiment of the invention uses a spreadsheet, it should be noted that any similar form of data file or program type used for storing information can be used. 
         [0040]    Each document file is reviewed and searched to find subject matter pertinent to the objects of interest.  FIG. 4  illustrates an example of the process where HVAC equipment is the general subject matter, so that any documents depicting the installation, operation, maintenance, repair, controls, or other pertinent information pertaining to HVAC equipment is cross-indexed (as described below). When a piece of information relative to any object of interest is located within a document, the exact view of the information  300  is marked with a unique identifier tag  302 . While the unique identifier tag can be in any form, in the embodiment shown, the unique identifier tag is a two-part alpha-numeric string denoting a combination of the object of interest (e.g., Air Handling Unit), and the kind of information pertaining to the object of interest (e.g., drawing plan view of the unit), with an underscore character used to separate the parts. The page view  300  best representing the floor plan view of an air handling unit named “AHU-DT-10-01” thus would receive the unique identifier tag of “FLOOR_DT1001.” A “destination”  310  is added to the PDF document file with that unique identifier tag in the list of destinations  320  within the document, thus representing the location  304  and view of that information within the PDF document file. 
         [0041]    After a destination  310  is added to the list of destinations  320  in the PDF document, it is marked on the spreadsheet, as seen in  FIG. 5 , within the row representing the named object of interest and the column representing the PDF file name  210  where the designation resides (e.g., “Mech Drawings.pdf”), the type of information the destination is marking  212  (e.g., “Floor Plan”), or both. 
         [0042]    This process is completed for each object of interest in the spreadsheet assigned by type until all PDF documents have been thoroughly searched, analyzed, and provided with destinations. The spreadsheets are simultaneously updated to reflect the destinations created with the PDF documents.  FIG. 6  shows an example of a complete spreadsheet, with all objects of interest of a certain type  400  (in this case, air handling units) associated with the relevant PDF document files and the locations within those documents. 
         [0043]    If an object of interest was depicted within the PDF documentation, it is overlaid in the document with an invisible button or link  500 . The button/link is named  502  after the unique identifier tag of that object of interest, as seen in  FIG. 7 . As described later, these buttons/links are provided with Javascript (or similar coding) based on the information within the corresponding spreadsheet. 
         [0044]    After completion of the processing of all documents (Phase 1), the process proceeds to conceptual menu construction  110  (Phase 2). It should be noted that code construction (Phase 5, described below) can be performed simultaneously with Phase 2. 
         [0045]    For Phase 2, all objects of interest cataloged in the spreadsheets described above are now organized by type, using name and unique identifier tag, into a simple columnar list format in multiple type spreadsheets, as seen in  FIG. 8 . Each type is given a title  600 , which in the embodiment shown is placed at the top of the list of objects of interest for that type (e.g., “Air Handling Units”). As described in more detail below, this title is subsequently used for the menu title for a menu representing the type, and for each object of interest belonging to this type, there is a name  202  and unique object identifier tag  204  provided below the title. 
         [0046]    Each type is then assigned to a category (i.e., a collection of similar types). In a process similar to that described above for types, each category is given a name, and a category spreadsheet is generated where all types and categories are listed under higher level categories. This process is repeated for all categories in the spreadsheet until one final level category is reached (above all sub-categories and their types). In one exemplary embodiment, the end result is a spreadsheet where each row represents a category or a type of object of interest, and each column indicates the level of the category.  FIG. 9  shows an example with one level of sub-categories; however, the process allows for many levels of sub-categories between the highest-level category (e.g., “Home Menu”) and the types of objects of interest. Each sub-category belongs to the nearest higher-level category above it (i.e., to the left, in  FIG. 9 ), and each type of object of interest belongs to the sub-category above it. 
         [0047]      FIG. 9  shows an example with two category levels, and one type. The top category level  610  is named “Home Menu,” and there is one sub-category level  612  with sub-categories “Mechanical,” “Electrical,” “Fire Protection,” and “Medical Gas.” Each sub-category has several types  600 . Thus, the “Air Handling Units” type belong to the “Mechanical” sub-category, which belongs to the “Home Menu” final category. 
         [0048]    The menu category spreadsheet file may be reviewed to ensure that every category or sub-category falls within a higher level category up to the top level, and that each type of object of interest belongs to the lowest level of category. Then the spreadsheets cataloging the objects of interest are reviewed to ensure that all objects of interest belong to a category listed in the menu spreadsheet file. 
         [0049]    The process then proceeds to menu face construction  112  (Phase 3), which generates the object of interest menus. In one exemplary embodiment, a Visual Basic macro is executed on each spreadsheet cataloging the objects of interest to examine the quantity of objects of interest, and determine the best layout for the objects to be displayed as buttons in a menu. It then creates a menu for the type of the group, and each object of interest within it is represented by a button. In one embodiment, the type of menu created is a PowerPoint menu, as seen in  FIGS. 10-16 . The title  620  for each object of interest menu is taken from the title given to the objects of interest list (as seen in  FIG. 8 ), and the object of interest names are applied to individual buttons  622  in the menu. The number of buttons in the menu is automatically determined and placed depending on the total number of objects of interest to be included in the menu. 
         [0050]    The menu category spreadsheet file undergoes a similar process to create the Home Menu and the various category and sub-category menus. The process (which can be executed through a Visual Basic macro, or other similar program) examines the quantity of sub-categories for each higher-level category, and determines the best layout for the objects to be displayed as menu buttons. It then creates a menu (such as a PowerPoint type menu) for each category, where the menu title is the category name, and each button represents one of the sub-categories for that category. 
         [0051]      FIG. 17  shows an example of a top-level category  610  “Home Menu” with the title “Interactive Maintenance and Engineering Documentation”  630 . Several sub-categories are listed and shown as buttons. Once the menus are completed, using the “Mechanical” button  632  from this menu, for example, displays the second-level category menu for “Mechanical Equipment,” as seen in  FIG. 18 , which contains buttons for the objects of interest menus (as described above). 
         [0052]    Once the basic menu faces are constructed for all category and type menus (e.g., PowerPoint menus, in the examples shown), the menus are then completed by generating standard format menus  114  (Phase 4). In one exemplary embodiment, where the document files are in PDF format, the completion process generates PDF menus using the basic menu faces. A Visual Basic macro (or other similar program) opens each PowerPoint menu, generates an identical PDF menu, and uses the unique identifier tag information from the button in each PowerPoint file to overlay the PDF with buttons in the same arrangement, with each button  700  tagged by its unique identifier tag  702 , as seen in  FIG. 19 . The buttons correlate with objects of interest, and the button for each object of interest is named after its tag. For example, the object of interest “AHU-DT-10-01” is overlain with a button named “DT1001.” The identifier tag can be used to reference the information provided in the spreadsheets cataloging the objects of interest generated in Phase  1 , as seen in  FIG. 6 . 
         [0053]    The system similarly generates a PDF menu for each category and sub-category menu face, with the PDF overlain with buttons  700  in the same arrangement, as seen in  FIG. 20 . Each button is tagged the same as it was named in the PowerPoint file, with a .pdf suffix added  704 . 
         [0054]    Separate from the menu construction process, the system proceeds with constructing code text files  120  (Phase 5). As noted above, Phase  5  can be performed simultaneously with Phases 2-4. 
         [0055]    Phase 5 uses the object of interest spreadsheet file (as seen in  FIG. 6 ) for each type, where all objects of interest have been associated with relevant document files (e.g., PDF document files), and the locations within those files. A macro program (such as a Visual Basic macro program) is executed on each of these type spreadsheet files, and generates a text file for each object of interest based on the information provided for that object (i.e., the information provided in that object&#39;s row), wherein the text in the file is in the form of code. In one embodiment, the macro program arranges the information from the spreadsheet row into a Javascript code format which can be placed into PDF files. Each text file is named after the unique identifier tag for its object of interest. The text files  750 , each representing an object of interest with “pointers” to important locations within the original collection of PDF documents, may be collected in a single folder, as seen in  FIG. 21 . For example, the text file “DT1001.txt”  750  contains the Javascript which will be placed into relevant PDF files which have buttons or links with the “DT1001” tag (which corresponds to the “AHU-DT-10-01” air handling unit, as seen in  FIG. 6 ). In this embodiment, the values in the column labeled “DEST” in  FIG. 6  are used as the unique identifier tags for the corresponding objects shown in the first column. 
         [0056]    In Phase 6, the code from the text files are injected into relevant PDF files  122 . In one embodiment, all of the PDF documents analyzed in Phase  1 , and all of the PDF menu files generated from Phase 4, are placed into a common folder for ease of processing. A Visual Basic script (or other similar program) then processes a PDF document by opening it, and collecting a list of buttons and links available in the PDF (these buttons and links were generated in Phase 1 for the collection of documents or in Phase 4 for the menus). 
         [0057]    For each button or link, the process first determines whether the button or link is named after a document, or a unique identifier tag for an object (this is apparent by the button or link name). If the button/link is named after another document (e.g., “Air Handling Units.pdf”), the program generates a Javascript code for the button/link and inserts the code into the PDF document so that when the button/link is clicked (such as by an end-user), the code opens the document bearing the same name as the button/link. This is the case for all category PDF menus. 
         [0058]    If the button/link is named after the unique identifier tag of an object of interest, the program searches the text files for a file name bearing the unique identifier tag. If a match is found, the text file is opened and the Javascript code is copied from it and placed within the PDF document. When a user clicks the button/link, a pop-up menu  800  is presented showing options that can guide the user to various destinations, as seen in  FIG. 22 . The unique identifier tags exist within both the PDF menus and the original PDF document files. 
         [0059]    In the example shown in  FIG. 22 , the user has clicked on the button labeled “AHU-DT-01-01.” The pop-up menu  800  generated by the imbedded Javascript code presents the type of information available for the unit. When user clicks on an option with the pop-up menu, the PDF containing the information is opened to the page based upon the destination provided (as determined in Phase 1). For example, if the user clicks on the submenu option “Floor Plan,” the code opens the correct PDF document to the view shown in  FIG. 4 , providing the user with a floor plan view of “AHU-DT-10-01.” 
         [0060]    Phase 7 is a code-verification phase  124 . In one embodiment, a Visual Basic script (or similar program) is executed on each PDF file. The program compiles a list of each filename as well as each button and destination within that file. It then opens each type spreadsheet representing each object of interest, and verifies that each data point shown on the spreadsheet is accurately associated with the buttons and destinations list collected from the PDFs. Any points which do not have a match are marked in some way (e.g., highlighted, or with a different color), for easy detection, as seen in  FIG. 23 . Mismatched points can then be corrected either in the spreadsheet or in the PDF documents by re-executing the appropriate steps in Phases 1 and 5. 
         [0061]    The complete library of PDF documents and menus can then be stored on one or more single computer storage devices (e.g., external disk drive, computer hard drive, portable drive, USB drive, or the like), and provided to end-users. The end-user can initiate the menu file and proceed through the menus to find the information needed, then click on the appropriate link or button to go to that information in the original PDF document, wherever located. 
         [0062]    In order to provide a context for the various aspects of the invention, the following discussion provides a brief, general description of a suitable computing environment in which the various aspects of the present invention may be implemented. A computing system environment is one example of a suitable computing environment, but is not intended to suggest any limitation as to the scope of use or functionality of the invention. A computing environment may contain any one or combination of components discussed below, and may contain additional components, or some of the illustrated components may be absent. Various embodiments of the invention are operational with numerous general purpose or special purpose computing systems, environments or configurations. Examples of computing systems, environments, or configurations that may be suitable for use with various embodiments of the invention include, but are not limited to, personal computers, laptop computers, computer servers, computer notebooks, hand-held devices, microprocessor-based systems, multiprocessor systems, TV set-top boxes and devices, programmable consumer electronics, cell phones, personal digital assistants (PDAs), network PCs, minicomputers, mainframe computers, embedded systems, distributed computing environments, and the like. 
         [0063]    Embodiments of the invention may be implemented in the form of computer-executable instructions, such as program code or program modules, being executed by a computer or computing device. Program code or modules may include programs, objections, components, data elements and structures, routines, subroutines, functions and the like. These are used to perform or implement particular tasks or functions. Embodiments of the invention also may be implemented in distributed computing environments. In such environments, tasks are performed by remote processing devices linked via a communications network or other data transmission medium, and data and program code or modules may be located in both local and remote computer storage media including memory storage devices. 
         [0064]    In one embodiment, a computer system comprises multiple client devices in communication with at least one server device through or over a network. In various embodiments, the network may comprise the Internet, an intranet, Wide Area Network (WAN), or Local Area Network (LAN). It should be noted that many of the methods of the present invention are operable within a single computing device. 
         [0065]    A client device may be any type of processor-based platform that is connected to a network and that interacts with one or more application programs. The client devices each comprise a computer-readable medium in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and random access memory (RAM) in communication with a processor. The processor executes computer-executable program instructions stored in memory. Examples of such processors include, but are not limited to, microprocessors, ASICs, and the like. 
         [0066]    Client devices may further comprise computer-readable media in communication with the processor, said media storing program code, modules and instructions that, when executed by the processor, cause the processor to execute the program and perform the steps described herein. Computer readable media can be any available media that can be accessed by computer or computing device and includes both volatile and nonvolatile media, and removable and non-removable media. Computer-readable media may further comprise computer storage media and communication media. Computer storage media comprises media for storage of information, such as computer readable instructions, data, data structures, or program code or modules. Examples of computer-readable media include, but are not limited to, any electronic, optical, magnetic, or other storage or transmission device, a floppy disk, hard disk drive, CD-ROM, DVD, magnetic disk, memory chip, ROM, RAM, EEPROM, flash memory or other memory technology, an ASIC, a configured processor, CDROM, DVD or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium from which a computer processor can read instructions or that can store desired information. Communication media comprises media that may transmit or carry instructions to a computer, including, but not limited to, a router, private or public network, wired network, direct wired connection, wireless network, other wireless media (such as acoustic, RF, infrared, or the like) or other transmission device or channel. This may include computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism. Said transmission may be wired, wireless, or both. Combinations of any of the above should also be included within the scope of computer readable media. The instructions may comprise code from any computer-programming language, including, for example, C, C++, C#, Visual Basic, Java, and the like. 
         [0067]    Components of a general purpose client or computing device may further include a system bus that connects various system components, including the memory and processor. A system bus may be any of several types of bus structures, including, but not limited to, a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. Such architectures include, but are not limited to, Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus. 
         [0068]    Computing and client devices also may include a basic input/output system (BIOS), which contains the basic routines that help to transfer information between elements within a computer, such as during start-up. BIOS typically is stored in ROM. In contrast, RAM typically contains data or program code or modules that are accessible to or presently being operated on by processor, such as, but not limited to, the operating system, application program, and data. 
         [0069]    Client devices also may comprise a variety of other internal or external components, such as a monitor or display, a keyboard, a mouse, a trackball, a pointing device, touch pad, microphone, joystick, satellite dish, scanner, a disk drive, a CD-ROM or DVD drive, or other input or output devices. These and other devices are typically connected to the processor through a user input interface coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, serial port, game port or a universal serial bus (USB). A monitor or other type of display device is typically connected to the system bus via a video interface. In addition to the monitor, client devices may also include other peripheral output devices such as speakers and printer, which may be connected through an output peripheral interface. 
         [0070]    Client devices may operate on any operating system capable of supporting an application of the type disclosed herein. Client devices also may support a browser or browser-enabled application. Examples of client devices include, but are not limited to, personal computers, laptop computers, personal digital assistants, computer notebooks, hand-held devices, cellular phones, mobile phones, smart phones, pagers, digital tablets, Internet appliances, and other processor-based devices. Users may communicate with each other, and with other systems, networks, and devices, over the network through the respective client devices. 
         [0071]    Thus, it should be understood that the embodiments and examples described herein have been chosen and described in order to best illustrate the principles of the invention and its practical applications to thereby enable one of ordinary skill in the art to best utilize the invention in various embodiments and with various modifications as are suited for particular uses contemplated. Even though specific embodiments of this invention have been described, they are not to be taken as exhaustive. There are several variations that will be apparent to those skilled in the art.