US8578363B2 - Differentiated installable packages - Google Patents

Differentiated installable packages Download PDF

Info

Publication number
US8578363B2
US8578363B2 US11/470,281 US47028106A US8578363B2 US 8578363 B2 US8578363 B2 US 8578363B2 US 47028106 A US47028106 A US 47028106A US 8578363 B2 US8578363 B2 US 8578363B2
Authority
US
United States
Prior art keywords
patch
component
computer
patch file
certificate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related, expires
Application number
US11/470,281
Other versions
US20070261047A1 (en
Inventor
Maneesh Sah
Garett Richard Nell
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority to US11/470,281 priority Critical patent/US8578363B2/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SAH, MANEESH
Publication of US20070261047A1 publication Critical patent/US20070261047A1/en
Application granted granted Critical
Publication of US8578363B2 publication Critical patent/US8578363B2/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Definitions

  • the new binaries would be manually copied to the location specified by the software manufacturer.
  • the machines would then be rebooted to start running with the fixes.
  • the customer would confirm these fixes work on the machine, and would be asked to clean up these old binaries by rebooting again in safe mode and restoring the original files, then doing a final reboot to start up normally again.
  • the customer would then communicate the results of their test to the software manufacturer.
  • FIG. 1 is a block diagram of a computing system that may operate in accordance with the claims;
  • FIG. 2 is a block diagram of a method of distributing fixes to a software application
  • FIG. 3 is a block diagram of an additional method of distributing fixes to a software application.
  • FIG. 4 is a graphical illustration of a file in accordance with the claims.
  • FIG. 1 illustrates an example of a suitable computing system environment 100 on which a system for the steps of the claimed method and apparatus may be implemented.
  • the computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the method of apparatus of the claims. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100 .
  • the steps of the claimed method and apparatus are operational with numerous other general purpose or special purpose computing system environments or configurations.
  • Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the methods or apparatus of the claims include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • the methods and apparatus may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computer storage media including memory storage devices.
  • an exemplary system for implementing the steps of the claimed method and apparatus includes a general purpose computing device in the form of a computer 110 .
  • Components of computer 110 may include, but are not limited to, a processing unit 120 , a system memory 130 , and a system bus 121 that couples various system components including the system memory to the processing unit 120 .
  • the system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus, and the Peripheral Component Interconnect-Express (PCI-E).
  • ISA Industry Standard Architecture
  • MCA Micro Channel Architecture
  • EISA Enhanced ISA
  • VESA Video Electronics Standards Association
  • PCI Peripheral Component Interconnect
  • PCI-E Peripheral Component Interconnect-Express
  • Computer 110 typically includes a variety of computer readable media.
  • Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media.
  • Computer readable media may comprise computer storage media and communication media.
  • Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110 .
  • Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
  • modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
  • communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
  • the system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132 .
  • ROM read only memory
  • RAM random access memory
  • BIOS basic input/output system
  • RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120 .
  • FIG. 1 illustrates operating system 134 , application programs 135 , other program modules 136 program data 137 , and batch module 138 .
  • the computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media.
  • FIG. 1 illustrates a hard disk drive 140 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152 , and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media.
  • removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.
  • the hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140
  • magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150 .
  • hard disk drive 141 is illustrated as storing operating system 144 , application programs 145 , other program modules 146 program data 147 , and batch module 148 . Note that these components can either be the same as or different from operating system 134 , application programs 135 , other program modules 136 program data 137 , and patch module 138 . Operating system 144 , application programs 145 , other program modules 146 program data 147 , and patch module 148 are given different numbers here to illustrate that, at a minimum, they are different copies. The patch module 148 fixes a software application.
  • a user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and pointing device 161 , commonly referred to as a mouse, trackball or touch pad.
  • Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
  • These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).
  • a monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190 .
  • computers may also include other peripheral output devices such as speakers 197 and printer 196 , which may be connected through an output peripheral interface 190 .
  • the computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180 .
  • the remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110 , although only a memory storage device 181 has been illustrated in FIG. 1 .
  • the logical connections depicted in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173 , but may also include other networks.
  • LAN local area network
  • WAN wide area network
  • Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
  • the computer 110 When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170 .
  • the computer 110 When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173 , such as the Internet.
  • the modem 172 which may be internal or external, may be connected to the system bus 121 via the user input interface 160 , or other appropriate mechanism.
  • program modules depicted relative to the computer 110 may be stored in the remote memory storage device.
  • FIG. 1 illustrates remote application programs 185 as residing on memory device 181 . It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
  • FIG. 2 may be a graphical illustration of a method of distributing fixes to a software application that may be performed by the computer 110 described in FIG. 1 .
  • the method may create a source code change to fix the software application.
  • Software is complicated and often times, software may be distributed that has a problem that is not immediately apparent. After a period of time, a user may notice a problem with some software. The user may report this problem to the software manufacture who may try to fix the problem. Ideally, the patch works and does not create any other unexpected problems. But just like any software, problems based on the patch may not appear for a period of time. Accordingly, patches may not be widely distributed but may be distributed to select parties (such as the party that noticed the problem) for testing before the patch is widely distributed in order to avoid creating additional problems.
  • the source code of the patch may be compiled into a file to be communicated.
  • the patch file may be compiled into a binary file.
  • the source code may be converted into any useful format and distributed accordingly.
  • the file may be communicated to a single end user, multiple end users or to a network of end users.
  • the method may create a specialized mechanism that includes additional executable code that is not a component of an installer or the binary payload containing the source code fix.
  • the specialized mechanism may be adapted to perform a variety of functions such as registration, detection, setup, reporting, tracking, policy verification or clean up. Detection may review the computer 110 on which it is to be installed, determine whether changes need to be made to the computer 110 such that the installer will operate properly or ask the computer 110 for permission to run the installer. Setup may assist in setting up the computer 110 or with installing the patch. Reporting may report data back to a remote system or computer 110 , the patch creator, or local user.
  • the data may include information on the patch installation, state change (such as a reinstallation), or uninstallation and whether the patch was a success or a failure.
  • Tracking may report back tracking data on the size of the patch, the content of the patch, the patch deployment time, subcomponents of the patch deployment time, whether a system restart was required, the user credential used when the patch was installed, a change in the number of software applications or services on the computer 110 (some patches carry new applications not previously present on the machine possibly in addition to fixes for existing components), system hardware or capabilities now able to be detected after patch payload deployed, other changes in system condition (such as a decrease in disk fragmentation, for example), the number of patch installations, any problems with the patches, etc.
  • Policy verification may ensure that the patch conforms to system or administrative policies such as the patch is digitally signed and not a malicious patch, or the system is permitted to install a patch, or the user is not authenticated to deploy patches or this particular patch, etc. Clean up may assist with returning the computer 110 to a functional state.
  • the specialized mechanism will be further discussed with respect to FIG. 3 .
  • the method may create a signed “for testing” package to be distributed.
  • the package may include executable installer code that is automatically deployed when the entire package is received, the patch files and the specialized mechanism from block 230 .
  • FIG. 3 may be a more detailed embodiment of the method.
  • Blocks 305 - 320 may be the same as previously described blocks 210 - 240 in FIG. 2 .
  • the specialized mechanism may check with a host to confirm whether or not installation of the patch is permitted. For example, in order to modify files in software, some level of trust must be present to avoid having malicious code be installed in software. That level of trust may be obtained through a variety of ways.
  • a signed certificate is used that is verified by a third party and is recognized by the user's computer 110 as being trusted.
  • the user's computer 110 may not recognize that the certificate is to be trusted, but the user may be part of a network and an authority or other host on the network may recognize that the certificate should be trusted.
  • the specialized mechanism may report that a patch has been installed to another host on a network. If the patch has been installed to another host on the network then it may not be necessary to install the patch on the computer 110 in question. On the other hand, the host may decide that the code should be the same on all computers 110 on the network and it may become necessary to install the patch such that the code on the computer 110 in question is the same as all the computers 110 on the network.
  • the method may display at the receiving station an indication that the source code change is a test patch.
  • Test patches may be patches that are thought to address a problem but have not been fully tested and evaluated. Accordingly, it may not be appropriate to widely distribute test patches and it makes logical sense to indicate on the display 191 of the computer 110 in question that a test patch has been installed.
  • the indication may be a watermark, may be a text box, or may be a window, all of which indicate that a test patch is present on the computer 110 in question.
  • the watermark may be visible to other network users that access the computer 110 with the test patch.
  • the presence of a ‘for testing’ patch can be communicated to the user via an audible alert to the speakers 197 or via an LED or other light on the keyboard 162 or mouse 161 when associated with the computer 110 .
  • the method may allow for the specialized mechanism to be added to patches without affecting the underlying patch or installation code.
  • the specialized mechanism may be added to a pre-existing patch whereby the patch and installation code are unaffected by the specialized mechanism.
  • code may have already been distributed to computers 110 such that the specialized mechanism will be recognized and handled appropriately.
  • the specialized mechanism may review the computer 110 on which it is to be installed, and determine whether changes need to be made to the computer 110 such that the installer will operate properly or asking the computer 110 for permission to run the installer code.
  • the specialized code will be activated as part of the trusted installation code and if the specialized code is not recognized by the computer 110 , the specialized code may instruct the computer 110 to seek out the necessary support to allow the specialized code to operate as intended.
  • the necessary support may be obtained from the software manufacture, from another computer 110 on a network, from a host computer 110 or from another source.
  • the method may treat the specialized mechanism as trusted operations without compromising machine security.
  • a certain level of trust is necessary to modify files. For example, if the files in question are core system files, a high level of permission is required. If the files are non-core system files, a lesser level of trust may be necessary.
  • the level of trust distributed with the patch may be related to the patch itself. Whatever level of trust is used, it may be appropriate in view of the patch to be distributed and may not jeopardize the security of the computer 110 .
  • a patch may be designated as one of “for testing” or “for evaluation” and the level of trust is different for patches designated “for testing” and patches designated “for evaluation.” Further, the level of trust may be different than official final patches.
  • FIG. 4 may illustrate a sample self extracting executable file 400 for providing a fix to a computer application.
  • the file 400 may include a package installer module 405 which may automatically install the patch when it is activated.
  • the file 400 may also have a wrapper 410 to the package installer 405 which may allow for the package installer 405 to be easily communicated.
  • the wrapper 410 may be an executable file named clearly to differentiate the deliverable as a private patch rather than a traditional, broadly distributed patch (or hotfix).
  • the executable name may include the phrase ‘-fortestingpurposesonly’ (For Testing Purposes Only). The name may also allow the file to be located by the detection algorithm.
  • the wrapper 410 may be the enabling technology to support “specialized mechanisms” as described in FIGS. 2 and 3 .
  • the specialized mechanism in this embodiment may be a certificate management utility.
  • the wrapper 410 may call into the certificate management utility before calling the package installation component. It may detect any error conditions thrown by the utility and report them back to the
  • the file 400 may also use a certificate management utility 415 which may be similar to the specialized mechanism described in FIGS. 2 and 3 .
  • the specialized mechanism in a patch ‘for testing’ may be the certificate management utility 415 . It may perform the detection, registration, setup, and clean-up functionality described above that a specialized mechanism could perform.
  • the certificate management utility 415 performs the following tasks during installation:
  • the utility Upon completion, the utility returns to the wrapper 410 , which checks for errors before calling the package installer. The package installer continues from there. Any return code is passed back through the wrapper 410 and returned to the user.
  • the certificate management utility 415 performs the following tasks after uninstallation:
  • Uninstallation refers to a window of time after the uninstaller components have completed, but before indicating completion to the user. It is during this time the utility is called with an argument to indicate uninstallation mode. Uninstallation may seamlessly return the customer's machine to one not containing the certificate of ‘for testing’ packages. Of note, the complete return to a normal state will only occur when no more registered content depending on the certificate exists. Also, the removal of the certificate leaves behind the visual cue until the next reboot though other computers 110 could remove the cue immediately.
  • the file 400 may also contain a detection algorithm 420 for finding patch content with the appropriate title (for testing). For example, the patch may check to see if the patch has already been installed or if the proper code is already on the computer 110 such that the certificate management utility 415 may operate properly.
  • the file 400 may contain a signing mechanism 425 that can assign authority different from official patches.
  • a patch may arrive with a generic level of security that may be unnecessarily high to install the code in the patch.
  • the signing mechanism 425 may act as a second level of authority checking and may adjust the level of authority as appropriate or indicated by the patch itself.
  • official hotfix packages from Microsoft are digitally signed using the Microsoft Publisher certificate.
  • ‘For testing’ hotfix packages are digitally signed using a different Microsoft certificate. The method does not require the use of this particular certificate.
  • the use of this signing mechanism 425 offers several benefits:
  • the package payload may be trusted by a catalog that is test signed with a Microsoft ‘test’ certificate. Code on a particular system may exist to recognize certain certificates to trigger a watermark on the bottom-right corner of their screen, indicating the presence of unofficial content on the computer 110 .
  • a hotfix package creation process then supports creating packages containing all differentiating features including the specialized mechanism to have the package register and work ‘for testing’. The process runs on an individual developer's machine with minimal setup and minimal time investment to create such a hotfix package.
  • the file 400 may contain a “do not remove” key 430 .
  • a key may be set to allow additional test patch data to be installed.
  • a second test patch may also be installed.
  • the permission to receive addition patch data may also be removed.
  • the permission to implement and receive data about the second patch may be maintained.
  • the file 400 may contain a mechanism for enforcing a limited installation window 435 .
  • a limited installation window may be enforced in the ‘for testing’ package to help prevent customers from installing an out-dated patch.
  • a timestamp of a future date (the expiration date) may be registered in the package and during installation, the current date is compared with this timestamp. If the current date is beyond the date of expiration, installation is blocked and the user is presented with a message.
  • the code for the check may be in an external library that is activated by the installer.
  • the file 400 may contain a name to differentiate the package from other fixes and indicate a level of trust 440 .
  • the wrapper may be an executable file named clearly to differentiate the deliverable as a private patch rather than a traditional, broadly distributed patch (or hotfix).
  • the executable name may include the phrase ‘-fortestingpurposesonly’ (For Testing Purposes Only).
  • the file 400 may contain a specialized package 445 that performs at least one function such as registration, detection, setup, reporting, tracking, policy verification or clean up. Detection may review the computer 110 on which it is to be installed, determines whether changes need to be made to the computer 110 such that the installer will operate properly or asks the computer 110 for permission to run the installer.
  • the detection algorithm for this implementation may operate as follows:
  • This form of registration allows for administrative tools to scan computers 110 for fixes of the class ‘for testing’ with only remote registry access.
  • setup may assist in setting up the installer and in installing the patch.
  • Reporting may report back to the patch creator upon installation and on patch success or failure.
  • Tracking may report back tracking data on the number of patch installations, any problems with the patches, etc.
  • the policy verification may ensure that the patch is a properly signed patch and not a malicious patch. Clean up may assist with returning the computer 110 to a functional state. If the patch does not solve the problem or creates new problems, the patch may be removed and the computer 110 may return to its pre-patch state.
  • Installing automatic patches is easier than installing binary files.
  • One patch package may contain one or more patch files.
  • Installing and uninstalling the patch is now as easy as with official patches and users experience a more consistent servicing experience. Special-case deployment instructions are not needed. Fewer reboots are required and less training is required for customer technicians. Detecting private fixes is now easy with differentiated naming and specialized registration. The whole end-to-end process takes less time.

Abstract

A code fix is communicated using an automatically executable code patch that has an additional code element that allows the code to perform the functions of registration, detection, setup, reporting, tracking, policy verification or clean up.

Description

This is a non-provisional of U.S. Provisional Application Ser. No. 60/797,557, filed May 3, 2006, the entire disclosure of which is incorporated herein by reference.
BACKGROUND
Customer satisfaction is critically important to a software company's success. Often, patches are deployed to correct problems with software. In some cases, the patches are sent to just a few parties to test the patches but these patches would not be automatically installed and the deployment of these fixes required tedious, manual work from customers contributing to dissatisfaction. For example, in the past, a customer would call product support reporting an issue and request a fix for the issue. Product support would work with a developer to get a private fix created. For the developer, making the private fix required making a source code change in the source tree, compiling the source into binaries, and putting those raw binaries on a share for the product support engineer to share with the customer. The customer would then follow hand-prepared instructions from product support to put the fix onto their affected machines. The new binaries would be manually copied to the location specified by the software manufacturer. The machines would then be rebooted to start running with the fixes. Next, the customer would confirm these fixes work on the machine, and would be asked to clean up these old binaries by rebooting again in safe mode and restoring the original files, then doing a final reboot to start up normally again. The customer would then communicate the results of their test to the software manufacturer.
The process above has many pain points including:
    • Developer pain delivering multiple binaries in their fix;
    • Customer pain from extra reboots during deployment;
    • Customer pain deploying multiple files to single machine;
    • Customer pain deploying a fix to multiple machines;
    • Customer pain manually removing files after testing;
    • Customer pain manually confirming fixes removed after testing;
    • Customer pain from downtime due to length of process;
    • Product Support pain communicating what/how to deploy; and
    • Customer & Product Support pain identifying machines with private fixes.
SUMMARY
Issuing private fixes to software problems has been difficult as the code fixes often involve distributing binary files that customers have to install manually. One approach is to communicate the code fix using an automatically executable code patch that has an additional code element that allows the code to perform the functions of registration, detection, setup, reporting, tracking, policy verification or clean up. The automatic code fix has a level of trust that is less than a traditional code fix but sufficient to make the necessary code changes and the code fix to the software is visually noted on the display.
DRAWINGS
FIG. 1 is a block diagram of a computing system that may operate in accordance with the claims;
FIG. 2 is a block diagram of a method of distributing fixes to a software application;
FIG. 3 is a block diagram of an additional method of distributing fixes to a software application; and
FIG. 4 is a graphical illustration of a file in accordance with the claims.
DESCRIPTION
Although the following text sets forth a detailed description of numerous different embodiments, it should be understood that the legal scope of the description is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment since describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.
It should also be understood that, unless a term is expressly defined in this patent using the sentence “As used herein, the term ‘_’ is hereby defined to mean . . . ” or a similar sentence, there is no intent to limit the meaning of that term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be interpreted to be limited in scope based on any statement made in any section of this patent (other than the language of the claims). To the extent that any term recited in the claims at the end of this patent is referred to in this patent in a manner consistent with a single meaning, that is done for sake of clarity only so as to not confuse the reader, and it is not intended that such claim term by limited, by implication or otherwise, to that single meaning. Finally, unless a claim element is defined by reciting the word “means” and a function without the recital of any structure, it is not intended that the scope of any claim element be interpreted based on the application of 35 U.S.C. §112, sixth paragraph.
FIG. 1 illustrates an example of a suitable computing system environment 100 on which a system for the steps of the claimed method and apparatus may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the method of apparatus of the claims. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100.
The steps of the claimed method and apparatus are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the methods or apparatus of the claims include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The steps of the claimed method and apparatus may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The methods and apparatus may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to FIG. 1, an exemplary system for implementing the steps of the claimed method and apparatus includes a general purpose computing device in the form of a computer 110. Components of computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus, and the Peripheral Component Interconnect-Express (PCI-E).
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, FIG. 1 illustrates operating system 134, application programs 135, other program modules 136 program data 137, and batch module 138.
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 140 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
The drives and their associated computer storage media discussed above and illustrated in FIG. 1, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In FIG. 1, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146 program data 147, and batch module 148. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136 program data 137, and patch module 138. Operating system 144, application programs 145, other program modules 146 program data 147, and patch module 148 are given different numbers here to illustrate that, at a minimum, they are different copies. The patch module 148 fixes a software application. A user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 190.
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 1 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
FIG. 2 may be a graphical illustration of a method of distributing fixes to a software application that may be performed by the computer 110 described in FIG. 1. At block 210, the method may create a source code change to fix the software application. Software is complicated and often times, software may be distributed that has a problem that is not immediately apparent. After a period of time, a user may notice a problem with some software. The user may report this problem to the software manufacture who may try to fix the problem. Ideally, the patch works and does not create any other unexpected problems. But just like any software, problems based on the patch may not appear for a period of time. Accordingly, patches may not be widely distributed but may be distributed to select parties (such as the party that noticed the problem) for testing before the patch is widely distributed in order to avoid creating additional problems.
At block 220, the source code of the patch may be compiled into a file to be communicated. In one embodiment, the patch file may be compiled into a binary file. Of course, the source code may be converted into any useful format and distributed accordingly. The file may be communicated to a single end user, multiple end users or to a network of end users.
At block 230, the method may create a specialized mechanism that includes additional executable code that is not a component of an installer or the binary payload containing the source code fix. The specialized mechanism may be adapted to perform a variety of functions such as registration, detection, setup, reporting, tracking, policy verification or clean up. Detection may review the computer 110 on which it is to be installed, determine whether changes need to be made to the computer 110 such that the installer will operate properly or ask the computer 110 for permission to run the installer. Setup may assist in setting up the computer 110 or with installing the patch. Reporting may report data back to a remote system or computer 110, the patch creator, or local user. The data may include information on the patch installation, state change (such as a reinstallation), or uninstallation and whether the patch was a success or a failure. Tracking may report back tracking data on the size of the patch, the content of the patch, the patch deployment time, subcomponents of the patch deployment time, whether a system restart was required, the user credential used when the patch was installed, a change in the number of software applications or services on the computer 110 (some patches carry new applications not previously present on the machine possibly in addition to fixes for existing components), system hardware or capabilities now able to be detected after patch payload deployed, other changes in system condition (such as a decrease in disk fragmentation, for example), the number of patch installations, any problems with the patches, etc. Policy verification may ensure that the patch conforms to system or administrative policies such as the patch is digitally signed and not a malicious patch, or the system is permitted to install a patch, or the user is not authenticated to deploy patches or this particular patch, etc. Clean up may assist with returning the computer 110 to a functional state. The specialized mechanism will be further discussed with respect to FIG. 3.
At block 240, the method may create a signed “for testing” package to be distributed. The package may include executable installer code that is automatically deployed when the entire package is received, the patch files and the specialized mechanism from block 230.
FIG. 3 may be a more detailed embodiment of the method. Blocks 305-320 may be the same as previously described blocks 210-240 in FIG. 2. At block 325, the specialized mechanism may check with a host to confirm whether or not installation of the patch is permitted. For example, in order to modify files in software, some level of trust must be present to avoid having malicious code be installed in software. That level of trust may be obtained through a variety of ways. In one embodiment, a signed certificate is used that is verified by a third party and is recognized by the user's computer 110 as being trusted. In another embodiment, the user's computer 110 may not recognize that the certificate is to be trusted, but the user may be part of a network and an authority or other host on the network may recognize that the certificate should be trusted.
At block 335, the specialized mechanism may report that a patch has been installed to another host on a network. If the patch has been installed to another host on the network then it may not be necessary to install the patch on the computer 110 in question. On the other hand, the host may decide that the code should be the same on all computers 110 on the network and it may become necessary to install the patch such that the code on the computer 110 in question is the same as all the computers 110 on the network.
At block 340, the method may display at the receiving station an indication that the source code change is a test patch. There may be variety of levels of patches or fixes that are distributed. Test patches may be patches that are thought to address a problem but have not been fully tested and evaluated. Accordingly, it may not be appropriate to widely distribute test patches and it makes logical sense to indicate on the display 191 of the computer 110 in question that a test patch has been installed. The indication may be a watermark, may be a text box, or may be a window, all of which indicate that a test patch is present on the computer 110 in question. The watermark may be visible to other network users that access the computer 110 with the test patch. Additionally, the presence of a ‘for testing’ patch can be communicated to the user via an audible alert to the speakers 197 or via an LED or other light on the keyboard 162 or mouse 161 when associated with the computer 110.
At block 345, the method may allow for the specialized mechanism to be added to patches without affecting the underlying patch or installation code. Related, at block 345, the specialized mechanism may be added to a pre-existing patch whereby the patch and installation code are unaffected by the specialized mechanism.
At block 350, in one embodiment, code may have already been distributed to computers 110 such that the specialized mechanism will be recognized and handled appropriately. For example, the specialized mechanism may review the computer 110 on which it is to be installed, and determine whether changes need to be made to the computer 110 such that the installer will operate properly or asking the computer 110 for permission to run the installer code. At block 355, in another embodiment, the specialized code will be activated as part of the trusted installation code and if the specialized code is not recognized by the computer 110, the specialized code may instruct the computer 110 to seek out the necessary support to allow the specialized code to operate as intended. The necessary support may be obtained from the software manufacture, from another computer 110 on a network, from a host computer 110 or from another source.
At block 360, the method may treat the specialized mechanism as trusted operations without compromising machine security. Depending on the patch to be distributed, a certain level of trust is necessary to modify files. For example, if the files in question are core system files, a high level of permission is required. If the files are non-core system files, a lesser level of trust may be necessary. As such, the level of trust distributed with the patch may be related to the patch itself. Whatever level of trust is used, it may be appropriate in view of the patch to be distributed and may not jeopardize the security of the computer 110. For example, at block 365, a patch may be designated as one of “for testing” or “for evaluation” and the level of trust is different for patches designated “for testing” and patches designated “for evaluation.” Further, the level of trust may be different than official final patches.
FIG. 4 may illustrate a sample self extracting executable file 400 for providing a fix to a computer application. The file 400 may include a package installer module 405 which may automatically install the patch when it is activated. The file 400 may also have a wrapper 410 to the package installer 405 which may allow for the package installer 405 to be easily communicated. The wrapper 410 may be an executable file named clearly to differentiate the deliverable as a private patch rather than a traditional, broadly distributed patch (or hotfix). The executable name may include the phrase ‘-fortestingpurposesonly’ (For Testing Purposes Only). The name may also allow the file to be located by the detection algorithm. The wrapper 410 may be the enabling technology to support “specialized mechanisms” as described in FIGS. 2 and 3. The specialized mechanism in this embodiment may be a certificate management utility. The wrapper 410 may call into the certificate management utility before calling the package installation component. It may detect any error conditions thrown by the utility and report them back to the user.
The file 400 may also use a certificate management utility 415 which may be similar to the specialized mechanism described in FIGS. 2 and 3. The specialized mechanism in a patch ‘for testing’ may be the certificate management utility 415. It may perform the detection, registration, setup, and clean-up functionality described above that a specialized mechanism could perform.
In one embodiment, the certificate management utility 415 performs the following tasks during installation:
Detects the certificate that trust the patch content
If the certificate is found,
 It scans the user computer 110 for other ‘for testing’ patches
 If none are found,
  It sets a “do not remove” key
Otherwise,
 It installs the needed certificate
Upon completion, the utility returns to the wrapper 410, which checks for errors before calling the package installer. The package installer continues from there. Any return code is passed back through the wrapper 410 and returned to the user.
The certificate management utility 415 performs the following tasks after uninstallation:
Detects the “do not remove” key
If “do not remove” bit is found,
  It returns, leaving the certificate
Otherwise,
 It scans the computer 110 for private patches
 If none are found,
  It removes the certificate
  Otherwise,
   It returns, leaving the certificate
“After uninstallation” refers to a window of time after the uninstaller components have completed, but before indicating completion to the user. It is during this time the utility is called with an argument to indicate uninstallation mode. Uninstallation may seamlessly return the customer's machine to one not containing the certificate of ‘for testing’ packages. Of note, the complete return to a normal state will only occur when no more registered content depending on the certificate exists. Also, the removal of the certificate leaves behind the visual cue until the next reboot though other computers 110 could remove the cue immediately.
The file 400 may also contain a detection algorithm 420 for finding patch content with the appropriate title (for testing). For example, the patch may check to see if the patch has already been installed or if the proper code is already on the computer 110 such that the certificate management utility 415 may operate properly.
The file 400 may contain a signing mechanism 425 that can assign authority different from official patches. For example, a patch may arrive with a generic level of security that may be unnecessarily high to install the code in the patch. The signing mechanism 425 may act as a second level of authority checking and may adjust the level of authority as appropriate or indicated by the patch itself. For example, official hotfix packages from Microsoft are digitally signed using the Microsoft Publisher certificate. ‘For testing’ hotfix packages are digitally signed using a different Microsoft certificate. The method does not require the use of this particular certificate. The use of this signing mechanism 425 offers several benefits:
1) It is a protection mechanism to prevent a miscreant from distributing the private fix as an official hotfix package; and
2) It facilitates creation of private hotfix packages on developer machines.
In the implementation, the package payload may be trusted by a catalog that is test signed with a Microsoft ‘test’ certificate. Code on a particular system may exist to recognize certain certificates to trigger a watermark on the bottom-right corner of their screen, indicating the presence of unofficial content on the computer 110. A hotfix package creation process then supports creating packages containing all differentiating features including the specialized mechanism to have the package register and work ‘for testing’. The process runs on an individual developer's machine with minimal setup and minimal time investment to create such a hotfix package.
The file 400 may contain a “do not remove” key 430. When a first test patch is installed, a key may be set to allow additional test patch data to be installed. In some circumstances, a second test patch may also be installed. However, if the first test patch is removed, the permission to receive addition patch data may also be removed. By setting the do not remove key, the permission to implement and receive data about the second patch may be maintained.
The file 400 may contain a mechanism for enforcing a limited installation window 435. A limited installation window may be enforced in the ‘for testing’ package to help prevent customers from installing an out-dated patch. A timestamp of a future date (the expiration date) may be registered in the package and during installation, the current date is compared with this timestamp. If the current date is beyond the date of expiration, installation is blocked and the user is presented with a message. In the implementation, the code for the check may be in an external library that is activated by the installer.
The file 400 may contain a name to differentiate the package from other fixes and indicate a level of trust 440. The wrapper may be an executable file named clearly to differentiate the deliverable as a private patch rather than a traditional, broadly distributed patch (or hotfix). The executable name may include the phrase ‘-fortestingpurposesonly’ (For Testing Purposes Only).
The file 400 may contain a specialized package 445 that performs at least one function such as registration, detection, setup, reporting, tracking, policy verification or clean up. Detection may review the computer 110 on which it is to be installed, determines whether changes need to be made to the computer 110 such that the installer will operate properly or asks the computer 110 for permission to run the installer. In one embodiment, the detection algorithm for this implementation may operate as follows:
    • Iterates over the hotfix key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix looking for a distinct mark made by an installed private package:
    • Returns true if 1 or more privates are found, false otherwise.
This form of registration allows for administrative tools to scan computers 110 for fixes of the class ‘for testing’ with only remote registry access.
As previously disclosed, setup may assist in setting up the installer and in installing the patch. Reporting may report back to the patch creator upon installation and on patch success or failure. Tracking may report back tracking data on the number of patch installations, any problems with the patches, etc. The policy verification may ensure that the patch is a properly signed patch and not a malicious patch. Clean up may assist with returning the computer 110 to a functional state. If the patch does not solve the problem or creates new problems, the patch may be removed and the computer 110 may return to its pre-patch state.
As a result of the method, several opportunities may now be available. Installing automatic patches is easier than installing binary files. One patch package may contain one or more patch files. Installing and uninstalling the patch is now as easy as with official patches and users experience a more consistent servicing experience. Special-case deployment instructions are not needed. Fewer reboots are required and less training is required for customer technicians. Detecting private fixes is now easy with differentiated naming and specialized registration. The whole end-to-end process takes less time.
Although the forgoing text sets forth a detailed description of numerous different embodiments, it should be understood that the scope of the patent is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment because describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.
Thus, many modifications and variations may be made in the techniques and structures described and illustrated herein without departing from the spirit and scope of the present claims. Accordingly, it should be understood that the methods and apparatus described herein are illustrative only and are not limiting upon the scope of the claims.

Claims (20)

The invention claimed is:
1. A method of distributing fixes to a software application problem comprising:
creating a source code change to fix the software application problem;
compiling the source code change into a patch file to be communicated, the patch file including a certificate indicating a level of trust to be assigned to the patch file;
creating executable installer code for installing the patch file;
creating a specialized mechanism that includes additional executable code comprising:
a certificate management utility configured to install a “for testing” certificate and set a “do not remove” key if a “for testing” certificate is not found on a receiving computer; and
a signing component for adjusting a level of security granted to the installer code according to the patch file's certificate; and;
creating a signed “for testing” package to be distributed, the “for testing” designation being indicative of a test package, where the test package comprises:
the executable installer code;
the patch file; and
the specialized mechanism;
wherein the signed “for testing” package, upon installation, causes an indication to be displayed that the test package was installed; and
wherein the certificate management utility, upon installation, tests the patch file's certificate and causes the signing component to adjust the level of security granted to the executable installer code.
2. The method according to claim 1, wherein the specialized mechanism performs at least one selected from a group comprising:
registering the patch file;
detecting whether a receiving computer can accept the test package by:
reviewing the receiving computer on which it is to be installed,
determining whether changes need to be made to the receiving computer such that the executable installer code will operate properly or
asking the receiving computer for permission to run the executable installer code;
setting up by assisting in setting up the receiving computer or with installing the patch file;
reporting by communicating reports back to one selected from a group comprising:
a remote computer,
the patch creator, or
a local user on the receiving computer;
data about one selected from a group comprising:
state changes,
uninstallation requirements, or
patch installation success or failure;
tracking by communicating tracking data on at least one of:
size of the patch file,
content of the patch file,
patch file deployment time,
subcomponents of the patch file deployment time,
whether a system restart was required,
user credential used when the patch file was installed,
a change in a number of software applications or services on the receiving computer,
system hardware or capabilities now able to be detected after patch payload deployed,
changes in system condition,
a number of patch file installations, and
any problems with the patch file;
verifying policy by ensuring that the patch file conforms to system or administrative policies, or
cleaning up by assisting with returning the receiving computer to a functional state.
3. The method according to claim 2, wherein the system or administrative policies comprise:
the patch file is digitally signed and not a malicious patch,
the receiving computer is permitted to install the patch file, and
a user is authenticated to deploy patches or this particular patch.
4. The method according to claim 2, further comprising using the specialized mechanism to check with a host to confirm whether or not installation of the patch file is permitted.
5. The method according to claim 2, further comprising using the specialized mechanism to report that the patch file has been installed on another host on a network.
6. The method of claim 1, wherein the indication comprises at least one of:
a visual indication on a display;
an audible alert; and
a visible indication on a keyboard or mouse associated with a computer.
7. The method according to claim 1, whereby the specialized mechanism is added to existing patches.
8. The method according to claim 1, wherein the specialized mechanism is executed by the operating system as a trusted operation.
9. The method according to claim 1, wherein the patch file is associated with a level of trust and wherein a patch file modifying core system files requires a first level of trust and a patch file modifying non-core system files requires a second level of trust.
10. The method of claim 1, further comprising the specialized mechanism looking to other computers for sufficient permission to run the installer.
11. The method of claim 1 wherein the indication that the patch file is installed is visible to a network user remotely.
12. A computer-storage medium storing computer-readable instructions, which when executed by a computer provide a fix to a computer application problem, comprising:
a patch component that corrects the computer application problem when installed;
a package installer component that automatically installs the patch component when the package installer component is activated;
a wrapper component to the package installer component, the wrapper component being indicative of a private patch;
a certificate management utility component, the certificate management utility component detecting a certificate that trusts the patch component during installation and for setting and detecting a “do not remove” bit;
a detection algorithm component for finding the patch component content with appropriate title;
a signing mechanism component adjusting a level of security as indicated by the patch component, the signing mechanism component assigning a first level of security for a private patch component and a second level of security for an official hotfix package;
a mechanism component enforcing a limited installation window; and
a naming component differentiating the patch component from other fixes and indicating a level of trust and a patch file intended to modify core system files requires a first level of trust and a patch file intended to modify non-core system files requires a second level of trust;
wherein, upon installation, the certificate management utility component scans for other patches, if none are found it sets the “do not remove” bit, and otherwise installs the certificate; and
upon uninstallation, the certificate management utility component tests for the “do not remove” bit and if the “do not remove” bit is not found scans the computer for private patches and removes the certificate only if none are found.
13. The computer-storage medium of claim 12, wherein the certificate management utility component performs at least one function selected from a group comprising:
registration of the patch component content;
detection, wherein detection further comprises reviewing a receiving computer on which the patch component is to be installed, determining whether changes need to be made to the receiving computer are such that the package installer component will operate properly or asks the receiving computer for permission to run the package installer component;
setup, wherein setup further comprises assisting in setting up the receiving computer or with installing the patch component content;
reporting, wherein reporting reports back to one selected from a group comprising:
a remote computer,
a patch creator, or
a local user on the receiving computer;
on one selected from a group comprising:
the patch component content installation,
state change required,
uninstallation required or
whether patch content was installed successfully;
tracking, wherein tracking may report back tracking data on at least one of:
the size of the patch component content,
the content of the patch component,
the patch component content deployment time,
subcomponents of the patch component content deployment time,
whether a system restart was required,
a user credential used when the patch component content was installed,
a change in the number of software applications or services on the receiving computer,
changes in system condition,
a number of patch component file installations,
the number of patch component content installations, and
any problems with the patch component content;
policy verification wherein policy verification further comprises ensuring that the patch component content conforms to system or administrative policies, or
clean up, wherein clean up assists with returning the receiving computer to a functional state.
14. The computer-storage medium of claim 13, wherein the system or administrative policies comprise:
the patch component content is digitally signed and not malicious patch content,
the receiving computer is permitted to install a patch, and
the user at the receiving computer is not authenticated to deploy patch component content or this particular patch component content.
15. The computer-storage medium of claim 12, wherein the naming component allows the patch file to be located by the detection algorithm component.
16. The computer-storage medium of claim 12, wherein the certificate management utility reports that a patch/fix has been installed on another host on a network.
17. The computer-storage medium of claim 12, wherein the certificate management utility displays at a receiving station an indication that the patch component is a test package.
18. The computer-storage medium of claim 17, wherein the indication comprises at least one of:
a visual indication on a display;
an audible alert; and
a visible indication on a keyboard or mouse associated with the receiving station.
19. A tangible computer storage medium storing computer executable instructions, for distributing fixes to a software application, which when executed perform the steps comprising:
creating a source code change to fix the software application;
compiling the source code into a patch file to be communicated, the patch file including a certificate indicating a level of trust to be assigned to the patch file;
creating executable installer code for installing the patch file;
creating a specialized mechanism that includes additional executable code comprising:
a certificate management utility configured to install a “for testing” certificate and set a “do not remove” key if a “for testing” certificate is not found on a receiving computer; and
a signing component for adjusting a level of security granted to the installer code according to the patch file's certificate; and;
creating a package to be distributed, the package being designated as “for testing”, the “for testing” designation being indicative of a test package, where the package comprises:
the executable installer code;
the patch file; and
the specialized mechanism;
wherein the signed “for testing” package, upon installation, causes an indication to be displayed that the test package was installed; and
wherein the certificate management utility, upon installation, tests the patch file's certificate and causes the signing component to adjust the level of security granted to the executable installer code.
20. The computer storage media of claim 19, wherein the specialized mechanism checks if the executable installer code will operate properly when automatically deployed.
US11/470,281 2006-05-03 2006-09-06 Differentiated installable packages Expired - Fee Related US8578363B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/470,281 US8578363B2 (en) 2006-05-03 2006-09-06 Differentiated installable packages

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US79755706P 2006-05-03 2006-05-03
US11/470,281 US8578363B2 (en) 2006-05-03 2006-09-06 Differentiated installable packages

Publications (2)

Publication Number Publication Date
US20070261047A1 US20070261047A1 (en) 2007-11-08
US8578363B2 true US8578363B2 (en) 2013-11-05

Family

ID=38662604

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/470,281 Expired - Fee Related US8578363B2 (en) 2006-05-03 2006-09-06 Differentiated installable packages

Country Status (1)

Country Link
US (1) US8578363B2 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8677346B1 (en) * 2011-09-27 2014-03-18 Symantec Corporation Providing installer package information to a user
US20140282439A1 (en) * 2013-03-14 2014-09-18 Red Hat, Inc. Migration assistance using compiler metadata
US9621403B1 (en) * 2012-03-05 2017-04-11 Google Inc. Installing network certificates on a client computing device
US20170142156A1 (en) * 2015-11-12 2017-05-18 Toyota Infotechnology Center Usa, Inc. Application Assurance for Open Platform In-Vehicle Infotainment System
US20180253295A1 (en) * 2015-09-11 2018-09-06 Siemens Aktiengesellschaft Increasing the reliability of software
US10095870B2 (en) * 2016-04-25 2018-10-09 Cloudminds (Shenzhen) Robotics Systems Co., Ltd. Virtual machine creation method and apparatus
US10620935B2 (en) * 2018-01-31 2020-04-14 Salesforce.Com, Inc. Version management automation and consistent application builds for different target systems
US11443067B2 (en) 2018-01-31 2022-09-13 Salesforce.Com, Inc. Restricting access and edit permissions of metadata

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7734285B2 (en) * 2001-04-03 2010-06-08 Qualcomm Incorporated Method and apparatus for network initiated uninstallation of application program over wireless network
US20080250385A1 (en) * 2007-04-09 2008-10-09 Sanchez Elton R Automating the deployment of applications
US9354853B2 (en) * 2008-07-02 2016-05-31 Hewlett-Packard Development Company, L.P. Performing administrative tasks associated with a network-attached storage system at a client
US8826005B1 (en) * 2008-08-21 2014-09-02 Adobe Systems Incorporated Security for software in a computing system
KR20110062937A (en) * 2009-12-04 2011-06-10 삼성전자주식회사 Server connected to image forming apparatus and client, client, and remote installing method for driver thereof
US9251312B2 (en) * 2010-02-23 2016-02-02 Siemens Aktiengesellschaft Application platform
JP2013020354A (en) * 2011-07-08 2013-01-31 Ricoh Co Ltd Log tabulation program, log tabulation device, and installer packager program
US9158533B2 (en) * 2012-01-16 2015-10-13 International Business Machines Corporation Manipulating source code patches
US10360064B1 (en) * 2013-08-19 2019-07-23 Amazon Technologies, Inc. Task scheduling, execution and monitoring
US10038719B2 (en) * 2014-04-29 2018-07-31 Dell Products L.P. Single-step custom configuration of a cloud client device
US10489139B2 (en) * 2017-01-31 2019-11-26 Salesforce.Com, Inc. Additive packaging through smart wrapping of packages and customizations in an on-demand environment
CN111897555A (en) * 2019-05-06 2020-11-06 阿里巴巴集团控股有限公司 Dynamic updating method, device and system of client and terminal equipment
US11392844B1 (en) * 2020-03-31 2022-07-19 Amazon Technologies, Inc. Customizable service for recommendations on source code quality

Citations (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5790856A (en) * 1995-05-08 1998-08-04 Apple Computer, Inc. Methods, apparatus, and data structures for data driven computer patches and static analysis of same
US5832275A (en) * 1994-12-13 1998-11-03 Novell, Inc. System for dynamically replacing operating software which provides distributed directory service after verifying that versions of new software and the operating software are compatible
US5881236A (en) * 1996-04-26 1999-03-09 Hewlett-Packard Company System for installation of software on a remote computer system over a network using checksums and password protection
US5905797A (en) * 1994-03-23 1999-05-18 Gms(Recordings)Limited Interactive compact disc system
US5953533A (en) * 1997-08-27 1999-09-14 Lucent Technologies Inc. Computer software distribution, installation and maintenance method and apparatus
US6167567A (en) * 1998-05-05 2000-12-26 3Com Corporation Technique for automatically updating software stored on a client computer in a networked client-server environment
US6202207B1 (en) * 1998-01-28 2001-03-13 International Business Machines Corporation Method and a mechanism for synchronized updating of interoperating software
US6256773B1 (en) * 1999-08-31 2001-07-03 Accenture Llp System, method and article of manufacture for configuration management in a development architecture framework
US6314565B1 (en) * 1997-05-19 2001-11-06 Intervu, Inc. System and method for automated identification, retrieval, and installation of multimedia software components
US6341373B1 (en) * 1996-12-20 2002-01-22 Liberate Technologies Secure data downloading, recovery and upgrading
US6367075B1 (en) * 1996-07-24 2002-04-02 Marimba, Inc. Method and apparatus for producing instructions describing the removal of updates to a computer system
US6389589B1 (en) * 1998-09-21 2002-05-14 Microsoft Corporation Class store schema
US6425126B1 (en) * 1999-05-19 2002-07-23 International Business Machines Corporation Apparatus and method for synchronizing software between computers
US20020100036A1 (en) * 2000-09-22 2002-07-25 Patchlink.Com 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
US6493871B1 (en) * 1999-09-16 2002-12-10 Microsoft Corporation Method and system for downloading updates for software installation
US20020194584A1 (en) * 2001-04-30 2002-12-19 Suorsa Raymond E. Automated provisioning of computing networks using a network database model
US6510513B1 (en) * 1999-01-13 2003-01-21 Microsoft Corporation Security services and policy enforcement for electronic data
US20030028867A1 (en) * 1998-09-01 2003-02-06 Kryloff Sergey A. Software patch generator
US20030088516A1 (en) * 1999-12-21 2003-05-08 Eric B. Remer Software anti-piracy licensing
US20030121033A1 (en) * 2001-12-05 2003-06-26 Peev Igor B. Installing software on a mobile computing device using the rollback and security features of a configuration manager
US20040003266A1 (en) * 2000-09-22 2004-01-01 Patchlink Corporation Non-invasive automatic offsite patch fingerprinting and updating system and method
US20040015956A1 (en) * 2001-04-05 2004-01-22 International Business Machines Corporation System and method for automatically de-installing previously installed software based on user defined preferences
US20040015950A1 (en) * 2001-05-10 2004-01-22 International Business Machines Corporation Application service provider upgrades
US20040045000A1 (en) * 2002-09-04 2004-03-04 Nec Corporation Software license management system and method and recording medium
US20040098715A1 (en) * 2002-08-30 2004-05-20 Parixit Aghera Over the air mobile device software management
US20040103411A1 (en) * 2002-11-26 2004-05-27 Thayer Jennifer Joy System and method for automated program updating in a remote appliance
US20040109187A1 (en) * 2002-08-30 2004-06-10 Hiroyuki Matsushima Image processing apparatus, image processing method and program
US20040117784A1 (en) * 2002-10-15 2004-06-17 Canon Kabushiki Kaisha Management apparatus, management method, and control program therefor
US20040187103A1 (en) * 2003-03-17 2004-09-23 Wickham Robert T. Software updating system and method
US20050132359A1 (en) * 2003-12-15 2005-06-16 Mcguire Thomas D. System and method for updating installation components in a networked environment
US20050210448A1 (en) * 2004-03-17 2005-09-22 Kipman Alex A Architecture that restricts permissions granted to a build process
US20060075401A1 (en) * 2004-10-05 2006-04-06 Microsoft Corporation Patch installation control
US20060101457A1 (en) * 2004-10-29 2006-05-11 Zweifel Evan R Method and apparatus for determining which program patches to recommend for installation
US20060117184A1 (en) * 2004-11-29 2006-06-01 Bleckmann David M Method to control access between network endpoints based on trust scores calculated from information system component analysis
US20060184926A1 (en) * 2002-07-17 2006-08-17 Yan Or Deployment of applications in a multitier compute infrastructure
US7130897B2 (en) * 2001-10-11 2006-10-31 International Business Machines Corporation Dynamic cluster versioning for a group

Patent Citations (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5905797A (en) * 1994-03-23 1999-05-18 Gms(Recordings)Limited Interactive compact disc system
US5832275A (en) * 1994-12-13 1998-11-03 Novell, Inc. System for dynamically replacing operating software which provides distributed directory service after verifying that versions of new software and the operating software are compatible
US5790856A (en) * 1995-05-08 1998-08-04 Apple Computer, Inc. Methods, apparatus, and data structures for data driven computer patches and static analysis of same
US5881236A (en) * 1996-04-26 1999-03-09 Hewlett-Packard Company System for installation of software on a remote computer system over a network using checksums and password protection
US6367075B1 (en) * 1996-07-24 2002-04-02 Marimba, Inc. Method and apparatus for producing instructions describing the removal of updates to a computer system
US6341373B1 (en) * 1996-12-20 2002-01-22 Liberate Technologies Secure data downloading, recovery and upgrading
US6314565B1 (en) * 1997-05-19 2001-11-06 Intervu, Inc. System and method for automated identification, retrieval, and installation of multimedia software components
US5953533A (en) * 1997-08-27 1999-09-14 Lucent Technologies Inc. Computer software distribution, installation and maintenance method and apparatus
US6202207B1 (en) * 1998-01-28 2001-03-13 International Business Machines Corporation Method and a mechanism for synchronized updating of interoperating software
US6167567A (en) * 1998-05-05 2000-12-26 3Com Corporation Technique for automatically updating software stored on a client computer in a networked client-server environment
US20020026634A1 (en) * 1998-05-18 2002-02-28 Robert Shaw Secure data downloading, recovery and upgrading
US20030028867A1 (en) * 1998-09-01 2003-02-06 Kryloff Sergey A. Software patch generator
US6389589B1 (en) * 1998-09-21 2002-05-14 Microsoft Corporation Class store schema
US6510513B1 (en) * 1999-01-13 2003-01-21 Microsoft Corporation Security services and policy enforcement for electronic data
US6425126B1 (en) * 1999-05-19 2002-07-23 International Business Machines Corporation Apparatus and method for synchronizing software between computers
US6968550B2 (en) * 1999-05-19 2005-11-22 International Business Machines Corporation Apparatus and method for synchronizing software between computers
US6256773B1 (en) * 1999-08-31 2001-07-03 Accenture Llp System, method and article of manufacture for configuration management in a development architecture framework
US6493871B1 (en) * 1999-09-16 2002-12-10 Microsoft Corporation Method and system for downloading updates for software installation
US20030088516A1 (en) * 1999-12-21 2003-05-08 Eric B. Remer Software anti-piracy licensing
US20040003266A1 (en) * 2000-09-22 2004-01-01 Patchlink Corporation Non-invasive automatic offsite patch fingerprinting and updating system and method
US20020100036A1 (en) * 2000-09-22 2002-07-25 Patchlink.Com 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
US20040015956A1 (en) * 2001-04-05 2004-01-22 International Business Machines Corporation System and method for automatically de-installing previously installed software based on user defined preferences
US20020194584A1 (en) * 2001-04-30 2002-12-19 Suorsa Raymond E. Automated provisioning of computing networks using a network database model
US20040015950A1 (en) * 2001-05-10 2004-01-22 International Business Machines Corporation Application service provider upgrades
US7130897B2 (en) * 2001-10-11 2006-10-31 International Business Machines Corporation Dynamic cluster versioning for a group
US20030121033A1 (en) * 2001-12-05 2003-06-26 Peev Igor B. Installing software on a mobile computing device using the rollback and security features of a configuration manager
US20060184926A1 (en) * 2002-07-17 2006-08-17 Yan Or Deployment of applications in a multitier compute infrastructure
US20040098715A1 (en) * 2002-08-30 2004-05-20 Parixit Aghera Over the air mobile device software management
US20040109187A1 (en) * 2002-08-30 2004-06-10 Hiroyuki Matsushima Image processing apparatus, image processing method and program
US20040045000A1 (en) * 2002-09-04 2004-03-04 Nec Corporation Software license management system and method and recording medium
US20040117784A1 (en) * 2002-10-15 2004-06-17 Canon Kabushiki Kaisha Management apparatus, management method, and control program therefor
US20040103411A1 (en) * 2002-11-26 2004-05-27 Thayer Jennifer Joy System and method for automated program updating in a remote appliance
US20040187103A1 (en) * 2003-03-17 2004-09-23 Wickham Robert T. Software updating system and method
US20050132359A1 (en) * 2003-12-15 2005-06-16 Mcguire Thomas D. System and method for updating installation components in a networked environment
US20050210448A1 (en) * 2004-03-17 2005-09-22 Kipman Alex A Architecture that restricts permissions granted to a build process
US20060075401A1 (en) * 2004-10-05 2006-04-06 Microsoft Corporation Patch installation control
US20060101457A1 (en) * 2004-10-29 2006-05-11 Zweifel Evan R Method and apparatus for determining which program patches to recommend for installation
US20060117184A1 (en) * 2004-11-29 2006-06-01 Bleckmann David M Method to control access between network endpoints based on trust scores calculated from information system component analysis

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8677346B1 (en) * 2011-09-27 2014-03-18 Symantec Corporation Providing installer package information to a user
US9621403B1 (en) * 2012-03-05 2017-04-11 Google Inc. Installing network certificates on a client computing device
US20140282439A1 (en) * 2013-03-14 2014-09-18 Red Hat, Inc. Migration assistance using compiler metadata
US9223570B2 (en) * 2013-03-14 2015-12-29 Red Hat, Inc. Migration assistance using compiler metadata
US20180253295A1 (en) * 2015-09-11 2018-09-06 Siemens Aktiengesellschaft Increasing the reliability of software
US10698676B2 (en) * 2015-09-11 2020-06-30 Siemens Aktiengesellschaft Increasing the reliability of software
US20170142156A1 (en) * 2015-11-12 2017-05-18 Toyota Infotechnology Center Usa, Inc. Application Assurance for Open Platform In-Vehicle Infotainment System
US10095870B2 (en) * 2016-04-25 2018-10-09 Cloudminds (Shenzhen) Robotics Systems Co., Ltd. Virtual machine creation method and apparatus
US10620935B2 (en) * 2018-01-31 2020-04-14 Salesforce.Com, Inc. Version management automation and consistent application builds for different target systems
US11403089B2 (en) 2018-01-31 2022-08-02 Salesforce.Com, Inc. Version management automation and consistent application builds for different target systems
US11443067B2 (en) 2018-01-31 2022-09-13 Salesforce.Com, Inc. Restricting access and edit permissions of metadata
US11755780B2 (en) 2018-01-31 2023-09-12 Salesforce, Inc. Restricting access and edit permissions of metadata

Also Published As

Publication number Publication date
US20070261047A1 (en) 2007-11-08

Similar Documents

Publication Publication Date Title
US8578363B2 (en) Differentiated installable packages
US9910743B2 (en) Method, system and device for validating repair files and repairing corrupt software
CN103729597B (en) System starts method of calibration, system starts calibration equipment and terminal
US7788730B2 (en) Secure bytecode instrumentation facility
CN104200153B (en) A kind of starting verification method and system
CN101156166B (en) Systems and methods for using machine attributes to deter software piracy in an enterprise environment
US7516367B1 (en) Automated, distributed problem determination and upgrade planning tool
US8032880B2 (en) Multi-branch management for updating software
US20050027657A1 (en) Distinguishing legitimate hardware upgrades from unauthorized installations of software on additional computers
JP2005327275A (en) Efficient patching
US8095987B2 (en) Software anti-piracy protection
EP2413257B1 (en) Method for replacing an illegitimate copy of a software program with legitimate copy and corresponding system
JP2005327274A (en) Efficient patching
JP2019008376A (en) File management device and file management method
CN107632932B (en) Multi-stage checking software warehouse reliability detection method
CN108205491B (en) NKV 6.0.0 system-based trusted technology compatibility testing method
CN110869931A (en) Electronic system vulnerability assessment
CN113642004A (en) Container mirror image security scanning and repairing method, device and equipment
US8074205B2 (en) Binary verification service
Dadzie Understanding Software Patching: Developing and deploying patches is an increasingly important part of the software development process.
KR101600178B1 (en) Method and apparatus for detecting illegally copied application
CN114546420A (en) Software remote installation protection uninstalling method
CN112464243A (en) Firmware tamper-proofing method and device based on android system
JP2006092475A (en) Source code inspection system
KR20020011509A (en) Method of monitoring for illegal copy of program

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SAH, MANEESH;REEL/FRAME:018701/0743

Effective date: 20060905

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034542/0001

Effective date: 20141014

FPAY Fee payment

Year of fee payment: 4

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20211105