Abstract:
A network based solution is described associated with the extraction, transfer, storage, and processing of application settings, files and other data from a subscriber&#39;s source computer-based device to a server system, and the subsequent transfer of the application settings, files, and other data from the server system onto a target computer-based device. A server downloads a software module onto the user&#39;s computer-based device. A series of pre-stored instructions commensurate with selected settings, files and data are sent from a remote server to the software module to uncover, extract, collect, and return to allocated storage space of the server the sought information. Once the application settings, files and other data are stored within the remote server system, they can be retrieved by the subscriber for purposes of restoring a crashed system, transference to a repaired or new system, converted for use on a new differing device or updated to reflect changes in software. Furthermore, the present invention allows for future compatibility of formats, programs, platforms or device configurations based on periodic updating of the instruction scripts without any modifications to the downloaded software module.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    1. Field of Invention  
           [0002]    The present invention relates generally to the field of remote acquisition/transfer and storage of computer files and settings associated with a computer-based device. More specifically, the present invention is related to a server system that facilitates the extraction of application settings, files and other data from a source computer-based device, intelligent remote storage and the subsequent transfer of the application settings, files, and other data from the server system to a target computer-based device.  
           [0003]    2. Discussion of Prior Art  
           [0004]    Computer users have long sought ways to improve the speed and ease of storing, customizing and transferring data and program files. Primary storage typically has been dedicated to a PC&#39;s hard drive or connected network storage. Recently, Internet storage of data for the purposes of backing-up files has become available. In each of these cases, a user selects files for storage and copies an instance of the file to the destination computer storage location. What the prior art has failed to provide for is a network-based method of extracting, not only specified data and program files for download and storage, but specific settings and user preferences associated with the files, such as a user&#39;s PC desktop settings, e.g. background design on the monitor (wallpaper), desktop settings or automatic start-up commands which are frequently customized.  
           [0005]    Over time, individuals will normally store certain software applications and data on their PCs. These applications are typically customized to suit the individual user&#39;s particular preferences. For instance, with regard to a word processing application, the user may specify a preferred default font, a custom page layout, customized spell-checking dictionaries, and easy access to frequently retrieved files.  
           [0006]    More recently, users have personalized their computer-based devices so that certain Internet features are stored for later use. For example, users normally customize their computer-based devices to allow easy dial-up access to their preferred Internet service provider or to save their favorite World Wide Web (“WWW”) sites, e-mail addresses, browser bookmarks, etc. At the present time, a user must endure both the time and effort to customize every new device that they purchase. No method exists to easily enable the user to perform a selective direct extraction, transference and remote storage of the “look and feel” or content of existing devices. In addition, it would be useful to carry the user&#39;s configuration from device to device without requiring the user to reconfigure each time (i.e., customizing hardware and software settings, reloading software and files, etc.).  
           [0007]    Prior art methods of file extraction are time consuming, technically demanding on the user and fail to allow conversion between differing devices, differing software, hardware, platforms, environments, communications standards, etc. Most consumer users, especially residential users, do not have the resources or the know how to undertake the transfer of the appropriate files and settings from one computer-based device-based device to another in a quick and efficient manner. In the enterprise or industrial environment, introducing new computer-based devices or moving/upgrading existing ones becomes a burden because of compatibility, loss of data, and time issues.  
           [0008]    What is needed is a server system which can provide a network-based, easy, fast and comprehensive method of extraction/transference of settings, software, and data, while considering modifications thereof based on compatibility, software programs, the selected receiving device, user selections and upgrading.  
         SUMMARY OF THE INVENTION  
         [0009]    The present invention provides for a network-based solution associated with the extraction, transfer, storage and processing of application settings, files and other data from a source computer-based device, and the subsequent transfer of the application settings, files, and other data from the server system onto a target computer-based device. The preferred embodiment server system includes an application server, a binary data server, and a database server.  
           [0010]    A user wishing to use the present system contacts the remote server system to secure storage space, payment terms and related security measures (i.e., ID and password). Once space is allocated to the new subscriber, the server system attempts to recognize the operating environment of at least a first computer-based device operated by said subscriber, the remote network server system downloads an XML based software module onto the first computer-based device. The software module will uncover this information with a series of instructions which are sent from a remote server to the software module providing a roadmap to uncover, extract, collect and return such to the allocated storage space of the connected server.  
           [0011]    Once the operating environment is discovered, instructions specific to selected application settings, files and other data on the subscriber&#39;s computer-based device are communicated to the software module to uncover, extract, collect and return such to the allocated storage space of the connected server using a network communications path. In an enterprise environment, the remote servers may be retained within the enterprise&#39;s computing environment.  
           [0012]    Once the application settings, files and other data are stored within the remote server system, they can be retrieved by the subscriber for purposes of restoring a crashed system, transference to a repaired or new system, converted for use on a new differing device or updated to reflect changes in software.  
           [0013]    Furthermore, the server system of the present invention allows for future expansion and compatibility based on periodic updating of the instruction scripts without any modifications to the software module that is resident in the source computer-based system. Thus the system is dynamically modified to work with new and different systems, platforms, formats and programs without input from the subscriber. This differs greatly from prior art systems, which require users to download updated versions of the software modules/plug-ins for proper functionality.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0014]    [0014]FIG. 1 illustrates the system associated with co-pending application entitled, “System for Transporting Application Settings, Files, and Other Data from One Computer-Based Device to Another Computer-Based Device”.  
         [0015]    [0015]FIG. 2 illustrates the various data servers of the server system of the present invention.  
         [0016]    [0016]FIG. 3 illustrates the architecture of the settings extractor and injector module (SEIM).  
         [0017]    [0017]FIG. 4 illustrates the format management system as described in the co-pending application entitled, “Virtual Access”.  
         [0018]    [0018]FIG. 5 illustrates a flowchart of the method associated with the upload scenario.  
         [0019]    [0019]FIG. 6 illustrates the system associated with the method of FIG. 5.  
         [0020]    [0020]FIG. 7 illustrates a flowchart of the method associated with the download scenario.  
         [0021]    [0021]FIG. 8 illustrates the system associated with the method of FIG. 7.  
         [0022]    [0022]FIG. 9 illustrates the steps performed when retrieving the load review directive file.  
         [0023]    [0023]FIG. 10 illustrates the schema diagram of the catalog table.  
         [0024]    [0024]FIG. 11 illustrates the steps occurring during the processing of the load review directive.  
         [0025]    [0025]FIG. 12 illustrates the processing of the load review directive on the server.  
         [0026]    [0026]FIG. 13 illustrates the UDS VanApp table.  
         [0027]    [0027]FIG. 14 illustrates the process of getting the load directive.  
         [0028]    [0028]FIG. 15 illustrates the CDS snippet table.  
         [0029]    [0029]FIG. 16 illustrates the client processing of the load directive.  
         [0030]    [0030]FIG. 17 illustrates the server processing of the load directive out file.  
         [0031]    [0031]FIG. 18 illustrates the settings table.  
         [0032]    [0032]FIG. 19 illustrates the parsing and use of CIDs to retrieve values in settings table.  
         [0033]    [0033]FIG. 20 illustrates the steps performed during processing of the unload directive file. 
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0034]    While this invention is illustrated and described in a preferred embodiment, the invention may be produced in many different configurations, forms and materials. There is depicted in the drawings, and will herein be described in detail, a preferred embodiment of the invention, with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and the associated functional specifications for its construction and is not intended to limit the invention to the embodiment illustrated. Those skilled in the art will envision many other possible variations within the scope of the present invention.  
         [0035]    Definitions are provided to help with the general understanding of server activity during transfer of application settings, files, and other data, and are not meant to limit their interpretation or use thereof. Therefore, other known definitions or equivalents may be substituted without departing from the scope of the present invention. Throughout this document, the term ‘Network’ includes all current methods of data transfer between computer-based devices, including those currently implied by the term ‘the Internet,’ to include but not limited to HTTP, FTP, SSH, TCP/IP, socket connection, XML, XMI, wireless and telephony data transfer. Furthermore, throughout the specification the term CAD (client access DLL) has been replaced with SEIM (settings extraction/injection module). These terns are interchangeable.  
         [0036]    Application Server—the user interface for the system. Components of the Application Server comprise: dynamic interface pages, hidden Dynamic Server Pages for application logic in “Network Calls.” (Described below) Dynamic Server Pages (DSP) that drive the flow of the browser GUI, creating directive files for transmission to the client, decoding directive files from a client to store in the database.  
         [0037]    Dynamic Server Page (DSP)—as is well known in the art, a specification for dynamically created pages for execution in a browser that utilizes client or server-side code, which enables network-based applications to be interactive. DSP pages are similar to CGI scripts, but the processing they perform is managed by code within the page, as opposed to code external to the page.  
         [0038]    Settings Extraction/Injection Module (SEIM)—a software module downloaded to the client computer-based device whose main flnctions are to load and unload settings from user devices into an XML file. It interacts with the registry, settings files, file system, and the browser on the user device. It also interacts with the BDS (see below) and the SMOD (see below) via network calls.  
         [0039]    BDS (Binary Data Server)—a series of dynamic server pages that interact with the server file system and the database. Its main function is to facilitate the storing and cataloging of user files. The BDS also contains a database of binary files of the system. The binary database serves the BDS and is preferably located on a separate computer-based device than the BDS; however, the binary database and binary data server are capable of being located on the same computer-based device. Binary files are stored separate from the other databases to provide efficient use of storage space and to provide greater storage scalability.  
         [0040]    SMOD (Server Module)—a, module that runs on the Application Server to process the settings data that is stored in the database.  
         [0041]    Database Server—one or more databases which store information such as a catalog of the files stored on the file system, the settings gathered from the user&#39;s computer-based device, and general information about the user. Database Server services requests from the Web Application Server, reporting systems, and system tools. Data models of the Database Server are: Accounts and user demographics: logins, passwords, names, e-mail addresses, last time system used, user profile, value of settings being integrated, etc., Application Settings Repository: known applications, settings of known applications, settings categories, application versions, conversion tables for settings, etc., Binary data catalog: name and location of user binary files on the binary data server.  
         [0042]    File System—the actual file system where user binary data is stored.  
         [0043]    Profile—environment of computer-based device including settings, data, files, etc.  
         [0044]    Van—A Van is the term used to refer to a specific ‘profile’ (see above) that a user loads with the system. A Van may not comprise the entirety of a user environment or profile, but may, at the user&#39;s discretion, be comprised of different types of content. For example, a user may create a ‘Home Van’ for personal content and settings, and a ‘Work Van’ for work-related content and settings.  
         [0045]    The co-pending application, entitled “System for Transporting Application Settings, Files, and Other Data from One Computer-Based Device to Another Computer-Based Device”, describes a system for overcoming the above difficulties. In the system of the co-pending application a software module is transferred to computer-based devices in order to determine and facilitate the appropriate data transfer. As the software module and the application settings, files and other data are transferred between the computer-based devices over network communication links external to the devices, significant advantages are obtained when the software module itself, as well as communication messages between the module and the rest of the system, are as small as possible. Some advantages (e.g., decreased overall time of transferring operating environment) would be particularly noticeable to users of the system in which low-bandwidth communication links are utilized, such as when users are connected via modems. However, even if high-bandwidth communication links are used, conservation of bandwidth is a desirable quality in all systems. FIG. 1 illustrates the system associated with this co-pending application, wherein a software module facilitates the transfer of application settings, files, and other data between a first computer-based device  100 , and a second computer-based device  106 , via an application server  108 . In the process, information regarding the application settings, files, and other data of the first computer-based device are stored in data servers  110  and  112 .  
         [0046]    [0046]FIG. 2 illustrates the various data servers associated with the server system of the above-mentioned application. Server system  200  contains content database  204  for the purpose of storing any data that is displayed to the user, e.g., GUIs, web site pages, advertisements, offers, etc., as well as any data related to applications and application settings obtained from the manufacturers of the respective software applications. This database will be updated frequently to continually contain the most current data regarding software applications and their application settings. Server system  200  also contains user database  206  for the purpose of storing data related to each individual user&#39;s computer-based device, personal profile, applications, account number, login password to the system server, etc. Processors  202  will utilize this user data to facilitate the transfer process. The user data can also be used to trigger the server system to display to the user, via the web site, advertisements and offers targeted to the user&#39;s particular profile, as discussed below in further detail. Furthermore, server system  200  also contains Binary Database  208  to store binary files, e.g., documents, e-mails, address books, etc. uploaded from first computer-based device  100 . The user selects specific data stored for download to second computer  106 . Server system  200  also contains e-commerce database  210  to store data related to on-line purchases by the user with relation to the transfer process. For instance, during the transfer process, the server system may have detected and informed the user that a software application on first computer-based device  100  has since been upgraded. In turn, the user may decide to purchase, through the server system, the most recent upgraded version of the software for the second computer-based device. All the data necessary for this purchase, e.g. credit card information, billing information, etc., can be handled and stored in this database.  
         [0047]    The co-pending application, entitled “System and Method for Transferring Settings and Files Defining an Operating Environment utilizing a Software Module”, describes a software module (SEIM) that facilitates the exchange of application settings, files, and other data. A general description of the software module is given below, but a complete discussion of the SEIM may be found in said co-pending application. The SEIM is the module of the system that runs on both the source and target device. The module performs functions including scanning the registry, interacting with the user, and communicating with an Application Server using “network calls.” The architecture of the SEM is discussed with reference to FIGS. 3. The entire SEIM component is built as a set of modules as shown in FIG. 4. The SEIM component comprises core module  302 , network calls module  304 , file transfer module  306 , and event notification module  308 . Core module  302  natively provides access to the services of the operating system and exposes the four automation methods, which may be called by scripted routines on the server side. The core module maintains functionality so that the SEIM can be accessed and executed by other applications on the computer-based device, particularly the browser. It utilizes Network Calls Module  304  and File Transfer Module  306  for all interaction with Application Server  108  and Binary Data Server  112 . Thus, Network Calls Module  304  is responsible for communicating with the Application Server  108 , and File Transfer Module  306  encapsulates the actions needed for all transfer of files between the client and servers. Furthermore, Event Notification Module  308  provides the interfaces for browsers to receive notifications from the core module  302 .  
         [0048]    The co-pending application entitled, “Virtual Access”, describes a system for processing extracted and stored settings for new or different computer-based devices. FIG. 4 illustrates this system wherein a profile is uploaded from a computer-based device  402  and stored onto the BDS  404  in an XML-based directive file. Next, another computer-based device  406  is able to access the directive file on the BDS  404 , if a user wants to configure the second computer-based device  406  to have the same environment as the first computer-based device  402 . In the event the second computer-based device does not have the same operating platform as the first device, a conversion of the directive file to a format that is compatible with the second computer-based device(s)  410 ,  412 ,  416  is necessary and is done via a format management module  408 .  
         [0049]    [0049]FIG. 5 illustrates the flowchart of the method  500  associated with a profile upload scenario. First, a communication link is established  502  between the first computer-based device  402  and the Application Server  108 . Next, if all the necessary components are found on first computer-based device  402 , a SEIM is downloaded  504  onto the first computer-based device  402 . Next, the system detects the system and data compatibility format  506 , so it knows what scripts to use. The user then selects information (comprising any of the following: application settings, files, and other data)  808  to be uploaded onto a server. Last, the SEIM then uploads an XML directive file  510  with the selected information onto the binary data server.  
         [0050]    [0050]FIG. 6 illustrates a detailed description of the system associated with the upload scenario. First, a software module (SEIM  604 ) is downloaded onto the first computer-based device  606 . This can be accomplished in a variety of ways. In one embodiment, a user interface such as a website is accessed by consumers who download a software module (SEIM  604 ) by clicking on an icon on a web page  600 . In a further embodiment, a check  602  is performed to see if the settings on the first computer-based device  606  make it compatible to download the software module (SEIM  604 ), and upon establishment of compatibility, the SEIM  604  is downloaded. In the event of incompatibility, a response page is presented to the consumer indicating what needs to be upgraded on the first computer-based device  606  for successful execution of the software module (SEIM  604 ).  
         [0051]    After SEIM  604  is successfully downloaded onto the first computer-based device, user interface  608  is generated to get input from the user. In one embodiment, user interface  908  is a set of network web pages. After reviewing the user interface  608 , users decide which files, settings, or other data need to be uploaded to a server for storage. Next, an instruction is sent from the SEIM  602  to the application server  610  regarding information on the location of the files, settings, and other data to be uploaded. The application server  610  then runs a Dynamic Server Page (DSP)  612  invoking the SMOD, which then uses an Active Data Object (ADO)  614  to query the database server  616 . Next, database server  616  returns a resultant set in ADO  614  that contains the location info to be uploaded. The SMOD then steps through the records and creates a data stream that uses XML tags. This XML format of data with tags specific to the present invention is called a directive file. The directive file is then passed on to XML parser  618  in the SEIM  604  where it is parsed and relevant files, settings, or other data are extracted. Then, the extracted data is accumulated in yet another directive file called the local directive file. Lastly, the local directive file is uploaded to binary data server  620  using a network transfer instruction.  
         [0052]    [0052]FIG. 7 illustrates the flowchart of the method  700  associated with the download scenario. First, like the upload scenario, a communication link is established  702  and after detection of all necessary components, a SEIM is downloaded  704  onto the second computer-based devices ( 410 ,  412 ,  414 ). Next, the system detects the data and system compatibility formats  706 , to determine the parameters and limitations of the format for the downloaded. Furthermore, the stored XML directive file is read by SMOD  708  and processed to extract the logic  710  associated with said XML file. Next, an XSL style sheet  712 , with a format compatible with the second computer-based device is applied and rendered  714  with respect to the end client&#39;s resource type format. Lastly, the downloaded rendered XML directive file is parsed and the new settings take effect  716 .  
         [0053]    The system associated with the method of FIG. 7 is described in FIG. 8. First, software module (SEIM)  802 , compatible with second computer-based device  1104 , is downloaded onto said device  804  via network data transfer and using a user interface such as a webpage. In one embodiment, in the event of incompatibility, the system provides the second computer-based device(s)  804  with a response page with compatibility information. Next, the SEIM  802  identifies the file and data format associated with the second computer-based device  804 . A user then requests various files, settings, and other data via interface  805  generated by the SEIM  802 . The SEIM  802  then sends an network data transfer instruction to the application server  806  requesting information regarding the location of a directive file which contains information requested by the user regarding the settings, files, and other data that need to be downloaded. The application server  806  then passes this information onto the parser  808  located in the SEIM  802 . Next, The SEIM  802  sends an network data transfer instruction to the binary database server (BDS)  810  requesting said directive file in a format compatible with computer-based device  804 . The BDS  810  extracts the corresponding directive file and uses a format management module to render the directive file in a format compatible with the second computer-based device  804 . Lastly, the BDS  810  returns the requested directive file to the second device  804 . Once the requesting computer-based device  804  receives the directive file (containing the application settings, files, and other data), the software module (SEIM)  802  parses the directive file (via the XML parser  808 ), installs and updates necessary settings, files, and other data in their respective locations such thatmaking the receiving computer-based device&#39;s operating environment similar to that of the first computer-based device. In a further embodiment, an option is provided in the SEIM  802  such that users can revert back to the operating environment previously held by the receiving computer-based device if they are not satisfied with the newly installed profile.  
         [0054]    Thus, from a system&#39;s perspective, the server system of the present invention obtains settings from a computer-based device in two stages: Load Review stage and Load stage. The Load Review stage gathers information about the user&#39;s computer-based device. The Load stage is responsible for moving the user&#39;s settings and files to the server.  
         [0055]    Generally, after the information is gathered on the user&#39;s computer-based device, a scripted routine invokes a load method on the SEIM. The SEIM starts by making a network call to an Application Server to ask it to provide instructions on how to collect the settings that the user has chosen. The network call causes the Application Server  108  to run a Dynamic Server Page (DSP) that invokes the SMOD, using an Active Data Object (ADO) to run a query on a database located at the Database Server  110 . The Database Server returns a result set that contains the information about how to collect each setting (for example, a record in the result set might say that the Outlook-2000® personal address book is identified by their registry key HKCU\Software\Microsoft\Outlook\PAB). The SMOD receives the entire result set from the Database Server  110  in the Active Data Object. The SMOD steps through each record in the ADO and converts it into a data stream that uses XML tags to delineate the fields in the records. This XML format of data with the website specific tags is called a directive file. The directive file is returned to the SEIM as a response from the network call. The SEIM uses its XML Parser to decode the instructions from the application server. It then executes the instructions in the Directive File (For example, it would fetch the value in HKCU\Software\Microsoft\Outlook \PAB). The SEIM accumulates the settings data into a local directive file as it runs each instruction. When done, the SEIM makes a network call to upload the directive file to the Binary Data Server  112 . The SEIM then makes a network call to tell the server  108  that the settings have been uploaded.  
         [0056]    Specifically, as explained following, this overall process is performed in six parts, three parts during the Load Review stage and three parts during the Load stage.  
         [0057]    Load Review  
         [0058]    After the user has logged on to the system, he/she will be asked to wait while the system determines the applications that are installed on the client . The system interaction for this stage comprises 3 parts: Getting the Load Review directive file, Client processing of the Load Review directive file, and Server processing of the load review directive file.  
         [0059]    Getting the Load Review Directive File  
         [0060]    The sequence diagram of FIG. 9 illustrates the steps performed when retrieving the load review directive file. After the user has chosen to load transfer application settings, etc., the Application Server  900  downloads the SEIM  902  (if not already present) and makes the LoadReview call  912  to it. The LoadReview call causes the SEIM  902  to follow the automated steps of retrieving the load review directive. The SEIM  902  has an automated method for determining the operating system of the computer-based device, which it first performs, then the SEIM  902  performs a call to the SMOD  906  to get the load review directive file  914 .  
         [0061]    The SEIM  902  makes this call to the SMOD  906  through a dynamic server page. The SMOD  906  retrieves a unique ID  918  of the review directive file. In particular, this information is retrieved from the content database. SMOD  906  then returns the uniqueID  920  of the review directive file back to the SEIM  902 .  
         [0062]    Preferably, there is another DSP method of the SMOD  906  that will build the review directives called BuildReviewDirectives. This generates the review directives from the snippets stored in the database, puts the files in the BDS file system, and puts the appropriate rows in the Catalog and DirectiveLocation tables. BuildReviewDirectives allows administrators of the system to update the review directive files after support for more applications has been added into the content database. Thus, the present invention allows unlimited recognition of future formats, platforms, devices, etc., through updating of directive files without modification of the SEIM.  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             DYNAMIC UPDATING OF SCRIPTS                   Example of a DirectiveFile for Windows Millennium Edition with Internet       Explorer Before WinZip Data is Added            &lt;DirectiveFileVersion&gt;                1.0                  -  &lt;ReviewDirective&gt;                  -  &lt;PID&gt;                230           &lt;Description&gt;Windows Millennium Edition&lt;/Description&gt;                  -  &lt;and&gt;                &lt;KeyExists&gt;HKLM\SOFTWARE\Microsoft\Windows&lt;/Key           Exists&gt;                  -  &lt;or&gt;                  -  &lt;ValueExistsAndMatches&gt;                HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion           \ProductName           &lt;Value&gt;Microsoft Windows ME&lt;/Value&gt;                &lt;/ValueExistsAndMatches&gt;                  -  &lt;ValueExistsAndMatches&gt;                HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion           \ProductName           &lt;Value&gt;Microsoft Windows Millennium                Edition&lt;/Value&gt;                &lt;/ValueExistsAndMatches&gt;                &lt;/or&gt;                &lt;/and&gt;                  -  &lt;FileSize&gt;                &lt;StoreFileAtValue&gt;HKCU\Control                Panel\Desktop\Wallpaper&lt;/StoreFileAtValue&gt;                &lt;/FileSize&gt;                &lt;/PID&gt;                  -  &lt;PID&gt;                6           &lt;Description&gt;IE 4/5/5.5&lt;/Description&gt;                  -  &lt;and&gt;                &lt;KeyExists&gt;HKLM\SOFTWARE\Microsoft\Internet                Explorer&lt;/KeyExists&gt;                  -  &lt;or&gt;                &lt;KeyExists&gt;HKLM\SOFTWARE\Microsoft\IE4           &lt;/KeyExists&gt;           &lt;KeyExists&gt;HKCU\Software\Microsoft\Windows\           CurrentVersion\Internet Settings\5.0&lt;/KeyExists&gt;                &lt;/or&gt;                &lt;/and&gt;                  -  &lt;FileSize&gt;                &lt;StoreTreeAtValue&gt;HKCU\Software\Microsoft\Windows\           CurrentVersion\Explorer\Shell           Folders\Favorites&lt;/StoreTreeAtValue&gt;                &lt;StoreTreeAtValue&gt;HKCU\Software\Microsoft\Internet                Explorer\Desktop\General&lt;/StoreTreeAtValue&gt;                &lt;StoreFileAtValue&gt;HKCU\Software\Microsoft\Internet                Explorer\Desktop\General\Wallpaper&lt;/StoreFileAtValue&gt;                &lt;StoreFileAtValue&gt;HKCU\Software\Microsoft\Internet                Explorer\Desktop\General\BackupWallpaper&lt;/StoreFileAt           Value&gt;                &lt;/FileSize&gt;                &lt;/PID&gt;                &lt;/ReviewDirective&gt;                &lt;/DirectiveFileVersion&gt;            Example of a DirectiveFile for Windows Millennium Edition with Internet       Explorer and WinZip Support After Data is Added            &lt;DirectiveFileVersion&gt;                1.0                  -  &lt;ReviewDirective&gt;                  -  &lt;PID&gt;                230           &lt;Description&gt;Windows Millennium Edition&lt;/Description&gt;                  -  &lt;and&gt;                &lt;KeyExists&gt;HKLM\SOFTWARE\Microsoft\Windows&lt;/Key           Exists&gt;                  -  &lt;or&gt;                  -  &lt;ValueExistsAndMatches&gt;                HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\           ProductName           &lt;Value&gt;Microsoft Windows ME&lt;/Value&gt;                &lt;/ValueExistsAndMatches&gt;                  -  &lt;ValueExistsAndMatches&gt;                HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\           ProductName           &lt;Value&gt;Microsoft Windows Millennium                Edition&lt;/Value&gt;                &lt;/ValueExistsAndMatches&gt;                &lt;/or&gt;                &lt;/and&gt;                  -  &lt;FileSize&gt;                &lt;StoreFileAtValue&gt;HKCU\Control                Panel\Desktop\Wallpaper&lt;/StoreFileAtValue&gt;                &lt;/FileSize&gt;                &lt;/PID&gt;                  -  &lt;PID&gt;                6           &lt;Description&gt;IE 4/5/5.5&lt;/Description&gt;                  -  &lt;and&gt;                &lt;KeyExists&gt;HKLM\SOFTWARE\Microsoft\Internet                Explorer&lt;/KeyExists&gt;                  -  &lt;or&gt;                &lt;KeyExists&gt;HKLM\SOFTWARE\Microsoft\IE4&lt;/           KeyExists&gt;           &lt;KeyExists&gt;HKCU\Software\Microsoft\Windows\           CurrentVersion\Internet Settings\5.0&lt;/KeyExists&gt;                &lt;/or&gt;                &lt;/and&gt;                  -  &lt;FileSize&gt;                &lt;StoreTreeAtValue&gt;HKCU\Software\Microsoft\Windows\           CurrentVersion\Explorer\Shell           Folders\Favorites&lt;/StoreTreeAtValue&gt;                &lt;StoreTreeAtValue&gt;HKCU\Software\Microsoft\Internet                Explorer\Desktop\General&lt;/StoreTreeAtValue&gt;                &lt;StoreFileAtValue&gt;HKCU\Software\Microsoft\Internet                Explorer\Desktop\General\Wallpaper&lt;/StoreFileAtValue&gt;                &lt;StoreFileAtValue&gt;HKCU\Software\Microsoft\Internet                Explorer\Desktop\General\BackupWallpaper&lt;/StoreFileAt           Value&gt;                &lt;/FileSize&gt;                &lt;/PID&gt;                &lt;PID&gt;                34           &lt;Description&gt;WinZip&lt;/Description&gt;           &lt;KeyExists&gt;HKCU\Software\Nico Mak                Computing\WinZip\WinZip&lt;/KeyExists&gt;                &lt;/PID&gt;                &lt;/ReviewDirective&gt;            &lt;/DirectiveFileVersion&gt;                  
 
         [0063]    The load review directive file is stored on the BDS file system  910 . In order to retrieve the directive file, SEIM  902  uses the HTTP protocol to transfer the file from the BDS file system  910  to the local computer-based device. In order to retrieve the directive file, SEIM  902  must know the actual location of the review directive file on BDS file system  910 . The uniqueId of the review directive file and an active server page of BDS  904  is utilized to retrieve this information. The SEIM  902  makes a BeginTransfer call passing the uniqueID to BDS  922 . BDS then returns the location  924  of the load review directive file to the SEIM  902 . An exemplary BeginTransfer call  922  for a review directive looks like:  
         /actions/bds/BeginTransfer.asp?sSessionlD=133794890&amp;sMode=GET&amp;nUniquelD=70302 
         [0064]    An exemplary response  924  from BDS  904  is:  
                                   &lt;HTML&gt;       &lt;HEAD&gt;       &lt;TITLE&gt;&lt;/TITLE&gt;       &lt;/HEAD&gt;       &lt;BODY&gt;       &lt;pid&gt;0&lt;/pid&gt;       &lt;pathname&gt;ReviewDirective.xml&lt;/pathname&gt;       &lt;flags&gt;O&lt;/flags&gt;       &lt;creationhi&gt;0&lt;/creationhi&gt;       &lt;creationlo&gt;0&lt;/creationlo&gt;       &lt;Iastaccesshi&gt;0&lt;/Iastaccesshi&gt;       &lt;Iastaccesslo&gt;0&lt;/Iastaccesslo&gt;       &lt;Iastwritehi&gt;0&lt;/Iastwritehi&gt;       &lt;Iastwritelo&gt;0&lt;/Iastwritelo&gt;       &lt;filesizehi&gt;0&lt;/filesizehi&gt;       &lt;filesizelo&gt;0&lt;/filesizelo&gt;       &lt;uri&gt;/actions/bds/data/{00000000-0000-OODO-0000-000000000000}-halsexmvfthpkwz&lt;/uri&gt;       &lt;sResult&gt;Success&lt;/sResult&gt;       &lt;sInfo&gt;File exists at /actions/bds/data/{00000000-0000-0000-0000-000000000000}-       halsexmvfthpkwz.&lt;/sInfo&gt;       &lt;/BODY&gt;       &lt;/HTML&gt;                  
 
         [0065]    The SEIM  902  parses the response to get the location. In the above example, the response indicates to the SEIN  902  that the load review directive file is located on BDS file system  910  at “/actions/bds/data/{00000000-0000-0000-0000-000000000000}-halsexmvfthpkwz.” 
         [0066]    A discussion of the BDS  904  and associated file system  910  will aid in the understanding of the above steps and associated examples. The binary data files for a computer-based device are stored in the file system of the APPLICATION SERVER  900 . The part of the APPLICATION SERVER file system which these binary data files are stored is considered BDS file system  910 . By way of example, these data files are located in the “\actions\bds\data” directory. The naming convention of the files is the ID number for the file (in GUID form), which is followed by a “-”, followed by a randomly generated text string (as illustrated in the location contained in &lt;URI&gt;tag above). However, in the system, files are referred to by a number called a uniqueId. UniqueIDs are mapped to file locations and file attributes by a table in the binary database called the catalog table. This keeps track of information gathered about the file from the user&#39;s computer-based device. It includes the file system attributes (nFlagsAndAttributes, etc.), where the file belongs on the user&#39;s computer-based device (sFullPath), the product that a file is associated with (nPID), and the location where it can be found on the BDS (sURI). A schema diagram of the catalog table is illustrated in FIG. 10.  
         [0067]    Since the Review Directives are also stored in the BDS, there is also a corresponding row in the catalog table for each of them. The only part of the catalog table that is of concern for review directives is the nUniqueID and sURI columns in the table. There is another table in the content database, DirectiveLocation, that SMOD  906  uses to determine the uniqueID for the review directive that has been requested.  
         [0068]    Having obtained the location for the load review directive file, the SEIM  902  performs an network call such as an HTTP GET transfer  926 , which returns the contents of the review directive file  928 .  
         [0069]    Processing the Load Review Directive on the Client  
         [0070]    Having retrieved the load review directive file, the SEIM  902  follows the instructions of this file to determine the applications that are installed on the computer-based device. Details for this process are illustrated in FIG. 11. Numerals indicating the various components of the system remain the same as those utilized with FIG. 9.  
         [0071]    The following is an example (shortened) review directive file:  
                                   &lt;DirectiveFileVersion&gt;1.0       &lt;ReviewDirective&gt;       &lt;PID&gt;26       &lt;Description&gt;IE 4.0&lt;/Description&gt;       &lt;and&gt;       &lt;KeyExists&gt;HKCU\Software\Microsoft\lnternet       Explorer&lt;/KeyExists&gt;       &lt;ValueDoesNotExist&gt;HKCU\Software\Microsofi\Windows\CurrentVersion\lnternet       Settings\S.D.\Cache\Signature&lt;/ValueDoesNotExist&gt;       &lt;/and&gt;       &lt;/PID&gt;       &lt;/ReviewDirective&gt;       &lt;/DirectiveFileVersion&gt;                  
 
         [0072]    The XML tags represent the commands or the instructions that tell the SEIM  902  how to determine if an application exists. The SEIM  902  does the evaluation as the tag is encountered in the parsing process. For example, the above review directive file would be used to determine if IE 4 is on the user&#39;s computer-based device. As described above, the PID is the Product ID. Each application that is supported has its own PID. Different versions of the same application have different PIDs. The XML instructs the SEIM  902  that if the “HKCU\Software\Microsoft\Internet Explorer” key exists in the registry and there is not a value for the key “HKCMSoftware\Microsoft\Windows\CurrentVersion\Intemet Settings\5.0\Cache\Signature”, then the user&#39;s computer-based device has IE 4 installed on it. &lt;KeyExists&gt;and &lt;ValueDoesNotExist&gt;are examples of tag instructions that the SEIM  902  knows how to process. To process these instructions, the SEIM  902  looks in the registry, and in some cases the file system, to determine if applications exist on the computer-based device. As it is doing this parsing process, it is also creating the XML results, the ReviewDirectiveOut file. Following is an example of the results from this search, which indicates that IE 4.0 does not exist on the user computer-based device.  
         [0073]    &lt;DirectiveFile Version&gt;1.0  
         [0074]    &lt;ReviewDirectiveOut&gt; 
         [0075]    &lt;PID&gt;26  
         [0076]    &lt;Description&gt;IE 4.0&lt;/Description&gt; 
         [0077]    &lt;Value&gt;FALSE&lt;/Value&gt; 
         [0078]    &lt;/PID&gt; 
         [0079]    &lt;/ReviewDirectiveout&gt; 
         [0080]    &lt;/DirectiveFileVersion&gt; 
         [0081]    As shown in FIG. 11, once the SEIM  902  has parsed and processed the load review directive file, the created ReviewDirectiveOut file needs to be put on the server. To do this, the SEIM  902  performs a BeginTransfer call to BDS  904 , to notify the BDS  904  that a file needs to be put in file system  910 . Ultimately, BDS  904  will return the location of where to put the file. The following is the query string that is sent.  
         [0082]    \actions\bds\BeginTransfer.asp?sVanID.(DOAB4C48-ISC3-IID4-9DB9-0000C0540132)&amp;  
         [0083]    sSessionID-133794890  
         [0084]    nPID=−1&amp;  
         [0085]    sMode=PUTQ  
         [0086]    FullPath.C: \Programt2OFiles\PCMovingVan\ReviewDirective.Out.xml&amp;  
         [0087]    nFlagsAndAttributes=0&amp;  
         [0088]    nCreationTimeLow=0&amp;  
         [0089]    nCreationTimeHigh=0&amp;  
         [0090]    nLastAccessTimeLow=0&amp; SVC- 3003555   
         [0091]    nLastAccessTimeHigh=0&amp;  
         [0092]    nLastWriteTimeLow=0&amp;  
         [0093]    nLastWriteTimeHigh=0&amp;  
         [0094]    nSizeLow-O&amp;  
         [0095]    nSizeHigh=0  
         [0096]    This causes BDS  904  to create a zero-length file  1102  on file system  910  that the SEIM  902  can transfer the ReviewDirectiveOut file to. The zero-length file is created to ensure that no other file on the file system has the same name. Then BDS  904  adds a row to the catalog table in the database  1104  with the file attribute and location information. The PID in this case is −1, as review files are not associated with a particular product. Also, the attribute information is blank, as this file will not be transferred back to a computer-based device. The call returns with a result similar to the following, which tells the SEIM  902  where to transfer the file.  
         [0097]    &lt;HTML&gt; 
         [0098]    &lt;HEAD&gt; 
         [0099]    &lt;TITLE&gt;&lt;/TITLE&gt; 
         [0100]    &lt;/HEAD&gt; 
         [0101]    &lt;BODY&gt; 
         [0102]    &lt;fileid&gt;79465&lt;/fileid&gt; 
         [0103]    &lt;Uri&gt;/actions/bds/data/@DAB4C48-ISC3-IID4-9DB9-0000CO540132)-olkfrrxabccfmc&lt;/ uri&gt; 
         [0104]    &lt;sResult&gt;Success&lt;/sResultlt&gt; 
         [0105]    &lt;sInfo&gt;File /actions/bds/data/(DOAB4C48-IBC3-IID4-9DB9-0000CO540132)-olkfkrrxabccfmc created.&lt;/sInfo&gt; 
         [0106]    &lt;/BODY&gt; 
         [0107]    &lt;/HTML&gt; 
         [0108]    After obtaining this response, the SEIM  902  performs a network call such as an HTTP PUT, transferring the ReviewDirectiveOut file to the BDS to the /actions/bds/data/{DOAB4C48-1BC3-1 1D4-9DB 9 -0000C 0 540132}-olkfkrrxabccfmc data file  1106 .  
         [0109]    Processing the Load Review Directive on the Server  
         [0110]    Once the SEIM  902  has determined the applications that are installed on the client&#39;s computer-based device, and put the results on file system  910 , the ReviewDirectiveOut file is processed. This process is illustrated in FIG. 12. As before, numerals designating various components of the system remain the same as those utilized with FIG. 9.  
         [0111]    The SEIM  902  notifies SMOD  906  that there is a directive file ready to be parsed by making the PutDirecitve call  1200 . A typical call is as follows:  
         /actions/smod/PutDirective.asp?sVanID-(DOAB4C48-IBC3-IID4-9DB9-0000COS40132) &amp;sSessionID=133 794890&amp;eType−O&amp;sOS=WinNT&amp;nUniqueID.7946S 
         [0112]    SMOD  906 , in turn, resolves the uniqueId to a file location  1202  on file system  910  via BDS  904  and gets the file through a network call such as an HTTP GET  1204 . SMOD  906  then parses the file  1206  and stores the applications that were found in the database in the VanApp table  1208 . FIG. 13 illustrates the schema of VanApp table.  
         [0113]    For every application that is found on the user computer-based device, one row is put into the VanApp table. This information is used later when the Load Directive file is built. The Type determines whether the application was found on the old computer-based device (0) or the new computer-based device (1). The IncludeInLoad and IncludeInUnload columns are modified based on the results of the selections made by the user in an expert mode. These columns indicate which application settings and files will actually be transferred based upon the choices made by the user. Once this is complete, PutDirective returns back  1210  to the SEIM  902 , which returns back  1212  to the APPLICATION SERVER  900  to signal the end of the LoadReview call. The following is an example of a PutDirective reply:  
         [0114]    &lt;HTML&gt; 
         [0115]    &lt;HEAD&gt; 
         [0116]    &lt;META NAME-“GENERATOR” Content=,“Microsoft Developer Studio”&gt; 
         [0117]    &lt;META HTTP-EQUIV-“Content-Type” content=“text/html; charset=iso-8859-111”&gt; 
         [0118]    &lt;TITLE&gt;PutDirective&lt;/TITLE&gt; 
         [0119]    &lt;/HEAD&gt; 
         [0120]    &lt;BODY&gt; 
         [0121]    &lt;sResult&gt;Success&lt;/sResult&gt; 
         [0122]    &lt;/BODY&gt; 
         [0123]    &lt;/HTML&gt; 
         [0124]    The APPLICATION SERVER  900  then goes to the database and looks in the VanApp table so as to display to the user the applications that were found on his/her computer-based device  1214  by redirecting to an active server page.  
         [0125]    Load  
         [0126]    Once the applications, which are installed on the user&#39;s computer-based device, are determined, and in an expert mode, particular applications and files are chosen, transfer of application settings, files and other data is performed. This comprises three parts, getting the load directive file, processing the load directive file on the client, and processing the LoadDirectiveOut file on the server.  
         [0127]    Getting the Load Directive File  
         [0128]    Like in Load Review, the process begins with getting the directive file from the server. This is illustrated in FIG. 14.  
         [0129]    When the user indicates they want to transfer their settings, such as by clicking a button marked “load” on the web page, a JavaScript routine on the APPLICATION SERVER  900  calls a method  1400  on the SEIM  902 , in this case, i.e., Load(). The SEIM  902  then calls GetDirective  1402  on SMOD  906 . The goal of GetDirective is still to return the uniqueID of the directive file, but for load directives, SMOD  906  generates the load directive based on the applications that the user has on their computer-based device and what they have chosen to load  1404 .  
         [0130]    To build the file, SMOD  906  reads the VanApp table in database  908  and selects all of the PIDS of the applications that the user has on the computer-based device (in expert mode, only including those that were chosen to be loaded. These are the applications that have the IncludeInLoad flag set. After getting this list, the SMOD looks in a CDS snippet table to determine the XML load snippets that should be included in the Load directive file. FIG. 15 illustrates the schema of the CDS snippet table.  
         [0131]    The snippet table holds XML directive snippets for review and load directives. Load directive snippets have a Load Type ( 41 ), and review directive snippets have a type of Review ( 38 ). Review Directive snippets are used to build the pre-built review directive files when BuildReviewDirectives is utilized by administrators of the system. The following is an example snippet for a load directive:  
         [0132]    &lt;PID&gt; 
         [0133]    30  
         [0134]    &lt;Description&gt; 
         [0135]    Excel 97  
         [0136]    &lt;StoreKeyValue&gt; 
         [0137]    HKCU\PSoftware\Microsoft\Office\B. o\Excel\microsoft Excel\s CmdBarData  
         [0138]    &lt;CID&gt;36&lt;/CID&gt; 
         [0139]    &lt;/StoreKeyValue&gt; 
         [0140]    &lt;/Description&gt;&lt;/PID&gt; 
         [0141]    SMOD  906  gathers this snippet info for all selected applications and creates a directive file including all snippets plus some additional tags to denote the type and the version of the directive file.  
         [0142]    When a user has manually selected a collection of files on their computer-based device for transfer, a special snippet, the MoveFiles snippet, is placed in the directive file as it is being created, and after it has been created, the directive it is then parsed and the MoveFiles snippet is replaced with the list of files that the user selected during the pre-load phase.  
         [0143]    Once the directive has been created, SMOD  906  then makes the BeginTransfer call  1406  to BDS  904  to get the location  1408  of where to write the file. As in the case of LoadReview, this call to BDS  904  with the PUT flag set causes a row to be created in the catalog table of BDS  904  that cross-references the location with the file&#39;s uniqueId. In addition, the zero-length file gets created in the file system. Then, SMOD  906  writes the file  1410  directly to file system  910 , i.e. there is no HTTP transfer taking place. SMOD  906  then returns the uniqueID of the file  1412  back to CAD  902 .  
         [0144]    As in the case of Load Review, the SEIM calls BeginTransfer  1414  on BDS  904  passing it in the uniqueID. This call returns with the location of the file to get  1416 . The SEIM  902  in turn, performs a network call such as an HTTP GET of the file  1418 .  
         [0145]    Processing the Load Directive file on the Client  
         [0146]    Once the SEIM  902  has the list of instructions on how to gather settings on the client&#39;s computer-based device, it begins storing the settings. Similar to the load review stage, the SEIM  902  creates a LoadDirectiveOut file to tell the server what settings to store.  
         [0147]    The SEIM  902  parses the load directive file, which includes instructions on how to gather settings, files, and other data. As it parses the instructions, the SEIM  902  gathers settings from the computer-based device. Successive network calls such as BeginTransfer/HTTP PUT calls, as will be explained below in conjunction with FIG. 16, are performed to store files on file system  910 . UniqueIDs for files and settings are written to the LoadDirectiveOut file, as further detailed below.  
         [0148]    Settings are basically divided into user files and registry settings. An exemplary part of a Load Directive to store registry settings looks like:  
         [0149]    &lt;StoreKey Value&gt;HKCU\Control Panel Desktop\WallpaperStyle  
         [0150]    &lt;CID&gt;14&lt;/CID&gt; 
         [0151]    &lt;/StoreKeyValue&gt; 
         [0152]    This instructs the SEIM  902  to store the value found for the registry key “HKCU\Control Panel\Desktop\WallpaperStyle.” The SEIM  902  retrieves this value and writes it to the LoadDirectiveOut file snippet as follows:  
         [0153]    &lt;StoreKey Value&gt;HKCU\Control Panel\Desktop\WallpaperStyle  
         [0154]    &lt;CID&gt;14&lt;/CID&gt; 
         [0155]    &lt;Value&gt;2&lt;/Value&gt; 
         [0156]    &lt;Value&gt;REG_SZ&lt;/Value&gt; 
         [0157]    &lt;/StoreKeyValue&gt; 
         [0158]    The CID tag directs SMOD  906  as to what command in the command table this snippet corresponds to. Each CID is mapped to a unique command in the command table. As in example above, only the command “&lt;StoreKeyValue&gt;HKCU\Control Panel\Desktop\WallpaperStyle” has a CID of 14. The CID is used, as explained below, to speed processing during the generation of the unload directive file. The registry setting is represented as two pieces of data, the registry value and the type of registry data that it is. REG_SZ indicates that the value is a string (The other types are REG_DWORD and REG_BINARY). Both need to be saved to put the settings on the new computer-based device.  
         [0159]    In some cases, the SEIM  902  needs to store file information on the server as in the following snippet:  
         [0160]    &lt;StoreFileAtValue&gt;HKCU\Software Microsoft\WAB\WAB4\Wab File Name\ 
         [0161]    &lt;CID&gt;20&lt;/CID&gt; 
         [0162]    &lt;/StoreFileAtValue&gt; 
         [0163]    The StoreFileAtValue tags tells the SEIM  902  to look in the registry for the key, “HKCU\Software\Microsoft\WAB\WAB4\Wab File Name\”, get the value of the fully qualified path of the file stored at that location and store that file on the server. The load directive out snippet generated for that command is:  
         [0164]    &lt;StoreFileAt Value&gt;HKCU\Software Microsoft\WAB\WAB4\Wab File Name\ 
         [0165]    &lt;CID&gt;20&lt;/CID&gt; 
         [0166]    &lt;Value&gt;80596&lt;/Value&gt; 
         [0167]    &lt;/StoreFileAtValue&gt; 
         [0168]    The 80596 is the uniqueID of the file that the SEIM stored on the server. The process to put the file and store the uniqueID is shown in FIG. 16.  
         [0169]    Once the SEIM  902  gets the file location from the registry, it gathers the attributes from the file and passes this into BeginTransfer  1600  as illustrated by the following:  
         [0170]    /actions/bds/Begin Transfer.asp?s VanlD=(DOAB4C61}-IBC3-1:LD4-9DB9-0000CO540132)&amp;:  
         [0171]    sSessionID=19443788986  
         [0172]    nPID=13&amp;  
         [0173]    sMode=PUT&amp;  
         [0174]    sFullPath=C:\WINNT\ProfileS\Taylor\Application W20Data\Microsoft\Address%20Book\Tay  
         [0175]    lor.wab&amp;  
         [0176]    nFlagsAndAttributes=32&amp;  
         [0177]    nCreationTimeLow=947677846&amp;  
         [0178]    nCreationTimeHigh=29274947&amp;  
         [0179]    nLastAccessTimeLow−1505512040&amp;  
         [0180]    nLastAccessTimeHigh=29343558&amp;  
         [0181]    nLastWriteTimeLow=451749727&amp;  
         [0182]    nLastWriteTimeHigh=29342591&amp;  
         [0183]    nSizeLow=117848&amp;  
         [0184]    nSizeHigh=0  
         [0185]    BeginTransfer then creates the Catalog table entry  1614  as in Load Review, but this time the PID and file attributes are passed in and have meaning. The BDS also makes the zero-length file  1612  on file system  910 .  
         [0186]    The BeginTransfer, as in the other examples, returns the location  1616  of where to put the file and the uniqueId. An example of the return message is:  
         [0187]    &lt;HTML&gt; 
         [0188]    &lt;HEAD&gt; 
         [0189]    &lt;TITLE&gt;&lt;/TITLE&gt; 
         [0190]    &lt;/HEAD&gt; 
         [0191]    &lt;BODY&gt; 
         [0192]    &lt;fileid&gt;80596&lt;/fileid&gt; 
         [0193]    &lt;Uri&gt;/actions//bds/data/(DOAB4C6D-IBC3-IID4-9DB9-OOOOCOS40132)-nfiuawtmtldkifr&lt;/ur  
         [0194]    i&gt; 
         [0195]    &lt;sResult&gt;Success&lt;/sResult&gt; 
         [0196]    &lt;sInfo&gt;File /actions/bds/data/(DOAB4C60-IBC3-IID4-9DB9-0000CO5401321-nfiuswtmtldkifr  
         [0197]    created.&lt;/sInfo&gt; 
         [0198]    &lt;/BODY&gt; 
         [0199]    &lt;/HTML&gt; 
         [0200]    After obtaining the location from the return message, the SEIM  902  performs a network call such as an HTTP PUT to transfer the file  1618  to file system  910  and stores the uniqueId for the file in the load directive out file as shown in the &lt;StoreFileAtValue&gt;snippet above.  
         [0201]    For groups of files, as in the case of storing a user&#39;s favorites, the SEIM  902  gathers all of the files and compresses them. The attribute and local path information for the files are stored in the compressed file. The SEIM then follows the process in FIG. 19 to transfer the compressed file on file system  910 . As in the single file case, the uniqueID of the compressed file is stored in the LoadDirectiveOut file.  
         [0202]    Processing the Load Directive Out File on the Server  
         [0203]    Once all of the settings have been gathered in the Load Directive Out file, the SEIM will put the directive on the server. The process is outlined in FIG. 17.  
         [0204]    The SEIM  902  places the LoadDirectiveOut file on file system  910 , utilizing network calls such as the BeginTransfer call and HTTP PUT, in the same manner as it placed the ReviewDirectiveOut file before. This is illustrated in FIG. 20 at  2000  and  2002 .  
         [0205]    After placing the LoadDirectiveOut file on file system  910 , the SEIM  902  notifies SMOD  906  that the new directive file is on file system  910  through the PutDirective active server page call  1704 , SMOD  906  then retrieves the LoadDirectiveOut file, by performing a network call such as an HTTP GET  1706 , from file system  910 .  
         [0206]    SMOD  906  parses  1708  through the file to store the setting information into the database  1710 . This information is stored in the UDS in the Setting table. FIG. 18 illustrates the schema of the setting table.  
         [0207]    Each setting will have its own row in the Setting table. The VanID, CID, and Data are mapped directly from the directive file (the VanID is passed in the call to PutDirective). The SequenceNumber is the order that the Settings were found in the file within a CID. This is in case the settings need to be unloaded in a particular order.  
         [0208]    Once all of the settings have been stored in the database, the PutDirective call will return success  1712  to the SEIM  902 . The SEIM  902  then returns from the Load  1714 , i.e., returns back to the application server  900 . The application server  900  then informs the user via a web page that all of the settings have been moved, and they can go to their new computer-based device to unload the settings.  
         [0209]    Likewise, the process for transferring settings to a computer-based device takes place in two stages. The Unload Review stage gathers information about the user&#39;s new computer-based device. The Unload stage is responsible for moving settings from the server to the new or target computer-based device.  
         [0210]    For transferring settings to the second computer-based device, in one embodiment, the user interacts with some additional web pages and eventually be told to visit the website from their new computer-based device. On the new device, after passing through the same general auto install process just described above, they would get to the point where the could click an “UnLoad” button. This would trigger the JavaScript which invokes an “UnLoad Settings” method on the SEIM (now located on the new computer-based device). The client would make a network call such as a HTTP call to request where it should find the directive file that holds the user&#39;s settings. It would then make a network call such as an HTTP GET call to retrieve the appropriate corresponding directive file to the new computer. Once downloaded, it would decode the directive file and follow the instructions to install the user&#39;s settings. In most cases, when done, the user will re-boot and their settings will then take affect. An option to undo the load is also given.  
         [0211]    Specifically, as explained following, this overall process is performed in five parts, three parts during the unload review stage and two parts during the unload stage.  
         [0212]    Unload Review  
         [0213]    The unload review process is essentially the same as the load review process. As such, only a brief discussion of the unload process will be given with relation to FIGS. 12, 14 and  15 . Like the load review process, the system interaction for this stage comprises  3  parts: Getting the unload review directive file, Client processing of the unload review directive file, and Server processing of the unload review directive file.  
         [0214]    One difference occurs when the SMOD is processing the unload review directive out file. When the rows for the applications that were found are put in the VanApp table, the TypeID is set to a 1 instead of a 0 as in the case for Load Review.  
         [0215]    Getting the Unload Review Directive File  
         [0216]    The steps of the getting the unload review directive file part is the same as that of the corresponding getting the load review directive file part of the load review stage, except, in the cases where transference of settings are between an old computer-based device and a new computer-based device, it is possible that the user may be unloading settings on a computer-based device with a different operating system, hardware or other system parameters. Therefore, the review directive file that the SEIM gets from the server may be different and therefore looking for different applications.  
         [0217]    During the discussion, the unload review directive file is distinguished in this process from the load review directive, however, it should be understood that, in the preferred embodiment, only one set of review directives is maintained at the server side. The use of the term unload or load review directive is used to distinguish between the phases in which a review directive is used and the possibility that a different review directive is used in each phase as the operating systems of different computer-based devices may differ. For retrieval of the unload review directive file, the application server  900  downloads the SEIM  902  (if not already present) and makes the UnLoadReview call  912  to it. The UnLoadReview call causes the SEIM  902  to follow the automated steps of retrieving the unload review directive. First, the SEIM  902  performs a GetDirective call to SMOD  906  to get the unload review directive file  914 .  
         [0218]    SMOD  906  retrieves a uniqueid  916 ,  918  of the review directive built for the particular operating system of the new computer-based device from database  908 . In particular, this information is retrieved from the content database. SMOD  906  then returns the uniqueld  920  of the review directive file back to the SEIM  902 .  
         [0219]    The SEIM  902  makes a BeginTransfer call passing the uniqueID to BDS  122 . BDS then returns the location  924  of the unload review directive file to the SEIM  902 .  
         [0220]    Having obtained the location for the unload review directive file, the SEIM  902  performs a network call such as an HTTP GET transfer  926  which returns the contents of the review directive file  928 .  
         [0221]    Processing the Unload Review Directive on the Client  
         [0222]    Having retrieved the unload review directive file, the SEIM  902  follows the instructions of this file to determine the applications that are installed on the computer-based device.  
         [0223]    As shown in FIG. 14, once the SEIM  902  has parsed and processed the unload review directive file, the created ReviewDirectiveOut file needs to be put on the server. To do this, the SEIM  902  performs a BeginTransfer call to BDS  904 , to notify the BDS  904  that a file needs to be put in file system  910 .  
         [0224]    This causes BDS  904  to create a zero-length file  1102  on file system  910  that the SEIM  902  can transfer the ReviewDirectiveOut file to. Then BDS  904  adds a row to the catalog table in the database  1104  with the file attribute and location information. The PID in this case is −1, as review files are not associated with a particular product. Also, the attribute information is blank as this file will not be transferred back to a computer-based device. The call returns with a result telling the SEIM  902  where to transfer the file.  
         [0225]    After obtaining this response, the SEIM  902  performs a network call such as an HTTP PUT, transferring the ReviewDirectiveOut file to file system  910 .  
         [0226]    Processing the Unload Review Directive Out on the Server  
         [0227]    Once  902  has determined the applications that are installed on the client computer-based device, and put the results on file system  910 , the ReviewDirectiveOut file is processed.  
         [0228]    Referring to FIG. 15, the SEIM  902  notifies SMOD  906  that there is a directive file ready to be parsed by making the PutDirective call  1200 . SMOD  906 , in turn, resolves the uniqueID to a file location  1202  on file system  910  via BDS  904  and gets the file through a network call such as an HTTP GET  1204 . SMOD  906  then parses the file  1206  and stores the applications that were found in the database in the VanApp table  1208 .  
         [0229]    For every application that is found on the user computer-based device, one row is put into the VanApp table. This information is used later when the unload directive file is built. However, when the rows for the applications are put in the VanApp table for the unload review directive, the TypeID is set to a 1 instead of a 0 as in the case for Load Review. In an expert mode, the IncludeInLoad and IncludeInUnload columns are modified based on the results of the user&#39;s selections. Once this is complete, PutDirective returns back  1210  to the SEIM  902 , which returns back  1212  to the APPLICATION SERVER  900  to signal the end of the UnLoadReview call.  
         [0230]    The APPLICATION SERVER  900  then goes to the database and looks in the VanApp table so as to display to the user the applications that were found on his/her computer-based device  1214  by redirecting to an active server page.  
         [0231]    Unload  
         [0232]    As in the unload review stage, the unload is essentially the same as the load stage, however, in one embodiment, it only has two parts rather than three. The following will be a brief description on the unload stage, denoting the differences between the unload and load stage, with regards to FIGS. 14, 19 and  20 .  
         [0233]    Getting the Unload Directive File  
         [0234]    When the user indicates they want to transfer their settings, such as by clicking a button marked “unload” on the web page, a JavaScript routine on the APPLICATION SERVER  900  calls a method  1400  on the SEIM  902 , in this case, i.e., Unload(). The SEIM  902  then calls GetDirective  1402  on SMOD  906 . The goal of GetDirective is still to return the uniqueID of the directive file, but for unload directives, SMOD  906  generates the unload directive.  
         [0235]    The set of applications to include in the unload directive file is based on the applications that the user chooses to unload from the old computer-based device and the applications the user has installed on the new computer-based device. The latter list comes from unload review and lives in the VanApp table. As in the Load stage, SMOD  906  then builds up the snippets from the snippet table (with type  41 ) for all of these applications into a file. Then, SMOD  906  parses through this file and replaces the &lt;CID&gt;n&lt;/CID&gt; entries with the values from the first computer-based device. These values were stored in the setting table. The result is a file that looks very similar to the Load Directive Out file.  
         [0236]    To further illustrate the construction of the unload directive file, FIG. 19 illustrates the parsing and use of CIDs to retrieve values in the setting table. A snippet from snippet table is illustrated at  1900 . When SMOD  906  parses through the snippet file, it encounters CID  1906 . SMOD  906  uses CID  1906 , in this case  20 , to look into setting table  1910 . As previously described, each CID corresponds to a particular command, and is used to locate the particular data retrieved from that command in the setting table. Therefore, when SMOD  906  matches CID  1906  with CID  1908  in the particular VanID of interest, SMOD retrieves the stored data which was transferred from the first computer-based device in response to the command. SMOD then inserts the data into the snippet, as shown at  1902 . In the particular example of FIG. 19, SMOD matches a CID  1906  of  20  to  20  in the setting table  1908 , retrieves “&lt;Value&gt;80596&lt;/Value&gt;” and inserts it into the snippet  1904 . By doing this for all snippets, the unload directive file is generated.  
         [0237]    Once the directive has been created, SMOD  906  then makes the BeginTransfer call  1406  to BDS  904  to get the location  1408  of where to write the file. As in the case of LoadReview, this call to BDS  904  with the PUT flag set causes a row to be created in the catalog table of BDS  904  that cross-references the location with the file&#39;s uniqueID. In addition, the zero-length file gets created in the file system. Then, SMOD  906  writes the file  1410  directly to file system  910 , i.e. there is no HTTP transfer taking place. SMOD  906  then returns the uniqueId of the file  1412  back to the SEIM  902 .  
         [0238]    As in the case of Load Review, the SEIM calls BeginTransfer  1414  on BDS  904  passing it in the uniqueID.). This call returns with the location of the file to get  1416 . The SEIM  902  in turn, executes a network call, such as an HTTP GET, to obtain the file  1418 .  
         [0239]    Client processing of the Unload Directive File  
         [0240]    The SEIM  902  parses the unload directive file which includes instructions on how to place on the new computer-based device the previously retrieved settings, files, and other data. As it parses the instructions, the SEIM  902  it places the settings onto the computer-based device. Successive network calls such as BeginTransfer/HTTP GET calls, as will be explained below in conjunction with FIG. 14, are performed to retrieve files on file system  910  and place them on the new computer-based device.  
         [0241]    Once the client has all of the instructions for unloading, it begins processing the file in much the same way that the load directive was parsed. One difference is that instead of gathering settings from the registry and storing them in the directive out file, the SEIM  902  is parsing the settings from the unload directive file and storing them in the new computer-based device&#39;s registry.  
         [0242]    An exemplary part of a unload directive to store registry settings looks like:  
         [0243]    &lt;StoreKey Value&gt;HKCU\Control Panel\desktop\WallpaperStyle  
         [0244]    &lt;CID&gt;14&lt;/CID&gt; 
         [0245]    &lt;Value&gt;2&lt;/Value&gt; 
         [0246]    &lt;Value&gt;REG_SZ&lt;/Value&gt; 
         [0247]    &lt;/StoreKeyValue&gt; 
         [0248]    This instructs the SEIM  902  to store the value found for the registry key “HKCU\Control Panel\Desktop\WallpaperStyle.” The SEIM  902  retrieves this value and places it registry key of the new computer-based device.  
         [0249]    For files, the process is much the same as described in the section, “Processing the Load Directive file on the Client” and in FIG. 19. In Load, the SEIM  902  calls BeginTransfer on BDS  904  to get the location and uniqueID. It then uses the location to put the user file on file system  910  and writes the uniqueID to the load directive out file. Here, the process is reversed. The SEIM  902  gets the uniqueId from the unload directive as in the snippet below.  
         [0250]    &lt;StoreFileAtValue&gt;HKCU\Software\Microsoft\WAB\WAB4\Wab File Name\ 
         [0251]    &lt;CID&gt;20&lt;/CID&gt; 
         [0252]    &lt;Value&gt;80618&lt;/Value&gt; 
         [0253]    &lt;/StoreFileAtValue&gt; 
         [0254]    Then the SEIM  902  calls BeginTransfer(GET)  2000  passing in the uniqueID as shown below.  
         [0255]    /actions/bds/BeginTransfer.asp?s VanID=@DOAB4C6D-IBC3-IID4-9DB9-0000CO540132)&amp;  
         [0256]    sSessionID=1519609423&amp;  
         [0257]    sMode=GET&amp;  
         [0258]    n UniquelD=80618  
         [0259]    The response  2002  from this would list all of the attributes, the location where to put the file on the client computer-based device, and the location of the file location on the server side. The timestamps are displayed as signed integers to conform to the way the database stores them.  
         [0260]    An example response would be:  
         [0261]    &lt;HTML&gt; 
         [0262]    [0262] 21  HEAD&gt; 
         [0263]    &lt;TITLE&gt;&lt;/TITLE&gt; 
         [0264]    &lt;/HEAD&gt; 
         [0265]    &lt;BODY&gt; 
         [0266]    &lt;pid&gt;13&lt;/pid&gt; 
         [0267]    &lt;pathname&gt;C:\WINNT\ProfileS\Taylor\Application Data\microsoft\Address  
         [0268]    Book\Taylar.wab&lt;/pathname&gt; 
         [0269]    &lt;flags&gt;32&lt;/flags&gt; 
         [0270]    &lt;creationhi&gt;29274947&lt;/creationhi&gt; 
         [0271]    &lt;creationlo&gt;29343558&lt;/creationlo&gt; 
         [0272]    &lt;Iastaccesshi&gt; 29343558 &lt;/Iastaccesshi&gt; 
         [0273]    &lt;Iastaccesslo&gt;1505512040&lt;/Iastaccesslo&gt; 
         [0274]    &lt;Iastwritehi&gt;29342sgi&lt;/Iastwritehi&gt; 
         [0275]    &lt;lastwritelo&gt;−451749727&lt;/Iastwritelo&gt; 
         [0276]    &lt;filesizeh i&gt;0&lt;/filesizehi&gt; 
         [0277]    &lt;filesizelo&gt;117848&lt;/filesizelo&gt; 
         [0278]    &lt;uri&gt;/actionslbds/data/(DOAB4CGD-IBC 3 -IID4-SDB9-0000CO 540132 )-nfiuswtmtldkifr&lt;/uri&gt; 
         [0279]    &lt;sResult&gt;success&lt;/sResult&gt; 
         [0280]    &lt;sInfo&gt;File exists at /actions/bds/data/(DOA34C6D-IBC3-IID4-9DB9-0000CO540132)-nfiuswtmtldkifr.&lt;/sInfo&gt; 
         [0281]    &lt;/BODY&gt; 
         [0282]    &lt;/HTML&gt; 
         [0283]    The SEIM  902  then uses the location to get the data file through a network call such as an HTTP GET transfer  2004 , put it in the correct place on the user&#39;s new computer-based device and restore all of its attributes.  
         [0284]    Once the SEIM  902  has unloaded all of the user&#39;s file and registry settings, it returns back  2006  to the application server  900  from the call to Unload(). The APPLICATION SERVER  900  then tells the user that all of the settings have been moved, and that they may have to reboot their system.  
         [0285]    It is to be appreciated that essentially all of the components of the server system will be comprised of multiple software applications, multiple hardware components and potentially multiple hosting locations as is conventionally done in the industry for network site operation.  
       CONCLUSION  
       [0286]    A system and method has been shown in the above embodiments for the effective implementation of a method and system for server based extraction, transfer, storage and processing of remote settings, files and data. While various preferred embodiments have been shown and described, it will be understood that there is no intent to limit the invention by such disclosure, but rather, it is intended to cover all modifications and alternate constructions falling within the spirit and scope of the invention, as defined in the appended claims. For example, the present invention should not be limited by software/program, computing environment, or specific computing hardware.  
         [0287]    The above enhancements for the method and system associated with the server activity during the process of transfer of files, application settings, and other data and its described functional elements are implemented in various computing environments. For example, the present invention may be implemented on a conventional IBM PC or equivalent, multi-nodal system (e.g. LAN) or network (e.g. Internet, WWW, wireless web). All programming, Guls, display panels and dialog box templates, and data related thereto are stored in computer memory, static or dynamic, and may be retrieved by the user in any of: conventional computer storage, display (i.e. CRT) and/or hardcopy (i.e. printed) formats. The programming of the present invention may be implemented by one of skill in the art of object-oriented or database programming. In addition, the methodology and architecture of the present invention is equally applicable, and the appropriate modifications are easily performed by one of skill in the art, to an embodiment in which pre-generated profiles are created and transferred to the end computer-based device.