Method, apparatus and computer program for loading files during a boot-up process

A method, apparatus and computer program are provided for loading files during a boot-up process. In the context of a method, the method includes identifying at least one new file to be loaded in a computing device during a boot-up process of said computing device. Also, determining if loading at least one of the identified new file(s) causes the computing device to crash. Also, updating a list on the computing device in dependence on whether the loading of the identified new file(s) causes the computing device to crash. Also, loading at least one file in the computing device during a boot-up process in dependence on the list, to prevent the computing device crashing during the boot-up process.

RELATED APPLICATION

This application was originally filed as PCT Application No. PCT/IB2010/052321 filed May 25, 2010, which claims priority benefit to Great Britain Patent Application No. 0911337.4, filed Jun. 30, 2009.

TECHNICAL FIELD

Embodiments of the present invention relate generally to computing devices. More particularly, embodiments relate to a method, apparatus and computer program for loading files during a boot-up process of said computing devices.

BACKGROUND

When a computing device is switched on or after it has been rebooted, the computing device performs a boot-up process to initialise the device. The boot-up process involves the loading of a number of files. In the event one of the files is corrupt the computing device may crash when trying to load the corrupt file and consequently need to reboot. However, the corrupt file can lead to a continuous reboot cycle, wherein the device never completes the boot-up process.

SUMMARY OF EMBODIMENTS

A first example of the invention provides a method, comprising:

identifying at least one new file to be loaded in a computing device during a boot-up process of said computing device, determining if loading at least one of the identified new file(s) causes said computing device to crash, and updating a list on said computing device in dependence on whether the loading of the identified new file(s) causes said computing device to crash; and,

loading at least one file in said computing device during a boot-up process of said computing device in dependence on said list to prevent said computing device crashing during the boot-up process.

In an example, determining if loading at least one of the identified new file(s) causes said computing device to crash comprises loading the identified new file(s) and detecting if said computing device has not crashed. In another example, detecting that said computing device has not crashed comprises detecting that said computing device is operational.

In an example, determining if loading at least one of the identified new file(s) causes said computing device to crash further comprises performing a verification test on the identified new file(s) before the identified new file(s) is/are loaded. In another example, it is determined that loading an identified new file causes said computing device to crash if the identified new file fails the verification test. In a further example, the verification test comprises determining that the size of the identified new file is greater than zero.

In an example, said list comprises an invalid portion, and a representation of an identified new file is stored in said invalid portion if it is determined that loading the identified new file causes said computing device to crash. In another example, said list further comprises a valid portion, and a representation of an identified new file is stored in said valid portion if it is determined that loading the identified new file does not cause said computing device to crash. In another example, step a. further comprises writing a representation of at least one of the identified new file(s) in said invalid portion, and updating said list comprises moving a representation to said valid portion if loading the identified new file corresponding to the representation is determined not to cause said computing device to crash. In a further example, each representation written in said invalid portion is tagged, and updating said list further comprises de-tagging a representation in said invalid portion if loading the identified new file corresponding to the representation is determined to cause said computing device to crash.

In an example, step b. comprises not loading files having a representation in said invalid portion. In another example, step b. comprises loading files having a representation in said valid portion.

In an example, the method further comprises detecting a modification to a file having a representation in said list, and removing said representation from said list.

In an example, identifying at least one new file to be loaded in the computing device during a boot-up process of said computing device comprises identifying files to be loaded during the boot-up process which do not have a representation in said list. In another example, identifying at least one new file to be loaded in the computing device during a boot-up process of said computing device further comprises identifying files corresponding to one or more representation(s) received from the computing device which do not have a representation in said list.

A second example of the invention provides an apparatus, comprising:

a processor

memory including computer program code

the memory and computer program code configured in use to, with the processor, cause the apparatus to perform at least the following:

identify any new files to be loaded in a computing device during a boot-up process of said computing device, determining if loading at least one of the identified new file(s) causes said computing device to crash, and updating a list on said computing device in dependence on whether the loading of the identified new file(s) causes said computing device to crash; and,

load at least one file in said computing device during a boot-up process of said computing device in dependence on said list to prevent said computing device crashing during the boot-up process.

A third example of the invention provides a computer program, comprising: code for identifying at least one new file to be loaded in a computing device during a boot-up process of said computing device, determining if loading at least one of the identified new file(s) causes said computing device to crash, and updating a list on said computing device in dependence on whether the loading of the identified new file(s) causes said computing device to crash; and,

code for loading at least one file in said computing device during a boot-up process of said computing device in dependence on said list to prevent said computing device crashing during the boot-up process.

In an example, the computer program is a computer program product comprising a computer-readable medium bearing a computer program code embodied therein for use with a computer.

A fourth example of the invention provides a computer-readable medium encoded with instructions that, when executed by a computer:

identify any new files to be loaded in a computing device during a boot-up process of said computing device, determining if loading at least one of the identified new file(s) causes said computing device to crash, and updating a list on said computing device in dependence on whether the loading of the identified new file(s) causes said computing device to crash; and,

load at least one file in said computing device during a boot-up process of said computing device in dependence on said list to prevent said computing device crashing during the boot-up process.

A fifth example of the invention provides an apparatus, comprising:

means for identifying at least one new file to be loaded in a computing device during a boot-up process of said computing device, said means being configured to determine if loading at least one of the identified new file(s) causes said computing device to crash, and said means being configured to update a list on said computing device in dependence on whether the loading of the identified new file(s) causes said computing device to crash; and,

means for loading at least one file in said computing device during a boot-up process of said computing device in dependence on said list to prevent said computing device crashing during the boot-up process.

DESCRIPTION OF EMBODIMENTS

A description of a number of embodiments follows, provided by way of example only.

FIG. 1is a schematic diagram of a computing device10having a casing12. The computing device10forms the basis of the embodiments to be described. The casing12of the device10encapsulates a keypad14, a touch-screen display16, a speaker18and a microphone20. The device10further includes an antenna22. The device10illustrated inFIG. 1is a mobile device in that it may be held in a user's hand and used to participate in communication sessions, in particular, telephone calls. During such sessions the device10may be utilised so that the speaker18is held to a user's ear and the microphone20is situated in proximity to a user's mouth.

The device10is a computing device which operates as a mobile phone. However, further embodiments relate to other computing devices which do not include telephony as their major function.

FIG. 2is a schematic illustration showing the arrangement of the hardware components of the device10ofFIG. 1. The keypad14, display16, speaker18and microphone20shown inFIG. 1communicate with a system bus42. The bus42further communicates with an application processor24, a baseband processor26, a transmitter28, a receiver30and a battery40. Transmitter28and receiver30communicate with the antenna22. The bus42further communicates with a memory controller32which, in turn, communicates with volatile memory34and non-volatile memory36. The application processor24processes instructions related to various software modules and operating system software which run on the device10and which provide various functionality of the device10. The baseband processor26is concerned with the communication functions and to this end controls a telephony stack and communicates with the transmitter28and receiver30to establish communications by means of the antenna22. The various processing elements of the device10such as the application processor24and baseband processor26may be provided on a single processor.

Memory controller32controls the access to, and interaction with, volatile memory34and non-volatile memory36. In this manner the application processor24is able to communicate with the various hardware elements as well as the memory controller32and thereby control the operation of the various hardware elements according to software instructions stored on volatile memory34or non-volatile memory36.

Only a single bus, bus42, is illustrated inFIG. 2. It is to be realised that this bus may be replaced by two or more buses and that the topology ofFIG. 2would vary accordingly. Furthermore, known computing devices include hardware components additional to those illustrated inFIG. 2.

FIG. 3is a diagram illustrating various hardware and software components of the device10. The software operating on the device10can be categorised in various ways. Certain software operates to manage the resources provided by the various hardware components and to establish an operational environment in which other software executes. This software is known as the operating system of the device and is represented inFIG. 3by an Operating System (OS)50. The OS50interacts with the memory management unit32which, as previously described, communicates with volatile memory34and non-volatile memory36. The OS50further communicates with a plurality of applications44each of which may access the hardware components in a manner dictated by the OS50. The applications44are user applications, which may be started and terminated by the user.FIG. 3shows that among the contents of the non-volatile memory36is a list file38. In the current embodiment the list file is a text file, however, it is to be understood that in some other embodiments the list file could be of any other file type including but not limited to, a binary file or an XML file.

The OS50in this example also comprises a font server51. One of the roles of the font server is to load font files during a boot-up process of the device10, for example, after the device is switched on or following a reboot. In the present embodiment, the font server51loads each font file stored on the non-volatile memory36into the volatile memory34. This operation enables the font corresponding to the font file for use by software of the device10, such as, for example, the applications44.

The OS50communicates with the keypad14by means of device driver52, with speaker18by means of device driver54and with the display16by means of device driver56. Only some of the hardware components have been illustrated but, generally, the OS50controls the hardware resources of the device10through various device drivers. Furthermore, although the device drivers have been illustrated as separate to the OS50, it is possible for them to be incorporated into the OS50.

The software components ofFIG. 3are delineated by dashed area60. However, this distinction between software and hardware is not essential. Components depicted as software inFIG. 3may be rendered in hardware, and those depicted as hardware may, in certain circumstances, be rendered as software.

During operation of the device, software instructions stored in non-volatile memory36establish the OS50, the applications44and the device drivers52,54and56. Through the use of the various components illustrated inFIG. 2a user is able to utilise the device10according to the functionality provided by the various applications44. For example, a user uses the keypad14and/or the touch-screen display16to communicate with the OS50by means of device drivers52and56to cause one of the applications44to access data stored on non-volatile memory36by means of memory management unit32. The OS50causes the data supplied by memory management unit32to be processed by the applications44, typically running on the application processor24. The application processor24will return results from the data and instructions, generally utilising volatile memory34in the process. On further instructions from the application, the OS50will cause the results to be displayed to the user on display16by means of device driver56. It is to be realised that device drivers52,54and56are also software components originating from instructions stored on non-volatile memory36.

The illustration ofFIG. 3is presented merely by way of example; known devices may comprise more components than those shown. Implementations of embodiments are not dependent on the precise arrangement and configuration of components shown inFIGS. 1,2and3. Therefore other components with similar functionality may be substituted and further components added thereto, or illustrated components omitted therefrom, without affecting the operation of embodiments.

FIG. 4is a flow diagram illustrating a boot process98of the device10in the present example. The boot process98is activated after the device10has been turned on or rebooted, for example, by a human user of the device or a software application running thereon. At step100, a hardware reset is triggered by activation of a power button (not shown) of the device10, or the device10rebooting. The first software that is executed after this is a bootstrap program stored on the non-volatile memory36. On entry to the bootstrap, the execution environment is very primitive, and the bootstrap operates to provide a basic execution environment for a kernel process of the OS50. When this is complete, processing flows to step102. At step102, the kernel process is started. At this time the application processor24is running and an execution stack allows high-level software programming language code to be run, such as, for example, C++ code. However, there is still only a primitive memory environment and only one execution path. Once initialisation of the kernel process is complete, there is full management of the application processor24, the memories34and36, the battery40, and peripherals, such as the display16and the speaker18. Processing then flows to step104. At step104there is a functioning kernel however, the OS50has not yet provided the means to instantiate new processes, to read file-based data from the non-volatile memory36or to persist data in the volatile memory34or the non-volatile memory36. The process of establishing all of these services occurs in step104and once complete, processing flows to step106. At step106, all of the kernel and the file server services are fully initialised and ready for the rest of the OS to begin its boot process, using the system starter process. The system starter manages the initialisation of the rest of the OS system services in an ordered manner. The precise order in which the persistence, communications, multimedia, security, and other services are started is chosen to respect dependencies between services, and to start essential services first. Once enough of the system services are running, processing can flow to step108. At step108, the primary graphical user interface (GUI) of the OS can be started. In the case of the Symbian® OS, the primary GUI is the windows server. This now allows initialisation of other user interface services and the applications that make up the aspects of the OS that are most evident to a user of the device10.

FIG. 5illustrates in more detail the system starter process discussed above with reference to step106ofFIG. 4. The system starter process involves the initialisation of a number of OS system services200a-n. As mentioned above, the OS system services200a-nare initialised in an ordered manner which respects dependencies between different services and ensures that vital services are started first. The OS system services200a-ninclude but are not limited to, graphics, audio, security and communications services. The OS system service200brepresents the font server51of the OS50. The font server51represents part of a graphics service as it initialises the various fonts so that they can be used by the OS50and other software of the device10, such as the applications44. As can be seen inFIG. 5, once the font server51is initialised, the font server51loads a number of font files202a-nstored on the device10. In particular, the font server51reads a number of font files from the non-volatile memory36and then loads them into the volatile memory34. It is to be understood that this process can involve a step of decompression if the font files are stored on the non-volatile memory36in a compressed state. In the present embodiment, the font server51loads each font file stored on the non-volatile memory36. However, in other embodiments the font server51may only load a subset of all the font files stored on the non-volatile memory36. For example, the device may be able to identify which fonts are required in order to initialise the device10and only load font files corresponding to those identified fonts. Thereafter, if any unloaded fonts are required, the device10is further capable of loading the corresponding font files at that time.

In any case, during the system start-up step106(FIG. 4) of the boot up process98the font server51loads a number of font files. In the event that one of the font files is corrupt, the loading of that font file can cause the device10to crash during the boot-up process. This may force the device10to reboot. The next time the device10boots up the font server51may again try to load the same corrupted font file which may again cause the device10to crash. This operation can cause a continuous reboot cycle, wherein the device10keeps rebooting midway through booting up thereby rendering the device10unusable.

FIG. 6provides a flow diagram which illustrates the operation of the font server51to load all the font files stored on the non-volatile memory36. The operation ofFIG. 6avoids causing a continuous reboot cycle by using the list file38stored on the non-volatile memory36. Processing inFIG. 6starts at step300.

At step300, the device10is booted up. In the present case, a user of the device initiates the boot up by pressing a power button (not shown) of the device10. However, it is equally valid that a reboot causes the device to boot-up. Also, the re-boot could be initiated by a user of the device, an application of the device or the OS50. In any case, processing flows to step302, once the boot up process98reaches step106, i.e. system start up. At step302, the font server51is initialised. This causes processing to flow to step304, wherein the font server51checks for the presence of the list file38on the non-volatile memory36. In the present embodiment, if the list file38is stored on the non-volatile memory36it is located at a specific memory location. However, in other embodiments, the list file38may be stored anywhere on the non-volatile memory36and the font server51is capable of searching the non-volatile memory36in order to locate the file. In any case, if the list file38is present on the non-volatile memory36then processing flows to step306, which is discussed later. Alternatively, if no list file is present, processing flows to step308. If no list file is present then this generally indicates that this is the first time that the device10has been activated, or the device10has just been formatted.

At step308, the font server creates a new list file on the non-volatile memory36. The list file comprises two list portions, an invalid list portion (hereinafter, ‘invalid list’) and a valid list portion (hereinafter, ‘valid list’). Each list of the list file38is for storing one or a number of file representations. In the present embodiment each representation comprises a filename. However, in some other embodiments other representation types are used, such as, for example, a file location or a unique file identifier. Once the new list file has been created processing flows to step310. At step310, the font server51identifies a font file which is not listed in either list of the list file38. The lists of the list file38are currently blank and therefore there will be a number of font files which are present and not listed. Therefore, in step310the font server51selects one of them in accordance with its internal logic. In the present embodiment, the font server51will identify the first font file according to the order in which they are stored on the non-volatile memory36. However, in other embodiments other orders are equally valid, for example, the font server51could identify the first font file in alphabetical order. In any case, once the first font file has been identified processing flows to step312.

At step312, the font server51writes a representation of the identified font file into the invalid list of the list file38. As mentioned above, the representation comprises the name of the file. Next, at step314, the font server51tags the font file name as ‘new’, following which processing flows to step316. At step316, the font server51loads the font file and processing flows to step318. At step318, there are two possible outcomes to the file loading operation. Either the font file loads successfully, in which case processing flows to step320, or the font file does not load successfully, in which case processing flows to step322. Processing may flow to step322if the font file is corrupt. At step322, the device10crashes and reboots, after which processing flows back to step300. Returning to step300causes the font server operation to start again as defined by the flow diagram ofFIG. 6. Alternatively, if the file load at step316was successful, then processing flows from step318to step320. In practise, the first embodiment detects that the file load was successful if the device10is still operational following the file load.

At step320, the font server moves the font file name from the invalid list to the valid list, and removes the ‘new’ tag. Once the file name has been moved processing flows to step324, wherein the font server identifies if any other font files are present which are not yet listed. At present only one file name has been listed and therefore, it is highly likely that further font file names will be present. In this case, processing will flow around the above-described loop until processing returns to step324and there are no further font files which are present on the non-volatile memory36and which are not listed in the list file38. At this time, processing will flow from step324to step326wherein font file loading is complete. Once font file loading is complete the boot process98returns to step106ofFIG. 5wherein, the next system service is initialised. If all system services have been initialised then the boot process will flow to step108ofFIG. 5, as discussed above.

As mentioned briefly above, at step304, if a list file is present, processing flows to step306. It is noted that this will generally be the case unless the device is being booted up for the first time or following being formatted. At step306, the font server51loads all of the font files listed in the valid list, following which processing flows to step328. At step328, the font server51searches the list file38to identify any font file names in the invalid list which have been tagged ‘new’. In the event that no tagged font file names are found processing flows to step324, which was discussed above. Alternatively, if a tagged font file name is identified in step328, processing flows to step330. Processing will flow in this way if the last time the file server51operated, it attempted to load a font file which caused the device10to crash. In other words, processing flowed via step322back to step300, and then from step300, via steps302,304,306,328to step330. In this case, at step330, the new tag is removed and the font file name is left in the invalid list. Leaving the font file name in the invalid list in an untagged state shows that the font file should not be loaded as it will cause the device10to crash during boot-up. According to this operation, continuous rebooting cycles are avoided. Once the ‘new’ tag is removed at step330, processing flows to step324, which was discussed above.

According to the above described operation of the first embodiment of the invention, once each font file stored in the non-volatile memory has been loaded its file name appears in the list file38. In particular, the file name is written in the valid list if the font file loads successfully, or the invalid list if it does not load successfully. Once each font file name has been written in the list file38, the next time the device10is booted up, only those font files in the valid list are loaded by the font server51. Any font files in the invalid list are not loaded. Accordingly, continuous reboot cycles are avoided. In particular, a font file which causes the device to crash while booting is only permitted to be loaded once, thereafter its name is stored in the invalid list and it will not be loaded during boot-up again.

It is to be understood that the font server provides a means for identifying files to be loaded during a boot-up process of the device10. The font server also provides a means for determining if loading a file causes the device10to crash. The font server also provides a means for updating the list file38to indicate whether loading a particular file causes the device10to crash. The font server also provides a means for loading files during the boot-up process in dependence on the content of the list file38.

In the event a new font file is loaded onto the non-volatile memory36, during the next boot up following the addition of the new font file, the font server51detects the presence of the new file at step324and adds the name of the new file to the invalid list of the list file38at step312. If the new file loads successfully its name is moved to the valid list at step322. Alternatively, if the file does not load successfully then its name remains in the invalid list. It is noted that a new font file can be added to the device10in a number of ways. For example, the user could install a new application onto the device10which could include one or a number of new font files. Additionally or alternatively, an automatic software update may add one or number of new font files to the device10.

In the event that an existing font file is modified, the font server51detects this and ensures that the file name is re-inserted into the invalid list and tagged as new. If the unmodified version of the file was in the valid list then this entry is removed at the same time. Accordingly, the modified file will be treated as a new file again and will only be moved to the valid list if it does not cause the device10to crash when the file is loaded.

It is an advantage of the first embodiment that the number of times a file is written to in order to protect the device10from continuous reboot cycles is minimised. Accordingly, any boot-up time increase resulting from the above-described operation of the font server is also minimised. In turn, this means that boot-up time is not prolonged unnecessarily which would degrade the user experience. In particular, the list file38is only written to at the beginning to position the file name of each font file in the correct list. Once all the font file names are in the correct list, the font server only reads from the list file38to establish which files to load. Stated differently, the font server does not have to write to the list file once the file name of each font file on the device10is positioned in the correct list. Accordingly, the font server can automatically detect invalid files without having to perform any file writes.

In the first embodiment, the non-volatile memory is a flash memory drive. A further advantage of the operation of the first embodiment is that excessive wear on the flash drive is reduced. In particular, excessive wear can occur if repeated writing operations are performed on the flash drive. As the operation of the first embodiment minimises the number of file writes necessary to detect invalid files, the first embodiment also prolongs the life of the flash memory.

It is an advantage of the first embodiment that the list file38is created and automatically updated by the font server51. Moreover, it is not the responsibility of a user of the device to maintain the list file38. This is an advantage as to maintain the list file38the user would have to have an intimate knowledge of the font files present on the device10. According to the first embodiment, the user can simply install new font files onto the device and the font server will automatically detect invalid files and automatically protect the device10from continuous reboot cycling.

In the first embodiment, the list file38comprised two lists, an invalid list and a valid list. However, in other embodiments, it would be equally valid for the font server to create and manage two list files, wherein one file contains the valid list and the other contains the invalid list. The list file may be a text file, a binary file, an XML file, or of any other file type.

In the first embodiment, when the font server inserts a new font file name into the list file the font server tags that file name as new. The purpose of this being that the font server knows which file to move to the valid list in the event that a file load is successful. In other embodiments, the font server does not need to tag file names. However, in such embodiments the font server has to remember the file name of the current file being tested so that it knows which file name to move to the valid list if a loading test is passed (step318).

The operation ofFIG. 6can be modified to form a second embodiment of the invention.FIG. 7provides a flow diagram of the operation of the second embodiment. The following describes the aspects ofFIG. 7which are different fromFIG. 6. In particular, new steps400and402are inserted in between steps314and316.

At step314, a new font file name which has been inserted into the invalid list is tagged as ‘new’. InFIG. 7, once the file name has been tagged, processing flows to new step400. At step400, the font server51verifies the new font file. File verification performs one or a number of tests on the file before the file is loaded. The purpose of each verification test is to determine is the file will cause the device to crash if it is loaded. Once the file verification test has been performed processing flows to new step402, wherein the outcome of the test is considered. In the second embodiment, the font server checks the font file size to confirm it is greater than zero. In the event that the file size is greater than zero, the font server assumes that the font file is valid and will not crash the device10if it is loaded. Accordingly, processing flows from step402to step316, which was discussed above with reference to the first embodiment and FIG.6. Alternatively, if the file size is zero, the font server assumes that the font file is corrupt and will crash the device10if it is loaded. Accordingly, processing flows from step402to step330, which was discussed above with reference to the first embodiment.

An advantage of the second embodiment is that the font server can identify, in certain cases, a font file which will crash the device10if it is loaded. Accordingly, upon identifying such a font file, the font server can avoid loading the file. Further, the font server can de-tag the file name and leave it in the invalid list so that the file is not loaded during boot-up. Therefore, the second embodiment avoids having to go through the process of loading the corrupt file, crashing the device and re-booting device. According to this operation, the second embodiment can reduce the boot-up time and thereby improve the user experience.

In the second embodiment the font server performed a single verification test. In other embodiments of the invention any number of verification tests may be performed. Furthermore, a different verification test may be performed. For example, the font server could determine if the memory tables that the font file points to are correct, that the font file contains the correct syntax, or that the font file contains the correct data type.

In addition, the advantages and alternative features stated in connection with the first embodiment apply equally to the second embodiment.

FIG. 8is a diagram illustrating various hardware and software components of the device10when it is arranged according to a third embodiment of the invention. The following describes the differences between the components ofFIG. 8and the components ofFIG. 3.

InFIG. 8, the OS50comprises a verification server500. A function of the verification server500is to automatically detect and prevent the loading of invalid (i.e. corrupt) files during boot-up of the device10. Accordingly, the verification server500functions to automatically prevent continuous reboot cycles.

FIG. 9illustrates in more detail the system starter process discussed above with reference to step106ofFIG. 4, when the device10is arranged according to the third embodiment. As mentioned above, the system starter process involves the initialisation of a number of OS system services200a-n.FIG. 9shows that each of the OS system services200a-ncommunicates with the verification server500. In particular, each of the OS system services200a-ncommunicates with the verification server500when they need to load a file during boot-up. The file can relate to any OS system service and is not limited to graphics services or fonts. For example, the file could relate to files such as device drivers, or services such as, security, communication or audio services. When the service200a-ncommunicates with the verification server500it sends a verification request which specifies a representation of a file that needs to be loaded. In the present embodiment the file representation comprises the file name. However, in some other embodiments a different representation could be used, such as, for example, a file location or a unique file identifier. On receiving the verification request, the verification server500identifies whether or not the file is valid. If the file is valid, the verification server500permits the file to be loaded. On the other hand, if the file is invalid, the verification server500prevents the file from being loaded. According to this operation, the verification server500operates to automatically avoid continuous reboot cycling.

FIG. 10provides a flow diagram which defines the operation of the third embodiment of the invention. Where step numbers inFIG. 10are the same as those inFIGS. 6 and 7, those steps inFIG. 10relate to the same operations as those defined in relation toFIGS. 6 and 7. Processing inFIG. 10starts at step300.

At step300, the device10boots-up. In the present case, a user of the device initiates the boot up by pressing a power button (not shown) of the device10. However, it is equally valid that a reboot causes the device to boot-up. Also, the re-boot could be initiated by a user of the device, or an application of the device, such as, the OS50. In any case, processing flows to step502, once the boot up process98reaches step106, i.e. system start up.

At step502, the verification server500is initialised. This causes processing to flow to step304, wherein the verification server500checks for the presence of the list file38on the non-volatile memory36. In the present embodiment, if the list file38is stored on the non-volatile memory36it is located at a specific memory location. However, in other embodiments, the list file38may be stored anywhere on the non-volatile memory36and the verification server500is capable of searching the non-volatile memory36in order to locate it. In any case, if the list file38is present on the non-volatile memory36then processing flows to step504, which is discussed later. Alternatively, if no list file is present, processing flows to step308. If no list file is present then this generally indicates that this is the first time that the device10has been activated, or the device10has just been formatted.

At step308, the verification server500creates a new list file on the non-volatile memory36. The list file comprises two list portions, an invalid list portion and a valid list portion. Each list of the list file38is for storing one or a number of file representations. In the present embodiment, the file representations comprise file names. Once the new list file has been created, processing flows to step504.

At step504, the verification server500waits until a verification request is received from one of the OS system services200a-n. When a verification request is received processing flows from step504to step506. It is noted that each verification request received by the verification server500comprises a representation of a file. In the third embodiment, the representation comprises the file name. However, in some other embodiments it is equally valid that other file representations are used. For example, in some embodiments a file location or a unique file identifier is used. Moreover, the verification request is a request from an OS system service to confirm if the file who's file name accompanies the request is valid. At step506, the verification server500identifies whether the file name passed with the request is listed in the valid list of the list file38. In the event that it is, processing flows from step506to step508, wherein the verification server500responds to the OS system service which sent the verification request. In particular, the verification server500confirms that the OS system service can safely load the file without crashing the device10.

Alternatively, if at step506the file name is not in the valid list, processing flows to step510. At step510, the verification server500determines if the file name is in the invalid list. If it is then processing flows to step512, else processing flows to step312. At step512, the verification server500checks to see if the file name is tagged as new in the invalid list. This will be the case if the last time the verification server500was operated it loaded the file and that crashed the device10. In this case, the new tag is removed from the file name at step330, following which processing flows to step514. Alternatively, if the file name is not tagged then processing flows from step512directly to step514. At step514, the verification server500responds to the OS system service which made the initial verification request at step504and tells that OS system service not to load the file.

As mentioned briefly above, processing flows from step510to step312if the file name is not in either the valid or invalid list of the list file38. This will be the case if the file represented by the file name is a new file. At step312, the file name is inserted into the invalid list of the list file38, following which processing flows to step314. At step314, the verification server500tags the file name just inserted, following which processing flows to step400. At step400, the verification server500verifies the file. In the present embodiment, the verification test comprises checking that the file size is greater than zero. In the event that the file size is zero, the verification test fails and processing flows from step400to step402and then step330, which is discussed above. Alternatively, if the file size is greater than zero, the verification test is passed at step402and processing flows to step316. At step316the file is loaded and processing flows to step318. At step318, the result of the file load is considered. If the file loaded successfully at step316, then processing flows to step320. In practise, the third embodiment detects that the file load was successful if the device10is still operational following the file load. At step320, the file name is de-tagged and moved from the invalid list to the valid list. Processing then flows to step516, wherein the verification server500responds to the OS system service which made the verification request at step504and confirms that the file has been loaded successfully. Alternatively, if at step318the file load is not successful then the device crashes and processing flows to step322, following which processing returns to step300when the device reboots.

According to the above described operation, the verification server500can be used to verify each file loaded by the OS system services200a-n. Alternatively, the verification server500can be used to verify only a subset of the files loaded by the OS system services200a-n. In any case, if a file is corrupt and causes the device to crash then that file enters the invalid list. If the file is not corrupt then the OS system service200a-nis either informed that it can load the file or informed that the verification server has already loaded the file. In subsequent boot-ups the verification server will prevent OS system services from loading files in the invalid list and will permit OS system services to load files in the valid list. According to this operation, continuous reboot cycling is automatically prevented.

It is to be understood that the verification server provides a means for identifying files to be loaded during a boot-up process of the device10. The verification server also provides a means for determining if loading a file causes the device10to crash. The verification server also provides a means for updating the list file38to indicate whether loading a particular file causes the device10to crash. The verification server also provides a means for loading files during the boot-up process in dependence on the content of the list file38.

In the event that an existing file is modified, the verification server detects this and ensures that the file name is re-inserted into the invalid list and tagged as new. If the unmodified version of the file was in the valid list then this entry is removed at the same time. Accordingly, the modified file is treated as a new file again and will only be moved to the valid list if it does not cause the device10to crash when the file is loaded.

It is an advantage of the third embodiment that any OS system service can use the verification server500to automatically determine if a file can be loaded or not. Accordingly, any file which needs to be loaded during boot-up can be run through the verification server. Additionally, all files which need to be loaded during boot-up can be run through the verification server. Stated differently, continuous reboot cycling resulting from any file loaded during boot-up is automatically prevented. Either a corrupt file is detected at verification step318, or the corrupt file is loaded once, detected following a reboot at step312, and never loaded again.

It is an advantage of the third embodiment that the number of times a file is written to in order to protect the device10from continuous reboot cycles is minimised. Accordingly, any boot-up time increase resulting from the above-described operation of the verification server is also minimised. In turn, this means that boot-up time is not prolonged unnecessarily which would degrade the user experience. In particular, the list file38is only written to at the beginning to position the name of each file in the correct list. Once all the file names are in the correct list, the verification server only reads from the list file38to establish which files can be loaded. Stated differently, the verification server does not have to write to the list file once the name of each file to be loaded during boot-up is positioned in the correct list. Accordingly, the verification server can automatically detect invalid files without having to perform any file writes.

In the third embodiment the non-volatile memory is a flash memory drive. A further advantage of the operation of the third embodiment is that excessive wear on the flash drive is reduced. In particular, excessive wear can occur if repeated writing operations are performed on the flash drive. As the operation of the third embodiment minimises the number of file writes necessary to automatically detect invalid files, the first embodiment also prolongs the life of the flash memory.

In the third embodiment, if the verification server identifies that a file is invalid (i.e. corrupt) it informs the OS system service not to load the file. In some other embodiments, the verification server could additionally or alternatively load a default file which corresponds to the invalid file. In particular, the loading of the file may be essential for the device10to enter an operational state. If this is the case, then simply instructing the corresponding OS system service not to load the file will prevent the device from entering an operational state. Accordingly, the verification server could store a number of old but valid copies of essential files so that in the event the current version is corrupt, the verification server can load the valid old version of the file. According to this operation, the device will then be able to enter an operational state. In some embodiments, the device could automatically detect that a current version of a file is invalid and automatically instruct a user of the device to obtain a current version of the file which is valid, for example, via an appropriate message on the display16.

It is an advantage of the third embodiment that the list file38is created and updated automatically by the verification server. Moreover, it is not the responsibility of a user of the device to maintain the list file38. This is an advantage as to maintain the list file38the user would require an intimate knowledge of the files which were loaded during boot-up. According to the third embodiment, the user can simply install new files onto the device and the verification server will automatically protect the device10from continuous reboot cycling if those files are loaded during boot-up and cause the device to crash.

In the third embodiment, the list file38comprised two lists, an invalid list and a valid list. However, in other embodiments, it would be equally valid for the font server to create and manage two list files, wherein one file contained the valid list and the other contained the invalid list. The list file could be a text file, a binary file, an XML file, or a file of any other file type.

In the third embodiment, when the verification server inserts a new file name into the list file the verification server tags that file name as new. The purpose of this is so that the verification server knows which file to move from the invalid list to the valid list in the event that a file load test is successful (step318). In other embodiments, the verification server does not tag file names. However, in such embodiments the verification server needs to remember the file name of the current file being tested so that it knows which file name to move to the valid list if the file passes the loading test.

The third embodiment included the verification stage represented by steps400and402. However, it is to be understood that in some other embodiments steps400and402could be omitted. Such embodiments would therefore correspond with the first embodiment described above.

The first, second and third embodiments have been discussed with reference to loading files during the system start-up stage (step106) of the boot-up process98. However, it is to be understood that some other embodiments of the invention could relate to different boot-up processes. Further, some other embodiments could relate to file loading which occurs at a different stage in the boot-up process. For example, some other embodiments may relate to file loading during the GUI and other application loading stage (i.e. step108) ofFIG. 4.

The first, second and third embodiments have been discussed above with reference to files which either load successfully or crash the device. It is to be understood that some other embodiments could also operate with files which are corrupt but which do not crash the device. In such cases, the new tag relating to the file would be removed and the file name would remain in the invalid list. Alternatively, if file tagging was not performed then the file name would just be left in the invalid list.

In the first, second and third embodiments discussed above the list file38lists file names. However, it is to be understood that in other embodiments of the invention file representations other than names are used. For example, the list file38could list file locations or unique file identifiers. Alternatively, a code could be generated for each file and that code could be used as the representation stored in the list file. Furthermore, in the third embodiment the verification server has been discussed above with reference to receiving a single file representation with each verification request. In some other embodiments more than one file representation could be passed with a verification request. Any number of file representations could be passed with some verification requests.

Finally, various additions and modifications may be made to the above described embodiments to provide further embodiments, apparent to the intended reader being a person skilled in the art, any and all of which are intended to fall within the scope of the appended claims.