US20090271782A1 - Mechanism for determining applicability of software packages for installation - Google Patents
Mechanism for determining applicability of software packages for installation Download PDFInfo
- Publication number
- US20090271782A1 US20090271782A1 US12/435,330 US43533009A US2009271782A1 US 20090271782 A1 US20090271782 A1 US 20090271782A1 US 43533009 A US43533009 A US 43533009A US 2009271782 A1 US2009271782 A1 US 2009271782A1
- Authority
- US
- United States
- Prior art keywords
- component
- components
- file
- installation
- version
- 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.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
Definitions
- the present invention relates generally to computer systems. More particularly, this invention relates to mechanism for determining applicability of software packages for installation.
- the Internet provides a channel for customers to obtain the latest updates for software products.
- the vendor sites on the Internet can be designed to make it very simple to discover and locate updated files for an application.
- the technical aspects of file downloading have mostly disappeared from the user's view, and are now typically handled by the operating system.
- file patches which contain only the changes that must be made to pre-existing files, rather than the whole files themselves.
- a patch assumes that the original file on the target system is of a specific state. “Patching” applies changes to that file to bring the file to a desired, usually newer, state. However, the file should be verified to be in the required condition. Otherwise, the patch may be incorrectly applied and the file may be damaged. If a file to be patched is in an unexpected state, the patch cannot be applied.
- the client machine has a sub-component that has a newer version than the one about to be upgraded, a conventional installation may abort the whole installation, even though there might be other sub-components that have older versions.
- a process is provided to retrieve authentication information for a component from an installation descriptor file, where the descriptor file describes installation information pertaining to the software package.
- the software package may include one or more components and each component having zero or more sub-components. For at least one sub-component of at least one existing component that has already been installed, an image of the sub-component is authenticated using an authentication key extracted from the authentication information, to determine whether the component can be installed based on the existing version of the component.
- FIG. 1 is a diagram of a network of computer systems in which one or more clients may download and install a software package from a server.
- FIG. 2 is a block diagram illustrating an exemplary component descriptor of an installation descriptor file according to one embodiment of the invention.
- FIG. 3 is a timeline illustrating a version timeline of a software package upgrade according to one embodiment.
- FIG. 4 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.
- FIG. 5 is a block diagram illustrating an exemplary document-type definition (DTD) file of an installation descriptor according to one embodiment of the invention.
- DTD document-type definition
- FIGS. 6A-6D are an example of an installation descriptor file written in XML according to one embodiment of the invention.
- FIG. 7 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.
- FIG. 8 is a flow diagram illustrating an exemplary process for installing a software package according to another embodiment of the invention.
- FIG. 9 is a flow diagram illustrating an exemplary process for installing a software package according to another embodiment of the invention.
- FIG. 10 is a block diagram of a digital processing system, which may be used with one embodiment of the invention.
- an installation package is optimized by size, containing a combination of patches and/or full files. Installation of the package ensures that the user will have at least the version of the software included in the package.
- the content of an installation package includes patches for some files and/or full versions of some other files, dependent upon the configurations.
- the package further includes a package description file, which may be used by an installer to determine whether the installation package can be installed.
- the package description file also referred to as installation descriptor file or a package metadata (PKM) file, describes the contents of the installation package with sufficient details to allow the installation system to determine whether the software package can be installed on a client system.
- PPM package metadata
- the PKM file further includes one or more components and each component includes zero or more files (e.g., sub-components or child components).
- the files to be updated or added to the client system are divided into distinct, non-overlapping components.
- the information contained in the PKM file about the individual files is grouped by component.
- two types of versioning may be used: component version for some of the components and authentication information for authenticating or determining authenticity of at least some of the files for each component.
- the first version is the version of the component that is expected to be on the client system prior to applying the patches, also referred to as a pre-install version.
- the second version is the version of the component that the client system will contain after the patches are applied, also referred to as a post-install version.
- more or less versions may be implemented.
- the authentication information includes at least one authentication key, which may be used to authenticate a file image of at least some files of a component or alternatively, to authenticate the component itself.
- the authentication key may include a checksum value and the authentication operations may include a checksum operation.
- the authentication information includes a pre-install authentication key and a post-install authentication key.
- the pre-install authentication key may be used to authenticate the pre-existing file corresponding to the file being installed.
- the post-install authentication key may be used to verify whether a particular file has already been installed.
- the pre-install and post-install authentication keys may be checksum values (e.g., pre-install and post-install checksum values).
- the present invention also relates to apparatus for performing the operations herein.
- This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer.
- a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
- a machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer).
- a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
- FIG. 1 is a diagram of a network of computer systems in which one or more clients may download and install a software package from a server.
- a network 100 includes a number of client computer systems 101 that are coupled together through a network 102 , for example, an Internet.
- the term “Internet” refers to a network of networks.
- Such networks may use a variety of protocols for exchange of information, such as TCP/IP, ATM, SNA, SDI, etc.
- the physical connections of the Internet and the protocols and communication procedures of the Internet are well known to those in the art.
- Such a system may be implemented in an Intranet within an organization.
- Access to the Internet 102 is typically provided by Internet service providers (ISPs). Users on client systems, such as the client computer systems 101 , generally obtain access to the Internet through Internet service providers. Access to the Internet may facilitate transfer of information (e.g., email, text files, media files, etc.) between two or more digital processing systems and/or a server system 103 , which may be a Web server. For example, one or more of the client computer systems and/or the Web server may provide document presentations (e.g., a Web page) to another one or more of the client computer systems and/or Web server.
- ISPs Internet service providers
- one or more client computer systems 101 may request to access a document that may be stored at a remote location, such as the Web server 103 .
- a remote location such as the Web server 103 .
- the data may be transferred as a file (e.g., download) and then displayed (e.g., in a window of a browser) after transferring the file.
- the document presentation may be stored locally at the client computer systems.
- the client system may retrieve and display the document via an application, such as a word processing application, without requiring a network connection.
- the server 103 typically includes at least one computer system to operate with one or more data communication protocols, such as the protocols of the World Wide Web, and as such, is typically coupled to the Internet 102 .
- the server 103 may be part of an ISP which may provide access to the Internet and/or other network(s) for client computer systems.
- the client computer systems 101 may each, with appropriate Web browsing software, access data, such as HTML documents (e.g., Web pages), which may be provided by the server 103 .
- the ISP provides Internet connectivity to the client computer system 101 via a network interface, which may be considered as part of the client computer system.
- the client computer systems may be a conventional data processing system, such as a Power Mac G5 or iMac computer available from Apple Computer, Inc., a “network” computer, a handheld portable computer, a cell phone with data processing capabilities, a Web TV system, or other types of digital processing systems (e.g., a personal digital assistant (PDA)).
- PDA personal digital assistant
- the client computer system 101 may be part of a local area network (LAN).
- the network interface of the client 101 may represent an analog modern, an ISDN modem, a DSL modem, a cable modem, a wireless interface, or other interface for coupling a digital processing system, such as a client computer system, to another digital processing system.
- the network interface of client 101 may be an Ethernet-type, asynchronous transfer mode (ATM), or other type of network interface, which may couple the client 101 to a local area network (LAN).
- the LAN may also be coupled to a gateway digital processing system, which may provide firewall and other Internet-related services for a LAN.
- the gateway digital processing system is coupled to the ISP to provide Internet connectivity to the client computer systems 101 .
- the gateway digital processing system may, for example, include a conventional server computer system.
- the server 103 may, for example, include a conventional server computer system.
- server 103 may be a Web server that provides software upgrade packages, which may include one or more software packages 109 .
- the server 103 may be file server of a local network, such as, for example, an Intranet.
- the installer 107 may be shared by some or all installation of software packages 109 .
- the installer 107 is capable of reading the installation description from the respective PKM file and correctly installs the respective software package.
- the client 101 may download the installer 104 and the PKM file 106 corresponding to the software package being installed.
- the client system 101 includes the installer 104 pre-installed when the client system was manufactured. In which case, the client 101 only needs to download the PKM file 106 .
- the installer 104 retrieves installation description from the PKM file 106 to determine the installation configuration of the respective software package being installed.
- the installation description may include versioning and authentication information, which may be used to verify one or more existing components and/or files 105 that have already been installed in the client 101 from which the new patches or components may be installed.
- the PKM file 106 includes one or more component descriptors 110 describing installation of the corresponding one or more components.
- Each of the components described by the descriptors 110 may optionally include version information 111 associated with the respective component.
- each of the component descriptors may include zero or more sub-component descriptors 112 describing installation of zero or more files grouped under the respective component.
- the sub-component descriptors 112 may include a pre-install authentication key 113 and a post-install authentication key 114 .
- the pre-install authentication key 113 may be used to authenticate the pre-existing sub-component corresponding to the sub-component being installed.
- the post-install authentication key 114 may be used to verify whether a particular sub-component has already been installed.
- pre-install and post-install authentication keys may be checksum values.
- a sub-component may be a file associated with a component.
- a file and a sub-component are used interchangeably. However, they are not so limited.
- a sub-component, as a parent component, may further include one or more sub-components (e.g., child components).
- the installation system uses the information retrieved from the PKM file 106 to ensure that the client will have at least the version of each of the software components included in the installation package when the installation is completed. Since performing authentication (e.g., a checksum operation) on a file is a relatively time-expensive operation, the component version 111 may be used to optimize the install target verification process.
- authentication e.g., a checksum operation
- the installer would know by comparing the version of the existing component and the version retrieved from the PKM file, without having to perform the authentication on each file of the existing component, that the client system does not meet the requirement of the installation package.
- the installation system does not need to install the files for that component, while allowing the rest of the installation package to proceed.
- the installer 104 may further perform the authentication on each of the sub-components described by the sub-component descriptors 112 to ensure that the sub-components have not been tampered with and are of the exact state required by the patch, using the pre-install authentication information 113 .
- the post-install authentication information 114 may be used to verify whether the sub-component (e.g., file) being updated has already been installed in the client system 101 . In such a case, the sub-component does not need to be installed (e.g., skipping). On the other hand, if the post-install authentication is not performed successfully, the patch cannot be applied to the client system 101 and the installation of the entire software package should not be allowed.
- the PKM file 106 and/or installer 104 are initially downloaded from the server 103 to the client system 101 without downloading the actual software package 109 being installed.
- the installer 104 is capable of determining whether the software package (e.g., the patches) can be installed on the client system 101 , or alternatively, a full installation of the software may be needed. Once the installer 104 determines that the software package may be installed based on the existing components and/or files 105 , the installer 104 may download the necessary patch files (e.g., only those that would be installed) from the server 103 to install the patches.
- the installer 104 may download the full installation image of the software (e.g., full version) and perform a complete installation of the software, which consumes more time and resources.
- the PKM file 108 may provide additional information regarding other portions of the package that are located on other media. For example, if a particular software distribution is packaged on multiple CDs, the PKM file of the first CD may provide information regarding the files stored in the subsequent CDs. At the beginning of the installation, a user can choose which of the packages she would like to install from the subsequent CDs without having to insert the subsequent CDs, where the installer can simply read the PKM files for those packages existing elsewhere.
- server 103 may include multiple servers separated from each other. Some or all of the components 107 - 109 may be located on different servers. For example, the installer 107 and the PKM files 108 may be downloaded from a first server. After the installer 107 determines, based on the PKM files 108 , which patches may be installed at a client machine, the actual patches to be installed may be downloaded from a second server. Other configurations may exist.
- FIG. 2 is a block diagram illustrating an exemplary component descriptor of an installation descriptor file according to one embodiment of the invention.
- the exemplary component descriptor 200 may be implemented, for example, as a component descriptor 110 of FIG. 1 .
- exemplary component 200 also referred to as a bundle, includes a default path 201 indicating where the component is being installed.
- the exemplary component 200 also includes a bundle information block 202 to specify the specific information associated with the respective bundle.
- the information block 202 includes an identifier 204 for identifying the respective bundle, a bundle version 205 indicating the version of the bundle being installed and a pre-bundle version of an existing bundle on top of which the new bundle is to be installed.
- the exemplary component 200 further includes files block 203 having zero or more files 207 - 208 (e.g., sub-components).
- Each of the files 207 - 208 may include a path 209 and 211 respectively to specify where the file will be installed and authentication keys 210 and 212 to provide authentication information; including pre-install and post-install authentication keys to the installer to perform authentication operations.
- FIG. 3 is a timeline illustrating a version timeline of a software package upgrade according to one embodiment.
- the exemplary timeline 300 includes a software package having a component with newer version 302 that is intended to be installed on a system with previous version of an existing component 301 . That is, the component having version 302 is intended to be installed on a client machine that already has a previous component having version 301 . If the existing component has any other version between the versions 302 and 301 , such as, for example, version 307 , the installation of the component (e.g., the upgrade) would not be allowed.
- the installer opens and parses a PKM file to identify each of the components being installed. If the respective component is a versioned component (e.g., the component has a specific version, which may be described in a version block such as version block 111 of FIG. 1 ), the installer examines the version of the corresponding existing component. If the version of the existing component is the same or newer than the version of the component that is about to be installed, in this case, situation 303 , the component does not need to be installed and the installation of the component will be skipped.
- a versioned component e.g., the component has a specific version, which may be described in a version block such as version block 111 of FIG. 1
- the installer examines the version of the corresponding existing component. If the version of the existing component is the same or newer than the version of the component that is about to be installed, in this case, situation 303 , the component does not need to be installed and the installation of the component will be skipped.
- the installer may further authenticate at least one of the sub-components of the existing component using the pre-install authentication information retrieved from the PKM file. If the authentication is performed successfully, the new component will be installed based on the existing component. Otherwise, the installation may be aborted. Similarly, if the version of the existing component is older than the pre-install version (e.g., situation 306 ) or between the pre-install version and the post-install version, such as version 307 (e.g., situation 305 ), the installation may be aborted.
- the pre-install version e.g., situation 306
- version 307 e.g., situation 305
- FIG. 4 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.
- Exemplary process 400 may be performed by a processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a dedicated machine), or a combination of both.
- the exemplary process 400 may be performed by an installer using a PKM file, such as, for example, installer 104 using PKM file 106 of FIG. 1 .
- exemplary process 400 includes, but is not limited to, downloading from a server over a network a package metadata (PKM) file describing installation of the software package without downloading the software package.
- the software package including one or more components and each of the components having zero or more sub-components, authenticating an image of at least one sub-component of at least one existing component from which the software package is installed, wherein the authentication is performed using a first key retrieved from the PKM file, and downloading at least a portion of the software package from the server to be installed if the image of at least one sub-component is authenticated successfully using the first key retrieved from the PKM file.
- a PKM file is downloaded from a server over a network.
- an installer application e.g., installer 104 of FIG. 1
- the PKM file may provide sufficient information describing the installation of a software package being installed.
- the software package may include one or more components (e.g., bundles) and each component may include zero or more files.
- the PKM file may be a metadata file written in a variety of programming languages, such as, for example, XML and HTML (hypertext markup language). In one embodiment, the actual software package has not been downloaded yet at this point.
- the PKM file may be downloaded over the Internet from a Web server using a variety of protocols, for example, TCP/IP protocols.
- the PKM file may be downloaded from a server within a local network (e.g., the Intranet or LAN).
- the authentication information associated with the respective file is retrieved from the PKM file.
- the authentication information may be used to authenticate an image of an existing sub-component (e.g., file) of an existing component to determine whether a new version of the component may be installed on the basis of the existing sub-component of the existing component.
- the authentication information includes an authentication key for authenticating the sub-component.
- an authentication operation is performed on the existing sub-component of the existing component that has already been installed in a client machine, using the authentication information retrieved from the PKM file, for example, an authentication key.
- the authentication key may include a checksum value and the authentication operation includes a checksum operation performed on the sub-component using the checksum value.
- the actual sub-components and/or the respective component may be downloaded from the server and installed in the client machine.
- a full installation image of the software package, rather than patches may be downloaded and the full installation may be invoked.
- FIG. 5 is a block diagram illustrating an exemplary document-type definition (DTD) file of an installation descriptor according to one embodiment of the invention.
- DTD document-type definition
- FIGS. 6A-6D An example of an installation descriptor written in XML is shown in FIGS. 6A-6D according to certain embodiments of the invention.
- the installation descriptor is not limited to XML. It will be appreciated that other languages, such as, for example, HTML (hypertext markup language) may also be used.
- exemplary DTD 500 includes a package information tag 501 for describing general information regarding the software package being installed.
- the package information 501 may include an identifier tag 502 to provide an identifier for identifying the software package being installed.
- the identifier specified by the identifier tag 502 may be a unique identifier specifically identifying the package.
- An example of a package information block and the identifier tag in XML are shown as package information block 601 and identifier 602 in FIG. 6A .
- the exemplary DTD 500 may also include a version block 503 .
- An example of a version block is shown as version block 603 in FIG. 6A .
- the version of the software package being installed may include at least one of a short version, a major version, a minor version, a build version, and/or a build date. Other version related information may be included.
- the exemplary DTD 500 may also include one or more flags which may be implemented within a flag block 504 .
- An example of a flag block is shown as a flag block 604 in FIG. 6A .
- a variety of flags may be implemented within the flag block 504 . For example, there may be a flag that indicates whether the client system has to restart after the installation of the package.
- the exemplary DTD 500 includes a component block (e.g., a component array) 505 that may include one or more components 506 .
- Each of the components may or may not include one or more sub-components 513 , for example, one or more sub-components grouped under the respective component.
- the exemplary installation descriptor 600 shown in FIGS. 6A-6D includes components 606 and 621 - 622 , which may include zero or more sub-components respectively.
- component 606 includes sub-components 614 and 620
- component 622 includes sub-components 623 - 625 .
- certain sub-components may further include their respective sub-components (e.g., child components).
- each component 506 may include a component information tag 507 and an identifier tag 508 .
- An example of a component information block and an identifier tag are shown as tags 607 and 608 in FIG. 6B .
- the component identifier includes a string that uniquely identifies a component (e.g., a bundle) of a client machine. This information may be found in a predetermined location of the client machine and may be hidden from a user of the client machine, such that the user may not easily modify it.
- each component 506 may include a default path tag 512 specifying where the component, including the sub-components, may be installed. However, a specific sub-component may further specify a path which may override the default path of the parent component.
- a component may or may not be a versioned component. That is, a component may or may not have an associated version number, string, or combination of both. If a component is a versioned component, the component may include a version block 509 , which may include a pre-install version 510 , a post-install version 511 , and/or other version related information.
- Pre-install version 510 may be used to represent the version of the component that is required to patch the existing component (e.g., an existing component that has already been installed in the client machine prior to the current installation).
- the pre-install version 510 may be the version of the component used as a “baseline” from which the patches are generated.
- Post-install version 511 may be used to represent the version of the component being installed (e.g., a new component version).
- Post-install version 511 is the version to which the described software package will update the client machine. That is, the post-install version 511 is the version the component has after the current installation.
- each of the pre-install and post-install versions includes at least one of a build version, a version string, a component version, and/or a source version, where the source version is an identifier that uniquely identifies a snapshot of the sources in time.
- An example of a pre-install and a post-install versions is shown as a pre-install version 610 and a post-install version 611 in FIG. 6B .
- each of the components 505 may or may not include a sub-component block describing one or more sub-components 514 .
- the sub-component 514 may further include a sub-component information tag 515 describing the respective sub-component.
- the sub-component 514 may optionally include a path 517 specifying a path at which the respective sub-component may be installed.
- the path 517 may be used to override or supplement the default path 512 of the parent component 506 .
- the sub-component path may be the actual location within the component's location/directory structure.
- the sub-component path combined with the path of the component, identifies the location at which the file should be installed or patched. If the path 517 is absent, the respective sub-component may be installed according to the default path 512 of the parent component 506 .
- the sub-component 514 may further include a pre-install authentication key 518 and/or a post-install authentication key 519 .
- the pre-install and/or post-install authentication keys may include checksum values and the authentication operations may include checksum operations. It will be appreciated that other authentication mechanisms may be utilized.
- the pre-install authentication key 518 may be used to authenticate an image of an existing sub-component that has already been installed on the client machine, which serves as a baseline of the respective patch.
- An example of the pre-install authentication key 518 and the post-install authentication key 519 is shown as keys 618 and 619 respectively in FIG. 6B .
- the installer retrieves the pre-install authentication key 518 from the installation descriptor file and authenticates the image of the existing sub-component using the pre-install authentication key 518 to ensure that the existing component satisfies the prerequisites of the patch. If the existing sub-component cannot be authenticated successfully, the patch may not be installed.
- the post-install authentication key 519 may be used to authenticate the existing component to determine whether the new version of the component (e.g., the patch) has already been installed. In one embodiment, if the pre-install authentication fails, the installer may optionally use the post-install authentication key 519 to determine whether the new file or component has already been installed. In such a case, the respective patch installation may be skipped. In another embodiment, the post-version of the parent component may be used to determine whether the new component version has already been installed prior to the post-install authentication.
- some of the components may not be patched components. That is, those components may not include patches.
- the version information regarding the patches may not be needed.
- the version block 509 and the sub-component block 513 may not be needed, leaving only the identification information 507 and 508 , as well as the default path 512 in the descriptor for those components.
- a full installation for the respective component may be performed instead of patching.
- An example of such a component is shown as component 621 of FIG. 6C .
- certain components may not have an associated version (e.g., the component is not part of a versioned bundle).
- the version block 509 may not be needed.
- the pre-install and post-install authentication keys 518 and 519 may be used to authenticate the sub-components of the non-versioned component.
- An example of a non-versioned component is shown as component 622 of FIG. 6C .
- Other configurations may exist.
- FIG. 7 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.
- Exemplary process 700 may be performed by a processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a dedicated machine), or a combination of both.
- the exemplary process 700 may be performed by an installer using a PKM file such as, for example, installer 104 using PKM file 106 of FIG. 1 .
- exemplary process 700 includes, but is not limited to, retrieving authentication information of a component from an installation descriptor file describing installation of the software package, the software package having one or more components and each component having zero or more sub-components, and authenticating an image of at least one sub-component of an existing component that has already been installed using a first key extracted from the authentication information to determine whether the component can be installed based on the existing component.
- installation description information for a component of a software package being deployed is retrieved from an installation descriptor file (e.g., a PKM file).
- the installation descriptor file describes installation of one or more components and each component may include one or more sub-components, for example, one or more files.
- the installation descriptor file may be a scripting file written in a variety of languages, such as, for example, XML or HTML, etc.
- the descriptor file may include some or all of the installation information described in accordance with the exemplary DTD 500 of FIG. 5 .
- the respective component is examined to determine whether the component is a versioned component. If the component is a versioned component, at block 703 , the version of the existing component corresponding to the component being installed is verified using a pre-install version extracted from the installation information retrieved from the installation descriptor file. The verification is performed to ensure that the client machine being patched contains a pre-required existing component from which (e.g., a baseline) the patches are generated.
- the processing logic authenticates an image of each sub-component of the respective component using one or more authentication keys extracted from the installation information.
- the authentication keys include a pre-install authentication key and a post-install authentication key.
- the pre-install authentication key may be used to authenticate an image of an existing sub-component that has already been installed on the client machine, which serves as a baseline for the respective patch.
- the post-install authentication key may be used to authenticate the existing component to determine whether the new component version (e.g., the patch) has already been installed.
- the pre-install and post-install authentication keys may include checksum values and the authentication operations may include checksum operations. Other authentication mechanisms may be utilized. If the authentication is performed successfully, at block 705 , it is indicated that the respective component will be installed subsequently. If the authentication is performed unsuccessfully, at block 711 , it is determined whether the sub-component has already been installed.
- the authentication is performed using a post-install key extracted from the descriptor file. If the sub-component has already been installed (e.g., post-install authentication is performed successfully), at block 709 , the sub-component is indicated that it is does not need to be installed. Otherwise, at block 710 , the operation will be aborted.
- the processing logic verifies whether the updated component has already been installed. In one embodiment, the verification is performed by comparing the version of the existing component with a post-install version extracted from the installation descriptor.
- a post-install authentication may be performed on an image of each sub-component of the existing component, using a post-install authentication key extracted from the installation descriptor file.
- the patching installation may be aborted.
- the components and/or the sub-components that have been indicated are installed and those without indication will be skipped. Other operations may also be performed.
- FIG. 8 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.
- Exemplary process 800 may be performed by a processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a dedicated machine), or a combination of both.
- the exemplary process 800 may be performed as a part of operations involved in block 704 of FIG. 7 .
- exemplary process 800 may be performed on a non-versioned component.
- the processing logic authenticates each sub-component of an existing component corresponding to the component being installed using a post-install authentication key extracted from the descriptor file to determine whether the component has already been installed.
- the post-install authentication is performed optionally.
- the post-install version may be used to verify for the similar purposes.
- the processing logic authenticates each sub-component of an existing component using a pre-install authentication key extracted from the descriptor file to determine whether the existing component meets the pre-requirements of the installing the new component (e.g., whether the existing component is a baseline from which the new component is created).
- pre-install authentication is performed successfully, at block 803 , it is indicated that the respective component will be installed. Otherwise, at block 805 , the installation of the software package will be aborted.
- pre-install and post-install authentication are not performed in a particular order. For example, the pre-install authentication may be performed prior to the post-install authentication. Other operations may also be performed.
- FIG. 9 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.
- Exemplary process 900 may be performed by a processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a dedicated machine), or a combination of both.
- the exemplary process 900 may be performed as a part of operations involved in block 708 of FIG. 7 .
- the processing logic determines whether a version of the existing component is the same or newer than the version of the new component being installed. If the version of the existing component is the same or newer than the new one, at block 902 , the processing logic may optionally authenticates an image of one or more sub-components of the existing component using a post-install authentication key extracted from the descriptor file.
- the installation of the package may be aborted.
- the version of the existing component is older than the version of the new component being installed, at block 904 , the installation may be aborted.
- Other operations may also be performed.
- FIG. 10 is a block diagram of a digital processing system, which may be used with one embodiment of the invention.
- the system 1000 shown in FIG. 10 may be used as a client computer system such as client 101 of FIG. 1 .
- the exemplary system 1000 may be implemented as a server 103 of FIG. 1 .
- FIG. 10 illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components, as such details are not germane to the present invention. It will also be appreciated that network computers, handheld computers, cell phones, and other data processing systems which have fewer components or perhaps more components may also be used with the present invention.
- the computer system of FIG. 10 may, for example, be an Apple Macintosh computer or an IBM compatible PC.
- the computer system 1000 which is a form of a data processing system, includes a bus 1002 which is coupled to a microprocessor 1003 and a ROM 1007 , a volatile RAM 1005 , and a non-volatile memory 1006 .
- the microprocessor 1003 which may be, for example, a PowerPC G4 or PowerPC G5 microprocessor from Motorola, Inc. or IBM, is coupled to cache memory 1004 as shown in the example of FIG. 10 .
- the bus 1002 interconnects these various components together and also interconnects these components 1003 , 1007 , 1005 , and 1006 to a display controller and display device 1008 , as well as to input/output (I/O) devices 1010 , which may be mice, keyboards, modems, network interfaces, printers, and other devices which are well-known in the art.
- I/O input/output
- the input/output devices 1010 are coupled to the system through input/output controllers 1009 .
- the volatile RAM 1005 is typically implemented as dynamic RAM (DRAM) which requires power continuously in order to refresh or maintain the data in the memory.
- the non-volatile memory 1006 is typically a magnetic hard drive, a magnetic optical drive, an optical drive, or a DVD RAM or other type of memory system which maintains data even after power is removed from the system.
- the non-volatile memory will also be a random access memory, although this is not required.
- the present invention may utilize a non-volatile memory which is remote from the system; such as, a network storage device which is coupled to the data processing system through a network interface such as a modem or Ethernet interface.
- the bus 1002 may include one or more buses connected to each other through various bridges, controllers, and/or adapters, as is well-known in the art.
- the I/O controller 1009 includes a USB (Universal Serial Bus) adapter for controlling USB peripherals.
- I/O controller 1009 may include an IEEE-1394 adapter, also known as FireWire adapter, for controlling FireWire devices.
Abstract
Mechanism for determining applicability of a software package for installation is described herein. In one embodiment, a process is provided to retrieve authentication information of a component from an installation descriptor file, where the descriptor file describes installation information of the software package. The software package may include one or more components and each component having zero or more sub-components. For at least one sub-component of at least one existing component that has already been installed, an image of the sub-component is authenticated using an authentication key extracted from the authentication information to determine whether the component can be installed based on the existing component. Other methods and apparatuses are also described.
Description
- This application is a continuation of co-pending U.S. patent application Ser. No. 10/918,614, filed on Aug. 13, 2004.
- The present invention relates generally to computer systems. More particularly, this invention relates to mechanism for determining applicability of software packages for installation.
- Most popular software products nowadays constantly go through revisions to fix “bugs” or add new features and functionality. To that end, each revision of a software product or component may require the addition of new files, the replacement of existing files with newer versions of files, and/or removal of a file. Once a vendor has isolated a software product problem and created a solution for the problem, they would want to put that fix into an update and make the update widely available to the customers. Software vendors have a business incentive to distribute software updates to customers as quickly and trouble-free as possible.
- The Internet provides a channel for customers to obtain the latest updates for software products. The vendor sites on the Internet can be designed to make it very simple to discover and locate updated files for an application. The technical aspects of file downloading have mostly disappeared from the user's view, and are now typically handled by the operating system.
- To minimize the size of the updates over the Internet, software companies utilize file patches, which contain only the changes that must be made to pre-existing files, rather than the whole files themselves. A patch assumes that the original file on the target system is of a specific state. “Patching” applies changes to that file to bring the file to a desired, usually newer, state. However, the file should be verified to be in the required condition. Otherwise, the patch may be incorrectly applied and the file may be damaged. If a file to be patched is in an unexpected state, the patch cannot be applied. In addition, if the client machine has a sub-component that has a newer version than the one about to be upgraded, a conventional installation may abort the whole installation, even though there might be other sub-components that have older versions.
- Mechanism for determining applicability of software packages for installation is described herein. In one embodiment, a process is provided to retrieve authentication information for a component from an installation descriptor file, where the descriptor file describes installation information pertaining to the software package. The software package may include one or more components and each component having zero or more sub-components. For at least one sub-component of at least one existing component that has already been installed, an image of the sub-component is authenticated using an authentication key extracted from the authentication information, to determine whether the component can be installed based on the existing version of the component.
- Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.
- The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.
-
FIG. 1 is a diagram of a network of computer systems in which one or more clients may download and install a software package from a server. -
FIG. 2 is a block diagram illustrating an exemplary component descriptor of an installation descriptor file according to one embodiment of the invention. -
FIG. 3 is a timeline illustrating a version timeline of a software package upgrade according to one embodiment. -
FIG. 4 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention. -
FIG. 5 is a block diagram illustrating an exemplary document-type definition (DTD) file of an installation descriptor according to one embodiment of the invention. -
FIGS. 6A-6D are an example of an installation descriptor file written in XML according to one embodiment of the invention. -
FIG. 7 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention. -
FIG. 8 is a flow diagram illustrating an exemplary process for installing a software package according to another embodiment of the invention. -
FIG. 9 is a flow diagram illustrating an exemplary process for installing a software package according to another embodiment of the invention. -
FIG. 10 is a block diagram of a digital processing system, which may be used with one embodiment of the invention. - Mechanism for determining applicability of software packages for installation is described herein. According to one embodiment, an installation package is optimized by size, containing a combination of patches and/or full files. Installation of the package ensures that the user will have at least the version of the software included in the package. In one embodiment, the content of an installation package includes patches for some files and/or full versions of some other files, dependent upon the configurations.
- In one embodiment, the package further includes a package description file, which may be used by an installer to determine whether the installation package can be installed. The package description file, also referred to as installation descriptor file or a package metadata (PKM) file, describes the contents of the installation package with sufficient details to allow the installation system to determine whether the software package can be installed on a client system.
- In addition, the PKM file further includes one or more components and each component includes zero or more files (e.g., sub-components or child components). The files to be updated or added to the client system are divided into distinct, non-overlapping components. The information contained in the PKM file about the individual files is grouped by component.
- Further, according to one embodiment, two types of versioning may be used: component version for some of the components and authentication information for authenticating or determining authenticity of at least some of the files for each component. In one embodiment, there may be two versions specified for at least some of the components that have patched files in the distribution. The first version is the version of the component that is expected to be on the client system prior to applying the patches, also referred to as a pre-install version. The second version is the version of the component that the client system will contain after the patches are applied, also referred to as a post-install version. Alternatively, more or less versions may be implemented.
- In one embodiment, the authentication information includes at least one authentication key, which may be used to authenticate a file image of at least some files of a component or alternatively, to authenticate the component itself. In a particular embodiment, the authentication key may include a checksum value and the authentication operations may include a checksum operation. In a further embodiment, the authentication information includes a pre-install authentication key and a post-install authentication key. The pre-install authentication key may be used to authenticate the pre-existing file corresponding to the file being installed. The post-install authentication key may be used to verify whether a particular file has already been installed. Similarly, the pre-install and post-install authentication keys may be checksum values (e.g., pre-install and post-install checksum values).
- In the following description, numerous details are set forth to provide a more thorough explanation of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
- Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
- It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device; that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
- The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
- The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. Alternatively, a variety of programming languages may be used to implement the teachings of the invention as described herein.
- A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
-
FIG. 1 is a diagram of a network of computer systems in which one or more clients may download and install a software package from a server. As shown inFIG. 1 , anetwork 100 includes a number ofclient computer systems 101 that are coupled together through anetwork 102, for example, an Internet. Alternatively, the term “Internet” refers to a network of networks. Such networks may use a variety of protocols for exchange of information, such as TCP/IP, ATM, SNA, SDI, etc. The physical connections of the Internet and the protocols and communication procedures of the Internet are well known to those in the art. Such a system may be implemented in an Intranet within an organization. - Access to the
Internet 102 is typically provided by Internet service providers (ISPs). Users on client systems, such as theclient computer systems 101, generally obtain access to the Internet through Internet service providers. Access to the Internet may facilitate transfer of information (e.g., email, text files, media files, etc.) between two or more digital processing systems and/or aserver system 103, which may be a Web server. For example, one or more of the client computer systems and/or the Web server may provide document presentations (e.g., a Web page) to another one or more of the client computer systems and/or Web server. - For example, in one embodiment of the invention, one or more
client computer systems 101 may request to access a document that may be stored at a remote location, such as theWeb server 103. In the case of remote storage, the data may be transferred as a file (e.g., download) and then displayed (e.g., in a window of a browser) after transferring the file. In another embodiment, the document presentation may be stored locally at the client computer systems. In the case of local storage, the client system may retrieve and display the document via an application, such as a word processing application, without requiring a network connection. - The
server 103 typically includes at least one computer system to operate with one or more data communication protocols, such as the protocols of the World Wide Web, and as such, is typically coupled to theInternet 102. Optionally, theserver 103 may be part of an ISP which may provide access to the Internet and/or other network(s) for client computer systems. Theclient computer systems 101 may each, with appropriate Web browsing software, access data, such as HTML documents (e.g., Web pages), which may be provided by theserver 103. - The ISP provides Internet connectivity to the
client computer system 101 via a network interface, which may be considered as part of the client computer system. The client computer systems may be a conventional data processing system, such as a Power Mac G5 or iMac computer available from Apple Computer, Inc., a “network” computer, a handheld portable computer, a cell phone with data processing capabilities, a Web TV system, or other types of digital processing systems (e.g., a personal digital assistant (PDA)). - However, as depicted in
FIG. 1 , such connectivity may vary between various client computer systems. For example, theclient computer system 101 may be part of a local area network (LAN). The network interface of theclient 101 may represent an analog modern, an ISDN modem, a DSL modem, a cable modem, a wireless interface, or other interface for coupling a digital processing system, such as a client computer system, to another digital processing system. - Alternatively, the network interface of
client 101 may be an Ethernet-type, asynchronous transfer mode (ATM), or other type of network interface, which may couple theclient 101 to a local area network (LAN). The LAN may also be coupled to a gateway digital processing system, which may provide firewall and other Internet-related services for a LAN. The gateway digital processing system, in turn, is coupled to the ISP to provide Internet connectivity to theclient computer systems 101. The gateway digital processing system may, for example, include a conventional server computer system. Similarly, theserver 103 may, for example, include a conventional server computer system. - In one embodiment,
server 103 may be a Web server that provides software upgrade packages, which may include one or more software packages 109. Alternatively, theserver 103 may be file server of a local network, such as, for example, an Intranet. For each of the software packages 109, there may be aninstaller 107 and aPKM file 108 associated with the respective software package. Theinstaller 107 may be shared by some or all installation of software packages 109. Theinstaller 107 is capable of reading the installation description from the respective PKM file and correctly installs the respective software package. - When
client system 101 requires an upgrade, theclient 101 may download theinstaller 104 and the PKM file 106 corresponding to the software package being installed. Alternatively, theclient system 101 includes theinstaller 104 pre-installed when the client system was manufactured. In which case, theclient 101 only needs to download thePKM file 106. In one embodiment, theinstaller 104 retrieves installation description from the PKM file 106 to determine the installation configuration of the respective software package being installed. The installation description may include versioning and authentication information, which may be used to verify one or more existing components and/orfiles 105 that have already been installed in theclient 101 from which the new patches or components may be installed. - In one embodiment, the
PKM file 106 includes one ormore component descriptors 110 describing installation of the corresponding one or more components. Each of the components described by thedescriptors 110 may optionally includeversion information 111 associated with the respective component. In addition, each of the component descriptors may include zero or moresub-component descriptors 112 describing installation of zero or more files grouped under the respective component. - In one embodiment, at least some of the
sub-component descriptors 112 may include apre-install authentication key 113 and apost-install authentication key 114. Thepre-install authentication key 113 may be used to authenticate the pre-existing sub-component corresponding to the sub-component being installed. Thepost-install authentication key 114 may be used to verify whether a particular sub-component has already been installed. In a particular embodiment, pre-install and post-install authentication keys may be checksum values. - In one embodiment, a sub-component may be a file associated with a component. Throughout this application, for the purposes of illustrations, a file and a sub-component are used interchangeably. However, they are not so limited. A sub-component, as a parent component, may further include one or more sub-components (e.g., child components).
- According to one embodiment, the installation system uses the information retrieved from the PKM file 106 to ensure that the client will have at least the version of each of the software components included in the installation package when the installation is completed. Since performing authentication (e.g., a checksum operation) on a file is a relatively time-expensive operation, the
component version 111 may be used to optimize the install target verification process. - For example, if the version of a particular component on the client system is not what is required for the patch (e.g., the pre-install version) and it is not the post-install version or newer (e.g., the updated component has already been installed), the installer would know by comparing the version of the existing component and the version retrieved from the PKM file, without having to perform the authentication on each file of the existing component, that the client system does not meet the requirement of the installation package.
- Similarly, if the client system's version of a component is already the same or newer than the version contained in the package (e.g., the post-install version), the installation system does not need to install the files for that component, while allowing the rest of the installation package to proceed.
- If the
installer 104 determines that the version of the existing component on theclient system 101 is the pre-install version, theinstaller 104 may further perform the authentication on each of the sub-components described by thesub-component descriptors 112 to ensure that the sub-components have not been tampered with and are of the exact state required by the patch, using thepre-install authentication information 113. - If the authentication of the sub-component is not performed successfully (e.g., the checksum operation does not match with the corresponding checksum value retrieved from the PKM file 106), the
post-install authentication information 114 may be used to verify whether the sub-component (e.g., file) being updated has already been installed in theclient system 101. In such a case, the sub-component does not need to be installed (e.g., skipping). On the other hand, if the post-install authentication is not performed successfully, the patch cannot be applied to theclient system 101 and the installation of the entire software package should not be allowed. - In one embodiment, the
PKM file 106 and/orinstaller 104 are initially downloaded from theserver 103 to theclient system 101 without downloading the actual software package 109 being installed. With thePKM file 106, theinstaller 104 is capable of determining whether the software package (e.g., the patches) can be installed on theclient system 101, or alternatively, a full installation of the software may be needed. Once theinstaller 104 determines that the software package may be installed based on the existing components and/orfiles 105, theinstaller 104 may download the necessary patch files (e.g., only those that would be installed) from theserver 103 to install the patches. Alternatively, according to another embodiment, if the installer determines that the existing components and/orfiles 105 of theclient 101 cannot be patched (e.g., only certain files need to be updated), theinstaller 104 may download the full installation image of the software (e.g., full version) and perform a complete installation of the software, which consumes more time and resources. - According to another embodiment, the
PKM file 108 may provide additional information regarding other portions of the package that are located on other media. For example, if a particular software distribution is packaged on multiple CDs, the PKM file of the first CD may provide information regarding the files stored in the subsequent CDs. At the beginning of the installation, a user can choose which of the packages she would like to install from the subsequent CDs without having to insert the subsequent CDs, where the installer can simply read the PKM files for those packages existing elsewhere. - It will be appreciated that
server 103 may include multiple servers separated from each other. Some or all of the components 107-109 may be located on different servers. For example, theinstaller 107 and the PKM files 108 may be downloaded from a first server. After theinstaller 107 determines, based on the PKM files 108, which patches may be installed at a client machine, the actual patches to be installed may be downloaded from a second server. Other configurations may exist. -
FIG. 2 is a block diagram illustrating an exemplary component descriptor of an installation descriptor file according to one embodiment of the invention. Theexemplary component descriptor 200 may be implemented, for example, as acomponent descriptor 110 ofFIG. 1 . Referring toFIG. 2 ,exemplary component 200, also referred to as a bundle, includes adefault path 201 indicating where the component is being installed. Theexemplary component 200 also includes a bundle information block 202 to specify the specific information associated with the respective bundle. In one embodiment, the information block 202 includes anidentifier 204 for identifying the respective bundle, abundle version 205 indicating the version of the bundle being installed and a pre-bundle version of an existing bundle on top of which the new bundle is to be installed. - The
exemplary component 200 further includes files block 203 having zero or more files 207-208 (e.g., sub-components). Each of the files 207-208 may include apath authentication keys -
FIG. 3 is a timeline illustrating a version timeline of a software package upgrade according to one embodiment. In this embodiment, theexemplary timeline 300 includes a software package having a component withnewer version 302 that is intended to be installed on a system with previous version of an existingcomponent 301. That is, thecomponent having version 302 is intended to be installed on a client machine that already has a previouscomponent having version 301. If the existing component has any other version between theversions version 307, the installation of the component (e.g., the upgrade) would not be allowed. - Referring to
FIG. 3 , the installer opens and parses a PKM file to identify each of the components being installed. If the respective component is a versioned component (e.g., the component has a specific version, which may be described in a version block such asversion block 111 ofFIG. 1 ), the installer examines the version of the corresponding existing component. If the version of the existing component is the same or newer than the version of the component that is about to be installed, in this case,situation 303, the component does not need to be installed and the installation of the component will be skipped. - If the version of the existing component is the same as the pre-install version retrieved from the PKM file (e.g., the existing component is the targeted component from which the new component will be installed), in this case, situation 304, the installer may further authenticate at least one of the sub-components of the existing component using the pre-install authentication information retrieved from the PKM file. If the authentication is performed successfully, the new component will be installed based on the existing component. Otherwise, the installation may be aborted. Similarly, if the version of the existing component is older than the pre-install version (e.g., situation 306) or between the pre-install version and the post-install version, such as version 307 (e.g., situation 305), the installation may be aborted.
-
FIG. 4 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.Exemplary process 400 may be performed by a processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a dedicated machine), or a combination of both. For example, theexemplary process 400 may be performed by an installer using a PKM file, such as, for example,installer 104 using PKM file 106 ofFIG. 1 . - In one embodiment,
exemplary process 400 includes, but is not limited to, downloading from a server over a network a package metadata (PKM) file describing installation of the software package without downloading the software package. The software package including one or more components and each of the components having zero or more sub-components, authenticating an image of at least one sub-component of at least one existing component from which the software package is installed, wherein the authentication is performed using a first key retrieved from the PKM file, and downloading at least a portion of the software package from the server to be installed if the image of at least one sub-component is authenticated successfully using the first key retrieved from the PKM file. - Referring to
FIG. 4 , atblock 401, a PKM file is downloaded from a server over a network. In one embodiment, an installer application (e.g.,installer 104 ofFIG. 1 ) may also be downloaded with the PKM file. The PKM file may provide sufficient information describing the installation of a software package being installed. The software package may include one or more components (e.g., bundles) and each component may include zero or more files. The PKM file may be a metadata file written in a variety of programming languages, such as, for example, XML and HTML (hypertext markup language). In one embodiment, the actual software package has not been downloaded yet at this point. The PKM file may be downloaded over the Internet from a Web server using a variety of protocols, for example, TCP/IP protocols. Alternatively, the PKM file may be downloaded from a server within a local network (e.g., the Intranet or LAN). - At
block 402, for at least one file of at least one component of the software package, the authentication information associated with the respective file is retrieved from the PKM file. The authentication information may be used to authenticate an image of an existing sub-component (e.g., file) of an existing component to determine whether a new version of the component may be installed on the basis of the existing sub-component of the existing component. In one embodiment, the authentication information includes an authentication key for authenticating the sub-component. - At
block 403, an authentication operation is performed on the existing sub-component of the existing component that has already been installed in a client machine, using the authentication information retrieved from the PKM file, for example, an authentication key. In one embodiment, the authentication key may include a checksum value and the authentication operation includes a checksum operation performed on the sub-component using the checksum value. - If the authentication is performed successfully, at
block 404, the actual sub-components and/or the respective component may be downloaded from the server and installed in the client machine. In an alternative embodiment, if the authentication is performed unsuccessfully, a full installation image of the software package, rather than patches, may be downloaded and the full installation may be invoked. -
FIG. 5 is a block diagram illustrating an exemplary document-type definition (DTD) file of an installation descriptor according to one embodiment of the invention. An example of an installation descriptor written in XML is shown inFIGS. 6A-6D according to certain embodiments of the invention. However the installation descriptor is not limited to XML. It will be appreciated that other languages, such as, for example, HTML (hypertext markup language) may also be used. - Referring to FIGS. 5 and 6A-6D,
exemplary DTD 500 includes apackage information tag 501 for describing general information regarding the software package being installed. For example, among other information, thepackage information 501 may include anidentifier tag 502 to provide an identifier for identifying the software package being installed. In one embodiment, the identifier specified by theidentifier tag 502 may be a unique identifier specifically identifying the package. An example of a package information block and the identifier tag in XML are shown as package information block 601 andidentifier 602 inFIG. 6A . - The
exemplary DTD 500 may also include aversion block 503. An example of a version block is shown asversion block 603 inFIG. 6A . In one embodiment, the version of the software package being installed may include at least one of a short version, a major version, a minor version, a build version, and/or a build date. Other version related information may be included. - The
exemplary DTD 500 may also include one or more flags which may be implemented within aflag block 504. An example of a flag block is shown as aflag block 604 inFIG. 6A . In one embodiment, a variety of flags may be implemented within theflag block 504. For example, there may be a flag that indicates whether the client system has to restart after the installation of the package. - In addition, according to one embodiment, the
exemplary DTD 500 includes a component block (e.g., a component array) 505 that may include one ormore components 506. Each of the components may or may not include one ormore sub-components 513, for example, one or more sub-components grouped under the respective component. For example, theexemplary installation descriptor 600 shown inFIGS. 6A-6D includescomponents 606 and 621-622, which may include zero or more sub-components respectively. In the example shown inFIGS. 6A-6D ,component 606 includessub-components component 622 includes sub-components 623-625. In a further embodiment, certain sub-components may further include their respective sub-components (e.g., child components). - Referring back to
FIG. 5 , eachcomponent 506 may include acomponent information tag 507 and anidentifier tag 508. An example of a component information block and an identifier tag are shown astags FIG. 6B . In one embodiment, the component identifier includes a string that uniquely identifies a component (e.g., a bundle) of a client machine. This information may be found in a predetermined location of the client machine and may be hidden from a user of the client machine, such that the user may not easily modify it. - Further, each
component 506 may include a default path tag 512 specifying where the component, including the sub-components, may be installed. However, a specific sub-component may further specify a path which may override the default path of the parent component. - In one embodiment, a component may or may not be a versioned component. That is, a component may or may not have an associated version number, string, or combination of both. If a component is a versioned component, the component may include a
version block 509, which may include apre-install version 510, apost-install version 511, and/or other version related information. -
Pre-install version 510 may be used to represent the version of the component that is required to patch the existing component (e.g., an existing component that has already been installed in the client machine prior to the current installation). In other words, thepre-install version 510 may be the version of the component used as a “baseline” from which the patches are generated.Post-install version 511 may be used to represent the version of the component being installed (e.g., a new component version).Post-install version 511 is the version to which the described software package will update the client machine. That is, thepost-install version 511 is the version the component has after the current installation. In one embodiment, each of the pre-install and post-install versions includes at least one of a build version, a version string, a component version, and/or a source version, where the source version is an identifier that uniquely identifies a snapshot of the sources in time. An example of a pre-install and a post-install versions is shown as apre-install version 610 and apost-install version 611 inFIG. 6B . - Furthermore, according to one embodiment, each of the
components 505 may or may not include a sub-component block describing one or more sub-components 514. Similar to the parent component, the sub-component 514 may further include asub-component information tag 515 describing the respective sub-component. The sub-component 514 may optionally include apath 517 specifying a path at which the respective sub-component may be installed. Thepath 517 may be used to override or supplement thedefault path 512 of theparent component 506. In one embodiment, the sub-component path may be the actual location within the component's location/directory structure. The sub-component path, combined with the path of the component, identifies the location at which the file should be installed or patched. If thepath 517 is absent, the respective sub-component may be installed according to thedefault path 512 of theparent component 506. - Further, according to one embodiment, if the sub-component 514 is a patch, which is indicated by the
flag 516, the sub-component 514 may further include apre-install authentication key 518 and/or apost-install authentication key 519. In a particular embodiment, the pre-install and/or post-install authentication keys may include checksum values and the authentication operations may include checksum operations. It will be appreciated that other authentication mechanisms may be utilized. - In one embodiment, the
pre-install authentication key 518 may be used to authenticate an image of an existing sub-component that has already been installed on the client machine, which serves as a baseline of the respective patch. An example of thepre-install authentication key 518 and thepost-install authentication key 519 is shown askeys FIG. 6B . - In one embodiment, the installer retrieves the pre-install authentication key 518 from the installation descriptor file and authenticates the image of the existing sub-component using the
pre-install authentication key 518 to ensure that the existing component satisfies the prerequisites of the patch. If the existing sub-component cannot be authenticated successfully, the patch may not be installed. - The
post-install authentication key 519 may be used to authenticate the existing component to determine whether the new version of the component (e.g., the patch) has already been installed. In one embodiment, if the pre-install authentication fails, the installer may optionally use thepost-install authentication key 519 to determine whether the new file or component has already been installed. In such a case, the respective patch installation may be skipped. In another embodiment, the post-version of the parent component may be used to determine whether the new component version has already been installed prior to the post-install authentication. - Referring to FIGS. 5 and 6A-6D, according to one embodiment, some of the components may not be patched components. That is, those components may not include patches. In such a case, the version information regarding the patches may not be needed. As a result, the
version block 509 and thesub-component block 513 may not be needed, leaving only theidentification information default path 512 in the descriptor for those components. As a result, a full installation for the respective component may be performed instead of patching. An example of such a component is shown ascomponent 621 ofFIG. 6C . - Furthermore, according to one embodiment, certain components may not have an associated version (e.g., the component is not part of a versioned bundle). In such case, the
version block 509 may not be needed. However the pre-install andpost-install authentication keys component 622 ofFIG. 6C . Other configurations may exist. -
FIG. 7 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.Exemplary process 700 may be performed by a processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a dedicated machine), or a combination of both. For example, theexemplary process 700 may be performed by an installer using a PKM file such as, for example,installer 104 using PKM file 106 ofFIG. 1 . In one embodiment,exemplary process 700 includes, but is not limited to, retrieving authentication information of a component from an installation descriptor file describing installation of the software package, the software package having one or more components and each component having zero or more sub-components, and authenticating an image of at least one sub-component of an existing component that has already been installed using a first key extracted from the authentication information to determine whether the component can be installed based on the existing component. - Referring to
FIG. 7 , atblock 701, installation description information for a component of a software package being deployed is retrieved from an installation descriptor file (e.g., a PKM file). The installation descriptor file describes installation of one or more components and each component may include one or more sub-components, for example, one or more files. In one embodiment, the installation descriptor file may be a scripting file written in a variety of languages, such as, for example, XML or HTML, etc. The descriptor file may include some or all of the installation information described in accordance with theexemplary DTD 500 ofFIG. 5 . - At
block 702, the respective component is examined to determine whether the component is a versioned component. If the component is a versioned component, atblock 703, the version of the existing component corresponding to the component being installed is verified using a pre-install version extracted from the installation information retrieved from the installation descriptor file. The verification is performed to ensure that the client machine being patched contains a pre-required existing component from which (e.g., a baseline) the patches are generated. - If the version of the existing component matches the pre-install version extracted from the installation descriptor file, at block 704, the processing logic authenticates an image of each sub-component of the respective component using one or more authentication keys extracted from the installation information. In one embodiment, the authentication keys include a pre-install authentication key and a post-install authentication key.
- The pre-install authentication key may be used to authenticate an image of an existing sub-component that has already been installed on the client machine, which serves as a baseline for the respective patch. The post-install authentication key may be used to authenticate the existing component to determine whether the new component version (e.g., the patch) has already been installed. In a particular embodiment, the pre-install and post-install authentication keys may include checksum values and the authentication operations may include checksum operations. Other authentication mechanisms may be utilized. If the authentication is performed successfully, at
block 705, it is indicated that the respective component will be installed subsequently. If the authentication is performed unsuccessfully, atblock 711, it is determined whether the sub-component has already been installed. In one embodiment, the authentication is performed using a post-install key extracted from the descriptor file. If the sub-component has already been installed (e.g., post-install authentication is performed successfully), at block 709, the sub-component is indicated that it is does not need to be installed. Otherwise, atblock 710, the operation will be aborted. - If the version of the existing component does not match the pre-install version extracted from the installation descriptor file, at
block 708, the processing logic verifies whether the updated component has already been installed. In one embodiment, the verification is performed by comparing the version of the existing component with a post-install version extracted from the installation descriptor. Optionally, a post-install authentication may be performed on an image of each sub-component of the existing component, using a post-install authentication key extracted from the installation descriptor file. - If the post-install authentication is performed successfully, at block 709, it is indicated that the respective component does not need to be installed. Otherwise, at
block 710, the patching installation may be aborted. Atblock 706, it is determined whether there are more components that need to be processed based on the installation description retrieved from the installation descriptor file. If there are more components, the above processes may be repeated until no more components have to be processed. Atblock 707, the components and/or the sub-components that have been indicated are installed and those without indication will be skipped. Other operations may also be performed. -
FIG. 8 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.Exemplary process 800 may be performed by a processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a dedicated machine), or a combination of both. For example, theexemplary process 800 may be performed as a part of operations involved in block 704 ofFIG. 7 . In a particular embodiment,exemplary process 800 may be performed on a non-versioned component. - Referring to
FIG. 8 , at block 801, the processing logic authenticates each sub-component of an existing component corresponding to the component being installed using a post-install authentication key extracted from the descriptor file to determine whether the component has already been installed. In one embodiment, the post-install authentication is performed optionally. Alternatively, the post-install version may be used to verify for the similar purposes. - If the post-install authentication is performed successfully, at
block 804, it is indicated that the respective component does not need to be installed. In which case, the installation of the component will be skipped. - If the post-install authentication is performed unsuccessfully, at block 802, the processing logic authenticates each sub-component of an existing component using a pre-install authentication key extracted from the descriptor file to determine whether the existing component meets the pre-requirements of the installing the new component (e.g., whether the existing component is a baseline from which the new component is created).
- If the pre-install authentication is performed successfully, at
block 803, it is indicated that the respective component will be installed. Otherwise, atblock 805, the installation of the software package will be aborted. Note that the pre-install and post-install authentication are not performed in a particular order. For example, the pre-install authentication may be performed prior to the post-install authentication. Other operations may also be performed. -
FIG. 9 is a flow diagram illustrating an exemplary process for installing a software package according to one embodiment of the invention.Exemplary process 900 may be performed by a processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a dedicated machine), or a combination of both. For example, theexemplary process 900 may be performed as a part of operations involved inblock 708 ofFIG. 7 . - Referring to
FIG. 9 , atblock 901, the processing logic determines whether a version of the existing component is the same or newer than the version of the new component being installed. If the version of the existing component is the same or newer than the new one, atblock 902, the processing logic may optionally authenticates an image of one or more sub-components of the existing component using a post-install authentication key extracted from the descriptor file. - If the post-install authentication is performed successfully, at
block 903, it is indicated that the component has already been installed and its installation will be skipped. Otherwise, atblock 904, the installation of the package may be aborted. Similarly, if the version of the existing component is older than the version of the new component being installed, atblock 904, the installation may be aborted. Other operations may also be performed. -
FIG. 10 is a block diagram of a digital processing system, which may be used with one embodiment of the invention. For example, thesystem 1000 shown inFIG. 10 may be used as a client computer system such asclient 101 ofFIG. 1 . Alternatively, theexemplary system 1000 may be implemented as aserver 103 ofFIG. 1 . - Note that while
FIG. 10 illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components, as such details are not germane to the present invention. It will also be appreciated that network computers, handheld computers, cell phones, and other data processing systems which have fewer components or perhaps more components may also be used with the present invention. The computer system ofFIG. 10 may, for example, be an Apple Macintosh computer or an IBM compatible PC. - As shown in
FIG. 10 , thecomputer system 1000, which is a form of a data processing system, includes abus 1002 which is coupled to amicroprocessor 1003 and aROM 1007, avolatile RAM 1005, and anon-volatile memory 1006. Themicroprocessor 1003, which may be, for example, a PowerPC G4 or PowerPC G5 microprocessor from Motorola, Inc. or IBM, is coupled tocache memory 1004 as shown in the example of FIG. 10. Thebus 1002 interconnects these various components together and also interconnects thesecomponents display device 1008, as well as to input/output (I/O)devices 1010, which may be mice, keyboards, modems, network interfaces, printers, and other devices which are well-known in the art. - Typically, the input/
output devices 1010 are coupled to the system through input/output controllers 1009. Thevolatile RAM 1005 is typically implemented as dynamic RAM (DRAM) which requires power continuously in order to refresh or maintain the data in the memory. Thenon-volatile memory 1006 is typically a magnetic hard drive, a magnetic optical drive, an optical drive, or a DVD RAM or other type of memory system which maintains data even after power is removed from the system. Typically, the non-volatile memory will also be a random access memory, although this is not required. - While
FIG. 10 shows that the non-volatile memory is a local device coupled directly to the rest of the components in the data processing system, the present invention may utilize a non-volatile memory which is remote from the system; such as, a network storage device which is coupled to the data processing system through a network interface such as a modem or Ethernet interface. Thebus 1002 may include one or more buses connected to each other through various bridges, controllers, and/or adapters, as is well-known in the art. In one embodiment, the I/O controller 1009 includes a USB (Universal Serial Bus) adapter for controlling USB peripherals. Alternatively, I/O controller 1009 may include an IEEE-1394 adapter, also known as FireWire adapter, for controlling FireWire devices. - Thus, mechanism for determining applicability of software packages for installation has been described herein. In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
Claims (6)
1.-36. (canceled)
37. A method for installing a software package, the method comprising:
downloading from a server over a network a package metadata (PKM) file describing installation of the software package without downloading the software package, the software package including one or more components and each of the components having zero or more sub-components;
authenticating an image of at least one sub-component of at least one existing component from which the software package is installed, wherein the authentication is performed using a first key retrieved from the PKM file; and
downloading at least a portion of the software package from the server to be installed if the image of the at least one sub-component is authenticated successfully using the first key retrieved from the PKM file.
38. The method of claim 37 , wherein the PKM file is an extensible markup language (XML) compatible file.
39. The method of claim 37 , wherein the first key comprises a checksum value of the at least one sub-component of the existing component, and wherein the authentication includes a checksum operation using the checksum value to authenticate the existing component.
40. A method for installing a software package, the method comprising:
retrieving authentication information of a component from an installation descriptor file describing installation information of the software package the software package having one or more components; and
determining authenticity of an image of at least one existing component that has already been installed using a first key extracted from the authentication information, to determine whether the component can be installed based on the existing component.
41. A method for installing a software package having a plurality of components on a computer system, the method comprising:
downloading from a server over a network metadata describing the plurality of components of the package without downloading the components;
determining, using at least a portion of the metadata, whether any of the components are already installed on the computer system;
determining, based at least in part on determining whether any of the components are already installed on the computer system, which of the components should be downloaded to the computer system for installation.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/435,330 US20090271782A1 (en) | 2004-08-13 | 2009-05-04 | Mechanism for determining applicability of software packages for installation |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/918,614 US7530065B1 (en) | 2004-08-13 | 2004-08-13 | Mechanism for determining applicability of software packages for installation |
US12/435,330 US20090271782A1 (en) | 2004-08-13 | 2009-05-04 | Mechanism for determining applicability of software packages for installation |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/918,614 Continuation US7530065B1 (en) | 2004-08-13 | 2004-08-13 | Mechanism for determining applicability of software packages for installation |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090271782A1 true US20090271782A1 (en) | 2009-10-29 |
Family
ID=40585033
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/918,614 Active 2025-12-04 US7530065B1 (en) | 2004-08-13 | 2004-08-13 | Mechanism for determining applicability of software packages for installation |
US12/435,330 Abandoned US20090271782A1 (en) | 2004-08-13 | 2009-05-04 | Mechanism for determining applicability of software packages for installation |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/918,614 Active 2025-12-04 US7530065B1 (en) | 2004-08-13 | 2004-08-13 | Mechanism for determining applicability of software packages for installation |
Country Status (1)
Country | Link |
---|---|
US (2) | US7530065B1 (en) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011146917A2 (en) * | 2010-05-21 | 2011-11-24 | Inedible Software, Llc | Apparatuses, systems and methods for determining installed software applications on a computing device |
US20120102477A1 (en) * | 2010-10-21 | 2012-04-26 | Samsung Electronics Co., Ltd. | Firmware update method and apparatus for a mobile device |
US8495625B1 (en) * | 2010-07-27 | 2013-07-23 | Symantec Corporation | Method and system for creation of streamed files on-demand |
WO2014193463A1 (en) * | 2013-05-30 | 2014-12-04 | Microsoft Corporation | Bundle package retrieving |
US20140359603A1 (en) * | 2013-05-30 | 2014-12-04 | The Boeing Company | Deployment of software across an enterprise system |
US9323514B2 (en) | 2013-05-30 | 2016-04-26 | Microsoft Technology Licensing, Llc | Resource package indexing |
US20170032107A1 (en) * | 2015-07-27 | 2017-02-02 | International Business Machines Corporation | File origin determination |
US9766870B2 (en) | 2013-05-30 | 2017-09-19 | Microsoft Technology Licensing, Llc | Bundle package generation |
US10015282B2 (en) | 2013-05-30 | 2018-07-03 | Microsoft Technology Licensing, Llc | Context-based selective downloading of application resources |
US20210209219A1 (en) * | 2020-01-08 | 2021-07-08 | Samsung Electronics Co., Ltd. | Apparatus and method for authentication of software |
US11400380B2 (en) * | 2017-07-31 | 2022-08-02 | Sony Interactive Entertainment Inc. | Information processing apparatus and download processing method |
Families Citing this family (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9134989B2 (en) | 2002-01-31 | 2015-09-15 | Qualcomm Incorporated | System and method for updating dataset versions resident on a wireless device |
US8533702B2 (en) * | 2002-06-27 | 2013-09-10 | International Business Machines Corporation | Dynamically resolving fix groups for managing multiple releases of multiple products on multiple systems |
US9092286B2 (en) * | 2002-12-20 | 2015-07-28 | Qualcomm Incorporated | System to automatically process components on a device |
US8626146B2 (en) | 2003-10-29 | 2014-01-07 | Qualcomm Incorporated | Method, software and apparatus for performing actions on a wireless device using action lists and versioning |
US20060136909A1 (en) * | 2004-09-07 | 2006-06-22 | Davis Arthur G | Methods and systems for providing software copy control |
US7716661B2 (en) * | 2005-03-16 | 2010-05-11 | Microsoft Corporation | Embedded device update service |
WO2006110991A1 (en) * | 2005-04-18 | 2006-10-26 | Research In Motion Limited | Method and system for controlling software version updates |
US8171482B1 (en) * | 2006-05-09 | 2012-05-01 | Vmware, Inc. | Application environment specifications for provisioning application specific runtime environments using subsets of resources required for execution |
US8019872B2 (en) * | 2006-07-12 | 2011-09-13 | International Business Machines Corporation | Systems, methods and computer program products for performing remote data storage for client devices |
US20100242034A1 (en) * | 2006-11-01 | 2010-09-23 | Microsoft Corporation | Distributing software products as an executable containing script logic with external resources |
US20080127175A1 (en) * | 2006-11-01 | 2008-05-29 | Microsoft Corporation | Packaging software products as single-file executables containing scripting logic |
JP2008191786A (en) * | 2007-02-01 | 2008-08-21 | Canon Inc | Program management device, program management method and program |
US8577937B1 (en) | 2007-05-09 | 2013-11-05 | Vmware, Inc. | Repository including exclusion list |
US8347263B1 (en) * | 2007-05-09 | 2013-01-01 | Vmware, Inc. | Repository including installation metadata for executable applications |
US11262996B2 (en) | 2007-05-09 | 2022-03-01 | Vmware, Inc. | Repository including exclusion list |
US8219987B1 (en) | 2007-08-24 | 2012-07-10 | Vmware, Inc. | Optimized virtual machine specification for provisioning application specific runtime environment |
US9015180B1 (en) | 2007-05-09 | 2015-04-21 | Vmware, Inc. | Repository including file identification |
JP5065482B2 (en) | 2007-06-19 | 2012-10-31 | クゥアルコム・インコーポレイテッド | Method and apparatus for synchronizing data sets in a wireless environment |
US8589912B2 (en) * | 2007-06-29 | 2013-11-19 | International Business Machines Corporation | Loosely coupled product install and configuration |
US20090007097A1 (en) * | 2007-06-29 | 2009-01-01 | Hinton Heather M | Product install and configuration providing choice of new installation and re-use of existing installation |
US8719812B1 (en) * | 2008-06-30 | 2014-05-06 | Emc Corporation | Methods, systems, and computer readable media for dynamically modifying and utilizing a software package description for software installation |
US8380549B2 (en) * | 2008-09-18 | 2013-02-19 | Sap Ag | Architectural design for embedded support application software |
US20100161975A1 (en) * | 2008-12-19 | 2010-06-24 | Vixs Systems, Inc. | Processing system with application security and methods for use therewith |
JP2010231674A (en) * | 2009-03-28 | 2010-10-14 | Brother Ind Ltd | Site information registration program and computer for executing the site information registration program |
JP2010257162A (en) * | 2009-04-23 | 2010-11-11 | Brother Ind Ltd | Install program |
US20100299664A1 (en) * | 2009-05-21 | 2010-11-25 | Salesforce.Com, Inc. | System, method and computer program product for pushing an application update between tenants of a multi-tenant on-demand database service |
CN101989208A (en) * | 2009-08-04 | 2011-03-23 | 鸿富锦精密工业(深圳)有限公司 | Software updating method |
US20110107325A1 (en) * | 2009-11-03 | 2011-05-05 | Jack Matthew | Early Detection of Errors in a Software Installation |
US8725839B2 (en) * | 2009-12-22 | 2014-05-13 | International Business Machines Corporation | Imposing pre-installation prerequisite checks on the install user to ensure a higher rate of installation success |
US9772834B2 (en) | 2010-04-27 | 2017-09-26 | Red Hat, Inc. | Exportable encoded identifications of networked machines |
US8762931B2 (en) * | 2010-05-26 | 2014-06-24 | Red Hat, Inc. | Generating an encoded package profile |
KR101284551B1 (en) * | 2011-04-21 | 2013-07-11 | (주)지온네트웍스 | Method for installing applications that have been installed in an old mobile terminal to a new mobile terminal |
US8825864B2 (en) | 2011-09-29 | 2014-09-02 | Oracle International Corporation | System and method for supporting a dynamic resource broker in a transactional middleware machine environment |
CN102426533B (en) * | 2011-12-12 | 2014-10-01 | 奇智软件(北京)有限公司 | Method and device for installing software |
US10237370B2 (en) | 2012-09-22 | 2019-03-19 | Avaya Inc. | Co-resident plug-ins of third party software |
US9116772B2 (en) | 2012-09-22 | 2015-08-25 | Avaya Inc. | Dynamic customization of pluggable service by users |
US9690559B2 (en) * | 2012-09-22 | 2017-06-27 | Avaya Inc. | Downloadable pluggable services |
US9262150B2 (en) | 2012-09-22 | 2016-02-16 | Avaya Inc. | Services versioning |
KR20140106991A (en) * | 2013-02-27 | 2014-09-04 | 삼성전자주식회사 | Apparatus and method for providing an application in a portable terminal |
US9996339B2 (en) * | 2014-06-04 | 2018-06-12 | Microsoft Technology Licensing, Llc | Enhanced updating for digital content |
US10372434B1 (en) | 2016-07-22 | 2019-08-06 | Amdocs Development Limited | Apparatus, computer program, and method for communicating an update to a subset of devices |
US10228931B2 (en) | 2016-11-07 | 2019-03-12 | Microsoft Technology Licensing, Llc | Peripheral device support with a digital assistant for operating system upgrades |
US11238147B2 (en) | 2019-08-27 | 2022-02-01 | Comcast Cable Communications, Llc | Methods and systems for verifying applications |
US20210064756A1 (en) * | 2019-08-27 | 2021-03-04 | Comcast Cable Communications, Llc | Methods and systems for verifying applications |
Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5155847A (en) * | 1988-08-03 | 1992-10-13 | Minicom Data Corporation | Method and apparatus for updating software at remote locations |
US5999740A (en) * | 1996-11-08 | 1999-12-07 | International Computers Limited | Updating mechanism for software |
US6009274A (en) * | 1996-12-13 | 1999-12-28 | 3Com Corporation | Method and apparatus for automatically updating software components on end systems over a network |
US6154878A (en) * | 1998-07-21 | 2000-11-28 | Hewlett-Packard Company | System and method for on-line replacement of software |
US6332217B1 (en) * | 1997-05-09 | 2001-12-18 | Hearme | Software inventory control system |
US6381742B2 (en) * | 1998-06-19 | 2002-04-30 | Microsoft Corporation | Software package management |
US20020174422A1 (en) * | 2000-09-28 | 2002-11-21 | The Regents Of The University Of California | Software distribution system |
US6493871B1 (en) * | 1999-09-16 | 2002-12-10 | Microsoft Corporation | Method and system for downloading updates for software installation |
US6557054B2 (en) * | 1994-05-31 | 2003-04-29 | Richard R. Reisman | Method and system for distributing updates by presenting directory of software available for user installation that is not already installed on user station |
US20040003266A1 (en) * | 2000-09-22 | 2004-01-01 | Patchlink Corporation | Non-invasive automatic offsite patch fingerprinting and updating system and method |
US20040003389A1 (en) * | 2002-06-05 | 2004-01-01 | Microsoft Corporation | Mechanism for downloading software components from a remote source for use by a local software application |
US6675382B1 (en) * | 1999-06-14 | 2004-01-06 | Sun Microsystems, Inc. | Software packaging and distribution system |
US6718549B1 (en) * | 1999-05-05 | 2004-04-06 | Microsoft Corporation | Methods for managing the distribution of client bits to client computers |
US6725453B1 (en) * | 2000-08-23 | 2004-04-20 | Microsoft Corporation | Remote software installation and maintenance |
US6751795B1 (en) * | 1998-12-24 | 2004-06-15 | Nec Corporation | System and method for software installation |
US6754896B2 (en) * | 1998-09-21 | 2004-06-22 | Microsoft Corporation | Method and system for on-demand installation of software implementations |
US20040181787A1 (en) * | 2003-03-10 | 2004-09-16 | Microsoft Corporation | Software updating system and method |
US20040181561A1 (en) * | 2003-03-14 | 2004-09-16 | International Business Machines Corporation | Real time XML data update identification |
US20040205709A1 (en) * | 2001-05-09 | 2004-10-14 | Sun Microsystems, Inc. | Method,system, and program for providing patch expressions used in determining whether to install a patch |
US20050010916A1 (en) * | 2003-05-24 | 2005-01-13 | Hagen David A. | System for providing software application updates to multiple clients on a network |
US20050055686A1 (en) * | 2003-09-08 | 2005-03-10 | Microsoft Corporation | Method and system for servicing software |
US7000230B1 (en) * | 2000-06-21 | 2006-02-14 | Microsoft Corporation | Network-based software extensions |
US7155713B1 (en) * | 2000-04-27 | 2006-12-26 | Microsoft Corporation | Componentized operating system |
-
2004
- 2004-08-13 US US10/918,614 patent/US7530065B1/en active Active
-
2009
- 2009-05-04 US US12/435,330 patent/US20090271782A1/en not_active Abandoned
Patent Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5155847A (en) * | 1988-08-03 | 1992-10-13 | Minicom Data Corporation | Method and apparatus for updating software at remote locations |
US6557054B2 (en) * | 1994-05-31 | 2003-04-29 | Richard R. Reisman | Method and system for distributing updates by presenting directory of software available for user installation that is not already installed on user station |
US5999740A (en) * | 1996-11-08 | 1999-12-07 | International Computers Limited | Updating mechanism for software |
US6009274A (en) * | 1996-12-13 | 1999-12-28 | 3Com Corporation | Method and apparatus for automatically updating software components on end systems over a network |
US6332217B1 (en) * | 1997-05-09 | 2001-12-18 | Hearme | Software inventory control system |
US6381742B2 (en) * | 1998-06-19 | 2002-04-30 | Microsoft Corporation | Software package management |
US6154878A (en) * | 1998-07-21 | 2000-11-28 | Hewlett-Packard Company | System and method for on-line replacement of software |
US6754896B2 (en) * | 1998-09-21 | 2004-06-22 | Microsoft Corporation | Method and system for on-demand installation of software implementations |
US6751795B1 (en) * | 1998-12-24 | 2004-06-15 | Nec Corporation | System and method for software installation |
US6718549B1 (en) * | 1999-05-05 | 2004-04-06 | Microsoft Corporation | Methods for managing the distribution of client bits to client computers |
US6675382B1 (en) * | 1999-06-14 | 2004-01-06 | Sun Microsystems, Inc. | Software packaging and distribution system |
US6493871B1 (en) * | 1999-09-16 | 2002-12-10 | Microsoft Corporation | Method and system for downloading updates for software installation |
US7155713B1 (en) * | 2000-04-27 | 2006-12-26 | Microsoft Corporation | Componentized operating system |
US7000230B1 (en) * | 2000-06-21 | 2006-02-14 | Microsoft Corporation | Network-based software extensions |
US6725453B1 (en) * | 2000-08-23 | 2004-04-20 | Microsoft Corporation | Remote software installation and maintenance |
US20040003266A1 (en) * | 2000-09-22 | 2004-01-01 | Patchlink Corporation | Non-invasive automatic offsite patch fingerprinting and updating system and method |
US20020174422A1 (en) * | 2000-09-28 | 2002-11-21 | The Regents Of The University Of California | Software distribution system |
US20040205709A1 (en) * | 2001-05-09 | 2004-10-14 | Sun Microsystems, Inc. | Method,system, and program for providing patch expressions used in determining whether to install a patch |
US20040003389A1 (en) * | 2002-06-05 | 2004-01-01 | Microsoft Corporation | Mechanism for downloading software components from a remote source for use by a local software application |
US20040181787A1 (en) * | 2003-03-10 | 2004-09-16 | Microsoft Corporation | Software updating system and method |
US20040181561A1 (en) * | 2003-03-14 | 2004-09-16 | International Business Machines Corporation | Real time XML data update identification |
US20050010916A1 (en) * | 2003-05-24 | 2005-01-13 | Hagen David A. | System for providing software application updates to multiple clients on a network |
US20050055686A1 (en) * | 2003-09-08 | 2005-03-10 | Microsoft Corporation | Method and system for servicing software |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011146917A2 (en) * | 2010-05-21 | 2011-11-24 | Inedible Software, Llc | Apparatuses, systems and methods for determining installed software applications on a computing device |
WO2011146917A3 (en) * | 2010-05-21 | 2012-04-12 | Inedible Software, Llc | Apparatuses, systems and methods for determining installed software applications on a computing device |
US8495625B1 (en) * | 2010-07-27 | 2013-07-23 | Symantec Corporation | Method and system for creation of streamed files on-demand |
US20120102477A1 (en) * | 2010-10-21 | 2012-04-26 | Samsung Electronics Co., Ltd. | Firmware update method and apparatus for a mobile device |
US9766870B2 (en) | 2013-05-30 | 2017-09-19 | Microsoft Technology Licensing, Llc | Bundle package generation |
US10015282B2 (en) | 2013-05-30 | 2018-07-03 | Microsoft Technology Licensing, Llc | Context-based selective downloading of application resources |
US20140359606A1 (en) * | 2013-05-30 | 2014-12-04 | Microsoft Corporation | Bundle package retrieving |
US9323514B2 (en) | 2013-05-30 | 2016-04-26 | Microsoft Technology Licensing, Llc | Resource package indexing |
US20140359603A1 (en) * | 2013-05-30 | 2014-12-04 | The Boeing Company | Deployment of software across an enterprise system |
US9720669B2 (en) * | 2013-05-30 | 2017-08-01 | The Boeing Company | Deployment of software across an enterprise system |
WO2014193463A1 (en) * | 2013-05-30 | 2014-12-04 | Microsoft Corporation | Bundle package retrieving |
US10061907B2 (en) | 2015-07-27 | 2018-08-28 | International Business Machines Corporation | File origin determination |
US9910967B2 (en) * | 2015-07-27 | 2018-03-06 | International Business Machines Corporation | File origin determination |
US20170032107A1 (en) * | 2015-07-27 | 2017-02-02 | International Business Machines Corporation | File origin determination |
US10068067B2 (en) | 2015-07-27 | 2018-09-04 | International Business Machines Corporation | File origin determination |
US10262116B2 (en) | 2015-07-27 | 2019-04-16 | International Business Machines Corporation | File origin determination |
US10339282B2 (en) | 2015-07-27 | 2019-07-02 | International Business Machines Corporation | File origin determination |
US10430561B2 (en) | 2015-07-27 | 2019-10-01 | International Business Machines Corporation | File origin determination |
US10902094B2 (en) | 2015-07-27 | 2021-01-26 | International Business Machines Corporation | File origin determination |
US11400380B2 (en) * | 2017-07-31 | 2022-08-02 | Sony Interactive Entertainment Inc. | Information processing apparatus and download processing method |
US20210209219A1 (en) * | 2020-01-08 | 2021-07-08 | Samsung Electronics Co., Ltd. | Apparatus and method for authentication of software |
US11829464B2 (en) * | 2020-01-08 | 2023-11-28 | Samsung Electronics Co., Ltd. | Apparatus and method for authentication of software |
Also Published As
Publication number | Publication date |
---|---|
US7530065B1 (en) | 2009-05-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7530065B1 (en) | Mechanism for determining applicability of software packages for installation | |
US7984435B2 (en) | Update system employing reference software to reduce number of update packages | |
US7146609B2 (en) | Method, system and article of manufacture for a firmware image | |
US6493871B1 (en) | Method and system for downloading updates for software installation | |
US6578142B1 (en) | Method and apparatus for automatically installing and configuring software on a computer | |
KR101075388B1 (en) | Peripheral device driver maintenance scheme for networked peripheral device clients | |
US6353926B1 (en) | Software update notification | |
US20030217358A1 (en) | Method, system, and article of manufacture for firmware downloads | |
TWI359597B (en) | Method,computer system ,and computer-readable medi | |
US7934210B1 (en) | System and method for updating one or more programs and their environment | |
US8667483B2 (en) | Device dependent on-demand compiling and deployment of mobile applications | |
US6373498B1 (en) | Displaying images during boot-up and shutdown | |
RU2372644C2 (en) | System and method for updating installation components in network environment | |
JP5403771B2 (en) | System and method for providing secure updates to firmware | |
TW476911B (en) | Method and apparatus to automatically deinstall an application module when not functioning | |
US6405309B1 (en) | Method and apparatus for creating and deploying smaller Microsoft Windows applications for automatic configuration of a computing device | |
KR101238511B1 (en) | Publishing the status of and updating firmware components | |
US20070214453A1 (en) | Installation of Software on Removable Media | |
US6438750B1 (en) | Determining loading time of an operating system | |
US7380003B1 (en) | Method and system for staged web service upgrade from an existing version to a different version | |
US20070061800A1 (en) | System and method for updating software in a network device | |
US20040154014A1 (en) | System and method for automatically installing data on a handheld computer | |
WO2000077614A2 (en) | Software packaging and distribution system | |
WO2000068836A2 (en) | Methods for managing the distribution of client bits to client computers | |
US6457122B1 (en) | Fault tolerant process for the delivery of programs to writeable storage device utilizing pre-operating system software/firmware |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |