With the proliferation of networked devices such as computers, digital assistants, wireless phones and so forth, and the ubiquitous access afforded to these devices by local, regional and wide area networks, such as the Internet, even the most protected executables and data can be vulnerable to harm. Whether the harm is due to damage caused by a virus, an unauthorized access, or simply due to natural occurrences such as exposure to the elements, the importance of executable and data integrity and security cannot be overstated.
Unfortunately, under the prior art, integrity and security issues have been pretty much treated as post-installation issues. That is, denial of unauthorized accesses, protection of executable and data integrity, and so forth have been addressed with protocols, utilities and tools that are decoupled from the installation process.
FIG. 1 illustrates a typical prior art installation process for installing software products or entities onto a computing apparatus. The terms “product” and “entity” as used herein are substantively synonymous to convey the fact that for the purpose of the application, the object of an install may be of a wide range of “entities”. These “entities” may include, but are not limited to, simple “entities”, each having only a handful of parts and generally not referred to as a “product” whether they have commercial values or not, as well as complex “entities”, each having a large number of parts and generally refers to as a “product”, as it typically has commercial value.
As illustrated, typically, a software product/entity 102 having a number of components 110, has one or more associated description and installation instruction files 104. Collectively, the associated description and installation instruction files 104 include e.g. the feature list of the software product/entity 102, the part list 114, the association between features and parts 116, and instructions on how and/or where to store the parts 118. Further, if applicable, the associated description and installation instruction files 104 may also include customization instructions 120, compilation instructions 122, linking instructions 124 and access set up instructions 126.
Generally, both components 110 and features are made up of parts. Components 110 are collections of parts viewed from a structure perspective of the product/entity 102, whereas features are collections of parts viewed from an external user perspective. As used herein, the terms are not necessarily meant to be mutually exclusive. The precise definition and delineation of these terms are not essential to the understanding or practice of the present invention. Accordingly, they are not to be read restrictively.
Continuing to refer to FIG. 1, typically an installer 100 reads 128 the product description and installation instruction file(s) 112, then installs the product/entity 102 based substantially on the description and installation instructions provided. Typically, the installation results in the components 110 of product/entity 102, made up of executables 144 and associated resources 146, being stored into a file system 106 in a manner that allows executables 144 to be retrievable for execution. Various product/entity related information 148, such as the installed parts, their usage of shared functions, and so forth, may be stored in a system repository 108.
In addition to reading the product/entity description and install instructions 104, installer 100 typically reads 202 product/entity file 102 to obtain the parts, and stores 132 the obtained parts as instructed. Upon storing the parts, installer 100 typically solicits 134 customization inputs from a user, then compiles 136 and links 138 the product together per the instructions provided and the customization inputs received. Further, for products/entities 102 designed for interactive usage, typically, the installation process may also include setting up the user access mechanism, e.g. “start up” icons and so forth.
Accordingly, it is desirable if the installation process can be enhanced to contribute to the safe guarding of the integrity of a computing apparatus, or simply, a programmable apparatus.
USPTO Backgrounds
USPTO Backgrounds