FORM-2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2006
PROVISIONAL SPECIFICATION
(See section 10 and rule 13)


SYSTEM FOR APPLICATION UPGRADE

TATA CONSULTANCY SERVICES LTD.,
an Indian Company,
ofNirmal Building,
9th floor, Nariman Point,
Mumbai - 400 021, Maharashtra, India
The following specification particularly describes the nature of the invention,


FIELD OF THE INVENTION
The present invention relates to the field of application lifecycle
management
Particularly, the present invention relates to the field of application
maintenance.
Still particularly, the present invention relates to the field of application
upgrade.
BACKGROUND OF THE INVENTION AND PRIOR ART
A computer in a client-server architecture, which typically performs most of the functions independent of the server is known as a thick client and a computer which is dependent on the server for all its operations is a thin client.
Many enterprises have thick client front end architectures for better performance and usability. A thick client front end allows for lower bandwidth to a central server due to its amenability for TCP/IP communication, better response for data items which are cached in a local data store typically, a local database, richer GUI in Java or in .NET, and limited offline functionality in the absence of network connectivity.
Application upgrade refers to the term of enhancing the quality of a product by replacing it with a newer version of that same product. While users are highly appreciative of the services provided through a thick front end, there are numerous challenges faced by an enterprise in keeping the front end application up to date. In a thin client front end which is browser based there is no installation required on the user's desktop and in this way application upgradation is a non issue.
2

Typically, during application upgrade a user clicks on an icon on the desktop to open the application. The first step in the upgrade process is to check for version mismatch. This is usually done by automatically connecting to a distribution site and verifying the version number on the desktop against the latest upgrade version number at the site.
If the version number at the desktop is older than that at the site, the workstation automatically initiates a download of the newer version. Quite often only the difference between the two versions is downloaded.
Typically, the download is available as a single file packaged with a number of libraries and data files and the total size is usually in megabytes. Once the download is complete the installation of the newer version automatically starts.
The newer version installation involves replacing the old libraries with the new libraries, registering the new libraries, updating the local data store with the newer definitions as well as the refreshed data, updating other files including image and configuration files, and finally updating the version number of the application on the desktop to be the latest version.
Typically, the application upgrade process is implemented in a controlled environment which comprises high end desktops with sufficient resources accessing a server over the local area network (LAN). Environment reliability issues rarely manifest themselves in such an environment. In real life one needs to assume:
• Hundreds to thousands of user workstations;
3

• varied network bandwidth from workstation to distribution site, it can vary from a few kbps (dialup) in case of some users, to high bandwidth leased lines from other users;
• varied desktop configurations across users, some users may have 512MB of RAM with single older generation processor and some may have more than 2GB of RAM with dual processor;
• varied free disk space available on workstation from close to zero megabytes to gigabytes of free space;
• other applications can be running on workstation at the time of upgrade; and
• applications such as virus scans can be running on workstation at the time of download and installation.
With this as the typical scenario during application upgrade a number of failures can occur during the application upgrade process. This includes and is not limited to;
• User aborting the download because it takes too long;
• download automatically aborted because of abrupt failure in connectivity;
• running out of disk space during download or installation;
• running out of memory during installation;
• conflicts during installation due to other applications running on desktop;
• significant slow down during download or installation during virus scan or other resource hungry applications running on the desktop;
• failure to update local data store due to consistency issues; and
4

• failure to restore to the older version in case of error with the new version.
Given these issues and given that on a low bandwidth line the entire process of upgrade can take several minutes, there is a need for a highly reliable and an efficient system and process for performing application upgrades.
OBJECTS OF THE INVENTION
It is an object of the present invention to provide an efficient and a reliable system for automated application upgrade.
it is another object of the present invention to provide a system for automated application upgrade on desktops for thick client front end applications.
It is still another object of the present invention to provide an automated application upgrade system which handles all kinds of errors which occur at various stages of the application upgrade.
SUMMARY OF THE INVENTION
The present invention envisages a reliable and an efficient system for application upgrade. Particularly, the invention envisages a reliable and an efficient system for upgrading thick client front end applications.
The application upgradation system envisaged by the present invention typically comprises a user interface for accepting requests for application upgrade, a version checking means for checking if there is version mismatch between the application installed on the thick client (workstation) and the distribution site, an extraction means for extracting the latest version of the
5

package file of the application, a deploying means for deploying the package files on the workstation and a recovery means for error handling.
According to one aspect of the present invention, the upgrade passes through various states for its successful execution and completion like version check, download, unzip, backup, copy/replace, database update, registry update, cleanup, version number update and restore. The application upgradation system keeps track of the state the upgrade has reached to ensure that a failure does not cause the entire upgrade to reinitiate. Moreover, the present invention in case of partial state execution followed by a failure aborts the upgrade operation to avoid leaving the upgrade inconsistent. Therefore, the present invention controls the amount of recovery so that the upgrade is time bound and wherever a fatal error occurs human assistance is called for.
According to another aspect of the present invention, the present invention writes the state variables into a file so that the application upgradation system can track itself even upon a client application or desktop failure and reboot.
According to still another aspect of the present invention, in case of failure the application upgradation system restarts the upgrade from the beginning of the state instead of resuming from within the state.
According to a preferred embodiment of the present invention, the process of application upgrade comprises:
• checking for version mismatch between the client application and the application available at the distribution site;
6

• downloading a newer version of the application in the form of one or more packages to the workstation;
• unpacking the downloaded files;
• copying the libraries and other files pertaining to the new version to the respective location and wherever relevant replacing the older versions;
• applying the newer schema definitions through the database scripts at the client;
• updating or inserting data in to the database or data store at the workstation;
• updating the registry with newer versions of the libraries installed at the workstation;
• deleting libraries and files pertaining to the older version from the workstation;
• updating the configuration to reflect the version number of the upgrade that was downloaded and installed; and
• in case of any failure at the workstation restoring to the older version of the application.
The present invention includes attributes which are a part of a state. The attributes include 'state label', 'entry time', 'time to live', 'max retries' and 'retry count'.
• State Label: Formal state the upgrade process has reached;
• Entry Time: The time at which the upgrade process first entered in to the state;
• Time to Live: The maximum time the upgrade process can spend in the given state;
7

• Max Retries: The maximum number of times the upgrade process can try to recover itself in the given state; and
• Retry Count: The number of times recovery has been initiated in the given state.
According to another preferred embodiment of the present invention, the max retry count and the time to live are the key parameters to decide the progress of the upgrade process. Post expiry of the retry count or time to live parameters trigger 'restore backup' to roll back the application to the older version by restoring the backup. In the event of the 'restore backup' also failing, it is assumed that a fatal error needs human intervention. Usually, this fatal error is communicated in the form of a message to contact the helpdesk or an operator through email or phone or by posting a support request over the internet and/or intranet.
In accordance with yet another aspect of the present invention, the 'restore backup' processing may vary depending on the state which has failed. For example, if the download failed the max retry times then, nothing has to be done other than cleanup of the partially downloaded files. However, if database update failed the max retry times, 'restore backup' will need to ensure a complete restore back to the previous version. The 'restore backup' processing involves cleanup then copying all files from backup including database dump, database reinstallation, and registry updates.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
The invention will now be described in relation to the accompanying drawings, in which:
8

Figure 1 illustrates a schematic of the application upgradation system in
accordance with the present invention;
Figure 2 illustrates a state transition diagram for a normal application
upgrade process in accordance with the present invention; and
Figure 3 illustrates a state transition diagram for recovery processing in
accordance with the present invention.
DESCRIPTION OF THE INVENTION
The system for automated application upgrade will now be described with reference to the accompanying drawings which do not limit the scope and ambit of the invention and are provided purely by way of example and illustration.
Referring to the drawings, Figure 1 illustrates a schematic of the application upgradation system (AUS) represented by reference numeral 10 of Figure 1. The AUS 10 typically includes the following components which assist in successful execution and completion of upgrade of an application:
Interface: Interface represented by block 12 of Figure 1, is the standard interface of the system. The interface receives the upgradation request from the workstation represented by reference numeral 22 of Figure 1; and passes the request along with the product ID and the current version of the application at the workstation 22 to the version checking means, represented by block 14 of Figure 1.
Version checking means: The version checking means 14 receives the product ID and the workstation application version. The version checking means checks for the version mismatch between the workstation 22
9

application and the latest version of the application available in the product repository, represented by block 20 of Figure 1. If the workstation 22 application is not up-to-date then the version checking means sends the upgrade instructions to the extraction means, represented by block 16 of Figure 1.
Extraction means: Extraction means 16 receives the upgrade instructions and retrieves the latest version of the product from the product repository 20 in the form of one or more packaged files. The extraction means 16 downloads these files to the workstation 22 and unpacks/unzips them. After successful download the extraction means 16 notifies the deployment means represented by block 18 of Figure 1 to start installing the downloaded version of the application.
Deploying means: Deploying means 18 takes a back-up of the older version of the application at the workstation 22. The backup involves backup of libraries, data files, registry files, database and OS scripts, and other files including image and configuration files. Further, the deploying means 18 copies the libraries and other files pertaining to the new version to their respective locations and wherever relevant replaces the older version. The newer schema definitions are applied through database scripts and newer data is updated or inserted in to the database or data store at the workstation 22. The file system registry is updated with newer versions of libraries installed and the libraries and files pertaining to the older version are deleted from the workstation 22. The workstation configuration is made to reflect the version number of the upgrade that was downloaded and installed. On
10

successful upgrade the deploying means 18 displays an 'upgrade successful' message and exits from the upgrade process.
Product repository: Product repository 20 is the database which stores the latest versions of the application available at the distribution site. The repository 20 stores the product ID, one or more package files for that product ID, version information and the timestamp when the current version of the application was uploaded in the repository.
Recovery means: Recovery means, represented by block 24 of Figure 1, handles the various failures and errors which occur during the upgrade operation. The recovery means 24 keeps track of the states otherwise a failure can cause the entire upgrade process to reinitiate. The recovery means 24 eliminates partial state execution so that a failure does not leave the upgrade process inconsistent. It controls the amount of recovery so that the process is time bound and wherever a fatal error occurs human assistance is called for.
The upgrade operation will now be described using the state transition diagram as shown in Figure 2 for a normal application upgrade operation.
The definitions of the various states are listed below:
• Version Check: Version Check state, as represented by reference numeral 50 of Figure 2, checks for version mismatch, as represented by reference numeral 52 of Figure 2, between the workstation application and the application available at the distribution site;
11

• Download: Download state, as represented by reference numeral 54 of Figure 2, in this state the newer version of the application (in the form of one or more packaged files) is downloaded to the workstation;
• Unzip: Unzip state, as represented by reference numeral 56 of Figure 2, unpacks the downloaded files;
• Backup: Backup state, as represented by reference numeral 58 of Figure 2, takes a backup of the older version of the software at the workstation. This involves backup of libraries, data files, registry files, database and OS scripts, and other files including image and configuration files;
• Copy/Replace: In this state, as represented by reference numeral 60 of Figure 2, libraries and other files pertaining to the new version are copied to their respective locations and wherever relevant they are replaced by the older versions;
• Database Update: In this state, as represented by reference numeral 62 of Figure 2, the newer schema definitions are applied through database scripts and newer data is updated or inserted in to the database or data store;
• Registry Update: In this state, as represented by reference numeral 64 of Figure 2, the file system registry is updated with newer versions of libraries installed;
• Cleanup: In this state, as represented by reference numeral 66 of Figure 2, the libraries and files pertaining to the older version are deleted from the workstation;
• Version Number Update: In this state, as represented by reference numeral 68 of Figure 2, the workstation configuration is made to reflect
12

the version number of the upgrade that was downloaded and installed and exit the process as represented by reference numeral 70 of Figure 2; and • Restore: In this state, the application is rolled back to the older version. The normal process assumes no failures. Just as a precaution, the cleanup state is kept last so that in case any operation fails in between, the backup of the older version is still available for restore.
The present invention utilizes formal attributes that are a part of a state. They are defined as below:
• State Label: These are the various states of the upgrade process including version check, download, unzip and the like.
• Entry Time: This is the time at which the upgrade process first entered in to the state;
• Time to Live: This is the maximum time the upgrade process can spend in the given state;
• Max Retries: This is the maximum time the upgrade process can take to try and recover itself in the given state; and
• Retry Count: This is the number of times recovery has been initiated in the given state.
The attribute values can be different for different states. The present invention makes these state variables persistent so that the upgrade process can track itself even upon workstation application or desktop failure and reboot. This is achieved by writing these variables in to a file.
According to an aspect of the present invention, the application upgrade system requires that during the state 'recovery' the upgrade process must
13

restart from the beginning of the state as opposed to resume from within the state.
Figure 3 shows the recovery processing in accordance with the present invention.
State S is any of the normal states, represented by reference numeral 80 of Figure 3. In case of normal operation the upgrade process performs the task of State S 80 and if the operation of the state is successful then exits from that State S, represented by reference numeral 82 of Figure 3 and enters the Next State represented by reference numeral 84 of Figure 3. If the operation performed in State S is not successful then the present invention starts the recovery processing. It checks essentially for the max retry count and the time to live parameters to decide the progress, represented by reference numeral 86 of Figure 3
A more complicated recovery process can be implemented by deciding the next state post expiry of retry count or time to live. But, presently the state simply triggers a 'restore backup' represented by reference numeral 88 of Figure 3.
The present invention checks if 'restore backup' is successful represented by reference numeral 90 of Figure 3. If 'restore backup' is successful then the upgrade process exits from the current operation as represented by reference numeral 92 of Figure 3. Otherwise, the present invention checks for max retry count and the time to live parameters to decide the progress represented by reference numeral 94 of Figure 3. In the event of the 'restore backup' failing repeatedly, it assumed that a fatal error is taken place that needs
14

human intervention represented by reference numeral 96 of Figure 3. Usually human intervention can asked in the form of a message to contact the helpdesk or operator through email or phone or by posting a support request over the internet/intranet.
The advantage of the approach outlined in Figure 3 is that it handles all exceptions the same way. Restore backup processing may vary depending on the state which failed. For example, if the download failed 'max retry times' then nothing has to be done other than cleanup of the partially downloaded files. However, if database update failed the max retry times, restore backup needs to ensure a Complete restore to the previous version.
According to yet another aspect of the present invention, before entry into any state the necessary validations for entry in to the state are complete including any cleanup, and likewise upon exit the necessary validations are done. The type of error handling and validation required per state is provided in Table 1.

State Entry Exit Failure Action Upon
Criteria Criteria Types Failure
Version Connectiv Version Connectivity Ask user to
Check ity to number fails during reconnect and
distributio check processing retry as per
nsite complete Figure 3
Download Connectiv Download Connectivity Delete partial
ity to file size fails, out of files, ask user for
distributio matches disk space, space/permission
n site, user abort, s if required
disk space system reconnect, and
available crash, no write retry as per Figure 3
permissions,
15

corrupt file
Unzip Successfu Unzipped Out of disk Delete all
1 exit from file names space, no unzipped files,
download, and sizes write ask user for
plus disk match permissions, space/permission
space system s if required, and
available crash, retry as per
corrupt file Figure 3
Backup Folder File Out of disk Delete all backed
available names space, no up files, ask user
with and sizes write for
enough match permissions, space/permission
disk space source folder system crash s if required, and retry as per Figure 3
Copy/ Disk File sizes Out of disk Delete all
Replace space match space, no overwritten files,
available, source overwrite cleanup registry
permissio files, permission, modifications,
n to write Registry updates done if required system crash ask user for space/permission s if required, and retry as per Figure 3
Database Permissio Successfu Script Restore previous
Update ns 1 script failure, no database backup,
available, execution space ask user for
previous and data available, no space/permission
database load permissions, s if required, and
backup system or retry as per
available,
space
available database crash, change in OS (e.g. patch) or database environment Figure 3
Registry Permissio Successfu Update Cleanup partial
Update ns 1 update failed, no updates, Ask
available of registry permission user for
16

f entries for new
software to be to update permission if required and retry as per Figure 3
installed
Version# Verificati Version Verification Ask user for
Update on that number failed, permission if
installatio updated in system required and
n is a suitable crash, no file retry as per
successful configurat write Figure 3

preferably through verificatio n script ion file permission
| Cleanup Successfu Backup System Ask user for
1 exit from folder crash, no permission if
Version# empty and permission required and
update deleted to delete retry up to max retry count. Upon failure log
error message.
Table 1
The restore backup processing will involve cleanup then copying all files from backup including database dump, database reinstallation, and registry updates.
The technical advancements of the present invention include:
• providing a system for reliable and efficient application upgrade on desktops for thick front end applications;
• providing a system which handles all kinds of failures and does not leave the application in an inconsistent state; and
17

• providing a system which has uniform recovery logic for all kinds of errors that can occur during the upgrade process and the error handling across all states.
While considerable emphasis has been placed herein on the particular features of this invention, it will be appreciated that various modifications can be made, and that many changes can be made in the preferred embodiments without departing from the principles of the invention. These and other modifications in the nature of the invention or the preferred embodiments will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the invention and not as a limitation.