Abstract: A mechanism that allows firmware for a computing device to be updated in a secure manner by utilizing an update validation procedure included in a ROM image is discussed.

Abstract: A mechanism that allows firmware for a computing device to be updated in a secure manner by utilizing an update validation procedure included in a ROM image is discussed.

Abstract: A mechanism for creating secure storage for firmware for a computing device. A designated secure storage area holding firmware that is executable prior to a loading of an operating system for the computing device is created during a build of a ROM image. The creating marks one or more files as requiring encrypted storage and the one or marked files are combined during the build into the designated secure storage area. The designated secure storage area is located outside the ROM image and includes, during the build of the ROM image, a reference to the designated secure storage area in a build of firmware placed in the ROM image. The reference includes a flag indicating a current encrypted status of the designated secure storage area.

Abstract: A mechanism for making increased amounts of firmware available to a computer pre-boot is discussed. To increase the amount of firmware available pre-boot, a design decision is made during the build process as to which segments of the firmware need to be placed on the ROM part and which segments of the firmware can be located elsewhere. The segments of the firmware that are stored remotely from the ROM are referred to as “virtual ROM modules”. Each of the virtual ROM modules is assigned a generated unique identifier, and a “message digest” is constructed for each module using an algorithm such as MD5 or SHA-1. In the software build of the ROM image, the message digest-unique identifier pair created for each Virtual ROM module is used as a logical pointer for the virtual module. Additionally, a search path variable is placed into the ROM image in non-volatile storage. The search path provides for one or more locations in which to look for the Virtual ROM modules, and may be updated at a later point in time.

Abstract: A mechanism for creating secure storage for firmware for a computing device. A designated secure storage area holding firmware that is executable prior to a loading of an operating system for the computing device is created during a build of a ROM image. The creating marks one or more files as requiring encrypted storage and the one or marked files are combined during the build into the designated secure storage area. The designated secure storage area is located outside the ROM image and includes, during the build of the ROM image, a reference to the designated secure storage area in a build of firmware placed in the ROM image. The reference includes a flag indicating a current encrypted status of the designated secure storage area.

Abstract: A mechanism for creating and accessing a secure storage area for firmware that stores a “Virtual ROM” module reference or pointer in the actual ROM that includes a unique identifier for the virtual ROM module to be retrieved is discussed. The actual ROM image also contains a generated unique identifier for the whole machine. In retrieving a Virtual ROM module, both the module identifier and the machine identifier are used. Once retrieved, the module is validated using a message digest stored in the Virtual ROM module reference. If required, the Virtual ROM module is then decrypted using a secret key that is stored elsewhere in the actual ROM. Updates to the Virtual ROM module are made in memory by pre-boot code. At a point in time when these updates are complete, the Virtual ROM module is written back out to the location from which it was retrieved.

Abstract: A mechanism that allows firmware to be updated in a secure manner is discussed. Two attributes are used in the actual ROM to refer to a Virtual ROM module. The two attributes are a version attribute and a reference to a separate module that is capable of validating updates. The update process updates the message digest associated with the first Virtual ROM module and the version attribute associated with the first Virtual ROM module. The update process also produces a new copy of the corresponding file (that may be located on the local disk) that when hashed will “match” the new message digest.

Abstract: A mechanism for making increased amounts of firmware available to a computer pre-boot is discussed. To increase the amount of firmware available pre-boot, a design decision is made during the build process as to which segments of the firmware need to be placed on the ROM part and which segments of the firmware can be located elsewhere. The segments of the firmware that are stored remotely from the ROM are referred to as “virtual ROM modules”. Each of the virtual ROM modules is assigned a generated unique identifier, and a “message digest” is constructed for each module using an algorithm such as MD5 or SHA-1. In the software build of the ROM image, the message digest-unique identifier pair created for each Virtual ROM module is used as a logical pointer for the virtual module. Additionally, a search path variable is placed into the ROM image in non-volatile storage. The search path provides for one or more locations in which to look for the Virtual ROM modules, and may be updated at a later point in time.

Abstract: A mechanism for making increased amounts of firmware available to a computer pre-boot is discussed. To increase the amount of firmware available pre-boot, a design decision is made during the build process as to which segments of the firmware need to be placed on the ROM part and which segments of the firmware can be located elsewhere. The segments of the firmware that are stored remotely from the ROM are referred to as “virtual ROM modules”. Each of the virtual ROM modules is assigned a generated unique identifier, and a “message digest” is constructed for each module using an algorithm such as MD5 or SHA-1. In the software build of the ROM image, the message digest-unique identifier pair created for each Virtual ROM module is used as a logical pointer for the virtual module. Additionally, a search path variable is placed into the ROM image in non-volatile storage. The search path provides for one or more locations in which to look for the Virtual ROM modules, and may be updated at a later point in time.

Abstract: A mechanism for creating and accessing a secure storage area for firmware that stores a “Virtual ROM” module reference or pointer in the actual ROM that includes a unique identifier for the virtual ROM module to be retrieved is discussed. The actual ROM image also contains a generated unique identifier for the whole machine. In retrieving a Virtual ROM module, both the module identifier and the machine identifier are used. Once retrieved, the module is validated using a message digest stored in the Virtual ROM module reference. If required, the Virtual ROM module is then decrypted using a secret key that is stored elsewhere in the actual ROM. Updates to the Virtual ROM module are made in memory by pre-boot code. At a point in time when these updates are complete, the Virtual ROM module is written back out to the location from which it was retrieved.

Abstract: A mechanism for making increased amounts of firmware available to a computer pre-boot is discussed. To increase the amount of firmware available pre-boot, a design decision is made during the build process as to which segments of the firmware need to be placed on the ROM part and which segments of the firmware can be located elsewhere. The segments of the firmware that are stored remotely from the ROM are referred to as “virtual ROM modules”. Each of the virtual ROM modules is assigned a generated unique identifier, and a “message digest” is constructed for each module using an algorithm such as MD5 or SHA-1. In the software build of the ROM image, the message digest-unique identifier pair created for each Virtual ROM module is used as a logical pointer for the virtual module. Additionally, a search path variable is placed into the ROM image in non-volatile storage. The search path provides for one or more locations in which to look for the Virtual ROM modules, and may be updated at a later point in time.

Abstract: A mechanism that allows firmware to be updated in a secure manner is discussed. Two attributes are used in the actual ROM to refer to a Virtual ROM module. The two attributes are a version attribute and a reference to a separate module that is capable of validating updates. The update process updates the message digest associated with the first Virtual ROM module and the version attribute associated with the first Virtual ROM module. The update process also produces a new copy of the corresponding file (that may be located on the local disk) that when hashed will “match” the new message digest.

Abstract: A system and method for the delivery, retrieval and display of content to a user during the initial boot sequence of a computer or electronic device and/or after the completion of the initial boot sequence but prior to the loading of an operating system is disclosed. The illustrative embodiment of the present invention also includes a non-intrusive method of updating the content is provided that minimizes the disruption to other processes running on the computer or electronic device. The method enables the content to be updated automatically following the loading of the operating system or in response to a user request, depending upon the implementation of the invention. Additional embodiments of the present invention vary the display of content according to user responses to queries posed during the boot sequence and enable the tailoring of content to an individual user based upon a user profile.

Abstract: An electronic device, such as a hand-held portable computer, is provided with capability to operate an application during a low power mode. During the low power mode, portions of hardware, software, services, and/or other components of the portable computer that are not necessary to the operation of the application is suspended or otherwise deactivated. As each task is performed by the application, the components that are no longer needed for subsequent tasks to be performed by the application are also deactivated and reactivated as needed. The deactivation can be performed in sequence from the highest-level components to the lowest-level components to ensure that components that are needed by other components are not prematurely deactivated. A specific set of events transitions the portable computer out of the low power mode.

Abstract: A low power media player is provided for an electronic device, such as a hand-held portable computer having capability to operate an application during a low power mode. During the low power mode, portions of hardware, software, services, and/or other components of the portable computer that are not necessary to the operation of the low power media player are suspended or otherwise deactivated. Rather than repeatedly accessing a hard disk to read media files for playback, the low power media player limits its number of access operations by reading as many media files as possible during each access operation, and then caching the read media files. When playback of the media files is to be performed, the media files are read from the cache, thereby reducing the amount of power consumption attributable to hard disk access operations.

Abstract: Low power email capabilities are provided for an electronic device, such as a hand-held portable computer having capability to operate an application during a low power mode. During the low power mode, portions of hardware, software, services, and/or other components of the portable computer that are not necessary for email-related operations, such as polling a server for new email, are suspended or otherwise deactivated. At least a portion of a new email is stored in a memory of a low power display module (LPDM) of the portable computer. The LPDM is provided with its own low-power processing unit, user interface, and other components to allow access to and manipulation of the stored email while other components of the portable computer remain deactivated.

Abstract: A method for altering the start-up sequence of an operating system prior to loading the operating system is disclosed. The method allows changes to be made to the start-up sequence of processes and applications initiated by the operating system based upon the occurrence of a designated event during the BIOS boot sequence. In this manner, events occurring prior to operating system loading affect the operating system start-up sequence. Similarly, the illustrative embodiment of the present invention may, during the period of time the operating system is operating, write instructions which control the sequence of events taking place during the subsequent BIOS boot sequence.

Abstract: A system and method for the delivery, retrieval and display of content to a user during the initial boot sequence of a computer or electronic device and/or after the completion of the initial boot sequence but prior to the loading of an operating system is disclosed. The illustrative embodiment of the present invention also includes a non-intrusive method of updating the content is provided that minimizes the disruption to other processes running on the computer or electronic device. The method enables the content to be updated automatically following the loading of the operating system or in response to a user request, depending upon the implementation of the invention. Additional embodiments of the present invention vary the display of content according to user responses to queries posed during the boot sequence and enable the tailoring of content to an individual user based upon a user profile.

Abstract: A method for altering the start-up sequence of an operating system prior to loading the operating system is disclosed. The method allows changes to be made to the start-up sequence of processes and applications initiated by the operating system based upon the occurrence of a designated event during the BIOS boot sequence. In this manner, events occurring prior to operating system loading affect the operating system start-up sequence. Similarly, the illustrative embodiment of the present invention may, during the period of time the operating system is operating, write instructions which control the sequence of events taking place during the subsequent BIOS boot sequence.

Abstract: A method and apparatus for providing an historical perspective into a database of information objects through an efficient method and apparatus for versioning information objects stored in a database as well as an index representative of the information objects is disclosed. The latest versions of each one of the information objects and each one of the entries in the index are maintained in the database. Partial earlier versions of each one of the information objects and each one of the index entries are stored with the latest versions. The partial versions contain only sufficient information about the differences between the earlier versions and the later ones so that any earlier version may be reconstructed. Identification tags are employed as unique identifiers for each one of the plurality of information objects and for different versions of the information objects.