HK1134354B - Methods and systems for searching and storing data - Google Patents

Description

Method and system for searching and storing data

This application is a divisional application of the inventive patent application having an application date of 24/6/2005, application number 200580012889.4, entitled "method and system for indexing files and adding related metadata to an index and metadata database".

This application is a co-pending application to U.S. patent application serial No. 10/877584, filed on 25/6/2004. This application also claims priority from pending U.S. patent application No. 60/643087, filed on 7.1.2005, which is hereby incorporated by reference in its entirety; this application claims benefit of provisional filing date under 35u.s.c. § 119 (e). The present application claims benefit from an earlier filing date in accordance with 35u.s.c. § 120 herein.

Background

Modern data processing systems, such as general purpose computer systems, allow users of the systems to generate large numbers of different types of data files. By way of example, a typical user of a data processing system may generate a text file using a Word processing program, such as Microsoft corporation's Word, and an image file using an image processing program, such as Adobe corporation's Photoshop. Numerous other types of files can be generated or changed, edited, and used by one or more users of a typical data processing system. The large number of different types of files that are generated or changed presents a challenge to typical users seeking to generate a particular file.

Modern data processing systems typically include a file management system that allows users to place files in directories or subdirectories (e.g., folders) and allows users to name files. In addition, the file management system typically allows a user to find files by searching for file names, or creation dates, or modification dates, or file types. One example of such a file management system is the Finder program used on Macintosh computers, manufactured by apple computer, Inc. of Coopertino, Calif. Another example of a file management system program is the Windows Explorer program used on the Windows operating system, manufactured by Microsoft corporation of Redmond, Washington. Both the Finder program and the Windows Explorer program include a find command that allows a user to find a file with a variety of criteria, including file name or date of creation or date of modification or file type. However, regardless of the type of file, the query capability searches each file for the same information. Thus, for example, the search data for a Microsoft word file is the same as the search data for an Adobe Photoshop file, and typically includes a file name, file type, date generated, date last modified, file size, and other specific parameters, which may be maintained by the file management system.

Existing specific applications allow users to maintain data about specific files. This data about a particular file may be considered metadata because the data is data about other data. Metadata for a particular file includes information about the author of the file, a summary of the document, and a variety of other types of information. Programs such as microsoft word may automatically generate some of this data when the user generates a file and the user adds additional data or edits the data by selecting "property sheet" in the menu selector of microsoft word. The property sheet of Microsoft Word allows a user to generate metadata for a particular file or document. However, in existing systems, a user cannot search for metadata in a large number of different applications using one search request from the user. In addition, existing systems are capable of performing searches for data files, but the search also does not include searching for metadata in the file.

Existing systems perform indexing operations in response to a setting, a predetermined time (e.g., set by a user), or in response to an immediate user request to begin an indexing operation.

Disclosure of Invention

Methods of managing data in a data processing system and a data management system are described herein.

According to one aspect of the invention described herein, an exemplary method includes receiving, by an indexing software component, a notification that an existing file on a data storage device has been modified or that a new file is created on the data storage device, and in response to the notification, performing an indexing operation on the existing file or the new file. Preferably, the notification includes an identifier identifying the existing file (or the new file). In another embodiment, the notification is not based solely on time or user input. In response to detecting user behavior, the indexing operation may be delayed or stalled or have a reduced processing priority. The notification may be entered into a queue for the index operation and the queue may be saved on non-volatile memory. Changes to the queue are written to the transaction log of the notification.

According to another aspect of the invention described herein, an exemplary method of processing data includes determining whether a file is to be indexed into an index database or metadata is to be added into a metadata database, adding an entry representing the file to a list of index operations (or metadata operations), and saving the list on a non-volatile memory. The method may further include removing the entry from the list after indexing the file (or after the metadata operation) to generate an updated list, and saving the updated list on the non-volatile memory. The method also includes entering the change into a list of transaction logs. The notification may come from an operating system component that provides a notification in response to storing data with respect to the file on a storage device, such as non-volatile memory.

In accordance with another aspect of the present invention, an exemplary method includes monitoring user usage of a data processing system and automatically adjusting indexing operations and metadata processing operations in response to the monitoring. The index operation is a typical operation that includes indexing a file to generate an entry to add to an index database, and typically, a metadata operation involves adding metadata to a metadata database for the file. The indexing operation or the metadata operation may be automatically performed by the data processing system in response to a notification, which may be communicated from the operating system component to the indexing software component or the metadata software component. Typically, fewer indexing operations are performed over an increased period of time as the user's use of the data processing system increases. The automatic adjustment of the indexing operations (or metadata operations) involves changing the processing priority of the indexing software (or metadata software) relative to other software executed by the data processing system (e.g., the "Nice" command in Unix). The priority of the indexing operation may be changed or the priority of the input/output (I/O) operation may be changed or the priority of both operations may be changed.

According to another aspect of the invention described herein, an exemplary method of processing data includes determining a time of a last update of an index database, wherein the index database contains content from files stored on a storage device, and determining whether a file stored on the storage device was modified or created after the time of the last update of the index database, and updating the index database for files modified or created after the time of the last update of the index database. This update may occur automatically without user intervention. A similar method may be performed to determine whether to update the metadata repository.

According to another aspect of the invention described herein, an exemplary method of processing data includes assembling a storage device and automatically determining whether to index one or more files on the storage device in response to the assembling. Determining whether to index the one or more files includes comparing a last usage time or a last closing time of the index database with an unloading time or a last writing time of the storage device, and may also include comparing an earliest usage time or a last opening time of the index database with an assembly time or an earliest writing time of the storage device after the unloading time. Typically, the index database is stored on an assembled storage device. A similar method may be performed to determine whether to automatically update the metadata repository in response to an assembly of the storage device.

According to another aspect of the invention described herein, an exemplary method includes assembling a storage device and evaluating, after assembly, whether to automatically index one or more files on the storage device by evaluating whether a file on the storage device was modified or whether a new file was added since a last time an index database of files on the storage device was closed or written.

According to another aspect of the invention described herein, an exemplary method of processing data includes assembling a storage device and automatically responding to the assembling to determine whether to index one or more files on the storage device without examining records for each file indexed in an index database.

The foregoing exemplary method may also be performed to determine whether metadata from a new file or a modified file needs to be automatically added (e.g., imported) into the metadata repository. By way of example, one exemplary method according to this aspect of the invention includes assembling a storage device and automatically determining whether to import metadata from one or more files on the storage device in response to the assembling.

Another exemplary method of processing data includes determining whether metadata from a file is imported or added to a metadata repository; adding an entry representing the file to a list of import or add metadata, the import or add metadata being imported or added from the file to a metadata repository; and saving the list to non-volatile memory. Changes to the list may be entered into the transaction log and entries of the list may be removed from the list after the metadata for the file is added to the metadata repository.

In accordance with another aspect of the invention described herein, an exemplary method includes monitoring usage by a user of a data processing system, and automatically adjusting an import operation or an add operation that adds metadata from a file to a metadata repository in response to the monitoring. Typically, a metadata repository contains metadata from many different types of files, such that the information type of the metadata of a first type of file is different from the information type of the metadata of a second type of file.

Other aspects of the invention include various data processing systems that perform these methods and machine-readable media that perform one or more of the various methods described herein.

Drawings

The present invention will be illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

FIG. 1 is an exemplary embodiment of a data processing system, which may be a general purpose computer system and which may operate in accordance with any of the various methods described herein.

FIG. 2 shows a general example of an exemplary method according to an aspect of the present invention.

Fig. 3A shows an example of the contents of a specific type of metadata of a specific type of file.

Fig. 3B shows another example of the contents of a specific type of metadata of another specific type of file.

Fig. 4 shows an example of an architecture for metadata management according to an exemplary embodiment of the present invention.

Fig. 5 is a flow chart illustrating another exemplary method of the present invention.

Fig. 6 is a storage format example showing an expanded file format using metadata according to an exemplary embodiment of the present invention.

7A-7E illustrate the order in which the graphical user interfaces provided by the illustrative embodiments are used to implement searches for metadata and/or other data in a data processing system.

Fig. 8A and 8B show two format examples of displaying search results according to an exemplary embodiment of the present invention.

Fig. 9 shows another example of a user interface of the present invention.

Fig. 10 shows another example of a user interface of the present invention.

FIGS. 11A-11D illustrate, in sequence, another exemplary user interface in the present invention.

Fig. 12A-12D show alternative embodiments of the user interface of the present invention.

Fig. 13A and 13B further illustrate an alternative embodiment of a user interface in the present invention.

14A, 14B, 14C and 14D further illustrate alternative embodiments of the user interface of the present invention.

15A, 15B, 15C and 15D show another alternative embodiment of the user interface in the present invention.

FIGS. 16A and 16B illustrate certain aspects of an embodiment of a user interface in the present invention.

FIG. 17 illustrates an aspect of a particular embodiment of a user interface in the present invention.

FIGS. 18A and 18B illustrate another aspect of a particular embodiment of a user interface in the present invention.

19A, 19B, 19C, 19D and 19E further illustrate exemplary embodiments of user interfaces in the present invention.

Fig. 20 is a flow chart illustrating another exemplary method of the present invention.

FIG. 21 is a flow chart illustrating another exemplary method of the present invention.

22A, 22B, 22C, and 22D illustrate the display of a display device on which one embodiment of the method shown in FIG. 21 is performed.

FIG. 23 is a flow chart illustrating an exemplary method in accordance with certain aspects of the invention described herein.

FIG. 24 is a flow chart illustrating an exemplary method in which indexing is performed in response to a notification about a file.

FIG. 25 is a flow chart illustrating another exemplary method in accordance with certain aspects of the invention.

FIG. 26 is a flow chart illustrating an exemplary method of determining whether to update a database.

FIG. 27 is a flow chart setting forth an exemplary method of determining whether to update a database, such as an index database or a metadata database.

FIG. 28 is a flow chart setting forth an exemplary method of determining whether to update a database, such as an index database or a metadata database.

Detailed Description

The present invention will be described with reference to numerous details below and the accompanying drawings will illustrate the invention. The following description and drawings are illustrative of the invention and are not to be construed as limiting the invention. Numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail.

The description includes an illustration of copyrighted material such as graphical user interface images. Copyright holders herein, including the agents of the present invention, reserve rights to such material, including copyrights. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office files or records, but otherwise reserves all copyright rights whatsoever. Apple Inc. copyright owned, 2004.

FIG. 1 shows an example of a typical computer system that may be used by the present invention. It is noted that FIG. 1 illustrates various components of a computer system and is not meant to represent any particular architecture or manner of connecting the components as such details are not germane to the present invention. It will also be appreciated that network computers and other data processing systems which have fewer components or perhaps more components may also be used with the present invention. The computer system shown in fig. 1 may be, for example, a Macintosh computer manufactured by apple computer, inc.

As shown in FIG. 1, computer system 101 is one form of data processing system that includes a bus 102, bus and microprocessor 103 and ROM (read Only memory) 107 and volatile RAM105 and non-volatile memory 106. The microprocessor 103 may be a G3 or G4 microprocessor manufactured by motorola, inc, or one or more G5 microprocessors manufactured by IBM. The bus 102 connects the various components together and also connects the components 103, 107, 105, and 106 to a display controller and display device 104 and peripheral devices such as input/output (I/O) devices which may be mice, keyboards, modems, network interfaces, printers, and other devices known in the art. Typically, the input/output devices 109 are connected to the system through input/output controllers 108. Typically, the volatile RAM (random access memory) 105 is implemented by dynamic RAM (dram), which requires power continuously to update or maintain the data in the memory. Typically, mass storage 106 may also be a magnetic hard drive or a magnetic optical drive or an optical drive or a DVD RAM or other type of memory system that retains data (e.g., large amounts of data) even after the system is powered down. Typically, although not necessarily, mass storage 106 will also be random access memory. Although FIG. 1 shows that the mass storage 106 is a local device connected directly to the other components of the data processing system, it should be understood that the present invention may utilize non-volatile storage that is located remotely from the system, such as a network storage device that is connected to the data processing system through a network interface, such as a modem or Ethernet interface. Bus 102 may include one or more buses connected to each other through various bridges, controllers and/or adapters as is well known in the art. In an embodiment I/O controller 108 includes a USB (Universal Serial bus) adapter for controlling USB peripheral devices and an IEEE1394 controller for IEEE1394 peripheral devices.

It will be apparent from this description that aspects of the invention may be, and at least partially are, implemented in software. That is, the techniques may be implemented in a computer system or other data processing system in response to a processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM107, RAM105, mass storage 106, or a remote storage device. In various embodiments, hardwired circuitry may be used in combination with software instructions to implement the present invention. As such, the techniques are not limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system. In addition, throughout this description, various functions and operations are described as being performed by or caused by software code to simplify this description. However, those skilled in the art will appreciate that the expression means that the function is performed by a processor, such as the microprocessor 103, executing code.

Metadata acquisition and application in multiple applications

Figure 2 shows a general example of an embodiment of the invention. In this example, the captured metadata is useful to a search device, e.g., a component of an operating system, that allows all metadata to be searched simultaneously in all applications that capture the metadata (and optionally in all non-metadata in the data file). The method of FIG. 2 may begin at operation 201, where metadata is captured from a number of different applications. The captured metadata is then used in operation 203 by a search device, such as file management system software for searching. In step 205, the search device allows a search of metadata to be conducted among all applications having the captured metadata. In step 207, the method also provides a user interface of the search engine and search results obtained by the search engine. There are a large number of possible implementations of the method of fig. 2. By way of example, FIG. 5 illustrates a specific implementation of one exemplary embodiment of the method of FIG. 2. Alternative implementations may also be used. For example, in an alternative implementation, the metadata is provided by each application program into a central source that stores metadata used by the search device, and the central source is managed by an operating system component, which may be metadata processing software. The user interface provided in operation 207 may be in a number of different formats, including some examples described below as well as conventional existing user interfaces. The metadata is stored in a database, which may be in any of a variety of formats, including a B-tree format, or an expanded file format according to one embodiment of the present invention, as described below.

The method of fig. 2 may be implemented by a program that does not store or provide metadata. In this case, a portion of the operating system implements functionality to capture metadata from a large number of different programs, although the programs are not designed to provide or capture metadata. For programs that allow a user to generate metadata for a particular document, certain embodiments of the invention may allow captured metadata to be output back to a data file of an application that maintains metadata about the data file.

The method of FIG. 2 allows information regarding a variety of different files produced by a variety of different applications to be accessible by a system level search device in a manner similar to prior art versions of Finder or Windows Explorer that search for file names, production dates, etc. in a large number of different applications. As such, metadata for a plurality of different files generated by a plurality of different applications may be accessed by an extension to the operating system, and an example of such an extension is shown in FIG. 4 as metadata processing software that interacts with other components of the system and is described in detail below.

Fig. 3A and 3B show two different metadata formats for two different data file types. Note that there may be no overlap in all fields; in other words, the fields of one type of metadata are completely different from the fields of another type of metadata. The metadata format 301 may be used for image files such as JPEG image files. The metadata may include information such as image width, image length, image color space, number of bits per pixel, ISO settings, flash settings, F/stop of the camera, brand of camera being photographed, user added keyboard, and other fields such as fields that may uniquely identify a particular document, which identification is permanent in the modification of the document. The metadata format 331 shown in fig. 3B may be used for music files such as MP3 music files. The data in this metadata format may include a musician identification, music genre, album name, song name in an album or song name of a particular file, song play time or song play time of a particular song, and other fields such as a persistent file ID identifying the particular MP3 file in which the metadata was captured. Other field types may also be used. The following chart shows an example of a number of fields that may be used in the metadata for various types of files.

One particular field that is useful in various metadata types may be to include an insertion identifier or other software element that may be used to capture metadata from a data file and/or output the metadata back to the generating application.

Various different software architectures may be used to implement the functions and operations described herein. The following discussion provides one example of this architecture, but it should be appreciated that alternative architectures may also be used to achieve the same or similar results. The software architecture shown in fig. 4 is an example based on the Macintosh operating system. Architecture 400 includes metadata processing software 401 and an Operating System (OS) kernel 403 that operates in conjunction with metadata processing software 401 for a notification mechanism described below. Metadata processing software 401 is also connected to other software programs such as file system graphical user interface software 405 (which may be a Finder), email software 407, and other applications 409. These applications are connected to the metadata processing software 401 through a client application program interface 411, which provides a method of transferring data and commands between the metadata processing software 401 and the software 405, 407, and 409. The commands and data may include user-specified search parameters and commands from the user to perform the search, which are communicated to metadata processing software 401 via interface 411. The metadata processing software 401 is also connected to a set of inputs 413 which extract data from various applications. In particular, in one exemplary embodiment, a text input is used to extract text and other information from a Word processing or text processing file, such as Microsoft Word or the like. The extracted information is metadata of the specific file. Other types of inputs extract metadata from other types of files, such as image files or music files. In this particular embodiment, the particular input is selected based on the type of file generated and modified by the application. For example, if the data file is created by PhotoShop, an image input for PhotoShop is used to input metadata from the PhotoShop data file to the metadata database 415 via the metadata processing software 401. On the other hand, if the data file is a word processing document, an input designed to extract metadata from the word processing data document is accessed to extract the metadata from the word processing data file and place it in metadata repository 415 via metadata processing software 401. Typically, many different inputs are required to handle many different applications that are applied to a typical computer system. Preferably, the input 413 includes a number of outputs that are capable of outputting extracted metadata for a particular type of data file back to a property table or other data component maintained by a particular application. For example, an application program may maintain some metadata for each data file created by the program, but the metadata is only a subset of the metadata extracted from the output of that type of data file. In this case, the output may output additional metadata back or simply insert the metadata into the blank fields of the metadata maintained by the application.

Software architecture 400 also includes a file system directory 417 of metadata. The file system directory tracks the relationship between data files and their metadata, and tracks the location of metadata objects created at each input (e.g., metadata files corresponding to data files in which they were extracted). In one exemplary embodiment, the metadata repository is maintained in an expanded file format as described below, and the file system directory 417 maintains the expanded file format. One advantage of expanding the file format is that data is placed on the storage device as strings of data, regardless of the fields from one metadata file (corresponding to a particular data file) to another metadata file (corresponding to another data file). This arrangement of data often results in faster retrieval of information from the metadata repository 415.

The software architecture 400 of fig. 4 also includes content-based lookup software 419 operatively connected to the database 421 that includes the index of the file. The file index represents at least a subset of the data files in a storage device, such as the main hard drive of a computer system, and may include all the data files in a particular storage device(s). The index of files may be a conventional indexed representation of the content of each document. Content-based lookup software 419 looks up the vocabulary in the content to see if the particular vocabulary is present in any indexed data file, by looking up database 421. The functionality of the content-based lookup software has utility in metadata processing software 401, which has the benefit to the user that the user can simultaneously retrieve the file index (for the content in the file) in database 421 and the metadata for the various data files to be retrieved. The software architecture shown in fig. 4 may be used to perform the method shown in fig. 5, or an alternative software architecture may be used to perform the method shown in fig. 5.

The method of FIG. 5 begins in operation 501 in which a notification of a file change is received. The notification comes from the operating system kernel 403, which notifies the metadata processing software 401 that the file has changed. The notification may come from a listening software element that monitors for new or changed files and deletion of files. The change may be the creation of a new file or the change of an existing file or the deletion of an existing file. Deletion of an existing file causes a special case of the processing method in fig. 5 and is not shown in fig. 5. In the case of deletion, the metadata processing software 401 deletes the metadata file in the metadata repository 415, which corresponds to the deleted file, by using the file system directory 417. Other types of operations, such as creation of a new file or change of an existing file, cause a process from operation 501 to operation 503 in which the type of file that is a notification target is determined. The file may be an Acrobat PDF file or an RTF word processing file or a JPEG image file, etc. In any case, the file type is determined in operation 503. It may be through receipt of a file type with a notification from the operating system kernel 403, or the metadata processing software 401 may require identification of a file type from the file system graphical user interface software 405 or similar software that maintains information for the data file, such as the generating application or parent application of the data file. It should be appreciated that in one exemplary embodiment, the file system graphical user interface software 405 is a Finder program running on a Macintosh operating system. In an alternative embodiment, the file system graphical user interface system may be Windows Explorer running on Microsoft corporation's Windows operating system. After the file type is determined at operation 503, appropriate capture software (e.g., one of the inputs 413) is initiated to determine the file type. The input may be an application-specific plug-in that generates a file type about which notifications are received in operation 501. Once launched, the import or capture software enters the appropriate metadata (for the particular file type) into a metadata repository, such as metadata repository 415 shown in operation 507. Next, in operation 509, the metadata is stored in a database. In an exemplary embodiment, it may be stored in the form of an expanded file. Next, in operation 511, metadata processing software 401 receives the input of the search parameters and performs a retrieval of the metadata repository (and preferably also causes a retrieval of a non-metadata source such as file index 421) and causes the retrieval results to be displayed on the user interface. This may be performed by exchanging information between an application, such as software 405 or software 407 or other application 409, and the metadata processing software 401 via interface 411. By way of example, the file system software 405 may be embodied as a graphical user interface that allows a user to enter search parameters and to initiate a search to be performed. This information is transferred via the interface 411 to the metadata processing software 401 which causes a search in the metadata repository 415 and may also cause a search in the database 421 of indexed files to search for content in each data file being indexed. The results of the search are provided by metadata processing software 401 to the requesting application, which in the example given herein is software 405, but it should be appreciated that other components of the software, such as e-mail software 407, may be used to receive search input and may be used to provide a display of the results of the search. Various examples of user interfaces for entering search requests and for displaying search results are described herein and shown in the accompanying drawings.

It should be appreciated that notifications are global, system-level notification processes if done in the operating system kernel, such that any file changes will cause a notification to be sent to the metadata processing software. It should also be appreciated that in alternative embodiments, each application may generate the necessary metadata itself and provide the metadata directly to the metadata repository without notification requirements from the operating system kernel or intervention from an input such as input 413. Alternatively, rather than using operating system kernel notifications, embodiments may use software calls from any application to the metadata processing software that receives the calls and then inputs metadata from each file in response to the calls.

As described above, the metadata repository 415 may be stored in the form of an expanded file, thereby increasing information retrieval speed in most cases. The expanded file format may be considered to be a non-B tree (non-B tree), non-hash tree (non-hash tree) format in which data is not intended to be organized but stored as a stream of data. Each metadata object or metadata file itself contains fields, such as those shown in fig. 3A and 3B. However, typically there is no relationship or reference or pointing from one field of one metadata file to the corresponding field (or another field) of the next original data file or another original data file of the same file type. FIG. 6 shows an embodiment of a layout of a metadata expansion file. Format 601 includes a number of metadata files for a corresponding number of data files. As shown in fig. 6, the metadata file 603 is metadata of file 1 from application a, and may be referred to as metadata file a 1. Similarly, metadata file 605 is metadata from file 1 of application B and may be referred to as metadata file B1. Typically, each of the metadata files includes a field that is not linked to other fields and that does not contain references or pointers to other fields of other metadata files. As can be seen in FIG. 6, the metadata repository in FIG. 6 includes metadata files from many different applications (applications A, B and C) and different files created by the applications. The metadata files 607, 609, 611, and 617 are additional metadata files created by the applications A, B and C shown in fig. 6.

The soft query language may be used to search the metadata database in the same manner as the query language is used to search other databases. The data in each metadata file may be packed or even compressed, if desired. As described above, in certain embodiments, each metadata file includes a permanent identifier that uniquely identifies the corresponding data file. Even if the file name changes or the file is modified, the identifier remains the same. This is to achieve a permanent association of a particular data file and metadata.

User interface aspects

Various examples of user interfaces for entering search parameters and for displaying search results are provided herein. It is to be understood that some features of the specific embodiments may be combined with other embodiments, such that the combination results in a hybrid embodiment. It should be appreciated that certain features may be removed from these embodiments and still provide sufficient functionality in many cases.

FIG. 7A shows a graphical user interface that is a window displayed on a display device that interfaces with a data processing system, such as a computer system. The window 701 contains a sidebar having two regions 703A and 703B, region 703A being a user-configured region and region 703B being designated by the data processing system. More details regarding the side bar regions can be found in commonly-filed U.S. patent application No. ___, filed on 22.6.2004 and entitled Methods and apparatus for operating a Data Processing System, Donald Lindsay and Bas Ording, attorney's abstract No. 04860. P3306. Window 701 also includes a display area 705, which in this case displays the search results requested by the user. Window 701 also includes a search parameter menu bar 707 that includes configurable drop down menus 713, 715, and 717. Window 701 also includes a text entry area 709 that allows the user to enter text as part of a search query or search parameter. Button 711 may be a start search button that the user may actuate to start a search based on the selected search parameters. Alternatively, the system may perform the search as soon as it receives any search parameter input or search query from the user, rather than waiting for a command to begin the search. The window 701 may also include a title bar 729 that may be used in conjunction with a cursor control device to move the window on a desktop, which is displayed on a display device, in a conventional manner. The window 701 also includes a close button 734, a minimize button 735, and a resize button 736 for closing or minimizing or resizing the window, respectively. The window 701 also includes a resize control 731, which allows a user to change the size of the window on the display device. Window 701 also includes a back button 732 and a forward button 733 that operate in a similar manner to the back and forward buttons on a web browser, such as an Internet browser (Internet Explorer) or Safari. The window 701 also includes a display controller that includes three buttons for selecting three different types of content display modes on the display area 705. When the content found in the search exceeds the effective display area of the display area 705, scroll controls, such as scroll controls 721, 722, and 723 are displayed on the window 701. This may be accomplished in a conventional manner, such as by dragging the scroll bar 721 over the scroll area 721A using conventional graphical user interface techniques.

The combination of text input area 709 and a search parameter menu bar allows the user to specify search queries or search parameters. Each configurable drop down menu presents a list of options that the user can select when the user activates the drop down menu. As shown in FIG. 7A, the user has made a selection from configurable drop down menu 713 to indicate the location to search, in this case indicating that the search is to occur on the local disk of the computer system. The configurable drop down menu 715 is also used by the user to indicate the type of document to be searched, in this case an image document, as indicated by the configurable drop down menu 715, which indicates that "images" are the selected configuration of the menu, and thus the search parameters, as specifically indicated. As shown in FIG. 7A, configurable drop-down menu 717 represents an added search parameter drop-down menu. This added search parameter drop-down menu allows the user to add additional criteria to the search query to further limit the search results. In the embodiment shown in fig. 7A, the search parameter is logically added in boolean form. Thus, in the state shown in FIG. 7A, the current search parameter indicated by the user searches all local disks for all images, and the user is in the middle of selecting another search criterion, which is accomplished by selecting the Add search criteria drop-down menu 717, resulting in the display of a drop-down menu 719 having a number of options that can be selected by the user.

Fig. 7B shows the window 701 after the user has selected the time option in the pull-down menu 719, thus resulting in the display of a sub-menu 719A that includes possible times from which the user may select. It is thus seen that the user wishes to limit the search for all images at all local disks to a time period determined by making a selection in the submenu 719A.

FIG. 7C shows window 701 on the data processing system display after the user has selected a particular option (in this case, "last week") in sub-menu 719A. If the user accepts the selection, then the display shown in FIG. 7D results in the display of which configurable drop down menu 718 is displayed which illustrates the portion of the search criteria file that was most recently created or modified as selected by the user. As can be seen in fig. 7D, the user may change the particular time selected from the pull-down menu 718 by selecting another time period in the pull-down menu 718A shown in fig. 7D. Note that the configurable drop down menu 717, which represents the add search parameter menu, now moves to the right of the configurable drop down menu 718. The user may further add search parameters by clicking on or otherwise activating a configurable drop-down menu 717 on the search parameter menu bar 707. If the user decides that the number of weeks passed is an appropriate search criteria for the time class, the user may dismiss the drop-down menu 718A from being displayed in a number of different ways (e.g., the user may release a mouse button that is pressed to maintain the display of the drop-down menu 718A). When the drop-down menu 718A is released or otherwise dismissed, the resulting window 701 displayed on FIG. 7E next appears. There are some notable aspects in the user interface shown in fig. 7A-7E. The search parameters and the search query are implemented in the same window as the display of the search results. This allows the user to view a single location or window to understand the search parameters and how the search parameters affect the displayed search results and makes it easier for the user to change or increase the search parameters to obtain one or more files. The configurable drop down menus, for example, add search parameter drop down menus, including hierarchical drop down menus. An example of this is shown in FIG. 7B, where a selection of a time criterion from the pull-down menu 717 results in the display of another menu, in this case a sub-menu 719A, which is selectable by the user. This allows multiple search parameters to be displayed closely while keeping the initial complexity (e.g., without sub-menu display) at a low level. Another useful aspect of the user interface shown in fig. 7A-7E is the ability to reconfigure pull-down menus that have been previously configured. Thus, for example, the configurable drop-down menu 713 may now indicate a search location (in this case all local disks), which may be changed by selecting a drop-down region associated with the configurable drop-down menu 713, resulting in the display of an options menu indicating alternative locations that may be selected by the user. It can also be seen in fig. 7D that the most recent option in this figure is selected by the user (indicated by the "last week" in search parameter menu bar 707), but the options menu displayed by drop-down menu 718A allows the user to change the time of selection from "last week" to other time criteria. Another useful aspect of the user interface is the ability to add various search criteria by using the add search criteria drop down menu 717 and selecting new criteria.

It should be understood that the various options in the drop down menu may depend on the fields in a particular type of metadata file. For example, selection of an "image" to search for may result in various fields set forth in the metadata of the image type file being displayed in one or more drop down menus, allowing a user to search for a particular type of file in one or more of the fields. Other fields that are not applicable to "image" type files may not be displayed in the menu to reduce the complexity of the menu and prevent user confusion.

Another feature of the present invention is shown in fig. 7A-7E. In certain cases, the sidebar region 703A includes an identification of the folder 725 that represents search results obtained from a particular search, the sidebar region being a user-configurable portion of the sidebar, the search results may be static or dynamic in that the search is performed again in certain cases to obtain results based on the current files in the system. Folder 725 in the example shown in fig. 7A-7E represents a search for all images on a local disk completed by No. 10 december. By selecting the folder in the side bar region 703A, the user may cause the display of search results on the display region 705. In this way, the user can automatically retrieve the search results by saving the search results in the sidebar shaped area 703A. The mechanism for causing the search results or search queries to be saved in the side bar region 703A is to select the add folder button 727, which is displayed at the bottom of the window 701. By selecting this button, the current search result or search query is saved in the form of a list of files and other objects retrieved from the current search result. Where the search query, rather than the search results, is saved for later use, the current search query is saved for later reuse to find files that match the search query at a later time. The user may select between the two functions (saving search results or saving search queries) by way of a command selection, not shown.

Fig. 8A and 8B illustrate another aspect of a user interface feature that may be employed in certain embodiments of the present invention. Window 801 in fig. 8A represents a display of search results that may be obtained using one of many different embodiments of the present invention. In this case during the title reproduction time, the search results may be sorted, with the categories separated by titles 805, 807, 809, and 811. This particular division into usage titles is selected by the user using a date modification button 803, by the user selecting the title "modified date" (data modified) using the date modification button 803 at the top of the window 801. By selecting the button 802 at the top of the window 801A shown in fig. 8B, an alternative selection causes the different search result formats to now be sorted by title, which indicates the type of file that was retrieved in the search and separated by titles 815, 817, 819 and 821 as shown in fig. 8B. The use of these titles in the search results display allows a user to quickly browse through the search results to find a file.

Fig. 9 shows another aspect of the present invention, which is illustrated in fig. 9 as part of window 901. The window includes a display area 905 that displays the search results, and the window further includes two sidebar areas 903A and 903B, with sidebar area 903A being a user configuration portion and sidebar area 903B being a system control portion. Folder add button 927 may be selected by the user to cause an additional portion of the search results or search query to be added to the user-configured portion of the sidebar. The window 901 also includes conventional window controls such as a title bar or region 929 that can be used to move the window on the display screen, and view selection buttons 937 and also maximize, minimize, and resize buttons 934, 935, and 936, respectively. The window 901 shows a specific style under which results based on a text search are displayed. The text input area 909 is used to input text to be searched. The text may be used to search in the metadata file or the index file or a combination of both. The display area 905 displays the text search results and includes at least two columns 917 and 919, which provide the names of the found files and matching criteria. As shown in column 919, the match criteria may be an author field or filename or keyword or comment or other data field contained in the searched metadata. Column 921 shows the text found that matches the search parameters entered into the text entry area 909. Another column 911 provides additional information with respect to the search results. In particular, the column includes the number of matches for each particular type of category or field, as well as the total number of matches indicated by entry 913. Thus, for example, the total number of matches found in the comment field is only 1, while other fields have a higher number of matches.

FIG. 10 illustrates other particular aspects of embodiments of the present invention. Window 1001 is another search results window that includes various fields and menus for selection of various search parameters or formation of a search query by a user. The window 1001 includes a display area 1005 that may be used to display search results and a user configurable sidebar area 1003A and a system-designated sidebar area 1003B. In addition, window 1001 includes conventional scrolling controls such as controls 1021 and 1022 and 1021A. The window also includes conventional controls such as a title bar 1029, which may be used to move the window, and display control buttons 1037 and maximize, minimize, and resize buttons 1034, 1035, and 1036. The start search button 1015 is closer to the text entry region 1009. The first search parameter menu bar 1007 is displayed adjacent to the second search parameter bar 1011. The first search parameter search field 1007 allows a user to specify a location of a specific search when the two menu pull-down controls of the second search parameter menu field 1011 allow the user to specify a file type using the pull-down menu 1012 and to specify a time of file creation or last modification using the menu 1013.

Window 1001 includes additional features that are useful when analyzing search results. The user may select a single file from the display area 1005 and add it to a collection. Each file may be individually tagged with a specific command (e.g., pressing the right mouse button and selecting a command from a menu displayed on the display screen, a command that may be "add selection to current group" or the like). By selecting the file individually or by selecting a group of files at once, the user can associate the group of files with the selected group or "marked" group, and this association can be used to perform command actions in all files of the group (e.g., print each file or view each file in a viewing window or move each file to a new or existing folder, etc.). The label group identifier is displayed as a folder in the user configuration area 1003A. An example of this folder is folder 1020 displayed in the user configuration area. By selecting the folder (e.g., by positioning a cursor in the folder 1020 and pressing and releasing a mouse button or by pressing another button), the user may cause grouped or annotated files to be displayed in the display area 1005 as a result of the selection. Alternatively, a separate window may only display tagged or grouped items. The associations or groupings may be only temporary (e.g., they exist only while the search results window is displayed), or may be made permanent by keeping a list of grouped files and by keeping folders 1020 or other grouping identifications in a user-configurable sidebar (e.g., sidebar 1003A). Some embodiments may allow for multiple different groupings to exist at the same time, each of these groupings or associations may be only temporary (e.g., they exist only when the search window is displayed), or they may be permanently retained by keeping a list of all files that have been grouped in each individual group. It should be appreciated that the files in each group may be created by different applications. As described above, a group may be selected and then the user selects a command to perform a common action (e.g., print or view or move or delete) in all files of the selected group.

11A, 11B, 11C, and 11D show alternative user interfaces that allow a user to enter a search query or search parameters. The user interface shown in the figure is displayed in a window 1101 having a user configurable sidebar region 1103A and a system designated sidebar region 1103B. The window 1101 also includes conventional window controls, such as window resize control 1131, which may be dragged in a conventional graphical user interface manner to resize the window, and scroll controls, such as controls 1121, 1122, and 1123. For example, the scroll controller 1121 may be dragged in the scroll region 1121A, or a scroll wheel on a mouse or other input device may be used to cause scrolling within the display region 1105. Further, conventional window controllers include a title bar 1129 that may be used to move windows on the desktop, which are displayed on a display device of the computer system. And the window also includes a view button 1137 and close, minimize, and resize buttons 1134, 1135, and 1136. Back and forward buttons, such as back button 1132, are also provided to allow the user to move backward and forward in a manner similar to back and forward commands in a web browser. The window 1101 includes a search parameter menu bar 1111 that includes a "search by" pull-down menu 1112 and an "sort by" pull-down menu 1114. The "search" drop down menu 1112 allows the user to specify particular search parameters, as shown in FIG. 11B, by selecting from the options that are displayed in the drop down menu once activated. In particular, the drop-down menu 1113 shows an example of a drop-down menu when the "search" drop-down menu 1112 is activated. The "sort" drop down menu 1114 allows the user to specify how the search results are displayed in the display area 1105. In the example shown in FIGS. 11A-11D, the user selects the "date viewed" criterion using the "sort" pull down menu 1114 to sort the search results based thereon. It should be noted that the user can change the type of view of the search query results by selecting one of the three view buttons 1137. For example, the user may select an icon view for the button currently selected in view button 1137, or the user may select a list view or a column view.

FIG. 11B shows the result of a user activating the "search" pull-down menu 1112, which results in the display of a menu 1113, menu 1113 containing a number of options from which the user can choose the basis for performing a search. It should be appreciated that there are a number of different ways for a user to activate the "search" pull-down menu 1112. One approach involves the use of a cursor, such as a pointer on a display screen controlled by a cursor control device, such as a mouse. The cursor is located in the area associated with the "search" menu title (which is the portion of search parameter menu bar 1111 containing "press.. search") and the user then indicates selection of the menu title by pressing a button, such as a mouse button, causing a drop down menu to appear, in this case menu 1113 shown in fig. 11B. At this point, the user may continue to move the cursor to point to a particular option in the menu, such as the "time" option. This may result in sub-menus being displayed on the left or right side of menu 1113. The submenu may be similar to the submenu 719A or the menu 1214 shown in fig. 12A. If the "Category (Kind)" option is selected in menu 1113, the submenu may include an overall list of different kinds of documents, such as images, photographs, movies, text, music, PDF documents, email documents, etc., or the list may include a reference to a particular program name, such as Photoshop, Director, Excel, Word, etc., or it may include a combination of an overall name and a particular name. FIG. 11C shows the result of the user selecting a Photoshop type document from the submenu of the "Category" option displayed in menu 1113. This results in the display of a search parameter menu bar 1111A shown in fig. 11C, which includes a highlight region 1111B indicating a PhotoShop type document to be searched. The search parameter menu bar 1111 is displayed below the search parameter menu bar 1111A as shown in fig. 11C. The user then indicates additional search parameters by again using the "search" pull down menu 1112 or by entering text into the text entry area 1109. By way of example, from the state of window 1101 shown in FIG. 11C, the user may select a "search" pull-down menu 1112, causing a menu to be displayed containing a number of options, such as the option shown in menu 1113 or alternative options related to, for example, a Photoshop document (e.g., various fields of metadata for Photoshop type documents). The union of these fields and other categories of fields (e.g., time, file size, and other parameters) contained in the metadata of PhotoShop type documents may be displayed in a menu, such as menu 1113 activated by selecting the "search" drop-down menu. The user may then select another criterion, such as a time criterion. In this case, window 1101 displays a new search parameter menu bar 1115 that allows the user to specify a particular time. The user may select a time on menu bar 1115 or may activate a pull-down menu by selecting a menu entitled "time," which is displayed as menu title 1116. The state of the window 1101 shown in fig. 11D may then search for all PhotoShop documents created the last 30 or 7 or 2 or the current day or any time based on the particular time period selected by the user.

12A, 12B, 12C, and 12D illustrate another embodiment of a user interface for enabling generation of a search query that searches for metadata and other data, and for displaying results of performing a search using the search query. 12A-12D show representations of a user interface in a column mode; this can be seen by illustrating the selection of the column button, which is the rightmost button in view button 1237 shown in FIG. 12A. The window 1201 has two columns 1211 and a display area 1205, while the window 1251 in FIG. 12C has three columns, columns 1257, 1259 and a display area 1255, and the window 1271 has three columns, columns 1277, 1279 and a display area 1275.

The window 1201 shown in fig. 12A and 12B includes a display area 1205 that displays the search result; the results may be displayed dynamically as the user enters search parameters, or the results may be displayed only after the user instructs the system to perform the search (e.g., by selecting a "perform search" command). The window 1201 includes conventional window controls such as a resize control 1231, a scroll control 1221, a title bar 1229 that may be used to move the window, a window close button, a window minimize button, and various window resize buttons 1234, 1235, and 1236. Window 1201 also includes a user configurable sidebar area 1203A and a system designated sidebar area 1203B. As can be seen from fig. 12A, a "browse" icon 1203C is highlighted in the system designation sidebar region 1203B to indicate that the browser mode is selected. The window 1201 also includes a text entry area 1209 with which the user can enter text to be searched, and the window 1201 also includes a view selection button 1237.

Column 1211 of window 1201 allows a user to select various search parameters by selecting an option which in turn causes display of a sub-menu corresponding to the selected option. In the case of FIG. 12A, the user has selected the "Category" option 1212 and then has selected the "photo" option from the submenu using the submenu 1214, resulting in the display of an identifier 1213 (photo) in the column 1211 under the "Category" option, as shown in FIG. 12A. It can also be seen that the user has previously selected the "time" option in column 1211 and that when the "time" option is selected as the "last week" search parameter, a selection is made from the resulting submenu. After the user has selected various options and sub-options from all of the columns 1112 and any corresponding sub-menus displayed, a display appears as shown in FIG. 12B. Note that the sub-menu no longer appears and the user has completed the selection of various options and sub-options that embody the search parameters. Column 1211 in fig. 12B provides feedback to the user indicating the precise nature of the search query (in this case, the search for all photos dates back to the last week) and that results matching the search query are present on the display area 1205.

Fig. 12C and 12D show alternative embodiments in which the sub-menu is replaced by an additional column that does not disappear after the selection is made, in the embodiment of fig. 12A and 12B the sub-menu is displayed on a temporary basis. In particular, column 1259 of window 1251 functions in the same manner as submenu 1214, except that the column remains within window 1251 after a selection is made (where submenu 1214 is removed from the window after the user makes a selection from the submenu). Column 1279 of window 1271 in FIG. 12D is similar to column 1259. Window 1251 includes a sidebar having a user-configurable sidebar region 1253A and a system-defined sidebar region 1253B. The system designated side bar area 1253B includes a "browse" selection area 1254 having a clear button 1258 that the user can select to clear the current search query. Window 1271 in FIG. 12D provides an alternative interface for explicit search queries. The window 1271 also includes a user configurable sidebar region 1273A and a system specific sidebar region 1273B, but a clear button is located at the top of the column 1277 that is not located with the "search" region 1274. The user may clear the current search parameters by selecting button 1283 shown in fig. 12D.

FIG. 13A shows another embodiment of a window 1301 that displays the search results in a display area 1302. Window 1301 is a window that can be closed, minimized, resized and moved, with resize control 1310, title bar 1305 for moving the form, text entry area 1306 and user configuration section 1303, and system designation section 1304. Window 1301 also includes buttons to select various viewing modes, including icon viewing, list viewing, and column viewing. Currently, list view button 1316 is selected, causing the search results to be displayed in display area 1302 in a list view manner. It can be seen that text ("button") is entered into the text entry area 1306 and this enables the system to respond to the search results presented in the display area 1302. The user indicates that the search is being conducted at all locations by selecting the "everywhere" button 1317. Further, the user searches for all kinds of documents by selecting a "kind" option in the drop-down menu 1315 and an "any" option in the drop-down menu 1319. Location portion 1307 includes a "+" button that can be used to further add search arguments, and simply, portion 1308 includes "+" and "-" buttons for adding or deleting search arguments, respectively. Section 1307 also includes a "save" (save) button 1309 that causes the current search query to be saved in a folder that is added to user configuration section 1303 for later use. This will be described further below and may be referred to as a "smart folder". In particular embodiments, the search input user interface shown in FIGS. 13A and 13B may be active within each window controlled by a graphical user interface file management system, such as the Finder program running on Macintosh or Windows Explorer running on the Microsoft Windows operating system. The interface includes a text entry area 1306 and portions 1307 and 1308.

The window 1301 shown in fig. 13B displays the start of the menu by selecting the search button 1323A, resulting in the display of a menu having two input portions 1323 and 1325. Input section 1323 displays the most recently performed search so that the user can restart the previous search by merely selecting the previous search and have the previous search run again. Menu selection 1325 allows the user to clear the list of recent searches in the menu.

14A, 14B, and 14C show an example of another window in a graphical user interface file system, such as a Finder program running on a Macintosh operating system. These windows display the results of a particular search and also display the ability to save and use smart folders that hold previous searches. Fig. 14A shows a window 1401 including a display area 1403, a user configuration area 1405, an intelligent folder 1406, a system designation area 1407, an icon view button 1409, a list view button 1410, and a column view button 1411. The window 1401 also includes a text entry area 1415 and a location portion 1416, which can be used to specify a search location, and a save button 1417. The additional section below section 1416 allows the user to further specify details about the search, in this case the type of document that was the image that was last viewed in the week. The user sets the search parameters in this case by selecting the "category" option from the pull-down menu 1419 and the "image" type from the pull-down menu 1420 and the "most recently viewed" option from the pull-down menu 1418 and the "this week (this week)" from the pull-down menu 1422. The user also selects "everywhere" by selecting button 1421 to search for all disks and storage devices connected to the system. The result is displayed on the display area 1403. The user then stores the search query by selecting the "save" button 1417, and may name the saved search query as "images of the week" to generate the smart folder 1406, as shown in the user configuration section 1405. This allows the user to repeat the search in relatively close time simply by selecting the smart folder 1406 which causes the system to perform a new search again and all data matching the search criteria will be displayed in the display area 1403. Thus, if none of the files displayed in display area 1403 in FIG. 14A were viewed in the last weeks from the next search performed by selecting smart folder 1406, after several weeks, a repeat of the search by selecting smart folder 1406 will produce a completely different list.

FIG. 14B illustrates a manner in which a user may sort or further search among search results determined by a saved search, such as a smart folder. In the case of FIG. 14B, the user has selected smart folder 1406 and then entered the text "jpg" 1425 in text entry area 1415. This causes the system to filter or further limit the search results obtained for the search queries saved by intelligent folder 1406. Thus, PhotoShop files and other files such as TIF files and GIF files are excluded from the search results displayed in display area 1403 of fig. 14B because the user has excluded these files by adding additional search criteria, which are indicated by text 1425 in text entry area 1415. It can be seen that the "jpg" text entry is logically anded with other search parameters to obtain search results displayed in the display area 1403. It can also be seen that the user selects the icon view by selecting the icon view button 1409. Thus, it is possible for a user to save a search query and then use it, and further restrict the results of the search query by performing a search on the results of the search query to further restrict the search results.

FIG. 14C presents a window 1401 and presents search results displayed in a display area 1403 where the results are based on the saved search determined by the smart folder 1406. The user causes a drop down menu 1427 to be displayed by selecting the drop down region 1427A. Drop down area 1427 includes a number of options that the user may select. These options include hiding search criteria or saving a search (which is similar to select button 1417) or displaying view options or opening a selection file. This allows, for example, the user to hide the search criteria, thus allowing portion 1416 and other search parameters to be removed from window 1401, which is a movable, resizable, minizable, and closable window.

FIG. 14D shows an example of a user interface that allows a user to specify, for example, the appearance of the smart folder 1406.

15A, 15B, 15C, and 15D show examples of a system level search input user interface and a search results user interface. In a particular exemplary embodiment, these user interfaces are valid for all applications throughout the system that run on the system and all files and metadata and even address book entities in the address book program, such as personal information management programs, calendar entities in calendar programs, emails in email programs, and so forth. In one exemplary embodiment, the system begins performing the search and begins displaying the search results as text that the user types into a text entry area, such as text entry area 1507. The search results are organized in categories and displayed in a shorter list that is intentionally abbreviated to present only the most relevant (better-rated) matches or hits for a selected number of search queries. The user may request the display of all hits by selecting a command, such as a "show all" command 1509. FIG. 15A shows a portion of a display controlled by a data processing system. This section includes a menu bar 1502 with a search menu command 1505 at the distal end of the menu bar. The user may select the search menu command by positioning a cursor, using a mouse, for example, placing the mouse over the search menu command 1505, or by otherwise actuating or selecting the command. This causes display of a text entry area 1507 into which the user can enter text. In the example shown in fig. 15A, which is a portion of the display, the user enters the text "shakeit" which causes the display of a search results area that is directly below the "show all" command area 1509, which itself is directly below the text entry area 1507. It can be seen that hits or matches are grouped by category ("documents" and "PDF documents" (PDFdocuments)), which are shown as categories 1511 and 1513 of the search results region 1503. FIG. 15B shows another example of a search. In this case, a large number of hits (392 hits) are obtained, of which only a few are displayed in the search results region 1503. Additionally, hits are organized by categories 1511 and 1513. The number of items displayed on the display results region 1503 is limited for each category to allow more categories to be displayed on the search results region at the same time. For example, the number of hits in a document class may greatly exceed the available display space in the search results region 1503, but the hits for that class are limited to a predetermined or dynamically determined number of entities in the search results region 1503 of the class 1511. An additional class, "top hit" is selected based on score or relevance using techniques well known in the art. The user may select the "all display" command 1509 to cause the display of a window, such as the window 1601 shown in FIG. 16A. Fig. 15C illustrates the display of a graphical user interface including a menu bar 1502 and a search menu command 1505 on the menu bar 1502, in accordance with one embodiment of the present invention. Fig. 15D shows another example of the search results region 1503, which is displayed after a search input of the term "safari" into the text entry region 1507. As can be seen in the search results region 1503 in fig. 15D, the search results are again organized by category. Another search results window 1520 is also shown in the user interface of fig. 15D. It can be seen that the applications are retrieved as part of the search results and the user can load any of the applications by selecting it from the search results area, thereby causing the program to load.

Fig. 16A and 16B show an example of a search result window, which is caused to be displayed by selecting the "all display" command 1509 in fig. 15A or 15B. Alternatively, the window is displayed as a result of the user selecting a "find" command or some other command indicating that the search is expected. In addition, the window 1601 shown in fig. 16A and 16B may be displayed in response to a selection to display all commands or in response to a selection to search for a command. The window 1601 includes a text input area 1603, a grouping menu selection area 1605, a sorting menu selection area 1607, and a place menu selection area 1609. The grouping selection area 1605 allows the user to indicate the manner in which items are grouped accordingly among the search results. In the example shown in FIG. 16A, the user selects the "Category" option from the grouping menu selection area 1605, resulting in search results grouped or categorized by category or type of document or file. As shown in fig. 16A, it can be seen that the file types include "html" files, image files, PDF files, source code files, and other types of files. Documents of each type or category are separated from other documents by grouping within a section and from other sections by headers. Thus, the headers 1611, 1613, 1615, 1617, 1619, 1621, and 1623 specify each packet and separate one packet from the other. This allows the user to focus attention on evaluating search results according to document type. Within each group, such as a document group or a folder group, the user indicates that the items are stored by time because the user selected the date option in the sorting menu selection area 1607. The user also indicates that all storage locations are searched by selecting "anywhere" in the places menu selection area 1609. Each item in the search result list includes an information button 1627 that may be selected to generate a display of additional information that may be obtained from the system. An example of this additional information is shown in FIG. 17, where a user selects an information button 1627 from an item 1635, resulting in the display of an image 1636 corresponding to the item and the display of the additional information 1637. Similarly, the user selects an information button from another item 1630 to generate a display of an image of the item 1631 and additional information 1632. The user may remove the additional information from the display by selecting the close button 1628, which causes the display of the information of item 1635 to revert to the appearance of the item shown in FIG. 16A. The user may collapse the full group by selecting collapse button 1614 shown in FIG. 16A to hide entries or search results in the group, resulting in the disappearance of entries in the group as shown in FIG. 16B. As shown in fig. 16B, the user can restore to the item display shown in fig. 16A by selecting expand button 1614A to cause the item to reappear.

The search results user interface shown in fig. 16A and 16B only shows a limited number of matches or hits in the class. In the particular example of this figure, only the five top-level (most relevant or highest ranked) hits are displayed. This can be seen by noting the entry at the bottom of each list in the group that indicates how many hits are still in the group; these hits may be checked by selecting the indication section, such as indication section 1612, which causes all items in the document category or category for the search of "button (button)" to be displayed, which is input to text input area 1603. Further examples of this behavior are described below and shown with reference to fig. 18A and 18B. It should be appreciated that window 1601 is a window that can be closed and resized and moved and includes a close button and resize control 1625A.

Fig. 18A and 18B illustrate another window 1801 that is very similar to window 1601. The window 1801 includes a text entry area 1803, a grouping menu selection area 1805, a category menu selection area 1807, and a place menu selection area 1809, each of which functions in a similar manner to areas 1605, 1607, and 1609, respectively, in fig. 16A. In a list view in window 1801, each item includes an information button 1827 that allows the user to obtain additional information beyond the list of items shown in window 1801. The window 1801 also includes headings 1811, 1813, 1815, 1817, 1819, 1821, and 1823 that separate each group of items from the other, grouped by category or kind of document, and ordered by date in each group of items. The collapse button 1814 is effective for each title. The embodiment shown in fig. 18A and 18B shows the exchange between different modes of viewing information. For example, as shown in FIG. 18A, the user may display all hits in a particular group by selecting an indicator portion 1812 that causes all image files to be displayed in window 1801 in area 1818A. The window is scrollable, thus allowing the user to scroll through the images. The user may revert to displaying only the list of the five most relevant images by selecting the "show top5 5" button 1832 shown in fig. 18B. In addition, the user can make a selection in the list view or icon view of the image portion shown in fig. 18A and 18B. The user may select list viewing by selecting list viewing button 1830 or icon viewing by selecting icon viewing button 1831. In FIG. 16A, a list view of a group of images is shown; and in fig. 18A and 18B, icon views of image groups are shown. It can be seen that in a single, movable, resizable, closable search result window, there are two different viewing modes (e.g., list viewing and icon viewing) that are displayed simultaneously in the window. For example, in fig. 18A and 18B, PDF documents under the title 1819 are displayed in list view, while graphics under the title 1817 are displayed in chart view. As can be seen in FIGS. 18A and 18B, each image is displayed in preview form, as described in the patent application entitled "Live Content Resizing" (filed) by the inventors SteveJobs, Steve Lemays, Jessica Kahn, Sarah Wilkin, David Hyatt, J ens Alfke, Wayne Loofbourrow, and Bertrand Serlet, which was filed the same date as the present application and which has been assigned to the assignee of the present invention described herein and which is hereby incorporated by reference.

Fig. 19A shows another example of a search results window, which is similar to window 1601. Fig. 19A shows a window 1901 including a text entry area 1903 and a grouping menu selection area 1905 and a classification menu selection area 1907 and a place menu selection area 1908. In addition, the window also includes a close button 1925 and a resize control 1925A. Text is entered into a text entry area 1903 to produce the search results shown in window 1901. The search results are again grouped by category selected by the user, in this case the people (peoples) option 1906. This causes titles 1911, 1913, 1915, and 1917 to display groups respectively according to the names of the persons. Within each group, the user selects to sort by the date of the particular file or document. By way of example, the user interface shown in FIG. 19A allows a user to specify the names of individuals and allows the user to group by person to view communications between two people. FIG. 19B illustrates another manner in which a user groups text searches ("imrans") in a different manner than that shown in FIG. 19A. In the case shown in fig. 19B, the user selects a spread list (flat list) in the group of the menu selection area 1905 and selects "person" from the sorting menu selection area 1907. The results display of window 1901A has no title and is therefore displayed as an expanded file.

FIG. 19C shows a user interface of another search results window 1930 that includes text entry area 1903 and selection areas 1905, 1907, and 1908, and scroll controller 1926. The results displayed in window 1930 are grouped by date and sorted by date in each group. Thus, the headings 1932, 1934, 1936, 1938, and 1940 specify a time period, such as the time of the last modification of the document (e.g., the last modification today, or yesterday, or last week). Also displayed in search results window 1930 is an information button 1942, which may be selected to reveal more information, such as an icon 1945 and additional information 1946, displayed in the items under the today's group. This additional information can be removed by selecting the pinch button 1944.

Fig. 19D shows a search results window 1950 in which searches for the text string "te" are grouped by date, but are limited to the "home" folder indicated by the menu selection area 1908. As shown in fig. 19D, time-specific titles 1952, 1954, 1956, and 1958 separate items from other groups in the group.

FIG. 19E shows an alternative embodiment of a search results window. Under this embodiment, window 1970 includes similar elements to window 1901; such as selection areas 1905, 1907, and scroll control 1926 as well as close button 1925 and resize control 1925A. Search results window 1970 also includes a "when" menu selection area 1972 that allows the user to specify search parameters based on time and text entered into text entry area 1903. As can be seen in the example shown in FIG. 19E, the user decides to group the search results by category and sort by date in each group. The results of the headings 1973, 1975, 1977 and 1979 are shown in figure 19E.

FIG. 20 shows an exemplary method of operating a system level menu to enter a search query, such as the system level menu that may be used by selecting search menu command 1505 as shown in FIG. 15A or 15B or 15C. In operation 2001, the system displays a system level menu for entering a search query. This may be a search menu command 1505. The user enters a search in operation 2003 and, at the time of search query entry, the system begins executing and begins displaying search results before the user has finished entering the search query. Thus, after the user inputs information, timely feedback and user input are provided. In operation 2005, the system performs a search among the files, metadata of the files, emails in the email program, address book entries in the address book program, calendar entries in the calendar program, and so forth. In operation 2007, if there are more than a certain number of hits, the system then displays a reduced (e.g., incomplete) list of hits. An example of a reduced list is shown in fig. 15B. The list may be sorted by relevance and separated into groups, such as categories or categories of documents. Next, the system receives a command from the user to display all hits in operation 2009 and displays a search results window, such as window 1601 shown in fig. 16A, in operation 2011. The window has the ability to display two different types of views, such as icon views and list views, in the same closable, resizable and movable window. It should be appreciated that the search performed when the user types and the display of results when the user types may include a search for metafiles created from metadata extracted from files created by many different types of software programs.

In describing another aspect of the present invention, reference is now made to FIGS. 21 and 22A, 22B, 22C and 22D. This aspect relates to a method of selecting a set of files, such as a set of independent data files. In an exemplary method of this aspect, a data processing system receives a selection of a number of items, such as data files, folders (e.g., graphical user interfaces representing subdirectories), applications, or a combination of one or more of these items. The selection may be performed by one of many conventional methods for selecting many items, such as (a) individually positioning a cursor over each item (e.g., by movement of a mouse) and indicating the selection, such as by pressing and releasing buttons, individually, such as mouse buttons; (b) pointing the cursor to the first item in the list and indicating a selection of the first item and pointing the cursor to the last item of the list of items and indicating a selection of all items in the list from the first item to the last item; (c) a selection rectangle is drawn by an operation of dragging a cursor, and so on. Thus, operation 2101 shown in FIG. 21 receives one or more inputs indicating the selection of a plurality of items. The system in operation 2103 receives a command that requires both the creation of a new storage tool (e.g., a folder) and the attachment of many items with the new storage tool. Although operation 2103 is shown after operation 2101, in certain embodiments operation 2103 may precede operation 2101. The dependent operation of operation 2103 may be a copy or move operation. For example, a user may select multiple items and then instruct the system to move those items from where they exist to a new folder that is created in one operation as a result of the move and create new folder commands. In response to the command received in operation 2103, the system creates a new storage tool, e.g., a new folder, using the predetermined directory pathname or user-specified pathname, the system further associates the selected plurality of items with the new storage tool. The association may be a move or copy operation. Typically, the copy operation includes copying and storing the item under a path name for each selected item, as if the item was stored in a new folder with a predetermined directory path name or a user-specified directory path name. The move operation, in which items are moved into a new folder, may simply change the pathname associated with each selected item (rather than copying the item), which would affect the location of the new file system for the selected item (e.g., in a subdirectory of the new folder).

FIGS. 22A-22D illustrate an example of the method of FIG. 21. A desktop 2201 on the display device is displayed, which desktop includes a number of windows and also includes icons 2227 on the desktop. A cursor 2211 is also displayed on the desktop. Windows 2203, 2205, and 2207 each contain a number of items that are displayed as icons. In particular, window 2203 includes a data file represented by icon 2215 that is within a folder (e.g., a graphical representation of a subdirectory in a file storage system) represented by icon 2217. Window 2205 includes a program icon 2223 and a document icon 2219 and another document icon 2225 and a folder icon 2221. Window 2207 displays a list view of some files including "File B (File B)". The user may then select multiple items using cursor 2211 or using other conventional user interface techniques. This may be done using one input or multiple inputs indicating the selection of multiple items. FIG. 22B shows the results of the user selecting icons 2215, 2217, 2223, 2225, 2227 and "File B (File B)" in window 2207. It can be seen that cursor 2211 is adjacent to icon 2225 in the operative position. The user may then invoke the command mentioned in operation 2103 after selecting a number of items. An example of this is shown in FIG. 22C, which shows a portion of the desktop 2101, which is designated as 2201A as shown in FIG. 22C. The user causes a pop-up menu 2230 to be displayed that includes three items 2231, 2232, and 2233. Option 2231 allows the user to move all selected items to the recycle bin (e.g., delete them), while options 2232 and 2233 are related to the commands in operation 2103 in fig. 21. In particular, option 2232 is a command that can be selected by the user to create a new folder, and under the same operation, remove items that have been selected into the new folder. Option 2233 is a command that in operation allows the user to generate a new folder and copy the selected items to the new folder. In the example shown in fig. 22A-22D, the user selects option 2232, which causes the system to generate a new storage tool, such as a new folder having a predetermined pathname (e.g., "new folder"), or alternatively, a new folder having a user-specified pathname. The result is shown in FIG. 22D, where desktop 2201 now includes a new window titled new folder, which represents and displays the contents of the new folder, which is also shown as folder 2253, which folder 2253 is a graphical user interface that represents the new folder.

It should be appreciated that various alternatives may be used with this method. For example, a window is displayed after command option 2232 or 2233 is selected, and the window asks for the name of the new folder. In the case where the user does not input a new name, the window displays a default name (e.g., "new folder"). Alternatively, the system may simply default pathnames to new folders or new storage facilities. In addition, the system can simply create a new folder and move or copy items into the new folder without displaying the new window in FIG. 22D.

FIG. 23 relates to an aspect of information processing that is directed to updating one or more databases, such as an index database or a metadata database. Updates to one or more databases are performed and controlled in response to user behavior on the data processing system. Typically, use by a user that is used more frequently will cause the system to automatically adjust the number of index database or metadata database updates so that the user's behavior and use of the data processing system are not adversely affected by the update operations on one or more databases. It should be appreciated that in particular embodiments, only one type of update, rather than all types of updates, is controlled in response to user behavior; for example, because indexes typically require higher computer resources, the indexes may be controlled to respond to user behavior, but not the operation of the metadata repository. Operation 2301 relates to monitoring of user usage of the data processing system. Which can be done in a number of different ways depending on the data processing system. For example, a data processing system using a UNIX-based operating system typically includes a device that provides an indication of the number of programs used that "belong" to a user, which may be referred to as a "root" user, relative to all programs controlled by the data processing system. One or more thresholds of user behavior may be used to determine whether the usage or behavior of a user on the data processing system is at a higher or lower level. For example, if the user is not inputting data or positioning a cursor and the user's owning application is not performing calculations or data processing, then typically the user behavior is considered low. On the other hand, if the user enters data or otherwise makes data available or causes a user program to perform a complex set of calculations, then the data processing system will typically determine that the user usage of the system is high. Operation 2303 shows how, in an exemplary embodiment, the system responds when the user's usage is at a higher level. In this case, the data processing system either stops the indexing and/or input operations of the metadata or sets the indexing and/or metadata software to a lower priority (e.g., the Nice command is changed), e.g., sets a lower processing priority to one or all of the indexing software and the metadata software. This allows the system to provide more processing time for the user's program and less processing time for the indexing software and/or metadata software. This type of control is useful in operating systems that provide preemptive multitasking. Typically, as shown in FIG. 23, the data processing system operates in a loop in which it continues to monitor the user's usage after adjusting the processing priority. If the system determines that the user's usage is below a threshold, then the system gives the indexing and/or metadata software higher processing priority, as shown in operation 2305, and returns to the user usage monitoring of operation 2301.

FIG. 24 illustrates a method according to another aspect of the invention described herein. In the method, the notification is used to automatically cause an update of the index database. Preferably, the notification may be entered into an index queue (e.g., an "about to index" sequence), and typically the notification is based not only on time, but also only on user input. In operation 2403, a notification is automatically generated in response to a change to an existing file or saving a new innovative file. For example, the kernel of the operating system may automatically generate a notification in response to a user or system initiated save, such as writing a file to a hard disk. The system performs this saving automatically (e.g., certain word processing programs and other software allow the user to set the auto-save operation to occur after a predetermined period of time has elapsed). The automatically generated notification is introduced to the indexing software component, which receives the notification in operation 2405. Preferably, the notification is entered into an index queue, which will be discussed further in connection with FIG. 25. In operation 2407, the indexing software performs indexing of the file and stores the index data into an index database. The index responds to the notification, rather than responding to the occurrence of a specified time or a command by the user to perform the index. Further, the notification indicates the file by an identifier.

FIG. 25 illustrates a particular exemplary methodology for performing indexing using notifications and also saving notification inputs to a queue (e.g., an index queue) on a non-volatile storage device, such as a hard disk of a data processing system. Further, the method displays that information about queue changes can be entered into the transaction log. The file and index database containing the indexed content of the text construct and the index queue and log may all be stored on the same non-volatile storage device. The method of FIG. 25 may also be performed for notifications to update metadata in a metadata database; in particular, notifications to add or change metadata in the metadata repository may be added to the queue to update the metadata, and the queue (e.g., a "metadata queue") may be stored on non-volatile memory, and information about changes to the queue may be entered into the transaction log. The file and metadata repository containing the file metadata and the metadata queue and journal may all be stored on the same non-volatile storage. Typically, a log including information about the queue changes is saved on non-volatile memory before the queue changes are stored on non-volatile memory.

The method of FIG. 25 may begin at operation 2501, where a notification from an operating system kernel is received. The notification indicates that an existing file was changed or that a new file was created. The notification typically includes an identifier that indicates the file (e.g., by a permanent unique file ID number). In operation 2503, a file identifier is entered into an index queue and the queue is stored on a non-volatile memory, such as a hard disk. Further information about queue changes is entered into a transaction log, which is maintained by indexing software or metadata base software. The log is designed to maintain the state of the data processing system in the event of a system crash. Existing techniques for implementing the log may be used to maintain information about the queue. The log may be implemented as a simple log or as a log maintained by "ACID" (automation, consistency, independence and persistence) compliant records similar to those maintained by a record file system. Next, in operation 2505, indexing is performed on the files listed in the index queue. Because the indexing software completes the indexing of the file, this causes the file identifier to be removed from the file from the index queue and causes storage on the update queue to non-volatile memory and also causes information about the queue change to be entered into the transaction log in step 2507.

FIG. 25 illustrates further aspects of an embodiment. In particular, it shows how the system implements interruptions in metadata indexing or updating in response to growing user behavior through the use of an index queue and/or a metadata queue. This is shown in operations 2509 and 2511, which implement user interruption in response to increasing user usage and then implement index or metadata processing resumption in response to decreasing user usage. The index queue and metadata queue allow the system to track changes to files and input information identifying files in the index queue and metadata queue without the need to perform indexing and importing of metadata while a user is actively using the data processing system.

Fig. 26, 27 and 28 relate to another aspect of the invention described herein. This aspect relates to the intent of determining whether to update an index database or a metadata database without necessarily requiring examination of every record or file indexed in the index database or added to the metadata database.

FIG. 26 illustrates an exemplary method of determining whether to update a database, such as an index database or a metadata database. The method is removable at the storage device and is removable from and removable from a data processing system, such as a USB hard drive or a USB flash drive or other type of removable storage device or storage. For example, a removable storage file is indexed on a first data processing system, and then the removable storage device is removed from the first data processing system and connected to a second data processing system that does not automatically perform indexing of the file content or add (e.g., import) metadata from the file into a metadata repository. The user may change the files on the storage volume when the storage volume is connected to the second data processing system without updating the index database or the meta database. In addition, when the storage volume is connected to the second data processing system, the user may create a new file and store it on the removable storage device. This also occurs without adding the contents of the new file to the index database and without adding the metadata of the new file to the metadata database. The removable storage device may then be detached from the second processing system and reconnected to the first data processing system. The indexing software and metadata software on the first data processing system are intended to determine that the indexing database and/or metadata database stored on the removable storage device needs to be updated. Similar needs arise in the case of non-removable storage devices. For example, a user may create and/or change files through some action that prevents the data processing system from obtaining the necessary processing time to index and import metadata from the new or changed files. After the user's action, the user instructs the system to shut down or instructs the system to power down (e.g., the system is powered by a battery, such as a notebook computer, and there is insufficient power left on the battery, requiring the notebook computer to shut down as quickly as possible).

The method of FIG. 26 begins at operation 2601, where it is determined when the index database of the file system is eventually updated for a particular bank. In operation 2603, after the last update time of the index database, it is determined whether a file was updated or created. Preferably, rather than using the last update time of the index database, a period of time, such as one hour, is used earlier than the last update time to compensate for system clock differences between one data processing system and another. Next, in operation 2605, the data processing system updates the index database for all files that were updated or created after the index database last update time, or if used a period of time, e.g., one hour, earlier than the last update time, the index database will be updated for any files that were updated or created one hour earlier than the index database last update time. The technique shown in FIG. 26 allows for determining whether to update the database based on a time-based comparison that does not require checking the records of each file indexed in the index database. The technique of the method shown in FIG. 26 may also be used to determine whether the metadata repository needs to be updated to add metadata from a file that was updated or created after the time the metadata repository was last updated (or after a period of time, say an hour, earlier than the last time).

The method shown in FIG. 27 illustrates a specific example of how it may be determined whether to update an index database or a metadata database. The method of fig. 27 may be performed using the time comparison population or the specific time comparison shown in fig. 28. The methods of fig. 27 and 28 may be used to determine whether to update an index database or a metadata database or both databases stored in the storage volume. It should be appreciated that, at least in certain embodiments, the indexed file and the metadata for the file stored in the metadata repository are stored on the same device that also stores the particular index database and metadata repository. That is, the index database is typically (in these embodiments) not separate from the file indexed into the index database, and similarly, the file containing the metadata and the metadata database are typically (in these embodiments) not separate from the file. In an alternative embodiment, a database, such as an index database or a metadata database, may be stored on a storage medium or storage device separate from the file from which the database's data is obtained.

The method of FIG. 27 may begin at operation 2701, where the data processing system completes indexing and closes the index database and index queue and unloads the memory banks indexed (at least partially indexed) by the first data processing system. Preferably, the first data processing system may perform operation 2801 shown in FIG. 28 during a memory bank cut or mount. This operation includes three values, which are the time the index database is closed, the time the file system on the storage volume is unloaded, and the write count of the storage volume at the time of shutdown or unloading. The storage volume may then be used for another data processing system in operation 2703 and the file may be changed without updating the index database and/or the metadata database. The database of indexing software and/or metadata software that is not necessary on the data processing system may be changed. In operation 2705, the memory bank is again assembled onto the first data processing system. Preferably, at this point in time, the first data processing system may perform operation 2803, which includes collecting three values, which are the last mount time of the bank, the database open time, and the current write count. As can be seen in fig. 28. Next in operation 2707, the first data processing system determines after the index database was last closed and/orWhether any files on the storage volume have changed after the metadata library was last closed. Operation 2805 in FIG. 28 shows one example of how to determine whether to update the database. In operation 2805, whether there are two time values T_FSAnd T_DSThe difference between is determined to be less than a small time delay and similarly, whether two other time values T are present_D0And T_FMThe difference between is determined to be less than another, smaller time delay (which may be the same or different in time from the other time delay). In addition, the two write counts are compared to determine if the difference between them is less than a small number. As shown at operation 2805 in fig. 28, if the three interpolations are less than a particular value, it may be determined that the index database (and/or metadata database) does not need to be updated. If any of these comparisons fail in operation 2805, it may then be determined that a database, such as an index database or a metadata database, needs to be updated. The method of fig. 27 is useful even when the memory bank is not removable. It is often the case that a data processing system is repeatedly turned on and off for short periods of time, such as an hour or less. Browsing files to determine whether to index a new file is a waste of computing resources. The method of fig. 27 is therefore intended to determine whether a database needs to be updated without having to examine the records of each file in the database. The particular method in FIG. 28 is intended to verify that no files have changed after the index database is closed, and does so by comparing some time values rather than comparing the time values of each file or by sorting the files by time.

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (8)

1. A machine-implemented method of processing data, the method comprising:

determining that a file is to be indexed into an index database or that metadata from the file is to be added to a metadata database;

adding an entry representing the file to a list of index operations and metadata operations;

saving the list to non-volatile memory; and

performing an indexing operation and a metadata operation, wherein in response to detecting user activity beyond a threshold level, a processing priority of the indexing operation and/or a processing priority of the metadata operation is set to a lower priority, and wherein in response to detecting user activity below the threshold level, the processing priority of the indexing operation and/or the processing priority of the metadata operation is set to a higher priority.

2. The method of claim 1, further comprising:

after indexing the file, effectively removing the entry from the list to create an updated list; and

saving the updated list to the non-volatile memory.

3. The method of claim 2, wherein the determining step comprises receiving a notification that the file is to be indexed, the notification being communicated from an operating system component to an indexing component.

4. The method of claim 3, wherein the notification is not based solely on time or user input and the transaction log displays a change to the list.

5. A data processing system comprising:

means for determining that the file is to be indexed into an index database or that metadata from the file is to be added to a metadata database;

means for adding an entry representing the file to a list of index operations and metadata operations;

means for saving the list onto non-volatile memory; and

means for performing an indexing operation and a metadata operation, wherein in response to detecting user activity exceeding a threshold level, a processing priority of the indexing operation and/or a processing priority of the metadata operation is set to a lower priority, and wherein in response to detecting user activity below the threshold level, the processing priority of the indexing operation and/or the processing priority of the metadata operation is set to a higher priority.

6. The system of claim 5, further comprising:

means for, after indexing the file, effectively removing the entry from the list to create an updated list; and

means for saving the updated list onto the non-volatile memory.

7. The system of claim 6, wherein the determining means comprises means for receiving a notification, the notification being communicated from the operating system component to the indexing component.

8. The system of claim 7, wherein the notification is not based solely on time or user input and the transaction log displays changes to the list.