CA2325544C - Multi-tiered incremental software updating - Google Patents
Multi-tiered incremental software updating Download PDFInfo
- Publication number
- CA2325544C CA2325544C CA002325544A CA2325544A CA2325544C CA 2325544 C CA2325544 C CA 2325544C CA 002325544 A CA002325544 A CA 002325544A CA 2325544 A CA2325544 A CA 2325544A CA 2325544 C CA2325544 C CA 2325544C
- Authority
- CA
- Canada
- Prior art keywords
- update
- state
- patches
- patch
- tier
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 claims description 31
- 230000001131 transforming effect Effects 0.000 claims description 5
- 238000004590 computer program Methods 0.000 claims description 3
- 241000700605 Viruses Species 0.000 description 20
- 230000007246 mechanism Effects 0.000 description 12
- 230000009466 transformation Effects 0.000 description 10
- 239000000796 flavoring agent Substances 0.000 description 6
- 235000019634 flavors Nutrition 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- GFRROZIJVHUSKZ-FXGMSQOLSA-N OS I Natural products C[C@@H]1O[C@@H](O[C@H]2[C@@H](O)[C@@H](CO)O[C@@H](OC[C@@H](O)[C@@H](O)[C@@H](O)CO)[C@@H]2NC(=O)C)[C@H](O)[C@H](O)[C@H]1O GFRROZIJVHUSKZ-FXGMSQOLSA-N 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000007723 transport mechanism Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 101000872083 Danio rerio Delta-like protein C Proteins 0.000 description 1
- 241000726306 Irus Species 0.000 description 1
- 230000002155 anti-virotic effect Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000007630 basic procedure Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/64—Retargetable
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/658—Incremental updates; Differential updates
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Abstract
A software application (110) is updated to a newer version by means of incremental update patches (122). The incremental update patches (122) each contain that information necessary to transform one version of an applicatio n to another version. Any version of an application (110) may be upgraded to a ny other version of the application, through the use of a series of incremental update patches (122). The appropriate incremental update patches (122) are distributed in a multi-tiered manner, such that some update patches (122) update the application (110) by only one version, and others update the application (110) by several versions.
Description
Multi-Tiered Incremental Software Updatine BACKGROUND OF THE INVENTION
I . Field of the Invention The present invention relates generally to incremental software updating, and more specifically to a system and method for using an automated, multi-tiered approach to performing incremental software updates.
I . Field of the Invention The present invention relates generally to incremental software updating, and more specifically to a system and method for using an automated, multi-tiered approach to performing incremental software updates.
2. Description of Backeround Art Some computer software publishers update their software "applications"
(computer programs and data files associated with the programs) frequently. For some types of software applications, such as virus protection software, these updates are particularly frequent. V irus 1 S protection software applications are designed to detect computer viruses on a computer system, and may also remove viruses which are found. An example of such a software application is Norton Anti-Virus, published by Symantec Corporation of Cupertino, California. Because these virus protection software applications rely on data about specific viruses, and new viruses are constantly being written to avoid current virus detection capabilities, it is necessary to update virus protection software applications on a regular basis to account for the newest viruses. Frequent updating of data files is also necessary for some database publishers, who must put up-to-date information in their databases, and remove obsolete information therefrom. Periodic updating of general software applications to expand capabilities and eliminate "bugs" is also common.
Currently, several methods are used to update software applications. The simplest of these is to distribute one entire software application to replace an older one. This method, the "full update" method, is simple, but expensive and inconvenient. Typically the software is distributed on some type of removable media, such as floppy disks or CD-ROMs, which are costly to produce and distribute. The time an end user must wait for the removable medium to arnve and the time it takes for the software application to install itself on a computer system are inconvenient. This inconvenience is compounded where updates occur frequently.
Because of the large size of software applications it is generally not feasible to distribute such updates over computer networks, such as the Internet. When full updates are distributed over the Internet, they often cause such high loads on servers that other users suffer slow-downs on the network, and the servers.have trouble meeting the demands.
In order to bypass many of the problems associated with this type of software updating, some software publishers distribute "incremental updates." These updates do not contain entire software applications, but rather only that information necessary to transform a given version of a software application to a newer version. Among the methods available to perform such incremental software updating is binary patching, performed by programs such as RTPatch, published by Pocket Soft, Inc. A binary patcher replaces only those binary bits of a software application which are different in a newer version. Because most software updates involve changes to only a small portion of a software application, a binary patcher needs, in addition to the old software application, only a small data file including the differences between the two versions. The smaller data files distributed for a binary patch update are often less than 1 % of the size of a full update, taking advantage of the large amount of redundancy in the two versions.
The use of incremental update methods allows for smaller updates which can be distributed by means that are not conducive to the distribution of full updates, such as distribution over the Internet. The smaller incremental updates also make distribution by floppy disk more feasible where a full update would have required many disks, and an incremental update may require only one. However, incremental update methods introduce another problem: the incremental update is specifically useful for updating only one particular version of a software application to another particular version. When updates occur frequently, as with virus protection software applications, end users may often update from an arbitrarily old version to the newest version, skipping over several previously released versions. An incremental update for the newest version of a software application will update only from the most recent version, however.
One solution to this problem has been for software publishers to group a number of binary patch data files together into one distribution. The user of an arbitrarily old version can then apply each incremental update, one at a time, to update to the newest version. However, the number of incremental updates may be large, due to the fact that the grouping covers a large number of versions. The benefits of smaller distributed update files begin to disappear, as the size of the grouped-together incremental updates grows. This method of updating applications can also be cumbersome, as a series of update patches need to be selected from the group and applied to the software application one after another.
Another solution to the problem of incremental update version-specificity has been to create a unique patch file for transforming every previous version of the application to the most current version. Some users may not wish to update their software applications to the most current version, however, for a number of reasons. Some may be within a corporate setting, where an information services department allows updates only to versions it has had a chance to test and approve. Others may have older computer systems which do not support the increased resource requirements of the newest version of an application. For these reasons, publishers of software updates using this method must generally keep updates available from every previous version of an application to a large number of more recent versions. This results in a geometrically growing number of update patch files to produce, store and maintain for users. In the case of publishers who update their applications frequently, such as publishers of virus-protection software applications, this may quickly become untenable.
One alternative to the methods described above is the use of "push"
technology, in which servers maintain databases of what versions of a software application each user has The servers then send the necessary updates to each user, as they become available. This system requires "smart" servers, however, to monitor user configurations, determine what each user needs, and send the appropriate update information. This results in a server-intensive system which can cause a drain on server resources comparable to that experienced in the full update scheme, when many users are simultaneously requesting fill updates.
What is needed is a system for updating software applications from an arbitrary first version to an arbitrary second version which does not require a large amount of information to be stored and maintained by a software publisher, does not require the user to acquire a large amount of data to perform such an update, and does not require the use of "smart" servers.
SUMMARY OF THE INVENTION
The present invention is a method and apparatus for distributive the appropriate incremental software update information to users. A software publisher (118) provides update patches ( 122) which will update users' software applications ( 110) from one state to another.
The update patches (122) are 'tiered.' Update patches on the first tier (200) update from a given application state to the subsequent application state. Update patches on the second tier (202) update an application from a given state to the state which is two versions later. The tier of an update patch indicates how many individual updates are spanned by the patch.
By selectively providing tiered update patches, software publishers (118) can facilitate quick, efficient updating of users' applications ( 110) without producing and maintaining large numbers of update patches (122). These update patches ( 122) may be provided to users simultaneously through a variety of distribution channels ( 124), since a "smart server" is not necessary to provide users with the needed update patches (122). This allows for selective redundancy. as update patches (122) which are likely to be needed by many users may be made available through more of the available distribution channels (124) than others, providing a robust distribution system.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other more detailed and specific objects and features of the present invention are more fully disclosed in the following specification, reference being had to the accompanying drawings, in which:
Figure 1 is a block diagram of a first embodiment of the present invention, in which a software application 110 on a user's computer 116 is updated with incremental update patches 122 from a remote source 118.
Figure 2 is an illustration of the relation of various tiers of updates to a series of application states in the present invention.
Figure 3 is an illustration of an example of the use of mufti-tiered incremental updates to perform a software application update according to the present invention.
Figure 4 is an illustration of an example of a sub-optimal software application update using incremental updates.
Figure 5 is an illustration of an example of a publishing schedule for mufti-tiered incremental updates which meets the necessary condition for optimal updates according to the present invention.
Figure 6 is an illustration of an updating program 126 using a catalog 404 to determine an appropriate sequential set of update packages 412 based on attributes of an application 110.
Figure 7 is an illustration of an updating program 126 constructing a sorted directory 408 of available catalogs 404 from different sources 400 and 402.
WO 99/49391 PCT/US99/06b19 Figures 8a and 8b are a flowchart showing how an updating program determines what update patches need to be applied to effect an update, and how the updating program carries out the updating.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
S In one embodiment, the present invention may be implemented as an update mechanism for a virus protection software application. In other embodiments, the present invention may be used to update general computer readable files, which may include data files, program files, database files, graphics files, or audio files. For illustrative purposes only, the invention will be described as embodied in an update mechanism for virus protection software.
Referring to Figure 1, a virus protection software application 110 which incorporates a number of virus detecting routines 112, and utilizes a number of data files containing virus information 114, is installed on a user's computer 116. Because of the rate at which new viruses are created. it is desirable to update the virus protection software applications on the user's computer frequently. These updates could take place as often as daily, or even more frequently if desired. Generally, these updated applications 110 will include only small changes to the data files I14, but sometimes larger changes to the virus detecting routines I12 will also be included.
In order to fully describe the embodiment of the present invention, it is first necessary to describe DeltaPackages, DeltaCatalogs, and DeltaDirectories.
DeltaPackages Each time an updated software application 110 is produced by the virus protection software publisher, the updated form of the software application constitutes a new version.
The software publisher uses an incremental update builder, such as binary patch file builder 120, to produce at least one incremental update, such as binary patch file 122, which can transform a previous version of the software application to the cturent version. A binary patch file builder 120 is a program which takes two versions of a software application, for example versions A and B, and produces a binary patch file, 122, which can be used with version A of the software application to produce version B. In this example, version A
would be the "source" state and version B would be the "destination" state of the application. This binary patch file 122 can either be an executable file which acts directly on version A of the software application, or it can be a data file which is used by a separate binary patch program (not shown) to transform version A of the software application to version B. The binary patch files 122 are stored on an update data source 124 (a "server") which makes the patch files 122 available to an updater program 126 (a "client"). The updater program 126 determines what patch files 122 are necessary, retrieves them and applies them to the application to be updated 110. In the illustrative embodiment, the incremental update files are binary patch files which are digitally signed compressed executable modules, and the Java ARchive (JAR) platform-independent file format, available from Sun Microsystems, is used for this purpose. Because they are digitally signed, the authenticity of the updates can be ensured.
When executed, the incremental update file automatically transforms a software application from a source state to a destination state. These self contained executable incremental update files conforming to the JAR format are referred to as "DeltaPackages" 122, and are one example of what is referred to herein as an "update patch".
In Figure 2, a series of application states are given, designated state A
through state S.
Each application state is a software application version which is produced by the software publisher later in time than a version with an alphabetically earlier letter designation. The DeltaPackages 122, which are referred to as "tier 1" DeltaPackages 200, are so named because they each effect a transition from an application state which is only one version earlier than the destination state. There is a tier 1 DeltaPackage 200 for updating to each application state other than the initial application state, A. The software publisher may produce higher tier DeltaPackages 122, such as "tier 3" DeltaPackages 202 and "tier 9"
DeltaPackages 204. A tier 3 DeltaPackage 202 is used to transform an application from a source state three versions earlier than the destination state, and a tier 9 DeltaPackage 204 is used to transform an application from a source state nine versions earlier than the destination state. Many other tiers of DeltaPackages 122 may be produced, but the benefits of additional tiers must be weighed against the costs, described below. In Figure 2, tier 1 DeltaPackages 200 are produced for each new version, tier 3 DeltaPackages 202 are produced for every third version, and tier 9 DeltaPackages 204 are produced for every ninth version.
For illustrative purposes, each DeltaPackage 122 is given a designation which is "0"
followed by two letters. The first letter indicates the application source state upon which the DeItaPackage 122 works and the second letter indicates the application destination state produced. For the case where there are not multiple "flavors" of the application which need to be updated in parallel, a relatively simple process is employed to update the application.
DeltaPackages 122 are applied to a user's software application incrementally, beginning with the highest tier DeltaPackage 122 available which has a source state equal to the current state of the application, and a destination state no later than the desired ending state. After the DeltaPackage 122 is applied, and the application is updated to the destination state of the DeltaPackage 122, another DeltaPackage 122 is chosen in the same manner, with the new application state providing the source state of the next DeltaPackage 122.
This continues until the desired ending state of the application is reached.
Figure 3 illustrates this procedure for a case in which it is desired to transform an application of state F to an application of state T. Following the procedure described above, such a transformation is accomplished through only four incremental updates, from F to G to J
to S to T. Each time a new DeltaPackage 122 is to be selected, the one chosen is the highest tier DeltaPackage 122 with the current application state as a source state, and a destination state which does not exceed the desired ending state.
When fewer incremental updates are required to perform a given transformation, fewer DeltaPackages 122, and therefore less information, needs to be transferred to the application.
The procedure described above produces a desired transformation using the smallest number of available DeltaPackages 122, as long as one condition is met: no available DeltaPackage 122 may have a source state which is between the source and destination states of an available DeltaPackage 122 with a lower tier. As long as this condition is met, then the procedure described above will perform an optimum transformation, using the smallest number of available DeltaPackages 122 to get from the beginning state to the desired ending state. If the condition is not met then the procedure described above may result in a transformation which uses more of the available DeltaPackages 122 than necessary. An example of a sub-optimal transformation is illustrated in Figure 4. In that case, a transformation from state G to state S
uses four DeltaPackages 122 (OGJ, AJM, NVIP and APS), when it need only use three (OGH, CHI, and AIS). Because the AIS DeltaPackage 122 has a source state (I) which is between the source and destination states of a lower tier DeltaPackage (~GJ), the DIS
DeltaPackage 122 violates the above condition, and a sub-optimal set of DeltaPackages 122 is used. In practice, a software publisher may easily ensure that the available DeltaPackages 122 meet this condition, since each DeltaPackage I22 is produced later in time than DeltaPackages 122 with earlier destination states. In the above example, before issuing DeltaPackage DIS, the publisher would eliminate DeltaPackage ~GJ and possibly replace it with another, such as DeltaPackage ~GI.
In the example of Figure 3, if only the tier 1 DeltaPackages 200 had been available, fourteen DeltaPackaees 122 would have been required for the transformation, instead of four, and much unnecessary information would have been transferred to the application. The total number of DeltaPackages 122 which would have been produced by the publisher, however, would have been smailer, the higher tier DeltaPackages 122 not having been produced. On the other hand. if a tier 14 DeItaPackage 1Z2 designated OFT had been available, only one DeltaPackage 122 would have been required, and very little information would have been transferred to the user. However, the availability of a DeltaPackage 122 which accomplishes any particular transformation in one step can be assured only by producing individual DeltaPacka~es I22 from every source state to every destination state, which requires a number of DeltaPackages 122 approaching N' (where N is the number of file states).
Producing and maintaining such a large number of individual DeltaPackages 122 is not feasible in many situations. as explained above. These considerations must be considered by a software publisher in determining the most efficient DeItaPackage 122 publishing schedule. For the illustrative embodiment, it was determined that providing DeltaPackages 122 of tiers 1, 3 and 9 would be most efficient.
The tiers of DeltaPackages 122 produced do not need to be published according to any fixed schedule, but rather may be determined as new updates become available.
In Figure 5 an irregular publishing schedule of DeltaPackages 122 is shown. There are four separate tiers of DeltaPackages 122 available with J as a source state. The decision to create so many DeltaPackages I22 with the same source state may be.based on the fact that many copies of the application in the J state are known to be at large. Many publisher-specific, application-specific, and information transport mechanism-specific factors will affect the desirability of a publishing schedule for DeltaPackages 122.
DeltaCatalogs Sofrware publishers often produce different "flavors" of a single software application, directed to different computer architectures, different operating systems, and users who speak different languages. The scheme for publishing incremental updates laid out above is adequate for the case in which there is only one flavor of a software application. For the more general case of several application flavors, however, some additional mechanisms can be used to handle the additional complexities of parallel updating. A system which addresses these complexities is described in the second illustrative embodiment of the present invention.
In the case of virus definition updates, there are often updates which are not operating system-specific, and sometimes there are updates which are not even computer architecture-specific. Other times, updates are specific to these, and other, categories. A
single update DeltaPackage 122 may be useful to update some flavors of an application, but not others. To handle these complexities, update catalogs, referred to as "DeltaCatalogs,"
are utilized. These update catalogs are another example of what are referred to herein as "update patches." Rather than having a single DeltaPackage 122 correspond to each incremental update (i.e. "HIS") as above, a DeltaCataiog corresponds to each incremental update (i.e. "DIS").
Each DeltaCatalog has an associated source state and an associated destination state, and specifies the necessary update information by specifying which DeltaPackages 122 should be used by each flavor of the application to update from the source state to the destination state. In one embodiment, DeltaPackages 122 are given unique IDs which do not conform to the "DAB"
format used above for illustrative purposes, and are specified by the DeItaCatalogs using these unique IDs.
With DeltaCatalogs substituted for DeltaPackages 122, the general scheme described above is utilized.
There are a number of different ways DeltaCatalogs can be implemented. In this embodiment, the Extensible Markup Language (XML) standard is used to create a document type definition. The XML standard is available from W3C Publications, World Wide Web Consortium, Massachusetts Institute of Technology, Laboratory for Computing Sciences, NE43-356, 545 Technology Square, Cambridge, MA 02139. An example document type definition corresponding to the XML standard, referred to as DPML (for DeltaPackage Markup Language), is given in Appendix A. In this document type definition, there are a number of types of entries a DeltaCatalog may contain. These types are Product (the type of software application), Package (a specific DeltaPackage 122), OS (operating system), CPU
(computer architecture) and Language (the language spoken by the users of the software application). An entry of any of these types except Package may in turn contain entries of the types Product, Package, OS, CPU or Language. None of the entry types may contain a DeltaCatalog, and the Package must contain an "ID" which corresponds to a specific DeltaPackage 122. Also, the "to", or destination state, data field and the "from", or source state, data field must be given for a DeltaCatalog.
An example of a DeltaCatalog contained in a file written to conform to the XML
format is given in Appendix B. In the DeltaCatalog file itself, the document type definition for "DPML" is specified by including a uniform resource locator (URL) pointing to the location of a current specification of the document type definition. Alternatively, the data type definition may be included in the file explicitly. A software application to be updated contains the attributes of current state, Product, OS, CPU, and Language, and has access to the desired ending state of the software application, as described below. In order to determine a sequential set of DeltaPackages 122 which need to be applied to the software application to effect the transformation from the current state to the desired ending state, an updating mechanism, referred to as a "DeltaUpdater" is used. The DeltaUpdater may be a separate program. or may be part of the software application itself. It goes through the same basic procedure outlined above, with DeltaCatalogs taking the place of DeltaPackages 122. The DeltaCatalog of the highest tier available which has a "from" field matching the application's curreflt state and which has a "to" field which does not exceed the ending state is selected by the DeltaUpdater.
The DeltaCatalog is then processed, with the DeltaUpdater processing only those sub-entries contained within entries with attributes which match those of the application.
An example is 1 ~ illustrated in Figure 6. The DeltaCatalog 404 contains a simplified form of the information contained in the DeltaCatalog file of Appendix B. Application 110 has the attributes of "NAV version 2.0 running on Windows NT on an alpha computer using North American English." The DeitaUpdater 126 would process only Package )D's "487" and "766," as all other Package entries correspond to different attributes. Those DeItaPackages I22 which correspond to these two IDs would then make up a sequential set 412 of DeltaPackages 122 to be applied to application 110 in the order they were encountered in DeltaCatalog 404. When applied to application 110, the DeltaPackages 122 of set 412 transform application 110 from state 1 to state 8, the states given in the "from" and "to" fields of DeltaCatalog 404. If the desired ending state were still later than state 8, then this procedure would again be applied to select and process another DeltaCatalog 404, one which has a "from" value of 8.
DeltaDirectories A number of transfer mechanisms are available to a DeltaUpdater for retrieving DeltaCatalogs and DeltaPackages 122. Among these are the NNTP Usenet server protocol, available from Internic as "Request For Comments 977"; the HTTP protocol, available from Internic as "Request For Comments 1945"; the FTP protocol, available from Internic as "Request For Comments 959"; and direct access to a "file server" using a protocol such as the Universal Naming Convention (UNC). A file server may be, among other things, internal disk media, removable disk media, or a network resource. Other distribution mechanisms are currently available and more will likely be available in the future. All that is required of a transfer mechanism is that the mechanism be able to supply computer readable data upon request. The present invention utilizes so called "dumb media," meaning that the medium supplying the requested information need not interact with the DeltaUpdater beyond simply supplying requested data. Specifically, "smart servers," such as those used in "push"
technology, are not necessary. A smart server determines what update information is necessary, given information about the state of the software application, and then supplies that information. The described transfer mechanisms allow DeltaCatalogs and DeltaPackages 122 to be retrieved from "catalog sources" and "update data sources" on which they are stored.
A typical system embodying the present invention will have available more than one of the mentioned transfer mechanisms, as illustrated in Figure 7. A DeltaUpdater 126 will have access to a list 403 of locations, specified as URLs, where needed data may be found. In general, these URLs will specify a number of NNTP news-servers with news-groups, HTTP
servers with directory paths, FTP servers with directory paths, and file servers with directory paths. In the embodiment illustrated in Figure 7, an NNTP server 400 and a file server 402 contain available DeltaCatalogs 404. The flowchart of Figure 8 shows the steps carried out by the DeltaUpdate>:126. When an update process is begun, the locations specified in list 403 wilt be polled 502 in order until one is found which contains the required DeltaCatalogs 404.
The DeltaUpdater 126 builds a "DeltaDirectory" 408, which is a list of available DeltaCatalogs 404 at the specified location: For transfer mechanisms which support querying of a file directory, such as HTTP, FTP and file servers, the DeltaDirectory 408 is constructed with the information returned by such queries. For these transfer mechanisms, the DeltaCatalog 404 source and destination state information is contained in the name of each DeltaCatalog file.
DeltaCatalogs 404 are named according to a scheme where the first four characters specify a source state, the next four characters specify a destination state, and the file extension is "cat."
For NNTP, the DeltaUpdater 126 retrieves headers for available messages, and looks for DeltaCatalog information in the headers. The DeltaCatalog information specifies that the message is a DeltaCatalog 404, and specifies the source and destination states are for the DeltaCatalog 404.
After retrieving the source state and destination state for each available DeltaCatalog 404, the DeltaUpdater 126 organizes this information in the DeltaDirectory 408 by sorting 504 the DeltaCatalogs 404 first by source state, and next by reverse destination state. The DeltaCatalogs 404 of the preferred transport mechanism are used, if possible.
Otherwise.
DeltaCatalogs 404 of alternate transport mechanisms are used. This ordering of the DeltaCatalog 404 information allows the DeltaUpdater 126 to move through the DeltaDirectory 408 efficiently, finding the URL of each DeltaCatalog 404 with the necessary source state, and the farthest destination state which does not exceed the desired ending state.
The DeltaUpdater 126 determines 506 the current state of the application to be updated. and the desired ending state of the application. The application can supply its current state to the DeltaUpdater 126, but the DeltaUpdater 126 needs other information to determine the desired ending state. The method by which the DeltaUpdater 126 determines the desire ending state of the application is addressed below.
The sequential set 412 of DeltaPackages 122 is cleared out 508, in preparation for the determination of the set 412. The DeltaUpdater 126 moves through the DeltaDirectorv 408 sequentially in the loop comprising steps 510, 512, and 514 to find the first DeltaCatalog 404 in the DeltaDirectory 408 which has the current state as a source state. The DeltaUpdater 126 then moves through the DeltaDirectory 408 from this DeltaCatalog 404 to fmd the DeltaCatalog 404 which has the farthest destination state which is not beyond the desired ending state (loop 516, 518, and 520). If all of the DeltaCatalogs 404 which have the current state as a source state have a destination state which is beyond the desired ending state, then the update will fail 520.
When a DeltaCatalog 404 is identified at 516 which has a destination state which is not beyond the desired ending state, the DeltaCatalog 404 is requested 524 from the appropriate source 400 or 402. After the requested DeltaCatalog 404 is received 526, the DeltaCatalog 404 is processed 528, as described above, to determine an incremental set of DeltaPackages 2~ 122 which are appended to the sequential set 412. The current state of the application is then set 530 to the destination state of this DeltaCatalog 404, and if that state is not the desired ending state 532 the processing continues at step 514, and another DeltaCatalog 404 is determined.
When the full sequential set of DeltaPackages 122 necessary for an update are determined 532, the DeltaUpdater 126 requests 534 each needed DeltaPackage 122. The DeltaUpdater 126 receives 536 the requested DeltaPackages 122 using the appropriate protocol, then uses the digital signature to verify that the DeltaPackages 122 are authentic and WO 99/49391 PCTlUS99/06619 have not been altered. Each DeltaPackage 122 retrieved is executed in sequence 538, transforming the application from the beginning state to the desired ending state. In other embodiments, the DeltaUpdater 126 retrieves all of the DeltaPackages 122 specified by a DeltaCatalog 404 before moving on to the next DeltaCatalog 404.
DeltaDirectives The beginning state of an application update is determined by the DeltaUpdater with reference to the application itself, which will carry some designation of the current state. The desired ending state, however, is not necessarily as easy to identify. One possibility would be for the DeltaUpdater to simply update the application to the latest state for which DeltaCatalogs are available. In many situations, however, it may not be desirable to the user of a soft<vare application to update the application to the latest available state. For example, in corporate settings, Information Services departments may wish to test out and verify the stability of a version of a software application before allowing the applications owned by the corporation to be updated to that version. This is often the case when the update is a major I S revision. Also, some networked computer systems may require that all copies of a particular application be at exactly the same state. One solution would be for an Information Services department to control the availability of DeltaCatalogs 404. Alternatively, it is desirable in some situations to utilize "DeltaDirectives," which are issued in connection with a given computer or network, specifying to which destination state an update is allowed. A
DeltaDirective is a file or NNTP message containing a single value, the allowed destination state. The filename or NNTP message header identifies the file or NNTP message as a DeltaDirective. The location for such DeltaDirectives is made available to the DeltaUpdater before the update procedure is begun. As illustrated in Figure 7, the DeltaUpdater 126 identifies the latest available DeltaDirective 405 in the prescribed location, obtains the DeltaDirective 405, and reads the desired ending state from it. This desired ending state is used by the DeltaUpdater 126 in steps 506, 516, and 532 of Figure 8. The publisher of the updates may make available general DeltaDirectives 405 which specify the latest available state. The DeItaUpdater for any given computer may be set to look to the DeltaDirectives 405 issued by the software publisher or those issued by some other authority, such as an Information Services department.
The above description is included to illustrate the operation of the prefenred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above description, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the present invention.
APPENDIX A
DPML.DTD
<?XML version="1.0"?>
<!DOCTYPE DeltaCatalog [
<!ELEMENT DeltaCataiog (Product I Package I OS I CPU I Language)*>
<!ATTLIST DeltaCatalog from CDATA #IMPLIED>
<!ATTLIST DeltaCatalog to CDATA #REQUIRED>
<!ELEMENT Produce (Product I Package I OS I CPU I Language)*>
<!ATTLIST Produce name CDATA #IMPLIED>
<!ATTLIST Product version CDATA #IMPLIED>
<!ATTLIST Product ID CDATA #IMPLIED>
<!ATTLIST Product maxversion CDATA #IMPLIED>
1$ <!ATTLIST Product minversion CDATA #IMPLIED>
<!ELEMENT OS (Product I Package I OS I CPU I Language)*>
<!ATTLIST OS name CDATA #IMPLIED>
<!ATTLIST OS version CDATA #IMPLIED>
<!ATTLIST OS maxversion CDATA #IMPLIED>
<!ATTLIST OS minversion CDATA #IMPLIED>
<!ELEMENT CPU (Product I Package I OS I CPU I Language)*>
<!ATTLIST CPU name CDATA #IMPLIED>
<!ELEMENT Language (Product I Package I OS ( CPU I Language)*>
<!ATTLIST Language name CDATA #IMPLIED>
<!ATTLIST Language locale CDATA #IMPLIED>
<!ELEMENT Package EMPTY>
<!ATTLIST Package ID CDATA #REQUIRED>
l>
APPENDIX B
CATALOG. CAT
<?XML version="1.~" ?>
<!DOCTY=? DeltaCatalog system "http://www.symantec.com/DPML.DTD">
<DeltaCatalog from="1" to="8">
<product name="NAV" ID="12395">
<OS name="Win95">
<product version="1.0">
<package IC="1025">
</product>
<Product version="2.0">
<Package ID="1026">
</Product>
1$ </OS>
<OS name="WinNT">
<Product version="1.0">
<packact~ IC="1027">
</Product>
<Product version="2.0">
<CPU name="x86">
<OS vesion="3.51">
<Package ID="1100">
</OS>
2$ <OS version="4.0">
<Package ID="250">
</OS>
</CPU>
<CPU name="Alpha">
<Package ID="987">
</CPU>
</Product>
</OS>
<Language name="English" locale="NorthAmerica">
<Package ID="766">
</Language>
<Language name="French" locale="Canada">
<Package ID="4775">
</Language>
</Product>
</DeltaC~talog>
(computer programs and data files associated with the programs) frequently. For some types of software applications, such as virus protection software, these updates are particularly frequent. V irus 1 S protection software applications are designed to detect computer viruses on a computer system, and may also remove viruses which are found. An example of such a software application is Norton Anti-Virus, published by Symantec Corporation of Cupertino, California. Because these virus protection software applications rely on data about specific viruses, and new viruses are constantly being written to avoid current virus detection capabilities, it is necessary to update virus protection software applications on a regular basis to account for the newest viruses. Frequent updating of data files is also necessary for some database publishers, who must put up-to-date information in their databases, and remove obsolete information therefrom. Periodic updating of general software applications to expand capabilities and eliminate "bugs" is also common.
Currently, several methods are used to update software applications. The simplest of these is to distribute one entire software application to replace an older one. This method, the "full update" method, is simple, but expensive and inconvenient. Typically the software is distributed on some type of removable media, such as floppy disks or CD-ROMs, which are costly to produce and distribute. The time an end user must wait for the removable medium to arnve and the time it takes for the software application to install itself on a computer system are inconvenient. This inconvenience is compounded where updates occur frequently.
Because of the large size of software applications it is generally not feasible to distribute such updates over computer networks, such as the Internet. When full updates are distributed over the Internet, they often cause such high loads on servers that other users suffer slow-downs on the network, and the servers.have trouble meeting the demands.
In order to bypass many of the problems associated with this type of software updating, some software publishers distribute "incremental updates." These updates do not contain entire software applications, but rather only that information necessary to transform a given version of a software application to a newer version. Among the methods available to perform such incremental software updating is binary patching, performed by programs such as RTPatch, published by Pocket Soft, Inc. A binary patcher replaces only those binary bits of a software application which are different in a newer version. Because most software updates involve changes to only a small portion of a software application, a binary patcher needs, in addition to the old software application, only a small data file including the differences between the two versions. The smaller data files distributed for a binary patch update are often less than 1 % of the size of a full update, taking advantage of the large amount of redundancy in the two versions.
The use of incremental update methods allows for smaller updates which can be distributed by means that are not conducive to the distribution of full updates, such as distribution over the Internet. The smaller incremental updates also make distribution by floppy disk more feasible where a full update would have required many disks, and an incremental update may require only one. However, incremental update methods introduce another problem: the incremental update is specifically useful for updating only one particular version of a software application to another particular version. When updates occur frequently, as with virus protection software applications, end users may often update from an arbitrarily old version to the newest version, skipping over several previously released versions. An incremental update for the newest version of a software application will update only from the most recent version, however.
One solution to this problem has been for software publishers to group a number of binary patch data files together into one distribution. The user of an arbitrarily old version can then apply each incremental update, one at a time, to update to the newest version. However, the number of incremental updates may be large, due to the fact that the grouping covers a large number of versions. The benefits of smaller distributed update files begin to disappear, as the size of the grouped-together incremental updates grows. This method of updating applications can also be cumbersome, as a series of update patches need to be selected from the group and applied to the software application one after another.
Another solution to the problem of incremental update version-specificity has been to create a unique patch file for transforming every previous version of the application to the most current version. Some users may not wish to update their software applications to the most current version, however, for a number of reasons. Some may be within a corporate setting, where an information services department allows updates only to versions it has had a chance to test and approve. Others may have older computer systems which do not support the increased resource requirements of the newest version of an application. For these reasons, publishers of software updates using this method must generally keep updates available from every previous version of an application to a large number of more recent versions. This results in a geometrically growing number of update patch files to produce, store and maintain for users. In the case of publishers who update their applications frequently, such as publishers of virus-protection software applications, this may quickly become untenable.
One alternative to the methods described above is the use of "push"
technology, in which servers maintain databases of what versions of a software application each user has The servers then send the necessary updates to each user, as they become available. This system requires "smart" servers, however, to monitor user configurations, determine what each user needs, and send the appropriate update information. This results in a server-intensive system which can cause a drain on server resources comparable to that experienced in the full update scheme, when many users are simultaneously requesting fill updates.
What is needed is a system for updating software applications from an arbitrary first version to an arbitrary second version which does not require a large amount of information to be stored and maintained by a software publisher, does not require the user to acquire a large amount of data to perform such an update, and does not require the use of "smart" servers.
SUMMARY OF THE INVENTION
The present invention is a method and apparatus for distributive the appropriate incremental software update information to users. A software publisher (118) provides update patches ( 122) which will update users' software applications ( 110) from one state to another.
The update patches (122) are 'tiered.' Update patches on the first tier (200) update from a given application state to the subsequent application state. Update patches on the second tier (202) update an application from a given state to the state which is two versions later. The tier of an update patch indicates how many individual updates are spanned by the patch.
By selectively providing tiered update patches, software publishers (118) can facilitate quick, efficient updating of users' applications ( 110) without producing and maintaining large numbers of update patches (122). These update patches ( 122) may be provided to users simultaneously through a variety of distribution channels ( 124), since a "smart server" is not necessary to provide users with the needed update patches (122). This allows for selective redundancy. as update patches (122) which are likely to be needed by many users may be made available through more of the available distribution channels (124) than others, providing a robust distribution system.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other more detailed and specific objects and features of the present invention are more fully disclosed in the following specification, reference being had to the accompanying drawings, in which:
Figure 1 is a block diagram of a first embodiment of the present invention, in which a software application 110 on a user's computer 116 is updated with incremental update patches 122 from a remote source 118.
Figure 2 is an illustration of the relation of various tiers of updates to a series of application states in the present invention.
Figure 3 is an illustration of an example of the use of mufti-tiered incremental updates to perform a software application update according to the present invention.
Figure 4 is an illustration of an example of a sub-optimal software application update using incremental updates.
Figure 5 is an illustration of an example of a publishing schedule for mufti-tiered incremental updates which meets the necessary condition for optimal updates according to the present invention.
Figure 6 is an illustration of an updating program 126 using a catalog 404 to determine an appropriate sequential set of update packages 412 based on attributes of an application 110.
Figure 7 is an illustration of an updating program 126 constructing a sorted directory 408 of available catalogs 404 from different sources 400 and 402.
WO 99/49391 PCT/US99/06b19 Figures 8a and 8b are a flowchart showing how an updating program determines what update patches need to be applied to effect an update, and how the updating program carries out the updating.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
S In one embodiment, the present invention may be implemented as an update mechanism for a virus protection software application. In other embodiments, the present invention may be used to update general computer readable files, which may include data files, program files, database files, graphics files, or audio files. For illustrative purposes only, the invention will be described as embodied in an update mechanism for virus protection software.
Referring to Figure 1, a virus protection software application 110 which incorporates a number of virus detecting routines 112, and utilizes a number of data files containing virus information 114, is installed on a user's computer 116. Because of the rate at which new viruses are created. it is desirable to update the virus protection software applications on the user's computer frequently. These updates could take place as often as daily, or even more frequently if desired. Generally, these updated applications 110 will include only small changes to the data files I14, but sometimes larger changes to the virus detecting routines I12 will also be included.
In order to fully describe the embodiment of the present invention, it is first necessary to describe DeltaPackages, DeltaCatalogs, and DeltaDirectories.
DeltaPackages Each time an updated software application 110 is produced by the virus protection software publisher, the updated form of the software application constitutes a new version.
The software publisher uses an incremental update builder, such as binary patch file builder 120, to produce at least one incremental update, such as binary patch file 122, which can transform a previous version of the software application to the cturent version. A binary patch file builder 120 is a program which takes two versions of a software application, for example versions A and B, and produces a binary patch file, 122, which can be used with version A of the software application to produce version B. In this example, version A
would be the "source" state and version B would be the "destination" state of the application. This binary patch file 122 can either be an executable file which acts directly on version A of the software application, or it can be a data file which is used by a separate binary patch program (not shown) to transform version A of the software application to version B. The binary patch files 122 are stored on an update data source 124 (a "server") which makes the patch files 122 available to an updater program 126 (a "client"). The updater program 126 determines what patch files 122 are necessary, retrieves them and applies them to the application to be updated 110. In the illustrative embodiment, the incremental update files are binary patch files which are digitally signed compressed executable modules, and the Java ARchive (JAR) platform-independent file format, available from Sun Microsystems, is used for this purpose. Because they are digitally signed, the authenticity of the updates can be ensured.
When executed, the incremental update file automatically transforms a software application from a source state to a destination state. These self contained executable incremental update files conforming to the JAR format are referred to as "DeltaPackages" 122, and are one example of what is referred to herein as an "update patch".
In Figure 2, a series of application states are given, designated state A
through state S.
Each application state is a software application version which is produced by the software publisher later in time than a version with an alphabetically earlier letter designation. The DeltaPackages 122, which are referred to as "tier 1" DeltaPackages 200, are so named because they each effect a transition from an application state which is only one version earlier than the destination state. There is a tier 1 DeltaPackage 200 for updating to each application state other than the initial application state, A. The software publisher may produce higher tier DeltaPackages 122, such as "tier 3" DeltaPackages 202 and "tier 9"
DeltaPackages 204. A tier 3 DeltaPackage 202 is used to transform an application from a source state three versions earlier than the destination state, and a tier 9 DeltaPackage 204 is used to transform an application from a source state nine versions earlier than the destination state. Many other tiers of DeltaPackages 122 may be produced, but the benefits of additional tiers must be weighed against the costs, described below. In Figure 2, tier 1 DeltaPackages 200 are produced for each new version, tier 3 DeltaPackages 202 are produced for every third version, and tier 9 DeltaPackages 204 are produced for every ninth version.
For illustrative purposes, each DeltaPackage 122 is given a designation which is "0"
followed by two letters. The first letter indicates the application source state upon which the DeItaPackage 122 works and the second letter indicates the application destination state produced. For the case where there are not multiple "flavors" of the application which need to be updated in parallel, a relatively simple process is employed to update the application.
DeltaPackages 122 are applied to a user's software application incrementally, beginning with the highest tier DeltaPackage 122 available which has a source state equal to the current state of the application, and a destination state no later than the desired ending state. After the DeltaPackage 122 is applied, and the application is updated to the destination state of the DeltaPackage 122, another DeltaPackage 122 is chosen in the same manner, with the new application state providing the source state of the next DeltaPackage 122.
This continues until the desired ending state of the application is reached.
Figure 3 illustrates this procedure for a case in which it is desired to transform an application of state F to an application of state T. Following the procedure described above, such a transformation is accomplished through only four incremental updates, from F to G to J
to S to T. Each time a new DeltaPackage 122 is to be selected, the one chosen is the highest tier DeltaPackage 122 with the current application state as a source state, and a destination state which does not exceed the desired ending state.
When fewer incremental updates are required to perform a given transformation, fewer DeltaPackages 122, and therefore less information, needs to be transferred to the application.
The procedure described above produces a desired transformation using the smallest number of available DeltaPackages 122, as long as one condition is met: no available DeltaPackage 122 may have a source state which is between the source and destination states of an available DeltaPackage 122 with a lower tier. As long as this condition is met, then the procedure described above will perform an optimum transformation, using the smallest number of available DeltaPackages 122 to get from the beginning state to the desired ending state. If the condition is not met then the procedure described above may result in a transformation which uses more of the available DeltaPackages 122 than necessary. An example of a sub-optimal transformation is illustrated in Figure 4. In that case, a transformation from state G to state S
uses four DeltaPackages 122 (OGJ, AJM, NVIP and APS), when it need only use three (OGH, CHI, and AIS). Because the AIS DeltaPackage 122 has a source state (I) which is between the source and destination states of a lower tier DeltaPackage (~GJ), the DIS
DeltaPackage 122 violates the above condition, and a sub-optimal set of DeltaPackages 122 is used. In practice, a software publisher may easily ensure that the available DeltaPackages 122 meet this condition, since each DeltaPackage I22 is produced later in time than DeltaPackages 122 with earlier destination states. In the above example, before issuing DeltaPackage DIS, the publisher would eliminate DeltaPackage ~GJ and possibly replace it with another, such as DeltaPackage ~GI.
In the example of Figure 3, if only the tier 1 DeltaPackages 200 had been available, fourteen DeltaPackaees 122 would have been required for the transformation, instead of four, and much unnecessary information would have been transferred to the application. The total number of DeltaPackages 122 which would have been produced by the publisher, however, would have been smailer, the higher tier DeltaPackages 122 not having been produced. On the other hand. if a tier 14 DeItaPackage 1Z2 designated OFT had been available, only one DeltaPackage 122 would have been required, and very little information would have been transferred to the user. However, the availability of a DeltaPackage 122 which accomplishes any particular transformation in one step can be assured only by producing individual DeltaPacka~es I22 from every source state to every destination state, which requires a number of DeltaPackages 122 approaching N' (where N is the number of file states).
Producing and maintaining such a large number of individual DeltaPackages 122 is not feasible in many situations. as explained above. These considerations must be considered by a software publisher in determining the most efficient DeItaPackage 122 publishing schedule. For the illustrative embodiment, it was determined that providing DeltaPackages 122 of tiers 1, 3 and 9 would be most efficient.
The tiers of DeltaPackages 122 produced do not need to be published according to any fixed schedule, but rather may be determined as new updates become available.
In Figure 5 an irregular publishing schedule of DeltaPackages 122 is shown. There are four separate tiers of DeltaPackages 122 available with J as a source state. The decision to create so many DeltaPackages I22 with the same source state may be.based on the fact that many copies of the application in the J state are known to be at large. Many publisher-specific, application-specific, and information transport mechanism-specific factors will affect the desirability of a publishing schedule for DeltaPackages 122.
DeltaCatalogs Sofrware publishers often produce different "flavors" of a single software application, directed to different computer architectures, different operating systems, and users who speak different languages. The scheme for publishing incremental updates laid out above is adequate for the case in which there is only one flavor of a software application. For the more general case of several application flavors, however, some additional mechanisms can be used to handle the additional complexities of parallel updating. A system which addresses these complexities is described in the second illustrative embodiment of the present invention.
In the case of virus definition updates, there are often updates which are not operating system-specific, and sometimes there are updates which are not even computer architecture-specific. Other times, updates are specific to these, and other, categories. A
single update DeltaPackage 122 may be useful to update some flavors of an application, but not others. To handle these complexities, update catalogs, referred to as "DeltaCatalogs,"
are utilized. These update catalogs are another example of what are referred to herein as "update patches." Rather than having a single DeltaPackage 122 correspond to each incremental update (i.e. "HIS") as above, a DeltaCataiog corresponds to each incremental update (i.e. "DIS").
Each DeltaCatalog has an associated source state and an associated destination state, and specifies the necessary update information by specifying which DeltaPackages 122 should be used by each flavor of the application to update from the source state to the destination state. In one embodiment, DeltaPackages 122 are given unique IDs which do not conform to the "DAB"
format used above for illustrative purposes, and are specified by the DeItaCatalogs using these unique IDs.
With DeltaCatalogs substituted for DeltaPackages 122, the general scheme described above is utilized.
There are a number of different ways DeltaCatalogs can be implemented. In this embodiment, the Extensible Markup Language (XML) standard is used to create a document type definition. The XML standard is available from W3C Publications, World Wide Web Consortium, Massachusetts Institute of Technology, Laboratory for Computing Sciences, NE43-356, 545 Technology Square, Cambridge, MA 02139. An example document type definition corresponding to the XML standard, referred to as DPML (for DeltaPackage Markup Language), is given in Appendix A. In this document type definition, there are a number of types of entries a DeltaCatalog may contain. These types are Product (the type of software application), Package (a specific DeltaPackage 122), OS (operating system), CPU
(computer architecture) and Language (the language spoken by the users of the software application). An entry of any of these types except Package may in turn contain entries of the types Product, Package, OS, CPU or Language. None of the entry types may contain a DeltaCatalog, and the Package must contain an "ID" which corresponds to a specific DeltaPackage 122. Also, the "to", or destination state, data field and the "from", or source state, data field must be given for a DeltaCatalog.
An example of a DeltaCatalog contained in a file written to conform to the XML
format is given in Appendix B. In the DeltaCatalog file itself, the document type definition for "DPML" is specified by including a uniform resource locator (URL) pointing to the location of a current specification of the document type definition. Alternatively, the data type definition may be included in the file explicitly. A software application to be updated contains the attributes of current state, Product, OS, CPU, and Language, and has access to the desired ending state of the software application, as described below. In order to determine a sequential set of DeltaPackages 122 which need to be applied to the software application to effect the transformation from the current state to the desired ending state, an updating mechanism, referred to as a "DeltaUpdater" is used. The DeltaUpdater may be a separate program. or may be part of the software application itself. It goes through the same basic procedure outlined above, with DeltaCatalogs taking the place of DeltaPackages 122. The DeltaCatalog of the highest tier available which has a "from" field matching the application's curreflt state and which has a "to" field which does not exceed the ending state is selected by the DeltaUpdater.
The DeltaCatalog is then processed, with the DeltaUpdater processing only those sub-entries contained within entries with attributes which match those of the application.
An example is 1 ~ illustrated in Figure 6. The DeltaCatalog 404 contains a simplified form of the information contained in the DeltaCatalog file of Appendix B. Application 110 has the attributes of "NAV version 2.0 running on Windows NT on an alpha computer using North American English." The DeitaUpdater 126 would process only Package )D's "487" and "766," as all other Package entries correspond to different attributes. Those DeItaPackages I22 which correspond to these two IDs would then make up a sequential set 412 of DeltaPackages 122 to be applied to application 110 in the order they were encountered in DeltaCatalog 404. When applied to application 110, the DeltaPackages 122 of set 412 transform application 110 from state 1 to state 8, the states given in the "from" and "to" fields of DeltaCatalog 404. If the desired ending state were still later than state 8, then this procedure would again be applied to select and process another DeltaCatalog 404, one which has a "from" value of 8.
DeltaDirectories A number of transfer mechanisms are available to a DeltaUpdater for retrieving DeltaCatalogs and DeltaPackages 122. Among these are the NNTP Usenet server protocol, available from Internic as "Request For Comments 977"; the HTTP protocol, available from Internic as "Request For Comments 1945"; the FTP protocol, available from Internic as "Request For Comments 959"; and direct access to a "file server" using a protocol such as the Universal Naming Convention (UNC). A file server may be, among other things, internal disk media, removable disk media, or a network resource. Other distribution mechanisms are currently available and more will likely be available in the future. All that is required of a transfer mechanism is that the mechanism be able to supply computer readable data upon request. The present invention utilizes so called "dumb media," meaning that the medium supplying the requested information need not interact with the DeltaUpdater beyond simply supplying requested data. Specifically, "smart servers," such as those used in "push"
technology, are not necessary. A smart server determines what update information is necessary, given information about the state of the software application, and then supplies that information. The described transfer mechanisms allow DeltaCatalogs and DeltaPackages 122 to be retrieved from "catalog sources" and "update data sources" on which they are stored.
A typical system embodying the present invention will have available more than one of the mentioned transfer mechanisms, as illustrated in Figure 7. A DeltaUpdater 126 will have access to a list 403 of locations, specified as URLs, where needed data may be found. In general, these URLs will specify a number of NNTP news-servers with news-groups, HTTP
servers with directory paths, FTP servers with directory paths, and file servers with directory paths. In the embodiment illustrated in Figure 7, an NNTP server 400 and a file server 402 contain available DeltaCatalogs 404. The flowchart of Figure 8 shows the steps carried out by the DeltaUpdate>:126. When an update process is begun, the locations specified in list 403 wilt be polled 502 in order until one is found which contains the required DeltaCatalogs 404.
The DeltaUpdater 126 builds a "DeltaDirectory" 408, which is a list of available DeltaCatalogs 404 at the specified location: For transfer mechanisms which support querying of a file directory, such as HTTP, FTP and file servers, the DeltaDirectory 408 is constructed with the information returned by such queries. For these transfer mechanisms, the DeltaCatalog 404 source and destination state information is contained in the name of each DeltaCatalog file.
DeltaCatalogs 404 are named according to a scheme where the first four characters specify a source state, the next four characters specify a destination state, and the file extension is "cat."
For NNTP, the DeltaUpdater 126 retrieves headers for available messages, and looks for DeltaCatalog information in the headers. The DeltaCatalog information specifies that the message is a DeltaCatalog 404, and specifies the source and destination states are for the DeltaCatalog 404.
After retrieving the source state and destination state for each available DeltaCatalog 404, the DeltaUpdater 126 organizes this information in the DeltaDirectory 408 by sorting 504 the DeltaCatalogs 404 first by source state, and next by reverse destination state. The DeltaCatalogs 404 of the preferred transport mechanism are used, if possible.
Otherwise.
DeltaCatalogs 404 of alternate transport mechanisms are used. This ordering of the DeltaCatalog 404 information allows the DeltaUpdater 126 to move through the DeltaDirectory 408 efficiently, finding the URL of each DeltaCatalog 404 with the necessary source state, and the farthest destination state which does not exceed the desired ending state.
The DeltaUpdater 126 determines 506 the current state of the application to be updated. and the desired ending state of the application. The application can supply its current state to the DeltaUpdater 126, but the DeltaUpdater 126 needs other information to determine the desired ending state. The method by which the DeltaUpdater 126 determines the desire ending state of the application is addressed below.
The sequential set 412 of DeltaPackages 122 is cleared out 508, in preparation for the determination of the set 412. The DeltaUpdater 126 moves through the DeltaDirectorv 408 sequentially in the loop comprising steps 510, 512, and 514 to find the first DeltaCatalog 404 in the DeltaDirectory 408 which has the current state as a source state. The DeltaUpdater 126 then moves through the DeltaDirectory 408 from this DeltaCatalog 404 to fmd the DeltaCatalog 404 which has the farthest destination state which is not beyond the desired ending state (loop 516, 518, and 520). If all of the DeltaCatalogs 404 which have the current state as a source state have a destination state which is beyond the desired ending state, then the update will fail 520.
When a DeltaCatalog 404 is identified at 516 which has a destination state which is not beyond the desired ending state, the DeltaCatalog 404 is requested 524 from the appropriate source 400 or 402. After the requested DeltaCatalog 404 is received 526, the DeltaCatalog 404 is processed 528, as described above, to determine an incremental set of DeltaPackages 2~ 122 which are appended to the sequential set 412. The current state of the application is then set 530 to the destination state of this DeltaCatalog 404, and if that state is not the desired ending state 532 the processing continues at step 514, and another DeltaCatalog 404 is determined.
When the full sequential set of DeltaPackages 122 necessary for an update are determined 532, the DeltaUpdater 126 requests 534 each needed DeltaPackage 122. The DeltaUpdater 126 receives 536 the requested DeltaPackages 122 using the appropriate protocol, then uses the digital signature to verify that the DeltaPackages 122 are authentic and WO 99/49391 PCTlUS99/06619 have not been altered. Each DeltaPackage 122 retrieved is executed in sequence 538, transforming the application from the beginning state to the desired ending state. In other embodiments, the DeltaUpdater 126 retrieves all of the DeltaPackages 122 specified by a DeltaCatalog 404 before moving on to the next DeltaCatalog 404.
DeltaDirectives The beginning state of an application update is determined by the DeltaUpdater with reference to the application itself, which will carry some designation of the current state. The desired ending state, however, is not necessarily as easy to identify. One possibility would be for the DeltaUpdater to simply update the application to the latest state for which DeltaCatalogs are available. In many situations, however, it may not be desirable to the user of a soft<vare application to update the application to the latest available state. For example, in corporate settings, Information Services departments may wish to test out and verify the stability of a version of a software application before allowing the applications owned by the corporation to be updated to that version. This is often the case when the update is a major I S revision. Also, some networked computer systems may require that all copies of a particular application be at exactly the same state. One solution would be for an Information Services department to control the availability of DeltaCatalogs 404. Alternatively, it is desirable in some situations to utilize "DeltaDirectives," which are issued in connection with a given computer or network, specifying to which destination state an update is allowed. A
DeltaDirective is a file or NNTP message containing a single value, the allowed destination state. The filename or NNTP message header identifies the file or NNTP message as a DeltaDirective. The location for such DeltaDirectives is made available to the DeltaUpdater before the update procedure is begun. As illustrated in Figure 7, the DeltaUpdater 126 identifies the latest available DeltaDirective 405 in the prescribed location, obtains the DeltaDirective 405, and reads the desired ending state from it. This desired ending state is used by the DeltaUpdater 126 in steps 506, 516, and 532 of Figure 8. The publisher of the updates may make available general DeltaDirectives 405 which specify the latest available state. The DeItaUpdater for any given computer may be set to look to the DeltaDirectives 405 issued by the software publisher or those issued by some other authority, such as an Information Services department.
The above description is included to illustrate the operation of the prefenred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above description, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the present invention.
APPENDIX A
DPML.DTD
<?XML version="1.0"?>
<!DOCTYPE DeltaCatalog [
<!ELEMENT DeltaCataiog (Product I Package I OS I CPU I Language)*>
<!ATTLIST DeltaCatalog from CDATA #IMPLIED>
<!ATTLIST DeltaCatalog to CDATA #REQUIRED>
<!ELEMENT Produce (Product I Package I OS I CPU I Language)*>
<!ATTLIST Produce name CDATA #IMPLIED>
<!ATTLIST Product version CDATA #IMPLIED>
<!ATTLIST Product ID CDATA #IMPLIED>
<!ATTLIST Product maxversion CDATA #IMPLIED>
1$ <!ATTLIST Product minversion CDATA #IMPLIED>
<!ELEMENT OS (Product I Package I OS I CPU I Language)*>
<!ATTLIST OS name CDATA #IMPLIED>
<!ATTLIST OS version CDATA #IMPLIED>
<!ATTLIST OS maxversion CDATA #IMPLIED>
<!ATTLIST OS minversion CDATA #IMPLIED>
<!ELEMENT CPU (Product I Package I OS I CPU I Language)*>
<!ATTLIST CPU name CDATA #IMPLIED>
<!ELEMENT Language (Product I Package I OS ( CPU I Language)*>
<!ATTLIST Language name CDATA #IMPLIED>
<!ATTLIST Language locale CDATA #IMPLIED>
<!ELEMENT Package EMPTY>
<!ATTLIST Package ID CDATA #REQUIRED>
l>
APPENDIX B
CATALOG. CAT
<?XML version="1.~" ?>
<!DOCTY=? DeltaCatalog system "http://www.symantec.com/DPML.DTD">
<DeltaCatalog from="1" to="8">
<product name="NAV" ID="12395">
<OS name="Win95">
<product version="1.0">
<package IC="1025">
</product>
<Product version="2.0">
<Package ID="1026">
</Product>
1$ </OS>
<OS name="WinNT">
<Product version="1.0">
<packact~ IC="1027">
</Product>
<Product version="2.0">
<CPU name="x86">
<OS vesion="3.51">
<Package ID="1100">
</OS>
2$ <OS version="4.0">
<Package ID="250">
</OS>
</CPU>
<CPU name="Alpha">
<Package ID="987">
</CPU>
</Product>
</OS>
<Language name="English" locale="NorthAmerica">
<Package ID="766">
</Language>
<Language name="French" locale="Canada">
<Package ID="4775">
</Language>
</Product>
</DeltaC~talog>
Claims (22)
1. A system for transforming a computer readable file of a beginning state to a computer readable file of an ending state, where the beginning state and the ending state are both states within a sequence of states associated with the computer readable file, the system comprising:
at least two update patches, each update patch having a first state and a second state associated therewith, the first state and the second state of each update patch being states within the sequence of states, the first state of each update patch preceding in the sequence of states the second state of that update patch, and each update patch specifying information about differences between the first state and the second state associated with that update patch;
at least one update data source, each update data source having access to at least one of the update patches, each update data source being disposed to receive a request which is associated with one of the update patches, for transmitting the update patch associated with the request; and a client coupled to each update data source and having access to the computer readable file, disposed to receive transmitted update patches from each update data source, for determining a sequential set of update patches which specify information for transforming the computer readable file from the beginning state to the ending state.
at least two update patches, each update patch having a first state and a second state associated therewith, the first state and the second state of each update patch being states within the sequence of states, the first state of each update patch preceding in the sequence of states the second state of that update patch, and each update patch specifying information about differences between the first state and the second state associated with that update patch;
at least one update data source, each update data source having access to at least one of the update patches, each update data source being disposed to receive a request which is associated with one of the update patches, for transmitting the update patch associated with the request; and a client coupled to each update data source and having access to the computer readable file, disposed to receive transmitted update patches from each update data source, for determining a sequential set of update patches which specify information for transforming the computer readable file from the beginning state to the ending state.
2. The system of claim 1, wherein:
the ending state is specified by a directive file available to the client.
the ending state is specified by a directive file available to the client.
3. The system of claim 1, wherein:
at least one update data source is selected from the group consisting of an NNTP
Usenet server, an HTTP server, an FTP server, and a file system server which is locally accessible to the client.
at least one update data source is selected from the group consisting of an NNTP
Usenet server, an HTTP server, an FTP server, and a file system server which is locally accessible to the client.
4. The system of claim 1, wherein:
the update patches are binary patches which include binary differences between the first state and the second state.
the update patches are binary patches which include binary differences between the first state and the second state.
5. The system of claim 1, wherein:
the sequential set contains that number of update patches which is the smallest number of accessible update patches necessary for the client to transform the computer readable file from the beginning state to the ending state.
the sequential set contains that number of update patches which is the smallest number of accessible update patches necessary for the client to transform the computer readable file from the beginning state to the ending state.
6. The system of claim 1, wherein:
each update patch has a tier associated with it, the tier being a number which corresponds to the number of states between the first state and the second state associated with the update patch; and at least one of the update patches has a tier which is different from the tier of another update patch.
each update patch has a tier associated with it, the tier being a number which corresponds to the number of states between the first state and the second state associated with the update patch; and at least one of the update patches has a tier which is different from the tier of another update patch.
7. The system of claim 6, wherein:
the client transmits a request associated with each update patch of the sequential set to the update data source which has access to that update patch, receives each requested update patch from the update data source which has access to the requested update patch, and updates the computer readable file from the beginning state to the ending state with the update patches received; and the update patches are binary patches which include binary differences between the first state and the second state.
the client transmits a request associated with each update patch of the sequential set to the update data source which has access to that update patch, receives each requested update patch from the update data source which has access to the requested update patch, and updates the computer readable file from the beginning state to the ending state with the update patches received; and the update patches are binary patches which include binary differences between the first state and the second state.
8. The system of claim 1, wherein:
the client transmits a request associated with each update patch of the sequential set of update patches to the update data source which has access to that update patch, receives each requested update patch from the update data source which has access to the requested update patch, and updates the computer readable file from the beginning state to the ending state with the update patches received.
the client transmits a request associated with each update patch of the sequential set of update patches to the update data source which has access to that update patch, receives each requested update patch from the update data source which has access to the requested update patch, and updates the computer readable file from the beginning state to the ending state with the update patches received.
9. The system of claim 8, wherein:
at least one of the update patches is a catalog which specifies at least one other file which specifies information about differences between two states.
at least one of the update patches is a catalog which specifies at least one other file which specifies information about differences between two states.
10. The system of claim 9, wherein:
each catalog has a tier associated with it, the tier being a number which corresponds to the number of states between the first state and the second state associated with the catalog; and at least one of the catalogs has a tier which is different from the tier of another catalog.
each catalog has a tier associated with it, the tier being a number which corresponds to the number of states between the first state and the second state associated with the catalog; and at least one of the catalogs has a tier which is different from the tier of another catalog.
11. The system of claim 10, wherein:
the ending state is specified by a directive file available to the client.
the ending state is specified by a directive file available to the client.
12. The system of claim 8, wherein:
at least one of the update patches is a catalog which specifies at least one binary patch file which includes information about binary differences between two states.
at least one of the update patches is a catalog which specifies at least one binary patch file which includes information about binary differences between two states.
13. The system of claim 12, wherein:
each catalog has a tier associated with it, the tier being a number which corresponds to the number of states between the first state and the second state associated with the catalog; and at least one of the catalogs has a tier which is different from the tier of another catalog.
each catalog has a tier associated with it, the tier being a number which corresponds to the number of states between the first state and the second state associated with the catalog; and at least one of the catalogs has a tier which is different from the tier of another catalog.
14. The system of claim 13, wherein:
the ending state is specified by a directive file available to the client.
the ending state is specified by a directive file available to the client.
15. A computer implemented method for transforming a computer readable file of a beginning state to a computer readable file of an ending state using available update patches, the beginning state and the ending state both being states within a sequence of states associated with the computer readable file, each update patch having a first state and a second state associated therewith, the first state of each update patch preceding in the sequence of states the second state of that update patch, and each update patch specifying information about differences between the first state and the second state associated with that update patch, the computer implemented method comprising the steps of:
determining a sequential set of update patches from those available such that the first state associated with the initial update patch in the sequential set of update patches is the beginning state, the first state associated with each other update patch in the sequential set of update patches is the same state as the second state associated with the preceding update patch in the sequential set of update patches, and the second state associated with the final update patch in the sequential set of update patches is the ending state;
requesting each update patch in the sequential set of update patches from at least one update data source, wherein each update data source has access to at least one of the available update patches, and is disposed to receive the request and transmit the requested update patch;
receiving each requested update patch in the sequential set of update patches from at least one update data source; and producing a computer readable file of the ending state by using each update patch in the sequential set of update patches to transform the computer readable file from the first state associated with the update patch to the second state associated with the update patch.
determining a sequential set of update patches from those available such that the first state associated with the initial update patch in the sequential set of update patches is the beginning state, the first state associated with each other update patch in the sequential set of update patches is the same state as the second state associated with the preceding update patch in the sequential set of update patches, and the second state associated with the final update patch in the sequential set of update patches is the ending state;
requesting each update patch in the sequential set of update patches from at least one update data source, wherein each update data source has access to at least one of the available update patches, and is disposed to receive the request and transmit the requested update patch;
receiving each requested update patch in the sequential set of update patches from at least one update data source; and producing a computer readable file of the ending state by using each update patch in the sequential set of update patches to transform the computer readable file from the first state associated with the update patch to the second state associated with the update patch.
16. The method of claim 15, wherein:
the ending state is specified by a directive file.
the ending state is specified by a directive file.
17. The method of claim 15, wherein:
at least one update data source is selected from the group consisting of an NNTP
Usenet server, an HTTP server, an FTP server, and a locally accessible file system server.
at least one update data source is selected from the group consisting of an NNTP
Usenet server, an HTTP server, an FTP server, and a locally accessible file system server.
18. The method of claim 15, wherein:
the update patches are binary patches which include binary differences between the first state and the second state.
the update patches are binary patches which include binary differences between the first state and the second state.
19. The method of claim 15, wherein:
the sequential set of update patches contains that number of update patches which is the smallest number of available update patches necessary to transform the computer readable file from the beginning state to the ending state.
the sequential set of update patches contains that number of update patches which is the smallest number of available update patches necessary to transform the computer readable file from the beginning state to the ending state.
20. The method of claim 15, wherein:
the step of determining the sequential set of update patches comprises:
determining a sequential set of catalogs from available catalogs, each catalog specifying at least one update patch;
interpreting each catalog of the sequential set of catalogs seriatim to determine an incremental set of update patches associated with the catalog; and combining the incremental sets of update patches.
the step of determining the sequential set of update patches comprises:
determining a sequential set of catalogs from available catalogs, each catalog specifying at least one update patch;
interpreting each catalog of the sequential set of catalogs seriatim to determine an incremental set of update patches associated with the catalog; and combining the incremental sets of update patches.
21. The method of claim 15, wherein:
each update patch has a tier associated with it, the tier being a number which corresponds to the number of states between the first state and the second state associated with the update patch; and at least one of the update patches has a tier which is different from the tier of another update patch.
each update patch has a tier associated with it, the tier being a number which corresponds to the number of states between the first state and the second state associated with the update patch; and at least one of the update patches has a tier which is different from the tier of another update patch.
22. A computer readable medium containing a computer program which transforms a computer readable file of a beginning state to a computer readable file of an ending state using available update patches, the beginning state and the ending state both being states within a sequence of states associated with the computer readable file, each update patch having a first state and a second state associated therewith, the first state of each update patch preceding in the sequence of states the second state of that update patch, each update patch specifying information about differences between the first state and the second state associated with that update patch, each update patch having a tier associated with it, the tier being a number which corresponds to the number of states between the first state and the second state associated with the update patch, and at least one of the update patches has a tier which is different from the tier of another update patch, the computer program performing the steps of:
determining a sequential set of update patches from those available such that the first state associated with the initial update patch in the sequential set of update patches is the beginning state, the first state associated with each other update patch in the sequential set of update patches is the same state as the second state associated with the preceding update patch in the sequential set of update patches, and the second state associated with the final update patch in the sequential set of update patches is the ending state;
requesting each update patch in the sequential set of update patches from at least one update data source, wherein each update data source has access to at least one of the available update patches, and is disposed to receive the request and transmit the requested update patch;
receiving each requested update patch in the sequential set of update patches from at least one update data source; and producing a computer readable file of the ending state by using each update patch in the sequential set of update patches to transform the computer readable file from the first state associated with the update patch to the second state associated with the update patch.
determining a sequential set of update patches from those available such that the first state associated with the initial update patch in the sequential set of update patches is the beginning state, the first state associated with each other update patch in the sequential set of update patches is the same state as the second state associated with the preceding update patch in the sequential set of update patches, and the second state associated with the final update patch in the sequential set of update patches is the ending state;
requesting each update patch in the sequential set of update patches from at least one update data source, wherein each update data source has access to at least one of the available update patches, and is disposed to receive the request and transmit the requested update patch;
receiving each requested update patch in the sequential set of update patches from at least one update data source; and producing a computer readable file of the ending state by using each update patch in the sequential set of update patches to transform the computer readable file from the first state associated with the update patch to the second state associated with the update patch.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/047,949 US6052531A (en) | 1998-03-25 | 1998-03-25 | Multi-tiered incremental software updating |
US09/047,949 | 1998-03-25 | ||
PCT/US1999/006619 WO1999049391A2 (en) | 1998-03-25 | 1999-03-25 | Multi-tiered incremental software updating |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2325544A1 CA2325544A1 (en) | 1999-09-30 |
CA2325544C true CA2325544C (en) | 2002-02-05 |
Family
ID=21951915
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002325544A Expired - Fee Related CA2325544C (en) | 1998-03-25 | 1999-03-25 | Multi-tiered incremental software updating |
Country Status (5)
Country | Link |
---|---|
US (2) | US6052531A (en) |
EP (1) | EP1073952B1 (en) |
CA (1) | CA2325544C (en) |
DE (1) | DE69902898T2 (en) |
WO (1) | WO1999049391A2 (en) |
Families Citing this family (329)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6738970B1 (en) | 1999-06-30 | 2004-05-18 | Marimba, Inc. | Method and apparatus for identifying changes made to a computer system due to software installation |
US6367075B1 (en) * | 1996-07-24 | 2002-04-02 | Marimba, Inc. | Method and apparatus for producing instructions describing the removal of updates to a computer system |
US6317860B1 (en) * | 1996-10-28 | 2001-11-13 | Altera Corporation | Electronic design automation tool for display of design profile |
AU8397298A (en) * | 1997-07-15 | 1999-02-10 | Pocket Soft, Inc. | System for finding differences between two computer files and updating the computer files |
US6035423A (en) | 1997-12-31 | 2000-03-07 | Network Associates, Inc. | Method and system for providing automated updating and upgrading of antivirus applications using a computer network |
US7185332B1 (en) | 1998-03-25 | 2007-02-27 | Symantec Corporation | Multi-tiered incremental software updating |
US6230311B1 (en) * | 1998-06-12 | 2001-05-08 | International Business Machines Corporation | Apparatus and method for disabling methods called on an object |
US6233589B1 (en) * | 1998-07-31 | 2001-05-15 | Novell, Inc. | Method and system for reflecting differences between two files |
US6952823B2 (en) * | 1998-09-01 | 2005-10-04 | Pkware, Inc. | Software patch generator using compression techniques |
GB2341462B (en) * | 1998-09-12 | 2003-06-11 | Ibm | Method for deployment of incremental versions of applications |
US7478142B1 (en) * | 1998-09-29 | 2009-01-13 | Netscape Communications Corporation | Self-contained applications that are applied to be received by and processed within a browser environment and that have a first package that includes a manifest file and an archive of files including a markup language file and second package |
US6487566B1 (en) * | 1998-10-05 | 2002-11-26 | International Business Machines Corporation | Transforming documents using pattern matching and a replacement language |
US7673323B1 (en) | 1998-10-28 | 2010-03-02 | Bea Systems, Inc. | System and method for maintaining security in a distributed computer network |
US6158010A (en) | 1998-10-28 | 2000-12-05 | Crosslogix, Inc. | System and method for maintaining security in a distributed computer network |
US8069407B1 (en) * | 1998-12-08 | 2011-11-29 | Yodlee.Com, Inc. | Method and apparatus for detecting changes in websites and reporting results to web developers for navigation template repair purposes |
US6484315B1 (en) * | 1999-02-01 | 2002-11-19 | Cisco Technology, Inc. | Method and system for dynamically distributing updates in a network |
US6480860B1 (en) * | 1999-02-11 | 2002-11-12 | International Business Machines Corporation | Tagged markup language interface with document type definition to access data in object oriented database |
US6594822B1 (en) * | 1999-02-19 | 2003-07-15 | Nortel Networks Limited | Method and apparatus for creating a software patch by comparing object files |
US6434744B1 (en) * | 1999-03-03 | 2002-08-13 | Microsoft Corporation | System and method for patching an installed application program |
US6427236B1 (en) * | 1999-03-03 | 2002-07-30 | Microsoft Corporation | Method for installing a patch based on patch criticality and software execution format |
KR100684986B1 (en) * | 1999-12-31 | 2007-02-22 | 주식회사 잉카인터넷 | Online dangerous information screening system and method |
US6526529B1 (en) * | 1999-06-29 | 2003-02-25 | Microsoft Corporation | Dynamic error messaging |
US6556904B1 (en) | 1999-09-02 | 2003-04-29 | Hunter Engineering Company | Method and apparatus for update and acquisition of automotive vehicle specifications in automotive diagnostic equipment |
US6230199B1 (en) | 1999-10-29 | 2001-05-08 | Mcafee.Com, Inc. | Active marketing based on client computer configurations |
JP3655152B2 (en) * | 1999-11-29 | 2005-06-02 | 富士通株式会社 | Software editing apparatus and storage medium |
US6879988B2 (en) | 2000-03-09 | 2005-04-12 | Pkware | System and method for manipulating and managing computer archive files |
US8959582B2 (en) | 2000-03-09 | 2015-02-17 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
US20050015608A1 (en) | 2003-07-16 | 2005-01-20 | Pkware, Inc. | Method for strongly encrypting .ZIP files |
GB2366640B (en) * | 2000-03-30 | 2004-12-29 | Ibm | Distribution of activation information |
US7130870B1 (en) * | 2000-05-20 | 2006-10-31 | Ciena Corporation | Method for upgrading embedded configuration databases |
JP2001331321A (en) * | 2000-05-22 | 2001-11-30 | Canon Inc | Information processor, method and system for processing information and medium |
JP3852269B2 (en) * | 2000-05-29 | 2006-11-29 | セイコーエプソン株式会社 | A system that automatically collects content that exists on the network |
US6907396B1 (en) * | 2000-06-01 | 2005-06-14 | Networks Associates Technology, Inc. | Detecting computer viruses or malicious software by patching instructions into an emulator |
US6535894B1 (en) * | 2000-06-01 | 2003-03-18 | Sun Microsystems, Inc. | Apparatus and method for incremental updating of archive files |
US7712024B2 (en) | 2000-06-06 | 2010-05-04 | Microsoft Corporation | Application program interfaces for semantically labeling strings and providing actions based on semantically labeled strings |
US7716163B2 (en) | 2000-06-06 | 2010-05-11 | Microsoft Corporation | Method and system for defining semantic categories and actions |
US7788602B2 (en) * | 2000-06-06 | 2010-08-31 | Microsoft Corporation | Method and system for providing restricted actions for recognized semantic categories |
US7421645B2 (en) | 2000-06-06 | 2008-09-02 | Microsoft Corporation | Method and system for providing electronic commerce actions based on semantically labeled strings |
US7770102B1 (en) | 2000-06-06 | 2010-08-03 | Microsoft Corporation | Method and system for semantically labeling strings and providing actions based on semantically labeled strings |
JP3904808B2 (en) * | 2000-06-08 | 2007-04-11 | 株式会社日立製作所 | Distributed object management method, apparatus for implementing the method, and recording medium recording the processing program |
US20040073617A1 (en) | 2000-06-19 | 2004-04-15 | Milliken Walter Clark | Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail |
US6874143B1 (en) * | 2000-06-21 | 2005-03-29 | Microsoft Corporation | Architectures for and methods of providing network-based software extensions |
US7191394B1 (en) | 2000-06-21 | 2007-03-13 | Microsoft Corporation | Authoring arbitrary XML documents using DHTML and XSLT |
US7624356B1 (en) | 2000-06-21 | 2009-11-24 | Microsoft Corporation | Task-sensitive methods and systems for displaying command sets |
US7346848B1 (en) | 2000-06-21 | 2008-03-18 | Microsoft Corporation | Single window navigation methods and systems |
US7155667B1 (en) * | 2000-06-21 | 2006-12-26 | Microsoft Corporation | User interface for integrated spreadsheets and word processing tables |
US6948135B1 (en) | 2000-06-21 | 2005-09-20 | Microsoft Corporation | Method and systems of providing information to computer users |
WO2001098928A2 (en) * | 2000-06-21 | 2001-12-27 | Microsoft Corporation | System and method for integrating spreadsheets and word processing tables |
US6883168B1 (en) * | 2000-06-21 | 2005-04-19 | Microsoft Corporation | Methods, systems, architectures and data structures for delivering software via a network |
US7000230B1 (en) | 2000-06-21 | 2006-02-14 | Microsoft Corporation | Network-based software extensions |
US6941353B1 (en) * | 2000-06-29 | 2005-09-06 | Auran Holdings Pty Ltd | E-commerce system and method relating to program objects |
EP1168165A3 (en) * | 2000-06-30 | 2005-02-16 | International Business Machines Corporation | Device and method for updating code |
KR100455566B1 (en) * | 2000-06-30 | 2004-11-09 | 인터내셔널 비지네스 머신즈 코포레이션 | Device and method for updating code |
US6981252B1 (en) | 2000-07-14 | 2005-12-27 | Symantec Corporation | Method and apparatus for automatically uninstalling software on a network |
US7131122B1 (en) * | 2000-08-24 | 2006-10-31 | International Business Machines Corporation | Apparatus, system and method for detecting old version of an applet in a client brower's JVM |
US6370455B1 (en) | 2000-09-05 | 2002-04-09 | Hunter Engineering Company | Method and apparatus for networked wheel alignment communications and service |
US20040003266A1 (en) * | 2000-09-22 | 2004-01-01 | Patchlink Corporation | Non-invasive automatic offsite patch fingerprinting and updating system and method |
WO2002025438A1 (en) * | 2000-09-22 | 2002-03-28 | Patchlink.Com Corporation | Non-invasive automatic offsite patch fingerprinting and updating system and method |
CA2320665C (en) * | 2000-09-26 | 2010-08-17 | Spielo Manufacturing Incorporated | System and method for downloading electronic information to a video lottery terminal |
US7120675B1 (en) * | 2000-09-26 | 2006-10-10 | Microsoft Corporation | Information location service |
US7392540B1 (en) * | 2000-10-03 | 2008-06-24 | Hewlett-Packard Development Company, L.P. | Methods and systems for customer premises remote collaboration facility |
US6757830B1 (en) * | 2000-10-03 | 2004-06-29 | Networks Associates Technology, Inc. | Detecting unwanted properties in received email messages |
US6971023B1 (en) * | 2000-10-03 | 2005-11-29 | Mcafee, Inc. | Authorizing an additional computer program module for use with a core computer program |
US7703092B1 (en) * | 2000-10-12 | 2010-04-20 | International Business Machines Corporation | Method, system, computer program product, and article of manufacture for installation and configuration of a computer program according to a stored configuration |
US7089553B1 (en) * | 2000-10-12 | 2006-08-08 | International Business Machines Corporation | Method, system, computer program product, and article of manufacture for downloading a remote computer program according to a stored configuration |
US6944857B1 (en) * | 2000-10-12 | 2005-09-13 | International Business Machines Corporation | Method, system, computer program product, and article of manufacture for updating a computer program according to a stored configuration |
US7890947B2 (en) * | 2000-10-13 | 2011-02-15 | Sony Corporation | System, method and apparatus for embedded firmware code update |
US6754717B1 (en) * | 2000-10-23 | 2004-06-22 | International Business Machines Corporation | Establishing compatibility of messages for communicating between processing entities with continuous availability |
US6983486B1 (en) * | 2000-11-14 | 2006-01-03 | Mcafee, Inc. | Method and apparatus for establishing security scanner attributes in a computer system |
US8479189B2 (en) | 2000-11-17 | 2013-07-02 | Hewlett-Packard Development Company, L.P. | Pattern detection preprocessor in an electronic device update generation system |
US20030182414A1 (en) * | 2003-05-13 | 2003-09-25 | O'neill Patrick J. | System and method for updating and distributing information |
US7409685B2 (en) | 2002-04-12 | 2008-08-05 | Hewlett-Packard Development Company, L.P. | Initialization and update of software and/or firmware in electronic devices |
US7512635B1 (en) * | 2000-12-18 | 2009-03-31 | Bmc Software, Inc. | System and method for updating information on a computer system using a limited amount of space |
US7574481B2 (en) * | 2000-12-20 | 2009-08-11 | Microsoft Corporation | Method and system for enabling offline detection of software updates |
US7058667B2 (en) * | 2000-12-27 | 2006-06-06 | Microsoft Corporation | Method and system for creating and maintaining version-specific properties in a file |
US6658330B2 (en) | 2000-12-29 | 2003-12-02 | General Electric Co. | Method and system for upgrading software for controlling locomotives |
US7467379B2 (en) * | 2001-01-16 | 2008-12-16 | International Business Machines Corporation | System and method for incrementally executing a client/server application |
EP1237078A1 (en) * | 2001-01-19 | 2002-09-04 | Siemens Aktiengesellschaft | Execution of a time-optimised exchange of a software application |
US6763517B2 (en) * | 2001-02-12 | 2004-07-13 | Sun Microsystems, Inc. | Automated analysis of kernel and user core files including searching, ranking, and recommending patch files |
US7127712B1 (en) * | 2001-02-14 | 2006-10-24 | Oracle International Corporation | System and method for providing a java code release infrastructure with granular code patching |
US6963930B2 (en) * | 2001-02-15 | 2005-11-08 | Centric Software, Inc. | Automatic transfer and expansion of application-specific data for display at a website |
US7647411B1 (en) | 2001-02-26 | 2010-01-12 | Symantec Corporation | System and method for controlling distribution of network communications |
WO2002069108A2 (en) | 2001-02-26 | 2002-09-06 | Eprivacy Group, Inc. | System and method for controlling distribution of network communications |
US6965928B1 (en) | 2001-03-09 | 2005-11-15 | Networks Associates Technology, Inc. | System and method for remote maintenance of handheld computers |
US7302584B2 (en) * | 2001-03-16 | 2007-11-27 | Mcafee, Inc. | Mechanisms for banning computer programs from use |
US7734285B2 (en) * | 2001-04-03 | 2010-06-08 | Qualcomm Incorporated | Method and apparatus for network initiated uninstallation of application program over wireless network |
US7464092B2 (en) * | 2001-04-04 | 2008-12-09 | Alorica, Inc | Method, system and program for customer service and support management |
US20020156877A1 (en) * | 2001-04-23 | 2002-10-24 | Lu James C. | System and method for the duplication of a software system onto an appropriate target computer |
US7778816B2 (en) * | 2001-04-24 | 2010-08-17 | Microsoft Corporation | Method and system for applying input mode bias |
CA2349654A1 (en) * | 2001-06-04 | 2002-12-04 | Ibm Canada Limited-Ibm Canada Limitee | Server configuration versioning tool |
US20030083958A1 (en) * | 2001-06-08 | 2003-05-01 | Jinshan Song | System and method for retrieving information from an electronic catalog |
US7392546B2 (en) | 2001-06-11 | 2008-06-24 | Bea Systems, Inc. | System and method for server security and entitlement processing |
US7234168B2 (en) * | 2001-06-13 | 2007-06-19 | Mcafee, Inc. | Hierarchy-based method and apparatus for detecting attacks on a computer system |
US20030005408A1 (en) * | 2001-07-02 | 2003-01-02 | Pradeep Tumati | System and method for creating software modifiable without halting its execution |
US20060059479A1 (en) * | 2001-07-02 | 2006-03-16 | Pradeep Tumati | System and method for modifying software without halting its execution |
US7231637B1 (en) * | 2001-07-26 | 2007-06-12 | Mcafee, Inc. | Security and software testing of pre-release anti-virus updates on client and transmitting the results to the server |
US7827611B2 (en) | 2001-08-01 | 2010-11-02 | Mcafee, Inc. | Malware scanning user interface for wireless devices |
US20030041125A1 (en) * | 2001-08-16 | 2003-02-27 | Salomon Kirk C. | Internet-deployed wireless system |
JP2003067208A (en) * | 2001-08-23 | 2003-03-07 | Sony Corp | Information processing device and the method, recording medium and program |
JP4083505B2 (en) | 2001-08-27 | 2008-04-30 | 株式会社リコー | Image forming apparatus, program update method, and recording medium |
US20040255000A1 (en) * | 2001-10-03 | 2004-12-16 | Simionescu Dan C. | Remotely controlled failsafe boot mechanism and remote manager for a network device |
US7266731B2 (en) * | 2001-11-13 | 2007-09-04 | Sun Microsystems, Inc. | Method and apparatus for managing remote software code update |
US6915513B2 (en) * | 2001-11-29 | 2005-07-05 | Hewlett-Packard Development Company, L.P. | System and method for dynamically replacing code |
US7159036B2 (en) * | 2001-12-10 | 2007-01-02 | Mcafee, Inc. | Updating data from a source computer to groups of destination computers |
US9392002B2 (en) * | 2002-01-31 | 2016-07-12 | Nokia Technologies Oy | System and method of providing virus protection at a gateway |
US7222138B2 (en) * | 2002-02-20 | 2007-05-22 | Sun Microsystems, Inc. | Versioning application programming interface and method for using versioning functionality |
US7065760B2 (en) * | 2002-02-28 | 2006-06-20 | Sun Microsystems, Inc. | Reducing the memory footprint of applications executed in a virtual machine |
US7178140B2 (en) | 2002-02-28 | 2007-02-13 | Sun Microsystems, Inc. | Speeding up application downloading from a remote server |
JP2003288211A (en) * | 2002-03-27 | 2003-10-10 | Minolta Co Ltd | Network management program |
US7600021B2 (en) * | 2002-04-03 | 2009-10-06 | Microsoft Corporation | Delta replication of source files and packages across networked resources |
US6904430B1 (en) * | 2002-04-26 | 2005-06-07 | Microsoft Corporation | Method and system for efficiently identifying differences between large files |
US7325194B2 (en) | 2002-05-07 | 2008-01-29 | Microsoft Corporation | Method, system, and apparatus for converting numbers between measurement systems based upon semantically labeled strings |
US7707496B1 (en) | 2002-05-09 | 2010-04-27 | Microsoft Corporation | Method, system, and apparatus for converting dates between calendars and languages based upon semantically labeled strings |
US7237008B1 (en) * | 2002-05-10 | 2007-06-26 | Mcafee, Inc. | Detecting malware carried by an e-mail message |
US6925467B2 (en) * | 2002-05-13 | 2005-08-02 | Innopath Software, Inc. | Byte-level file differencing and updating algorithms |
US6965674B2 (en) * | 2002-05-21 | 2005-11-15 | Wavelink Corporation | System and method for providing WLAN security through synchronized update and rotation of WEP keys |
US7742048B1 (en) | 2002-05-23 | 2010-06-22 | Microsoft Corporation | Method, system, and apparatus for converting numbers based upon semantically labeled strings |
US7707024B2 (en) * | 2002-05-23 | 2010-04-27 | Microsoft Corporation | Method, system, and apparatus for converting currency values based upon semantically labeled strings |
US6999976B2 (en) * | 2002-05-29 | 2006-02-14 | International Business Machines Corporation | Method, apparatus, and program for using a Java archive to encode a file system delta |
US7281245B2 (en) * | 2002-06-05 | 2007-10-09 | Microsoft Corporation | Mechanism for downloading software components from a remote source for use by a local software application |
US7827546B1 (en) | 2002-06-05 | 2010-11-02 | Microsoft Corporation | Mechanism for downloading software components from a remote source for use by a local software application |
US7356537B2 (en) | 2002-06-06 | 2008-04-08 | Microsoft Corporation | Providing contextually sensitive tools and help content in computer-generated documents |
US7191435B2 (en) * | 2002-06-07 | 2007-03-13 | Sun Microsystems, Inc. | Method and system for optimizing software upgrades |
US7716676B2 (en) | 2002-06-25 | 2010-05-11 | Microsoft Corporation | System and method for issuing a message to a program |
US7392479B2 (en) | 2002-06-27 | 2008-06-24 | Microsoft Corporation | System and method for providing namespace related information |
US7965842B2 (en) * | 2002-06-28 | 2011-06-21 | Wavelink Corporation | System and method for detecting unauthorized wireless access points |
US7209915B1 (en) | 2002-06-28 | 2007-04-24 | Microsoft Corporation | Method, system and apparatus for routing a query to one or more providers |
US8393001B1 (en) * | 2002-07-26 | 2013-03-05 | Mcafee, Inc. | Secure signature server system and associated method |
US7606242B2 (en) * | 2002-08-02 | 2009-10-20 | Wavelink Corporation | Managed roaming for WLANS |
US7522906B2 (en) * | 2002-08-09 | 2009-04-21 | Wavelink Corporation | Mobile unit configuration management for WLANs |
US7313791B1 (en) * | 2002-08-22 | 2007-12-25 | Hewlett-Packard Development Company, L.P. | Firmware update network and process employing preprocessing techniques |
US20080313282A1 (en) | 2002-09-10 | 2008-12-18 | Warila Bruce W | User interface, operating system and architecture |
US7669197B1 (en) * | 2002-09-12 | 2010-02-23 | Hewlett-Packard Development Company, L.P. | Embedded system employing component architecture platform |
US7472380B1 (en) * | 2002-09-23 | 2008-12-30 | Hewlett-Packard Development Company, L.P. | Processing system with component architecture platform support |
EP1408410A1 (en) * | 2002-09-30 | 2004-04-14 | Sap Ag | Remote debugging of computer programs |
US7096311B2 (en) | 2002-09-30 | 2006-08-22 | Innopath Software, Inc. | Updating electronic files using byte-level file differencing and updating algorithms |
US6836657B2 (en) * | 2002-11-12 | 2004-12-28 | Innopath Software, Inc. | Upgrading of electronic files including automatic recovery from failures and errors occurring during the upgrade |
US20040064722A1 (en) * | 2002-10-01 | 2004-04-01 | Dinesh Neelay | System and method for propagating patches to address vulnerabilities in computers |
US7188369B2 (en) * | 2002-10-03 | 2007-03-06 | Trend Micro, Inc. | System and method having an antivirus virtual scanning processor with plug-in functionalities |
US7194728B1 (en) * | 2002-11-18 | 2007-03-20 | Bmc Software, Inc. | System and method for packaging updates |
US6711676B1 (en) * | 2002-10-15 | 2004-03-23 | Zomaya Group, Inc. | System and method for providing computer upgrade information |
US7577948B2 (en) * | 2003-07-02 | 2009-08-18 | Upgradedetect, Inc. | System and method for providing computer upgrade information |
US7984435B2 (en) * | 2002-11-13 | 2011-07-19 | Hewlett-Packard Development Company, L.P. | Update system employing reference software to reduce number of update packages |
US20040098421A1 (en) * | 2002-11-18 | 2004-05-20 | Luosheng Peng | Scheduling updates of electronic files |
US7007049B2 (en) | 2002-11-18 | 2006-02-28 | Innopath Software, Inc. | Device memory management during electronic file updating |
US20050204351A1 (en) * | 2002-11-18 | 2005-09-15 | James Jiang | Dynamic addressing (DA) using a centralized DA Manager |
US7844734B2 (en) * | 2002-11-18 | 2010-11-30 | Innopath Software, Inc. | Dynamic addressing (DA) using a centralized DA manager |
US7003534B2 (en) * | 2002-11-18 | 2006-02-21 | Innopath Software, Inc. | Generating difference files using module information of embedded software components |
US20040098361A1 (en) * | 2002-11-18 | 2004-05-20 | Luosheng Peng | Managing electronic file updates on client devices |
US7320010B2 (en) * | 2002-11-18 | 2008-01-15 | Innopath Software, Inc. | Controlling updates of electronic files |
US7434216B1 (en) * | 2002-11-25 | 2008-10-07 | Hewlett-Packard Development Company, L.P. | Update package generator that employs genetic evolution to determine bank order |
US7099884B2 (en) * | 2002-12-06 | 2006-08-29 | Innopath Software | System and method for data compression and decompression |
JP3979285B2 (en) * | 2002-12-17 | 2007-09-19 | 株式会社日立製作所 | Information processing system |
US7783614B2 (en) * | 2003-02-13 | 2010-08-24 | Microsoft Corporation | Linking elements of a document to corresponding fields, queries and/or procedures in a database |
US7389309B2 (en) * | 2003-02-28 | 2008-06-17 | Microsoft Corporation | Method for managing file replication in applications |
US20040172584A1 (en) * | 2003-02-28 | 2004-09-02 | Microsoft Corporation | Method and system for enhancing paste functionality of a computer software application |
US8010491B2 (en) * | 2003-02-28 | 2011-08-30 | Microsoft Corporation | Method for managing multiple file states for replicated files |
US7765281B1 (en) * | 2003-03-10 | 2010-07-27 | Motive, Inc. | Large-scale targeted data distribution system |
US7275216B2 (en) * | 2003-03-24 | 2007-09-25 | Microsoft Corporation | System and method for designing electronic forms and hierarchical schemas |
US7370066B1 (en) | 2003-03-24 | 2008-05-06 | Microsoft Corporation | System and method for offline editing of data files |
US7415672B1 (en) | 2003-03-24 | 2008-08-19 | Microsoft Corporation | System and method for designing electronic forms |
US7296017B2 (en) | 2003-03-28 | 2007-11-13 | Microsoft Corporation | Validation of XML data files |
US7320009B1 (en) | 2003-03-28 | 2008-01-15 | Novell, Inc. | Methods and systems for file replication utilizing differences between versions of files |
US7913159B2 (en) | 2003-03-28 | 2011-03-22 | Microsoft Corporation | System and method for real-time validation of structured data files |
EP1609061A2 (en) | 2003-04-01 | 2005-12-28 | Siemens Aktiengesellschaft | Method and array for changing software or source code |
DE10314832B3 (en) * | 2003-04-01 | 2004-12-09 | Siemens Ag | Computer software modification method with initial conversion of selected software components at modification points and delivery in mixed form for final conversion of software components on user side |
US7373519B1 (en) | 2003-04-09 | 2008-05-13 | Symantec Corporation | Distinguishing legitimate modifications from malicious modifications during executable computer file modification analysis |
US7711550B1 (en) | 2003-04-29 | 2010-05-04 | Microsoft Corporation | Methods and system for recognizing names in a computer-generated document and for providing helpful actions associated with recognized names |
ATE366912T1 (en) * | 2003-05-07 | 2007-08-15 | Harman Becker Automotive Sys | METHOD AND DEVICE FOR VOICE OUTPUT, DATA CARRIER WITH VOICE DATA |
US20040225282A1 (en) * | 2003-05-09 | 2004-11-11 | Ness Anton P. | Method and articles for assuring appropriate surgery |
US7089270B2 (en) * | 2003-06-20 | 2006-08-08 | Innopath Software | Processing software images for use in generating difference files |
US7739588B2 (en) | 2003-06-27 | 2010-06-15 | Microsoft Corporation | Leveraging markup language data for semantically labeling text strings and data and for providing actions based on semantically labeled text strings and data |
US20040268229A1 (en) * | 2003-06-27 | 2004-12-30 | Microsoft Corporation | Markup language editing with an electronic form |
US7451392B1 (en) | 2003-06-30 | 2008-11-11 | Microsoft Corporation | Rendering an HTML electronic form by applying XSLT to XML using a solution |
US7539727B2 (en) * | 2003-07-01 | 2009-05-26 | Microsoft Corporation | Instant messaging object store |
US7363378B2 (en) * | 2003-07-01 | 2008-04-22 | Microsoft Corporation | Transport system for instant messaging |
US20050010576A1 (en) * | 2003-07-09 | 2005-01-13 | Liwei Ren | File differencing and updating engines |
US20050010870A1 (en) * | 2003-07-09 | 2005-01-13 | Jinsheng Gu | Post-processing algorithm for byte-level file differencing |
US7031972B2 (en) * | 2003-07-21 | 2006-04-18 | Innopath Software, Inc. | Algorithms for block-level code alignment of software binary files |
US20050020308A1 (en) * | 2003-07-23 | 2005-01-27 | David Lai | Dynamically binding Subscriber Identity Modules (SIMs)/User Identity Modules (UIMs) with portable communication devices |
US7406660B1 (en) | 2003-08-01 | 2008-07-29 | Microsoft Corporation | Mapping between structured data and a visual surface |
US7334187B1 (en) | 2003-08-06 | 2008-02-19 | Microsoft Corporation | Electronic form aggregation |
JP2005077642A (en) | 2003-08-29 | 2005-03-24 | Mitsubishi Electric Corp | Map information processor, map correction information storage medium, map correction information data structure, map correction information producing system, and updating system of map information |
US8555273B1 (en) | 2003-09-17 | 2013-10-08 | Palm. Inc. | Network for updating electronic devices |
WO2005031570A1 (en) * | 2003-09-26 | 2005-04-07 | Bitfone Corporation | Update package catalog for update package transfer between generator and content server in a network |
US20050102536A1 (en) * | 2003-10-10 | 2005-05-12 | Bea Systems, Inc. | Dynamically configurable distributed security system |
US7644432B2 (en) | 2003-10-10 | 2010-01-05 | Bea Systems, Inc. | Policy inheritance through nested groups |
US20050114499A1 (en) * | 2003-11-24 | 2005-05-26 | Monk John M. | System and method for updating testing devices in a distributed environment |
US8713544B1 (en) | 2003-11-25 | 2014-04-29 | Symantec Corporation | Universal data-driven computer proxy |
US7415706B1 (en) * | 2003-12-01 | 2008-08-19 | Cisco Technology, Inc. | Dynamic handling of multiple software component versions for device management |
US7434157B2 (en) | 2003-12-09 | 2008-10-07 | Microsoft Corporation | Programmable object model for namespace or schema library support in a software application |
US7487515B1 (en) | 2003-12-09 | 2009-02-03 | Microsoft Corporation | Programmable object model for extensible markup language schema validation |
US7404195B1 (en) | 2003-12-09 | 2008-07-22 | Microsoft Corporation | Programmable object model for extensible markup language markup in an application |
US7178102B1 (en) | 2003-12-09 | 2007-02-13 | Microsoft Corporation | Representing latent data in an extensible markup language document |
US7574706B2 (en) * | 2003-12-15 | 2009-08-11 | Microsoft Corporation | System and method for managing and communicating software updates |
US7478381B2 (en) * | 2003-12-15 | 2009-01-13 | Microsoft Corporation | Managing software updates and a software distribution service |
US7451440B2 (en) * | 2004-01-09 | 2008-11-11 | Hewlett-Packard Development Company, L.P. | Patch application that enables the identification of patches for installation on a computer system in a reactive manner |
US8171084B2 (en) * | 2004-01-20 | 2012-05-01 | Microsoft Corporation | Custom emoticons |
US8024783B2 (en) * | 2004-01-22 | 2011-09-20 | Ryan Riley | Modular agent architecture |
US7689984B2 (en) * | 2004-01-22 | 2010-03-30 | Autonomic Software, Inc. | Client-server data execution flow |
US8819072B1 (en) | 2004-02-02 | 2014-08-26 | Microsoft Corporation | Promoting data from structured data files |
US7467378B1 (en) | 2004-02-09 | 2008-12-16 | Symantec Corporation | System state rollback after modification failure |
US20050182617A1 (en) * | 2004-02-17 | 2005-08-18 | Microsoft Corporation | Methods and systems for providing automated actions on recognized text strings in a computer-generated document |
US7509573B1 (en) | 2004-02-17 | 2009-03-24 | Microsoft Corporation | Anti-virus security information in an extensible markup language document |
US7318063B2 (en) * | 2004-02-19 | 2008-01-08 | Microsoft Corporation | Managing XML documents containing hierarchical database information |
US7140549B2 (en) | 2004-02-24 | 2006-11-28 | Sun Microsystems, Inc. | Method and apparatus for selecting a desired application on a smart card |
US7374099B2 (en) | 2004-02-24 | 2008-05-20 | Sun Microsystems, Inc. | Method and apparatus for processing an application identifier from a smart card |
US8051483B2 (en) | 2004-03-12 | 2011-11-01 | Fortinet, Inc. | Systems and methods for updating content detection devices and systems |
US8688803B2 (en) * | 2004-03-26 | 2014-04-01 | Microsoft Corporation | Method for efficient content distribution using a peer-to-peer networking infrastructure |
US7913248B1 (en) | 2004-03-26 | 2011-03-22 | Adobe Systems Incorporated | System and method for installing one or more programs, and at least a portion of their environment |
US7739679B2 (en) * | 2004-04-06 | 2010-06-15 | Hewlett-Packard Development Company, L.P. | Object ordering tool for facilitating generation of firmware update friendly binary image |
US20060047855A1 (en) * | 2004-05-13 | 2006-03-02 | Microsoft Corporation | Efficient chunking algorithm |
US7555531B2 (en) * | 2004-04-15 | 2009-06-30 | Microsoft Corporation | Efficient algorithm and protocol for remote differential compression |
US7904895B1 (en) | 2004-04-21 | 2011-03-08 | Hewlett-Packard Develpment Company, L.P. | Firmware update in electronic devices employing update agent in a flash memory card |
US7496837B1 (en) | 2004-04-29 | 2009-02-24 | Microsoft Corporation | Structural editing with schema awareness |
US7900056B1 (en) | 2004-04-30 | 2011-03-01 | Network Engines, Inc. | Digital data processing methods and apparatus for management of software installation and execution |
US8572280B2 (en) * | 2004-05-06 | 2013-10-29 | Valve Corporation | Method and system for serialization of hierarchically defined objects |
US20050257205A1 (en) * | 2004-05-13 | 2005-11-17 | Microsoft Corporation | Method and system for dynamic software updates |
US7774620B1 (en) | 2004-05-27 | 2010-08-10 | Microsoft Corporation | Executing applications at appropriate trust levels |
KR100608796B1 (en) * | 2004-06-15 | 2006-08-08 | 엘지전자 주식회사 | Method for upgrading binary data of mobile communication terminal |
US20060010175A1 (en) * | 2004-06-17 | 2006-01-12 | International Business Machines Corporation | Apparatus, system, and method for automated conversion of content having multiple representation versions |
US8526940B1 (en) | 2004-08-17 | 2013-09-03 | Palm, Inc. | Centralized rules repository for smart phone customer care |
US7373492B2 (en) * | 2004-08-30 | 2008-05-13 | Lehman Brothers Inc. | Boot disk management utility |
US7516451B2 (en) * | 2004-08-31 | 2009-04-07 | Innopath Software, Inc. | Maintaining mobile device electronic files including using difference files when upgrading |
US7613787B2 (en) * | 2004-09-24 | 2009-11-03 | Microsoft Corporation | Efficient algorithm for finding candidate objects for remote differential compression |
US7516399B2 (en) * | 2004-09-30 | 2009-04-07 | Microsoft Corporation | Structured-document path-language expression methods and systems |
US7692636B2 (en) | 2004-09-30 | 2010-04-06 | Microsoft Corporation | Systems and methods for handwriting to a screen |
JP4688472B2 (en) * | 2004-11-01 | 2011-05-25 | 株式会社エヌ・ティ・ティ・ドコモ | Terminal control apparatus and terminal control method |
US7712022B2 (en) | 2004-11-15 | 2010-05-04 | Microsoft Corporation | Mutually exclusive options in electronic forms |
US7721190B2 (en) | 2004-11-16 | 2010-05-18 | Microsoft Corporation | Methods and systems for server side form processing |
US7747573B2 (en) * | 2004-11-18 | 2010-06-29 | International Business Machines Corporation | Updating elements in a data storage facility using a predefined state machine, with serial activation |
US7904801B2 (en) | 2004-12-15 | 2011-03-08 | Microsoft Corporation | Recursive sections in electronic forms |
US7437376B2 (en) * | 2004-12-20 | 2008-10-14 | Microsoft Corporation | Scalable object model |
US7613875B2 (en) * | 2004-12-29 | 2009-11-03 | Intel Corporation | Apparatus and method for incremental package deployment |
US8073926B2 (en) * | 2005-01-07 | 2011-12-06 | Microsoft Corporation | Virtual machine image server |
US20070094348A1 (en) * | 2005-01-07 | 2007-04-26 | Microsoft Corporation | BITS/RDC integration and BITS enhancements |
US7849462B2 (en) * | 2005-01-07 | 2010-12-07 | Microsoft Corporation | Image server |
US7610610B2 (en) | 2005-01-10 | 2009-10-27 | Mcafee, Inc. | Integrated firewall, IPS, and virus scanner system and method |
US7937651B2 (en) | 2005-01-14 | 2011-05-03 | Microsoft Corporation | Structural editing operations for network forms |
US7640363B2 (en) * | 2005-02-16 | 2009-12-29 | Microsoft Corporation | Applications for remote differential compression |
US20060195532A1 (en) * | 2005-02-28 | 2006-08-31 | Microsoft Corporation | Client-side presence documentation |
US7725834B2 (en) | 2005-03-04 | 2010-05-25 | Microsoft Corporation | Designer-created aspect for an electronic form template |
US20080222604A1 (en) * | 2005-03-07 | 2008-09-11 | Network Engines, Inc. | Methods and apparatus for life-cycle management |
US20090089871A1 (en) * | 2005-03-07 | 2009-04-02 | Network Engines, Inc. | Methods and apparatus for digital data processor instantiation |
US7716661B2 (en) * | 2005-03-16 | 2010-05-11 | Microsoft Corporation | Embedded device update service |
US8086615B2 (en) * | 2005-03-28 | 2011-12-27 | Oracle International Corporation | Security data redaction |
US20060224628A1 (en) * | 2005-03-29 | 2006-10-05 | Bea Systems, Inc. | Modeling for data services |
US7505940B2 (en) * | 2005-03-31 | 2009-03-17 | Adobe Systems Incorporated | Software suite activation |
US8010515B2 (en) | 2005-04-15 | 2011-08-30 | Microsoft Corporation | Query to an electronic form |
EP1872215B1 (en) | 2005-04-18 | 2018-05-09 | BlackBerry Limited | Implementing data-compatibility-based version scheme |
US7529255B2 (en) * | 2005-04-21 | 2009-05-05 | Microsoft Corporation | Peer-to-peer multicasting using multiple transport protocols |
US7748027B2 (en) * | 2005-05-11 | 2010-06-29 | Bea Systems, Inc. | System and method for dynamic data redaction |
US7937697B2 (en) * | 2005-05-19 | 2011-05-03 | International Business Machines Corporation | Method, system and computer program for distributing software patches |
US7770168B1 (en) | 2005-05-25 | 2010-08-03 | Landesk Software Limited | Systems and methods for distributing software using nodes within a network group |
US8200975B2 (en) | 2005-06-29 | 2012-06-12 | Microsoft Corporation | Digital signatures for network forms |
US7934211B2 (en) * | 2005-06-30 | 2011-04-26 | Oracle International Corporation | Multi-level patching operation |
US7908600B2 (en) | 2005-06-30 | 2011-03-15 | Oracle International Corporation | Fault-tolerant patching system |
US8037290B1 (en) * | 2005-07-01 | 2011-10-11 | Symantec Corporation | Preboot security data update |
US8272058B2 (en) | 2005-07-29 | 2012-09-18 | Bit 9, Inc. | Centralized timed analysis in a network security system |
US8984636B2 (en) | 2005-07-29 | 2015-03-17 | Bit9, Inc. | Content extractor and analysis system |
US7895651B2 (en) | 2005-07-29 | 2011-02-22 | Bit 9, Inc. | Content tracking in a network security system |
US7752651B2 (en) * | 2005-09-26 | 2010-07-06 | Bea Systems Inc. | System and method for propagating security information in a web portal system |
US7992085B2 (en) | 2005-09-26 | 2011-08-02 | Microsoft Corporation | Lightweight reference user interface |
US7788590B2 (en) | 2005-09-26 | 2010-08-31 | Microsoft Corporation | Lightweight reference user interface |
US7730477B2 (en) * | 2005-09-26 | 2010-06-01 | Bea Systems Inc. | System and method for propagation in a web portal system |
US7484173B2 (en) * | 2005-10-18 | 2009-01-27 | International Business Machines Corporation | Alternative key pad layout for enhanced security |
US8001459B2 (en) | 2005-12-05 | 2011-08-16 | Microsoft Corporation | Enabling electronic documents for limited-capability computing devices |
US20070167362A1 (en) * | 2006-01-18 | 2007-07-19 | Staidson (Beijing) Pharmaceutical Co., Ltd. | Medicines containing nerve growth factor for assisting losing weight and methods for assisting losing weight using same |
US20070203956A1 (en) * | 2006-02-28 | 2007-08-30 | Microsoft Corporation | Metadata Customization Using Diffgrams |
US7962125B2 (en) * | 2006-03-27 | 2011-06-14 | Research In Motion Limited | Wireless email communications system providing resource updating features and related methods |
US7818740B2 (en) * | 2006-05-05 | 2010-10-19 | Microsoft Corporation | Techniques to perform gradual upgrades |
US7665081B1 (en) | 2006-05-06 | 2010-02-16 | Kaspersky Lab, Zao | System and method for difference-based software updating |
US8055096B2 (en) * | 2006-05-10 | 2011-11-08 | Research In Motion Limited | Method and system for incremental patching of binary files |
US8209676B2 (en) | 2006-06-08 | 2012-06-26 | Hewlett-Packard Development Company, L.P. | Device management in a network |
JP4864557B2 (en) * | 2006-06-15 | 2012-02-01 | 富士通株式会社 | Software update processing program and update processing apparatus |
US8775572B2 (en) | 2006-06-23 | 2014-07-08 | Microsoft Corporation | Public network distribution of software updates |
EP1873631B1 (en) * | 2006-06-26 | 2010-08-11 | Research In Motion Limited | Method and system for generating a reverse binary patch |
US7779401B2 (en) | 2006-06-26 | 2010-08-17 | Research In Motion Limited | Method and system for generating a reverse binary patch for undoing a software update |
WO2008014454A2 (en) | 2006-07-27 | 2008-01-31 | Hewlett-Packard Development Company, L.P. | User experience and dependency management in a mobile device |
US7904418B2 (en) * | 2006-11-14 | 2011-03-08 | Microsoft Corporation | On-demand incremental update of data structures using edit list |
KR100942695B1 (en) * | 2006-12-04 | 2010-02-16 | 한국전자통신연구원 | Client system and method for managing a software version thereof |
US8095517B2 (en) * | 2007-02-08 | 2012-01-10 | Blue Coat Systems, Inc. | Method and system for policy-based protection of application data |
US9563640B2 (en) * | 2007-02-09 | 2017-02-07 | Micro Focus Software Inc. | Techniques for versioning files |
EA200700455A1 (en) * | 2007-02-13 | 2008-08-29 | Общество С Ограниченной Ответственностью "Крипто-Про" | METHOD FOR UPDATING SOFTWARE SECURITY OF SOFTWARE |
US8230417B1 (en) | 2007-06-08 | 2012-07-24 | Adobe Systems Incorporated | Combined application and execution environment install |
US7930273B1 (en) * | 2007-07-30 | 2011-04-19 | Adobe Systems Incorporated | Version management for application execution environment |
US8375381B1 (en) | 2007-07-30 | 2013-02-12 | Adobe Systems Incorporated | Management user interface for application execution environment |
US8448161B2 (en) * | 2007-07-30 | 2013-05-21 | Adobe Systems Incorporated | Application tracking for application execution environment |
US8122447B2 (en) * | 2007-07-31 | 2012-02-21 | Hewlett-Packard Development Company, L.P. | Firmware installation |
US8122444B2 (en) * | 2007-08-02 | 2012-02-21 | Accenture Global Services Limited | Legacy application decommissioning framework |
US8589909B2 (en) * | 2008-01-10 | 2013-11-19 | Oracle International Corporation | Techniques for reducing down time in updating applications with metadata |
TWI416410B (en) * | 2008-04-11 | 2013-11-21 | Hon Hai Prec Ind Co Ltd | System and method for updating version of the executable file |
US8234709B2 (en) * | 2008-06-20 | 2012-07-31 | Symantec Operating Corporation | Streaming malware definition updates |
US20100153942A1 (en) * | 2008-12-12 | 2010-06-17 | Lazar Borissov | Method and a system for delivering latest hotfixes with a support package stack |
US8468516B1 (en) * | 2008-12-19 | 2013-06-18 | Juniper Networks, Inc. | Creating hot patches for embedded systems |
US8438558B1 (en) | 2009-03-27 | 2013-05-07 | Google Inc. | System and method of updating programs and data |
US9195455B2 (en) | 2009-04-01 | 2015-11-24 | Oracle International Corporation | Reducing downtime when patching multiple inter-dependent software components |
US10013277B2 (en) * | 2009-05-29 | 2018-07-03 | Red Hat, Inc. | Rolling back state changes in distributed transactions |
JP5428721B2 (en) * | 2009-10-02 | 2014-02-26 | 富士通株式会社 | Management system, management device, management method, and management program |
US20110106776A1 (en) * | 2009-11-03 | 2011-05-05 | Schlumberger Technology Corporation | Incremental implementation of undo/redo support in legacy applications |
US20110107246A1 (en) * | 2009-11-03 | 2011-05-05 | Schlumberger Technology Corporation | Undo/redo operations for multi-object data |
US20110138374A1 (en) * | 2009-12-09 | 2011-06-09 | Suprio Pal | Downtime reduction for enterprise manager patching |
US9021392B2 (en) * | 2010-07-26 | 2015-04-28 | Sap Se | Managing extension projects with repository based tagging |
US8762980B1 (en) * | 2010-09-09 | 2014-06-24 | Symantec Corporation | Rolling incremental updates |
US8856724B2 (en) | 2011-06-20 | 2014-10-07 | Ebay Inc. | Systems and methods for incremental software development |
US9250866B2 (en) | 2011-06-20 | 2016-02-02 | Ebay Inc. | Systems and methods for incremental software deployment |
US20130111458A1 (en) * | 2011-11-02 | 2013-05-02 | Research In Motion Limited | Method and system for on-demand patch generation and management |
US8789034B1 (en) * | 2011-12-31 | 2014-07-22 | Parallels IP Holdings GmbH | Method for updating operating system without memory reset |
JP5860436B2 (en) * | 2013-06-14 | 2016-02-16 | 京セラドキュメントソリューションズ株式会社 | Software update program and software update device |
US9965271B2 (en) * | 2015-04-28 | 2018-05-08 | Microsoft Technology Licensing, Llc | Projection of build and design-time inputs and outputs between different build environments |
US10389794B2 (en) | 2015-05-21 | 2019-08-20 | International Business Machines Corporation | Managing redundancy among application bundles |
US10530660B2 (en) | 2015-05-21 | 2020-01-07 | International Business Machines Corporation | Application bundle preloading |
US10389850B2 (en) | 2015-05-21 | 2019-08-20 | International Business Machines Corporation | Managing redundancy among application bundles |
US9965262B2 (en) * | 2015-05-21 | 2018-05-08 | International Business Machines Corporation | Application bundle pulling |
US10152516B2 (en) | 2015-05-21 | 2018-12-11 | International Business Machines Corporation | Managing staleness latency among application bundles |
US9888057B2 (en) | 2015-05-21 | 2018-02-06 | International Business Machines Corporation | Application bundle management across mixed file system types |
US9792109B2 (en) | 2015-09-30 | 2017-10-17 | Apple Inc. | Software updating |
US11379102B1 (en) * | 2015-10-23 | 2022-07-05 | Perfect Sense, Inc. | Native application development techniques |
WO2017130030A1 (en) * | 2016-01-29 | 2017-08-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Rolling upgrade with dynamic batch size |
CN109074248A (en) * | 2016-04-04 | 2018-12-21 | 鲁门无线电通信公司 | Method for the software upgrading distributed in communication network |
US11055087B2 (en) * | 2018-03-16 | 2021-07-06 | Google Llc | Leveraging previously installed application elements to install an application |
US10509642B2 (en) * | 2018-03-30 | 2019-12-17 | International Business Machines Corporation | Intelligent discovery and application of API changes for application migration |
US10635428B2 (en) * | 2018-03-30 | 2020-04-28 | Arista Networks, Inc. | System and method for in-service update of software |
CN108829418A (en) * | 2018-06-01 | 2018-11-16 | 联想(北京)有限公司 | A kind of processing method and electronic equipment |
US20200104118A1 (en) * | 2018-09-28 | 2020-04-02 | Bose Corporation | Systems and methods for providing staged updates in embedded devices |
US10846179B2 (en) | 2018-11-05 | 2020-11-24 | Arista Networks, Inc. | Hitless repair for network device components |
US11301231B2 (en) | 2019-04-05 | 2022-04-12 | Arista Networks, Inc. | Dynamic run time programming of hardware tables |
US11379215B1 (en) * | 2020-06-15 | 2022-07-05 | Amazon Technologies, Inc. | Application-update techniques |
US11822910B2 (en) | 2021-10-14 | 2023-11-21 | International Business Machines Corporation | Reducing a delivery size of a software update |
Family Cites Families (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3969723A (en) | 1974-07-03 | 1976-07-13 | General Electric Company | On-line modification of computer programs |
US4558413A (en) | 1983-11-21 | 1985-12-10 | Xerox Corporation | Software version management system |
US4714992A (en) | 1985-11-26 | 1987-12-22 | International Business Machines Corporation | Communication for version management in a distributed information service |
EP0230616A3 (en) * | 1986-01-21 | 1991-10-23 | International Business Machines Corporation | Library management system |
US4809170A (en) * | 1987-04-22 | 1989-02-28 | Apollo Computer, Inc. | Computer device for aiding in the development of software system |
US5155847A (en) * | 1988-08-03 | 1992-10-13 | Minicom Data Corporation | Method and apparatus for updating software at remote locations |
US5182806A (en) * | 1989-06-30 | 1993-01-26 | Digital Equipment Corporation | Incremental compiler for source-code development system |
EP0415863A3 (en) * | 1989-08-31 | 1992-02-26 | International Business Machines Corporation | Computer system with downward compatibility function |
US5495610A (en) * | 1989-11-30 | 1996-02-27 | Seer Technologies, Inc. | Software distribution system to build and distribute a software release |
US5204960A (en) * | 1990-01-08 | 1993-04-20 | Microsoft Corporation | Incremental compiler |
US5479654A (en) * | 1990-04-26 | 1995-12-26 | Squibb Data Systems, Inc. | Apparatus and method for reconstructing a file from a difference signature and an original file |
US5649200A (en) * | 1993-01-08 | 1997-07-15 | Atria Software, Inc. | Dynamic rule-based version control system |
US5566335A (en) * | 1993-03-16 | 1996-10-15 | Hewlett-Packard Company | Method and apparatus for firmware upgrades in embedded systems |
WO1994025913A2 (en) * | 1993-04-30 | 1994-11-10 | Novadigm, Inc. | Method and apparatus for enterprise desktop management |
US5519866A (en) * | 1993-06-28 | 1996-05-21 | Taligent, Inc. | Method and apparatus of incrementally linking components of a modeled computer program |
CA2147036A1 (en) * | 1994-05-16 | 1995-11-17 | Yih-Farn Robin Chen | System and method for selective regression testing |
US5574906A (en) * | 1994-10-24 | 1996-11-12 | International Business Machines Corporation | System and method for reducing storage requirement in backup subsystems utilizing segmented compression and differencing |
US5699275A (en) * | 1995-04-12 | 1997-12-16 | Highwaymaster Communications, Inc. | System and method for remote patching of operating code located in a mobile unit |
US5790856A (en) * | 1995-05-08 | 1998-08-04 | Apple Computer, Inc. | Methods, apparatus, and data structures for data driven computer patches and static analysis of same |
US5671398A (en) * | 1995-06-09 | 1997-09-23 | Unisys Corporation | Method for collapsing a version tree which depicts a history of system data and processes for an enterprise |
US5745906A (en) * | 1995-11-14 | 1998-04-28 | Deltatech Research, Inc. | Method and apparatus for merging delta streams to reconstruct a computer file |
US5729743A (en) * | 1995-11-17 | 1998-03-17 | Deltatech Research, Inc. | Computer apparatus and method for merging system deltas |
US6349407B1 (en) * | 1995-12-29 | 2002-02-19 | Sun Microsystems, Incorporated | Method and apparatus for re-introducing version control |
KR100286008B1 (en) * | 1995-12-30 | 2001-04-16 | 윤종용 | Method for automatically updating software program |
US6006242A (en) * | 1996-04-05 | 1999-12-21 | Bankers Systems, Inc. | Apparatus and method for dynamically creating a document |
US5893113A (en) * | 1996-04-25 | 1999-04-06 | Navigation Technologies Corporation | Update transactions and method and programming for use thereof for incrementally updating a geographic database |
US6151643A (en) | 1996-06-07 | 2000-11-21 | Networks Associates, Inc. | Automatic updating of diverse software products on multiple client computer systems by downloading scanning application to client computer and generating software list on client computer |
US5832499A (en) * | 1996-07-10 | 1998-11-03 | Survivors Of The Shoah Visual History Foundation | Digital library system |
US6006034A (en) * | 1996-09-05 | 1999-12-21 | Open Software Associates, Ltd. | Systems and methods for automatic application version upgrading and maintenance |
US5960204A (en) * | 1996-10-28 | 1999-09-28 | J.D. Edwards World Source Company | System and method for installing applications on a computer on an as needed basis |
US5933647A (en) * | 1997-01-24 | 1999-08-03 | Cognet Corporation | System and method for software distribution and desktop management in a computer network environment |
FR2762737B1 (en) * | 1997-04-24 | 1999-06-11 | Alsthom Cge Alcatel | METHOD FOR CHANGING SOFTWARE VERSION IN A COMPUTER SYSTEM COMPRISING MULTIPLE STATIONS, AND COMPUTER SYSTEM FOR IMPLEMENTING SAID METHOD |
US5948104A (en) | 1997-05-23 | 1999-09-07 | Neuromedical Systems, Inc. | System and method for automated anti-viral file update |
US6081814A (en) * | 1997-07-07 | 2000-06-27 | Novell, Inc. | Document reference environment manager |
US6119165A (en) | 1997-11-17 | 2000-09-12 | Trend Micro, Inc. | Controlled distribution of application programs in a computer network |
US6035423A (en) | 1997-12-31 | 2000-03-07 | Network Associates, Inc. | Method and system for providing automated updating and upgrading of antivirus applications using a computer network |
US6510552B1 (en) * | 1999-01-29 | 2003-01-21 | International Business Machines Corporation | Apparatus for keeping several versions of a file |
US6535894B1 (en) * | 2000-06-01 | 2003-03-18 | Sun Microsystems, Inc. | Apparatus and method for incremental updating of archive files |
-
1998
- 1998-03-25 US US09/047,949 patent/US6052531A/en not_active Expired - Lifetime
-
1999
- 1999-03-25 EP EP99915047A patent/EP1073952B1/en not_active Expired - Lifetime
- 1999-03-25 WO PCT/US1999/006619 patent/WO1999049391A2/en active IP Right Grant
- 1999-03-25 DE DE69902898T patent/DE69902898T2/en not_active Expired - Lifetime
- 1999-03-25 CA CA002325544A patent/CA2325544C/en not_active Expired - Fee Related
- 1999-12-22 US US09/469,582 patent/US6651249B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
WO1999049391A3 (en) | 1999-12-23 |
EP1073952B1 (en) | 2002-09-11 |
US6651249B2 (en) | 2003-11-18 |
DE69902898D1 (en) | 2002-10-17 |
CA2325544A1 (en) | 1999-09-30 |
WO1999049391A2 (en) | 1999-09-30 |
US20030177485A1 (en) | 2003-09-18 |
EP1073952A2 (en) | 2001-02-07 |
DE69902898T2 (en) | 2003-05-22 |
US6052531A (en) | 2000-04-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2325544C (en) | Multi-tiered incremental software updating | |
US7185332B1 (en) | Multi-tiered incremental software updating | |
US7457831B2 (en) | Peripheral device driver maintenance scheme for networked peripheral device clients | |
US6349311B1 (en) | Storage of reverse delta updates | |
US7559059B2 (en) | Method and apparatus for smart directories for application deployment | |
US7222341B2 (en) | Method and system for processing software dependencies in management of software packages | |
US8417686B2 (en) | Web crawler scheduler that utilizes sitemaps from websites | |
EP0978033B1 (en) | Use of polymorphic package files to update software components | |
AU2002325054A1 (en) | Method and apparatus for smart directories for application deployment | |
US20060015527A1 (en) | System and method for transport of objects utilizing LDAP directory structure | |
US20050246702A1 (en) | System and method for automatically updating versions of software programs in client computers | |
US20040054800A1 (en) | Content synchronization frameworks using dynamic attributes and file bundles for connected devices | |
US7054859B2 (en) | Apparatus and method for responding to search requests for stored documents | |
US6862616B1 (en) | System and method for facilitating distributed server administration of server systems that are scalable and version independent | |
US7536404B2 (en) | Electronic files preparation for storage in a server | |
US6424976B1 (en) | Method of implementing a forward compatibility network directory syntax | |
US20030115172A1 (en) | Electronic file management | |
US20100037129A1 (en) | Electronic Document Request/Supply Method Based on XML | |
JP2002014817A (en) | System for distributing file | |
JP2002304263A (en) | Network printing system | |
JP2004021531A (en) | Document management device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKLA | Lapsed |